[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 3721

          Internet Draft
          Draft Title: iSCSI Naming and Discovery

                                                    Mark Bakke

                                                    Joe Czap

                                                    Jim Hafner

                                                    Howard Hall

                                                    Jack Harwood

                                                    John Hufferd

                                                    Yaron Klein

                                                    Marjorie Krueger

                                                    Lawrence Lamers
                                                    San Valley Systems

                                                    Todd Sperry

                                                    Joshua Tseng

                                                    Kaladhar Voruganti

                       iSCSI Naming and Discovery

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

Voruganti          Internet Draft  Expires Dec 2001                1

                     iSCSI Naming and Discovery             Aug. 2001

   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-

   The list of Internet-Draft Shadow Directories can be accessed at

   Comments should be sent to the ips mailing list (ips@ece.cmu.edu) or
   to kaladhar@us.ibm.com


   This document describes iSCSI [7] naming and discovery details. This
   document complements the iSCSI Protocol draft. Flexibility is the key
   guiding principle behind this 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

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   this document are to be interpreted as described in RFC-2119.

Table of Contents

1.  Naming Requirements..............................................2
 1.1. iSCSI Model....................................................2
 1.2. SCSI Architecture Model........................................4
 1.3. Consequences of the model......................................5
2.  Naming Requirements..............................................6
 2.1. iSCSI Names....................................................7
 2.2. Initiator and Target Requirements for iSCSI Name support:.....14
3.  iSCSI Discovery.................................................14
4.  References......................................................20
5.  Author's Addresses..............................................21

Voruganti           Internet Draft  Exp. Dec. 2001                  2

                     iSCSI Naming and Discovery             Aug. 2001

1. Naming Requirements
  1.1. iSCSI Model

   This section describes that part of the iSCSI architectural model
   that has the most bearing on the relationship between iSCSI and the
   SCSI Architectural Model.

   a) Network Entity
   The Network Entity represents a device or gateway that is accessible
   from the IP network. This device or gateway may support one or more
   iSCSI Node. The iSCSI Node is accessed via a network portal (see

   b) iSCSI Node
   There may be one or more iSCSI Storage Nodes within the Network
   Entity. An iSCSI Node is identified by its iSCSI name. There is a
   requirement for iSCSI names to be unique.  iSCSI names 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 iSCSI Node object present at every target network
   entity that may be accessed without specifying the iSCSI name for
   the purpose of discovering a target nodes name(s).  However, it is
   necessary for the initiator to specify the full target iSCSI name to
   instantiate a fully functional iSCSI session.

   c) Network Portal
   The Network Portal is a port through which access to any iSCSI Node
   within the Network Entity can be obtained. A Network Entity must
   have one or more Network Portals, each of which is usable by some
   iSCSI Nodes contained in that Network Entity to gain access to the
   IP network.  A Network Portal in an initiator is identified by it IP
   name or address.  A Network Portal in a target is identified by its
   IP name or address and its listening TCP port.

   d) Portal Groups
   iSCSI supports multiple connections within the same session; some
   implementations will have the ability to do this across multiple
   Network Portals.  A Portal Group is a group of Network Portals which
   collectively can support a multiple-connection session.  A device
   may contain one or more Portal Groups.  Each Network Portal belongs
   to exactly one portal group on each iSCSI node.  Portal Groups are
   identified within an iSCSI Node by a portal group tag, a simple
   integer value.  All Network Portals with the same portal group tag
   are in the same Portal Group.

   The following diagram shows an example of one such configuration on
   a target and how a session may be established that shares Network
   Portals within a Portal Group.

