RFC 4171
Internet Storage Name Service (iSNS)
6. iSNS Attributes
Attributes can be stored in the iSNS server using iSNSP registration messages, and they can be retrieved using iSNSP query messages. Unless otherwise indicated, these attributes are supplied by iSNS clients using iSNSP registration messages.6.1. iSNS Attribute Summary
The complete registry of iSNS attributes is maintained by IANA, and the following table summarizes the initial set of iSNS attributes available at the time of publication of this document. Attributes Length Tag Reg Key Query Key ---------- ------ --- ------- --------- Delimiter 0 0 N/A N/A Entity Identifier (EID) 4-256 1 1 1|2|16&17|32|64 Entity Protocol 4 2 1 1|2|16&17|32|64 Management IP Address 16 3 1 1|2|16&17|32|64 Timestamp 8 4 -- 1|2|16&17|32|64 Protocol Version Range 4 5 1 1|2|16&17|32|64 Registration Period 4 6 1 1|2|16&17|32|64 Entity Index 4 7 1 1|2|16&17|32|64 Entity Next Index 4 8 -- 1|2|16&17|32|64 Entity ISAKMP Phase-1 var 11 1 1|2|16&17|32|64 Entity Certificate var 12 1 1|2|16&17|32|64 Portal IP Address 16 16 1 1|16&17|32|64 Portal TCP/UDP Port 4 17 1 1|16&17|32|64 Portal Symbolic Name 4-256 18 16&17 1|16&17|32|64 ESI Interval 4 19 16&17 1|16&17|32|64 ESI Port 4 20 16&17 1|16&17|32|64 Portal Index 4 22 16&17 1|16&17|32|64 SCN Port 4 23 16&17 1|16&17|32|64 Portal Next Index 4 24 -- 1|16&17|32|64 Portal Security Bitmap 4 27 16&17 1|16&17|32|64 Portal ISAKMP Phase-1 var 28 16&17 1|16&17|32|64 Portal ISAKMP Phase-2 var 29 16&17 1|16&17|32|64 Portal Certificate var 31 16&17 1|16&17|32|64 iSCSI Name 4-224 32 1 1|16&17|32|33 iSCSI Node Type 4 33 32 1|16&17|32 iSCSI Alias 4-256 34 32 1|16&17|32 iSCSI SCN Bitmap 4 35 32 1|16&17|32 iSCSI Node Index 4 36 32 1|16&17|32 WWNN Token 8 37 32 1|16&17|32
iSCSI Node Next Index 4 38 -- 1|16&17|32 iSCSI AuthMethod var 42 32 1|16&17|32 PG iSCSI Name 4-224 48 32|16&17 1|16&17|32|52 PG Portal IP Addr 16 49 32|16&17 1|16&17|32|52 PG Portal TCP/UDP Port 4 50 32|16&17 1|16&17|32|52 PG Tag (PGT) 4 51 32|16&17 1|16&17|32|52 PG Index 4 52 32|16&17 1|16&17|32|52 PG Next Index 4 53 -- 1|16&17|32|52 FC Port Name WWPN 8 64 1 1|16&17|64|66|96|128 Port ID 4 65 64 1|16&17|64 FC Port Type 4 66 64 1|16&17|64 Symbolic Port Name 4-256 67 64 1|16&17|64 Fabric Port Name 8 68 64 1|16&17|64 Hard Address 4 69 64 1|16&17|64 Port IP-Address 16 70 64 1|16&17|64 Class of Service 4 71 64 1|16&17|64 FC-4 Types 32 72 64 1|16&17|64 FC-4 Descriptor 4-256 73 64 1|16&17|64 FC-4 Features 128 74 64 1|16&17|64 iFCP SCN bitmap 4 75 64 1|16&17|64 Port Role 4 76 64 1|16&17|64 Permanent Port Name 8 77 -- 1|16&17|64 FC-4 Type Code 4 95 -- 1|16&17|64 FC Node Name WWNN 8 96 64 1|16&17|64|96 Symbolic Node Name 4-256 97 96 64|96 Node IP-Address 16 98 96 64|96 Node IPA 8 99 96 64|96 Proxy iSCSI Name 4-256 101 96 64|96 Switch Name 8 128 128 128 Preferred ID 4 129 128 128 Assigned ID 4 130 128 128 Virtual_Fabric_ID 4-256 131 128 128 iSNS Server Vendor OUI 4 256 -- SOURCE Attribute Vendor-Spec iSNS Srvr 257-384 -- SOURCE Attribute Vendor-Spec Entity 385-512 1 1|2|16&17|32|64 Vendor-Spec Portal 513-640 16&17 1|16&17|32|64 Vendor-Spec iSCSI Node 641-768 32 16&17|32 Vendor-Spec FC Port Name 769-896 64 1|16&17|64 Vendor-Spec FC Node Name 897-1024 96 64|96 Vendor-Specific DDS 1025-1280 2049 2049 Vendor-Specific DD 1281-1536 2065 2065 Other Vendor-Specific 1537-2048 DD_Set ID 4 2049 2049 1|32|64|2049|2065 DD_Set Sym Name 4-256 2050 2049 2049 DD_Set Status 4 2051 2049 2049 DD_Set_Next_ID 4 2052 -- 2049 DD_ID 4 2065 2049 1|32|64|2049|2065 DD_Symbolic Name 4-256 2066 2065 2065
DD_Member iSCSI Index 4 2067 2065 2065
DD_Member iSCSI Name 4-224 2068 2065 2065
DD_Member FC Port Name 8 2069 2065 2065
DD_Member Portal Index 4 2070 2065 2065
DD_Member Portal IP Addr 16 2071 2065 2065
DD_Member Portal TCP/UDP 4 2072 2065 2065
DD_Features 4 2078 2065 2065
DD_ID Next ID 4 2079 -- 2065
The following are descriptions of the columns used in the above
table:
Length: indicates the attribute length in bytes used for the TLV
format. Variable-length identifiers are NULL-terminated
and 4-byte aligned (NULLs are included in the length).
Tag: the IANA-assigned integer tag value used to identify the
attribute. All undefined tag values are reserved.
Reg Key: indicates the tag values for the object key in DevAttrReg
messages for registering a new attribute value in the
database. These tags represent attributes defined as
object keys in Section 4.
Query Key: indicates the possible tag values for the Message Key and
object key that are used in the DevAttrQry messages for
retrieving a stored value from the iSNS database.
The following is a summary of iSNS attribute tag values available for
future allocation by IANA at the time of publication:
Tag Values Reg Key Query Key
---------- ------- ---------
9-10, 13-15 1 1|2|16&17|32|64
21, 25-26, 30 16&17 1|16&17|32|64
39-41, 44-47 32 1|16&17|32
54-63 32|16&17 1|16&17|32|52
78-82, 85-94 64 1|16&17|64
102-127 96 64|96
132-255 -- SOURCE Attribute
2053-2064 2049 2049
2073-2077 2065 2065
2080-65535 To be assigned To be assigned
Registration and query keys for attributes with tags in the range
2080 to 65535 are to be documented in the RFC introducing the new
iSNS attributes. IANA will maintain registration of these values as
required by the new RFC.
New iSNS attributes with any of the above tag values MAY also be designated as "read-only" attributes. The new RFC introducing these attributes as "read-only" SHALL document them as such, and IANA will record their corresponding Registration Keys (Reg Keys) as "--".6.2. Entity Identifier-Keyed Attributes
The following attributes are stored in the iSNS server using the Entity Identifier attribute as the key.6.2.1. Entity Identifier (EID)
The Entity Identifier (EID) is variable-length UTF-8 encoded NULL- terminated text-based description for a Network Entity. This key attribute uniquely identifies each Network Entity registered in the iSNS server. The attribute length varies from 4 to 256 bytes (including the NULL termination), and is a unique value within the iSNS server. If the iSNS client does not provide an EID during registration, the iSNS server SHALL generate one that is unique within the iSNS database. If an EID is to be generated, then the EID attribute value in the registration message SHALL be empty (0 length). The generated EID SHALL be returned in the registration response. In environments where the iSNS server is integrated with a DNS infrastructure, the Entity Identifier may be used to store the Fully Qualified Domain Name (FQDN) of the iSCSI or iFCP device. FQDNs of greater than 255 bytes MUST NOT be used. If FQDNs are not used, the iSNS server can be used to generate EIDs. EIDs generated by the iSNS server MUST begin with the string "isns:". iSNS clients MUST NOT generate and register EIDs beginning with the string "isns:". This field MUST be normalized according to the nameprep template [NAMEPREP] before it is stored in the iSNS database.6.2.2. Entity Protocol
The Entity Protocol is a required 4-byte integer attribute that indicates the block storage protocol used by the registered NETWORK ENTITY. Values used for this attribute are assigned and maintained by IANA. The initial set of protocols supported by iSNS is as follows:
Value Entity Protocol Type
----- --------------------
1 No Protocol
2 iSCSI
3 iFCP
All others To be assigned by IANA
'No Protocol' is used to indicate that the Network Entity does not
support an IP block storage protocol. A Control Node or monitoring
Node would likely (but not necessarily) use this value.
This attribute is required during initial registration of the Network
Entity.
6.2.3. Management IP Address
This field contains the IP Address that may be used to manage the
Network Entity and all Storage Nodes contained therein via the iSNS
MIB [iSNSMIB]. Some implementations may also use this IP address to
support vendor-specific proprietary management protocols. The
Management IP Address is a 16-byte field that may contain an IPv4 or
IPv6 address. When this field contains an IPv4 value, it is stored
as an IPv4-mapped IPv6 address. That is, the most significant 10
bytes are set to 0x00, with the next two bytes set to 0xFFFF
[RFC2373]. When this field contains an IPv6 value, the entire 16-
byte field is used. If this field is not set, then in-band
management through the IP address of one of the Portals of the
Network Entity is assumed.
6.2.4. Entity Registration Timestamp
This field indicates the most recent time when the Network Entity
registration occurred or when an associated object attribute was
updated or queried by the iSNS client registering the Network Entity.
The time format is, in seconds, the update period since the standard
base time of 00:00:00 GMT on January 1, 1970. This field cannot be
explicitly registered. This timestamp TLV format is also used in the
SCN and ESI messages.
6.2.5. Protocol Version Range
This field contains the minimum and maximum version of the block
storage protocol supported by the Network Entity. The most
significant two bytes contain the maximum version supported, and the
least significant two bytes contain the minimum version supported.
If a range is not registered, then the Network Entity is assumed to
support all versions of the protocol. The value 0xffff is a wildcard that indicates no minimum or maximum. If the Network Entity does not support a protocol, then this field SHALL be set to 0.6.2.6. Registration Period
This 4-byte unsigned integer field indicates the maximum period, in seconds, that the registration SHALL be maintained by the server without receipt of an iSNS message from the iSNS client that registered the Network Entity. Entities that are not registered for ESI monitoring MUST have a non-zero Registration Period. If a Registration Period is not requested by the iSNS client and Entity Status Inquiry (ESI) messages are not enabled for that client, then the Registration Period SHALL be set to a non-zero value by the iSNS server. This implementation-specific value for the Registration Period SHALL be returned in the registration response to the iSNS client. The Registration Period may be set to zero, indicating its non-use, only if ESI messages are enabled for that Network Entity. The registration SHALL be removed from the iSNS database if an iSNS Protocol message is not received from the iSNS client before the registration period has expired. Receipt of any iSNS Protocol message from the iSNS client automatically refreshes the Entity Registration Period and Entity Registration Timestamp. To prevent a registration from expiring, the iSNS client should send an iSNS Protocol message to the iSNS server at intervals shorter than the registration period. Such a message can be as simple as a query for one of its own attributes, using its associated iSCSI Name or FC Port Name WWPN as the Source attribute. For an iSNS client that is supporting a Network Entity with multiple Storage Node objects, receipt of an iSNS message from any Storage Node of that Network Entity is sufficient to refresh the registration for all Storage Node objects of the Network Entity. If ESI support is requested as part of a Portal registration, the ESI Response message received from the iSNS client by the iSNS server SHALL refresh the registration.6.2.7. Entity Index
The Entity Index is an unsigned non-zero integer value that uniquely identifies each Network Entity registered in the iSNS server. Upon initial registration of a Network Entity, the iSNS server assigns an unused value for the Entity Index. Each Network Entity in the iSNS database MUST be assigned a value for the Entity Index that is not
assigned to any other Network Entity. Furthermore, Entity Index values for recently deregistered Network Entities SHOULD NOT be reused in the short term. The Entity Index MAY be used to represent the Network Entity in situations when the Entity Identifier is too long or otherwise inappropriate. An example of this is when SNMP is used for management, as described in Section 2.10.6.2.8. Entity Next Index
This is a virtual attribute containing a 4-byte integer value that indicates the next available (i.e., unused) Entity Index value. This attribute may only be queried; the iSNS server SHALL return an error code of 3 (Invalid Registration) to any client that attempts to register a value for this attribute. A Message Key is not required when exclusively querying for this attribute. The Entity Next Index MAY be used by an SNMP client to create an entry in the iSNS server. SNMP requirements are described in Section 2.10.6.2.9. Entity ISAKMP Phase-1 Proposals
This field contains the IKE Phase-1 proposal, listing in decreasing order of preference the protection suites acceptable to protect all IKE Phase-2 messages sent and received by the Network Entity. This includes Phase-2 SAs from the iSNS client to the iSNS server as well as to peer iFCP and/or iSCSI devices. This attribute contains the SA payload, proposal payload(s), and transform payload(s) in the ISAKMP format defined in [RFC2408]. This field should be used if the implementer wishes to define a single phase-1 SA security configuration used to protect all phase-2 IKE traffic. If the implementer desires to have a different phase-1 SA security configuration to protect each Portal interface, then the Portal Phase-1 Proposal (Section 6.3.10) should be used.6.2.10. Entity Certificate
This attribute contains one or more X.509 certificates that are bound to the Network Entity. This certificate is uploaded and registered to the iSNS server by clients wishing to allow other clients to authenticate themselves and to access the services offered by that Network Entity. The format of the X.509 certificate is found in [RFC3280]. This certificate MUST contain a Subject Name with an empty sequence and MUST contain a SubjectAltName extension encoded
with the dNSName type. The Entity Identifier (Section 6.2.1) of the identified Entity MUST be stored in the SubjectAltName field of the certificate.6.3. Portal-Keyed Attributes
The following Portal attributes are registered in the iSNS database using the combined Portal IP-Address and Portal TCP/UDP Port as the key. Each Portal is associated with one Entity Identifier object key.6.3.1. Portal IP Address
This attribute is the IP address of the Portal through which a Storage Node can transmit and receive storage data. The Portal IP Address is a 16-byte field that may contain an IPv4 or IPv6 address. When this field contains an IPv4 address, it is stored as an IPv4- mapped IPv6 address. That is, the most significant 10 bytes are set to 0x00, with the next 2 bytes set to 0xFFFF [RFC2373]. When this field contains an IPv6 address, the entire 16-byte field is used. The Portal IP Address and the Portal TCP/UDP Port number (see 6.3.2 below) are used as a key to identify a Portal uniquely. It is a required attribute for registration of a Portal.6.3.2. Portal TCP/UDP Port
The TCP/UDP port of the Portal through which a Storage Node can transmit and receive storage data. Bits 16 to 31 represents the TCP/UDP port number. Bit 15 represents the port type. If bit 15 is set, then the port type is UDP. Otherwise it is TCP. Bits 0 to 14 are reserved. If the field value is 0, then the port number is the implied canonical port number and type of the protocol indicated by the associated Entity Type. The Portal IP Address and the Portal TCP/UDP Port number are used as a key to identify a Portal uniquely. It is a required attribute for registration of a Portal.6.3.3. Portal Symbolic Name
A variable-length UTF-8 encoded NULL-terminated text-based description of up to 256 bytes. The Portal Symbolic Name is a user- readable description of the Portal entry in the iSNS server.
6.3.4. Entity Status Inquiry Interval
This field indicates the requested time, in seconds, between Entity Status Inquiry (ESI) messages sent from the iSNS server to this Network Entity. ESI messages can be used to verify that a Portal registration continues to be valid. To request monitoring by the iSNS server, an iSNS client registers a non-zero value for this Portal attribute using a DevAttrReg message. The client MUST register an ESI Port on at least one of its Portals to receive the ESI monitoring. If the iSNS server does not receive an expected response to an ESI message, it SHALL attempt an administratively configured number of re-transmissions of the ESI message. The ESI Interval period begins with the iSNS server's receipt of the last ESI Response. All re- transmissions MUST be sent before twice the ESI Interval period has passed. If no response is received from any of the ESI messages, then the Portal SHALL be deregistered. Note that only Portals that have registered a value in their ESI Port field can be deregistered in this way. If all Portals associated with a Network Entity that have registered for ESI messages are deregistered due to non-response, and if no registrations have been received from the client for at least two ESI Interval periods, then the Network Entity and all associated objects (including Storage Nodes) SHALL be deregistered. If the iSNS server is unable to support ESI messages or the ESI Interval requested, it SHALL either reject the ESI request by returning an "ESI Not Available" Status Code or modify the ESI Interval attribute by selecting its own suitable value and returning that value in the Operating Attributes of the registration response message. If at any time an iSNS client that is registered for ESI messages has not received an ESI message to any of its Portals as expected, then the client MAY attempt to query the iSNS server using a DevAttrQry message using its Entity_ID as the key. If the query result is the error "no such entry", then the client SHALL close all remaining TCP connections to the iSNS server and assume that it is no longer registered in the iSNS database. Such a client MAY attempt re- registration.
6.3.5. ESI Port
This field contains the TCP or UDP port used for ESI monitoring by the iSNS server at the Portal IP Address. Bits 16 to 31 represent the port number. If bit 15 is set, then the port type is UDP. Otherwise, the port is TCP. Bits 0 to 14 are reserved. If the iSNS client registers a valid TCP or UDP port number in this field, then the client SHALL allow ESI messages to be received at the indicated TCP or UDP port. If a TCP port is registered and a pre- existing TCP connection from that TCP port to the iSNS server does not already exist, then the iSNS client SHALL accept new TCP connections from the iSNS server at the indicated TCP port. The iSNS server SHALL return an error if a Network Entity is registered for ESI monitoring and none of the Portals of that Network Entity has an entry for the ESI Port field. If multiple Portals have a registered ESI port, then the ESI message may be delivered to any one of the indicated Portals.6.3.6. Portal Index
The Portal Index is a 4-byte non-zero integer value that uniquely identifies each Portal registered in the iSNS database. Upon initial registration of a Portal, the iSNS server assigns an unused value for the Portal Index of that Portal. Each Portal in the iSNS database MUST be assigned a value for the Portal Index that is not assigned to any other Portal. Furthermore, Portal Index values for recently deregistered Portals SHOULD NOT be reused in the short term. The Portal Index MAY be used to represent a registered Portal in situations where the Portal IP-Address and Portal TCP/UDP Port is unwieldy to use. An example of this is when SNMP is used for management, as described in Section 2.10.6.3.7. SCN Port
This field contains the TCP or UDP port used by the iSNS client to receive SCN messages from the iSNS server. When a value is registered for this attribute, an SCN message may be received on the indicated port for any of the Storage Nodes supported by the Portal. Bits 16 to 31 contain the port number. If bit 15 is set, then the port type is UDP. Otherwise, the port type is TCP. Bits 0 to 14 are reserved. If the iSNS client registers a valid TCP or UDP port number in this field, then the client SHALL allow SCN messages to be received at the indicated TCP or UDP port. If a TCP port is registered and a pre-
existing TCP connection from that TCP port to the iSNS server does not already exist, then the iSNS client SHALL accept new TCP connections from the iSNS server at the indicated TCP port. The iSNS server SHALL return an error if an SCN registration message is received and none of the Portals of the Network Entity has an entry for the SCN Port. If multiple Portals have a registered SCN Port, then the SCN SHALL be delivered to any one of the indicated Portals of that Network Entity.6.3.8. Portal Next Index
This is a virtual attribute containing a 4-byte integer value that indicates the next available (i.e., unused) Portal Index value. This attribute may only be queried; the iSNS server SHALL return an error code of 3 (Invalid Registration) to any client that attempts to register a value for this attribute. A Message Key is not required when exclusively querying for this attribute. The Portal Next Index MAY be used by an SNMP client to create an entry in the iSNS server. SNMP requirements are described in Section 2.10.6.3.9. Portal Security Bitmap
This 4-byte field contains flags that indicate security attribute settings for the Portal. Bit 31 (Lsb) of this field must be 1 (enabled) for this field to contain significant information. If Bit 31 is enabled, this signifies that the iSNS server can be used to store and distribute security policies and settings for iSNS clients (i.e., iSCSI devices). Bit 30 must be 1 for bits 25-29 to contain significant information. All other bits are reserved for non- IKE/IPSec security mechanisms to be specified in the future. Bit Position Flag Description ------------ ---------------- 25 1 = Tunnel Mode Preferred; 0 = No Preference 26 1 = Transport Mode Preferred; 0 = No Preference 27 1 = Perfect Forward Secrecy (PFS) Enabled; 0 = PFS Disabled 28 1 = Aggressive Mode Enabled; 0 = Disabled 29 1 = Main Mode Enabled; 0 = MM Disabled 30 1 = IKE/IPSec Enabled; 0 = IKE/IPSec Disabled 31 (Lsb) 1 = Bitmap VALID; 0 = INVALID All others RESERVED
6.3.10. Portal ISAKMP Phase-1 Proposals
This field contains the IKE Phase-1 proposal listing in decreasing order of preference of the protection suites acceptable to protect all IKE Phase-2 messages sent and received by the Portal. This includes Phase-2 SAs from the iSNS client to the iSNS server as well as to peer iFCP and/or iSCSI devices. This attribute contains the SA payload, proposal payload(s), and transform payload(s) in the ISAKMP format defined in [RFC2408]. This field should be used if the implementer wishes to define phase-1 SA security configuration on a per-Portal basis, as opposed to on a per-Network Entity basis. If the implementer desires to have a single phase-1 SA security configuration to protect all phase-2 traffic regardless of the interface used, then the Entity Phase-1 Proposal (Section 6.2.9) should be used.6.3.11. Portal ISAKMP Phase-2 Proposals
This field contains the IKE Phase-2 proposal, in ISAKMP format [RFC2408], listing in decreasing order of preference the security proposals acceptable to protect traffic sent and received by the Portal. This field is used only if bits 31, 30, and 29 of the Security Bitmap (see 6.3.9) are enabled. This attribute contains the SA payload, proposal payload(s), and associated transform payload(s) in the ISAKMP format defined in [RFC2408].6.3.12. Portal Certificate
This attribute contains one or more X.509 certificates that are a credential of the Portal. This certificate is used to identify and authenticate communications to the IP address and TCP/UDP Port supported by the Portal. The format of the X.509 certificate is specified in [RFC3280]. This certificate MUST contain a Subject Name with an empty sequence and MUST contain a SubjectAltName extension encoded with the iPAddress type. The Portal IP Address (Section 6.3.1) of the identified Portal SHALL be stored in the SubjectAltName field of the certificate.6.4. iSCSI Node-Keyed Attributes
The following attributes are stored in the iSNS database using the iSCSI Name attribute as the key. Each set of Node-Keyed attributes is associated with one Entity Identifier object key. Although the iSCSI Name key is associated with one Entity Identifier, it is unique across the entire iSNS database.
6.4.1. iSCSI Name
This is a variable-length UTF-8 encoded NULL-terminated text-based description of up to 224 bytes. This key attribute is required for iSCSI Storage Nodes and is provided by the iSNS client. The registered iSCSI Name MUST conform to the format described in [iSCSI] for iSCSI Names. The maximum size for an iSCSI Name is 223 bytes. Including the NULL character and 4-byte alignment (see Section 5.3.1), the maximum iSCSI Name field size is 224 bytes. If an iSCSI Name is registered without an EID key, then a Network Entity SHALL be created and an EID assigned. The assigned EID SHALL be returned in the registration response as an operating attribute. This field MUST be normalized according to the stringprep template [STRINGPREP] before it is stored in the iSNS database.6.4.2. iSCSI Node Type
This required 32-bit field is a bitmap indicating the type of iSCSI Storage Node. The bit positions are defined below. A set bit (1) indicates that the Node has the corresponding characteristics. Bit Position Node Type ------------ --------- 29 Control 30 Initiator 31 (Lsb) Target All others RESERVED If the Target bit is set to 1, then the Node represents an iSCSI target. The Target bit MAY be set by iSNS clients using the iSNSP. If the Initiator bit is set to 1, then the Node represents an iSCSI initiator. The Initiator bit MAY be set by iSNS clients using the iSNSP. If the control bit is set to 1, then the Node represents a gateway, a management station, a backup iSNS server, or another device that is not an initiator or target, but that requires the ability to send and receive iSNSP messages, including state change notifications. Setting the control bit is an administrative task that MUST be performed on the iSNS server; iSNS clients SHALL NOT be allowed to change this bit using the iSNSP.
This field MAY be used by the iSNS server to distinguish among permissions by different iSCSI Node types for accessing various iSNS functions. More than one Node Type bit may be simultaneously enabled.6.4.3. iSCSI Node Alias
This is a variable-length UTF-8 encoded NULL-terminated text-based description of up to 256 bytes. The Alias is a user-readable description of the Node entry in the iSNS database.6.4.4. iSCSI Node SCN Bitmap
The iSCSI Node SCN Bitmap indicates events for which the registering iSNS client wishes to receive a notification message. The following table displays events that result in notifications, and the bit field in the SCN Bitmap that, when enabled, results in the corresponding notification. Note that this field is of dual use: it is used in the SCN registration process to define interested events that will trigger an SCN message, and it is also contained in each SCN message itself, to indicate the type of event that triggered the SCN message. A set bit (1) indicates the corresponding type of SCN. Bit Position Flag Description ------------ ---------------- 24 INITIATOR AND SELF INFORMATION ONLY 25 TARGET AND SELF INFORMATION ONLY 26 MANAGEMENT REGISTRATION/SCN 27 OBJECT REMOVED 28 OBJECT ADDED 29 OBJECT UPDATED 30 DD/DDS MEMBER REMOVED (Mgmt Reg/SCN only) 31 (Lsb) DD/DDS MEMBER ADDED (Mgmt Reg/SCN only) All others RESERVED DD/DDS MEMBER REMOVED indicates that an existing member of a Discovery Domain and/or Discovery Domain Set has been removed. DD/DDS MEMBER ADDED indicates that a new member was added to an existing DD and/or DDS. OBJECT REMOVED, OBJECT ADDED, and OBJECT UPDATED indicate a Network Entity, Portal, Storage Node, FC Device, DD, and/or DDS object was removed from, added to, or updated in the Discovery Domain or in the iSNS database (Control Nodes only).
Regular SCNs provide information about objects that are updated in, added to or removed from Discovery Domains of which the Storage Node is a member. An SCN or SCN registration is considered a regular SCN or regular SCN registration if the MANAGEMENT REGISTRATION/SCN flag is cleared. All iSNS clients may register for regular SCNs. Management SCNs provide information about all changes to the network, regardless of discovery domain membership. Registration for management SCNs is indicated by setting bit 26 to 1. Only Control Nodes may register for management SCNs. Bits 30 and 31 may only be enabled if bit 26 is set to 1. TARGET AND SELF INFORMATION ONLY SCNs (bit 25) provides information only about changes to target devices, or if the iSCSI Storage Node itself has undergone a change. Similarly, INITIATOR AND SELF INFORMATION ONLY SCNs (bit 24) provides information only about changes to initiator Nodes, or to the target itself.6.4.5. iSCSI Node Index
The iSCSI Node Index is a 4-byte non-zero integer value used as a key that uniquely identifies each iSCSI Storage Node registered in the iSNS database. Upon initial registration of the iSCSI Storage Node, the iSNS server assigns an unused value for the iSCSI Node Index. Each iSCSI Node MUST be assigned a value for the iSCSI Node Index that is not assigned to any other iSCSI Storage Node. Furthermore, iSCSI Node Index values for recently deregistered iSCSI Storage Nodes SHOULD NOT be reused in the short term. The iSCSI Node Index may be used as a key to represent a registered Node in situations where the iSCSI Name is too long to be used as a key. An example of this is when SNMP is used for management, as described in Section 2.10. The value assigned for the iSCSI Node Index SHALL persist as long as the iSCSI Storage Node is registered in the iSNS database or a member of a Discovery Domain. An iSCSI Node Index value that is assigned for a Storage Node SHALL NOT be used for any other Storage Node as long as the original node is registered in the iSNS database or a member of a Discovery Domain.6.4.6. WWNN Token
This field contains a globally unique 64-bit integer value that can be used to represent the World Wide Node Name of the iSCSI device in a Fibre Channel fabric. This identifier is used during the device registration process and MUST conform to the requirements in [FC-FS].
The FC-iSCSI gateway uses the value found in this field to register
the iSCSI device in the Fibre Channel name server. It is stored in
the iSNS server to prevent conflict when "proxy" WWNN values are
assigned to iSCSI initiators establishing storage sessions to devices
in the FC fabric.
If the iSNS client does not assign a value for WWNN Token, then the
iSNS server SHALL provide a value for this field upon initial
registration of the iSCSI Storage Node. The process by which the
WWNN Token is assigned by the iSNS server MUST conform to the
following requirements:
1. The assigned WWNN Token value MUST be unique among all WWN
entries in the existing iSNS database, and among all devices that
can potentially be registered in the iSNS database.
2. Once the value is assigned, the iSNS server MUST persistently
save the mapping between the WWNN Token value and registered
iSCSI Name. That is, successive re-registrations of the iSCSI
Storage Node keyed by the same iSCSI Name maintain the original
mapping to the associated WWNN Token value in the iSNS server.
Similarly, the mapping SHALL be persistent across iSNS server
reboots. Once assigned, the mapping can only be changed if a
DevAttrReg message from an authorized iSNS client explicitly
provides a different WWNN Token value.
3. Once a WWNN Token value has been assigned and mapped to an iSCSI
name, that WWNN Token value SHALL NOT be reused or mapped to any
other iSCSI name.
4. The assigned WWNN Token value MUST conform to the formatting
requirements of [FC-FS] for World Wide Names (WWNs).
An iSNS client, such as an FC-iSCSI gateway or the iSCSI initiator,
MAY register its own WWNN Token value or overwrite the iSNS Server-
supplied WWNN Token value, if it wishes to supply its own iSCSI-FC
name mapping. This is accomplished using the DevAttrReg message with
the WWNN Token (tag=37) as an operating attribute. Once overwritten,
the new WWNN Token value MUST be stored and saved by the iSNS server,
and all requirements specified above continue to apply. If an iSNS
client attempts to register a value for this field that is not unique
in the iSNS database or that is otherwise invalid, then the
registration SHALL be rejected with an Status Code of 3 (Invalid
Registration).
There MAY be matching records in the iSNS database for the Fibre Channel device specified by the WWNN Token. These records may contain device attributes for that FC device registered in the Fibre Channel fabric name server.6.4.7. iSCSI Node Next Index
This is a virtual attribute containing a 4-byte integer value that indicates the next available (i.e., unused) iSCSI Node Index value. This attribute may only be queried; the iSNS server SHALL return an error code of 3 (Invalid Registration) to any client that attempts to register a value for this attribute. A Message Key is not required when exclusively querying for this attribute. The iSCSI Node Next Index MAY be used by an SNMP client to create an entry in the iSNS server. SNMP requirements are described in Section 2.10.6.4.8. iSCSI AuthMethod
This attribute contains a NULL-terminated string of UTF-8 text listing the iSCSI authentication methods enabled for this iSCSI Storage Node, in order of preference. The text values used to identify iSCSI authentication methods are embedded in this string attribute and delineated by a comma. The text values are identical to those found in the main iSCSI document [iSCSI]; additional vendor-specific text values are also possible. Text Value Description Reference ---------- ----------- --------- KB5 Kerberos V5 [RFC1510] SPKM1 Simple Public Key GSS-API [RFC2025] SPKM2 Simple Public Key GSS-API [RFC2025] SRP Secure Remote Password [RFC2945] CHAP Challenge Handshake Protocol [RFC1994] none No iSCSI Authentication6.5. Portal Group (PG) Object-Keyed Attributes
The following attributes are used to associate Portal and iSCSI Storage Node objects. PG objects are stored in the iSNS database using the PG iSCSI Name, the PG Portal IP Address, and the PG Portal TCP/UDP Port as keys. New PG objects are implicitly or explicitly created at the time that the corresponding Portal and/or iSCSI Storage Node objects are registered. Section 3.4 has a general discussion of PG usage. For further details on use of Portal Groups, see [iSCSI].
6.5.1. Portal Group iSCSI Name
This is the iSCSI Name for the iSCSI Storage Node that is associated with the PG object. This name MAY represent an iSCSI Storage Node not currently registered in the server.6.5.2. PG Portal IP Addr
This is the Portal IP Address attribute for the Portal that is associated with the PG object. This Portal IP Address MAY be that of a Portal that is not currently registered in the server.6.5.3. PG Portal TCP/UDP Port
This is the Portal TCP/UDP Port attribute for the Portal that is associated with the PG object. This Portal TCP/UDP Port MAY be that of a Portal that is not currently registered in the server.6.5.4. Portal Group Tag (PGT)
This field is used to group Portals in order to coordinate connections in a session across Portals to a specified iSCSI Node. The PGT is a value in the range of 0-65535, or NULL. A NULL PGT value is registered by using 0 for the length in the TLV during registration. The two least significant bytes of the value contain the PGT for the object. The two most significant bytes are reserved. If a PGT value is not explicitly registered for an iSCSI Storage Node and Portal pair, then the PGT value SHALL be implicitly registered as 0x00000001.6.5.5. Portal Group Index
The PG Index is a 4-byte non-zero integer value used as a key that uniquely identifies each PG object registered in the iSNS database. Upon initial registration of a PG object, the iSNS server MUST assign an unused value for the PG Index. Furthermore, PG Index values for recently deregistered PG objects SHOULD NOT be reused in the short term. The PG Index MAY be used as the key to reference a registered PG in situations where a unique index for each PG object is required. It MAY also be used as the message key in an iSNS message to query or update a pre-existing PG object. An example of this is when SNMP is used for management, as described in Section 2.10. The value assigned for the PG Index SHALL persist as long as the server is active.
6.5.6. Portal Group Next Index
The PG Next Index is a virtual attribute containing a 4-byte integer value that indicates the next available (i.e., unused) PG Index value. This attribute may only be queried; the iSNS server SHALL return an error code of 3 (Invalid Registration) to any client that attempts to register a value for this attribute. A Message Key is not required when exclusively querying for this attribute. The Portal Group Next Index MAY be used by an SNMP client to create an entry in the iSNS server. SNMP requirements are described in Section 2.10.6.6. FC Port Name-Keyed Attributes
The following attributes are registered in the iSNS database using the FC Port World Wide Name (WWPN) attribute as the key. Each set of FC Port-Keyed attributes is associated with one Entity Identifier object key. Although the FC Port World Wide Name is associated with one Entity Identifier, it is also globally unique.6.6.1. FC Port Name (WWPN)
This 64-bit identifier uniquely defines the FC Port, and it is the World Wide Port Name (WWPN) of the corresponding Fibre Channel device. This attribute is the key for the iFCP Storage Node. This globally unique identifier is used during the device registration process, and it uses a value conforming to IEEE EUI-64 [EUI-64].6.6.2. Port ID (FC_ID)
The Port Identifier is a Fibre Channel address identifier assigned to an N_Port or NL_Port during fabric login. The format of the Port Identifier is defined in [FC-FS]. The least significant 3 bytes contain this address identifier. The most significant byte is RESERVED.
6.6.3. FC Port Type
Indicates the type of FC port. Encoded values for this field are listed in the following table: Type Description ---- ----------- 0x0000 Unidentified/Null Entry 0x0001 Fibre Channel N_Port 0x0002 Fibre Channel NL_Port 0x0003 Fibre Channel F/NL_Port 0x0004-0080 RESERVED 0x0081 Fibre Channel F_Port 0x0082 Fibre Channel FL_Port 0x0083 RESERVED 0x0084 Fibre Channel E_Port 0x0085-00FF RESERVED 0xFF11 RESERVED 0xFF12 iFCP Port 0xFF13-FFFF RESERVED6.6.4. Symbolic Port Name
This is a variable-length UTF-8 encoded NULL-terminated text-based description of up to 256 bytes that is associated with the iSNS- registered FC Port Name in the network.6.6.5. Fabric Port Name (FWWN)
This 64-bit identifier uniquely defines the fabric port. If the port of the FC Device is attached to a Fibre Channel fabric port with a registered Port Name, then that fabric Port Name SHALL be indicated in this field.6.6.6. Hard Address
This field is the requested hard address 24-bit NL Port Identifier, included in the iSNSP for compatibility with Fibre Channel Arbitrated Loop devices and topologies. The least significant 3 bytes of this field contain the address. The most significant byte is RESERVED.6.6.7. Port IP Address
The Fibre Channel IP address associated with the FC Port. When this field contains an IPv4 value, it is stored as an IPv4-mapped IPv6 address. That is, the most significant 10 bytes are set to 0x00, with the next two bytes set to 0xFFFF [RFC2373]. When an IPv6 value is contained in this field, then the entire 16-byte field is used.
6.6.8. Class of Service (COS)
This 32-bit bit-map field indicates the Fibre Channel Class of Service types that are supported by the registered port. In the following table, a set bit (1) indicates a Class of Service supported. Bit Position Description ------------ ----------- 29 Fibre Channel Class 2 Supported 28 Fibre Channel Class 3 Supported6.6.9. FC-4 Types
This 32-byte field indicates the FC-4 protocol types supported by the associated port. This field can be used to support Fibre Channel devices and is consistent with FC-GS-4.6.6.10. FC-4 Descriptor
This is a variable-length UTF-8 encoded NULL-terminated text-based description of up to 256 bytes that is associated with the iSNS- registered device port in the network. This field can be used to support Fibre Channel devices and is consistent with FC-GS-4.6.6.11. FC-4 Features
This is a 128-byte array, 4 bits per type, for the FC-4 protocol types supported by the associated port. This field can be used to support Fibre Channel devices and is consistent with FC-GS-4.6.6.12. iFCP SCN Bitmap
This field indicates the events the iSNS client is interested in. These events can cause SCNs to be generated. SCNs provide information about objects that are updated in, added to or removed from Discovery Domains of which the source and destination are a member. Management SCNs provide information about all changes to the network. A set bit (1) indicates the type of SCN for the bitmap as follows:
Bit Position Flag Description
------------ ----------------
24 INITIATOR AND SELF INFORMATION ONLY
25 TARGET AND SELF INFORMATION ONLY
26 MANAGEMENT REGISTRATION/SCN
27 OBJECT REMOVED
28 OBJECT ADDED
29 OBJECT UPDATED
30 DD/DDS MEMBER REMOVED (Mgmt Reg/SCN only)
31 (Lsb) DD/DDS MEMBER ADDED (Mgmt Reg/SCN only)
All others RESERVED
Further information on the use of the bit positions specified above
can be found in Section 6.4.4.
6.6.13. Port Role
This required 32-bit field is a bitmap indicating the type of iFCP
Storage Node. The bit fields are defined below. A set bit indicates
the Node has the corresponding characteristics.
Bit Position Node Type
------------ ---------
29 Control
30 FCP Initiator
31 (Lsb) FCP Target
All Others RESERVED
If the 'Target' bit is set to 1, then the port represents an FC
target. Setting of the 'Target' bit MAY be performed by iSNS clients
using the iSNSP.
If the 'Initiator' bit is set to 1, then the port represents an FC
initiator. Setting of the 'Initiator' bit MAY be performed by iSNS
clients using the iSNSP.
If the 'Control' bit is set to 1, then the port represents a gateway,
a management station, an iSNS backup server, or another device.
This is usually a special device that is neither an initiator nor a
target, which requires the ability to send and receive iSNSP
messages, including state-change notifications. Setting the control
bit is an administrative task that MUST be administratively
configured on the iSNS server; iSNS clients SHALL NOT be allowed to
change this bit using the iSNSP.
This field MAY be used by the iSNS server to distinguish among permissions by different iSNS clients. For example, an iSNS server implementation may be administratively configured to allow only targets to receive ESIs, or to permit only Control Nodes to add, modify, or delete discovery domains.6.6.14. Permanent Port Name (PPN)
The Permanent Port Name can be used to support Fibre Channel devices and is consistent with the PPN description in FC-GS-4 [FC-GS-4]. The format of the PPN is identical to the FC Port Name WWPN attribute format.6.7. Node-Keyed Attributes
The following attributes are registered in the iSNS database using the FC Node Name (WWNN) attribute as the key. Each set of FC Node- Keyed attributes represents a single device and can be associated with many FC Ports. The FC Node Name is unique across the entire iSNS database.6.7.1. FC Node Name (WWNN)
The FC Node Name is a 64-bit identifier that is the World Wide Node Name (WWNN) of the corresponding Fibre Channel device. This attribute is the key for the FC Device. This globally unique identifier is used during the device registration process, and it uses a value conforming to IEEE EUI-64 [EUI-64].6.7.2. Symbolic Node Name
This is a variable-length UTF-8 encoded NULL-terminated text-based description of up to 256 bytes that is associated with the iSNS- registered FC Device in the network.6.7.3. Node IP Address
This IP address is associated with the device Node in the network. This field is included for compatibility with Fibre Channel. When this field contains an IPv4 value, it is stored as an IPv4-mapped IPv6 address. That is, the most significant 10 bytes are set to 0x00, with the next two bytes set to 0xFFFF [RFC2373]. When an IPv6 value is contained in this field, the entire 16-byte field is used.
6.7.4. Node IPA
This field is the 8-byte Fibre Channel Initial Process Associator (IPA) associated with the device Node in the network. The initial process associator is used for communication between Fibre Channel devices.6.7.5. Proxy iSCSI Name
This is a variable-length UTF-8 encoded NULL-terminated text-based field that contains the iSCSI Name used to represent the FC Node in the IP network. It is used as a pointer to the matching iSCSI Name entry in the iSNS server. Its value is usually registered by an FC- iSCSI gateway connecting the IP network to the fabric containing the FC device. Note that if this field is used, there SHOULD be a matching entry in the iSNS database for the iSCSI device specified by the iSCSI name. The database entry should include the full range of iSCSI attributes needed for discovery and management of the "iSCSI proxy image" of the FC device.6.8. Other Attributes
The following are not attributes of the previously-defined objects.6.8.1. FC-4 Type Code
This is a 4-byte field used to provide a FC-4 type during a FC-4 Type query. The FC-4 types are consistent with the FC-4 Types as defined in FC-FS. Byte 0 contains the FC-4 type. All other bytes are reserved.6.8.2. iFCP Switch Name
The iFCP Switch Name is a 64-bit World Wide Name (WWN) identifier that uniquely identifies a distinct iFCP gateway in the network. This globally unique identifier is used during the switch registration/FC_DOMAIN_ID assignment process. The iFCP Switch Name value used MUST conform to the requirements stated in [FC-FS] for World Wide Names. The iSNS server SHALL track the state of all FC_DOMAIN_ID values that have been allocated to each iFCP Switch Name. If a given iFCP Switch Name is deregistered from the iSNS database, then all FC_DOMAIN_ID values allocated to that iFCP Switch Name SHALL be returned to the unused pool of values.
6.8.3. iFCP Transparent Mode Commands
6.8.3.1. Preferred ID
This is a 4-byte unsigned integer field, and it is the requested value that the iSNS client wishes to use for the FC_DOMAIN_ID. The iSNS server SHALL grant the iSNS client the use of the requested value as the FC_DOMAIN_ID, if the requested value has not already been allocated. If the requested value is not available, the iSNS server SHALL return a different value that has not been allocated.6.8.3.2. Assigned ID
This is a 4-byte unsigned integer field that is used by an iFCP gateway to reserve its own unique FC_DOMAIN_ID value from the range 1 to 239. When a FC_DOMAIN_ID is no longer required, it SHALL be released by the iFCP gateway using the RlseDomId message. The iSNS server MUST use the Entity Status Inquiry message to determine whether an iFCP gateway is still present on the network.6.8.3.3. Virtual_Fabric_ID
This is a variable-length UTF-8 encoded NULL-terminated text-based field of up to 256 bytes. The Virtual_Fabric_ID string is used as a key attribute to identify a range of non-overlapping FC_DOMAIN_ID values to be allocated using RqstDomId. Each Virtual_Fabric_ID string submitted by an iSNS client SHALL have its own range of non- overlapping FC_DOMAIN_ID values to be allocated to iSNS clients.6.9. iSNS Server-Specific Attributes
Access to the following attributes may be administratively controlled. These attributes are specific to the iSNS server instance; the same value is returned for all iSNS clients accessing the iSNS server. Only query messages may be performed on these attributes. Attempted registrations of values for these attributes SHALL return a status code of 3 (Invalid Registration). A query for an iSNS Server-Specific attribute MUST contain the identifying key attribute (i.e., iSCSI Name or FC Port Name WWPN) of the Node originating the registration or query message as the Source and Message Key attributes. The Operating Attributes are the server-specific attributes being registered or queried.
6.9.1. iSNS Server Vendor OUI
This attribute is the OUI (Organizationally Unique Identifier) [802-1990] identifying the specific vendor implementing the iSNS server. This attribute can only be queried; iSNS clients SHALL NOT be allowed to register a value for the iSNS Server Vendor OUI.6.10. Vendor-Specific Attributes
iSNS server implementations MAY define vendor-specific attributes for private use. These attributes MAY be used to store optional data that is registered and/or queried by iSNS clients in order to gain optional capabilities. Note that any implementation of vendor- specific attributes in the iSNS server SHALL NOT impose any form of mandatory behavior on the part of the iSNS client. The tag values used for vendor-specific and user-specific use are defined in Section 6.1. To avoid misinterpreting proprietary attributes, the vendor's own OUI (Organizationally Unique Identifier) MUST be placed in the upper three bytes of the attribute value field itself. The OUI is defined in IEEE Std 802-1990 and is the same constant used to generate 48 bit Universal LAN MAC addresses. A vendor's own iSNS implementation will then be able to recognize the OUI in the attribute field and be able to execute vendor-specific handling of the attribute.6.10.1. Vendor-Specific Server Attributes
Attributes with tags in the range 257 to 384 are vendor-specific or site-specific attributes of the iSNS server. Values for these attributes are administratively set by the specific vendor providing the iSNS server implementation. Query access to these attributes may be administratively controlled. These attributes are unique for each logical iSNS server instance. Query messages for these attributes SHALL use the key identifier (i.e., iSCSI Name or FC Port Name WWPN) for both the Source attribute and Message Key attribute. These attributes can only be queried; iSNS clients SHALL NOT be allowed to register a value for server attributes.6.10.2. Vendor-Specific Entity Attributes
Attributes in the range 385 to 512 are vendor-specific or site- specific attributes used to describe the Network Entity object. These attributes are keyed by the Entity Identifier attribute (tag=1).
6.10.3. Vendor-Specific Portal Attributes
Attributes in the range 513 to 640 are vendor-specific or site- specific attributes used to describe the Portal object. These attributes are keyed by the Portal IP-Address (tag=16) and Portal TCP/UDP Port (tag=17).6.10.4. Vendor-Specific iSCSI Node Attributes
Attributes in the range 641 to 768 are vendor-specific or site- specific attributes used to describe the iSCSI Node object. These attributes are keyed by the iSCSI Name (tag=32).6.10.5. Vendor-Specific FC Port Name Attributes
Attributes in the range 769 to 896 are vendor-specific or site- specific attributes used to describe the N_Port Port Name object. These attributes are keyed by the FC Port Name WWPN (tag=64).6.10.6. Vendor-Specific FC Node Name Attributes
Attributes in the range 897 to 1024 are vendor-specific or site- specific attributes used to describe the FC Node Name object. These attributes are keyed by the FC Node Name WWNN (tag=96).6.10.7. Vendor-Specific Discovery Domain Attributes
Attributes in the range 1025 to 1280 are vendor-specific or site- specific attributes used to describe the Discovery Domain object. These attributes are keyed by the DD_ID (tag=104).6.10.8. Vendor-Specific Discovery Domain Set Attributes
Attributes in the range 1281 to 1536 are vendor-specific or site- specific attributes used to describe the Discovery Domain Set object. These attributes are keyed by the DD Set ID (tag=101)6.10.9. Other Vendor-Specific Attributes
Attributes in the range 1537 to 2048 can be used for key and non-key attributes that describe new vendor-specific objects specific to the vendor's iSNS server implementation.
6.11. Discovery Domain Registration Attributes
6.11.1. DD Set ID Keyed Attributes
6.11.1.1. Discovery Domain Set ID (DDS ID)
The DDS ID is an unsigned non-zero integer identifier used in the iSNS directory database as a key to indicate a Discovery Domain Set uniquely. A DDS is a collection of Discovery Domains that can be enabled or disabled by a management station. This value is used as a key for DDS attribute queries. When a Discovery Domain is registered, it is initially not in any DDS. If the iSNS client does not provide a DDS_ID in a DDS registration request message, the iSNS server SHALL generate a DDS_ID value that is unique within the iSNS database for that new DDS. The created DDS ID SHALL be returned in the response message. The DDS ID value of 0 is reserved, and the DDS ID value of 1 is used for the default DDS (see Section 2.2.2).6.11.1.2. Discovery Domain Set Symbolic Name
A variable-length UTF-8 encoded NULL-terminated text-based field of up to 256 bytes. This is a user-readable field used to assist a network administrator in tracking the DDS function. When a client registers a DDS symbolic name, the iSNS server SHALL verify it is unique. If the name is not unique, then the DDS registration SHALL be rejected with an "Invalid Registration" Status Code. The invalid attribute(s), in this case the DDS symbolic name, SHALL be included in the response.6.11.1.3. Discovery Domain Set Status
The DDS_Status field is a 32-bit bitmap indicating the status of the DDS. Bit 0 of the bitmap indicates whether the DDS is Enabled (1) or Disabled (0). The default value for the DDS Enabled flag is Disabled (0). Bit Position DDS Status ------------ --------- 31 (Lsb) DDS Enabled (1) / DDS Disabled (0) All others RESERVED6.11.1.4. Discovery Domain Set Next ID
This is a virtual attribute containing a 4-byte integer value that indicates the next available (i.e., unused) Discovery Domain Set Index value. This attribute may only be queried; the iSNS server
SHALL return an error code of 3 (Invalid Registration) to any client that attempts to register a value for this attribute. A Message Key is not required when exclusively querying for this attribute. The Discovery Domain Set Next Index MAY be used by an SNMP client to create an entry in the iSNS server. SNMP requirements are described in Section 2.10.6.11.2. DD ID Keyed Attributes
6.11.2.1. Discovery Domain ID (DD ID)
The DD ID is an unsigned non-zero integer identifier used in the iSNS directory database as a key to identify a Discovery Domain uniquely. This value is used as the key for any DD attribute query. If the iSNS client does not provide a DD_ID in a DD registration request message, the iSNS server SHALL generate a DD_ID value that is unique within the iSNS database for that new DD (i.e., the iSNS client will be registered in a new DD). The created DD ID SHALL be returned in the response message. The DD ID value of 0 is reserved, and the DD ID value of 1 is used for the default DD (see Section 2.2.2).6.11.2.2. Discovery Domain Symbolic Name
A variable-length UTF-8 encoded NULL-terminated text-based field of up to 256 bytes. When a client registers a DD symbolic name, the iSNS server SHALL verify it is unique. If the name is not unique, then the DD registration SHALL be rejected with an "Invalid Registration" Status Code. The invalid attribute(s), in this case the DD symbolic name, SHALL be included in the response.6.11.2.3. Discovery Domain Member: iSCSI Node Index
This is the iSCSI Node Index of a Storage Node that is a member of the DD. The DD may have a list of 0 to n members. The iSCSI Node Index is one alternative representation of membership in a Discovery Domain, the other alternative being the iSCSI Name. The Discovery Domain iSCSI Node Index is a 4-byte non-zero integer value. The iSCSI Node Index can be used to represent a DD member in situations where the iSCSI Name is too long to be used. An example of this is when SNMP is used for management, as described in Section 2.10. The iSCSI Node Index and the iSCSI Name stored as a member in a DD SHALL be consistent with the iSCSI Node Index and iSCSI Name attributes registered for the Storage Node object in the iSNS server.
6.11.2.4. Discovery Domain Member: iSCSI Name
A variable-length UTF-8 encoded NULL-terminated text-based field of up to 224 bytes. It indicates membership for the specified iSCSI Storage Node in the Discovery Domain. Note that the referenced Storage Node does not need to be actively registered in the iSNS database before the iSNS client uses this attribute. There is no limit to the number of members that may be in a DD. Membership is represented by the iSCSI Name of the iSCSI Storage Node.6.11.2.5. Discovery Domain Member: FC Port Name
This 64-bit identifier attribute indicates membership for an iFCP Storage Node (FC Port) in the Discovery Domain. Note that the referenced Storage Node does not need to be actively registered in the iSNS database before the iSNS client uses this attribute. There is no limit to the number of members that may be in a DD. Membership is represented by the FC Port Name (WWPN) of the iFCP Storage Node.6.11.2.6. Discovery Domain Member: Portal Index
This attribute indicates membership in the Discovery Domain for a Portal. It is an alternative representation for Portal membership to the Portal IP Address and Portal TCP/UDP Port. The referenced Portal MUST be actively registered in the iSNS database before the iSNS client uses this attribute.6.11.2.7. Discovery Domain Member: Portal IP Address
This attribute and the Portal TCP/UDP Port attribute indicate membership in the Discovery Domain for the specified Portal. Note that the referenced Portal does not need to be actively registered in the iSNS database before the iSNS client uses this attribute.6.11.2.8. Discovery Domain Member: Portal TCP/UDP Port
This attribute and the Portal IP Address attribute indicate membership in the Discovery Domain for the specified Portal. Note that the referenced Portal does not need to be actively registered in the iSNS database before the iSNS client uses this attribute.6.11.2.9. Discovery Domain Features
The Discovery Domain Features is a bitmap indicating the features of this DD. The bit positions are defined below. A bit set to 1 indicates the DD has the corresponding characteristics.
Bit Position DD Feature
------------ ----------
31 (Lsb) Boot List Enabled (1)/Boot List Disabled (0)
All others RESERVED
Boot List: this feature indicates that the target(s) in this DD
provides boot capabilities for the member initiators, as described in
[iSCSI-boot].
6.11.2.10. Discovery Domain Next ID
This is a virtual attribute containing a 4-byte integer value that
indicates the next available (i.e., unused) Discovery Domain Index
value. This attribute may only be queried; the iSNS server SHALL
return an error code of 3 (Invalid Registration) to any client that
attempts to register a value for this attribute. A Message Key is
not required when exclusively querying for this attribute.
(page 103 continued on part 5)
