tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4171

 
 
 

Internet Storage Name Service (iSNS)

Part 2 of 5, p. 21 to 44
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 21 
3.  iSNS Object Model

   iSNS provides the framework for the registration, discovery, and
   management of iSCSI devices and Fibre Channel-based devices (using
   iFCP).  This architecture framework provides elements needed to
   describe various storage device objects and attributes that may exist
   on an IP storage network.  Objects defined in this architecture
   framework include Network Entity, Portal, Storage Node, FC Device,
   Discovery Domain, and Discovery Domain Set.  Each of these objects is
   described in greater detail in the following sections.

Top      Up      ToC       Page 22 
3.1.  Network Entity Object

   The Network Entity object is a container of Storage Node objects and
   Portal objects.  It represents the infrastructure supporting access
   to a unique set of one or more Storage Nodes.  The Entity Identifier
   attribute uniquely distinguishes a Network Entity, and is the key
   used to register a Network Entity object in an iSNS server.  All
   Storage Nodes and Portals contained within a single Network Entity
   object operate as a cohesive unit.

   Note that it is possible for a single physical device or gateway to
   be represented by more than one logical Network Entity in the iSNS
   database.  For example, one of the Storage Nodes on a physical device
   may be accessible from only a subset of the network interfaces (i.e.,
   Portals) available on that device.  In this case, a logical network
   entity (i.e., a "shadow entity") is created and used to contain the
   Portals and Storage Nodes that can operate cooperatively.  No object
   (Portals, Storage Nodes, etc.) can be contained in more than one
   logical Network Entity.

   Similarly, it is possible for a logical Network Entity to be
   supported by more than one physical device or gateway.  For example,
   multiple FC-iSCSI gateways may be used to bridge FC devices in a
   single Fibre Channel network.  Collectively, the multiple gateways
   can be used to support a single logical Network Entity that is used
   to contain all the devices in that Fibre Channel network.

3.2.  Portal Object

   The Portal object is an interface through which access to Storage
   Nodes within the Network Entity can be obtained.  The IP address and
   TCP/UDP Port number attributes uniquely distinguish a Portal object,
   and combined are the key used to register a Portal object in an iSNS
   server.  A Portal is contained in one and only one Network Entity,
   and may be contained in one or more DDs (see Section 3.6).

3.3.  Storage Node Object

   The Storage Node object is the logical endpoint of an iSCSI or iFCP
   session.  In iFCP, the session endpoint is represented by the World
   Wide Port Name (WWPN).  In iSCSI, the session endpoint is represented
   by the iSCSI Name of the device.  For iSCSI, the iSCSI Name attribute
   uniquely distinguishes a Storage Node, and is the key used to
   register a Storage Node object in an iSNS Server.  For iFCP, the FC
   Port Name (WWPN) attribute uniquely distinguishes a Storage Node, and
   is the key used to register a Storage Node object in the iSNS Server.
   Storage Node is contained in only one Network Entity object and may
   be contained in one or more DDs (see Section 3.6).

Top      Up      ToC       Page 23 
3.4.  Portal Group Object

   The Portal Group (PG) object represents an association between a
   Portal and an iSCSI Node.  Each Portal and iSCSI Storage Node
   registered in an Entity can be associated using a Portal Group (PG)
   object.  The PG Tag (PGT), if non-NULL, indicates that the associated
   Portal provides access to the associated iSCSI Storage Node in the
   Entity.  All Portals that have the same PGT value for a specific
   iSCSI Storage Node allow coordinated access to that node.

   A PG object MAY be registered when a Portal or iSCSI Storage Node is
   registered.  Each Portal to iSCSI Node association is represented by
   one and only one PG object.  In order for a Portal to provide access
   to an iSCSI Node, the PGT of the PG object MUST be non-NULL.  If the
   PGT value registered for a specified Portal and iSCSI Node is NULL,
   or if no PGT value is registered, then the Portal does not provide
   access to that iSCSI Node in the Entity.

   The PGT value indicates whether access to an iSCSI Node can be
   coordinated across multiple Portals.  All Portals that have the same
   PGT value for a specific iSCSI Node can provide coordinated access to
   that iSCSI Node.  According to the iSCSI Specification, coordinated
   access to an iSCSI node indicates the capability of coordinating an
   iSCSI session with connections that span these Portals [iSCSI].

   The PG object is uniquely distinguished by the iSCSI Name, Portal IP
   Address, and Portal TCP Port values of the associated Storage Node
   and Portal objects.  These are represented in the iSNS Server by the
   PG iSCSI Name, PG Portal IP Address, and PG Portal TCP/UDP Port
   attributes, respectively.  The PG object is also uniquely
   distinguished in the iSNS Server by the PG Index value.

   A new PG object can only be registered by referencing its associated
   iSCSI Storage Node or Portal object.  A pre-existing PG object can be
   modified or queried by using its Portal Group Index as message key,
   or by referencing its associated iSCSI Storage Node or Portal object.
   A 0-length Tag, Length, Value TLV is used to register a PGT NULL
   value.

   The PG object is deregistered if and only if its associated iSCSI
   Node and Portal objects are both removed.

Top      Up      ToC       Page 24 
3.5.  FC Device Object

   The FC Device represents the Fibre Channel Node.  This object
   contains information that may be useful in the management of the
   Fibre Channel device.  The FC Node Name (WWNN) attribute uniquely
   distinguishes an FC Device, and is the key used to register an FC
   Device object in the iSNS Server.

   The FC Device is contained in one or more Storage Node objects.