Voruganti           Internet Draft  Exp. Dec. 2001                  3

                     iSCSI Naming and Discovery             Aug. 2001

      ----------------------------IP Network---------------------

            |               |                    |
   |   +----|---------------|-----+         +----|---------+           |
   |   | +---------+  +---------+ |         | +---------+  |           |
   |   | | Network |  | Network | |         | | Network |  |           |
   |   | | Portal  |  | Portal  | |         | | Portal  |  |           |
   |   | +--|------+  +---------+ |         | +---------+  |           |
   |   |    |               |     |         |    |         |           |
   |   |    |    Portal     |     |         |    | Portal  |           |
   |   |    |    Group 1    |     |         |    | Group 2 |           |
   |   +--------------------------+         +--------------+           |
   |        |               |                    |                     |
   |   +----------------------------+  +-----------------------------+ |
   |   | iSCSI Session (Target side)|  | iSCSI Session (Target side) | |
   |   |                            |  |                             | |
   |   |  (iSCSI Name + TSID=0)     |  | (iSCSI Name + TSID=1)       | |
   |   +----------------------------+  +-----------------------------+ |
   |                                                                   |
   |                      iSCSI Target Node                            |
   |              (within Network Entity, not shown)                   |

  1.2. SCSI Architecture Model

   This section describes the relationship between the SCSI
   Architecture Model (SAM-2, see [cite?]) constructs of SCSI device,
   SCSI port and I_T nexus and the iSCSI constructs described above.
   This relationship implies implementation requirements in order to
   conform to the SAM-2 model and other SCSI operational functions.
   These implementation requirements are detailed in Section 3.3.

   a) SCSI Device
   This is the SAM-2 term for an entity that contains other SCSI
   entities.  For example, a SCSI Initiator Device contains one or more
   SCSI Initiator Ports and zero or more application clients; a SCSI
   Target Device contains one or more SCSI Target Ports and one or more
   logical units.  For iSCSI, the SCSI Device is the component within
   an iSCSI Node that provides the SCSI functionality.  As such there
   can be at most one SCSI Device within a given iSCSI Node.   The SCSI
   Device Name is the same as the iSCSI Node name.

   b) SCSI Port
   This is the SAM-2 term for an entity in a SCSI device that provides
   the SCSI functionality to interface with a service delivery
   subsystem or transport.  For iSCSI, the definition of SCSI Initiator
   Port and SCSI Target Port are different.

   SCSI Initiator Port: this maps to the endpoint of a session.  An
   iSCSI session is negotiated through the login process between an
   iSCSI Intiator Node and an iSCSI Target Node.  At successful
   completion of this process, a SCSI Initiator Port is created within

Voruganti           Internet Draft  Exp. Dec. 2001                  4

                     iSCSI Naming and Discovery             Aug. 2001

   the iSCSI Initiator Node.  The SCSI Initiator Port Name and SCSI
   Initiator Port Identifier are both defined as the iSCSI Initiator
   Name together with the ISID portion of the session identifier.

   SCSI Target Port: this maps to a target Portal Group.  The SCSI
   Target Port Name and SCSI Target Port Identifier are both defined as
   the iSCSI Target Name together with the portal group tag.

   c) I_T Nexus
   The I_T Nexus is a relationship between a SCSI Initiator Port and a
   SCSI Target Port.  For iSCSI, this relationship is a session.  This
   then is a relationship between the initiator end of a session (SCSI
   Initiator Port) and the target portal group (SCSI Target Port)
   through which the session is established.

  1.3. Consequences of the model

   This section describes the implementation and behavioral
   requirements that result from the mapping of SCSI constructs to
   iSCSI constructs defined above.

   ISID RULE: Between a given iSCSI Initiator and iSCSI Target Portal
   Group, there can be only one session with a given ISID.  This does
   not preclude use of the same ISID with a different Target Portal
   Group on the same iSCSI Target Node (or on other iSCSI Target
   Nodes), nor does it preclude other sessions with different ISIDs to
   the same Target Portal Group.

   The reason for this rule is to avoid instantiation of "parallel"
   nexi between the same two SCSI initiator and SCSI target ports.

   Certain nexus relationships contain explicit state (e.g., initiator-
   specific mode pages or reservation state) that may need to be
   preserved through changes or failures in the iSCSI layer (e.g.,
   session collapses).  In order for that state to be restored, the
   initiator should reestablish its session (relogin) to the same
   Target Portal Group using the previous ISID.  This is because the
   SCSI Initiator Port Identifier and the SCSI Target Port Identifier
   (or relative target port) that the SCSI logical unit device server
   uses to identify the nexus.

   To facilitate compliance with the ISID RULE, the following should

   iSCSI Initiator Requirements:

    a) The iSCSI Name should be configurable parameter of each
       initiator portal group.

    b) The ISID name space of the iSCSI Initiator should be partitioned
       among the intiator portal groups.

Voruganti           Internet Draft  Exp. Dec. 2001                  5

                     iSCSI Naming and Discovery             Aug. 2001

   iSCSI Target Requirements:

    a) The iSCSI Name should be configurable parameter of each target
       portal group.

    b) The TSID name space of the iSCSI Initiator should be partitioned
       among the target portal groups.

   SCSI Mode Pages:

   If the SCSI target does not maintain initiator-specific mode pages,
   and an initiator makes changes to port-specific mode pages, the
   changes may affect all other initiators logged in to that iSCSI
   Target through the same Target Portal Group.

