tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 4171

 
 
 

Internet Storage Name Service (iSNS)

Part 3 of 5, p. 44 to 73
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 44 
5.6.5.  Registration and Query Request Message Types

   The following describes each query and message type.

5.6.5.1.  Device Attribute Registration Request (DevAttrReg)

   The DevAttrReg message type is 0x0001.  The DevAttrReg message
   provides the means for iSNS clients to update existing objects or
   register new objects.  The value of the replace bit in the FLAGs
   field determines whether the DevAttrReg message updates or replaces
   an existing registration.

   The Source Attribute identifies the Node initiating the registration
   request.

   The Message Key identifies the object the DevAttrReg message acts
   upon.  It MUST contain the key attribute(s) identifying an object.
   This object MUST contain all attributes and related subordinate
   object attributes that will be included in the Operating Attributes
   of the DevAttrReg PDU Payload.  The key attribute(s) identifying this
   object MUST also be included among the Operating Attributes.

   If the Message Key contains an EID and no pre-existing objects match
   the Message Key, then the DevAttrReg message SHALL create a new
   Entity with the specified EID and any new object(s) specified by the
   Operating Attributes.  The replace bit SHALL be ignored.

   If the Message Key does not contain an EID, and no pre-existing
   objects match the Message Key, then the DevAttrReg message SHALL be
   rejected with a status code of 3 (Invalid Registration).

   If the Message Key is not present, then the DevAttrReg message
   implicitly registers a new Network Entity.  In this case, the replace
   bit SHALL be ignored; a new Network Entity SHALL be created.
   Existing entities, their objects, and their relationships remain
   unchanged.

Top      Up      ToC       Page 45 
   The replace bit determines the kind of operation conducted on the
   object identified in the DevAttrReg Message Key.  The replace bit
   only applies to the DevAttrReg message; it is ignored for all other
   message types.

   If the replace bit is set, then the objects, attributes, and
   relationships specified in the Operating Attributes SHALL replace the
   object identified by the Message Key.  The object and all of its
   subordinate objects SHALL be deregistered, and the appropriate SCNs
   SHALL be sent by the iSNS server for the deregistered objects.  The
   objects listed in the Operating Attributes are then used to replace
   the just-deregistered objects.  Note that additional SCNs SHALL be
   sent for the newly-registered objects, if appropriate.  Existing
   objects and relationships that are not identified or that are
   subordinate to the object identified by the Message Key MUST NOT be
   affected or changed.

   If the replace bit is not set, then the message updates the
   attributes of the object identified by the Message Key and its
   subordinate objects.  Existing object containment relationships MUST
   NOT be changed.  For existing objects, key attributes MUST NOT be
   modified, but new subordinate objects MAY be added.

   The Operating Attributes represent objects, attributes, and
   relationships that are to be registered.  Multiple related objects
   and attributes MAY be registered in a single DevAttrReg message.  The
   ordering of the objects in this message indicates the structure of,
   and associations among, the objects to be registered.  At least one
   object MUST be listed in the Operating Attributes.  Additional
   objects (if any) MUST be subordinate to the first object listed.  Key
   attributes MUST precede non-key attributes of each object.  A given
   object may only appear a maximum of once in the Operating Attributes
   of a message.  If the Node identified by the Source Attribute is not
   a Control Node, then the objects in the operating attributes MUST be
   members of the same Network Entity as the Source Node.

   For example, to establish relationships between a Network Entity
   object and its Portal and Storage Node objects, the Operating
   Attributes list the key and non-key attributes of the Network Entity
   object, followed by the key and non-key attributes of each Portal and
   Storage Node object to be linked to that Network Entity.  Similarly,
   an FC Device object that follows a Storage Node object is considered
   subordinate to that Storage Node.

   New PG objects are registered when an associated Portal or iSCSI Node
   object is registered.  An explicit PG object registration MAY follow
   a Portal or iSCSI Node object registration in a DevAttrReg message.

Top      Up      ToC       Page 46 
   When a Portal is registered, the Portal attributes MAY immediately be
   followed by a PGT attribute.  The PGT attribute SHALL be followed by
   the set of PG iSCSI Names representing nodes that will be associated
   to the Portal using the indicated PGT value.  Additional sets of PGTs
   and PG iSCSI Names to be associated to the registered Portal MAY
   follow.  Indicated PGT values are assigned to the PG object
   associated with the newly registered Portal and to the iSCSI Storage
   Node(s) referenced immediately following the PGT attribute in the
   operating attributes.

   When an iSCSI Storage Node is registered, the Storage Node attributes
   MAY immediately be followed by a PGT attribute.  The PGT attribute
   SHALL be followed by the set of PG Portal IP-Address, PG TCP/UDP Port
   pairs representing Portal objects that will be associated with the
   Storage Node using the indicated PGT value.  Additional sets of PGTs
   and PG Portal IP-Address PG TCP/UDP Port pairs to be associated with
   the registered Storage Node MAY follow.  Indicated PGT values are
   assigned to the PG object associated with the newly registered iSCSI
   Storage Node and Portal object(s) referenced immediately following
   the PGT attribute in the operating attributes.

   If the PGT value is not included in the Storage Node or Portal object
   registration, and if a PGT value was not previously registered for
   the relationship, then the PGT for the corresponding PG object SHALL
   be registered with a value of 0x00000001.  If the PGT attribute is
   included in the registration message as a 0-length TLV, then the PGT
   value for the corresponding PG object SHALL be registered as NULL.  A
   0-length TLV for the PGT in an update registration message overwrites
   the previous PGT value with NULL, indicating that there is no
   relationship between the Storage Node and Portal.

   A maximum of one Network Entity object can be created or updated with
   a single DevAttrReg message.  Consequently, the Operating Attributes
   MUST NOT contain more than one Network Entity object.  There is no
   limit to the number of Portal, Storage Node, and FC Device objects
   that can listed in the Operating Attributes, provided they are all
   subordinate to the listed Network Entity object.

   If the Message Key and Operating Attributes do not contain an EID
   attribute, or if the EID attribute has a length of 0, then a new
   Network Entity object SHALL be created and the iSNS server SHALL
   supply a unique EID value for it.  The assigned EID value SHALL be
   included in the DevAttrReg Response message.  If the Message Key and
   Operating Attributes contain an EID that does not match the EID of an
   existing Network Entity in the iSNS database, then a new Network
   Entity SHALL be created and assigned the value contained in that EID
   attribute.  Finally, if the Message Key and Operating Attributes
   contain an EID that matches the EID of an existing object in the iSNS

Top      Up      ToC       Page 47 
   database, then the objects, attributes, and relationships specified
   in the Operating Attributes SHALL be appended to the existing Network
   Entity identified by the EID.

   A registration message that creates a new Network Entity object MUST
   contain at least one Portal or one Storage Node.  If the message does
   not, then it SHALL be considered invalid and result in a response
   with Status Code of 3 (Invalid Registration).

   If an iSNS Server does not support a registration feature, such as
   explicit PG object registration, then the server SHALL return a
   Status Code of 23 (Registration Feature Not Supported).

   Note that the iSNS server may modify or reject the registration of
   certain attributes, such as ESI Interval.  In addition, the iSNS
   server may assign values for additional Operating Attributes that are
   not explicitly registered in the original DevAttrReg message, such as
   the EID and WWNN Token.

