Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4171

Internet Storage Name Service (iSNS)

Pages: 123
Proposed Standard
Errata
Part 4 of 5 – Pages 73 to 103
First   Prev   Next

Top   ToC   RFC4171 - Page 73   prevText

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
Top   ToC   RFC4171 - Page 74
   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
Top   ToC   RFC4171 - Page 75
   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.
Top   ToC   RFC4171 - Page 76
   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:
Top   ToC   RFC4171 - Page 77
          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
Top   ToC   RFC4171 - Page 78
   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
Top   ToC   RFC4171 - Page 79
   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
Top   ToC   RFC4171 - Page 80
   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.
Top   ToC   RFC4171 - Page 81

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.
Top   ToC   RFC4171 - Page 82

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-
Top   ToC   RFC4171 - Page 83
   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
Top   ToC   RFC4171 - Page 84

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.
Top   ToC   RFC4171 - Page 85

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.
Top   ToC   RFC4171 - Page 86
   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).
Top   ToC   RFC4171 - Page 87
   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].
Top   ToC   RFC4171 - Page 88
   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).
Top   ToC   RFC4171 - Page 89
   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 Authentication

6.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].
Top   ToC   RFC4171 - Page 90

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.
Top   ToC   RFC4171 - Page 91

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.
Top   ToC   RFC4171 - Page 92

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 RESERVED

6.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.
Top   ToC   RFC4171 - Page 93

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 Supported

6.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:
Top   ToC   RFC4171 - Page 94
          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.
Top   ToC   RFC4171 - Page 95
   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.
Top   ToC   RFC4171 - Page 96

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.
Top   ToC   RFC4171 - Page 97

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.
Top   ToC   RFC4171 - Page 98

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).
Top   ToC   RFC4171 - Page 99

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.
Top   ToC   RFC4171 - Page 100

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 RESERVED
6.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
Top   ToC   RFC4171 - Page 101
   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.
Top   ToC   RFC4171 - Page 102
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.
Top   ToC   RFC4171 - Page 103
          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)

Next Section