Re: iSCSI: URL scheme

["Prasenjit Sarkar/Almaden/IBM" <psarkar@almaden.ibm.com>]

Hi,

Can you clarify what you meant by "target" out here? I've heard there's a
lot of
work going on in T10 to define what exactly it is, specially in terms of
multiple
ports.

I would also like clarification if SAM allows targets to share ports as
implied
by requirement (2).

Regds,
Prasenjit



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


To:   <ips@ece.cmu.edu>
cc:   csapuntz@cisco.com
Subject:  Re: iSCSI: URL scheme




I would like to propose the following requirement for any naming scheme.

   * Any naming scheme proposed MUST support multiple targets behind a
single
     IP address

   * Any naming scheme proposed SHOULD support multiple targets behind
     a single port. This helps make traffic analysis easier.


Consider the topology pictured below. An initiator is connected
to a private network that has a gateway to the Internet. Similarly,
the target is connected to a private network which is connected
by another gateway to the Internet.



Initiator - Private Network - Gateway 1
                                   \
                                    \
                                  Internet
                                     /
                                    /
Target -   Private Network - Gateway 2
 (bob)           |
               Target (fred)




How does the Initiator get to talk to the Target bob?

-------------
Current model
-------------

SCSI device identifier is a string in two parts: a hostname and a
host-specific
name (HSN). The hostname is either a domain name or an IPv4 or IPv6
address.

Steps:
   0) Configuration mechanism tells initiator to talk to SCSI device
      identifier "bob"

   1) Do a DNS (or other name service) lookup on bob.
      Reply arrives with IP address of Gateway #2

   2) TCP connect to gateway #2 on well known iSCSI port

   3) As part of first login packet, send "Target: bob"

   4) Gateway #2 resolves the name "bob" on the internal
      network and gets the private IP address of the Target Bob

   5) Gateway #2 opens a TCP connection to Target Bob and
      passes all traffic between connections

Third party command from bob to fred
   0) Configuration tells initiator that bob should talk to
      SCSI device identifier "fred"

   1) Initiator sends command to bob which has SCSI device identifier
      "fred"

   2) Bob resolves fred's name and gets Fred's private Ip address

   3) Bob connects to Fred and they do their thing


Refinements
-----------
   Configuration mechanism (e.g. LDAP server) in step 0, along with
   returning the SCSI device identifier "bob", also returns the IP
   address of gateway #2. The DNS lookup in #1 is avoided.

   DNS lookup of bob actually returns gateway #1 (would work for
   iSCSI and HTTP/1.1 but unlikely to work for other protocols).
   Gateway #1 then looks up the name on the Internet and gets
   gateway #2... and so on...


----------------
IP address model
----------------

A target name is made of two parts: an IP address and a target ID.
The target ID can be either a string or a fixed-length binary
quantity. The target ID is not necessarily globally unique; it
can be IP-address specific.


Step 0) Initiator queries the configuration mechanisms and gets
the IP address of gateway #2 and the target ID for bob.

Step 1) Open TCP connection to IP address of gateway #2 on well-known
  iSCSI port

Step 2) As part of first login packet, initiator send the target ID for bob

Step 3) Gateway #2 opens connection to bob based on the target ID

Step 4) Gateway #2 passes all info between connections

Third party commands - passable way
--------------------

Step 0) Configuartion mechanism tells initiator that bob should talk
to fred. The configuration mechanism tells the initiator about the
private IP address/target ID of Fred as seen by Bob (how does it find
this out??)

Step 1) Initiator sends third party command with Fred's IP address
and target ID

Step 2) Bob opens connection to Fred's IP address+port


Third party commands - icky way
--------------------
Step 0) Configuartion mechanism tells initiator that bob should talk
to fred. The configuration mechanism tells the initiator about the
IP address of gateway #2 and target ID of fred

Step 1) Initiator sends third party command with IP address of gateway#2
and target ID of fred

Step 2) Gateway #2 intercepts the third party command and rewrites it
to have Fred's private IP address (based on the target ID)

Step 3) Bob opens connection to Fred's private IP address on well known
iSCSI
port, sends target ID in the first iSCSI PDU, etc.

or

Step 2) Bob opens a connection to gateway #2's IP address and passes target
ID

Step 3) Bob gets redirected to Fred (or... gateway opens connection
to Fred and passes all commands between Fred & Bob)


In this approach, the gateway must be able to map a target ID to an IP
address
and a (possibly new) target ID.


Note on using port numbers instead of target IDs
------------------------------------------------

The only thing that changes in the analysis above is that the target
ID need not be sent on connection open, since the destination port
number on the TCP connection identifies the target.



In this specific scenario, it seems to me that using strings entirely
is cleaner than passing IP addresses which are potentially non-sensical.

-Costa