2. Naming Requirements

   The concepts of names and addresses have been carefully separated in
   iSCSI.  A name is an identifier that specifies an end-point, such as
   an initiator or target.  The name must be location-independent; the
   target can be moved to another address, or have multiple addresses,
   but it is still the same target.  An address is an identifier that
   specifies a path to an end-point at which the target may currently
   be found.  Names are forever; addresses may change at any time.

   This means that two types of identifiers are needed for iSCSI
   initiators and targets:

    -  An iSCSI Node Name, or iSCSI Name, is a location-independent,
       permanent identifier for an iSCSI initiator or target.  It stays
       constant for the life of the target.  An iSCSI Name specifies an
       iSCSI Node.

    -  An iSCSI Address specifies the location of an iSCSI initiator or
       target.  An iSCSI address consists of a host name or IP address,
       a TCP port number (for the target), and the iSCSI Name of the
       host or target.  An iSCSI Address specifies an iSCSI Portal plus
       an iSCSI Node.

    -  An iSCSI Identifier is either an iSCSI Name or an iSCSI Address.
       Some specifications of iSCSI targets, such as a configuration
       file or the iSCSI Boot mechanism [BOOT], require either a name
       or an address to be stored in the same field.  In this case, the
       term "iSCSI Identifier" is specified to indicate that either the
       name or the address can be used.

   This set of structures has already been defined by the WWW and
   internet folks.  An iSCSI Identifier is functionally equivalent to a
   Uniform Resource Identifier (URI), an iSCSI Name is functionally

Voruganti           Internet Draft  Exp. Dec. 2001                  6

                     iSCSI Naming and Discovery             Aug. 2001

   equivalent to a Uniform Resource Name (URN), and an iSCSI Address
   fulfils the same function as a Uniform Resource Locator (URL).

   A similar analogy exists for people.  A person might be:

       Robert Smith
       SSN: 333-44-5555
       Phone: +1 (763) 555.1212
       Home Address: 555 Big Road, Minneapolis, MN 55444

       Work Address: 222 Freeway Blvd, St. Paul, MN 55333

   In this case, Robert's globally unique name is really his Social
   Security Number (perhaps it should have a "us." in front of it); his
   common name, "Robert Smith", is not guaranteed to be unique. Robert
   has three locations at which he may be reached; two Physical
   addresses, and a phone number.  In this example, Robert's SSN is
   like the iSCSI Name, his phone number and addresses are analogous to
   the iSCSI Address, and "Robert Smith" would be a human-friendly
   label for this person.

  2.1. iSCSI Names

   An iSCSI Node Name, or iSCSI name, is used to identify each iSCSI
   initiator and target.  The terms "initiator name" and "target name",
   when used in this document, refer to iSCSI Node Names.  This name is
   designed to be globally unique, and is independent of the location
   of the initiator or target.  iSCSI names are formatted as UTF-8 text

   iSCSI names may be assigned by a hardware manufacturer, software
   manufacturer, or the end user.  A naming authority scheme is
   provided to ensure that each of these can confidently generate
   unique names.

   The iSCSI Name uniquely identifies iSCSI initiators and targets. The
   Initiator Name corresponds to the logical operating system on which
   the initiator is running, and the Target Name corresponds to the
   target Storage Node entity.

   iSCSI names are designed to fulfill the following requirements:

    1. iSCSI names are globally unique.  No two initiators or targets
       should have the same name.

    2. iSCSI names are permanent.  An iSCSI initiator or target has the
       same name for its lifetime.

    3. iSCSI names do not imply a location or address.  An iSCSI
       initiator or target can move, or have multiple addresses.  A
       change of address does not cause a change of name.

Voruganti           Internet Draft  Exp. Dec. 2001                  7

                     iSCSI Naming and Discovery             Aug. 2001

    4. iSCSI names must not rely on a central name broker; the naming
       authority must be distributed.

    5. iSCSI names must support integration with existing unique naming

    6. iSCSI names must rely on existing naming authorities.  iSCSI
       must not create its own naming authority.

   The encoding of an iSCSI name also has some requirements:

    1. iSCSI names have one single encoding method when transmitted

       over various protocols.

    2. iSCSI names must be relatively simple to compare.  The algorithm
       for comparing two iSCSI names for equivalence must not rely on
       any external server.

    3. iSCSI names must be transcribable by humans.  iSCSI names should
       be kept as simple as possible, and should not use more than a
       few special characters.  They must also be case-insensitive, and
       cannot include white space.

    4. iSCSI names must be transport-friendly.  They must be
       transported using both binary and ASCII-based protocols, as well
       as on paper.

   An iSCSI Name really names a logical software entity, and is not
   tied to a port or other hardware that can be changed.  For instance,
   an Initiator Name should name the iSCSI initiator driver, and not a
   particular NIC or HBA card.  When multiple NICs are used, they
   should generally all present the same iSCSI Initiator Name to the
   targets, since they are really to the same entity.  In most
   operating systems, the named entity is the operating system image.
   Most hosts will have a single OS running; some of the really big
   ones could have multiples.

   A Target Name should similarly not be tied to hardware interfaces
   which can be changed.  A Target Name should identify the logical
   target, and must be the same for the target regardless of the
   physical portion being addressed.  This gives iSCSI initiators an
   easy way to determine that two targets it has discovered are really
   two paths to the same target.

   The iSCSI Name is designed to fulfill the functional requirements
   for Uniform Resource Names (URN) [RFC1737].  Among these
   requirements are that the name must have a global scope, independent
   of address or location, and that it be persistent and globally
   unique.  It must be extensible, and scale with the use of naming
   authorities.  The encoding of the name should be transcribable by a
   human, as well as be machine-readable.  There are other requirements
   as well; please read RFC1737 (only 5 pages) for definitions of these

