RE: iSCSI Naming and Discovery

[Joshua Tseng/Nishan Systems <joshua.tseng@NishanSystems.com>]

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