RE: iSCSI gateways, proxies, etc.

["Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com>]

Charles,
 Comments in <JIM> </JIM> and other stuff snuffed out.

Jim Hafner


Charles Monia <cmonia@NishanSystems.com>@ece.cmu.edu on 10-12-2000 03:02:19
PM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI gateways, proxies, etc.



Hi Jim:

>
> Charles,
>
> In some sense I agree with you.  But I'd turn it around. In
> your scenario,
> it is MY OBLIGATION to give to A an identifier for B that is
> consistent
> with A's view of the world. I shouldn't be so myopic to
> think that A's
> equals mine.   How I might discover A's view of the world is
> implementation
> dependent.  In fact, one might argue that if I don't know A's
> view of B,
> then I have no right to ask A to do something with the data on B!
>
I think that's unworkable in practice. More to the point,

First, 'A' should not advertise to the initiator a capability that it can't
support.
More importantly, I think that approach is unworkable in practice when the
labyrinth of tunnels, firewalls and the like is considered. I believe, when
the dust settles, we will have to assume the presence of some sort of
storage name server that mediates these kinds of addressability problems.

<JIM>
This storage name server is an implementation of something that enables
what I'm talking about in a somewhat transparent way.  Namely, if the
initiator knows about the presense of this server AND that A uses it, then
it can use the hooks of that server to provide A enough information for A
to find B.  In other words, this server is the way the initiator "discovers
A's view of the world".   I certainly won't argue that this is not a bad
way to go, I only argue that this is one implementation.  The requirement
for I to give A an identifier for B that is in A's view is still there.
There server just makes the world appear transparently to be global, in a
manner that is analogous to DNS.
</JIM>

> In your second paragraph, you suggest WWN.  I have to ask
> "whose WWN?"

I meant the SCSI device wwn.
<JIM>
Do SCSI devices have WWNs or just Logical Units?  I guess I didn't know
that.  Can you point to the T10 spec (or draft) that has that?  Thanks.
</JIM>

...Frankly, I haven't thought this through in detail, but I
suspect we may have to have ask T10 for some way for an initiator to
dynamically assign a LUN to a specific LU WWN. ...
<JIM>
Who does the initiator ask the question of "can I have a LUN for this LU
WWN?".  If its the target of that logical unit, then that initiator already
has LUN for that WWN implicit in the combination of REPORT LUNS and INQUIRY
(EVPD), assuming it has access to that logical unit (if it doesn't then the
answer to the above question should be NO).   If it's not the target of
that logical unit, then it must be some server or service (not a SCSI
thing).  In that case, it only needs to again ask for the target address
and it can then find the LU as above.  It can't ask the server for target
address AND LUN because the LUN association to logical unit (and initiator)
is owned by the target.

One might propose to T10 a twist on this that I don't think would cause too
much stir: a command that an initiator can ask the question "which of my
LUNs is mapped to the logical unit with LU WWN?".  [Or is this what you
meant in the first place.].  The semantic difference between the question
you phrased and this, is that I'm not asking for the target to create a LUN
for me, just assist me in finding it quickly.  [Is this a bi-directional
command?].  Or we could make it even simpler and have REPORT LUNS AND
IDENTIFIERS command which allows the initiator to get both the LUN set and
the identifiers in one command sequence.

The access controls has a "can I have a LUN for this Proxy Token?" to
enable a similer function, but the notion here is that the Proxy Token is
the explicit permission token to get the access right and have a LUN
generated by the target.  That is, prior to seeing the token, the target
will not have a LUN for that LU in the initiator's REPORT LUNS list.
</JIM>

As noted above, I'm assuming any WWN that can be converted by the name
server to a network address for accessing the device.  As you've noted, the
real issue is what such a WWN stands for. In my view, the most intuitive
definition is that the WWN represents the iSCSI device abstraction as it
appears to other iSCSI devices on the network.  As you note above, such a
definition is particularly convenient for an iSCSI-to-fc gateway, since fc
devices already have such identifiers.
<JIM>
IMHO, we don't have such an identifier defined for the iSCSI device
abstraction.  The nearest thing seems to be ipname:port or ipaddress:port.
If that's not sufficient (and many think so), then we need something more.
The key here is that if we define such a thing, it MUST be WW unique, and
the namespace probably has to be managed by some entity (IEEE, or IETF) to
guarantee uniqueness.
</JIM>

In that sense, the issue of parallel SCSI compatibility is a bit of a red
herring. This is simply another issue, among many, that an iSCSI gateway
would have to address if it chose to present the device to the network as
an
iSCSI target. In this case, it would be the gateways job, acting as a proxy
for the parallel SCSI device, to generate some sort of acceptable WWN.
<JIM>
Agreed.
</JIM>

Charles