Voruganti           Internet Draft  Exp. Dec. 2001                  8

                     iSCSI Naming and Discovery             Aug. 2001

   The iSCSI Name may be displayed by user interfaces, but is generally
   uninterpreted and used as an opaque, case-sensitive string for
   comparison with other iSCSI Name values.

   An iSCSI name is text-based.  This was done for the following

    - A text-based identifier is transcribable, and is easier to
    differentiate when looking at a user interface, or while
    debugging problems with iSCSI login and discovery.

    - iSCSI names are only used during login and discovery phases, so

    the overhead does not get in the way of the data path.

    - The iSCSI protocol communicates these via text strings, so it
       "fits in" easily.

   An iSCSI name consists of three parts: a type designator, followed
   by a naming authority, with the remaining format designated by the
   naming authority itself, subject to the following requirements.

   An iSCSI name can be any Unicode character string with the following

    - it is in Normalization Form C (see Unicode Standard Annex #15,
       "Unicode Normalization Forms" at

    - it contains only the ASCII dash character ('-'=U+002d) or the
    ASCII dot character ('.'=U+002e) or is in one of the following
    Unicode General Categories:

             a) Lu (Letter, Uppercase)
             b) Ll (Letter, Lowercase)
             c) Lt (Letter, Titlecase)
             d) Lm (Letter, Modifier)
             e) Lo (Letter, Other)
             f) Nd (Number, Decimal Digit)
             g) Nl (Number, Letter)

             h) No (Number, Other)

    - when encoded in UTF-8, it is no more than 255 bytes

   In particular, white space, punctuation (except as noted), marks and
   symbols are not allowed.

   When included in Text or Login messages, an iSCSI Name MUST be
   formatted in UTF-8 form.

Voruganti           Internet Draft  Exp. Dec. 2001                  9

                     iSCSI Naming and Discovery             Aug. 2001

   For the purposes of comparison, computing hash values, or anything
   else that operates on an iSCSI Name, iSCSI names (in their UTF-8
   form) must be simply compared byte-for-byte.

   The iSCSI Name does not define any new naming authorities.  Instead,
   it supports two existing authorities: an iSCSI-Qualified Name, using
   domain names as an authority, similar to the Java class naming
   heirarchy, and the EUI format used in Fibre Channel world- wide

   Since there are different types of naming authorities, there are
   different types of iSCSI Names to make use of them.  Each name is
   prefixed with a short type designator string that indicates the type
   of naming authority being used.

   Here are the type designator strings that may currently be used:

            iqn.       - iSCSI Qualified Name
            eui.       - Remainder of the string is an EUI-64 address,
                         in ASCII hexadecimal.

   As these two naming authorities will suffice in nearly every case
   for both software and hardware-based entities, the creation of
   additional type designators is discouraged.  One of these two type
   strings MUST be used when constructing an iSCSI name; any type
   string not listed here is not allowed, as they cannot be guaranteed
   to be unique.

   The use of the naming authority means that iSCSI names 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.

      Type "iqn." (iSCSI Qualified Name)

   This iSCSI name type can be used by any organization which owns a
   Domain Name.  This naming format is handy when an end user or
   service provider wishes to assign the iSCSI Name for a target or
   initiator.  Customers which own domain names may not own an EUI,
   OUI, SCSI Vendor ID, or any of the other assigned identifiers that
   could be used as a naming authority.

   To generate names of this type, the person or organization
   generating the name must own a DNS domain name.  This name does not
   have to be active, and does not have to resolve to an address; it
   just needs to be reserved to prevent others from generating iSCSI
   names using the same domain name.  For example, "ACME Storage
   Arrays, Inc.", might own the domain "acme.com".

   The organization generating names must also own an enterprise
   number, obtained from IANA.  Since a domain name can expire, be
   aquired by another entity that wishes to generate iSCSI names, there
   is a small possibility that the use of reversed domain names to