5.6.5.2.  Device Attribute Query Request (DevAttrQry)

   The DevAttrQry message type is 0x0002.  The DevAttrQry message
   provides an iSNS client with the means to query the iSNS server for
   object attributes.

   The Source Attribute identifies the Node initiating the request.  For
   non-Control Nodes initiating the DevAttrQry message, the query is
   scoped to the Discovery Domains of which the initiating Node is a
   member.  The DevAttrQry message SHALL only return information on
   Storage Nodes and their related parent and subordinate objects, where
   the Storage Node has a common Discovery Domain with the Node
   identified in the Source Attribute.

   The Message Key may contain key or non-key attributes or no
   attributes at all.  If multiple attributes are used as the Message
   Key, then they MUST all be from the same object type (e.g., IP
   address and TCP/UDP Port are attributes of the Portal object type).
   A Message Key with non-key attributes may match multiple instances of
   the specific object type.  A Message Key with zero-length TLV(s) is
   scoped to every object of the type indicated by the zero-length
   TLV(s).  An empty Message Key field indicates the query is scoped to
   the entire database accessible by the source Node.

   The DevAttrQry response message returns attributes of objects listed
   in the Operating Attributes that are related to the Message Key of
   the original DevAttrQry message.  The Operating Attributes of the
   DevAttrQry message contain zero-length TLVs that specify the
   attributes that are to be returned in the DevAttrQryRsp message.  A

Top      Up      ToC       Page 48 
   Message Key containing zero-length TLVs indicates that the set of
   attributes specified in the Operating Attributes are to be returned
   for each object matching the type indicated by the Message Key.

   If the Message Key contains non-zero length TLVs, then Operating
   Attributes for the object matching the Message Key SHALL be returned
   in the DevAttrQryRsp message.  Each attribute type (i.e., zero-length
   TLV) in the Operating Attributes indicates an attribute from the
   object matching the Message Key, or from other objects in the same
   Entity having a relationship to the object matching the Message Key,
   is to be returned in the response.  The ordering of the object keys
   and associated attributes returned in the DevAttrQry response message
   SHALL be the same as in the original query message.  If no objects
   match the Message Key, then the DevAttrQryRsp message SHALL NOT
   return any operating attributes.  Such a message and its
   corresponding response SHALL NOT be considered an error.

   The Portal Group object determines whether a relationship exists
   between a given Storage Node and Portal object.  If the PGT of the
   Portal Group is not NULL, then a relationship exists between the
   indicated Storage Node and Portal; if the PGT is NULL, then no
   relationship exists.  Therefore, the value (NULL or not NULL) of the
   PGT attribute of each Portal Group object determines the structure
   and ordering of the DevAttrQry response to a query for Storage Nodes
   and Portals.

   For example, an iSNS database contains a Network Entity having two
   Portals and two Nodes.  Each Storage Node has two Portal Groups, one
   with a NULL PGT value for one Portal and another with a non-NULL PGT
   value for the other Portal.  The DevAttrQry message contains a
   Message Key entry matching one of the Nodes, and Operating Attributes
   with zero-length TLVs listing first the Node attributes, Portal
   attributes, and then the PG attributes.  The response message SHALL
   therefore return first the matching Node object, then the requested
   attributes of the one Portal object that can be used to access the
   Storage Node (as indicated by the PGT), and finally the requested
   attributes of the PG object used to access that Storage Node.  The
   order in which each object's attributes are listed is the same as the
   ordering of the object's attributes in the Operating Attributes of
   the original request message.

   If the Message Key Attribute contains zero-length TLV(s), then the
   query returns requested attributes for all objects matching the
   Message Key type (DD restrictions SHALL apply for non-Control Nodes).
   If multiple objects match the Message Key type, then the attributes
   for each object matching the Message Key MUST be listed before the
   attributes for the next matching object are listed in the query

Top      Up      ToC       Page 49 
   response.  In other words, the process described above must be
   iterated in the message response for each object that matches the
   Message Key type specified by the zero-length TLV(s).

   For example, an iSNS database contains only one Network Entity having
   two Portals and three Nodes.  All PG objects in the Entity have a PGT
   value of 0x00000001.  In the DevAttrQry message, the Message Key
   contains a zero-length TLV specifying a Node type, and Operating
   Attributes listing first the Node attributes, and then the Portal
   attributes.  The response message will return, in the following
   order, the attributes for the first, next, and last Node objects,
   each followed by attributes for both Portals.  If that same
   DevAttrQry message had instead contained a zero-length TLV specifying
   the Network Entity type, then the response message would have
   returned attributes for all three Node objects, followed by
   attributes for the two Portals.

   If there is no Message Key Attribute, then the query returns all
   attributes in the iSNS database (once again, DD restrictions SHALL
   apply for non-Control Nodes).  All attributes matching the type
   specified by each zero-length TLV in the Operating Attributes SHALL
   be listed.  All attributes of each type SHALL be listed before the
   attributes matching the next zero-length TLV are listed.

   For example, an iSNS database contains two Entities, each having two
   Nodes and two Portals.  The DevAttrQry message contains no Message
   Key attribute, and Operating Attributes list first the Portal
   attributes, and then the Node attributes.  The Operating Attributes
   of the response message will return attributes from each of the four
   Portals, followed by attributes from each of the four nodes.

   If a DevAttrQry message requests an attribute for which the iSNS
   server has no value, then the server SHALL NOT return the requested
   attribute in the query response.  Such query and response messages
   SHALL NOT be considered errors.

   Registration and query messages for iSNS server-specific attributes
   (i.e., tags in the range 132 to 384) SHALL be formatted using the
   identifying key attribute of the Storage Node originating the query
   (i.e., iSCSI Name or FC Port Name WWPN) for both the Source Attribute
   and Message Key attribute.  Operating Attributes SHALL include the
   TLV of the server-specific attribute being requested.

   DD membership can be discovered through the DevAttrQry message by
   including either DD member attributes (i.e., DD Member iSCSI Index,
   DD Member iSCSI Node, DD Member iFCP Node, DD Member Portal Index, DD
   Member Portal IP Addr, and DD Member Portal TCP/UDP) or the object
   key of the Storage Node or Portal (i.e., iSCSI Name, iSCSI Index,

Top      Up      ToC       Page 50 
   Portal IP Addr, Portal TCP/UDP Port, and Portal Index) in the
   Operating Attributes.  Using DD member attributes SHALL return both
   registered and unregistered member Storage Nodes and/or Portals of a
   DD.  DevAttrQry messages using the Storage Node and/or Portal object
   key SHALL return only member Storage Nodes or Portals that are
   currently registered in the iSNS database.

   The DevAttrQry message SHALL support the following minimum set of
   Message Key Attributes:

          Valid Message Key Attributes for Queries
          ----------------------------------------
           Entity Identifier
           Entity Protocol
           Portal IP-Address & Portal TCP/UDP Port
           Portal Index
           iSCSI Node Type
           iSCSI Name
           iSCSI Index
           PG Index
           FC Port Name WWPN
           FC Port Type
           FC-4 Type
           Discovery Domain ID
           Discovery Domain Set ID
           Source Attribute (for server-specific attributes)
           Switch Name (FC Device WWNN--for Virtual_Fabric_ID queries)