3.6.  Discovery Domain Object

   Discovery Domains (DD) are a security and management mechanism used
   to administer access and connectivity to storage devices.  For query
   and registration purposes, they are considered containers for Storage
   Node and Portal objects.  A query by an iSNS client that is not from
   a Control Node only returns information about objects with which it
   shares at least one active DD.  The only exception to this rule is
   with Portals; if Storage Nodes of a Network Entity are registered in
   the DD without Portals, then all Portals of that Network Entity are
   implicit members of that DD.  The Discovery Domain ID (DD_ID)
   attribute uniquely distinguishes a Discovery Domain object, and is
   the key used to register a Discovery Domain object in the iSNS
   Server.

   A DD is considered active if it is a member of at least one active DD
   Set.  DDs that are not members of at least one enabled DDS are
   considered disabled.  A Storage Node can be a member of one or more
   DDs.  An enabled DD establishes connectivity among the Storage Nodes
   in that DD.

3.7.  Discovery Domain Set Object

   The Discovery Domain Set (DDS) is a container object for Discovery
   Domains (DDs).  DDSs may contain one or more DDs.  Similarly, each DD
   can be a member of one or more DDSs.  DDSs are a mechanism to store
   coordinated sets of DD mappings in the iSNS server.  Active DDs are
   members of at least one active DD Set.  Multiple DDSs may be
   considered active at the same time.  The Discovery Domain Set ID
   (DDS_ID) attribute uniquely distinguishes a Discovery Domain Set
   object, and is the key used to register a Discovery Domain Set object
   in the iSNS Server.

3.8.  iSNS Database Model

   As presented to the iSNS client, each object of a specific type in
   the iSNS database MUST have an implicit internal linear ordering
   based on the key(s) for that object type.  This ordering provides the

Top      Up      ToC       Page 25 
   ability to respond to DevGetNext queries (see Section 5.6.5.3).  The
   ordering of objects in the iSNS database SHOULD NOT be changed with
   respect to that implied ordering, as a consequence of object
   insertions and deletions.  That is, the relative order of surviving
   object entries in the iSNS database SHOULD be preserved so that the
   DevGetNext message encounters generally reasonable behavior.

   The following diagram shows the various objects described above and
   their relationship to each other.

                    +--------------+    +-----------+
                    |    NETWORK   |1  *|           |
                    |    ENTITY    |----|  PORTAL   |
                    |              |    |           |
                    +--------------+    +-----------+
                            |1            |1  |*
                            |             |   |
                            |             |*  |
                            |   +----------+  |
                            |   |  PORTAL  |  |
                            |   |  GROUP   |  |
                            |   +----------+  |
                            |    |*           |
                            |    |            |
                            |*   |1           |*
   +-----------+    +--------------+    +-----------+    +-----------+
   |    FC     |1  *|   STORAGE    |*  *| DISCOVERY |*  *| DISCOVERY |
   |  DEVICE   |----|    NODE      |----|  DOMAIN   |----|  DOMAIN   |
   |           |    |              |    |           |    |    SET    |
   +-----------+    +--------------+    +-----------+    +-----------+

                * represents 0 to many possible relationships

4.  iSNS Implementation Requirements

   This section details specific requirements for support of each of
   these IP storage protocols.  Implementation requirements for security
   are described in Section 7.

4.1.  iSCSI Requirements

   Use of iSNS in support of iSCSI is OPTIONAL.  iSCSI devices MAY be
   manually configured with the iSCSI Name and IP address of peer
   devices, without the aid or intervention of iSNS.  iSCSI devices may
   also use SLP [RFC2608] to discover peer iSCSI devices.  However, iSNS
   is useful for scaling a storage network to a larger number of iSCSI
   devices.

Top      Up      ToC       Page 26 
4.1.1.  Required Attributes for Support of iSCSI

   The following attributes are available to support iSCSI.  Attributes
   indicated in the REQUIRED for Server column MUST be implemented by an
   iSNS server used to support iSCSI.  Attributes indicated in the
   REQUIRED for Client column MUST be implemented by an iSCSI device
   that elects to use the iSNS.  Attributes indicated in the K (Key)
   column uniquely identify the object type in the iSNS Server.  A more
   detailed description of each attribute is found in Section 6.

                                                        REQUIRED for:
   Object             Attribute                    K    Server  Client
   ------             ---------                    -    ------  ------
   NETWORK ENTITY     Entity Identifier            *      *        *
                      Entity Protocol                     *        *
                      Management IP Address               *
                      Timestamp                           *
                      Protocol Version Range              *
                      Registration Period                 *
                      Entity Index                        *
                      Entity IKE Phase-1 Proposal
                      Entity Certificate

   PORTAL             IP Address                   *      *        *
                      TCP/UDP Port                 *      *        *
                      Portal Symbolic Name                *
                      ESI Interval                        *
                      ESI Port                            *
                      Portal Index                        *
                      SCN Port                            *
                      Portal Security Bitmap              *
                      Portal IKE Phase-1 Proposal
                      Portal IKE Phase-2 Proposal
                      Portal Certificate

   PORTAL GROUP       PG iSCSI Name                *      *        *
                      PG IP Address                *      *        *
                      PG TCP/UDP Port              *      *        *
                      PG Tag                              *        *
                      PG Index                            *

Top      Up      ToC       Page 27 
   STORAGE NODE       iSCSI Name                   *      *        *
                      iSCSI Node Type                     *        *
                      Alias                               *
                      iSCSI SCN Bitmap                    *
                      iSCSI Node Index                    *
                      WWNN Token
                      iSCSI AuthMethod
                      iSCSI Node Certificate

   DISCOVERY DOMAIN   DD ID                        *      *        *
                      DD Symbolic Name                    *
                      DD Member iSCSI Node Index          *
                      DD Member iSCSI Name                *
                      DD Member Portal Index              *
                      DD Member Portal IP Addr            *
                      DD Member Portal TCP/UDP            *
                      DD Features                         *

   DISCOVERY DOMAIN   DDS Identifier                *     *
   SET                DDS Symbolic Name                   *
                      DDS Status                          *

   All iSCSI user-specified and vendor-specified attributes are OPTIONAL
   to implement and use.

