RFC 4171
Internet Storage Name Service (iSNS)
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.
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).
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.
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
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 relationships4. 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.
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 *
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.
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:
+---------------------------------------------------------------+
| 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].
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 *
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-0xFFFF4.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
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.
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 |
| | | |
+-------------+ +--------------------+
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 *
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-0xFFFF5. 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 + L5.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.
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 RESERVED5.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
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
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.
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 RESERVED5.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.
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.
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
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,
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.
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)