5.6.5.3.  Device Get Next Request (DevGetNext)

   The DevGetNext message type is 0x0003.  This message provides the
   iSNS client with the means to retrieve each and every instance of an
   object type exactly once.

   The Source Attribute identifies the Node initiating the DevGetNext
   request, and is used to scope the retrieval process to the Discovery
   Domains of which the initiating Node is a member.

   The Message Key Attribute may be an Entity Identifier (EID), iSCSI
   Name, iSCSI Index, Portal IP Address and TCP/UDP Port, Portal Index,
   PG Index, FC Node Name WWNN, or FC Port Name WWPN.  If the TLV length
   of the Message Key Attribute(s) is zero, then the first object entry
   in the iSNS database matching the Message Key type SHALL be returned
   in the Message Key of the corresponding DevGetNextRsp message.  If
   non-zero-length TLV attributes are contained in the Message Key, then
   the DevGetNext response message SHALL return the next object stored
   after the object identified by the Message Key in the original
   DevGetNext request message.

Top      Up      ToC       Page 51 
   If the Message Key provided matches the last object instance in the
   iSNS database, then the Status Code of 9 (No Such Entry) SHALL be
   returned in the response.

   The Operating Attributes can be used to specify the scope of the
   DevGetNext request, and to specify the attributes of the next object,
   which are to be returned in the DevGetNext response message.  All
   Operating Attributes MUST be attributes of the object type identified
   by the Message Key.  For example, if the Message Key is an Entity_ID
   attribute, then the Operating Attributes MUST NOT contain attributes
   of Portals.

   Non-zero-length TLV attributes in the Operating Attributes are used
   to scope the DevGetNext message.  Only the next object with attribute
   values that match the non-zero-length TLV attributes SHALL be
   returned in the DevGetNext response message.

   Zero-length TLV attributes MUST be listed after non-zero-length
   attributes in the Operating Attributes of the DevGetNext request
   message.  Zero-length TLV attributes specify the attributes of the
   next object which are to be returned in the DevGetNext response
   message.

   Note that there are no specific requirements concerning the order in
   which object entries are retrieved from the iSNS database; the
   retrieval order of object entries using the DevGetNext message is
   implementation specific.

   The iSNS client is responsible for ensuring that information acquired
   through use of the DevGetNext message is accurate and up-to-date.
   There is no assurance that the iSNS database will not change between
   successive DevGetNext request messages.  If the Message Key provided
   does not match an existing database entry, then attributes for the
   next object key following the provided Message Key SHALL be returned.
   For example, an object entry may have been deleted between successive
   DevGetNext messages.  This may result in a DevGetNext request in
   which the Message Key does not match an existing object entry.  In
   this case, attributes for the next object stored in the iSNS database
   are returned.

5.6.5.4.  Device Deregister Request (DevDereg)

   The DevDereg message type is 0x0004.  This message is used to remove
   object entries from the iSNS database.  One or more objects may be
   removed through a single DevDereg message.  Note that deregistered
   Storage Node objects will retain membership in their Discovery
   Domain(s) until explicit deregistration of the membership(s) or
   Discovery Domain(s).

Top      Up      ToC       Page 52 
   Upon receiving the DevDereg, the iSNS server removes all objects
   identified by the Operating Attribute(s), and all subordinate objects
   that are solely dependent on those identified objects.  For example,
   removal of a Network Entity also results in removal of all associated
   Portal, Portal Group, Storage Node, and FC Device objects associated
   with that Network Entity.  FC Device objects SHALL not be
   deregistered in this manner unless all Storage Nodes associated with
   them have been deregistered.

   The DevDereg request PDU Payload contains a Source Attribute and
   Operating Attribute(s); there are no Message Key Attributes.  If the
   Node identified by the Source Attribute is not a Control Node, then
   it MUST be from the same Network Entity as the object(s) identified
   for removal by the Operating Attribute(s).  Valid Operating
   Attributes are shown below:

          Valid Operating Attributes for DevDereg
          ---------------------------------------
           Entity Identifier
           Portal IP-Address & Portal TCP/UDP Port
           Portal Index
           iSCSI Name
           iSCSI Index
           FC Port Name WWPN
           FC Node Name WWNN

   The removal of the object may result in SCN messages to the
   appropriate iSNS clients.

   Attempted deregistration of non-existing entries SHALL not be
   considered an error.

   If all Nodes and Portals associated with a Network Entity are
   deregistered, then the Network Entity SHALL also be removed.

   If both the Portal and iSCSI Storage Node objects associated with a
   Portal Group object are removed, then that Portal Group object SHALL
   also be removed.  The Portal Group object SHALL remain registered as
   long as either of its associated Portal or iSCSI Storage Node objects
   remain registered.  If a deleted Storage Node or Portal object is
   subsequently re-registered, then a relationship between the re-
   registered object and an existing Portal or Storage Node object
   registration, indicated by the PG object, SHALL be restored.

Top      Up      ToC       Page 53 
5.6.5.5.  SCN Register Request (SCNReg)

   The SCNReg message type is 0x0005.  The State Change Notification
   Registration Request (SCNReg) message allows an iSNS client to
   register a Storage Node to receive State Change Notification (SCN)
   messages.

   The SCN notifies the Storage Node of changes to any Storage Nodes
   within any DD of which it is a member.  If the Storage Node is a
   Control Node, it SHALL receive SCN notifications for changes in the
   entire network.  Note that whereas SCNReg sets the SCN Bitmap field,
   the DevAttrReg message registers the UDP or TCP Port used by each
   Portal to receive SCN messages.  If no SCN Port fields of any Portals
   of the Storage Node are registered to receive SCN messages, then the
   SCNReg message SHALL be rejected with Status Code 17 (SCN
   Registration Rejected).

   The SCNReg request PDU Payload contains a Source Attribute, a Message
   Key Attribute, and an Operating Attribute.  Valid Message Key
   Attributes for a SCNReg are shown below:

          Valid Message Key Attributes for SCNReg
          ---------------------------------------
           iSCSI Name
           FC Port Name WWPN

   The node with the iSCSI Name or FC Port Name WWPN attribute that
   matches the Message Key in the SCNReg message is registered to
   receive SCNs using the specified SCN bitmap.  A maximum of one Node
   SHALL be registered for each SCNReg message.

   The SCN Bitmap is the only operating attribute of this message, and
   it always overwrites the previous contents of this field in the iSNS
   database.  The bitmap indicates the SCN event types for which the
   Node is registering.

   Note that the settings of this bitmap determine whether the SCN
   registration is for regular SCNs or management SCNs.  Control Nodes
   MAY conduct registrations for management SCNs; iSNS clients that are
   not supporting Control Nodes MUST NOT conduct registrations for
   management SCNs.  Control Nodes that register for management SCNs
   receive a copy of every SCN message generated by the iSNS server.  It
   is recommended that management registrations be used only when needed
   in order to conserve iSNS server resources.  In addition, a Control
   Node that conducts such registrations should be prepared to receive
   the anticipated volume of SCN message traffic.

Top      Up      ToC       Page 54 
5.6.5.6.  SCN Deregister Request (SCNDereg)

   The SCNDereg message type is 0x0006.  The SCNDereg message allows an
   iSNS client to stop receiving State Change Notification (SCN)
   messages.

   The SCNDereg request message PDU Payload contains a Source Attribute
   and Message Key Attribute(s).  Valid Message Key Attributes for a
   SCNDereg are shown below:

          Valid Message Key Attributes for SCNDereg
          -----------------------------------------
           iSCSI Name
           FC Port Name WWPN

   The node with an iSCSI Name or FC Port Name WWPN attribute that
   matches the Message Key Attributes in the SCNDereg message is
   deregistered for SCNs.  The SCN bitmap field of such Nodes are
   cleared.  A maximum of one Node SHALL be deregistered for each
   SCNDereg message.

   There are no Operating Attributes in the SCNDereg message.