Top      Up      ToC       Page 28 
4.1.2.  Examples: iSCSI Object Model Diagrams

   The following diagram models how a simple iSCSI-based initiator and
   target is represented using database objects stored in the iSNS
   server.  In this implementation, each target and initiator is
   attached to a single Portal.

   +----------------------------------------------------------------+
   |                         IP Network                             |
   +------------+--------------------------------------+------------+
                |                                      |
                |                                      |
   +-----+------+------+-----+            +-----+------+------+-----+
   |     | PORTAL      |     |            |     | PORTAL      |     |
   |     | -IP Addr 1  |     |            |     | -IP Addr 2  |     |
   |     | -TCP Port 1 |     |            |     | -TCP Port 2 |     |
   |     +-----+ +-----+     |            |     +-----+ +-----+     |
   |           | |           |            |           | |           |
   |     +-----+ +-----+     |            |     +-----+ +-----+     |
   |     | PORTAL GROUP|     |            |     | PORTAL GROUP|     |
   |     | -Prtl Tag 1 |     |            |     | -Prtl Tag 2 |     |
   |     +-----+ +-----+     |            |     +-----+ +-----+     |
   |           | |           |            |           | |           |
   |  +--------+ +--------+  |            |   +-------+ +--------+  |
   |  |                   |  |            |   |                  |  |
   |  |  STORAGE NODE     |  |            |   |  STORAGE NODE    |  |
   |  |  -iSCSI Name      |  |            |   |   -iSCSI Name    |  |
   |  |  -Alias: "server1"|  |            |   |   -Alias: "disk1"|  |
   |  |  -Type: initiator |  |            |   |   -Type: target  |  |
   |  |                   |  |            |   |                  |  |
   |  +-------------------+  |            |   +------------------+  |
   |                         |            |                         |
   |    NETWORK ENTITY       |            |    NETWORK ENTITY       |
   |   -Entity ID (FQDN):    |            |   -Entity ID (FQDN):    |
   |    "strg1.example.com"  |            |    "strg2.example.net"  |
   |   -Protocol: iSCSI      |            |   -Protocol: iSCSI      |
   |                         |            |                         |
   +-------------------------+            +-------------------------+

   The object model can be expanded to describe more complex devices,
   such as an iSCSI device with more than one storage controller, in
   which each controller is accessible through any of multiple Portal
   interfaces, possibly using multiple Portal Groups.  The storage
   controllers on this device can be accessed through alternate Portal
   interfaces if any original interface should fail.  The following
   diagram describes such a device:

Top      Up      ToC       Page 29 
      +---------------------------------------------------------------+
      |                         IP Network                            |
      +-------------------+-----------------------+-------------------+
                          |                       |
                          |                       |
      +------------+------+------+---------+------+------+------------+
      |            | PORTAL 1    |         | PORTAL 2    |            |
      |            | -IP Addr 1  |         | -IP Addr 2  |            |
      |            | -TCP Port 1 |         | -TCP Port 2 |            |
      |            +-----+ +-----+         +-----+ +-----+            |
      |                  | |                     | |                  |
      |  +---------------+ +---------------------+ +---------------+  |
      |  +-------+ +----------------+ +-------------------+ +------+  |
      |          | |                | |                   | |         |
      |  +-------+ +-------+ +------+ +--------+ +--------+ +------+  |
      |  |                 | |                 | |                 |  |
      |  | STORAGE NODE 1  | | STORAGE NODE 2  | | STORAGE NODE 3  |  |
      |  |  -iSCSI Name 1  | |  -iSCSI Name 2  | |  -iSCSI Name 3  |  |
      |  |  -Alias: "disk1"| |  -Alias: "disk2"| |  -Alias: "disk3"|  |
      |  |  -Type: target  | |  -Type: target  | |  -Type: target  |  |
      |  |                 | |                 | |                 |  |
      |  +-----------------+ +-----------------+ +-----------------+  |
      |                                                               |
      |                         NETWORK ENTITY                        |
      |                    -Entity ID (FQDN): "dev1.example.com"      |
      |                    -Protocol: iSCSI                           |
      |                                                               |
      |                   Portal Group Object Table                   |
      |           Storage-Node Portal Portal-Group-Tag                |
      |                1         1           10                       |
      |                1         2         NULL (no access permitted) |
      |                2         1           20                       |
      |                2         2           20                       |
      |                3         1           30                       |
      |                3         2           10                       |
      |                                                               |
      +---------------------------------------------------------------+

   Storage Node 1 is accessible via Portal 1 with a PGT of 10.  It does
   not have a Portal Group Tag (PGT) assigned for Portal 2, so Storage
   Node 1 cannot be accessed via Portal 2.

   Storage Node 2 can be accessed via both Portal 1 and Portal 2.  Since
   Storage Node 2 has the same PGT value assigned to both Portal 1 and
   Portal 2, in this case 20, coordinated access via the Portals is
   available [iSCSI].

Top      Up      ToC       Page 30 
   Storage Node 3 can be accessed via Portal 1 or Portal 2.  However,
   since Storage Node 3 has different PGT values assigned to each
   Portal, in this case 10 and 30, access is not coordinated [iSCSI].
   Because PGTs are assigned within the context of a Storage Node, the
   PGT value of 10 used for Storage Node 1 and Storage Node 3 are not
   interrelated.

