[要約] RFC 4171は、iSNS（Internet Storage Name Service）に関する規格であり、ストレージネットワークでのデバイスの発見と管理を目的としています。iSNSは、ストレージネットワークの効率性と信頼性を向上させるために設計されています。
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)
インターネットストレージネームサービス（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).
Copyright（C）The Internet Society（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クライアント間の対話に使用されるインターネットストレージネームサービス（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
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.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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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.
RESERVEDを含むすべての未使用のフィールドとビットマップは、送信時にゼロに設定し、受信時に無視する必要があります。
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に保存されているすべてのDDにアクセスできる特別なタイプのiSNSクライアントです。
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（インターネットSCSI）は、TCP / IP [iSCSI]で相互接続された新世代のストレージデバイス用のSCSIのカプセル化です。
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（インターネットFCP）は、TCP / IPを使用して既存のファイバーチャネルとSCSIデバイスを相互接続するように設計されたゲートウェイ間プロトコルです。 iFCPは、既存のFCP標準および関連するファイバーチャネルサービスをTCP / IP [iFCP]にマッピングします。
There are four main functions of the iSNS:
iSNSには4つの主な機能があります。
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で説明されているファイバーチャネルGeneric Services Name Serverをモデルにしており、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ログインまたはファイバーチャネルポートログイン）の数を減らし、ホストがストレージネットワークのサイズの拡大に応じてログイン関係の初期化に費やす時間を制限するために特に重要です。ストレージノードは、互いに関する情報を取得するために、少なくとも1つの共通の有効なDDに存在する必要があります。デバイスは同時に複数のDDのメンバーになることができます。
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 initiators that match the required identification and authorization provided by the iSNS will be allowed access by that target Node during session establishment.
ログイン制御により、ターゲットはアクセス制御/許可ポリシーをiSNSサーバーに委任できます。これは、iSNSサーバーを使用してこれらのストレージデバイスを集中管理するという目標と一致しています。ターゲットノードまたはデバイスは、許可されたイニシエーターのリストをiSNSからダウンロードします。各ノードまたはデバイスは、iSCSI名またはFCポート名によって一意に識別されます。 iSNSによって提供される必要なIDと許可に一致するイニシエーターのみが、セッションの確立中にそのターゲットノードによるアクセスを許可されます。
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をスコープとするクエリは、そのネットワークエンティティのすべてのポータルを報告する必要があります。ネットワークエンティティの1つ以上のポータルが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.
DDは、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セットステータス値が「有効」である「デフォルトDDS」に含まれる「デフォルトDD」に配置されることを決定する場合があります。これにより、デフォルトのDD内の他のデバイスに表示されます。他の実装は、それらがDDなしで登録され、ソーススコープのiSNSPメッセージにアクセスできないようにすることを決定してもよい（MAY）。
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.
有効でアクティブなディスカバリードメイン（DD）は、少なくとも1つのアクティブなディスカバリードメインセット（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登録には、通常の登録と管理登録の2つのタイプがあります。管理登録を行うと管理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登録は、Discovery Domain Serviceを使用して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クライアントをサポートするのに十分なハードウェアおよびソフトウェアリソースで実装する必要があります（SHOULD）。ただし、リソースが予期せず使い果たされた場合、iSNSサーバーはSCN Registration Rejected（ステータスコード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.
SCNをトリガーするイベントをiSNSサーバーが学習する特定の通知メカニズムは実装固有ですが、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名」を保存できます。このフィールドは、ファイバーチャネルデバイスがIPネットワーク内のiSCSIデバイスと通信するために使用されるiSCSI登録エントリにFCデバイスを関連付けるために使用されます。逆に、タグ37（6.1を参照）には、WWNNトークンフィールドが含まれています。これは、ファイバーチャネルドメイン内のiSCSIデバイスを表すためにiSCSI-FCゲートウェイで使用される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ゲートウェイ内に情報を格納するよりも利点が提供されます。ここでは、独自のメカニズムを除いて、他のデバイスからマッピングにアクセスできません。
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ターゲットは、iSNSサーバーにその存在を登録することにより、iSCSIイニシエーターが自身を検出できるようにします。また、リソース割り当ての目的でイニシエーターの追加または削除を検出するために、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デバイスIDからiSCSIデバイスIDへのマッピングを保存できます。 iSNSには、iSCSIデバイスとファイバーチャネルデバイスの両方のすべての属性を保存する機能があります。 iSCSIデバイスは、iSNSを使用した直接対話を通じて管理されますが、FCデバイスは、iSNS-FCゲートウェイとのiSNS対話を通じて間接的に管理できます。これにより、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_Portネットワークアドレスに関する情報を返します。
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 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サーバーと対話します。管理ステーションは、検出ドメインの操作を通じて、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
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の変更：指定されたタイプのノードがDDおよび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).
Service Location Protocol（SLP）は、iSNSサーバーを含むネットワークサービスの存在、場所、および構成に関する情報へのアクセスをホストに提供するための柔軟でスケーラブルなフレームワークを提供します。 iSNSクライアントはSLPを使用して、iSNSサーバーのIPアドレスまたはFQDNを検出できます。 SLPによるディスカバリーを実装するには、サービスエージェント（SA）をiSNSサーバーにホストし、ユーザーエージェント（UA）を各iSNSクライアントに配置する必要があります。各クライアントは、iSNSサーバーのIPアドレスを要求する検出メッセージをマルチキャストします。 SAはこの要求に応答します。オプションで、iSNSサーバーの場所をSLP Directory Agent（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]にあり、このドキュメントの範囲を超えていることに注意してください。 SLPを使用してiSNSサーバーを見つけるためのサービステンプレートは、[iSCSI-SLP]にあります。
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サーバーに保存され、DHCPオプションを使用してiSNSクライアントによってダウンロードされます。 iSNSサーバーの場所の配布に使用されるDHCPオプション番号は、[iSNSOption]にあります。
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.
iSNSハートビートメッセージについては、5.6.5.14項で説明します。これにより、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サーバーに格納されているIPアドレス情報は、iSNSクライアントのドメインで解釈されたときに正しくない可能性があります。
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クライアントは、アドレス指定情報を探すときに、エンティティIDフィールドに格納されている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.
2番目のアプローチは、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クライアントを排他的にサポートする可能性があることに注意してください。この場合、管理者は、iSNSクライアントがiSNSPセッションをiSNSサーバーに開始できるように、NATゲートウェイで適切なマッピングが構成されていることを確認するだけで済みます。したがって、iSNSサーバーに含まれるすべての登録済みアドレスは、NAT境界の外側で使用するためのパブリックIPアドレスです。 NAT境界の内側からサーバーにクエリを行うiSNSクライアントが存在しないように注意する必要があります。
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サーバー間でデータレコードを転送するための可能な方法を示しています。最初の例では、iSNSサーバーをサポートするためにバックエンドLDAP情報ベースが使用され、データは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
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".
上の図では、2つのビジネスパートナーがストレージ「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
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レコードを共有する方法の2番目の例を示しています。この方法では、SNMPベースの管理ステーションを使用して、「dev C」の目的のレコードを手動で取得（GET）し、ローカルのiSNSサーバーに直接格納（SET）します。レコードがネットワーク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サーバーの状態とステータスを監視する必要があります（SHOULD）。各バックアップサーバーがこれを達成する方法は実装に依存し、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.
同じ正規iSNS TCPまたはUDPポート番号でリッスンしている複数のサーバーからの競合を回避するために、最大1つの論理バックアップiSNSサーバーが個々のIPアドレスに存在する必要があります。
The iSNS heartbeat can also be used to coordinate the designation and selection of primary and backup iSNS servers.
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 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アドレスの順序付けられたリスト内のIPアドレスの位置に注目することにより、iSNSハートビートメッセージからそれを学習できます（MAY）。たとえば、ハートビートメッセージにリストされている最初のバックアップの場合、そのバックアップ優先順位は1です。リストされている3番目のバックアップサーバーの場合、そのバックアップ優先順位は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).
バックアップサーバーがアクティブサーバーと優先順位の高い他のバックアップサーバーへの接続を失ったと確立した場合、それはアクティブサーバーであると想定する必要があります。接続が失われたかどうかを判断する方法は、実装によって異なります。 1つの可能なアプローチは、バックアップサーバーが一定期間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ハートビートメッセージの送信（使用されている場合）を含むすべてのアクティブサーバーの責任を負うものとします（SHALL）。 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クライアントによる再登録は必要ありません。
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 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.
iSNS通信にTCPを使用できる必要があります。 iSNSサーバーは、クライアント登録のためにTCP接続を受け入れる必要があります。 Entity Status Inquiry（ESI）（セクション5.6.5.13を参照）を受信してTCPの使用を監視するために、クライアントはポータルESI間隔と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通知を受信するには、クライアントはiSCSIまたはiFCP SCNビットマップと、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メッセージを受け入れることができます（MAY）。 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監視メッセージを受信するには、クライアントは、iSNSサーバーからのESIメッセージの受信と応答に使用される少なくとも1つのポータルにUDPポートのポート番号を登録します。ネットワークエンティティに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通知メッセージを受信するために、クライアントは、iSNSサーバーからのSCNメッセージの受信に使用される少なくとも1つのポータルにUDPポートのポート番号を登録します。ネットワークエンティティに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が1つだけ含まれている必要があります（セクション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の両方のプロトコルには、iSCSI名など、128文字を超える識別子が含まれています。このような識別子をインデックスとして使用すると、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.
ネットワークエンティティオブジェクトは、ストレージノードオブジェクトとポータルオブジェクトのコンテナです。これは、1つ以上のストレージノードの一意のセットへのアクセスをサポートするインフラストラクチャを表します。エンティティID属性はネットワークエンティティを一意に識別し、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データベース内の複数の論理ネットワークエンティティによって表される可能性があることに注意してください。たとえば、物理デバイス上のストレージノードの1つは、そのデバイスで使用可能なネットワークインターフェースのサブセット（ポータルなど）からのみアクセスできます。この場合、論理ネットワークエンティティ（「シャドウエンティティ」）が作成され、連携して動作できるポータルとストレージノードを含めるために使用されます。オブジェクト（ポータル、ストレージノードなど）を複数の論理ネットワークエンティティに含めることはできません。
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サーバーにポータルオブジェクトを登録するために使用されるキーです。ポータルは1つだけのネットワークエンティティに含まれ、1つ以上のDDに含まれる場合があります（セクション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 Name属性はストレージノードを一意に識別し、iSNSサーバーにストレージノードオブジェクトを登録するために使用されるキーです。 iFCPの場合、FCポート名（WWPN）属性はストレージノードを一意に識別し、iSNSサーバーにストレージノードオブジェクトを登録するために使用されるキーです。ストレージノードは1つのネットワークエンティティオブジェクトにのみ含まれ、1つ以上のDDに含まれる場合があります（セクション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ノード間の関連付けを表します。エンティティに登録されている各ポータルとiSCSIストレージノードは、ポータルグループ（PG）オブジェクトを使用して関連付けることができます。 PGタグ（PGT）は、NULL以外の場合、関連するポータルがエンティティ内の関連する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.
PGオブジェクトは、ポータルまたはiSCSIストレージノードが登録されるときに登録される場合があります。各PortalとiSCSIノードの関連付けは、1つのPGオブジェクトのみで表されます。ポータルがiSCSIノードへのアクセスを提供するためには、PGオブジェクトのPGTはNULL以外でなければなりません。指定されたポータルとiSCSIノードに登録されているPGT値がNULLの場合、または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ポータルIPアドレス、およびPGポータル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ストレージノードまたはポータルオブジェクトを参照することによってのみ登録できます。既存のPGオブジェクトは、ポータルグループインデックスをメッセージキーとして使用するか、関連するiSCSIストレージノードまたはポータルオブジェクトを参照することで、変更または照会できます。長さ0のタグ、長さ、値TLVは、PGT NULL値を登録するために使用されます。
The PG object is deregistered if and only if its associated iSCSI Node and Portal objects are both removed.
PGオブジェクトは、関連付けられているiSCSIノードとポータルオブジェクトの両方が削除された場合にのみ登録解除されます。
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デバイスは、1つ以上のストレージノードオブジェクトに含まれています。
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クライアントによるクエリは、少なくとも1つのアクティブな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は、少なくとも1つのアクティブなDDセットのメンバーである場合、アクティブと見なされます。少なくとも1つの有効なDDSのメンバーではないDDは無効と見なされます。ストレージノードは、1つ以上のDDのメンバーになることができます。有効な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）は、探索ドメイン（DD）のコンテナーオブジェクトです。 DDSには1つ以上のDDが含まれる場合があります。同様に、各DDは1つ以上のDDSのメンバーになることができます。 DDSは、調整されたDDマッピングのセットをiSNSサーバーに格納するメカニズムです。アクティブDDは、少なくとも1つのアクティブ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 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.
iSNSクライアントに提示されるように、iSNSデータベース内の特定のタイプの各オブジェクトには、そのオブジェクトタイプのキーに基づく暗黙的な内部線形順序が必要です。この順序は、DevGetNextクエリに応答する機能を提供します（セクション5.6.5.3を参照）。オブジェクトの挿入と削除の結果として、iSNSデータベース内のオブジェクトの順序は、暗黙の順序に関して変更してはなりません（SHOULD NOT）。つまり、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 |
+-----------+ +--------------+ +-----------+ +-----------+
* 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.
iSCSIをサポートするiSNSの使用はオプションです。 iSCSIデバイスは、iSNSの支援や介入なしに、ピアデバイスのiSCSI名とIPアドレスを使用して手動で構成できます。 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をサポートするために、次の属性を使用できます。 REQUIRED for Server列に示されている属性は、iSCSIのサポートに使用されるiSNSサーバーによって実装する必要があります。 REQUIRED for Client列に示されている属性は、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
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 *
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 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 |
| | | |
+-------------------------+ +-------------------------+
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 |
| |
+---------------------------------------------------------------+
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は、PGT 10のポータル1を介してアクセスできます。ポータル2に割り当てられたポータルグループタグ（PGT）がないため、ストレージノード1はポータル2を介してアクセスできません。
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].
ストレージノード2は、ポータル1とポータル2の両方を介してアクセスできます。ストレージノード2は、同じPGT値がポータル1とポータル2の両方に割り当てられているため、この場合は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.
ストレージノード3には、ポータル1またはポータル2を介してアクセスできます。ただし、ストレージノード3には、各ポータル（この場合は10と30）に異なるPGT値が割り当てられているため、アクセスは調整されません[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のサポートで利用できます。 REQUIRED for Server列に示されているメッセージは、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
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 * 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をサポートするために使用する属性を示しています。 REQUIRED for Server列に示されている属性は、iFCPをサポートするiSNSサーバーで実装する必要があります。 REQUIRED for Client列に示されている属性は、iFCPゲートウェイでサポートされている必要があります。 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
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 *
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 DDS ID * *
SET DDS Symbolic Name *
DDS Status *
OTHER Switch Name Preferred_ID Assigned_ID Virtual_Fabric_ID
OTHERスイッチ名Preferred_ID割り当て済み_ID Virtual_Fabric_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プロトコルにより、iFCPゲートウェイに接続されたネイティブファイバーチャネルデバイスまたはファイバーチャネルファブリックを、IPを使用して直接インターネットワーキングすることができます。
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.
次の図は、背後にある複数のファイバーチャネルデバイスをサポートするゲートウェイを表しています。 2つのポータルオブジェクトは、その背後にある3つのストレージノードオブジェクトのいずれかにアクセスするために使用できるiFCPゲートウェイ上のIPインターフェイスを表します。 FCデバイスオブジェクトはネットワークエンティティオブジェクトに含まれていないことに注意してください。ただし、各FCデバイスには、1つ以上のストレージノードオブジェクトとの関係があります。
+--------------------------------------------------------+
| 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ゲートウェイをサポートするために使用できます。 REQUIRED TO IMPLEMENT列に示されているメッセージは、iFCPゲートウェイが使用するiSNSサーバーでサポートされている必要があります。 REQUIRED TO USE列に示されているメッセージは、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
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 * 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などの他の一般的なプロトコルのフォーマットに似ています。 iSNSPメッセージは、1つ以上のiSNSプロトコルデータユニット（PDU）で送信できます。各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
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 VERSION、FUNCTION ID、PDU LENGTH、FLAGS、TRANSACTION ID、およびSEQUENCE 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.
FUNCTION 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.
iSNSPコマンドまたは応答メッセージへのFUNCTION_ID値のマッピングについては、適切なプロトコル（iSCSIまたはiFCPなど）のセクション4を参照してください。 iSNSPメッセージを構成するすべてのPDUは、同じFUNCTION_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 Lengthは、PDU PAYLOADフィールドの長さをバイト単位で指定します。 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
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 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は、同時に未処理の要求メッセージごとに一意の値に設定する必要があります。返信では、関連付けられたiSNSリクエストメッセージと同じTRANSACTION ID値を使用する必要があります。メッセージが再送信される場合、元のトランザクションID値を使用する必要があります。 iSNSPメッセージを構成するすべてのPDUは、同じTRANSACTION 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.
SEQUENCE IDには、1つのトランザクション内の各PDUに一意の値があります。特定のiSNSメッセージで送信される最初のPDUのSEQUENCE_ID値はゼロ（0）である必要があり、各PDUの各SEQUENCE_ID値は、PDUが送信される順序で順番に番号が付けられなければなりません（MUST）。 2バイトのシーケンス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メッセージは、1つ以上のiSNS PDUで伝送されます。 iSNSメッセージを運ぶために1つのiSNS PDUのみを使用する場合、FLAGSフィールドのビット21（最初のPDU）とビット20（最後のPDU）の両方を設定する必要があります。複数のPDUを使用してiSNSメッセージを伝送する場合、ビット21をメッセージの最初のPDUに設定し、ビット20を最後のPDUに設定する必要があります。
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は、同じFUNCTION_IDとTRANSACTION_IDの値を持つ必要があります。 iSNSPメッセージを構成する各PDUは、一意のSEQUENCE_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 PAYLOADは可変長であり、登録およびクエリ操作に使用される属性が含まれています。属性データ項目は、DHCP [RFC2131]オプションなど、他のプロトコルと同様の形式を使用します。各iSNS属性は、以下に示すように、Tag-Length-Value（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
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.
属性タグ：セクション6.1で定義されている属性を識別する4バイトのフィールド。このフィールドには、示されたテーブルのタグ値が含まれています。
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.
属性長：TLVで後に続く値フィールドの長さ（バイト単位）を示す4バイトのフィールド。可変長属性の場合、値フィールドには、必要に応じて、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は、1つ以上の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で提供されるパッドバイト数の明示的なカウントはありません。
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応答メッセージには、iSNSP PDU PAYLOADの最初のフィールドとして4バイトのステータスコードフィールドが含まれています。元のiSNSP要求メッセージがiSNSサーバーによって、またはESNSおよびSCNメッセージのiSNSクライアントによって正常に処理された場合、このフィールドにはステータスコード0（成功）が含まれている必要があります（SHALL）。ゼロ以外のステータスコードは、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
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は認証機能を提供します。次のセクションでは、SLP認証ブロック[RFC2608]と形式が同じであるiSNS認証ブロックについて詳しく説明します。 iSNSユニキャストメッセージには認証ブロックを含めるべきではなく（SHOULD NOT）、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ヘッダーのFLAGSフィールドの「Authentication block present」ビットを有効にする必要があります。
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.
PKIが[X.509]認証局（CA）で利用可能な場合、iSNSサーバーの公開鍵認証が可能です。認証ブロックは、公開鍵インフラストラクチャに簡単に統合できるSHA-1アルゴリズムを備えたDSAを活用します。
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
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.
BLOCK STRUCTURE DESCRIPTOR（BSD）：STRUCTURED AUTHENTICATORに使用する構造とアルゴリズムを定義します。 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.
AUTHENTICATION BLOCK LENGTH：BSDフィールドから始まり、STRUCTURED AUTHENTICATORの最後のバイトまで続く、認証ブロックの長さを定義します。
TIMESTAMP: This is an 8-byte unsigned, fixed-point integer giving the number of seconds since 00:00:00 GMT on January 1, 1970.
TIMESTAMP：これは、1970年1月1日の00:00:00 GMTからの秒数を示す8バイトの符号なし固定小数点整数です。
SPI STRING LENGTH: The length of the SPI STRING field.
SPI STRING LENGTH：SPI STRINGフィールドの長さ。
SPI STRING (Security Parameters Index): Index to the key and algorithm used by the message recipient to decode the STRUCTURED AUTHENTICATOR field.
SPI STRING（セキュリティパラメータインデックス）：STRUCTURED AUTHENTICATORフィールドをデコードするためにメッセージ受信者が使用するキーとアルゴリズムへのインデックス。
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].
STRUCTURED AUTHENTICATOR：デジタル署名が含まれています。デフォルトのBSD値0x0002の場合、このフィールドには、[RFC3279]のセクション2.2.2で指定されている、SHA-1署名計算によるDSAからの出力値のバイナリASN.1エンコーディングが含まれている必要があります（SHALL）。
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) |
+----------------------------------------+
| . . . |
+----------------------------------------+
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 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.
各ソース、メッセージキー、デリミタ、およびオペレーティング属性は、タグ長値（TLV）データ形式を使用してPDUペイロードで指定されます。 iSNS登録およびクエリメッセージは、iSNSクライアントによって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.
ソース属性は、ソースの識別を必要とするクエリやその他のメッセージに対して、iSNSサーバーに対してストレージノードを識別するために使用されます。ソース属性は、メッセージのソースを一意に識別します。有効なソース属性タイプを以下に示します。
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サーバーは、ソース属性が、追加、削除、または変更されたオブジェクトを含むネットワークエンティティの一部であるコントロールノードまたはストレージノードを識別することを確認する必要があります。
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, all containing zeros). If a Message Key is not required for a message, then the Delimiter Attribute immediately follows the Source Attribute.
デリミタ属性は、PDUペイロードの操作属性からメッセージキー属性を分離します。区切り文字属性のタグ値は0、長さ値は0です。区切り文字属性は常に8バイトの長さです（4バイトのタグフィールドと4バイトの長さフィールド、すべてゼロを含みます）。メッセージにメッセージキーが不要な場合、デリミタ属性はソース属性の直後に続きます。
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登録または実行されているクエリ操作に関連する1つ以上のキー属性と非キー属性のリストです。
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オブジェクトを一意に識別します。鍵属性は、操作属性の各オブジェクトの非鍵属性の前になければなりません。タグ値は、属性をオブジェクトキー属性（つまり、tag = 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（メッセージフォーマットエラー）で拒否されるものとします（SHALL）。適切な操作属性の順序付け要件については、メッセージの説明を参照してください。
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.
QueryおよびGet Next要求メッセージでは、長さの値が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フィールドの置換ビットの値は、DevAttrRegメッセージが既存の登録を更新するか、置き換えるかを決定します。
The Source Attribute identifies the Node initiating the registration request.
ソース属性は、登録要求を開始するノードを識別します。
The Message Key identifies the object the DevAttrReg message acts upon. It MUST contain the key attribute(s) identifying an object. This object MUST contain all attributes and related subordinate object attributes that will be included in the Operating Attributes of the DevAttrReg PDU Payload. The key attribute(s) identifying this object MUST also be included among the Operating Attributes.
メッセージキーは、DevAttrRegメッセージが作用するオブジェクトを識別します。オブジェクトを識別するキー属性が含まれている必要があります。このオブジェクトには、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が含まれ、既存のオブジェクトがメッセージキーと一致しない場合、DevAttrRegメッセージは、指定されたEIDと新しいオブジェクトを操作属性で指定された新しいエンティティを作成するものとします（SHALL）。置換ビットは無視する必要があります。
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（無効な登録）で拒否される必要があります（SHALL）。
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.
置換ビットは、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.
置換ビットが設定されている場合、操作属性で指定されたオブジェクト、属性、および関係は、メッセージキーで識別されたオブジェクトを置換するものとします（SHALL）。オブジェクトとそのすべての従属オブジェクトは登録解除される必要があり（SHALL）、登録解除されたオブジェクトのiSNSサーバーによって適切なSCNが送信される必要があります（SHALL）。次に、動作属性にリストされているオブジェクトを使用して、登録を解除したばかりのオブジェクトを置き換えます。必要に応じて、新しく登録されたオブジェクトに対して追加の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.
置換ビットが設定されていない場合、メッセージはメッセージキーによって識別されるオブジェクトとその従属オブジェクトの属性を更新します。既存のオブジェクト包含関係は変更してはなりません。既存のオブジェクトの場合、キー属性は変更してはなりません（MUST NOT）が、新しい従属オブジェクトを追加してもよい（MAY）。
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メッセージに登録される場合があります。このメッセージ内のオブジェクトの順序は、登録されるオブジェクトの構造とオブジェクト間の関連付けを示します。少なくとも1つのオブジェクトが操作属性にリストされている必要があります。追加のオブジェクト（存在する場合）は、リストされている最初のオブジェクトに従属している必要があります。キー属性は、各オブジェクトの非キー属性の前にある必要があります。特定のオブジェクトは、メッセージの操作属性に最大1回しか表示されません。ソース属性によって識別されるノードがコントロールノードでない場合、操作属性のオブジェクトは、ソースノードと同じネットワークエンティティのメンバーである必要があります。
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オブジェクトの登録は、DevAttrRegメッセージのポータルまたは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属性の後には、示されたPGT値を使用してポータルに関連付けられるノードを表すPG iSCSI名のセットが続く必要があります（SHALL）。登録されたポータルに関連付けられる追加の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属性の後には、示されたPGT値を使用してストレージノードに関連付けられるポータルオブジェクトを表すPGポータルIPアドレス、PG TCP / UDPポートのペアのセットが続く必要があります（SHALL）。登録されたストレージノードに関連付ける追加のPGTとPGポータルIPアドレスPG TCP / UDPポートペアのセットが続く場合があります。示されたPGT値は、動作属性のPGT属性の直後に参照される、新しく登録されたiSCSIストレージノードおよびポータルオブジェクトに関連付けられたPGオブジェクトに割り当てられます。
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で登録する必要があります（SHALL）。 PGT属性が長さ0のTLVとして登録メッセージに含まれている場合、対応するPGオブジェクトのPGT値はNULLとして登録される必要があります。更新登録メッセージのPGTの長さが0のTLVは、以前のPGT値をNULLで上書きします。これは、ストレージノードとポータルの間に関係がないことを示します。
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メッセージで最大1つのネットワークエンティティオブジェクトを作成または更新できます。したがって、運用属性に複数のネットワークエンティティオブジェクトを含めることはできません。動作属性にリストできるポータル、ストレージノード、および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 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属性が含まれていない場合、またはEID属性の長さが0の場合、新しいネットワークエンティティオブジェクトが作成され、iSNSサーバーはその一意のEID値を提供する必要があります。割り当てられたEID値は、DevAttrReg応答メッセージに含まれる必要があります。メッセージキーと操作属性に、iSNSデータベース内の既存のネットワークエンティティのEIDと一致しないEIDが含まれている場合、新しいネットワークエンティティが作成され、そのEID属性に含まれる値が割り当てられる必要があります。最後に、メッセージキーと操作属性に、iSNSデータベース内の既存のオブジェクトのEIDと一致するEIDが含まれている場合、操作属性で指定されたオブジェクト、属性、および関係を、EIDで識別される既存のネットワークエンティティに追加する必要があります（SHALL）。 。
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).
新しいネットワークエンティティオブジェクトを作成する登録メッセージには、少なくとも1つのポータルまたは1つのストレージノードが含まれている必要があります。メッセージがそうでない場合は、それは無効であると見なされ、ステータスコード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間隔などの特定の属性の登録を変更または拒否する場合があることに注意してください。さらに、iSNSサーバーは、EIDやWWNNトークンなど、元のDevAttrRegメッセージに明示的に登録されていない追加の操作属性に値を割り当てる場合があります。
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.
ソース属性は、リクエストを開始するノードを識別します。 DevAttrQryメッセージを開始する非制御ノードの場合、クエリのスコープは、開始ノードがメンバーであるディスカバリードメインです。 DevAttrQryメッセージは、ストレージノードとそれらに関連する親および従属オブジェクトに関する情報のみを返す必要があります（SHALL）。ストレージノードには、ソース属性で識別されたノードとの共通のディスカバリドメインがあります。
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 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.
DevAttrQry応答メッセージは、元のDevAttrQryメッセージのメッセージキーに関連する動作属性にリストされているオブジェクトの属性を返します。 DevAttrQryメッセージの動作属性には、DevAttrQryRspメッセージで返される属性を指定する長さがゼロのTLVが含まれています。長さがゼロの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がNULLでない場合、示されたストレージノードとポータルの間に関係が存在します。 PGTがNULLの場合、関係は存在しません。したがって、各ポータルグループオブジェクトのPGT属性の値（NULLまたはNULLではない）によって、ストレージノードとポータルのクエリに対する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データベースには、2つのポータルと2つのノードを持つネットワークエンティティが含まれています。各ストレージノードには2つのポータルグループがあり、1つは1つのポータルのNULL PGT値を持ち、もう1つは他のポータルのNULL以外のPGT値を持ちます。 DevAttrQryメッセージには、ノードの1つに一致するメッセージキーエントリと、最初にノード属性、ポータル属性、次にPG属性をリストする長さゼロのTLVを持つ動作属性が含まれます。したがって、応答メッセージは最初に一致するノードオブジェクトを返し、次にストレージノードへのアクセスに使用できる1つのポータルオブジェクトの要求された属性（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 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).
メッセージキー属性に長さ0のTLVが含まれている場合、クエリはメッセージキータイプに一致するすべてのオブジェクトに対して要求された属性を返します（非制御ノードにはDD制限が適用される必要があります（SHALL））。複数のオブジェクトがメッセージキータイプに一致する場合、メッセージキーに一致する各オブジェクトの属性をリストしてから、次の一致するオブジェクトの属性をクエリ応答にリストする必要があります。つまり、長さ0の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データベースには、2つのポータルと3つのノードを持つネットワークエンティティが1つだけ含まれています。エンティティ内のすべてのPGオブジェクトのPGT値は0x00000001です。 DevAttrQryメッセージのメッセージキーには、ノードタイプを指定する長さ0のTLVと、最初にノード属性、次にポータル属性をリストする操作属性が含まれています。応答メッセージは、最初、次、最後のノードオブジェクトの属性を次の順序で返し、それぞれに両方のポータルの属性が続きます。その同じDevAttrQryメッセージに代わりにネットワークエンティティタイプを指定する長さゼロのTLVが含まれていた場合、応答メッセージは3つのノードオブジェクトすべての属性を返し、その後に2つのポータルの属性が返されます。
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制限が適用される必要があります（SHALL））。動作属性の各長さゼロのTLVで指定されたタイプと一致するすべての属性がリストされます。各タイプのすべての属性は、次の長さゼロのTLVと一致する属性がリストされる前にリストされなければなりません（SHALL）。
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データベースには2つのエンティティが含まれ、それぞれに2つのノードと2つのポータルがあります。 DevAttrQryメッセージにはメッセージキー属性が含まれておらず、操作属性は最初にポータル属性、次にノード属性のリストです。応答メッセージの操作属性は、4つのポータルのそれぞれから属性を返し、続いて4つのノードのそれぞれから属性を返します。
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, 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.
DDメンバーシップは、DDメンバー属性（つまり、DDメンバーiSCSIインデックス、DDメンバーiSCSIノード、DDメンバーiFCPノード、DDメンバーポータルインデックス、DDメンバーポータルIPアドレス、およびDDメンバーポータルTCP /のいずれかを含めることにより、DevAttrQryメッセージを通じて検出できます。 UDP）またはオペレーティング属性のストレージノードまたはポータルのオブジェクトキー（iSCSI名、iSCSIインデックス、ポータルIPアドレス、ポータルTCP / UDPポート、およびポータルインデックス）。 DDメンバー属性を使用すると、DDの登録済みと未登録の両方のメンバーストレージノードやポータルが返される必要があります（SHALL）。ストレージノードまたはポータルオブジェクトキー、あるいはその両方を使用するDevAttrQryメッセージは、現在iSNSデータベースに登録されているメンバーストレージノードまたはポータルのみを返す必要があります。
The DevAttrQry message SHALL support the following minimum set of Message Key Attributes:
DevAttrQryメッセージは、以下のメッセージキー属性の最小セットをサポートするものとします（SHALL）。
Valid Message Key Attributes for Queries
----------------------------------------
Entity Identifier
Entity Protocol
Portal IP-Address & Portal TCP/UDP Port
Portal Index
iSCSI Node Type
iSCSI Name
iSCSI Index
PG Index
FC Port Name WWPN
FC Port Type
FC-4 Type
Discovery Domain ID
Discovery Domain Set ID
Source Attribute (for server-specific attributes)
Switch Name (FC Device WWNN--for Virtual_Fabric_ID queries)
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です。このメッセージは、オブジェクトタイプのすべてのインスタンスを1回だけ取得する手段を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.
ソース属性は、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長がゼロの場合、メッセージキータイプと一致するiSNSデータベースの最初のオブジェクトエントリは、対応するDevGetNextRspメッセージのメッセージキーに返される必要があります。メッセージキーに長さがゼロでない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応答メッセージで返される次のオブジェクトの属性を指定できます。すべての操作属性は、メッセージキーで識別されるオブジェクトタイプの属性でなければなりません。たとえば、メッセージキーがEntity_ID属性の場合、運用属性にポータルの属性を含めてはなりません（MUST NOT）。
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メッセージのスコープに使用されます。長さがゼロ以外のTLV属性と一致する属性値を持つ次のオブジェクトのみが、DevGetNext応答メッセージで返される必要があります。
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メッセージを使用して取得した情報が正確で最新であることを確認する責任があります。連続するDevGetNextリクエストメッセージ間でiSNSデータベースが変更されないという保証はありません。提供されたメッセージキーが既存のデータベースエントリと一致しない場合、提供されたメッセージキーに続く次のオブジェクトキーの属性が返される必要があります。たとえば、連続する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データベースからオブジェクトエントリを削除するために使用されます。 1つ以上のオブジェクトは、単一の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
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通知を受信する必要があります（SHALL）。 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
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.
SCNRegメッセージのメッセージキーと一致するiSCSI名またはFCポート名のWWPN属性を持つノードは、指定されたSCNビットマップを使用してSCNを受信するように登録されます。 SCNRegメッセージごとに最大1つのノードを登録する必要があります。
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
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.
SCNDeregメッセージのメッセージキー属性と一致するiSCSI名またはFCポート名WWPN属性を持つノードは、SCNから登録解除されます。そのようなノードのSCNビットマップフィールドはクリアされます。 SCNDeregメッセージごとに最大1つのノードの登録を解除する必要があります。
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です。 SCNEventは、iSNSサーバーによる状態変更通知（SCN）メッセージの生成を要求するためにiSNSクライアントによって送信されるメッセージです。 iSNSサーバーによって送信されたSCNは、影響を受けるDD内のiFCP、iSCSI、および制御ノードに、SCNEventで示された変更を通知します。
Most SCNs are automatically generated by the iSNS server when Nodes are registered or deregistered from the directory database. SCNs are also generated when a network management application or Control Node makes changes to the DD membership in the iSNS server. However, an iSNS client can trigger an SCN by using SCNEvent.
ほとんどのSCNは、ノードがディレクトリデータベースに登録または登録解除されるときに、iSNSサーバーによって自動的に生成されます。 SCNは、ネットワーク管理アプリケーションまたは制御ノードがiSNSサーバーのDDメンバーシップに変更を加えたときにも生成されます。ただし、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ペイロードには、ソース属性、メッセージキー属性、および操作属性が含まれます。 SCNEventの有効なキー属性を以下に示します。
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イベントビットマップ属性が含まれている必要があります。ビットマップは、SCNEventが生成される原因となったイベントを示します。
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登録には、通常の登録と管理登録の2つのタイプがあります。通常の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ポートの値が登録されている登録済みストレージノードの1つのポータルに送信する必要があります。ストレージノードの複数のポータルにSCNポート値が登録されている場合、選択されたポータルがSCNの対象ではない場合、SCNは指定されたポータルのいずれかに配信される必要があります（SHALL）。
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イベントビットマップによって異なります。 iSCSIノードSCNビットマップについては、セクション6.4.4で説明します。 iFCP SCNビットマップについては、セクション6.6.12で説明しています。
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) |
+----------------------------------------+
| . . . |
+----------------------------------------+
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.
宛先属性は、SCNを受信するノード識別子です。宛先属性は、iSCSI名またはFCポート名にすることができます。
The Timestamp field, using the Timestamp TLV format, described in Section 6.2.4, indicates the time the SCN was generated.
セクション6.2.4で説明されているTimestamp TLV形式を使用するTimestampフィールドは、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、あるいはその両方をリストする必要があります（SHALL）。これらの追加の属性（つまり、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.
たとえば、特定のiSCSIターゲットで使用可能な新しいポータルをiSNSクライアントに通知するための通常のSCNには、SCNビットマップと、それに続くソース属性としてターゲットデバイスのiSCSI名が含まれます。 SCNが管理SCNの場合、iSCSI名の後に共有ディスカバリドメインのDD_IDが続き、宛先ストレージノードが影響を受けるストレージノードを認識できるようになります。この可視性を提供するためにディスカバリードメインセット（DDS）が有効になっている場合、適切なDDS_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.
DDは、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メッセージを拒否する必要があります（SHALL）。 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）の作成を試行する必要があります（SHALL）。 DD_ID属性（長さがゼロ以外）がDDRegメッセージの操作属性に含まれている場合、新しい検出ドメインには、そのDD_ID属性に含まれている値が割り当てられる必要があります（SHALL）。それ以外の場合、DD_ID属性がDDRegメッセージの操作属性に含まれていない場合、またはDD_IDがTLV長が0の操作属性である場合、iSNSサーバーはDD_ID値を割り当てる必要があります（SHALL）。次に、割り当てられたDD_ID値がDDReg応答メッセージで返されます。動作属性には、DDメンバーiSCSIノードインデックス、DDメンバーiSCSI名、DDメンバーFCポート名、DDメンバーポータルIPアドレス、DDメンバーポータルTCP / UDPポート番号、または追加するメンバーのDDメンバーポータルインデックスも含めることができます。 DD。また、DDのDD_Symbolic_NameまたはDD_Features、あるいはその両方が含まれる場合もあります。
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_IDで指定されたディスカバリドメインに操作属性としてリストされているDDメンバーを追加するものとします（SHALL）。 DD_Features属性がオペレーティング属性である場合、指定されたDDの機能リストとしてiSNSサーバーに格納する必要があります。 DD_Symbolic_Nameが操作属性であり、その値が一意である（つまり、別のDDの登録済みDD_Symbolic_Nameと一致しない）場合、値は、指定したディスカバリードメインのDD_Symbolic_NameとしてiSNSデータベースに格納する必要があります（SHALL）。 DD_Symbolic_Nameの値が一意でない場合、iSNSサーバーは、ステータスコード3（無効な登録）で試行されたDD登録を拒否する必要があります（SHALL）。
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_Symbolic_Nameが操作属性に含まれていない場合、または長さがゼロのTLVに含まれている場合、iSNSサーバーは、作成されたDDに一意のDD_Symbolic_Name値を提供する必要があります。割り当てられたDD_Symbolic_Name値は、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_Features属性が運用属性に含まれていない場合、iSNSサーバーはデフォルト値を割り当てる必要があります（SHALL）。 DD_Featuresのデフォルト値は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データベースエントリと一致する必要はありません。これにより、たとえば、ストレージノードが現在iSNSデータベースに登録されていない場合でも、ストレージノードをDDに追加できます。これにより、ストレージノードまたはポータルがストレージネットワークで現在アクティブではない場合でも、DDの作成時にストレージノードまたはポータルを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ノードインデックスは、DDメンバーiSCSIノードインデックスとしてDDRegRspメッセージで返される必要があります。割り当てられたiSCSIノードインデックス値は、iSNSデータベースに登録される場合、ストレージノードに割り当てられる必要があります（SHALL）。
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アドレスとDDメンバーポータルTCP / UDP値が動作属性に含まれている場合、iSNSサーバーはそのポータルに未使用のポータルインデックス値を割り当てる必要があります。割り当てられたポータルインデックス値は、DDメンバーポータルインデックスとしてDDRegRspメッセージで返される必要があります。割り当てられたポータルインデックス値は、iSNSデータベースに登録する場合、ポータルに割り当てる必要があります（SHALL）。
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メンバーポータルインデックスは、それらのストレージノードまたはポータルがiSNSデータベースにアクティブに登録されていない限り、DDにストレージノードまたはポータルを追加するために使用しないでください。
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.
DDは、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の既存のメンバーは、削除したばかりのDDのメンバーシップなしでiSNSデータベースに残る必要があります（SHALL）。
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_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メッセージを拒否する必要があります（SHALL）。 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 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.
メッセージキーのないDDSRegメッセージは、新しい検出ドメインセット（DDS）の作成を試行する必要があります（SHALL）。 DDSRegメッセージの操作属性に（長さがゼロ以外の）DDS_ID属性が含まれている場合、新しい検出ドメインセットには、そのDDS_ID属性に含まれている値を割り当てる必要があります（SHALL）。それ以外の場合、DDS_ID属性がDDSRegメッセージの操作属性に含まれていない場合、またはDDS_IDがTLV長が0の操作属性である場合、iSNSサーバーはDDS_ID値を割り当てる必要があります（SHALL）。次に、割り当てられたDDS_ID値がDDSReg応答メッセージで返されます。運用属性には、DDSに追加するDDS_Symbolic_Name、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シンボリック名と一致しない）場合、値は次のようにiSNSデータベースに格納する必要があります。そのDDSのDDSシンボリック名。 DDSシンボリック名の値が一意でない場合、iSNSサーバーは、ステータスコード3（無効な登録）で試行されたDDS登録を拒否するものとします（SHALL）。
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シンボリック名の値は、DDSRegRspメッセージで返される必要があります。
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.
このメッセージは、DDS_IDメッセージキー属性で指定されたディスカバリドメインセットに、動作属性としてリストされているDD_IDを追加する必要があります（SHALL）。さらに、DDS_Symbolic_Nameが操作属性であり、値が一意である場合、指定された検出ドメインセットのDDS_Symbolic_NameとしてiSNSデータベースに格納する必要があります（SHALL）。
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を作成する必要があります（SHALL）。この場合、新しいDDの場合、iSNSサーバーはDDシンボリック名に一意の値を割り当てなければならず（SHALL）、DD Features属性をデフォルト値の0に設定する必要があります。これらの割り当てられた値は、DDSRegRspメッセージで返される必要があります（SHALL）。
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から一部のDDを削除したりできます。
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 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.
DDSDeregメッセージのメッセージキー属性は、削除されるDDSまたはメンバーが削除されるDDSのDDS IDです。 DDS IDが既存のDDSと一致し、操作属性がない場合は、DDSを削除して、成功ステータスコードを返す必要があります。そのDDSの既存のメンバーは、削除したばかりのDDSのメンバーシップなしでiSNSデータベースに残る必要があります（SHALL）。
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 |
+----------------------------------------+
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データベースから削除する必要があります（SHALL）。関連付けられているネットワークエンティティに他の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サーバーの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 |
+------------------------------------------------+
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に設定され、次の2バイトは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から始まるカウント。このサーバーがアクティブになってから送信されたハートビートごとに、カウントは1ずつ増加します。
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_DOMAIN_ID値を割り当てるために使用されます。iSNSサーバーは、iFCPファブリック全体のアドレス割り当て権限になります。複数のFC_DOMAIN_ID値を取得するには、この要求をiSNSサーバーに対して複数回繰り返す必要があります。 FC_DOMAIN_ID値をiSNSサーバーから取得する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ペイロードには、3つのTLV属性が次の順序で含まれています。要求元のスイッチ名（WWN）がソース属性、Virtual_Fabric_IDがメッセージキー属性、優先IDが操作属性。 Virtual_Fabric_IDは、iSNSサーバーが1〜239の重複しない整数FC_DOMAIN_ID値を割り当てる必要があるドメインスペースを識別する文字列です。Preferred_IDは、iSNSクライアントが要求する公称FC_DOMAIN_ID値です。 Preferred_ID値が利用可能であり、メッセージで指定されたVirtual_Fabric_IDにまだ割り当てられていない場合、iSNSサーバーは、要求されたPreferred_ID値をAssigned_IDとして要求元のクライアントに返す必要があります（SHALL）。
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が含まれています。このスペースから利用可能な未割り当ての値がない場合、iSNSサーバーはステータスコード18「FC_DOMAIN_IDが利用できません」で応答する必要があります（SHALL）。
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.
FC_DOMAIN_ID値が特定のVirtual_Fabric_IDのiSNSサーバーによってiSNSクライアントに割り当てられると、そのFC_DOMAIN_ID値は、割り当てが解除されるまで、またはESI監視がiSNSクライアントがネットワークおよびオブジェクト上に存在しないことを検出するまで、再利用できませんそのクライアントのiSNSデータベースから削除されます。
The iSNS server and client SHALL use TCP to transmit and receive RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
iSNSサーバーとクライアントは、RqstDomId、RqstDomIdRsp、RlseDomId、およびRlseDomIdRspメッセージの送受信にTCPを使用する必要があります（SHALL）。
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バイトのファイバーチャネルPORT_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メッセージには、3つのTLV属性が次の順序で含まれています。要求元のEIDがソース属性、Virtual_Fabric_IDがメッセージキー属性、Assigned_IDが操作属性です。 RlseDomIdメッセージを受信すると、iSNSサーバーは、指定されたVirtual_Fabric_ID属性のAssigned_ID属性に含まれるFC_DOMAIN_ID値の割り当てを解除する必要があります。割り当てを解除すると、そのFC_DOMAIN_ID値は、別のiSNSクライアントによって要求され、割り当てられます。
The iSNS server and client SHALL use TCP to transmit and receive RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
iSNSサーバーとクライアントは、RqstDomId、RqstDomIdRsp、RlseDomId、およびRlseDomIdRspメッセージの送受信にTCPを使用する必要があります（SHALL）。
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です。このメッセージは、特定のVirtual_Fabric_IDに現在割り当てられているFC_DOMAIN_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メッセージのメッセージキー属性はVirtual_Fabric_IDです。このメッセージへの応答は、指定されたVirtual_Fabric_IDに割り当てられているすべてのFC_DOMAIN_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) |
+----------------------------------------+
| . . . |
+----------------------------------------+
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 Attributeのタグ値は0で、長さ値は0です。DelimiterAttributeは事実上8バイトの長さです。0x00000000を含む4バイトのタグと、0x00000000を含む4バイトの長さフィールドです。
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メッセージによって明示的に変更または作成された非キー属性が含まれている必要があります（SHALL）。運用属性の中で、変更または追加された各非キー属性は、DevAttrRegRspメッセージのキー属性の後にリストされる必要があります。暗黙的に登録された属性は、DevAttrRegRspメッセージで返されてはなりません（MUST NOT）。暗黙的に登録された属性は、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メッセージで返されたキーまたは非キー属性を持っていてはなりません（MUST NOT）。ただし、明示的に登録されたPGオブジェクト（つまり、登録または置換メッセージに明示的に含まれるPGT値を持つオブジェクト）は、DGTAttrRegRspメッセージでPGT値が返される必要があります（SHALL）。
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リクエストメッセージには3つのポータルが登録されています。リソースが不足しているため、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メッセージの操作属性に無効な属性のリストを含めることができます（MAY）。
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.
元の登録メッセージの一部の属性値（ESI間隔、登録期間など）は、iSNSサーバーによって変更される場合があります。これは、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メッセージの結果が含まれている必要があります（SHALL）。
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.
動作属性フィールドは、元の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.
エラーが発生した場合、この応答メッセージには、適切なステータスコードと、iSNSデータベースから正常に登録解除されなかった元のDevDeregメッセージからのオブジェクトのリストが含まれます。このオブジェクトのリストは、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.
SCNDeregRspメッセージタイプは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メッセージにメッセージキーがなかった場合、DDRegRspメッセージにはメッセージキーがないはずです（SHALL）。
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.
DDシンボリック名属性またはDD機能属性がDDReg操作中に割り当てまたは更新された場合、新しい値はDDRegRspメッセージの操作属性として返される必要があります（SHALL）。
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メッセージの操作属性に含めることができます（MAY）。
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.
DDSRegRspメッセージタイプは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.
DDSRegRspメッセージのメッセージキーには、元のDDSRegメッセージのメッセージキーが含まれている必要があります。元のDDSRegメッセージにメッセージキーがなかった場合、DDSRegRspメッセージにはメッセージキーがなければならない（SHALL NOT）。
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.
DDSRegRsp操作中にDDSシンボリック名属性またはDDSステータス属性が割り当てられたか更新された場合、新しい値はDDSRegRspメッセージの操作属性として返される必要があります（SHALL）。
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メッセージの操作属性に無効な属性のリストを含めることができます（MAY）。
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サーバーはそのネットワークエンティティとポータルのタイムスタンプ属性を更新する必要があります（SHALL）。
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が含まれています。このスペースから使用可能な未割り当ての値がない場合、iSNSサーバーは、ステータスコード19「FC_DOMAIN_IDが使用不可」で応答する必要があります（SHALL）。
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.
FC_DOMAIN_ID値がiSNSサーバーによって割り当てられると、値が割り当てられたiSNSクライアントによって割り当てが解除されるまで、またはESIメッセージがiSNSクライアントがネットワーク上に存在しないことを検出するまで、再利用しないでください。
The iSNS server and client SHALL use TCP to transmit and receive RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
iSNSサーバーとクライアントは、RqstDomId、RqstDomIdRsp、RlseDomId、およびRlseDomIdRspメッセージの送受信にTCPを使用する必要があります（SHALL）。
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メッセージのAssigned_ID値が割り当てられていない場合、iSNSサーバーは、ステータスコード20「FC_DOMAIN_ID Not Allocated」を使用してこのメッセージで応答する必要があります。
The iSNS server and client SHALL use TCP to transmit and receive RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
iSNSサーバーとクライアントは、RqstDomId、RqstDomIdRsp、RlseDomId、およびRlseDomIdRspメッセージの送受信にTCPを使用する必要があります（SHALL）。
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要求メッセージで指定されたVirtual_Fabric_IDに割り当てられているFC_DOMAIN_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のリストが含まれています。 Assigned_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 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.
ベンダー固有のiSNSPメッセージの機能IDは0x0100〜0x01FFですが、ベンダー固有の応答の機能IDは0x8100〜0x81FFです。ベンダー固有のメッセージの最初のメッセージキー属性は、独自のiSNSPメッセージの元の作成者を識別する会社のOUI（tag = 256）である必要があります。メッセージの残りの内容はベンダー固有です。
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クエリメッセージを使用して取得できます。特に明記されていない限り、これらの属性はiSNSP登録メッセージを使用してiSNSクライアントによって提供されます。
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 iSCSI Node Next Index 4 38 -- 1|16&17|32
iSCSI AuthMethod var 42 32 1|16&17|32
PG iSCSI Name 4-224 48 32|16&17 1|16&17|32|52
PG Portal IP Addr 16 49 32|16&17 1|16&17|32|52
PG Portal TCP/UDP Port 4 50 32|16&17 1|16&17|32|52
PG Tag (PGT) 4 51 32|16&17 1|16&17|32|52
PG Index 4 52 32|16&17 1|16&17|32|52
PG Next Index 4 53 -- 1|16&17|32|52
FC Port Name WWPN 8 64 1 1|16&17|64|66|96|128
Port ID 4 65 64 1|16&17|64
FC Port Type 4 66 64 1|16&17|64
Symbolic Port Name 4-256 67 64 1|16&17|64
Fabric Port Name 8 68 64 1|16&17|64
Hard Address 4 69 64 1|16&17|64
Port IP-Address 16 70 64 1|16&17|64
Class of Service 4 71 64 1|16&17|64
FC-4 Types 32 72 64 1|16&17|64
FC-4 Descriptor 4-256 73 64 1|16&17|64
FC-4 Features 128 74 64 1|16&17|64
iFCP SCN bitmap 4 75 64 1|16&17|64
Port Role 4 76 64 1|16&17|64
Permanent Port Name 8 77 -- 1|16&17|64
FC-4 Type Code 4 95 -- 1|16&17|64
FC Node Name WWNN 8 96 64 1|16&17|64|96
Symbolic Node Name 4-256 97 96 64|96
Node IP-Address 16 98 96 64|96
Node IPA 8 99 96 64|96
Proxy iSCSI Name 4-256 101 96 64|96
Switch Name 8 128 128 128
Preferred ID 4 129 128 128
Assigned ID 4 130 128 128
Virtual_Fabric_ID 4-256 131 128 128
iSNS Server Vendor OUI 4 256 -- SOURCE Attribute
Vendor-Spec iSNS Srvr 257-384 -- SOURCE Attribute
Vendor-Spec Entity 385-512 1 1|2|16&17|32|64
Vendor-Spec Portal 513-640 16&17 1|16&17|32|64
Vendor-Spec iSCSI Node 641-768 32 16&17|32
Vendor-Spec FC Port Name 769-896 64 1|16&17|64
Vendor-Spec FC Node Name 897-1024 96 64|96
Vendor-Specific DDS 1025-1280 2049 2049
Vendor-Specific DD 1281-1536 2065 2065
Other Vendor-Specific 1537-2048
DD_Set ID 4 2049 2049 1|32|64|2049|2065
DD_Set Sym Name 4-256 2050 2049 2049
DD_Set Status 4 2051 2049 2049
DD_Set_Next_ID 4 2052 -- 2049
DD_ID 4 2065 2049 1|32|64|2049|2065
DD_Symbolic Name 4-256 2066 2065 2065 DD_Member iSCSI Index 4 2067 2065 2065
DD_Member iSCSI Name 4-224 2068 2065 2065
DD_Member FC Port Name 8 2069 2065 2065
DD_Member Portal Index 4 2070 2065 2065
DD_Member Portal IP Addr 16 2071 2065 2065
DD_Member Portal TCP/UDP 4 2072 2065 2065
DD_Features 4 2078 2065 2065
DD_ID Next ID 4 2079 -- 2065
The following are descriptions of the columns used in the above table:
以下は、上記の表で使用されている列の説明です。
Length: indicates the attribute length in bytes used for the TLV format. Variable-length identifiers are NULL-terminated and 4-byte aligned (NULLs are included in the length).
長さ：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.
クエリキー：iSNSデータベースから保存された値を取得するためにDevAttrQryメッセージで使用されるメッセージキーとオブジェクトキーの可能なタグ値を示します。
The following is a summary of iSNS attribute tag values available for future allocation by IANA at the time of publication:
以下は、発行時にIANAが将来の割り当てに使用できるiSNS属性タグ値の概要です。
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属性は、「読み取り専用」属性として指定することもできます（MAY）。これらの属性を「読み取り専用」として導入する新しいRFCはそれらをそのように文書化するものとし（SHALL）、IANAは対応する登録キー（Reg Keys）を「-」として記録します。
The following attributes are stored in the iSNS server using the Entity Identifier attribute as the key.
以下の属性は、エンティティーID属性をキーとして使用して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でエンコードされた、ネットワークエンティティのNULLで終了するテキストベースの説明です。このキー属性は、iSNSサーバーに登録されている各ネットワークエンティティを一意に識別します。属性の長さは4〜256バイト（NULL終端を含む）で異なり、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を生成する必要があります（SHALL）。 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は使用してはなりません（MUST NOT）。
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を生成および登録してはなりません（MUST NOT）。
This field MUST be normalized according to the nameprep template [NAMEPREP] before it is stored in the iSNS database.
このフィールドは、iSNSデータベースに格納する前に、nameprepテンプレート[NAMEPREP]に従って正規化する必要があります。
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:
Entity Protocolは、登録されたNETWORK ENTITYによって使用されるブロックストレージプロトコルを示す必須の4バイト整数属性です。この属性に使用される値は、IANAによって割り当てられ、維持されます。 iSNSでサポートされるプロトコルの初期セットは次のとおりです。
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アドレスは、IPv4またはIPv6アドレスを含むことができる16バイトのフィールドです。このフィールドにIPv4値が含まれている場合、IPv4にマップされたIPv6アドレスとして格納されます。つまり、最上位の10バイトは0x00に設定され、次の2バイトは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.
このフィールドには、ネットワークエンティティでサポートされているブロックストレージプロトコルの最小バージョンと最大バージョンが含まれています。最上位の2バイトにはサポートされる最大バージョンが含まれ、最下位の2バイトにはサポートされる最小バージョンが含まれます。範囲が登録されていない場合、ネットワークエンティティはすべてのバージョンのプロトコルをサポートしていると見なされます。値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モニタリングに登録されていないエンティティには、0以外の登録期間が必要です。登録期間が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をソース属性として使用して、独自の属性の1つに対するクエリと同じくらい簡単にすることができます。
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応答メッセージは、登録を更新する必要があります（SHALL）。
The Entity Index is an unsigned non-zero integer value that uniquely identifies each Network Entity registered in the iSNS server. Upon initial registration of a Network Entity, the iSNS server assigns an unused value for the Entity Index. Each Network Entity in the iSNS database MUST be assigned a value for the Entity Index that is not assigned to any other Network Entity. Furthermore, Entity Index values for recently deregistered Network Entities SHOULD NOT be reused in the short term.
エンティティインデックスは、iSNSサーバーに登録されている各ネットワークエンティティを一意に識別する、符号なしのゼロ以外の整数値です。ネットワークエンティティの初期登録時に、iSNSサーバーはエンティティインデックスに未使用の値を割り当てます。 iSNSデータベース内の各ネットワークエンティティには、他のネットワークエンティティに割り当てられていないエンティティインデックスの値を割り当てる必要があります。さらに、最近登録解除されたネットワークエンティティのエンティティインデックス値は、短期的には再利用しないでください。
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（無効な登録）を返す必要があります（SHALL）。この属性のみを照会する場合、メッセージキーは必要ありません。
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.
Entity Next Indexは、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 SAが含まれます。この属性には、[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セキュリティ構成を定義する場合に使用する必要があります。実装者が各ポータルインターフェースを保護するために異なるフェーズ1 SAセキュリティ構成を希望する場合は、ポータルフェーズ1プロポーザル（セクション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 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.
この属性には、ネットワークエンティティにバインドされている1つ以上のX.509証明書が含まれています。この証明書は、他のクライアントが自分自身を認証し、そのネットワークエンティティによって提供されるサービスにアクセスすることを許可したいクライアントによってアップロードされ、iSNSサーバーに登録されます。 X.509証明書のフォーマットは[RFC3280]にあります。この証明書には、空のシーケンスを持つサブジェクト名が含まれている必要があり、dNSNameタイプでエンコードされたSubjectAltName拡張が含まれている必要があります。識別されたエンティティのエンティティ識別子（セクション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データベースに登録されます。各ポータルは、1つのエンティティIDオブジェクトキーに関連付けられています。
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アドレスは、IPv4またはIPv6アドレスを含むことができる16バイトのフィールドです。このフィールドに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.
最大256バイトの可変長UTF-8でエンコードされたNULLで終了するテキストベースの説明。ポータルシンボリック名は、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モニタリングを受信するには、クライアントは少なくとも1つのポータルに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メッセージの再送信を試行するものとします（SHALL）。 ESIインターバル期間は、iSNSサーバーが最後のESI応答を受信することから始まります。 ESIインターバル期間の2倍が経過する前に、すべての再送信を送信する必要があります。どのESIメッセージからも応答がない場合、ポータルの登録を解除する必要があります（SHALL）。この方法で登録解除できるのは、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メッセージに登録されているネットワークエンティティに関連付けられたすべてのポータルが無応答のために登録解除され、少なくとも2つの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メッセージを受信していない場合、クライアントはEntity_IDをキーとして使用してDevAttrQryメッセージを使用してiSNSサーバーにクエリを試行できます（MAY）。クエリ結果が「そのようなエントリはありません」というエラーの場合、クライアントは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.
このフィールドには、ポータルIPアドレスのiSNSサーバーによる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メッセージを受信できるようにする必要があります（SHALL）。 TCPポートが登録されていて、そのTCPポートからiSNSサーバーへの既存のTCP接続がまだ存在しない場合、iSNSクライアントは、指定されたTCPポートでiSNSサーバーからの新しいTCP接続を受け入れるものとします（SHALL）。
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サーバーはエラーを返す必要があります（SHALL）。複数のポータルに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.
ポータルインデックスは、iSNSデータベースに登録された各ポータルを一意に識別する4バイトのゼロ以外の整数値です。ポータルの初期登録時に、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- 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ポート番号を登録する場合、クライアントは、SCNメッセージが指定されたTCPまたはUDPポートで受信されることを許可するものとします（SHALL）。 TCPポートが登録されていて、そのTCPポートからiSNSサーバーへの既存のTCP接続がまだ存在しない場合、iSNSクライアントは、指定されたTCPポートでiSNSサーバーからの新しいTCP接続を受け入れるものとします（SHALL）。
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サーバーはエラーを返す必要があります（SHALL）。複数のポータルに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（無効な登録）を返す必要があります（SHALL）。この属性のみを照会する場合、メッセージキーは必要ありません。
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.
Portal Next Indexは、SNMPクライアントが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デバイスなど）のセキュリティポリシーと設定を保存および配布できることを意味します。重要な情報を含めるには、ビット25〜29のビット30を1にする必要があります。他のすべてのビットは、将来指定される非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
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フェーズ2メッセージを保護するために受け入れ可能な保護スイートの優先順位の降順で、IKEフェーズ1プロポーザルリストが含まれています。これには、iSNSクライアントからiSNSサーバー、およびピアiFCPやiSCSIデバイスへのフェーズ2 SAが含まれます。この属性には、[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
このフィールドには、IKEフェーズ2プロポーザルがISAKMP形式[RFC2408]で含まれ、ポータルによって送受信されるトラフィックを保護するために受け入れ可能なセキュリティプロポーザルを優先度の高い順にリストします。このフィールドは、ビット31、30、29が
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.
この属性には、ポータルの資格情報である1つ以上のX.509証明書が含まれています。この証明書は、ポータルでサポートされているIPアドレスおよびTCP / UDPポートへの通信を識別および認証するために使用されます。 X.509証明書の形式は、[RFC3280]で指定されています。この証明書には、空のシーケンスを持つサブジェクト名が含まれている必要があり、iPAddressタイプでエンコードされたSubjectAltName拡張が含まれている必要があります。識別されたポータルのポータルIPアドレス（セクション6.3.1）は、証明書のSubjectAltNameフィールドに格納する必要があります（SHALL）。
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 Name属性をキーとして使用してiSNSデータベースに格納されます。ノードキー属性の各セットは、1つのエンティティ識別子オブジェクトキーに関連付けられています。
Although the iSCSI Name key is associated with one Entity Identifier, it is unique across the entire iSNS database.
iSCSI名キーは1つのエンティティ識別子に関連付けられていますが、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.
これは、最大224バイトの可変長UTF-8エンコードのNULL終了テキストベースの説明です。このキー属性は、iSCSIストレージノードに必要であり、iSNSクライアントによって提供されます。登録されたiSCSI名は、iSCSI名の[iSCSI]で説明されている形式に準拠する必要があります。 iSCSI名の最大サイズは223バイトです。 NULL文字と4バイトアライメント（セクション5.3.1を参照）を含め、iSCSI Nameフィールドの最大サイズは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.
EIDキーなしでiSCSI名が登録されている場合は、ネットワークエンティティを作成してEIDを割り当てる必要があります。割り当てられたEIDは、動作属性として登録応答で返される必要があります。
This field MUST be normalized according to the stringprep template [STRINGPREP] before it is stored in the iSNS database.
このフィールドは、iSNSデータベースに格納する前に、stringprepテンプレート[STRINGPREP]に従って正規化する必要があります。
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
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ターゲットを表します。ターゲットビットは、iSNSPを使用してiSNSクライアントによって設定される場合があります。
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イニシエーターを表します。イニシエータービットは、iSNSPを使用してiSNSクライアントによって設定される場合があります。
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.
これは、最大256バイトの可変長UTF-8エンコードされたNULL終了テキストベースの説明です。エイリアスは、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
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 MEMBER ADDEDは、新しいメンバーが既存の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).
OBJECT REMOVED、OBJECT ADDED、およびOBJECT UPDATEDは、ネットワークエンティティ、ポータル、ストレージノード、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登録は、MANAGEMENT REGISTRATION / 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に登録できるのは、制御ノードのみです。ビット30と31は、ビット26が1に設定されている場合にのみ有効にできます。
TARGET AND SELF INFORMATION ONLY SCNs (bit 25) provides information only about changes to target devices, or if the iSCSI Storage Node itself has undergone a change. Similarly, INITIATOR AND SELF INFORMATION ONLY SCNs (bit 24) provides information only about changes to initiator Nodes, or to the target itself.
ターゲットと自己の情報のみ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ノードインデックスは、iSNSデータベースに登録されている各iSCSIストレージノードを一意に識別するキーとして使用される4バイトのゼロ以外の整数値です。 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ノードインデックスに割り当てられた値は、iSCSIストレージノードがiSNSデータベースまたはディスカバリドメインのメンバーに登録されている限り存続します。ストレージノードに割り当てられた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].
このフィールドには、ファイバーチャネルファブリック内のiSCSIデバイスのワールドワイドノード名を表すために使用できるグローバルに一意の64ビット整数値が含まれています。この識別子はデバイス登録プロセス中に使用され、[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サーバーに格納され、FCファブリック内のデバイスへのストレージセッションを確立するiSCSIイニシエーターに「プロキシ」WWNN値が割り当てられるときの競合を防止します。
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ストレージノードの初期登録時にこのフィールドに値を提供する必要があります（SHALL）。 WSNSトークンがiSNSサーバーによって割り当てられるプロセスは、次の要件に準拠する必要があります。
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サーバーの再起動後も持続する必要があります（SHALL）。割り当てられると、許可された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トークン値は、World Wide Name（WWN）の[FC-FS]のフォーマット要件に準拠する必要があります。
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).
FC-iSCSIゲートウェイやiSCSIイニシエーターなどのiSNSクライアントは、独自のiSCSI-FC名のマッピングを提供したい場合は、独自のWWNNトークン値を登録するか、iSNSサーバー提供のWWNNトークン値を上書きできます（MAY）。これは、WWNNトークン（tag = 37）を操作属性としてDevAttrRegメッセージを使用して行われます。上書きされると、新しいWWNNトークン値はiSNSサーバーによって保存および保存される必要があり、上記で指定されたすべての要件が引き続き適用されます。 iSNSクライアントがiSNSデータベースで一意ではない、または無効であるこのフィールドの値を登録しようとした場合、ステータスコード3（無効な登録）で登録が拒否される必要があります（SHALL）。
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.
WSNSトークンで指定されたファイバーチャネルデバイスのiSNSデータベースに一致するレコードが存在する場合があります。これらのレコードには、ファイバーチャネルファブリックネームサーバーに登録されているその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.
これは、次に使用可能な（つまり、未使用の）iSCSIノードインデックス値を示す4バイトの整数値を含む仮想属性です。この属性は照会のみが可能です。 iSNSサーバーは、この属性の値を登録しようとするすべてのクライアントにエラーコード3（無効な登録）を返す必要があります（SHALL）。この属性のみを照会する場合、メッセージキーは必要ありません。
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.
この属性には、このiSCSIストレージノードで有効になっているiSCSI認証方式を優先順にリストした、UTF-8テキストのNULL終了文字列が含まれています。 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
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ポータルIPアドレス、およびPGポータルTCP / UDPポートをキーとして使用して、iSNSデータベースに格納されます。新しいPGオブジェクトは、対応するポータルやiSCSIストレージノードオブジェクトが登録されるときに暗黙的または明示的に作成されます。セクション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ポートは、現在サーバーに登録されていないポータルのポートである可能性があります。
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です。登録時にTLVの長さに0を使用して、NULL PGT値が登録されます。値の最下位2バイトには、オブジェクトのPGTが含まれています。最上位の2バイトは予約されています。 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インデックスは、iSNSデータベースに登録されている各PGオブジェクトを一意に識別するキーとして使用される4バイトのゼロ以外の整数値です。 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を参照するためのキーとして使用できます。また、既存のPGオブジェクトを照会または更新するためのiSNSメッセージのメッセージキーとしても使用できます。この例は、セクション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は、次に使用可能な（つまり、未使用の）PGインデックス値を示す4バイト整数値を含む仮想属性です。この属性は照会のみが可能です。 iSNSサーバーは、この属性の値を登録しようとするすべてのクライアントにエラーコード3（無効な登録）を返す必要があります（SHALL）。この属性のみを照会する場合、メッセージキーは必要ありません。
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ポートキー属性の各セットは、1つのエンティティIDオブジェクトキーに関連付けられています。
Although the FC Port World Wide Name is associated with one Entity Identifier, it is also globally unique.
FCポートのワールドワイド名は1つのエンティティ識別子に関連付けられていますが、グローバルに一意でもあります。
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_PortまたはNL_Portに割り当てられるファイバーチャネルアドレス識別子です。ポート識別子のフォーマットは[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
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.
これは、ネットワーク内のiSNS登録FCポート名に関連付けられた、最大256バイトの可変長UTF-8エンコードのNULL終了テキストベースの説明です。
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に設定され、次の2バイトは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
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.
これは、ネットワーク内のiSNS登録済みデバイスポートに関連付けられた、最大256バイトの可変長UTF-8エンコードのNULL終了テキストベースの説明です。このフィールドは、ファイバチャネルデバイスをサポートするために使用でき、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.
これは、関連するポートでサポートされるFC-4プロトコルタイプの場合、128バイトの配列で、タイプごとに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
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
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ターゲットを表します。 「ターゲット」ビットの設定は、iSNSPを使用してiSNSクライアントによって実行される場合があります。
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イニシエーターを表します。 「イニシエーター」ビットの設定は、iSNSPを使用してiSNSクライアントによって実行される場合があります。
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.
これは、ネットワーク内のiSNS登録済みFCデバイスに関連付けられた、最大256バイトの可変長UTF-8エンコードのNULL終了テキストベースの説明です。
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に設定され、次の2バイトは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でエンコードされたNULLで終了するテキストベースのフィールドで、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.
このフィールドを使用する場合、iSCSI名で指定されたiSCSIデバイスのiSNSデータベースに一致するエントリが存在する必要があります（SHOULD）。データベースエントリには、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.
これは、FC-4タイプの照会中にFC-4タイプを提供するために使用される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スイッチ名は、ネットワーク内の個別のiFCPゲートウェイを一意に識別する64ビットのワールドワイドネーム（WWN）識別子です。このグローバルに一意の識別子は、スイッチ登録/ FC_DOMAIN_ID割り当てプロセス中に使用されます。使用されるiFCPスイッチ名の値は、ワールドワイド名の[FC-FS]に記載されている要件に準拠する必要があります。 iSNSサーバーは、各iFCPスイッチ名に割り当てられているすべてのFC_DOMAIN_ID値の状態を追跡する必要があります（SHALL）。特定のiFCPスイッチ名がiSNSデータベースから登録解除されると、その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_DOMAIN_IDに使用したい要求された値です。 iSNSサーバーは、要求された値がまだ割り当てられていない場合、iSNSクライアントにFC_DOMAIN_IDとして要求された値の使用を許可するものとします（SHALL）。要求された値が利用できない場合、iSNSサーバーは割り当てられていない別の値を返す必要があります（SHALL）。
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ゲートウェイが1から239の範囲の独自の一意のFC_DOMAIN_ID値を予約するために使用します。FC_DOMAIN_IDが不要になった場合、RlseDomIdメッセージを使用してiFCPゲートウェイによって解放される必要があります。 。 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.
これは、最大256バイトの可変長UTF-8エンコードされたNULL終了テキストベースのフィールドです。 Virtual_Fabric_ID文字列は、RqstDomIdを使用して割り当てられる重複しないFC_DOMAIN_ID値の範囲を識別するためのキー属性として使用されます。 iSNSクライアントから送信された各Virtual_Fabric_ID文字列には、iSNSクライアントに割り当てられる独自の範囲の重複しないFC_DOMAIN_ID値が必要です。
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（無効な登録）が返される必要があります（SHALL）。
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（Organizationally Unique Identifier）[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（Organizationally Unique Identifier）を属性値フィールド自体の上位3バイトに配置する必要があります。
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）を使用する必要があります（SHALL）。これらの属性は照会のみが可能です。 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の範囲の属性は、ネットワークエンティティオブジェクトを説明するために使用されるベンダー固有またはサイト固有の属性です。これらの属性は、エンティティーID属性（tag = 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 Port Nameオブジェクトを記述するために使用されるベンダー固有またはサイト固有の属性です。これらの属性は、FCポート名WWPN（tag = 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（tag = 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は、管理ステーションによって有効または無効にできるDiscovery Domainsのコレクションです。この値は、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は、応答メッセージで返される必要があります。 0のDDS ID値は予約されており、1のDDS ID値はデフォルトのDDSに使用されます（セクション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.
最大256バイトの可変長UTF-8エンコードされたNULL終了テキストベースのフィールド。これは、ユーザーが読み取り可能なフィールドであり、ネットワーク管理者がDDS機能を追跡するのを支援するために使用されます。クライアントがDDSシンボリック名を登録すると、iSNSサーバーはそれが一意であることを検証する必要があります。名前が一意でない場合、DDS登録は「無効な登録」ステータスコードで拒否される必要があります。無効な属性（この場合はDDSシンボリック名）を応答に含める必要があります（SHALL）。
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_Statusフィールドは、DDSのステータスを示す32ビットのビットマップです。ビットマップのビット0は、DDSが有効（1）か無効（0）かを示します。 DDS有効フラグのデフォルト値は無効（0）です。
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 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（無効な登録）を返す必要があります（SHALL）。この属性のみを照会する場合、メッセージキーは必要ありません。
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.
発見ドメインセットの次のインデックスは、iSNSサーバーにエントリを作成するためにSNMPクライアントによって使用される場合があります。 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 ID値1はデフォルトDDに使用されます（セクション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.
最大256バイトの可変長UTF-8エンコードされたNULL終了テキストベースのフィールド。クライアントがDDシンボリック名を登録すると、iSNSサーバーはそれが一意であることを検証する必要があります。名前が一意でない場合、DD登録は「無効な登録」ステータスコードで拒否される必要があります。無効な属性（この場合はDDシンボリック名）を応答に含める必要があります（SHALL）。
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ノードインデックスは、探索ドメインのメンバーシップを表す1つの代替表現であり、もう1つの代替はiSCSI名です。 Discovery Domain iSCSI Node Indexは、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.
最大224バイトの可変長UTF-8エンコードされたNULL終了テキストベースのフィールド。検出ドメイン内の指定された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ビットのID属性は、ディスカバリードメイン内の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.
Discovery Domain Featuresは、このDDの機能を示すビットマップです。ビット位置は以下に定義されています。 1に設定されたビットは、DDに対応する特性があることを示します。
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].
ブートリスト：この機能は、[iSCSI-boot]で説明されているように、このDDのターゲットがメンバーイニシエーターにブート機能を提供することを示します。
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.
これは、次に使用可能な（つまり、未使用の）Discovery Domain Index値を示す4バイトの整数値を含む仮想属性です。この属性は照会のみが可能です。 iSNSサーバーは、この属性の値を登録しようとするすべてのクライアントにエラーコード3（無効な登録）を返す必要があります（SHALL）。この属性のみを照会する場合、メッセージキーは必要ありません。
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およびiFCPデバイスに不正なピアデバイスとの接続を確立するように指示したり、iSCSIまたはiFCPトラフィックのIPSec保護を弱めたり排除したりするなど、iSNSプロトコルメッセージを変更する可能性があります。
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ピアデバイス間の通信の承認を配布する場合は、null変換を使用したIPsec ESPを実装する必要があり、非null変換を実装する必要があります。 null以外の変換が実装されている場合は、DES暗号化アルゴリズムを使用してはなりません（SHOULD NOT）。
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デバイスのセキュリティポリシーを配布する場合は、認証、データ整合性、および機密性をサポートして使用する必要があります。機密性が必要または必要な場合は、null以外の変換を伴うIPSec ESPを使用する必要があり（SHOULD）、DES暗号化アルゴリズムを使用するべきではありません（SHOULD NOT）。
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接続を実装する必要があります（SHOULD）。
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をサポートしなければなりません（MUST）。認証ブロックは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プロトコルメッセージで通信しているIDを秘密にしておく必要はありません。具体的には、iSNSサーバーのIDと場所は機密情報とは見なされません。
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セキュリティ実装は、IPSec DOI [RFC2407]を使用して、認証、セキュリティアソシエーションのネゴシエーション、およびキー管理のために、IKEメインモードとアグレッシブモードの両方をサポートする必要があります。
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セキュリティ実装は、事前共有キーを使用した認証をサポートする必要があり、デジタル署名を使用した証明書ベースのピア認証をサポートする場合があります（MAY）。 IKEセクション5.2および5.3で概説されている公開鍵暗号化方式を使用したピア認証[RFC2409]はサポートされるべきではありません（SHOULD NOT）。
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メインモードとアグレッシブモードの両方をサポートする必要があります。事前共有キー認証を使用するIKEメインモードは、いずれかのピアが動的に割り当てられたIPアドレスを使用する場合は使用しないでください。事前共有キー認証を使用するメインモードは多くの場合に優れたセキュリティを提供しますが、動的に割り当てられたアドレスが使用される状況では、中間者攻撃に対して脆弱なグループ事前共有キーが強制的に使用されます。 IKE IDペイロードID_KEY_IDは使用してはなりません（MUST NOT）。
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証明書要求ペイロードを使用して、そのローカルポリシーに従って信頼される認証局を指定する必要があります（SHOULD）。 IKEネゴシエーターは、IKEの認証手順で使用するPKI証明書を受け入れる前に、関連する証明書失効リスト（CRL）を確認する必要があります（SHOULD）。
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.
IPSecを使用してiSNSクライアントとiSNSサーバー間の通信が保護されると、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構成は、クライアントデバイス間のIKEフェーズ1およびフェーズ2ネゴシエーションに使用されるポリシーを含め、iSNSサーバーに保存できます。 IKEペイロード形式には、iSCSIまたはiFCPトラフィックを保護するために使用する適切なIPsecポリシーをネゴシエートするときにiSCSIまたはiFCPデバイスが使用する一連の1つ以上の提案が含まれています。
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）には、そのiSCSIデバイスが使用するiSCSI認証方法を示すテキスト値が埋め込まれたnullで終了する文字列が含まれています。
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サーバーだけです。 iSCSIおよびiFCPエンドノードはIKEおよびIPSecを実装する必要があるため、これらの既存の要件を使用して、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データベースに登録されている少なくとも1つのストレージノードを持つ各iSNSクライアントは、iSNSサーバーとの少なくとも1つのフェーズ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サーバーはフェーズ1削除メッセージを関連するiSNSクライアントのIKEピアに送信し（SHALL）、その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の標準アクションは、iSNSPをサポートするためにIANAによって維持される2つのレジストリを作成し、両方のレジストリに初期値を割り当てます。最初のレジストリは、iSNSでサポートされているBlock Storage Protocolsのレジストリです。 2番目のレジストリは、iSNSサーバーに登録および照会できる標準のiSNS属性の詳細なレジストリです。このRFCは、Service Location Protocol、バージョン2 [RFC2608]のセクション15でBlock Structure Descriptor（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 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.
iSNSPがサポートするブロックストレージプロトコルのレジストリを維持するために、IANAはiSNSがサポートする各ブロックストレージプロトコルに32ビットの符号なし整数を割り当てます。この番号は、エンティティプロトコルとしてiSNSデータベースに保存されます。エンティティプロトコルのIANAによって維持される初期値のセットは、セクション6.2.2の表に示されています。 iSNSによってサポートされる新しいブロックストレージプロトコルの追加の値は、IPS WG議長、またはIETFトランスポートエリアディレクターによって任命されたDesignated Expert [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属性のレジストリの作成と維持を担当します。 iSNS属性の初期リストについては、セクション6で説明します。各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割り当て用に予約されているタグ値の使用を指定するものとします（SHALL）。 RFCは、最小値として、新しい属性タグ値、属性の長さ、および新しい属性に使用できる許可された登録およびクエリキーのセットを指定する必要があります（SHALL）。 RFC SHALLには、新しい属性の理由と新しい属性の使用方法の説明も含まれています。
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 WGメーリングリスト、またはIPS WGがその時点で解散されている場合は、IETFトランスポートエリアディレクターによって指定されたメーリングリストで利用可能にする必要があります。 。レビューとコメント期間は、IPS WG議長またはIETFトランスポートエリアディレクターによって指定された人物が提案を却下するか、草案をRFCとして公開するためにIESGに転送するかを決定する前に、少なくとも3か月続くものとします。仕様が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、「Internet Small Computer Systems Interface（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-A Protocol for Internet Fibre Channel Storage Networking」、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、インターネットストレージネームサービスのIPv4動的ホスト構成プロトコル（DHCP）オプション、RFC 4174、2005年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、「Service Location Protocol、Version 2」、RFC 2608、1999年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、「Finding Internet Small Computer Systems Interface（iSCSI）Targets and Name Servers Using Using Service Location Protocol version 2（SLP）、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-boot] Sarkar、P.、Missimer、D。、およびC. Sapuntzakis、「インターネットSamll Computer System Interface（iSCSI）プロトコルを使用したクライアントのブートストラップ」、RFC 4173、2005年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]ホフマン、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、「Internet Security Association and Key Management Protocol（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.、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。
[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、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile」、RFC 3280、2002年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.、et al。、 "Definitions of Managed Objects for iSNS（Internet Storage Name Service）"、Work in Progress、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]ファイバーチャネルGeneric Services-4（作業中）、NCITSワーキングドラフトプロジェクト1505-D
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[RFC1510]コールJ.およびC.ノイマン、「Kerberosネットワーク認証サービス（V5）」、RFC 1510、1993年9月。
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.
[RFC2025] Adams、C。、「The Simple Public-Key GSS-API Mechanism（SPKM）」、RFC 2025、1996年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、「RFCで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 2945、2000年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。、「Dynamic Host Configuration Protocol」、RFC 2131、1997年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]ケース、J.、Mundy、R.、Partain、D。、およびB. Stewart、「Introduction and Applicability Statements for Internet-Standard Management Framework」、RFC 3410、2002年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.、Presuhn、R。、およびB. Wijnen、「単純なネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ」、STD 62、RFC 3411、2002年12月。
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.
この例では、SLPサービスエージェント（SA）がiSNSホストに実装され、SLPユーザーエージェント（UA）がiSNSイニシエーターに実装されていることを前提としています。 SAとUAの詳細については、[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で、1つのストレージノード、1つのポータル、およびストレージノードとポータル間の関係を提供する暗黙的に登録されたポータルグループを含むエンティティによって表されます。管理者によってターゲットに完全修飾ドメイン名（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" | |
| |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.
この例では、2つのストレージノードとESIモニタリングを使用する2つのポータルを持つより複雑なターゲットがiSNSに登録されます。このターゲットはDNSサーバーで完全修飾ドメイン名（FQDN）を使用して構成されており、ユーザーはこの識別子をデバイスに使用したいと考えています。ターゲットは、ポータルグループを明示的に登録して、各ポータルが各ストレージノードへのアクセスを提供する方法を記述します。 1つのターゲットストレージノードにより、両方のポータルを介した協調アクセスが可能になります。もう一方のストレージノードは、両方のポータルを介してアクセスを許可しますが、調整されたアクセスは許可しません。
+--------------------------+------------------+-------------------+
| 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=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 | |
+--------------------------+------------------+-------------------+
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の例からターゲットNAMEabcdを検出する新しいイニシエーターを示しています。
+--------------------------+------------------+-------------------+
| 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=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=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).
多数の個人が、注意深いレビューとコメントおよび推奨事項の提出を通じて、このドキュメントの作成に貢献しました。このドキュメントへの技術的な貢献について、次の人物に感謝します。MarkBakke（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）、Hirata Ken（Vixel）、Howard Hall（Pirus）、Malikarjun Chadalapaka（HP） 、Marjorie Krueger（HP）、Siva Vaddepuri（McDATA）、Vinai Singh（American Megatrends）。
Authors' Addresses
著者のアドレス
Josh Tseng Riverbed Technology 501 2nd Street, Suite 410 San Francisco, CA 94107
Josh Tseng Riverbed Technology 501 2nd Street、Suite 410 San Francisco、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 Great America Parkway Santa Clara、CA 95054-1208
Phone: (408) 567-5765 EMail: kevin.gibbons@mcdata.com
電話：（408）567-5765メール：kevin.gibbons@mcdata.com
Franco Travostino Nortel 600 Technology Park Drive Billerica, MA 01821 USA
Franco Travostino Nortel 600 Technology Park Drive Billerica、MA 01821 USA
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
Curt du Laney Rincon Research Corporation 101 North Wilmot Road、Suite 101 Tucson AZ 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
じょえ そうざ みｃろそｆｔ こｒぽらちおん おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２ー６３９９
Phone: (425) 706-3135 EMail: joes@exmsft.com
電話：（425）706-3135メール：joes@exmsft.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
Copyright（C）The Internet Society（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事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンライン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は、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。