>
> Charles Monia <cmonia@NishanSystems.com>@ece.cmu.edu on
> 10-12-2000 11:28:51
> AM
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: iSCSI gateways, proxies, etc.
>
>
>
> Hi:
>
> The naming issue is only one aspect of the problem.  Another
> factor is the
> implicit assumption of how all devices see the world.  For
> example, if I
> give device 'A' a third pary command referencing the network
> address of B,
> I
> am providing B's address in my frame of reference, under the
> assumption
> that
> A's view of the network is the same as mine.
>
> Now, if I have followed the naming, addressing and tunneling
> discussions,
> it
> seems to me that this assumption may be troublesome.  So, perhaps an
> alternate approach to the naming issue is to use the WWN of
> the device as
> the common denominator and leave the translation to network
> addresses up to
> some storage naming service.
>
> Charles
>
> > -----Original Message-----
> > From: Jim Hafner/Almaden/IBM [mailto:hafner@almaden.ibm.com]
> > Sent: Thursday, October 12, 2000 8:39 AM
> > To: julian_satran@il.ibm.com
> > Cc: ips@ece.cmu.edu
> > Subject: Re: iSCSI gateways, proxies, etc.
> >
> >
> >
> > Julo,
> >
> > The Map/Unmap commands will not be needed (by the time the
> > iSCSI standard
> > gets approved).  I predict that the function you want will be
> > part of SCSI
> > (i.e., approved by T10) by the Jan. 2001 meeting.   Ed
> > Gardner is proposing
> > something along these lines to solve both the iSCSI and SVP
> > (SCSI over VI
> > Protocol) issues of names larger than 8 bytes.
> >
> > Jim Hafner
> >
> >
> > julian_satran@il.ibm.com@ece.cmu.edu on 10-12-2000 12:26:47 AM
> >
> > Sent by:  owner-ips@ece.cmu.edu
> >
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  Re: iSCSI gateways, proxies, etc.
> >
> >
> >
> >
> >
> > David,
> >
> > That is a fair summary and I agree with it.
> > I think that one point of clarification is needed with regard to 2.
> > To use the T10 addresses for third party we invented the
> > (admittedly ugly)
> > map and unmap
> > messages. It should be clear that as we can't afford to
> > synchronize with
> > T10
> > those will have to stay and get obsoleted in some later
> > version when T10
> > moves
> > to a more flexible scheme.
> >
> > Julo
> >
> > Black_David@emc.com on 11/10/2000 21:17:51
> >
> > Please respond to Black_David@emc.com
> >
> > To:   ips@ece.cmu.edu
> > cc:
> > Subject:  iSCSI gateways, proxies, etc.
> >
> >
> >
> >
> > Folks,
> >
> > We've been going around on the topic of these for
> > a while without much visible progress.  I'd like
> > to suggest a means to extricate ourselves from this
> > situation.
> >
> > Jim Hafner correctly observed that there is a
> > fundamental difference between:
> > - A gateway that always exposes TCP/IP addresses for the
> >      iSCSI targets behind it, and
> > - A gateway that must be dynamically configured to
> >      obtain connectivity to the iSCSI targets behind it.
> > We don't need to do anything to support the first class
> > of gateway.  For the second class, there's another
> > crucial distinction in the second category, namely
> > between in-band and out-of-band configuration mechanisms.
> >
> > From a protocol specification viewpoint, out-of-band
> > configuration mechanisms are both more flexible and
> > easier to deal with.  Flexibility comes from the
> > variety of possible mechanisms, for example:
> >
> > [A] A NAT monitors DNS traffic to/from a DNS server in
> > private address space behind the NAT.  When a DNS reply
> > containing a translation is intercepted, the NAT sets up
> > an external IP address that maps to the internal IP address
> > in the DNS reply, and substitutes that external IP address
> > for the internal IP address before forwarding the reply
> > (in addition to the usual translation operations performed
> > on the header).  Credit/apologies to whomever (Joshua Tseng?)
> > originally described this example.
> >
> > [B] An encrypting firewall does not provide connectivity
> > to hosts behind the firewall for general traffic outside
> > the firewall.  If an encrypted IPsec tunnel is set up in
> > accordance with the firewall's policies, then connectivity
> > to some of the hosts behind the firewall is provided for
> > traffic using the tunnel in accordance with the firewall's
> > policies.
> >
> > Note that both the NAT and the firewall have to be configured
> > by some means, and that both of these mechanisms work without
> > any changes to the iSCSI protocol, as both the DNS lookup and
> > IPsec tunnel setup happen before the first iSCSI packet is sent.
> > The fact that we don't have to specify anything makes these
> > easier to deal with, and gives iSCSI compatibility with all sorts
> > of things we haven't thought of (yet).
> >
> > Both the current URL mechanism and the discussion of the
> > CONNECT message are in-band configuration mechanisms.  In the
> > context of proxy configuration (Julian's concern about views
> > is a different, but related issue), this has been turning
> > into a tarpit on the list.  From what I can see, the issues
> > here are similar to the issues in naming for 3rd party
> > commands, something that is not in particularly good shape,
> > despite T10's best efforts. I find it hard to believe that
> > people want to repeat T10's experience with this from scratch
> > for iSCSI, but ... I see three possible paths forward
> > from which the WG needs to choose:
> >
> > (1) Rely on out-of-band gateway/proxy configuration.
> > (2) Reference T10's 3rd party naming formats for target naming.
> >      This WG would still define an iSCSI 3rd party naming format
> >      and recommend it to T10, and could define ways of using
> >      T10 naming formats with Internet protocols (e.g., LDAP).
> > (3) Invent new ways of naming targets.
> >
> > I'm inclined to dismiss (3) as being out-of-scope, because
> > if this really is analogous to 3rd party naming, then it needs
> > to be left to T10 and iSCSI should follow what T10 adopts, BUT
> > I'm willing to listen to counter-arguments.
> >
> > (1) and (2) are complementary rather than exclusive, but the
> > protocol gets simpler if we don't have to do (2).  The 3rd party
> > naming recommendations to T10 are needed regardless.
> >
> > Ok - comments are solicited, as I do intend to try to call
> > consensus on this set of issues to make progress.
> >
> > Thanks,
> > --David
> >
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > black_david@emc.com       Mobile: +1 (978) 394-7754
> > ---------------------------------------------------
> >
> >
> >
> >
> >
> >
> >
>
>
>