RE: iSCSI Naming and Discovery

["John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>]

Julian,

That is the point, he needs the Session level WWN. Not a Lun WWN.  You are
on 3rd party copy, I did not think he said anything about 3rd party copy.

.
.
.
John L. Hufferd


julian_satran@il.ibm.com@ece.cmu.edu on 10/06/2000 09:20:22 AM

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


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI Naming and Discovery





John,

I have some trouble following you.

Regular commands that address a device within a session and use
a binary 8 byte LUN to address a device.

This is (for a while) true also for third party commands.

The login used to build a session has a text portion but it is addressing a
target not
a device.

Are you suggesting that we use a "text appendix" to every command?

That would be rather expensive.

Julo

"John Hufferd/San Jose/IBM" <hufferd@us.ibm.com> on 06/10/2000 12:59:00

Please respond to "John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>

To:   ips@ece.cmu.edu
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  RE: iSCSI Naming and Discovery




Julian,
I do not think Joshua's problem is getting a LUN number, it is getting
through a IP to FC gateway (which might include a switch type function) to
the approprate Storage Controller with an approprate WWN.   I think the
proposal that Costa had which is just the inclusion in the Text of the
Login command (in the field called "Target:") should be most of what is
needed.  The name gets resolved at each step along the IP path (which is
normal DNS resolution), and then when the IP to FC gateway is reached, it
can use the end of the "Target:" Text Sting (following the last "/") to get
to the approprate qualifier which will identify the target Storage
Controller.   This will work the best, if the Text field also has a field
called "WWN:".  The text that followed that "WWN:" field would be the WWN
that the IP to FC gateway wishes to proxy as the original Host initiator
WWN. Every thing else like Report LUNs, etc.  should still work as today,
after the proxy connection is established.

.
.
.
John L. Hufferd


julian_satran@il.ibm.com@ece.cmu.edu on 10/06/2000 01:46:32 AM

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


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI Naming and Discovery





Joshua & John,

If the troublesome item is for a "knowledgeable" gateway to to FC to get a
hold on LUNs
then this can be done within the current draft.
The LUN in the PDUs is an 8byte "object" opaque to iSCSI.
An initiator can choose to put there a WWN to be replaced (rewritten) by
the gateway with
a LUN or nay such commbination.  This operation is stateless.

Julo

"Joshua Tseng/Nishan Systems" <joshua.tseng@NishanSystems.com> on
05/10/2000 22:26:01

Please respond to "Joshua Tseng/Nishan Systems"
      <joshua.tseng@NishanSystems.com>

To:   ips@ece.cmu.edu
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  RE: iSCSI Naming and Discovery




John,

>Joshua,
>I think the LU being part of the "/Modifier" is a bit problematical.  You
>should focus on the connections each end, and let the LU stuff be
>transparent to your Gateway.  They will of course use Report LUNs and
>Inquiry and use their approprate LU number, I am having problems
>understanding why a gateway would need to know the LU number.
>
>Could you resend your note without the LUN stuff so that we can see, a
>little easier, what you think is really needed.

You are right...my bad.  The LUN is carried in the iSCSI PDU.
What is needed in the Fibre Channel World Wide Port Name (WWPN),
which the gateway will need in order to address the Fibre Channel
device.  The gateway/proxy should register this attribute key in
the name server (yes Doug--an LDAP-based server) for retrieval by
the iSCSI initiator, who can use it in the /modifier when addressing
the Fibre Channel target.

Josh