Voruganti           Internet Draft  Exp. Dec. 2001                 10

                     iSCSI Naming and Discovery             Aug. 2001

   indicate the naming authority could produce a name collision.  The
   enterprise number is used as a qualifier to the reversed domain
   name.  Enterprise numbers cannot be re-assigned.

   The iSCSI qualified name string consists of:

    -  The string "iqn.", used to distinguish these names from other
       types, such as "eui".

    -  A decimal enterprise number, assigned by IANA and owned by the
       person or organization creating the iSCSI name.

    -  Another ".".

    -  A reversed domain name, owned by the person or organization
       creating the iSCSI name.  For example, our storage vendor
       example would reverse its name to "com.acme".  This is similar

       to the process used to generate unique Java class names [22],
       but without the restrictions on the domain name, since iSCSI
       names allow hyphens, and does not have any reserved words.

    -  Another ".".

    -  Any string, within the character set and length boundaries, that
       the owner of "acme.com" deems appropriate.  This may contain
       product types, serial numbers, host identifiers, software keys,
       or anything else that makes sense to uniquely identify the
       initiator or target.

   Everything after the backwards domain name, followed by another dot
   ".", can be assigned as needed by the owner of the domain name.  It
   is the responsbility of the naming authority to ensure that the
   iSCSI names it assigns are world wide unique.

   The following is an example of a iSCSI qualified name from an
   equipment vendor:

               Ent   Naming      Defined by
          Type  #     Auth       Naming Authority
           +-+ +--+ +------+ +--------------------+
           | | |  | |      | |                    |



         "iqn" specifies the use of the iSCSI qualified name as the

         "5886" is the enterprise number owned by the naming authority.

         "com.acme" defines the naming authority.  The owner of the DNS

Voruganti           Internet Draft  Exp. Dec. 2001                 11

                     iSCSI Naming and Discovery             Aug. 2001

         name "acme.com" has the sole right of use of this name within
         an iSCSI name, as well as the responsibility to keep the
         remainder of the iSCSI name unique.  In this case, acme.com
         happens to manufacture disk arrays.

         "diskarrays" was picked arbitrarily by acme.com to identify
         the disk arrays they manufacture.  Another product
         that ACME makes might use a different name, and have it's
         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 iSCSI Names 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.

   The following is an example of a name that might be constructed by
   an research organization:

                 Naming                     Defined by
          Type    Auth                      Naming Authority
           +-+ +-------------------------+ +-----------+
           | | |                         | |           |

   In the above example, Professor Oaks of Pika University is building
   research prototypes of iSCSI targets.  Pika-U's computer science
   department allows each user to use his or her user name as a naming
   authority for this type of work.  Professor Oaks chose to use
   "proto.target4" for a particular target.  Note that since this is a
   research project, the Professor did not obtain an enterprise number,
   and just used "0".  This will ensure that his iSCSI names will not
   conflict with commercially-assigned names, but accepts the risk that
   it could conflict with another research organization if his domain
   name is ever re-acquired.

   The following is an example of an iSCSI name string from a storage
   service provider:

                Naming          Defined by
          Type   Auth           Naming Authority
           +-+ +-------------+ +----------------------+
           | | |             | |                      |


   In this case, a storage service provider (my-ssp.com) has decided to
   re-name the targets from the manufacturer, to provide the

Voruganti           Internet Draft  Exp. Dec. 2001                 12

                     iSCSI Naming and Discovery             Aug. 2001

   flexibility to move the customer's data to a different storage
   subsystem should the need arise.

   My-ssp has configured the iSCSI Name on this particular target for
   one of its customers, and has determined that it made the most sense
   to track these targets by their Customer ID number and a disk
   number.  This target was created for use by customer #4567, and is
   the 107th target configured for this customer.

   Note that when reversing these domain names, the first
   component(after the "iqn.") will always be a top-level domain name,
   which includes "com", "edu", "gov", "org", "net", "mil", or one of
   the two-letter country codes.  The use of anything else as the first
   component of these names is not allowed.  In particular, companies
   generating these names must not eliminate their "com." from the

   Again, these iSCSI names are NOT addresses.  Even though they make
   use of DNS domain names, they are used only to specify the naming
   authority.  An iSCSI name contains no implications of the iSCSI

   target or initiator's location.  The use of the domain name is only
   a method of re-using an already ubiquitous name space.

   Note that the SCSI Vendor ID or IEEE OUI could have been specified
   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 was deemed more appropriate.

   Type "eui." (IEEE EUI format)

   The IEEE iSCSI name 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

   The format is "eui." followed by 16 hex digits.

   Example iSCSI name :

         Type    EUI-64 WWN
          +-+ +--------------+
          | | |              |