5.6.5.7.  SCN Event (SCNEvent)

   The SCNEvent message type is 0x0007.  The SCNEvent is a message sent
   by an iSNS client to request generation of a State Change
   Notification (SCN) message by the iSNS server.  The SCN, sent by the
   iSNS server, then notifies iFCP, iSCSI, and Control Nodes within the
   affected DD of the change indicated in the SCNEvent.

   Most SCNs are automatically generated by the iSNS server when Nodes
   are registered or deregistered from the directory database.  SCNs are
   also generated when a network management application or Control Node
   makes changes to the DD membership in the iSNS server.  However, an
   iSNS client can trigger an SCN by using SCNEvent.

   The SCNEvent message PDU Payload contains a Source Attribute, a
   Message Key Attribute, and an Operating Attribute.  Valid Key
   Attributes for a SCNEvent are shown below:

          Valid Message Key Attributes for SCNEvent
          -----------------------------------------
           iSCSI Name
           FC Port Name WWPN

Top      Up      ToC       Page 55 
   The Operating Attributes section SHALL contain the SCN Event Bitmap
   attribute.  The bitmap indicates the event that caused the SCNEvent
   to be generated.

5.6.5.8.  State Change Notification (SCN)

   The SCN message type is 0x0008.  The SCN is a message generated by
   the iSNS server, notifying a registered Storage Node of changes.
   There are two types of SCN registrations: regular registrations and
   management registrations.  Regular SCNs notify iSNS clients of events
   within the discovery domain.  Management SCNs notify Control Nodes
   that register for management SCNs of events occurring anywhere in the
   network.

   If no active TCP connection to the SCN recipient exists, then the SCN
   message SHALL be sent to one Portal of the registered Storage Node
   that has a registered TCP or UDP Port value in the SCN Port field.
   If more than one Portal of the Storage Node has a registered SCN Port
   value, then the SCN SHALL be delivered to any one of the indicated
   Portals, provided that the selected Portal is not the subject of the
   SCN.

   The types of events that can trigger an SCN message, and the amount
   of information contained in the SCN message, depend on the registered
   SCN Event Bitmap for the Storage Node.  The iSCSI Node SCN Bitmap is
   described in Section 6.4.4.  The iFCP SCN Bitmap is described in
   Section 6.6.12.

Top      Up      ToC       Page 56 
   The format of the SCN PDU Payload is shown below:

          +----------------------------------------+
          |         Destination Attribute          |
          +----------------------------------------+
          |               Timestamp                |
          +----------------------------------------+
          |          Source SCN Bitmap 1           |
          +----------------------------------------+
          |          Source Attribute [1]          |
          +----------------------------------------+
          |    Source Attribute [2](if present)    |
          +----------------------------------------+
          |    Source Attribute [3](if present)    |
          +----------------------------------------+
          |    Source Attribute [n](if present)    |
          +----------------------------------------+
          |    Source SCN Bitmap 2 (if present)    |
          +----------------------------------------+
          |                 . . .                  |
          +----------------------------------------+

   All PDU Payload attributes are in TLV format.

   The Destination Attribute is the Node identifier that is receiving
   the SCN.  The Destination Attribute can be an iSCSI Name or FC Port
   Name.

   The Timestamp field, using the Timestamp TLV format, described in
   Section 6.2.4, indicates the time the SCN was generated.

   The Source SCN Bitmap field indicates the type of SCN notification
   (i.e., regular or management SCN), and the type of event that caused
   the SCN to be generated; it does not necessarily correlate with the
   original SCN bitmap registered in the iSNS server.

   Following the timestamp, the SCN message SHALL list the SCN bitmap,
   followed by the key attribute (i.e., iSCSI Name or FC Port Name) of
   the Storage Node affected by the SCN event.  If the SCN is a
   Management SCN, then the SCN message SHALL also list the DD_ID and/or
   DDS_ID of the Discovery Domains and Discovery Domain Sets (if any)
   that caused the change in state for that Storage Node.  These
   additional attributes (i.e., DD_ID and/or DDS_ID) shall immediately
   follow the iSCSI Name or FC Port Name and precede the next SCN bitmap
   for the next notification message (if any).  The SCN bitmap is used
   as a delineator for SCN messages providing multiple state change
   notifications.

Top      Up      ToC       Page 57 
   For example, a regular SCN for notifying an iSNS client of a new
   Portal available for a particular iSCSI target would contain the SCN
   bitmap followed by the iSCSI Name of the target device as the source
   attribute.  If the SCN were a management SCN, then the iSCSI Name
   would be followed by the DD_ID(s) of the shared Discovery Domains
   that allow the destination Storage Node to have visibility to the
   affected Storage Node.  If a Discovery Domain Set (DDS) was enabled
   in order to provide this visibility, then the appropriate DDS_ID
   would be included as well.

   A management SCN is also generated to notify a Control Node of the
   creation, deletion, or modification of a Discovery Domain or
   Discovery Domain Set.  In this case, the DD_ID and/or DDS_ID of the
   affected Discovery Domain and/or Discovery Domain Set would follow
   the SCN bitmap.

   For example, a management SCN to notify a Control Node of a new DD
   within a Discovery Domain Set would contain both the DD_ID and the
   DDS_ID of the affected Discovery Domain and Discovery Domain Set
   among the Source Attributes.

   See Sections 6.4.4 and 6.6.12 for additional information on the SCN
   Bitmap.

5.6.5.9.  DD Register (DDReg)

   The DDReg message type is 0x0009.  This message is used to create a
   new Discovery Domain (DD), to update an existing DD Symbolic Name
   and/or DD Features attribute, and to add DD members.

   DDs are uniquely defined using DD_IDs.  DD registration attributes
   are described in Section 6.11.

   The DDReg message PDU Payload contains the Source Attribute and
   optional Message Key and Operating Attributes.

   The Message Key, if used, contains the DD_ID of the Discovery Domain
   to be registered.  If the Message Key contains a DD_ID of an existing
   DD entry in the iSNS database, then the DDReg message SHALL attempt
   to update the existing entry.  If the DD_ID in the Message Key (if
   used) does not match an existing DD entry, then the iSNS server SHALL
   reject the DDReg message with a status code of 3 (Invalid
   Registration).  If the DD_ID is included in both the Message Key and
   Operating Attributes, then the DD_ID value in the Message Key MUST be
   the same as the DD_ID value in the Operating Attributes.

