Network Working Group J. Tseng
Request for Comments: 4171 Riverbed Technology
Category: Standards Track K. Gibbons
McDATA Corporation
F. Travostino
Nortel
C. Du Laney
Rincon Research Corporation
J. Souza
Microsoft
September 2005
Network Working Group J. Tseng
Request for Comments: 4171 Riverbed Technology
Category: Standards Track K. Gibbons
McDATA Corporation
F. Travostino
Nortel
C. Du Laney
Rincon Research Corporation
J. Souza
Microsoft
September 2005
Internet Storage Name Service (iSNS)
Internet存储名称服务（iSNS）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document specifies the Internet Storage Name Service (iSNS) protocol, used for interaction between iSNS servers and iSNS clients, which facilitates automated discovery, management, and configuration of iSCSI and Fibre Channel devices (using iFCP gateways) on a TCP/IP network. iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a capacity similar to that of a storage area network. iSNS facilitates a seamless integration of IP and Fibre Channel networks due to its ability to emulate Fibre Channel fabric services and to manage both iSCSI and Fibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices (using iFCP gateways), or any combination thereof.
本文档指定了用于iSNS服务器和iSNS客户端之间交互的Internet存储名称服务（iSNS）协议，该协议有助于在TCP/IP网络上自动发现、管理和配置iSCSI和光纤通道设备（使用iFCP网关）。iSNS提供了与光纤通道网络中类似的智能存储发现和管理服务，允许商品IP网络以类似于存储区域网络的容量运行。iSNS能够模拟光纤通道结构服务并管理iSCSI和光纤通道设备，因此有助于IP和光纤通道网络的无缝集成。因此，iSNS在由iSCSI设备、光纤通道设备（使用iFCP网关）或其任何组合组成的任何存储网络中都能提供价值。
Table of Contents
目录
1. Introduction................................................... 6
1.1. Conventions Used in This Document........................ 6
1.2. Purpose of This Document................................. 6
2. iSNS Overview.................................................. 6
2.1. iSNS Architectural Components ........................... 7
2.1.1. iSNS Protocol (iSNSP) ........................... 7
2.1.2. iSNS Client...................................... 7
2.1.3. iSNS Server...................................... 7
2.1.4. iSNS Database ................................... 7
2.1.5. iSCSI............................................ 7
2.1.6. iFCP............................................. 7
2.2. iSNS Functional Overview................................. 8
2.2.1. Name Registration Service........................ 8
2.2.2. Discovery Domain and Login Control Service....... 8
2.2.3. State Change Notification Service............... 10
2.2.4. Open Mapping between
Fibre Channel and iSCSI Devices................. 11
2.3. iSNS Usage Model........................................ 11
2.3.1. iSCSI Initiator................................. 12
2.3.2. iSCSI Target.................................... 12
2.3.3. iSCSI-FC Gateway................................ 12
2.3.4. iFCP Gateway.................................... 12
2.3.5. Management Station.............................. 12
2.4. Administratively Controlled iSNS Settings............... 13
2.5. iSNS Server Discovery .................................. 14
2.5.1. Service Location Protocol (SLP)................. 14
2.5.2. Dynamic Host Configuration Protocol (DHCP)...... 14
2.5.3. iSNS Heartbeat Message.......................... 14
2.6. iSNS and Network Address Translation (NAT).............. 14
2.7. Transfer of iSNS Database Records between iSNS Servers.. 15
2.8. Backup iSNS Servers..................................... 17
2.9. Transport Protocols..................................... 19
2.9.1. Use of TCP for iSNS Communication............... 19
2.9.2. Use of UDP for iSNS Communication............... 20
2.9.3. iSNS Multicast and Broadcast Messages........... 20
2.10. Simple Network Management Protocol (SNMP) Requirements.. 21
3. iSNS Object Model............................................. 21
3.1. Network Entity Object .................................. 22
3.2. Portal Object .......................................... 22
3.3. Storage Node Object..................................... 22
3.4. Portal Group Object..................................... 23
3.5. FC Device Object........................................ 24
3.6. Discovery Domain Object................................. 24
3.7. Discovery Domain Set Object............................. 24
3.8. iSNS Database Model..................................... 24
4. iSNS Implementation Requirements.............................. 25
1. Introduction................................................... 6
1.1. Conventions Used in This Document........................ 6
1.2. Purpose of This Document................................. 6
2. iSNS Overview.................................................. 6
2.1. iSNS Architectural Components ........................... 7
2.1.1. iSNS Protocol (iSNSP) ........................... 7
2.1.2. iSNS Client...................................... 7
2.1.3. iSNS Server...................................... 7
2.1.4. iSNS Database ................................... 7
2.1.5. iSCSI............................................ 7
2.1.6. iFCP............................................. 7
2.2. iSNS Functional Overview................................. 8
2.2.1. Name Registration Service........................ 8
2.2.2. Discovery Domain and Login Control Service....... 8
2.2.3. State Change Notification Service............... 10
2.2.4. Open Mapping between
Fibre Channel and iSCSI Devices................. 11
2.3. iSNS Usage Model........................................ 11
2.3.1. iSCSI Initiator................................. 12
2.3.2. iSCSI Target.................................... 12
2.3.3. iSCSI-FC Gateway................................ 12
2.3.4. iFCP Gateway.................................... 12
2.3.5. Management Station.............................. 12
2.4. Administratively Controlled iSNS Settings............... 13
2.5. iSNS Server Discovery .................................. 14
2.5.1. Service Location Protocol (SLP)................. 14
2.5.2. Dynamic Host Configuration Protocol (DHCP)...... 14
2.5.3. iSNS Heartbeat Message.......................... 14
2.6. iSNS and Network Address Translation (NAT).............. 14
2.7. Transfer of iSNS Database Records between iSNS Servers.. 15
2.8. Backup iSNS Servers..................................... 17
2.9. Transport Protocols..................................... 19
2.9.1. Use of TCP for iSNS Communication............... 19
2.9.2. Use of UDP for iSNS Communication............... 20
2.9.3. iSNS Multicast and Broadcast Messages........... 20
2.10. Simple Network Management Protocol (SNMP) Requirements.. 21
3. iSNS Object Model............................................. 21
3.1. Network Entity Object .................................. 22
3.2. Portal Object .......................................... 22
3.3. Storage Node Object..................................... 22
3.4. Portal Group Object..................................... 23
3.5. FC Device Object........................................ 24
3.6. Discovery Domain Object................................. 24
3.7. Discovery Domain Set Object............................. 24
3.8. iSNS Database Model..................................... 24
4. iSNS Implementation Requirements.............................. 25
4.1. iSCSI Requirements...................................... 25
4.1.1. Required Attributes for Support of iSCSI........ 26
4.1.2. Examples: iSCSI Object Model Diagrams........... 28
4.1.3. Required Commands and
Response Messages for Support of iSCSI.......... 30
4.2. iFCP Requirements....................................... 31
4.2.1. Required Attributes for Support of iFCP......... 31
4.2.2. Example: iFCP Object Model Diagram.............. 32
4.2.3. Required Commands and
Response Messages for Support of iFCP........... 34
5. iSNSP Message Format.......................................... 35
5.1. iSNSP PDU Header........................................ 35
5.1.1. iSNSP Version................................... 36
5.1.2. iSNSP Function ID............................... 36
5.1.3. iSNSP PDU Length................................ 36
5.1.4. iSNSP Flags..................................... 36
5.1.5. iSNSP Transaction ID............................ 36
5.1.6. iSNSP Sequence ID............................... 37
5.2. iSNSP Message Segmentation and Reassembly............... 37
5.3. iSNSP PDU Payload....................................... 37
5.3.1. Attribute Value 4-Byte Alignment................ 38
5.4. iSNSP Response Status Codes............................. 39
5.5. Authentication for iSNS Multicast and Broadcast Messages 39
5.6. Registration and Query Messages......................... 41
5.6.1. Source Attribute................................ 42
5.6.2. Message Key Attributes.......................... 42
5.6.3. Delimiter Attribute............................. 42
5.6.4. Operating Attributes............................ 43
5.6.5. Registration and Query Request Message Types ... 44
5.7. Response Messages....................................... 66
5.7.1. Status Code..................................... 66
5.7.2. Message Key Attributes in Response.............. 66
5.7.3. Delimiter Attribute in Response................. 67
5.7.4. Operating Attributes in Response................ 67
5.7.5. Registration and Query Response Message Type.... 67
5.8. Vendor-Specific Messages................................ 72
6. iSNS Attributes............................................... 73
6.1. iSNS Attribute Summary.................................. 73
6.2. Entity Identifier-Keyed Attributes...................... 76
6.2.1. Entity Identifier (EID)......................... 76
6.2.2. Entity Protocol................................. 76
6.2.3. Management IP Address .......................... 77
6.2.4. Entity Registration Timestamp .................. 77
6.2.5. Protocol Version Range.......................... 77
6.2.6. Registration Period............................. 78
6.2.7. Entity Index.................................... 78
6.2.8. Entity Next Index............................... 79
6.2.9. Entity ISAKMP Phase-1 Proposals................. 79
4.1. iSCSI Requirements...................................... 25
4.1.1. Required Attributes for Support of iSCSI........ 26
4.1.2. Examples: iSCSI Object Model Diagrams........... 28
4.1.3. Required Commands and
Response Messages for Support of iSCSI.......... 30
4.2. iFCP Requirements....................................... 31
4.2.1. Required Attributes for Support of iFCP......... 31
4.2.2. Example: iFCP Object Model Diagram.............. 32
4.2.3. Required Commands and
Response Messages for Support of iFCP........... 34
5. iSNSP Message Format.......................................... 35
5.1. iSNSP PDU Header........................................ 35
5.1.1. iSNSP Version................................... 36
5.1.2. iSNSP Function ID............................... 36
5.1.3. iSNSP PDU Length................................ 36
5.1.4. iSNSP Flags..................................... 36
5.1.5. iSNSP Transaction ID............................ 36
5.1.6. iSNSP Sequence ID............................... 37
5.2. iSNSP Message Segmentation and Reassembly............... 37
5.3. iSNSP PDU Payload....................................... 37
5.3.1. Attribute Value 4-Byte Alignment................ 38
5.4. iSNSP Response Status Codes............................. 39
5.5. Authentication for iSNS Multicast and Broadcast Messages 39
5.6. Registration and Query Messages......................... 41
5.6.1. Source Attribute................................ 42
5.6.2. Message Key Attributes.......................... 42
5.6.3. Delimiter Attribute............................. 42
5.6.4. Operating Attributes............................ 43
5.6.5. Registration and Query Request Message Types ... 44
5.7. Response Messages....................................... 66
5.7.1. Status Code..................................... 66
5.7.2. Message Key Attributes in Response.............. 66
5.7.3. Delimiter Attribute in Response................. 67
5.7.4. Operating Attributes in Response................ 67
5.7.5. Registration and Query Response Message Type.... 67
5.8. Vendor-Specific Messages................................ 72
6. iSNS Attributes............................................... 73
6.1. iSNS Attribute Summary.................................. 73
6.2. Entity Identifier-Keyed Attributes...................... 76
6.2.1. Entity Identifier (EID)......................... 76
6.2.2. Entity Protocol................................. 76
6.2.3. Management IP Address .......................... 77
6.2.4. Entity Registration Timestamp .................. 77
6.2.5. Protocol Version Range.......................... 77
6.2.6. Registration Period............................. 78
6.2.7. Entity Index.................................... 78
6.2.8. Entity Next Index............................... 79
6.2.9. Entity ISAKMP Phase-1 Proposals................. 79
6.2.10. Entity Certificate.............................. 79
6.3. Portal-Keyed Attributes................................. 80
6.3.1. Portal IP Address............................... 80
6.3.2. Portal TCP/UDP Port............................. 80
6.3.3. Portal Symbolic Name............................ 80
6.3.4. Entity Status Inquiry Interval.................. 81
6.3.5. ESI Port........................................ 82
6.3.6. Portal Index.................................... 82
6.3.7. SCN Port........................................ 82
6.3.8. Portal Next Index............................... 83
6.3.9. Portal Security Bitmap.......................... 83
6.3.10. Portal ISAKMP Phase-1 Proposals................. 84
6.3.11. Portal ISAKMP Phase-2 Proposals................. 84
6.3.12. Portal Certificate.............................. 84
6.4. iSCSI Node-Keyed Attributes............................. 84
6.4.1. iSCSI Name...................................... 85
6.4.2. iSCSI Node Type................................. 85
6.4.3. iSCSI Node Alias................................ 86
6.4.4. iSCSI Node SCN Bitmap .......................... 86
6.4.5. iSCSI Node Index................................ 87
6.4.6. WWNN Token...................................... 87
6.4.7. iSCSI Node Next Index .......................... 89
6.4.8. iSCSI AuthMethod................................ 89
6.5. Portal Group (PG) Object-Keyed Attributes............... 89
6.5.1. Portal Group iSCSI Name......................... 90
6.5.2. PG Portal IP Addr............................... 90
6.5.3. PG Portal TCP/UDP Port.......................... 90
6.5.4. Portal Group Tag (PGT).......................... 90
6.5.5. Portal Group Index.............................. 90
6.5.6. Portal Group Next Index......................... 91
6.6. FC Port Name-Keyed Attributes .......................... 91
6.6.1. FC Port Name (WWPN)............................. 91
6.6.2. Port ID (FC_ID)................................. 91
6.6.3. FC Port Type.................................... 92
6.6.4. Symbolic Port Name.............................. 92
6.6.5. Fabric Port Name (FWWN)......................... 92
6.6.6. Hard Address.................................... 92
6.6.7. Port IP Address................................. 92
6.6.8. Class of Service (COS).......................... 93
6.6.9. FC-4 Types...................................... 93
6.6.10. FC-4 Descriptor................................. 93
6.6.11. FC-4 Features .................................. 93
6.6.12. iFCP SCN Bitmap................................. 93
6.6.13. Port Role....................................... 94
6.6.14. Permanent Port Name (PPN)....................... 95
6.7. Node-Keyed Attributes .................................. 95
6.7.1. FC Node Name (WWNN)............................. 95
6.7.2. Symbolic Node Name.............................. 95
6.2.10. Entity Certificate.............................. 79
6.3. Portal-Keyed Attributes................................. 80
6.3.1. Portal IP Address............................... 80
6.3.2. Portal TCP/UDP Port............................. 80
6.3.3. Portal Symbolic Name............................ 80
6.3.4. Entity Status Inquiry Interval.................. 81
6.3.5. ESI Port........................................ 82
6.3.6. Portal Index.................................... 82
6.3.7. SCN Port........................................ 82
6.3.8. Portal Next Index............................... 83
6.3.9. Portal Security Bitmap.......................... 83
6.3.10. Portal ISAKMP Phase-1 Proposals................. 84
6.3.11. Portal ISAKMP Phase-2 Proposals................. 84
6.3.12. Portal Certificate.............................. 84
6.4. iSCSI Node-Keyed Attributes............................. 84
6.4.1. iSCSI Name...................................... 85
6.4.2. iSCSI Node Type................................. 85
6.4.3. iSCSI Node Alias................................ 86
6.4.4. iSCSI Node SCN Bitmap .......................... 86
6.4.5. iSCSI Node Index................................ 87
6.4.6. WWNN Token...................................... 87
6.4.7. iSCSI Node Next Index .......................... 89
6.4.8. iSCSI AuthMethod................................ 89
6.5. Portal Group (PG) Object-Keyed Attributes............... 89
6.5.1. Portal Group iSCSI Name......................... 90
6.5.2. PG Portal IP Addr............................... 90
6.5.3. PG Portal TCP/UDP Port.......................... 90
6.5.4. Portal Group Tag (PGT).......................... 90
6.5.5. Portal Group Index.............................. 90
6.5.6. Portal Group Next Index......................... 91
6.6. FC Port Name-Keyed Attributes .......................... 91
6.6.1. FC Port Name (WWPN)............................. 91
6.6.2. Port ID (FC_ID)................................. 91
6.6.3. FC Port Type.................................... 92
6.6.4. Symbolic Port Name.............................. 92
6.6.5. Fabric Port Name (FWWN)......................... 92
6.6.6. Hard Address.................................... 92
6.6.7. Port IP Address................................. 92
6.6.8. Class of Service (COS).......................... 93
6.6.9. FC-4 Types...................................... 93
6.6.10. FC-4 Descriptor................................. 93
6.6.11. FC-4 Features .................................. 93
6.6.12. iFCP SCN Bitmap................................. 93
6.6.13. Port Role....................................... 94
6.6.14. Permanent Port Name (PPN)....................... 95
6.7. Node-Keyed Attributes .................................. 95
6.7.1. FC Node Name (WWNN)............................. 95
6.7.2. Symbolic Node Name.............................. 95
6.7.3. Node IP Address................................. 95
6.7.4. Node IPA........................................ 96
6.7.5. Proxy iSCSI Name................................ 96
6.8. Other Attributes........................................ 96
6.8.1. FC-4 Type Code.................................. 96
6.8.2. iFCP Switch Name................................ 96
6.8.3. iFCP Transparent Mode Commands.................. 97
6.9. iSNS Server-Specific Attributes......................... 97
6.9.1. iSNS Server Vendor OUI.......................... 98
6.10. Vendor-Specific Attributes.............................. 98
6.10.1. Vendor-Specific Server Attributes............... 98
6.10.2. Vendor-Specific Entity Attributes............... 98
6.10.3. Vendor-Specific Portal Attributes............... 99
6.10.4. Vendor-Specific iSCSI Node Attributes........... 99
6.10.5. Vendor-Specific FC Port Name Attributes......... 99
6.10.6. Vendor-Specific FC Node Name Attributes......... 99
6.10.7. Vendor-Specific Discovery Domain Attributes..... 99
6.10.8. Vendor-Specific Discovery Domain Set Attributes. 99
6.10.9. Other Vendor-Specific Attributes................ 99
6.11. Discovery Domain Registration Attributes............... 100
6.11.1. DD Set ID Keyed Attributes..................... 100
6.11.2. DD ID Keyed Attributes......................... 101
7. Security Considerations...................................... 103
7.1. iSNS Security Threat Analysis ......................... 103
7.2. iSNS Security Implementation and Usage Requirements.... 104
7.3. Discovering Security Requirements of Peer Devices...... 105
7.4. Configuring Security Policies of iFCP/iSCSI Devices.... 106
7.5. Resource Issues........................................ 107
7.6. iSNS Interaction with IKE and IPSec.................... 107
8. IANA Considerations.......................................... 107
8.1. Registry of Block Storage Protocols.................... 107
8.2. Registry of Standard iSNS Attributes .................. 108
8.3. Block Structure Descriptor (BSD) Registry.............. 108
9. Normative References......................................... 109
10. Informative References....................................... 110
Appendix A: iSNS Examples........................................ 112
A.1. iSCSI Initialization Example........................... 112
A.1.1. Simple iSCSI Target Registration............... 112
A.1.2. Target Registration and DD Configuration....... 114
A.1.3. Initiator Registration and Target Discovery.... 117
Acknowledgements................................................. 121
6.7.3. Node IP Address................................. 95
6.7.4. Node IPA........................................ 96
6.7.5. Proxy iSCSI Name................................ 96
6.8. Other Attributes........................................ 96
6.8.1. FC-4 Type Code.................................. 96
6.8.2. iFCP Switch Name................................ 96
6.8.3. iFCP Transparent Mode Commands.................. 97
6.9. iSNS Server-Specific Attributes......................... 97
6.9.1. iSNS Server Vendor OUI.......................... 98
6.10. Vendor-Specific Attributes.............................. 98
6.10.1. Vendor-Specific Server Attributes............... 98
6.10.2. Vendor-Specific Entity Attributes............... 98
6.10.3. Vendor-Specific Portal Attributes............... 99
6.10.4. Vendor-Specific iSCSI Node Attributes........... 99
6.10.5. Vendor-Specific FC Port Name Attributes......... 99
6.10.6. Vendor-Specific FC Node Name Attributes......... 99
6.10.7. Vendor-Specific Discovery Domain Attributes..... 99
6.10.8. Vendor-Specific Discovery Domain Set Attributes. 99
6.10.9. Other Vendor-Specific Attributes................ 99
6.11. Discovery Domain Registration Attributes............... 100
6.11.1. DD Set ID Keyed Attributes..................... 100
6.11.2. DD ID Keyed Attributes......................... 101
7. Security Considerations...................................... 103
7.1. iSNS Security Threat Analysis ......................... 103
7.2. iSNS Security Implementation and Usage Requirements.... 104
7.3. Discovering Security Requirements of Peer Devices...... 105
7.4. Configuring Security Policies of iFCP/iSCSI Devices.... 106
7.5. Resource Issues........................................ 107
7.6. iSNS Interaction with IKE and IPSec.................... 107
8. IANA Considerations.......................................... 107
8.1. Registry of Block Storage Protocols.................... 107
8.2. Registry of Standard iSNS Attributes .................. 108
8.3. Block Structure Descriptor (BSD) Registry.............. 108
9. Normative References......................................... 109
10. Informative References....................................... 110
Appendix A: iSNS Examples........................................ 112
A.1. iSCSI Initialization Example........................... 112
A.1.1. Simple iSCSI Target Registration............... 112
A.1.2. Target Registration and DD Configuration....... 114
A.1.3. Initiator Registration and Target Discovery.... 117
Acknowledgements................................................. 121
"iSNS" refers to the storage network model and associated services covered in the text of this document.
“iSNS”指本文档正文中涵盖的存储网络模型和相关服务。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
All frame formats are in big endian network byte order.
所有帧格式均为大端网络字节顺序。
All unused fields and bitmaps, including those that are RESERVED, SHOULD be set to zero when sending and ignored when receiving.
所有未使用的字段和位图，包括保留的字段和位图，在发送时应设置为零，在接收时应忽略。
This is a standards track document containing normative text specifying the iSNS Protocol, used by iSCSI and iFCP devices to communicate with the iSNS server. This document focuses on the interaction between iSNS servers and iSNS clients; interactions among multiple authoritative primary iSNS servers are a potential topic for future work.
这是一份标准跟踪文档，其中包含指定iSNS协议的规范性文本，iSCSI和iFCP设备用于与iSNS服务器通信。本文档重点介绍iSNS服务器和iSNS客户端之间的交互；多个权威主iSNS服务器之间的交互是未来工作的一个潜在主题。
iSNS facilitates scalable configuration and management of iSCSI and Fibre Channel (FCP) storage devices in an IP network by providing a set of services comparable to that available in Fibre Channel networks. iSNS thus allows a commodity IP network to function at a level of intelligence comparable to a Fibre Channel fabric. iSNS allows the administrator to go beyond a simple device-by-device management model, where each storage device is manually and individually configured with its own list of known initiators and targets. Using the iSNS, each storage device subordinates its discovery and management responsibilities to the iSNS server. The iSNS server thereby serves as the consolidated configuration point through which management stations can configure and manage the entire storage network, including both iSCSI and Fibre Channel devices.
iSNS通过提供一组与光纤通道网络中可用的服务相当的服务，促进了IP网络中iSCSI和光纤通道（FCP）存储设备的可扩展配置和管理。因此，iSNS允许商品IP网络以与光纤通道结构相当的智能级别运行。iSNS允许管理员超越简单的逐设备管理模式，在这种模式下，每个存储设备都可以手动和单独地配置其自己的已知启动器和目标列表。使用iSNS，每个存储设备都将其发现和管理职责从属于iSNS服务器。因此，iSNS服务器充当整合的配置点，通过它，管理站可以配置和管理整个存储网络，包括iSCSI和光纤通道设备。
iSNS can be implemented to support iSCSI and/or iFCP protocols as needed; an iSNS implementation MAY provide support for one or both of these protocols as desired by the implementor. Implementation requirements within each of these protocols are further discussed in Section 5. Use of iSNS is OPTIONAL for iSCSI and REQUIRED for iFCP.
可以根据需要实施iSNS以支持iSCSI和/或iFCP协议；iSNS实现可以根据实现者的需要为这些协议中的一个或两个提供支持。第5节将进一步讨论每个协议中的实现要求。iSNS的使用对于iSCSI是可选的，对于iFCP是必需的。
The iSNS Protocol (iSNSP) is a flexible and lightweight protocol that specifies how iSNS clients and servers communicate. It is suitable for various platforms, including switches and targets as well as server hosts.
iSNS协议（iSNSP）是一种灵活、轻量级的协议，用于指定iSNS客户端和服务器的通信方式。它适用于各种平台，包括交换机和目标以及服务器主机。
iSNS clients initiate transactions with iSNS servers using the iSNSP. iSNS clients are processes that are co-resident in the storage device, and that can register device attribute information, download information about other registered clients in a common Discovery Domain (DD), and receive asynchronous notification of events that occur in their DD(s). Management stations are a special type of iSNS client that have access to all DDs stored in the iSNS.
iSNS客户端使用iSNSP启动与iSNS服务器的事务。iSNS客户端是共同驻留在存储设备中的进程，可以注册设备属性信息，下载公共发现域（DD）中其他已注册客户端的信息，并接收DD中发生的事件的异步通知。管理站是一种特殊类型的iSNS客户端，可以访问iSNS中存储的所有DDs。
iSNS servers respond to iSNS protocol queries and requests, and initiate iSNS protocol State Change Notifications. Properly authenticated information submitted by a registration request is stored in an iSNS database.
iSNS服务器响应iSNS协议查询和请求，并启动iSNS协议状态更改通知。通过注册请求提交的经过适当身份验证的信息存储在iSNS数据库中。
The iSNS database is the information repository for the iSNS server(s). It maintains information about iSNS client attributes. A directory-enabled implementation of iSNS may store client attributes in an LDAP directory infrastructure.
iSNS数据库是iSNS服务器的信息存储库。它维护有关iSNS客户端属性的信息。启用目录的iSNS实现可以将客户端属性存储在LDAP目录基础结构中。
iSCSI (Internet SCSI) is an encapsulation of SCSI for a new generation of storage devices interconnected with TCP/IP [iSCSI].
iSCSI（Internet SCSI）是SCSI的封装，用于与TCP/IP[iSCSI]互连的新一代存储设备。
iFCP (Internet FCP) is a gateway-to-gateway protocol designed to interconnect existing Fibre Channel and SCSI devices using TCP/IP. iFCP maps the existing FCP standard and associated Fibre Channel services to TCP/IP [iFCP].
iFCP（Internet FCP）是一种网关到网关协议，旨在使用TCP/IP互连现有光纤通道和SCSI设备。iFCP将现有FCP标准和相关光纤通道服务映射到TCP/IP[iFCP]。
There are four main functions of the iSNS:
iSNS有四个主要功能：
1) A Name Service Providing Storage Resource Discovery
1) 提供存储资源发现的名称服务
2) Discovery Domain (DD) and Login Control Service
2) 发现域（DD）和登录控制服务
3) State Change Notification Service
3) 状态更改通知服务
4) Open Mapping of Fibre Channel and iSCSI Devices
4) 光纤通道和iSCSI设备的开放映射
The iSNS provides a registration function to allow all entities in a storage network to register and query the iSNS database. Both targets and initiators can register in the iSNS database, as well as query for information about other initiators and targets. This allows, for example, a client initiator to obtain information about target devices from the iSNS server. This service is modeled on the Fibre Channel Generic Services Name Server described in FC-GS-4, with extensions, operating within the context of an IP network.
iSNS提供注册功能，允许存储网络中的所有实体注册和查询iSNS数据库。目标和启动器都可以在iSNS数据库中注册，也可以查询有关其他启动器和目标的信息。例如，这允许客户端启动器从iSNS服务器获取有关目标设备的信息。此服务以FC-GS-4中描述的光纤通道通用服务名称服务器为模型，并带有扩展，在IP网络的上下文中运行。
The naming registration service also provides the ability to obtain a network-unique Domain ID for iFCP gateways when one is required.
命名注册服务还提供了在需要时为iFCP网关获取网络唯一域ID的功能。
The Discovery Domain (DD) Service facilitates the partitioning of Storage Nodes into more manageable groupings for administrative and login control purposes. It allows the administrator to limit the login process of each host to the more appropriate subset of targets registered in the iSNS. This is particularly important for reducing the number of unnecessary logins (iSCSI logins or Fibre Channel Port Logins), and for limiting the amount of time that the host spends initializing login relationships as the size of the storage network scales up. Storage Nodes must be in at least one common enabled DD in order to obtain information about each other. Devices can be members of multiple DDs simultaneously.
发现域（DD）服务有助于将存储节点划分为更易于管理的组，以便进行管理和登录控制。它允许管理员将每个主机的登录过程限制在iSNS中注册的更合适的目标子集。这对于减少不必要的登录次数（iSCSI登录或光纤通道端口登录）以及限制主机在存储网络规模扩大时初始化登录关系所花费的时间特别重要。存储节点必须至少位于一个公共启用DD中，才能获取彼此的信息。设备可以同时是多个DDs的成员。
Login Control allows targets to delegate their access control/authorization policies to the iSNS server. This is consistent with the goal of centralizing management of those storage devices using the iSNS server. The target node or device downloads the list of authorized initiators from the iSNS. Each node or device is uniquely identified by an iSCSI Name or FC Port Name. Only
登录控制允许目标将其访问控制/授权策略委托给iSNS服务器。这与使用iSNS服务器集中管理这些存储设备的目标是一致的。目标节点或设备从iSNS下载授权启动器列表。每个节点或设备都由iSCSI名称或FC端口名称唯一标识。只有
initiators that match the required identification and authorization provided by the iSNS will be allowed access by that target Node during session establishment.
在会话建立期间，目标节点将允许与iSNS提供的所需标识和授权相匹配的启动器进行访问。
Placing Portals of a Network Entity into Discovery Domains allows administrators to indicate the preferred IP Portal interface through which storage traffic should access specific Storage Nodes of that Network Entity. If no Portals of a Network Entity have been placed into a DD, then queries scoped to that DD SHALL report all Portals of that Network Entity. If one or more Portals of a Network Entity have been placed into a DD, then queries scoped to that DD SHALL report only those Portals that have been explicitly placed in the DD.
将网络实体的入口放置到发现域中，管理员可以指示首选的IP入口接口，存储流量应通过该接口访问该网络实体的特定存储节点。如果未将网络实体的入口放入DD中，则该DD范围内的查询应报告该网络实体的所有入口。如果一个网络实体的一个或多个门户已放置在DD中，则该DD范围内的查询应仅报告已明确放置在DD中的那些门户。
DDs can be managed offline through a separate management workstation using the iSNSP or SNMP. If the target opts to use the Login Control feature of the iSNS, the target delegates management of access control policy (i.e., the list of initiators allowed to log in to that target) to the management workstations that are managing the configuration in the iSNS database.
DDs可以通过使用iSNSP或SNMP的单独管理工作站进行脱机管理。如果目标选择使用iSNS的登录控制功能，则目标将访问控制策略的管理（即允许登录到该目标的启动器列表）委托给管理iSNS数据库中配置的管理工作站。
If administratively authorized, a target can upload its own Login Control list. This is accomplished using the DDReg message and listing the iSCSI name of each initiator to be registered in the target's DD.
如果经过管理授权，目标可以上载自己的登录控制列表。这是通过使用DDReg消息并列出要在目标DD中注册的每个启动器的iSCSI名称来实现的。
An implementation MAY decide that newly registered devices that have not explicitly been placed into a DD by the management station will be placed into a "default DD" contained in a "default DDS" whose initial DD Set Status value is "enabled". This makes them visible to other devices in the default DD. Other implementations MAY decide that they are registered with no DD, making them inaccessible to source-scoped iSNSP messages.
实现可以决定，未被管理站显式地放置到DD中的新注册设备将被放置到包含在初始DD设置状态值为“enabled”的“default DDS”中的“default DD”中。这使它们在默认DD中对其他设备可见。其他实现可能会决定它们没有DD注册，从而使源范围的iSNSP消息无法访问它们。
The iSNS server uses the Source Attribute of each iSNSP message to determine the originator of the request and to scope the operation to a set of Discovery Domains. In addition, the Node Type (specified in the iFCP or iSCSI Node Type bitmap field) may also be used to determine authorization for the specified iSNS operation. For example, only Control Nodes are authorized to create or delete discovery domains.
iSNS服务器使用每个iSNSP消息的源属性来确定请求的发起人，并将操作范围限定到一组发现域。此外，节点类型（在iFCP或iSCSI节点类型位图字段中指定）也可用于确定指定iSNS操作的授权。例如，只有控制节点有权创建或删除发现域。
Valid and active Discovery Domains (DDs) belong to at least one active Discovery Domain Set (DDS). Discovery Domains that do not belong to an activated DDS are not enabled. The iSNS server MUST maintain the state of DD membership for all Storage Nodes, even for those that have been deregistered. DD membership is persistent regardless of whether a Storage Node is actively registered in the iSNS database.
有效和活动发现域（DDs）至少属于一个活动发现域集（DDs）。不属于已激活DDS的发现域未启用。iSNS服务器必须为所有存储节点（即使是已注销的存储节点）保持DD成员身份状态。无论存储节点是否在iSNS数据库中主动注册，DD成员身份都是持久的。
The State Change Notification (SCN) service allows the iSNS Server to issue notifications about network events that affect the operational state of Storage Nodes. The iSNS client may register for notifications on behalf of its Storage Nodes for notification of events detected by the iSNS Server. SCNs notify iSNS clients of explicit or implicit changes to the iSNS database; they do not necessarily indicate the state of connectivity to peer storage devices in the network. The response of a storage device to receipt of an SCN is implementation-specific; the policy for responding to SCNs is outside of the scope of this document.
状态更改通知（SCN）服务允许iSNS服务器发出有关影响存储节点运行状态的网络事件的通知。iSNS客户端可以代表其存储节点注册通知，以通知iSNS服务器检测到的事件。SCN通知iSNS客户端iSNS数据库的显式或隐式更改；它们不一定表示网络中对等存储设备的连接状态。存储设备对接收到SCN的响应是特定于实现的；响应SCN的策略不在本文档的范围内。
There are two types of SCN registrations: regular registrations and management registrations. Management registrations result in management SCNs, whereas regular registrations result in regular SCNs. The type of registration and SCN message is indicated in the SCN bitmap (see Sections 6.4.4 and 6.6.12).
SCN注册有两种类型：常规注册和管理注册。管理注册产生管理SCN，而常规注册产生常规SCN。注册类型和SCN消息在SCN位图中显示（见第6.4.4节和第6.6.12节）。
A regular SCN registration indicates that the Discovery Domain Service SHALL be used to control the distribution of SCN messages. Receipt of regular SCNs is limited to the discovery domains in which the SCN-triggering event takes place. Regular SCNs do not contain information about discovery domains.
常规SCN注册表示应使用发现域服务来控制SCN消息的分发。常规SCN的接收仅限于发生SCN触发事件的发现域。常规SCN不包含有关发现域的信息。
A management SCN registration can only by requested by Control Nodes. Management SCNs resulting from management registrations are not bound by the Discovery Domain service. Authorization to request management SCN registrations may be administratively controlled.
管理SCN注册只能由控制节点请求。由管理注册产生的管理SCN不受发现域服务的约束。请求管理SCN注册的授权可能受到管理控制。
The iSNS server SHOULD be implemented with hardware and software resources sufficient to support the expected number of iSNS clients. However, if resources are unexpectedly exhausted, then the iSNS server MAY refuse SCN service by returning an SCN Registration Rejected (Status Code 17). The rejection might occur in situations where the network size or current number of SCN registrations has passed an implementation-specific threshold. A client not allowed to register for SCNs may decide to monitor its sessions with other storage devices directly.
iSNS服务器的硬件和软件资源应足以支持预期数量的iSNS客户端。但是，如果资源意外耗尽，iSNS服务器可能会通过返回SCN注册已拒绝（状态代码17）来拒绝SCN服务。拒绝可能发生在网络大小或当前SCN注册数已超过特定于实现的阈值的情况下。不允许注册SCN的客户端可能决定直接监视其与其他存储设备的会话。
The specific notification mechanism by which the iSNS server learns of the events that trigger SCNs is implementation-specific, but can include examples such as explicit notification messages from an iSNS client to the iSNS server, or a hardware interrupt to a switch-hosted iSNS server as a result of link failure.
iSNS服务器学习触发SCN的事件的特定通知机制是特定于实现的，但可以包括示例，例如从iSNS客户端到iSNS服务器的显式通知消息，或由于链路故障导致交换机承载的iSNS服务器的硬件中断。
The iSNS database stores naming and discovery information about both Fibre Channel and iSCSI devices. This allows the iSNS server to store mappings of a Fibre Channel device to a proxy iSCSI device "image" in the IP network. Similarly, mappings of an iSCSI device to a "proxy WWN" can be stored under the WWNN Token field for that iSCSI device.
iSNS数据库存储有关光纤通道和iSCSI设备的命名和发现信息。这允许iSNS服务器在IP网络中存储光纤通道设备到代理iSCSI设备“映像”的映射。类似地，iSCSI设备到“代理WWN”的映射可以存储在该iSCSI设备的WWNN令牌字段下。
Furthermore, through use of iSCSI-FC gateways, Fibre Channel-aware management stations can interact with the iSNS server to retrieve information about Fibre Channel devices, and use this information to manage Fibre Channel and iSCSI devices. This allows management functions such as Discovery Domains and State Change Notifications to be applied seamlessly to both iSCSI and Fibre Channel devices, facilitating integration of IP networks with Fibre Channel devices and fabrics.
此外，通过使用iSCSI FC网关，支持光纤通道的管理站可以与iSNS服务器交互，以检索有关光纤通道设备的信息，并使用此信息管理光纤通道和iSCSI设备。这允许将发现域和状态更改通知等管理功能无缝应用于iSCSI和光纤通道设备，从而促进IP网络与光纤通道设备和结构的集成。
Note that Fibre Channel attributes are stored as iFCP attributes, and that the ability to store this information in the iSNS server is useful even if the iFCP protocol is not implemented. In particular, tag 101 can be used to store a "Proxy iSCSI Name" for Fibre Channel devices registered in the iSNS server. This field is used to associate the FC device with an iSCSI registration entry that is used for the Fibre Channel device to communicate with iSCSI devices in the IP network. Conversely, tag 37 (see Section 6.1) contains a WWNN Token field, which can be used to store an FC Node Name (WWNN) value used by iSCSI-FC gateways to represent an iSCSI device in the Fibre Channel domain.
请注意，光纤通道属性存储为iFCP属性，即使未实施iFCP协议，在iSNS服务器中存储此信息的功能也很有用。特别是，标签101可用于存储iSNS服务器中注册的光纤通道设备的“代理iSCSI名称”。此字段用于将FC设备与iSCSI注册条目相关联，iSCSI注册条目用于光纤通道设备与IP网络中的iSCSI设备通信。相反，标记37（请参见第6.1节）包含一个WWNN令牌字段，可用于存储iSCSI FC网关用于表示光纤通道域中iSCSI设备的FC节点名称（WWNN）值。
By storing the mapping between Fibre Channel and iSCSI devices in the iSNS server, this information becomes open to any authorized iSNS client wishing to retrieve and use this information. In many cases, this provides advantages over storing the information internally within an iSCSI-FC gateway, where the mapping is inaccessible to other devices except by proprietary mechanisms.
通过将光纤通道和iSCSI设备之间的映射存储在iSNS服务器中，此信息将对任何希望检索和使用此信息的授权iSNS客户端开放。在许多情况下，与在iSCSI FC网关内部存储信息相比，这提供了一些优势，在iSCSI FC网关中，除专有机制外，其他设备无法访问映射。
The following is a high-level description of how each type of device in a storage network can utilize iSNS. Each type of device interacts with the iSNS server as an iSNS client and must register itself in the iSNS database in order to access services provided by the iSNS.
以下是存储网络中每种类型的设备如何利用iSNS的高级描述。每种类型的设备都作为iSNS客户端与iSNS服务器交互，并且必须在iSNS数据库中注册，以便访问iSNS提供的服务。
An iSCSI initiator will query the iSNS server to discover the presence and location of iSCSI target devices. It may also request state change notifications (SCNs) so that it can be notified of new targets that appear on the network after the initial bootup and discovery. SCNs can also inform the iSCSI initiator of targets that have been removed from or no longer available in the storage network, so that incomplete storage sessions can be gracefully terminated and resources for non-existent targets can be reallocated.
iSCSI启动器将查询iSNS服务器以发现iSCSI目标设备的存在和位置。它还可以请求状态更改通知（SCN），以便在初始启动和发现后可以通知它网络上出现的新目标。SCN还可以将已从存储网络中删除或不再可用的目标通知iSCSI启动器，以便正常终止不完整的存储会话，并重新分配不存在的目标的资源。
An iSCSI target allows itself to be discovered by iSCSI initiators by registering its presence in the iSNS server. It may also register for SCNs in order to detect the addition or removal of initiators for resource allocation purposes. The iSCSI target device may also register for Entity Status Inquiry (ESI) messages, which allow the iSNS to monitor the target device's availability in the storage network.
iSCSI目标允许iSCSI启动器通过在iSNS服务器中注册其存在来发现其自身。它还可以注册SCN，以便出于资源分配目的检测启动器的添加或删除。iSCSI目标设备还可以注册实体状态查询（ESI）消息，该消息允许iSNS监视目标设备在存储网络中的可用性。
An iSCSI-FC gateway bridges devices in a Fibre Channel network to an iSCSI/IP network. It may use the iSNS server to store FC device attributes discovered in the FC name server, as well as mappings of FC device identifiers to iSCSI device identifiers. iSNS has the capability to store all attributes of both iSCSI and Fibre Channel devices; iSCSI devices are managed through direct interaction using iSNS, while FC devices can be indirectly managed through iSNS interactions with the iSCSI-FC gateway. This allows both iSCSI and Fibre Channel devices to be managed in a seamless management framework.
iSCSI FC网关将光纤通道网络中的设备桥接到iSCSI/IP网络。它可以使用iSNS服务器存储在FC名称服务器中发现的FC设备属性，以及FC设备标识符到iSCSI设备标识符的映射。iSNS能够存储iSCSI和光纤通道设备的所有属性；iSCSI设备通过使用iSNS的直接交互进行管理，而FC设备可以通过iSNS与iSCSI FC网关的交互进行间接管理。这允许在无缝管理框架中管理iSCSI和光纤通道设备。
An iFCP gateway uses iSNS to emulate the services provided by a Fibre Channel name server for FC devices in its gateway region. iSNS provides basic discovery and zoning configuration information to be enforced by the iFCP gateway. When queried, iSNS returns information on the N_Port network address used to establish iFCP sessions between FC devices supported by iFCP gateways.
iFCP网关使用iSNS模拟光纤通道名称服务器为其网关区域中的FC设备提供的服务。iSNS提供由iFCP网关强制执行的基本发现和分区配置信息。当被查询时，iSNS返回用于在iFCP网关支持的FC设备之间建立iFCP会话的N_端口网络地址的信息。
A management station uses iSNS to monitor storage devices and to enable or disable storage sessions by configuring discovery domains. A management station usually interacts with the iSNS server as a
管理站使用iSNS监控存储设备，并通过配置发现域启用或禁用存储会话。管理站通常作为服务器与iSNS服务器交互
Control Node endowed with access to all iSNS database records and with special privileges to configure discovery domains. Through manipulation of discovery domains, the management station controls the scope of device discovery for iSNS clients querying the iSNS server.
控制节点具有访问所有iSNS数据库记录的权限，并具有配置发现域的特权。通过操作发现域，管理站控制查询iSNS服务器的iSNS客户端的设备发现范围。
Some important operational settings for the iSNS server are configured using administrative means, such as a configuration file, a console port, an SNMP, or another implementation-specific method. These administratively-controlled settings cannot be configured using the iSNS Protocol, and therefore the iSNS server implementation MUST provide for such an administrative control interface.
iSNS服务器的一些重要操作设置是使用管理手段配置的，例如配置文件、控制台端口、SNMP或其他特定于实现的方法。无法使用iSNS协议配置这些管理控制设置，因此iSNS服务器实现必须提供此类管理控制接口。
The following is a list of parameters that are administratively controlled for the iSNS server. In the absence of alternative settings provided by the administrator, the following specified default settings MUST be used.
以下是iSNS服务器管理控制的参数列表。如果管理员未提供其他设置，则必须使用以下指定的默认设置。
Setting Default Setting
------- ---------------
ESI Non-Response Threshold 3 (see 5.6.5.13)
Management SCNs (Control Nodes only) enabled (see 5.6.5.8)
Default DD/DDS disabled
DD/DDS Modification
- Control Node enabled
- iSCSI Target Node Type disabled
- iSCSI Initiator Node Type disabled
- iFCP Target Port Role disabled
- iFCP Initiator Port Role disabled
Authorized Control Nodes N/A
Setting Default Setting
------- ---------------
ESI Non-Response Threshold 3 (see 5.6.5.13)
Management SCNs (Control Nodes only) enabled (see 5.6.5.8)
Default DD/DDS disabled
DD/DDS Modification
- Control Node enabled
- iSCSI Target Node Type disabled
- iSCSI Initiator Node Type disabled
- iFCP Target Port Role disabled
- iFCP Initiator Port Role disabled
Authorized Control Nodes N/A
ESI Non-Response Threshold: determines the number of ESI messages sent without receiving a response before the network entity is deregistered from the iSNS database.
ESI非响应阈值：确定在从iSNS数据库注销网络实体之前，未接收响应而发送的ESI消息数。
Management SCN for Control Node: determines whether a registered Control Node is permitted to register to receive Management SCNs.
控制节点的管理SCN：确定是否允许已注册的控制节点注册以接收管理SCN。
Default DD/DDS: determines whether a newly registered device not explicitly placed into a discovery domain (DD) and discovery domain set (DDS) is placed into a default DD/DDS.
默认DD/DDS：确定未显式放入发现域（DD）和发现域集（DDS）的新注册设备是否放入默认DD/DDS。
DD/DDS Modification: determines whether the specified type of Node is allowed to add, delete or update DDs and DDSs.
DD/DDS修改：确定是否允许指定类型的节点添加、删除或更新DDS和DDS。
Authorized Control Nodes: a list of Nodes identified by iSCSI Name or FC Port Name WWPN that are authorized to register as Control Nodes.
授权控制节点：由iSCSI名称或FC端口名称WWPN标识的节点列表，这些节点被授权注册为控制节点。
The Service Location Protocol (SLP) provides a flexible and scalable framework for providing hosts with access to information about the existence, location, and configuration of networked services, including the iSNS server. SLP can be used by iSNS clients to discover the IP address or FQDN of the iSNS server. To implement discovery through SLP, a Service Agent (SA) should be cohosted in the iSNS server, and a User Agent (UA) should be in each iSNS client. Each client multicasts a discovery message requesting the IP address of the iSNS server(s). The SA responds to this request. Optionally, the location of the iSNS server can be stored in the SLP Directory Agent (DA).
服务位置协议（SLP）提供了一个灵活且可扩展的框架，让主机能够访问有关网络服务（包括iSNS服务器）的存在、位置和配置的信息。iSNS客户端可以使用SLP来发现iSNS服务器的IP地址或FQDN。要通过SLP实现发现，应在iSNS服务器中共同驻留一个服务代理（SA），并在每个iSNS客户端中驻留一个用户代理（UA）。每个客户端多播一条发现消息，请求iSNS服务器的IP地址。SA响应此请求。或者，iSNS服务器的位置可以存储在SLP目录代理（DA）中。
Note that a complete description and specification of SLP can be found in [RFC2608], and is beyond the scope of this document. A service template for using SLP to locate iSNS servers can be found in [iSCSI-SLP].
请注意，SLP的完整说明和规范可在[RFC2608]中找到，并且超出了本文件的范围。可以在[iSCSI SLP]中找到使用SLP定位iSNS服务器的服务模板。
The IP address of the iSNS server can be stored in a DHCP server to be downloaded by iSNS clients using a DHCP option. The DHCP option number to be used for distributing the iSNS server location is found in [iSNSOption].
iSNS服务器的IP地址可以存储在DHCP服务器中，由iSNS客户端使用DHCP选项下载。用于分发iSNS服务器位置的DHCP选项号可在[iSNOPTION]中找到。
The iSNS heartbeat message is described in Section 5.6.5.14. It allows iSNS clients within the broadcast or multicast domain of the iSNS server to discover the location of the active iSNS server and any backup servers.
第5.6.5.14节描述了iSNS心跳消息。它允许iSNS服务器的广播或多播域内的iSNS客户端发现活动iSNS服务器和任何备份服务器的位置。
The existence of NAT will have an impact upon information retrieved from the iSNS server. If the iSNS client exists in an addressing domain different from that of the iSNS server, then IP address information stored in the iSNS server may not be correct when interpreted in the domain of the iSNS client.
NAT的存在将对从iSNS服务器检索到的信息产生影响。如果iSNS客户端位于不同于iSNS服务器的寻址域中，则在iSNS客户端的域中进行解释时，iSNS服务器中存储的IP地址信息可能不正确。
There are several possible approaches to allow operation of iSNS within a NAT network. The first approach is to require use of the canonical TCP port number by both targets and initiators when addressing targets across a NAT boundary, and for the iSNS client not to query for nominal IP addresses. Rather, the iSNS client queries for the DNS Fully Qualified Domain Name stored in the Entity Identifier field when seeking addressing information. Once retrieved, the DNS name can be interpreted in each address domain and mapped to the appropriate IP address by local DNS servers.
有几种可能的方法允许在NAT网络中操作iSNS。第一种方法是要求目标和启动器在跨NAT边界寻址目标时使用规范TCP端口号，并且iSNS客户端不查询标称IP地址。相反，iSNS客户端在查找寻址信息时会查询存储在实体标识符字段中的DNS完全限定域名。一旦检索到，DNS名称可以在每个地址域中进行解释，并由本地DNS服务器映射到相应的IP地址。
A second approach is to deploy a distributed network of iSNS servers. Local iSNS servers are deployed inside and outside NAT boundaries, with each local server storing relevant IP addresses for their respective NAT domains. Updates among the network of decentralized, local iSNS servers are handled using LDAP and appropriate NAT translation rules implemented within the update mechanism in each server.
第二种方法是部署iSNS服务器的分布式网络。本地iSNS服务器部署在NAT边界内外，每个本地服务器存储各自NAT域的相关IP地址。分散的本地iSNS服务器网络之间的更新使用LDAP和在每个服务器的更新机制中实现的适当NAT转换规则进行处理。
Finally, note that it is possible for an iSNS server in the private addressing domain behind a NAT boundary to exclusively support iSNS clients that are operating in the global IP addressing domain. If this is the case, the administrator only needs to ensure that the appropriate mappings are configured on the NAT gateways to allow the iSNS clients to initiate iSNSP sessions to the iSNS server. All registered addresses contained in the iSNS server are thus public IP addresses for use outside the NAT boundary. Care should be taken to ensure that there are no iSNS clients querying the server from inside the NAT boundary.
最后，请注意，NAT边界后面的专用寻址域中的iSNS服务器可以专门支持在全局IP寻址域中运行的iSNS客户端。如果是这种情况，管理员只需确保在NAT网关上配置了适当的映射，以允许iSNS客户端启动到iSNS服务器的iSNSP会话。因此，iSNS服务器中包含的所有注册地址都是在NAT边界之外使用的公共IP地址。应注意确保没有iSNS客户端从NAT边界内查询服务器。
Transfer of iSNS database records between iSNS servers has important applications, including the following:
在iSNS服务器之间传输iSNS数据库记录具有重要的应用，包括：
1) An independent organization needs to transfer storage information to a different organization. Each organization independently maintains its own iSNS infrastructure. To facilitate discovery of storage assets of the peer organization using IP, iSNS database records can be transferred between authoritative iSNS servers from each organization. This allows storage sessions to be established directly between devices residing in each organization's storage network infrastructure over a common IP network.
1) 独立组织需要将存储信息传输到其他组织。每个组织都独立维护自己的iSNS基础架构。为了便于使用IP发现对等组织的存储资产，可以在每个组织的权威iSNS服务器之间传输iSNS数据库记录。这允许通过公共IP网络在每个组织的存储网络基础结构中的设备之间直接建立存储会话。
2) Multiple iSNS servers are desired for redundancy. Backup servers need to maintain copies of the primary server's dynamically changing database.
2) 需要多台iSNS服务器以实现冗余。备份服务器需要维护主服务器动态更改的数据库的副本。
To support the above applications, information in an iSNS server can be distributed to other iSNS servers either using the iSNS protocol, or through out-of-band mechanisms using non-iSNS protocols. The following examples illustrate possible methods for transferring data records between iSNS servers. In the first example, a back-end LDAP information base is used to support the iSNS server, and the data is transferred using the LDAP protocol. Once the record transfer of the remote device is completed, it becomes visible and accessible to local devices using the local iSNS server. This allows local devices to establish sessions with remote devices (provided that firewall boundaries can be negotiated).
为了支持上述应用程序，可以使用iSNS协议或使用非iSNS协议通过带外机制将iSNS服务器中的信息分发到其他iSNS服务器。以下示例说明了在iSNS服务器之间传输数据记录的可能方法。在第一个示例中，使用后端LDAP信息库来支持iSNS服务器，并使用LDAP协议传输数据。一旦远程设备的记录传输完成，使用本地iSNS服务器的本地设备就可以看到并访问该记录。这允许本地设备与远程设备建立会话（前提是可以协商防火墙边界）。
+-------------------------+ +-------------------------+
|+------+ iSNSP | | iSNSP +-----+ |
||dev A |<----->+------+ | | +------+<----->|dev C| |
|+------+ | | | | | | +-----+ |
|+------+ iSNSP |local | | | |remote| iSNSP +-----+ |
||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| |
|+------+ |server| | | |server| +-----+ |
|........ +--+---+ | WAN | +---+--+ |
|.dev C'. | | Link | | |
|........ | ============= | |
| | | | | |
| +--+---+ | | +---+--+ |
| | local|<--- <--- <--- <-|remote| |
| | LDAP | | LDAP: | | LDAP | |
| +------+ Xfer "dev C"| +------+ |
+-------------------------+ +-------------------------+
Enterprise Enterprise
Network A Network B
+-------------------------+ +-------------------------+
|+------+ iSNSP | | iSNSP +-----+ |
||dev A |<----->+------+ | | +------+<----->|dev C| |
|+------+ | | | | | | +-----+ |
|+------+ iSNSP |local | | | |remote| iSNSP +-----+ |
||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| |
|+------+ |server| | | |server| +-----+ |
|........ +--+---+ | WAN | +---+--+ |
|.dev C'. | | Link | | |
|........ | ============= | |
| | | | | |
| +--+---+ | | +---+--+ |
| | local|<--- <--- <--- <-|remote| |
| | LDAP | | LDAP: | | LDAP | |
| +------+ Xfer "dev C"| +------+ |
+-------------------------+ +-------------------------+
Enterprise Enterprise
Network A Network B
In the above diagram, two business partners wish to share storage "dev C". Using LDAP, the record for "dev C" can be transferred from Network B to Network A. Once accessible to the local iSNS server in Network A, local devices A and B can now discover and connect to "dev C".
在上图中，两个业务合作伙伴希望共享存储“dev C”。使用LDAP，“dev C”的记录可以从网络B传输到网络A。一旦网络A中的本地iSNS服务器可以访问，本地设备A和B现在可以发现并连接到“dev C”。
+-------------------------+ +-------------------------+
|+------+ iSNSP | | iSNSP +-----+ |
||dev A |<----->+------+ | | +------+<----->|dev C| |
|+------+ | | | | | | +-----+ |
|+------+ iSNSP |local | | | |remote| iSNSP +-----+ |
||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| |
|+------+ |server| | | |server| +-----+ |
|........ +------+ | WAN | +---+--+ |
|.dev C'. ^ | Link | | |
|........ | ============= v |
| | | | |SNMP |
| | | | | |
| +--+----+ | | v |
| | SNMP |<--- <--- <--- <---- |
| | Mgmt | | SNMP: Xfer "dev C" |
| |Station| | | |
| +-------+ | | |
+-------------------------+ +-------------------------+
Enterprise Enterprise
Network A Network B
+-------------------------+ +-------------------------+
|+------+ iSNSP | | iSNSP +-----+ |
||dev A |<----->+------+ | | +------+<----->|dev C| |
|+------+ | | | | | | +-----+ |
|+------+ iSNSP |local | | | |remote| iSNSP +-----+ |
||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| |
|+------+ |server| | | |server| +-----+ |
|........ +------+ | WAN | +---+--+ |
|.dev C'. ^ | Link | | |
|........ | ============= v |
| | | | |SNMP |
| | | | | |
| +--+----+ | | v |
| | SNMP |<--- <--- <--- <---- |
| | Mgmt | | SNMP: Xfer "dev C" |
| |Station| | | |
| +-------+ | | |
+-------------------------+ +-------------------------+
Enterprise Enterprise
Network A Network B
The above diagram illustrates a second example of how iSNS records can be shared. This method uses an SNMP-based management station to retrieve (GET) the desired record for "dev C" manually, and then to store (SET) it on the local iSNS server directly. Once the record is transferred to the local iSNS server in Network A, "dev C" becomes visible and accessible (provided that firewall boundaries can be negotiated) to other devices in Network A.
上图展示了如何共享iSNS记录的第二个示例。此方法使用基于SNMP的管理站手动检索（获取）所需的“dev C”记录，然后直接将其存储（设置）在本地iSNS服务器上。一旦将记录传输到网络A中的本地iSNS服务器，“dev C”将变得可见，并且可以访问网络A中的其他设备（前提是可以协商防火墙边界）。
Other methods, including proprietary protocols, can be used to transfer device records between iSNS servers. Further discussion and explanation of these methodologies is beyond the scope of this document.
其他方法，包括专有协议，可用于在iSNS服务器之间传输设备记录。对这些方法的进一步讨论和解释超出了本文件的范围。
This section offers a broad framework for implementation and deployment of iSNS backup servers. Server failover and recovery are topics of continuing research, and adequate resolution of issues such as split brain and primary server selection is dependent on the specific implementation requirements and deployment needs. The failover mechanisms discussed in this document focus on the interaction between iSNS clients and iSNS servers. Specifically, what is covered in this document includes the following:
本节为iSNS备份服务器的实施和部署提供了广泛的框架。服务器故障切换和恢复是持续研究的主题，而诸如拆分大脑和主服务器选择等问题的充分解决取决于具体的实施要求和部署需要。本文档中讨论的故障切换机制侧重于iSNS客户端和iSNS服务器之间的交互。具体而言，本文件包括以下内容：
- iSNS client behavior and the iSNS protocol interaction between the client and multiple iSNS servers, some of which are backup servers.
- iSNS客户端行为和客户端与多个iSNS服务器（其中一些是备份服务器）之间的iSNS协议交互。
- Required failover behaviors of the collection of iSNS servers that includes active and backup servers.
- iSNS服务器集合（包括活动服务器和备份服务器）所需的故障切换行为。
However, note that this document does not specify the complete functional failover requirements of each iSNS server. In particular, it does not specify the complete set of protocol interactions among the iSNS servers that are required to achieve stable failover operation in an interoperable manner.
但是，请注意，本文档并未指定每个iSNS服务器的完整功能故障切换要求。特别是，它没有指定iSNS服务器之间以互操作方式实现稳定故障切换操作所需的一整套协议交互。
For the purposes of this discussion, the specified backup mechanisms pertain to interaction among different logical iSNS servers. Note that it is possible to create multiple physical iSNS servers to form a single logical iSNS server cluster, and thus to distribute iSNS transaction processing among multiple physical servers. However, a more detailed discussion of the interactions between physical servers within a logical iSNS server cluster is beyond the scope of this document.
在本讨论中，指定的备份机制与不同逻辑iSNS服务器之间的交互有关。请注意，可以创建多个物理iSNS服务器以形成单个逻辑iSNS服务器群集，从而在多个物理服务器之间分配iSNS事务处理。但是，关于逻辑iSNS服务器群集中物理服务器之间交互的更详细讨论超出了本文档的范围。
Multiple logical iSNS servers can be used to provide redundancy in the event that the active iSNS server fails or is removed from the network. The methods described in Section 2.7 above can be used to transfer name server records to backup iSNS servers. Each backup server maintains a redundant copy of the name server database found in the primary iSNS server, and can respond to iSNS protocol messages in the same way as the active server. Each backup server SHOULD monitor the health and status of the active iSNS server, including checking to make sure its own database is synchronized with the active server's database. How each backup server accomplishes this is implementation-dependent, and may (or may not) include using the iSNS protocol. If the iSNS protocol is used, then the backup server MAY register itself in the active server's iSNS database as a Control Node, allowing it to receive state-change notifications.
多个逻辑iSNS服务器可用于在活动iSNS服务器发生故障或从网络中删除时提供冗余。上述第2.7节中描述的方法可用于将名称服务器记录传输到备份iSNS服务器。每个备份服务器都维护主iSNS服务器中名称服务器数据库的冗余副本，并可以与活动服务器相同的方式响应iSNS协议消息。每个备份服务器都应监视活动iSNS服务器的运行状况和状态，包括检查以确保其自己的数据库与活动服务器的数据库同步。每个备份服务器如何实现这一点取决于实现，可能（也可能不）包括使用iSNS协议。如果使用iSNS协议，则备份服务器可以在活动服务器的iSNS数据库中注册自己作为控制节点，从而接收状态更改通知。
Generally, the administrator or some automated election process is responsible for initial and subsequent designation of the primary server and each backup server.
通常，管理员或某些自动选择过程负责主服务器和每个备份服务器的初始和后续指定。
A maximum of one logical backup iSNS server SHALL exist at any individual IP address, in order to avoid conflicts from multiple servers listening on the same canonical iSNS TCP or UDP port number.
任何单个IP地址上最多应有一台逻辑备份iSNS服务器，以避免多台服务器在同一规范iSNS TCP或UDP端口号上侦听时发生冲突。
The iSNS heartbeat can also be used to coordinate the designation and selection of primary and backup iSNS servers.
iSNS心跳信号还可用于协调主iSNS服务器和备份iSNS服务器的指定和选择。
Each backup server MUST note its relative precedence in the active server's list of backup servers. If its precedence is not already known, each backup server MAY learn it from the iSNS heartbeat message, by noting the position of its IP address in the ordered list
每个备份服务器必须在活动服务器的备份服务器列表中注明其相对优先级。如果尚未知道其优先级，则每个备份服务器都可以通过记录其IP地址在有序列表中的位置，从iSNS心跳消息中了解其优先级
of backup server IP addresses. For example, if it is the first backup listed in the heartbeat message, then its backup precedence is 1. If it is the third backup server listed, then its backup precedence is 3.
备份服务器IP地址的数目。例如，如果它是心跳消息中列出的第一个备份，则其备份优先级为1。如果它是列出的第三个备份服务器，则其备份优先级为3。
If a backup server establishes that it has lost connectivity to the active server and other backup servers of higher precedence, then it SHOULD assume that it is the active server. The method of determining whether connectivity has been lost is implementation-specific. One possible approach is to assume that if the backup server does not receive iSNS heartbeat messages for a period of time, then connectivity to the active server has been lost. Alternatively, the backup server may establish TCP connections to the active server and other backup servers, with loss of connectivity determined through non-response to periodic echo or polling messages (using iSNSP, SNMP, or other protocols).
如果备份服务器确定它已失去与活动服务器和其他优先级较高的备份服务器的连接，则应假定它是活动服务器。确定连接是否丢失的方法是特定于实现的。一种可能的方法是假设备份服务器在一段时间内没有接收到iSNS心跳消息，则与活动服务器的连接已丢失。或者，备份服务器可以建立到活动服务器和其他备份服务器的TCP连接，通过不响应定期回显或轮询消息（使用iSNSP、SNMP或其他协议）确定连接丢失。
When a backup server becomes the active server, it SHALL assume all active server responsibilities, including (if used) transmission of the iSNS heartbeat message. If transmitting the iSNS heartbeat, the backup server replaces the active Server IP Address and TCP/UDP Port entries with its own IP address and TCP/UDP Port, and begins incrementing the counter field from the last known value from the previously-active iSNS server. However, it MUST NOT change the original ordered list of backup server IP Address and TCP/UDP Port entries. If the primary backup server or other higher-precedence backup server returns, then the existing active server is responsible for ensuring that the new active server's database is up-to-date before demoting itself to its original status as backup.
当备份服务器成为活动服务器时，它应承担所有活动服务器的责任，包括（如果使用）iSNS心跳消息的传输。如果传输iSNS心跳信号，备份服务器将用自己的IP地址和TCP/UDP端口替换活动服务器IP地址和TCP/UDP端口条目，并开始从先前活动iSNS服务器的最后一个已知值开始递增计数器字段。但是，它不能更改备份服务器IP地址和TCP/UDP端口项的原始顺序列表。如果主备份服务器或其他优先级更高的备份服务器返回，则现有活动服务器负责确保新活动服务器的数据库是最新的，然后再将其降级为其原始备份状态。
Since the primary and backup iSNS servers maintain a coordinated database, no re-registration by an iSNS Client is required when a backup server takes the active server role. Likewise, no re-registration by an iSNS Client is required when the previous primary server returns to the active server role.
由于主iSNS服务器和备份iSNS服务器维护一个协调的数据库，因此当备份服务器担任活动服务器角色时，iSNS客户端无需重新注册。同样，当以前的主服务器返回到活动服务器角色时，不需要iSNS客户端重新注册。
The iSNS Protocol is transport-neutral. Query and registration messages are transported over TCP or UDP. iSNS heartbeat messages are transported using IP multicast or broadcast.
iSNS协议与传输无关。查询和注册消息通过TCP或UDP传输。iSNS心跳消息使用IP多播或广播传输。
It MUST be possible to use TCP for iSNS communication. The iSNS server MUST accept TCP connections for client registrations. To receive Entity Status Inquiry (ESI) (see Section 5.6.5.13) monitoring the use of TCP, the client registers the Portal ESI Interval and the
必须能够使用TCP进行iSNS通信。iSNS服务器必须接受客户端注册的TCP连接。为了接收监控TCP使用的实体状态查询（ESI）（见第5.6.5.13节），客户机注册门户ESI间隔和
port number of the TCP port that will be used to receive ESI messages. The iSNS server initiates the TCP connection used to deliver the ESI message. This TCP connection does not need to be continuously open.
将用于接收ESI消息的TCP端口的端口号。iSNS服务器启动用于传递ESI消息的TCP连接。此TCP连接不需要持续打开。
To receive SCN notifications using TCP, the client registers the iSCSI or iFCP SCN Bitmap and the port number of the TCP port in the Portal used to receive SCNs. The iSNS server initiates the TCP connection used to deliver the SCN message. This TCP connection does not need to be continuously open.
要使用TCP接收SCN通知，客户端将在用于接收SCN的门户中注册iSCSI或iFCP SCN位图以及TCP端口的端口号。iSNS服务器启动用于传递SCN消息的TCP连接。此TCP连接不需要持续打开。
It is possible for an iSNS client to use the same TCP connection for SCN, ESI, and iSNS queries. Alternatively, separate connections may be used.
iSNS客户端可以对SCN、ESI和iSNS查询使用相同的TCP连接。或者，可以使用单独的连接。
The iSNS server MAY accept UDP messages for client registrations. The iSNS server MUST accept registrations from clients requesting UDP-based ESI and SCN messages.
iSNS服务器可以接受用于客户端注册的UDP消息。iSNS服务器必须接受来自请求基于UDP的ESI和SCN消息的客户端的注册。
To receive UDP-based ESI monitoring messages, the client registers the port number of the UDP port in at least one Portal to be used to receive and respond to ESI messages from the iSNS server. If a Network Entity has multiple Portals with registered ESI UDP Ports, then ESI messages SHALL be delivered to every Portal registered to receive such messages.
要接收基于UDP的ESI监视消息，客户端在至少一个门户中注册UDP端口的端口号，以用于接收和响应来自iSNS服务器的ESI消息。如果一个网络实体有多个具有注册ESI UDP端口的门户，则ESI消息应发送到每个注册以接收此类消息的门户。
To receive UDP-based SCN notification messages, the client registers the port number of the UDP port in at least one Portal to be used to receive SCN messages from the iSNS server. If a Network Entity has multiple Portals with registered SCN UDP Ports, then SCN messages SHALL be delivered to each Portal registered to receive such messages.
要接收基于UDP的SCN通知消息，客户端至少在一个门户中注册UDP端口的端口号，以用于从iSNS服务器接收SCN消息。如果一个网络实体有多个具有注册SCN UDP端口的门户，则SCN消息应发送到每个注册以接收此类消息的门户。
When using UDP to transport iSNS messages, each UDP datagram MUST contain exactly one iSNS PDU (see Section 5).
使用UDP传输iSNS消息时，每个UDP数据报必须正好包含一个iSNS PDU（请参阅第5节）。
iSNS multicast messages are transported using IP multicast or broadcast. The iSNS heartbeat is the only iSNS multicast or broadcast message. This message is originated by the iSNS server and sent to all iSNS clients that are listening on the IP multicast address allocated for the iSNS heartbeat.
iSNS多播消息使用IP多播或广播传输。iSNS心跳是唯一的iSNS多播或广播消息。此消息由iSNS服务器发出，并发送到正在侦听为iSNS心跳分配的IP多播地址的所有iSNS客户端。
The iSNS Server may be managed via the iSNS MIB [iSNSMIB] using an SNMP management framework [RFC3411]. For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to Section 7 of RFC 3410 [RFC3410]. The iSNS MIB provides the ability to configure and monitor an iSNS server without using the iSNS protocol directly. SNMP management frameworks have several requirements for object indexing in order for objects to be accessed or added.
iSNS服务器可以使用SNMP管理框架[RFC3411]通过iSNS MIB[iSNSMIB]进行管理。有关描述当前互联网标准管理框架的文件的详细概述，请参阅RFC 3410[RFC3410]第7节。iSNS MIB提供了配置和监视iSNS服务器的能力，而无需直接使用iSNS协议。SNMP管理框架对对象索引有几个要求，以便访问或添加对象。
SNMP uses an Object Identifier (OID) for object identification. The size of each OID is restricted to a maximum of 128 sub-identifiers. Both the iSCSI and iFCP protocol contain identifiers, such as the iSCSI Name, that are greater the 128 characters in length. Using such identifiers as an index would result in more than 128 sub-identifiers per OID. In order to support objects that have key identifiers whose maximum length is longer than the maximum SNMP-supported length, the iSNS server provides secondary non-zero integer index identifiers. These indexes SHALL be persistent for as long as the server is active. Furthermore, index values for recently deregistered objects SHOULD NOT be reused in the short term. Object attributes, including indexes, are described in detail in Section 6.
SNMP使用对象标识符（OID）进行对象标识。每个OID的大小限制为最多128个子标识符。iSCSI和iFCP协议都包含长度大于128个字符的标识符，如iSCSI名称。使用此类标识符作为索引将导致每个OID超过128个子标识符。为了支持具有最大长度大于SNMP支持的最大长度的密钥标识符的对象，iSNS服务器提供辅助非零整数索引标识符。只要服务器处于活动状态，这些索引应保持不变。此外，近期注销对象的索引值短期内不应重复使用。第6节详细描述了对象属性，包括索引。
For SNMP based management applications to create a new entry in a table of objects, a valid OID must be available to specify the table row. The iSNS server supports this by providing, for each type of object that can be added via SNMP, an object attribute that returns the next available non-zero integer index. This allows an SNMP client to request an OID to be used for registering a new object in the server. Object attributes, including next available index attributes, are described in detail in Section 6.
要使基于SNMP的管理应用程序在对象表中创建新条目，必须有有效的OID来指定表行。iSNS服务器通过为可以通过SNMP添加的每种类型的对象提供一个对象属性来支持这一点，该属性返回下一个可用的非零整数索引。这允许SNMP客户端请求用于在服务器中注册新对象的OID。第6节详细描述了对象属性，包括下一个可用的索引属性。
iSNS provides the framework for the registration, discovery, and management of iSCSI devices and Fibre Channel-based devices (using iFCP). This architecture framework provides elements needed to describe various storage device objects and attributes that may exist on an IP storage network. Objects defined in this architecture framework include Network Entity, Portal, Storage Node, FC Device, Discovery Domain, and Discovery Domain Set. Each of these objects is described in greater detail in the following sections.
iSNS为iSCSI设备和基于光纤通道的设备（使用iFCP）的注册、发现和管理提供了框架。此体系结构框架提供了描述IP存储网络上可能存在的各种存储设备对象和属性所需的元素。此体系结构框架中定义的对象包括网络实体、门户、存储节点、FC设备、发现域和发现域集。以下各节将对这些对象进行更详细的描述。
The Network Entity object is a container of Storage Node objects and Portal objects. It represents the infrastructure supporting access to a unique set of one or more Storage Nodes. The Entity Identifier attribute uniquely distinguishes a Network Entity, and is the key used to register a Network Entity object in an iSNS server. All Storage Nodes and Portals contained within a single Network Entity object operate as a cohesive unit.
网络实体对象是存储节点对象和门户对象的容器。它表示支持访问一组唯一的一个或多个存储节点的基础结构。实体标识符属性唯一区分网络实体，是用于在iSNS服务器中注册网络实体对象的密钥。单个网络实体对象中包含的所有存储节点和入口都作为一个内聚单元运行。
Note that it is possible for a single physical device or gateway to be represented by more than one logical Network Entity in the iSNS database. For example, one of the Storage Nodes on a physical device may be accessible from only a subset of the network interfaces (i.e., Portals) available on that device. In this case, a logical network entity (i.e., a "shadow entity") is created and used to contain the Portals and Storage Nodes that can operate cooperatively. No object (Portals, Storage Nodes, etc.) can be contained in more than one logical Network Entity.
请注意，单个物理设备或网关可能由iSNS数据库中的多个逻辑网络实体表示。例如，物理设备上的一个存储节点可以仅从该设备上可用的网络接口（即，入口）的子集进行访问。在这种情况下，创建并使用逻辑网络实体（即“影子实体”）来包含可协同操作的入口和存储节点。多个逻辑网络实体中不能包含任何对象（入口、存储节点等）。
Similarly, it is possible for a logical Network Entity to be supported by more than one physical device or gateway. For example, multiple FC-iSCSI gateways may be used to bridge FC devices in a single Fibre Channel network. Collectively, the multiple gateways can be used to support a single logical Network Entity that is used to contain all the devices in that Fibre Channel network.
类似地，逻辑网络实体可能由多个物理设备或网关支持。例如，多个FC iSCSI网关可用于桥接单个光纤通道网络中的FC设备。总之，多个网关可用于支持单个逻辑网络实体，该实体用于包含该光纤通道网络中的所有设备。
The Portal object is an interface through which access to Storage Nodes within the Network Entity can be obtained. The IP address and TCP/UDP Port number attributes uniquely distinguish a Portal object, and combined are the key used to register a Portal object in an iSNS server. A Portal is contained in one and only one Network Entity, and may be contained in one or more DDs (see Section 3.6).
门户对象是一个接口，通过它可以访问网络实体中的存储节点。IP地址和TCP/UDP端口号属性是唯一区分门户对象的属性，它们的组合是用于在iSNS服务器中注册门户对象的密钥。门户包含在一个且仅一个网络实体中，并且可以包含在一个或多个DDs中（见第3.6节）。
The Storage Node object is the logical endpoint of an iSCSI or iFCP session. In iFCP, the session endpoint is represented by the World Wide Port Name (WWPN). In iSCSI, the session endpoint is represented by the iSCSI Name of the device. For iSCSI, the iSCSI Name attribute uniquely distinguishes a Storage Node, and is the key used to register a Storage Node object in an iSNS Server. For iFCP, the FC Port Name (WWPN) attribute uniquely distinguishes a Storage Node, and is the key used to register a Storage Node object in the iSNS Server. Storage Node is contained in only one Network Entity object and may be contained in one or more DDs (see Section 3.6).
存储节点对象是iSCSI或iFCP会话的逻辑端点。在iFCP中，会话端点由全球通用端口名（WWPN）表示。在iSCSI中，会话端点由设备的iSCSI名称表示。对于iSCSI，iSCSI名称属性可唯一区分存储节点，是用于在iSNS服务器中注册存储节点对象的密钥。对于iFCP，FC Port Name（WWPN）属性唯一区分存储节点，是用于在iSNS服务器中注册存储节点对象的密钥。存储节点仅包含在一个网络实体对象中，并且可以包含在一个或多个DDs中（参见第3.6节）。
The Portal Group (PG) object represents an association between a Portal and an iSCSI Node. Each Portal and iSCSI Storage Node registered in an Entity can be associated using a Portal Group (PG) object. The PG Tag (PGT), if non-NULL, indicates that the associated Portal provides access to the associated iSCSI Storage Node in the Entity. All Portals that have the same PGT value for a specific iSCSI Storage Node allow coordinated access to that node.
门户组（PG）对象表示门户和iSCSI节点之间的关联。可以使用入口组（PG）对象关联实体中注册的每个入口和iSCSI存储节点。PG标记（PGT）如果不为空，则表示关联的入口提供对实体中关联的iSCSI存储节点的访问。对于特定iSCSI存储节点，所有具有相同PGT值的入口都允许协调访问该节点。
A PG object MAY be registered when a Portal or iSCSI Storage Node is registered. Each Portal to iSCSI Node association is represented by one and only one PG object. In order for a Portal to provide access to an iSCSI Node, the PGT of the PG object MUST be non-NULL. If the PGT value registered for a specified Portal and iSCSI Node is NULL, or if no PGT value is registered, then the Portal does not provide access to that iSCSI Node in the Entity.
注册门户或iSCSI存储节点时，可以注册PG对象。每个入口到iSCSI节点关联由一个且仅一个PG对象表示。为了使门户提供对iSCSI节点的访问，PG对象的PGT必须为非空。如果为指定入口和iSCSI节点注册的PGT值为空，或者如果未注册PGT值，则入口不提供对实体中该iSCSI节点的访问。
The PGT value indicates whether access to an iSCSI Node can be coordinated across multiple Portals. All Portals that have the same PGT value for a specific iSCSI Node can provide coordinated access to that iSCSI Node. According to the iSCSI Specification, coordinated access to an iSCSI node indicates the capability of coordinating an iSCSI session with connections that span these Portals [iSCSI].
PGT值指示是否可以跨多个门户协调对iSCSI节点的访问。对于特定iSCSI节点具有相同PGT值的所有门户都可以提供对该iSCSI节点的协调访问。根据iSCSI规范，对iSCSI节点的协调访问表示能够协调iSCSI会话与跨这些门户的连接[iSCSI]。
The PG object is uniquely distinguished by the iSCSI Name, Portal IP Address, and Portal TCP Port values of the associated Storage Node and Portal objects. These are represented in the iSNS Server by the PG iSCSI Name, PG Portal IP Address, and PG Portal TCP/UDP Port attributes, respectively. The PG object is also uniquely distinguished in the iSNS Server by the PG Index value.
PG对象通过关联存储节点和入口对象的iSCSI名称、入口IP地址和入口TCP端口值进行唯一区分。在iSNS服务器中，它们分别由PG iSCSI名称、PG Portal IP地址和PG Portal TCP/UDP端口属性表示。PG对象在iSNS服务器中也通过PG索引值进行唯一区分。
A new PG object can only be registered by referencing its associated iSCSI Storage Node or Portal object. A pre-existing PG object can be modified or queried by using its Portal Group Index as message key, or by referencing its associated iSCSI Storage Node or Portal object. A 0-length Tag, Length, Value TLV is used to register a PGT NULL value.
新PG对象只能通过引用其关联的iSCSI存储节点或门户对象进行注册。可以通过将其入口组索引用作消息键，或通过引用其关联的iSCSI存储节点或入口对象来修改或查询预先存在的PG对象。长度为0的标记、长度、值TLV用于注册PGT空值。
The PG object is deregistered if and only if its associated iSCSI Node and Portal objects are both removed.
当且仅当PG对象的关联iSCSI节点和门户对象均已删除时，才会注销PG对象。
The FC Device represents the Fibre Channel Node. This object contains information that may be useful in the management of the Fibre Channel device. The FC Node Name (WWNN) attribute uniquely distinguishes an FC Device, and is the key used to register an FC Device object in the iSNS Server.
FC设备表示光纤通道节点。此对象包含在光纤通道设备管理中可能有用的信息。FC节点名称（WWNN）属性可唯一区分FC设备，是用于在iSNS服务器中注册FC设备对象的密钥。
The FC Device is contained in one or more Storage Node objects.
FC设备包含在一个或多个存储节点对象中。
Discovery Domains (DD) are a security and management mechanism used to administer access and connectivity to storage devices. For query and registration purposes, they are considered containers for Storage Node and Portal objects. A query by an iSNS client that is not from a Control Node only returns information about objects with which it shares at least one active DD. The only exception to this rule is with Portals; if Storage Nodes of a Network Entity are registered in the DD without Portals, then all Portals of that Network Entity are implicit members of that DD. The Discovery Domain ID (DD_ID) attribute uniquely distinguishes a Discovery Domain object, and is the key used to register a Discovery Domain object in the iSNS Server.
发现域（DD）是一种安全和管理机制，用于管理对存储设备的访问和连接。出于查询和注册目的，它们被视为存储节点和门户对象的容器。不是来自控制节点的iSNS客户端的查询仅返回与之共享至少一个活动DD的对象的信息。此规则的唯一例外是门户；如果网络实体的存储节点在DD中注册而没有门户，则该网络实体的所有门户都是该DD的隐式成员。发现域ID（DD_ID）属性唯一区分发现域对象，是用于在iSNS服务器中注册发现域对象的密钥。
A DD is considered active if it is a member of at least one active DD Set. DDs that are not members of at least one enabled DDS are considered disabled. A Storage Node can be a member of one or more DDs. An enabled DD establishes connectivity among the Storage Nodes in that DD.
如果DD是至少一个活动DD集的成员，则认为其为活动DD。不属于至少一个已启用DDs成员的DDs被视为已禁用。存储节点可以是一个或多个DDs的成员。启用的DD在该DD中的存储节点之间建立连接。
The Discovery Domain Set (DDS) is a container object for Discovery Domains (DDs). DDSs may contain one or more DDs. Similarly, each DD can be a member of one or more DDSs. DDSs are a mechanism to store coordinated sets of DD mappings in the iSNS server. Active DDs are members of at least one active DD Set. Multiple DDSs may be considered active at the same time. The Discovery Domain Set ID (DDS_ID) attribute uniquely distinguishes a Discovery Domain Set object, and is the key used to register a Discovery Domain Set object in the iSNS Server.
发现域集（DDS）是发现域（DDS）的容器对象。DDs可以包含一个或多个DDs。类似地，每个DD可以是一个或多个DD的成员。DDS是一种在iSNS服务器中存储协调的DD映射集的机制。活动DD是至少一个活动DD集合的成员。多个DDS可被视为同时激活。发现域集ID（DDS_ID）属性唯一区分发现域集对象，是用于在iSNS服务器中注册发现域集对象的密钥。
As presented to the iSNS client, each object of a specific type in the iSNS database MUST have an implicit internal linear ordering based on the key(s) for that object type. This ordering provides the
正如向iSNS客户端显示的那样，iSNS数据库中特定类型的每个对象必须具有基于该对象类型的键的隐式内部线性排序。此订购提供
ability to respond to DevGetNext queries (see Section 5.6.5.3). The ordering of objects in the iSNS database SHOULD NOT be changed with respect to that implied ordering, as a consequence of object insertions and deletions. That is, the relative order of surviving object entries in the iSNS database SHOULD be preserved so that the DevGetNext message encounters generally reasonable behavior.
能够响应DevGetNext查询（见第5.6.5.3节）。iSNS数据库中对象的顺序不应因插入和删除对象而改变。也就是说，应保留iSNS数据库中幸存对象条目的相对顺序，以便DevGetNext消息遇到一般合理的行为。
The following diagram shows the various objects described above and their relationship to each other.
下图显示了上述各种对象及其相互之间的关系。
+--------------+ +-----------+
| NETWORK |1 *| |
| ENTITY |----| PORTAL |
| | | |
+--------------+ +-----------+
|1 |1 |*
| | |
| |* |
| +----------+ |
| | PORTAL | |
| | GROUP | |
| +----------+ |
| |* |
| | |
|* |1 |*
+-----------+ +--------------+ +-----------+ +-----------+
| FC |1 *| STORAGE |* *| DISCOVERY |* *| DISCOVERY |
| DEVICE |----| NODE |----| DOMAIN |----| DOMAIN |
| | | | | | | SET |
+-----------+ +--------------+ +-----------+ +-----------+
+--------------+ +-----------+
| NETWORK |1 *| |
| ENTITY |----| PORTAL |
| | | |
+--------------+ +-----------+
|1 |1 |*
| | |
| |* |
| +----------+ |
| | PORTAL | |
| | GROUP | |
| +----------+ |
| |* |
| | |
|* |1 |*
+-----------+ +--------------+ +-----------+ +-----------+
| FC |1 *| STORAGE |* *| DISCOVERY |* *| DISCOVERY |
| DEVICE |----| NODE |----| DOMAIN |----| DOMAIN |
| | | | | | | SET |
+-----------+ +--------------+ +-----------+ +-----------+
* represents 0 to many possible relationships
* 表示0到多个可能的关系
This section details specific requirements for support of each of these IP storage protocols. Implementation requirements for security are described in Section 7.
本节详细介绍了支持每种IP存储协议的具体要求。第7节描述了安全性的实施要求。
Use of iSNS in support of iSCSI is OPTIONAL. iSCSI devices MAY be manually configured with the iSCSI Name and IP address of peer devices, without the aid or intervention of iSNS. iSCSI devices may also use SLP [RFC2608] to discover peer iSCSI devices. However, iSNS is useful for scaling a storage network to a larger number of iSCSI devices.
使用iSNS支持iSCSI是可选的。可以使用对等设备的iSCSI名称和IP地址手动配置iSCSI设备，而无需iSNS的帮助或干预。iSCSI设备也可以使用SLP[RFC2608]来发现对等iSCSI设备。但是，iSNS对于将存储网络扩展到更多iSCSI设备非常有用。
The following attributes are available to support iSCSI. Attributes indicated in the REQUIRED for Server column MUST be implemented by an iSNS server used to support iSCSI. Attributes indicated in the REQUIRED for Client column MUST be implemented by an iSCSI device that elects to use the iSNS. Attributes indicated in the K (Key) column uniquely identify the object type in the iSNS Server. A more detailed description of each attribute is found in Section 6.
以下属性可用于支持iSCSI。必须由用于支持iSCSI的iSNS服务器实现服务器所需列中指示的属性。必须由选择使用iSNS的iSCSI设备实现客户机所需列中指示的属性。K（键）列中指示的属性唯一标识iSNS服务器中的对象类型。有关每个属性的更详细说明，请参见第6节。
REQUIRED for:
Object Attribute K Server Client
------ --------- - ------ ------
NETWORK ENTITY Entity Identifier * * *
Entity Protocol * *
Management IP Address *
Timestamp *
Protocol Version Range *
Registration Period *
Entity Index *
Entity IKE Phase-1 Proposal
Entity Certificate
REQUIRED for:
Object Attribute K Server Client
------ --------- - ------ ------
NETWORK ENTITY Entity Identifier * * *
Entity Protocol * *
Management IP Address *
Timestamp *
Protocol Version Range *
Registration Period *
Entity Index *
Entity IKE Phase-1 Proposal
Entity Certificate
PORTAL IP Address * * *
TCP/UDP Port * * *
Portal Symbolic Name *
ESI Interval *
ESI Port *
Portal Index *
SCN Port *
Portal Security Bitmap *
Portal IKE Phase-1 Proposal
Portal IKE Phase-2 Proposal
Portal Certificate
PORTAL IP Address * * *
TCP/UDP Port * * *
Portal Symbolic Name *
ESI Interval *
ESI Port *
Portal Index *
SCN Port *
Portal Security Bitmap *
Portal IKE Phase-1 Proposal
Portal IKE Phase-2 Proposal
Portal Certificate
PORTAL GROUP PG iSCSI Name * * *
PG IP Address * * *
PG TCP/UDP Port * * *
PG Tag * *
PG Index *
PORTAL GROUP PG iSCSI Name * * *
PG IP Address * * *
PG TCP/UDP Port * * *
PG Tag * *
PG Index *
STORAGE NODE iSCSI Name * * *
iSCSI Node Type * *
Alias *
iSCSI SCN Bitmap *
iSCSI Node Index *
WWNN Token
iSCSI AuthMethod
iSCSI Node Certificate
STORAGE NODE iSCSI Name * * *
iSCSI Node Type * *
Alias *
iSCSI SCN Bitmap *
iSCSI Node Index *
WWNN Token
iSCSI AuthMethod
iSCSI Node Certificate
DISCOVERY DOMAIN DD ID * * *
DD Symbolic Name *
DD Member iSCSI Node Index *
DD Member iSCSI Name *
DD Member Portal Index *
DD Member Portal IP Addr *
DD Member Portal TCP/UDP *
DD Features *
DISCOVERY DOMAIN DD ID * * *
DD Symbolic Name *
DD Member iSCSI Node Index *
DD Member iSCSI Name *
DD Member Portal Index *
DD Member Portal IP Addr *
DD Member Portal TCP/UDP *
DD Features *
DISCOVERY DOMAIN DDS Identifier * *
SET DDS Symbolic Name *
DDS Status *
DISCOVERY DOMAIN DDS Identifier * *
SET DDS Symbolic Name *
DDS Status *
All iSCSI user-specified and vendor-specified attributes are OPTIONAL to implement and use.
所有iSCSI用户指定和供应商指定的属性都是可选的，可以实施和使用。
The following diagram models how a simple iSCSI-based initiator and target is represented using database objects stored in the iSNS server. In this implementation, each target and initiator is attached to a single Portal.
下图模拟了如何使用存储在iSNS服务器中的数据库对象表示简单的基于iSCSI的启动器和目标。在此实现中，每个目标和启动器都连接到单个门户。
+----------------------------------------------------------------+
| IP Network |
+------------+--------------------------------------+------------+
| |
| |
+-----+------+------+-----+ +-----+------+------+-----+
| | PORTAL | | | | PORTAL | |
| | -IP Addr 1 | | | | -IP Addr 2 | |
| | -TCP Port 1 | | | | -TCP Port 2 | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | | | | | | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | PORTAL GROUP| | | | PORTAL GROUP| |
| | -Prtl Tag 1 | | | | -Prtl Tag 2 | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | | | | | | |
| +--------+ +--------+ | | +-------+ +--------+ |
| | | | | | | |
| | STORAGE NODE | | | | STORAGE NODE | |
| | -iSCSI Name | | | | -iSCSI Name | |
| | -Alias: "server1"| | | | -Alias: "disk1"| |
| | -Type: initiator | | | | -Type: target | |
| | | | | | | |
| +-------------------+ | | +------------------+ |
| | | |
| NETWORK ENTITY | | NETWORK ENTITY |
| -Entity ID (FQDN): | | -Entity ID (FQDN): |
| "strg1.example.com" | | "strg2.example.net" |
| -Protocol: iSCSI | | -Protocol: iSCSI |
| | | |
+-------------------------+ +-------------------------+
+----------------------------------------------------------------+
| IP Network |
+------------+--------------------------------------+------------+
| |
| |
+-----+------+------+-----+ +-----+------+------+-----+
| | PORTAL | | | | PORTAL | |
| | -IP Addr 1 | | | | -IP Addr 2 | |
| | -TCP Port 1 | | | | -TCP Port 2 | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | | | | | | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | PORTAL GROUP| | | | PORTAL GROUP| |
| | -Prtl Tag 1 | | | | -Prtl Tag 2 | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | | | | | | |
| +--------+ +--------+ | | +-------+ +--------+ |
| | | | | | | |
| | STORAGE NODE | | | | STORAGE NODE | |
| | -iSCSI Name | | | | -iSCSI Name | |
| | -Alias: "server1"| | | | -Alias: "disk1"| |
| | -Type: initiator | | | | -Type: target | |
| | | | | | | |
| +-------------------+ | | +------------------+ |
| | | |
| NETWORK ENTITY | | NETWORK ENTITY |
| -Entity ID (FQDN): | | -Entity ID (FQDN): |
| "strg1.example.com" | | "strg2.example.net" |
| -Protocol: iSCSI | | -Protocol: iSCSI |
| | | |
+-------------------------+ +-------------------------+
The object model can be expanded to describe more complex devices, such as an iSCSI device with more than one storage controller, in which each controller is accessible through any of multiple Portal interfaces, possibly using multiple Portal Groups. The storage controllers on this device can be accessed through alternate Portal interfaces if any original interface should fail. The following diagram describes such a device:
对象模型可以扩展以描述更复杂的设备，例如具有多个存储控制器的iSCSI设备，其中每个控制器都可以通过多个入口接口（可能使用多个入口组）中的任何一个进行访问。如果任何原始接口出现故障，可以通过备用入口接口访问此设备上的存储控制器。下图描述了此类设备：
+---------------------------------------------------------------+
| IP Network |
+-------------------+-----------------------+-------------------+
| |
| |
+------------+------+------+---------+------+------+------------+
| | PORTAL 1 | | PORTAL 2 | |
| | -IP Addr 1 | | -IP Addr 2 | |
| | -TCP Port 1 | | -TCP Port 2 | |
| +-----+ +-----+ +-----+ +-----+ |
| | | | | |
| +---------------+ +---------------------+ +---------------+ |
| +-------+ +----------------+ +-------------------+ +------+ |
| | | | | | | |
| +-------+ +-------+ +------+ +--------+ +--------+ +------+ |
| | | | | | | |
| | STORAGE NODE 1 | | STORAGE NODE 2 | | STORAGE NODE 3 | |
| | -iSCSI Name 1 | | -iSCSI Name 2 | | -iSCSI Name 3 | |
| | -Alias: "disk1"| | -Alias: "disk2"| | -Alias: "disk3"| |
| | -Type: target | | -Type: target | | -Type: target | |
| | | | | | | |
| +-----------------+ +-----------------+ +-----------------+ |
| |
| NETWORK ENTITY |
| -Entity ID (FQDN): "dev1.example.com" |
| -Protocol: iSCSI |
| |
| Portal Group Object Table |
| Storage-Node Portal Portal-Group-Tag |
| 1 1 10 |
| 1 2 NULL (no access permitted) |
| 2 1 20 |
| 2 2 20 |
| 3 1 30 |
| 3 2 10 |
| |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| IP Network |
+-------------------+-----------------------+-------------------+
| |
| |
+------------+------+------+---------+------+------+------------+
| | PORTAL 1 | | PORTAL 2 | |
| | -IP Addr 1 | | -IP Addr 2 | |
| | -TCP Port 1 | | -TCP Port 2 | |
| +-----+ +-----+ +-----+ +-----+ |
| | | | | |
| +---------------+ +---------------------+ +---------------+ |
| +-------+ +----------------+ +-------------------+ +------+ |
| | | | | | | |
| +-------+ +-------+ +------+ +--------+ +--------+ +------+ |
| | | | | | | |
| | STORAGE NODE 1 | | STORAGE NODE 2 | | STORAGE NODE 3 | |
| | -iSCSI Name 1 | | -iSCSI Name 2 | | -iSCSI Name 3 | |
| | -Alias: "disk1"| | -Alias: "disk2"| | -Alias: "disk3"| |
| | -Type: target | | -Type: target | | -Type: target | |
| | | | | | | |
| +-----------------+ +-----------------+ +-----------------+ |
| |
| NETWORK ENTITY |
| -Entity ID (FQDN): "dev1.example.com" |
| -Protocol: iSCSI |
| |
| Portal Group Object Table |
| Storage-Node Portal Portal-Group-Tag |
| 1 1 10 |
| 1 2 NULL (no access permitted) |
| 2 1 20 |
| 2 2 20 |
| 3 1 30 |
| 3 2 10 |
| |
+---------------------------------------------------------------+
Storage Node 1 is accessible via Portal 1 with a PGT of 10. It does not have a Portal Group Tag (PGT) assigned for Portal 2, so Storage Node 1 cannot be accessed via Portal 2.
存储节点1可通过入口1访问，PGT为10。它没有为入口2分配入口组标记（PGT），因此无法通过入口2访问存储节点1。
Storage Node 2 can be accessed via both Portal 1 and Portal 2. Since Storage Node 2 has the same PGT value assigned to both Portal 1 and Portal 2, in this case 20, coordinated access via the Portals is available [iSCSI].
可以通过入口1和入口2访问存储节点2。由于存储节点2具有分配给入口1和入口2的相同PGT值，在本例中为20，因此可以通过入口进行协调访问[iSCSI]。
Storage Node 3 can be accessed via Portal 1 or Portal 2. However, since Storage Node 3 has different PGT values assigned to each Portal, in this case 10 and 30, access is not coordinated [iSCSI]. Because PGTs are assigned within the context of a Storage Node, the PGT value of 10 used for Storage Node 1 and Storage Node 3 are not interrelated.
可以通过入口1或入口2访问存储节点3。但是，由于存储节点3为每个入口分配了不同的PGT值，在本例中为10和30，因此访问不协调[iSCSI]。因为PGT是在存储节点的上下文中分配的，所以用于存储节点1和存储节点3的PGT值10是不相关的。
The following iSNSP messages and responses are available in support of iSCSI. Messages indicated in the REQUIRED for Server column MUST be implemented in iSNS servers used for iSCSI devices. Messages indicated in the REQUIRED for Client column MUST be implemented in iSCSI devices that elect to use the iSNS server.
以下iSNSP消息和响应可用于支持iSCSI。必须在用于iSCSI设备的iSNS服务器中实现服务器所需列中指示的消息。必须在选择使用iSNS服务器的iSCSI设备中实现客户端所需列中指示的消息。
REQUIRED for:
Message Description Abbreviation Func_ID Server Client
------------------- ------------ ------- ------ ------
RESERVED 0x0000
Device Attr Reg Request DevAttrReg 0x0001 * *
Dev Attr Query Request DevAttrQry 0x0002 * *
Dev Get Next Request DevGetNext 0x0003 *
Deregister Dev Request DevDereg 0x0004 * *
SCN Register Request SCNReg 0x0005 *
SCN Deregister Request SCNDereg 0x0006 *
SCN Event SCNEvent 0x0007 *
State Change Notification SCN 0x0008 *
DD Register DDReg 0x0009 * *
DD Deregister DDDereg 0x000A * *
DDS Register DDSReg 0x000B * *
DDS Deregister DDSDereg 0x000C * *
Entity Status Inquiry ESI 0x000D *
Name Service Heartbeat Heartbeat 0x000E
RESERVED 0x000F-0x00FF
Vendor Specific 0x0100-0x01FF
RESERVED 0x0200-0x7FFF
REQUIRED for:
Message Description Abbreviation Func_ID Server Client
------------------- ------------ ------- ------ ------
RESERVED 0x0000
Device Attr Reg Request DevAttrReg 0x0001 * *
Dev Attr Query Request DevAttrQry 0x0002 * *
Dev Get Next Request DevGetNext 0x0003 *
Deregister Dev Request DevDereg 0x0004 * *
SCN Register Request SCNReg 0x0005 *
SCN Deregister Request SCNDereg 0x0006 *
SCN Event SCNEvent 0x0007 *
State Change Notification SCN 0x0008 *
DD Register DDReg 0x0009 * *
DD Deregister DDDereg 0x000A * *
DDS Register DDSReg 0x000B * *
DDS Deregister DDSDereg 0x000C * *
Entity Status Inquiry ESI 0x000D *
Name Service Heartbeat Heartbeat 0x000E
RESERVED 0x000F-0x00FF
Vendor Specific 0x0100-0x01FF
RESERVED 0x0200-0x7FFF
The following are iSNSP response messages used in support of iSCSI:
以下是用于支持iSCSI的iSNSP响应消息：
REQUIRED for:
Response Message Desc Abbreviation Func_ID Server Client
--------------------- ------------ ------- ------ ------
RESERVED 0x8000
Device Attr Register Rsp DevAttrRegRsp 0x8001 * *
Device Attr Query Rsp DevAttrQryRsp 0x8002 * *
Device Get Next Rsp DevGetNextRsp 0x8003 *
Device Dereg Rsp DevDeregRsp 0x8004 * *
SCN Register Rsp SCNRegRsp 0x8005 *
REQUIRED for:
Response Message Desc Abbreviation Func_ID Server Client
--------------------- ------------ ------- ------ ------
RESERVED 0x8000
Device Attr Register Rsp DevAttrRegRsp 0x8001 * *
Device Attr Query Rsp DevAttrQryRsp 0x8002 * *
Device Get Next Rsp DevGetNextRsp 0x8003 *
Device Dereg Rsp DevDeregRsp 0x8004 * *
SCN Register Rsp SCNRegRsp 0x8005 *
SCN Deregister Rsp SCNDeregRsp 0x8006 *
SCN Event Rsp SCNEventRsp 0x8007 *
SCN Response SCNRsp 0x8008 *
DD Register Rsp DDRegRsp 0x8009 * *
DD Deregister Rsp DDDeregRsp 0x800A * *
DDS Register Rsp DDSRegRsp 0x800B * *
DDS Deregister Rsp DDSDeregRsp 0x800C * *
Entity Stat Inquiry Rsp ESIRsp 0x800D *
RESERVED 0x800E-0x80FF
Vendor Specific 0x8100-0x81FF
RESERVED 0x8200-0xFFFF
SCN Deregister Rsp SCNDeregRsp 0x8006 *
SCN Event Rsp SCNEventRsp 0x8007 *
SCN Response SCNRsp 0x8008 *
DD Register Rsp DDRegRsp 0x8009 * *
DD Deregister Rsp DDDeregRsp 0x800A * *
DDS Register Rsp DDSRegRsp 0x800B * *
DDS Deregister Rsp DDSDeregRsp 0x800C * *
Entity Stat Inquiry Rsp ESIRsp 0x800D *
RESERVED 0x800E-0x80FF
Vendor Specific 0x8100-0x81FF
RESERVED 0x8200-0xFFFF
In iFCP, use of iSNS is REQUIRED. No alternatives exist for support of iFCP Naming & Discovery functions.
在iFCP中，需要使用iSNS。不存在支持iFCP命名和发现功能的替代方案。
The following table displays attributes that are used by iSNS to support iFCP. Attributes indicated in the REQUIRED for Server column MUST be implemented by the iSNS server that supports iFCP. Attributes indicated in the REQUIRED for Client column MUST be supported by iFCP gateways. Attributes indicated in the K (Key) column uniquely identify the object type in the iSNS Server. A more detailed description of each attribute is found in Section 6.
下表显示了iSNS用于支持iFCP的属性。服务器所需列中指示的属性必须由支持iFCP的iSNS服务器实现。iFCP网关必须支持REQUIRED for Client列中指示的属性。K（键）列中指示的属性唯一标识iSNS服务器中的对象类型。有关每个属性的更详细说明，请参见第6节。
REQUIRED for:
Object Attribute K Server Client
------ --------- - ------ ------
NETWORK ENTITY Entity Identifier * * *
Entity Protocol * *
Management IP Address *
Timestamp *
Protocol Version Range *
Registration period
Entity Index
Entity IKE Phase-1 Proposal
Entity Certificate
REQUIRED for:
Object Attribute K Server Client
------ --------- - ------ ------
NETWORK ENTITY Entity Identifier * * *
Entity Protocol * *
Management IP Address *
Timestamp *
Protocol Version Range *
Registration period
Entity Index
Entity IKE Phase-1 Proposal
Entity Certificate
PORTAL IP Address * * *
TCP/UDP Port * * *
Symbolic Name *
ESI Interval *
ESI Port *
SCN Port *
Portal IKE Phase-1 Proposal
Portal IKE Phase-2 Proposal
PORTAL IP Address * * *
TCP/UDP Port * * *
Symbolic Name *
ESI Interval *
ESI Port *
SCN Port *
Portal IKE Phase-1 Proposal
Portal IKE Phase-2 Proposal
Portal Certificate Security Bitmap *
门户证书安全位图*
STORAGE NODE FC Port Name (WWPN) * * *
(FC Port) Port_ID * *
FC Port Type * *
Port Symbolic Name *
Fabric Port Name (FWWN) *
Hard Address *
Port IP Address *
Class of Service *
FC FC-4 Types *
FC FC-4 Descriptors *
FC FC-4 Features *
SCN Bitmap *
iFCP Port Role *
Permanent Port Name *
STORAGE NODE FC Port Name (WWPN) * * *
(FC Port) Port_ID * *
FC Port Type * *
Port Symbolic Name *
Fabric Port Name (FWWN) *
Hard Address *
Port IP Address *
Class of Service *
FC FC-4 Types *
FC FC-4 Descriptors *
FC FC-4 Features *
SCN Bitmap *
iFCP Port Role *
Permanent Port Name *
FC DEVICE FC Node Name (WWNN) * * *
(FC Node) Node Symbolic Name *
Node IP Address *
Node IPA *
Proxy iSCSI Name
FC DEVICE FC Node Name (WWNN) * * *
(FC Node) Node Symbolic Name *
Node IP Address *
Node IPA *
Proxy iSCSI Name
DISCOVERY DOMAIN DD ID * * *
DD Symbolic Name *
DD Member FC Port Name *
DD Member Portal Index *
DD Member Portal IP Addr *
DD Member Portal TCP/UDP *
DISCOVERY DOMAIN DD ID * * *
DD Symbolic Name *
DD Member FC Port Name *
DD Member Portal Index *
DD Member Portal IP Addr *
DD Member Portal TCP/UDP *
DISCOVERY DOMAIN DDS ID * *
SET DDS Symbolic Name *
DDS Status *
DISCOVERY DOMAIN DDS ID * *
SET DDS Symbolic Name *
DDS Status *
OTHER Switch Name Preferred_ID Assigned_ID Virtual_Fabric_ID
其他交换机名称首选\u ID分配\u ID虚拟\u结构\u ID
All iFCP user-specified and vendor-specified attributes are OPTIONAL to implement and use.
所有iFCP用户指定和供应商指定的属性都是可选的，可以实现和使用。
The iFCP protocol allows native Fibre Channel devices or Fibre Channel fabrics connected to an iFCP gateway to be directly internetworked using IP.
iFCP协议允许使用IP直接互连连接到iFCP网关的本机光纤通道设备或光纤通道结构。
When supporting iFCP, the iSNS server stores Fibre Channel device attributes, iFCP gateway attributes, and Fibre Channel fabric switch attributes that might also be stored in an FC name server.
支持iFCP时，iSNS服务器存储光纤通道设备属性、iFCP网关属性和光纤通道结构交换机属性，这些属性也可能存储在FC名称服务器中。
The following diagram shows a representation of a gateway supporting multiple Fibre Channel devices behind it. The two Portal objects represent IP interfaces on the iFCP gateway that can be used to access any of the three Storage Node objects behind it. Note that the FC Device object is not contained in the Network Entity object. However, each FC Device has a relationship to one or more Storage Node objects.
下图显示了支持多个光纤通道设备的网关的表示形式。这两个门户对象表示iFCP网关上的IP接口，可用于访问其后面的三个存储节点对象中的任何一个。请注意，FC设备对象不包含在网络实体对象中。但是，每个FC设备都与一个或多个存储节点对象有关系。
+--------------------------------------------------------+
| IP Network |
+--------+-----------------+-----------------------------+
| |
+-+------+------+---+------+------+----------------------+
| | PORTAL | | PORTAL | NETWORK ENTITY |
| | -IP Addr 1 | | -IP Addr 2 | -Entity ID (FQDN): |
| | -TCP Port 1 | | -TCP Port 2 | "gtwy1.example.com" |
| +-----+ +-----+ +-----+ +-----+ -Protocol: iFCP |
| | | | | |
| +-----+ +---------------+ +----------------------+ |
| +-----+ +---------------+ +-------------+ +------+ |
| | | | | | | |
| +-----+ +-----+ +----+ +------+ +----+ +------+ |
| |STORAGE NODE | |STORAGE NODE | |STORAGE NODE | |
| | -WWPN 1 | | -WWPN 2 | | -WWPN 3 | |
| | -Port ID 1 | | -Port ID 2 | | -Port ID 3 | |
| | -FWWN 1 | | -FWWN 2 | | -FWWN 3 | |
| | -FC COS | | -FC COS | | -FC COS | |
| +------+------+ +-------+-----+ +----+--------+ |
+--------|-------------------|------------|--------------+
| | |
+------+------+ +---+------------+---+
| FC DEVICE | | FC DEVICE |
| -WWNN 1 | | -WWNN 2 |
| | | |
+-------------+ +--------------------+
+--------------------------------------------------------+
| IP Network |
+--------+-----------------+-----------------------------+
| |
+-+------+------+---+------+------+----------------------+
| | PORTAL | | PORTAL | NETWORK ENTITY |
| | -IP Addr 1 | | -IP Addr 2 | -Entity ID (FQDN): |
| | -TCP Port 1 | | -TCP Port 2 | "gtwy1.example.com" |
| +-----+ +-----+ +-----+ +-----+ -Protocol: iFCP |
| | | | | |
| +-----+ +---------------+ +----------------------+ |
| +-----+ +---------------+ +-------------+ +------+ |
| | | | | | | |
| +-----+ +-----+ +----+ +------+ +----+ +------+ |
| |STORAGE NODE | |STORAGE NODE | |STORAGE NODE | |
| | -WWPN 1 | | -WWPN 2 | | -WWPN 3 | |
| | -Port ID 1 | | -Port ID 2 | | -Port ID 3 | |
| | -FWWN 1 | | -FWWN 2 | | -FWWN 3 | |
| | -FC COS | | -FC COS | | -FC COS | |
| +------+------+ +-------+-----+ +----+--------+ |
+--------|-------------------|------------|--------------+
| | |
+------+------+ +---+------------+---+
| FC DEVICE | | FC DEVICE |
| -WWNN 1 | | -WWNN 2 |
| | | |
+-------------+ +--------------------+
The iSNSP messages and responses displayed in the following tables are available to support iFCP gateways. Messages indicated in the REQUIRED TO IMPLEMENT column MUST be supported by the iSNS server used by iFCP gateways. Messages indicated in the REQUIRED TO USE column MUST be supported by the iFCP gateways themselves.
下表中显示的iSNSP消息和响应可用于支持iFCP网关。iFCP网关使用的iSNS服务器必须支持“需要实现”列中指示的消息。“需要使用”列中指示的消息必须由iFCP网关本身支持。
REQUIRED for:
Message Description Abbreviation Func ID Server Client
------------------- ------------ ------- ------ ------
RESERVED 0x0000
Device Attr Reg Request DevAttrReg 0x0001 * *
Device Attr Query Request DevAttrQry 0x0002 * *
Device Get Next Request DevGetNext 0x0003 *
Device Dereg Request DevDereg 0x0004 * *
SCN Register Request SCNReg 0x0005 *
SCN Deregister Request SCNDereg 0x0006 *
SCN Event SCNEvent 0x0007 *
State Change Notification SCN 0x0008 *
DD Register DDReg 0x0009 * *
DD Deregister DDDereg 0x000A * *
DDS Register DDSReg 0x000B * *
DDS Deregister DDSDereg 0x000C * *
Entity Status Inquiry ESI 0x000D *
Name Service Heartbeat Heartbeat 0x000E *
Reserved Reserved 0x000F-0x0010
Request FC_DOMAIN_ID RqstDomId 0x0011
Release FC_DOMAIN_ID RlseDomId 0x0012
Get FC_DOMAIN_IDs GetDomId 0x0013
RESERVED 0x0014-0x00FF
Vendor Specific 0x0100-0x01FF
RESERVED 0x0200-0x7FFF
REQUIRED for:
Message Description Abbreviation Func ID Server Client
------------------- ------------ ------- ------ ------
RESERVED 0x0000
Device Attr Reg Request DevAttrReg 0x0001 * *
Device Attr Query Request DevAttrQry 0x0002 * *
Device Get Next Request DevGetNext 0x0003 *
Device Dereg Request DevDereg 0x0004 * *
SCN Register Request SCNReg 0x0005 *
SCN Deregister Request SCNDereg 0x0006 *
SCN Event SCNEvent 0x0007 *
State Change Notification SCN 0x0008 *
DD Register DDReg 0x0009 * *
DD Deregister DDDereg 0x000A * *
DDS Register DDSReg 0x000B * *
DDS Deregister DDSDereg 0x000C * *
Entity Status Inquiry ESI 0x000D *
Name Service Heartbeat Heartbeat 0x000E *
Reserved Reserved 0x000F-0x0010
Request FC_DOMAIN_ID RqstDomId 0x0011
Release FC_DOMAIN_ID RlseDomId 0x0012
Get FC_DOMAIN_IDs GetDomId 0x0013
RESERVED 0x0014-0x00FF
Vendor Specific 0x0100-0x01FF
RESERVED 0x0200-0x7FFF
The following are iSNSP response messages in support of iFCP:
以下是支持iFCP的iSNSP响应消息：
REQUIRED for:
Response Message Desc Abbreviation Func_ID Server Client
--------------------- ------------ ------- ------ ------
RESERVED 0x8000
Device Attr Reg Rsp DevAttrRegRsp 0x8001 * *
Device Attr Query Rsp DevAttrQryRsp 0x8002 * *
Device Get Next Rsp DevGetNextRsp 0x8003 *
Device Deregister Rsp DevDeregRsp 0x8004 * *
SCN Register Rsp SCNRegRsp 0x8005 *
SCN Deregister Rsp SCNDeregRsp 0x8006 *
SCN Event Rsp SCNEventRsp 0x8007 *
SCN Rsp SCNRsp 0x8008 *
REQUIRED for:
Response Message Desc Abbreviation Func_ID Server Client
--------------------- ------------ ------- ------ ------
RESERVED 0x8000
Device Attr Reg Rsp DevAttrRegRsp 0x8001 * *
Device Attr Query Rsp DevAttrQryRsp 0x8002 * *
Device Get Next Rsp DevGetNextRsp 0x8003 *
Device Deregister Rsp DevDeregRsp 0x8004 * *
SCN Register Rsp SCNRegRsp 0x8005 *
SCN Deregister Rsp SCNDeregRsp 0x8006 *
SCN Event Rsp SCNEventRsp 0x8007 *
SCN Rsp SCNRsp 0x8008 *
DD Register Rsp DDRegRsp 0x8009 * *
DD Deregister Rsp DDDeregRsp 0x800A * *
DDS Register Rsp DDSRegRsp 0x800B * *
DDS Deregister Rsp DDSDeregRsp 0x800C * *
Entity Status Inquiry Rsp ESIRsp 0x800D *
NOT USED 0x800E
RESERVED 0x800F-0x8010
Request FC_DOMAIN_ID Rsp RqstDomIdRsp 0x8011
Release FC_DOMAIN_ID Rsp RlseDomIdRsp 0x8012
Get FC_DOMAIN_IDs GetDomIdRsp 0x0013
RESERVED 0x8014-0x80FF
Vendor Specific 0x8100-0x81FF
RESERVED 0x8200-0xFFFF
DD Register Rsp DDRegRsp 0x8009 * *
DD Deregister Rsp DDDeregRsp 0x800A * *
DDS Register Rsp DDSRegRsp 0x800B * *
DDS Deregister Rsp DDSDeregRsp 0x800C * *
Entity Status Inquiry Rsp ESIRsp 0x800D *
NOT USED 0x800E
RESERVED 0x800F-0x8010
Request FC_DOMAIN_ID Rsp RqstDomIdRsp 0x8011
Release FC_DOMAIN_ID Rsp RlseDomIdRsp 0x8012
Get FC_DOMAIN_IDs GetDomIdRsp 0x0013
RESERVED 0x8014-0x80FF
Vendor Specific 0x8100-0x81FF
RESERVED 0x8200-0xFFFF
The iSNSP message format is similar to the format of other common protocols such as DHCP, DNS and BOOTP. An iSNSP message may be sent in one or more iSNS Protocol Data Units (PDU). Each PDU is 4-byte aligned. The following describes the format of the iSNSP PDU:
iSNSP消息格式类似于其他常见协议（如DHCP、DNS和BOOTP）的格式。可以在一个或多个iSNS协议数据单元（PDU）中发送iSNSP消息。每个PDU都是4字节对齐的。以下描述了iSNSP PDU的格式：
Byte MSb LSb
Offset 0 15 16 31
+---------------------+----------------------+
0 | iSNSP VERSION | FUNCTION ID | 4 Bytes
+---------------------+----------------------+
4 | PDU LENGTH | FLAGS | 4 Bytes
+---------------------+----------------------+
8 | TRANSACTION ID | SEQUENCE ID | 4 Bytes
+---------------------+----------------------+
12 | |
| PDU PAYLOAD | N Bytes
| ... |
+--------------------------------------------+
12+N | AUTHENTICATION BLOCK (Multicast/Broadcast) | L Bytes
+--------------------------------------------+
Total Length = 12 + N + L
Byte MSb LSb
Offset 0 15 16 31
+---------------------+----------------------+
0 | iSNSP VERSION | FUNCTION ID | 4 Bytes
+---------------------+----------------------+
4 | PDU LENGTH | FLAGS | 4 Bytes
+---------------------+----------------------+
8 | TRANSACTION ID | SEQUENCE ID | 4 Bytes
+---------------------+----------------------+
12 | |
| PDU PAYLOAD | N Bytes
| ... |
+--------------------------------------------+
12+N | AUTHENTICATION BLOCK (Multicast/Broadcast) | L Bytes
+--------------------------------------------+
Total Length = 12 + N + L
The iSNSP PDU header contains the iSNSP VERSION, FUNCTION ID, PDU LENGTH, FLAGS, TRANSACTION ID, and SEQUENCE ID fields as defined below.
iSNSP PDU标头包含iSNSP版本、函数ID、PDU长度、标志、事务ID和序列ID字段，定义如下。
The iSNSP version described in this document is 0x0001. All other values are RESERVED. The iSNS server MAY reject messages for iSNSP version numbers that it does not support.
本文档中描述的iSNSP版本为0x0001。所有其他值均保留。iSNS服务器可能会拒绝其不支持的iSNSP版本号的消息。
The FUNCTION ID defines the type of iSNS message and the operation to be executed. FUNCTION_ID values with the leading bit cleared indicate query, registration, and notification messages, whereas FUNCTION_ID values with the leading bit set indicate response messages.
函数ID定义iSNS消息的类型和要执行的操作。前导位已清除的FUNCTION_ID值表示查询、注册和通知消息，而前导位已设置的FUNCTION_ID值表示响应消息。
See Section 4 under the appropriate protocol (i.e., iSCSI or iFCP) for a mapping of the FUNCTION_ID value to the iSNSP Command or Response message. All PDUs comprising an iSNSP message must have the same FUNCTION_ID value.
有关函数ID值到iSNSP命令或响应消息的映射，请参见相应协议（即iSCSI或iFCP）下的第4节。包含iSNSP消息的所有PDU必须具有相同的函数ID值。
The iSNS PDU Length specifies the length of the PDU PAYLOAD field in bytes. The PDU Payload contains TLV attributes for the operation.
iSNS PDU长度以字节为单位指定PDU有效负载字段的长度。PDU有效负载包含操作的TLV属性。
Additionally, response messages contain a success/failure code. The PDU Length MUST be 4-byte aligned.
此外，响应消息包含成功/失败代码。PDU长度必须是4字节对齐的。
The FLAGS field indicates additional information about the message and the type of Network Entity that generated the message. The following table displays the valid flags:
FLAGS字段表示有关消息和生成消息的网络实体类型的其他信息。下表显示了有效标志：
Bit Position Enabled (1) means:
------------ -----------------
16 Sender is the iSNS client
17 Sender is the iSNS server
18 Authentication block is present
19 Replace flag (for DevAttrReg)
20 Last PDU of the iSNS message
21 First PDU of the iSNS message
22-31 RESERVED
Bit Position Enabled (1) means:
------------ -----------------
16 Sender is the iSNS client
17 Sender is the iSNS server
18 Authentication block is present
19 Replace flag (for DevAttrReg)
20 Last PDU of the iSNS message
21 First PDU of the iSNS message
22-31 RESERVED
The TRANSACTION ID MUST be set to a unique value for each concurrently outstanding request message. Replies MUST use the same TRANSACTION ID value as the associated iSNS request message. If a
对于每个并发未完成的请求消息，必须将事务ID设置为唯一值。回复必须使用与关联iSNS请求消息相同的事务ID值。如果
message is retransmitted, the original TRANSACTION ID value MUST be used. All PDUs comprising an iSNSP message must have the same TRANSACTION ID value.
消息重新传输时，必须使用原始事务ID值。包含iSNSP消息的所有PDU必须具有相同的事务ID值。
The SEQUENCE ID has a unique value for each PDU within a single transaction. The SEQUENCE_ID value of the first PDU transmitted in a given iSNS message MUST be zero (0), and each SEQUENCE_ID value in each PDU MUST be numbered sequentially in the order in which the PDUs are transmitted. Note that the two-byte SEQUENCE ID allows for up to 65536 PDUs per iSNS message.
序列ID对于单个事务中的每个PDU都具有唯一的值。给定iSNS消息中传输的第一个PDU的SEQUENCE_ID值必须为零（0），并且每个PDU中的每个SEQUENCE_ID值必须按照PDU传输的顺序顺序编号。请注意，双字节序列ID允许每个iSNS消息最多65536个PDU。
iSNS messages may be carried in one or more iSNS PDUs. If only one iSNS PDU is used to carry the iSNS message, then bit 21 (First PDU) and bit 20 in the FLAGS field (Last PDU) SHALL both be set. If multiple PDUs are used to carry the iSNS message, then bit 21 SHALL be set in the first PDU of the message, and bit 20 SHALL be set in the last PDU.
iSNS消息可以在一个或多个iSNS PDU中传送。如果仅使用一个iSNS PDU来传送iSNS信息，则应同时设置标志字段（最后一个PDU）中的第21位（第一个PDU）和第20位。如果使用多个PDU承载iSNS信息，则应在信息的第一个PDU中设置位21，并在最后一个PDU中设置位20。
All PDUs comprising the same iSNSP message SHALL have the same FUNCTION_ID and TRANSACTION_ID values. Each PDU comprising an iSNSP message SHALL have a unique SEQUENCE_ID value.
包含相同iSNSP消息的所有PDU应具有相同的功能ID和事务ID值。包含iSNSP消息的每个PDU应具有唯一的序列ID值。
The iSNSP PDU PAYLOAD is of variable length and contains attributes used for registration and query operations. The attribute data items use a format similar to that of other protocols, such as DHCP [RFC2131] options. Each iSNS attribute is specified in the PDU Payload using Tag-Length-Value (TLV) data format, as shown below:
iSNSP PDU有效负载长度可变，包含用于注册和查询操作的属性。属性数据项使用与其他协议类似的格式，例如DHCP[RFC2131]选项。每个iSNS属性都使用标记长度值（TLV）数据格式在PDU有效负载中指定，如下所示：
Byte MSb LSb
Offset 0 31
+--------------------------------------------+
0 | Attribute Tag | 4 Bytes
+--------------------------------------------+
4 | Attribute Length (N) | 4 Bytes
+--------------------------------------------+
8 | |
| Attribute Value | N Bytes
| |
+--------------------------------------------+
Total Length = 8 + N
Byte MSb LSb
Offset 0 31
+--------------------------------------------+
0 | Attribute Tag | 4 Bytes
+--------------------------------------------+
4 | Attribute Length (N) | 4 Bytes
+--------------------------------------------+
8 | |
| Attribute Value | N Bytes
| |
+--------------------------------------------+
Total Length = 8 + N
Attribute Tag: a 4-byte field that identifies the attribute as defined in Section 6.1. This field contains the tag value from the indicated table.
属性标签：一个4字节字段，用于标识第6.1节中定义的属性。此字段包含指示表中的标记值。
Attribute Length: a 4-byte field that indicates the length, in bytes, of the value field to follow in the TLV. For variable-length attributes, the value field MUST contain padding bytes, if necessary, in order to achieve 4-byte alignment. A "zero-length TLV" contains only the attribute tag and length fields.
属性长度：一个4字节的字段，指示TLV中要遵循的值字段的长度（以字节为单位）。对于可变长度属性，如果需要，值字段必须包含填充字节，以便实现4字节对齐。“零长度TLV”仅包含属性标记和长度字段。
Attribute Value: a variable-length field containing the attribute value and padding bytes (if necessary).
属性值：包含属性值和填充字节（如果需要）的可变长度字段。
The above format is used to identify each attribute in the PDU Payload. Note that TLV boundaries need not be aligned with PDU boundaries; PDUs may carry one or more TLVs, or any fraction thereof. The Response Status Code, contained in response message PDU Payloads and described below, is not in TLV format. PDU Payloads for messages that do not contain iSNS attributes, such as the Name Service Heartbeat, do not use the TLV format.
上述格式用于标识PDU有效负载中的每个属性。注意，TLV边界不需要与PDU边界对齐；PDU可携带一个或多个TLV，或其任何部分。响应消息PDU有效载荷中包含的响应状态代码（如下所述）不是TLV格式。不包含iSNS属性（如名称服务心跳）的邮件的PDU有效负载不使用TLV格式。
All attribute values are aligned to 4-byte boundaries. For variable length attributes, if necessary, the TLV length MUST be increased to the next 4-byte boundary through padding with bytes containing zero (0). If an attribute value is padded, a combination of the tag and attribute value itself is used to determine the actual value length and number of pad bytes. There is no explicit count of the number of pad bytes provided in the TLV.
所有属性值都与4字节边界对齐。对于可变长度属性，如有必要，必须通过填充包含零（0）的字节将TLV长度增加到下一个4字节边界。如果填充属性值，则使用标记和属性值本身的组合来确定实际值长度和填充字节数。TLV中提供的pad字节数没有明确的计数。
All iSNSP response messages contain a 4-byte Status Code field as the first field in the iSNSP PDU PAYLOAD. If the original iSNSP request message was processed normally by the iSNS server, or by the iSNS client for ESI and SCN messages, then this field SHALL contain a status code of 0 (Successful). A non-zero status code indicates rejection of the entire iSNS client request message.
所有iSNSP响应消息都包含一个4字节的状态代码字段，作为iSNSP PDU有效负载中的第一个字段。如果原始iSNSP请求消息由iSNS服务器正常处理，或由iSNS客户端为ESI和SCN消息正常处理，则此字段应包含状态代码0（成功）。非零状态代码表示整个iSNS客户端请求消息被拒绝。
Status Code Status Description
----------- -----------------
0 Successful
1 Unknown Error
2 Message Format Error
3 Invalid Registration
4 RESERVED
5 Invalid Query
6 Source Unknown
7 Source Absent
8 Source Unauthorized
9 No Such Entry
10 Version Not Supported
11 Internal Error
12 Busy
13 Option Not Understood
14 Invalid Update
15 Message (FUNCTION_ID) Not Supported
16 SCN Event Rejected
17 SCN Registration Rejected
18 Attribute Not Implemented
19 FC_DOMAIN_ID Not Available
20 FC_DOMAIN_ID Not Allocated
21 ESI Not Available
22 Invalid Deregistration
23 Registration Feature Not Supported
24 and above RESERVED
Status Code Status Description
----------- -----------------
0 Successful
1 Unknown Error
2 Message Format Error
3 Invalid Registration
4 RESERVED
5 Invalid Query
6 Source Unknown
7 Source Absent
8 Source Unauthorized
9 No Such Entry
10 Version Not Supported
11 Internal Error
12 Busy
13 Option Not Understood
14 Invalid Update
15 Message (FUNCTION_ID) Not Supported
16 SCN Event Rejected
17 SCN Registration Rejected
18 Attribute Not Implemented
19 FC_DOMAIN_ID Not Available
20 FC_DOMAIN_ID Not Allocated
21 ESI Not Available
22 Invalid Deregistration
23 Registration Feature Not Supported
24 and above RESERVED
For iSNS multicast and broadcast messages (see Section 2.9.3), the iSNSP provides authentication capability. The following section details the iSNS Authentication Block, which is identical in format to the SLP authentication block [RFC2608]. iSNS unicast messages SHOULD NOT include the authentication block, but rather should rely upon IPSec security mechanisms.
对于iSNS多播和广播消息（参见第2.9.3节），iSNSP提供身份验证功能。以下部分详细介绍了iSNS身份验证块，其格式与SLP身份验证块[RFC2608]相同。iSNS单播消息不应包括身份验证块，而应依赖IPSec安全机制。
If a message contains an authentication block, then the "Authentication block present" bit in the iSNSP PDU header FLAGS field SHALL be enabled.
如果消息包含身份验证块，则应启用iSNSP PDU标题标志字段中的“身份验证块存在”位。
If a PKI is available with an [X.509] Certificate Authority (CA), then public key authentication of the iSNS server is possible. The authentication block leverages the DSA with SHA-1 algorithm, which can easily integrate into a public key infrastructure.
如果[X.509]证书颁发机构（CA）提供PKI，则可以对iSNS服务器进行公钥身份验证。身份验证块利用DSA和SHA-1算法，该算法可以轻松集成到公钥基础结构中。
The authentication block contains a digital signature for the multicast message. The digital signature is calculated on a per-PDU basis. The authentication block contains the following information:
身份验证块包含多播消息的数字签名。数字签名是基于每个PDU计算的。身份验证块包含以下信息：
1. A time stamp, to prevent replay attacks. 2. A structured authenticator containing a signature calculated over the time stamp and the message being secured. 3. An indicator of the cryptographic algorithm that was used to calculate the signature. 4. An indicator of the keying material and algorithm parameters, used to calculate the signature.
1. 时间戳，用于防止重播攻击。2.一种结构化身份验证器，包含在时间戳上计算的签名和被保护的消息。3.用于计算签名的加密算法的指示符。4.密钥材料和算法参数的指示器，用于计算签名。
The authentication block is described in the following figure:
认证块如下图所示：
Byte MSb LSb
Offset 0 31
+----------------------------------+
0 | BLOCK STRUCTURE DESCRIPTOR | 4 Bytes
+----------------------------------+
4 | AUTHENTICATION BLOCK LENGTH | 4 Bytes
+----------------------------------+
8 | TIMESTAMP | 8 Bytes
+----------------------------------+
16 | SPI STRING LENGTH | 4 Bytes
+----------------------------------+
20 | SPI STRING | N Bytes
+----------------------------------+
20 + N | STRUCTURED AUTHENTICATOR | M Bytes
+----------------------------------+
Total Length = 20 + N + M
Byte MSb LSb
Offset 0 31
+----------------------------------+
0 | BLOCK STRUCTURE DESCRIPTOR | 4 Bytes
+----------------------------------+
4 | AUTHENTICATION BLOCK LENGTH | 4 Bytes
+----------------------------------+
8 | TIMESTAMP | 8 Bytes
+----------------------------------+
16 | SPI STRING LENGTH | 4 Bytes
+----------------------------------+
20 | SPI STRING | N Bytes
+----------------------------------+
20 + N | STRUCTURED AUTHENTICATOR | M Bytes
+----------------------------------+
Total Length = 20 + N + M
BLOCK STRUCTURE DESCRIPTOR (BSD): Defines the structure and algorithm to use for the STRUCTURED AUTHENTICATOR. BSD values from 0x00000000 to 0x00007FFF are assigned by IANA, while values 0x00008000 to 0x00008FFF are for private use.
块结构描述符（BSD）：定义用于结构化身份验证程序的结构和算法。从0x00000000到0x00007FFF的BSD值由IANA分配，而0x00008000到0x00008FFF的值则供私人使用。
AUTHENTICATION BLOCK LENGTH: Defines the length of the authentication block, beginning with the BSD field and running through the last byte of the STRUCTURED AUTHENTICATOR.
身份验证块长度：定义身份验证块的长度，从BSD字段开始，一直到结构化身份验证程序的最后一个字节。
TIMESTAMP: This is an 8-byte unsigned, fixed-point integer giving the number of seconds since 00:00:00 GMT on January 1, 1970.
时间戳：这是一个8字节无符号定点整数，表示自1970年1月1日格林威治标准时间00:00:00以来的秒数。
SPI STRING LENGTH: The length of the SPI STRING field.
SPI字符串长度：SPI字符串字段的长度。
SPI STRING (Security Parameters Index): Index to the key and algorithm used by the message recipient to decode the STRUCTURED AUTHENTICATOR field.
SPI字符串（安全参数索引）：邮件收件人解码结构化身份验证符字段时使用的密钥和算法的索引。
STRUCTURED AUTHENTICATOR: Contains the digital signature. For the default BSD value of 0x0002, this field SHALL contain the binary ASN.1 encoding of output values from the DSA with SHA-1 signature calculation as specified in Section 2.2.2 of [RFC3279].
结构化身份验证器：包含数字签名。对于默认BSD值0x0002，该字段应包含[RFC3279]第2.2.2节中规定的使用SHA-1签名计算的DSA输出值的二进制ASN.1编码。
The iSNSP registration and query message PDU Payloads contain a list of attributes, and have the following format:
iSNSP注册和查询消息PDU有效载荷包含属性列表，格式如下：
+----------------------------------------+
| Source Attribute (Requests Only) |
+----------------------------------------+
| Message Key Attribute[1] (if present) |
+----------------------------------------+
| Message Key Attribute[2] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
| - Delimiter Attribute - |
+----------------------------------------+
| Operating Attribute[1] (if present) |
+----------------------------------------+
| Operating Attribute[2] (if present) |
+----------------------------------------+
| Operating Attribute[3] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
+----------------------------------------+
| Source Attribute (Requests Only) |
+----------------------------------------+
| Message Key Attribute[1] (if present) |
+----------------------------------------+
| Message Key Attribute[2] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
| - Delimiter Attribute - |
+----------------------------------------+
| Operating Attribute[1] (if present) |
+----------------------------------------+
| Operating Attribute[2] (if present) |
+----------------------------------------+
| Operating Attribute[3] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
Each Source, Message Key, Delimiter, and Operating attribute is specified in the PDU Payload using the Tag-Length-Value (TLV) data format. iSNS Registration and Query messages are sent by iSNS Clients
使用标记长度值（TLV）数据格式在PDU有效负载中指定每个源、消息键、分隔符和操作属性。iSNS注册和查询消息由iSNS客户端发送
to the iSNS server IP Address and well-known TCP/UDP Port. The iSNS Responses will be sent to the iSNS Client IP address and TCP/UDP port number from the original request message.
到iSNS服务器IP地址和众所周知的TCP/UDP端口。iSNS响应将从原始请求消息发送到iSNS客户端IP地址和TCP/UDP端口号。
The Source Attribute is used to identify the Storage Node to the iSNS server for queries and other messages that require source identification. The Source Attribute uniquely identifies the source of the message. Valid Source Attribute types are shown below.
Source属性用于向iSNS服务器标识存储节点，以用于需要源标识的查询和其他消息。Source属性唯一标识消息的源。有效的源属性类型如下所示。
Valid Source Attributes
-----------------------
iSCSI Name
FC Port Name WWPN
Valid Source Attributes
-----------------------
iSCSI Name
FC Port Name WWPN
For a query operation, the Source Attribute is used to limit the scope of the specified operation to the Discovery Domains of which the source is a member. Special Control Nodes, identified by the Source Attribute, may be administratively configured to perform the specified operation on all objects in the iSNS database without scoping to Discovery Domains.
对于查询操作，“源”属性用于将指定操作的范围限制为源所属的发现域。由源属性标识的特殊控制节点可以通过管理方式配置为对iSNS数据库中的所有对象执行指定的操作，而无需限定到发现域。
For messages that change the contents of the iSNS database, the iSNS server MUST verify that the Source Attribute identifies either a Control Node or a Storage Node that is a part of the Network Entity containing the added, deleted, or modified objects.
对于更改iSNS数据库内容的邮件，iSNS服务器必须验证Source属性是否标识控制节点或存储节点，该节点是包含添加、删除或修改对象的网络实体的一部分。
Message Key attributes are used to identify matching objects in the iSNS database for iSNS query and registration messages. If present, the Message Key MUST be a Registration or Query Key for an object as described in Sections 5.6.5 and 6.1. A Message Key is not required when a query spans the entire set of objects available to the Source or a registration is for a new Entity.
消息密钥属性用于标识iSNS数据库中iSNS查询和注册消息的匹配对象。如果存在，消息密钥必须是第5.6.5节和第6.1节所述对象的注册或查询密钥。当查询跨越源可用的整个对象集或注册是针对新实体时，不需要消息键。
iSCSI Names used in the Message Key MUST be normalized according to the stringprep template [STRINGPREP]. Entity Identifiers (EIDs) used in the Message Key MUST be normalized according to the nameprep template [NAMEPREP].
消息密钥中使用的iSCSI名称必须根据stringprep模板[stringprep]进行规范化。消息键中使用的实体标识符（EID）必须根据nameprep模板[nameprep]进行规范化。
The Delimiter Attribute separates the Message Key attributes from the Operating Attributes in a PDU Payload. The Delimiter Attribute has a tag value of 0 and a length value of 0. The Delimiter Attribute is always 8 bytes long (a 4-byte tag field and a 4-byte length field,
分隔符属性将消息键属性与PDU有效负载中的操作属性分开。Delimiter属性的标记值为0，长度值为0。Delimiter属性的长度始终为8字节（4字节标记字段和4字节长度字段，
all containing zeros). If a Message Key is not required for a message, then the Delimiter Attribute immediately follows the Source Attribute.
全部包含零）。如果消息不需要消息键，则Delimiter属性紧跟在Source属性之后。
The Operating Attributes are a list of one or more key and non-key attributes related to the actual iSNS registration or query operation being performed.
操作属性是与正在执行的实际iSNS注册或查询操作相关的一个或多个关键和非关键属性的列表。
Operating Attributes include object key attributes and non-key attributes. Object key attributes uniquely identify iSNS objects. Key attributes MUST precede the non-key attributes of each object in the Operating Attributes. The tag value distinguishes the attribute as an object key attribute (i.e., tag=1, 16&17, 32, 64, and 96) or a non-key attribute. iSCSI Names used in the Operating Attributes MUST be normalized according to the stringprep template [STRINGPREP]. Entity Identifiers (EIDs) used in the Operating Attributes MUST be normalized according to the nameprep template [NAMEPREP].
操作属性包括对象关键属性和非关键属性。对象键属性唯一标识iSNS对象。关键属性必须位于操作属性中每个对象的非关键属性之前。标记值将属性区分为对象键属性（即标记=1、16和17、32、64和96）或非键属性。操作属性中使用的iSCSI名称必须根据stringprep模板[stringprep]进行规范化。操作属性中使用的实体标识符（EID）必须根据nameprep模板[nameprep]进行规范化。
The ordering of Operating Attributes in the message is important for determining the relationships among objects and their ownership of non-key attributes. iSNS protocol messages that violate these ordering rules SHALL be rejected with the Status Code of 2 (Message Format Error). See the message descriptions for proper operating attribute ordering requirements.
消息中操作属性的顺序对于确定对象之间的关系及其非关键属性的所有权非常重要。违反这些订购规则的iSNS协议消息将被拒绝，状态代码为2（消息格式错误）。有关正确的操作属性排序要求，请参阅消息说明。
Some objects are keyed by more than one object key attribute value. For example, the Portal object is keyed by attribute tags 16 and 17. When describing an object keyed by more than one key attribute, every object key attribute of that object MUST be listed sequentially by tag value in the message before non-key attributes of that object and key attributes of the next object. A group of key attributes of this kind is treated as a single logical key attribute when identifying an object.
某些对象由多个对象关键点属性值设置关键点。例如，门户对象由属性标记16和17设置关键帧。当描述由多个关键属性设置关键帧的对象时，该对象的每个对象关键帧属性必须在该对象的非关键属性和下一个对象的关键帧属性之前，按消息中的标记值顺序列出。在标识对象时，此类键属性组被视为单个逻辑键属性。
Non-key attributes that immediately follow key attributes MUST be attributes of the object referenced by the key attributes. All non-key attributes of an object MUST be listed before the object key attributes introducing the next object.
紧跟在关键属性之后的非关键属性必须是关键属性引用的对象的属性。在引入下一个对象的对象键属性之前，必须列出对象的所有非键属性。
Objects MUST be listed in inheritance order, according to their containment order. Storage Node and Portal objects and their respective attributes MUST follow the Network Entity object to which they have a relationship. Similarly, FC Device objects MUST follow the Storage Node object to which they have a relationship.
对象必须按照其包含顺序按继承顺序列出。存储节点和入口对象及其各自的属性必须遵循与其有关系的网络实体对象。类似地，FC设备对象必须跟随与其有关系的存储节点对象。
Vendor-specific objects defined by tag values in the range 1537-2048 have the same requirements described above.
由1537-2048范围内的标记值定义的特定于供应商的对象具有上述相同的要求。
In Query and Get Next request messages, TLV attributes with length value of 0 are used to indicate which Operating Attributes are to be returned in the corresponding response. Operating Attribute values that match the TLV attributes in the original message are returned in the response message.
在查询和获取下一个请求消息中，长度值为0的TLV属性用于指示在相应的响应中返回哪些操作属性。与原始消息中的TLV属性匹配的操作属性值将在响应消息中返回。
The following describes each query and message type.
下面介绍每个查询和消息类型。
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.
DevAttrReg消息类型为0x0001。DevAttrReg消息为iSNS客户端提供了更新现有对象或注册新对象的方法。FLAGs字段中replace位的值确定DevAttrReg消息是更新还是替换现有注册。
The Source Attribute identifies the Node initiating the registration request.
Source属性标识发起注册请求的节点。
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.
消息键标识Devatrreg消息作用的对象。它必须包含标识对象的键属性。此对象必须包含所有属性和相关的从属对象属性，这些属性将包含在DevAttrReg PDU有效负载的操作属性中。标识此对象的关键属性也必须包含在操作属性中。
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.
如果消息键包含EID且没有与消息键匹配的预先存在的对象，则Devatrreg消息应使用指定的EID和操作属性指定的任何新对象创建一个新实体。应忽略替换钻头。
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).
如果消息密钥不包含EID，并且没有与消息密钥匹配的预先存在的对象，则DevAttrReg消息将被拒绝，状态代码为3（无效注册）。
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.
如果消息密钥不存在，则DevAttrReg消息隐式注册一个新的网络实体。在这种情况下，应忽略更换钻头；应创建新的网络实体。现有实体、其对象及其关系保持不变。
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.
replace位确定对DevAttrReg消息键中标识的对象执行的操作类型。替换位仅适用于DevAttrReg消息；对于所有其他消息类型，它将被忽略。
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.
如果设置了替换位，则操作属性中指定的对象、属性和关系应替换消息键标识的对象。应注销该对象及其所有从属对象，iSNS服务器应为注销的对象发送适当的SCN。然后使用操作属性中列出的对象替换刚刚注销的对象。请注意，如果合适，应为新注册的对象发送额外的SCN。不能影响或更改未标识或从属于消息键标识的对象的现有对象和关系。
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.
操作属性表示要注册的对象、属性和关系。多个相关对象和属性可以在一条DevAttrReg消息中注册。此消息中对象的顺序表示要注册的对象的结构以及对象之间的关联。操作属性中必须至少列出一个对象。其他对象（如果有）必须从属于列出的第一个对象。关键点属性必须位于每个对象的非关键点属性之前。给定对象在消息的操作属性中最多只能出现一次。如果源属性标识的节点不是控制节点，则操作属性中的对象必须是与源节点相同的网络实体的成员。
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.
例如，要建立网络实体对象与其门户和存储节点对象之间的关系，操作属性列出网络实体对象的关键和非关键属性，然后列出要链接到该网络实体的每个门户和存储节点对象的关键和非关键属性。类似地，跟随存储节点对象的FC设备对象被视为从属于该存储节点。
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.
注册关联的门户或iSCSI节点对象时，将注册新的PG对象。显式PG对象注册可以在Devatrreg消息中的入口或iSCSI节点对象注册之后进行。
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.
注册门户时，门户属性后面可能紧跟着一个PGT属性。PGT属性后面应跟随一组PG iSCSI名称，表示将使用指示的PGT值与门户关联的节点。随后可能会出现与注册门户关联的其他PGT和PG iSCSI名称集。指示的PGT值被分配给与新注册的门户关联的PG对象和紧跟在操作属性中的PGT属性之后引用的iSCSI存储节点。
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.
注册iSCSI存储节点时，存储节点属性后面可能紧跟着一个PGT属性。PGT属性后面应跟随PG门户IP地址集，PG TCP/UDP端口对表示将使用指示的PGT值与存储节点关联的门户对象。随后可能会出现与注册的存储节点关联的其他PGT和PG门户IP地址PG TCP/UDP端口对集。指示的PGT值分配给与新注册的iSCSI存储节点关联的PG对象，以及紧跟在操作属性中的PGT属性之后引用的入口对象。
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.
如果PGT值未包括在存储节点或门户对象注册中，并且如果PGT值之前未为关系注册，则对应PG对象的PGT应以0x00000001的值注册。如果PGT属性作为0长度TLV包含在注册消息中，则对应PG对象的PGT值应注册为NULL。更新注册消息中PGT的0长度TLV将用NULL覆盖以前的PGT值，这表示存储节点和门户之间没有关系。
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.
最多可以使用一条DevAttrReg消息创建或更新一个网络实体对象。因此，操作属性不能包含多个网络实体对象。操作属性中可以列出的入口、存储节点和FC设备对象的数量没有限制，前提是它们都从属于列出的网络实体对象。
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
如果消息键和操作属性不包含EID属性，或者EID属性的长度为0，则应创建新的网络实体对象，iSNS服务器应为其提供唯一的EID值。指定的EID值应包含在DevAttrReg响应消息中。如果消息键和操作属性包含的EID与iSNS数据库中现有网络实体的EID不匹配，则应创建一个新的网络实体，并为其分配EID属性中包含的值。最后，如果消息键和操作属性包含与iSNS中现有对象的EID匹配的EID
database, then the objects, attributes, and relationships specified in the Operating Attributes SHALL be appended to the existing Network Entity identified by the EID.
数据库，则操作属性中指定的对象、属性和关系应附加到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).
创建新网络实体对象的注册消息必须至少包含一个入口或一个存储节点。如果消息不存在，则应视为无效，并导致状态代码为3（无效注册）的响应。
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).
如果iSNS服务器不支持注册功能，例如显式PG对象注册，则服务器应返回状态代码23（不支持注册功能）。
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.
请注意，iSNS服务器可能会修改或拒绝某些属性的注册，例如ESI Interval。此外，iSNS服务器还可以为未在原始DevAttrReg消息中明确注册的其他操作属性（如EID和WWNN令牌）分配值。
The DevAttrQry message type is 0x0002. The DevAttrQry message provides an iSNS client with the means to query the iSNS server for object attributes.
DevAttrQry消息类型为0x0002。DevAttrQry消息为iSNS客户端提供了向iSNS服务器查询对象属性的方法。
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.
Source属性标识发起请求的节点。对于发起DevAttrQry消息的非控制节点，查询的范围是发起节点所属的发现域。DevAttrQry消息应仅返回存储节点及其相关父对象和从属对象的信息，其中存储节点与源属性中标识的节点具有公共发现域。
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.
消息键可以包含键或非键属性，也可以根本不包含属性。如果将多个属性用作消息密钥，则它们必须都来自同一对象类型（例如，IP地址和TCP/UDP端口是门户对象类型的属性）。具有非键属性的消息键可能与特定对象类型的多个实例匹配。具有零长度TLV的消息键的作用域为零长度TLV指示的类型的每个对象。空消息键字段表示查询的范围为源节点可访问的整个数据库。
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
DevAttrQry响应消息返回与原始DevAttrQry消息的消息键相关的操作属性中列出的对象属性。DevAttrQry消息的操作属性包含长度为零的TLV，用于指定要在DevAttrQryRsp消息中返回的属性。A.
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.
包含零长度TLV的消息键表示操作属性中指定的属性集将针对与消息键指示的类型匹配的每个对象返回。
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.
如果消息键包含非零长度TLV，则应在DevAttrQryRsp消息中返回与消息键匹配的对象的操作属性。操作属性中的每个属性类型（即，零长度TLV）表示响应中将返回与消息键匹配的对象中的属性，或同一实体中与消息键匹配的对象具有关系的其他对象中的属性。DevAttrQry响应消息中返回的对象键和相关属性的顺序应与原始查询消息中的顺序相同。如果没有对象与消息键匹配，则DevAttrQryRsp消息不应返回任何操作属性。此类信息及其相应响应不应视为错误。
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.
门户组对象确定给定存储节点和门户对象之间是否存在关系。如果门户组的PGT不为空，则表示所示存储节点与门户之间存在关系；如果PGT为NULL，则不存在任何关系。因此，每个门户组对象的PGT属性的值（NULL或notnull）决定了对存储节点和门户查询的DevAttrQry响应的结构和顺序。
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.
例如，iSNS数据库包含一个具有两个入口和两个节点的网络实体。每个存储节点有两个入口组，一个入口的PGT值为空，另一个入口的PGT值为非空。DevAttrQry消息包含一个与其中一个节点匹配的消息键条目，以及具有零长度TLV的操作属性，首先列出节点属性、门户属性，然后列出PG属性。因此，响应消息应首先返回匹配的节点对象，然后返回可用于访问存储节点的一个门户对象的请求属性（如PGT所示），最后返回用于访问该存储节点的PG对象的请求属性。列出每个对象属性的顺序与原始请求消息的操作属性中对象属性的顺序相同。
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
如果消息键属性包含长度为零的TLV，则查询将返回与消息键类型匹配的所有对象的请求属性（DD限制应适用于非控制节点）。如果多个对象与消息键类型匹配，则在查询中列出下一个匹配对象的属性之前，必须列出与消息键匹配的每个对象的属性
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).
回答换句话说，对于与零长度TLV指定的消息键类型匹配的每个对象，必须在消息响应中迭代上述过程。
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.
例如，一个iSNS数据库只包含一个具有两个入口和三个节点的网络实体。实体中的所有PG对象的PGT值均为0x00000001。在DevAttrQry消息中，消息键包含指定节点类型的零长度TLV，操作属性首先列出节点属性，然后列出门户属性。响应消息将按以下顺序返回第一个、下一个和最后一个节点对象的属性，每个属性后面都是两个入口的属性。如果相同的DevAttrQry消息包含指定网络实体类型的零长度TLV，则响应消息将返回所有三个节点对象的属性，然后是两个入口的属性。
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.
如果没有消息键属性，则查询返回iSNS数据库中的所有属性（同样，DD限制应适用于非控制节点）。应列出与操作属性中每个零长度TLV指定类型相匹配的所有属性。在列出与下一个零长度TLV匹配的属性之前，应列出每种类型的所有属性。
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.
例如，iSNS数据库包含两个实体，每个实体有两个节点和两个入口。DevAttrQry消息不包含消息键属性，操作属性首先列出门户属性，然后列出节点属性。响应消息的操作属性将返回来自四个门户中每个门户的属性，然后是来自四个节点中每个节点的属性。
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.
如果DevAttrQry消息请求iSNS服务器没有值的属性，则服务器不应在查询响应中返回请求的属性。此类查询和响应消息不应视为错误。
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.
iSNS服务器特定属性（即132到384范围内的标签）的注册和查询消息应使用源属性和消息密钥属性的发起查询的存储节点的标识密钥属性（即iSCSI名称或FC端口名称WWPN）进行格式化。操作属性应包括所请求的服务器特定属性的TLV。
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,
通过包含DD成员属性（即DD成员iSCSI索引、DD成员iSCSI节点、DD成员iFCP节点、DD成员门户索引、DD成员门户IP地址和DD成员门户TCP/UDP）或存储节点或门户的对象密钥（即iSCSI名称、iSCSI索引、，
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.
操作属性中的入口IP地址、入口TCP/UDP端口和入口索引）。使用DD成员属性应返回DD的已注册和未注册成员存储节点和/或入口。使用存储节点和/或入口对象密钥的DevAttrQry消息应仅返回当前在iSNS数据库中注册的成员存储节点或入口。
The DevAttrQry message SHALL support the following minimum set of Message Key Attributes:
DevAttrQry报文应至少支持以下一组报文密钥属性：
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)
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)
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.
DevGetNext消息类型为0x0003。此消息为iSNS客户端提供了只检索一次对象类型的每个实例的方法。
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.
Source属性标识发起DevGetNext请求的节点，并用于将检索过程限定到发起节点所属的发现域。
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.
消息密钥属性可以是实体标识符（EID）、iSCSI名称、iSCSI索引、门户IP地址和TCP/UDP端口、门户索引、PG索引、FC节点名称WWNN或FC端口名称WWPN。如果消息密钥属性的TLV长度为零，则应在相应DevGetNextRsp消息的消息密钥中返回iSNS数据库中与消息密钥类型匹配的第一个对象条目。如果消息键中包含非零长度TLV属性，则DevGetNext响应消息应返回在原始DevGetNext请求消息中消息键标识的对象之后存储的下一个对象。
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.
如果提供的消息键与iSNS数据库中的最后一个对象实例匹配，则响应中应返回状态代码9（无此类条目）。
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.
操作属性可用于指定DevGetNext请求的范围，并指定下一个对象的属性，这些属性将在DevGetNext响应消息中返回。所有操作属性必须是消息键标识的对象类型的属性。例如，如果消息键是实体ID属性，则操作属性不得包含门户的属性。
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.
操作属性中的非零长度TLV属性用于确定DevGetNext消息的范围。DevGetNext响应消息中仅返回属性值与非零长度TLV属性匹配的下一个对象。
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.
零长度TLV属性必须列在DevGetNext请求消息的操作属性中的非零长度属性之后。零长度TLV属性指定要在DevGetNext响应消息中返回的下一个对象的属性。
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.
请注意，对于从iSNS数据库检索对象条目的顺序没有具体要求；使用DevGetNext消息的对象条目的检索顺序是特定于实现的。
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.
iSNS客户端负责确保通过使用DevGetNext消息获取的信息准确且是最新的。无法保证iSNS数据库不会在连续的DevGetNext请求消息之间更改。如果提供的消息键与现有数据库条目不匹配，则应返回所提供消息键之后的下一个对象键的属性。例如，一个对象条目可能在连续的DevGetNext消息之间被删除。这可能导致DevGetNext请求中的消息键与现有对象项不匹配。在这种情况下，将返回存储在iSNS数据库中的下一个对象的属性。
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).
DevDereg消息类型为0x0004。此消息用于从iSNS数据库中删除对象条目。可以通过单个DevDereg消息删除一个或多个对象。请注意，取消注册的存储节点对象将保留其发现域中的成员资格，直到明确取消成员资格或发现域的注册。
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.
在接收到DevDereg后，iSNS服务器将删除由操作属性标识的所有对象，以及仅依赖于这些标识对象的所有从属对象。例如，删除网络实体还会导致删除与该网络实体关联的所有关联门户、门户组、存储节点和FC设备对象。FC设备对象不得以这种方式注销，除非与它们相关联的所有存储节点都已注销。
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:
DevDereg请求PDU有效负载包含源属性和操作属性；没有消息键属性。如果源属性标识的节点不是控制节点，则该节点必须与操作属性标识的要删除的对象来自同一网络实体。有效的操作属性如下所示：
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
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.
删除该对象可能会导致向相应的iSNS客户端发送SCN消息。
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.
如果删除了与门户组对象关联的门户和iSCSI存储节点对象，则还应删除该门户组对象。只要其关联的门户或iSCSI存储节点对象保持注册状态，门户组对象就应保持注册状态。如果删除的存储节点或入口对象随后重新注册，则应恢复重新注册的对象与PG对象指示的现有入口或存储节点对象注册之间的关系。
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.
SCNReg消息类型为0x0005。状态更改通知注册请求（SCNReg）消息允许iSNS客户端注册存储节点以接收状态更改通知（SCN）消息。
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).
SCN通知存储节点它所属的任何DD中的任何存储节点的更改。如果存储节点是控制节点，则它应接收整个网络中更改的SCN通知。请注意，尽管SCNReg设置SCN位图字段，但DevAttrReg消息会注册每个门户用于接收SCN消息的UDP或TCP端口。如果未注册存储节点任何入口的SCN端口字段以接收SCN消息，则应拒绝SCNReg消息，状态代码为17（SCN注册已拒绝）。
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:
SCNReg请求PDU有效负载包含源属性、消息键属性和操作属性。SCNReg的有效消息密钥属性如下所示：
Valid Message Key Attributes for SCNReg
---------------------------------------
iSCSI Name
FC Port Name WWPN
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.
具有iSCSI名称或FC端口名称WWPN属性且与SCNReg消息中的消息密钥匹配的节点已注册为使用指定的SCN位图接收SCN。每个SCNReg消息最多应注册一个节点。
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.
SCN位图是此消息的唯一操作属性，它始终覆盖iSNS数据库中此字段以前的内容。位图指示节点正在注册的SCN事件类型。
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.
请注意，此位图的设置确定SCN注册是针对常规SCN还是管理SCN。控制节点可对管理SCN进行注册；不支持控制节点的iSNS客户端不得注册管理SCN。注册管理SCN的控制节点接收iSNS服务器生成的每个SCN消息的副本。建议仅在需要时使用管理注册，以节省iSNS服务器资源。此外，进行此类注册的控制节点应准备好接收预期的SCN消息通信量。
The SCNDereg message type is 0x0006. The SCNDereg message allows an iSNS client to stop receiving State Change Notification (SCN) messages.
SCNDereg消息类型为0x0006。SCNDereg消息允许iSNS客户端停止接收状态更改通知（SCN）消息。
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:
SCNDereg请求消息PDU有效负载包含源属性和消息密钥属性。SCNDereg的有效消息密钥属性如下所示：
Valid Message Key Attributes for SCNDereg
-----------------------------------------
iSCSI Name
FC Port Name WWPN
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.
已为SCN注销iSCSI名称或FC端口名称WWPN属性与SCNDereg消息中的消息密钥属性匹配的节点。清除此类节点的SCN位图字段。每个SCNDereg消息最多应注销一个节点。
There are no Operating Attributes in the SCNDereg message.
SCNDereg消息中没有操作属性。
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.
SCNEvent消息类型为0x0007。SCN通知是由iSNS客户端发送的消息，用于请求iSNS服务器生成状态更改通知（SCN）消息。然后，由iSNS服务器发送的SCN将SCN事件中指示的更改通知受影响DD内的iFCP、iSCSI和控制节点。
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.
当从目录数据库注册或注销节点时，大多数SCN由iSNS服务器自动生成。当网络管理应用程序或控制节点更改iSNS服务器中的DD成员身份时，也会生成SCN。但是，iSNS客户端可以使用SCNEvent触发SCN。
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:
SCNEvent消息PDU有效负载包含源属性、消息密钥属性和操作属性。SCN事件的有效密钥属性如下所示：
Valid Message Key Attributes for SCNEvent
-----------------------------------------
iSCSI Name
FC Port Name WWPN
Valid Message Key Attributes for SCNEvent
-----------------------------------------
iSCSI Name
FC Port Name WWPN
The Operating Attributes section SHALL contain the SCN Event Bitmap attribute. The bitmap indicates the event that caused the SCNEvent to be generated.
操作属性部分应包含SCN事件位图属性。位图指示导致生成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.
SCN消息类型为0x0008。SCN是由iSNS服务器生成的消息，通知已注册的存储节点更改。SCN注册有两种类型：常规注册和管理注册。常规SCN将发现域中的事件通知iSNS客户端。管理SCN通知为管理SCN注册的控制节点网络中任何位置发生的事件。
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.
如果不存在与SCN收件人的活动TCP连接，则应将SCN消息发送到已注册存储节点的一个入口，该入口在SCN端口字段中具有已注册的TCP或UDP端口值。如果存储节点的多个入口具有注册的SCN端口值，则应将SCN交付给任何一个指定入口，前提是所选入口不是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.
可以触发SCN消息的事件类型以及SCN消息中包含的信息量取决于存储节点注册的SCN事件位图。第6.4.4节介绍了iSCSI节点SCN位图。第6.6.12节描述了iFCP SCN位图。
The format of the SCN PDU Payload is shown below:
SCN PDU有效负载的格式如下所示：
+----------------------------------------+
| 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) |
+----------------------------------------+
| . . . |
+----------------------------------------+
+----------------------------------------+
| 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.
所有PDU有效负载属性均为TLV格式。
The Destination Attribute is the Node identifier that is receiving the SCN. The Destination Attribute can be an iSCSI Name or FC Port Name.
Destination属性是接收SCN的节点标识符。目标属性可以是iSCSI名称或FC端口名称。
The Timestamp field, using the Timestamp TLV format, described in Section 6.2.4, indicates the time the SCN was generated.
时间戳字段使用时间戳TLV格式，如第6.2.4节所述，指示SCN生成的时间。
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.
源SCN位图字段指示SCN通知的类型（即常规或管理SCN）以及导致生成SCN的事件的类型；它不一定与iSNS服务器中注册的原始SCN位图相关。
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.
在时间戳之后，SCN消息应列出SCN位图，后跟受SCN事件影响的存储节点的密钥属性（即iSCSI名称或FC端口名称）。如果SCN是管理SCN，则SCN消息还应列出导致该存储节点状态更改的发现域和发现域集（如果有）的DD_ID和/或DDS_ID。这些附加属性（即DD_ID和/或DDS_ID）应紧跟在iSCSI名称或FC端口名称之后，并位于下一条通知消息（如有）的下一个SCN位图之前。SCN位图用作提供多个状态更改通知的SCN消息的描绘器。
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.
例如，用于通知iSNS客户端可用于特定iSCSI目标的新门户的常规SCN将包含SCN位图，后跟目标设备的iSCSI名称作为源属性。如果SCN是管理SCN，则iSCSI名称后面将跟有共享发现域的DD_ID，这些域允许目标存储节点查看受影响的存储节点。如果为了提供此可见性而启用了发现域集（DDS），则还将包括相应的DDS\u ID。
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.
还生成管理SCN，以通知控制节点发现域或发现域集的创建、删除或修改。在这种情况下，受影响的发现域和/或发现域集的DD_ID和/或DDS_ID将跟随SCN位图。
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.
例如，将发现域集中的新DD通知控制节点的管理SCN将在源属性中包含受影响的发现域和发现域集的DD_ID和DDS_ID。
See Sections 6.4.4 and 6.6.12 for additional information on the SCN Bitmap.
有关SCN位图的更多信息，请参见第6.4.4节和第6.6.12节。
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.
DDReg消息类型为0x0009。此消息用于创建新的发现域（DD），更新现有DD符号名和/或DD功能属性，以及添加DD成员。
DDs are uniquely defined using DD_IDs. DD registration attributes are described in Section 6.11.
DDs是使用DD_ID唯一定义的。DD注册属性见第6.11节。
The DDReg message PDU Payload contains the Source Attribute and optional Message Key and Operating Attributes.
DDReg消息PDU有效负载包含源属性、可选消息键和操作属性。
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.
消息密钥（如果使用）包含要注册的发现域的DD_ID。如果消息键包含iSNS数据库中现有DD条目的DD_ID，则DDReg消息应尝试更新现有条目。如果消息密钥（如果使用）中的DD_ID与现有DD条目不匹配，则iSNS服务器应拒绝状态代码为3（无效注册）的DDReg消息。如果消息键和操作属性中都包含DD_ID，则消息键中的DD_ID值必须与操作属性中的DD_ID值相同。
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.
没有消息密钥的DDReg消息将导致尝试创建新的发现域（DD）。如果DDReg消息中的操作属性中包含DD_ID属性（长度非零），则应为新发现域分配该DD_ID属性中包含的值。否则，如果DDReg消息的操作属性中不包含DD_ID属性，或者如果DD_ID是TLV长度为0的操作属性，则iSNS服务器应分配DD_ID值。然后在DDReg响应消息中返回分配的DD_ID值。操作属性还可以包含DD成员iSCSI节点索引、DD成员iSCSI名称、DD成员FC端口名称、DD成员门户IP地址、DD成员门户TCP/UDP端口号或要添加到DD的成员的DD成员门户索引。它还可以包含DD的DD_符号名称和/或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).
此消息应将列为操作属性的任何DD成员添加到DD_ID指定的发现域中。如果DD_功能属性是操作属性，则应将其存储在iSNS服务器中，作为指定DD的功能列表。如果DD_符号名称是操作属性且其值是唯一的（即，它与另一个DD的注册DD_符号_名称不匹配），则该值应作为指定发现域的DD_符号_名称存储在iSNS数据库中。如果DD_符号_名称的值不唯一，则iSNS服务器应拒绝尝试的DD注册，状态代码为3（无效注册）.
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.
创建新DD时，如果操作属性中未包含DD_符号_名称，或者如果包含零长度TLV，则iSNS服务器应为创建的DD提供唯一的DD_符号_名称值。分配的DD_符号_名称值应在DDRegRsp消息中返回。
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时，如果操作属性中未包含DD_功能属性，则iSNS服务器应分配默认值。DD_功能的默认值为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.
操作属性中包含的DD成员iSCSI名称、DD成员iFCP节点、DD成员门户IP地址和DD成员TCP/UDP端口号属性无需与当前现有的iSNS数据库条目匹配。例如，这允许将存储节点添加到DD，即使该存储节点当前未在iSNS数据库中注册。因此，即使存储节点或入口当前在存储网络中未处于活动状态，也可以在创建DDs时将存储节点或入口添加到DD。
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.
如果操作属性包含当前未在iSNS数据库中注册的存储节点的DD成员iSCSI名称值，则iSNS服务器必须为该存储节点分配未使用的iSCSI节点索引。分配的iSCSI节点索引应在DDREGSP消息中作为DD成员iSCSI节点索引返回。如果存储节点在iSNS数据库中注册，则应将分配的iSCSI节点索引值分配给存储节点。
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.
如果操作属性包含当前未在iSNS数据库中注册的门户的DD成员门户IP Addr和DD成员门户TCP/UDP值，则iSNS服务器必须为该门户分配未使用的门户索引值。分配的入口索引值应在DDRegRsp消息中作为DD成员入口索引返回。如果门户在iSNS数据库中注册，则应将分配的门户索引值分配给门户。
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.
操作属性中提供的DD成员iSCSI节点索引和DD成员门户索引属性必须与iSNS数据库中现有存储节点或门户条目的相应iSCSI节点索引或门户索引匹配。此外，DD成员iSCSI节点索引和DD成员入口索引不得用于向DD添加存储节点或入口，除非这些存储节点或入口已在iSNS数据库中主动注册。
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.
DDDereg消息类型为0x000A。此消息允许iSNS客户端注销现有发现域（DD）并从现有DD中删除成员。
DDs are uniquely identified using DD_IDs. DD registration attributes are described in Section 6.11.
DDs使用DD_ID进行唯一标识。DD注册属性见第6.11节。
The DDDereg message PDU Payload contains a Source Attribute, Message Key Attribute, and optional Operating Attributes.
DDDereg消息PDU有效负载包含源属性、消息键属性和可选操作属性。
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.
DDDereg消息的消息键属性是正在删除或已删除成员的发现域的DD ID。如果DD ID与现有DD匹配且没有操作属性，则应删除DD并返回成功状态代码。该DD的任何现有成员应保留在iSNS数据库中，而不是刚刚删除的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.
如果DD ID与现有DD匹配，且存在与DD成员匹配的操作属性，则应将由操作属性标识的DD成员从DD中删除，并返回成功状态代码。
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.
如果操作属性中标识的DD成员iSCSI名称包含当前未在iSNS数据库中注册或未包含在其他DD中的存储节点的iSCSI名称，则应删除该存储节点与其预先分配的iSCSI节点索引之间的关联。预先分配的iSCSI节点索引值不再与特定iSCSI名称关联，现在可以重新分配。
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.
如果操作属性中标识的DD成员门户IP地址和DD成员TCP/UDP端口引用当前未在iSNS数据库中注册或包含在另一DD中的门户，则应删除该门户与其预先分配的门户索引之间的关联。现在可以重新分配预先分配的入口索引值。
The attempted deregistration of non-existent DD entries SHALL not be considered an error.
尝试注销不存在的DD条目不应视为错误。
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.
DDSReg消息类型为0x000B。此消息允许iSNS客户端创建新的发现域集（DDS），更新现有DDS符号名和/或DDS状态，或添加DDS成员。
DDSs are uniquely defined using DDS_IDs. DDS registration attributes are described in Section 6.11.1.
DDS是使用DDS\u ID唯一定义的。DDS注册属性如第6.11.1节所述。
The DDSReg message PDU Payload contains the Source Attribute and, optionally, Message Key and Operating Attributes.
DDSReg消息PDU有效负载包含源属性以及（可选）消息键和操作属性。
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.
消息键（如果使用）包含要注册或修改的发现域集的DDS_ID。如果消息键包含iSNS数据库中现有DDS条目的DDS_ID，则DDSReg消息应尝试更新现有条目。如果消息键（如果使用）中的DDS_ID与现有DDS条目不匹配，则iSNS服务器应拒绝状态代码为3（无效注册）的DDSReg消息。如果DDS_ID同时包含在消息键和操作属性中，则消息键中的DDS_ID值必须与操作属性中的DDS_ID值相同。
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
没有消息密钥的DDSReg消息将导致尝试创建新的发现域集（DDS）。如果DDS_ID属性（长度非零）包含在DDSReg消息中的操作属性中，则应为新发现域集分配该DDS_ID属性中包含的值。否则，如果DDS_ID属性不包含在DDSReg消息的操作属性中，或者如果DDS_ID为
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.
TLV长度为0的操作属性，则iSNS服务器应分配DDS_ID值。然后在DDSReg响应消息中返回分配的DDS_ID值。操作属性还可以包含DDS_符号_名称、DDS状态和要添加到DDS的发现域的DD_ID。
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).
创建新的DDS时，如果DDS符号名称包含在操作属性中，且其值是唯一的（即，它与另一个DDS的注册DDS符号名称不匹配），则该值应作为该DDS的DDS符号名称存储在iSNS数据库中。如果DDS符号名称的值不唯一，则iSNS服务器应拒绝尝试的DDS注册，状态代码为3（无效注册）。
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.
创建新的DDS时，如果DDS符号名称未包含在操作属性中，或者如果它包含在零长度TLV中，则iSNS服务器应为创建的DDS提供唯一的DDS符号名称值。指定的DDS符号名称值应在DDSSP消息中返回。
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.
该消息应将作为操作属性列出的任何DD_ID添加到DDS_ID消息密钥属性指定的发现域集。此外，如果DDS_符号_名称是一个操作属性且值是唯一的，则应将其作为指定发现域集的DDS_符号_名称存储在iSNS数据库中。
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.
如果操作属性中列出的DD_ID与现有DD不匹配，则应使用DD_ID创建新的DD。在这种情况下，对于新DD，iSNS服务器应为DD符号名称分配一个唯一值，并应将DD Features属性设置为默认值0。这些指定值应在DDSRegRsp消息中返回。
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.
DDSDereg消息类型为0x000C。此消息允许iSNS客户端注销现有发现域集（DDS）或从现有DDS中删除一些DDS。
The DDSDereg message PDU Payload contains a Source Attribute, a Message Key Attribute, and optional Operating Attributes.
DDSDereg消息PDU有效负载包含源属性、消息键属性和可选操作属性。
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
DDSDereg消息的消息键属性是正在删除或已删除成员的DDS的DDS ID。如果驾驶员侧车门开关（DDS）识别码与现有驾驶员侧车门开关（DDS）匹配，并且没有操作属性，则
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.
应移除DDS并返回成功状态代码。该DDS的任何现有成员应保留在iSNS数据库中，而不是刚刚删除的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.
如果DDS ID与现有DDS匹配，且存在与DDS成员匹配的操作属性，则应从DDS中删除DDS成员，并返回成功状态代码。
The attempted deregistration of non-existent DDS entries SHALL not be considered an error.
尝试注销不存在的DDS条目不应视为错误。
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.
ESI消息类型为0x000D。此消息由iSNS服务器发送，用于验证iSNS客户端门户是否可访问和可用。ESI消息将发送到注册期间提供的ESI UDP端口，或发送到用于ESI注册的TCP连接，具体取决于所使用的通信类型。
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:
ESI消息PDU有效负载包含以下TLV格式的属性，并按列出的顺序排列：当前iSNS时间戳、EID、门户IP地址和门户TCP/UDP端口。此消息的格式如下所示：
+----------------------------------------+
| Timestamp |
+----------------------------------------+
| Entity_ID |
+----------------------------------------+
| Portal IP Address |
+----------------------------------------+
| Portal TCP/UDP Port |
+----------------------------------------+
+----------------------------------------+
| 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.
ESI响应消息PDU有效负载包含状态代码，后跟原始ESI消息的属性。
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.
如果门户未能响应管理确定的连续ESI消息数，则iSNS服务器应将该门户从iSNS数据库中删除。如果相关网络实体没有其他剩余的ESI监控门户，则该网络实体也应被删除。应触发适当的状态更改通知（如有）。
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.
此消息（如果使用）仅由活动iSNS服务器发送。它允许侦听广播或多播地址的iSNS客户端和备份服务器发现主iSNS服务器和备份iSNS服务器的IP地址。它还允许相关方监控主iSNS服务器的运行状况和状态。
This message is NOT in TLV format. There is no response message to the Name Service Heartbeat.
此消息不是TLV格式。没有对名称服务检测信号的响应消息。
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 |
+------------------------------------------------+
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:
心跳PDU有效负载包含以下内容：
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.
活动服务器IP地址：IPv6格式的活动iSNS服务器的IP地址。当此字段包含IPv4值时，它将存储为IPv4映射的IPv6地址。也就是说，最重要的10个字节设置为0x00，接下来的两个字节设置为0xFFFF[RFC2373]。当此字段包含IPv6值时，将使用整个16字节字段。
Active TCP Port: the TCP Port of the server currently in use.
活动TCP端口：当前正在使用的服务器的TCP端口。
Active UDP Port: the UDP Port of the server currently in use, otherwise 0.
活动UDP端口：当前正在使用的服务器的UDP端口，否则为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.
计数器：此服务器处于活动状态时从0开始的计数。自此服务器处于活动状态以来，每发送一次心跳，计数就会增加一次。
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.
备份服务器：iSNS备份服务器的数量。每个iSNS备份服务器的IP地址、TCP端口和UDP端口遵循此字段。请注意，如果使用备份服务器，则活动iSNS服务器应位于备份服务器列表中。
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.
备份服务器列表后此消息其余部分的内容是特定于供应商的。供应商可以使用其他字段来协调多个iSNS服务器，和/或识别供应商特定的功能。
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.
RqstDomId消息类型为0x0011。此消息用于iFCP透明模式，以在1和239之间分配不重叠的FC_域_ID值。iSNS服务器成为整个iFCP结构的地址分配机构。要获取多个FC_域_ID值，必须向iSNS服务器重复多次此请求。从iSNS服务器获取FC_DOMAIN_ID值的iSNS客户端必须从该iSNS服务器注册ESI监视。
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.
RqstDomId PDU有效负载按以下顺序包含三个TLV属性：请求交换机名称（WWN）作为源属性，虚拟结构ID作为消息键属性，首选ID作为操作属性。Virtual_Fabric_ID是一个字符串，标识域空间，iSNS服务器应为其分配1到239之间的不重叠整数FC_domain_ID值。首选_ID是iSNS客户端请求的标称FC_域_ID值。如果首选\u ID值可用且尚未为消息中指定的虚拟\u结构\u ID分配，iSNS服务器应将请求的首选\u ID值作为分配的\u ID返回给请求客户端。
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".
RqstDomId响应包含状态代码和TLV属性分配ID，该ID包含请求空间中的整数值。如果此空间中没有其他未分配的值可用，iSNS服务器应以状态代码18“FC_域_ID不可用”进行响应。
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.
一旦iSNS服务器为给定的虚拟\u结构\u ID向iSNS客户端分配了FC\u域\u ID值，在解除分配该FC\u域\u ID值之前，或者在ESI监控检测到网络上不再存在iSNS客户端并且该客户端的对象从iSNS数据库中删除之前，不得重复使用该FC\u域\u ID值。
The iSNS server and client SHALL use TCP to transmit and receive RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
iSNS服务器和客户端应使用TCP发送和接收RqstDomId、RqstDomIdRsp、RlseDomId和RlseDomIdRsp消息。
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.
RlseDomId消息类型为0x0012。iFCP透明模式可使用此消息来释放用于分配3字节光纤通道端口ID值的整数标识符值。
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.
RlseDomId消息按以下顺序包含三个TLV属性：请求EID作为源属性，虚拟结构ID作为消息键属性，分配ID作为操作属性。在接收到RlseDomId消息后，iSNS服务器应为指定的虚拟结构ID属性解除分配分配分配的ID属性中包含的FC_域ID值。解除分配后，该FC_域_ID值可以由其他iSNS客户端请求并分配给其他iSNS客户端。
The iSNS server and client SHALL use TCP to transmit and receive RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
iSNS服务器和客户端应使用TCP发送和接收RqstDomId、RqstDomIdRsp、RlseDomId和RlseDomIdRsp消息。
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.
GetDomId消息类型为0x0013。此消息用于了解给定虚拟\u结构\u ID的当前分配的FC\u域\u ID值。
The GetDomId message PDU Payload contains a Source Attribute and Message Key Attribute.
GetDomId消息PDU有效负载包含源属性和消息键属性。
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.
GetDomId消息的Message Key属性是Virtual\u Fabric\u ID。对此消息的响应返回已为指定的Virtual\u Fabric\u ID分配的所有FC\u DOMAIN\u ID值。
The iSNSP response message PDU Payloads contain a Status Code, followed by a list of attributes, and have the following format:
iSNSP响应消息PDU有效载荷包含状态代码，后跟属性列表，格式如下：
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) |
+----------------------------------------+
| . . . |
+----------------------------------------+
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.
iSNSP响应消息应发送至iSNS客户端IP地址和用于相关注册和查询消息的原始TCP/UDP端口。
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.
iSNSP响应消息PDU有效负载中的第一个字段是已执行操作的状态代码。第5.4节定义了状态代码编码。
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.
根据特定的iSNSP请求，响应消息可能包含消息键属性。消息密钥属性通常包含受原始iSNS注册或查询消息中指定的操作影响的有趣密钥属性。
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.
Delimiter属性用于分隔响应消息中的键和操作属性（如果存在）。Delimiter属性的标记值为0，长度值为0。Delimiter属性的长度实际上是8字节：一个4字节的标记包含0x00000000，一个4字节的字段包含0x00000000。
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.
响应中的操作属性是与正在执行的iSNS注册或查询操作相关的结果。某些响应消息将不具有操作属性。
The following sections describe each query and message type.
以下各节描述了每个查询和消息类型。
The DevAttrRegRsp message type is 0x8001. The DevAttrRegRsp message contains the results for the DevAttrReg message with the same TRANSACTION ID.
DevAttrRegRsp消息类型为0x8001。DevAttrRegRsp消息包含具有相同事务ID的DevAttrReg消息的结果。
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.
DevAttrRegRsp消息中的消息密钥应返回原始注册消息中的消息密钥。如果iSNS服务器为网络实体分配了实体标识符，则消息密钥属性字段应包含分配的实体标识符。
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.
DevAttrRegRsp消息的操作属性应包含受影响对象的关键和非关键属性，这些属性已由原始DevAttrReg消息明确修改或创建。在操作属性中，每个修改或添加的非关键属性应列在DevAttrRegRsp消息中其关键属性之后。DevAttrRegRsp消息中不得返回隐式注册的属性。隐式注册的属性是那些由iSNS服务器分配固定默认值或辅助索引值的属性。
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.
隐式注册的PG对象（即未显式包含在注册或替换消息中的PG对象）的密钥或非密钥属性不得在DevAttrRegRsp消息中返回。但是，显式注册的PG对象（即，注册或替换消息中显式包含PGT值的对象）应在DevAttrRegRsp消息中返回其PGT值。
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.
例如，在最初的DevAttrReg请求消息中注册了三个门户。由于缺少资源，iSNS服务器需要修改其中一个门户的已注册ESI间隔值。为此，iSNS服务器返回标识门户的密钥属性，然后返回非密钥修改ESI间隔属性值，作为相应DevAttrRegRsp消息的操作属性。
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.
如果iSNS服务器因无效属性值或类型而拒绝注册，则指示的状态代码应为3（无效注册）。如果出现这种情况，iSNS服务器可能会在DevAttrRsp消息的操作属性中包含无效属性列表。
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.
iSNS服务器可能会修改原始注册消息中的某些属性值（例如，ESI间隔、注册周期）。如第6.1节中的表格所示，这仅适用于一组有限的属性类型。发生这种情况时，应将注册视为成功（状态代码为0），并在DevAttrRsp消息的操作属性中指示更改的值。
The DevAttrQryRsp message type is 0x8002. The DevAttrQryRsp message contains the results for the DevAttrQry message with the same TRANSACTION ID.
DevAttrQryRsp消息类型为0x8002。DevAttrQryRsp消息包含具有相同事务ID的DevAttrQry消息的结果。
The Message Key in the DevAttrQryRsp message SHALL return the Message Key in the original query message.
DevAttrQryRsp消息中的消息键应返回原始查询消息中的消息键。
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.
对于成功的查询结果，DevAttrQryRsp操作属性应包含原始DevAttrQry消息的结果。
The DevGetNextRsp message type is 0x8003. The DevGetNextRsp message contains the results for the DevGetNext message with the same TRANSACTION ID.
DevGetNextRsp消息类型为0x8003。DevGetNextRsp消息包含具有相同事务ID的DevGetNext消息的结果。
The Message Key Attribute field returns the object keys for the next object after the Message Key Attribute in the original DevGetNext message.
消息键属性字段返回原始DevGetNext消息中消息键属性之后的下一个对象的对象键。
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.
Operating Attribute字段返回原始DevGetNext消息中请求的下一个对象的操作属性。操作属性的值与DevGetNextRsp消息的消息键属性字段标识的对象相关。
The DevDeregRsp message type is 0x8004. This message is the response to the DevDereg request message.
DevDeregRsp消息类型为0x8004。此消息是对DevDereg请求消息的响应。
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.
发生错误时，此响应消息包含适当的状态代码以及原始DevDereg消息中未成功从iSNS数据库注销的对象列表。此对象列表包含在DevDeregRsp消息的操作属性中。请注意，尝试注销不存在的对象并不构成错误，不存在的条目不应在DevDeregRsp消息中返回。
The SCNRegRsp message type is 0x8005. This message is the response to the SCNReg request message.
SCNRegRsp消息类型为0x8005。此消息是对SCNReg请求消息的响应。
The SCNRegRsp message does not contain any Message Key or Operating Attributes.
SCNRegRsp消息不包含任何消息键或操作属性。
The SCNDeregRsp message type is 0x8006. This message is the response to the SCNDereg request message.
SCNDERGRSP消息类型为0x8006。此消息是对SCNDereg请求消息的响应。
The SCNDeregRsp message does not contain any Message Key or Operating Attributes.
SCNDeregRsp消息不包含任何消息键或操作属性。
The SCNEventRsp message type is 0x8007. This message is the response to the SCNEvent request message.
SCNEventRsp消息类型为0x8007。此消息是对SCNEvent请求消息的响应。
The SCNEventRsp message does not contain any Message Key or Operating Attributes.
SCNEventRsp消息不包含任何消息键或操作属性。
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.
SCNRsp消息类型为0x8008。此消息由iSNS客户端发送，并确认已接收和处理SCN消息。
The SCNRsp response contains the SCN Destination Attribute representing the Node identifier that received the SCN.
SCNRsp响应包含表示接收SCN的节点标识符的SCN目标属性。
The DDRegRsp message type is 0x8009. This message is the response to the DDReg request message.
DDRegRsp消息类型为0x8009。此消息是对DDReg请求消息的响应。
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.
DDRegRsp消息中的消息键应返回原始查询消息中的消息键。如果原始DDReg消息没有消息密钥，则DDREGSP消息不应具有消息密钥。
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.
如果DDReg操作成功，创建或更新的DD的DD ID应作为消息的操作属性返回。
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.
如果在DDReg操作期间分配或更新了DD符号名称属性或DD功能属性，则应将任何新值作为DDREGSP消息的操作属性返回。
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.
如果iSNS服务器由于无效的属性值或类型而拒绝DDReg，则指示的状态代码应为3（无效注册）。如果出现这种情况，iSNS服务器可能会在DDRegRsp消息的操作属性中包含无效属性列表。
The DDDeregRsp message type is 0x800A. This message is the response to the DDDereg request message.
DDDeregRsp消息类型为0x800A。此消息是对DDDereg请求消息的响应。
The DDDeregRsp message does not contain any Message Key or Operating Attributes.
DDDeregRsp消息不包含任何消息键或操作属性。
The DDSRegRsp message type is 0x800B. This message is the response to the DDSReg request message.
DDSSP消息类型为0x800B。此消息是对DDSReg请求消息的响应。
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.
DDSREGSP消息中的消息键应包含原始DDSReg消息的消息键。如果原始DDSReg消息没有消息键，则DDSREGSP消息不应有消息键。
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.
如果DDSReg操作成功，创建或更新的DDS的DDS ID应作为消息的操作属性返回。
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.
如果DDS符号名称属性或DDS状态属性在DDSRegRsp操作期间被分配或更新，则任何新值应作为DDSRegRsp消息的操作属性返回。
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.
如果iSNS服务器由于无效属性值或类型而拒绝DDSReg，则指示的状态代码应为3（无效注册）。如果出现这种情况，iSNS服务器可能会在DDSRegRsp消息的操作属性中包含无效属性列表。
The DDSDeregRsp message type is 0x800C. This message is the response to the DDSDereg request message.
DDSDeregRsp消息类型为0x800C。此消息是对DDSDereg请求消息的响应。
The DDSDeregRsp message does not contain any Message Key or Operating Attributes.
DDSDeregRsp消息不包含任何消息键或操作属性。
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.
ESIRsp消息类型为0x800D。此消息由iSNS客户端发送，并确认已接收和处理ESI消息。
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.
ESIRsp响应消息PDU有效负载包含原始ESI消息的属性。这些属性表示响应ESI的门户。ESIRsp属性的顺序与原始ESI消息中提供的顺序相同。
Upon receiving the ESIRsp from the iSNS client, the iSNS server SHALL update the timestamp attribute for that Network Entity and Portal.
从iSNS客户端接收ESIRsp后，iSNS服务器应更新该网络实体和门户的时间戳属性。
The RqstDomIdRsp message type is 0x8011. This message provides the response for RqstDomId.
RqstDomIdRsp消息类型为0x8011。此消息提供对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".
RqstDomId响应包含状态代码和TLV属性分配ID，该ID包含请求空间中的整数值。如果此空间中没有其他未分配的值可用，iSNS服务器应以状态代码19“FC_域_ID不可用”进行响应。
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.
一旦iSNS服务器分配了FC_DOMAIN_ID值，在该值被分配到的iSNS客户端解除分配之前，或者在ESI消息检测到网络上不再存在iSNS客户端之前，不得重复使用该值。
The iSNS server and client SHALL use TCP to transmit and receive RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
iSNS服务器和客户端应使用TCP发送和接收RqstDomId、RqstDomIdRsp、RlseDomId和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".
RlseDomIdRsp消息类型为0x8012。此消息提供对RlseDomId的响应。响应包含一个错误，指示请求是否成功。如果未分配原始RlseDomId消息中分配的_ID值，则iSNS服务器应使用状态代码20“未分配FC_域_ID”响应此消息。
The iSNS server and client SHALL use TCP to transmit and receive RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
iSNS服务器和客户端应使用TCP发送和接收RqstDomId、RqstDomIdRsp、RlseDomId和RlseDomIdRsp消息。
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.
GetDomIdRsp消息类型为0x8013。此消息用于确定已为原始GetDomId请求消息中指定的虚拟结构ID分配了哪些FC_域ID值。
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.
GetDomId响应消息PDU有效负载包含指示请求是否成功的状态代码，以及从请求的空间分配的ID列表。指定的_ID属性以TLV格式列出。
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
特定于供应商的iSNSP消息的功能ID介于0x0100和0x01FF之间，而特定于供应商的响应的功能ID介于0x8100和0x81FF之间。消息中的第一个消息键属性
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.
供应商特定信息应为公司OUI（tag=256），标识专有iSNSP信息的原始创建者。消息其余部分的内容是特定于供应商的。
Attributes can be stored in the iSNS server using iSNSP registration messages, and they can be retrieved using iSNSP query messages. Unless otherwise indicated, these attributes are supplied by iSNS clients using iSNSP registration messages.
可以使用iSNSP注册消息将属性存储在iSNS服务器中，也可以使用iSNSP查询消息检索属性。除非另有说明，这些属性由iSNS客户端使用iSNSP注册消息提供。
The complete registry of iSNS attributes is maintained by IANA, and the following table summarizes the initial set of iSNS attributes available at the time of publication of this document.
iSNS属性的完整注册表由IANA维护，下表总结了本文档发布时可用的初始iSNS属性集。
Attributes Length Tag Reg Key Query Key
---------- ------ --- ------- ---------
Delimiter 0 0 N/A N/A
Entity Identifier (EID) 4-256 1 1 1|2|16&17|32|64
Entity Protocol 4 2 1 1|2|16&17|32|64
Management IP Address 16 3 1 1|2|16&17|32|64
Timestamp 8 4 -- 1|2|16&17|32|64
Protocol Version Range 4 5 1 1|2|16&17|32|64
Registration Period 4 6 1 1|2|16&17|32|64
Entity Index 4 7 1 1|2|16&17|32|64
Entity Next Index 4 8 -- 1|2|16&17|32|64
Entity ISAKMP Phase-1 var 11 1 1|2|16&17|32|64
Entity Certificate var 12 1 1|2|16&17|32|64
Portal IP Address 16 16 1 1|16&17|32|64
Portal TCP/UDP Port 4 17 1 1|16&17|32|64
Portal Symbolic Name 4-256 18 16&17 1|16&17|32|64
ESI Interval 4 19 16&17 1|16&17|32|64
ESI Port 4 20 16&17 1|16&17|32|64
Portal Index 4 22 16&17 1|16&17|32|64
SCN Port 4 23 16&17 1|16&17|32|64
Portal Next Index 4 24 -- 1|16&17|32|64
Portal Security Bitmap 4 27 16&17 1|16&17|32|64
Portal ISAKMP Phase-1 var 28 16&17 1|16&17|32|64
Portal ISAKMP Phase-2 var 29 16&17 1|16&17|32|64
Portal Certificate var 31 16&17 1|16&17|32|64
iSCSI Name 4-224 32 1 1|16&17|32|33
iSCSI Node Type 4 33 32 1|16&17|32
iSCSI Alias 4-256 34 32 1|16&17|32
iSCSI SCN Bitmap 4 35 32 1|16&17|32
iSCSI Node Index 4 36 32 1|16&17|32
WWNN Token 8 37 32 1|16&17|32
Attributes Length Tag Reg Key Query Key
---------- ------ --- ------- ---------
Delimiter 0 0 N/A N/A
Entity Identifier (EID) 4-256 1 1 1|2|16&17|32|64
Entity Protocol 4 2 1 1|2|16&17|32|64
Management IP Address 16 3 1 1|2|16&17|32|64
Timestamp 8 4 -- 1|2|16&17|32|64
Protocol Version Range 4 5 1 1|2|16&17|32|64
Registration Period 4 6 1 1|2|16&17|32|64
Entity Index 4 7 1 1|2|16&17|32|64
Entity Next Index 4 8 -- 1|2|16&17|32|64
Entity ISAKMP Phase-1 var 11 1 1|2|16&17|32|64
Entity Certificate var 12 1 1|2|16&17|32|64
Portal IP Address 16 16 1 1|16&17|32|64
Portal TCP/UDP Port 4 17 1 1|16&17|32|64
Portal Symbolic Name 4-256 18 16&17 1|16&17|32|64
ESI Interval 4 19 16&17 1|16&17|32|64
ESI Port 4 20 16&17 1|16&17|32|64
Portal Index 4 22 16&17 1|16&17|32|64
SCN Port 4 23 16&17 1|16&17|32|64
Portal Next Index 4 24 -- 1|16&17|32|64
Portal Security Bitmap 4 27 16&17 1|16&17|32|64
Portal ISAKMP Phase-1 var 28 16&17 1|16&17|32|64
Portal ISAKMP Phase-2 var 29 16&17 1|16&17|32|64
Portal Certificate var 31 16&17 1|16&17|32|64
iSCSI Name 4-224 32 1 1|16&17|32|33
iSCSI Node Type 4 33 32 1|16&17|32
iSCSI Alias 4-256 34 32 1|16&17|32
iSCSI SCN Bitmap 4 35 32 1|16&17|32
iSCSI Node Index 4 36 32 1|16&17|32
WWNN Token 8 37 32 1|16&17|32
iSCSI Node Next Index 4 38 -- 1|16&17|32 iSCSI AuthMethod var 42 32 1|16&17|32 PG iSCSI Name 4-224 48 32|16&17 1|16&17|32|52 PG Portal IP Addr 16 49 32|16&17 1|16&17|32|52 PG Portal TCP/UDP Port 4 50 32|16&17 1|16&17|32|52 PG Tag (PGT) 4 51 32|16&17 1|16&17|32|52 PG Index 4 52 32|16&17 1|16&17|32|52 PG Next Index 4 53 -- 1|16&17|32|52 FC Port Name WWPN 8 64 1 1|16&17|64|66|96|128 Port ID 4 65 64 1|16&17|64 FC Port Type 4 66 64 1|16&17|64 Symbolic Port Name 4-256 67 64 1|16&17|64 Fabric Port Name 8 68 64 1|16&17|64 Hard Address 4 69 64 1|16&17|64 Port IP-Address 16 70 64 1|16&17|64 Class of Service 4 71 64 1|16&17|64 FC-4 Types 32 72 64 1|16&17|64 FC-4 Descriptor 4-256 73 64 1|16&17|64 FC-4 Features 128 74 64 1|16&17|64 iFCP SCN bitmap 4 75 64 1|16&17|64 Port Role 4 76 64 1|16&17|64 Permanent Port Name 8 77 -- 1|16&17|64 FC-4 Type Code 4 95 -- 1|16&17|64 FC Node Name WWNN 8 96 64 1|16&17|64|96 Symbolic Node Name 4-256 97 96 64|96 Node IP-Address 16 98 96 64|96 Node IPA 8 99 96 64|96 Proxy iSCSI Name 4-256 101 96 64|96 Switch Name 8 128 128 128 Preferred ID 4 129 128 128 Assigned ID 4 130 128 128 Virtual_Fabric_ID 4-256 131 128 128 iSNS Server Vendor OUI 4 256 -- SOURCE Attribute Vendor-Spec iSNS Srvr 257-384 -- SOURCE Attribute Vendor-Spec Entity 385-512 1 1|2|16&17|32|64 Vendor-Spec Portal 513-640 16&17 1|16&17|32|64 Vendor-Spec iSCSI Node 641-768 32 16&17|32 Vendor-Spec FC Port Name 769-896 64 1|16&17|64 Vendor-Spec FC Node Name 897-1024 96 64|96 Vendor-Specific DDS 1025-1280 2049 2049 Vendor-Specific DD 1281-1536 2065 2065 Other Vendor-Specific 1537-2048 DD_Set ID 4 2049 2049 1|32|64|2049|2065 DD_Set Sym Name 4-256 2050 2049 2049 DD_Set Status 4 2051 2049 2049 DD_Set_Next_ID 4 2052 -- 2049 DD_ID 4 2065 2049 1|32|64|2049|2065 DD_Symbolic Name 4-256 2066 2065 2065
iSCSI节点下一个索引4 38--1 | 16和17 | 32 iSCSI身份验证方法变量42 32 1 | 16和17 | 32 PG iSCSI名称4-224 48 32 | 16和17 1 | 16和17 | 32 | 52 PG Portal IP地址16 49 32 | 16和17 | 32 | 52 PG Portal TCP/UDP端口4 50 32 | 16和17 | 16和17 | 32 | 52 PGT标签4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4| 64硬地址4 69 64 1 | 16和17 | 64端口IP地址16 70 6416和17 | 16和17 12416和17 12416和17 12416和17 12444 4 FC-4 4类32 72 64 1 12416和17 12416和17 12416和17 12416和17 12416和17 12416和17 12416和17 12444 4 4 6 FC-FC-4 FC-4 4 4 4 4 4 4 4 4 4 4 4 7 7 7 7 7 7 7 7 7 7 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 7 7 7 7 7 7 7 7 7 7 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4| 64 | 96符号节点名称4-256 97 96 64 | 96节点IP地址16 98 96 64 | 96节点IPA 8 99 96 64 | 96代理iSCSI名称4-256 101 96 64 | 96交换机名称8 128 128首选ID 4 129 128 128分配ID 4 130 128 128虚拟结构ID 4-256 131 128 128 iSNS服务器供应商OUI 4 256--源属性供应商规范iSNS Srvr 257-384--源属性供应商规范实体385-5121 | 2 | 16和17 | 32 | 64供应商规范门户513-640 16和17 | 16和17 | 64供应商规范iSCSI节点641-768 32 16和17 | 32供应商规范FC端口名称769-896 64 1 | 16和17 | 64供应商规范FC节点名称897-1024 96 64 | 96供应商特定DDS 1025-1280 2049 2049供应商特定DD 1281-1536 2065其他供应商特定的1537-2048 DD U集12492049数据集符号名称4-256 2050 2049 2049数据集状态4 2051 2049 2049数据集下一个数据集ID 4 2052--2049数据集ID 4 2065 2049 1 | 32 | 64 | 2049 | 2065数据集符号名称4-256 2066 2065 2065
DD_Member iSCSI Index 4 2067 2065 2065 DD_Member iSCSI Name 4-224 2068 2065 2065 DD_Member FC Port Name 8 2069 2065 2065 DD_Member Portal Index 4 2070 2065 2065 DD_Member Portal IP Addr 16 2071 2065 2065 DD_Member Portal TCP/UDP 4 2072 2065 2065 DD_Features 4 2078 2065 2065 DD_ID Next ID 4 2079 -- 2065
DD_成员iSCSI索引4 2067 2065 2065 DD_成员iSCSI名称4-224 2068 2065 2065 DD_成员FC端口名称8 2069 2065 2065 DD_成员门户索引4 2070 2065 2065 DD_成员门户IP地址16 2071 2065 2065 DD_成员门户TCP/UDP 4 2072 2065 DD_功能4 2078 2065 2065 DD_ID下一个ID 4 2079--2065
The following are descriptions of the columns used in the above table:
以下是上表中使用的列的说明：
Length: indicates the attribute length in bytes used for the TLV format. Variable-length identifiers are NULL-terminated and 4-byte aligned (NULLs are included in the length).
长度：表示TLV格式使用的属性长度（字节）。可变长度标识符以NULL结尾，4字节对齐（长度中包括NULL）。
Tag: the IANA-assigned integer tag value used to identify the attribute. All undefined tag values are reserved.
标记：IANA分配的整数标记值，用于标识属性。保留所有未定义的标记值。
Reg Key: indicates the tag values for the object key in DevAttrReg messages for registering a new attribute value in the database. These tags represent attributes defined as object keys in Section 4.
Reg Key：指示用于在数据库中注册新属性值的DevAttrReg消息中对象键的标记值。这些标记表示第4节中定义为对象键的属性。
Query Key: indicates the possible tag values for the Message Key and object key that are used in the DevAttrQry messages for retrieving a stored value from the iSNS database.
查询键：指示DevAttrQry消息中用于从iSNS数据库检索存储值的消息键和对象键的可能标记值。
The following is a summary of iSNS attribute tag values available for future allocation by IANA at the time of publication:
以下是iSNS属性标签值的摘要，可供IANA在发布时将来分配：
Tag Values Reg Key Query Key
---------- ------- ---------
9-10, 13-15 1 1|2|16&17|32|64
21, 25-26, 30 16&17 1|16&17|32|64
39-41, 44-47 32 1|16&17|32
54-63 32|16&17 1|16&17|32|52
78-82, 85-94 64 1|16&17|64
102-127 96 64|96
132-255 -- SOURCE Attribute
2053-2064 2049 2049
2073-2077 2065 2065
2080-65535 To be assigned To be assigned
Tag Values Reg Key Query Key
---------- ------- ---------
9-10, 13-15 1 1|2|16&17|32|64
21, 25-26, 30 16&17 1|16&17|32|64
39-41, 44-47 32 1|16&17|32
54-63 32|16&17 1|16&17|32|52
78-82, 85-94 64 1|16&17|64
102-127 96 64|96
132-255 -- SOURCE Attribute
2053-2064 2049 2049
2073-2077 2065 2065
2080-65535 To be assigned To be assigned
Registration and query keys for attributes with tags in the range 2080 to 65535 are to be documented in the RFC introducing the new iSNS attributes. IANA will maintain registration of these values as required by the new RFC.
标签范围在2080到65535之间的属性的注册和查询密钥将记录在引入新iSNS属性的RFC中。IANA将按照新RFC的要求对这些值进行登记。
New iSNS attributes with any of the above tag values MAY also be designated as "read-only" attributes. The new RFC introducing these attributes as "read-only" SHALL document them as such, and IANA will record their corresponding Registration Keys (Reg Keys) as "--".
具有上述任何标记值的新iSNS属性也可以指定为“只读”属性。引入这些属性为“只读”的新RFC应将其记录为只读，IANA将其相应的注册密钥（注册密钥）记录为“-”。
The following attributes are stored in the iSNS server using the Entity Identifier attribute as the key.
以下属性使用实体标识符属性作为密钥存储在iSNS服务器中。
The Entity Identifier (EID) is variable-length UTF-8 encoded NULL-terminated text-based description for a Network Entity. This key attribute uniquely identifies each Network Entity registered in the iSNS server. The attribute length varies from 4 to 256 bytes (including the NULL termination), and is a unique value within the iSNS server.
实体标识符（EID）是网络实体的可变长度UTF-8编码的空终止文本描述。此密钥属性唯一标识在iSNS服务器中注册的每个网络实体。属性长度从4字节到256字节不等（包括空终止），是iSNS服务器中的唯一值。
If the iSNS client does not provide an EID during registration, the iSNS server SHALL generate one that is unique within the iSNS database. If an EID is to be generated, then the EID attribute value in the registration message SHALL be empty (0 length). The generated EID SHALL be returned in the registration response.
如果iSNS客户端在注册期间未提供EID，iSNS服务器应在iSNS数据库中生成唯一的EID。如果要生成EID，则注册消息中的EID属性值应为空（0长度）。生成的EID应在注册响应中返回。
In environments where the iSNS server is integrated with a DNS infrastructure, the Entity Identifier may be used to store the Fully Qualified Domain Name (FQDN) of the iSCSI or iFCP device. FQDNs of greater than 255 bytes MUST NOT be used.
在iSNS服务器与DNS基础架构集成的环境中，实体标识符可用于存储iSCSI或iFCP设备的完全限定域名（FQDN）。不得使用大于255字节的FQDN。
If FQDNs are not used, the iSNS server can be used to generate EIDs. EIDs generated by the iSNS server MUST begin with the string "isns:". iSNS clients MUST NOT generate and register EIDs beginning with the string "isns:".
如果未使用FQDN，则可以使用iSNS服务器生成EID。iSNS服务器生成的EID必须以字符串“iSNS:”开头。iSNS客户端不得生成和注册以字符串“iSNS:”开头的EID。
This field MUST be normalized according to the nameprep template [NAMEPREP] before it is stored in the iSNS database.
此字段必须根据nameprep模板[nameprep]进行规范化，然后才能存储在iSNS数据库中。
The Entity Protocol is a required 4-byte integer attribute that indicates the block storage protocol used by the registered NETWORK ENTITY. Values used for this attribute are assigned and maintained by IANA. The initial set of protocols supported by iSNS is as follows:
实体协议是一个必需的4字节整数属性，表示注册网络实体使用的块存储协议。用于此属性的值由IANA分配和维护。iSNS支持的初始协议集如下：
Value Entity Protocol Type
----- --------------------
1 No Protocol
2 iSCSI
3 iFCP
All others To be assigned by IANA
Value Entity Protocol Type
----- --------------------
1 No Protocol
2 iSCSI
3 iFCP
All others To be assigned by IANA
'No Protocol' is used to indicate that the Network Entity does not support an IP block storage protocol. A Control Node or monitoring Node would likely (but not necessarily) use this value.
“无协议”用于表示网络实体不支持IP块存储协议。控制节点或监视节点可能（但不一定）使用此值。
This attribute is required during initial registration of the Network Entity.
此属性在网络实体的初始注册期间是必需的。
This field contains the IP Address that may be used to manage the Network Entity and all Storage Nodes contained therein via the iSNS MIB [iSNSMIB]. Some implementations may also use this IP address to support vendor-specific proprietary management protocols. The Management IP Address is a 16-byte field that may contain an IPv4 or IPv6 address. When this field contains an IPv4 value, it is stored as an IPv4-mapped IPv6 address. That is, the most significant 10 bytes are set to 0x00, with the next two bytes set to 0xFFFF [RFC2373]. When this field contains an IPv6 value, the entire 16- byte field is used. If this field is not set, then in-band management through the IP address of one of the Portals of the Network Entity is assumed.
此字段包含可用于通过iSNS MIB[iSNSMIB]管理网络实体和其中包含的所有存储节点的IP地址。一些实现还可能使用此IP地址来支持特定于供应商的专有管理协议。管理IP地址是一个16字节的字段，可能包含IPv4或IPv6地址。当此字段包含IPv4值时，它将存储为IPv4映射的IPv6地址。也就是说，最重要的10个字节设置为0x00，接下来的两个字节设置为0xFFFF[RFC2373]。当此字段包含IPv6值时，将使用整个16字节字段。如果未设置此字段，则假定通过网络实体的一个入口的IP地址进行带内管理。
This field indicates the most recent time when the Network Entity registration occurred or when an associated object attribute was updated or queried by the iSNS client registering the Network Entity. The time format is, in seconds, the update period since the standard base time of 00:00:00 GMT on January 1, 1970. This field cannot be explicitly registered. This timestamp TLV format is also used in the SCN and ESI messages.
此字段表示网络实体注册发生的最近时间，或注册网络实体的iSNS客户端更新或查询关联对象属性的最近时间。时间格式是自1970年1月1日标准基准时间00:00:00 GMT以来的更新周期（以秒为单位）。无法显式注册此字段。此时间戳TLV格式也用于SCN和ESI消息中。
This field contains the minimum and maximum version of the block storage protocol supported by the Network Entity. The most significant two bytes contain the maximum version supported, and the least significant two bytes contain the minimum version supported. If a range is not registered, then the Network Entity is assumed to
此字段包含网络实体支持的块存储协议的最低和最高版本。最高有效的两个字节包含支持的最高版本，最低有效的两个字节包含支持的最低版本。如果未注册范围，则假定网络实体为
support all versions of the protocol. The value 0xffff is a wildcard that indicates no minimum or maximum. If the Network Entity does not support a protocol, then this field SHALL be set to 0.
支持协议的所有版本。值0xffff是一个通配符，表示没有最小值或最大值。如果网络实体不支持协议，则该字段应设置为0。
This 4-byte unsigned integer field indicates the maximum period, in seconds, that the registration SHALL be maintained by the server without receipt of an iSNS message from the iSNS client that registered the Network Entity. Entities that are not registered for ESI monitoring MUST have a non-zero Registration Period. If a Registration Period is not requested by the iSNS client and Entity Status Inquiry (ESI) messages are not enabled for that client, then the Registration Period SHALL be set to a non-zero value by the iSNS server. This implementation-specific value for the Registration Period SHALL be returned in the registration response to the iSNS client. The Registration Period may be set to zero, indicating its non-use, only if ESI messages are enabled for that Network Entity.
此4字节无符号整数字段表示服务器在未收到来自注册网络实体的iSNS客户端的iSNS消息的情况下保持注册的最长时间（以秒为单位）。未注册ESI监控的实体必须具有非零注册期。如果iSNS客户端未请求注册期，且该客户端未启用实体状态查询（ESI）消息，则iSNS服务器应将注册期设置为非零值。注册期间的该实施特定值应在向iSNS客户端的注册响应中返回。仅当为该网络实体启用ESI消息时，注册周期可设置为零，表示其未使用。
The registration SHALL be removed from the iSNS database if an iSNS Protocol message is not received from the iSNS client before the registration period has expired. Receipt of any iSNS Protocol message from the iSNS client automatically refreshes the Entity Registration Period and Entity Registration Timestamp. To prevent a registration from expiring, the iSNS client should send an iSNS Protocol message to the iSNS server at intervals shorter than the registration period. Such a message can be as simple as a query for one of its own attributes, using its associated iSCSI Name or FC Port Name WWPN as the Source attribute.
如果在注册期到期之前未从iSNS客户端收到iSNS协议消息，则应从iSNS数据库中删除注册。从iSNS客户端接收任何iSNS协议消息时，都会自动刷新实体注册周期和实体注册时间戳。为防止注册过期，iSNS客户端应以短于注册周期的间隔向iSNS服务器发送iSNS协议消息。这样的消息可以非常简单，只需使用其关联的iSCSI名称或FC端口名称WWPN作为源属性，查询其自身的一个属性即可。
For an iSNS client that is supporting a Network Entity with multiple Storage Node objects, receipt of an iSNS message from any Storage Node of that Network Entity is sufficient to refresh the registration for all Storage Node objects of the Network Entity.
对于支持具有多个存储节点对象的网络实体的iSNS客户端，从该网络实体的任何存储节点接收iSNS消息足以刷新该网络实体的所有存储节点对象的注册。
If ESI support is requested as part of a Portal registration, the ESI Response message received from the iSNS client by the iSNS server SHALL refresh the registration.
如果作为门户注册的一部分请求ESI支持，则iSNS服务器从iSNS客户端收到的ESI响应消息应刷新注册。
The Entity Index is an unsigned non-zero integer value that uniquely identifies each Network Entity registered in the iSNS server. Upon initial registration of a Network Entity, the iSNS server assigns an unused value for the Entity Index. Each Network Entity in the iSNS database MUST be assigned a value for the Entity Index that is not
实体索引是一个无符号非零整数值，它唯一标识在iSNS服务器中注册的每个网络实体。初始注册网络实体后，iSNS服务器会为实体索引分配一个未使用的值。必须为iSNS数据库中的每个网络实体分配一个不可用的实体索引值
assigned to any other Network Entity. Furthermore, Entity Index values for recently deregistered Network Entities SHOULD NOT be reused in the short term.
分配给任何其他网络实体。此外，近期注销的网络实体的实体索引值短期内不应重复使用。
The Entity Index MAY be used to represent the Network Entity in situations when the Entity Identifier is too long or otherwise inappropriate. An example of this is when SNMP is used for management, as described in Section 2.10.
实体索引可用于在实体标识符过长或不适当的情况下表示网络实体。如第2.10节所述，使用SNMP进行管理就是一个例子。
This is a virtual attribute containing a 4-byte integer value that indicates the next available (i.e., unused) Entity Index value. This attribute may only be queried; the iSNS server SHALL return an error code of 3 (Invalid Registration) to any client that attempts to register a value for this attribute. A Message Key is not required when exclusively querying for this attribute.
这是一个虚拟属性，包含一个4字节整数值，指示下一个可用（即未使用）实体索引值。只能查询该属性；iSNS服务器应向尝试注册此属性值的任何客户端返回错误代码3（无效注册）。独占查询此属性时不需要消息键。
The Entity Next Index MAY be used by an SNMP client to create an entry in the iSNS server. SNMP requirements are described in Section 2.10.
SNMP客户端可以使用实体下一个索引在iSNS服务器中创建条目。SNMP要求见第2.10节。
This field contains the IKE Phase-1 proposal, listing in decreasing order of preference the protection suites acceptable to protect all IKE Phase-2 messages sent and received by the Network Entity. This includes Phase-2 SAs from the iSNS client to the iSNS server as well as to peer iFCP and/or iSCSI devices. This attribute contains the SA payload, proposal payload(s), and transform payload(s) in the ISAKMP format defined in [RFC2408].
此字段包含IKE第1阶段建议，按优先顺序递减列出可接受的保护套件，以保护网络实体发送和接收的所有IKE第2阶段消息。这包括从iSNS客户端到iSNS服务器以及到对等iFCP和/或iSCSI设备的第2阶段SAs。此属性包含[RFC2408]中定义的ISAKMP格式的SA有效负载、提案有效负载和转换有效负载。
This field should be used if the implementer wishes to define a single phase-1 SA security configuration used to protect all phase-2 IKE traffic. If the implementer desires to have a different phase-1 SA security configuration to protect each Portal interface, then the Portal Phase-1 Proposal (Section 6.3.10) should be used.
如果实施者希望定义用于保护所有阶段2 IKE流量的单阶段1 SA安全配置，则应使用此字段。如果实施者希望使用不同的第一阶段SA安全配置来保护每个门户接口，则应使用门户第一阶段提案（第6.3.10节）。
This attribute contains one or more X.509 certificates that are bound to the Network Entity. This certificate is uploaded and registered to the iSNS server by clients wishing to allow other clients to authenticate themselves and to access the services offered by that Network Entity. The format of the X.509 certificate is found in [RFC3280]. This certificate MUST contain a Subject Name with an empty sequence and MUST contain a SubjectAltName extension encoded
此属性包含一个或多个绑定到网络实体的X.509证书。此证书由希望允许其他客户端进行身份验证并访问该网络实体提供的服务的客户端上载并注册到iSNS服务器。X.509证书的格式见[RFC3280]。此证书必须包含具有空序列的Subject名称，并且必须包含SubjectAltName扩展名
with the dNSName type. The Entity Identifier (Section 6.2.1) of the identified Entity MUST be stored in the SubjectAltName field of the certificate.
使用dNSName类型。已识别实体的实体标识符（第6.2.1节）必须存储在证书的SubjectAltName字段中。
The following Portal attributes are registered in the iSNS database using the combined Portal IP-Address and Portal TCP/UDP Port as the key. Each Portal is associated with one Entity Identifier object key.
使用组合的门户IP地址和门户TCP/UDP端口作为密钥，在iSNS数据库中注册以下门户属性。每个门户都与一个实体标识符对象键相关联。
This attribute is the IP address of the Portal through which a Storage Node can transmit and receive storage data. The Portal IP Address is a 16-byte field that may contain an IPv4 or IPv6 address. When this field contains an IPv4 address, it is stored as an IPv4- mapped IPv6 address. That is, the most significant 10 bytes are set to 0x00, with the next 2 bytes set to 0xFFFF [RFC2373]. When this field contains an IPv6 address, the entire 16-byte field is used. The Portal IP Address and the Portal TCP/UDP Port number (see 6.3.2 below) are used as a key to identify a Portal uniquely. It is a required attribute for registration of a Portal.
此属性是门户的IP地址，存储节点可以通过该IP地址发送和接收存储数据。门户IP地址是一个16字节的字段，可能包含IPv4或IPv6地址。当此字段包含IPv4地址时，它将存储为IPv4映射的IPv6地址。也就是说，最重要的10个字节设置为0x00，接下来的2个字节设置为0xFFFF[RFC2373]。当此字段包含IPv6地址时，将使用整个16字节字段。门户IP地址和门户TCP/UDP端口号（见下文6.3.2）用作唯一标识门户的密钥。它是门户注册所必需的属性。
The TCP/UDP port of the Portal through which a Storage Node can transmit and receive storage data. Bits 16 to 31 represents the TCP/UDP port number. Bit 15 represents the port type. If bit 15 is set, then the port type is UDP. Otherwise it is TCP. Bits 0 to 14 are reserved.
门户的TCP/UDP端口，存储节点可通过该端口传输和接收存储数据。位16到31表示TCP/UDP端口号。位15表示端口类型。如果设置了位15，则端口类型为UDP。否则就是TCP。保留位0至14。
If the field value is 0, then the port number is the implied canonical port number and type of the protocol indicated by the associated Entity Type.
如果字段值为0，则端口号是由关联实体类型指示的隐含规范端口号和协议类型。
The Portal IP Address and the Portal TCP/UDP Port number are used as a key to identify a Portal uniquely. It is a required attribute for registration of a Portal.
门户IP地址和门户TCP/UDP端口号用作唯一标识门户的密钥。它是门户注册所必需的属性。
A variable-length UTF-8 encoded NULL-terminated text-based description of up to 256 bytes. The Portal Symbolic Name is a user-readable description of the Portal entry in the iSNS server.
一种可变长度UTF-8编码的空终止文本描述，最多256字节。门户符号名称是iSNS服务器中门户条目的用户可读描述。
This field indicates the requested time, in seconds, between Entity Status Inquiry (ESI) messages sent from the iSNS server to this Network Entity. ESI messages can be used to verify that a Portal registration continues to be valid. To request monitoring by the iSNS server, an iSNS client registers a non-zero value for this Portal attribute using a DevAttrReg message. The client MUST register an ESI Port on at least one of its Portals to receive the ESI monitoring.
此字段表示从iSNS服务器发送到此网络实体的实体状态查询（ESI）消息之间的请求时间（以秒为单位）。ESI消息可用于验证门户注册是否继续有效。要请求iSNS服务器进行监视，iSNS客户端将使用DevAttrReg消息为此门户属性注册一个非零值。客户端必须在其至少一个门户上注册ESI端口，才能接收ESI监视。
If the iSNS server does not receive an expected response to an ESI message, it SHALL attempt an administratively configured number of re-transmissions of the ESI message. The ESI Interval period begins with the iSNS server's receipt of the last ESI Response. All re-transmissions MUST be sent before twice the ESI Interval period has passed. If no response is received from any of the ESI messages, then the Portal SHALL be deregistered. Note that only Portals that have registered a value in their ESI Port field can be deregistered in this way.
如果iSNS服务器未收到对ESI消息的预期响应，则应尝试重新传输ESI消息的管理配置次数。ESI间隔期从iSNS服务器收到最后一个ESI响应开始。所有重新传输必须在ESI间隔时间超过两倍之前发送。如果未收到来自任何ESI消息的响应，则应注销门户。请注意，只有在ESI端口字段中注册了值的门户才能以这种方式取消注册。
If all Portals associated with a Network Entity that have registered for ESI messages are deregistered due to non-response, and if no registrations have been received from the client for at least two ESI Interval periods, then the Network Entity and all associated objects (including Storage Nodes) SHALL be deregistered.
如果与已注册ESI消息的网络实体相关联的所有门户由于无响应而取消注册，并且如果在至少两个ESI间隔期间未收到来自客户端的注册，则应取消注册网络实体和所有相关对象（包括存储节点）。
If the iSNS server is unable to support ESI messages or the ESI Interval requested, it SHALL either reject the ESI request by returning an "ESI Not Available" Status Code or modify the ESI Interval attribute by selecting its own suitable value and returning that value in the Operating Attributes of the registration response message.
如果iSNS服务器无法支持ESI消息或请求的ESI间隔，则应通过返回“ESI不可用”状态代码来拒绝ESI请求，或通过选择自己的合适值并在注册响应消息的操作属性中返回该值来修改ESI间隔属性。
If at any time an iSNS client that is registered for ESI messages has not received an ESI message to any of its Portals as expected, then the client MAY attempt to query the iSNS server using a DevAttrQry message using its Entity_ID as the key. If the query result is the error "no such entry", then the client SHALL close all remaining TCP connections to the iSNS server and assume that it is no longer registered in the iSNS database. Such a client MAY attempt re-registration.
如果在任何时候，注册ESI消息的iSNS客户端未按预期接收到发送至其任何门户的ESI消息，则该客户端可尝试使用其实体ID作为密钥的DevAttrQry消息查询iSNS服务器。如果查询结果为错误“无此类条目”，则客户端应关闭与iSNS服务器的所有剩余TCP连接，并假定它不再在iSNS数据库中注册。这样的客户可能会尝试重新注册。
This field contains the TCP or UDP port used for ESI monitoring by the iSNS server at the Portal IP Address. Bits 16 to 31 represent the port number. If bit 15 is set, then the port type is UDP. Otherwise, the port is TCP. Bits 0 to 14 are reserved.
此字段包含用于iSNS服务器在门户IP地址进行ESI监视的TCP或UDP端口。位16到31表示端口号。如果设置了位15，则端口类型为UDP。否则，端口为TCP。保留位0至14。
If the iSNS client registers a valid TCP or UDP port number in this field, then the client SHALL allow ESI messages to be received at the indicated TCP or UDP port. If a TCP port is registered and a pre-existing TCP connection from that TCP port to the iSNS server does not already exist, then the iSNS client SHALL accept new TCP connections from the iSNS server at the indicated TCP port.
如果iSNS客户端在此字段中注册了有效的TCP或UDP端口号，则客户端应允许在指定的TCP或UDP端口接收ESI消息。如果已注册TCP端口，并且从该TCP端口到iSNS服务器的预先存在的TCP连接不存在，则iSNS客户端应在指定的TCP端口接受来自iSNS服务器的新TCP连接。
The iSNS server SHALL return an error if a Network Entity is registered for ESI monitoring and none of the Portals of that Network Entity has an entry for the ESI Port field. If multiple Portals have a registered ESI port, then the ESI message may be delivered to any one of the indicated Portals.
如果某个网络实体注册进行ESI监控，且该网络实体的任何门户都没有ESI端口字段的条目，则iSNS服务器应返回错误。如果多个入口具有注册的ESI端口，则ESI消息可被传送到所指示的入口中的任何一个。
The Portal Index is a 4-byte non-zero integer value that uniquely identifies each Portal registered in the iSNS database. Upon initial registration of a Portal, the iSNS server assigns an unused value for the Portal Index of that Portal. Each Portal in the iSNS database MUST be assigned a value for the Portal Index that is not assigned to any other Portal. Furthermore, Portal Index values for recently deregistered Portals SHOULD NOT be reused in the short term.
门户索引是一个4字节的非零整数值，唯一标识iSNS数据库中注册的每个门户。初始注册门户后，iSNS服务器会为该门户的门户索引分配一个未使用的值。必须为iSNS数据库中的每个门户分配一个未分配给任何其他门户的门户索引值。此外，近期注销的门户的门户索引值短期内不应重复使用。
The Portal Index MAY be used to represent a registered Portal in situations where the Portal IP-Address and Portal TCP/UDP Port is unwieldy to use. An example of this is when SNMP is used for management, as described in Section 2.10.
在门户IP地址和门户TCP/UDP端口难以使用的情况下，门户索引可用于表示已注册的门户。如第2.10节所述，使用SNMP进行管理就是一个例子。
This field contains the TCP or UDP port used by the iSNS client to receive SCN messages from the iSNS server. When a value is registered for this attribute, an SCN message may be received on the indicated port for any of the Storage Nodes supported by the Portal. Bits 16 to 31 contain the port number. If bit 15 is set, then the port type is UDP. Otherwise, the port type is TCP. Bits 0 to 14 are reserved.
此字段包含iSNS客户端用于从iSNS服务器接收SCN消息的TCP或UDP端口。为该属性注册值时，可能会在门户支持的任何存储节点的指定端口上接收SCN消息。位16到31包含端口号。如果设置了位15，则端口类型为UDP。否则，端口类型为TCP。保留位0至14。
If the iSNS client registers a valid TCP or UDP port number in this field, then the client SHALL allow SCN messages to be received at the indicated TCP or UDP port. If a TCP port is registered and a pre-
如果iSNS客户端在此字段中注册了有效的TCP或UDP端口号，则客户端应允许在指定的TCP或UDP端口接收SCN消息。如果TCP端口已注册且预-
existing TCP connection from that TCP port to the iSNS server does not already exist, then the iSNS client SHALL accept new TCP connections from the iSNS server at the indicated TCP port.
从该TCP端口到iSNS服务器的现有TCP连接不存在，则iSNS客户端应在指定的TCP端口接受来自iSNS服务器的新TCP连接。
The iSNS server SHALL return an error if an SCN registration message is received and none of the Portals of the Network Entity has an entry for the SCN Port. If multiple Portals have a registered SCN Port, then the SCN SHALL be delivered to any one of the indicated Portals of that Network Entity.
如果收到SCN注册消息，且网络实体的任何门户都没有SCN端口条目，则iSNS服务器应返回错误。如果多个门户具有注册的SCN端口，则SCN应交付给该网络实体的任何一个指定门户。
This is a virtual attribute containing a 4-byte integer value that indicates the next available (i.e., unused) Portal Index value. This attribute may only be queried; the iSNS server SHALL return an error code of 3 (Invalid Registration) to any client that attempts to register a value for this attribute. A Message Key is not required when exclusively querying for this attribute.
这是一个虚拟属性，包含一个4字节整数值，指示下一个可用（即未使用）门户索引值。只能查询该属性；iSNS服务器应向尝试注册此属性值的任何客户端返回错误代码3（无效注册）。独占查询此属性时不需要消息键。
The Portal Next Index MAY be used by an SNMP client to create an entry in the iSNS server. SNMP requirements are described in Section 2.10.
SNMP客户端可以使用Portal Next索引在iSNS服务器中创建条目。SNMP要求见第2.10节。
This 4-byte field contains flags that indicate security attribute settings for the Portal. Bit 31 (Lsb) of this field must be 1 (enabled) for this field to contain significant information. If Bit 31 is enabled, this signifies that the iSNS server can be used to store and distribute security policies and settings for iSNS clients (i.e., iSCSI devices). Bit 30 must be 1 for bits 25-29 to contain significant information. All other bits are reserved for non-IKE/IPSec security mechanisms to be specified in the future.
此4字节字段包含指示门户安全属性设置的标志。此字段的位31（Lsb）必须为1（启用），此字段才能包含重要信息。如果启用位31，则表示iSNS服务器可用于存储和分发iSNS客户端（即iSCSI设备）的安全策略和设置。位30必须为1，位25-29才能包含重要信息。所有其他位保留给将来指定的非IKE/IPSec安全机制。
Bit Position Flag Description
------------ ----------------
25 1 = Tunnel Mode Preferred; 0 = No Preference
26 1 = Transport Mode Preferred; 0 = No Preference
27 1 = Perfect Forward Secrecy (PFS) Enabled;
0 = PFS Disabled
28 1 = Aggressive Mode Enabled; 0 = Disabled
29 1 = Main Mode Enabled; 0 = MM Disabled
30 1 = IKE/IPSec Enabled; 0 = IKE/IPSec Disabled
31 (Lsb) 1 = Bitmap VALID; 0 = INVALID
All others RESERVED
Bit Position Flag Description
------------ ----------------
25 1 = Tunnel Mode Preferred; 0 = No Preference
26 1 = Transport Mode Preferred; 0 = No Preference
27 1 = Perfect Forward Secrecy (PFS) Enabled;
0 = PFS Disabled
28 1 = Aggressive Mode Enabled; 0 = Disabled
29 1 = Main Mode Enabled; 0 = MM Disabled
30 1 = IKE/IPSec Enabled; 0 = IKE/IPSec Disabled
31 (Lsb) 1 = Bitmap VALID; 0 = INVALID
All others RESERVED
This field contains the IKE Phase-1 proposal listing in decreasing order of preference of the protection suites acceptable to protect all IKE Phase-2 messages sent and received by the Portal. This includes Phase-2 SAs from the iSNS client to the iSNS server as well as to peer iFCP and/or iSCSI devices. This attribute contains the SA payload, proposal payload(s), and transform payload(s) in the ISAKMP format defined in [RFC2408].
此字段包含IKE第1阶段建议列表，按优先顺序递减，列出可接受的保护套件，以保护门户发送和接收的所有IKE第2阶段消息。这包括从iSNS客户端到iSNS服务器以及到对等iFCP和/或iSCSI设备的第2阶段SAs。此属性包含[RFC2408]中定义的ISAKMP格式的SA有效负载、提案有效负载和转换有效负载。
This field should be used if the implementer wishes to define phase-1 SA security configuration on a per-Portal basis, as opposed to on a per-Network Entity basis. If the implementer desires to have a single phase-1 SA security configuration to protect all phase-2 traffic regardless of the interface used, then the Entity Phase-1 Proposal (Section 6.2.9) should be used.
如果实施者希望基于每个门户定义阶段1 SA安全配置，而不是基于每个网络实体，则应使用此字段。如果实施者希望有一个单一的阶段1 SA安全配置，以保护所有阶段2流量，而不管所使用的接口如何，则应使用实体阶段1提案（第6.2.9节）。
This field contains the IKE Phase-2 proposal, in ISAKMP format [RFC2408], listing in decreasing order of preference the security proposals acceptable to protect traffic sent and received by the Portal. This field is used only if bits 31, 30, and 29 of the
此字段包含ISAKMP格式[RFC2408]的IKE第2阶段建议，按优先顺序递减列出可接受的安全建议，以保护门户发送和接收的流量。此字段仅在
Security Bitmap (see 6.3.9) are enabled. This attribute contains the SA payload, proposal payload(s), and associated transform payload(s) in the ISAKMP format defined in [RFC2408].
安全位图（见6.3.9）已启用。此属性包含[RFC2408]中定义的ISAKMP格式的SA有效负载、提案有效负载和相关转换有效负载。
This attribute contains one or more X.509 certificates that are a credential of the Portal. This certificate is used to identify and authenticate communications to the IP address and TCP/UDP Port supported by the Portal. The format of the X.509 certificate is specified in [RFC3280]. This certificate MUST contain a Subject Name with an empty sequence and MUST contain a SubjectAltName extension encoded with the iPAddress type. The Portal IP Address (Section 6.3.1) of the identified Portal SHALL be stored in the SubjectAltName field of the certificate.
此属性包含一个或多个X.509证书，这些证书是门户的凭据。此证书用于标识和验证与门户支持的IP地址和TCP/UDP端口的通信。[RFC3280]中规定了X.509证书的格式。此证书必须包含具有空序列的使用者名称，并且必须包含使用iPAddress类型编码的SubjectAltName扩展名。已识别门户的门户IP地址（第6.3.1节）应存储在证书的SubjectAltName字段中。
The following attributes are stored in the iSNS database using the iSCSI Name attribute as the key. Each set of Node-Keyed attributes is associated with one Entity Identifier object key.
以下属性使用iSCSI名称属性作为密钥存储在iSNS数据库中。每组节点键控属性与一个实体标识符对象键相关联。
Although the iSCSI Name key is associated with one Entity Identifier, it is unique across the entire iSNS database.
尽管iSCSI名称密钥与一个实体标识符相关联，但它在整个iSNS数据库中是唯一的。
This is a variable-length UTF-8 encoded NULL-terminated text-based description of up to 224 bytes. This key attribute is required for iSCSI Storage Nodes and is provided by the iSNS client. The registered iSCSI Name MUST conform to the format described in [iSCSI] for iSCSI Names. The maximum size for an iSCSI Name is 223 bytes. Including the NULL character and 4-byte alignment (see Section 5.3.1), the maximum iSCSI Name field size is 224 bytes.
这是一个可变长度UTF-8编码的空终止文本描述，最多224字节。此密钥属性是iSCSI存储节点所必需的，由iSNS客户端提供。注册的iSCSI名称必须符合[iSCSI]中描述的iSCSI名称格式。iSCSI名称的最大大小为223字节。包括空字符和4字节对齐（请参阅第5.3.1节），iSCSI名称字段的最大大小为224字节。
If an iSCSI Name is registered without an EID key, then a Network Entity SHALL be created and an EID assigned. The assigned EID SHALL be returned in the registration response as an operating attribute.
如果注册的iSCSI名称没有EID密钥，则应创建网络实体并分配EID。分配的EID应在注册响应中作为操作属性返回。
This field MUST be normalized according to the stringprep template [STRINGPREP] before it is stored in the iSNS database.
此字段必须根据stringprep模板[stringprep]进行规范化，然后才能存储在iSNS数据库中。
This required 32-bit field is a bitmap indicating the type of iSCSI Storage Node. The bit positions are defined below. A set bit (1) indicates that the Node has the corresponding characteristics.
此必填32位字段是指示iSCSI存储节点类型的位图。位位置定义如下。设定位（1）表示节点具有相应的特征。
Bit Position Node Type
------------ ---------
29 Control
30 Initiator
31 (Lsb) Target
All others RESERVED
Bit Position Node Type
------------ ---------
29 Control
30 Initiator
31 (Lsb) Target
All others RESERVED
If the Target bit is set to 1, then the Node represents an iSCSI target. The Target bit MAY be set by iSNS clients using the iSNSP.
如果目标位设置为1，则节点表示iSCSI目标。目标位可由iSNS客户端使用iSNSP设置。
If the Initiator bit is set to 1, then the Node represents an iSCSI initiator. The Initiator bit MAY be set by iSNS clients using the iSNSP.
如果启动器位设置为1，则节点表示iSCSI启动器。iSNS客户端可以使用iSNSP设置启动器位。
If the control bit is set to 1, then the Node represents a gateway, a management station, a backup iSNS server, or another device that is not an initiator or target, but that requires the ability to send and receive iSNSP messages, including state change notifications. Setting the control bit is an administrative task that MUST be performed on the iSNS server; iSNS clients SHALL NOT be allowed to change this bit using the iSNSP.
如果控制位设置为1，则节点表示网关、管理站、备份iSNS服务器或其他设备，这些设备不是启动器或目标，但需要能够发送和接收iSNSP消息，包括状态更改通知。设置控制位是必须在iSNS服务器上执行的管理任务；不允许iSNS客户端使用iSNSP更改此位。
This field MAY be used by the iSNS server to distinguish among permissions by different iSCSI Node types for accessing various iSNS functions. More than one Node Type bit may be simultaneously enabled.
iSNS服务器可使用此字段区分不同iSCSI节点类型对访问各种iSNS功能的权限。可以同时启用多个节点类型位。
This is a variable-length UTF-8 encoded NULL-terminated text-based description of up to 256 bytes. The Alias is a user-readable description of the Node entry in the iSNS database.
这是一个可变长度UTF-8编码的空终止文本描述，最多256字节。别名是iSNS数据库中节点项的用户可读描述。
The iSCSI Node SCN Bitmap indicates events for which the registering iSNS client wishes to receive a notification message. The following table displays events that result in notifications, and the bit field in the SCN Bitmap that, when enabled, results in the corresponding notification.
iSCSI节点SCN位图指示注册iSNS客户端希望接收通知消息的事件。下表显示了导致通知的事件，以及启用后导致相应通知的SCN位图中的位字段。
Note that this field is of dual use: it is used in the SCN registration process to define interested events that will trigger an SCN message, and it is also contained in each SCN message itself, to indicate the type of event that triggered the SCN message. A set bit (1) indicates the corresponding type of SCN.
请注意，此字段具有双重用途：在SCN注册过程中，它用于定义将触发SCN消息的相关事件，并且还包含在每个SCN消息本身中，以指示触发SCN消息的事件类型。设定位（1）表示相应的SCN类型。
Bit Position Flag Description
------------ ----------------
24 INITIATOR AND SELF INFORMATION ONLY
25 TARGET AND SELF INFORMATION ONLY
26 MANAGEMENT REGISTRATION/SCN
27 OBJECT REMOVED
28 OBJECT ADDED
29 OBJECT UPDATED
30 DD/DDS MEMBER REMOVED (Mgmt Reg/SCN only)
31 (Lsb) DD/DDS MEMBER ADDED (Mgmt Reg/SCN only)
All others RESERVED
Bit Position Flag Description
------------ ----------------
24 INITIATOR AND SELF INFORMATION ONLY
25 TARGET AND SELF INFORMATION ONLY
26 MANAGEMENT REGISTRATION/SCN
27 OBJECT REMOVED
28 OBJECT ADDED
29 OBJECT UPDATED
30 DD/DDS MEMBER REMOVED (Mgmt Reg/SCN only)
31 (Lsb) DD/DDS MEMBER ADDED (Mgmt Reg/SCN only)
All others RESERVED
DD/DDS MEMBER REMOVED indicates that an existing member of a Discovery Domain and/or Discovery Domain Set has been removed.
DD/DDS MEMBER REMOVED表示发现域和/或发现域集的现有成员已被删除。
DD/DDS MEMBER ADDED indicates that a new member was added to an existing DD and/or DDS.
添加DD/DDS成员表示已将新成员添加到现有DD和/或DDS。
OBJECT REMOVED, OBJECT ADDED, and OBJECT UPDATED indicate a Network Entity, Portal, Storage Node, FC Device, DD, and/or DDS object was removed from, added to, or updated in the Discovery Domain or in the iSNS database (Control Nodes only).
对象已删除、对象已添加和对象已更新表示网络实体、门户、存储节点、FC设备、DD和/或DDS对象已从发现域或iSNS数据库中删除、添加或更新（仅限控制节点）。
Regular SCNs provide information about objects that are updated in, added to or removed from Discovery Domains of which the Storage Node is a member. An SCN or SCN registration is considered a regular SCN or regular SCN registration if the MANAGEMENT REGISTRATION/SCN flag is cleared. All iSNS clients may register for regular SCNs.
常规SCN提供有关在存储节点所属的发现域中更新、添加或删除的对象的信息。如果清除管理注册/SCN标志，则SCN或SCN注册被视为常规SCN或常规SCN注册。所有iSNS客户端都可以注册常规SCN。
Management SCNs provide information about all changes to the network, regardless of discovery domain membership. Registration for management SCNs is indicated by setting bit 26 to 1. Only Control Nodes may register for management SCNs. Bits 30 and 31 may only be enabled if bit 26 is set to 1.
管理SCN提供有关网络所有更改的信息，而不考虑发现域成员身份。管理SCN的注册通过将位26设置为1表示。只有控制节点可以注册管理SCN。仅当位26设置为1时，才可启用位30和31。
TARGET AND SELF INFORMATION ONLY SCNs (bit 25) provides information only about changes to target devices, or if the iSCSI Storage Node itself has undergone a change. Similarly, INITIATOR AND SELF INFORMATION ONLY SCNs (bit 24) provides information only about changes to initiator Nodes, or to the target itself.
仅目标和自身信息SCN（位25）仅提供有关目标设备更改的信息，或者如果iSCSI存储节点本身发生了更改，则仅提供这些信息。类似地，仅启动器和自身信息SCN（位24）仅提供有关启动器节点或目标自身更改的信息。
The iSCSI Node Index is a 4-byte non-zero integer value used as a key that uniquely identifies each iSCSI Storage Node registered in the iSNS database. Upon initial registration of the iSCSI Storage Node, the iSNS server assigns an unused value for the iSCSI Node Index. Each iSCSI Node MUST be assigned a value for the iSCSI Node Index that is not assigned to any other iSCSI Storage Node. Furthermore, iSCSI Node Index values for recently deregistered iSCSI Storage Nodes SHOULD NOT be reused in the short term.
iSCSI节点索引是一个4字节非零整数值，用作唯一标识iSNS数据库中注册的每个iSCSI存储节点的密钥。初始注册iSCSI存储节点后，iSNS服务器会为iSCSI节点索引分配一个未使用的值。必须为每个iSCSI节点分配一个未分配给任何其他iSCSI存储节点的iSCSI节点索引值。此外，最近注销的iSCSI存储节点的iSCSI节点索引值短期内不应重复使用。
The iSCSI Node Index may be used as a key to represent a registered Node in situations where the iSCSI Name is too long to be used as a key. An example of this is when SNMP is used for management, as described in Section 2.10.
在iSCSI名称太长而不能用作密钥的情况下，iSCSI节点索引可以用作密钥来表示已注册的节点。如第2.10节所述，使用SNMP进行管理就是一个例子。
The value assigned for the iSCSI Node Index SHALL persist as long as the iSCSI Storage Node is registered in the iSNS database or a member of a Discovery Domain. An iSCSI Node Index value that is assigned for a Storage Node SHALL NOT be used for any other Storage Node as long as the original node is registered in the iSNS database or a member of a Discovery Domain.
只要iSCSI存储节点在iSNS数据库或发现域的成员中注册，为iSCSI节点索引分配的值就应保持不变。为存储节点分配的iSCSI节点索引值不得用于任何其他存储节点，只要原始节点已在iSNS数据库或发现域的成员中注册。
This field contains a globally unique 64-bit integer value that can be used to represent the World Wide Node Name of the iSCSI device in a Fibre Channel fabric. This identifier is used during the device registration process and MUST conform to the requirements in [FC-FS].
此字段包含一个全局唯一的64位整数值，可用于表示光纤通道结构中iSCSI设备的全球节点名。该标识符在设备注册过程中使用，必须符合[FC-FS]中的要求。
The FC-iSCSI gateway uses the value found in this field to register the iSCSI device in the Fibre Channel name server. It is stored in the iSNS server to prevent conflict when "proxy" WWNN values are assigned to iSCSI initiators establishing storage sessions to devices in the FC fabric.
FC iSCSI网关使用此字段中的值在光纤通道名称服务器中注册iSCSI设备。它存储在iSNS服务器中，以防止在将“代理”WWNN值分配给iSCSI启动器时发生冲突，从而为FC结构中的设备建立存储会话。
If the iSNS client does not assign a value for WWNN Token, then the iSNS server SHALL provide a value for this field upon initial registration of the iSCSI Storage Node. The process by which the WWNN Token is assigned by the iSNS server MUST conform to the following requirements:
如果iSNS客户端未为WWNN令牌分配值，则iSNS服务器应在初始注册iSCSI存储节点时为此字段提供值。iSNS服务器分配WWNN令牌的过程必须符合以下要求：
1. The assigned WWNN Token value MUST be unique among all WWN entries in the existing iSNS database, and among all devices that can potentially be registered in the iSNS database.
1. 分配的WWNN令牌值在现有iSNS数据库中的所有WWN条目中，以及在可能在iSNS数据库中注册的所有设备中，必须是唯一的。
2. Once the value is assigned, the iSNS server MUST persistently save the mapping between the WWNN Token value and registered iSCSI Name. That is, successive re-registrations of the iSCSI Storage Node keyed by the same iSCSI Name maintain the original mapping to the associated WWNN Token value in the iSNS server. Similarly, the mapping SHALL be persistent across iSNS server reboots. Once assigned, the mapping can only be changed if a DevAttrReg message from an authorized iSNS client explicitly provides a different WWNN Token value.
2. 分配该值后，iSNS服务器必须持续保存WWNN令牌值和注册的iSCSI名称之间的映射。也就是说，由相同iSCSI名称键入的iSCSI存储节点的连续重新注册将保持到iSNS服务器中关联WWNN令牌值的原始映射。同样，映射应在iSNS服务器重新启动时保持不变。分配后，仅当来自授权iSNS客户端的DevAttrReg消息明确提供不同的WWNN令牌值时，才能更改映射。
3. Once a WWNN Token value has been assigned and mapped to an iSCSI name, that WWNN Token value SHALL NOT be reused or mapped to any other iSCSI name.
3. 一旦WWNN令牌值已分配并映射到iSCSI名称，则该WWNN令牌值不得重复使用或映射到任何其他iSCSI名称。
4. The assigned WWNN Token value MUST conform to the formatting requirements of [FC-FS] for World Wide Names (WWNs).
4. 分配的WWNN令牌值必须符合[FC-FS]对全球通用名称（WWN）的格式要求。
An iSNS client, such as an FC-iSCSI gateway or the iSCSI initiator, MAY register its own WWNN Token value or overwrite the iSNS Server-supplied WWNN Token value, if it wishes to supply its own iSCSI-FC name mapping. This is accomplished using the DevAttrReg message with the WWNN Token (tag=37) as an operating attribute. Once overwritten, the new WWNN Token value MUST be stored and saved by the iSNS server, and all requirements specified above continue to apply. If an iSNS client attempts to register a value for this field that is not unique in the iSNS database or that is otherwise invalid, then the registration SHALL be rejected with an Status Code of 3 (Invalid Registration).
如果iSNS客户端（如FC iSCSI网关或iSCSI启动器）希望提供自己的iSCSI FC名称映射，则可以注册自己的WWNN令牌值或覆盖iSNS服务器提供的WWNN令牌值。这是通过使用带有WWNN令牌（tag=37）的DevAttrReg消息作为操作属性来实现的。一旦被覆盖，iSNS服务器必须存储和保存新的WWNN令牌值，并且上面指定的所有要求继续适用。如果iSNS客户端试图为该字段注册一个在iSNS数据库中不唯一或无效的值，则注册将被拒绝，状态代码为3（无效注册）。
There MAY be matching records in the iSNS database for the Fibre Channel device specified by the WWNN Token. These records may contain device attributes for that FC device registered in the Fibre Channel fabric name server.
iSNS数据库中可能存在WWNN令牌指定的光纤通道设备的匹配记录。这些记录可能包含在光纤通道结构名称服务器中注册的FC设备的设备属性。
This is a virtual attribute containing a 4-byte integer value that indicates the next available (i.e., unused) iSCSI Node Index value. This attribute may only be queried; the iSNS server SHALL return an error code of 3 (Invalid Registration) to any client that attempts to register a value for this attribute. A Message Key is not required when exclusively querying for this attribute.
这是一个虚拟属性，包含一个4字节整数值，指示下一个可用（即未使用）iSCSI节点索引值。只能查询该属性；iSNS服务器应向尝试注册此属性值的任何客户端返回错误代码3（无效注册）。独占查询此属性时不需要消息键。
The iSCSI Node Next Index MAY be used by an SNMP client to create an entry in the iSNS server. SNMP requirements are described in Section 2.10.
SNMP客户端可以使用iSCSI节点下一个索引在iSNS服务器中创建条目。SNMP要求见第2.10节。
This attribute contains a NULL-terminated string of UTF-8 text listing the iSCSI authentication methods enabled for this iSCSI Storage Node, in order of preference. The text values used to identify iSCSI authentication methods are embedded in this string attribute and delineated by a comma. The text values are identical to those found in the main iSCSI document [iSCSI]; additional vendor-specific text values are also possible.
此属性包含一个以NULL结尾的UTF-8文本字符串，按优先顺序列出为此iSCSI存储节点启用的iSCSI身份验证方法。用于标识iSCSI身份验证方法的文本值嵌入到此字符串属性中，并用逗号表示。文本值与iSCSI主文档[iSCSI]中的文本值相同；也可以使用其他特定于供应商的文本值。
Text Value Description Reference
---------- ----------- ---------
KB5 Kerberos V5 [RFC1510]
SPKM1 Simple Public Key GSS-API [RFC2025]
SPKM2 Simple Public Key GSS-API [RFC2025]
SRP Secure Remote Password [RFC2945]
CHAP Challenge Handshake Protocol [RFC1994]
none No iSCSI Authentication
Text Value Description Reference
---------- ----------- ---------
KB5 Kerberos V5 [RFC1510]
SPKM1 Simple Public Key GSS-API [RFC2025]
SPKM2 Simple Public Key GSS-API [RFC2025]
SRP Secure Remote Password [RFC2945]
CHAP Challenge Handshake Protocol [RFC1994]
none No iSCSI Authentication
The following attributes are used to associate Portal and iSCSI Storage Node objects. PG objects are stored in the iSNS database using the PG iSCSI Name, the PG Portal IP Address, and the PG Portal TCP/UDP Port as keys. New PG objects are implicitly or explicitly created at the time that the corresponding Portal and/or iSCSI Storage Node objects are registered. Section 3.4 has a general discussion of PG usage. For further details on use of Portal Groups, see [iSCSI].
以下属性用于关联门户和iSCSI存储节点对象。PG对象使用PG iSCSI名称、PG Portal IP地址和PG Portal TCP/UDP端口作为密钥存储在iSNS数据库中。在注册相应的门户和/或iSCSI存储节点对象时，隐式或显式创建新的PG对象。第3.4节对PG的使用进行了一般性讨论。有关使用门户组的更多详细信息，请参阅[iSCSI]。
This is the iSCSI Name for the iSCSI Storage Node that is associated with the PG object. This name MAY represent an iSCSI Storage Node not currently registered in the server.
这是与PG对象关联的iSCSI存储节点的iSCSI名称。此名称可能表示当前未在服务器中注册的iSCSI存储节点。
This is the Portal IP Address attribute for the Portal that is associated with the PG object. This Portal IP Address MAY be that of a Portal that is not currently registered in the server.
这是与PG对象关联的门户的门户IP地址属性。此门户IP地址可能是当前未在服务器中注册的门户的IP地址。
This is the Portal TCP/UDP Port attribute for the Portal that is associated with the PG object. This Portal TCP/UDP Port MAY be that of a Portal that is not currently registered in the server.
这是与PG对象关联的门户的门户TCP/UDP端口属性。此门户TCP/UDP端口可能是当前未在服务器中注册的门户的TCP/UDP端口。
This field is used to group Portals in order to coordinate connections in a session across Portals to a specified iSCSI Node. The PGT is a value in the range of 0-65535, or NULL. A NULL PGT value is registered by using 0 for the length in the TLV during registration. The two least significant bytes of the value contain the PGT for the object. The two most significant bytes are reserved. If a PGT value is not explicitly registered for an iSCSI Storage Node and Portal pair, then the PGT value SHALL be implicitly registered as 0x00000001.
此字段用于对门户进行分组，以便协调会话中跨门户到指定iSCSI节点的连接。PGT是0-65535或NULL范围内的值。在注册期间，使用0作为TLV中的长度来注册空PGT值。值的两个最低有效字节包含对象的PGT。保留两个最重要的字节。如果未为iSCSI存储节点和入口对显式注册PGT值，则PGT值应隐式注册为0x00000001。
The PG Index is a 4-byte non-zero integer value used as a key that uniquely identifies each PG object registered in the iSNS database. Upon initial registration of a PG object, the iSNS server MUST assign an unused value for the PG Index. Furthermore, PG Index values for recently deregistered PG objects SHOULD NOT be reused in the short term.
PG索引是一个4字节非零整数值，用作唯一标识iSNS数据库中注册的每个PG对象的键。初始注册PG对象后，iSNS服务器必须为PG索引分配一个未使用的值。此外，近期注销的PG对象的PG索引值短期内不应重复使用。
The PG Index MAY be used as the key to reference a registered PG in situations where a unique index for each PG object is required. It MAY also be used as the message key in an iSNS message to query or update a pre-existing PG object. An example of this is when SNMP is used for management, as described in Section 2.10. The value assigned for the PG Index SHALL persist as long as the server is active.
在需要每个PG对象的唯一索引的情况下，PG索引可用作引用已注册PG的键。它也可以用作iSNS消息中的消息键，以查询或更新预先存在的PG对象。如第2.10节所述，使用SNMP进行管理就是一个例子。只要服务器处于活动状态，为PG索引分配的值应保持不变。
The PG Next Index is a virtual attribute containing a 4-byte integer value that indicates the next available (i.e., unused) PG Index value. This attribute may only be queried; the iSNS server SHALL return an error code of 3 (Invalid Registration) to any client that attempts to register a value for this attribute. A Message Key is not required when exclusively querying for this attribute.
PG Next Index是一个虚拟属性，包含一个4字节整数值，该整数值表示下一个可用（即未使用）PG Index值。只能查询该属性；iSNS服务器应向尝试注册此属性值的任何客户端返回错误代码3（无效注册）。独占查询此属性时不需要消息键。
The Portal Group Next Index MAY be used by an SNMP client to create an entry in the iSNS server. SNMP requirements are described in Section 2.10.
SNMP客户端可以使用门户组下一个索引在iSNS服务器中创建条目。SNMP要求见第2.10节。
The following attributes are registered in the iSNS database using the FC Port World Wide Name (WWPN) attribute as the key. Each set of FC Port-Keyed attributes is associated with one Entity Identifier object key.
以下属性使用FC端口全球通用名称（WWPN）属性作为密钥在iSNS数据库中注册。每组FC端口键控属性与一个实体标识符对象键相关联。
Although the FC Port World Wide Name is associated with one Entity Identifier, it is also globally unique.
尽管FC端口全球通用名称与一个实体标识符关联，但它也是全局唯一的。
This 64-bit identifier uniquely defines the FC Port, and it is the World Wide Port Name (WWPN) of the corresponding Fibre Channel device. This attribute is the key for the iFCP Storage Node. This globally unique identifier is used during the device registration process, and it uses a value conforming to IEEE EUI-64 [EUI-64].
此64位标识符唯一定义FC端口，它是相应光纤通道设备的全球通用端口名（WWPN）。此属性是iFCP存储节点的键。该全局唯一标识符在设备注册过程中使用，并使用符合IEEE EUI-64[EUI-64]的值。
The Port Identifier is a Fibre Channel address identifier assigned to an N_Port or NL_Port during fabric login. The format of the Port Identifier is defined in [FC-FS]. The least significant 3 bytes contain this address identifier. The most significant byte is RESERVED.
端口标识符是在结构登录期间分配给N_端口或NL_端口的光纤通道地址标识符。端口标识符的格式在[FC-FS]中定义。最低有效3字节包含此地址标识符。保留最高有效字节。
Indicates the type of FC port. Encoded values for this field are listed in the following table:
指示FC端口的类型。下表列出了此字段的编码值：
Type Description
---- -----------
0x0000 Unidentified/Null Entry
0x0001 Fibre Channel N_Port
0x0002 Fibre Channel NL_Port
0x0003 Fibre Channel F/NL_Port
0x0004-0080 RESERVED
0x0081 Fibre Channel F_Port
0x0082 Fibre Channel FL_Port
0x0083 RESERVED
0x0084 Fibre Channel E_Port
0x0085-00FF RESERVED
0xFF11 RESERVED
0xFF12 iFCP Port
0xFF13-FFFF RESERVED
Type Description
---- -----------
0x0000 Unidentified/Null Entry
0x0001 Fibre Channel N_Port
0x0002 Fibre Channel NL_Port
0x0003 Fibre Channel F/NL_Port
0x0004-0080 RESERVED
0x0081 Fibre Channel F_Port
0x0082 Fibre Channel FL_Port
0x0083 RESERVED
0x0084 Fibre Channel E_Port
0x0085-00FF RESERVED
0xFF11 RESERVED
0xFF12 iFCP Port
0xFF13-FFFF RESERVED
This is a variable-length UTF-8 encoded NULL-terminated text-based description of up to 256 bytes that is associated with the iSNS-registered FC Port Name in the network.
这是一个可变长度UTF-8编码的空终止文本描述，最多256字节，与网络中iSNS注册的FC端口名关联。
This 64-bit identifier uniquely defines the fabric port. If the port of the FC Device is attached to a Fibre Channel fabric port with a registered Port Name, then that fabric Port Name SHALL be indicated in this field.
此64位标识符唯一地定义结构端口。如果FC设备的端口连接到具有注册端口名的光纤通道结构端口，则该结构端口名应在该字段中指示。
This field is the requested hard address 24-bit NL Port Identifier, included in the iSNSP for compatibility with Fibre Channel Arbitrated Loop devices and topologies. The least significant 3 bytes of this field contain the address. The most significant byte is RESERVED.
此字段是请求的硬地址24位NL端口标识符，包含在iSNSP中，以与光纤通道仲裁环路设备和拓扑兼容。此字段的最低有效3字节包含地址。保留最高有效字节。
The Fibre Channel IP address associated with the FC Port. When this field contains an IPv4 value, it is stored as an IPv4-mapped IPv6 address. That is, the most significant 10 bytes are set to 0x00, with the next two bytes set to 0xFFFF [RFC2373]. When an IPv6 value is contained in this field, then the entire 16-byte field is used.
与FC端口关联的光纤通道IP地址。当此字段包含IPv4值时，它将存储为IPv4映射的IPv6地址。也就是说，最重要的10个字节设置为0x00，接下来的两个字节设置为0xFFFF[RFC2373]。如果此字段中包含IPv6值，则使用整个16字节字段。
This 32-bit bit-map field indicates the Fibre Channel Class of Service types that are supported by the registered port. In the following table, a set bit (1) indicates a Class of Service supported.
此32位映射字段表示注册端口支持的光纤通道服务类型类别。在下表中，设置位（1）表示支持的服务类别。
Bit Position Description
------------ -----------
29 Fibre Channel Class 2 Supported
28 Fibre Channel Class 3 Supported
Bit Position Description
------------ -----------
29 Fibre Channel Class 2 Supported
28 Fibre Channel Class 3 Supported
This 32-byte field indicates the FC-4 protocol types supported by the associated port. This field can be used to support Fibre Channel devices and is consistent with FC-GS-4.
此32字节字段表示相关端口支持的FC-4协议类型。此字段可用于支持光纤通道设备，并与FC-GS-4一致。
This is a variable-length UTF-8 encoded NULL-terminated text-based description of up to 256 bytes that is associated with the iSNS-registered device port in the network. This field can be used to support Fibre Channel devices and is consistent with FC-GS-4.
这是一个可变长度UTF-8编码的空终止文本描述，最多256字节，与网络中iSNS注册的设备端口关联。此字段可用于支持光纤通道设备，并与FC-GS-4一致。
This is a 128-byte array, 4 bits per type, for the FC-4 protocol types supported by the associated port. This field can be used to support Fibre Channel devices and is consistent with FC-GS-4.
这是一个128字节数组，每种类型4位，用于相关端口支持的FC-4协议类型。此字段可用于支持光纤通道设备，并与FC-GS-4一致。
This field indicates the events the iSNS client is interested in. These events can cause SCNs to be generated. SCNs provide information about objects that are updated in, added to or removed from Discovery Domains of which the source and destination are a member. Management SCNs provide information about all changes to the network. A set bit (1) indicates the type of SCN for the bitmap as follows:
此字段表示iSNS客户端感兴趣的事件。这些事件可能导致生成SCN。SCN提供有关在源和目标都是其成员的发现域中更新、添加或删除的对象的信息。管理SCN提供有关网络所有更改的信息。设置位（1）表示位图的SCN类型，如下所示：
Bit Position Flag Description
------------ ----------------
24 INITIATOR AND SELF INFORMATION ONLY
25 TARGET AND SELF INFORMATION ONLY
26 MANAGEMENT REGISTRATION/SCN
27 OBJECT REMOVED
28 OBJECT ADDED
29 OBJECT UPDATED
30 DD/DDS MEMBER REMOVED (Mgmt Reg/SCN only)
31 (Lsb) DD/DDS MEMBER ADDED (Mgmt Reg/SCN only)
All others RESERVED
Bit Position Flag Description
------------ ----------------
24 INITIATOR AND SELF INFORMATION ONLY
25 TARGET AND SELF INFORMATION ONLY
26 MANAGEMENT REGISTRATION/SCN
27 OBJECT REMOVED
28 OBJECT ADDED
29 OBJECT UPDATED
30 DD/DDS MEMBER REMOVED (Mgmt Reg/SCN only)
31 (Lsb) DD/DDS MEMBER ADDED (Mgmt Reg/SCN only)
All others RESERVED
Further information on the use of the bit positions specified above can be found in Section 6.4.4.
有关使用上述位位置的更多信息，请参见第6.4.4节。
This required 32-bit field is a bitmap indicating the type of iFCP Storage Node. The bit fields are defined below. A set bit indicates the Node has the corresponding characteristics.
此必需的32位字段是指示iFCP存储节点类型的位图。位字段定义如下。设定位表示节点具有相应的特征。
Bit Position Node Type
------------ ---------
29 Control
30 FCP Initiator
31 (Lsb) FCP Target
All Others RESERVED
Bit Position Node Type
------------ ---------
29 Control
30 FCP Initiator
31 (Lsb) FCP Target
All Others RESERVED
If the 'Target' bit is set to 1, then the port represents an FC target. Setting of the 'Target' bit MAY be performed by iSNS clients using the iSNSP.
如果“目标”位设置为1，则端口表示FC目标。“目标”位的设置可由iSNS客户端使用iSNSP执行。
If the 'Initiator' bit is set to 1, then the port represents an FC initiator. Setting of the 'Initiator' bit MAY be performed by iSNS clients using the iSNSP.
如果“启动器”位设置为1，则端口表示FC启动器。“启动器”位的设置可由iSNS客户端使用iSNSP执行。
If the 'Control' bit is set to 1, then the port represents a gateway, a management station, an iSNS backup server, or another device.
如果“控制”位设置为1，则端口表示网关、管理站、iSNS备份服务器或其他设备。
This is usually a special device that is neither an initiator nor a target, which requires the ability to send and receive iSNSP messages, including state-change notifications. Setting the control bit is an administrative task that MUST be administratively configured on the iSNS server; iSNS clients SHALL NOT be allowed to change this bit using the iSNSP.
这通常是一种既不是启动器也不是目标的特殊设备，需要能够发送和接收iSNSP消息，包括状态更改通知。设置控制位是一项管理任务，必须在iSNS服务器上进行管理配置；不允许iSNS客户端使用iSNSP更改此位。
This field MAY be used by the iSNS server to distinguish among permissions by different iSNS clients. For example, an iSNS server implementation may be administratively configured to allow only targets to receive ESIs, or to permit only Control Nodes to add, modify, or delete discovery domains.
iSNS服务器可以使用此字段来区分不同iSNS客户端的权限。例如，iSNS服务器实现可以在管理上配置为仅允许目标接收ESI，或仅允许控制节点添加、修改或删除发现域。
The Permanent Port Name can be used to support Fibre Channel devices and is consistent with the PPN description in FC-GS-4 [FC-GS-4]. The format of the PPN is identical to the FC Port Name WWPN attribute format.
永久端口名可用于支持光纤通道设备，并与FC-GS-4[FC-GS-4]中的PPN描述一致。PPN的格式与FC端口名WWPN属性格式相同。
The following attributes are registered in the iSNS database using the FC Node Name (WWNN) attribute as the key. Each set of FC Node-Keyed attributes represents a single device and can be associated with many FC Ports.
使用FC节点名称（WWNN）属性作为密钥在iSNS数据库中注册以下属性。每组FC节点键控属性表示单个设备，可以与多个FC端口关联。
The FC Node Name is unique across the entire iSNS database.
FC节点名称在整个iSNS数据库中是唯一的。
The FC Node Name is a 64-bit identifier that is the World Wide Node Name (WWNN) of the corresponding Fibre Channel device. This attribute is the key for the FC Device. This globally unique identifier is used during the device registration process, and it uses a value conforming to IEEE EUI-64 [EUI-64].
FC节点名称是一个64位标识符，它是相应光纤通道设备的全球节点名称（WWNN）。此属性是FC设备的密钥。该全局唯一标识符在设备注册过程中使用，并使用符合IEEE EUI-64[EUI-64]的值。
This is a variable-length UTF-8 encoded NULL-terminated text-based description of up to 256 bytes that is associated with the iSNS-registered FC Device in the network.
这是一个可变长度UTF-8编码的空终止文本描述，最多256字节，与网络中的iSNS注册FC设备关联。
This IP address is associated with the device Node in the network. This field is included for compatibility with Fibre Channel. When this field contains an IPv4 value, it is stored as an IPv4-mapped IPv6 address. That is, the most significant 10 bytes are set to 0x00, with the next two bytes set to 0xFFFF [RFC2373]. When an IPv6 value is contained in this field, the entire 16-byte field is used.
此IP地址与网络中的设备节点相关联。包含此字段是为了与光纤通道兼容。当此字段包含IPv4值时，它将存储为IPv4映射的IPv6地址。也就是说，最重要的10个字节设置为0x00，接下来的两个字节设置为0xFFFF[RFC2373]。当此字段中包含IPv6值时，将使用整个16字节字段。
This field is the 8-byte Fibre Channel Initial Process Associator (IPA) associated with the device Node in the network. The initial process associator is used for communication between Fibre Channel devices.
此字段是与网络中的设备节点关联的8字节光纤通道初始进程关联器（IPA）。初始进程关联器用于光纤通道设备之间的通信。
This is a variable-length UTF-8 encoded NULL-terminated text-based field that contains the iSCSI Name used to represent the FC Node in the IP network. It is used as a pointer to the matching iSCSI Name entry in the iSNS server. Its value is usually registered by an FC-iSCSI gateway connecting the IP network to the fabric containing the FC device.
这是一个长度可变的UTF-8编码的空终止文本字段，包含用于表示IP网络中FC节点的iSCSI名称。它用作指向iSNS服务器中匹配的iSCSI名称条目的指针。其值通常由将IP网络连接到包含FC设备的结构的FC iSCSI网关注册。
Note that if this field is used, there SHOULD be a matching entry in the iSNS database for the iSCSI device specified by the iSCSI name. The database entry should include the full range of iSCSI attributes needed for discovery and management of the "iSCSI proxy image" of the FC device.
请注意，如果使用此字段，则iSNS数据库中应存在由iSCSI名称指定的iSCSI设备的匹配条目。数据库条目应包括查找和管理FC设备的“iSCSI代理映像”所需的全部iSCSI属性。
The following are not attributes of the previously-defined objects.
以下不是以前定义的对象的属性。
This is a 4-byte field used to provide a FC-4 type during a FC-4 Type query. The FC-4 types are consistent with the FC-4 Types as defined in FC-FS. Byte 0 contains the FC-4 type. All other bytes are reserved.
这是一个4字节字段，用于在FC-4类型查询期间提供FC-4类型。FC-4类型与FC-FS中定义的FC-4类型一致。字节0包含FC-4类型。所有其他字节均保留。
The iFCP Switch Name is a 64-bit World Wide Name (WWN) identifier that uniquely identifies a distinct iFCP gateway in the network. This globally unique identifier is used during the switch registration/FC_DOMAIN_ID assignment process. The iFCP Switch Name value used MUST conform to the requirements stated in [FC-FS] for World Wide Names. The iSNS server SHALL track the state of all FC_DOMAIN_ID values that have been allocated to each iFCP Switch Name. If a given iFCP Switch Name is deregistered from the iSNS database, then all FC_DOMAIN_ID values allocated to that iFCP Switch Name SHALL be returned to the unused pool of values.
iFCP交换机名称是一个64位全球通用名称（WWN）标识符，用于唯一标识网络中不同的iFCP网关。此全局唯一标识符在交换机注册/FC_域\u ID分配过程中使用。使用的iFCP开关名称值必须符合[FC-FS]中规定的全球通用名称要求。iSNS服务器应跟踪分配给每个iFCP交换机名称的所有FC_域_ID值的状态。如果从iSNS数据库中注销了给定的iFCP交换机名称，则分配给该iFCP交换机名称的所有FC_DOMAIN_ID值应返回到未使用的值池。
This is a 4-byte unsigned integer field, and it is the requested value that the iSNS client wishes to use for the FC_DOMAIN_ID. The iSNS server SHALL grant the iSNS client the use of the requested value as the FC_DOMAIN_ID, if the requested value has not already been allocated. If the requested value is not available, the iSNS server SHALL return a different value that has not been allocated.
这是一个4字节无符号整数字段，是iSNS客户端希望用于FC_域_ID的请求值。如果请求值尚未分配，iSNS服务器应授予iSNS客户端将请求值用作FC_域_ID的权限。如果请求的值不可用，iSNS服务器应返回未分配的其他值。
This is a 4-byte unsigned integer field that is used by an iFCP gateway to reserve its own unique FC_DOMAIN_ID value from the range 1 to 239. When a FC_DOMAIN_ID is no longer required, it SHALL be released by the iFCP gateway using the RlseDomId message. The iSNS server MUST use the Entity Status Inquiry message to determine whether an iFCP gateway is still present on the network.
这是一个4字节无符号整数字段，iFCP网关使用该字段保留其自己的唯一FC_域_ID值，范围为1到239。当不再需要FC_域_ID时，iFCP网关应使用RlseDomId消息将其释放。iSNS服务器必须使用实体状态查询消息来确定网络上是否仍存在iFCP网关。
This is a variable-length UTF-8 encoded NULL-terminated text-based field of up to 256 bytes. The Virtual_Fabric_ID string is used as a key attribute to identify a range of non-overlapping FC_DOMAIN_ID values to be allocated using RqstDomId. Each Virtual_Fabric_ID string submitted by an iSNS client SHALL have its own range of non-overlapping FC_DOMAIN_ID values to be allocated to iSNS clients.
这是一个长度可变的UTF-8编码的空终止文本字段，最多256字节。Virtual_Fabric_ID字符串用作键属性，用于标识要使用RqstDomId分配的一系列不重叠的FC_DOMAIN_ID值。iSNS客户端提交的每个虚拟\u结构\u ID字符串应具有自己的非重叠FC\u域\u ID值范围，以分配给iSNS客户端。
Access to the following attributes may be administratively controlled. These attributes are specific to the iSNS server instance; the same value is returned for all iSNS clients accessing the iSNS server. Only query messages may be performed on these attributes. Attempted registrations of values for these attributes SHALL return a status code of 3 (Invalid Registration).
对以下属性的访问可能受到管理控制。这些属性特定于iSNS服务器实例；对于访问iSNS服务器的所有iSNS客户端，返回相同的值。只能对这些属性执行查询消息。尝试注册这些属性的值将返回状态代码3（无效注册）。
A query for an iSNS Server-Specific attribute MUST contain the identifying key attribute (i.e., iSCSI Name or FC Port Name WWPN) of the Node originating the registration or query message as the Source and Message Key attributes. The Operating Attributes are the server-specific attributes being registered or queried.
对iSNS服务器特定属性的查询必须包含发起注册或查询消息的节点的标识密钥属性（即iSCSI名称或FC端口名称WWPN）作为源和消息密钥属性。操作属性是正在注册或查询的服务器特定属性。
This attribute is the OUI (Organizationally Unique Identifier) [802-1990] identifying the specific vendor implementing the iSNS server. This attribute can only be queried; iSNS clients SHALL NOT be allowed to register a value for the iSNS Server Vendor OUI.
此属性是用于标识实现iSNS服务器的特定供应商的OUI（组织唯一标识符）[802-1990]。该属性只能查询；不允许iSNS客户端为iSNS服务器供应商OUI注册值。
iSNS server implementations MAY define vendor-specific attributes for private use. These attributes MAY be used to store optional data that is registered and/or queried by iSNS clients in order to gain optional capabilities. Note that any implementation of vendor-specific attributes in the iSNS server SHALL NOT impose any form of mandatory behavior on the part of the iSNS client.
iSNS服务器实施可能会定义供私人使用的特定于供应商的属性。这些属性可用于存储iSNS客户端注册和/或查询的可选数据，以获得可选功能。请注意，iSNS服务器中供应商特定属性的任何实现均不得对iSNS客户端施加任何形式的强制行为。
The tag values used for vendor-specific and user-specific use are defined in Section 6.1. To avoid misinterpreting proprietary attributes, the vendor's own OUI (Organizationally Unique Identifier) MUST be placed in the upper three bytes of the attribute value field itself.
第6.1节定义了用于供应商特定用途和用户特定用途的标签值。为了避免误解专有属性，供应商自己的OUI（组织唯一标识符）必须放在属性值字段本身的上三个字节中。
The OUI is defined in IEEE Std 802-1990 and is the same constant used to generate 48 bit Universal LAN MAC addresses. A vendor's own iSNS implementation will then be able to recognize the OUI in the attribute field and be able to execute vendor-specific handling of the attribute.
OUI在IEEE Std 802-1990中定义，是用于生成48位通用LAN MAC地址的相同常数。然后，供应商自己的iSNS实现将能够识别属性字段中的OUI，并能够执行特定于供应商的属性处理。
Attributes with tags in the range 257 to 384 are vendor-specific or site-specific attributes of the iSNS server. Values for these attributes are administratively set by the specific vendor providing the iSNS server implementation. Query access to these attributes may be administratively controlled. These attributes are unique for each logical iSNS server instance. Query messages for these attributes SHALL use the key identifier (i.e., iSCSI Name or FC Port Name WWPN) for both the Source attribute and Message Key attribute. These attributes can only be queried; iSNS clients SHALL NOT be allowed to register a value for server attributes.
标记范围在257到384之间的属性是iSNS服务器的特定于供应商或特定于站点的属性。这些属性的值由提供iSNS服务器实现的特定供应商进行管理设置。对这些属性的查询访问可能受到管理控制。这些属性对于每个逻辑iSNS服务器实例都是唯一的。这些属性的查询消息应使用源属性和消息密钥属性的密钥标识符（即iSCSI名称或FC端口名称WWPN）。这些属性只能查询；不允许iSNS客户端为服务器属性注册值。
Attributes in the range 385 to 512 are vendor-specific or site-specific attributes used to describe the Network Entity object. These attributes are keyed by the Entity Identifier attribute (tag=1).
385到512范围内的属性是用于描述网络实体对象的特定于供应商或特定于站点的属性。这些属性由实体标识符属性（标记=1）设置关键帧。
Attributes in the range 513 to 640 are vendor-specific or site-specific attributes used to describe the Portal object. These attributes are keyed by the Portal IP-Address (tag=16) and Portal TCP/UDP Port (tag=17).
513到640范围内的属性是用于描述门户对象的特定于供应商或特定于站点的属性。这些属性由门户IP地址（标记=16）和门户TCP/UDP端口（标记=17）设置密钥。
Attributes in the range 641 to 768 are vendor-specific or site-specific attributes used to describe the iSCSI Node object. These attributes are keyed by the iSCSI Name (tag=32).
641到768范围内的属性是用于描述iSCSI节点对象的特定于供应商或特定于站点的属性。这些属性由iSCSI名称（标记=32）设置密钥。
Attributes in the range 769 to 896 are vendor-specific or site-specific attributes used to describe the N_Port Port Name object. These attributes are keyed by the FC Port Name WWPN (tag=64).
范围769到896中的属性是特定于供应商或特定于站点的属性，用于描述N_Port Name对象。这些属性由FC端口名WWPN（标记=64）设置关键帧。
Attributes in the range 897 to 1024 are vendor-specific or site-specific attributes used to describe the FC Node Name object. These attributes are keyed by the FC Node Name WWNN (tag=96).
897到1024范围内的属性是特定于供应商或特定于站点的属性，用于描述FC节点名称对象。这些属性由FC节点名称WWNN（标记=96）设置关键帧。
Attributes in the range 1025 to 1280 are vendor-specific or site-specific attributes used to describe the Discovery Domain object. These attributes are keyed by the DD_ID (tag=104).
1025到1280范围内的属性是特定于供应商或特定于站点的属性，用于描述发现域对象。这些属性由DD_ID（tag=104）设置关键帧。
Attributes in the range 1281 to 1536 are vendor-specific or site-specific attributes used to describe the Discovery Domain Set object. These attributes are keyed by the DD Set ID (tag=101)
1281到1536范围内的属性是特定于供应商或特定于站点的属性，用于描述发现域集对象。这些属性由DD集合ID（标记=101）设置关键帧
Attributes in the range 1537 to 2048 can be used for key and non-key attributes that describe new vendor-specific objects specific to the vendor's iSNS server implementation.
1537到2048范围内的属性可用于描述特定于供应商iSNS服务器实现的新供应商特定对象的关键属性和非关键属性。
The DDS ID is an unsigned non-zero integer identifier used in the iSNS directory database as a key to indicate a Discovery Domain Set uniquely. A DDS is a collection of Discovery Domains that can be enabled or disabled by a management station. This value is used as a key for DDS attribute queries. When a Discovery Domain is registered, it is initially not in any DDS.
DDS ID是一个无符号非零整数标识符，在iSNS目录数据库中用作唯一指示发现域集的键。DDS是可由管理站启用或禁用的发现域的集合。此值用作DDS属性查询的键。注册发现域时，它最初不在任何DDS中。
If the iSNS client does not provide a DDS_ID in a DDS registration request message, the iSNS server SHALL generate a DDS_ID value that is unique within the iSNS database for that new DDS. The created DDS ID SHALL be returned in the response message. The DDS ID value of 0 is reserved, and the DDS ID value of 1 is used for the default DDS (see Section 2.2.2).
如果iSNS客户端未在DDS注册请求消息中提供DDS_ID，iSNS服务器应为该新DDS生成一个在iSNS数据库中唯一的DDS_ID值。创建的DDS ID应在响应消息中返回。保留DDS ID值0，默认DDS使用DDS ID值1（参见第2.2.2节）。
A variable-length UTF-8 encoded NULL-terminated text-based field of up to 256 bytes. This is a user-readable field used to assist a network administrator in tracking the DDS function. When a client registers a DDS symbolic name, the iSNS server SHALL verify it is unique. If the name is not unique, then the DDS registration SHALL be rejected with an "Invalid Registration" Status Code. The invalid attribute(s), in this case the DDS symbolic name, SHALL be included in the response.
一个可变长度UTF-8编码的空终止文本字段，最多256字节。这是一个用户可读字段，用于协助网络管理员跟踪DDS功能。当客户端注册DDS符号名时，iSNS服务器应验证其唯一性。如果名称不唯一，则DDS注册将被拒绝，状态代码为“无效注册”。无效属性（在这种情况下为DDS符号名）应包含在响应中。
The DDS_Status field is a 32-bit bitmap indicating the status of the DDS. Bit 0 of the bitmap indicates whether the DDS is Enabled (1) or Disabled (0). The default value for the DDS Enabled flag is Disabled (0).
DDS_状态字段是一个32位位图，指示DDS的状态。位图的位0表示DDS是启用（1）还是禁用（0）。DDS启用标志的默认值为禁用（0）。
Bit Position DDS Status
------------ ---------
31 (Lsb) DDS Enabled (1) / DDS Disabled (0)
All others RESERVED
Bit Position DDS Status
------------ ---------
31 (Lsb) DDS Enabled (1) / DDS Disabled (0)
All others RESERVED
This is a virtual attribute containing a 4-byte integer value that indicates the next available (i.e., unused) Discovery Domain Set Index value. This attribute may only be queried; the iSNS server
这是一个虚拟属性，包含一个4字节整数值，指示下一个可用（即未使用）的发现域集索引值。只能查询该属性；iSNS服务器
SHALL return an error code of 3 (Invalid Registration) to any client that attempts to register a value for this attribute. A Message Key is not required when exclusively querying for this attribute.
应向尝试注册此属性值的任何客户端返回错误代码3（无效注册）。独占查询此属性时不需要消息键。
The Discovery Domain Set Next Index MAY be used by an SNMP client to create an entry in the iSNS server. SNMP requirements are described in Section 2.10.
SNMP客户端可以使用发现域集下一个索引在iSNS服务器中创建条目。SNMP要求见第2.10节。
The DD ID is an unsigned non-zero integer identifier used in the iSNS directory database as a key to identify a Discovery Domain uniquely. This value is used as the key for any DD attribute query. If the iSNS client does not provide a DD_ID in a DD registration request message, the iSNS server SHALL generate a DD_ID value that is unique within the iSNS database for that new DD (i.e., the iSNS client will be registered in a new DD). The created DD ID SHALL be returned in the response message. The DD ID value of 0 is reserved, and the DD ID value of 1 is used for the default DD (see Section 2.2.2).
DD ID是一个无符号非零整数标识符，在iSNS目录数据库中用作唯一标识发现域的密钥。此值用作任何DD属性查询的键。如果iSNS客户端未在DD注册请求消息中提供DD_ID，iSNS服务器应为该新DD生成在iSNS数据库中唯一的DD_ID值（即，iSNS客户端将在新DD中注册）。创建的DD ID应在响应消息中返回。保留DD ID值0，默认DD使用DD ID值1（见第2.2.2节）。
A variable-length UTF-8 encoded NULL-terminated text-based field of up to 256 bytes. When a client registers a DD symbolic name, the iSNS server SHALL verify it is unique. If the name is not unique, then the DD registration SHALL be rejected with an "Invalid Registration" Status Code. The invalid attribute(s), in this case the DD symbolic name, SHALL be included in the response.
一个可变长度UTF-8编码的空终止文本字段，最多256字节。当客户端注册DD符号名时，iSNS服务器应验证其唯一性。如果名称不唯一，则DD注册将被拒绝，状态代码为“无效注册”。无效属性（在本例中为DD符号名）应包含在响应中。
This is the iSCSI Node Index of a Storage Node that is a member of the DD. The DD may have a list of 0 to n members. The iSCSI Node Index is one alternative representation of membership in a Discovery Domain, the other alternative being the iSCSI Name. The Discovery Domain iSCSI Node Index is a 4-byte non-zero integer value.
这是作为DD成员的存储节点的iSCSI节点索引。DD可能有0到n个成员的列表。iSCSI节点索引是发现域中成员身份的一种备选表示形式，另一种备选表示形式是iSCSI名称。发现域iSCSI节点索引是一个4字节的非零整数值。
The iSCSI Node Index can be used to represent a DD member in situations where the iSCSI Name is too long to be used. An example of this is when SNMP is used for management, as described in Section 2.10.
iSCSI节点索引可用于在iSCSI名称太长而无法使用的情况下表示DD成员。如第2.10节所述，使用SNMP进行管理就是一个例子。
The iSCSI Node Index and the iSCSI Name stored as a member in a DD SHALL be consistent with the iSCSI Node Index and iSCSI Name attributes registered for the Storage Node object in the iSNS server.
作为DD中的成员存储的iSCSI节点索引和iSCSI名称应与iSNS服务器中为存储节点对象注册的iSCSI节点索引和iSCSI名称属性一致。
A variable-length UTF-8 encoded NULL-terminated text-based field of up to 224 bytes. It indicates membership for the specified iSCSI Storage Node in the Discovery Domain. Note that the referenced Storage Node does not need to be actively registered in the iSNS database before the iSNS client uses this attribute. There is no limit to the number of members that may be in a DD. Membership is represented by the iSCSI Name of the iSCSI Storage Node.
一个可变长度UTF-8编码的空终止文本字段，最多224字节。它表示发现域中指定iSCSI存储节点的成员身份。请注意，在iSNS客户端使用此属性之前，不需要在iSNS数据库中主动注册引用的存储节点。DD中的成员数量没有限制。成员资格由iSCSI存储节点的iSCSI名称表示。
This 64-bit identifier attribute indicates membership for an iFCP Storage Node (FC Port) in the Discovery Domain. Note that the referenced Storage Node does not need to be actively registered in the iSNS database before the iSNS client uses this attribute. There is no limit to the number of members that may be in a DD. Membership is represented by the FC Port Name (WWPN) of the iFCP Storage Node.
此64位标识符属性表示发现域中iFCP存储节点（FC端口）的成员身份。请注意，在iSNS客户端使用此属性之前，不需要在iSNS数据库中主动注册引用的存储节点。DD中的成员数量没有限制。成员资格由iFCP存储节点的FC端口名（WWPN）表示。
This attribute indicates membership in the Discovery Domain for a Portal. It is an alternative representation for Portal membership to the Portal IP Address and Portal TCP/UDP Port. The referenced Portal MUST be actively registered in the iSNS database before the iSNS client uses this attribute.
此属性表示门户在发现域中的成员身份。它是门户IP地址和门户TCP/UDP端口的门户成员身份的替代表示形式。在iSNS客户端使用此属性之前，必须在iSNS数据库中主动注册引用的门户。
This attribute and the Portal TCP/UDP Port attribute indicate membership in the Discovery Domain for the specified Portal. Note that the referenced Portal does not need to be actively registered in the iSNS database before the iSNS client uses this attribute.
此属性和门户TCP/UDP端口属性表示指定门户在发现域中的成员身份。请注意，在iSNS客户端使用此属性之前，不需要在iSNS数据库中主动注册引用的门户。
This attribute and the Portal IP Address attribute indicate membership in the Discovery Domain for the specified Portal. Note that the referenced Portal does not need to be actively registered in the iSNS database before the iSNS client uses this attribute.
此属性和门户IP地址属性表示指定门户在发现域中的成员身份。请注意，在iSNS客户端使用此属性之前，不需要在iSNS数据库中主动注册引用的门户。
The Discovery Domain Features is a bitmap indicating the features of this DD. The bit positions are defined below. A bit set to 1 indicates the DD has the corresponding characteristics.
发现域功能是指示此DD功能的位图。位位置定义如下。位设置为1表示DD具有相应的特性。
Bit Position DD Feature
------------ ----------
31 (Lsb) Boot List Enabled (1)/Boot List Disabled (0)
All others RESERVED
Bit Position DD Feature
------------ ----------
31 (Lsb) Boot List Enabled (1)/Boot List Disabled (0)
All others RESERVED
Boot List: this feature indicates that the target(s) in this DD provides boot capabilities for the member initiators, as described in [iSCSI-boot].
引导列表：此功能表示此DD中的目标为成员启动器提供引导功能，如[iSCSI引导]中所述。
This is a virtual attribute containing a 4-byte integer value that indicates the next available (i.e., unused) Discovery Domain Index value. This attribute may only be queried; the iSNS server SHALL return an error code of 3 (Invalid Registration) to any client that attempts to register a value for this attribute. A Message Key is not required when exclusively querying for this attribute.
这是一个虚拟属性，包含一个4字节整数值，指示下一个可用（即未使用）的发现域索引值。只能查询该属性；iSNS服务器应向尝试注册此属性值的任何客户端返回错误代码3（无效注册）。独占查询此属性时不需要消息键。
When the iSNS protocol is deployed, the interaction between iSNS server and iSNS clients is subject to the following security threats:
部署iSNS协议时，iSNS服务器和iSNS客户端之间的交互会受到以下安全威胁：
a) An attacker could alter iSNS protocol messages, such as to direct iSCSI and iFCP devices to establish connections with rogue peer devices, or to weaken/eliminate IPSec protection for iSCSI or iFCP traffic.
a) 攻击者可以更改iSNS协议消息，例如指示iSCSI和iFCP设备与恶意对等设备建立连接，或者削弱/消除对iSCSI或iFCP流量的IPSec保护。
b) An attacker could masquerade as the real iSNS server using false iSNS heartbeat messages. This could cause iSCSI and iFCP devices to use rogue iSNS servers.
b) 攻击者可以使用虚假的iSNS心跳消息伪装成真实的iSNS服务器。这可能导致iSCSI和iFCP设备使用流氓iSNS服务器。
c) An attacker could gain knowledge about iSCSI and iFCP devices by snooping iSNS protocol messages. Such information could aid an attacker in mounting a direct attack on iSCSI and iFCP devices, such as a denial-of-service attack or outright physical theft.
c) 攻击者可以通过窥探iSNS协议消息获得有关iSCSI和iFCP设备的信息。此类信息可能有助于攻击者对iSCSI和iFCP设备发起直接攻击，例如拒绝服务攻击或彻底的物理盗窃。
To address these threats, the following capabilities are needed:
为了应对这些威胁，需要具备以下能力：
a) Unicast iSNS protocol messages may need to be authenticated. In addition, to protect against threat c), confidentiality support is desirable and is REQUIRED when certain functions of iSNS server are utilized.
a) 单播iSNS协议消息可能需要进行身份验证。此外，为了防止受到威胁（c），需要提供保密支持，并且在使用iSNS服务器的某些功能时需要提供保密支持。
b) Multicast iSNS protocol messages such as the iSNS heartbeat message may need to be authenticated. These messages need not be confidential since they do not leak critical information.
b) 可能需要对多播iSNS协议消息（如iSNS心跳消息）进行身份验证。这些信息不需要保密，因为它们不会泄露关键信息。
If the iSNS server is used to distribute authorizations for communications between iFCP and iSCSI peer devices, IPsec ESP with null transform MUST be implemented, and non-null transform MAY be implemented. If a non-null transform is implemented, then the DES encryption algorithm SHOULD NOT be used.
如果iSNS服务器用于为iFCP和iSCSI对等设备之间的通信分发授权，则必须实现带空转换的IPsec ESP，并且可以实现非空转换。如果实现了非空转换，则不应使用DES加密算法。
If the iSNS server is used to distribute security policy for iFCP and iSCSI devices, then authentication, data integrity, and confidentiality MUST be supported and used. Where confidentiality is desired or required, IPSec ESP with non-null transform SHOULD be used, and the DES encryption algorithm SHOULD NOT be used.
如果iSNS服务器用于为iFCP和iSCSI设备分发安全策略，则必须支持并使用身份验证、数据完整性和机密性。如果需要保密性，则应使用具有非空转换的IPSec ESP，而不应使用DES加密算法。
If the iSNS server is used to provide the boot list for clients, as described in Section 6.11.2.9, then the iSCSI boot client SHOULD implement a secure iSNS connection.
如第6.11.2.9节所述，如果使用iSNS服务器为客户端提供引导列表，则iSCSI引导客户端应实现安全的iSNS连接。
In order to protect against an attacker masquerading as an iSNS server, client devices MUST support the ability to authenticate broadcast or multicast messages such as the iSNS heartbeat. The iSNS authentication block (which is identical in format to the SLP authentication block) SHALL be used for this purpose. iSNS clients MUST implement the iSNS authentication block and MUST support BSD value 0x002. If the iSNS server supports broadcast or multicast iSNS messages (i.e., the heartbeat), then the server MUST implement the iSNS authentication block and MUST support BSD value 0x002. Note that the authentication block is used only for iSNS broadcast or multicast messages and MUST NOT be used in unicast iSNS messages.
为了防止伪装成iSNS服务器的攻击者，客户端设备必须支持对广播或多播消息（如iSNS心跳）进行身份验证的能力。为此，应使用iSNS认证块（其格式与SLP认证块相同）。iSNS客户端必须实现iSNS身份验证块，并且必须支持BSD值0x002。如果iSNS服务器支持广播或多播iSNS消息（即心跳），则服务器必须实现iSNS身份验证块，并且必须支持BSD值0x002。请注意，身份验证块仅用于iSNS广播或多播消息，不得用于单播iSNS消息。
There is no requirement that the communicating identities in iSNS protocol messages be kept confidential. Specifically, the identity and location of the iSNS server is not considered confidential.
没有要求对iSNS协议消息中的通信身份保密。具体而言，iSNS服务器的身份和位置不被视为机密。
For protecting unicast iSNS protocol messages, iSNS servers supporting security MUST implement ESP in tunnel mode and MAY implement transport mode.
为了保护单播iSNS协议消息，支持安全性的iSNS服务器必须在隧道模式下实现ESP，并且可以实现传输模式。
All iSNS implementations supporting security MUST support the replay protection mechanisms of IPsec.
所有支持安全性的iSNS实现都必须支持IPsec的重播保护机制。
iSNS security implementations MUST support both IKE Main Mode and Aggressive Mode for authentication, negotiation of security associations, and key management, using the IPSec DOI [RFC2407].
iSNS安全实现必须支持IKE主模式和主动模式，以便使用IPSec DOI[RFC2407]进行身份验证、安全关联协商和密钥管理。
Manual keying SHOULD NOT be used since it does not provide the necessary rekeying support. Conforming iSNS security implementations MUST support authentication using a pre-shared key, and MAY support certificate-based peer authentication using digital signatures. Peer authentication using the public key encryption methods outlined in IKEs Sections 5.2 and 5.3 [RFC2409] SHOULD NOT be supported.
不应使用手动键控，因为它不提供必要的重新键控支持。符合要求的iSNS安全实现必须支持使用预共享密钥的身份验证，并且可能支持使用数字签名的基于证书的对等身份验证。不应支持使用IKEs第5.2节和第5.3节[RFC2409]中概述的公钥加密方法进行对等身份验证。
Conforming iSNS implementations MUST support both IKE Main Mode and Aggressive Mode. IKE Main Mode with pre-shared key authentication SHOULD NOT be used when either of the peers use dynamically assigned IP addresses. Although Main Mode with pre-shared key authentication offers good security in many cases, situations where dynamically assigned addresses are used force the use of a group pre-shared key, which is vulnerable to man-in-the-middle attack. IKE Identity Payload ID_KEY_ID MUST NOT be used.
一致的iSNS实现必须同时支持IKE主模式和攻击模式。当任一对等方使用动态分配的IP地址时，不应使用带有预共享密钥身份验证的IKE主模式。尽管带有预共享密钥身份验证的主模式在许多情况下提供了良好的安全性，但在使用动态分配地址的情况下，强制使用组预共享密钥，这很容易受到中间人攻击。不得使用IKE标识有效负载ID\u密钥\u ID。
When digital signatures are used for authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used. In all cases, access to locally stored secret information (pre-shared key or private key for digital signing) MUST be suitably restricted, since compromise of the secret information nullifies the security properties of the IKE/IPsec protocols.
当数字签名用于身份验证时，可以使用IKE主模式或IKE攻击模式。在所有情况下，必须适当限制对本地存储的秘密信息（预共享密钥或用于数字签名的私钥）的访问，因为泄露秘密信息会使IKE/IPsec协议的安全属性无效。
When digital signatures are used to achieve authentication, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority (or authorities) that are trusted in accordance with its local policy. IKE negotiators SHOULD check the pertinent Certificate Revocation List (CRL) before accepting a PKI certificate for use in IKE's authentication procedures.
当使用数字签名实现身份验证时，IKE谈判者应使用IKE证书请求有效载荷来指定根据其本地策略受信任的证书颁发机构。IKE谈判者在接受用于IKE认证过程的PKI证书之前，应检查相关的证书撤销列表（CRL）。
When the iSNS server is used without security, IP block storage protocol implementations MUST support a negative cache for authentication failures. This allows implementations to avoid continually contacting discovered endpoints that fail authentication within IPsec or at the application layer (in the case of iSCSI Login). The negative cache need not be maintained within the IPsec implementation, but rather within the IP block storage protocol implementation.
如果使用iSNS服务器时没有安全性，IP块存储协议实施必须支持身份验证失败的负缓存。这允许实现避免在IPsec内或在应用程序层（在iSCSI登录的情况下）不断联系发现的未通过身份验证的端点。负缓存不需要在IPsec实现中维护，而是在IP块存储协议实现中维护。
Once communication between iSNS clients and the iSNS server has been secured through use of IPSec, the iSNS client devices have the capability to discover the security settings that they need to use for their peer-to-peer communications using the iSCSI and/or iFCP protocols. This provides a potential scaling advantage over device-by-device configuration of individual security policies for each iSCSI and iFCP device.
一旦iSNS客户端和iSNS服务器之间的通信通过IPSec得到保护，iSNS客户端设备就能够发现它们需要使用iSCSI和/或iFCP协议进行对等通信的安全设置。与每个iSCSI和iFCP设备的单个安全策略的逐设备配置相比，这提供了潜在的扩展优势。
The iSNS server stores security settings for each iSCSI and iFCP device interface. These security settings, which can be retrieved by authorized hosts, include use or non-use of IPSec, IKE, Main Mode, and Aggressive Mode. For example, IKE may not be enabled for a particular interface of a peer device. If a peer device can learn of this in advance by consulting the iSNS server, it will not need to waste time and resources attempting to initiate an IKE phase 1 session with that peer device interface.
iSNS服务器存储每个iSCSI和iFCP设备接口的安全设置。这些安全设置可由授权主机检索，包括使用或不使用IPSec、IKE、主模式和攻击模式。例如，可能不会为对等设备的特定接口启用IKE。如果对等设备可以通过咨询iSNS服务器提前了解到这一点，则无需浪费时间和资源来尝试启动与该对等设备接口的IKE阶段1会话。
If iSNS is used for this purpose, then the minimum information that should be learned from the iSNS server is the use or non-use of IKE and IPSec by each iFCP or iSCSI peer device interface. This information is encoded in the Security Bitmap field of each Portal of the peer device, and is applicable on a per-interface basis for the peer device. iSNS queries for acquiring security configuration data about peer devices MUST be protected by IPSec/ESP authentication.
如果iSNS用于此目的，则应从iSNS服务器了解的最低信息是每个iFCP或iSCSI对等设备接口是否使用IKE和IPSec。该信息编码在对等设备的每个入口的安全位图字段中，并且适用于对等设备的每个接口。用于获取对等设备的安全配置数据的iSNS查询必须受到IPSec/ESP身份验证的保护。
Use of iSNS for distribution of security policies offers the potential to reduce the burden of manual device configuration, and to decrease the probability of communications failures due to incompatible security policies. If iSNS is used to distribute security policies, then IPSec authentication, data integrity, and confidentiality MUST be used to protect all iSNS protocol messages.
使用iSNS分发安全策略有可能减轻手动设备配置的负担，并降低由于安全策略不兼容而导致通信失败的概率。如果iSNS用于分发安全策略，则必须使用IPSec身份验证、数据完整性和机密性来保护所有iSNS协议消息。
The complete IKE/IPSec configuration of each iFCP and/or iSCSI device can be stored in the iSNS server, including policies that are used for IKE Phase 1 and Phase 2 negotiations between client devices. The IKE payload format includes a series of one or more proposals that the iSCSI or iFCP device will use when negotiating the appropriate IPsec policy to use to protect iSCSI or iFCP traffic.
每个iFCP和/或iSCSI设备的完整IKE/IPSec配置可以存储在iSNS服务器中，包括用于客户端设备之间IKE阶段1和阶段2协商的策略。IKE有效负载格式包括一系列一个或多个方案，iSCSI或iFCP设备将在协商用于保护iSCSI或iFCP流量的适当IPsec策略时使用这些方案。
In addition, the iSCSI Authentication Methods used by each iSCSI device can also be stored in the iSNS server. The iSCSI AuthMethod field (tag=42) contains a null-terminated string embedded with the text values indicating iSCSI authentication methods to be used by that iSCSI device.
此外，每个iSCSI设备使用的iSCSI身份验证方法也可以存储在iSNS服务器中。iSCSI AuthMethod字段（tag=42）包含一个以null结尾的字符串，其中嵌入了指示该iSCSI设备要使用的iSCSI身份验证方法的文本值。
Note that iSNS distribution of security policy is not necessary if the security settings can be determined by other means, such as manual configuration or IPsec security policy distribution. If a network entity has already obtained its security configuration via other mechanisms, then it MUST NOT request security policy via iSNS.
请注意，如果可以通过其他方式（如手动配置或IPsec安全策略分发）确定安全设置，则无需分发安全策略的iSNS。如果网络实体已通过其他机制获得其安全配置，则不得通过iSNS请求安全策略。
The iSNS protocol is lightweight and will not generate a significant amount of traffic. iSNS traffic is characterized by occasional registration, notification, and update messages that do not consume significant amounts of bandwidth. Even software-based IPSec implementations should not have a problem handling the traffic loads generated by the iSNS protocol.
iSNS协议是轻量级的，不会产生大量流量。iSNS流量的特点是偶尔注册、通知和更新消息，这些消息不会占用大量带宽。即使是基于软件的IPSec实现，在处理iSNS协议生成的流量负载时也不应该有问题。
To fulfill iSNS security requirements, the only additional resources needed beyond what is already required for iSCSI and iFCP involve the iSNS server. Because iSCSI and iFCP end nodes are already required to implement IKE and IPSec, these existing requirements can also be used to fulfill IKE and IPSec requirements for iSNS clients.
为了满足iSNS安全要求，除了iSCSI和iFCP已经需要的资源外，iSNS服务器还需要额外的资源。由于实现IKE和IPSec已经需要iSCSI和iFCP端节点，因此这些现有需求也可用于满足iSNS客户端的IKE和IPSec需求。
When IPSec security is enabled, each iSNS client with at least one Storage Node that is registered in the iSNS database SHALL maintain at least one phase-1 security association with the iSNS server. All iSNS protocol messages between iSNS clients and the iSNS server SHALL be protected by a phase-2 security association.
启用IPSec安全时，每个iSNS客户端（至少有一个在iSNS数据库中注册的存储节点）应与iSNS服务器保持至少一个阶段1安全关联。iSNS客户端和iSNS服务器之间的所有iSNS协议消息应受到第2阶段安全关联的保护。
When a Network Entity is removed from the iSNS database, the iSNS server SHALL send a phase-1 delete message to the associated iSNS client IKE peer, and tear down all phase-1 and phase-2 SAs associated with that iSNS client.
从iSNS数据库中删除网络实体时，iSNS服务器应向相关iSNS客户端IKE对等方发送阶段1删除消息，并拆除与该iSNS客户端相关的所有阶段1和阶段2 SA。
The well-known TCP and UDP port number for iSNS is 3205.
iSNS众所周知的TCP和UDP端口号是3205。
The standards action of this RFC creates two registries to be maintained by IANA in support of iSNSP and assigns initial values for both registries. The first registry is of Block Storage Protocols supported by iSNS. The second registry is a detailed registry of standard iSNS attributes that can be registered to and queried from the iSNS server. Note that this RFC uses the registry created for Block Structure Descriptor (BSD) in Section 15 of Service Location Protocol, Version 2 [RFC2608].
本RFC的标准行动创建了两个注册中心，由IANA维护以支持iSNSP，并为两个注册中心分配初始值。第一个注册表是iSNS支持的块存储协议。第二个注册表是标准iSNS属性的详细注册表，可以在iSNS服务器上注册和查询这些属性。请注意，此RFC使用服务位置协议第2版[RFC2608]第15节中为块结构描述符（BSD）创建的注册表。
In order to maintain a registry of block storage protocols supported by iSNSP, IANA will assign a 32-bit unsigned integer number for each block storage protocol supported by iSNS. This number is stored in the iSNS database as the Entity Protocol. The initial set of values to be maintained by IANA for Entity Protocol is indicated in the
为了维护iSNSP支持的块存储协议的注册表，IANA将为iSNS支持的每个块存储协议分配一个32位无符号整数。此号码作为实体协议存储在iSNS数据库中。IANA为实体协议维护的初始值集在
table in Section 6.2.2. Additional values for new block storage protocols to be supported by iSNS SHALL be assigned by the IPS WG Chairperson, or by a Designated Expert [RFC2434] appointed by the IETF Transport Area Director.
第6.2.2节中的表。iSNS支持的新数据块存储协议的附加值应由IPS工作组主席或IETF传输区域主任指定的指定专家[RFC2434]指定。
IANA is responsible for creating and maintaining the Registry of Standard iSNS Attributes. The initial list of iSNS attributes is described in Section 6. For each iSNS attribute this information MUST include, its tag value, the attribute length, and the tag values for the set of permissible registration and query keys that can be used for that attribute. The initial list of iSNS attributes to be maintained by IANA is indicated in Section 6.1.
IANA负责创建和维护标准iSNS属性的注册表。第6节介绍了iSNS属性的初始列表。对于每个iSNS属性，此信息必须包括其标记值、属性长度以及可用于该属性的允许注册和查询密钥集的标记值。IANA维护的iSNS属性初始列表如第6.1节所示。
Additions of new standard attributes to the Registry of Standard iSNS Attributes SHALL require IETF Consensus [RFC2434]. The RFC required for this process SHALL specify use of tag values reserved for IANA allocation in Section 6.1. The RFC SHALL specify as a minimum, the new attribute tag value, attribute length, and the set of permissible registration and query keys that can be used for the new attribute. The RFC SHALL also include a discussion of the reasons for the new attribute(s) and how the new attribute(s) are to be used.
向标准iSNS属性注册中心添加新的标准属性需要IETF协商一致[RFC2434]。该过程所需的RFC应规定使用第6.1节中为IANA分配保留的标签值。RFC应至少指定新属性标签值、属性长度以及可用于新属性的允许注册和查询密钥集。RFC还应包括对新属性的原因以及如何使用新属性的讨论。
As part of the process of obtaining IETF Consensus, the proposed RFC and its supporting documentation SHALL be made available to the IPS WG mailing list or, if the IPS WG is disbanded at the time, to a mailing list designated by the IETF Transport Area Director. The review and comment period SHALL last at least three months before the IPS WG Chair or a person designated by the IETF Transport Area Director decides either to reject the proposal or to forward the draft to the IESG for publication as an RFC. When the specification is published as an RFC, then IANA will register the new iSNS attribute(s) and make the registration available to the community.
作为获得IETF共识过程的一部分，提议的RFC及其支持文件应提供给IPS工作组邮件列表，或者，如果IPS工作组当时解散，则提供给IETF运输区域总监指定的邮件列表。审查和评论期应至少持续三个月，然后IPS工作组主席或IETF运输区主任指定的人员决定拒绝该提案或将草案转发给IESG作为RFC发布。当规范作为RFC发布时，IANA将注册新的iSNS属性，并使社区可以使用该注册。
Note that IANA is already responsible for assigning and maintaining values used for the Block Structure Descriptor for the iSNS Authentication Block (see Section 5.5). Section 15 of [RFC2608] describes the process for allocation of new BSD values.
请注意，IANA已经负责为iSNS认证块分配和维护用于块结构描述符的值（参见第5.5节）。[RFC2608]第15节描述了分配新BSD值的过程。
[iSCSI] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[iSCSI]Satran，J.，Meth，K.，Sapuntzakis，C.，Chadalapaka，M.，和E.Zeidner，“互联网小型计算机系统接口（iSCSI）”，RFC 3720，2004年4月。
[iFCP] Monia, C., Mullendore, R., Travostino, F., Jeong, W., and M. Edwards, "iFCP - A Protocol for Internet Fibre Channel Storage Networking", RFC 4172, September 2005.
[iFCP]Monia，C.，Mullendore，R.，Travostino，F.，Jeong，W.，和M.Edwards，“iFCP-互联网光纤通道存储网络协议”，RFC 4172，2005年9月。
[iSNSOption] Monia, C., Tseng, J., and K. Gibbons, The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service, RFC 4174, September 2005.
[iSNSOption]Monia，C.，Tseng，J.，和K.Gibbons，Internet存储名称服务的IPv4动态主机配置协议（DHCP）选项，RFC 41742005年9月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2 ", RFC 2608, June 1999.
[RFC2608]Guttman，E.，Perkins，C.，Veizades，J.，和M.Day，“服务位置协议，版本2”，RFC 26081999年6月。
[iSCSI-SLP] Bakke, M., Hufferd, J., Voruganti, K., Krueger, M., and T. Sperry, "Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLP), RFC 4018, April 2005.
[iSCSI SLP]Bakke，M.，Hufferd，J.，Voruganti，K.，Krueger，M.，和T.Sperry，“通过使用服务位置协议版本2（SLP）查找Internet小型计算机系统接口（iSCSI）目标和名称服务器”，RFC 4018，2005年4月。
[iSCSI-boot] Sarkar, P., Missimer, D., and C. Sapuntzakis, "Bootstrapping Clients using the Internet Samll Computer System Interface (iSCSI) Protocol", RFC 4173, September 2005.
[iSCSI引导]Sarkar，P.，Missimer，D.，和C.Sapuntzakis，“使用互联网Samll计算机系统接口（iSCSI）协议引导客户端”，RFC 41732005年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[STRINGPREP] Bakke, M., "String Profile for Internet Small Computer Systems Interface (iSCSI) Names", RFC 3722, April 2004.
[STRINGPREP]Bakke，M.，“互联网小型计算机系统接口（iSCSI）名称的字符串配置文件”，RFC 3722，2004年4月。
[NAMEPREP] Hoffman, P. Nameprep: A Stringprep Profile for Internationalized Domain Names, July 2002.
[NAMEPREP]Hoffman，P.NAMEPREP：国际化域名的Stringprep配置文件，2002年7月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2408]Maughan，D.，Schertler，M.，Schneider，M.，和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[EUI-64] Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority, May 2001, IEEE
[EUI-64]64位全局标识符（EUI-64）注册机构指南，2001年5月，IEEE
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[RFC3279]Bassham，L.，Polk，W.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的算法和标识符”，RFC 3279，2002年4月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280]Housley，R.，Polk，W.，Ford，W.，和D.Solo，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）概要”，RFC 32802002年4月。
[802-1990] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, Technical Committee on Computer Communications of the IEEE Computer Society, May 31, 1990
[802-1990]IEEE局域网和城域网标准：概述和体系结构，IEEE计算机协会计算机通信技术委员会，1990年5月31日
[FC-FS] Fibre Channel Framing and Signaling Interface, NCITS Working Draft Project 1331-D
[FC-FS]光纤通道成帧和信令接口，NCITS工作草案项目1331-D
[iSNSMIB] Gibbons, K., et al., "Definitions of Managed Objects for iSNS (Internet Storage name Service)", Work in Progress, July 2003.
[iSNSMIB]Gibbons，K.，等人，“iSNS（Internet存储名称服务）的托管对象定义”，正在进行的工作，2003年7月。
[X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, June 1997
[X.509]ITU-T建议X.509（1997 E）：信息技术-开放系统互连-目录：认证框架，1997年6月
[FC-GS-4] Fibre Channel Generic Services-4 (work in progress), NCITS Working Draft Project 1505-D
[FC-GS-4]光纤通道通用服务-4（在建工程），NCITS工作草案项目1505-D
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[RFC1510]Kohl，J.和C.Neuman，“Kerberos网络身份验证服务（V5）”，RFC15101993年9月。
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.
[RFC2025]Adams，C.，“简单公钥GSS-API机制（SPKM）”，RFC 20252996年10月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000.
[RFC2945]Wu，T.，“SRP认证和密钥交换系统”，RFC 29452000年9月。
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994]辛普森，W.，“PPP挑战握手认证协议（CHAP）”，RFC 1994，1996年8月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]Case，J.，Mundy，R.，Partain，D.，和B.Stewart，“互联网标准管理框架的介绍和适用性声明”，RFC 34102002年12月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]Harrington，D.，Presohn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
Appendix A: iSNS Examples
附录A：iSNS示例
This example assumes an SLP Service Agent (SA) has been implemented on the iSNS host, and an SLP User Agent (UA) has been implemented on the iSNS initiator. See [RFC2608] for further details on SAs and UAs. This example also assumes that the target is configured to use the iSNS server, and have its access control policy subordinated to the iSNS server.
本示例假设在iSNS主机上实现了SLP服务代理（SA），并且在iSNS启动器上实现了SLP用户代理（UA）。有关SAs和UAs的更多详细信息，请参阅[RFC2608]。本示例还假设目标配置为使用iSNS服务器，并且其访问控制策略从属于iSNS服务器。
In this example, a simple target with a single iSCSI name registers with the iSNS server. The target is represented in the iSNS by an Entity containing one Storage Node, one Portal, and an implicitly registered Portal Group that provides a relationship between the Storage Node and Portal. The target has not been assigned a Fully Qualified Domain Name (FQDN) by the administrator. In this example, because a PG object is not explicitly registered, a Portal Group with a PGT of 1 is implicitly registered. In this example SLP is used to discover the location of the iSNS Server. An alternative is to use the iSNS DHCP option [iSNSOption] to discover the iSNS server.
在本例中，具有单个iSCSI名称的简单目标在iSNS服务器中注册。iSNS中的目标由一个实体表示，该实体包含一个存储节点、一个门户和一个隐式注册的门户组，该门户组提供存储节点和门户之间的关系。管理员尚未为目标分配完全限定的域名（FQDN）。在本例中，由于PG对象未显式注册，因此PGT为1的门户组将隐式注册。在本例中，SLP用于发现iSNS服务器的位置。另一种方法是使用iSNS DHCP选项[iSNSOption]来发现iSNS服务器。
+--------------------------+------------------+-------------------+
| iSCSI Target Device | iSNS Server |Management Station |
+--------------------------+------------------+-------------------+
|Discover iSNS--SLP------->| |/*mgmt station is |
| |<--SLP--iSNS Here:| administratively |
| | 192.0.2.100 | authorized to view|
| | | all DDs. Device |
| DevAttrReg--------->| | NAMEabcd was |
|Src:(tag=32) "NAMEabcd" | | previously placed |
|Key: <none present> | | into DDabcd along |
|Oper Attrs: | | with devpdq and |
|tag=1: NULL | | devrst. |
|tag=2: "iSCSI" | | |
|tag=16: 192.0.2.5 | | |
|tag=17: 5001 | | |
|tag=32: "NAMEabcd" | | |
|tag=33: target | | |
|tag=34: "disk 1" | | |
| |<---DevAttrRegRsp | |
| |SUCCESS | |
| |Key:(tag=1) "isns:0001" |
| |Oper Attrs: | |
| |tag=1: "isns:0001"| |
| |tag=2: "iSCSI" | |
+--------------------------+------------------+-------------------+
| iSCSI Target Device | iSNS Server |Management Station |
+--------------------------+------------------+-------------------+
|Discover iSNS--SLP------->| |/*mgmt station is |
| |<--SLP--iSNS Here:| administratively |
| | 192.0.2.100 | authorized to view|
| | | all DDs. Device |
| DevAttrReg--------->| | NAMEabcd was |
|Src:(tag=32) "NAMEabcd" | | previously placed |
|Key: <none present> | | into DDabcd along |
|Oper Attrs: | | with devpdq and |
|tag=1: NULL | | devrst. |
|tag=2: "iSCSI" | | |
|tag=16: 192.0.2.5 | | |
|tag=17: 5001 | | |
|tag=32: "NAMEabcd" | | |
|tag=33: target | | |
|tag=34: "disk 1" | | |
| |<---DevAttrRegRsp | |
| |SUCCESS | |
| |Key:(tag=1) "isns:0001" |
| |Oper Attrs: | |
| |tag=1: "isns:0001"| |
| |tag=2: "iSCSI" | |
| |tag=16: 192.0.2.5 | |
| |tag=17: 5001 | |
| |tag=32: "NAMEabcd"|/* previously |
| |tag=33: target | placed in a DD */ |
| |tag=34: "disk 1" | |
| | | |
| | SCN-------->| |
| |(or SNMP notification) |
| |dest:(tag=32):"MGMTname1" |
| |time:(tag=4): <current time> |
| |tag=35: "MGT-SCN, OBJ-ADD" |
| |tag=32: "NAMEabcd"| |
| | |<-------SCNRsp |
| DevAttrQry--------->| | |
|Src:(tag=32) "NAMEabcd" | | |
|Key:(tag=33) "initiator" | | |
|Oper Attrs: | | |
|tag=16: NULL | | |
|tag=17: NULL | | |
|tag=32: NULL | | |
|/*Query asks for all initr| | |
|devices' IP address, port |<---DevAttrQryRsp | |
|number, and Name*/ |SUCCESS | |
| |tag=16:192.0.2.1 | |
| |tag=17:50000 | |
| |tag=32:"devpdq" | |
| |tag=16:192.0.2.2 | |
| |tag=17:50000 | |
| |tag=32:"devrst" | |
|/*************************| |<-----DevAttrQry |
|Our target "NAMEabcd" | |src: "MGMTname1" |
|discovers two initiators | key:(tag=32)"NAMEabcd"
|in shared DDs. It will | |Op Attrs: |
|accept iSCSI logins from | |tag=16: NULL |
|these two identified | |tag=17: NULL |
|initiators presented by | |tag=32: NULL |
|iSNS | | |
|*************************/| DevAttrQryRsp--->| |
| |SUCCESS | |
| |tag=16: 192.0.2.5 | |
| |tag=17: 5001 | |
| |tag=32: "NAMEabcd"| |
+--------------------------+------------------+-------------------+
| |tag=16: 192.0.2.5 | |
| |tag=17: 5001 | |
| |tag=32: "NAMEabcd"|/* previously |
| |tag=33: target | placed in a DD */ |
| |tag=34: "disk 1" | |
| | | |
| | SCN-------->| |
| |(or SNMP notification) |
| |dest:(tag=32):"MGMTname1" |
| |time:(tag=4): <current time> |
| |tag=35: "MGT-SCN, OBJ-ADD" |
| |tag=32: "NAMEabcd"| |
| | |<-------SCNRsp |
| DevAttrQry--------->| | |
|Src:(tag=32) "NAMEabcd" | | |
|Key:(tag=33) "initiator" | | |
|Oper Attrs: | | |
|tag=16: NULL | | |
|tag=17: NULL | | |
|tag=32: NULL | | |
|/*Query asks for all initr| | |
|devices' IP address, port |<---DevAttrQryRsp | |
|number, and Name*/ |SUCCESS | |
| |tag=16:192.0.2.1 | |
| |tag=17:50000 | |
| |tag=32:"devpdq" | |
| |tag=16:192.0.2.2 | |
| |tag=17:50000 | |
| |tag=32:"devrst" | |
|/*************************| |<-----DevAttrQry |
|Our target "NAMEabcd" | |src: "MGMTname1" |
|discovers two initiators | key:(tag=32)"NAMEabcd"
|in shared DDs. It will | |Op Attrs: |
|accept iSCSI logins from | |tag=16: NULL |
|these two identified | |tag=17: NULL |
|initiators presented by | |tag=32: NULL |
|iSNS | | |
|*************************/| DevAttrQryRsp--->| |
| |SUCCESS | |
| |tag=16: 192.0.2.5 | |
| |tag=17: 5001 | |
| |tag=32: "NAMEabcd"| |
+--------------------------+------------------+-------------------+
In this example, a more complex target, with two Storage Nodes and two Portals using ESI monitoring, registers with the iSNS. This target has been configured with a Fully Qualified Domain Name (FQDN) in the DNS servers, and the user wishes to use this identifier for the device. The target explicitly registers Portal Groups to describe how each Portal provides access to each Storage Node. One target Storage Node allows coordinated access through both Portals. The other Storage Node allows access, but not coordinated access, through both Portals.
在本例中，一个更复杂的目标（有两个存储节点和两个使用ESI监控的门户）向iSNS注册。此目标已在DNS服务器中配置了完全限定的域名（FQDN），用户希望将此标识符用于设备。目标明确注册门户组，以描述每个门户如何提供对每个存储节点的访问。一个目标存储节点允许通过两个入口进行协调访问。另一个存储节点允许通过两个入口进行访问，但不允许协调访问。
+--------------------------+------------------+-------------------+
| iSCSI Target Device | iSNS Server |Management Station |
+--------------------------+------------------+-------------------+
|Discover iSNS--SLP--> | |/*mgmt station is |
| |<--SLP--iSNS Here:| administratively |
| | 192.0.2.100 | authorized to view|
| DevAttrReg--> | | all DDs */ |
|Src: | | |
|tag=32: "NAMEabcd" | | |
|Msg Key: | | |
|tag=1: "jbod1.example.com"| | |
|Oper Attrs: | | |
|tag=1: "jbod1.example.com"| | |
|tag=2: "iSCSI" | | |
|tag=16: 192.0.2.4 | | |
|tag=17: 5001 | | |
|tag=19: 5 | | |
|tag=20: 5002 | | |
|tag=16: 192.0.2.5 | | |
|tag=17: 5001 | | |
|tag=19: 5 | | |
|tag=20: 5002 | | |
|tag=32: "NAMEabcd" | | |
|tag=33: "Target" | | |
|tag=34: "Storage Array 1" | | |
|tag=51: 10 | | |
|tag=49: 192.0.2.4 | | |
|tag=50: 5001 | | |
|tag=49: 192.0.2.5 | | |
|tag=50: 5001 | | |
|tag=32: "NAMEefgh" | | |
|tag=33: "Target" | | |
|tag=34: "Storage Array 2" |/*****************| |
|tag=51: 20 |jbod1.example.com is |
|tag=49: 192.0.2.4 |now registered in | |
|tag=50: 5001 |iSNS, but is not | |
+--------------------------+------------------+-------------------+
| iSCSI Target Device | iSNS Server |Management Station |
+--------------------------+------------------+-------------------+
|Discover iSNS--SLP--> | |/*mgmt station is |
| |<--SLP--iSNS Here:| administratively |
| | 192.0.2.100 | authorized to view|
| DevAttrReg--> | | all DDs */ |
|Src: | | |
|tag=32: "NAMEabcd" | | |
|Msg Key: | | |
|tag=1: "jbod1.example.com"| | |
|Oper Attrs: | | |
|tag=1: "jbod1.example.com"| | |
|tag=2: "iSCSI" | | |
|tag=16: 192.0.2.4 | | |
|tag=17: 5001 | | |
|tag=19: 5 | | |
|tag=20: 5002 | | |
|tag=16: 192.0.2.5 | | |
|tag=17: 5001 | | |
|tag=19: 5 | | |
|tag=20: 5002 | | |
|tag=32: "NAMEabcd" | | |
|tag=33: "Target" | | |
|tag=34: "Storage Array 1" | | |
|tag=51: 10 | | |
|tag=49: 192.0.2.4 | | |
|tag=50: 5001 | | |
|tag=49: 192.0.2.5 | | |
|tag=50: 5001 | | |
|tag=32: "NAMEefgh" | | |
|tag=33: "Target" | | |
|tag=34: "Storage Array 2" |/*****************| |
|tag=51: 20 |jbod1.example.com is |
|tag=49: 192.0.2.4 |now registered in | |
|tag=50: 5001 |iSNS, but is not | |
|tag=51: 30 |in any DD. Therefore, |
|tag=49: 192.0.2.5 |no other devices | |
|tag=50: 5001 |can "see" it. | |
| |*****************/| |
| |<--DevAttrRegRsp | |
| |SUCCESS | |
| |Msg Key: | |
| |tag=1: "jbod1.example.com" |
| |Oper Attrs: | |
| |tag=1: "jbod1.example.com" |
| |tag=2: "iSCSI" | |
| |tag=16: 192.0.2.4 | |
| |tag=17: 5001 | |
| |tag=19: 5 | |
| |tag=20: 5002 | |
| |tag=16: 192.0.2.5 | |
| |tag=17: 5001 | |
| |tag=19: 5 | |
| |tag=20: 5002 | |
| |tag=32: "NAMEabcd"| |
| |tag=33: "Target" | |
| |tag=34: "Storage Array 1" |
| |tag=48: "NAMEabcd"| |
| |tag=49: 192.0.2.4 | |
| |tag=50: 5001 | |
| |tag=51: 10 | |
| |tag=48: "NAMEabcd"| |
| |tag=49: 192.0.2.5 | |
| |tag=50: 5001 | |
| |tag=51: 10 | |
| |tag=32: "NAMEefgh"| |
| |tag=33: "Target" | |
| |tag=34: "Storage Array 2" |
| |tag=43: X.509 cert| |
| |tag=48: "NAMEefgh"| |
| |tag=49: 192.0.2.4 | |
| |tag=50: 5001 | |
| |tag=51: 20 | |
| |tag=48: "NAMEefgh"| |
| |tag=49: 192.0.2.5 | |
| |tag=50: 5001 | |
| |tag=51: 30 | |
| | | |
| | SCN------> | |
| | (or SNMP notification) |
| |dest:(tag=32)"mgmt.example.com" |
| |time:(tag=4): <current time> |
| |tag=35: "MGT-SCN, OBJ-ADD" |
|tag=51: 30 |in any DD. Therefore, |
|tag=49: 192.0.2.5 |no other devices | |
|tag=50: 5001 |can "see" it. | |
| |*****************/| |
| |<--DevAttrRegRsp | |
| |SUCCESS | |
| |Msg Key: | |
| |tag=1: "jbod1.example.com" |
| |Oper Attrs: | |
| |tag=1: "jbod1.example.com" |
| |tag=2: "iSCSI" | |
| |tag=16: 192.0.2.4 | |
| |tag=17: 5001 | |
| |tag=19: 5 | |
| |tag=20: 5002 | |
| |tag=16: 192.0.2.5 | |
| |tag=17: 5001 | |
| |tag=19: 5 | |
| |tag=20: 5002 | |
| |tag=32: "NAMEabcd"| |
| |tag=33: "Target" | |
| |tag=34: "Storage Array 1" |
| |tag=48: "NAMEabcd"| |
| |tag=49: 192.0.2.4 | |
| |tag=50: 5001 | |
| |tag=51: 10 | |
| |tag=48: "NAMEabcd"| |
| |tag=49: 192.0.2.5 | |
| |tag=50: 5001 | |
| |tag=51: 10 | |
| |tag=32: "NAMEefgh"| |
| |tag=33: "Target" | |
| |tag=34: "Storage Array 2" |
| |tag=43: X.509 cert| |
| |tag=48: "NAMEefgh"| |
| |tag=49: 192.0.2.4 | |
| |tag=50: 5001 | |
| |tag=51: 20 | |
| |tag=48: "NAMEefgh"| |
| |tag=49: 192.0.2.5 | |
| |tag=50: 5001 | |
| |tag=51: 30 | |
| | | |
| | SCN------> | |
| | (or SNMP notification) |
| |dest:(tag=32)"mgmt.example.com" |
| |time:(tag=4): <current time> |
| |tag=35: "MGT-SCN, OBJ-ADD" |
| |tag=32: "NAMEabcd"| |
| |tag=35: "MGT-SCN, OBJ-ADD" |
| |tag=32: "NAMEefgh"| |
| | |<--SCNRsp |
| | |SUCCESS |
| | tag=32:"mgmt.example.com"|
| | | |
| | |<--DevAttrQry |
| | |Src: |
| | tag=32:"mgmt.example.com"
| | |Msg Key: |
| | |tag=32: "NAMEabcd" |
| | |Oper Attrs: |
| | |tag=16: <0-length> |
| | |tag=17: <0-length> |
| | |tag=32: <0-length> |
| | | |
| | DevAttrQryRsp--> | |
| |SUCCESS | |
| |Msg Key: | |
| |tag=32: "NAMEabcd"| |
| |Oper Attrs: | |
| |tag=16: 192.0.2.4 | |
| |tag=17: 5001 | |
| |tag=32:"NAMEabcd" | |
| |tag=16: 192.0.2.5 | |
| |tag=17: 5001 | |
| |tag=32:"NAMEabcd" | |
| | |Src: |
| | tag=32:"mgmt.example.com"
| | |Msg Key: |
| | |tag=32: "NAMEefgh" |
| | |Oper Attrs: |
| | |tag=16: <0-length> |
| | |tag=17: <0-length> |
| | |tag=32: <0-length> |
| | | |
| | DevAttrQryRsp--> | |
| |SUCCESS | |
| |Msg Key: | |
| |tag=32: "NAMEefgh"| |
| |Oper Attrs: | |
| |tag=16: 192.0.2.4 | |
| |tag=17: 5001 | |
| |tag=32:"NAMEefgh" | |
| |tag=16: 192.0.2.5 |/**Mgmt Station ***|
| |tag=17: 5001 |displays device, |
| |tag=32:"NAMEefgh" |the operator decides
| |tag=32: "NAMEabcd"| |
| |tag=35: "MGT-SCN, OBJ-ADD" |
| |tag=32: "NAMEefgh"| |
| | |<--SCNRsp |
| | |SUCCESS |
| | tag=32:"mgmt.example.com"|
| | | |
| | |<--DevAttrQry |
| | |Src: |
| | tag=32:"mgmt.example.com"
| | |Msg Key: |
| | |tag=32: "NAMEabcd" |
| | |Oper Attrs: |
| | |tag=16: <0-length> |
| | |tag=17: <0-length> |
| | |tag=32: <0-length> |
| | | |
| | DevAttrQryRsp--> | |
| |SUCCESS | |
| |Msg Key: | |
| |tag=32: "NAMEabcd"| |
| |Oper Attrs: | |
| |tag=16: 192.0.2.4 | |
| |tag=17: 5001 | |
| |tag=32:"NAMEabcd" | |
| |tag=16: 192.0.2.5 | |
| |tag=17: 5001 | |
| |tag=32:"NAMEabcd" | |
| | |Src: |
| | tag=32:"mgmt.example.com"
| | |Msg Key: |
| | |tag=32: "NAMEefgh" |
| | |Oper Attrs: |
| | |tag=16: <0-length> |
| | |tag=17: <0-length> |
| | |tag=32: <0-length> |
| | | |
| | DevAttrQryRsp--> | |
| |SUCCESS | |
| |Msg Key: | |
| |tag=32: "NAMEefgh"| |
| |Oper Attrs: | |
| |tag=16: 192.0.2.4 | |
| |tag=17: 5001 | |
| |tag=32:"NAMEefgh" | |
| |tag=16: 192.0.2.5 |/**Mgmt Station ***|
| |tag=17: 5001 |displays device, |
| |tag=32:"NAMEefgh" |the operator decides
| | |to place "NAMEabcd"|
| | |into Domain "DDxyz"|
|/*************************| |******************/|
|Target is now registered | | |
|in iSNS. It is then placed| |<--DDReg |
|in a pre-existing DD with | |Src: |
|DD_ID 123 by a management | tag=32:"mgmt.example.com"
|station. | |Msg Key: |
|*************************/| |tag=2065: 123 |
| | |Oper Attrs: |
| | |tag=2068: "NAMEabcd"
| | DDRegRsp-----> | |
| |SUCCESS | |
| |Msg Key: | |
| |tag=2065: 123 | |
| |Oper Attrs: | |
| |tag=2065: 123 | |
+--------------------------+------------------+-------------------+
| | |to place "NAMEabcd"|
| | |into Domain "DDxyz"|
|/*************************| |******************/|
|Target is now registered | | |
|in iSNS. It is then placed| |<--DDReg |
|in a pre-existing DD with | |Src: |
|DD_ID 123 by a management | tag=32:"mgmt.example.com"
|station. | |Msg Key: |
|*************************/| |tag=2065: 123 |
| | |Oper Attrs: |
| | |tag=2068: "NAMEabcd"
| | DDRegRsp-----> | |
| |SUCCESS | |
| |Msg Key: | |
| |tag=2065: 123 | |
| |Oper Attrs: | |
| |tag=2065: 123 | |
+--------------------------+------------------+-------------------+
The following example illustrates a new initiator registering with the iSNS, and discovering the target NAMEabcd from the example in A.1.2.
以下示例说明了一个新的启动器向iSNS注册，并从a.1.2中的示例中发现目标名称ABCD。
+--------------------------+------------------+-------------------+
| iSCSI Initiator | iSNS |Management Station |
+--------------------------+------------------+-------------------+
|Discover iSNS--SLP--> | |/*mgmt station is |
| |<--SLP--iSNS Here:| administratively |
| | 192.36.53.1 | authorized to view|
|DevAttrReg--> | | all DDs ********/ |
|Src: | | |
|tag=32: "NAMEijkl" | | |
|Msg Key: | | |
|tag=1: "svr1.example.com" | | |
|Oper Attrs: | | |
|tag=1: "svr1.example.com" | | |
|tag=2: "iSCSI" | | |
|tag=16: 192.20.3.1 |/*****************| |
|tag=17: 5001 |Device not in any | |
|tag=19: 5 |DD, so it is | |
|tag=20: 5002 |inaccessible by | |
|tag=32: "NAMEijkl" |other devices | |
|tag=33: "Initiator" |*****************/| |
|tag=34: "Server1" | | |
|tag=51: 11 | | |
|tag=49: 192.20.3.1 | | |
+--------------------------+------------------+-------------------+
| iSCSI Initiator | iSNS |Management Station |
+--------------------------+------------------+-------------------+
|Discover iSNS--SLP--> | |/*mgmt station is |
| |<--SLP--iSNS Here:| administratively |
| | 192.36.53.1 | authorized to view|
|DevAttrReg--> | | all DDs ********/ |
|Src: | | |
|tag=32: "NAMEijkl" | | |
|Msg Key: | | |
|tag=1: "svr1.example.com" | | |
|Oper Attrs: | | |
|tag=1: "svr1.example.com" | | |
|tag=2: "iSCSI" | | |
|tag=16: 192.20.3.1 |/*****************| |
|tag=17: 5001 |Device not in any | |
|tag=19: 5 |DD, so it is | |
|tag=20: 5002 |inaccessible by | |
|tag=32: "NAMEijkl" |other devices | |
|tag=33: "Initiator" |*****************/| |
|tag=34: "Server1" | | |
|tag=51: 11 | | |
|tag=49: 192.20.3.1 | | |
|tag=50: 5001 | | |
| |<--DevAttrRegRsp | |
| |SUCCESS | |
| |Msg Key: | |
| |tag=1: "svr1.example.com" |
| |Oper Attrs: | |
| |tag=1: "svr1.example.com" |
| |tag=2: "iSCSI" | |
| |tag=16: 192.20.3.1| |
| |tag=17: 5001 | |
| |tag=19: 5 | |
| |tag=20: 5002 | |
| |tag=32: "NAMEijkl"| |
| |tag=33: "Initiator" |
| |tag=34: "Server1" | |
| |tag=48: "NAMEijkl"| |
| |tag=49: 192.20.3.1| |
| |tag=50: 5001 | |
| |tag=51: 11 | |
| | | |
| | SCN------> | |
| | (or SNMP notification) |
| |dest:(tag=32)"mgmt.example.com" |
| |time:(tag=4): <current time> |
| |tag=35: "MGT-SCN, OBJ-ADD" |
| |tag=32: "NAMEijkl"| |
| | | |
| | |<------SCNRsp |
| | |SUCCESS |
| | tag=32:"mgmt.example.com"
| | | |
|SCNReg--> | | |
|Src: | | |
|tag=32: "NAMEijkl" | | |
|Msg Key: | | |
|tag=32: "NAMEijkl" | | |
|Oper Attrs: | | |
|tag=35: <TARG&SELF, OBJ-RMV/ADD/UPD> | |
| |<--SCNRegRsp | |
| |SUCCESS | |
| | | |
| | |<----DevAttrQry |
| | |Src: |
| | tag=32:"mgmt.example.com"
| | |Msg Key: |
| | |tag=32: "NAMEijkl" |
| | |Oper Attrs: |
| | |tag=16: <0-length> |
|tag=50: 5001 | | |
| |<--DevAttrRegRsp | |
| |SUCCESS | |
| |Msg Key: | |
| |tag=1: "svr1.example.com" |
| |Oper Attrs: | |
| |tag=1: "svr1.example.com" |
| |tag=2: "iSCSI" | |
| |tag=16: 192.20.3.1| |
| |tag=17: 5001 | |
| |tag=19: 5 | |
| |tag=20: 5002 | |
| |tag=32: "NAMEijkl"| |
| |tag=33: "Initiator" |
| |tag=34: "Server1" | |
| |tag=48: "NAMEijkl"| |
| |tag=49: 192.20.3.1| |
| |tag=50: 5001 | |
| |tag=51: 11 | |
| | | |
| | SCN------> | |
| | (or SNMP notification) |
| |dest:(tag=32)"mgmt.example.com" |
| |time:(tag=4): <current time> |
| |tag=35: "MGT-SCN, OBJ-ADD" |
| |tag=32: "NAMEijkl"| |
| | | |
| | |<------SCNRsp |
| | |SUCCESS |
| | tag=32:"mgmt.example.com"
| | | |
|SCNReg--> | | |
|Src: | | |
|tag=32: "NAMEijkl" | | |
|Msg Key: | | |
|tag=32: "NAMEijkl" | | |
|Oper Attrs: | | |
|tag=35: <TARG&SELF, OBJ-RMV/ADD/UPD> | |
| |<--SCNRegRsp | |
| |SUCCESS | |
| | | |
| | |<----DevAttrQry |
| | |Src: |
| | tag=32:"mgmt.example.com"
| | |Msg Key: |
| | |tag=32: "NAMEijkl" |
| | |Oper Attrs: |
| | |tag=16: <0-length> |
| | |tag=17: <0-length> |
| | |tag=32: <0-length> |
| | DevAttrQryRsp--->| |
| |SUCCESS | |
| |Msg Key: | |
| |tag=32: "NAMEijkl"| |
| |Oper Attrs: | |
| |tag=16:192.20.3.1 | |
| |tag=17: 5001 | |
| |tag=32:"NAMEijkl" | |
| | |/**Mgmt Station ***|
| | |displays device, the
| | |operator decides to|
| | |place "NAMEijkl" into
| | |pre-existing Disc |
| | |Domain "DDxyz" with|
| | |device NAMEabcd |
| | |******************/|
| | |<--DDReg |
| | |Src: |
| | tag=32:"mgmt.example.com"
| | |Msg Key: |
| | |tag=2065: 123 |
| | |Oper Attrs: |
| | |tag=2068: "NAMEijkl"
| | | |
| | DDRegRsp---->| |
| |SUCCESS | |
| |Msg Key: | |
| |tag=2065: 123 | |
| |Oper Attrs: | |
| |tag=2065: 123 |/******************|
| | |"NAMEijkl" has been|
| | |moved to "DDxyz" |
| | |******************/|
| | SCN------>| |
| |dest:(tag=32)"mgmt.example.com" |
| |time:(tag=4): <current time> |
| |tag=35: <MGT-SCN, DD/DDS-MBR-ADD> |
| |tag=2065: 123 | |
| |tag=2068: "NAMEijkl" |
| | | |
| | |<------SCNRsp |
| | |SUCCESS |
| | tag=32:"mgmt.example.com"
| |<-----SCN | |
| |dest:(tag=32)"NAMEijkl" |
| |time:(tag=4): <current time> |
| | |tag=17: <0-length> |
| | |tag=32: <0-length> |
| | DevAttrQryRsp--->| |
| |SUCCESS | |
| |Msg Key: | |
| |tag=32: "NAMEijkl"| |
| |Oper Attrs: | |
| |tag=16:192.20.3.1 | |
| |tag=17: 5001 | |
| |tag=32:"NAMEijkl" | |
| | |/**Mgmt Station ***|
| | |displays device, the
| | |operator decides to|
| | |place "NAMEijkl" into
| | |pre-existing Disc |
| | |Domain "DDxyz" with|
| | |device NAMEabcd |
| | |******************/|
| | |<--DDReg |
| | |Src: |
| | tag=32:"mgmt.example.com"
| | |Msg Key: |
| | |tag=2065: 123 |
| | |Oper Attrs: |
| | |tag=2068: "NAMEijkl"
| | | |
| | DDRegRsp---->| |
| |SUCCESS | |
| |Msg Key: | |
| |tag=2065: 123 | |
| |Oper Attrs: | |
| |tag=2065: 123 |/******************|
| | |"NAMEijkl" has been|
| | |moved to "DDxyz" |
| | |******************/|
| | SCN------>| |
| |dest:(tag=32)"mgmt.example.com" |
| |time:(tag=4): <current time> |
| |tag=35: <MGT-SCN, DD/DDS-MBR-ADD> |
| |tag=2065: 123 | |
| |tag=2068: "NAMEijkl" |
| | | |
| | |<------SCNRsp |
| | |SUCCESS |
| | tag=32:"mgmt.example.com"
| |<-----SCN | |
| |dest:(tag=32)"NAMEijkl" |
| |time:(tag=4): <current time> |
| |tag=35: <TARG&SELF, OBJ-ADD> |
| |tag=32: "NAMEijkl"| |
| SCNRsp------> | | |
|SUCCESS | | |
|tag=32:"NAMEijkl" | | |
| | | |
| |/*****************| |
| |Note that NAMEabcd| |
| |also receives an | |
| |SCN that NAMEijkl | |
| |is in the same DD | |
| |*****************/| |
| (to "NAMEabcd")|<-----SCN | |
| |dest:(tag=32)"NAMEabcd" |
| |time:(tag=4): <current time> |
| |tag=35: <INIT&SELF, OBJ-ADD> |
| |tag=32: "NAMEijkl"| |
| SCNRsp------> | | |
|SUCCESS | | |
|tag=32:"NAMEabcd" | | |
| | | |
| DevAttrQry----------->| | |
|Src: | | |
|tag=32: "NAMEijkl" | | |
|Msg Key: | | |
|tag=33: "Target" | | |
|Oper Attrs: | | |
|tag=16: <0-length> | | |
|tag=17: <0-length> | | |
|tag=32: <0-length> | | |
|tag=34: <0-length> | | |
|tag=43: <0-length> | | |
|tag=48: <0-length> | | |
|tag=49: <0-length> | | |
|tag=50: <0-length> | | |
|tag=51: <0-length> | | |
| |<--DevAttrQryRsp | |
| |SUCCESS | |
| |Msg Key: | |
| |tag=33:"Target" | |
| |Oper Attrs: | |
| |tag=16: 192.0.2.4 | |
| |tag=17: 5001 | |
| |tag=32: "NAMEabcd"| |
| |tag=34: "Storage Array 1" |
| |tag=16: 192.0.2.5 | |
| |tag=17: 5001 | |
| |tag=32: "NAMEabcd"| |
| |tag=35: <TARG&SELF, OBJ-ADD> |
| |tag=32: "NAMEijkl"| |
| SCNRsp------> | | |
|SUCCESS | | |
|tag=32:"NAMEijkl" | | |
| | | |
| |/*****************| |
| |Note that NAMEabcd| |
| |also receives an | |
| |SCN that NAMEijkl | |
| |is in the same DD | |
| |*****************/| |
| (to "NAMEabcd")|<-----SCN | |
| |dest:(tag=32)"NAMEabcd" |
| |time:(tag=4): <current time> |
| |tag=35: <INIT&SELF, OBJ-ADD> |
| |tag=32: "NAMEijkl"| |
| SCNRsp------> | | |
|SUCCESS | | |
|tag=32:"NAMEabcd" | | |
| | | |
| DevAttrQry----------->| | |
|Src: | | |
|tag=32: "NAMEijkl" | | |
|Msg Key: | | |
|tag=33: "Target" | | |
|Oper Attrs: | | |
|tag=16: <0-length> | | |
|tag=17: <0-length> | | |
|tag=32: <0-length> | | |
|tag=34: <0-length> | | |
|tag=43: <0-length> | | |
|tag=48: <0-length> | | |
|tag=49: <0-length> | | |
|tag=50: <0-length> | | |
|tag=51: <0-length> | | |
| |<--DevAttrQryRsp | |
| |SUCCESS | |
| |Msg Key: | |
| |tag=33:"Target" | |
| |Oper Attrs: | |
| |tag=16: 192.0.2.4 | |
| |tag=17: 5001 | |
| |tag=32: "NAMEabcd"| |
| |tag=34: "Storage Array 1" |
| |tag=16: 192.0.2.5 | |
| |tag=17: 5001 | |
| |tag=32: "NAMEabcd"| |
| |tag=34: "Storage Array 1" |
| |tag=43: X.509 cert| |
| |tag=48: "NAMEabcd"| |
| |tag=49: 192.0.2.4 | |
| |tag=50: 5001 | |
| |tag=51: 10 | |
| |tag=48: "NAMEabcd"| |
| |tag=49: 192.0.2.5 | |
| |tag=50: 5001 | |
| |tag=51: 10 | |
| | | |
|/***The initiator has discovered | |
|the target, and has everything | |
|needed to complete iSCSI login | |
|The same process occurs on the | |
|target side; the SCN prompts the | |
|target to download the list of | |
|authorized initiators from the | |
|iSNS (i.e., those initiators in the | |
|same DD as the target.************/ | |
+--------------------------+------------------+-------------------+
| |tag=34: "Storage Array 1" |
| |tag=43: X.509 cert| |
| |tag=48: "NAMEabcd"| |
| |tag=49: 192.0.2.4 | |
| |tag=50: 5001 | |
| |tag=51: 10 | |
| |tag=48: "NAMEabcd"| |
| |tag=49: 192.0.2.5 | |
| |tag=50: 5001 | |
| |tag=51: 10 | |
| | | |
|/***The initiator has discovered | |
|the target, and has everything | |
|needed to complete iSCSI login | |
|The same process occurs on the | |
|target side; the SCN prompts the | |
|target to download the list of | |
|authorized initiators from the | |
|iSNS (i.e., those initiators in the | |
|same DD as the target.************/ | |
+--------------------------+------------------+-------------------+
Acknowledgements
致谢
Numerous individuals contributed to the creation of this document through their careful review and submissions of comments and recommendations. We acknowledge the following persons for their technical contributions to this document: Mark Bakke (Cisco), John Hufferd (IBM), Julian Satran (IBM), Kaladhar Voruganti(IBM), Joe Czap (IBM), John Dowdy (IBM), Tom McSweeney (IBM), Jim Hafner (IBM), Chad Gregory (Intel), Yaron Klein (Sanrad), Larry Lamers (Adaptec), Jack Harwood (EMC), David Black (EMC), David Robinson (Sun), Alan Warwick (Microsoft), Bob Snead (Microsoft), Fa Yoeu (Intransa), Joe White (McDATA), Charles Monia (McDATA), Larry Hofer (McDATA), Ken Hirata (Vixel), Howard Hall (Pirus), Malikarjun Chadalapaka (HP), Marjorie Krueger (HP), Siva Vaddepuri (McDATA), and Vinai Singh (American Megatrends).
许多个人通过仔细审查和提交评论和建议，为本文件的编写做出了贡献。我们感谢以下人员对本文档所做的技术贡献：马克·巴克（Cisco）、约翰·赫费尔德（IBM）、朱利安·萨特兰（IBM）、卡拉达尔·沃鲁甘蒂（IBM）、乔·查普（IBM）、约翰·道迪（IBM）、汤姆·麦克斯韦尼（IBM）、吉姆·哈夫纳（IBM）、乍得·格雷戈里（英特尔）、亚龙·克莱因（桑拉德）、拉里·拉默斯（Adaptec）、杰克·哈伍德（EMC）、大卫·布莱克（EMC）、大卫·罗宾逊（Sun）、艾伦·沃里克（Microsoft）、鲍勃·斯奈德（Microsoft）、法·尤尤（Intransa）、乔·怀特（McDATA）、查尔斯·莫尼亚（McDATA）、拉里·霍弗（McDATA）、肯·海拉塔（Vixel）、霍华德·霍尔（Pirus）、马利卡君·查达拉帕卡（HP）、马乔里·克鲁格（HP）、西瓦·瓦迪普里（McDATA）和维奈·辛格（美国大趋势）。
Authors' Addresses
作者地址
Josh Tseng Riverbed Technology 501 2nd Street, Suite 410 San Francisco, CA 94107
Josh Tseng河床技术501第二街，套房410旧金山，CA 94107
Phone: (650)274-2109 EMail: joshtseng@yahoo.com
电话：（650）274-2109电子邮件：joshtseng@yahoo.com
Kevin Gibbons McDATA Corporation 4555 Great America Parkway Santa Clara, CA 95054-1208
Kevin Gibbons McDATA Corporation加利福尼亚州圣克拉拉大美洲大道4555号，邮编95054-1208
Phone: (408) 567-5765 EMail: kevin.gibbons@mcdata.com
电话：（408）567-5765电子邮件：凯文。gibbons@mcdata.com
Franco Travostino Nortel 600 Technology Park Drive Billerica, MA 01821 USA
Franco Travostino Nortel 600科技园大道，美国马萨诸塞州比尔里卡，邮编01821
Phone: (978) 288-7708 EMail: travos@nortel.com
电话：（978）288-7708电子邮件：travos@nortel.com
Curt du Laney Rincon Research Corporation 101 North Wilmot Road, Suite 101 Tucson AZ 85711
亚利桑那州图森市威尔莫特北路101号科特·杜拉尼·林康研究公司101室，邮编85711
Phone: (520) 519-4409 EMail: cdl@rincon.com
电话：（520）519-4409电子邮件：cdl@rincon.com
Joe Souza Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Joe Souza微软公司位于华盛顿州雷德蒙微软大道一号，邮编：98052-6399
Phone: (425) 706-3135 EMail: joes@exmsft.com
电话：（425）706-3135电子邮件：joes@exmsft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。