Voruganti           Internet Draft  Exp. Dec. 2001                 13

                     iSCSI Naming and Discovery             Aug. 2001

  2.2. Initiator and Target Requirements for iSCSI Name support:

   Each initiator and target implementation must support the use of
   iSCSI names.

   The initiator MUST send an InitiatorName and a TargetName as text
   fields within the login request.

   Initiators and targets shall support the receipt of iSCSI names of
   up to the maximum length.  If configuration of the initiator or
   target name is allowed, the implementation shall support the maximum

   In their user interfaces, both shall support, at a minimum, the
   display of the ASCII characters within the iSCSI Name's UTF-8

   If the other characters are unsupported, they may be displayed with
   escape codes as specified in [RFC 2396].

Voruganti           Internet Draft  Exp. Dec. 2001                 14

                     iSCSI Naming and Discovery             Aug. 2001

    3. iSCSI Discovery

   The goal of iSCSI discovery is to allow an initiator to find the
   targets to which it has access, and at least one address at which
   each target may be accessed. This should generally be done using as
   little configuration as possible.  This section defines the
   discovery mechanism only; no attempt is made to specify central
   management of iSCSI devices within this document.  Moreover, iSCSI
   discovery mechanism only deals with target discovery and one still
   needs to use the SCSI protocol for LUN discovery.

   In order for an iSCSI initiator to establish an iSCSI session with
   an iSCSI  target, the initiator needs the IP address, TCP port
   number and iSCSI  target name information. The goal of iSCSI
   discovery mechanism is to provide low overhead support for small
   iSCSI setups, and scalable discovery solutions for large enterprise
   setups. Thus, there are several methods that may be used to find
   targets ranging from configuring a list of targets and addresses  on
   each initiator and doing no discovery at all, to configuring nothing
   on each initiator, and allowing the initiator to discover  targets
   dynamically. The various discovery mechanisms differ in their
   assumptions about what information is already available to the
   initiators and what information needs to be still discovered.

   iSCSI supports the following discovery mechanisms:

 a. Static Configuration: This mechanism assumes that the IP address,
 TCP port and the iSCSI target name information are already available
 to the initiator.The initiators need to perform no discovery
 in this approach. The initiator uses the IP address and the TCP port
 information to establish a TCP connection, and it uses the
 iSCSI target name information to establish an iSCSI session. This
 discovery option is convenient for small iSCSI setups.

 b. SendTargets: This mechanism assumes that the IP address and TCP
 port information are already available to the initiator. The
 initiator then uses this information to log into the canonical iSCSI
 target present at the Network Entity. "iscsi" is the name of the
 canonical target. The initiator then subsequently issues the
 SendTargets text command to query information about the iSCSI
 Targets available at the particular Network Entity (IP address).
 SendTargets command details can be found in the iSCSI draft [7].
 This discovery option is convenient for iSCSI gateways and routers.

c. Zero-Configuration: This mechanism assumes that the initiator
does not have any information about the target. In this option, the
initiator can either multicast discovery messages directly to the
targets or it can send discovery messages to storage name servers.
Currently, there are many general purpose discovery frameworks
available such as Salutation[2], Jini[2],UnPnP[2], SLP[17] and iSNS[8].
However, with respect to iSCSI, SLP can clearly perform the needed
discovery functions [21], while iSNS [8] can be used to provide related
management functions including notification, access management,
configuration, and discovery management.  iSCSI equipment that

Voruganti           Internet Draft  Exp. Dec. 2001                 15

                     iSCSI Naming and Discovery             Aug. 2001

need discovery functions beyond SendTargets should at least implement
SLP, and then consider iSNS when extended discovery management
capabilities are required such as in larger storage networks.
It should be noted that since iSNS will support SLP, iSNS can
be used to help manage the discovery information returned by SLP.

Appendix A: iSCSI Name Notes

   Some iSCSI Name Examples for Targets

   - Assign to a target based on controller serial number


   - Assign to a target based on serial number


   Where oracle_database_1 might be a target label 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 iSCSI Name should NEVER be assigned based on interface
   hardware, or other hardware that can be swapped and moved to other

   Some iSCSI Name Examples for Initiators

   - Assign to the OS image by fully qualified host name


   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 iSCSI Name.

   - Assign to the OS image by OS install serial number


   Note that this breaks if an install CD is used more than once.
   Depending on the O/S vendor's philosophy, this might be a feature.

   - Assign to the OS image by a service provider

Voruganti           Internet Draft  Exp. Dec. 2001                 16

                     iSCSI Naming and Discovery             Aug. 2001

 Note that this could also be assigned to a particular iSCSI address
   if more than one service provider is used.