Top      Up      ToC       Page 58 
   A DDReg message with no Message Key SHALL result in the attempted
   creation of a new Discovery Domain (DD).  If the DD_ID attribute
   (with non-zero length) is included among the Operating Attributes in
   the DDReg message, then the new Discovery Domain SHALL be assigned
   the value contained in that DD_ID attribute.  Otherwise, if the DD_ID
   attribute is not contained among the Operating Attributes of the
   DDReg message, or if the DD_ID is an operating attribute with a TLV
   length of 0, then the iSNS server SHALL assign a DD_ID value.  The
   assigned DD_ID value is then returned in the DDReg Response message.
   The Operating Attributes can also contain the DD Member iSCSI Node
   Index, DD Member iSCSI Name, DD Member FC Port Name, DD Member Portal
   IP Address, DD Member Portal TCP/UDP Port Number, or DD Member Portal
   Index of members to be added to the DD.  It may also contain the
   DD_Symbolic_Name and/or DD_Features of the DD.

   This message SHALL add any DD members listed as Operating Attributes
   to the Discovery Domain specified by the DD_ID.  If the DD_Features
   attribute is an Operating Attribute, then it SHALL be stored in the
   iSNS server as the feature list for the specified DD.  If the
   DD_Symbolic_Name is an operating attribute and its value is unique
   (i.e., it does not match the registered DD_Symbolic_Name for another
   DD), then the value SHALL be stored in the iSNS database as the
   DD_Symbolic_Name for the specified Discovery Domain.  If the value
   for the DD_Symbolic_Name is not unique, then the iSNS server SHALL
   reject the attempted DD registration with a status code of 3 (Invalid
   Registration).

   When creating a new DD, if the DD_Symbolic_Name is not included in
   the Operating Attributes, or if it is included with a zero-length
   TLV, then the iSNS server SHALL provide a unique DD_Symbolic_Name
   value for the created DD.  The assigned DD_Symbolic_Name value SHALL
   be returned in the DDRegRsp message.

   When creating a new DD, if the DD_Features attribute is not included
   in the Operating Attributes, then the iSNS server SHALL assign the
   default value.  The default value for DD_Features is 0.

   DD Member iSCSI Name, DD Member iFCP Node, DD Member Portal IP
   Address, and DD Member TCP/UDP Port Number attributes included in the
   Operating Attributes need not match currently existing iSNS database
   entries.  This allows, for example, a Storage Node to be added to a
   DD even if the Storage Node is not currently registered in the iSNS
   database.  A Storage Node or Portal can thereby be added to a DD at
   the time of the DDs creation, even if the Storage Node or Portal is
   not currently active in the storage network.

Top      Up      ToC       Page 59 
   If the Operating Attributes contain a DD Member iSCSI Name value for
   a Storage Node that is currently not registered in the iSNS database,
   then the iSNS server MUST allocate an unused iSCSI Node Index for
   that Storage Node.  The assigned iSCSI Node Index SHALL be returned
   in the DDRegRsp message as the DD Member iSCSI Node Index.  The
   allocated iSCSI Node Index value SHALL be assigned to the Storage
   Node if and when it registers in the iSNS database.

   If the Operating Attributes contain a DD Member Portal IP Addr and DD
   Member Portal TCP/UDP value for a Portal that is not currently
   registered in the iSNS database, then the iSNS server MUST allocate
   an unused Portal Index value for that Portal.  The assigned Portal
   Index value SHALL be returned in the DDRegRsp message as the DD
   Member Portal Index.  The allocated Portal Index value SHALL be
   assigned to the Portal if and when it registers in the iSNS database.

   DD Member iSCSI Node Index and DD Member Portal Index attributes that
   are provided in the Operating Attributes MUST match a corresponding
   iSCSI Node Index or Portal Index of an existing Storage Node or
   Portal entry in the iSNS database.  Furthermore, the DD Member iSCSI
   Node Index and DD Member Portal Index SHALL NOT be used to add
   Storage Nodes or Portals to a DD unless those Storage Nodes or
   Portals are actively registered in the iSNS database.

5.6.5.10.  DD Deregister (DDDereg)

   The DDDereg message type is 0x000A.  This message allows an iSNS
   client to deregister an existing Discovery Domain (DD) and to remove
   members from an existing DD.

   DDs are uniquely identified using DD_IDs.  DD registration attributes
   are described in Section 6.11.

   The DDDereg message PDU Payload contains a Source Attribute, Message
   Key Attribute, and optional Operating Attributes.

   The Message Key Attribute for a DDDereg message is the DD ID for the
   Discovery Domain being removed or having members removed.  If the DD
   ID matches an existing DD and there are no Operating Attributes, then
   the DD SHALL be removed and a success Status Code returned.  Any
   existing members of that DD SHALL remain in the iSNS database without
   membership in the just-removed DD.

   If the DD ID matches an existing DD and there are Operating
   Attributes matching DD members, then the DD members identified by the
   Operating Attributes SHALL be removed from the DD and a successful
   Status Code returned.

Top      Up      ToC       Page 60 
   If a DD Member iSCSI Name identified in the Operating Attributes
   contains an iSCSI Name for a Storage Node that is not currently
   registered in the iSNS database or contained in another DD, then the
   association between that Storage Node and its pre-assigned iSCSI Node
   Index SHALL be removed.  The pre-assigned iSCSI Node Index value no
   longer has an association to a specific iSCSI Name and can now be
   re-assigned.

   If a DD Member Portal IP Address and DD Member TCP/UDP Port
   identified in the Operating Attributes reference a Portal that is not
   currently registered in the iSNS database or contained in another DD,
   then the association between that Portal and its pre-assigned Portal
   Index SHALL be removed.  The pre-assigned Portal Index value can now
   be reassigned.

   The attempted deregistration of non-existent DD entries SHALL not be
   considered an error.

5.6.5.11.  DDS Register (DDSReg)

   The DDSReg message type is 0x000B.  This message allows an iSNS
   client to create a new Discovery Domain Set (DDS), to update an
   existing DDS Symbolic Name and/or DDS Status, or to add DDS members.

   DDSs are uniquely defined using DDS_IDs.  DDS registration attributes
   are described in Section 6.11.1.

   The DDSReg message PDU Payload contains the Source Attribute and,
   optionally, Message Key and Operating Attributes.

   The Message Key, if used, contains the DDS_ID of the Discover Domain
   Set to be registered or modified.  If the Message Key contains a
   DDS_ID of an existing DDS entry in the iSNS database, then the DDSReg
   message SHALL attempt to update the existing entry.  If the DDS_ID in
   the Message Key (if used) does not match an existing DDS entry, then
   the iSNS server SHALL reject the DDSReg message with a status code of
   3 (Invalid Registration).  If the DDS_ID is included in both the
   Message Key and Operating Attributes, then the DDS_ID value in the
   Message Key MUST be the same as the DDS_ID value in the Operating
   Attributes.

   A DDSReg message with no Message Key SHALL result in the attempted
   creation of a new Discovery Domain Set (DDS).  If the DDS_ID
   attribute (with non-zero length) is included among the Operating
   Attributes in the DDSReg message, then the new Discovery Domain Set
   SHALL be assigned the value contained in that DDS_ID attribute.
   Otherwise, if the DDS_ID attribute is not contained among the
   Operating Attributes of the DDSReg message, or if the DDS_ID is an