4.1.3.  Required Commands and Response Messages for Support of iSCSI

   The following iSNSP messages and responses are available in support
   of iSCSI.  Messages indicated in the REQUIRED for Server column MUST
   be implemented in iSNS servers used for iSCSI devices.  Messages
   indicated in the REQUIRED for Client column MUST be implemented in
   iSCSI devices that elect to use the iSNS server.

                                                     REQUIRED for:
   Message Description       Abbreviation  Func_ID   Server  Client
   -------------------       ------------  -------   ------  ------
   RESERVED                                0x0000
   Device Attr Reg Request   DevAttrReg    0x0001       *       *
   Dev Attr Query Request    DevAttrQry    0x0002       *       *
   Dev Get Next Request      DevGetNext    0x0003       *
   Deregister Dev Request    DevDereg      0x0004       *       *
   SCN Register Request      SCNReg        0x0005       *
   SCN Deregister Request    SCNDereg      0x0006       *
   SCN Event                 SCNEvent      0x0007       *
   State Change Notification SCN           0x0008       *
   DD Register               DDReg         0x0009       *       *
   DD Deregister             DDDereg       0x000A       *       *
   DDS Register              DDSReg        0x000B       *       *
   DDS Deregister            DDSDereg      0x000C       *       *
   Entity Status Inquiry     ESI           0x000D       *
   Name Service Heartbeat    Heartbeat     0x000E
   RESERVED                                0x000F-0x00FF
   Vendor Specific                         0x0100-0x01FF
   RESERVED                                0x0200-0x7FFF

   The following are iSNSP response messages used in support of iSCSI:

                                                      REQUIRED for:
   Response Message Desc     Abbreviation  Func_ID    Server  Client
   ---------------------     ------------  -------    ------  ------
   RESERVED                                0x8000
   Device Attr Register Rsp  DevAttrRegRsp 0x8001       *       *
   Device Attr Query Rsp     DevAttrQryRsp 0x8002       *       *
   Device Get Next Rsp       DevGetNextRsp 0x8003       *
   Device Dereg Rsp          DevDeregRsp   0x8004       *       *
   SCN Register Rsp          SCNRegRsp     0x8005       *

Top      Up      ToC       Page 31 
   SCN Deregister Rsp        SCNDeregRsp   0x8006       *
   SCN Event Rsp             SCNEventRsp   0x8007       *
   SCN Response              SCNRsp        0x8008       *
   DD Register Rsp           DDRegRsp      0x8009       *       *
   DD Deregister Rsp         DDDeregRsp    0x800A       *       *
   DDS Register Rsp          DDSRegRsp     0x800B       *       *
   DDS Deregister Rsp        DDSDeregRsp   0x800C       *       *
   Entity Stat Inquiry Rsp   ESIRsp        0x800D       *
   RESERVED                                0x800E-0x80FF
   Vendor Specific                         0x8100-0x81FF
   RESERVED                                0x8200-0xFFFF

4.2.  iFCP Requirements

   In iFCP, use of iSNS is REQUIRED.  No alternatives exist for support
   of iFCP Naming & Discovery functions.

4.2.1.  Required Attributes for Support of iFCP

   The following table displays attributes that are used by iSNS to
   support iFCP.  Attributes indicated in the REQUIRED for Server column
   MUST be implemented by the iSNS server that supports iFCP.
   Attributes indicated in the REQUIRED for Client column MUST be
   supported by iFCP gateways.  Attributes indicated in the K (Key)
   column uniquely identify the object type in the iSNS Server.  A more
   detailed description of each attribute is found in Section 6.

                                                       REQUIRED for:
   Object             Attribute                   K    Server  Client
   ------             ---------                   -    ------  ------
   NETWORK ENTITY     Entity Identifier           *       *       *
                      Entity Protocol                     *       *
                      Management IP Address               *
                      Timestamp                           *
                      Protocol Version Range              *
                      Registration period
                      Entity Index
                      Entity IKE Phase-1 Proposal
                      Entity Certificate

   PORTAL             IP Address                  *       *       *
                      TCP/UDP Port                *       *       *
                      Symbolic Name                       *
                      ESI Interval                        *
                      ESI Port                            *
                      SCN Port                            *
                      Portal IKE Phase-1 Proposal
                      Portal IKE Phase-2 Proposal

Top      Up      ToC       Page 32 
                      Portal Certificate
                      Security Bitmap                     *

   STORAGE NODE       FC Port Name (WWPN)         *       *       *
   (FC Port)          Port_ID                             *       *
                      FC Port Type                        *       *
                      Port Symbolic Name                  *
                      Fabric Port Name (FWWN)             *
                      Hard Address                        *
                      Port IP Address                     *
                      Class of Service                    *
                      FC FC-4 Types                       *
                      FC FC-4 Descriptors                 *
                      FC FC-4 Features                    *
                      SCN Bitmap                          *
                      iFCP Port Role                      *
                      Permanent Port Name                 *

   FC DEVICE          FC Node Name (WWNN)         *       *       *
   (FC Node)          Node Symbolic Name                  *
                      Node IP Address                     *
                      Node IPA                            *
                      Proxy iSCSI Name

   DISCOVERY DOMAIN   DD ID                       *       *       *
                      DD Symbolic Name                    *
                      DD Member FC Port Name              *
                      DD Member Portal Index              *
                      DD Member Portal IP Addr            *
                      DD Member Portal TCP/UDP            *

   DISCOVERY DOMAIN   DDS ID                      *       *
   SET                DDS Symbolic Name                   *
                      DDS Status                          *

   OTHER              Switch Name
                      Preferred_ID
                      Assigned_ID
                      Virtual_Fabric_ID

   All iFCP user-specified and vendor-specified attributes are OPTIONAL
   to implement and use.