Appendix B: iSCSI Proxies and Firewalls Taxonomy

   iSCSI has been designed to allow SCSI initiators and targets to
   communicate over an arbitrary network.  This, making some assumptions
   about authentication and security, means that in theory, the whole
   internet could be used as one giant storage network.

   However, there are many access and scaling problems that would come
   up when this is attempted.

   1. Most iSCSI targets may only meant to be accessed by one or a few
   initiators.  Discovering everything would be unnecessary.

   2. The initiator and target may be owned by separate entities, each
   with their own directory services, authentication, and other schemes.
   An iSCSI-aware proxy may be required to map between these things.

   3. Many environments use non-routable IP addresses, such as the 10.

   For these and other reasons, various types of firewalls and proxies
   will be deployed for iSCSI, similar in nature to those already
   handling protocols such as HTTP and FTP.

   B.1. Port Redirector

   A port redirector is a stateless device that is not aware of iSCSI.
   It is used to do Network Address Translation (NAT), which can map IP
   addresses between routable and non-routable domains, as well as map
   TCP ports.  While devices providing these capabilities can often
   filter based on IP addresses and TCP ports, they generally do not
   provide meaningful security, and are used instead to resolve internal
   network routing issues.

   Since it is entirely possible that these devices are used as routers
   and/or aggregators between a firewall and an iSCSI initiator or
   target, iSCSI connections must be operable through them.

   Effects on iSCSI:

    -  iSCSI-level data integrity checks must not include information
       from the TCP or IP headers, as these may be changed in between
       the initiator and target.

Voruganti           Internet Draft  Exp. Dec. 2001                 17

                     iSCSI Naming and Discovery             Aug. 2001

 -  iSCSI messages that specify a particular initiator or target,
       such as login requests and third party requests, should specify
       the initiator or target in a location-independent manner.  This
       is accomplished using the iSCSI Name.

   B.2. SOCKS server

   A SOCKS server can be used to map TCP connections from one network
   domain to another.  It is aware of the state of each TCP connection.

   The SOCKS server provides authenticated firewall traversal for
   applications that are not firewall-aware.  Conceptually, SOCKS is a
   "shim-layer" that exists between the application (i.e., iSCSI) and

   To use SOCKS, the iSCSI initiator must be modified to use the
   encapsulation routines in the SOCKS library.  The initiator the opens
   up a TCP connection to the SOCKS server, typically on the canonical
   SOCKS port 1080.  A subnegotiation then occurs, during which the
   initiator is either authenticated or denied the connection request.
   If authenticated, the SOCKS server then opens a TCP connection to the
   iSCSI target using addressing information sent to it by the initiator
   in the SOCKS shim.  The SOCKS server then forwards iSCSI commands,
   data, and responses between the iSCSI initiator and target.

   Use of the SOCKS server requires special modifications to the iSCSI
   initiator.  No modifications are required to the iSCSI target.

   As a SOCKS server can map most of the addresses and information
   contained within the IP and TCP headers, including sequence numbers,
   its effects on iSCSI are identical to those in the port redirector.

   B.3. iSCSI Proxy

   An iSCSI proxy is similar to proxies available in HTTP. The initiator
   is aware of the actual addresses of the targets, but instead of
   connecting to the addresses, connects instead to a proxy's address.
   The proxy, in turn, connects to the actual targets.  This is similar
   to the HTTP/1.1 proxy, where the client passes the entire URL
   (including IP and TCP address) to the proxy, rather than just the
   path name.

   An iSCSI proxy can provide some good iSCSI-level access
   control and other functionality, while adding fairly light
   configuration responsibilities.

   Effects on iSCSI:

   - When logging in to a target at a proxy address instead of the
   actual address, the target should include the TargetAddress (IP
   address and TCP port) of the target, in addition to its iSCSI Name.
   Note, however, that this directly conflicts with the statement made

   regarding NAT firewalls.  Since the iSCSI Name can uniquely identify

Voruganti           Internet Draft  Exp. Dec. 2001                 18

                     iSCSI Naming and Discovery             Aug. 2001

   an iSCSI device, the TargetAddress must then be used by the proxy as
   a hint on where to find the iSCSI Name, and not as the final

       - This is beginning to be covered in the iSCSI specification.

   Having the address passed with the iSCSI Name would allow an iSCSI
   proxy to exist without extra configuration or name services.  Using
   this type of proxy can eliminate the need to implement SOCKS.

   B.4. SCSI gateway

   This gateway presents logical targets (iSCSI Names) to the
   initiators, and maps them to real iSCSI targets as it chooses.  The
   initiator sees this gateway as a real iSCSI target, and is unaware of
   any proxy or gateway behavior.  The gateway may manufacture its own
   iSCSI Names,or use those provided by the real devices.  This type of
   gateway is used to represent parallel SCSI, Fibre Channel, SSA, or
   other devices as iSCSI devices.

   Nearly any capability that could be imagined is possible with this
   type of gateway, but it may require more configuration than an iSCSI

   Effects on iSCSI:

   - Since the initiator is unaware of any addresses beyond the gateway,
   the gateway's own address is for all practial purposes the real
   address of a target.  Only the iSCSI Name needs to be passed.  This
   is already done in iSCSI, so there are no further requirements to
   support SCSI gateways.

   B.5. Stateful Inspection Firewall (stealth iSCSI firewall)

   The Stealth model would exist as an iSCSI-aware firewall, that is
   invisible to the initiator, but provides capabilities found in the
   iSCSI proxy.

   Effects on iSCSI:

   - Since this is invisible, I don't think there are any additional
   requirements on the iSCSI protocol for this one.

   This one is more difficult in some ways to implement, simply because
   it has to be part of a standard firewall product, rather than part of
   an iSCSI-type product.  For this reason, I would not expect to see
   these implemented for a while.

   Also note that this type of firewall is only effective in the
   outbound direction (allowing an initiator behind the
   firewall to connect to an outside target), unless the iSCSI target
   is located in a DMZ.  It does not provide adequate security

