6.5.1 Device Attribute Registraton Request（DevAttrReg）
DevAttrRet消息的类型为：0x0001。DevAttrRet消息可以让iSNS客户端注册一个新的对象或修改已存在对象。FLAGS中的Replace Bit的值决定DevAttrReg消息时更新还是覆盖一个已存在的注册。
Source Attribute 指明DevAttrReg消息的发起端。
Message Key指明需要注册的对象。它必须（MUST）包含一个能够识别出这个对象的Key属性。这个对象的所有属性和关联对象的所有属性必须（MUST）包含在Operating Attributes中。这个识别对象的Key属性，也必须（MUST）保存在Operating Attribute中。
如果Message Key包含一个EID，并且这个EID在iSNS数据库中不存在，那么DevAttrReg消息就应该（SHALL）用这个EID创建一个新的Entity和制定属性的所有对象。这时，Replace Bit应该（SHALL）被忽略。
如果Message key没有包含EID，并且Message Key中的其他属性不能匹配已注册的对象，那么这个DevAttrReg消息就应该（SHALL）用状态码3（Invalid Registration）来拒绝。
如果Message Key不存在，那么DevAttrReg消息就应该直接注册一个新的NetWork Entity。这种情况下Replace Bit应该（SHALL）被忽略；一个新的Network Entity应该（SHALL）被创建。现有的实体、他们的对象和之间的关系都不变。
Replace Bit决定了针对DevAttrReg消息中指定的Object的行为。Replace Bit只对DevAttrReg消息有效，其它的消息都应该忽略这个Bit。
如果Replace Bit被设置，那么在Operation Attribute中制定的Objects、Attributes、Relationships应该（SHALL）替换Message Key指定对象。这个对象和所有的关联对象都应该（SHALL）被注销，并且对应的SCN消息也应该（SHALL）由iSNS服务器发出。然后，Operating Attribute中列出的对象应该替换刚刚注销的对象。并且应该（SHALL）为新注册的对象发送另外的SCN消息。不是Message Key所指对象，或其关联对象的必须不能（MUST NOT）有任何改变。
如果Replace Bit没有被设置，那么就应该更新Message Key指定的对象和关联对象。已存在的对象和关系必须不能（MUST NOT）被改变。对于已存在的对象，Key属性必须不能（MUST NOT）被修改，但是新的关联对象可以（MAY）被添加。
Operating Attribute中描述的对象、属性和他们的关系就是用来被注册的。多个相关的对象和属性可能（MAY）在一个DevAttrRet消息中注册。消息中对象的次序指明了要注册对象的结构和他们之间的关系。Operating Attribute中必须（MUST）至少包含一个对象。其它的对象必须（MUST）是这个对象的从属对象。每个对象的Key属性必须（MUST）在Non-Key属性之前。一个对象只能在Operating Attribute中出现一次。如果Souce Attribute中指明的不是一个Control Node，那么所有Operating Attribute中的对象必须（MUST）是和Source Attribute中指明的同一个Network Entity中的对象。
比如，建立一个Network Entity和它的Portal、Storage Node之间的关系，那么Operating Attribute中先保存Network Entity的Key和Non-Key属性，然后是Portal的的Key和Non-Key属性，最后是Storage Node的Key和Non-Key属性。同样，如果有FC Device的话，就应该跟在Storage Node的对象之后。
当相关的Portal或iSCSI Node在注册时，会注册新的PG对象。在DevAttrReg消息中一个直接的PG对象的注册可能跟在Portal或iSCSI Node的后面。当一个Portal被注册时，Portal属性的后面可能（MAY）直接跟的就是PGT属性。PGT属性后面跟着的可以（SHALL）是使用这个PGT值得Portal的iSCSI Node的iSCSI Name的集合。其它的PGT和他们对应的iSCSI Name的属性，可能（MAY）跟在后面。在Operating Attribute中直接指定的PGT的值被分配给新注册的Portal和关联的iSCSI Storage Node对应的PG。
当一个iSCSI Storage Node被注册时，Storage Node的属性可能直接跟在PGT属性的后面。PGT属性可能（SHALL）跟在使用这个PGT值的iSCSI Storage Node对应的Portal的IP地址和TCP/UDP端口号对的集合后面。其它的和注册的Storage Node向关联的PGT和对应的Portal的IP地址和TCP/UDP端口对可能（MAY）跟在后面。这个PGT值被分配给新注册的iSCSI Storage Node和关联的Portal（s）对应的PG对象。
如果Storage Node或Portal的注册中没有包含PGT，并且也没有一个PGT值在之前被注册，那么对应的PG对象应该（SHALL）用值0x00000001注册。如果一个注册消息中的PGT值为一个0长度的TLV，那么对应的PG对象应该被注册为NULL。在一个更新注册消息中的0长TLV将用NULL覆盖已存在的PGT，这说明在Storage Node 和 Portal中没有关系。
在一个DevAttrReg消息中最多只能新建或更新一个Network Entity。因此，Operating Attribute中一定不能（MUST NOT）包含多于一个Network Entity的对象。但是Operating Attribute中列出的从属于一个Network Entity的Portal、Storage Node、FC Device没有多限制。
如果在Message Key和Operating Attribute没有提供一个EID属性，或提供的EID长度为0，那么iSNS服务器应该（SHALL）为新注册的Network Entity提供一个唯一的EID。这个EID应该（SHALL）在应答消息中返回。如果Message Key和Operating Attribute中的EID不是iSNS数据库中已存在的，那么应该（SHALL）这个EID注册一个新的Network Entity。最后，如果Message Key和Operating Attribute中的EID和ISNS数据库中的某个对象的EID一样，那么Operating Attibute中列出的对象、属性和关系应该被追加在这个已存在的Network Entity中。
一个注册新Network Entity的消息必须（MUST）最少包含一个Portal或一个Storage Node。如果没有就应该（SHALL）视为无效，并返回错误码3（Invalid Registration）。
如果一个iSNS服务器不支持某些注册，比如PG的注册，那么服务器应该（SHALL）返回状态码23（Registration Feature Not Supported）。
注意：iSNS服务器可能修改或拒绝一些注册的属性，如：ESI Interval。另外，iSNS服务器可能为一些没有指定的属性分配值，如EID、WWNN Token。
6.5.2、Device Attribute Query Request（DevAttrQry）
DevAttrQry的消息类型是0x0002。DevAttrQry消息可以让iSNS客户端查询iSNS服务器上的对象属性。
Source Attribute指明发起方。如果发起方不是Control Node，那么它只能查询它属于的那个DD中的对象。DevAttrQry消息应该（SHALL）仅仅返回发起方同DD的Storage Node属性和它的关联父-子对象的属性。
Message Key可能包含Key或Non-Key属性，或者什么属性也没有。如果Message Key中有多个属性，那么它们必须（MUST）输入同一种对象（比如，IP Address和TCP/UDP Port都属于Portal）。一个包括Non-Key属性的Message Key可能会匹配这个对象中的多个实例。Message Key中有一个0长的TLV，指定查询的范围是所有的TLV指定对象类型的对象。一个空的Messag Key指定查询的范围是数据库中所有发起方可能查询的对象。
DevAttrQry应答消息在Operating Attribute中列出了原DevAttrQry消息中Message Key属性所指定对象的属性。DevAttrQry消息中的Operating Attribute中包含的0长的TLV，指出需要DevAttrQry应答消息中需要返回的属性。DevAttrQry消息中的Message Key为0长TLV时，指出返回所有符合Message Key条件的对象的，Operating Attribute中指定的属性。
如果Message Key中是一个非0长TLV时，DevAttrQryRsp消息应该（SHALL）返回符合Message Key的对象的Operating Attribute中指定的属性。所有Message Key指定对象的，Operating Attribute中指定的所有属性都应该在应答消息中返回。DevAttrQry应答消息中的Operating Attribute的顺序，应该和原消息中Operating Attribute的顺序一致。如果没有任何对象匹配Message Key，那么DevAttrQryRsp消息中不应该（SHALL NOT）返回任何Operating Attribute。这样的消息和对应的应答消息不应该被视为Error。
Portal Group对象决定了Storage Node和portal之间的关系。如果Portal Group的PGT不是NULL，那么在指定的Storage Node和Portal中存在联系；如果PGT为NULL，那么就没有关系。因此，每个Portal Group的PGT的值决定了DevAttrQru应答消息的结构和Storage Node、Portal的顺序。
比如：iSNS数据库中有一个Network Entity，它有两个Portal和两个Nodes。每个Storage Node包含两个Portal Group，针对一个Portal的PGT的值为NULL，针对另一个Portal的PGT不是NULL。一个DevAttrQry消息的Message Key匹配了一个Node，并且Operating Attribute中列出了0长的Node、Portal和PG属性的TLV。应答消息应该（SHALL）首先返回匹配的Node属性，然后是匹配的Portal（对应PGT非NULL的）的属性，最后是Storage Node对应PG的属性。原消息和应答消息中的Operating Attribute中的次序应该是一样的。
如果Message Key中包含的是0长的TLV，那么应答消息应该返回所有匹配对象的请求属性（非Control Node应该（SHALL）考虑DD的注册范围）。如果有多个对象匹配了Message Key，那么应答消息中的每个匹配对象的属性，都应该在下一个匹配对象之前。也就是说，所有匹配的对象都应该遵守上述规则。
比如：iSNS数据库中有一个NetWork Entity，它有两个Portal和三个Node。所有的PG的PGT都为0x00000001。在DevAttrQry消息中，Message Key为一个指定Node类型的0长TLV，并且Operating Attribute中列举了先是Node的属性，然后是Portal的属性。在应答消息中三个Node都应该分别跟随着两个Portal属性（即：N1 P1 P2 N2 P1 P2 N3 P1 P2）。同 样，如果Message Key中是指定Network Entity类型的0长TLV，那么应答消息中就应该是两个Portal的属性跟在三个Node属性的后面(N1 N2 N3 P1 P2)。
如果没有Message Key属性，那么应该返回iSNS数据库中所有匹配的属性（非Control Node应该（SHALL）考虑DD的注册范围）。每个0长TLV的Operating Attribute中指定的属性都应该（SHALL）返回。一种类型的所有属性应该（SHALL）排在另一个匹配属性的前面。
如果：iSNS数据库中有两个NetWork Entity，每个都有两个Portal和两个Node。DevAttrQry消息中没有Message Key，Operating Attribute中先是Portal的属性，然后是Node的属性。那么应答消息的Operating Attribute中就应该是，四个Portal的属性排在四个Node属性之前(P1 P2 P3 P4 N1 N2 N3 N4)。 这种消息理解的不是很清楚，强烈建议察看英文原文。
如果DevAttrQry消息中要求的属性在iSNS数据库中没有值，那么服务器不应该（SHALL NOT）在应答消息中返回这个属性。这种类型的消息不应该（SHALL NOT）被视为错误。
这次和查询Server-Specific属性（Tag：132-384）应该（SHALL）同时使用Source Attribute和Message Key作为识别Key。Operaing attribute应该（SHALL）包括指定Server-Specific属性的TLV。
可以通过在DevAttrQry消息的Operating Attribute中包含没有DD成员的属性(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)或Storage Node的Key或Portal(i.e., iSCSI Name, iSCSI Index,Portal IP Addr, Portal TCP/UDP Port, and Portal Index)来发现DD的成员关系。消息中使用DD成员属性的，应该（SHALL）DD中所有注册和还没有注册的Storage Node或Portal都返回。使用Storage Node或Portal属性的，应该（SHALL）只返回现在已注册的Storage Node或Portal。
DevAttrQry消息应该（SHALL）至少支持一下的属性：
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)
6.5.3 Device Get Next Request （DevGetNext）
DevGetNext消息的类型是0x0003。这个消息能够让iSNS客户端一个一个的取到每个类型的所有对象。
Source Attribute指定消息的发起方，发起方所属DD为取得的范围。
Message Key可能是Entity Identifier (EID), iSCSI Name, iSCSI Index, Portal IP Address and TCP/UDP Port, Portal Index, PG Index, FC Node Name WWNN, 或 FC Port Name WWPN 。如果Message Key中是一个0长的TLV，那么在对应的DevGetNextRsp消息的Message Key中应该（SHALL）返回在iSNS数据库中第一个匹配的对象。如果DevGetNext消息的Message Key是非0TLV，那么DevGetNextRsp消息就应该（SHALL）返回Message Ｋｅｙ所匹配的下一个对象。
如果Message Key匹配的是iSNS数据库中最后一个对象，那么应答消息中应该（SHALL）返回状态码9（No Sush Entry）。
Operating Attribute中指定限定返回的范围，和下一个对象应该返回的属性。所有的Operating Attribute中的属性必须（MUST）是Message Key指定类型的属性。比如：Message Key中是EID，那么Operating Attribute一定不能（MUST NOT）包含任何Portal的属性。
Operating Attribute中的非0长的TLV被用来限定DevGetNext消息的范围。只有对应属性符合Operating Attribute中非0长TLV指定的下一个对象才应该（SHALL）被返回。
Operating Attribute中的0长TLV属性必须（MUST）排列在非0长TLV属性的后面。0长TLV指定下一个对象应该在DevGetNext应答消息中返回的属性。
注意，这里并没有指定iSNS数据库中对象的返回顺序；这个属性应该由实现者自己定义。
iSNS客户端有责任去确保通过DevGetNext消息取得的信息是及时、正确的。在DevGetNext消息完成之前，并不要求iSNS数据库一定不能改变。如果Message Key没有匹配到任何iSNS数据库中的对象，那么Message Key指定的下一个对象的属性还是要返回。比如：在DevGetNext消息成功返回后，一个对象被删除了。这可能导致下一个DevGetNext消息的 Message Key不能够匹配现有的对象。在这种情况下，iSNS数据库中的下一个对象的属性需要返回。
6.5.4 Device Deregister Request（DevDereg）
DevDereg消息的类型是0x0004。这个消息被用来从iSNS数据库中删除对象。一个DevDereg消息能够删除一个或多个对象。注意：被删除的Storage Node依然保留和DD的成员关系，直到有明确的注销这种关系的请求或DD被注销。
在收到DevDereg消息以后，iSNS服务器应该删除所有匹配Operating Attribute属性的对象，以及所有单独依赖于这个对象的子对象。比如：删除一个Network Entity应该删除所有关联的Portal，PG，Storage Node，FCDevice。FC Device应该（SHALL）在所有的关联的Storage Node都被注销后，才能被删除。
DevDereg消息的PDU Payload中只包含Source Attribute和Operating Attribute；没有Message Key。如果Source Attribute中指定的不是Control Node，那么Operating Attribute指定的对象必须属于同一个Network Entity。有效的Operating Attribute列举如下：
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
删除对象后，可能需要发送SCN消息给某些iSNS客户端。试图删除一个不存在的对象不应该（SHALL）被视为Error。如果一个Network Entity的所有Node和Portal都被删除了，那么这个Network Entity应该（SHALL）也被删除。如果PG关联的Portal和iSCSI Storage Node都已经被删除，那么这个PG也应该（SHALL）被删除。只有PG对应的Portal或iSCSI Storage Node还没有被删除，那么PG也不应该（SHALL）被删除。如果被删除的Storage Node或Portal随后别重新注册，那么PG关联的这个对象和已存在的Portal或Storage Node的关系应该被恢复。
6.5.5 SCN Register Request （SCNReg）
SCNReg消息类型是0x0005。State Chang Notification Registration Request（SCNReg）消息能够让iSNS客户端为一个Storage Node注册能够收到State Change Notification（SCN）消息。
SCN消息将一个Storage Node的变更，通知给它所属的DD内的任何Storage Node。如果Storage Node是一个Control Node，那么它应该（SHALL）受到整个网络中所有的变更。尽管SCNReg消息设置了SCN Bitmap字段，但是也要求DevAttrReg消息为Portal注册了收SCN 消息的TCP/UDP Port。有一个Storage Node，它对应的所有Portal都没有注册SCN Port；如果为他发送SCNReg消息，那么就应该（SHALL）通过状态码17（SCN Registration Rejected）来拒绝。
SCNReg消息的PDU Payload包含Source Attribute，Message Key，Operating Attrbute。有效的Message Key列举如下：
Valid Message Key Attributes for SCNReg
---------------------------------------
iSCSI Name
FC Port Name WWPN
Message Key中指定的iSCSI Name或FC Port Name WWPN指定的对象被注册了SCN消息。每个SCNReg消息应该（SHALL）最多注册一个Node。
Operating Attribute中只包含了一个SCN Bitmap属性，并且这个属性总是iSNS数据库中的对应字段。这个Bitmap指明了Node注册的SCN Event的类型。
注意：这个Bitmap指明了SCN注册的是普通或管理SCN。Control Node可以注册管理SCN；bu支持Control Node功能的iSNS客户端一定不能（MUST NOT）注册管理SCN。注册了Management SCNs的Control Node能够收到每个由iSNS服务器产生的SCN消息的拷贝。推荐：只有当希望保存iSNS服务器的资源时，才需要注册Management SCN。另外：注册的管理SCN消息的Control Node，应该准备接受大量的SCN消息通讯。
6.5.6 SCN Deregister Request （SCNDereg）
SCNDereg消息类型是0x0006。SCNDereg消息可以让iSNS客户端停止接受SCN消息。
SCNDereg消息的PDU Payload包含Source Attribute和Message Key。有效的Message Key属性如下：
Valid Message Key Attributes for SCNDereg
-----------------------------------------
iSCSI Name
FC Port Name WWPN
Message Key中指定的iSCSI Name或FC Port Name WWPN指定的对象被注销SCN消息。对应Node的SCN Bitmap应该被清空。每个SCNReg消息应该（SHALL）最多注销一个Node。SCNDereg 消息中没有Operating Attribute。
6.5.7 SCN Event (SCNEvent)
SCNEvnet消息类型是0x0007。iSNS客户端通过发送SCNEvent消息去舀起iSNS服务器产生一个SCN消息。服务器通过发送SCN消息，通知SCNEvent发起方对应DD内的iFCP、iSCSI和Control Node。
当Node注册或注销时，服务器自动发送多数的SCN消息。当网络管理软件或Control Node改变了iSNS服务器中的DD成员关系时，服务器也会发送SCN消息。当时，iSNS客户端也能通过SCNEvent消息触发一个SCN消息。
SCNEvent消息的PDU Payload中包含一个Source Attribute、Message Key和Operating Attribute。可用的Message Key属性有：
Valid Message Key Attributes for SCNEvent
-----------------------------------------
iSCSI Name
FC Port Name WWPN
Operating Attribute中应该（SHALL）包含一个SCN Event Bitmap属性。这个Bitmap指明了产生SCNEvent事件的类型。
6.5.8 State Change Notification （SCN）
SCN消息类型是0x0008。SCN消息由iSNS服务器发出，通知注册的Storage Node的变更。有两种类型的SCN注册：普通注册和管理注册。普通SCN在DD范围内通知变更。管理SCN向注册管理SCN的Control Node通知整个网络中的所有变更。
如果没有TCP连接打开在接受SCN消息的端口上，那么SCN消息就应该（SHALL）通过Portal发送给Storage Node。如果一个Storage Node有多个Portal注册了SCN Port，那么SCN应该（SHALL）通过其中的任意一个发送，指定的Portal并不隶属于SCN。
事件的类型能够触发一个SCN消息，SCN消息中的信息由Storage Node注册的SCN Event Bitmap决定。iSCSI Node SCN Bitmap在Section6.4.4中定义，iFCP SCN Bitmap在Section 6.6.12中定义。
SCN PDU Payload的格式如下：
Destingation Attribute是接受方的标志符，可以使iSCSI Name或FC Port Name。
Timestamp 使用的是Section6.2.4中描述的Timestamp TLV格式，指出生成SCN消息的时间。
Source SCN Bitmap指明SCN通知的类型(i.e., regular or management SCN)，和引起SCN消息的事件的类型；它可能与iSNS服务器中保存的原SCN Bitmap没有关系。
如果SCN是一个Management SCN，那么SCN消息应该（SHALL）列举出引发这次SCN的DD和DDS的DD ID和DDS ID。如果有这种额外的属性(i.e., DD_ID and/or DDS_ID)，应该直接跟在iSCSI Name或FC Port Name后面，并且要在下一个SCN Bitmap之前。SCN Bitmap是在SCN消息中分割多个State Change Notification的分隔符。
比如：一个通知某个iSCSI Target新注册了一个Portal的普通SCN消息，应该在Source Attribute（对应Node的iSCSI Name）后跟着SCN Bitmap。但是如果是一个管理SCN消息，iSCSI Name后就应该跟着DD ID，以便消息的接受方能够找到对应的反起方。如果存在DDS，那么为了准确地定位DDS ID也应该包含在其中。
DD和DDS的变更也会触发管理SCN。这种情况下，对应DD_ID和DDS_ID应该跟在SCN Bitmap后面。
比如：一个发向Control Node的管理SCN，如果通知的是一个DDS中新建了一个DD，那么对应的DD ID和DDS ID都应该保存在Source Attribute中。
SCN Bitmap的更多信心可参照Section6.4.4和Section6.6.12
6.5.9 DD Register (DDReg)
DDReg的消息类型是0x0009。这个消息被用来创建一个新DD，或更新一个已存在DD Symbolic Name和DD Features Attribute，或添加DD成员。
DD由DD ID唯一定义。DD 的注册属性在Section 6.11中描述。DDRet消息的PDU Payload中包含Source Attribute、可选的Message Key和Operating Attribute。
如果有Message Key的话，其中就应该包含被注册DD的DD ID。如果Message Key中包含的DD ID在iSNS数据库中已经存在，那么DDReg消息就应该（SHALL）更新一个已存在的DD。如果Message Key中DD ID不能匹配一个已存在的DD，那么iSNS服务器应该（SHALL）返回状态码3（Invalid Registration）拒绝DDReg消息。如果在Message Key和Operating Attribute中都有DD ID，那么这两个DD ID必须（MUST）一致。
如果一个DDReg消息没有Message Key应该（SHALL）是试图创建一个新的DD。如果Operating Attribute中包含的DD ID（非0长TLV），那么新建的DD应该（SHALL）关联和这个DD ID上。否则，如果Operating Attribute中没有包含DD ID，或者包含的DD ID为0长TLV，那么iSNS服务器应该（SHALL）分配一个DD ID。分配的DD ID应该在DDReg应答消息中返回。Operating Attribute中也可以包含添加到DD的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。还可以包含DD的DD Symbolic Name和DD Feature。
这个消息应该（SHALL）给DD ID指定的DD，添加任何DD Member。如果Operating Attribute中包含DD Feature属性，那么它应该（SHALL）保存在iSNS服务器中指定DD的Feature列表中。如果Operating Attribute中包含DD Sysmbolic Name，并且它的值为数据库中唯一，那么这个值就应该（SHALL）保存在iSNS服务器中指定DD的DD Symbolic Name中。如果DD Symbolic Name不是唯一的，那么iSNS服务器应该（SHALL）使用状态码3（Invalid Registration）拒绝这个消息。
当注册一个新的DD时，如果没有提供DD Symbolic Name或者提供的是0长TLV，那么iSNS服务器应该（SHALL）提供一个唯一的DD Symbolic Name值。新分配的DD Symbolic Name值应该（SHALL）在DDRegRsp消息中返回。
当注册一个新的DD时，如果Operating Attribute中没有包含DD Feature，那么iSNS服务器应该（SHALL）分配一个默认值。DD Feature的默认值是0。
Operating Attribute中的DD Member iSCSI Name, DD Member iFCP Node, DD Member Portal IP Address, and DD Member TCP/UDP Port Number不需要匹配iSNS数据库中已存在的对象。这就容许一个没有注册的Storage Node添加到一个DD中。一个Storage Node或Portal即使在网络中还不可用，它也能够被添加到DD中。
如果Operating Attribute中包含的DD Member iSCSI Name对应的Storage Node还没有注册到iSNS数据库中，那么iSNS服务器必须（MUST）给他分配一个iSCSI Node Index。这个分配的iSCSI Node Index应该（SHALL）在DDRegRsp消息中作为DD Member iSCSI Node Index返回。当这个Storage Node注册时，这个iSCSI Node Index值应该（SHALL）分配给这个Storage Node。
如果Operating Attribute中包含的DD Member Portal IP Address和DD Member Portal TCP/UDP对应的Portal还没有注册到iSNS数据库中，那么iSNS服务器必须（MUST）给他分配一个Portal Index。这个分配的Portal Index应该（SHALL）在DDRegRsp消息中作为DD Member Portal Index返回。当这个Portal注册时，这个Portal Index值应该（SHALL）分配给这个Portal。
Operating Attribute中提供的DD Member iSCSI Node Index和DD Member Portal Index属性，必须（MUST）匹配iSNS数据库中已经存在的iSCSI Node Index 或 Portal Index。而且，只有当Storage Node或Portal已经注册到iSNS数据库中以后，才能使用DD Member iSCSI Node Index和DD Member Portal Index添加一个Storage Node或Portal到DD中。
6.5.10 DD Deregister （DDDereg）
DDDereg的消息类型是0x000A。这个消息容许iSNS客户端去注销DD和删除DD的成员。
DD以DD ID作为标示，DD 的注册属性在Section 6.11中描述。DDDereg消息的PDU Payload包含Source Attribute，Message Key和一个可选的Operating Attribute。
Message Key中包含了将要被删除或删除成员的DD的DD ID。如果DD ID匹配了一个已存在的DD，并且没有Operating Attribute，那么这个DD应该（SHALL）被删除，并返回成功的状态码。刚被删除的DD的成员应该（SHALL）继续保存在iSNS数据库中，没有了和刚删除DD的成员关系。
如果DD匹配了一个已存在的DD，并且Operating Attribute匹配了一个DD的成员，那么这个DD成员应该（SHALL）被删除，并返回成功的状态码。
如果Operating Attribute中的DD Member iSCSI Name匹配的Storage Node，还没有被注册到iSNS数据库中或包含在另一个DD中，那么这个Storage Node和之前分配的iSCSI Node Index的连接应该（SHALL）被删除。这个预分配的iSCSI Node Index不再与特定的iSCSI Name有联机，并且可以被再次分配。
如果Operating Attribute中的DD Mamber Portal IP Address和DD Member TCP/UDP Port匹配的Portal，还没有注册到iSNS数据库中或包含在另一个DD中，那么这个Portal和之前分配的Portal Index的连接应该（SHALL）被删除。这个Portal Index可以再次分配了。
试图注销一个不存在的DD应该（SHALL）不湿为错误。
6.5.11 DDS Register （DDSReg）
DDSReg的消息类型是0x000B。这个消息容许iSNS客户端去建立一个新的DDS、更新已存在DDS Symbolic Name和DDS Status，或添加一个DDS成员。
DDS由DDS ID唯一识别，DDS的注册属性在Section6.11.1中描述。
DDSReg消息的PDU Payload包含Source Attribute、可选的Message Key和Operating Attribute。
Message Key中包含了被注册或修改的DDS的DDS ID。如果DDS ID匹配了一个iSNS数据库中已存在的DDS，那么DDSReg消息应该（SHALL）去更新这个DDS。如果DDS ID不能匹配一个已存在的DDS，那么这个消息应该（SHALL）消息通过状态码3（Invalid Registration）来拒绝。如果Operating Attribute和Message Key中都有DDS ID，那么两者必须（MUST）一致。
如果DDSReg消息没有Message Key，那么就应该（SHALL）注册一个新的DDS。如果Operating Attribute中包含了一个非0长TLV的DDS ID，那么新注册的DDS就应该关联到这个DDS ID上。如果Operating Attribute没有包含DDS ID，或包含的DDS ID为0长TLV，那么iSNS服务器应该（SHALL）分配一个DDS ID。这个分配的DDS ID应该在DDSReg应答消息中返回。Operating Attribute中也可以包含DDS Symbolic Name、DDS Status和被添加的DD的DD ID。
当注册一个新的DDS时，如果Operating Attribute中包含的DDS Symbolic Name在iSNS数据库中唯一的话，那么这个值就应该（SHALL）作为新的DDS的DDS Symbolic Name保存到iSNS数据库中。如果这个值不是唯一的那么，就应该（SHALL）使用状态码3（Invalid Registration）拒绝注册。
当注册一个新的DDS时，如果Operating Attribute中没有包含DDS Symbolic Name或包含的是0长TLV，那么iSNS应该（SHALL）提供一个唯一的DDS Symbolic Name。这个提供的值，应该在DDSRegRsp消息中返回。
这个消息应该（SHALL）将Operating Attribute中列出的DD ID，都添加到Message Key指定的DDS中。如果Operating Attribute中的DDS Symbolic Name值唯一，也应该（SHALL）保存到iSNS数据库中。
如果Operating Attribute列出的DD不存在，那么应该（SHALL）用这个DD ID注册一个新的DD。这时，新注册的DD的DD Symbolic Name应该（SHALL）由iSNS服务器分配，DD Feature应该（SHALL）为默认的0。这些分配的值应该（SHALL）在DDSRegRsp消息中返回。
6.5.12 DDS Deregister （DDSDereg）
DDSDereg的消息类型是0x000C。这个消息容许iSNS客户端注销一个已存在的DDS或删除DDS中的DD。
DDSDereg消息的PDU Payload中包含Source Attribute，Message Key和可选的Operating Attribute。
Message Key中指定的DDS ID，指明了将要被删除或删除成员的DDS。如果DDS ID匹配了一个已存在的DDS，并且没有Operating Attribute，那么这个DDS应该（SHALL）被删除，并返回成功状态码。所有被删除DDS的成员应该继续包括在iSNS数据库中，但是没有了成员关系。
如果DDS ID匹配了一个DDS，并且Operating Attribute也匹配了DDS成员，那么DDS成员应该（SHALL）从DDS中删除，并返回成功状态码。
注销一个不存在的DDS，应该（SHALL）不被认为是错误。
6.5.13 Entity Status Inquiry（ESI）
ESI的消息类型是0x000D。这个消息由iSNS服务器发送，以确认iSNS客户端的Portal是否可达、可用。ESI消息发送给ESI UDP端口，或通过TCP连接发送，这取决于注册时选择的通讯方式。
ESI消息的PDU Payload以TLV格式包含以下的属性，iSNS Timestamp，EID，Portal IP Address和Portal TCP/UDP Port。具体的格式如下：
如果Portal没有成功的应答服务器决定的ESI消息，那么iSNS服务器应该（SHALL）从iSNS数据库中删除Portal。如果关联的Network Entity已经没有可用的Portal，那么这个Network Entity就应该（SHALL）被删除。对应的SCN，应该（SHALL）被触发。
6.5.14 NameService Heartbeat （Heartbeat）
如果使用了这个消息，那么这个消息只能由当前iSNS服务器发送。它能够让iSNS客户端和备份服务器通过监视Broadcast或Multicast，来获取主服务器和备份服务器的IP地址。也容许相关部门去监视主服务器的iSNS服务器。
这个消息不时TLV格式的，并且也没有应答消息。
Active Server IP Address：主服务器的IPv6格式的IP地址。当包含一个IPv4的地址时，按照[ RFC2373]格式转换。
Active TCP Port：主服务器的TCP端口。
Active UDP Port：主服务器的UDP端口，或0。
Interval：Heartbeat的秒间隔。
Counter：当一个服务器可用时，从0凯死后。每发送Hearbeat消息就递增一次。
Backup Servers：备份服务器的个数。每个备份服务器的IP地址，TCP Port，UDP Port跟在其后。如果有备份服务器，那么主服务器也应该（SHOULD）在其中。
余下的Verdor-Specific。提供者可能使用这个另外的自动，协调多个iSNS服务器，或实现特定的功能。
6.5.15 Request FC_DOMAIN_ID （RqstDomId）
RqstDomId的消息类型是0x0011。
6.5.16 Release FC_DOMAIN_ID (RlseDomId)
RlseDomId的消息类型是0x12。
6.5.17 Get FC_DOMAIN_IDs （GetDomId）
GetDomId的消息类型是0x0013。
DevAttrRet消息的类型为：0x0001。DevAttrRet消息可以让iSNS客户端注册一个新的对象或修改已存在对象。FLAGS中的Replace Bit的值决定DevAttrReg消息时更新还是覆盖一个已存在的注册。
Source Attribute 指明DevAttrReg消息的发起端。
Message Key指明需要注册的对象。它必须（MUST）包含一个能够识别出这个对象的Key属性。这个对象的所有属性和关联对象的所有属性必须（MUST）包含在Operating Attributes中。这个识别对象的Key属性，也必须（MUST）保存在Operating Attribute中。
如果Message Key包含一个EID，并且这个EID在iSNS数据库中不存在，那么DevAttrReg消息就应该（SHALL）用这个EID创建一个新的Entity和制定属性的所有对象。这时，Replace Bit应该（SHALL）被忽略。
如果Message key没有包含EID，并且Message Key中的其他属性不能匹配已注册的对象，那么这个DevAttrReg消息就应该（SHALL）用状态码3（Invalid Registration）来拒绝。
如果Message Key不存在，那么DevAttrReg消息就应该直接注册一个新的NetWork Entity。这种情况下Replace Bit应该（SHALL）被忽略；一个新的Network Entity应该（SHALL）被创建。现有的实体、他们的对象和之间的关系都不变。
Replace Bit决定了针对DevAttrReg消息中指定的Object的行为。Replace Bit只对DevAttrReg消息有效，其它的消息都应该忽略这个Bit。
如果Replace Bit被设置，那么在Operation Attribute中制定的Objects、Attributes、Relationships应该（SHALL）替换Message Key指定对象。这个对象和所有的关联对象都应该（SHALL）被注销，并且对应的SCN消息也应该（SHALL）由iSNS服务器发出。然后，Operating Attribute中列出的对象应该替换刚刚注销的对象。并且应该（SHALL）为新注册的对象发送另外的SCN消息。不是Message Key所指对象，或其关联对象的必须不能（MUST NOT）有任何改变。
如果Replace Bit没有被设置，那么就应该更新Message Key指定的对象和关联对象。已存在的对象和关系必须不能（MUST NOT）被改变。对于已存在的对象，Key属性必须不能（MUST NOT）被修改，但是新的关联对象可以（MAY）被添加。
Operating Attribute中描述的对象、属性和他们的关系就是用来被注册的。多个相关的对象和属性可能（MAY）在一个DevAttrRet消息中注册。消息中对象的次序指明了要注册对象的结构和他们之间的关系。Operating Attribute中必须（MUST）至少包含一个对象。其它的对象必须（MUST）是这个对象的从属对象。每个对象的Key属性必须（MUST）在Non-Key属性之前。一个对象只能在Operating Attribute中出现一次。如果Souce Attribute中指明的不是一个Control Node，那么所有Operating Attribute中的对象必须（MUST）是和Source Attribute中指明的同一个Network Entity中的对象。
比如，建立一个Network Entity和它的Portal、Storage Node之间的关系，那么Operating Attribute中先保存Network Entity的Key和Non-Key属性，然后是Portal的的Key和Non-Key属性，最后是Storage Node的Key和Non-Key属性。同样，如果有FC Device的话，就应该跟在Storage Node的对象之后。
当相关的Portal或iSCSI Node在注册时，会注册新的PG对象。在DevAttrReg消息中一个直接的PG对象的注册可能跟在Portal或iSCSI Node的后面。当一个Portal被注册时，Portal属性的后面可能（MAY）直接跟的就是PGT属性。PGT属性后面跟着的可以（SHALL）是使用这个PGT值得Portal的iSCSI Node的iSCSI Name的集合。其它的PGT和他们对应的iSCSI Name的属性，可能（MAY）跟在后面。在Operating Attribute中直接指定的PGT的值被分配给新注册的Portal和关联的iSCSI Storage Node对应的PG。
当一个iSCSI Storage Node被注册时，Storage Node的属性可能直接跟在PGT属性的后面。PGT属性可能（SHALL）跟在使用这个PGT值的iSCSI Storage Node对应的Portal的IP地址和TCP/UDP端口号对的集合后面。其它的和注册的Storage Node向关联的PGT和对应的Portal的IP地址和TCP/UDP端口对可能（MAY）跟在后面。这个PGT值被分配给新注册的iSCSI Storage Node和关联的Portal（s）对应的PG对象。
如果Storage Node或Portal的注册中没有包含PGT，并且也没有一个PGT值在之前被注册，那么对应的PG对象应该（SHALL）用值0x00000001注册。如果一个注册消息中的PGT值为一个0长度的TLV，那么对应的PG对象应该被注册为NULL。在一个更新注册消息中的0长TLV将用NULL覆盖已存在的PGT，这说明在Storage Node 和 Portal中没有关系。
在一个DevAttrReg消息中最多只能新建或更新一个Network Entity。因此，Operating Attribute中一定不能（MUST NOT）包含多于一个Network Entity的对象。但是Operating Attribute中列出的从属于一个Network Entity的Portal、Storage Node、FC Device没有多限制。
如果在Message Key和Operating Attribute没有提供一个EID属性，或提供的EID长度为0，那么iSNS服务器应该（SHALL）为新注册的Network Entity提供一个唯一的EID。这个EID应该（SHALL）在应答消息中返回。如果Message Key和Operating Attribute中的EID不是iSNS数据库中已存在的，那么应该（SHALL）这个EID注册一个新的Network Entity。最后，如果Message Key和Operating Attribute中的EID和ISNS数据库中的某个对象的EID一样，那么Operating Attibute中列出的对象、属性和关系应该被追加在这个已存在的Network Entity中。
一个注册新Network Entity的消息必须（MUST）最少包含一个Portal或一个Storage Node。如果没有就应该（SHALL）视为无效，并返回错误码3（Invalid Registration）。
如果一个iSNS服务器不支持某些注册，比如PG的注册，那么服务器应该（SHALL）返回状态码23（Registration Feature Not Supported）。
注意：iSNS服务器可能修改或拒绝一些注册的属性，如：ESI Interval。另外，iSNS服务器可能为一些没有指定的属性分配值，如EID、WWNN Token。
6.5.2、Device Attribute Query Request（DevAttrQry）
DevAttrQry的消息类型是0x0002。DevAttrQry消息可以让iSNS客户端查询iSNS服务器上的对象属性。
Source Attribute指明发起方。如果发起方不是Control Node，那么它只能查询它属于的那个DD中的对象。DevAttrQry消息应该（SHALL）仅仅返回发起方同DD的Storage Node属性和它的关联父-子对象的属性。
Message Key可能包含Key或Non-Key属性，或者什么属性也没有。如果Message Key中有多个属性，那么它们必须（MUST）输入同一种对象（比如，IP Address和TCP/UDP Port都属于Portal）。一个包括Non-Key属性的Message Key可能会匹配这个对象中的多个实例。Message Key中有一个0长的TLV，指定查询的范围是所有的TLV指定对象类型的对象。一个空的Messag Key指定查询的范围是数据库中所有发起方可能查询的对象。
DevAttrQry应答消息在Operating Attribute中列出了原DevAttrQry消息中Message Key属性所指定对象的属性。DevAttrQry消息中的Operating Attribute中包含的0长的TLV，指出需要DevAttrQry应答消息中需要返回的属性。DevAttrQry消息中的Message Key为0长TLV时，指出返回所有符合Message Key条件的对象的，Operating Attribute中指定的属性。
如果Message Key中是一个非0长TLV时，DevAttrQryRsp消息应该（SHALL）返回符合Message Key的对象的Operating Attribute中指定的属性。所有Message Key指定对象的，Operating Attribute中指定的所有属性都应该在应答消息中返回。DevAttrQry应答消息中的Operating Attribute的顺序，应该和原消息中Operating Attribute的顺序一致。如果没有任何对象匹配Message Key，那么DevAttrQryRsp消息中不应该（SHALL NOT）返回任何Operating Attribute。这样的消息和对应的应答消息不应该被视为Error。
Portal Group对象决定了Storage Node和portal之间的关系。如果Portal Group的PGT不是NULL，那么在指定的Storage Node和Portal中存在联系；如果PGT为NULL，那么就没有关系。因此，每个Portal Group的PGT的值决定了DevAttrQru应答消息的结构和Storage Node、Portal的顺序。
比如：iSNS数据库中有一个Network Entity，它有两个Portal和两个Nodes。每个Storage Node包含两个Portal Group，针对一个Portal的PGT的值为NULL，针对另一个Portal的PGT不是NULL。一个DevAttrQry消息的Message Key匹配了一个Node，并且Operating Attribute中列出了0长的Node、Portal和PG属性的TLV。应答消息应该（SHALL）首先返回匹配的Node属性，然后是匹配的Portal（对应PGT非NULL的）的属性，最后是Storage Node对应PG的属性。原消息和应答消息中的Operating Attribute中的次序应该是一样的。
如果Message Key中包含的是0长的TLV，那么应答消息应该返回所有匹配对象的请求属性（非Control Node应该（SHALL）考虑DD的注册范围）。如果有多个对象匹配了Message Key，那么应答消息中的每个匹配对象的属性，都应该在下一个匹配对象之前。也就是说，所有匹配的对象都应该遵守上述规则。
比如：iSNS数据库中有一个NetWork Entity，它有两个Portal和三个Node。所有的PG的PGT都为0x00000001。在DevAttrQry消息中，Message Key为一个指定Node类型的0长TLV，并且Operating Attribute中列举了先是Node的属性，然后是Portal的属性。在应答消息中三个Node都应该分别跟随着两个Portal属性（即：N1 P1 P2 N2 P1 P2 N3 P1 P2）。同 样，如果Message Key中是指定Network Entity类型的0长TLV，那么应答消息中就应该是两个Portal的属性跟在三个Node属性的后面(N1 N2 N3 P1 P2)。
如果没有Message Key属性，那么应该返回iSNS数据库中所有匹配的属性（非Control Node应该（SHALL）考虑DD的注册范围）。每个0长TLV的Operating Attribute中指定的属性都应该（SHALL）返回。一种类型的所有属性应该（SHALL）排在另一个匹配属性的前面。
如果：iSNS数据库中有两个NetWork Entity，每个都有两个Portal和两个Node。DevAttrQry消息中没有Message Key，Operating Attribute中先是Portal的属性，然后是Node的属性。那么应答消息的Operating Attribute中就应该是，四个Portal的属性排在四个Node属性之前(P1 P2 P3 P4 N1 N2 N3 N4)。 这种消息理解的不是很清楚，强烈建议察看英文原文。
如果DevAttrQry消息中要求的属性在iSNS数据库中没有值，那么服务器不应该（SHALL NOT）在应答消息中返回这个属性。这种类型的消息不应该（SHALL NOT）被视为错误。
这次和查询Server-Specific属性（Tag：132-384）应该（SHALL）同时使用Source Attribute和Message Key作为识别Key。Operaing attribute应该（SHALL）包括指定Server-Specific属性的TLV。
可以通过在DevAttrQry消息的Operating Attribute中包含没有DD成员的属性(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)或Storage Node的Key或Portal(i.e., iSCSI Name, iSCSI Index,Portal IP Addr, Portal TCP/UDP Port, and Portal Index)来发现DD的成员关系。消息中使用DD成员属性的，应该（SHALL）DD中所有注册和还没有注册的Storage Node或Portal都返回。使用Storage Node或Portal属性的，应该（SHALL）只返回现在已注册的Storage Node或Portal。
DevAttrQry消息应该（SHALL）至少支持一下的属性：
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)
6.5.3 Device Get Next Request （DevGetNext）
DevGetNext消息的类型是0x0003。这个消息能够让iSNS客户端一个一个的取到每个类型的所有对象。
Source Attribute指定消息的发起方，发起方所属DD为取得的范围。
Message Key可能是Entity Identifier (EID), iSCSI Name, iSCSI Index, Portal IP Address and TCP/UDP Port, Portal Index, PG Index, FC Node Name WWNN, 或 FC Port Name WWPN 。如果Message Key中是一个0长的TLV，那么在对应的DevGetNextRsp消息的Message Key中应该（SHALL）返回在iSNS数据库中第一个匹配的对象。如果DevGetNext消息的Message Key是非0TLV，那么DevGetNextRsp消息就应该（SHALL）返回Message Ｋｅｙ所匹配的下一个对象。
如果Message Key匹配的是iSNS数据库中最后一个对象，那么应答消息中应该（SHALL）返回状态码9（No Sush Entry）。
Operating Attribute中指定限定返回的范围，和下一个对象应该返回的属性。所有的Operating Attribute中的属性必须（MUST）是Message Key指定类型的属性。比如：Message Key中是EID，那么Operating Attribute一定不能（MUST NOT）包含任何Portal的属性。
Operating Attribute中的非0长的TLV被用来限定DevGetNext消息的范围。只有对应属性符合Operating Attribute中非0长TLV指定的下一个对象才应该（SHALL）被返回。
Operating Attribute中的0长TLV属性必须（MUST）排列在非0长TLV属性的后面。0长TLV指定下一个对象应该在DevGetNext应答消息中返回的属性。
注意，这里并没有指定iSNS数据库中对象的返回顺序；这个属性应该由实现者自己定义。
iSNS客户端有责任去确保通过DevGetNext消息取得的信息是及时、正确的。在DevGetNext消息完成之前，并不要求iSNS数据库一定不能改变。如果Message Key没有匹配到任何iSNS数据库中的对象，那么Message Key指定的下一个对象的属性还是要返回。比如：在DevGetNext消息成功返回后，一个对象被删除了。这可能导致下一个DevGetNext消息的 Message Key不能够匹配现有的对象。在这种情况下，iSNS数据库中的下一个对象的属性需要返回。
6.5.4 Device Deregister Request（DevDereg）
DevDereg消息的类型是0x0004。这个消息被用来从iSNS数据库中删除对象。一个DevDereg消息能够删除一个或多个对象。注意：被删除的Storage Node依然保留和DD的成员关系，直到有明确的注销这种关系的请求或DD被注销。
在收到DevDereg消息以后，iSNS服务器应该删除所有匹配Operating Attribute属性的对象，以及所有单独依赖于这个对象的子对象。比如：删除一个Network Entity应该删除所有关联的Portal，PG，Storage Node，FCDevice。FC Device应该（SHALL）在所有的关联的Storage Node都被注销后，才能被删除。
DevDereg消息的PDU Payload中只包含Source Attribute和Operating Attribute；没有Message Key。如果Source Attribute中指定的不是Control Node，那么Operating Attribute指定的对象必须属于同一个Network Entity。有效的Operating Attribute列举如下：
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
删除对象后，可能需要发送SCN消息给某些iSNS客户端。试图删除一个不存在的对象不应该（SHALL）被视为Error。如果一个Network Entity的所有Node和Portal都被删除了，那么这个Network Entity应该（SHALL）也被删除。如果PG关联的Portal和iSCSI Storage Node都已经被删除，那么这个PG也应该（SHALL）被删除。只有PG对应的Portal或iSCSI Storage Node还没有被删除，那么PG也不应该（SHALL）被删除。如果被删除的Storage Node或Portal随后别重新注册，那么PG关联的这个对象和已存在的Portal或Storage Node的关系应该被恢复。
6.5.5 SCN Register Request （SCNReg）
SCNReg消息类型是0x0005。State Chang Notification Registration Request（SCNReg）消息能够让iSNS客户端为一个Storage Node注册能够收到State Change Notification（SCN）消息。
SCN消息将一个Storage Node的变更，通知给它所属的DD内的任何Storage Node。如果Storage Node是一个Control Node，那么它应该（SHALL）受到整个网络中所有的变更。尽管SCNReg消息设置了SCN Bitmap字段，但是也要求DevAttrReg消息为Portal注册了收SCN 消息的TCP/UDP Port。有一个Storage Node，它对应的所有Portal都没有注册SCN Port；如果为他发送SCNReg消息，那么就应该（SHALL）通过状态码17（SCN Registration Rejected）来拒绝。
SCNReg消息的PDU Payload包含Source Attribute，Message Key，Operating Attrbute。有效的Message Key列举如下：
Valid Message Key Attributes for SCNReg
---------------------------------------
iSCSI Name
FC Port Name WWPN
Message Key中指定的iSCSI Name或FC Port Name WWPN指定的对象被注册了SCN消息。每个SCNReg消息应该（SHALL）最多注册一个Node。
Operating Attribute中只包含了一个SCN Bitmap属性，并且这个属性总是iSNS数据库中的对应字段。这个Bitmap指明了Node注册的SCN Event的类型。
注意：这个Bitmap指明了SCN注册的是普通或管理SCN。Control Node可以注册管理SCN；bu支持Control Node功能的iSNS客户端一定不能（MUST NOT）注册管理SCN。注册了Management SCNs的Control Node能够收到每个由iSNS服务器产生的SCN消息的拷贝。推荐：只有当希望保存iSNS服务器的资源时，才需要注册Management SCN。另外：注册的管理SCN消息的Control Node，应该准备接受大量的SCN消息通讯。
6.5.6 SCN Deregister Request （SCNDereg）
SCNDereg消息类型是0x0006。SCNDereg消息可以让iSNS客户端停止接受SCN消息。
SCNDereg消息的PDU Payload包含Source Attribute和Message Key。有效的Message Key属性如下：
Valid Message Key Attributes for SCNDereg
-----------------------------------------
iSCSI Name
FC Port Name WWPN
Message Key中指定的iSCSI Name或FC Port Name WWPN指定的对象被注销SCN消息。对应Node的SCN Bitmap应该被清空。每个SCNReg消息应该（SHALL）最多注销一个Node。SCNDereg 消息中没有Operating Attribute。
6.5.7 SCN Event (SCNEvent)
SCNEvnet消息类型是0x0007。iSNS客户端通过发送SCNEvent消息去舀起iSNS服务器产生一个SCN消息。服务器通过发送SCN消息，通知SCNEvent发起方对应DD内的iFCP、iSCSI和Control Node。
当Node注册或注销时，服务器自动发送多数的SCN消息。当网络管理软件或Control Node改变了iSNS服务器中的DD成员关系时，服务器也会发送SCN消息。当时，iSNS客户端也能通过SCNEvent消息触发一个SCN消息。
SCNEvent消息的PDU Payload中包含一个Source Attribute、Message Key和Operating Attribute。可用的Message Key属性有：
Valid Message Key Attributes for SCNEvent
-----------------------------------------
iSCSI Name
FC Port Name WWPN
Operating Attribute中应该（SHALL）包含一个SCN Event Bitmap属性。这个Bitmap指明了产生SCNEvent事件的类型。
6.5.8 State Change Notification （SCN）
SCN消息类型是0x0008。SCN消息由iSNS服务器发出，通知注册的Storage Node的变更。有两种类型的SCN注册：普通注册和管理注册。普通SCN在DD范围内通知变更。管理SCN向注册管理SCN的Control Node通知整个网络中的所有变更。
如果没有TCP连接打开在接受SCN消息的端口上，那么SCN消息就应该（SHALL）通过Portal发送给Storage Node。如果一个Storage Node有多个Portal注册了SCN Port，那么SCN应该（SHALL）通过其中的任意一个发送，指定的Portal并不隶属于SCN。
事件的类型能够触发一个SCN消息，SCN消息中的信息由Storage Node注册的SCN Event Bitmap决定。iSCSI Node SCN Bitmap在Section6.4.4中定义，iFCP SCN Bitmap在Section 6.6.12中定义。
SCN PDU Payload的格式如下：
+----------------------------------------+所有PDU Payload属性都是以TLV格式保存的。
| 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) |
+----------------------------------------+
| . . . |
+----------------------------------------+
Destingation Attribute是接受方的标志符，可以使iSCSI Name或FC Port Name。
Timestamp 使用的是Section6.2.4中描述的Timestamp TLV格式，指出生成SCN消息的时间。
Source SCN Bitmap指明SCN通知的类型(i.e., regular or management SCN)，和引起SCN消息的事件的类型；它可能与iSNS服务器中保存的原SCN Bitmap没有关系。
如果SCN是一个Management SCN，那么SCN消息应该（SHALL）列举出引发这次SCN的DD和DDS的DD ID和DDS ID。如果有这种额外的属性(i.e., DD_ID and/or DDS_ID)，应该直接跟在iSCSI Name或FC Port Name后面，并且要在下一个SCN Bitmap之前。SCN Bitmap是在SCN消息中分割多个State Change Notification的分隔符。
比如：一个通知某个iSCSI Target新注册了一个Portal的普通SCN消息，应该在Source Attribute（对应Node的iSCSI Name）后跟着SCN Bitmap。但是如果是一个管理SCN消息，iSCSI Name后就应该跟着DD ID，以便消息的接受方能够找到对应的反起方。如果存在DDS，那么为了准确地定位DDS ID也应该包含在其中。
DD和DDS的变更也会触发管理SCN。这种情况下，对应DD_ID和DDS_ID应该跟在SCN Bitmap后面。
比如：一个发向Control Node的管理SCN，如果通知的是一个DDS中新建了一个DD，那么对应的DD ID和DDS ID都应该保存在Source Attribute中。
SCN Bitmap的更多信心可参照Section6.4.4和Section6.6.12
6.5.9 DD Register (DDReg)
DDReg的消息类型是0x0009。这个消息被用来创建一个新DD，或更新一个已存在DD Symbolic Name和DD Features Attribute，或添加DD成员。
DD由DD ID唯一定义。DD 的注册属性在Section 6.11中描述。DDRet消息的PDU Payload中包含Source Attribute、可选的Message Key和Operating Attribute。
如果有Message Key的话，其中就应该包含被注册DD的DD ID。如果Message Key中包含的DD ID在iSNS数据库中已经存在，那么DDReg消息就应该（SHALL）更新一个已存在的DD。如果Message Key中DD ID不能匹配一个已存在的DD，那么iSNS服务器应该（SHALL）返回状态码3（Invalid Registration）拒绝DDReg消息。如果在Message Key和Operating Attribute中都有DD ID，那么这两个DD ID必须（MUST）一致。
如果一个DDReg消息没有Message Key应该（SHALL）是试图创建一个新的DD。如果Operating Attribute中包含的DD ID（非0长TLV），那么新建的DD应该（SHALL）关联和这个DD ID上。否则，如果Operating Attribute中没有包含DD ID，或者包含的DD ID为0长TLV，那么iSNS服务器应该（SHALL）分配一个DD ID。分配的DD ID应该在DDReg应答消息中返回。Operating Attribute中也可以包含添加到DD的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。还可以包含DD的DD Symbolic Name和DD Feature。
这个消息应该（SHALL）给DD ID指定的DD，添加任何DD Member。如果Operating Attribute中包含DD Feature属性，那么它应该（SHALL）保存在iSNS服务器中指定DD的Feature列表中。如果Operating Attribute中包含DD Sysmbolic Name，并且它的值为数据库中唯一，那么这个值就应该（SHALL）保存在iSNS服务器中指定DD的DD Symbolic Name中。如果DD Symbolic Name不是唯一的，那么iSNS服务器应该（SHALL）使用状态码3（Invalid Registration）拒绝这个消息。
当注册一个新的DD时，如果没有提供DD Symbolic Name或者提供的是0长TLV，那么iSNS服务器应该（SHALL）提供一个唯一的DD Symbolic Name值。新分配的DD Symbolic Name值应该（SHALL）在DDRegRsp消息中返回。
当注册一个新的DD时，如果Operating Attribute中没有包含DD Feature，那么iSNS服务器应该（SHALL）分配一个默认值。DD Feature的默认值是0。
Operating Attribute中的DD Member iSCSI Name, DD Member iFCP Node, DD Member Portal IP Address, and DD Member TCP/UDP Port Number不需要匹配iSNS数据库中已存在的对象。这就容许一个没有注册的Storage Node添加到一个DD中。一个Storage Node或Portal即使在网络中还不可用，它也能够被添加到DD中。
如果Operating Attribute中包含的DD Member iSCSI Name对应的Storage Node还没有注册到iSNS数据库中，那么iSNS服务器必须（MUST）给他分配一个iSCSI Node Index。这个分配的iSCSI Node Index应该（SHALL）在DDRegRsp消息中作为DD Member iSCSI Node Index返回。当这个Storage Node注册时，这个iSCSI Node Index值应该（SHALL）分配给这个Storage Node。
如果Operating Attribute中包含的DD Member Portal IP Address和DD Member Portal TCP/UDP对应的Portal还没有注册到iSNS数据库中，那么iSNS服务器必须（MUST）给他分配一个Portal Index。这个分配的Portal Index应该（SHALL）在DDRegRsp消息中作为DD Member Portal Index返回。当这个Portal注册时，这个Portal Index值应该（SHALL）分配给这个Portal。
Operating Attribute中提供的DD Member iSCSI Node Index和DD Member Portal Index属性，必须（MUST）匹配iSNS数据库中已经存在的iSCSI Node Index 或 Portal Index。而且，只有当Storage Node或Portal已经注册到iSNS数据库中以后，才能使用DD Member iSCSI Node Index和DD Member Portal Index添加一个Storage Node或Portal到DD中。
6.5.10 DD Deregister （DDDereg）
DDDereg的消息类型是0x000A。这个消息容许iSNS客户端去注销DD和删除DD的成员。
DD以DD ID作为标示，DD 的注册属性在Section 6.11中描述。DDDereg消息的PDU Payload包含Source Attribute，Message Key和一个可选的Operating Attribute。
Message Key中包含了将要被删除或删除成员的DD的DD ID。如果DD ID匹配了一个已存在的DD，并且没有Operating Attribute，那么这个DD应该（SHALL）被删除，并返回成功的状态码。刚被删除的DD的成员应该（SHALL）继续保存在iSNS数据库中，没有了和刚删除DD的成员关系。
如果DD匹配了一个已存在的DD，并且Operating Attribute匹配了一个DD的成员，那么这个DD成员应该（SHALL）被删除，并返回成功的状态码。
如果Operating Attribute中的DD Member iSCSI Name匹配的Storage Node，还没有被注册到iSNS数据库中或包含在另一个DD中，那么这个Storage Node和之前分配的iSCSI Node Index的连接应该（SHALL）被删除。这个预分配的iSCSI Node Index不再与特定的iSCSI Name有联机，并且可以被再次分配。
如果Operating Attribute中的DD Mamber Portal IP Address和DD Member TCP/UDP Port匹配的Portal，还没有注册到iSNS数据库中或包含在另一个DD中，那么这个Portal和之前分配的Portal Index的连接应该（SHALL）被删除。这个Portal Index可以再次分配了。
试图注销一个不存在的DD应该（SHALL）不湿为错误。
6.5.11 DDS Register （DDSReg）
DDSReg的消息类型是0x000B。这个消息容许iSNS客户端去建立一个新的DDS、更新已存在DDS Symbolic Name和DDS Status，或添加一个DDS成员。
DDS由DDS ID唯一识别，DDS的注册属性在Section6.11.1中描述。
DDSReg消息的PDU Payload包含Source Attribute、可选的Message Key和Operating Attribute。
Message Key中包含了被注册或修改的DDS的DDS ID。如果DDS ID匹配了一个iSNS数据库中已存在的DDS，那么DDSReg消息应该（SHALL）去更新这个DDS。如果DDS ID不能匹配一个已存在的DDS，那么这个消息应该（SHALL）消息通过状态码3（Invalid Registration）来拒绝。如果Operating Attribute和Message Key中都有DDS ID，那么两者必须（MUST）一致。
如果DDSReg消息没有Message Key，那么就应该（SHALL）注册一个新的DDS。如果Operating Attribute中包含了一个非0长TLV的DDS ID，那么新注册的DDS就应该关联到这个DDS ID上。如果Operating Attribute没有包含DDS ID，或包含的DDS ID为0长TLV，那么iSNS服务器应该（SHALL）分配一个DDS ID。这个分配的DDS ID应该在DDSReg应答消息中返回。Operating Attribute中也可以包含DDS Symbolic Name、DDS Status和被添加的DD的DD ID。
当注册一个新的DDS时，如果Operating Attribute中包含的DDS Symbolic Name在iSNS数据库中唯一的话，那么这个值就应该（SHALL）作为新的DDS的DDS Symbolic Name保存到iSNS数据库中。如果这个值不是唯一的那么，就应该（SHALL）使用状态码3（Invalid Registration）拒绝注册。
当注册一个新的DDS时，如果Operating Attribute中没有包含DDS Symbolic Name或包含的是0长TLV，那么iSNS应该（SHALL）提供一个唯一的DDS Symbolic Name。这个提供的值，应该在DDSRegRsp消息中返回。
这个消息应该（SHALL）将Operating Attribute中列出的DD ID，都添加到Message Key指定的DDS中。如果Operating Attribute中的DDS Symbolic Name值唯一，也应该（SHALL）保存到iSNS数据库中。
如果Operating Attribute列出的DD不存在，那么应该（SHALL）用这个DD ID注册一个新的DD。这时，新注册的DD的DD Symbolic Name应该（SHALL）由iSNS服务器分配，DD Feature应该（SHALL）为默认的0。这些分配的值应该（SHALL）在DDSRegRsp消息中返回。
6.5.12 DDS Deregister （DDSDereg）
DDSDereg的消息类型是0x000C。这个消息容许iSNS客户端注销一个已存在的DDS或删除DDS中的DD。
DDSDereg消息的PDU Payload中包含Source Attribute，Message Key和可选的Operating Attribute。
Message Key中指定的DDS ID，指明了将要被删除或删除成员的DDS。如果DDS ID匹配了一个已存在的DDS，并且没有Operating Attribute，那么这个DDS应该（SHALL）被删除，并返回成功状态码。所有被删除DDS的成员应该继续包括在iSNS数据库中，但是没有了成员关系。
如果DDS ID匹配了一个DDS，并且Operating Attribute也匹配了DDS成员，那么DDS成员应该（SHALL）从DDS中删除，并返回成功状态码。
注销一个不存在的DDS，应该（SHALL）不被认为是错误。
6.5.13 Entity Status Inquiry（ESI）
ESI的消息类型是0x000D。这个消息由iSNS服务器发送，以确认iSNS客户端的Portal是否可达、可用。ESI消息发送给ESI UDP端口，或通过TCP连接发送，这取决于注册时选择的通讯方式。
ESI消息的PDU Payload以TLV格式包含以下的属性，iSNS Timestamp，EID，Portal IP Address和Portal TCP/UDP Port。具体的格式如下：
+----------------------------------------+ESI应答消息在原消息的属性后添加了一个Status Code。
| Timestamp |
+----------------------------------------+
| Entity_ID |
+----------------------------------------+
| Portal IP Address |
+----------------------------------------+
| Portal TCP/UDP Port |
+----------------------------------------+
如果Portal没有成功的应答服务器决定的ESI消息，那么iSNS服务器应该（SHALL）从iSNS数据库中删除Portal。如果关联的Network Entity已经没有可用的Portal，那么这个Network Entity就应该（SHALL）被删除。对应的SCN，应该（SHALL）被触发。
6.5.14 NameService Heartbeat （Heartbeat）
如果使用了这个消息，那么这个消息只能由当前iSNS服务器发送。它能够让iSNS客户端和备份服务器通过监视Broadcast或Multicast，来获取主服务器和备份服务器的IP地址。也容许相关部门去监视主服务器的iSNS服务器。
这个消息不时TLV格式的，并且也没有应答消息。
MSb LSbHeartbeat PDU Payload包含以下属性：
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 |
+------------------------------------------------+
Active Server IP Address：主服务器的IPv6格式的IP地址。当包含一个IPv4的地址时，按照[ RFC2373]格式转换。
Active TCP Port：主服务器的TCP端口。
Active UDP Port：主服务器的UDP端口，或0。
Interval：Heartbeat的秒间隔。
Counter：当一个服务器可用时，从0凯死后。每发送Hearbeat消息就递增一次。
Backup Servers：备份服务器的个数。每个备份服务器的IP地址，TCP Port，UDP Port跟在其后。如果有备份服务器，那么主服务器也应该（SHOULD）在其中。
余下的Verdor-Specific。提供者可能使用这个另外的自动，协调多个iSNS服务器，或实现特定的功能。
6.5.15 Request FC_DOMAIN_ID （RqstDomId）
RqstDomId的消息类型是0x0011。
6.5.16 Release FC_DOMAIN_ID (RlseDomId)
RlseDomId的消息类型是0x12。
6.5.17 Get FC_DOMAIN_IDs （GetDomId）
GetDomId的消息类型是0x0013。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
