SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI: URL scheme



    Costa,
    
    Thanks for your example as it makes analysis a bit easier.
    I have copied your diagram below, but I have labeled each
    Private Network.
    
    Initiator - Private Network 1 - Gateway 1
                   (aka PN1.com)        \
                                         \
                                       Internet 
                                          /
                                         /
    Target -   Private Network 2 - Gateway 2
     (bob)           |
                   Target (fred)
    
    DNS has a worldwide scope in assigning names to hosts and
    domains, and it has BEEN DEPLOYED.  To my knowledge no
    such naming infrastructure of the same worldwide scope
    exists for LDAP.  I do not understand how iSCSI can avoid
    use of DNS if it is to achieve the worldwide scope that DNS
    has.  Anyways, this message is partially in response to John
    Hufferd's request.
    
    DNS servers in each network (PN1, PN2, & Internet) are
    administered independently, with the Internet of course 
    administered by ICANN.  Assume the domain name for PN1
    is PN1.com and PN2 is PN2.com.  PN1.com may not even
    know about PN2.com.  Also note that there may be several
    layers of private networks, and hence nested adminstrations
    of DNS servers (network1.PN2.com, etc...).  This process
    is scalable to many layers of nested domain administrations.
    
    In some cases, Initiator must proxy through Gateway 1 first
    before they can get out to the Internet, especially if
    PN1 is doing "twice NAT" (changing both source & destination
    IP addresses).  Lets just assume this to show how multi-
    layered proxying would work.
    
    ****the following is tedious & detailed description******
    Initiator talks to Gateway 1, asks for connection to
    "bob.PN2.com".  Gateway 1 does a DNS resolve to the authoritative
    DNS server for "PN1.com", who has no idea where "bob.PN2.com" is.
    So this server asks the ".com" DNS server for the entire Public
    Internet.  The ".com" server says to ask the authoritative DNS
    server for "PN2.com" at address ww.xx.yy.zz.  So the "PN1.com"
    DNS server asks the DNS server at ww.xx.yy.zz, which resolves
    "bob.PN2.com" to the IP address for Gateway 2. The "PN1.com"
    DNS server then returns the original query to Gateway 1, giving
    him the IP address of Gateway 2.
    
    Gateway 1 then proxies the connection to Gateway 2.  Gateway 1
    asks Gateway 2 for a connection to "bob.PN2.com".  Gateway 2 does
    a DNS resolve query to the authoritative DNS server for PN2.com,
    who returns bob.PN2.com's IP address.  Gateway 2 then proxy's
    the connection to "bob", asking for a connection to
    "bob.PN2.com/modifer".  "bob" recognizes himself as the
    destination of the iSCSI connection, and they're in business.
    ***************************************************
    
    Okay, now try to do that with LDAP.  Yes, of course it's 
    theoretically possible, but there is no LDAP-based infrastructure
    has been set up with the worldwide scope of DNS.
    
    Josh
    
    -----Original Message-----
    From: csapuntz@cisco.com [mailto: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
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:06:50 2001
6315 messages in chronological order