RE: iSCSI: URL scheme

[Charles Monia <cmonia@NishanSystems.com>]

Hi:

By definition, the iSCSI session endpoints correspond to the service
delivery ports in the target and initiator devices. As I see it, one way of
looking at Costa's' proposal is to consider the endpoints of this session as
extending beyond the endpoints of the TCP/IP connection(s) through which the
iSCSI session traffic flows. From a storage perspective, I believe this has
the desirable properties discussed below.

Using Doug Otis' terminology,  I've chosen to refer to the terminus for all
the TCP/IP connections associated with an iSCSI session as the "scsi
portal". To get beyond the portal, some sort of black box is needed. For the
sake of this discussion, I've made this a component of something called a
Storage Gateway.  One function of the gateway is to provide connectivity to
one or more physical devices (targets or initiators). As Doug states, the
gateway-to-device connection could then be opaque to the initiator.  i.e.,
The actual physical connection could be parallel SCSI, Fibre Channel or an
iSCSI device hidden on some other network. It would then be the gateway's
job to make sure that the device appears as an iSCSI target or initiator. In
the simplest case, of course, the gateway and storage device would be one
and the same.

Charles


> -----Original Message-----
> From:	csapuntz@cisco.com [SMTP:csapuntz@cisco.com]
> Sent:	Wednesday, October 04, 2000 12:05 AM
> 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
> 
> 
> 
> 
>