RE: iSCSI gateways, proxies, etc.

[Charles Monia <cmonia@NishanSystems.com>]

Jim:

Thanks for your thoughful response.

My replies are interspersed below.

Charles


> -----Original Message-----
> From: Jim Hafner/Almaden/IBM [mailto:hafner@almaden.ibm.com]
> Sent: Friday, October 13, 2000 9:13 AM
> To: Charles Monia
> Subject: RE: iSCSI gateways, proxies, etc.
> 
> 
> 
> 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>

<CHARLES>
I see the problem a bit differently.  I want to define an iSCSI frame of
reference that's constant accross the network. Then I want to give A
information in this frame of reference and provide standard tools so A can
figure out how to establish the connection with B.
</CHARLES>

> > 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>
<CHARLES>
I have made the tacit assumption that any device presenting itself as an
iSCSI initiator or target would be required by the iSCSI spec to have a WWN
-- in the same sense that FC-compliant devices must have WWNs. The standards
allow inteconnects to define their own requirements in this regard, so I see
no conflict.
</CHARLES>

> 
> ...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>
> 


<CHARLES>

If I had this to do over again, I'd have been less specific about a
solution.  To me, the issue is that, one the device has been located, the
generic scalability, virtualization and access control problems regarding LU
access though that device ought to be decoupled from the protocol per se and
addressed through extensions to the SCSI device semantics.

In that regard, maybe the scope of the LU access proposals now being
considered by T10 could be extended to address the scalability issue. In any
event, I think consideration of this matter can be safely removed from the
iSCSI dialogue.

</CHARLES>



> 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>
> 
<CHARLES>
Now we're getting to the crux of the issue.

I think there are two entities here -- a flat space of iSCSI device
identifiers, which I suggest ought to be IEEE-administered WWNs, and a
corresponding network address.  In my view, <ip address - port number> pair
fills the bill for the latter.

We've tried walking though a number of device discovery scenarios here,
including firewalls, and believe this scheme works in a way that fits in
quite well with the internet tools environment.  What's more, it appears to
work for any internet storage protocol that's SAM-compliant.

</CHARLES>


> 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>

<Remaining material deleted>

Rgds,
Charles

Charles Monia
Senior Technology Consultant
Nishan Systems
email: cmonia@nishansystems.com
voice: (408) 519-3986
fax:   (408) 435-8385