RE: iSCSI Naming and Discovery

["Douglas Otis" <dotis@sanlight.net>]

Joshua,

The LDAP server responsible for publicly accessible drives, as used in your
example, would also need to be publicly accessible.  The local LDAP server
within an enterprise environment may point to this external LDAP server or
the client may employ a domain name using DNS to find the LDAP server.
Either way, the vital component in allowing a bootstrap operation would be
this LDAP database.  Symbolic conventions would not meet bootstrapping needs
nor would changing DNS servers to include SCSI portal information.

Doug

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Joshua Tseng/Nishan Systems
> Sent: Friday, October 06, 2000 4:16 PM
> To: Jim Hafner/Almaden/IBM
> Cc: ips@ece.cmu.edu
> Subject: RE: iSCSI Naming and Discovery
>
>
> Jim,
>
> >A couple of points:
> >a) by "target" in the above context, I mean the iSCSI version of a "SCSI
> >Target Device" (a box which holds many LUs and which has at least one IP
> >physical node). N.B.  "target" is not a logical unit!
> >b) Both (1) and (2) address the "how to open the TCP pipe" question, not
> >what happens after the TCP pipe is open.  This pipe is initiator TCP to
> >"target" TCP.
> >c) an initiator does not "connect" to a logical unit.  It connects to a
> >SCSI Target Device.
> >
> >The layers (as I see them) are:
> >  - TCP-to-TCP (open the pipe, certainly requires at least
> >datum=ipaddress:port)
> >  - iSCSI-to-iSCSI (login, requires some authentication datum for iSCSI
> >endpoints)
> >  - SCSI-to-SCSI (application client to LU device server and task manager
> >--
> >     addressing datum at this level is LUNs)
>
> Thanks for clarifying this layering model.  I think it makes analysis
> much easier.  This message is in regard to the question:
>
> >> 1) what datum does an initiator need to establish the IP connection to
> the
> >> target?
>
> I would like to point out that we're not necessarily talking about
> one TCP connection.  Use of proxies, may result in a chain of TCP
> connections.  I see the following scenario as very common, as exists
> today with http:
>
>     network domain 1  |   network domain 2   |    network domain 3
>                       |                      |
> iSCSI initiator-----proxy1-----------------proxy2-----------iSCSI target
>       |               |                      |                  |
>       |<---tcp 1----->|<-------tcp 2-------->|<-----tcp 3------>|
>       |                                                         |
>       |<-------------------iSCSI session----------------------->|
>       |                                                         |
>       |<--------------------SCSI session----------------------->|
>
> Note that NAT and the use of RFC1918 private addresses is only one
> of the reasons why there may be multiple network domains.  Security
> is another--many enterprises do not allow their internal IP addresses
> to be advertised to the Public Internet for security reasons, even
> though they may be using registered IP address space.
>
> In the above diagram, the iSCSI transport is carried end-to-end, from
> initiator to target, and it may span multiple network domains. What
> "datum" can it carry which will provide routing information valid in
> all network domains?  Each proxy (proxy1 and proxy2) must interpret this
> "datum", and be able to use it to forward the iSCSI traffic to the next
> IP endpoint.  An individual IP address will not do the trick because
> a routable IP address in one domain may not be routable in another.  An
> LDAP "binary information" is valid only if there is access to an LDAP
> server that can interpret this information in each network domain.  This
> may or may not exist, but if you're talking about the global public
> Internet, I would tend to doubt it.  The only universally acceptable
> "datum" that I can think of is the DNS domain name.
>
> I hope I don't sound like a broken record.
>
> Josh
>
> -----Original Message-----
> From: Jim Hafner/Almaden/IBM [mailto:hafner@almaden.ibm.com]
> Sent: Friday, October 06, 2000 1:55 PM
> To: David Robinson
> Cc: ips@ece.cmu.edu
> Subject: Re: iSCSI Naming and Discovery
>
>
>
> David,
>
> I'm glad we agree on some things.  At the risk of sounding too preachy...
>
> I wrote:
> >> In short, can we split this into two independent questions:
> >>
> >> 1) what datum does an initiator need to establish the IP connection to
> the
> >> target?
> >>
> >> 2) where can an initiator get that datum?
>
> You wrote:
> >I would propose that the information required for #1 is the IP address
> >and port number as well as an inband representation of the LU.
>
> I'm still trying to figure out where inband representation of LU is
> required in this context.
>
> A couple of points:
> a) by "target" in the above context, I mean the iSCSI version of a "SCSI
> Target Device" (a box which holds many LUs and which has at least one IP
> physical node). N.B.  "target" is not a logical unit!
> b) Both (1) and (2) address the "how to open the TCP pipe" question, not
> what happens after the TCP pipe is open.  This pipe is initiator TCP to
> "target" TCP.
> c) an initiator does not "connect" to a logical unit.  It connects to a
> SCSI Target Device.
>
> The layers (as I see them) are:
>   - TCP-to-TCP (open the pipe, certainly requires at least
> datum=ipaddress:port)
>   - iSCSI-to-iSCSI (login, requires some authentication datum for iSCSI
> endpoints)
>   - SCSI-to-SCSI (application client to LU device server and task manager
> --
>      addressing datum at this level is LUNs)
>
> NOTE: Everything in the SCSI-to-SCSI layer is already defined (both
> discovery, naming, addressing, protocol, etc.). Everything at a TCP-to-TCP
> layer is defined (once the datum is acquired).  This WG needs to
> define the
> iSCSI-to-iSCSI stuff and perhaps assist in answering (2) above to
> facilitate the operation of the TCP-to-TCP layer (1).
>
> In SAM terms, the iSCSI-to-iSCSI job is to create the I_T nexus (there is
> no LU or LUN datum involved here).
>
> Where in either the TCP or iSCSI layer is a LU identifier or LUN required,
> desirable, etc?
>
> (Sorry if this comes across too strong! -- maybe it's just a bad day!)
>
> Jim Hafner
>