RE: iSCSI: URL scheme

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

Costa,

We should make an attempt to keep the addressing schemes within the SCSI
transport SCSI.  That means we do not re-invent routers, tunnels, DNS, and
everything that goes with it.

> 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

I have no problem with that except to add that this IP is routable from the
client.  I call this address the SCSI portal.

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

Again, a good statement with the following provision, the address space
behind the SCSI portal is SCSI and not IP.  If you wish to bridge between
two portals, then you should setup a connection transparent to the SCSI
address space.  In otherwords, you would not indicate within the SCSI
address space any IPs.  This would be done as part of the SCSI address
configuration using LDAP.  This keeps each address space separate and clean
and yet you get the job done.

> 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.
>
		Server (Drive D)
                      \
(always Private)  SCSI Space ---- SCSI Space
                        \               \
                         \               \
             Routable SCSI Portal 1  Transparent Bridge Connection
                          \               \
                           \               \
                        IP Space        IP Space
                           /              /
                          /              /
                        NAT      Routable SCSI Portal 2
                        /              /
Non-Routable      Client (Bob)     Server (Drive C)

How does Bob get to talk to the Drive C?

Bob's system only knows about the Portal 1 however his drive is actually on
Portal 2.  Bob's system knows about this through a sequence of boot up
steps.  DHCP informs his system of an LDAP server.  Bob's system then
queries this server for SCSI services via SCSI class objects.  Bob's system
leans how to authenticate with Portal 1 and what target/lun/wwn his system
will find his Drive C at within the realm of Portal 1.  Portal 1 knows that
this target/lun/wwn is actually within the realm of Portal 2.  At Portal 2,
his drive is at yet another target/lun/wwn.  Portal 1 will make the
translation for Bob without Bob's knowledge into Portal 2.  Bob does not
know how to Authenticate with Portal 2 nor where Portal 2 keeps his drive.
That would be handled transparently for Bob.  As Portal 1 always responds
back to the client Bob at the IP and port that he came in at, the NAT is not
a problem.  As far as Portals are concerned, they must be exposed as
Routable.

I have changed the name Bob into Drive C and used Bob as the Client.
Otherwise, I get confused.  I have changed Fred into Drive D.  I know this
is very MSDOS and I could have chosen SCSI directory names such as /home,
/bin, <swap> or /temp

Doug



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