Subject: iSCSI: Naming and Discovery Document

From: "Kaladhar Voruganti" <[email-masked]>
Date: Fri, 12 Jan 2001 10:52:27 -0800

The following attached document has been submitted to IETF.
This naming and discovery document has been worked on by the
iSCSI naming and discovery team.

(See attached file: draft-ietf-ips-iscsi-disc-reqts-01.txt)

regards,
Kaladhar Voruganti

          
         iSCSI                                                        Mark Bakke  
         Internet Draft                                                    Cisco  
                                                                 
                                                                        Joe Czap  
                                                                             IBM  
                                                                                  
                                                                      Jim Hafner  
                                                                             IBM  
                                                                                  
                                                                     Howard Hall  
                                                                           Pirus  
                                                                                  
                                                                    Jack Harwood  
                                                                             EMC  
                                                                                  
                                                                    John Hufferd  
                                                                             IBM  
                                                                                  
                                                                     Yaron Klein  
                                                                          Sanrad  
                                                                                  
                                                                 Lawrence Lamers  
                                                              San Valley Systems  
                                                                                  
                                                                    Joshua Tseng  
                                                                          Nishan  
                                                                                  
                                                              Kaladhar Voruganti  
                                                                             IBM  

         draft-ietf-ips-iscsi-disc-reqts-01.txt              January, 2001  
         Expires July 2001                                                         
           
                      iSCSI Naming and Discovery Requirements 
           
         Status of this Memo  

            This document is an Internet-Draft and is in full conformance with  
            all provisions of Section 10 of RFC2026 except that the right to  
            produce derivative works is not granted.   
              
            Internet-Drafts are working documents of the Internet Engineering  
            Task Force (IETF), its areas, and its working groups. Note that  
            other groups may also distribute working documents as Internet- 
            Drafts. Internet-Drafts are draft documents valid for a maximum of  
            six months and may be updated, replaced, or obsoleted by other  
            documents at any time. It is inappropriate to use Internet- Drafts  
            as reference material or to cite them other than as "work in  
            progress."   
            The list of current Internet-Drafts can be accessed at  
            http://www.ietf.org/ietf/1id-abstracts.txt   
            
          
         Voruganti          Internet Draft Expires July 2001       1  

                            iSCSI Naming and Discovery        November 2000 

            The list of Internet-Draft Shadow Directories can be accessed at  
            http://www.ietf.org/shadow.html.  

         Comments  
         Comments should be sent to the ips mailing list ([email-masked]) or to   
         [email-masked]  

         1. Abstract 
          
         This document describes the  iSCSI [7] naming and discovery requirements. The  
         requirements presented in this document have been agreed to by the members of  
         the iSCSI naming and discovery team. This document complements the iSCSI IETF  
         draft. Flexibility is the key guiding principle behind this requirements  
         document. That is, an effort has been made to satisfy the needs of both small  
         isolated environments, as well as large environments requiring secure/scalable  
         solutions. 
          
         This document has been organized into the following sections: 
         a) Section 3 presents the naming requirements. 
         b) Section 4 discusses the discovery requirements. 
         c) Section 5 presents Storage Name Server (SNS) requirements. 
         d) Section 6 briefly discusses other existing discovery protocols. 

         2. Conventions used in this document 
          
            The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
            "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
            this document are to be interpreted as described in RFC-2119. 

         3. Naming Requirements  
         In order for an iSCSI initiator to connect to an iSCSI target, the initiator  
         needs to provide information about the Network Entity object, Portal Object and  
         the target Storage Node object. The details of these three iSCSI objects are as  
         follows: 
          
         a) Network Entity Object 
         The Network Entity object represents a device or gateway that is accessible from  
         the IP network. This device or gateway may support one or more initiators or  
         targets that are either internal to the storage device or accessible through a  
         network behind the gateway. Each initiator or target is represented by  
         subordinate Storage Node objects. The Network Entity object is identified by its  
         IP address. 
          
         b) Portal Object 
         The Portal object is a port through which access to any Storage Node 
         object within the Network Entity object can be obtained. A Network Entity object  
         must have one or more Portal objects, each of which is usable by Storage Node  
         objects contained in that Network Entity object to gain access to the IP  
         network. The Portal object is identified by its IP address and Port number. The  
         Portal object's IP address can be different than the Network Entity IP address. 
         There is a canonical iSCSI TCP port present at each Network Entity object. 
         However, Storage Node objects can also be accessed via non-canonical 
         iSCSI TCP ports. 
          
         c) Storage Node Object 
         The Storage Node object defines an individual iSCSI initiator or target. 
         There may be one or more Storage Node objects within the Network Entity 
         object. A Storage Node object is identified by its world wide unique 
         identifier (WWUI). There is a requirement to have the ability to generate  
         world wide unique identifiers (WWUIs) for both iSCSI initiators and targets. 
         However, it is not mandatory for the initiators and targets to use WWUIs 
         because a globally unique identifier might not be required in some simple,  
         isolated iSCSI configurations. WWUIs are useful because in some cases (e.g. when  
         DHCP services [6] are used etc), the combination of IP address and port number  
         [6] cannot uniquely identify an initiator or a target. 

         There is a default Storage Node object present at every target network entity  
         that can be accessed without specifying the WWUI. However, if there are multiple 
         iSCSI target Storage Nodes that are serviced by a single Network Entity and  
         Portal objects, then it is necessary for the initiator to specify the target  
         Storage Node WWUI to uniquely identify the target storage node. An alias string  
         could also be associated with a target storage node. The target alias helps an  
         organization to associate their own semantic meaning with the target alias  
         string. For example, the alias string could represent the organizational  
         hierarchy in which the storage device resides such as: 
         CompanyXXX.com/research/dept1/individual/storage_device1 
         However, the target alias string is not a substitute for the target WWUI. 

          
         3.1 World Wide Unique Identifier 
          
         The WWUI uniquely identifies iSCSI initiators and targets. The initiator WWUI  
         corresponds to the logical operating system on which the initiator is running,  
         and the target WWUI corresponds to the target Storage Node entity.  The WWUI may  
         be displayed by user interfaces, but is generally uninterpreted and used as an  
         opaque binary string for comparison with other WWUI values. 
          
         The use of the naming authority means that WWUIs can be assigned by virtually  
         any uniqueness scheme that can be devised by OS vendors, driver or iSCSI NIC  
         vendors, device vendors, gateway vendors, and even the customer. 

         The format of the iSCSI WWUI is as follows: 
          
         WWUI = Length + Type + Type-dependent format 
          
         Length is 1 byte and includes Type and the rest of the WWUI, but not itself.   
         The maximum length field value is 255, making a maximum total WWUI of 256 bytes  
         (including Length), and a maximum type-dependent format of 254 bytes. 
          
         The minimum length of a WWUI is 2; the WWUI would consist of just 
         the Length field (== 1), and a Type field. 
          
         Type is 1 byte and is as follows (similar, but not identical to SPC-2 VPD) 
          
               00 - No_Authority (not guaranteed to be unique) 
               01 - ASCII (using reversed DNS name as Naming Authority) 
               02 - IEEE EUI-64 
               03 - Unicode (DNS naming authority) 
               04 - Generic Binary WWUI (to be considered) 
          
           Addition of new types requires approval to become an iSCSI standard. 

         Open Question:  Should all occurences of "ASCII" in this 
                         document be replaced with "UTF-8"?  So far, we 
                         have had no votes for UTF-8. 
          
         Open Question:  Should the WWUI be padded to a 4-byte boundary? 
                         Please see discussion on transporting a WWUI. 

         Use of the ASCII format is recommended when possible for the following 
         reasons: 
          
         - an ASCII WWUI is easier to type and differentiate in a user 
           interface. 
          
         - An ASCII WWUI can use a DNS name as a naming authority.  It can 
           be assumed that anyone who wants to name targets or initiators 
           owns a DNS name.  The same is not true for either OUI or SCSI 
           Vendor ID.  This also means that end users can name their own 
           targets and initiators, for whatever their purposes may be. 
          
         - WWUIs are only used during login and discovery phases, so the 
           overhead does not get in the way of the data path. 

         The IEEE format is recommended when: 
          
         - There is an existing IEEE unique name that must be communicated 
           to iSCSI. 

         The Unicode format is recommended in place of ASCII when: 
          
         - Human-readable format is desired, and a character set other 
           than ASCII is needed. 

         We may also consider adding a generic binary string format using a 
         manufacturer's OUI as a naming authority. 

         Type determines the remainder of the WWUI format and it can be in the 
         following formats: 

         No_WWUI Format 
          
            +------------+-----------+ 
            | Length = 1 | Type = 00 | 
            +------------+-----------+ 
          
            This format is used to indicate a NULL WWUI. 

         ASCII_WWUI Format 
          
            +------------------+-----------+------------------ 
            | Length =         | Type = 01 | string 
            | 1+strlen(string) |           | 
            +------------------+-----------+------------------ 
          
            The ASCII WWUI string is defined as follows: 
          
            String starts with a backwards domain name specifying the Naming 
            Authority, using dots as separators, just as in a regular domain 
            name.  It's backwards, since it is not really used as a fully 
            qualified host name; only the necessary top levels need by used. 
          
            Basically, everything after the backwards domain name, followed 
            by another dot ".", can be assigned as needed by the owner of 
            the domain name. 
          
            Here is an example ASCII WWUI string: 
          
              3201com.acme.diskarrays.sn.a8675309 
          
            Where: 
              32  is the length of the string + length of Type 
              01  refers to ASCII WWUI type string 
          
              In the rest of this document even though the length field and the type 
              field values are in front of the WWUI string, they are not being  
         shown for 
              readability sake. 
          
              "com.acme" defines the Naming Authority.  The owner of the DNS 
              name "acme.com" has the sole right of use of this name within 
              a WWUI.  In this case, acme.com happens to manufacture disk 
              arrays. 
          
              "diskarrays" was picked arbitrarily by acme.com to use to 
              identify the disk arrays they manufacture.  Another product 
              that ACME makes would use a different name, and have their 
              own namespace independent of the disk array group. 
          
              "sn" was picked by the disk array group of Acme to show that 
              what follows is a serial number.  They could have just assumed 
              that all WWUIs are based on serial numbers, but they thought 
              that perhaps later products might be better identified by 
              something else.  Adding "sn" was a future-proof measure. 
          
              "a8675309" is the serial number of the disk array, uniquely 
              identifying it from all other arrays. 
          
            Please note that WWUI is NOT an address - even though it uses a DNS 
            name, this is for the naming authority only; it is not an address 
            used to discover anything. 
          
            Note that we could have used the ASCII Vendor ID as a naming 
            authority.  However, some large customers and service providers 
            may wish to use their own identification scheme, rather than 
            that provided by the manufacturer.  These customers would not 
            likely have a registered Vendor ID, but the domain name we 
            used is ubiquitous, and seemed more appropriate. 
          
            Further examples of ASCII WWUIs are given at the end of this 
            document. 

         IEEE_WWUI 
          
            +------------+-----------+---------------------+ 
            | Length = 9 | Type = 02 | IEEE EUI-64 Address | 
            +------------+-----------+---------------------+ 
          
            The IEEE WWUI might be used when a manufacturer is already 
            basing unique identifiers on World-Wide Names as defined in 
            the SCSI SPC-2 specification. 
          
            It may also be used by a gateway representing a Fibre Channel 
            or SCSI device that is already adequately identified using a 
            world-wide name. 
          
         Unicode_WWUI 
          
            +------------------+-----------+------------------ 
            | Length =         | Type = 03 | Unicode string 
            | 1+strlen(string) |           | 
            +------------------+-----------+------------------ 
          
           This format is identical to the ASCII format, including the 
           use of the reversed domain name as the naming authority, except 
           that Unicode is used instead of ASCII. 

         Binary_WWUI Format (to be considered) 
          
            +------------------+-----------+------------------ 
            | Length =         | Type = 04 | OUI     | binary UI 
            | 1+len(binary UI) |           | 3 bytes | 
            +------------------+-----------+------------------ 

         Initiator and Target Requirements for WWUI support: 
          
           Both shall support WWUIs of up to the maximum length. 
          
           Initiators and targets shall present their own WWUI as part of 
           the protocols defined elsewhere. 
          
           User interfaces should display any ASCII type WWUI as an 
           ASCII string, any binary format WWUI as a string of hex digits, 
           and all types unknown to the implementation as if the format 
           were binary. 

         Some WWUI Examples for Targets 
          
         - Assign to a target based on controller serial number 
          
              com.acme.diskarray.sn.8675309 
          
                  See the ASCII WWUI example above for discussion. 
          
         - Assign to a target based on serial number and logical target alias 
          
              com.acme.diskarray.sn.8675309.oracle_database_1 
          
                  Where oracle_database_1 might be a target alias assigned by 
                  a user. 
          
              This would be useful for a controller that can present 
                  different logical targets to different hosts. 
          
           Obviously, any naming authority may come up with its own scheme 
           and hierarchy for these names, and be just as valid. 
          
           A target WWUI should NEVER be assigned based on interface hardware, 
           or other hardware that can be swapped and moved to other devices. 

         Some WWUI Examples for Initiators 
          
         - Assign to the OS image by fully qualified host name 
          
             com.osvendor.dns.com.customer1.host_four 
          
             Note the use of two FQDNs - that of the naming 
             authority and also that of the host that is being 
             named.  This can cause problems, due to limitations 
             imposed on the size of the WWUI. 
          
             ( write in what to do about this ) 
          
         - Assign to the OS image by OS install serial number 
          
             com.osvendor.newos5.12345-OEM-0067890-23456 
          
             Note that this breaks if an install CD is used more 
             than once. 
          
         - Assign to the OS image by a service provider 
          
             com.mydisk.users.mbakke05657 
          
             Note that this could also be assigned to a particular 
             iSCSI address if more than one SP is used. 
          
         Some WWUI Examples for Gateways 
          
            ( needs work, but gateway vendors are a creative lot ) 

         Adding the WWUI to SCSI Third Party Commands 
          
           Work done on adding the WWUI address type to SCSI third 
           party commands, such as extended copy, is being done in 
           T10. 

         Using Initiator and Target WWUI During Login 
          
           The Initiator WWUI should always be sent during login.  As a target 
           may use the Initiator WWUI as part of its access control mechanism, an 
           initiator that does not send its WWUI stands the risk that it will be 
           excluded from accessing some or all of its targets. 
          
         1. Both target WWUI and the target alias are specified  I->Login Request 
              InitiatorWWUI: com.os.hostid.34567890 
              TargetWWUI: com.acme.diskarray.sn.8675309 
              TargetAlias: foo 
              . 
              .  text commands flow here during authentication phase 
              . 
           T->Login Response 
              TargetWWUI: com.acme.diskarray.sn.8675309 
              TargetAlias: foo 
          
         2. Only Target WWUI is specified and no alias is specified. 
          
           I->Login Request 
              InitiatorWWUI: com.os.hostid.34567890 
              TargetWWUI: com.acme.diskarray.sn.8675309 
              . 
              .  text commands flow here during authentication phase 
              . 
           T->Login Response 
              TargetWWUI: com.acme.diskarray.sn.8675309 
              TargetAlias: foo 
          
         3. Neither target alias nor WWUI is specified.  If there is just 
            one target, or a default target, at the IP Address and port, 
            this will work.  The target returns its WWUI so the initiator 
            can keep it for future use. 
          
           I->Login Request 
              InitiatorWWUI: com.os.hostid.34567890 
              . 
              .  text commands flow here during authentication phase 
              . 
           T->Login Response 
              TargetWWUI: com.acme.diskarray.sn.8675309 
              TargetAlias: foo 

         Answers to Potentially Frequently Asked Questions 
          
          What happens if an Initiator WWUI is not unique? 
          
           - Targets will authenticate both as same entity 
           - Targets will believe that one initiator is using 
             them via different network interfaces. 
           - Initiators may end up sharing a device by 
             accident. 

         3.2 Alias String 
         The alias string is an ASCII string that is used to identify a Storage Node  
         object that can be accessed via a particular Network Entity object and a Portal  
         object. The alias string is a variable length, between 0 to 255 bytes, 
         user-readable ASCII text string. The alias string is terminated with at least  
         one NULL character. The alias string format is similar to that of the UNIX file  
         address format. 

         4. iSCSI Discovery 
         An iSCSI initiator Storage Node can discover an iSCSI target Storage Node 
         in the following different ways: 
         a) Target information is hard-coded at the initiator. 
         b) Initiator queries storage name servers. 
         c) Initiator issues a multicast discovery message to the targets and the 
         SNS. 
         d) Initiator queries a canonical iSCSI target Storage Node object at a Network 
         Entity object for a list of targets. 
          
         4.1 Target Information is hard-coded 
         The exact manner in which the target information is hard-coded at the initiator  
         is an implementation detail. The information could be present in some persistent  
         location (such as a file) that can be accessed by the initiator. 
          
         4.2 Initiator queries a Storage Name Server (SNS) 
         The initiator can query a SNS for a list of the targets that it can access. 
         The type of information that is stored at the SNS, and the list of query and 
         registration APIs that should be supported by the SNS server are described in 
         Section 5 below. The implementation details of the SNS are beyond the scope of 
         this document. 
          
         4.3 Initiator Issues a Multicast Message 
         An initiator can send a multicast message to both storage name servers and iSCSI 
         targets. An initiator MAY send a multicast "SNS discovery" message to the (TBD) 
         iSCSI discovery multicast address on a (TBD) well-known iSCSI UDP port. An iSCSI 
         SNS MUST register as part of the iSCSI discovery multicast group and SHALL 
         respond to this message indicating that it functions as an SNS.  Targets MAY 
         register as part of this multicast group but SHALL NOT respond to this message. 
         Alternatively, an initiator MAY send a multicast "all storage discovery" message 
         to the same multicast address.  A storage name server MUST respond to this 
         message as if the message were the "SNS discovery message".   A registered 
         target MAY respond to this message indicating that it is an iSCSI target. 
         A device that provides both iSCSI target and storage name server functions SHALL 
         respond with a message indicating that it provides both services. Finally, 
         the initiator MAY send a multicast "iSCSI targets only" message to the same 
         multicast address, and only the iSCSI targets and the iSCSI devices that provide 
         both iSCSI target and storage name server functions MAY respond to this message. 
         The choice of static configuration, SNS discovery or all storage discovery 
         protocols is a configuration choice of the initiator.  There is no 
         authentication process associated with the iSCSI discovery multicast 
         messages. 
          
         If the initiator receives one or more responses to the "SNS discovery" message, 
         it may interact with those device for its target discovery services.  If an 
         initiator receives responses to the "all storage discovery" message from only 
         targets, it may attempt Login with each of those devices. If an initiator 
         receives responses to an "all storage discovery" message from both targets and 
         storage name servers, it may choose to interact with the storage name servers 
         for target discovery services and/or attempt Login directly with responding 
         registered targets. 
          
         In summary, this discovery approach is flexible in that the initiators have the 
         freedom to select static configuration, a multicast based discovery mechanism 
         for small, isolated iSCSI environments, or they can choose a scalable storage 
         name server based discovery mechanism for large iSCSI environments.  
         Additionally, targets may be configured to participate or not 
         participate in the multicast group (e.g., if there is an SNS available, then 
         they may chose either dynamically or by configuration not to register in the 
         group). 

         4.4 SendTargets Command 
          
         An initiator may, after the Login process, connect to an iSCSI 
         canonical target and request for a list of target WWUIs, via a separate 
         SendTargets command, at the particular Network Entity object and the Portal 
         object. The returned data for this request shall contain a list 
         of tuples, where each tuple consists of a target WWUI and an IP 
         address:Port and an optional alias string.  The canonical target MUST support 
         this request and the returned list MUST contain at least one entry for the 
         canonical target itself.  The initiator can then attempt iSCSI Login to each of 
         the targets specified in the returned list. 
          
         During the login command, the initiator sets the target alias to "iSCSI" 
         with a WWUI of "*".  If the login succeeds, the initiator may send a 
         sendTargets text command. 
          
         The response to this command is a text response containing a list of 
         tuples. 
          
         The format of this text string is as follows: 
          
         <TargetWWUI,IP Address:Port Number, Alias String> 
         The exact format of the text string is as follows: 
         TargetWWUI:com.acme.diskarray.sn.8675309 
         TargetAddress:10.1.0.45:3000 
         TargetAlias:foo/diskController1 
         TargetWWUI:com.acme.diskarray.sn.8888888 
         TargetAddress:10.1.0.46:3000 
         TargetAlias:foo/diskController2 
          
         A line containing the term TargetWWUI: is the start of a target; followed by its 
         address and alias, until the next targetWWUI: line. If no target addresses are 
         given, the initiator can log in to the same address as that used for in the 
         SendTargets command, and login to the default target.  If multiple paths to the 
         WWUI are known, multiple address lines may be given. 

          
         4.4.1 Port Redirect Command 
         During the Login process, a target may redirect the initiator to connect to 
         another IP address:Port and then terminate the Login command (and its 
         connection).  A target might do this for load balancing or it might do this to 
         provide multiple virtual targets through a simple initiator discovery protocol. 
         The target's response is a text string that is in the following format: 
         "REDIRECT: TargetWWUI:com.acme.diskarray.sn.999999 
         TargetAddress:10.1.0.49:3000 
         TargetAlias:foo/diskController3" 

         5.  Storage Name Server (SNS) 
          
         The following section describes requirements for any Storage Name Server 
         used to support iSCSI.  An example of a Storage Name Server is the iSNS 
         described in the draft document draft-ietf-ips-iSNS-00.txt [8]. 
          
         5.1  Overview 
          
         The SNS shall be architected using a client-server paradigm, with the SNS server 
         predominantly serving a passive role. SNS clients actively register and 
         manipulate entity objects and their attributes in the SNS server.  The SNS 
         server MAY send asynchronous state change notifications to registered SNS 
         clients in response to an action by a SNS client.  Examples of SNS clients 
         include initiators, targets, management stations, and switches.  The SNS server 
         can be hosted on a target, switch, or stand-alone server. 
          
         5.2  Login Control and Zoning 
          
         The SNS MUST support Zoning and Login control.  The SNS must provide SNS clients 
         with the ability to enforce zoning configurations which may exist on the SNS 
         server.  Targets and management stations shall be able to register (i.e., 
         upload) Login Control and Zoning configurations to the iSNS if authorized by the 
         end user. 
          
         Zoning and Login control supports two separate purposes: 
          
         5.2.1  Discovery Domain Partitions 
          
         The SNS SHALL support the ability to partition the storage network into separate 
         "Discovery Domains".  The SNS shall not provide information if the SNS client 
         performing the query is not in a common zone (i.e., "Discovery Domain") as the 
         SNS client that is the subject of the request.  This capability prevents an 
         initiator from attempting an iSCSI login to every single target in a large 
         enterprise network, and is the iSCSI equivalent of "Soft" zoning. 
          
         5.2.2  Login Control 
          
         To support login access security which is specified in the current iSCSI draft 
         (Appendix A) [7] and MAY be implemented by the iSCSI target.  The SNS shall 
         support login control by storing a mapping of initiators that are permitted to 
         access each target.  Targets shall be able to query the SNS for 
         a list of initiators that are allowed login access.  This list shall include 
         the key attribute (e.g., WWUI) used to identify the initiator.  This capability 
         is the iSCSI equivalent of "Hard" zoning. 
          
         5.3    Object Model 
          
         The SNS MUST store the following objects and attributes: 
          
             Network Entity: 
               -  Entity Identifier 
               -  Management IP Address 
               -  Entity Type (iSCSI) 
          
             Portal: 
               -  Portal Index 
               -  IP Address 
               -  TCP Port Number 
          
             Storage Node: 
               -  WWUI 
               -  Alias 
               -  Node Type (target or initiator or both) 
          
             Zone: 
               -  Zone symbolic name 
               -  Zone ID 
               -  Zone Member:  WWUI 
               -  Zone Member:  IP Address 
          
         A diagram of how the above objects are related is shown below. 
          
             +----------------------------------------------------------------+ 
             |                         IP Network                             | 
             +------------+--------------------------------------+------------+ 
                          |                                      | 
                          |                                      | 
             +-----+------+------+-----+            +-----+------+------+-----+ 
             |     | PORTAL      |     |            |     | PORTAL      |     | 
             |     | -IP Addr 1  |     |            |     | -IP Addr 2  |     | 
             |     | -TCP Port 1 |     |            |     | -TCP Port 2 |     | 
             |     +-----+ +-----+     |            |     +-----+ +-----+     | 
             |           | |           |            |           | |           | 
             |           | |           |            |           | |           | 
             |  +--------+ +--------+  |            |   +-------+ +--------+  | 
             |  |                   |  |            |   |                  |  | 
             |  |  STORAGE NODE     |  |            |   |  STORAGE NODE    |  | 
             |  |  -WWUI            |  |            |   |   -WWUI          |  | 
             |  |  -Alias: "server1"|  |            |   |  Alias: "disk1"  |  | 
             |  |  -Type: initiator |  |            |   |   -Type: target  |  | 
             |  |                   |  |            |   |                  |  | 
             |  +-------------------+  |            |   +------------------+  | 
             |                         |            |                         | 
             |    NETWORK ENTITY       |            |    NETWORK ENTITY       | 
             |   -Entity ID (DNS):     |            |   -Entity ID (DNS):     | 
             |    "strg1.foo.com"      |            |    "strg2.bar.com"      | 
             |   -Type: iSCSI          |            |   -Type: iSCSI          | 
             |                         |            |                         | 
             +-------------------------+            +-------------------------+ 
          
         A ZONE contains one or more NETWORK ENTITY objects.  Each NETWORK ENTITY 
         object contains one or more PORTAL objects, and one or more STORAGE NODE 
         objects. 
          
         5.4  SNS Message Format Requirements 
          
         The SNS protocol SHALL use a flexible and extensible message format such as 
         TLV (TLV is already used in many networking protocols such as DHCP).  The SNS 
         protocol shall allow manipulation of multiple objects and attributes in the SNS 
         server through a single message and response. 
          
         5.5  SNS Authentication Requirements 
          
         The SNS protocol SHALL include optional authentication of SNS protocol 
         messages from SNS clients. The authentication mechanism will allow for 
         authentication of both client and server. 
          
         5.6 SNS Query and Registration Services Requirements 
         The SNS protocol allows initiators and targets to register themselves at  
         the SNS server. Initiators and targets can also query the SNS server for 
         information. For example, targets can register themselves at the SNS server, and 
         the initiators can query the SNS server about which targets they can access. 
          
         During registration, the initiators and the targets must provide the  
         following information: 
         a) Storage Entity ID 
         b) Portal object address (IP address and Port Number) 
         c) WWUI information 
         d) Storage node type 
          
         They could optionally also provide other information such as: 
         a) Zone related information 
         b) Alias string information 
          
         When querying address information in order to establish an iSCSI  
         connection, the query, 
         as a minimum, should return the following information: 
         a) Storage Entity IP address 
          
         The Portal Object IP address can be the same as the Storage Entity IP  
         address, and the Portal Object port number can be the (TBD) default iSCSI port  
         number. Furthermore, the WWUI of the target device can be queried by issuing the  
         SendTarget command to the default canonical iSCSI target present at the IP 
         address and port number. 

         5.7  State Change Notification Requirements 
          
         Asynchronous notification (State Change Notifications):  The SNS must be 
         able to inform SNS clients of changes to its database, including changes or 
         modifications to zoning or login control policies and the 
         presence or absence of initiators and targets.  These changes may occur as a 
         result of various events, including an SNS client actively manipulating changing 
         the SNS database, response or non-response to an 
         SNS heartbeat message, or a hardware interrupt delivered by the SNS host 
         platform (such as a switch). Asynchronous notification shall be delivered only 
         to SNS clients that register for the notification, and only for SNS clients that 
         are in the same Zone as the event. 
          
         5.8  The SNS protocol SHALL be a lightweight protocol that can be scaled down 
         for implementation on switches and targets, or scaled up for implementation on 
         servers. 
          
         5.9  The SNS SHALL meet the iSCSI boot requirements (see 
         draft-ietf-ips-iscsi-boot-00.txt). 
          
         6) Related Work 
         Jini [1], PnP [2] and Internet Server Location Protocol (SLP)[3] are some of the 
         other discovery protocols that are present in the industry. It is important to 
         note that there is no consensus in the industry as to which discovery protocol 
         should be used. Therefore, instead of adopting a specific existing protocol, 
         the NDT team has ensured that the iSCSI discovery mechanism contains the key 
         essential features of the above mentioned discovery protocols. The multicast 
         discovery mechanism, described above, provides iSCSI with the same discovery 
         capabilities as these other discovery protocols. 

         7. Outstanding Work Items 
         The following work items are still outstanding: 
         a) Impact of naming and discovery on iSCSI Login command. 
         b) Secure interaction between the storage director and the initiators 
         and the targets. 

         8. References 
         [1] Edwards, K., "Core Jini: In Depth: Discovery", Prentice Hall, 1999. 
          
         [2] John, R., "UPnP, Jini and Salutation- A look at some popular coordination 
         frameworks for future networked devices", 
         http://www.cswl.com/whiteppr/tech/upnp.html", June 17, 1999. 
          
         [3] http://www.srvloc.org 
          
         [4] Freed, N., "Behavior of and Requirements for Internet Firewalls", 
         RFC 2979, October 2000. 
          
         [5] ANSI/IEEE Std 802-1990, Name: IEEE Standards for Local and 
         Metropolitan Area Networks: Overview and Architecture 
          
         [6] Kessler, G. and Shepard, S., "A Primer On Internet and TCP/IP Tools 
         and Utilities", RFC 2151, June 1997. 
          
         [7] Satran, J., Sapuntzakis, C., Wakeley, M., Von Stamwitz, P., Haagens, 
         R., Zeidner, E., Dalle Ore, L., Klein, Y., "iSCSI", 
         draft-ietf-ips-iscsi-00.txt, November, 2000. 
          
         [8] Gibbons, K., Tseng, J. and Monia, C., "iSNS Internet Storage Name 
         Service", draft-tseng-ips-isns-00.txt, October 2000. 

              
          
         6. Contact Author  
         Kaladhar Voruganti  
         650 Harry Road  
         IBM Almaden Research  
         San Jose, CA  
         USA  
         Email: [email-masked]  
            
         Voruganti            Internet Draft Expires July 2001       

                               iSCSI Naming and Discovery        January 2001 

           
         "Copyright (C) The Internet Society (date). All Rights Reserved. This   
         document and translations of it may be copied and furnished to others,  
         and derivative works that comment on or otherwise explain it or assist  
         in its implementation may be prepared, copied, published and distributed,  
         in whole or in part, without restriction of any kind, provided that the  
         above copyright notice and this paragraph are included on all such  
         copies and derivative works. However, this document itself may not be  
         modified in any way, Full Copyright Statement  
         such as by removing the copyright notice or references to the   
         Internet Society or other Internet organizations, except as needed for  
         the purpose of developing Internet standards in which case the  
         procedures for copyrights defined in the Internet Standards process must  
         be followed, or as required to translate it into languages other than  
         English.  
           
         The limited permissions granted above are perpetual and will not be   
         revoked by the Internet Society or its successors or assigns.  
           
         This document and the information contained herein is provided on an  
         "As IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING  
         TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED , INCLUDING  
         BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN  
         WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
         MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE"  
           
         Expires July 2001  
           
         Voruganti  iSCSI Naming and Discovery Draft Expires July 2001