[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01                                                         
                iSCSI
           Internet Draft
                                                            Mark Bakke
                                                            Cisco
                                                            Joe Czap
                                                            IBM
       
                                                            Jim Hafner
                                                            IBM
                                                            Howard Hall
                                                            Pirus
                                                            Jack Harwood
                                                            EMC
                                                            John Hufferd
                                                            IBM
       
                                                            Yaron Klein
                                                            SANRAD
                                                            Larry Lamers
                                                            SanValley Systems
                                                            Joshua Tseng
                                                            Nishan Systems
                                                           Kaladhar Voruganti
                                                           IBM
       
       
                                       Page 1
       
       
       
       
       
       
       
       
       
       
       draft-ietf-ips-iscsi-disc-reqts-00.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
       (ips@ece.cmu.edu) or to
                kaladhar@us.ibm.com
       
       
                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.
                                       Page 2
       
       
       
       
       
                         draft_ietf_ips_iscsi_disc_reqts_00
                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
                                       Page 3
       
       
       
       
       
                         draft_ietf_ips_iscsi_disc_reqts_00
       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.
                                       Page 4
       
       
       
       
       
                         draft_ietf_ips_iscsi_disc_reqts_00
       
                - 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
                                       Page 5
       
       
       
       
       
                         draft_ietf_ips_iscsi_disc_reqts_00
       
                   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
       
                   +------------------+-----------+------------------
                                       Page 6
       
       
       
       
       
                         draft_ietf_ips_iscsi_disc_reqts_00
                   | 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
       
                                       Page 7
       
       
       
       
       
                         draft_ietf_ips_iscsi_disc_reqts_00
                    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
                                       Page 8
       
       
       
       
       
                         draft_ietf_ips_iscsi_disc_reqts_00
                     .
                  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
                                       Page 9
       
       
       
       
       
                         draft_ietf_ips_iscsi_disc_reqts_00
       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
                                       Page 10
       
       
       
       
       
                         draft_ietf_ips_iscsi_disc_reqts_00
       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
                                       Page 11
       
       
       
       
       
                         draft_ietf_ips_iscsi_disc_reqts_00
       
                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
       
       
                                       Page 12
       
       
       
       
       
                         draft_ietf_ips_iscsi_disc_reqts_00
       +------------+--------------------------------------+-----
                                 |                                      |
                                 |                                      |
                    +-----+------+------+-----+            +-----+------+----
                    |     | 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
       
                                       Page 13
       
       
       
       
       
                         draft_ietf_ips_iscsi_disc_reqts_00
                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,
                                       Page 14
       
       
       
       
       
                         draft_ietf_ips_iscsi_disc_reqts_00
       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: kaladhar@us.ibm.com
       
       
                "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
                                       Page 15
       
       
       
       
       
                         draft_ietf_ips_iscsi_disc_reqts_00
       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"
       
        Voruganti  iSCSI Naming and Discovery Draft Expires July 2001