4.2.2.  Example: iFCP Object Model Diagram

   The iFCP protocol allows native Fibre Channel devices or Fibre
   Channel fabrics connected to an iFCP gateway to be directly
   internetworked using IP.

Top      Up      ToC       Page 33 
   When supporting iFCP, the iSNS server stores Fibre Channel device
   attributes, iFCP gateway attributes, and Fibre Channel fabric switch
   attributes that might also be stored in an FC name server.

   The following diagram shows a representation of a gateway supporting
   multiple Fibre Channel devices behind it.  The two Portal objects
   represent IP interfaces on the iFCP gateway that can be used to
   access any of the three Storage Node objects behind it.  Note that
   the FC Device object is not contained in the Network Entity object.
   However, each FC Device has a relationship to one or more Storage
   Node objects.

   +--------------------------------------------------------+
   |                         IP Network                     |
   +--------+-----------------+-----------------------------+
            |                 |
   +-+------+------+---+------+------+----------------------+
   | | PORTAL      |   | PORTAL      | NETWORK ENTITY       |
   | | -IP Addr 1  |   | -IP Addr 2  | -Entity ID (FQDN):   |
   | | -TCP Port 1 |   | -TCP Port 2 |  "gtwy1.example.com" |
   | +-----+ +-----+   +-----+ +-----+ -Protocol: iFCP      |
   |       | |               | |                            |
   | +-----+ +---------------+ +----------------------+     |
   | +-----+ +---------------+ +-------------+ +------+     |
   |       | |               | |             | |            |
   | +-----+ +-----+    +----+ +------+ +----+ +------+     |
   | |STORAGE NODE |    |STORAGE NODE | |STORAGE NODE |     |
   | | -WWPN 1     |    | -WWPN 2     | | -WWPN 3     |     |
   | | -Port ID 1  |    | -Port ID 2  | | -Port ID 3  |     |
   | | -FWWN 1     |    | -FWWN 2     | | -FWWN 3     |     |
   | | -FC COS     |    | -FC COS     | | -FC COS     |     |
   | +------+------+    +-------+-----+ +----+--------+     |
   +--------|-------------------|------------|--------------+
            |                   |            |
     +------+------+        +---+------------+---+
     | FC DEVICE   |        |    FC DEVICE       |
     | -WWNN 1     |        |   -WWNN 2          |
     |             |        |                    |
     +-------------+        +--------------------+

Top      Up      ToC       Page 34 
4.2.3.  Required Commands and Response Messages for Support of iFCP

   The iSNSP messages and responses displayed in the following tables
   are available to support iFCP gateways.  Messages indicated in the
   REQUIRED TO IMPLEMENT column MUST be supported by the iSNS server
   used by iFCP gateways.  Messages indicated in the REQUIRED TO USE
   column MUST be supported by the iFCP gateways themselves.

                                                     REQUIRED for:
   Message Description       Abbreviation  Func ID   Server   Client
   -------------------       ------------  -------   ------   ------
   RESERVED                                0x0000
   Device Attr Reg Request   DevAttrReg    0x0001       *       *
   Device Attr Query Request DevAttrQry    0x0002       *       *
   Device Get Next Request   DevGetNext    0x0003       *
   Device Dereg Request      DevDereg      0x0004       *       *
   SCN Register Request      SCNReg        0x0005       *
   SCN Deregister Request    SCNDereg      0x0006       *
   SCN Event                 SCNEvent      0x0007       *
   State Change Notification SCN           0x0008       *
   DD Register               DDReg         0x0009       *       *
   DD Deregister             DDDereg       0x000A       *       *
   DDS Register              DDSReg        0x000B       *       *
   DDS Deregister            DDSDereg      0x000C       *       *
   Entity Status Inquiry     ESI           0x000D       *
   Name Service Heartbeat    Heartbeat     0x000E       *
   Reserved                  Reserved      0x000F-0x0010
   Request FC_DOMAIN_ID      RqstDomId     0x0011
   Release FC_DOMAIN_ID      RlseDomId     0x0012
   Get FC_DOMAIN_IDs         GetDomId      0x0013
   RESERVED                                0x0014-0x00FF
   Vendor Specific                         0x0100-0x01FF
   RESERVED                                0x0200-0x7FFF

   The following are iSNSP response messages in support of iFCP:

                                                     REQUIRED for:
   Response Message Desc     Abbreviation  Func_ID   Server   Client
   ---------------------     ------------  -------   ------   ------
   RESERVED                                0x8000
   Device Attr Reg Rsp       DevAttrRegRsp 0x8001       *       *
   Device Attr Query Rsp     DevAttrQryRsp 0x8002       *       *
   Device Get Next Rsp       DevGetNextRsp 0x8003       *
   Device Deregister Rsp     DevDeregRsp   0x8004       *       *
   SCN Register Rsp          SCNRegRsp     0x8005       *
   SCN Deregister Rsp        SCNDeregRsp   0x8006       *
   SCN Event Rsp             SCNEventRsp   0x8007       *
   SCN Rsp                   SCNRsp        0x8008       *

Top      Up      ToC       Page 35 
   DD Register Rsp           DDRegRsp      0x8009       *       *
   DD Deregister Rsp         DDDeregRsp    0x800A       *       *
   DDS Register Rsp          DDSRegRsp     0x800B       *       *
   DDS Deregister Rsp        DDSDeregRsp   0x800C       *       *
   Entity Status Inquiry Rsp ESIRsp        0x800D       *
   NOT USED                                0x800E
   RESERVED                                0x800F-0x8010
   Request FC_DOMAIN_ID Rsp  RqstDomIdRsp  0x8011
   Release FC_DOMAIN_ID Rsp  RlseDomIdRsp  0x8012
   Get FC_DOMAIN_IDs         GetDomIdRsp   0x0013
   RESERVED                                0x8014-0x80FF
   Vendor Specific                         0x8100-0x81FF
   RESERVED                                0x8200-0xFFFF