Voruganti           Internet Draft  Exp. Dec. 2001                 19

                     iSCSI Naming and Discovery             Aug. 2001


5. References
    [1] Pascoe, R., "Building Networks on the Fly", in IEEE
       Spectrum,March, 2001.

    [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., Chadalapaka, M., Zeidner, E., Dalle Ore, L., Klein,
       Y., "iSCSI", draft-ietf-ips-iscsi-07.txt, July, 2001.

    [8] Gibbons, K., Tseng, J. and Monia, C., "iSNS Internet Storage
       Name Service", draft-tseng-ips-isns-01.txt, July 2001.

    [9] RFC 1737, "Functional Requirements for Uniform Resource Names".

    [10] RFC 1035, "Domain Names - Implementation and Specification".
       OUI - "IEEE OUI and Company_Id Assignments",

     [11]EUI - "Guidelines for 64-bit Global Identifier (EUI-64)
       Registration Authority

    [12] RFC 2396, "Uniform Resource Identifiers".

    [13] RFC 2276, "Architectural Principles of URN Resolution".

    [14] RFC 2483, "URI Resolution Services".

    [15] RFC 2141, "URN Syntax".

    [16] RFC 2611, "URN Namespace Definition Mechanisms".

    [17] RFC 2608, SLP Version 2.

Voruganti           Internet Draft  Exp. Dec. 2001                 20

                     iSCSI Naming and Discovery             Aug. 2001

    [18] RFC 2610, DHCP Options for the Service Location Protocol.

    [19] P. Sarkar et al, "A Standard for Bootstrapping Clients using
       the iSCSI Protocol", draft-ietf-ips-iscsi-boot-02.

    [21] M. Bakke et al,"Finding iSCSI Targets and Name Servers using
       SLP", draft-ietf-ips-iscsi-slp-01.txt, July, 2001.

    [22] Sun Microsystems, "Java Language Specification", section 7.7
       "Unique Package Names", 2000,

    [23] Flanagan, et. al, "Java in a Nutshell", O'Reilly, 1997.

6. Author's Addresses

   Address comments to:

   Kaladhar Voruganti
   650 Harry Road
   IBM Almaden Research
   San Jose, CA
   Email: kaladhar@us.ibm.com

   Mark Bakke
   Cisco Systems, Inc.
   6450 Wedgwood Road
   Maple Grove, MN 55311
   Phone: +1 763 398-1054
   Email: mbakke@cisco.com

   Jim Hafner
   IBM Research
   Almaden Research Center
   650 Harry Road
   San Jose, CA 95120
   Phone: +1 408-927-1892
   Email: hafner@almaden.ibm.com

   Joe Czap
   IBM Corp.
   600 Park Office Drive
   RTP, NC  27709
   Phone: +1 919 254-0828
   Email: zapper@us.ibm.com

   Josh Tseng
   Nishan Systems
   3850 North First Street

Voruganti           Internet Draft  Exp. Dec. 2001                 21

                     iSCSI Naming and Discovery             Aug. 2001

   San Jose, CA 95134
   Phone: 408 519-3749
   Email: jtseng@nishansystems.com

   Lawrence J. Lamers
   SAN Valley Systems, Inc.
   2105 South Bascom Avenue
   Campbell, CA   95008
   Phone: 408.234.0071
   Email: ljlamers@ieee.org

   Marjorie Krueger
   Hewlett-Packard Corporation
   8000 Foothills Blvd
   Roseville, CA 95747-5668, USA
   Phone: +1 916 785-2656
   Email: marjorie_krueger@hp.com

   Todd Sperry
   Adaptec, Inc.
   691 South Milpitas Boulevard
   Milpitas, Ca. 95035
   Phone: (408) 957-4980
   Email: todd_sperry@adaptec.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 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

Voruganti           Internet Draft  Exp. Dec. 2001                 22

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/