Top      Up      ToC       Page 61 
   operating attribute with a TLV length of 0, then the iSNS server
   SHALL assign a DDS_ID value.  The assigned DDS_ID value is then
   returned in the DDSReg Response message.  The Operating Attributes
   can also contain the DDS_Symbolic_Name, the DDS Status, and the
   DD_IDs of Discovery Domains to be added to the DDS.

   When creating a new DDS, if the DDS Symbolic Name is included in the
   Operating Attributes and its value is unique (i.e., it does not match
   the registered DDS Symbolic Name for another DDS), then the value
   SHALL be stored in the iSNS database as the DDS Symbolic Name for
   that DDS.  If the value for the DDS Symbolic Name is not unique, then
   the iSNS server SHALL reject the attempted DDS registration with a
   status code of 3 (Invalid Registration).

   When creating a new DDS, if the DDS Symbolic Name is not included in
   the Operating Attributes, or if it is included with a zero-length
   TLV, then the iSNS server SHALL provide a unique DDS Symbolic Name
   value for the created DDS.  The assigned DDS Symbolic Name value
   SHALL be returned in the DDSRegRsp message.

   This message SHALL add any DD_IDs listed as Operating Attributes to
   the Discovery Domain Set specified by the DDS_ID Message Key
   Attribute.  In addition, if the DDS_Symbolic_Name is an operating
   attribute and the value is unique, then it SHALL be stored in the
   iSNS database as the DDS_Symbolic_Name for the specified Discovery
   Domain Set.

   If a DD_ID listed in the Operating Attributes does not match an
   existing DD, then a new DD using the DD_ID SHALL be created.  In this
   case for the new DD, the iSNS server SHALL assign a unique value for
   the DD Symbolic Name and SHALL set the DD Features attribute to the
   default value of 0.  These assigned values SHALL be returned in the
   DDSRegRsp message.

5.6.5.12.  DDS Deregister (DDSDereg)

   The DDSDereg message type is 0x000C.  This message allows an iSNS
   client to deregister an existing Discovery Domain Set (DDS) or to
   remove some DDs from an existing DDS.

   The DDSDereg message PDU Payload contains a Source Attribute, a
   Message Key Attribute, and optional Operating Attributes.

   The Message Key Attribute for a DDSDereg message is the DDS ID for
   the DDS being removed or having members removed.  If the DDS ID
   matches an existing DDS and there are no Operating Attributes, then

Top      Up      ToC       Page 62 
   the DDS SHALL be removed and a success Status Code returned.  Any
   existing members of that DDS SHALL remain in the iSNS database
   without membership in the just-removed DDS.

   If the DDS ID matches an existing DDS, and there are Operating
   Attributes matching DDS members, then the DDS members SHALL be
   removed from the DDS and a success Status Code returned.

   The attempted deregistration of non-existent DDS entries SHALL not be
   considered an error.

5.6.5.13.  Entity Status Inquiry (ESI)

   The ESI message type is 0x000D.  This message is sent by the iSNS
   server, and is used to verify that an iSNS client Portal is reachable
   and available.  The ESI message is sent to the ESI UDP port provided
   during registration, or to the TCP connection used for ESI
   registration, depending on which communication type that is being
   used.

   The ESI message PDU Payload contains the following attributes in TLV
   format and in the order listed: the current iSNS timestamp, the EID,
   the Portal IP Address, and the Portal TCP/UDP Port.  The format of
   this message is shown below:

          +----------------------------------------+
          |               Timestamp                |
          +----------------------------------------+
          |               Entity_ID                |
          +----------------------------------------+
          |           Portal IP Address            |
          +----------------------------------------+
          |          Portal TCP/UDP Port           |
          +----------------------------------------+

   The ESI response message PDU Payload contains a status code, followed
   by the Attributes from the original ESI message.

   If the Portal fails to respond to an administratively-determined
   number of consecutive ESI messages, then the iSNS server SHALL remove
   that Portal from the iSNS database.  If there are no other remaining
   ESI-monitored Portals for the associated Network Entity, then the
   Network Entity SHALL also be removed.  The appropriate State Change
   Notifications, if any, SHALL be triggered.

Top      Up      ToC       Page 63 
5.6.5.14.  Name Service Heartbeat (Heartbeat)

   This message, if used, is only sent by the active iSNS server.  It
   allows iSNS clients and backup servers listening to a broadcast or
   multicast address to discover the IP address of the primary and
   backup iSNS servers.  It also allows concerned parties to monitor the
   health and status of the primary iSNS server.

   This message is NOT in TLV format.  There is no response message to
   the Name Service Heartbeat.

          MSb                                            LSb
          0                                               31
          +------------------------------------------------+
          |            Active Server IP-Address            | 16 Bytes
          +------------------------------------------------+
          |     iSNS TCP Port     |      iSNS UDP Port     | 4 Bytes
          +------------------------------------------------+
          |                   Interval                     | 4 Bytes
          +------------------------------------------------+
          |                    Counter                     | 4 Bytes
          +------------------------------------------------+
          |      RESERVED         |    Backup Servers      | 4 Bytes
          +------------------------------------------------+
          |    Primary Backup Server IP Address(if any)    | 16 Bytes
          +------------------------------------------------+
          |Backup TCP Port(if any)|Backup UDP Port(if any) | 4 Bytes
          +------------------------------------------------+
          |      2nd Backup Server IP Address(if any)      | 16 Bytes
          +------------------------------------------------+
          |Backup TCP Port(if any)|Backup UDP Port(if any) | 4 Bytes
          +------------------------------------------------+
          |                     . . .                      |
          +------------------------------------------------+
          |                VENDOR SPECIFIC                 |
          +------------------------------------------------+

   The heartbeat PDU Payload contains the following:

   Active Server IP Address: the IP Address of the active iSNS server in
                    IPv6 format.  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.

   Active TCP Port: the TCP Port of the server currently in use.

Top      Up      ToC       Page 64 
   Active UDP Port: the UDP Port of the server currently in use,
                    otherwise 0.

   Interval:        the interval, in seconds, of the heartbeat.

   Counter:         a count that begins at 0 when this server becomes
                    active.  The count increments by one for each
                    heartbeat sent since this server became active.

   Backup Servers:  the number of iSNS backup servers.  The IP address,
                    TCP Port, and UDP Port of each iSNS backup server
                    follow this field.  Note that if backup servers are
                    used, then the active iSNS server SHOULD be among
                    the list of backup servers.

   The content of the remainder of this message after the list of backup
   servers is vendor-specific.  Vendors may use additional fields to
   coordinate between multiple iSNS servers, and/or to identify vendor-
   specific features.

5.6.5.15.  Request FC_DOMAIN_ID (RqstDomId)

   The RqstDomId message type is 0x0011.  This message is used for iFCP
   Transparent Mode to allocate non-overlapping FC_DOMAIN_ID values
   between 1 and 239.  The iSNS server becomes the address assignment
   authority for the entire iFCP fabric.  To obtain multiple
   FC_DOMAIN_ID values, this request must be repeated to the iSNS server
   multiple times.  iSNS clients that acquire FC_DOMAIN_ID values from
   an iSNS server MUST register for ESI monitoring from that iSNS
   server.

   The RqstDomId PDU Payload contains three TLV attributes in the
   following order: the requesting Switch Name (WWN) as the Source
   Attribute, the Virtual_Fabric_ID as the Message Key Attribute, and
   Preferred ID as the operating attribute.  The Virtual_Fabric_ID is a
   string identifying the domain space for which the iSNS server SHALL
   allocate non-overlapping integer FC_DOMAIN_ID values between 1 and
   239.  The Preferred_ID is the nominal FC_DOMAIN_ID value requested by
   the iSNS client.  If the Preferred_ID value is available and has not
   already been allocated for the Virtual_Fabric_ID specified in the
   message, the iSNS server SHALL return the requested Preferred_ID
   value as the Assigned_ID to the requesting client.

   The RqstDomId response contains a Status Code, and the TLV attribute
   Assigned ID, which contains the integer value in the space requested.
   If no further unallocated values are available from this space, the
   iSNS server SHALL respond with the Status Code 18 "FC_DOMAIN_ID Not
   Available".