5.  iSNSP Message Format

   The iSNSP message format is similar to the format of other common
   protocols such as DHCP, DNS and BOOTP.  An iSNSP message may be sent
   in one or more iSNS Protocol Data Units (PDU).  Each PDU is 4-byte
   aligned.  The following describes the format of the iSNSP PDU:

   Byte   MSb                                        LSb
   Offset 0                   15 16                   31
          +---------------------+----------------------+
        0 |   iSNSP VERSION     |    FUNCTION ID       | 4 Bytes
          +---------------------+----------------------+
        4 |     PDU LENGTH      |       FLAGS          | 4 Bytes
          +---------------------+----------------------+
        8 |   TRANSACTION ID    |    SEQUENCE ID       | 4 Bytes
          +---------------------+----------------------+
       12 |                                            |
          |                PDU PAYLOAD                 | N Bytes
          |                    ...                     |
          +--------------------------------------------+
     12+N | AUTHENTICATION BLOCK (Multicast/Broadcast) | L Bytes
          +--------------------------------------------+
                   Total Length = 12 + N + L

5.1.  iSNSP PDU Header

   The iSNSP PDU header contains the iSNSP VERSION, FUNCTION ID, PDU
   LENGTH, FLAGS, TRANSACTION ID, and SEQUENCE ID fields as defined
   below.

Top      Up      ToC       Page 36 
5.1.1.  iSNSP Version

   The iSNSP version described in this document is 0x0001.  All other
   values are RESERVED.  The iSNS server MAY reject messages for iSNSP
   version numbers that it does not support.

5.1.2.  iSNSP Function ID

   The FUNCTION ID defines the type of iSNS message and the operation to
   be executed.  FUNCTION_ID values with the leading bit cleared
   indicate query, registration, and notification messages, whereas
   FUNCTION_ID values with the leading bit set indicate response
   messages.

   See Section 4 under the appropriate protocol (i.e., iSCSI or iFCP)
   for a mapping of the FUNCTION_ID value to the iSNSP Command or
   Response message.  All PDUs comprising an iSNSP message must have the
   same FUNCTION_ID value.

5.1.3.  iSNSP PDU Length

   The iSNS PDU Length specifies the length of the PDU PAYLOAD field in
   bytes.  The PDU Payload contains TLV attributes for the operation.

   Additionally, response messages contain a success/failure code.  The
   PDU Length MUST be 4-byte aligned.

5.1.4.  iSNSP Flags

   The FLAGS field indicates additional information about the message
   and the type of Network Entity that generated the message.  The
   following table displays the valid flags:

          Bit Position      Enabled (1) means:
          ------------      -----------------
           16               Sender is the iSNS client
           17               Sender is the iSNS server
           18               Authentication block is present
           19               Replace flag (for DevAttrReg)
           20               Last PDU of the iSNS message
           21               First PDU of the iSNS message
           22-31            RESERVED

5.1.5.  iSNSP Transaction ID

   The TRANSACTION ID MUST be set to a unique value for each
   concurrently outstanding request message.  Replies MUST use the same
   TRANSACTION ID value as the associated iSNS request message.  If a

Top      Up      ToC       Page 37 
   message is retransmitted, the original TRANSACTION ID value MUST be
   used.  All PDUs comprising an iSNSP message must have the same
   TRANSACTION ID value.

5.1.6.  iSNSP Sequence ID

   The SEQUENCE ID has a unique value for each PDU within a single
   transaction.  The SEQUENCE_ID value of the first PDU transmitted in a
   given iSNS message MUST be zero (0), and each SEQUENCE_ID value in
   each PDU MUST be numbered sequentially in the order in which the PDUs
   are transmitted.  Note that the two-byte SEQUENCE ID allows for up to
   65536 PDUs per iSNS message.

5.2.  iSNSP Message Segmentation and Reassembly

   iSNS messages may be carried in one or more iSNS PDUs.  If only one
   iSNS PDU is used to carry the iSNS message, then bit 21 (First PDU)
   and bit 20 in the FLAGS field (Last PDU) SHALL both be set.  If
   multiple PDUs are used to carry the iSNS message, then bit 21 SHALL
   be set in the first PDU of the message, and bit 20 SHALL be set in
   the last PDU.

   All PDUs comprising the same iSNSP message SHALL have the same
   FUNCTION_ID and TRANSACTION_ID values.  Each PDU comprising an iSNSP
   message SHALL have a unique SEQUENCE_ID value.

5.3.  iSNSP PDU Payload

   The iSNSP PDU PAYLOAD is of variable length and contains attributes
   used for registration and query operations.  The attribute data items
   use a format similar to that of other protocols, such as DHCP
   [RFC2131] options.  Each iSNS attribute is specified in the PDU
   Payload using Tag-Length-Value (TLV) data format, as shown below:

   Byte   MSb                                        LSb
   Offset 0                                           31
          +--------------------------------------------+
        0 |               Attribute Tag                | 4 Bytes
          +--------------------------------------------+
        4 |            Attribute Length (N)            | 4 Bytes
          +--------------------------------------------+
        8 |                                            |
          |              Attribute Value               | N Bytes
          |                                            |
          +--------------------------------------------+
                   Total Length = 8 + N

Top      Up      ToC       Page 38 
   Attribute Tag:    a 4-byte field that identifies the attribute as
                     defined in Section 6.1.  This field contains the
                     tag value from the indicated table.

   Attribute Length: a 4-byte field that indicates the length, in bytes,
                     of the value field to follow in the TLV.  For
                     variable-length attributes, the value field MUST
                     contain padding bytes, if necessary, in order to
                     achieve 4-byte alignment.  A "zero-length TLV"
                     contains only the attribute tag and length fields.

   Attribute Value:  a variable-length field containing the attribute
                     value and padding bytes (if necessary).

   The above format is used to identify each attribute in the PDU
   Payload.  Note that TLV boundaries need not be aligned with PDU
   boundaries; PDUs may carry one or more TLVs, or any fraction thereof.
   The Response Status Code, contained in response message PDU Payloads
   and described below, is not in TLV format.  PDU Payloads for messages
   that do not contain iSNS attributes, such as the Name Service
   Heartbeat, do not use the TLV format.

5.3.1.  Attribute Value 4-Byte Alignment

   All attribute values are aligned to 4-byte boundaries.  For variable
   length attributes, if necessary, the TLV length MUST be increased to
   the next 4-byte boundary through padding with bytes containing zero
   (0).  If an attribute value is padded, a combination of the tag and
   attribute value itself is used to determine the actual value length
   and number of pad bytes.  There is no explicit count of the number of
   pad bytes provided in the TLV.

Top      Up      ToC       Page 39 
5.4.  iSNSP Response Status Codes

   All iSNSP response messages contain a 4-byte Status Code field as the
   first field in the iSNSP PDU PAYLOAD.  If the original iSNSP request
   message was processed normally by the iSNS server, or by the iSNS
   client for ESI and SCN messages, then this field SHALL contain a
   status code of 0 (Successful).  A non-zero status code indicates
   rejection of the entire iSNS client request message.

          Status Code      Status Description
          -----------      -----------------
            0              Successful
            1              Unknown Error
            2              Message Format Error
            3              Invalid Registration
            4              RESERVED
            5              Invalid Query
            6              Source Unknown
            7              Source Absent
            8              Source Unauthorized
            9              No Such Entry
           10              Version Not Supported
           11              Internal Error
           12              Busy
           13              Option Not Understood
           14              Invalid Update
           15              Message (FUNCTION_ID) Not Supported
           16              SCN Event Rejected
           17              SCN Registration Rejected
           18              Attribute Not Implemented
           19              FC_DOMAIN_ID Not Available
           20              FC_DOMAIN_ID Not Allocated
           21              ESI Not Available
           22              Invalid Deregistration
           23              Registration Feature Not Supported
           24 and above    RESERVED

5.5.  Authentication for iSNS Multicast and Broadcast Messages

   For iSNS multicast and broadcast messages (see Section 2.9.3), the
   iSNSP provides authentication capability.  The following section
   details the iSNS Authentication Block, which is identical in format
   to the SLP authentication block [RFC2608]. iSNS unicast messages
   SHOULD NOT include the authentication block, but rather should rely
   upon IPSec security mechanisms.

Top      Up      ToC       Page 40 
   If a message contains an authentication block, then the
   "Authentication block present" bit in the iSNSP PDU header FLAGS
   field SHALL be enabled.

   If a PKI is available with an [X.509] Certificate Authority (CA),
   then public key authentication of the iSNS server is possible.  The
   authentication block leverages the DSA with SHA-1 algorithm, which
   can easily integrate into a public key infrastructure.

   The authentication block contains a digital signature for the
   multicast message.  The digital signature is calculated on a per-PDU
   basis.  The authentication block contains the following information:

   1.  A time stamp, to prevent replay attacks.
   2.  A structured authenticator containing a signature calculated over
       the time stamp and the message being secured.
   3.  An indicator of the cryptographic algorithm that was used to
       calculate the signature.
   4.  An indicator of the keying material and algorithm parameters,
       used to calculate the signature.

   The authentication block is described in the following figure:

      Byte   MSb                              LSb
      Offset 0                                 31
             +----------------------------------+
         0   |    BLOCK STRUCTURE DESCRIPTOR    |     4 Bytes
             +----------------------------------+
         4   |   AUTHENTICATION BLOCK LENGTH    |     4 Bytes
             +----------------------------------+
         8   |           TIMESTAMP              |     8 Bytes
             +----------------------------------+
        16   |       SPI STRING LENGTH          |     4 Bytes
             +----------------------------------+
        20   |           SPI STRING             |     N Bytes
             +----------------------------------+
    20 + N   |     STRUCTURED AUTHENTICATOR     |     M Bytes
             +----------------------------------+
                Total Length = 20 + N + M

   BLOCK STRUCTURE DESCRIPTOR (BSD): Defines the structure and algorithm
              to use for the STRUCTURED AUTHENTICATOR.  BSD values from
              0x00000000 to 0x00007FFF are assigned by IANA, while
              values 0x00008000 to 0x00008FFF are for private use.

Top      Up      ToC       Page 41 
   AUTHENTICATION BLOCK LENGTH: Defines the length of the authentication
              block, beginning with the BSD field and running through
              the last byte of the STRUCTURED AUTHENTICATOR.

   TIMESTAMP: This is an 8-byte unsigned, fixed-point integer giving the
              number of seconds since 00:00:00 GMT on January 1, 1970.

   SPI STRING LENGTH: The length of the SPI STRING field.

   SPI STRING (Security Parameters Index): Index to the key and
              algorithm used by the message recipient to decode the
              STRUCTURED AUTHENTICATOR field.

   STRUCTURED AUTHENTICATOR: Contains the digital signature.  For the
              default BSD value of 0x0002, this field SHALL contain the
              binary ASN.1 encoding of output values from the DSA with
              SHA-1 signature calculation as specified in Section 2.2.2
              of [RFC3279].