Top      Up      ToC       Page 65 
   Once a FC_DOMAIN_ID value has been allocated to an iSNS client by the
   iSNS server for a given Virtual_Fabric_ID, that FC_DOMAIN_ID value
   SHALL NOT be reused until it has been deallocated, or until ESI
   monitoring detects that the iSNS client no longer exists on the
   network and objects for that client are removed from the iSNS
   database.

   The iSNS server and client SHALL use TCP to transmit and receive
   RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.

5.6.5.16.  Release FC_DOMAIN_ID (RlseDomId)

   The RlseDomId message type is 0x0012.  This message may be used by
   iFCP Transparent Mode to release integer identifier values used to
   assign 3-byte Fibre Channel PORT_ID values.

   The RlseDomId message contains three TLV attributes in the following
   order: the requesting EID as the Source Attribute, the
   Virtual_Fabric_ID as the Message Key Attribute, and Assigned_ID as
   the operating attribute.  Upon receiving the RlseDomId message, the
   iSNS server SHALL deallocate the FC_DOMAIN_ID value contained in the
   Assigned_ID attribute for the Virtual_Fabric_ID attribute specified.
   Upon deallocation, that FC_DOMAIN_ID value can then be requested by
   and assigned to a different iSNS client.

   The iSNS server and client SHALL use TCP to transmit and receive
   RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.

5.6.5.17.  Get FC_DOMAIN_IDs (GetDomId)

   The GetDomId message type is 0x0013.  This message is used to learn
   the currently-allocated FC_DOMAIN_ID values for a given
   Virtual_Fabric_ID.

   The GetDomId message PDU Payload contains a Source Attribute and
   Message Key Attribute.

   The Message Key Attribute for the GetDomId message is the
   Virtual_Fabric_ID.  The response to this message returns all the
   FC_DOMAIN_ID values that have been allocated for the
   Virtual_Fabric_ID specified.

Top      Up      ToC       Page 66 
5.7.  Response Messages

   The iSNSP response message PDU Payloads contain a Status Code,
   followed by a list of attributes, and have the following format:

          MSb                                    LSb
          0                                       31
          +----------------------------------------+
          |          4-byte STATUS CODE            |
          +----------------------------------------+
          |  Message Key Attribute[1] (if present) |
          +----------------------------------------+
          |  Message Key Attribute[2] (if present) |
          +----------------------------------------+
          |                 . . .                  |
          +----------------------------------------+
          |  - Delimiter Attribute - (if present)  |
          +----------------------------------------+
          |   Operating Attribute[1] (if present)  |
          +----------------------------------------+
          |   Operating Attribute[2] (if present)  |
          +----------------------------------------+
          |   Operating Attribute[3] (if present)  |
          +----------------------------------------+
          |                 . . .                  |
          +----------------------------------------+

   The iSNSP Response messages SHALL be sent to the iSNS Client IP
   Address and the originating TCP/UDP Port that was used for the
   associated registration and query message.

5.7.1.  Status Code

   The first field in an iSNSP response message PDU Payload is the
   Status Code for the operation that was performed.  The Status Code
   encoding is defined in Section 5.4.

5.7.2.  Message Key Attributes in Response

   Depending on the specific iSNSP request, the response message MAY
   contain Message Key Attributes.  Message Key Attributes generally
   contain the interesting key attributes that are affected by the
   operation specified in the original iSNS registration or query
   message.

Top      Up      ToC       Page 67 
5.7.3.  Delimiter Attribute in Response

   The Delimiter Attribute separates the key and Operating Attributes in
   a response message, if they exist.  The Delimiter Attribute has a tag
   value of 0 and a length value of 0.  The Delimiter Attribute is
   effectively 8 bytes long: a 4-byte tag containing 0x00000000, and a 4
   Byte length field containing 0x00000000.

5.7.4.  Operating Attributes in Response

   The Operating Attributes in a response are the results related to the
   iSNS registration or query operation being performed.  Some response
   messages will not have Operating Attributes.

5.7.5.  Registration and Query Response Message Types

   The following sections describe each query and message type.

5.7.5.1.  Device Attribute Registration Response (DevAttrRegRsp)

   The DevAttrRegRsp message type is 0x8001.  The DevAttrRegRsp message
   contains the results for the DevAttrReg message with the same
   TRANSACTION ID.

   The Message Key in the DevAttrRegRsp message SHALL return the Message
   Key in the original registration message.  If the iSNS server
   assigned the Entity Identifier for a Network Entity, then the Message
   Key Attribute field SHALL contain the assigned Entity Identifier.

   The Operating Attributes of the DevAttrRegRsp message SHALL contain
   the affected object's key and non-key attributes that have been
   explicitly modified or created by the original DevAttrReg message.
   Among the Operating Attributes, each modified or added non-key
   attribute SHALL be listed after its key attribute(s) in the
   DevAttrRegRsp message.  Implicitly registered attributes MUST NOT be
   returned in the DevAttrRegRsp message.  Implicitly registered
   attributes are those that are assigned a fixed default value or
   secondary index value by the iSNS server.

   Implicitly registered PG objects (i.e., PG objects that are not
   explicitly included in the registration or replace message) MUST NOT
   have their key or non-key attributes returned in the DevAttrRegRsp
   message.  However, explicitly registered PG objects (i.e., those with
   PGT values that are explicitly included in the registration or
   replace message) SHALL have their PGT values returned in the
   DevAttrRegRsp message.

Top      Up      ToC       Page 68 
   For example, three Portals are registered in the original DevAttrReg
   request message.  Due to lack of resources, the iSNS server needs to
   modify the registered ESI Interval value of one of those Portals.  To
   accomplish this, the iSNS server returns the key attributes
   identifying the Portal, followed by the non-key modified ESI Interval
   attribute value, as Operating Attributes of the corresponding
   DevAttrRegRsp message.

   If the iSNS server rejects a registration due to invalid attribute
   values or types, then the indicated status code SHALL be 3 (Invalid
   Registration).  If this occurs, then the iSNS server MAY include the
   list of invalid attributes in the Operating Attributes of the
   DevAttrRsp message.

   Some attributes values (e.g., ESI Interval, Registration Period) in
   the original registration message MAY be modified by the iSNS server.
   This can occur only for a limited set of attribute types, as
   indicated in the table in Section 6.1.  When this occurs, the
   registration SHALL be considered a success (with status code 0), and
   the changed value(s) indicated in the Operating Attributes of the
   DevAttrRsp message.

5.7.5.2.  Device Attribute Query Response (DevAttrQryRsp)

   The DevAttrQryRsp message type is 0x8002.  The DevAttrQryRsp message
   contains the results for the DevAttrQry message with the same
   TRANSACTION ID.

   The Message Key in the DevAttrQryRsp message SHALL return the Message
   Key in the original query message.

   If no Operating Attributes are included in the original query, then
   all Operating Attributes SHALL be returned in the response.

   For a successful query result, the DevAttrQryRsp Operating Attributes
   SHALL contain the results of the original DevAttrQry message.

5.7.5.3.  Device Get Next Response (DevGetNextRsp)

   The DevGetNextRsp message type is 0x8003.  The DevGetNextRsp message
   contains the results for the DevGetNext message with the same
   TRANSACTION ID.

   The Message Key Attribute field returns the object keys for the next
   object after the Message Key Attribute in the original DevGetNext
   message.