5.6.  Registration and Query Messages

   The iSNSP registration and query message PDU Payloads contain a list
   of attributes, and have the following format:

             +----------------------------------------+
             |     Source Attribute (Requests Only)   |
             +----------------------------------------+
             |  Message Key Attribute[1] (if present) |
             +----------------------------------------+
             |  Message Key Attribute[2] (if present) |
             +----------------------------------------+
             |               . . .                    |
             +----------------------------------------+
             |       - Delimiter Attribute -          |
             +----------------------------------------+
             |   Operating Attribute[1] (if present)  |
             +----------------------------------------+
             |   Operating Attribute[2] (if present)  |
             +----------------------------------------+
             |   Operating Attribute[3] (if present)  |
             +----------------------------------------+
             |                 . . .                  |
             +----------------------------------------+

   Each Source, Message Key, Delimiter, and Operating attribute is
   specified in the PDU Payload using the Tag-Length-Value (TLV) data
   format. iSNS Registration and Query messages are sent by iSNS Clients

Top      Up      ToC       Page 42 
   to the iSNS server IP Address and well-known TCP/UDP Port.  The iSNS
   Responses will be sent to the iSNS Client IP address and TCP/UDP port
   number from the original request message.

5.6.1.  Source Attribute

   The Source Attribute is used to identify the Storage Node to the iSNS
   server for queries and other messages that require source
   identification.  The Source Attribute uniquely identifies the source
   of the message.  Valid Source Attribute types are shown below.

          Valid Source Attributes
          -----------------------
           iSCSI Name
           FC Port Name WWPN

   For a query operation, the Source Attribute is used to limit the
   scope of the specified operation to the Discovery Domains of which
   the source is a member.  Special Control Nodes, identified by the
   Source Attribute, may be administratively configured to perform the
   specified operation on all objects in the iSNS database without
   scoping to Discovery Domains.

   For messages that change the contents of the iSNS database, the iSNS
   server MUST verify that the Source Attribute identifies either a
   Control Node or a Storage Node that is a part of the Network Entity
   containing the added, deleted, or modified objects.

5.6.2.  Message Key Attributes

   Message Key attributes are used to identify matching objects in the
   iSNS database for iSNS query and registration messages.  If present,
   the Message Key MUST be a Registration or Query Key for an object as
   described in Sections 5.6.5 and 6.1.  A Message Key is not required
   when a query spans the entire set of objects available to the Source
   or a registration is for a new Entity.

   iSCSI Names used in the Message Key MUST be normalized according to
   the stringprep template [STRINGPREP].  Entity Identifiers (EIDs) used
   in the Message Key MUST be normalized according to the nameprep
   template [NAMEPREP].

5.6.3.  Delimiter Attribute

   The Delimiter Attribute separates the Message Key attributes from the
   Operating Attributes in a PDU Payload.  The Delimiter Attribute has a
   tag value of 0 and a length value of 0.  The Delimiter Attribute is
   always 8 bytes long (a 4-byte tag field and a 4-byte length field,

Top      Up      ToC       Page 43 
   all containing zeros).  If a Message Key is not required for a
   message, then the Delimiter Attribute immediately follows the Source
   Attribute.

5.6.4.  Operating Attributes

   The Operating Attributes are a list of one or more key and non-key
   attributes related to the actual iSNS registration or query operation
   being performed.

   Operating Attributes include object key attributes and non-key
   attributes.  Object key attributes uniquely identify iSNS objects.
   Key attributes MUST precede the non-key attributes of each object in
   the Operating Attributes.  The tag value distinguishes the attribute
   as an object key attribute (i.e., tag=1, 16&17, 32, 64, and 96) or a
   non-key attribute. iSCSI Names used in the Operating Attributes MUST
   be normalized according to the stringprep template [STRINGPREP].
   Entity Identifiers (EIDs) used in the Operating Attributes MUST be
   normalized according to the nameprep template [NAMEPREP].

   The ordering of Operating Attributes in the message is important for
   determining the relationships among objects and their ownership of
   non-key attributes.  iSNS protocol messages that violate these
   ordering rules SHALL be rejected with the Status Code of 2 (Message
   Format Error).  See the message descriptions for proper operating
   attribute ordering requirements.

   Some objects are keyed by more than one object key attribute value.
   For example, the Portal object is keyed by attribute tags 16 and 17.
   When describing an object keyed by more than one key attribute, every
   object key attribute of that object MUST be listed sequentially by
   tag value in the message before non-key attributes of that object and
   key attributes of the next object.  A group of key attributes of this
   kind is treated as a single logical key attribute when identifying an
   object.

   Non-key attributes that immediately follow key attributes MUST be
   attributes of the object referenced by the key attributes.  All non-
   key attributes of an object MUST be listed before the object key
   attributes introducing the next object.

   Objects MUST be listed in inheritance order, according to their
   containment order.  Storage Node and Portal objects and their
   respective attributes MUST follow the Network Entity object to which
   they have a relationship.  Similarly, FC Device objects MUST follow
   the Storage Node object to which they have a relationship.

Top      Up      ToC       Page 44 
   Vendor-specific objects defined by tag values in the range 1537-2048
   have the same requirements described above.

5.6.4.1.  Operating Attributes for Query and Get Next Requests

   In Query and Get Next request messages, TLV attributes with length
   value of 0 are used to indicate which Operating Attributes are to be
   returned in the corresponding response.  Operating Attribute values
   that match the TLV attributes in the original message are returned in
   the response message.



(page 44 continued on part 3)

Next RFC Part