Top      Up      ToC       Page 69 
   The Operating Attribute field returns the Operating Attributes of the
   next object as requested in the original DevGetNext message.  The
   values of the Operating Attributes are those associated with the
   object identified by the Message Key Attribute field of the
   DevGetNextRsp message.

5.7.5.4.  Deregister Device Response (DevDeregRsp)

   The DevDeregRsp message type is 0x8004.  This message is the response
   to the DevDereg request message.

   This message response does not contain a Message Key, but MAY contain
   Operating Attributes.

   In the event of an error, this response message contains the
   appropriate status code as well as a list of objects from the
   original DevDereg message that were not successfully deregistered
   from the iSNS database.  This list of objects is contained in the
   Operating Attributes of the DevDeregRsp message.  Note that an
   attempted deregistration of a non-existent object does not constitute
   an error, and non-existent entries SHALL not be returned in the
   DevDeregRsp message.

5.7.5.5.  SCN Register Response (SCNRegRsp)

   The SCNRegRsp message type is 0x8005.  This message is the response
   to the SCNReg request message.

   The SCNRegRsp message does not contain any Message Key or Operating
   Attributes.

5.7.5.6.  SCN Deregister Response (SCNDeregRsp)

   The SCNDeregRsp message type is 0x8006.  This message is the response
   to the SCNDereg request message.

   The SCNDeregRsp message does not contain any Message Key or Operating
   Attributes.

5.7.5.7.  SCN Event Response (SCNEventRsp)

   The SCNEventRsp message type is 0x8007.  This message is the response
   to the SCNEvent request message.

   The SCNEventRsp message does not contain any Message Key or Operating
   Attributes.

Top      Up      ToC       Page 70 
5.7.5.8.  SCN Response (SCNRsp)

   The SCNRsp message type is 0x8008.  This message is sent by an iSNS
   client, and provides confirmation that the SCN message was received
   and processed.

   The SCNRsp response contains the SCN Destination Attribute
   representing the Node identifier that received the SCN.

5.7.5.9.  DD Register Response (DDRegRsp)

   The DDRegRsp message type is 0x8009.  This message is the response to
   the DDReg request message.

   The Message Key in the DDRegRsp message SHALL return the Message Key
   in the original query message.  If the original DDReg message did not
   have a Message Key, then the DDRegRsp message SHALL not have a
   Message Key.

   If the DDReg operation is successful, the DD ID of the DD created or
   updated SHALL be returned as an operating attribute of the message.

   If the DD Symbolic Name attribute or DD Features attribute was
   assigned or updated during the DDReg operation, then any new values
   SHALL be returned as an operating attribute of the DDRegRsp message.

   If the iSNS server rejects a DDReg due to invalid attribute values or
   types, then the indicated status code SHALL be 3 (Invalid
   Registration).  If this occurs, then the iSNS server MAY include the
   list of invalid attributes in the Operating Attributes of the
   DDRegRsp message.

5.7.5.10.  DD Deregister Response (DDDeregRsp)

   The DDDeregRsp message type is 0x800A.  This message is the response
   to the DDDereg request message.

   The DDDeregRsp message does not contain any Message Key or Operating
   Attributes.

Top      Up      ToC       Page 71 
5.7.5.11.  DDS Register Response (DDSRegRsp)

   The DDSRegRsp message type is 0x800B.  This message is the response
   to the DDSReg request message.

   The Message Key in the DDSRegRsp message SHALL contain the Message
   Key of the original DDSReg message.  If the original DDSReg message
   did not have a Message Key, then the DDSRegRsp message SHALL NOT have
   a Message Key.

   If the DDSReg operation is successful, the DDS ID of the DDS created
   or updated SHALL be returned as an operating attribute of the
   message.

   If the DDS Symbolic Name attribute or DDS Status attribute was
   assigned or updated during the DDSRegRsp operation, then any new
   values SHALL be returned as an operating attribute of the DDSRegRsp
   message.

   If the iSNS server rejects a DDSReg due to invalid attribute values
   or types, then the indicated status code SHALL be 3 (Invalid
   Registration).  If this occurs, then the iSNS server MAY include the
   list of invalid attributes in the Operating Attributes of the
   DDSRegRsp message.

5.7.5.12.  DDS Deregister Response (DDSDeregRsp)

   The DDSDeregRsp message type is 0x800C.  This message is the response
   to the DDSDereg request message.

   The DDSDeregRsp message does not contain any Message Key or Operating
   Attributes.

5.7.5.13.  Entity Status Inquiry Response (ESIRsp)

   The ESIRsp message type is 0x800D.  This message is sent by an iSNS
   client and provides confirmation that the ESI message was received
   and processed.

   The ESIRsp response message PDU Payload contains the attributes from
   the original ESI message.  These attributes represent the Portal that
   is responding to the ESI.  The ESIRsp Attributes are in the order
   they were provided in the original ESI message.

   Upon receiving the ESIRsp from the iSNS client, the iSNS server SHALL
   update the timestamp attribute for that Network Entity and Portal.

Top      Up      ToC       Page 72 
5.7.5.14.  Request FC_DOMAIN_ID Response (RqstDomIdRsp)

   The RqstDomIdRsp message type is 0x8011.  This message provides the
   response for RqstDomId.

   The RqstDomId response contains a Status Code and the TLV attribute
   Assigned ID, which contains the integer value in the space requested.
   If no further unallocated values are available from this space, the
   iSNS server SHALL respond with the Status Code 19 "FC_DOMAIN_ID Not
   Available".

   Once a FC_DOMAIN_ID value is allocated by the iSNS server, it SHALL
   NOT be reused until it has been deallocated by the iSNS client to
   which the value was assigned, or until the ESI message detects that
   the iSNS client no longer exists on the network.

   The iSNS server and client SHALL use TCP to transmit and receive
   RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.

5.7.5.15.  Release FC_DOMAIN_ID Response (RlseDomIdRsp)

   The RlseDomIdRsp message type is 0x8012.  This message provides the
   response for RlseDomId.  The response contains an Error indicating
   whether the request was successful.  If the Assigned_ID value in the
   original RlseDomId message is not allocated, then the iSNS server
   SHALL respond with this message using the Status Code 20
   "FC_DOMAIN_ID Not Allocated".

   The iSNS server and client SHALL use TCP to transmit and receive
   RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.

5.7.5.16.  Get FC_DOMAIN_IDs Response (GetDomIdRsp)

   The GetDomIdRsp message type is 0x8013.  This message is used to
   determine which FC_DOMAIN_ID values have been allocated for the
   Virtual_Fabric_ID specified in the original GetDomId request message.

   The GetDomId response message PDU Payload contains a Status Code
   indicating whether the request was successful, and a list of the
   Assigned IDs from the space requested.  The Assigned_ID attributes
   are listed in TLV format.

5.8.  Vendor-Specific Messages

   Vendor-specific iSNSP messages have a functional ID of between 0x0100
   and 0x01FF, whereas vendor-specific responses have a functional ID of
   between 0x8100 and 0x81FF.  The first Message Key Attribute in a

Top      Up      ToC       Page 73 
   vendor-specific message SHALL be the company OUI (tag=256)
   identifying the original creator of the proprietary iSNSP message.
   The contents of the remainder of the message are vendor-specific.



(page 73 continued on part 4)

Next RFC Part