RFC4171 日本語訳
4171 Internet Storage Name Service (iSNS). J. Tseng, K. Gibbons, F.Travostino, C. Du Laney, J. Souza. September 2005. (Format: TXT=310636 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループJ.ツェン要求をネットワークでつないでください: 4171年の川床技術カテゴリ: 標準化過程K.テナガザルMcDATA社のF.TravostinoノーテルC.Duレーニーリンコン研究社のJ.スザマイクロソフト2005年9月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document specifies the Internet Storage Name Service (iSNS) protocol, used for interaction between iSNS servers and iSNS clients, which facilitates automated discovery, management, and configuration of iSCSI and Fibre Channel devices (using iFCP gateways) on a TCP/IP network. iSNS provides intelligent storage discovery and management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a capacity similar to that of a storage area network. iSNS facilitates a seamless integration of IP and Fibre Channel networks due to its ability to emulate Fibre Channel fabric services and to manage both iSCSI and Fibre Channel devices. iSNS thereby provides value in any storage network comprised of iSCSI devices, Fibre Channel devices (using iFCP gateways), or any combination thereof.
このドキュメントはTCP/IPネットワークでiSCSIとFibre Channelデバイス(iFCPゲートウェイを使用する)の自動化された発見、管理、および構成を容易にする相互作用にiSNSサーバとiSNSクライアントの間で使用されるインターネットStorage Name Service(iSNS)プロトコルを指定します。iSNSはFibre Channelネットワークで見つけられたものに匹敵する知的なストレージ発見と経営指導を提供します、商品IPネットワークがストレージエリアネットワークのものと同様の容量で機能するのを許容して; iSNSはFibre Channel骨組みのサービスを見習って、iSCSIとFibre Channelデバイスの両方を管理する性能のためIPとFibre Channelネットワークのシームレス統合を容易にします。その結果、iSNSはそれのiSCSIデバイスから成るどんなストレージネットワーク、Fibre Channelデバイス(iFCPゲートウェイを使用する)、またはどんな組み合わせにも値を供給します。
Tseng, et al. Standards Track [Page 1] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[1ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
Table of Contents
目次
1. Introduction................................................... 6
1.1. Conventions Used in This Document........................ 6
1.2. Purpose of This Document................................. 6
2. iSNS Overview.................................................. 6
2.1. iSNS Architectural Components ........................... 7
2.1.1. iSNS Protocol (iSNSP) ........................... 7
2.1.2. iSNS Client...................................... 7
2.1.3. iSNS Server...................................... 7
2.1.4. iSNS Database ................................... 7
2.1.5. iSCSI............................................ 7
2.1.6. iFCP............................................. 7
2.2. iSNS Functional Overview................................. 8
2.2.1. Name Registration Service........................ 8
2.2.2. Discovery Domain and Login Control Service....... 8
2.2.3. State Change Notification Service............... 10
2.2.4. Open Mapping between
Fibre Channel and iSCSI Devices................. 11
2.3. iSNS Usage Model........................................ 11
2.3.1. iSCSI Initiator................................. 12
2.3.2. iSCSI Target.................................... 12
2.3.3. iSCSI-FC Gateway................................ 12
2.3.4. iFCP Gateway.................................... 12
2.3.5. Management Station.............................. 12
2.4. Administratively Controlled iSNS Settings............... 13
2.5. iSNS Server Discovery .................................. 14
2.5.1. Service Location Protocol (SLP)................. 14
2.5.2. Dynamic Host Configuration Protocol (DHCP)...... 14
2.5.3. iSNS Heartbeat Message.......................... 14
2.6. iSNS and Network Address Translation (NAT).............. 14
2.7. Transfer of iSNS Database Records between iSNS Servers.. 15
2.8. Backup iSNS Servers..................................... 17
2.9. Transport Protocols..................................... 19
2.9.1. Use of TCP for iSNS Communication............... 19
2.9.2. Use of UDP for iSNS Communication............... 20
2.9.3. iSNS Multicast and Broadcast Messages........... 20
2.10. Simple Network Management Protocol (SNMP) Requirements.. 21
3. iSNS Object Model............................................. 21
3.1. Network Entity Object .................................. 22
3.2. Portal Object .......................................... 22
3.3. Storage Node Object..................................... 22
3.4. Portal Group Object..................................... 23
3.5. FC Device Object........................................ 24
3.6. Discovery Domain Object................................. 24
3.7. Discovery Domain Set Object............................. 24
3.8. iSNS Database Model..................................... 24
4. iSNS Implementation Requirements.............................. 25
1. 序論… 6 1.1. このドキュメントで中古のコンベンション… 6 1.2. このドキュメントの目的… 6 2. iSNS概要… 6 2.1iSNS建築構成… 7 2.1.1iSNSは(iSNSP)について議定書の中で述べます… 7 2.1 .2iSNSクライアント… 7 2.1 .3iSNSサーバ… 7 2.1 .4iSNSデータベース… 7 2.1.5iSCSI… 7 2.1.6iFCP… 7 2.2iSNS機能概要… 8 2.2.1. 登録をサービスと命名してください… 8 2.2.2. 発見ドメインとログインはサービスを制御します… 8 2.2.3. 変更届出書サービスを述べてください… 10 2.2.4. 繊維チャンネルとiSCSIの間でデバイスを写像して、開いてください… 11 2.3iSNS用法モデル… 11 2.3.1iSCSI創始者… 12 2.3.2iSCSI目標… 12 2.3.3iSCSI-FCゲートウェイ… 12 2.3.4iFCPゲートウェイ… 12 2.3.5. 管理駅… 12 2.4. 行政上、iSNS設定を制御します… 13 2.5iSNSサーバ発見… 14 2.5.1. 位置のプロトコル(SLP)を修理してください… 14 2.5.2. Dynamic Host Configuration Protocol(DHCP)… 14 2.5 .3iSNS鼓動メッセージ… 14 2.6のiSNSとネットワークが、翻訳が(NAT)であると扱います… 14 2.7. iSNSデータベースの転送はiSNSサーバの間に記録します。 15 2.8. iSNSサーバのバックアップをとってください… 17 2.9. プロトコルを輸送してください… 19 2.9.1. TCPのiSNSコミュニケーションの使用… 19 2.9.2. UDPのiSNSコミュニケーションの使用… 20の2.9.3iSNSマルチキャストと同報メッセージ… 20 2.10. 簡単なネットワーク管理プロトコル(SNMP)要件。 21 3iSNSオブジェクト・モデル… 21 3.1. 実体オブジェクトをネットワークでつないでください… 22 3.2. 入り口のオブジェクト… 22 3.3. ストレージノードオブジェクト… 22 3.4. 入り口のグループは反対します… 23 3.5. FCデバイスオブジェクト… 24 3.6. 発見ドメインオブジェクト… 24 3.7. 発見ドメインはオブジェクトを設定しました… 24 3.8iSNSデータベースモデル… 24 4iSNS実装要件… 25
Tseng, et al. Standards Track [Page 2] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[2ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
4.1. iSCSI Requirements...................................... 25
4.1.1. Required Attributes for Support of iSCSI........ 26
4.1.2. Examples: iSCSI Object Model Diagrams........... 28
4.1.3. Required Commands and
Response Messages for Support of iSCSI.......... 30
4.2. iFCP Requirements....................................... 31
4.2.1. Required Attributes for Support of iFCP......... 31
4.2.2. Example: iFCP Object Model Diagram.............. 32
4.2.3. Required Commands and
Response Messages for Support of iFCP........... 34
5. iSNSP Message Format.......................................... 35
5.1. iSNSP PDU Header........................................ 35
5.1.1. iSNSP Version................................... 36
5.1.2. iSNSP Function ID............................... 36
5.1.3. iSNSP PDU Length................................ 36
5.1.4. iSNSP Flags..................................... 36
5.1.5. iSNSP Transaction ID............................ 36
5.1.6. iSNSP Sequence ID............................... 37
5.2. iSNSP Message Segmentation and Reassembly............... 37
5.3. iSNSP PDU Payload....................................... 37
5.3.1. Attribute Value 4-Byte Alignment................ 38
5.4. iSNSP Response Status Codes............................. 39
5.5. Authentication for iSNS Multicast and Broadcast Messages 39
5.6. Registration and Query Messages......................... 41
5.6.1. Source Attribute................................ 42
5.6.2. Message Key Attributes.......................... 42
5.6.3. Delimiter Attribute............................. 42
5.6.4. Operating Attributes............................ 43
5.6.5. Registration and Query Request Message Types ... 44
5.7. Response Messages....................................... 66
5.7.1. Status Code..................................... 66
5.7.2. Message Key Attributes in Response.............. 66
5.7.3. Delimiter Attribute in Response................. 67
5.7.4. Operating Attributes in Response................ 67
5.7.5. Registration and Query Response Message Type.... 67
5.8. Vendor-Specific Messages................................ 72
6. iSNS Attributes............................................... 73
6.1. iSNS Attribute Summary.................................. 73
6.2. Entity Identifier-Keyed Attributes...................... 76
6.2.1. Entity Identifier (EID)......................... 76
6.2.2. Entity Protocol................................. 76
6.2.3. Management IP Address .......................... 77
6.2.4. Entity Registration Timestamp .................. 77
6.2.5. Protocol Version Range.......................... 77
6.2.6. Registration Period............................. 78
6.2.7. Entity Index.................................... 78
6.2.8. Entity Next Index............................... 79
6.2.9. Entity ISAKMP Phase-1 Proposals................. 79
4.1. iSCSI要件… 25 4.1.1. iSCSIのサポートのために属性を必要とします… 26 4.1.2. 例: iSCSIオブジェクト・モデルダイヤグラム… 28 4.1.3. iSCSIのサポートのためのコマンドと応答メッセージを必要とします… 30 4.2iFCP要件… 31 4.2.1. iFCPのサポートのために属性を必要とします… 31 4.2.2. 例: iFCPオブジェクト・モデルダイヤグラム… 32 4.2.3. iFCPのサポートのためのコマンドと応答メッセージを必要とします… 34 5iSNSPメッセージ・フォーマット… 35 5.1iSNSP PDUヘッダー… 35 5.1.1iSNSPバージョン… 36 5.1.2iSNSP Function ID… 36 5.1.3iSNSP PDUの長さ… 36 5.1.4iSNSPは弛みます… 36 5.1.5iSNSP Transaction ID… 36 5.1.6iSNSP Sequence ID… 37 5.2のiSNSPメッセージ分割とReassembly… 37 5.3iSNSP PDU有効搭載量… 37 5.3.1. 値の4バイトの整列を結果と考えてください… 38 5.4iSNSP応答ステータスコード… 39 5.5. iSNSマルチキャストと同報メッセージ39 5.6のための認証。 登録と質問メッセージ… 41 5.6.1. ソース属性… 42 5.6.2. メッセージの主要な属性… 42 5.6.3. デリミタ属性… 42 5.6.4. 属性を操作します… 43 5.6.5. 登録と質問はメッセージタイプを要求します… 44 5.7. 応答メッセージ… 66 5.7.1. 状態コード… 66 5.7.2. 応答におけるメッセージの主要な属性… 66 5.7.3. 応答におけるデリミタ属性… 67 5.7.4. 応答における属性を操作します… 67 5.7.5. 登録と質問応答メッセージタイプ… 67 5.8. ベンダー特有のメッセージ… 72 6iSNS属性… 73 6.1iSNSは概要を結果と考えます… 73 6.2. 実体の識別子で合わせられた属性… 76 6.2.1. エンティティ識別名(EID)… 76 6.2.2. 実体プロトコル… 76 6.2.3. 管理IPアドレス… 77 6.2.4. 実体登録タイムスタンプ… 77 6.2.5. バージョン範囲について議定書の中で述べてください… 77 6.2.6. 登録の期間… 78 6.2.7. 実体インデックス… 78 6.2.8. 次の実体は索引をつけます… 79 6.2.9. 実体ISAKMPフェーズ-1提案… 79
Tseng, et al. Standards Track [Page 3] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[3ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
6.2.10. Entity Certificate.............................. 79
6.3. Portal-Keyed Attributes................................. 80
6.3.1. Portal IP Address............................... 80
6.3.2. Portal TCP/UDP Port............................. 80
6.3.3. Portal Symbolic Name............................ 80
6.3.4. Entity Status Inquiry Interval.................. 81
6.3.5. ESI Port........................................ 82
6.3.6. Portal Index.................................... 82
6.3.7. SCN Port........................................ 82
6.3.8. Portal Next Index............................... 83
6.3.9. Portal Security Bitmap.......................... 83
6.3.10. Portal ISAKMP Phase-1 Proposals................. 84
6.3.11. Portal ISAKMP Phase-2 Proposals................. 84
6.3.12. Portal Certificate.............................. 84
6.4. iSCSI Node-Keyed Attributes............................. 84
6.4.1. iSCSI Name...................................... 85
6.4.2. iSCSI Node Type................................. 85
6.4.3. iSCSI Node Alias................................ 86
6.4.4. iSCSI Node SCN Bitmap .......................... 86
6.4.5. iSCSI Node Index................................ 87
6.4.6. WWNN Token...................................... 87
6.4.7. iSCSI Node Next Index .......................... 89
6.4.8. iSCSI AuthMethod................................ 89
6.5. Portal Group (PG) Object-Keyed Attributes............... 89
6.5.1. Portal Group iSCSI Name......................... 90
6.5.2. PG Portal IP Addr............................... 90
6.5.3. PG Portal TCP/UDP Port.......................... 90
6.5.4. Portal Group Tag (PGT).......................... 90
6.5.5. Portal Group Index.............................. 90
6.5.6. Portal Group Next Index......................... 91
6.6. FC Port Name-Keyed Attributes .......................... 91
6.6.1. FC Port Name (WWPN)............................. 91
6.6.2. Port ID (FC_ID)................................. 91
6.6.3. FC Port Type.................................... 92
6.6.4. Symbolic Port Name.............................. 92
6.6.5. Fabric Port Name (FWWN)......................... 92
6.6.6. Hard Address.................................... 92
6.6.7. Port IP Address................................. 92
6.6.8. Class of Service (COS).......................... 93
6.6.9. FC-4 Types...................................... 93
6.6.10. FC-4 Descriptor................................. 93
6.6.11. FC-4 Features .................................. 93
6.6.12. iFCP SCN Bitmap................................. 93
6.6.13. Port Role....................................... 94
6.6.14. Permanent Port Name (PPN)....................... 95
6.7. Node-Keyed Attributes .................................. 95
6.7.1. FC Node Name (WWNN)............................. 95
6.7.2. Symbolic Node Name.............................. 95
6.2.10. 実体証明書… 79 6.3. 属性を入り口で合わせます… 80 6.3.1. 入り口のIPアドレス… 80 6.3.2. 入り口のTCP/UDP港… 80 6.3.3. 入り口の英字名… 80 6.3.4. 実体資産調査間隔… 81 6.3.5. ESIポート… 82 6.3.6. 入り口のインデックス… 82 6.3.7. SCNポート… 82 6.3.8. 次の入り口は索引をつけます… 83 6.3.9. 入り口のセキュリティビットマップ… 83 6.3.10. 入り口のISAKMPフェーズ-1提案… 84 6.3.11. 入り口のISAKMPフェーズ-2提案… 84 6.3.12. 入り口の証明書… 84 6.4iSCSIは属性をノードで合わせました… 84 6.4.1iSCSI名… 85 6.4.2iSCSIノード種別… 85 6.4.3iSCSI Nodeアリア… 86 6.4.4iSCSIノードSCNビットマップ… 86 6.4.5iSCSIノードインデックス… 87 6.4.6. WWNNトークン… 次の87 6.4.7iSCSIノードは索引をつけます… 89 6.4.8iSCSI AuthMethod… 89 6.5. 入り口のグループの(未成年者不適当映画)オブジェクトで合わせられた属性… 89 6.5.1. 入り口のグループiSCSI名… 90 6.5.2. 未成年者不適当映画入り口のIP Addr… 90 6.5.3. 未成年者不適当映画入り口のTCP/UDP港… 90 6.5.4. 入り口のグループは(PGT)にタグ付けをします… 90 6.5.5. 入り口のグループは索引をつけます… 90 6.5.6. 入り口は次のインデックスを分類します… 91 6.6. FCは名前で合わせられた属性を移植します… 91 6.6.1. FCは名前(WWPN)を移植します… 91 6.6.2. ID(FC_ID)を移植してください… 91 6.6.3. FCはタイプを移植します… 92 6.6.4. シンボリックなポート名… 92 6.6.5. 骨組みのポート名(FWWN)… 92 6.6.6. 困難なアドレス… 92 6.6.7. IPアドレスを移植してください… 92 6.6.8. サービス(COS)のクラス… 93 6.6.9. FC-4はタイプします… 93 6.6.10. FC-4記述子… 93 6.6.11. FC-4の特徴… 93 6.6.12iFCP SCNビットマップ… 93 6.6.13. 役割を移植してください… 94 6.6.14. 永久的なポート名(PPN)… 95 6.7. 属性をノードで合わせます… 95 6.7.1. FCノード名(WWNN)… 95 6.7.2. シンボリックなノード名… 95
Tseng, et al. Standards Track [Page 4] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[4ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
6.7.3. Node IP Address................................. 95
6.7.4. Node IPA........................................ 96
6.7.5. Proxy iSCSI Name................................ 96
6.8. Other Attributes........................................ 96
6.8.1. FC-4 Type Code.................................. 96
6.8.2. iFCP Switch Name................................ 96
6.8.3. iFCP Transparent Mode Commands.................. 97
6.9. iSNS Server-Specific Attributes......................... 97
6.9.1. iSNS Server Vendor OUI.......................... 98
6.10. Vendor-Specific Attributes.............................. 98
6.10.1. Vendor-Specific Server Attributes............... 98
6.10.2. Vendor-Specific Entity Attributes............... 98
6.10.3. Vendor-Specific Portal Attributes............... 99
6.10.4. Vendor-Specific iSCSI Node Attributes........... 99
6.10.5. Vendor-Specific FC Port Name Attributes......... 99
6.10.6. Vendor-Specific FC Node Name Attributes......... 99
6.10.7. Vendor-Specific Discovery Domain Attributes..... 99
6.10.8. Vendor-Specific Discovery Domain Set Attributes. 99
6.10.9. Other Vendor-Specific Attributes................ 99
6.11. Discovery Domain Registration Attributes............... 100
6.11.1. DD Set ID Keyed Attributes..................... 100
6.11.2. DD ID Keyed Attributes......................... 101
7. Security Considerations...................................... 103
7.1. iSNS Security Threat Analysis ......................... 103
7.2. iSNS Security Implementation and Usage Requirements.... 104
7.3. Discovering Security Requirements of Peer Devices...... 105
7.4. Configuring Security Policies of iFCP/iSCSI Devices.... 106
7.5. Resource Issues........................................ 107
7.6. iSNS Interaction with IKE and IPSec.................... 107
8. IANA Considerations.......................................... 107
8.1. Registry of Block Storage Protocols.................... 107
8.2. Registry of Standard iSNS Attributes .................. 108
8.3. Block Structure Descriptor (BSD) Registry.............. 108
9. Normative References......................................... 109
10. Informative References....................................... 110
Appendix A: iSNS Examples........................................ 112
A.1. iSCSI Initialization Example........................... 112
A.1.1. Simple iSCSI Target Registration............... 112
A.1.2. Target Registration and DD Configuration....... 114
A.1.3. Initiator Registration and Target Discovery.... 117
Acknowledgements................................................. 121
6.7.3. ノードIPアドレス… 95 6.7.4. ノードIPA… 96 6.7.5. プロキシiSCSI名… 96 6.8. 他の属性… 96 6.8.1. FC-4はコードをタイプします… 96 6.8.2iFCPは名前を切り換えます… 96 6.8.3iFCP透過モードは命令します… 97 6.9iSNSのサーバ特有の属性… 97 6.9.1iSNSサーバベンダーOUI… 98 6.10. ベンダー特有の属性… 98 6.10.1. ベンダー特有のサーバ属性… 98 6.10.2. ベンダー特有の実体属性… 98 6.10.3. ベンダー特有の入り口の属性… 99 6.10.4. ベンダー特有のiSCSIノード属性… 99 6.10.5. ベンダー特有のFCは名前属性を移植します… 99 6.10.6. ベンダー特有のFCノード名属性… 99 6.10.7. ベンダー特有の発見ドメイン属性… 99 6.10.8. ベンダー特有の発見ドメインは属性を設定しました。 99 6.10.9. 他のベンダー特有の属性… 99 6.11. 発見ドメインの取得属性… 100 6.11.1. DDセットIDは属性を合わせました… 100 6.11.2. DD IDは属性を合わせました… 101 7. セキュリティ問題… 103 7.1. iSNS軍事的脅威分析… 103 7.2. iSNSセキュリティ実装と用法要件… 104 7.3. 同輩デバイスのセキュリティ要件を発見します… 105 7.4. iFCP/iSCSIデバイスの安全保障政策を構成します… 106 7.5. リソース問題… 107 7.6. IKEとIPSecとのiSNS相互作用… 107 8. IANA問題… 107 8.1. ブロックストレージプロトコルの登録… 107 8.2. 標準のiSNS属性の登録… 108 8.3. ブロック構造記述子(BSD)登録… 108 9. 標準の参照… 109 10. 有益な参照… 110 付録A: iSNSの例… 112 A.1iSCSI初期設定の例… 112 A.1.1。 簡単なiSCSIは登録を狙います… 112 A.1.2。 登録とDD構成を狙ってください… 114 A.1.3。 創始者登録と目標発見… 117の承認… 121
Tseng, et al. Standards Track [Page 5] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[5ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
1. Introduction
1. 序論
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
"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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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、発信するとき、ゼロに用意ができて、受信するとき無視されたSHOULDであるものを含むすべての未使用の分野とビットマップ。
1.2. Purpose of This Document
1.2. このドキュメントの目的
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.
これはiSCSIとiFCPデバイスによって使用される、iSNSサーバとコミュニケートするiSNSプロトコルを指定する標準のテキストを含む標準化過程ドキュメントです。このドキュメントはiSNSサーバとiSNSクライアントとの相互作用に焦点を合わせます。 複数の正式のプライマリiSNSサーバの中の相互作用は今後の活動のための潜在的話題です。
2. iSNS Overview
2. 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はFibre Channelネットワークでそれに匹敵するサービスのセットを提供するのによる利用可能なIPネットワークにおけるiSCSIとFibre Channel(FCP)記憶装置のスケーラブルな構成と管理を容易にします。その結果、iSNSは、商品IPネットワークがFibre Channel骨組みに匹敵する知性のレベルで機能するのを許容します。iSNSは、管理者がデバイスごとに簡単であるマネジメント・モデルを越えるのを許容します; 各記憶装置がそれ自身の知られている創始者と目標のリストによって手動で個別に構成されるところ。 iSNSを使用して、各記憶装置はiSNSサーバに発見と経営者の責任を従属します。その結果、iSNSサーバは管理局が全体のストレージネットワークを構成して、経営できる統合構成ポイントとして機能します、iSCSIとFibre Channelデバイスの両方を含んでいて。
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.
必要に応じてiSCSI、そして/または、iFCPがプロトコルであるとサポートするためにiSNSを実装することができます。 作成者によって望まれているようにiSNS実装はこれらのプロトコルの1か両方のサポートを提供するかもしれません。 セクション5でさらにそれぞれのこれらのプロトコルの中の実装要件について議論します。 iSNSの使用は、iSCSIのためのOPTIONALとiFCPのためのREQUIREDです。
Tseng, et al. Standards Track [Page 6] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[6ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
2.1. iSNS Architectural Components
2.1. iSNS建築構成
2.1.1. iSNS Protocol (iSNSP)
2.1.1. iSNSプロトコル(iSNSP)
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クライアントとサーバがどう交信するかを指定するフレキシブルで軽量のプロトコルです。 それはサーバー・ホストと同様にスイッチと目標を含む様々なプラットホームに適当です。
2.1.2. iSNS Client
2.1.2. 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クライアント開始トランザクションは、記憶装置におけるコレジデントであり、デバイス属性情報を登録できるプロセスであり、一般的なディスカバリーDomain(DD)で他の登録されたクライアントの情報をダウンロードして、それらのDD(s)に起こるイベントの非同期な通知を受け取ります。 管理局はiSNSに保存されたすべてのDDsに近づく手段を持っているiSNSクライアントの特別なタイプです。
2.1.3. iSNS Server
2.1.3. 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プロトコル州Change Notificationsを開始します。 登録要求で提出された適切に認証された情報はiSNSデータベースに保存されます。
2.1.4. iSNS Database
2.1.4. 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ディレクトリインフラストラクチャにおけるクライアント属性を保存するかもしれません。
2.1.5. iSCSI
2.1.5. iSCSI
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のカプセル化です。
2.1.6. iFCP
2.1.6. iFCP
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を使用することで既存のFibre ChannelとSCSIデバイスとインタコネクトするように設計されたゲートウェー間プロトコルです。iFCPはTCP/IP[iFCP]に対する既存のFCP標準の、そして、関連しているFibre Channelサービスを写像します。
Tseng, et al. Standards Track [Page 7] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[7ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
2.2. iSNS Functional Overview
2.2. iSNS機能概要
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デバイスの開いているマッピング
2.2.1. Name Registration Service
2.2.1. 名前登録サービス
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 GS4で説明されたFibre Channel 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.
また、命名登録サービスは1が必要であるときにネットワークユニークなDomain IDをiFCPゲートウェイに得る能力を提供します。
2.2.2. Discovery Domain and Login Control Service
2.2.2. 発見ドメインとログイン制御サービス
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.
ディスカバリーDomain(DD)サービスは管理とログイン管理目的のための、より処理しやすい組分けにStorage Nodesの仕切りを容易にします。 それで、管理者はそれぞれのホストのログインプロセスをiSNSに登録された目標の、より適切な部分集合に制限できます。 不要なログイン(iSCSIログインかFibre Channel Port Logins)の数を減少させて、ホストがストレージネットワークのサイズが拡大するのに従ってログイン関係を初期化しながら費やす時間を制限するには、これは特に重要です。 ストレージNodesは、互いの情報を得るために少なくとも1一般的な可能にされたDDにあるに違いありません。 同時に、デバイスは複数のDDsのメンバーであるかもしれません。
Login Control allows targets to delegate their access control/authorization policies to the iSNS server. This is consistent with the goal of centralizing management of those storage devices using the iSNS server. The target node or device downloads the list of authorized initiators from the iSNS. Each node or device is uniquely identified by an iSCSI Name or FC Port Name. Only
ログインControlは目標にそれらのアクセス制御/承認方針をiSNSサーバへ代表として派遣させます。これはそれらの記憶装置の管理を集結するというiSNSサーバを使用する目標のために一貫しています。目標ノードかデバイスがiSNSから認可された創始者のリストをダウンロードします。 各ノードかデバイスがiSCSI NameかFC Port Nameによって唯一特定されます。 唯一
Tseng, et al. Standards Track [Page 8] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[8ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
initiators that match the required identification and authorization provided by the iSNS will be allowed access by that target Node during session establishment.
アクセスはセッション設立の間、その目標NodeによってiSNSによって提供された必要な識別と承認に合っている創始者に許されるでしょう。
Placing Portals of a Network Entity into Discovery Domains allows administrators to indicate the preferred IP Portal interface through which storage traffic should access specific Storage Nodes of that Network Entity. If no Portals of a Network Entity have been placed into a DD, then queries scoped to that DD SHALL report all Portals of that Network Entity. If one or more Portals of a Network Entity have been placed into a DD, then queries scoped to that DD SHALL report only those Portals that have been explicitly placed in the DD.
Network EntityのPortalsをディスカバリーDomainsに置くのに、管理者はストレージトラフィックがそのNetwork Entityの特定のStorage Nodesにアクセスするべきである都合のよいIP Portalインタフェースを示すことができます。 Network EntityのPortalsが全くDDに置かれていないなら、質問はそのNetwork EntityのすべてのPortalsをそのDD SHALLレポートに見ました。 Network Entityの1PortalsがDDに置かれたなら、質問は明らかにDDに置かれたそれらのPortalsをそのDD SHALLレポートだけに見ました。
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.
iSNSPかSNMPを使用することで別々の管理者用ワークステーションを通してDDsにオフラインで対処できます。 目標がiSNSのLogin Controlの特徴を使用するために選ばれるなら、アクセスの目標代表経営者側は方針(すなわち、その目標にログインできた創始者のリスト)を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.
行政上認可されるなら、目標はそれ自身のLogin Controlリストをアップロードできます。 これは、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 Set Status値が「可能にされる」「デフォルトDDS」に含まれた「デフォルトDD」に置かれると決めるかもしれません。 これで、それらは対向機器に目に見えるようにデフォルトDDでなります。 それらをソースによって見られたiSNSPメッセージに近づきがたくして、他の実装は、それらがDDなしで登録されると決めるかもしれません。
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サーバは要求と範囲への操作の創始者をディスカバリーDomainsの1セットまで決定するそれぞれのiSNSPメッセージのSource Attributeを使用します。 また、さらに、Node Type(iFCPかiSCSI Node Typeビットマップ分野では、指定される)が、指定されたiSNS操作のために承認を決定するのに使用されるかもしれません。 例えば、Control Nodesだけが発見ドメインを作成するか、または削除するのが認可されます。
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.
有効でアクティブなディスカバリーDomains(DDs)は少なくとも1アクティブなディスカバリーDomain Set(DDS)に属します。 活性DDSに属さない発見Domainsが有効にされません。 iSNSサーバはすべてのStorage NodesのためにDD会員資格の状態を維持しなければなりません、反登録されたもののためにさえ。 Storage NodeがiSNSデータベースに活発に登録されるかどうかにかかわらずDD会員資格は永続的です。
Tseng, et al. Standards Track [Page 9] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[9ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
2.2.3. State Change Notification Service
2.2.3. 州の変更届出書サービス
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.
州Change Notification(SCN)サービスで、iSNS ServerはStorage Nodesの操作上の州に影響するネットワークイベントに関する通知を発行できます。 クライアントが通知のためにiSNS Server. SCNsによって検出されたイベントの通知のためのStorage Nodesを代表して登録するかもしれないiSNSはiSNSデータベースへの明白であるか内在している変化についてiSNSクライアントに通知します。 彼らは必ずネットワークで接続性の状態を同輩記憶装置に示すというわけではありません。 SCNの領収書への記憶装置の応答は実装特有です。 SCNsに応じるための方針がこのドキュメントの範囲の外にあります。
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).
2つのタイプのSCN登録証明書があります: 定期的な登録証明書と管理登録証明書。 管理登録証明書は管理SCNsをもたらしますが、定期的な登録証明書は通常のSCNsをもたらします。 セクション6.4.4と6.6を見てください。登録とSCNメッセージのタイプがSCNビットマップで示される、(.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登録は、ディスカバリーDomain Service SHALLがSCNメッセージの分配を制御するのに使用されるのを示します。 通常のSCNsの領収書はSCN-引き金となる出来事が行われる発見ドメインに制限されます。 通常のSCNsは発見ドメインの情報を含んでいません。
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登録はControl Nodesによって要求されるだけでそうすることができます。 管理登録証明書から生じる管理SCNsがディスカバリーDomainサービスで縛られません。 管理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サーバSHOULD、ハードウェアとソフトウェア・リソースがiSNSクライアントの予想された数をサポートすることができるくらい実装されてください。 しかしながら、リソースが不意に枯渇しているなら、iSNSサーバは、SCN Registration Rejected(状態Code17)を返すことによって、SCNにサービスを拒否するかもしれません。 拒絶はネットワークの規模か最新号のSCN登録証明書が実装特有の敷居を渡した状況で起こるかもしれません。 SCNsに登録できなかったクライアントは、直接他の記憶装置とのセッションをモニターすると決めるかもしれません。
The specific notification mechanism by which the iSNS server learns of the events that trigger SCNs is implementation-specific, but can include examples such as explicit notification messages from an iSNS client to the iSNS server, or a hardware interrupt to a switch-hosted iSNS server as a result of link failure.
iSNSサーバがSCNsの引き金となるイベントを知っている特定の通知メカニズムは、実装特有ですが、リンクの故障の結果、明白なiSNSクライアントからiSNSサーバか、ハードウェア割込みからスイッチで接待されたiSNSサーバまでの通知メッセージなどの例を含むことができます。
Tseng, et al. Standards Track [Page 10] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[10ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
2.2.4. Open Mapping between Fibre Channel and iSCSI Devices
2.2.4. 繊維チャンネルとiSCSIの間でデバイスを写像して、開いてください。
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データベースはFibre ChannelとiSCSIデバイスの両方の命名と発見情報を保存します。 これで、iSNSサーバはIPネットワークでプロキシiSCSIデバイス「イメージ」としてFibre Channelデバイスに関するマッピングを保存できます。 同様に、そのiSCSIデバイスのためにWWNN Token分野の下で「プロキシWWN」へのiSCSIデバイスに関するマッピングを保存できます。
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ゲートウェイの使用で、Fibre Channel意識している管理局は、Fibre Channelデバイスの情報を検索するためにiSNSサーバと対話して、Fibre ChannelとiSCSIデバイスを管理するのにこの情報を使用できます。 これは、ディスカバリーDomainsや州Change Notificationsなどの管理機能がシームレスにiSCSIとFibre Channelデバイスの両方に適用されるのを許容します、Fibre Channelデバイスと骨組みによる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.
Fibre Channel属性がiFCP属性として保存されて、iFCPプロトコルが実装されないでもiSNSサーバのこの情報を保存する能力が役に立つことに注意してください。 特に、iSNSサーバで登録されたFibre Channelデバイスのために「プロキシiSCSI名」を保存するのにタグ101を使用できます。この分野は、Fibre ChannelデバイスがIPネットワークでiSCSIデバイスとコミュニケートするのに使用されるiSCSI登録エントリーにFCデバイスを関連づけるのに使用されます。 逆に、タグ37(セクション6.1を見ます)はWWNN Token分野を含んでいます。(iSCSI-FCゲートウェイによって使用される、Fibre ChannelドメインにiSCSIデバイスを表すFC Node Name(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.
iSNSサーバでFibre ChannelとiSCSIデバイスの間のマッピングを保存することによって、この情報はこの情報を検索して、使用したがっているどんな認可されたiSNSクライアントにとっても開くようになります。 多くの場合、これはiSCSI-FCゲートウェイの中に内部的に情報を保存するより利点を提供します。そこでは、独占メカニズムを除いて、マッピングが対向機器に近づきがたいです。
2.3. iSNS Usage Model
2.3. iSNS用法モデル
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データベースにそれ自体を登録しなければなりません。
Tseng, et al. Standards Track [Page 11] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[11ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
2.3.1. iSCSI Initiator
2.3.1. iSCSI創始者
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創始者は、iSCSI対象装置の存在と位置を発見するためにiSNSサーバについて質問するでしょう。 また、それは、初期のbootupと発見の後にネットワークに現れる新しい目標についてそれに通知できるように、州の変更届出書(SCNs)を要求するかもしれません。 また、SCNsはストレージネットワークで取り外されたか、またはもう利用可能でない目標についてiSCSI創始者に知らせることができます、優雅に不完全なストレージセッションを終えることができて、実在しない目標のためのリソースを再割当てすることができるように。
2.3.2. iSCSI Target
2.3.2. 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.
iSNSサーバで存在を示すことによって、iSCSI創始者によってiSCSI目標は発見されます。また、それは、資源配分目的のために創始者の追加か解任を検出するためにSCNsに登録するかもしれません。 また、iSCSI対象装置はEntity Status Inquiry(ESI)メッセージに登録するかもしれません。(iSNSはメッセージでストレージネットワークで対象装置の有用性をモニターできます)。
2.3.3. iSCSI-FC Gateway
2.3.3. iSCSI-FCゲートウェイ
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ゲートウェイはFibre ChannelネットワークでiSCSI/IPネットワークにデバイスをブリッジします。 それはFCネームサーバで発見されたFCデバイス属性を保存するのにiSNSサーバを使用するかもしれません、iSCSIデバイス識別子へのFCデバイス識別子に関するマッピングと同様に。iSNSには、iSCSIとFibre Channelデバイスの両方のすべての属性を保存する能力があります。 iSCSIデバイスは直接的な相互作用を通してiSNSを使用することで管理されます、iSCSI-FCゲートウェイとのiSNS相互作用で間接的にFCデバイスに対処できますが。 これは、iSCSIとFibre Channelデバイスの両方がシームレスの管理フレームワークで管理されるのを許容します。
2.3.4. iFCP Gateway
2.3.4. iFCPゲートウェイ
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ゲートウェイは、ゲートウェイ領域でFibre ChannelネームサーバによってFCデバイスに提供されたサービスを見習うのにiSNSを使用します。iSNSは、iFCPゲートウェイによって実施されるために基本的な発見と帯状になる設定情報を提供します。 質問されると、iSNSはiFCPゲートウェイによって支えられたFCデバイスの間のiFCPセッションを証明するのに使用されるN_Portネットワーク・アドレスの情報を返します。
2.3.5. Management Station
2.3.5. 管理局
A management station uses iSNS to monitor storage devices and to enable or disable storage sessions by configuring discovery domains. A management station usually interacts with the iSNS server as a
管理局は、発見ドメインを構成することによってストレージセッションを記憶装置をモニターして、可能にするか、または無効にするのにiSNSを使用します。 通常、管理局はaとしてiSNSサーバと対話します。
Tseng, et al. Standards Track [Page 12] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[12ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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.
コントロールNodeは、発見ドメインを構成するためにすべてのiSNSデータベース・レコードと特権があるアクセスを寄付しました。 発見ドメインの操作で、管理局はiSNSサーバについて質問しているiSNSクライアントのためにデバイス発見の範囲を制御します。
2.4. Administratively Controlled iSNS Settings
2.4. 行政上制御された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
既定の設定を設定します。------- --------------- .5.13)管理SCNs(コントロールNodes専用)が可能にした5.6を見てください。ESI Non-応答Threshold3、((DD/DDS Modificationであることが無効にされた.8)デフォルトDD/DDS--Nodeが可能にしたコントロール--iSCSI Target Node Typeが無効にした.5--iSCSI Initiator Node Type身体障害者--iFCP Target Port Roleが無効にした5.6を見てください--、iFCP Initiator Port Roleは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: 登録されたControl NodeがManagement SCNsを受け取るために登録することが許可されているか否かに関係なく、決定します。
Default DD/DDS: determines whether a newly registered device not
explicitly placed into a discovery domain (DD) and
discovery domain set (DDS) is placed into a default
DD/DDS.
デフォルトDD/DDS: 新たに登録されたデバイスが明らかにドメイン(DD)と発見ドメインセット(DDS)がデフォルトDD/DDSに置かれるという発見に入賞しなかったか否かに関係なく、決定します。
DD/DDS Modification: determines whether the specified type of Node is
allowed to add, delete or update DDs and DDSs.
DD/DDS変更: DDsとDDSsを加えるか、削除するか、またはNodeの指定されたタイプがアップデートできることにかかわらず決定します。
Tseng, et al. Standards Track [Page 13] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[13ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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 Nameによって特定されたNodesかControl Nodesとして登録するのが認可されるFC Port Name WWPNのリスト。
2.5. iSNS Server Discovery
2.5. iSNSサーバ発見
2.5.1. Service Location Protocol (SLP)
2.5.1. サービス位置のプロトコル(SLP)
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プロトコル(SLP)はネットワークでつながれたサービスの存在、位置、および構成に関してフレキシブルでスケーラブルなフレームワークを情報入手をホストに提供するのに提供します、iSNSサーバを含んでいて。iSNSクライアントは、iSNSサーバのIPのアドレスかFQDNを発見するのにSLPを使用できます。SLPを通した発見を実装するために、Serviceエージェント(SA)はiSNSサーバで共同開催されるべきです、そして、Userエージェント(UA)はそれぞれのiSNSクライアントにいるべきです。 それぞれのクライアントマルチキャストa発見は、iSNSサーバのIPアドレスを要求しながら、通信します。 SAはこの要求に応じます。 任意に、SLPディレクトリエージェント(DA)にiSNSサーバの位置を保存できます。
Note that a complete description and specification of SLP can be found in [RFC2608], and is beyond the scope of this document. A service template for using SLP to locate iSNS servers can be found in [iSCSI-SLP].
SLPの完全な記述と仕様が[RFC2608]で見つけることができて、このドキュメントの範囲を超えていることに注意してください。 [iSCSI-SLP]でiSNSサーバの場所を見つけるのにSLPを使用するためのサービステンプレートを見つけることができます。
2.5.2. Dynamic Host Configuration Protocol (DHCP)
2.5.2. Dynamic Host Configuration Protocol(DHCP)
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].
DHCPオプションを使用することでiSNSクライアントによってダウンロードされるように、DHCPサーバでiSNSサーバのIPアドレスを保存できます。 iSNSサーバ位置を分配するのに使用されるべきDHCPオプション番号は[iSNSOption]で見つけられます。
2.5.3. iSNS Heartbeat Message
2.5.3. iSNS鼓動メッセージ
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サーバとどんなバックアップサーバの位置も発見できます。
2.6. iSNS and Network Address Translation (NAT)
2.6. iSNSとネットワークアドレス変換(NAT)
The existence of NAT will have an impact upon information retrieved from the iSNS server. If the iSNS client exists in an addressing domain different from that of the iSNS server, then IP address information stored in the iSNS server may not be correct when interpreted in the domain of the iSNS client.
NATの存在はiSNSサーバから検索された情報に影響を与えるでしょう。iSNSクライアントがiSNSサーバのものと異なったアドレス指定領域に存在するなら、iSNSクライアントのドメインで解釈される場合、iSNSサーバで保存されたIPアドレス情報は正しくないかもしれません。
Tseng, et al. Standards Track [Page 14] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[14ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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のためにアドレスについて質問しないことです。 アドレス指定情報を求めるときEntity Identifier分野に保存されたDNS Fully Qualified Domain NameのためのむしろiSNSクライアント質問。 一度検索されています、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サーバが、iSNSがグローバルなIPアドレス指定領域で働いているクライアントであると排他的にサポートするのが、可能であることに注意してください。 これがそうであるなら、管理者は、適切なマッピングがiSNSクライアントがiSNSサーバにiSNSPセッションを開始するのを許容するためにNATゲートウェイの上で構成されるのを保証する必要があるだけです。その結果、iSNSサーバに含まれたすべての登録されたアドレスがNAT境界の外での使用のための公共のIPアドレスです。 NAT境界の中からサーバについて質問しているiSNSクライアントが全くいないのを保証するために注意するべきです。
2.7. Transfer of iSNS Database Records between iSNS Servers
2.7. iSNSサーバの間の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サーバが冗長のために望まれています。 バックアップサーバは、プライマリサーバのダイナミックに変化しているデータベースのコピーを維持する必要があります。
Tseng, et al. Standards Track [Page 15] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[15ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
To support the above applications, information in an iSNS server can be distributed to other iSNS servers either using the iSNS protocol, or through out-of-band mechanisms using non-iSNS protocols. The following examples illustrate possible methods for transferring data records between iSNS servers. In the first example, a back-end LDAP information base is used to support the iSNS server, and the data is transferred using the LDAP protocol. Once the record transfer of the remote device is completed, it becomes visible and accessible to local devices using the local iSNS server. This allows local devices to establish sessions with remote devices (provided that firewall boundaries can be negotiated).
上のアプリケーションをサポートするために、非iSNSプロトコルを使用しながら、iSNSプロトコル、またはバンドの外を通したメカニズムを使用することで他のiSNSサーバにiSNSサーバの情報を分配できます。 以下の例はiSNSサーバの間にデータレコードを移すための可能なメソッドを例証します。 最初の例では、バックエンドLDAP情報ベースはiSNSサーバをサポートするのに使用されます、そして、データは、LDAPプロトコルを使用することでわたっています。 遠隔装置の記録的な転送がいったん終了されていると、それは、ローカルのiSNSサーバを使用することでローカル装置に目に見えてアクセスしやすくなります。これは、ローカル装置が遠隔装置とのセッションを確立するのを許容します(ファイアウォール限界を交渉できれば)。
+-------------------------+ +-------------------------+
|+------+ iSNSP | | iSNSP +-----+ |
||dev A |<----->+------+ | | +------+<----->|dev C| |
|+------+ | | | | | | +-----+ |
|+------+ iSNSP |local | | | |remote| iSNSP +-----+ |
||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| |
|+------+ |server| | | |server| +-----+ |
|........ +--+---+ | WAN | +---+--+ |
|.dev C'. | | Link | | |
|........ | ============= | |
| | | | | |
| +--+---+ | | +---+--+ |
| | local|<--- <--- <--- <-|remote| |
| | LDAP | | LDAP: | | LDAP | |
| +------+ Xfer "dev C"| +------+ |
+-------------------------+ +-------------------------+
Enterprise Enterprise
Network A Network B
+-------------------------+ +-------------------------+ |+------+ iSNSP| | iSNSP+-----+ | ||dev A| <、-、-、-、-->+------+ | | +------+ <。----->|dev C| | |+------+ | | | | | | +-----+ | |+------+ iSNSP|ローカル| | | |リモート| iSNSP+-----+ | ||dev B| <、-、-、-、--、>| iSNS| | | | iSNS| <、-、-、-、--、>|dev D| | |+------+ |サーバ| | | |サーバ| +-----+ | |........ +--+---+ | WAN| +---+--+ | |'.dev C'。 | | リンク| | | |........ | ============= | | | | | | | | | +--+---+ | | +---+--+ | | | ローカル| <、-、-- <-- <-- <、-、|リモート| | | | LDAP| | LDAP: | | LDAP| | | +------+ Xfer「dev C」| +------+ | +-------------------------+ +-------------------------+ エンタープライズ企業網はネットワーク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を使用して、Network BからNetwork AのローカルのiSNSサーバにアクセスしやすいNetwork A.Onceまで「dev C」のための記録を移すことができます、AとBが今「dev C」に発見して、接続できるローカル装置。
Tseng, et al. Standards Track [Page 16] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[16ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
+-------------------------+ +-------------------------+
|+------+ iSNSP | | iSNSP +-----+ |
||dev A |<----->+------+ | | +------+<----->|dev C| |
|+------+ | | | | | | +-----+ |
|+------+ iSNSP |local | | | |remote| iSNSP +-----+ |
||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| |
|+------+ |server| | | |server| +-----+ |
|........ +------+ | WAN | +---+--+ |
|.dev C'. ^ | Link | | |
|........ | ============= v |
| | | | |SNMP |
| | | | | |
| +--+----+ | | v |
| | SNMP |<--- <--- <--- <---- |
| | Mgmt | | SNMP: Xfer "dev C" |
| |Station| | | |
| +-------+ | | |
+-------------------------+ +-------------------------+
Enterprise Enterprise
Network A Network B
+-------------------------+ +-------------------------+ |+------+ iSNSP| | iSNSP+-----+ | ||dev A| <、-、-、-、-->+------+ | | +------+ <。----->|dev C| | |+------+ | | | | | | +-----+ | |+------+ iSNSP|ローカル| | | |リモート| iSNSP+-----+ | ||dev B| <、-、-、-、--、>| iSNS| | | | iSNS| <、-、-、-、--、>|dev D| | |+------+ |サーバ| | | |サーバ| +-----+ | |........ +------+ | WAN| +---+--+ | |'.dev C'。 ^ | リンク| | | |........ | ============= v| | | | | |SNMP| | | | | | | | +--+----+ | | v| | | SNMP| <、-、-- <-- <-- <、-、-、--、|、|、| 管理| | SNMP: Xfer「dev C」| | |駅| | | | | +-------+ | | | +-------------------------+ +-------------------------+ エンタープライズ企業網はネットワーク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番目の例を例証します。 このメソッドは、手動で「dev C」のための必要な記録を検索して(GET)、そして、ローカルのiSNSサーバに直接(SET)それを保存するのにSNMPベースの管理局を使用します。 いったんNetwork AのローカルのiSNSサーバに記録を移すと、「dev C」はNetwork 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サーバの間にデバイス記録を移すのに固有のプロトコルを含む他のメソッドは使用できます。 これらの方法論に関するさらなる議論と説明はこのドキュメントの範囲を超えています。
2.8. Backup iSNS Servers
2.8. バックアップ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サーバとの相互作用について議定書の中で述べます。その何かがバックアップサーバです。
Tseng, et al. Standards Track [Page 17] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[17ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
- 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サーバを使用できます。 iSNSサーバのバックアップをとるためにネームサーバ記録を移すのに上のセクション2.7で説明されたメソッドは使用できます。 それぞれのバックアップサーバは、プライマリiSNSサーバで見つけられたネームサーバデータベースの余分なコピーを維持して、アクティブなサーバと同様に、iSNSプロトコルメッセージに反応できます。それぞれのバックアップサーバSHOULDはアクティブなiSNSサーバの健康と状態をモニターします、それ自身のデータベースがアクティブなサーバのデータベースと同期するのを確実にするためにチェックするのを含んでいて。 または、そして、それぞれのバックアップサーバがどうこれを達成するかが、実装依存している、()、iSNSプロトコルを使用するのを含めるかもしれなくなってください。 iSNSプロトコルが使用されているなら、バックアップサーバはControl Nodeとしてアクティブなサーバの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.
サーバSHALLが存在する個々のいずれもIPが同じ正準なiSNS TCPで聴かれる複数のサーバから摩擦を避けるために扱う最大1論理的なバックアップiSNSかUDPが数を移植します。
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
それぞれのバックアップサーバはアクティブなサーバのバックアップサーバのリストにおける相対的な先行に注意しなければなりません。 先行が既に知られていないなら、それぞれのバックアップサーバはiSNS鼓動メッセージからそれを学ぶかもしれません、規則正しいリストのIPアドレスの位置に注意することによって
Tseng, et al. Standards Track [Page 18] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[18ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
of backup server IP addresses. For example, if it is the first backup listed in the heartbeat message, then its backup precedence is 1. If it is the third backup server listed, then its backup precedence is 3.
バックアップサーバIPアドレスについて。 例えば、それが鼓動メッセージに記載された最初のバックアップであるなら、バックアップ先行は1です。 それが記載された3番目のバックアップサーバであるなら、バックアップ先行は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).
バックアップサーバがそれを設立するなら、より高い先行のアクティブなサーバと他のバックアップサーバに接続性を失って、次に、それはSHOULDです。それがアクティブなサーバであると仮定してください。接続性が失われたかどうか決定するメソッドは実装特有です。 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.
aがいつサーバのバックアップをとるかはアクティブなサーバになって、それはSHALLです。すべてのアクティブなサーバ責任を負ってください、iSNS鼓動メッセージの(使用されるなら)伝達を含んでいて。 iSNS鼓動を伝えるなら、バックアップサーバは、アクティブなServer IP AddressとTCP/UDP Portエントリーをそれ自身のIPアドレスとTCP/UDP Portに取り替えて、最後に知られている値から以前にアクティブなiSNSサーバからカウンタ分野を増加し始めます。しかしながら、それはバックアップサーバIP AddressとTCP/UDP Portエントリーのオリジナルの規則正しいリストを変えてはいけません。 プライマリバックアップサーバか他の、より高い先行バックアップサーバが戻るなら、既存のアクティブなサーバは新しいアクティブなサーバのデータベースが確実にバックアップとして元の状態にそれ自体を格下げする前に最新になるようにするのに原因となります。
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 Clientによる再登録は全く必要ではありません。 前のプライマリサーバがアクティブなサーバーの役割に戻るとき、同様に、iSNS Clientによる再登録は全く必要ではありません。
2.9. Transport Protocols
2.9. トランスポート・プロトコル
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マルチキャストを使用することで輸送されるか、放送されます。
2.9.1. Use of TCP for iSNS Communication
2.9.1. TCPのiSNSコミュニケーションの使用
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
iSNSコミュニケーションにTCPを使用するのは可能であるに違いありません。 iSNSサーバはクライアント登録証明書のためのTCP接続を受け入れなければなりません。 そしてEntity Status Inquiry(ESI)を受け取る、(セクション5.6.5を見てください、.13が)TCPの使用をモニターして、クライアントがPortal ESI Intervalを登録する。
Tseng, et al. Standards Track [Page 19] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[19ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
port number of the TCP port that will be used to receive ESI messages. The iSNS server initiates the TCP connection used to deliver the ESI message. This TCP connection does not need to be continuously open.
ESIメッセージを受け取るのに使用されるTCPポートの数を移植してください。 iSNSサーバはESIメッセージを提供するのに使用されるTCP接続を開始します。 このTCP接続を絶え間なく開かせる必要はありません。
To receive SCN notifications using TCP, the client registers the iSCSI or iFCP SCN Bitmap and the port number of the TCP port in the Portal used to receive SCNs. The iSNS server initiates the TCP connection used to deliver the SCN message. This TCP connection does not need to be continuously open.
TCPを使用することでSCN通知を受け取るために、クライアントはiSCSIかiFCP SCN BitmapとSCNsを受け取るのに使用されるPortalの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接続を使用するのは、可能です。 あるいはまた、別々の接続は使用されるかもしれません。
2.9.2. Use of UDP for iSNS Communication
2.9.2. UDPのiSNSコミュニケーションの使用
The iSNS server MAY accept UDP messages for client registrations. The iSNS server MUST accept registrations from clients requesting UDP-based ESI and SCN messages.
iSNSサーバはクライアント登録証明書へのUDPメッセージを受け入れるかもしれません。 iSNSサーバはUDPベースのESIを要求するクライアントとSCNメッセージから登録証明書を受け入れなければなりません。
To receive UDP-based ESI monitoring messages, the client registers the port number of the UDP port in at least one Portal to be used to receive and respond to ESI messages from the iSNS server. If a Network Entity has multiple Portals with registered ESI UDP Ports, then ESI messages SHALL be delivered to every Portal registered to receive such messages.
UDPベースのESIモニターしているメッセージを受け取るなら、クライアントは、iSNSサーバからESIメッセージに受信して、応じるのに使用されるために少なくとも1PortalのUDPポートのポートナンバーを示します。Network Entityであるなら、登録されたESI UDP Ports、当時のESIメッセージSHALLと複数のPortalsがそのようなメッセージを受け取るために登録されたあらゆるPortalに提供されましたか?
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メッセージを受け取るのに使用されるために少なくとも1PortalのUDPポートのポートナンバーを示します。Network Entityであるなら、登録されたSCN UDP Ports、当時のSCNメッセージSHALLと複数のPortalsがそのようなメッセージを受け取るために登録された各Portalに提供されましたか?
When using UDP to transport iSNS messages, each UDP datagram MUST contain exactly one iSNS PDU (see Section 5).
iSNSメッセージを輸送するのにUDPを使用するとき、それぞれのUDPデータグラムはちょうど1iSNS PDUを含まなければなりません(セクション5を見てください)。
2.9.3. iSNS Multicast and Broadcast Messages
2.9.3. iSNSマルチキャストと同報メッセージ
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鼓動のために割り当てられたIPマルチキャストアドレスで聴いているすべてのiSNSクライアントに、このメッセージをiSNSサーバで溯源して、送ります。
Tseng, et al. Standards Track [Page 20] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[20ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
2.10. Simple Network Management Protocol (SNMP) Requirements
2.10. 簡単なネットワーク管理プロトコル(SNMP)要件
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 Serverは、iSNS MIB[iSNSMIB]を通してSNMP管理フレームワーク[RFC3411]を使用することで管理されるかもしれません。 現在のインターネット標準のManagement Frameworkについて説明するドキュメントの詳細な概要について、RFC3410[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はオブジェクト識別に、Object Identifier(OID)を使用します。 それぞれのOIDのサイズは最大128のサブ識別子に制限されます。 iSCSIとiFCPプロトコルの両方がiSCSI Nameなどの、よりすばらしい識別子を含んでいます。長さにおける128のキャラクタ。 インデックスのような識別子を使用すると、1OIDあたり128以上のサブ識別子がもたらされるでしょう。 最大の長さが最大SNMPが長さをサポートしたより長い主要な識別子を持っているオブジェクトを支えるために、iSNSサーバはセカンダリ非ゼロ整数インデックス識別子を提供します。 これらはSHALLに索引をつけます。サーバがアクティブである限り、永続的であってください。 その上、インデックスは再利用されたコネが短期間であったなら最近反登録されたオブジェクトのためにSHOULD NOTを評価します。 インデックスを含むオブジェクト属性がセクション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で詳細に説明されます。
3. iSNS Object Model
3. iSNSオブジェクト・モデル
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デバイスとFibre Channelベースのデバイスの登録、発見、および管理にフレームワークを提供します(iFCPを使用して)。 このアーキテクチャフレームワークは様々な記憶装置オブジェクトについて説明するのが必要である要素とIPストレージネットワークに存在するかもしれない属性を提供します。 このアーキテクチャフレームワークで定義されたオブジェクトはNetwork Entity、Portal、Storage Node、FC Device、ディスカバリーDomain、およびディスカバリーDomain Setを含んでいます。 それぞれのこれらのオブジェクトは以下のセクションで詳細によりすばらしい説明されます。
Tseng, et al. Standards Track [Page 21] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[21ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
3.1. Network Entity Object
3.1. ネットワーク実体オブジェクト
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.
Network EntityオブジェクトはStorage NodeオブジェクトとPortalオブジェクトのコンテナです。 それは1Storage Nodesのユニークなセットへのアクセスをサポートするインフラストラクチャを表します。 Entity Identifier属性は、唯一Network Entityを区別して、iSNSサーバでNetwork Entityオブジェクトを登録するのに使用されるキーです。単一のNetwork Entityオブジェクトの中に含まれたすべてのStorage NodesとPortalsは粘着性があるユニットとして作動します。
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論理的なNetwork Entityによって表されるのが、可能であることに注意してください。 例えば、フィジカル・デバイスの上のStorage Nodesの1つはそのデバイスで利用可能なネットワーク・インターフェース(すなわち、Portals)の部分集合だけからアクセスしやすいかもしれません。 この場合、論理的なネットワーク実体(すなわち、「影の実体」)は、協力して作動できるPortalsとStorage Nodesを含むのに作成されて、使用されます。 1論理的なNetwork Entityにオブジェクト(入り口、Storage Nodesなど)を全く含むことができません。
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.
同様に、論理的なNetwork Entityが複数のフィジカル・デバイスかゲートウェイによってサポートされるのは、可能です。 例えば、複数のFC-iSCSIゲートウェイがただ一つのFibre ChannelネットワークにブリッジFCデバイスに使用されるかもしれません。 そのFibre Channelネットワークにすべてのデバイスを含むのに使用される独身の論理的なNetwork Entityをサポートするのに複数のゲートウェイをまとめて、使用できます。
3.2. Portal Object
3.2. 入り口のオブジェクト
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).
PortalオブジェクトはNetwork Entityの中のStorage Nodesへのアクセスを得ることができるインタフェースです。 IPアドレスとTCP/UDP Port数の属性は唯一Portalオブジェクトを区別します、そして、結合されているのが、iSNSサーバでPortalオブジェクトを登録するのに使用されるキーです。Portalは唯一無二の1Network Entityに含まれていて、1DDsに含まれるかもしれません(セクション3.6を見てください)。
3.3. Storage Node Object
3.3. ストレージノードオブジェクト
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).
Storage NodeオブジェクトはiSCSIかiFCPセッションの論理的な終点です。 iFCPでは、セッション終点はWorld Wide Port Name(WWPN)によって表されます。 iSCSIでは、セッション終点はデバイスのiSCSI Nameによって表されます。 iSCSIに関しては、iSCSI Name属性は、唯一Storage Nodeを区別して、iSNS ServerにStorage Nodeオブジェクトを登録するのに使用されるキーです。iFCPに関して、FC Port Name(WWPN)属性は、唯一Storage Nodeを区別して、iSNS ServerにStorage Nodeオブジェクトを登録するのに使用されるキーです。ストレージNodeは1個のNetwork Entityオブジェクトだけに含まれていて、1DDsに含まれるかもしれません(セクション3.6を見てください)。
Tseng, et al. Standards Track [Page 22] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[22ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
3.4. Portal Group Object
3.4. 入り口の群対象
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.
Portal Group(未成年者不適当映画)オブジェクトはPortalとiSCSI Nodeとの協会を代表します。 Portal Group(未成年者不適当映画)オブジェクトを使用することでEntityに登録された各PortalとiSCSI Storage Nodeは関連づけることができます。 未成年者不適当映画Tag(PGT)は、非NULLであるなら関連PortalがEntityの関連iSCSI Storage Nodeへのアクセスを提供するのを示します。 特定のiSCSI Storage Nodeのために同じPGT値を持っているすべてのPortalsがそのノードへの連携アクセスを許します。
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.
PortalかiSCSI Storage Nodeが登録されているとき、未成年者不適当映画オブジェクトは登録されるかもしれません。 iSCSI Node協会への各Portalは1個の唯一無二の未成年者不適当映画オブジェクトによって表されます。 PortalがiSCSI Nodeへのアクセスを提供するように、未成年者不適当映画オブジェクトのPGTは非NULLでなければなりません。 PGT値が指定されたPortalに登録して、iSCSI NodeがNULLである、またはどんなPGT値も登録されていないなら、PortalはEntityのそのiSCSI Nodeへのアクセスを提供しません。
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値は、複数のPortalsの向こう側にiSCSI Nodeへのアクセスを調整できるかどうかを示します。 特定のiSCSI Nodeのために同じPGT値を持っているすべてのPortalsがそのiSCSI Nodeへの連携アクセスを提供できます。 iSCSI Specificationによると、iSCSIノードへの連携アクセスはこれらのPortals[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.
未成年者不適当映画オブジェクトは関連Storage NodeとPortalオブジェクトのiSCSI Name、Portal IP Address、およびPortal TCP Port値によって唯一区別されます。 これらはiSNS Serverに未成年者不適当映画iSCSI Name、未成年者不適当映画Portal IP Address、および未成年者不適当映画Portal TCP/UDP Port属性によってそれぞれ表されます。 また、未成年者不適当映画オブジェクトはiSNS Serverで未成年者不適当映画Index価値によって唯一区別されます。
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.
その関連iSCSI Storage NodeかPortalオブジェクトに参照をつけることによって、新しい未成年者不適当映画オブジェクトを登録できるだけです。 メッセージキーとしてPortal Group Indexを使用するか、またはその関連iSCSI Storage NodeかPortalオブジェクトに参照をつけることによって、先在の未成年者不適当映画オブジェクトについて変更するか、または質問できます。 0長さのTag、Length、Value TLVは、PGT NULL値を示すのに使用されます。
The PG object is deregistered if and only if its associated iSCSI Node and Portal objects are both removed.
未成年者不適当映画オブジェクトが反登録される、その関連iSCSI NodeとPortalオブジェクトである場合にだけ、取り除かれた両方がそうです。
Tseng, et al. Standards Track [Page 23] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[23ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
3.5. Device Object
3.5. デバイスオブジェクト
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 DeviceはFibre Channel Nodeを表します。 このオブジェクトはFibre Channelデバイスの管理で役に立つかもしれない情報を含んでいます。 FC Node Name(WWNN)属性は、唯一FC Deviceを区別して、iSNS ServerにFC Deviceオブジェクトを登録するのに使用されるキーです。
The FC Device is contained in one or more Storage Node objects.
FC Deviceは1個以上のStorage Nodeオブジェクトに含まれています。
3.6. Discovery Domain Object
3.6. 発見ドメインオブジェクト
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.
Domains(DD)がセキュリティと管理メカニズムであるという発見は以前はよくアクセスと接続性を記憶装置に施していました。 質問と登録目的のために、それらはStorage NodeのためのコンテナとPortalオブジェクトであると考えられます。 Control Nodeから来ていないiSNSクライアントによる質問はそれが少なくとも1アクティブなDDを共有するオブジェクトの情報を返すだけです。 この規則への唯一の例外がPortalsと共にあります。 Network EntityのStorage NodesがDDにPortalsなしで登録されるなら、そのNetwork EntityのすべてのPortalsがそのDDの内在しているメンバーです。 ディスカバリーDomain ID(DD_ID)属性は、唯一ディスカバリーDomainオブジェクトを区別して、iSNS ServerにディスカバリーDomainオブジェクトを登録するのに使用されるキーです。
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 Setのメンバーであるならアクティブであると考えられます。 少なくとも1可能にされたDDSのメンバーでないDDsは障害があると考えられます。 Storage Nodeは1DDsのメンバーであるかもしれません。 可能にされたDDはそのDDのStorage Nodesの中で接続性を確立します。
3.7. Discovery Domain Set Object
3.7. 発見ドメインセットオブジェクト
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.
ディスカバリーDomain Set(DDS)はディスカバリーDomains(DDs)のためのコンテナオブジェクトです。 DDSsは1DDsを含むかもしれません。 同様に、各DDは1DDSsのメンバーであるかもしれません。 DDSsはiSNSサーバの連携セットのDDマッピングを保存するメカニズムです。アクティブなDDsは少なくとも1アクティブなDD Setのメンバーです。 複数のDDSsが同時にアクティブであると考えられるかもしれません。 ディスカバリーDomain Set ID(DDS_ID)属性は、唯一ディスカバリーDomain Setオブジェクトを区別して、iSNS ServerにディスカバリーDomain Setオブジェクトを登録するのに使用されるキーです。
3.8. Database Model
3.8. データベースモデル
As presented to the iSNS client, each object of a specific type in the iSNS database MUST have an implicit internal linear ordering based on the key(s) for that object type. This ordering provides the
iSNSクライアントに提示されるように、暗黙の内部の線形順序はiSNSデータベースの特定のタイプの各オブジェクトでそのオブジェクト・タイプのためのキーに基づいていなければなりません。 この注文は提供されます。
Tseng, et al. Standards Track [Page 24] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[24ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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.
セクション5.6を見てください。DevGetNext質問に応じる能力、(.5 .3)。 注文、iSNSデータベースSHOULD NOTのオブジェクトでは、オブジェクト入と削除の結果として注文しながら含意されたそれに関して変えてください。 すなわち、DevGetNextメッセージが遭遇する保存されたそうが一般に合理的な振舞いであったならiSNSデータベースSHOULDにおけるオブジェクトエントリーを乗り切る相対オーダ。
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 |
+-----------+ +--------------+ +-----------+ +-----------+
+--------------+ +-----------+ | ネットワーク|1 *| | | 実体|----| 入り口| | | | | +--------------+ +-----------+ |1 |1 |* | | | | |* | | +----------+ | | | 入り口| | | | グループ| | | +----------+ | | |* | | | | |* |1 |* +-----------+ +--------------+ +-----------+ +-----------+ | FC|1 *| ストレージ|* *| 発見|* *| 発見| | デバイス|----| ノード|----| ドメイン|----| ドメイン| | | | | | | | セットします。| +-----------+ +--------------+ +-----------+ +-----------+
* represents 0 to many possible relationships
* 多くの可能な関係に0を表します。
4. iSNS Implementation Requirements
4. iSNS実装要件
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で説明されます。
4.1. iSCSI Requirements
4.1. iSCSI要件
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の使用はOPTIONAL. iSCSIデバイスが同輩デバイスのiSCSI NameとIPアドレスによって手動で構成されるかもしれません、援助なしでことであるかまた、iSNS. iSCSIデバイスの介入は、同輩iSCSIデバイスを発見するのに、SLP[RFC2608]を使用するかもしれません。 しかしながら、iSNSは、より多くのiSCSIデバイスにストレージネットワークについて合わせて調整することの役に立ちます。
Tseng, et al. Standards Track [Page 25] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[25ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
4.1.1. Required Attributes for Support of iSCSI
4.1.1. iSCSIのサポートのための必要な属性
The following attributes are available to support iSCSI. Attributes indicated in the REQUIRED for Server column MUST be implemented by an iSNS server used to support iSCSI. Attributes indicated in the REQUIRED for Client column MUST be implemented by an iSCSI device that elects to use the iSNS. Attributes indicated in the K (Key) column uniquely identify the object type in the iSNS Server. A more detailed description of each attribute is found in Section 6.
以下の属性は、iSCSIをサポートするために利用可能です。 iSCSIをサポートするのに使用されるiSNSサーバでServerコラムのためにREQUIREDで示された属性を実装しなければなりません。 iSNSを使用するのを選ぶiSCSIデバイスでClientコラムのためにREQUIREDで示された属性を実装しなければなりません。 K(主要な)コラムで唯一示された属性はiSNS Serverのオブジェクト・タイプを特定します。それぞれの属性の、より詳細な記述はセクション6で見つけられます。
REQUIRED for:
Object Attribute K Server Client
------ --------- - ------ ------
NETWORK ENTITY Entity Identifier * * *
Entity Protocol * *
Management IP Address *
Timestamp *
Protocol Version Range *
Registration Period *
Entity Index *
Entity IKE Phase-1 Proposal
Entity Certificate
以下のためのREQUIRED オブジェクト属性Kサーバクライアント------ --------- - ------ ------ ネットワーク実体エンティティ識別名***実体プロトコル**管理IPアドレス*タイムスタンプ*プロトコルバージョン範囲*登録期間*実体インデックス*実体IKEフェーズ-1提案実体証明書
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
入り口IPアドレス***TCP/UDPポート***入り口英字名*ESI間隔*ESIポート*入り口インデックス*SCNポート*入り口セキュリティビットマップ*入り口IKEフェーズ-1提案入り口のIKEフェーズ-2提案入り口の証明書
PORTAL GROUP PG iSCSI Name * * *
PG IP Address * * *
PG TCP/UDP Port * * *
PG Tag * *
PG Index *
入り口グループ未成年者不適当映画iSCSI名前***未成年者不適当映画IPアドレス***未成年者不適当映画TCP/UDPポート***未成年者不適当映画タグ**未成年者不適当映画インデックス*
Tseng, et al. Standards Track [Page 26] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[26ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
STORAGE NODE iSCSI Name * * *
iSCSI Node Type * *
Alias *
iSCSI SCN Bitmap *
iSCSI Node Index *
WWNN Token
iSCSI AuthMethod
iSCSI Node Certificate
ストレージノードiSCSI名前***iSCSIノード種別**アリア*iSCSI SCNビットマップ*iSCSIノードインデックス*WWNNトークンiSCSI AuthMethod iSCSIノード証明書
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 *
発見ドメインDD ID***DD英字名*DDメンバーiSCSIノードインデックス*DDメンバーiSCSI名前*DDメンバー入り口インデックス*DDメンバー入り口IP Addr*DDメンバー入り口TCP/UDP*DD機能*
DISCOVERY DOMAIN DDS Identifier * *
SET DDS Symbolic Name *
DDS Status *
ドメインDDS識別子**がDDS英字名*DDS状態*を設定するという発見
All iSCSI user-specified and vendor-specified attributes are OPTIONAL to implement and use.
すべてのiSCSIがユーザと同じくらい指定しました、そして、ベンダーによって指定された属性は道具と使用へのOPTIONALです。
Tseng, et al. Standards Track [Page 27] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[27ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
4.1.2. Examples: iSCSI Object Model Diagrams
4.1.2. 例: 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.
以下のダイヤグラムは純真なiSCSIベースの創始者と目標がiSNSサーバで保存されたデータベースオブジェクトを使用することでどう代理をされるかをモデル化します。この実装では、各目標と創始者は独身のPortalに取り付けられます。
+----------------------------------------------------------------+
| IP Network |
+------------+--------------------------------------+------------+
| |
| |
+-----+------+------+-----+ +-----+------+------+-----+
| | PORTAL | | | | PORTAL | |
| | -IP Addr 1 | | | | -IP Addr 2 | |
| | -TCP Port 1 | | | | -TCP Port 2 | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | | | | | | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | PORTAL GROUP| | | | PORTAL GROUP| |
| | -Prtl Tag 1 | | | | -Prtl Tag 2 | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | | | | | | |
| +--------+ +--------+ | | +-------+ +--------+ |
| | | | | | | |
| | STORAGE NODE | | | | STORAGE NODE | |
| | -iSCSI Name | | | | -iSCSI Name | |
| | -Alias: "server1"| | | | -Alias: "disk1"| |
| | -Type: initiator | | | | -Type: target | |
| | | | | | | |
| +-------------------+ | | +------------------+ |
| | | |
| NETWORK ENTITY | | NETWORK ENTITY |
| -Entity ID (FQDN): | | -Entity ID (FQDN): |
| "strg1.example.com" | | "strg2.example.net" |
| -Protocol: iSCSI | | -Protocol: iSCSI |
| | | |
+-------------------------+ +-------------------------+
+----------------------------------------------------------------+ | IPネットワーク| +------------+--------------------------------------+------------+ | | | | +-----+------+------+-----+ +-----+------+------+-----+ | | 入り口| | | | 入り口| | | | -IP Addr1| | | | -IP Addr2| | | | -TCPポート1| | | | -TCPポート2| | | +-----+ +-----+ | | +-----+ +-----+ | | | | | | | | | | +-----+ +-----+ | | +-----+ +-----+ | | | 入り口のグループ| | | | 入り口のグループ| | | | -Prtlタグ1| | | | -Prtlタグ2| | | +-----+ +-----+ | | +-----+ +-----+ | | | | | | | | | | +--------+ +--------+ | | +-------+ +--------+ | | | | | | | | | | | ストレージノード| | | | ストレージノード| | | | -iSCSI名| | | | -iSCSI名| | | | -アリア: "server1""| | | | -アリア: "disk1""| | | | -以下をタイプしてください。 創始者| | | | -以下をタイプしてください。 目標| | | | | | | | | | | +-------------------+ | | +------------------+ | | | | | | ネットワーク実体| | ネットワーク実体| | -実体ID(FQDN): | | -実体ID(FQDN): | | "strg1.example.com"| | "strg2.example.net"| | -プロトコル: iSCSI| | -プロトコル: 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:
より複雑なデバイスについて説明するためにオブジェクト・モデルを広げることができます、それぞれのコントローラが複数のPortalインタフェースのどれかを通してアクセスしやすい1台以上のストレージコントローラでのiSCSIデバイスのように、ことによると複数のPortal Groupsを使用して。 何か元のインタフェースが失敗するならPortalが連結する補欠を通してこのデバイスの上のストレージコントローラにアクセスできます。 以下のダイヤグラムはそのようなデバイスについて説明します:
Tseng, et al. Standards Track [Page 28] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[28ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
+---------------------------------------------------------------+
| IP Network |
+-------------------+-----------------------+-------------------+
| |
| |
+------------+------+------+---------+------+------+------------+
| | PORTAL 1 | | PORTAL 2 | |
| | -IP Addr 1 | | -IP Addr 2 | |
| | -TCP Port 1 | | -TCP Port 2 | |
| +-----+ +-----+ +-----+ +-----+ |
| | | | | |
| +---------------+ +---------------------+ +---------------+ |
| +-------+ +----------------+ +-------------------+ +------+ |
| | | | | | | |
| +-------+ +-------+ +------+ +--------+ +--------+ +------+ |
| | | | | | | |
| | STORAGE NODE 1 | | STORAGE NODE 2 | | STORAGE NODE 3 | |
| | -iSCSI Name 1 | | -iSCSI Name 2 | | -iSCSI Name 3 | |
| | -Alias: "disk1"| | -Alias: "disk2"| | -Alias: "disk3"| |
| | -Type: target | | -Type: target | | -Type: target | |
| | | | | | | |
| +-----------------+ +-----------------+ +-----------------+ |
| |
| NETWORK ENTITY |
| -Entity ID (FQDN): "dev1.example.com" |
| -Protocol: iSCSI |
| |
| Portal Group Object Table |
| Storage-Node Portal Portal-Group-Tag |
| 1 1 10 |
| 1 2 NULL (no access permitted) |
| 2 1 20 |
| 2 2 20 |
| 3 1 30 |
| 3 2 10 |
| |
+---------------------------------------------------------------+
+---------------------------------------------------------------+ | IP Network | +-------------------+-----------------------+-------------------+ | | | | +------------+------+------+---------+------+------+------------+ | | PORTAL 1 | | PORTAL 2 | | | | -IP Addr 1 | | -IP Addr 2 | | | | -TCP Port 1 | | -TCP Port 2 | | | +-----+ +-----+ +-----+ +-----+ | | | | | | | | +---------------+ +---------------------+ +---------------+ | | +-------+ +----------------+ +-------------------+ +------+ | | | | | | | | | | +-------+ +-------+ +------+ +--------+ +--------+ +------+ | | | | | | | | | | | STORAGE NODE 1 | | STORAGE NODE 2 | | STORAGE NODE 3 | | | | -iSCSI Name 1 | | -iSCSI Name 2 | | -iSCSI Name 3 | | | | -Alias: "disk1"| | -Alias: "disk2"| | -Alias: "disk3"| | | | -Type: target | | -Type: target | | -Type: target | | | | | | | | | | | +-----------------+ +-----------------+ +-----------------+ | | | | NETWORK ENTITY | | -Entity ID (FQDN): "dev1.example.com" | | -Protocol: iSCSI | | | | Portal Group Object Table | | Storage-Node Portal Portal-Group-Tag | | 1 1 10 | | 1 2 NULL (no access permitted) | | 2 1 20 | | 2 2 20 | | 3 1 30 | | 3 2 10 | | | +---------------------------------------------------------------+
Storage Node 1 is accessible via Portal 1 with a PGT of 10. It does not have a Portal Group Tag (PGT) assigned for Portal 2, so Storage Node 1 cannot be accessed via Portal 2.
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.
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].
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].
Tseng, et al. Standards Track [Page 29] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Tseng, et al. Standards Track [Page 29] RFC 4171 Internet Storage Name Service (iSNS) September 2005
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.
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.
4.1.3. Required Commands and Response Messages for Support of iSCSI
4.1.3. Required Commands and Response Messages for Support of iSCSI
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.
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.
REQUIRED for:
Message Description Abbreviation Func_ID Server Client
------------------- ------------ ------- ------ ------
RESERVED 0x0000
Device Attr Reg Request DevAttrReg 0x0001 * *
Dev Attr Query Request DevAttrQry 0x0002 * *
Dev Get Next Request DevGetNext 0x0003 *
Deregister Dev Request DevDereg 0x0004 * *
SCN Register Request SCNReg 0x0005 *
SCN Deregister Request SCNDereg 0x0006 *
SCN Event SCNEvent 0x0007 *
State Change Notification SCN 0x0008 *
DD Register DDReg 0x0009 * *
DD Deregister DDDereg 0x000A * *
DDS Register DDSReg 0x000B * *
DDS Deregister DDSDereg 0x000C * *
Entity Status Inquiry ESI 0x000D *
Name Service Heartbeat Heartbeat 0x000E
RESERVED 0x000F-0x00FF
Vendor Specific 0x0100-0x01FF
RESERVED 0x0200-0x7FFF
REQUIRED for: Message Description Abbreviation Func_ID Server Client ------------------- ------------ ------- ------ ------ RESERVED 0x0000 Device Attr Reg Request DevAttrReg 0x0001 * * Dev Attr Query Request DevAttrQry 0x0002 * * Dev Get Next Request DevGetNext 0x0003 * Deregister Dev Request DevDereg 0x0004 * * SCN Register Request SCNReg 0x0005 * SCN Deregister Request SCNDereg 0x0006 * SCN Event SCNEvent 0x0007 * State Change Notification SCN 0x0008 * DD Register DDReg 0x0009 * * DD Deregister DDDereg 0x000A * * DDS Register DDSReg 0x000B * * DDS Deregister DDSDereg 0x000C * * Entity Status Inquiry ESI 0x000D * Name Service Heartbeat Heartbeat 0x000E RESERVED 0x000F-0x00FF Vendor Specific 0x0100-0x01FF RESERVED 0x0200-0x7FFF
The following are iSNSP response messages used in support of iSCSI:
The following are iSNSP response messages used in support of iSCSI:
REQUIRED for:
Response Message Desc Abbreviation Func_ID Server Client
--------------------- ------------ ------- ------ ------
RESERVED 0x8000
Device Attr Register Rsp DevAttrRegRsp 0x8001 * *
Device Attr Query Rsp DevAttrQryRsp 0x8002 * *
Device Get Next Rsp DevGetNextRsp 0x8003 *
Device Dereg Rsp DevDeregRsp 0x8004 * *
SCN Register Rsp SCNRegRsp 0x8005 *
REQUIRED for: Response Message Desc Abbreviation Func_ID Server Client --------------------- ------------ ------- ------ ------ RESERVED 0x8000 Device Attr Register Rsp DevAttrRegRsp 0x8001 * * Device Attr Query Rsp DevAttrQryRsp 0x8002 * * Device Get Next Rsp DevGetNextRsp 0x8003 * Device Dereg Rsp DevDeregRsp 0x8004 * * SCN Register Rsp SCNRegRsp 0x8005 *
Tseng, et al. Standards Track [Page 30] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Tseng, et al. Standards Track [Page 30] RFC 4171 Internet Storage Name Service (iSNS) September 2005
SCN Deregister Rsp SCNDeregRsp 0x8006 * SCN Event Rsp SCNEventRsp 0x8007 * SCN Response SCNRsp 0x8008 * DD Register Rsp DDRegRsp 0x8009 * * DD Deregister Rsp DDDeregRsp 0x800A * * DDS Register Rsp DDSRegRsp 0x800B * * DDS Deregister Rsp DDSDeregRsp 0x800C * * Entity Stat Inquiry Rsp ESIRsp 0x800D * RESERVED 0x800E-0x80FF Vendor Specific 0x8100-0x81FF RESERVED 0x8200-0xFFFF
SCN Deregister Rsp SCNDeregRsp 0x8006 * SCN Event Rsp SCNEventRsp 0x8007 * SCN Response SCNRsp 0x8008 * DD Register Rsp DDRegRsp 0x8009 * * DD Deregister Rsp DDDeregRsp 0x800A * * DDS Register Rsp DDSRegRsp 0x800B * * DDS Deregister Rsp DDSDeregRsp 0x800C * * Entity Stat Inquiry Rsp ESIRsp 0x800D * RESERVED 0x800E-0x80FF Vendor Specific 0x8100-0x81FF RESERVED 0x8200-0xFFFF
4.2. iFCP Requirements
4.2. iFCP Requirements
In iFCP, use of iSNS is REQUIRED. No alternatives exist for support of iFCP Naming & Discovery functions.
In iFCP, use of iSNS is REQUIRED. No alternatives exist for support of iFCP Naming & Discovery functions.
4.2.1. Required Attributes for Support of iFCP
4.2.1. Required Attributes for Support of 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.
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.
REQUIRED for:
Object Attribute K Server Client
------ --------- - ------ ------
NETWORK ENTITY Entity Identifier * * *
Entity Protocol * *
Management IP Address *
Timestamp *
Protocol Version Range *
Registration period
Entity Index
Entity IKE Phase-1 Proposal
Entity Certificate
REQUIRED for: Object Attribute K Server Client ------ --------- - ------ ------ NETWORK ENTITY Entity Identifier * * * Entity Protocol * * Management IP Address * Timestamp * Protocol Version Range * Registration period Entity Index Entity IKE Phase-1 Proposal Entity Certificate
PORTAL IP Address * * *
TCP/UDP Port * * *
Symbolic Name *
ESI Interval *
ESI Port *
SCN Port *
Portal IKE Phase-1 Proposal
Portal IKE Phase-2 Proposal
PORTAL IP Address * * * TCP/UDP Port * * * Symbolic Name * ESI Interval * ESI Port * SCN Port * Portal IKE Phase-1 Proposal Portal IKE Phase-2 Proposal
Tseng, et al. Standards Track [Page 31] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Tseng, et al. Standards Track [Page 31] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Portal Certificate
Security Bitmap *
Portal Certificate Security Bitmap *
STORAGE NODE FC Port Name (WWPN) * * *
(FC Port) Port_ID * *
FC Port Type * *
Port Symbolic Name *
Fabric Port Name (FWWN) *
Hard Address *
Port IP Address *
Class of Service *
FC FC-4 Types *
FC FC-4 Descriptors *
FC FC-4 Features *
SCN Bitmap *
iFCP Port Role *
Permanent Port Name *
STORAGE NODE FC Port Name (WWPN) * * * (FC Port) Port_ID * * FC Port Type * * Port Symbolic Name * Fabric Port Name (FWWN) * Hard Address * Port IP Address * Class of Service * FC FC-4 Types * FC FC-4 Descriptors * FC FC-4 Features * SCN Bitmap * iFCP Port Role * Permanent Port Name *
FC DEVICE FC Node Name (WWNN) * * *
(FC Node) Node Symbolic Name *
Node IP Address *
Node IPA *
Proxy iSCSI Name
FC DEVICE FC Node Name (WWNN) * * * (FC Node) Node Symbolic Name * Node IP Address * Node IPA * Proxy iSCSI Name
DISCOVERY DOMAIN DD ID * * *
DD Symbolic Name *
DD Member FC Port Name *
DD Member Portal Index *
DD Member Portal IP Addr *
DD Member Portal TCP/UDP *
DISCOVERY DOMAIN DD ID * * * DD Symbolic Name * DD Member FC Port Name * DD Member Portal Index * DD Member Portal IP Addr * DD Member Portal TCP/UDP *
DISCOVERY DOMAIN DDS ID * *
SET DDS Symbolic Name *
DDS Status *
DISCOVERY DOMAIN DDS ID * * SET DDS Symbolic Name * DDS Status *
OTHER Switch Name
Preferred_ID
Assigned_ID
Virtual_Fabric_ID
OTHER Switch Name Preferred_ID Assigned_ID Virtual_Fabric_ID
All iFCP user-specified and vendor-specified attributes are OPTIONAL to implement and use.
All iFCP user-specified and vendor-specified attributes are OPTIONAL to implement and use.
4.2.2. Example: iFCP Object Model Diagram
4.2.2. Example: iFCP Object Model Diagram
The iFCP protocol allows native Fibre Channel devices or Fibre Channel fabrics connected to an iFCP gateway to be directly internetworked using IP.
The iFCP protocol allows native Fibre Channel devices or Fibre Channel fabrics connected to an iFCP gateway to be directly internetworked using IP.
Tseng, et al. Standards Track [Page 32] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Tseng, et al. Standards Track [Page 32] RFC 4171 Internet Storage Name Service (iSNS) September 2005
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.
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.
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.
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.
+--------------------------------------------------------+
| IP Network |
+--------+-----------------+-----------------------------+
| |
+-+------+------+---+------+------+----------------------+
| | PORTAL | | PORTAL | NETWORK ENTITY |
| | -IP Addr 1 | | -IP Addr 2 | -Entity ID (FQDN): |
| | -TCP Port 1 | | -TCP Port 2 | "gtwy1.example.com" |
| +-----+ +-----+ +-----+ +-----+ -Protocol: iFCP |
| | | | | |
| +-----+ +---------------+ +----------------------+ |
| +-----+ +---------------+ +-------------+ +------+ |
| | | | | | | |
| +-----+ +-----+ +----+ +------+ +----+ +------+ |
| |STORAGE NODE | |STORAGE NODE | |STORAGE NODE | |
| | -WWPN 1 | | -WWPN 2 | | -WWPN 3 | |
| | -Port ID 1 | | -Port ID 2 | | -Port ID 3 | |
| | -FWWN 1 | | -FWWN 2 | | -FWWN 3 | |
| | -FC COS | | -FC COS | | -FC COS | |
| +------+------+ +-------+-----+ +----+--------+ |
+--------|-------------------|------------|--------------+
| | |
+------+------+ +---+------------+---+
| FC DEVICE | | FC DEVICE |
| -WWNN 1 | | -WWNN 2 |
| | | |
+-------------+ +--------------------+
+--------------------------------------------------------+ | IP Network | +--------+-----------------+-----------------------------+ | | +-+------+------+---+------+------+----------------------+ | | PORTAL | | PORTAL | NETWORK ENTITY | | | -IP Addr 1 | | -IP Addr 2 | -Entity ID (FQDN): | | | -TCP Port 1 | | -TCP Port 2 | "gtwy1.example.com" | | +-----+ +-----+ +-----+ +-----+ -Protocol: iFCP | | | | | | | | +-----+ +---------------+ +----------------------+ | | +-----+ +---------------+ +-------------+ +------+ | | | | | | | | | | +-----+ +-----+ +----+ +------+ +----+ +------+ | | |STORAGE NODE | |STORAGE NODE | |STORAGE NODE | | | | -WWPN 1 | | -WWPN 2 | | -WWPN 3 | | | | -Port ID 1 | | -Port ID 2 | | -Port ID 3 | | | | -FWWN 1 | | -FWWN 2 | | -FWWN 3 | | | | -FC COS | | -FC COS | | -FC COS | | | +------+------+ +-------+-----+ +----+--------+ | +--------|-------------------|------------|--------------+ | | | +------+------+ +---+------------+---+ | FC DEVICE | | FC DEVICE | | -WWNN 1 | | -WWNN 2 | | | | | +-------------+ +--------------------+
Tseng, et al. Standards Track [Page 33] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Tseng, et al. Standards Track [Page 33] RFC 4171 Internet Storage Name Service (iSNS) September 2005
4.2.3. Required Commands and Response Messages for Support of iFCP
4.2.3. Required Commands and Response Messages for Support of iFCP
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.
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.
REQUIRED for:
Message Description Abbreviation Func ID Server Client
------------------- ------------ ------- ------ ------
RESERVED 0x0000
Device Attr Reg Request DevAttrReg 0x0001 * *
Device Attr Query Request DevAttrQry 0x0002 * *
Device Get Next Request DevGetNext 0x0003 *
Device Dereg Request DevDereg 0x0004 * *
SCN Register Request SCNReg 0x0005 *
SCN Deregister Request SCNDereg 0x0006 *
SCN Event SCNEvent 0x0007 *
State Change Notification SCN 0x0008 *
DD Register DDReg 0x0009 * *
DD Deregister DDDereg 0x000A * *
DDS Register DDSReg 0x000B * *
DDS Deregister DDSDereg 0x000C * *
Entity Status Inquiry ESI 0x000D *
Name Service Heartbeat Heartbeat 0x000E *
Reserved Reserved 0x000F-0x0010
Request FC_DOMAIN_ID RqstDomId 0x0011
Release FC_DOMAIN_ID RlseDomId 0x0012
Get FC_DOMAIN_IDs GetDomId 0x0013
RESERVED 0x0014-0x00FF
Vendor Specific 0x0100-0x01FF
RESERVED 0x0200-0x7FFF
REQUIRED for: Message Description Abbreviation Func ID Server Client ------------------- ------------ ------- ------ ------ RESERVED 0x0000 Device Attr Reg Request DevAttrReg 0x0001 * * Device Attr Query Request DevAttrQry 0x0002 * * Device Get Next Request DevGetNext 0x0003 * Device Dereg Request DevDereg 0x0004 * * SCN Register Request SCNReg 0x0005 * SCN Deregister Request SCNDereg 0x0006 * SCN Event SCNEvent 0x0007 * State Change Notification SCN 0x0008 * DD Register DDReg 0x0009 * * DD Deregister DDDereg 0x000A * * DDS Register DDSReg 0x000B * * DDS Deregister DDSDereg 0x000C * * Entity Status Inquiry ESI 0x000D * Name Service Heartbeat Heartbeat 0x000E * Reserved Reserved 0x000F-0x0010 Request FC_DOMAIN_ID RqstDomId 0x0011 Release FC_DOMAIN_ID RlseDomId 0x0012 Get FC_DOMAIN_IDs GetDomId 0x0013 RESERVED 0x0014-0x00FF Vendor Specific 0x0100-0x01FF RESERVED 0x0200-0x7FFF
The following are iSNSP response messages in support of iFCP:
The following are iSNSP response messages in support of iFCP:
REQUIRED for:
Response Message Desc Abbreviation Func_ID Server Client
--------------------- ------------ ------- ------ ------
RESERVED 0x8000
Device Attr Reg Rsp DevAttrRegRsp 0x8001 * *
Device Attr Query Rsp DevAttrQryRsp 0x8002 * *
Device Get Next Rsp DevGetNextRsp 0x8003 *
Device Deregister Rsp DevDeregRsp 0x8004 * *
SCN Register Rsp SCNRegRsp 0x8005 *
SCN Deregister Rsp SCNDeregRsp 0x8006 *
SCN Event Rsp SCNEventRsp 0x8007 *
SCN Rsp SCNRsp 0x8008 *
REQUIRED for: Response Message Desc Abbreviation Func_ID Server Client --------------------- ------------ ------- ------ ------ RESERVED 0x8000 Device Attr Reg Rsp DevAttrRegRsp 0x8001 * * Device Attr Query Rsp DevAttrQryRsp 0x8002 * * Device Get Next Rsp DevGetNextRsp 0x8003 * Device Deregister Rsp DevDeregRsp 0x8004 * * SCN Register Rsp SCNRegRsp 0x8005 * SCN Deregister Rsp SCNDeregRsp 0x8006 * SCN Event Rsp SCNEventRsp 0x8007 * SCN Rsp SCNRsp 0x8008 *
Tseng, et al. Standards Track [Page 34] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Tseng, et al. Standards Track [Page 34] RFC 4171 Internet Storage Name Service (iSNS) September 2005
DD Register Rsp DDRegRsp 0x8009 * * DD Deregister Rsp DDDeregRsp 0x800A * * DDS Register Rsp DDSRegRsp 0x800B * * DDS Deregister Rsp DDSDeregRsp 0x800C * * Entity Status Inquiry Rsp ESIRsp 0x800D * NOT USED 0x800E RESERVED 0x800F-0x8010 Request FC_DOMAIN_ID Rsp RqstDomIdRsp 0x8011 Release FC_DOMAIN_ID Rsp RlseDomIdRsp 0x8012 Get FC_DOMAIN_IDs GetDomIdRsp 0x0013 RESERVED 0x8014-0x80FF Vendor Specific 0x8100-0x81FF RESERVED 0x8200-0xFFFF
DD Register Rsp DDRegRsp 0x8009 * * DD Deregister Rsp DDDeregRsp 0x800A * * DDS Register Rsp DDSRegRsp 0x800B * * DDS Deregister Rsp DDSDeregRsp 0x800C * * Entity Status Inquiry Rsp ESIRsp 0x800D * NOT USED 0x800E RESERVED 0x800F-0x8010 Request FC_DOMAIN_ID Rsp RqstDomIdRsp 0x8011 Release FC_DOMAIN_ID Rsp RlseDomIdRsp 0x8012 Get FC_DOMAIN_IDs GetDomIdRsp 0x0013 RESERVED 0x8014-0x80FF Vendor Specific 0x8100-0x81FF RESERVED 0x8200-0xFFFF
5. iSNSP Message Format
5. iSNSP Message Format
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:
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:
Byte MSb LSb
Offset 0 15 16 31
+---------------------+----------------------+
0 | iSNSP VERSION | FUNCTION ID | 4 Bytes
+---------------------+----------------------+
4 | PDU LENGTH | FLAGS | 4 Bytes
+---------------------+----------------------+
8 | TRANSACTION ID | SEQUENCE ID | 4 Bytes
+---------------------+----------------------+
12 | |
| PDU PAYLOAD | N Bytes
| ... |
+--------------------------------------------+
12+N | AUTHENTICATION BLOCK (Multicast/Broadcast) | L Bytes
+--------------------------------------------+
Total Length = 12 + N + L
Byte MSb LSb Offset 0 15 16 31 +---------------------+----------------------+ 0 | iSNSP VERSION | FUNCTION ID | 4 Bytes +---------------------+----------------------+ 4 | PDU LENGTH | FLAGS | 4 Bytes +---------------------+----------------------+ 8 | TRANSACTION ID | SEQUENCE ID | 4 Bytes +---------------------+----------------------+ 12 | | | PDU PAYLOAD | N Bytes | ... | +--------------------------------------------+ 12+N | AUTHENTICATION BLOCK (Multicast/Broadcast) | L Bytes +--------------------------------------------+ Total Length = 12 + N + L
5.1. iSNSP PDU Header
5.1. iSNSP PDU Header
The iSNSP PDU header contains the iSNSP VERSION, FUNCTION ID, PDU LENGTH, FLAGS, TRANSACTION ID, and SEQUENCE ID fields as defined below.
The iSNSP PDU header contains the iSNSP VERSION, FUNCTION ID, PDU LENGTH, FLAGS, TRANSACTION ID, and SEQUENCE ID fields as defined below.
Tseng, et al. Standards Track [Page 35] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Tseng, et al. Standards Track [Page 35] RFC 4171 Internet Storage Name Service (iSNS) September 2005
5.1.1. iSNSP Version
5.1.1. iSNSP Version
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.
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.
5.1.2. iSNSP Function ID
5.1.2. iSNSP Function ID
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.
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.
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.
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.
5.1.3. iSNSP PDU Length
5.1.3. iSNSP PDU Length
The iSNS PDU Length specifies the length of the PDU PAYLOAD field in bytes. The PDU Payload contains TLV attributes for the operation.
The iSNS PDU Length specifies the length of the PDU PAYLOAD field in bytes. The PDU Payload contains TLV attributes for the operation.
Additionally, response messages contain a success/failure code. The PDU Length MUST be 4-byte aligned.
Additionally, response messages contain a success/failure code. The PDU Length MUST be 4-byte aligned.
5.1.4. iSNSP Flags
5.1.4. iSNSP Flags
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:
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:
Bit Position Enabled (1) means:
------------ -----------------
16 Sender is the iSNS client
17 Sender is the iSNS server
18 Authentication block is present
19 Replace flag (for DevAttrReg)
20 Last PDU of the iSNS message
21 First PDU of the iSNS message
22-31 RESERVED
Bit Position Enabled (1) means: ------------ ----------------- 16 Sender is the iSNS client 17 Sender is the iSNS server 18 Authentication block is present 19 Replace flag (for DevAttrReg) 20 Last PDU of the iSNS message 21 First PDU of the iSNS message 22-31 RESERVED
5.1.5. iSNSP Transaction ID
5.1.5. iSNSP Transaction ID
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
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
Tseng, et al. Standards Track [Page 36] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Tseng, et al. Standards Track [Page 36] RFC 4171 Internet Storage Name Service (iSNS) September 2005
message is retransmitted, the original TRANSACTION ID value MUST be used. All PDUs comprising an iSNSP message must have the same TRANSACTION ID value.
message is retransmitted, the original TRANSACTION ID value MUST be used. All PDUs comprising an iSNSP message must have the same TRANSACTION ID value.
5.1.6. iSNSP Sequence ID
5.1.6. iSNSP Sequence 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.
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.
5.2. iSNSP Message Segmentation and Reassembly
5.2. iSNSP Message Segmentation and Reassembly
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 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.
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.
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.
5.3. iSNSP PDU Payload
5.3. iSNSP PDU Payload
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:
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:
Byte MSb LSb
Offset 0 31
+--------------------------------------------+
0 | Attribute Tag | 4 Bytes
+--------------------------------------------+
4 | Attribute Length (N) | 4 Bytes
+--------------------------------------------+
8 | |
| Attribute Value | N Bytes
| |
+--------------------------------------------+
Total Length = 8 + N
Byte MSb LSb Offset 0 31 +--------------------------------------------+ 0 | Attribute Tag | 4 Bytes +--------------------------------------------+ 4 | Attribute Length (N) | 4 Bytes +--------------------------------------------+ 8 | | | Attribute Value | N Bytes | | +--------------------------------------------+ Total Length = 8 + N
Tseng, et al. Standards Track [Page 37] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Tseng, et al. Standards Track [Page 37] RFC 4171 Internet Storage Name Service (iSNS) September 2005
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.
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.
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.
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.
Attribute Value: a variable-length field containing the attribute
value and padding bytes (if necessary).
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.
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.
5.3.1. Attribute Value 4-Byte Alignment
5.3.1. Attribute Value 4-Byte Alignment
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.
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.
Tseng, et al. Standards Track [Page 38] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[38ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
5.4. iSNSP Response Status Codes
5.4. iSNSP応答ステータスコード
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有効搭載量における最初の分野として4バイトのStatus Code分野を含んでいます。 オリジナルのiSNSP要求メッセージがiSNSサーバ、またはESIとSCNメッセージのためのiSNSクライアントによって通常処理されたなら、この分野SHALLは0(うまくいっている)のステータスコードを含んでいます。 非ゼロステータスコードは全体のiSNSクライアント要求メッセージの拒絶を示します。
Status Code Status Description
----------- -----------------
0 Successful
1 Unknown Error
2 Message Format Error
3 Invalid Registration
4 RESERVED
5 Invalid Query
6 Source Unknown
7 Source Absent
8 Source Unauthorized
9 No Such Entry
10 Version Not Supported
11 Internal Error
12 Busy
13 Option Not Understood
14 Invalid Update
15 Message (FUNCTION_ID) Not Supported
16 SCN Event Rejected
17 SCN Registration Rejected
18 Attribute Not Implemented
19 FC_DOMAIN_ID Not Available
20 FC_DOMAIN_ID Not Allocated
21 ESI Not Available
22 Invalid Deregistration
23 Registration Feature Not Supported
24 and above RESERVED
ステータスコード状態記述----------- ----------------- 0 そのようなエントリー10バージョンが11内部エラー12の忙しい13オプションをサポートしなかった1つのうまくいっている未知の誤り2のメッセージ・フォーマット誤り3の無効の登録4予約された5無効の質問6のソースの未知の7ソース欠けている8ソース権限のない9ノー、は14の無効のアップデート15メッセージを理解していませんでした; 16SCNイベントであることはサポートされなかった(機能_ID)は登録の拒絶された18属性が24以上であることはサポートされなかった利用可能な22無効のDeregistration23登録機能ではなく、IDが21を割り当てなかった利用可能な20FC_ドメイン_ではなく、ID ESIが予約した19FC_ドメイン_を実装しなかった17SCNを拒絶しました。
5.5. Authentication for iSNS Multicast and Broadcast Messages
5.5. iSNSマルチキャストと同報メッセージのための認証
For iSNS multicast and broadcast messages (see Section 2.9.3), the iSNSP provides authentication capability. The following section details the iSNS Authentication Block, which is identical in format to the SLP authentication block [RFC2608]. iSNS unicast messages SHOULD NOT include the authentication block, but rather should rely upon IPSec security mechanisms.
iSNSマルチキャストと同報メッセージ(セクション2.9.3を見る)のために、iSNSPは認証能力を提供します。 以下のセクションがiSNS Authentication Blockについて詳述して、どれは形式がSLP認証ブロック[RFC2608]iSNSユニキャストメッセージSHOULD NOTと同じであるかが、認証ブロックを含んでいますが、むしろIPSecセキュリティー対策を当てにされるべきです。
Tseng, et al. Standards Track [Page 39] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[39ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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分野SHALLで噛み付きました。可能にされます。
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]証明書Authority(カリフォルニア)と共に利用可能であるなら、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:
認証ブロックはマルチキャストメッセージのためのデジタル署名を含んでいます。 デジタル署名は1PDUあたり1個のベースで計算されます。 認証ブロックは以下の情報を含んでいます:
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
バイトMSb LSbオフセット0 31+----------------------------------+ 0 | ブロック構造記述子| 4バイト+----------------------------------+ 4 | 認証ブロック長| 4バイト+----------------------------------+ 8 | タイムスタンプ| 8バイト+----------------------------------+ 16 | SPIストリング長| 4バイト+----------------------------------+ 20 | SPIストリング| Nバイト+----------------------------------+ 20+N| 構造化された固有識別文字| Mバイト+----------------------------------+ 全長=20+N+M
BLOCK STRUCTURE DESCRIPTOR (BSD): Defines the structure and algorithm
to use for the STRUCTURED AUTHENTICATOR. BSD values from
0x00000000 to 0x00007FFF are assigned by IANA, while
values 0x00008000 to 0x00008FFF are for private use.
ブロック構造記述子(BSD): STRUCTURED AUTHENTICATORに使用する構造とアルゴリズムを定義します。 0×00000000から0x00007FFFまでのBSD値はIANAによって割り当てられますが、0x00008FFFへの値0x00008000は私用のためのものです。
Tseng, et al. Standards Track [Page 40] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[40ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
AUTHENTICATION BLOCK LENGTH: Defines the length of the authentication
block, beginning with the BSD field and running through
the last byte of the STRUCTURED AUTHENTICATOR.
認証ブロック長: BSD分野で始まって、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.
タイムスタンプ: これは1970年1月1日グリニッジ標準時0時0分0秒以来の秒数を与える未署名の8バイトの定点整数です。
SPI STRING LENGTH: The length of the SPI STRING field.
SPIは長さを結びます: 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は(セキュリティパラメタインデックス)を結びます: 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].
固有識別文字を構造化します: デジタル署名を含んでいます。 0×0002のデフォルトBSD価値のために、この分野SHALLは.2セクション2.2[RFC3279]における指定されるとしてのSHA-1署名計算によるDSAからの出力値の2進のASN.1コード化を含んでいます。
5.6. Registration and Query Messages
5.6. 登録と質問メッセージ
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) |
+----------------------------------------+
| . . . |
+----------------------------------------+
+----------------------------------------+ | ソース属性(要求専用)| +----------------------------------------+ | メッセージKey Attribute[1](存在しているなら)| +----------------------------------------+ | メッセージKey Attribute[2](存在しているなら)| +----------------------------------------+ | . . . | +----------------------------------------+ | - デリミタ属性、-| +----------------------------------------+ | 操作Attribute[1](存在しているなら)| +----------------------------------------+ | 操作Attribute[2](存在しているなら)| +----------------------------------------+ | 操作Attribute[3](存在しているなら)| +----------------------------------------+ | . . . | +----------------------------------------+
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
Source、Message Key、Delimiter、およびOperatingが結果と考えるそれぞれが、PDU有効搭載量でTag長さの価値(TLV)のデータの形式を使用することで指定されます。iSNS RegistrationとQueryメッセージはiSNS Clientsによって送られます。
Tseng, et al. Standards Track [Page 41] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[41ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
to the iSNS server IP Address and well-known TCP/UDP Port. The iSNS Responses will be sent to the iSNS Client IP address and TCP/UDP port number from the original request message.
iSNSサーバのIP Addressとよく知られるTCP/UDP Portに。 iSNS Responsesをオリジナルの要求メッセージからiSNS Client IPアドレスとTCP/UDPポートナンバーに送るでしょう。
5.6.1. Source Attribute
5.6.1. ソース属性
The Source Attribute is used to identify the Storage Node to the iSNS server for queries and other messages that require source identification. The Source Attribute uniquely identifies the source of the message. Valid Source Attribute types are shown below.
Source Attributeは、ソース識別を必要とする質問と他のメッセージのためにiSNSサーバにStorage Nodeを特定するのに使用されます。 Source Attributeは唯一メッセージの源を特定します。 有効なSource Attributeタイプは以下で見せられます。
Valid Source Attributes
-----------------------
iSCSI Name
FC Port Name WWPN
有効なソース属性----------------------- iSCSI名前FCポート名前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.
質問操作において、Source Attributeは、指定された操作の範囲をソースがメンバーであるディスカバリーDomainsに制限するのに使用されます。 Source Attributeによって特定された特別なControl Nodesは、ディスカバリーDomainsにおいて見ないでiSNSデータベースのすべてのオブジェクトに指定された操作を実行するために行政上構成されるかもしれません。
For messages that change the contents of the iSNS database, the iSNS server MUST verify that the Source Attribute identifies either a Control Node or a Storage Node that is a part of the Network Entity containing the added, deleted, or modified objects.
iSNSデータベースのコンテンツを変えるメッセージに関しては、iSNSサーバは、Source Attributeが加えられたか、削除されたか、変更されたオブジェクトを含むNetwork Entityの一部であるControl NodeかStorage Nodeのどちらかを特定することを確かめなければなりません。
5.6.2. Message Key Attributes
5.6.2. メッセージの主要な属性
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.
メッセージKey属性は、iSNSのためのiSNSデータベースのオブジェクトが質問するマッチングと登録メッセージを特定するのに使用されます。 存在しているなら、Message Keyはセクション5.6.5と6.1で説明されるようにオブジェクトのためのRegistrationかQuery Keyでなければなりません。 質問がSourceに利用可能なオブジェクトの全体のセットにかかっているか、登録が新しいEntityのためのものであるときに、Message Keyは必要ではありません。
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].
stringprepテンプレート[STRINGPREP]に従って、Message Keyで使用されるiSCSI Namesを正常にしなければなりません。 nameprepテンプレート[NAMEPREP]に従って、Message Keyで使用される実体Identifiers(EIDs)を正常にしなければなりません。
5.6.3. Delimiter Attribute
5.6.3. デリミタ属性
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,
Delimiter AttributeはOperating AttributesとPDU有効搭載量でMessage Key属性を切り離します。 Delimiter Attributeには、0のタグ値と0の長さの値があります。 いつもDelimiter Attributeは8バイト長です。(4バイトは分野と4バイトの長さの分野にタグ付けをします。
Tseng, et al. Standards Track [Page 42] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[42ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
all containing zeros). If a Message Key is not required for a message, then the Delimiter Attribute immediately follows the Source Attribute.
ゼロをすべて含みます) Message Keyはメッセージに必要でないなら、Delimiter Attributeがすぐに、Source Attributeに続きます。
5.6.4. Operating Attributes
5.6.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.
Operating Attributesは実際の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].
操作Attributesはオブジェクトキー属性と非主要な属性を含んでいます。 オブジェクトキー属性は唯一iSNSオブジェクトを特定します。 主要な属性はOperating Attributesのそれぞれのオブジェクトの非主要な属性に先行しなければなりません。 タグ値はオブジェクトキー属性(すなわち、タグ=1、16、17、32、64、および96)か非主要な属性として属性を区別します。stringprepテンプレート[STRINGPREP]に従って、Operating Attributesで使用されるiSCSI Namesを正常にしなければなりません。 nameprepテンプレート[NAMEPREP]に従って、Operating Attributesで使用される実体Identifiers(EIDs)を正常にしなければなりません。
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.
オブジェクトの中で関係を決定するのに、メッセージにおける、Operating Attributesの注文は重要です、そして、それらの非主要な属性注文しながらこれらに違反するiSNSプロトコルメッセージの所有権はSHALLが2(メッセージFormat Error)のStatus Codeと共に拒絶されると裁決します。 適切な作動のための記述が結果と考えるメッセージが要件を命令しているのを見てください。
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.
いくつかのオブジェクトが1つ以上のオブジェクトキー属性値によって合わせられます。 例えば、Portalオブジェクトは属性タグ16と17によって合わせられます。 1つ以上の主要な属性によって合わせられたオブジェクトについて説明するとき、そのオブジェクトの非主要な属性と次のオブジェクトの主要な属性の前にメッセージのタグ値でそのオブジェクトのあらゆるオブジェクトキー属性を連続して記載しなければなりません。 オブジェクトを特定するとき、この種類の主要な属性のグループはただ一つの論理的な主要な属性として扱われます。
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.
彼らの封じ込め注文に従って、継承オーダーにオブジェクトを記載しなければなりません。 ストレージNode、Portalオブジェクト、およびそれらのそれぞれの属性はそれらが関係を持っているNetwork Entityオブジェクトに続かなければなりません。 同様に、FC Deviceオブジェクトはそれらが関係を持っているStorage Nodeオブジェクトに続かなければなりません。
Tseng, et al. Standards Track [Page 43] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[43ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
Vendor-specific objects defined by tag values in the range 1537-2048 have the same requirements described above.
範囲1537-2048でタグ値によって定義されたベンダー特有のオブジェクトは上で説明された同じ要件を持っています。
5.6.4.1. Operating Attributes for Query and Get Next Requests
5.6.4.1. 作動して、次の要求を質問のために結果と考えて、得てください。
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属性は、対応する応答で返すためにOperating Attributesがどれであるかを示すのに使用されます。 応答メッセージでオリジナルのメッセージのTLV属性に合っている操作Attribute値を返します。
5.6.5. Registration and Query Request Message Types
5.6.5. 登録と質問要求メッセージタイプ
The following describes each query and message type.
以下は各質問とメッセージタイプについて説明します。
5.6.5.1. Device Attribute Registration Request (DevAttrReg)
5.6.5.1. デバイス属性登録要求(DevAttrReg)
The DevAttrReg message type is 0x0001. The DevAttrReg message provides the means for iSNS clients to update existing objects or register new objects. The value of the replace bit in the FLAGs field determines whether the DevAttrReg message updates or replaces an existing registration.
DevAttrRegメッセージタイプは0×0001です。 DevAttrRegメッセージはiSNSクライアントが既存のオブジェクトをアップデートするか、または新しいオブジェクトを登録する手段を提供します。 値、DevAttrRegメッセージが既存の登録をアップデートするか、または取り替えることにかかわらず分野が決定するFLAGsでビットを取り替えてください。
The Source Attribute identifies the Node initiating the registration request.
Source Attributeは登録要求を開始するNodeを特定します。
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.
Message KeyはDevAttrRegメッセージが作用するオブジェクトを特定します。 オブジェクトを特定して、それは主要な属性を含まなければなりません。 このオブジェクトは、すべての属性を含まなければならなくて、DevAttrReg PDU有効搭載量のOperating Attributesに含まれている下位オブジェクト属性を関係づけました。 また、Operating Attributesの中にこのオブジェクトを特定する主要な属性を含まなければなりません。
If the Message Key contains an EID and no pre-existing objects match the Message Key, then the DevAttrReg message SHALL create a new Entity with the specified EID and any new object(s) specified by the Operating Attributes. The replace bit SHALL be ignored.
Message KeyがEIDを含んでいて、先在しないオブジェクトがMessage Keyに合っているなら、指定されたEIDとどんな新しいオブジェクトもOperating Attributesによって指定されている状態で、DevAttrRegメッセージSHALLは新しいEntityを作成します。 ビット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).
Message KeyがEIDにもかかわらず、先在でないのを含んでいないなら、オブジェクトはMessage Keyに合って、次に、DevAttrRegメッセージはSHALLです。3(無効のRegistration)のステータスコードで、拒絶されてください。
If the Message Key is not present, then the DevAttrReg message implicitly registers a new Network Entity. In this case, the replace bit SHALL be ignored; a new Network Entity SHALL be created. Existing entities, their objects, and their relationships remain unchanged.
Message Keyが存在していないなら、DevAttrRegメッセージはそれとなく新しいNetwork Entityを登録します。 ビットSHALLを取り替えてください。この場合、無視されてください。 新しいNetwork Entity SHALL、作成されてください。 既存の実体、それらのオブジェクト、およびそれらの関係は変わりがありません。
Tseng, et al. Standards Track [Page 44] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[44ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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 Message Keyで特定されたオブジェクトの上に行われた操作の種類を決定します。 取り替え、ビットは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.
ビットを取り替えてください。セット、その時はオブジェクト、属性です、そして、Operating Attributes SHALLで指定された関係はMessage Keyによって特定されたオブジェクトを取り替えます。 下位オブジェクトSHALLでは、反登録されていて適切SCNs SHALLになってください。オブジェクトとすべて、iSNSサーバで、反登録されたオブジェクトのために送ります。 そして、Operating Attributesに記載されたオブジェクトは、まさしく反登録されたオブジェクトを取り替えるのに使用されます。 追加SCNs SHALLが新たに登録されたオブジェクトのために送って、適切であることに注意してください。 特定されなかったか、またはMessage Keyによって特定されたオブジェクトに下位であることの既存のオブジェクトと関係を、影響を受けてはいけませんし、また変えてはいけません。
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.
取り替え、ビットは設定されないで、次に、メッセージはMessage Keyによって特定されたオブジェクトとその下位オブジェクトの属性をアップデートします。 既存のオブジェクト封じ込め関係を変えてはいけません。 既存のオブジェクトに関しては、主要な属性を変更してはいけませんが、新しい下位オブジェクトは加えられるかもしれません。
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.
Operating Attributesは示されることになっているオブジェクト、属性、および関係を表します。 複数の関連するオブジェクトと属性はただ一つのDevAttrRegメッセージに示されるかもしれません。 このメッセージにおける、オブジェクトの注文が構造を示す、協会、登録されるべきオブジェクト。 Operating Attributesに少なくとも1個のオブジェクトを記載しなければなりません。 追加オブジェクト(もしあれば)は記載された最初のオブジェクトに下位であるに違いありません。 主要な属性はそれぞれのオブジェクトの非主要な属性に先行しなければなりません。 与えられたオブジェクトはメッセージのOperating Attributesに最大一度現れるだけであるかもしれません。 Source Attributeによって特定されたNodeがControl Nodeでないなら、操作属性におけるオブジェクトはSource Nodeと同じNetwork Entityのメンバーであるに違いありません。
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.
例えば、そのNetwork Entityオブジェクトと、PortalとStorage Nodeオブジェクトとの関係を証明するために、Operating AttributesはそれぞれのPortalとStorage Nodeオブジェクトの主要で非主要な属性があとに続いた、そのNetwork EntityにリンクされたNetwork Entityオブジェクトの主要で非主要な属性を記載します。 同様に、Storage Nodeオブジェクトに続くFC DeviceオブジェクトはそのStorage Nodeに下位であると考えられます。
New PG objects are registered when an associated Portal or iSCSI Node object is registered. An explicit PG object registration MAY follow a Portal or iSCSI Node object registration in a DevAttrReg message.
関連PortalかiSCSI Nodeオブジェクトが登録されているとき、新しい未成年者不適当映画オブジェクトは登録されています。 明白な未成年者不適当映画オブジェクト登録はDevAttrRegメッセージにおけるPortalかiSCSI Nodeオブジェクト登録に続くかもしれません。
Tseng, et al. Standards Track [Page 45] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[45ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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.
Portalがすぐに登録されているとき、PGT属性はPortal属性のあとに続くかもしれません。 PGTはSHALLを結果と考えます。示されたPGT値を使用することでPortalに関連しているノードを表す未成年者不適当映画iSCSI Namesのセットによって続かれてください。 登録されたPortalに関連づけられるべきPGTsと未成年者不適当映画iSCSI Namesの追加セットは続くかもしれません。 操作属性におけるPGT属性に続いて、示されたPGT値は新たに登録されたPortalに関連している未成年者不適当映画オブジェクトと、そして、すぐに参照をつけられたiSCSI Storage Node(s)に割り当てられます。
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 Storage Nodeがすぐに登録されているとき、PGT属性はStorage Node属性のあとに続くかもしれません。 PGT属性SHALLが未成年者不適当映画Portal IP-アドレスのセットによって続かれて、未成年者不適当映画TCP/UDP Portは、示されたPGT値を使用するStorage Nodeに関連しているPortalオブジェクトを表しながら、対にします。 登録されたStorage Nodeに関連している追加セットのPGTsと未成年者不適当映画Portal IP-アドレス未成年者不適当映画TCP/UDP Port組は続くかもしれません。 操作属性におけるPGT属性に続いて、示されたPGT値はすぐに参照をつけられる新たに登録されたiSCSI Storage NodeとPortalオブジェクトに関連している未成年者不適当映画オブジェクトに割り当てられます。
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値がStorage NodeかPortalオブジェクト登録に含まれていなくて、また次に、関係、対応する未成年者不適当映画オブジェクトSHALLのためのPGTのために登録されて、登録されていて、以前にPGT値が0×00000001の値があるそうでなかったなら。 PGT属性が0長さのTLVとして登録メッセージに含まれているなら、登録されていて、PGTは対応する未成年者不適当映画オブジェクトのためにNULLとしてSHALLを評価します。 アップデート登録メッセージのPGTのための0長さのTLVはNULLと共に前のPGT値を上書きします、Storage NodeとPortalとの関係が全くないのを示して。
A maximum of one Network Entity object can be created or updated with a single DevAttrReg message. Consequently, the Operating Attributes MUST NOT contain more than one Network Entity object. There is no limit to the number of Portal, Storage Node, and FC Device objects that can listed in the Operating Attributes, provided they are all subordinate to the listed Network Entity object.
ただ一つのDevAttrRegメッセージで最大1個のNetwork Entityオブジェクトを作成するか、またはアップデートできます。 その結果、Operating Attributesは1個以上のNetwork Entityオブジェクトを含んではいけません。 Portalの数への限界が全くありません、Storage Node、そして、そうすることができるFC DeviceオブジェクトはOperating Attributesに記載しました、彼らが皆、記載されたNetwork Entityオブジェクトに下位であるなら。
If the Message Key and Operating Attributes do not contain an EID attribute, or if the EID attribute has a length of 0, then a new Network Entity object SHALL be created and the iSNS server SHALL supply a unique EID value for it. The assigned EID value SHALL be included in the DevAttrReg Response message. If the Message Key and Operating Attributes contain an EID that does not match the EID of an existing Network Entity in the iSNS database, then a new Network Entity SHALL be created and assigned the value contained in that EID attribute. Finally, if the Message Key and Operating Attributes contain an EID that matches the EID of an existing object in the iSNS
EID属性に新しいNetwork EntityオブジェクトSHALLが0の長さ、その時あるなら、Message KeyとOperating Attributesであるなら、EID属性を含まないでください、作成されていてSHALLがそれのためのユニークなEID値を供給するiSNSサーバいるのでないでください。 含まれていて、割り当てられたEIDはDevAttrReg ResponseメッセージでSHALLを評価します。 Message KeyとOperating AttributesがiSNSデータベースで既存のNetwork EntityのEIDに合っていないEIDを含んでいるなら、新しいNetwork Entity SHALLは作成されて、そのEID属性に含まれた値を割り当てました。 最終的に、Message KeyとOperating AttributesがEIDを含んでいるなら、それはiSNSで既存のオブジェクトのEIDに合っています。
Tseng, et al. Standards Track [Page 46] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[46ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
database, then the objects, attributes, and relationships specified in the Operating Attributes SHALL be appended to the existing Network Entity identified by the EID.
次にデータベース、オブジェクト、属性、および関係はOperating Attributes SHALLで指定しました。Network EntityがEIDで特定した存在に追加します。
A registration message that creates a new Network Entity object MUST contain at least one Portal or one Storage Node. If the message does not, then it SHALL be considered invalid and result in a response with Status Code of 3 (Invalid Registration).
新しいNetwork Entityオブジェクトを作成する登録メッセージは少なくとも1Portalか1Storage Nodeを含まなければなりません。 メッセージはそうしないで、次に、それはSHALLです。無効であると考えられてください、そして、3(無効のRegistration)のStatus Codeとの応答をもたらしてください。
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 Serverが明白な未成年者不適当映画オブジェクト登録などの登録機能をサポートしないなら、サーバSHALLは23(登録Feature Not Supported)のStatus Codeを返します。
Note that the iSNS server may modify or reject the registration of certain attributes, such as ESI Interval. In addition, the iSNS server may assign values for additional Operating Attributes that are not explicitly registered in the original DevAttrReg message, such as the EID and WWNN Token.
iSNSサーバがESI Intervalなどのある属性の登録を変更するか、または拒絶するかもしれないことに注意してください。 さらに、iSNSサーバはオリジナルのDevAttrRegメッセージに明らかに登録されない追加Operating Attributesのために値を割り当てるかもしれません、EIDやWWNN Tokenのように。
5.6.5.2. Device Attribute Query Request (DevAttrQry)
5.6.5.2. デバイス属性質問要求(DevAttrQry)
The DevAttrQry message type is 0x0002. The DevAttrQry message provides an iSNS client with the means to query the iSNS server for object attributes.
DevAttrQryメッセージタイプは0×0002です。 DevAttrQryメッセージはオブジェクト属性のためにiSNSサーバについて質問する手段をiSNSクライアントに提供します。
The Source Attribute identifies the Node initiating the request. For non-Control Nodes initiating the DevAttrQry message, the query is scoped to the Discovery Domains of which the initiating Node is a member. The DevAttrQry message SHALL only return information on Storage Nodes and their related parent and subordinate objects, where the Storage Node has a common Discovery Domain with the Node identified in the Source Attribute.
Source Attributeは要求を開始するNodeを特定します。 DevAttrQryメッセージを開始する非コントロールNodesに関しては、質問は開始しているNodeがメンバーであるディスカバリーDomainsにおいて見られます。 DevAttrQryメッセージSHALLは彼らのStorage Nodes、関連する親、および下位オブジェクトの上の情報を返すだけです。そこでは、Storage NodeがNodeがSource Attributeで特定されている一般的なディスカバリーDomainを持っています。
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.
主要であるか非主要な属性を含んでいますが、Message Keyはどんな属性も全く含まないかもしれません。 複数の属性がMessage Keyとして使用されるなら、それらは同じオブジェクト・タイプからすべて来ているに違いありません(例えば、IPアドレスとTCP/UDP PortはPortalオブジェクト・タイプの属性です)。 非主要な属性があるMessage Keyは特定のオブジェクト・タイプの複数のインスタンスに合うかもしれません。 ゼロ・レングスTLV(s)とMessage Keyはゼロ・レングスTLV(s)によって示されたタイプのあらゆるオブジェクトに見られます。 人影のないMessage Key分野は、質問がソースNodeがアクセス可能な全体のデータベースに見られるのを示します。
The DevAttrQry response message returns attributes of objects listed in the Operating Attributes that are related to the Message Key of the original DevAttrQry message. The Operating Attributes of the DevAttrQry message contain zero-length TLVs that specify the attributes that are to be returned in the DevAttrQryRsp message. A
DevAttrQry応答メッセージはオリジナルのDevAttrQryメッセージのMessage Keyに関連するOperating Attributesに記載されたオブジェクトの属性を返します。 DevAttrQryメッセージのOperating AttributesはDevAttrQryRspメッセージで返されることになっている属性を指定するゼロ・レングスTLVsを含んでいます。 A
Tseng, et al. Standards Track [Page 47] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[47ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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.
ゼロ・レングスTLVsを含むのが、属性のセットがOperating Attributesで指定したのを示すというメッセージKeyはMessage Keyによって示されたタイプに合っている各オブジェクトのために返されることになっています。
If the Message Key contains non-zero length TLVs, then Operating Attributes for the object matching the Message Key SHALL be returned in the DevAttrQryRsp message. Each attribute type (i.e., zero-length TLV) in the Operating Attributes indicates an attribute from the object matching the Message Key, or from other objects in the same Entity having a relationship to the object matching the Message Key, is to be returned in the response. The ordering of the object keys and associated attributes returned in the DevAttrQry response message SHALL be the same as in the original query message. If no objects match the Message Key, then the DevAttrQryRsp message SHALL NOT return any operating attributes. Such a message and its corresponding response SHALL NOT be considered an error.
Message Keyが非ゼロ・レングスTLVsを含んでいるなら、そして、返されたコネがDevAttrQryRspメッセージであったならMessage Key SHALLに合っているオブジェクトのためにOperating Attributesです。 Operating Attributesの各属性タイプ(すなわち、ゼロ・レングスTLV)は応答で返されるMessage Key、または他のオブジェクトからのMessage Keyに合っているオブジェクトとの同じEntity有における関係がことであるオブジェクトマッチングから属性を示します。 オブジェクトキーと関連属性の注文はコネと同じくらいがオリジナルの質問メッセージであったならDevAttrQry応答メッセージSHALLで戻りました。 どんなオブジェクトもMessage Keyに合っていないなら、DevAttrQryRspメッセージSHALL NOTはどんな操作属性も返します。 そのようなメッセージと対応する応答SHALL NOT、誤りであると考えられてください。
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.
Portal Group目的は、関係が与えられたStorage NodeとPortalオブジェクトの間に存在するかどうか決定します。 Portal GroupのPGTがNULLでないなら、関係は示されたStorage NodeとPortalの間に存在しています。 PGTがNULLであるなら、関係は全く存在していません。 したがって、それぞれのPortal GroupオブジェクトのPGT属性の値(NULLではなく、NULL)はStorage NodesとPortalsのために質問への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データベースは2Portalsと2Nodesを持っているNetwork Entityを含んでいます。 各Storage Nodeには、2Portal Groups、1が1PortalのためのNULL PGT値ともう片方のPortalのための非NULL PGT値がある別のものと共にあります。 DevAttrQryメッセージは、最初に、Node属性、Portalを記載する無の長さのTLVs属性にNodes、およびOperating Attributesの1つを合わせるMessage Keyエントリーを含んでいて、次に、未成年者不適当映画属性を含んでいます。 したがって、応答メッセージSHALLは最初に、合っているNodeオブジェクト、次に、Storage Node(PGTによって示されるように)にアクセスするのに使用できる1個のPortalオブジェクトの要求された属性、および最終的にそのStorage Nodeにアクセスするのに使用される未成年者不適当映画オブジェクトの要求された属性を返します。 各オブジェクトの属性が記載されているオーダーはオリジナルの要求メッセージのOperating Attributesでのオブジェクトの属性の注文と同じです。
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
Message Key Attributeがゼロ・レングスTLV(s)を含んでいるなら、質問リターンはMessage Keyタイプに合っているすべてのオブジェクトのために属性を要求しました(DD制限SHALLは非コントロールNodesに申し込みます)。 複数のオブジェクトがMessage Keyタイプに合っているなら、次の合っているオブジェクトのための属性が質問で記載されている前にMessage Keyに合っている各オブジェクトのための属性を記載しなければなりません。
Tseng, et al. Standards Track [Page 48] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[48ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
response. In other words, the process described above must be iterated in the message response for each object that matches the Message Key type specified by the zero-length TLV(s).
応答。 言い換えれば、ゼロ・レングスTLV(s)によって指定されたMessage Keyタイプに合っている各オブジェクトのためのメッセージ応答で上で説明されたプロセスを繰り返さなければなりません。
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データベースは2Portalsと3Nodesを持っている1Network Entityだけを含んでいます。 Entityのすべての未成年者不適当映画オブジェクトには、0×00000001のPGT値があります。 DevAttrQryメッセージでは、Message KeyはNodeタイプを指定する無の長さのTLV、および最初に、Node属性を記載して、次にPortal属性を記載するOperating Attributesを含んでいます。 応答メッセージは、次に、1日に以下のオーダーで属性を返して、Nodeオブジェクトを持続するでしょう、とそれぞれが両方のPortalsのために属性で続きました。 その同じDevAttrQryメッセージが代わりにNetwork Entityタイプを指定する無の長さのTLVを含んだなら、応答メッセージは属性が2Portalsのためにあとに続いたすべての3個のNodeオブジェクトのために属性を返したでしょうに。
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.
Message Key Attributeが全くなければ、質問はiSNSデータベースのすべての属性を返します(もう一度、DD制限SHALLは非コントロールNodesに申し込みます)。 各ゼロ・レングスに従って、タイプに合っているすべての属性がOperating Attributes SHALLでTLVを指定しました。記載されています。 それぞれのすべての属性がSHALLをタイプします。次のゼロ・レングスTLVに合っている属性が記載されている前に記載されてください。
For example, an iSNS database contains two Entities, each having two Nodes and two Portals. The DevAttrQry message contains no Message Key attribute, and Operating Attributes list first the Portal attributes, and then the Node attributes. The Operating Attributes of the response message will return attributes from each of the four Portals, followed by attributes from each of the four nodes.
例えば、それぞれ2Nodesと2Portalsを持っていて、iSNSデータベースは2Entitiesを含んでいます。 Operating AttributesはDevAttrQryメッセージがMessage Key属性を全く含んでいなくて、最初に、Portal属性を記載して、次に、Node属性を記載します。 応答メッセージのOperating Attributesは属性がそれぞれの4つのノードからあとに続いたそれぞれの4Portalsから属性を返すでしょう。
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サーバには値が全くない属性を要求するなら、サーバSHALL NOTは質問応答における要求された属性を返します。 そのような質問と応答メッセージSHALL NOT、誤りであると考えられてください。
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.
登録と質問はフォーマットされた使用がSource AttributeとMessage Keyが結果と考える両方のための質問(すなわち、iSCSI NameかFC Port Name WWPN)を溯源するStorage Nodeの特定の主要な属性であったならiSNSのサーバ特有の属性(すなわち、中では、132〜384に範囲にタグ付けをする)SHALLのために通信します。 操作Attributes SHALLは要求されているサーバ特有の属性の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,
そして、DevAttrQryメッセージを通してDDメンバーが結果と考えるどちらかを含んでいることによってDD会員資格を発見できる、(すなわち、DDメンバーiSCSI Index、DDメンバーiSCSI Node、DDメンバーiFCP Node、DDメンバーPortal IP AddrのDDメンバーPortal Index、DDメンバーPortal TCP/UDP)、Storage NodeかPortalのオブジェクトキー、(すなわち、iSCSI Name、iSCSI Index
Tseng, et al. Standards Track [Page 49] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[49ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
Portal IP Addr, Portal TCP/UDP Port, and Portal Index) in the Operating Attributes. Using DD member attributes SHALL return both registered and unregistered member Storage Nodes and/or Portals of a DD. DevAttrQry messages using the Storage Node and/or Portal object key SHALL return only member Storage Nodes or Portals that are currently registered in the iSNS database.
入り口のIP Addr、入り口のTCP/UDP港、および入り口のインデックス) 操作属性で。 DDを使用して、メンバー属性SHALLはDDの登録されたものと同様に登録されていないメンバーのStorage Nodes、そして/または、Portalsを返します。 Storage Node、そして/または、Portalオブジェクトの主要なSHALLを使用するDevAttrQryメッセージが現在iSNSデータベースに登録されるメンバーStorage NodesかPortalsだけを返します。
The DevAttrQry message SHALL support the following minimum set of Message Key Attributes:
DevAttrQryメッセージSHALLはMessage Key Attributesの以下の最小のセットを支えます:
Valid Message Key Attributes for Queries
----------------------------------------
Entity Identifier
Entity Protocol
Portal IP-Address & Portal TCP/UDP Port
Portal Index
iSCSI Node Type
iSCSI Name
iSCSI Index
PG Index
FC Port Name WWPN
FC Port Type
FC-4 Type
Discovery Domain ID
Discovery Domain Set ID
Source Attribute (for server-specific attributes)
Switch Name (FC Device WWNN--for Virtual_Fabric_ID queries)
質問のための有効なメッセージ主要な属性---------------------------------------- 実体Identifier EntityプロトコルPortal IP-アドレスとPortal TCP/UDP Port Portal Index iSCSI Node Type iSCSI Name iSCSI Index未成年者不適当映画Index FC Port Name WWPN FC Port Type FC-4 TypeディスカバリーDomain IDディスカバリーDomain Set ID Source Attribute(サーバ特有の属性のための)スイッチName(Virtual_Fabric_ID質問のためのFC Device WWNN)
5.6.5.3. Device Get Next Request (DevGetNext)
5.6.5.3. デバイスは次の要求を得ます。(DevGetNext)
The DevGetNext message type is 0x0003. This message provides the iSNS client with the means to retrieve each and every instance of an object type exactly once.
DevGetNextメッセージタイプは0×0003です。 このメッセージはまさに一度オブジェクト・タイプのありとあらゆるインスタンスを検索する手段をiSNSクライアントに提供します。
The Source Attribute identifies the Node initiating the DevGetNext request, and is used to scope the retrieval process to the Discovery Domains of which the initiating Node is a member.
Source AttributeはDevGetNext要求を開始するNodeを特定して、検索が開始しているNodeがメンバーであるディスカバリーDomainsに処理する範囲に使用されます。
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.
Message Key AttributeはPortal IPのEntity Identifier(EID)かiSCSI NameかiSCSI IndexかAddressとTCP/UDP Portか、Portal Indexか、未成年者不適当映画Indexか、FC Node Name WWNNか、FC Port Name WWPNであるかもしれません。 Message Key Attribute(s)のTLVの長さがゼロであるなら、そして、返されたコネが対応するDevGetNextRspメッセージのMessage KeyであったならMessage KeyタイプSHALLに合っているiSNSデータベースで最初のオブジェクトエントリーです。 非ゼロ・レングスTLV属性がMessage Keyに含まれているなら、DevGetNext応答メッセージSHALLはオリジナルのDevGetNext要求メッセージのMessage Keyによって特定されたオブジェクトの後に保存された次のオブジェクトを返します。
Tseng, et al. Standards Track [Page 50] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[50ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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.
Message Keyが次に、iSNSデータベース、9(Such Entryがない)SHALLのStatus Codeにおける最後のオブジェクトインスタンスをマッチに供給したなら、応答では、返してください。
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応答メッセージで返されることである次のオブジェクトの属性を指定するのにOperating Attributesを使用できます。 すべてのOperating AttributesがMessage Keyによって特定されたオブジェクト・タイプの属性であるに違いありません。 例えば、Message KeyがEntity_ID属性であるなら、Operating AttributesはPortalsの属性を含んではいけません。
Non-zero-length TLV attributes in the Operating Attributes are used to scope the DevGetNext message. Only the next object with attribute values that match the non-zero-length TLV attributes SHALL be returned in the DevGetNext response message.
Operating Attributesの非ゼロ・レングスTLV属性は、DevGetNextメッセージを見るのに使用されます。 属性がある次のオブジェクトだけが、マッチTLVが結果と考える非ゼロ・レングスSHALLが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.
DevGetNext要求メッセージのOperating Attributesに次々とゼロ・レングスTLV非ゼロ・レングス属性を記載しなければなりません。 ゼロ・レングスTLV属性はDevGetNext応答メッセージで返されることである次のオブジェクトの属性を指定します。
Note that there are no specific requirements concerning the order in which object entries are retrieved from the iSNS database; the retrieval order of object entries using the DevGetNext message is implementation specific.
オブジェクトエントリーがiSNSデータベースから検索されるオーダーに関して決められた一定の要求が全くないことに注意してください。 DevGetNextメッセージを使用するオブジェクトエントリーの検索命令は実装特有です。
The iSNS client is responsible for ensuring that information acquired through use of the DevGetNext message is accurate and up-to-date. There is no assurance that the iSNS database will not change between successive DevGetNext request messages. If the Message Key provided does not match an existing database entry, then attributes for the next object key following the provided Message Key SHALL be returned. For example, an object entry may have been deleted between successive DevGetNext messages. This may result in a DevGetNext request in which the Message Key does not match an existing object entry. In this case, attributes for the next object stored in the iSNS database are returned.
iSNSクライアントはDevGetNextメッセージの使用で取得された情報が確実に正確で最新になるようにするのに責任があります。 iSNSデータベースが連続したDevGetNext要求メッセージの間で変化しないという保証が全くありません。 提供されたMessage Keyが既存のデータベースエントリー、当時の属性をどんなマッチにもしないなら、提供されたMessage Key SHALLに続く次のオブジェクトキーに関して返してください。 例えば、オブジェクトエントリーは連続したDevGetNextメッセージの間で削除されたかもしれません。 これはMessage Keyが既存のオブジェクトエントリーに合っていないDevGetNext要求をもたらすかもしれません。 この場合、iSNSデータベースに保存された次のオブジェクトのための属性は返されます。
5.6.5.4. Device Deregister Request (DevDereg)
5.6.5.4. デバイスDeregister要求(DevDereg)
The DevDereg message type is 0x0004. This message is used to remove object entries from the iSNS database. One or more objects may be removed through a single DevDereg message. Note that deregistered Storage Node objects will retain membership in their Discovery Domain(s) until explicit deregistration of the membership(s) or Discovery Domain(s).
DevDeregメッセージタイプは0×0004です。 このメッセージは、iSNSデータベースからオブジェクトエントリーを取り除くのに使用されます。 ただ一つのDevDeregメッセージを通してあるオブジェクトを取り除くかもしれません。 deregistered Storage Nodeオブジェクトが会員資格の明白な反登録までのそれらのディスカバリーDomain(s)かディスカバリーDomain(s)で会員資格を保有することに注意してください。
Tseng, et al. Standards Track [Page 51] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[51ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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サーバはOperating Attribute(s)によって特定されたすべてのオブジェクトを取り除きます、そして、唯一それらに依存するすべての下位オブジェクトがオブジェクトを特定しました。 例えば、また、Network Entityの解任はそのNetwork Entityに関連しているすべての関連Portal、Portal Group、Storage Node、およびFC Deviceオブジェクトの取り外しをもたらします。 FC DeviceオブジェクトSHALL、彼らに関連しているすべてのStorage Nodesが反登録されるというわけではなかったなら、この様に反登録されません。
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有効搭載量がSource AttributeとOperating Attribute(s)を含むよう要求します。 Message Key Attributesが全くありません。 Source Attributeによって特定されたNodeがControl Nodeでないなら、それは取り外しのためにOperating Attribute(s)によって特定されたオブジェクトと同じNetwork Entityから来ているに違いありません。 有効なOperating Attributesは以下で見せられます:
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
DevDeregに、有効な操作属性--------------------------------------- エンティティ識別名入り口のIP-アドレスと入り口のTCP/UDPポート入り口のインデックスiSCSI名iSCSIインデックスFCポート名前WWPN FCノード名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.
試みられた反登録、非既存のエントリーSHALLでは、誤りであることは考えられないでください。
If all Nodes and Portals associated with a Network Entity are deregistered, then the Network Entity SHALL also be removed.
Network EntityはすべてのNodesとPortalsであるなら交際する状態で反登録されて、その時はNetwork Entity SHALLです。また、取り除きます。
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.
PortalとiSCSI Storage NodeオブジェクトのPortal Groupオブジェクトに関連している両方を取り除くなら、また、Portal GroupオブジェクトSHALLが取り外されるその時です。 Portal GroupオブジェクトSHALLはその関連PortalかiSCSI Storage Nodeに、オブジェクトが登録されたままで残っている限り、登録されたままで残っています。 削除されたStorage NodeかPortalオブジェクトが、次に、再登録されたオブジェクトと既存のPortalかStorage Nodeオブジェクト登録との関係が次に再登録されたということであり、未成年者不適当映画オブジェクト、SHALLで回復するように示したなら。
Tseng, et al. Standards Track [Page 52] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[52ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
5.6.5.5. SCN Register Request (SCNReg)
5.6.5.5. SCNレジスタ要求(SCNReg)
The SCNReg message type is 0x0005. The State Change Notification Registration Request (SCNReg) message allows an iSNS client to register a Storage Node to receive State Change Notification (SCN) messages.
SCNRegメッセージタイプは0×0005です。 州Change Notification Registration Request(SCNReg)メッセージで、iSNSクライアントは、州Change Notification(SCN)メッセージを受け取るためにStorage Nodeを登録できます。
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以内のどんなStorage Nodesへの変化についてもStorage Nodeに通知します。 Storage NodeはControl Nodeであり、それはSHALLです。全体のネットワークで変化のためのSCN通知を受け取ってください。 SCNRegはSCN Bitmap分野(UDPかTCP PortがSCNメッセージを受け取るのに各Portalで使用したDevAttrRegメッセージレジスタ)を設定しますが、それに注意してください。 Storage NodeのどんなPortalsのどんなSCN Port分野も登録されていないなら、SCNメッセージ、次に、SCNRegメッセージSHALLを受け取るには、Status Code17(SCN Registration Rejected)と共に拒絶されてください。
The SCNReg request PDU Payload contains a Source Attribute, a Message Key Attribute, and an Operating Attribute. Valid Message Key Attributes for a SCNReg are shown below:
SCNRegは、PDU有効搭載量がSource Attribute、Message Key Attribute、およびOperating Attributeを含むよう要求します。 SCNRegのための有効なMessage Key Attributesは以下で見せられます:
Valid Message Key Attributes for SCNReg
---------------------------------------
iSCSI Name
FC Port Name WWPN
有効なメッセージSCNRegに、主要な属性--------------------------------------- iSCSI名前FCポート名前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メッセージでMessage Keyに合っているiSCSI NameかFC Port Name WWPN属性があるノードは、指定されたSCNビットマップを使用することでSCNsを受け取るために登録されます。 最大1Node SHALL、それぞれのSCNRegメッセージには、登録されてください。
The SCN Bitmap is the only operating attribute of this message, and it always overwrites the previous contents of this field in the iSNS database. The bitmap indicates the SCN event types for which the Node is registering.
SCN Bitmapはこのメッセージの唯一の操作属性です、そして、それはいつもiSNSデータベースのこの分野の前のコンテンツを上書きします。 ビットマップはNodeが登録している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登録が通常のSCNsか管理SCNsのためのものであるかを決定することに注意してください。 コントロールNodesは管理SCNsのために登録証明書を行うかもしれません。 Control NodesをサポートしていないiSNSクライアントは管理SCNsのために登録証明書を行ってはいけません。 管理SCNsに登録するコントロールNodesがiSNSサーバによって生成されたあらゆるSCNメッセージのコピーを受けます。iSNSサーバ資源を節約するのに必要である場合にだけ管理登録証明書が使用されるのは、お勧めです。 さらに、そのような登録証明書を行うControl NodeはSCNメッセージトラフィックの予期された量を受けるように準備されるべきです。
Tseng, et al. Standards Track [Page 53] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[53ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
5.6.5.6. SCN Deregister Request (SCNDereg)
5.6.5.6. SCN Deregister要求(SCNDereg)
The SCNDereg message type is 0x0006. The SCNDereg message allows an iSNS client to stop receiving State Change Notification (SCN) messages.
SCNDeregメッセージタイプは0×0006です。 SCNDeregメッセージで、iSNSクライアントは、州Change Notification(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有効搭載量はSource AttributeとMessage Key Attribute(s)を含んでいます。 SCNDeregのための有効なMessage Key Attributesは以下で見せられます:
Valid Message Key Attributes for SCNDereg
-----------------------------------------
iSCSI Name
FC Port Name WWPN
有効なメッセージSCNDeregに、主要な属性----------------------------------------- iSCSI名前FCポート名前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メッセージでMessage Key Attributesに合っているiSCSI NameかFC Port Name WWPN属性があるノードはSCNsのために反登録されます。 そのようなNodesのSCNビットマップ分野はクリアされます。 最大1Node SHALL、それぞれのSCNDeregメッセージのために、反登録されます。
There are no Operating Attributes in the SCNDereg message.
SCNDeregメッセージにはOperating Attributesが全くありません。
5.6.5.7. SCN Event (SCNEvent)
5.6.5.7. SCNイベント(SCNEvent)
The SCNEvent message type is 0x0007. The SCNEvent is a message sent by an iSNS client to request generation of a State Change Notification (SCN) message by the iSNS server. The SCN, sent by the iSNS server, then notifies iFCP, iSCSI, and Control Nodes within the affected DD of the change indicated in the SCNEvent.
SCNEventメッセージタイプは0×0007です。 SCNEventはiSNSサーバから州Change Notification(SCN)メッセージの世代を要求するためにiSNSクライアントによって送られたメッセージです。次に、iSNSサーバによって送られたSCNは影響を受けるDDの中でSCNEventで示された変化についてiFCP、iSCSI、およびControl Nodesに通知します。
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.
Nodesがディレクトリデータベースから登録されるか、または反登録されるとき、ほとんどのSCNsがiSNSサーバによって自動的に生成されます。 また、ネットワークマネージメントアプリケーションかControl NodeがiSNSサーバのDD会員資格への変更を行うと、SCNsは生成されます。しかしながら、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有効搭載量はSource Attribute、Message Key Attribute、およびOperating Attributeを含んでいます。 SCNEventのための有効なKey Attributesは以下で見せられます:
Valid Message Key Attributes for SCNEvent
-----------------------------------------
iSCSI Name
FC Port Name WWPN
有効なメッセージSCNEventに、主要な属性----------------------------------------- iSCSI名前FCポート名前WWPN
Tseng, et al. Standards Track [Page 54] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[54ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
The Operating Attributes section SHALL contain the SCN Event Bitmap attribute. The bitmap indicates the event that caused the SCNEvent to be generated.
Operating Attributes部のSHALLはSCN Event Bitmap属性を含んでいます。 ビットマップはSCNEventを生成したイベントを示します。
5.6.5.8. State Change Notification (SCN)
5.6.5.8. 州の変更届出書(SCN)
The SCN message type is 0x0008. The SCN is a message generated by the iSNS server, notifying a registered Storage Node of changes. There are two types of SCN registrations: regular registrations and management registrations. Regular SCNs notify iSNS clients of events within the discovery domain. Management SCNs notify Control Nodes that register for management SCNs of events occurring anywhere in the network.
SCNメッセージタイプは0×0008です。 SCNは変化について登録されたStorage Nodeに通知して、iSNSサーバによって生成されたメッセージです。 2つのタイプのSCN登録証明書があります: 定期的な登録証明書と管理登録証明書。 通常のSCNsは発見ドメインの中でイベントについてiSNSクライアントに通知します。 イベントがネットワークでどこでも起こるのについて管理SCNsは管理SCNsに登録するControl Nodesに通知します。
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はSHALLを通信させます。SCN Port分野に登録されたTCPかUDP Port値を持っている登録されたStorage Nodeの1Portalに送ってください。 登録されたSCN Port値、次にSCN SHALLはStorage Nodeの1Portalであり、選択されたPortalがSCNの対象でなければ示されたPortalsのどれかに提供されましたか?
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メッセージに含まれた情報量はStorage Nodeのために登録されたSCN Event Bitmapに信頼されます。 iSCSI Node SCN Bitmapはセクション6.4.4で説明されます。 iFCP SCN Bitmapはセクション6.6.12で説明されます。
Tseng, et al. Standards Track [Page 55] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[55ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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) |
+----------------------------------------+
| . . . |
+----------------------------------------+
+----------------------------------------+ | 目的地属性| +----------------------------------------+ | タイムスタンプ| +----------------------------------------+ | ソースSCNビットマップ1| +----------------------------------------+ | ソース属性[1]| +----------------------------------------+ | ソースAttribute[2](存在しているなら)| +----------------------------------------+ | ソースAttribute[3](存在しているなら)| +----------------------------------------+ | ソースAttribute[n](存在しているなら)| +----------------------------------------+ | ソースSCN Bitmap2(存在しているなら)| +----------------------------------------+ | . . . | +----------------------------------------+
All PDU Payload attributes are in TLV format.
TLV形式にはすべてのPDU有効搭載量属性があります。
The Destination Attribute is the Node identifier that is receiving the SCN. The Destination Attribute can be an iSCSI Name or FC Port Name.
Destination AttributeはSCNを受けているNode識別子です。 Destination AttributeはiSCSI NameかFC Port Nameであるかもしれません。
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.
Source SCN Bitmap分野は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メッセージSHALLはSCNビットマップを記載します、続いて、SCNイベントで影響を受けるStorage Nodeの主要な属性(すなわち、iSCSI NameかFC Port Name)を記載します。 また、SCNがManagement SCNであるなら、SCNメッセージSHALLはそのStorage Nodeのために状態で変化を引き起こしたディスカバリーDomainsと(もしあれば)のディスカバリーDomain SetsのDD_ID、そして/または、DDS_IDを記載します。 これらの追加属性(すなわち、DD_ID、そして/または、DDS_ID)は、次の通知メッセージ(もしあれば)のためにすぐに、iSCSI NameかFC Port Nameに続いて、次のSCNビットマップに先行するものとします。 SCNビットマップは複数の州の変更届出書を提供するSCNメッセージに視線誘導標として使用されます。
Tseng, et al. Standards Track [Page 56] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[56ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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目標に利用可能な新しいPortalについてiSNSクライアントに通知するための通常のSCNはソース属性として対象装置のiSCSI Nameによって続かれたSCNビットマップを含んでいるでしょう。 そして、SCNであるなら、iSCSI Nameは管理がSCNであるなら、目的地Storage Nodeに影響を受けるStorage Nodeに目に見えることを持たせる共有されたディスカバリーDomainsのDD_IDによって続かれているでしょうに。 ディスカバリーDomain Set(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は、ディスカバリーDomainかディスカバリーDomain Setの作成、削除、または変更についてControl Nodeに通知するために生成されます。 この場合、影響を受けるディスカバリーDomain、そして/または、ディスカバリーDomain Setの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.
例えば、ディスカバリーDomain Setの中で新しいDDについてControl Nodeに通知する管理SCNはSource Attributesの中にDD_IDと影響を受けるディスカバリーDomainとディスカバリーDomain SetのDDS_IDの両方を含んでいるでしょう。
See Sections 6.4.4 and 6.6.12 for additional information on the SCN Bitmap.
セクション6.4.4と6.6を見てください。.12 SCN Bitmapに関する追加情報のために。
5.6.5.9. DD Register (DDReg)
5.6.5.9. DDは登録します。(DDReg)
The DDReg message type is 0x0009. This message is used to create a new Discovery Domain (DD), to update an existing DD Symbolic Name and/or DD Features attribute, and to add DD members.
DDRegメッセージタイプは0×0009です。 このメッセージは、新しいディスカバリーDomain(DD)を作成して、既存のDD Symbolic Name、そして/または、DD Features属性をアップデートして、DDメンバーを加えるのに使用されます。
DDs are uniquely defined using DD_IDs. DD registration attributes are described in Section 6.11.
DDsは、DD_IDを使用することで唯一定義されます。 DD登録属性はセクション6.11で説明されます。
The DDReg message PDU Payload contains the Source Attribute and optional Message Key and Operating Attributes.
DDRegメッセージPDU有効搭載量はSource Attribute、任意のMessage Key、およびOperating Attributesを含んでいます。
The Message Key, if used, contains the DD_ID of the Discovery Domain to be registered. If the Message Key contains a DD_ID of an existing DD entry in the iSNS database, then the DDReg message SHALL attempt to update the existing entry. If the DD_ID in the Message Key (if used) does not match an existing DD entry, then the iSNS server SHALL reject the DDReg message with a status code of 3 (Invalid Registration). If the DD_ID is included in both the Message Key and Operating Attributes, then the DD_ID value in the Message Key MUST be the same as the DD_ID value in the Operating Attributes.
使用されるなら、Message Keyは登録されるべきディスカバリーDomainのDD_IDを含んでいます。 Message KeyがiSNSデータベースにおける既存のDDエントリーのDD_IDを含んでいるなら、DDRegメッセージSHALLは、既存のエントリーをアップデートするのを試みます。 Message Key(使用されるなら)のDD_IDが既存のDDエントリーに合っていないなら、iSNSサーバSHALLは3(無効のRegistration)のステータスコードでDDRegメッセージを拒絶します。 DD_IDがMessage KeyとOperating Attributesの両方に含まれているなら、Message KeyのDD_ID値はOperating AttributesでDD_ID値と同じであるに違いありません。
Tseng, et al. Standards Track [Page 57] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[57ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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.
新しいディスカバリーDomain(DD)の試みられた作成におけるMessage Key SHALL結果のないDDRegメッセージ。 _ID属性(非ゼロ・レングスがある)はDDであるならDDRegメッセージのOperating Attributes、当時の新しいディスカバリーDomain SHALLの中に含まれています。そのDD_ID属性に含まれた値は割り当てられてください。 さもなければ、DD_ID属性がDDRegメッセージのOperating Attributesの中に含まれていないか、またはDD_IDが0のTLVの長さがある操作属性であるなら、iSNSサーバSHALLはDD_ID値を割り当てます。 そして、DDReg Responseメッセージで割り当てられたDD_ID値を返します。 また、Operating AttributesはDDに加えられるべきメンバーのDDメンバーiSCSI Node Index、DDメンバーiSCSI Name、DDメンバーFC Port Name、DDメンバーPortal IP Address(DDメンバーPortal TCP/UDP Port Number)またはDDメンバーPortal Indexを含むことができます。 また、それは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).
このメッセージSHALLは、どんなDDメンバーもDD_IDによって指定されたDomainにディスカバリーへのOperating Attributesについて記載したと言い足します。 DD_Featuresであるなら、属性はOperating Attributeであり、次に、それはSHALLです。iSNSサーバでは、指定されたDDのための特徴リストとして保存されてください。 DD_Symbolic_Nameが操作属性であるか、そして、値はユニークであり(すなわち、それは別のDDのために登録された_DD_Symbolic Nameに合っていません)、次に、値はSHALLです。指定されたディスカバリーDomainのためにDD_Symbolic_NameとしてiSNSデータベースに保存されてください。 DD_Symbolic_Nameのための値がユニークでないなら、iSNSサーバSHALLは3(無効のRegistration)のステータスコードで試みられたDD登録を拒絶します。
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がOperating Attributesに含まれていないか、またはそれが無の長さのTLVと共に含まれているなら、iSNSサーバSHALLは作成されたDDのために_Symbolic_Name値をユニークなDDに供給します。 割り当てられた_DD_Symbolic Nameは返されたコネがDDRegRspメッセージであったならSHALLを評価します。
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属性がOperating Attributesに含まれていないなら、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 Name、DDメンバーiFCP Node(DDメンバーPortal IP Address)、およびOperating Attributesに属性を含んでいるDDメンバーTCP/UDP Port Numberは現在の既存のiSNSデータベースエントリーに合う必要はありません。 これで、Storage Nodeが現在iSNSデータベースに登録されないでも、例えばStorage NodeはDDに加えます。 その結果、DDs作成時点でStorage NodeかPortalをDDに加えることができます、Storage NodeかPortalが現在ストレージネットワークでアクティブでなくても。
Tseng, et al. Standards Track [Page 58] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[58ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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.
Operating Attributesが現在iSNSデータベースに登録されないStorage NodeのためのDDメンバーiSCSI Name価値を含んでいるなら、iSNSサーバはそのStorage Nodeのために未使用のiSCSI Node Indexを割り当てなければなりません。 iSCSI Node Index SHALLが割り当てられて、DDメンバーiSCSI Node IndexとしてDDRegRspメッセージで返してください。 割り当てられたiSCSI Node IndexはSHALLを評価します。iSNSデータベースに登録するなら、Storage Nodeに割り当てられます。
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.
Operating Attributesが現在iSNSデータベースに登録されないPortalのためのDDメンバーPortal IP AddrとDDメンバーPortal TCP/UDP価値を含んでいるなら、iSNSサーバはそのPortalのために未使用のPortal Index値を割り当てなければなりません。 割り当てられたPortal Indexは返されたコネがDDメンバーPortal IndexとしてDDRegRspメッセージであったならSHALLを評価します。 割り当てられたPortal IndexはSHALLを評価します。iSNSデータベースに登録するなら、Portalに割り当てられます。
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.
Operating Attributesに提供されるDDメンバーiSCSI Node IndexとDDメンバーPortal Index属性はiSNSデータベースにおける既存のStorage NodeかPortalエントリーの対応するiSCSI Node IndexかPortal Indexに合わなければなりません。 その上、DDメンバーiSCSI Node IndexとDDメンバーPortal Index SHALL、Storage NodesかPortalsをDDに加えるには、それらのStorage NodesかPortalsがiSNSデータベースに活発に登録されない場合、使用されないでください。
5.6.5.10. DD Deregister (DDDereg)
5.6.5.10. DD Deregister(DDDereg)
The DDDereg message type is 0x000A. This message allows an iSNS client to deregister an existing Discovery Domain (DD) and to remove members from an existing DD.
DDDeregメッセージタイプは0x000Aです。 そして、このメッセージが「反-レジスタ」への既存のディスカバリーDomain(DD)をiSNSクライアントに許容する、既存のDDからメンバーを免職するために。
DDs are uniquely identified using DD_IDs. DD registration attributes are described in Section 6.11.
DDsは、DD_IDを使用することで唯一特定されます。 DD登録属性はセクション6.11で説明されます。
The DDDereg message PDU Payload contains a Source Attribute, Message Key Attribute, and optional Operating Attributes.
DDDeregメッセージPDU有効搭載量はSource Attribute、Message Key Attribute、および任意のOperating Attributesを含んでいます。
The Message Key Attribute for a DDDereg message is the DD ID for the Discovery Domain being removed or having members removed. If the DD ID matches an existing DD and there are no Operating Attributes, then the DD SHALL be removed and a success Status Code returned. Any existing members of that DD SHALL remain in the iSNS database without membership in the just-removed DD.
DDDeregメッセージのためのMessage Key Attributeは取り除くか、またはメンバーを免職することにさせるのであるディスカバリーDomainのためのDD IDです。 DD IDがそこで既存のDDに合っているなら、取り除かれるのとa成功が返されたStatus Codeであったなら、Operating Attributesがない、その時はDD SHALLですか? そのDD SHALLのどんな既存のメンバーもまさしく取り外されたDDにiSNSデータベースに会員資格なしで留まります。
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メンバーに合っているOperating Attributesがあれば、Operating Attributes SHALLによって特定されて、DDと返されたうまくいっているStatus Codeから取り除いてください。
Tseng, et al. Standards Track [Page 59] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[59ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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.
Operating Attributesで特定されたDDメンバーiSCSI NameがiSCSI Nameを含むなら、現在iSNSデータベースに登録されないか、または別のDD、当時の協会で含まれていないStorage Nodeに関してそのStorage Nodeとそのあらかじめ割り当てられたiSCSI Node Index SHALLの間に移されてください。 あらかじめ割り当てられたiSCSI Node Index値はもう特定のiSCSI Nameに協会を持っていません、そして、現在、再選任できます。
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メンバーPortal IP AddressとDDメンバーTCP/UDP PortがOperating Attributes参照で現在登録されないPortalを特定したなら、そのPortalとそのあらかじめ割り当てられたPortal Index SHALLの間のデータベースの、または、含まれた別のDD、当時の協会でiSNSでは、取り除いてください。 現在、あらかじめ割り当てられたPortal Index値を再選任できます。
The attempted deregistration of non-existent DD entries SHALL not be considered an error.
試みられた反登録、実在しないDDエントリーSHALLでは、誤りであることは考えられないでください。
5.6.5.11. DDS Register (DDSReg)
5.6.5.11. DDSは登録します。(DDSReg)
The DDSReg message type is 0x000B. This message allows an iSNS client to create a new Discovery Domain Set (DDS), to update an existing DDS Symbolic Name and/or DDS Status, or to add DDS members.
DDSRegメッセージタイプは0x000Bです。 このメッセージで、iSNSクライアントは、新しいディスカバリーDomain Set(DDS)を作成するか、既存のDDS Symbolic Name、そして/または、DDS Statusをアップデートするか、またはDDSメンバーを加えます。
DDSs are uniquely defined using DDS_IDs. DDS registration attributes are described in Section 6.11.1.
DDSsは、DDS_IDを使用することで唯一定義されます。 DDS登録属性はセクション6.11.1で説明されます。
The DDSReg message PDU Payload contains the Source Attribute and, optionally, Message Key and Operating Attributes.
DDSRegメッセージPDU有効搭載量は任意にSource Attribute、Message Key、およびOperating Attributesを含んでいます。
The Message Key, if used, contains the DDS_ID of the Discover Domain Set to be registered or modified. If the Message Key contains a DDS_ID of an existing DDS entry in the iSNS database, then the DDSReg message SHALL attempt to update the existing entry. If the DDS_ID in the Message Key (if used) does not match an existing DDS entry, then the iSNS server SHALL reject the DDSReg message with a status code of 3 (Invalid Registration). If the DDS_ID is included in both the Message Key and Operating Attributes, then the DDS_ID value in the Message Key MUST be the same as the DDS_ID value in the Operating Attributes.
使用されるなら、Message Keyは登録されるべきであるか、または変更されるべきDiscover Domain SetのDDS_IDを含んでいます。 Message KeyがiSNSデータベースにおける既存のDDSエントリーのDDS_IDを含んでいるなら、DDSRegメッセージSHALLは、既存のエントリーをアップデートするのを試みます。 Message Key(使用されるなら)のDDS_IDが既存のDDSエントリーに合っていないなら、iSNSサーバSHALLは3(無効のRegistration)のステータスコードでDDSRegメッセージを拒絶します。 DDS_IDがMessage KeyとOperating Attributesの両方に含まれているなら、Message KeyのDDS_ID値はOperating Attributesで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
新しいディスカバリーDomain Set(DDS)の試みられた作成におけるMessage Key SHALL結果のないDDSRegメッセージ。 _ID属性(非ゼロ・レングスがある)はDDSであるならDDSRegメッセージのOperating Attributes、当時の新しいディスカバリーDomain Set SHALLの中に含まれています。そのDDS_ID属性に含まれた値は割り当てられてください。 別の方法でDDS_ID属性がDDSRegメッセージのOperating Attributesの中に含まれていないか、またはDDS_IDがあります。
Tseng, et al. Standards Track [Page 60] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[60ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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.
0のTLVの長さで属性を操作して、そして、iSNSサーバSHALLはDDS_ID値を割り当てます。 そして、DDSReg Responseメッセージで割り当てられたDDS_ID値を返します。 また、Operating Attributesは_DDSに加えられるべきディスカバリーDomainsのDDS_SymbolicのName、DDS Status、および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 Symbolic NameがOperating Attributesに含まれているか、そして、値はユニークであり(すなわち、それは別のDDSのための登録されたDDS Symbolic Nameに合っていません)、次に、値はSHALLです。そのDDSのためのDDS Symbolic NameとしてiSNSデータベースに保存されてください。 DDS Symbolic Nameのための値がユニークでないなら、iSNSサーバSHALLは3(無効のRegistration)のステータスコードで試みられたDDS登録を拒絶します。
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 Symbolic NameがOperating Attributesに含まれていないか、またはそれが無の長さのTLVと共に含まれているなら、iSNSサーバSHALLはユニークなDDS Symbolic Name値を作成されたDDSに供給します。 割り当てられたDDS Symbolic Nameは返されたコネがDDSRegRspメッセージであったならSHALLを評価します。
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.
このメッセージSHALLは、どんなDD_IDもDDS_ID Message Key Attributeによって指定されたDomain SetにディスカバリーへのOperating Attributesについて記載したと言い足します。 さらに、DDS_Symbolic_Nameが操作属性であるか、そして、値はユニークであり、次に、それはSHALLです。指定されたディスカバリーDomain SetのためにDDS_Symbolic_NameとしてiSNSデータベースに保存されてください。
If a DD_ID listed in the Operating Attributes does not match an existing DD, then a new DD using the DD_ID SHALL be created. In this case for the new DD, the iSNS server SHALL assign a unique value for the DD Symbolic Name and SHALL set the DD Features attribute to the default value of 0. These assigned values SHALL be returned in the DDSRegRsp message.
Operating Attributesに記載されたDD_IDがそうしないなら、既存のDDを合わせてください、次に、新しいDDがDD_ID SHALLを使用して。作成されます。 この場合、新しいDDに関して、iSNSサーバSHALLはDD Symbolic Nameのためにユニークな値を割り当てます、そして、SHALLは0のデフォルト値にDD Features属性を設定します。 これらは返されたコネがDDSRegRspメッセージであったならSHALLを値に割り当てました。
5.6.5.12. DDS Deregister (DDSDereg)
5.6.5.12. DDS Deregister(DDSDereg)
The DDSDereg message type is 0x000C. This message allows an iSNS client to deregister an existing Discovery Domain Set (DDS) or to remove some DDs from an existing DDS.
DDSDeregメッセージタイプは0x000Cです。 または、このメッセージが「反-レジスタ」への既存のディスカバリーDomain Set(DDS)をiSNSクライアントに許容する、既存のDDSからいくつかのDDsを取り外すために。
The DDSDereg message PDU Payload contains a Source Attribute, a Message Key Attribute, and optional Operating Attributes.
DDSDeregメッセージPDU有効搭載量はSource Attribute、Message Key Attribute、および任意のOperating Attributesを含んでいます。
The Message Key Attribute for a DDSDereg message is the DDS ID for the DDS being removed or having members removed. If the DDS ID matches an existing DDS and there are no Operating Attributes, then
DDSDeregメッセージのためのMessage Key Attributeは取り除くか、またはメンバーを免職することにさせるのであるDDSのためのDDS IDです。 DDS IDが既存のDDSに合って、次に、Operating Attributesが全くなければ
Tseng, et al. Standards Track [Page 61] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[61ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
the DDS SHALL be removed and a success Status Code returned. Any existing members of that DDS SHALL remain in the iSNS database without membership in the just-removed DDS.
DDS SHALL、取り除いてStatus Codeが返した成功になってください。 そのDDS SHALLのどんな既存のメンバーもまさしく取り外されたDDSにiSNSデータベースに会員資格なしで留まります。
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を合わせて、Operating Attributesの合っているDDSメンバーがいて、次に、DDSはメンバーSHALLです。DDSとStatus Codeが返した成功から、取り除いてください。
The attempted deregistration of non-existent DDS entries SHALL not be considered an error.
試みられた反登録、実在しないDDSエントリーSHALLでは、誤りであることは考えられないでください。
5.6.5.13. Entity Status Inquiry (ESI)
5.6.5.13. 実体資産調査(ESI)
The ESI message type is 0x000D. This message is sent by the iSNS server, and is used to verify that an iSNS client Portal is reachable and available. The ESI message is sent to the ESI UDP port provided during registration, or to the TCP connection used for ESI registration, depending on which communication type that is being used.
ESIメッセージタイプは0x000Dです。 このメッセージは、iSNSサーバによって送られて、iSNSクライアントPortalが届いて利用可能であることを確かめるのに使用されます。 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、Portal IP Address、およびPortal TCP/UDP Port。 このメッセージの書式は以下に示されます:
+----------------------------------------+
| Timestamp |
+----------------------------------------+
| Entity_ID |
+----------------------------------------+
| Portal IP Address |
+----------------------------------------+
| Portal TCP/UDP Port |
+----------------------------------------+
+----------------------------------------+ | タイムスタンプ| +----------------------------------------+ | 実体_ID| +----------------------------------------+ | 入り口のIPアドレス| +----------------------------------------+ | 入り口のTCP/UDP港| +----------------------------------------+
The ESI response message PDU Payload contains a status code, followed by the Attributes from the original ESI message.
ESI応答メッセージPDU有効搭載量はAttributesによってオリジナルの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.
Portalが行政上決定している数の連続したESIメッセージに応じないなら、iSNSサーバSHALLはiSNSデータベースからそのPortalを取り外します。 また、関連Network Entity、当時のNetwork Entity SHALLのためにESIによってモニターされたPortalsのままで残っている何か他のものがいなければ、取り除いてください。 SHALL、いずれかであるなら州Change Notificationsを当ててください。引き起こされます。
Tseng, et al. Standards Track [Page 62] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[62ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
5.6.5.14. Name Service Heartbeat (Heartbeat)
5.6.5.14. 名前サービス鼓動(鼓動)
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形式においてそうではありません。 Name Service Heartbeatへの応答メッセージが全くありません。
MSb LSb
0 31
+------------------------------------------------+
| Active Server IP-Address | 16 Bytes
+------------------------------------------------+
| iSNS TCP Port | iSNS UDP Port | 4 Bytes
+------------------------------------------------+
| Interval | 4 Bytes
+------------------------------------------------+
| Counter | 4 Bytes
+------------------------------------------------+
| RESERVED | Backup Servers | 4 Bytes
+------------------------------------------------+
| Primary Backup Server IP Address(if any) | 16 Bytes
+------------------------------------------------+
|Backup TCP Port(if any)|Backup UDP Port(if any) | 4 Bytes
+------------------------------------------------+
| 2nd Backup Server IP Address(if any) | 16 Bytes
+------------------------------------------------+
|Backup TCP Port(if any)|Backup UDP Port(if any) | 4 Bytes
+------------------------------------------------+
| . . . |
+------------------------------------------------+
| VENDOR SPECIFIC |
+------------------------------------------------+
MSb LSb0 31+------------------------------------------------+ | アクティブなサーバIP-アドレス| 16バイト+------------------------------------------------+ | iSNS TCPポート| iSNS UDPポート| 4バイト+------------------------------------------------+ | 間隔| 4バイト+------------------------------------------------+ | カウンタ| 4バイト+------------------------------------------------+ | 予約されます。| バックアップサーバ| 4バイト+------------------------------------------------+ | プライマリBackup Server IP Address(もしあれば)| 16バイト+------------------------------------------------+ |バックアップTCP Port(もしあれば)|バックアップUDP Port(もしあれば)| 4バイト+------------------------------------------------+ | (もしあれば)の第2バックアップServer IP Address| 16バイト+------------------------------------------------+ |バックアップTCP Port(もしあれば)|バックアップUDP Port(もしあれば)| 4バイト+------------------------------------------------+ | . . . | +------------------------------------------------+ | ベンダー特有です。| +------------------------------------------------+
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 Address。 この分野がIPv4値を含むとき、それはIPv4によって写像されたIPv6アドレスとして保存されます。 すなわち、最も重要な10バイトは0xFFFFに設定された次の2バイトで0×00に設定されます[RFC2373]。 この分野がIPv6値を含むとき、全体の16バイトの分野は使用されています。
Active TCP Port: the TCP Port of the server currently in use.
アクティブなTCPポート: 現在使用中のサーバのTCP Port。
Tseng, et al. Standards Track [Page 63] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[63ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
Active UDP Port: the UDP Port of the server currently in use,
otherwise 0.
アクティブなUDPポート: そうでなければ、現在使用中のサーバのUDP Port、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 Port、およびUDP Portはこの野原に続きます。 バックアップサーバが使用されているならアクティブなiSNSサーバSHOULDがバックアップサーバのリストの中でそうであることに注意してください。
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サーバの間で調整して、ベンダーの特定の特徴を特定するのに追加分野を使用するかもしれません。
5.6.5.15. Request FC_DOMAIN_ID (RqstDomId)
5.6.5.15. FC_ドメイン_IDを要求してください。(RqstDomId)
The RqstDomId message type is 0x0011. This message is used for iFCP Transparent Mode to allocate non-overlapping FC_DOMAIN_ID values between 1 and 239. The iSNS server becomes the address assignment authority for the entire iFCP fabric. To obtain multiple FC_DOMAIN_ID values, this request must be repeated to the iSNS server multiple times. iSNS clients that acquire FC_DOMAIN_ID values from an iSNS server MUST register for ESI monitoring from that iSNS server.
RqstDomIdメッセージタイプは0×0011です。 iFCP Transparent Modeが非重なっているFC_DOMAIN_ID値に1〜239を割り当てるのにこのメッセージは使用されます。 iSNSサーバは全体のiFCP骨組みのためのアドレス課題権威になります。 複数のFC_DOMAIN_ID値を得るために、iSNSサーバ倍数回数にこの要求を繰り返さなければなりません。iSNSサーバからFC_DOMAIN_ID値を取得するiSNSクライアントは、そのiSNSサーバからのESIモニターに登録しなければなりません。
The RqstDomId PDU Payload contains three TLV attributes in the following order: the requesting Switch Name (WWN) as the Source Attribute, the Virtual_Fabric_ID as the Message Key Attribute, and Preferred ID as the operating attribute. The Virtual_Fabric_ID is a string identifying the domain space for which the iSNS server SHALL allocate non-overlapping integer FC_DOMAIN_ID values between 1 and 239. The Preferred_ID is the nominal FC_DOMAIN_ID value requested by the iSNS client. If the Preferred_ID value is available and has not already been allocated for the Virtual_Fabric_ID specified in the message, the iSNS server SHALL return the requested Preferred_ID value as the Assigned_ID to the requesting client.
RqstDomId PDU有効搭載量は以下のオーダーにおける3つのTLV属性を含んでいます: Source Attributeとしての要求Switch Name(WWN)、Message Key AttributeとしてのVirtual_Fabric_ID、および操作属性としてのPreferred ID。 Virtual_Fabric_IDはiSNSサーバSHALLが非重なっている整数FC_DOMAIN_ID値に1〜239を割り当てるドメインスペースを特定するストリングです。 Preferred_IDはiSNSクライアントによって要求された名目上のFC_DOMAIN_ID価値です。 Preferred_ID値が利用可能であり、メッセージで指定されたVirtual_Fabric_IDのために既に割り当てられていないなら、iSNSサーバSHALLはAssigned_IDとして要求されたPreferred_ID値を要求しているクライアントに返します。
The RqstDomId response contains a Status Code, and the TLV attribute Assigned ID, which contains the integer value in the space requested. If no further unallocated values are available from this space, the iSNS server SHALL respond with the Status Code 18 "FC_DOMAIN_ID Not Available".
RqstDomId応答はStatus Codeを含んでいます、そして、TLVはAssigned IDを結果と考えます。(それは、スペースの値が要求した整数を含みます)。 これ以上「非-割り当て」られなかった値がこのスペースから利用可能であるなら、Status Code18「利用可能でないFC_ドメイン_ID」でiSNSサーバSHALLは応じます。
Tseng, et al. Standards Track [Page 64] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[64ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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.
ESIモニターがそれを検出するまで、iSNSクライアントはもうネットワークに存在しません、そして、与えられたVirtual_Fabric_IDのためにiSNSサーバでいったんFC_DOMAIN_ID価値をiSNSクライアントに割り当てると、FC_DOMAIN_ID価値のSHALL NOTがそれまで再利用されるのを「反-割り当て」たか、またはiSNSデータベースからそのクライアントのためのオブジェクトを取り除きます。
The iSNS server and client SHALL use TCP to transmit and receive RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
iSNSサーバとクライアントSHALLは、RqstDomId、RqstDomIdRsp、RlseDomId、およびRlseDomIdRspメッセージを送受信するのにTCPを使用します。
5.6.5.16. Release FC_DOMAIN_ID (RlseDomId)
5.6.5.16. リリースFC_ドメイン_ID(RlseDomId)
The RlseDomId message type is 0x0012. This message may be used by iFCP Transparent Mode to release integer identifier values used to assign 3-byte Fibre Channel PORT_ID values.
RlseDomIdメッセージタイプは0×0012です。 このメッセージは、3バイトのFibre Channel PORT_ID値を割り当てるのにおいて中古の整数識別子値をリリースするのにiFCP Transparent Modeによって使用されるかもしれません。
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属性を含んでいます: Source Attributeとしての要求しているEID、Message Key AttributeとしてのVirtual_Fabric_ID、および操作属性としてのAssigned_ID。 RlseDomIdメッセージを受け取って、FC_DOMAIN_ID価値がVirtual_Fabric_ID属性のためのAssigned_ID属性に含んだiSNSサーバSHALL deallocateは指定しました。 反配分では、次に、そのFC_DOMAIN_ID価値は、クライアントを要求して、異なったiSNSに選任できます。
The iSNS server and client SHALL use TCP to transmit and receive RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
iSNSサーバとクライアントSHALLは、RqstDomId、RqstDomIdRsp、RlseDomId、およびRlseDomIdRspメッセージを送受信するのにTCPを使用します。
5.6.5.17. Get FC_DOMAIN_IDs (GetDomId)
5.6.5.17. FC_ドメイン_IDを得てください。(GetDomId)
The GetDomId message type is 0x0013. This message is used to learn the currently-allocated FC_DOMAIN_ID values for a given Virtual_Fabric_ID.
GetDomIdメッセージタイプは0×0013です。 このメッセージは、与えられたVirtual_Fabric_IDのために現在割り当てられたFC_DOMAIN_ID値を学ぶのに使用されます。
The GetDomId message PDU Payload contains a Source Attribute and Message Key Attribute.
GetDomIdメッセージPDU有効搭載量はSource AttributeとMessage Key Attributeを含んでいます。
The Message Key Attribute for the GetDomId message is the Virtual_Fabric_ID. The response to this message returns all the FC_DOMAIN_ID values that have been allocated for the Virtual_Fabric_ID specified.
GetDomIdメッセージのためのMessage Key AttributeはVirtual_Fabric_IDです。 このメッセージへの応答は_IDが指定したVirtual_Fabric_のために割り当てられたDOMAIN_ID値をすべてのFCに返します。
Tseng, et al. Standards Track [Page 65] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[65ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
5.7. Messages
5.7. メッセージ
The iSNSP response message PDU Payloads contain a Status Code, followed by a list of attributes, and have the following format:
iSNSP応答メッセージPDU有効搭載量は、Status Codeを含んでいて、属性のリストで続いて、以下の形式を持っています:
MSb LSb
0 31
+----------------------------------------+
| 4-byte STATUS CODE |
+----------------------------------------+
| Message Key Attribute[1] (if present) |
+----------------------------------------+
| Message Key Attribute[2] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
| - Delimiter Attribute - (if present) |
+----------------------------------------+
| Operating Attribute[1] (if present) |
+----------------------------------------+
| Operating Attribute[2] (if present) |
+----------------------------------------+
| Operating Attribute[3] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
MSb LSb0 31+----------------------------------------+ | 4バイトのステータスコード| +----------------------------------------+ | メッセージKey Attribute[1](存在しているなら)| +----------------------------------------+ | メッセージKey Attribute[2](存在しているなら)| +----------------------------------------+ | . . . | +----------------------------------------+ | - デリミタAttribute--、(現在)| +----------------------------------------+ | 操作Attribute[1](存在しているなら)| +----------------------------------------+ | 操作Attribute[2](存在しているなら)| +----------------------------------------+ | 操作Attribute[3](存在しているなら)| +----------------------------------------+ | . . . | +----------------------------------------+
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 ResponseメッセージSHALLは関連登録に使用されたiSNS Client IP Addressと起因しているTCP/UDP Portに送られて、メッセージについて質問します。
5.7.1. Status Code
5.7.1. ステータスコード
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有効搭載量における最初の分野は実行された操作のためのStatus Codeです。 Status Codeコード化はセクション5.4で定義されます。
5.7.2. Message Key Attributes in Response
5.7.2. 応答におけるメッセージの主要な属性
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要求によって、応答メッセージはMessage Key Attributesを含むかもしれません。 一般に、メッセージKey AttributesはオリジナルのiSNS登録か質問メッセージで指定された操作で影響を受けるおもしろい主要な属性を含んでいます。
Tseng, et al. Standards Track [Page 66] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[66ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
5.7.3. Delimiter Attribute in Response
5.7.3. 応答におけるデリミタ属性
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は応答メッセージでキーとOperating Attributesを切り離します。 Delimiter Attributeには、0のタグ値と0の長さの値があります。 事実上、Delimiter Attributeは8バイト長です: 0×00000000を含む4バイトのタグ、および0×00000000を含む4Byte長さの分野。
5.7.4. Operating Attributes in Response
5.7.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.
応答におけるOperating AttributesはiSNS登録に関連する結果であるか実行される操作について質問します。 いくつかの応答メッセージには、Operating Attributesがないでしょう。
5.7.5. Registration and Query Response Message Types
5.7.5. 登録と質問応答メッセージタイプ
The following sections describe each query and message type.
以下のセクションは各質問とメッセージタイプについて説明します。
5.7.5.1. Device Attribute Registration Response (DevAttrRegRsp)
5.7.5.1. デバイス属性登録応答(DevAttrRegRsp)
The DevAttrRegRsp message type is 0x8001. The DevAttrRegRsp message contains the results for the DevAttrReg message with the same TRANSACTION ID.
DevAttrRegRspメッセージタイプは0×8001です。 DevAttrRegRspメッセージは同じTRANSACTION 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メッセージSHALLのMessage Keyはオリジナルの登録メッセージでMessage Keyを返します。 iSNSサーバがNetwork EntityのためにEntity Identifierを割り当てたなら、Message Key Attribute分野SHALLは割り当てられたEntity Identifierを含んでいます。
The Operating Attributes of the DevAttrRegRsp message SHALL contain the affected object's key and non-key attributes that have been explicitly modified or created by the original DevAttrReg message. Among the Operating Attributes, each modified or added non-key attribute SHALL be listed after its key attribute(s) in the DevAttrRegRsp message. Implicitly registered attributes MUST NOT be returned in the DevAttrRegRsp message. Implicitly registered attributes are those that are assigned a fixed default value or secondary index value by the iSNS server.
DevAttrRegRspメッセージSHALLのOperating AttributesはオリジナルのDevAttrRegメッセージによって明らかに変更されるか、または作成された影響を受けるオブジェクトの主要で非主要な属性を含んでいます。 Operating Attributesの中では、それぞれが、非主要な属性SHALLがDevAttrRegRspメッセージの主要な属性の後に記載されると変更したか、または言い足しました。 DevAttrRegRspメッセージでそれとなく登録された属性を返してはいけません。 それとなく登録された属性は固定デフォルト値か二次索引値がiSNSサーバによって割り当てられるそれらです。
Implicitly registered PG objects (i.e., PG objects that are not explicitly included in the registration or replace message) MUST NOT have their key or non-key attributes returned in the DevAttrRegRsp message. However, explicitly registered PG objects (i.e., those with PGT values that are explicitly included in the registration or replace message) SHALL have their PGT values returned in the DevAttrRegRsp message.
それとなく登録された未成年者不適当映画オブジェクト(すなわち、登録に明らかに含まれていないか、またはメッセージを置き換える未成年者不適当映画オブジェクト)で、DevAttrRegRspメッセージでそれらの主要であるか非主要な属性を返してはいけません。 しかしながら、明らかに登録された未成年者不適当映画オブジェクト(すなわち、登録に明らかに含まれているか、またはメッセージを置き換えるPGT値があるそれら)SHALLはDevAttrRegRspメッセージでそれらのPGT値を返させます。
Tseng, et al. Standards Track [Page 67] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[67ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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.
例えば、3PortalsがオリジナルのDevAttrReg要求メッセージに登録されます。 財源不足のため、iSNSサーバは、それらのPortalsの1つの登録されたESI Interval値を変更する必要があります。 これを達成するために、iSNSサーバは対応するDevAttrRegRspメッセージのOperating Attributesとして非主要な変更されたESI Interval属性値があとに続いたPortalを特定する主要な属性を返します。
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サーバが登録を拒絶するなら、無効の属性値かタイプ、次に、示されたステータスコードSHALLが3歳(無効のRegistration)ですか? これが起こるなら、iSNSサーバはDevAttrRspメッセージのOperating Attributesに無効の属性のリストを含むかもしれません。
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.
Some attributes values (e.g., ESI Interval, Registration Period) in the original registration message MAY be modified by the iSNS server. This can occur only for a limited set of attribute types, as indicated in the table in Section 6.1. When this occurs, the registration SHALL be considered a success (with status code 0), and the changed value(s) indicated in the Operating Attributes of the DevAttrRsp message.
5.7.5.2. Device Attribute Query Response (DevAttrQryRsp)
5.7.5.2. Device Attribute Query Response (DevAttrQryRsp)
The DevAttrQryRsp message type is 0x8002. The DevAttrQryRsp message contains the results for the DevAttrQry message with the same TRANSACTION ID.
The DevAttrQryRsp message type is 0x8002. The DevAttrQryRsp message contains the results for the DevAttrQry message with the same TRANSACTION ID.
The Message Key in the DevAttrQryRsp message SHALL return the Message Key in the original query message.
The Message Key in the DevAttrQryRsp message SHALL return the Message Key in the original query message.
If no Operating Attributes are included in the original query, then all Operating Attributes SHALL be returned in the response.
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.
For a successful query result, the DevAttrQryRsp Operating Attributes SHALL contain the results of the original DevAttrQry message.
5.7.5.3. Device Get Next Response (DevGetNextRsp)
5.7.5.3. Device Get Next Response (DevGetNextRsp)
The DevGetNextRsp message type is 0x8003. The DevGetNextRsp message contains the results for the DevGetNext message with the same TRANSACTION ID.
The DevGetNextRsp message type is 0x8003. The DevGetNextRsp message contains the results for the DevGetNext message with the same TRANSACTION ID.
The Message Key Attribute field returns the object keys for the next object after the Message Key Attribute in the original DevGetNext message.
The Message Key Attribute field returns the object keys for the next object after the Message Key Attribute in the original DevGetNext message.
Tseng, et al. Standards Track [Page 68] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Tseng, et al. Standards Track [Page 68] RFC 4171 Internet Storage Name Service (iSNS) September 2005
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.
The Operating Attribute field returns the Operating Attributes of the next object as requested in the original DevGetNext message. The values of the Operating Attributes are those associated with the object identified by the Message Key Attribute field of the DevGetNextRsp message.
5.7.5.4. Deregister Device Response (DevDeregRsp)
5.7.5.4. Deregister Device Response (DevDeregRsp)
The DevDeregRsp message type is 0x8004. This message is the response to the DevDereg request message.
The DevDeregRsp message type is 0x8004. This message is the response to the DevDereg request message.
This message response does not contain a Message Key, but MAY contain Operating Attributes.
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.
In the event of an error, this response message contains the appropriate status code as well as a list of objects from the original DevDereg message that were not successfully deregistered from the iSNS database. This list of objects is contained in the Operating Attributes of the DevDeregRsp message. Note that an attempted deregistration of a non-existent object does not constitute an error, and non-existent entries SHALL not be returned in the DevDeregRsp message.
5.7.5.5. SCN Register Response (SCNRegRsp)
5.7.5.5. SCN Register Response (SCNRegRsp)
The SCNRegRsp message type is 0x8005. This message is the response to the SCNReg request message.
The SCNRegRsp message type is 0x8005. This message is the response to the SCNReg request message.
The SCNRegRsp message does not contain any Message Key or Operating Attributes.
The SCNRegRsp message does not contain any Message Key or Operating Attributes.
5.7.5.6. SCN Deregister Response (SCNDeregRsp)
5.7.5.6. SCN Deregister Response (SCNDeregRsp)
The SCNDeregRsp message type is 0x8006. This message is the response to the SCNDereg request message.
The SCNDeregRsp message type is 0x8006. This message is the response to the SCNDereg request message.
The SCNDeregRsp message does not contain any Message Key or Operating Attributes.
The SCNDeregRsp message does not contain any Message Key or Operating Attributes.
5.7.5.7. SCN Event Response (SCNEventRsp)
5.7.5.7. SCN Event Response (SCNEventRsp)
The SCNEventRsp message type is 0x8007. This message is the response to the SCNEvent request message.
The SCNEventRsp message type is 0x8007. This message is the response to the SCNEvent request message.
The SCNEventRsp message does not contain any Message Key or Operating Attributes.
The SCNEventRsp message does not contain any Message Key or Operating Attributes.
Tseng, et al. Standards Track [Page 69] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Tseng, et al. Standards Track [Page 69] RFC 4171 Internet Storage Name Service (iSNS) September 2005
5.7.5.8. SCN Response (SCNRsp)
5.7.5.8. SCN Response (SCNRsp)
The SCNRsp message type is 0x8008. This message is sent by an iSNS client, and provides confirmation that the SCN message was received and processed.
The SCNRsp message type is 0x8008. This message is sent by an iSNS client, and provides confirmation that the SCN message was received and processed.
The SCNRsp response contains the SCN Destination Attribute representing the Node identifier that received the SCN.
The SCNRsp response contains the SCN Destination Attribute representing the Node identifier that received the SCN.
5.7.5.9. DD Register Response (DDRegRsp)
5.7.5.9. DD Register Response (DDRegRsp)
The DDRegRsp message type is 0x8009. This message is the response to the DDReg request message.
The DDRegRsp message type is 0x8009. This message is the response to the DDReg request message.
The Message Key in the DDRegRsp message SHALL return the Message Key in the original query message. If the original DDReg message did not have a Message Key, then the DDRegRsp message SHALL not have a Message Key.
The Message Key in the DDRegRsp message SHALL return the Message Key in the original query message. If the original DDReg message did not have a Message Key, then the DDRegRsp message SHALL not have a Message Key.
If the DDReg operation is successful, the DD ID of the DD created or updated SHALL be returned as an operating attribute of the message.
If the DDReg operation is successful, the DD ID of the DD created or updated SHALL be returned as an operating attribute of the message.
If the DD Symbolic Name attribute or DD Features attribute was assigned or updated during the DDReg operation, then any new values SHALL be returned as an operating attribute of the DDRegRsp message.
If the DD Symbolic Name attribute or DD Features attribute was assigned or updated during the DDReg operation, then any new values SHALL be returned as an operating attribute of the DDRegRsp message.
If the iSNS server rejects a DDReg due to invalid attribute values or types, then the indicated status code SHALL be 3 (Invalid Registration). If this occurs, then the iSNS server MAY include the list of invalid attributes in the Operating Attributes of the DDRegRsp message.
If the iSNS server rejects a DDReg due to invalid attribute values or types, then the indicated status code SHALL be 3 (Invalid Registration). If this occurs, then the iSNS server MAY include the list of invalid attributes in the Operating Attributes of the DDRegRsp message.
5.7.5.10. DD Deregister Response (DDDeregRsp)
5.7.5.10. DD Deregister Response (DDDeregRsp)
The DDDeregRsp message type is 0x800A. This message is the response to the DDDereg request message.
The DDDeregRsp message type is 0x800A. This message is the response to the DDDereg request message.
The DDDeregRsp message does not contain any Message Key or Operating Attributes.
The DDDeregRsp message does not contain any Message Key or Operating Attributes.
Tseng, et al. Standards Track [Page 70] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Tseng, et al. Standards Track [Page 70] RFC 4171 Internet Storage Name Service (iSNS) September 2005
5.7.5.11. DDS Register Response (DDSRegRsp)
5.7.5.11. DDS Register Response (DDSRegRsp)
The DDSRegRsp message type is 0x800B. This message is the response to the DDSReg request message.
The DDSRegRsp message type is 0x800B. This message is the response to the DDSReg request message.
The Message Key in the DDSRegRsp message SHALL contain the Message Key of the original DDSReg message. If the original DDSReg message did not have a Message Key, then the DDSRegRsp message SHALL NOT have a Message Key.
The Message Key in the DDSRegRsp message SHALL contain the Message Key of the original DDSReg message. If the original DDSReg message did not have a Message Key, then the DDSRegRsp message SHALL NOT have a Message Key.
If the DDSReg operation is successful, the DDS ID of the DDS created or updated SHALL be returned as an operating attribute of the message.
If the DDSReg operation is successful, the DDS ID of the DDS created or updated SHALL be returned as an operating attribute of the message.
If the DDS Symbolic Name attribute or DDS Status attribute was assigned or updated during the DDSRegRsp operation, then any new values SHALL be returned as an operating attribute of the DDSRegRsp message.
If the DDS Symbolic Name attribute or DDS Status attribute was assigned or updated during the DDSRegRsp operation, then any new values SHALL be returned as an operating attribute of the DDSRegRsp message.
If the iSNS server rejects a DDSReg due to invalid attribute values or types, then the indicated status code SHALL be 3 (Invalid Registration). If this occurs, then the iSNS server MAY include the list of invalid attributes in the Operating Attributes of the DDSRegRsp message.
If the iSNS server rejects a DDSReg due to invalid attribute values or types, then the indicated status code SHALL be 3 (Invalid Registration). If this occurs, then the iSNS server MAY include the list of invalid attributes in the Operating Attributes of the DDSRegRsp message.
5.7.5.12. DDS Deregister Response (DDSDeregRsp)
5.7.5.12. DDS Deregister Response (DDSDeregRsp)
The DDSDeregRsp message type is 0x800C. This message is the response to the DDSDereg request message.
The DDSDeregRsp message type is 0x800C. This message is the response to the DDSDereg request message.
The DDSDeregRsp message does not contain any Message Key or Operating Attributes.
The DDSDeregRsp message does not contain any Message Key or Operating Attributes.
5.7.5.13. Entity Status Inquiry Response (ESIRsp)
5.7.5.13. Entity Status Inquiry Response (ESIRsp)
The ESIRsp message type is 0x800D. This message is sent by an iSNS client and provides confirmation that the ESI message was received and processed.
The ESIRsp message type is 0x800D. This message is sent by an iSNS client and provides confirmation that the ESI message was received and processed.
The ESIRsp response message PDU Payload contains the attributes from the original ESI message. These attributes represent the Portal that is responding to the ESI. The ESIRsp Attributes are in the order they were provided in the original ESI message.
The ESIRsp response message PDU Payload contains the attributes from the original ESI message. These attributes represent the Portal that is responding to the ESI. The ESIRsp Attributes are in the order they were provided in the original ESI message.
Upon receiving the ESIRsp from the iSNS client, the iSNS server SHALL update the timestamp attribute for that Network Entity and Portal.
Upon receiving the ESIRsp from the iSNS client, the iSNS server SHALL update the timestamp attribute for that Network Entity and Portal.
Tseng, et al. Standards Track [Page 71] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Tseng, et al. Standards Track [Page 71] RFC 4171 Internet Storage Name Service (iSNS) September 2005
5.7.5.14. Request FC_DOMAIN_ID Response (RqstDomIdRsp)
5.7.5.14. Request FC_DOMAIN_ID Response (RqstDomIdRsp)
The RqstDomIdRsp message type is 0x8011. This message provides the response for RqstDomId.
The RqstDomIdRsp message type is 0x8011. This message provides the response for RqstDomId.
The RqstDomId response contains a Status Code and the TLV attribute Assigned ID, which contains the integer value in the space requested. If no further unallocated values are available from this space, the iSNS server SHALL respond with the Status Code 19 "FC_DOMAIN_ID Not Available".
The RqstDomId response contains a Status Code and the TLV attribute Assigned ID, which contains the integer value in the space requested. If no further unallocated values are available from this space, the iSNS server SHALL respond with the Status Code 19 "FC_DOMAIN_ID Not Available".
Once a FC_DOMAIN_ID value is allocated by the iSNS server, it SHALL NOT be reused until it has been deallocated by the iSNS client to which the value was assigned, or until the ESI message detects that the iSNS client no longer exists on the network.
Once a FC_DOMAIN_ID value is allocated by the iSNS server, it SHALL NOT be reused until it has been deallocated by the iSNS client to which the value was assigned, or until the ESI message detects that the iSNS client no longer exists on the network.
The iSNS server and client SHALL use TCP to transmit and receive RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
The iSNS server and client SHALL use TCP to transmit and receive RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
5.7.5.15. Release FC_DOMAIN_ID Response (RlseDomIdRsp)
5.7.5.15. Release FC_DOMAIN_ID Response (RlseDomIdRsp)
The RlseDomIdRsp message type is 0x8012. This message provides the response for RlseDomId. The response contains an Error indicating whether the request was successful. If the Assigned_ID value in the original RlseDomId message is not allocated, then the iSNS server SHALL respond with this message using the Status Code 20 "FC_DOMAIN_ID Not Allocated".
The RlseDomIdRsp message type is 0x8012. This message provides the response for RlseDomId. The response contains an Error indicating whether the request was successful. If the Assigned_ID value in the original RlseDomId message is not allocated, then the iSNS server SHALL respond with this message using the Status Code 20 "FC_DOMAIN_ID Not Allocated".
The iSNS server and client SHALL use TCP to transmit and receive RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
The iSNS server and client SHALL use TCP to transmit and receive RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages.
5.7.5.16. Get FC_DOMAIN_IDs Response (GetDomIdRsp)
5.7.5.16. Get FC_DOMAIN_IDs Response (GetDomIdRsp)
The GetDomIdRsp message type is 0x8013. This message is used to determine which FC_DOMAIN_ID values have been allocated for the Virtual_Fabric_ID specified in the original GetDomId request message.
The GetDomIdRsp message type is 0x8013. This message is used to determine which FC_DOMAIN_ID values have been allocated for the Virtual_Fabric_ID specified in the original GetDomId request message.
The GetDomId response message PDU Payload contains a Status Code indicating whether the request was successful, and a list of the Assigned IDs from the space requested. The Assigned_ID attributes are listed in TLV format.
The GetDomId response message PDU Payload contains a Status Code indicating whether the request was successful, and a list of the Assigned IDs from the space requested. The Assigned_ID attributes are listed in TLV format.
5.8. Vendor-Specific Messages
5.8. Vendor-Specific Messages
Vendor-specific iSNSP messages have a functional ID of between 0x0100 and 0x01FF, whereas vendor-specific responses have a functional ID of between 0x8100 and 0x81FF. The first Message Key Attribute in a
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
Tseng, et al. Standards Track [Page 72] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Tseng, et al. Standards Track [Page 72] RFC 4171 Internet Storage Name Service (iSNS) September 2005
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.
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.
6. iSNS Attributes
6. iSNS Attributes
Attributes can be stored in the iSNS server using iSNSP registration messages, and they can be retrieved using iSNSP query messages. Unless otherwise indicated, these attributes are supplied by iSNS clients using iSNSP registration messages.
Attributes can be stored in the iSNS server using iSNSP registration messages, and they can be retrieved using iSNSP query messages. Unless otherwise indicated, these attributes are supplied by iSNS clients using iSNSP registration messages.
6.1. iSNS Attribute Summary
6.1. iSNS Attribute Summary
The complete registry of iSNS attributes is maintained by IANA, and the following table summarizes the initial set of iSNS attributes available at the time of publication of this document.
The complete registry of iSNS attributes is maintained by IANA, and the following table summarizes the initial set of iSNS attributes available at the time of publication of this document.
Attributes Length Tag Reg Key Query Key ---------- ------ --- ------- --------- Delimiter 0 0 N/A N/A Entity Identifier (EID) 4-256 1 1 1|2|16&17|32|64 Entity Protocol 4 2 1 1|2|16&17|32|64 Management IP Address 16 3 1 1|2|16&17|32|64 Timestamp 8 4 -- 1|2|16&17|32|64 Protocol Version Range 4 5 1 1|2|16&17|32|64 Registration Period 4 6 1 1|2|16&17|32|64 Entity Index 4 7 1 1|2|16&17|32|64 Entity Next Index 4 8 -- 1|2|16&17|32|64 Entity ISAKMP Phase-1 var 11 1 1|2|16&17|32|64 Entity Certificate var 12 1 1|2|16&17|32|64 Portal IP Address 16 16 1 1|16&17|32|64 Portal TCP/UDP Port 4 17 1 1|16&17|32|64 Portal Symbolic Name 4-256 18 16&17 1|16&17|32|64 ESI Interval 4 19 16&17 1|16&17|32|64 ESI Port 4 20 16&17 1|16&17|32|64 Portal Index 4 22 16&17 1|16&17|32|64 SCN Port 4 23 16&17 1|16&17|32|64 Portal Next Index 4 24 -- 1|16&17|32|64 Portal Security Bitmap 4 27 16&17 1|16&17|32|64 Portal ISAKMP Phase-1 var 28 16&17 1|16&17|32|64 Portal ISAKMP Phase-2 var 29 16&17 1|16&17|32|64 Portal Certificate var 31 16&17 1|16&17|32|64 iSCSI Name 4-224 32 1 1|16&17|32|33 iSCSI Node Type 4 33 32 1|16&17|32 iSCSI Alias 4-256 34 32 1|16&17|32 iSCSI SCN Bitmap 4 35 32 1|16&17|32 iSCSI Node Index 4 36 32 1|16&17|32 WWNN Token 8 37 32 1|16&17|32
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
Tseng, et al. Standards Track [Page 73] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Tseng, et al. Standards Track [Page 73] RFC 4171 Internet Storage Name Service (iSNS) September 2005
iSCSI Node Next Index 4 38 -- 1|16&17|32 iSCSI AuthMethod var 42 32 1|16&17|32 PG iSCSI Name 4-224 48 32|16&17 1|16&17|32|52 PG Portal IP Addr 16 49 32|16&17 1|16&17|32|52 PG Portal TCP/UDP Port 4 50 32|16&17 1|16&17|32|52 PG Tag (PGT) 4 51 32|16&17 1|16&17|32|52 PG Index 4 52 32|16&17 1|16&17|32|52 PG Next Index 4 53 -- 1|16&17|32|52 FC Port Name WWPN 8 64 1 1|16&17|64|66|96|128 Port ID 4 65 64 1|16&17|64 FC Port Type 4 66 64 1|16&17|64 Symbolic Port Name 4-256 67 64 1|16&17|64 Fabric Port Name 8 68 64 1|16&17|64 Hard Address 4 69 64 1|16&17|64 Port IP-Address 16 70 64 1|16&17|64 Class of Service 4 71 64 1|16&17|64 FC-4 Types 32 72 64 1|16&17|64 FC-4 Descriptor 4-256 73 64 1|16&17|64 FC-4 Features 128 74 64 1|16&17|64 iFCP SCN bitmap 4 75 64 1|16&17|64 Port Role 4 76 64 1|16&17|64 Permanent Port Name 8 77 -- 1|16&17|64 FC-4 Type Code 4 95 -- 1|16&17|64 FC Node Name WWNN 8 96 64 1|16&17|64|96 Symbolic Node Name 4-256 97 96 64|96 Node IP-Address 16 98 96 64|96 Node IPA 8 99 96 64|96 Proxy iSCSI Name 4-256 101 96 64|96 Switch Name 8 128 128 128 Preferred ID 4 129 128 128 Assigned ID 4 130 128 128 Virtual_Fabric_ID 4-256 131 128 128 iSNS Server Vendor OUI 4 256 -- SOURCE Attribute Vendor-Spec iSNS Srvr 257-384 -- SOURCE Attribute Vendor-Spec Entity 385-512 1 1|2|16&17|32|64 Vendor-Spec Portal 513-640 16&17 1|16&17|32|64 Vendor-Spec iSCSI Node 641-768 32 16&17|32 Vendor-Spec FC Port Name 769-896 64 1|16&17|64 Vendor-Spec FC Node Name 897-1024 96 64|96 Vendor-Specific DDS 1025-1280 2049 2049 Vendor-Specific DD 1281-1536 2065 2065 Other Vendor-Specific 1537-2048 DD_Set ID 4 2049 2049 1|32|64|2049|2065 DD_Set Sym Name 4-256 2050 2049 2049 DD_Set Status 4 2051 2049 2049 DD_Set_Next_ID 4 2052 -- 2049 DD_ID 4 2065 2049 1|32|64|2049|2065 DD_Symbolic Name 4-256 2066 2065 2065
iSCSI 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
Tseng, et al. Standards Track [Page 74] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Tseng, et al. Standards Track [Page 74] RFC 4171 Internet Storage Name Service (iSNS) September 2005
DD_Member iSCSI Index 4 2067 2065 2065 DD_Member iSCSI Name 4-224 2068 2065 2065 DD_Member FC Port Name 8 2069 2065 2065 DD_Member Portal Index 4 2070 2065 2065 DD_Member Portal IP Addr 16 2071 2065 2065 DD_Member Portal TCP/UDP 4 2072 2065 2065 DD_Features 4 2078 2065 2065 DD_ID Next ID 4 2079 -- 2065
DD_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:
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).
Length: indicates the attribute length in bytes used for the TLV format. Variable-length identifiers are NULL-terminated and 4-byte aligned (NULLs are included in the length).
Tag: the IANA-assigned integer tag value used to identify the
attribute. All undefined tag values are reserved.
Tag: the IANA-assigned integer tag value used to identify the attribute. All undefined tag values are reserved.
Reg Key: indicates the tag values for the object key in DevAttrReg
messages for registering a new attribute value in the
database. These tags represent attributes defined as
object keys in Section 4.
Reg Key: indicates the tag values for the object key in DevAttrReg messages for registering a new attribute value in the database. These tags represent attributes defined as object keys in Section 4.
Query Key: indicates the possible tag values for the Message Key and
object key that are used in the DevAttrQry messages for
retrieving a stored value from the iSNS database.
Query Key: indicates the possible tag values for the Message Key and object key that are used in the DevAttrQry messages for retrieving a stored value from the iSNS database.
The following is a summary of iSNS attribute tag values available for future allocation by IANA at the time of publication:
The following is a summary of iSNS attribute tag values available for future allocation by IANA at the time of publication:
Tag Values Reg Key Query Key ---------- ------- --------- 9-10, 13-15 1 1|2|16&17|32|64 21, 25-26, 30 16&17 1|16&17|32|64 39-41, 44-47 32 1|16&17|32 54-63 32|16&17 1|16&17|32|52 78-82, 85-94 64 1|16&17|64 102-127 96 64|96 132-255 -- SOURCE Attribute 2053-2064 2049 2049 2073-2077 2065 2065 2080-65535 To be assigned To be assigned
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.
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.
Tseng, et al. Standards Track [Page 75] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Tseng, et al. Standards Track [Page 75] RFC 4171 Internet Storage Name Service (iSNS) September 2005
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 "--".
New iSNS attributes with any of the above tag values MAY also be designated as "read-only" attributes. The new RFC introducing these attributes as "read-only" SHALL document them as such, and IANA will record their corresponding Registration Keys (Reg Keys) as "--".
6.2. Entity Identifier-Keyed Attributes
6.2. Entity Identifier-Keyed Attributes
The following attributes are stored in the iSNS server using the Entity Identifier attribute as the key.
The following attributes are stored in the iSNS server using the Entity Identifier attribute as the key.
6.2.1. Entity Identifier (EID)
6.2.1. Entity Identifier (EID)
The Entity Identifier (EID) is variable-length UTF-8 encoded NULL- terminated text-based description for a Network Entity. This key attribute uniquely identifies each Network Entity registered in the iSNS server. The attribute length varies from 4 to 256 bytes (including the NULL termination), and is a unique value within the iSNS server.
The Entity Identifier (EID) is variable-length UTF-8 encoded NULL- terminated text-based description for a Network Entity. This key attribute uniquely identifies each Network Entity registered in the iSNS server. The attribute length varies from 4 to 256 bytes (including the NULL termination), and is a unique value within the iSNS server.
If the iSNS client does not provide an EID during registration, the iSNS server SHALL generate one that is unique within the iSNS database. If an EID is to be generated, then the EID attribute value in the registration message SHALL be empty (0 length). The generated EID SHALL be returned in the registration response.
If the iSNS client does not provide an EID during registration, the iSNS server SHALL generate one that is unique within the iSNS database. If an EID is to be generated, then the EID attribute value in the registration message SHALL be empty (0 length). The generated EID SHALL be returned in the registration response.
In environments where the iSNS server is integrated with a DNS infrastructure, the Entity Identifier may be used to store the Fully Qualified Domain Name (FQDN) of the iSCSI or iFCP device. FQDNs of greater than 255 bytes MUST NOT be used.
In environments where the iSNS server is integrated with a DNS infrastructure, the Entity Identifier may be used to store the Fully Qualified Domain Name (FQDN) of the iSCSI or iFCP device. FQDNs of greater than 255 bytes MUST NOT be used.
If FQDNs are not used, the iSNS server can be used to generate EIDs. EIDs generated by the iSNS server MUST begin with the string "isns:". iSNS clients MUST NOT generate and register EIDs beginning with the string "isns:".
If FQDNs are not used, the iSNS server can be used to generate EIDs. EIDs generated by the iSNS server MUST begin with the string "isns:". iSNS clients MUST NOT generate and register EIDs beginning with the string "isns:".
This field MUST be normalized according to the nameprep template [NAMEPREP] before it is stored in the iSNS database.
This field MUST be normalized according to the nameprep template [NAMEPREP] before it is stored in the iSNS database.
6.2.2. Entity Protocol
6.2.2. Entity Protocol
The Entity Protocol is a required 4-byte integer attribute that indicates the block storage protocol used by the registered NETWORK ENTITY. Values used for this attribute are assigned and maintained by IANA. The initial set of protocols supported by iSNS is as follows:
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:
Tseng, et al. Standards Track [Page 76] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Tseng, et al. Standards Track [Page 76] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Value Entity Protocol Type
----- --------------------
1 No Protocol
2 iSCSI
3 iFCP
All others To be assigned by IANA
Value Entity Protocol Type ----- -------------------- 1 No Protocol 2 iSCSI 3 iFCP All others To be assigned by IANA
'No Protocol' is used to indicate that the Network Entity does not support an IP block storage protocol. A Control Node or monitoring Node would likely (but not necessarily) use this value.
'No Protocol' is used to indicate that the Network Entity does not support an IP block storage protocol. A Control Node or monitoring Node would likely (but not necessarily) use this value.
This attribute is required during initial registration of the Network Entity.
This attribute is required during initial registration of the Network Entity.
6.2.3. Management IP Address
6.2.3. Management IP Address
This field contains the IP Address that may be used to manage the Network Entity and all Storage Nodes contained therein via the iSNS MIB [iSNSMIB]. Some implementations may also use this IP address to support vendor-specific proprietary management protocols. The Management IP Address is a 16-byte field that may contain an IPv4 or IPv6 address. When this field contains an IPv4 value, it is stored as an IPv4-mapped IPv6 address. That is, the most significant 10 bytes are set to 0x00, with the next two bytes set to 0xFFFF [RFC2373]. When this field contains an IPv6 value, the entire 16- byte field is used. If this field is not set, then in-band management through the IP address of one of the Portals of the Network Entity is assumed.
This field contains the IP Address that may be used to manage the Network Entity and all Storage Nodes contained therein via the iSNS MIB [iSNSMIB]. Some implementations may also use this IP address to support vendor-specific proprietary management protocols. The Management IP Address is a 16-byte field that may contain an IPv4 or IPv6 address. When this field contains an IPv4 value, it is stored as an IPv4-mapped IPv6 address. That is, the most significant 10 bytes are set to 0x00, with the next two bytes set to 0xFFFF [RFC2373]. When this field contains an IPv6 value, the entire 16- byte field is used. If this field is not set, then in-band management through the IP address of one of the Portals of the Network Entity is assumed.
6.2.4. Entity Registration Timestamp
6.2.4. Entity Registration Timestamp
This field indicates the most recent time when the Network Entity registration occurred or when an associated object attribute was updated or queried by the iSNS client registering the Network Entity. The time format is, in seconds, the update period since the standard base time of 00:00:00 GMT on January 1, 1970. This field cannot be explicitly registered. This timestamp TLV format is also used in the SCN and ESI messages.
This field indicates the most recent time when the Network Entity registration occurred or when an associated object attribute was updated or queried by the iSNS client registering the Network Entity. The time format is, in seconds, the update period since the standard base time of 00:00:00 GMT on January 1, 1970. This field cannot be explicitly registered. This timestamp TLV format is also used in the SCN and ESI messages.
6.2.5. Protocol Version Range
6.2.5. Protocol Version Range
This field contains the minimum and maximum version of the block storage protocol supported by the Network Entity. The most significant two bytes contain the maximum version supported, and the least significant two bytes contain the minimum version supported. If a range is not registered, then the Network Entity is assumed to
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
Tseng, et al. Standards Track [Page 77] RFC 4171 Internet Storage Name Service (iSNS) September 2005
Tseng, et al. Standards Track [Page 77] RFC 4171 Internet Storage Name Service (iSNS) September 2005
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.
support all versions of the protocol. The value 0xffff is a wildcard that indicates no minimum or maximum. If the Network Entity does not support a protocol, then this field SHALL be set to 0.
6.2.6. Registration Period
6.2.6. Registration Period
This 4-byte unsigned integer field indicates the maximum period, in seconds, that the registration SHALL be maintained by the server without receipt of an iSNS message from the iSNS client that registered the Network Entity. Entities that are not registered for ESI monitoring MUST have a non-zero Registration Period. If a Registration Period is not requested by the iSNS client and Entity Status Inquiry (ESI) messages are not enabled for that client, then the Registration Period SHALL be set to a non-zero value by the iSNS server. This implementation-specific value for the Registration Period SHALL be returned in the registration response to the iSNS client. The Registration Period may be set to zero, indicating its non-use, only if ESI messages are enabled for that Network Entity.
This 4-byte unsigned integer field indicates the maximum period, in seconds, that the registration SHALL be maintained by the server without receipt of an iSNS message from the iSNS client that registered the Network Entity. Entities that are not registered for ESI monitoring MUST have a non-zero Registration Period. If a Registration Period is not requested by the iSNS client and Entity Status Inquiry (ESI) messages are not enabled for that client, then the Registration Period SHALL be set to a non-zero value by the iSNS server. This implementation-specific value for the Registration Period SHALL be returned in the registration response to the iSNS client. The Registration Period may be set to zero, indicating its non-use, only if ESI messages are enabled for that Network Entity.
The registration SHALL be removed from the iSNS database if an iSNS Protocol message is not received from the iSNS client before the registration period has expired. Receipt of any iSNS Protocol message from the iSNS client automatically refreshes the Entity Registration Period and Entity Registration Timestamp. To prevent a registration from expiring, the iSNS client should send an iSNS Protocol message to the iSNS server at intervals shorter than the registration period. Such a message can be as simple as a query for one of its own attributes, using its associated iSCSI Name or FC Port Name WWPN as the Source attribute.
The registration SHALL be removed from the iSNS database if an iSNS Protocol message is not received from the iSNS client before the registration period has expired. Receipt of any iSNS Protocol message from the iSNS client automatically refreshes the Entity Registration Period and Entity Registration Timestamp. To prevent a registration from expiring, the iSNS client should send an iSNS Protocol message to the iSNS server at intervals shorter than the registration period. Such a message can be as simple as a query for one of its own attributes, using its associated iSCSI Name or FC Port Name WWPN as the Source attribute.
For an iSNS client that is supporting a Network Entity with multiple Storage Node objects, receipt of an iSNS message from any Storage Node of that Network Entity is sufficient to refresh the registration for all Storage Node objects of the Network Entity.
複数のStorage NodeオブジェクトでNetwork EntityをサポートしているiSNSクライアントでは、そのNetwork EntityのどんなStorage NodeからのiSNSメッセージの領収書も、Network EntityのすべてのStorage Nodeオブジェクトのための登録をリフレッシュするために十分です。
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サポートが部分として要求されるなら、Portal登録、iSNSサーバによってiSNSクライアントから受け取られたESI Responseメッセージでは、SHALLは登録をリフレッシュします。
6.2.7. Entity Index
6.2.7. 実体インデックス
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
Entity Indexは唯一iSNSサーバで登録された各Network Entityを特定する未署名の非ゼロ整数価値です。Network Entityの新規登録のときに、iSNSサーバはEntity Indexのために未使用の値を割り当てます。 そうしないEntity IndexのためにiSNSデータベースの各Network Entityに値を割り当てなければなりません。
Tseng, et al. Standards Track [Page 78] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[78ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
assigned to any other Network Entity. Furthermore, Entity Index values for recently deregistered Network Entities SHOULD NOT be reused in the short term.
いかなる他のNetwork Entityにも割り当てられます。 その上、Entity Indexは再利用されたコネが短期間であったなら最近のためにderegistered Network Entities SHOULD NOTを評価します。
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.
Entity Indexは、Entity Identifierが長過ぎるか、またはそうでなければ、不適当であるときに、状況でNetwork Entityを表すのに使用されるかもしれません。 この例はSNMPが管理にセクション2.10で説明されるように使用される時です。
6.2.8. Entity Next Index
6.2.8. 次の実体は索引をつけます。
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.
これは次の利用可能な(すなわち、未使用の)実体Index価値を示す4バイトの整数値を含む仮想の属性です。 この属性は質問されるだけであるかもしれません。 iSNSサーバSHALLはこの属性のために値を示すのを試みるどんなクライアントにも3(無効のRegistration)のエラーコードを返します。 この属性のために排他的に質問するとき、Message Keyは必要ではありません。
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は、iSNSサーバにおけるエントリーを作成するのにSNMPクライアントによって使用されるかもしれません。SNMP要件はセクション2.10で説明されます。
6.2.9. Entity ISAKMP Phase-1 Proposals
6.2.9. 実体ISAKMPフェーズ-1提案
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 Phase-1提案を含んでいます、減少しているよく使われる順にNetwork Entityによって送られて、受け取られたすべてのIKE Phase-2メッセージを保護するのにおいて許容できる保護スイートを記載して。 これは同輩iFCP、そして/または、iSCSIデバイスに関してiSNSクライアントからまた、iSNSサーバまでのPhase-2 SAsを含んでいます。 この属性は[RFC2408]で定義されたISAKMP書式にSAペイロード、提案ペイロード、および変換ペイロードを含んでいます。
This field should be used if the implementer wishes to define a single phase-1 SA security configuration used to protect all phase-2 IKE traffic. If the implementer desires to have a different phase-1 SA security configuration to protect each Portal interface, then the Portal Phase-1 Proposal (Section 6.3.10) should be used.
implementerがすべてのフェーズ-2IKEトラフィックを保護するのに使用される単相-1SAセキュリティ設定を定義したいなら、この分野は使用されるべきです。 implementerが、それぞれのPortalインタフェースを保護するために異なったフェーズ-1SAセキュリティ設定を持っていることを望んでいるなら、Portal Phase-1 Proposal(セクション6.3.10)は使用されるべきです。
6.2.10. Entity Certificate
6.2.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
この属性はNetwork Entityに縛られる1通以上のX.509証明書を含んでいます。 この証明書は、他のクライアントが自分たちを認証して、そのNetwork Entityによって提供されたサービスにアクセスするのを許したがっているクライアントによって、iSNSサーバにアップロードされて、登録されます。 X.509証明書の形式は[RFC3280]で見つけられます。 この証明書は、空の系列があるSubject Nameを含まなければならなくて、コード化されたSubjectAltName拡張子を含まなければなりません。
Tseng, et al. Standards Track [Page 79] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[79ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
with the dNSName type. The Entity Identifier (Section 6.2.1) of the identified Entity MUST be stored in the SubjectAltName field of the certificate.
dNSNameと共にタイプしてください。 証明書のSubjectAltName分野に特定されたEntityのEntity Identifier(セクション6.2.1)を保存しなければなりません。
6.3. Portal-Keyed Attributes
6.3. 入り口で合わせられた属性
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.
以下のPortal属性は、iSNSデータベースにキーとして結合したPortal IP-アドレスとPortal TCP/UDP Portを使用することで示されます。 それぞれのPortalは1個のEntity Identifierオブジェクトキーに関連しています。
6.3.1. Portal IP Address
6.3.1. 入り口のIPアドレス
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.
この属性はStorage Nodeがストレージデータを送受信できるPortalのIPアドレスです。 Portal IP AddressはIPv4かIPv6アドレスを含むかもしれない16バイトの分野です。 この分野がIPv4アドレスを含むとき、IPv4がIPv6アドレスを写像したので、それは保存されます。 すなわち、最も重要な10バイトは0xFFFFに設定された次の2バイトで0×00に設定されます[RFC2373]。 この分野がIPv6アドレスを含むとき、全体の16バイトの分野は使用されています。 Portal IP AddressとPortal TCP/UDP Port番号、(見る、6.3、.2、下) キーとして、唯一Portalを特定するために、使用されます。 それはPortalの登録のための必要な属性です。
6.3.2. Portal TCP/UDP Port
6.3.2. 入り口のTCP/UDP港
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.
Storage Nodeがストレージデータを送受信できるPortalの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であるなら、ポートナンバーは、関連Entity Typeによって示されたプロトコルの暗示している正準なポートナンバーとタイプです。
The Portal IP Address and the Portal TCP/UDP Port number are used as a key to identify a Portal uniquely. It is a required attribute for registration of a Portal.
Portal IP AddressとPortal TCP/UDP Port番号は、唯一Portalを特定するのにキーとして使用されます。 それはPortalの登録のための必要な属性です。
6.3.3. Portal Symbolic Name
6.3.3. 入り口のシンボリックな名
A variable-length UTF-8 encoded NULL-terminated text-based description of up to 256 bytes. The Portal Symbolic Name is a user- readable description of the Portal entry in the iSNS server.
可変長のUTF-8は最大256バイトのNULLによって終えられたテキストベースの記述をコード化しました。 Portal Symbolic NameはiSNSサーバで、Portalエントリーのユーザの読み込み可能な記述です。
Tseng, et al. Standards Track [Page 80] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[80ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
6.3.4. Entity Status Inquiry Interval
6.3.4. 実体資産調査間隔
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サーバからこのNetwork Entityに送られたEntity Status Inquiry(ESI)メッセージの間で。 Portal登録がずっと有効であることを確かめるのにESIメッセージを使用できます。 iSNSサーバによるモニターを要求するために、iSNSクライアントはこのPortal属性のためにDevAttrRegメッセージを使用することで非ゼロ値を示します。 クライアントは、ESIモニターを受けるために少なくともPortalsの1つのESI Portを登録しなければなりません。
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メッセージへの予想された応答を受けないで、それはSHALL試みです。ESIメッセージの行政上構成された数の再送信。 ESI Intervalの期間はiSNSサーバの最後のESI Responseの領収書で始まります。 ESI Intervalの期間の2倍が通る前にすべての再トランスミッションを送らなければなりません。 いいえなら次に、ESIメッセージのどれか、Portal SHALLから応答を受けます。反登録します。 このように彼らのESI Port分野に値を示したPortalsしか反登録できないことに注意してください。
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メッセージに登録したNetwork Entityに関連しているすべてのPortalsが反登録されるなら、非応答、少なくとも2回のESI Intervalの期間、クライアントから登録証明書を全く受けていないか、そして、次に、Network Entity、およびすべての関連オブジェクト(Storage Nodesを含んでいる)SHALLが反登録されますか?
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.
ESIメッセージかESI Intervalが要求したサポートにiSNSサーバであることができなく、それがSHALLどちらかの廃棄物帰りによるESI要求「利用可能でないESI」Status Codeであるかそれ自身の適当な値を選択することによってESI Interval属性を変更して、それを返すのが、登録応答メッセージのOperating Attributesの値であるなら。
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メッセージをPortalsのいずれにも受け取っていないなら、クライアントは、キーとしてEntity_IDを使用することでDevAttrQryメッセージを使用することでiSNSサーバについて質問するのを試みるかもしれません。 そして誤りが質問結果であるなら「そのようなエントリーでない」であるので、クライアントSHALLは、すべての残っているTCP接続をiSNSサーバに終えて、それがもうiSNSデータベースに登録されないと思います。 そのようなクライアントは再登録を試みるかもしれません。
Tseng, et al. Standards Track [Page 81] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[81ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
6.3.5. ESI Port
6.3.5. ESIポート
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.
この分野はポートがPortalでiSNSサーバでIP Addressをモニターする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ポートナンバーを示すなら、クライアントSHALLは示されたTCPかUDPポートに受け取られるべきメッセージをESIに許容します。 TCPポートが登録されていて、そのTCPポートからiSNSサーバまでのプレ既存のTCP接続が既に存在していないなら、iSNSクライアントSHALLは示されたTCPポートのiSNSサーバから新しいTCP接続を受け入れます。
The iSNS server SHALL return an error if a Network Entity is registered for ESI monitoring and none of the Portals of that Network Entity has an entry for the ESI Port field. If multiple Portals have a registered ESI port, then the ESI message may be delivered to any one of the indicated Portals.
Network EntityがESIモニターのために登録されるなら、iSNSサーバSHALLは誤りを返します、そして、そのNetwork EntityのPortalsのいずれにはも、ESI Port分野のためのエントリーがありません。 複数のPortalsに登録されたESIポートがあるなら、ESIメッセージは示されたPortalsのいずれにも提供されるかもしれません。
6.3.6. Portal Index
6.3.6. 入り口のインデックス
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.
Portal Indexは唯一iSNSデータベースに登録された各Portalを特定する4バイトの非ゼロ整数価値です。 Portalの新規登録のときに、iSNSサーバはそのPortalのPortal Indexのために未使用の値を割り当てます。 いかなる他のPortalにも割り当てられないPortal IndexのためにiSNSデータベースの各Portalに値を割り当てなければなりません。 その上、Portal Indexは再利用されたコネが短期間であったなら最近のためにderegistered Portals SHOULD NOTを評価します。
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.
Portal Indexは、Portal IP-アドレスとPortal TCP/UDP Portが使用するために扱いにくい状況で登録されたPortalを表すのに使用されるかもしれません。 この例はSNMPが管理にセクション2.10で説明されるように使用される時です。
6.3.7. SCN Port
6.3.7. SCNポート
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サーバからSCNメッセージを受け取るのにiSNSクライアントで使用したTCPかUDPを保管しています。この属性のために値を示すとき、PortalによってサポートされたStorage Nodesのいずれのためにも示されたポートの上にSCNメッセージを受け取るかもしれません。 ビット16〜31はポートナンバーを含んでいます。 ビット15が設定されるなら、ポートタイプはUDPです。 さもなければ、ポートタイプはTCPです。 ビット0〜14は予約されています。
If the iSNS client registers a valid TCP or UDP port number in this field, then the client SHALL allow SCN messages to be received at the indicated TCP or UDP port. If a TCP port is registered and a pre-
iSNSクライアントがこの分野に有効なTCPかUDPポートナンバーを示すなら、クライアントSHALLは示されたTCPかUDPポートに受け取られるべきメッセージをSCNに許容します。 TCPポートが登録されているか、そして、a、プレ
Tseng, et al. Standards Track [Page 82] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[82ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
existing TCP connection from that TCP port to the iSNS server does not already exist, then the iSNS client SHALL accept new TCP connections from the iSNS server at the indicated TCP port.
そのTCPポートからiSNSサーバまでの既存のTCP接続は既に存在していなくて、次に、iSNSクライアントSHALLは示されたTCPポートのiSNSサーバから新しいTCP接続を受け入れます。
The iSNS server SHALL return an error if an SCN registration message is received and none of the Portals of the Network Entity has an entry for the SCN Port. If multiple Portals have a registered SCN Port, then the SCN SHALL be delivered to any one of the indicated Portals of that Network Entity.
SCN登録メッセージが受信されていて、Network EntityのPortalsのいずれにもSCN Portのためのエントリーがないなら、iSNSサーバSHALLは誤りを返します。 複数のPortalsであるなら、登録されたSCN Port、当時のSCN SHALLはそのNetwork Entityの示されたPortalsのどれかに提供されましたか?
6.3.8. Portal Next Index
6.3.8. 次の入り口は索引をつけます。
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.
これは次の利用可能な(すなわち、未使用の)入り口のIndex価値を示す4バイトの整数値を含む仮想の属性です。 この属性は質問されるだけであるかもしれません。 iSNSサーバSHALLはこの属性のために値を示すのを試みるどんなクライアントにも3(無効のRegistration)のエラーコードを返します。 この属性のために排他的に質問するとき、Message Keyは必要ではありません。
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は、iSNSサーバにおけるエントリーを作成するのにSNMPクライアントによって使用されるかもしれません。SNMP要件はセクション2.10で説明されます。
6.3.9. Portal Security Bitmap
6.3.9. 入り口のセキュリティビットマップ
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バイトの分野はPortalのためにセキュリティー属性設定を示す旗を含んでいます。 この分野のビット31(Lsb)は、この分野が重要な情報を含むためには1でなければなりません(可能にされます)。 Bit31が有効にされるなら、これは、iSNSクライアント(すなわち、iSCSIデバイス)のために安全保障政策と設定を保存して、分配するのにiSNSサーバを使用できるのを意味します。 ビット30は、ビット25-29が重要な情報を含むためには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
ビット位置旗の記述------------ ---------------- 25 1 トンネル・モードが好んだ=。 0 = いいえ好み26の1は好まれた交通機関と等しいです。 0 = いいえ好み27の1は(PFS)が可能にした完全な前進の秘密保持と等しいです。 0 = PFSは攻撃的な1=モードが可能にした28を無効にしました。 0 =は主な1=モードが可能にした29を無効にしました。 0 = mmは1=IKE/IPSecが可能にした30を無効にしました。 0 = IKE/IPSecは有効な状態で1つの31(Lsb)=ビットマップを無効にしました。 すべての他のものが予約した0=病人
Tseng, et al. Standards Track [Page 83] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[83ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
6.3.10. Portal ISAKMP Phase-1 Proposals
6.3.10. 入り口のISAKMPフェーズ-1提案
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].
この分野はPortalによって送られて、受け取られたすべてのIKE Phase-2メッセージを保護するのにおいて許容できる保護スイートの減少しているよく使われる順に記載するIKE Phase-1提案を含んでいます。 これは同輩iFCP、そして/または、iSCSIデバイスに関してiSNSクライアントからまた、iSNSサーバまでのPhase-2 SAsを含んでいます。 この属性は[RFC2408]で定義されたISAKMP書式にSAペイロード、提案ペイロード、および変換ペイロードを含んでいます。
This field should be used if the implementer wishes to define phase-1 SA security configuration on a per-Portal basis, as opposed to on a per-Network Entity basis. If the implementer desires to have a single phase-1 SA security configuration to protect all phase-2 traffic regardless of the interface used, then the Entity Phase-1 Proposal (Section 6.2.9) should be used.
implementerが1入り口あたり1個のベース(オンと対照的に1ネットワークあたり1つのEntity基礎)でフェーズ-1SAセキュリティ設定を定義したいなら、この分野は使用されるべきです。 implementerが、インタフェースにかかわらずトラフィックが使用したすべてのフェーズ-2を保護するために単相-1SAセキュリティ設定を持っていることを望んでいるなら、Entity Phase-1 Proposal(セクション6.2.9)は使用されるべきです。
6.3.11. Portal ISAKMP Phase-2 Proposals
6.3.11. 入り口のISAKMPフェーズ-2提案
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 Phase-2提案を含んでいます、ISAKMP形式[RFC2408]で、減少しているよく使われる順にPortalによって送られて、受け取られたトラフィックを保護するのにおいて許容できるセキュリティ提案を記載して。 この分野はビット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].
セキュリティBitmap(6.3に、.9を見る)は有効にされます。 この属性は[RFC2408]で定義されたISAKMP書式にSAペイロード、提案ペイロード、および関連変換ペイロードを含んでいます。
6.3.12. Portal Certificate
6.3.12. 入り口の証明書
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.
この属性はPortalの資格証明書である1通以上のX.509証明書を含んでいます。 この証明書は、IPアドレスとPortalによってサポートされたTCP/UDP Portにコミュニケーションを特定して、認証するのに使用されます。 X.509証明書の形式は[RFC3280]で指定されます。 この証明書は、空の系列があるSubject Nameを含まなければならなくて、iPAddressタイプでコード化されたSubjectAltName拡張子を含まなければなりません。 Portal IP Address、(セクション6.3.1) 特定されたPortal SHALLでは、証明書のSubjectAltName分野に保存されてください。
6.4. iSCSI Node-Keyed Attributes
6.4. iSCSIは属性をノードで合わせました。
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.
以下の属性は、iSNSデータベースにキーとしてiSCSI Name属性を使用することで保存されます。 それぞれのセットのNodeによって合わせられた属性は1個のEntity Identifierオブジェクトキーに関連しています。
Although the iSCSI Name key is associated with one Entity Identifier, it is unique across the entire iSNS database.
iSCSI Nameキーは1Entity Identifierに関連していますが、それは全体のiSNSデータベースの向こう側にユニークです。
Tseng, et al. Standards Track [Page 84] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[84ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
6.4.1. iSCSI Name
6.4.1. iSCSI名
This is a variable-length UTF-8 encoded NULL-terminated text-based description of up to 224 bytes. This key attribute is required for iSCSI Storage Nodes and is provided by the iSNS client. The registered iSCSI Name MUST conform to the format described in [iSCSI] for iSCSI Names. The maximum size for an iSCSI Name is 223 bytes. Including the NULL character and 4-byte alignment (see Section 5.3.1), the maximum iSCSI Name field size is 224 bytes.
これによる可変長のUTF-8が最大224バイトのNULLによって終えられたテキストベースの記述をコード化したということです。 この主要な属性は、iSCSI Storage Nodesに必要であり、iSNSクライアントによって提供されます。 登録されたiSCSI NameはiSCSI Namesのために[iSCSI]で説明された形式に従わなければなりません。 iSCSI Nameのための最大サイズは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.
iSCSI Nameであるなら、登録されてEIDキーなしで、当時のaはNetwork Entity SHALLです。作成されていてEIDになってください割り当てられて。 EID SHALLが割り当てられて、操作属性として登録応答で返してください。
This field MUST be normalized according to the stringprep template [STRINGPREP] before it is stored in the iSNS database.
それがiSNSデータベースに保存される前にstringprepテンプレート[STRINGPREP]に従って、この分野を正常にしなければなりません。
6.4.2. iSCSI Node Type
6.4.2. iSCSIノード種別
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 Storage Nodeのタイプを示すビットマップです。 ビット位置は以下で定義されます。 セット・ビット(1)は、Nodeには対応する特性があるのを示します。
Bit Position Node Type
------------ ---------
29 Control
30 Initiator
31 (Lsb) Target
All others RESERVED
ビット位置ノード種別------------ --------- 29 すべての他のものが予約したコントロール30創始者31(Lsb)目標
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.
Targetビットが1に設定されるなら、NodeはiSCSI目標を表します。 Targetビットは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.
Initiatorビットが1に設定されるなら、NodeはiSCSI創始者の代理をします。 Initiatorビットは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に設定されるなら、Nodeはゲートウェイを表します、管理局、バックアップiSNSサーバ、または、創始者か目標ではなく、それである別のデバイスがiSNSPメッセージを送って、受け取る能力を必要とします、州の変更届出書を含んでいて。 コントロールビットを設定するのは、iSNSサーバに実行しなければならない管理業務です。 iSNSクライアントSHALL NOT、iSNSPを使用することでこのビットを変えさせてください。
Tseng, et al. Standards Track [Page 85] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[85ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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機能にアクセスするのに許容の中で区別するiSNSサーバによって異なったiSCSI Nodeタイプによって使用されるかもしれません。 1Node Typeビット以上は同時に、可能にされるかもしれません。
6.4.3. iSCSI Node Alias
6.4.3. iSCSI Nodeアリア
This is a variable-length UTF-8 encoded NULL-terminated text-based description of up to 256 bytes. The Alias is a user-readable description of the Node entry in the iSNS database.
これによる可変長のUTF-8が最大256バイトのNULLによって終えられたテキストベースの記述をコード化したということです。 アリア一家はiSNSデータベースで、Nodeエントリーのユーザ読み込み可能な記述です。
6.4.4. iSCSI Node SCN Bitmap
6.4.4. iSCSIノードSCNビットマップ
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 Node SCN Bitmapは登録しているiSNSクライアントが通知メッセージを受け取りたがっているイベントを示します。 以下のテーブルは通知をもたらすイベント、およびSCN Bitmapの可能にされると対応する通知をもたらす噛み付いている野原を表示します。
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
ビット位置旗の記述------------ ---------------- 24INITIATOR AND SELF INFORMATION ONLY25TARGET AND SELF INFORMATION ONLY26MANAGEMENT REGISTRATION/SCN27OBJECT REMOVED28OBJECT ADDED29OBJECT UPDATED30DD/DDS MEMBER REMOVED(管理レッジ/SCN専用)31(Lsb)DD/DDS MEMBER ADDED(管理レッジ/SCN専用)はすべて、他のもの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は、ディスカバリーDomain、そして/または、ディスカバリーDomain Setの既存のメンバーが免職されたのを示します。
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は、Network Entity(オブジェクトが取り除かれたPortal、Storage Node、FC Device、DD、そして/または、DDS)が(コントロールNodes専用)を加えたか、またはディスカバリーDomainかiSNSデータベースでアップデートしたのを示します。
Tseng, et al. Standards Track [Page 86] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[86ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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.
通常のSCNsはそれがアップデートされるオブジェクトの情報を提供します、Storage Nodeがメンバーである加えられたかディスカバリーから取り外されたDomains。 MANAGEMENT REGISTRATION/SCN旗がきれいにされるなら、SCNかSCN登録が通常のSCNか定期的なSCN登録であると考えられます。 すべてのiSNSクライアントが通常のSCNsに登録するかもしれません。
Management SCNs provide information about all changes to the network, regardless of discovery domain membership. Registration for management SCNs is indicated by setting bit 26 to 1. Only Control Nodes may register for management SCNs. Bits 30 and 31 may only be enabled if bit 26 is set to 1.
管理SCNsは発見ドメイン会員資格にかかわらずネットワークへのすべての変化の情報を提供します。 管理SCNsのための登録は26〜1に噛み付かれた設定によって示されます。 Control Nodesだけが管理SCNsに登録するかもしれません。 ビット26が1に設定される場合にだけ、ビット30と31は可能にされるかもしれません。
TARGET AND SELF INFORMATION ONLY SCNs (bit 25) provides information only about changes to target devices, or if the iSCSI Storage Node itself has undergone a change. Similarly, INITIATOR AND SELF INFORMATION ONLY SCNs (bit 24) provides information only about changes to initiator Nodes, or to the target itself.
TARGET AND SELF INFORMATION ONLY SCNs(ビット25)は対象装置かそれともiSCSI Storage Node自身が推移したかどうかへの変化だけの情報を提供します。 同様に、INITIATOR AND SELF INFORMATION ONLY SCNs(ビット24)は創始者Nodes、または、目標自体への変化だけの情報を提供します。
6.4.5. iSCSI Node Index
6.4.5. iSCSIノードインデックス
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 Node Indexは唯一各iSCSI Storage Nodeを特定するキーがiSNSデータベースに登録されたので使用される4バイトの非ゼロ整数価値です。 iSCSI Storage Nodeの新規登録のときに、iSNSサーバはiSCSI Node Indexのために未使用の値を割り当てます。 いかなる他のiSCSI Storage Nodeにも割り当てられないiSCSI Node Indexのために各iSCSI Nodeに値を割り当てなければなりません。 その上、iSCSI Node Indexは再利用されたコネが短期間であったなら最近のためにderegistered iSCSI Storage Nodes SHOULD NOTを評価します。
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 Node Indexは、iSCSI Nameがキーとして使用できないくらい長い状況で登録されたNodeを表すのにキーとして使用されるかもしれません。 この例はSNMPが管理にセクション2.10で説明されるように使用される時です。
The value assigned for the iSCSI Node Index SHALL persist as long as the iSCSI Storage Node is registered in the iSNS database or a member of a Discovery Domain. An iSCSI Node Index value that is assigned for a Storage Node SHALL NOT be used for any other Storage Node as long as the original node is registered in the iSNS database or a member of a Discovery Domain.
iSCSI Node Index SHALLがiSCSI Storage Nodeと同じくらい長い間固執しているので、割り当てられた値はiSNSデータベースかディスカバリーDomainのメンバーに示されます。 iSCSI Node Index値、すなわち、Storage Node SHALL NOTのために割り当てられて、オリジナルのノードがiSNSデータベースかディスカバリーDomainのメンバーに登録される限り、いかなる他のStorage Nodeにも使用されてください。
6.4.6. WWNN Token
6.4.6. WWNNトークン
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].
この分野はFibre Channel骨組みにiSCSIデバイスのWorld Wide Node Nameを表すのに使用できるグローバルにユニークな64ビットの整数値を含んでいます。 この識別子は、デバイス登録手続の間、使用されて、[FC-FS]の要件に従わなければなりません。
Tseng, et al. Standards Track [Page 87] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[87ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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ゲートウェイはFibre ChannelネームサーバでiSCSIデバイスを登録するためにこの野原で発見される値を使用します。それは、「プロキシ」WWNN値がiSCSI創始者に割り当てられるときの闘争がFC骨組みのデバイスにストレージセッションを確立するのを防ぐためにiSNSサーバで保存されます。
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 Tokenのために値を割り当てないなら、iSNSサーバSHALLはiSCSI Storage Nodeの新規登録のこの分野に値を提供します。 WWNN Tokenが割り当てられるプロセスは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 Token値は既存の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 Token値と登録されたiSCSI Nameの間のマッピングを持続して保存しなければなりません。 すなわち、iSCSI NameがiSNSでオリジナルのマッピングであることを関連WWNN Token値に支持する同じくらいによって合わせられたiSCSI Storage Nodeの連続した再登録証明書サーバ同様である、SHALLを写像して、iSNSサーバリブートの向こう側に永続的であってください。 一度割り当てられます、認可されたiSNSクライアントからのDevAttrRegメッセージが明らかに異なったWWNN Token値を提供する場合にだけ、マッピングを変えることができます。
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 Token値のSHALL NOTはいかなる他のiSCSI名にもWWNN Token値が、一度、iSCSI名に割り当てられて、写像されたことがあって、再利用されるか、または写像されます。
4. The assigned WWNN Token value MUST conform to the formatting
requirements of [FC-FS] for World Wide Names (WWNs).
4. 割り当てられたWWNN Token値はWorld Wide Names(WWNs)のための[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クライアントは、それ自身のWWNN Token値を示すか、またはiSNS Serverの供給されたWWNN Token価値を上書きするかもしれません、それ自身のiSCSI-FC名前マッピングを提供したいなら。 これは操作属性としてWWNN Token(タグ=37)があるDevAttrRegメッセージを使用するのに優れています。 いったん上書きされると、iSNSサーバで新しいWWNN Token値を保存されて、節約しなければなりません、そして、上で指定されたすべての要件が適用し続けています。 iSNSクライアント試みであるなら、このiSNSデータベースでユニークでないか、またはそうでなければ無効の分野、次に、登録SHALLのために値を示すには、3(無効のRegistration)のStatus Codeと共に拒絶されてください。
Tseng, et al. Standards Track [Page 88] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[88ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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.
WWNN Tokenによって指定されたFibre ChannelデバイスのためのiSNSデータベースには合っている記録があるかもしれません。 これらの記録はFibre Channel骨組みのネームサーバで登録されたそのFCデバイスのためのデバイス属性を含むかもしれません。
6.4.7. iSCSI Node Next Index
6.4.7. 次のiSCSIノードは索引をつけます。
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 Node Index値を示す4バイトの整数値を含む仮想の属性です。 この属性は質問されるだけであるかもしれません。 iSNSサーバSHALLはこの属性のために値を示すのを試みるどんなクライアントにも3(無効のRegistration)のエラーコードを返します。 この属性のために排他的に質問するとき、Message Keyは必要ではありません。
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.
iSCSI Node Next Indexは、iSNSサーバにおけるエントリーを作成するのにSNMPクライアントによって使用されるかもしれません。SNMP要件はセクション2.10で説明されます。
6.4.8. iSCSI AuthMethod
6.4.8. iSCSI AuthMethod
This attribute contains a NULL-terminated string of UTF-8 text listing the iSCSI authentication methods enabled for this iSCSI Storage Node, in order of preference. The text values used to identify iSCSI authentication methods are embedded in this string attribute and delineated by a comma. The text values are identical to those found in the main iSCSI document [iSCSI]; additional vendor-specific text values are also possible.
この属性はこのiSCSI Storage Nodeのために可能にされた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
テキスト値の記述参照---------- ----------- --------- KB5ケルベロスV5[RFC1510]SPKM1 Simple Public Key GSS-API[RFC2025]SPKM2 Simple Public Key GSS-API[RFC2025]SRP Secure Remote Password[RFC2945]CHAP Challenge Handshakeプロトコル[RFC1994]、なにも、iSCSI Authenticationがありません。
6.5. Portal Group (PG) Object-Keyed Attributes
6.5. 入り口のグループの(未成年者不適当映画)オブジェクトで合わせられた属性
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].
以下の属性は、PortalとiSCSI Storage Nodeオブジェクトを関連づけるのに使用されます。 未成年者不適当映画オブジェクトは、iSNSデータベースにキーとして未成年者不適当映画iSCSI Name、未成年者不適当映画Portal IP Address、および未成年者不適当映画Portal TCP/UDP Portを使用することで保存されます。 新しい未成年者不適当映画オブジェクトは対応するPortal、そして/または、iSCSI Storage Nodeオブジェクトが登録されていることの時にそれとなくか明らかに作成されます。 セクション3.4は未成年者不適当映画用法の一般的な議論をします。 さらに詳しい明細についてはPortal Groupsの使用のときに、[iSCSI]を見てください。
Tseng, et al. Standards Track [Page 89] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[89ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
6.5.1. Portal Group iSCSI Name
6.5.1. 入り口のグループ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.
これは未成年者不適当映画オブジェクトに関連しているiSCSI Storage NodeのためのiSCSI Nameです。 この名前は現在サーバで登録されていないiSCSI Storage Nodeを表すかもしれません。
6.5.2. PG Portal IP Addr
6.5.2. 未成年者不適当映画入り口のIP Addr
This is the Portal IP Address attribute for the Portal that is associated with the PG object. This Portal IP Address MAY be that of a Portal that is not currently registered in the server.
これは未成年者不適当映画オブジェクトに関連しているPortalのためのPortal IP Address属性です。 このPortal IP Addressは現在サーバで登録されないPortalのものであるかもしれません。
6.5.3. PG Portal TCP/UDP Port
6.5.3. 未成年者不適当映画入り口のTCP/UDP港
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.
これは未成年者不適当映画オブジェクトに関連しているPortalのためのPortal TCP/UDP Port属性です。 このPortal TCP/UDP Portは現在サーバで登録されないPortalのものであるかもしれません。
6.5.4. Portal Group Tag (PGT)
6.5.4. 入り口のグループタグ(PGT)
This field is used to group Portals in order to coordinate connections in a session across Portals to a specified iSCSI Node. The PGT is a value in the range of 0-65535, or NULL. A NULL PGT value is registered by using 0 for the length in the TLV during registration. The two least significant bytes of the value contain the PGT for the object. The two most significant bytes are reserved. If a PGT value is not explicitly registered for an iSCSI Storage Node and Portal pair, then the PGT value SHALL be implicitly registered as 0x00000001.
この分野は、Portalsの向こう側に指定されたiSCSI Nodeにセッションにおける接続を調整するためにPortalsを分類するのに使用されます。 PGTは0-65535、またはNULLの範囲の値です。 NULL PGT値は、長さに登録の間、TLVで0を使用することによって、示されます。 価値の最も重要でない2バイトはオブジェクトのためのPGTを含んでいます。 最も重要な2バイトは予約されています。 PGT値がiSCSI Storage NodeとPortal組のために明らかに示されないなら、0×00000001として登録されて、PGT値のSHALLはそれとなくそうです。
6.5.5. Portal Group Index
6.5.5. 入り口のグループインデックス
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.
未成年者不適当映画Indexは唯一それぞれの未成年者不適当映画オブジェクトを特定するキーがiSNSデータベースに登録されたので使用される4バイトの非ゼロ整数価値です。 未成年者不適当映画オブジェクトの新規登録のときに、iSNSサーバは未成年者不適当映画Indexのために未使用の値を割り当てなければなりません。 その上、未成年者不適当映画Indexは再利用されたコネが短期間であったなら最近反登録された未成年者不適当映画オブジェクトのためにSHOULD NOTを評価します。
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.
未成年者不適当映画Indexは参照のキーとして使用されて、状況におけるそれぞれの未成年者不適当映画オブジェクトのためのユニークなインデックスがそうである登録された未成年者不適当映画が必要であるということであるかもしれません。 また、それは先在の未成年者不適当映画オブジェクトを質問するか、またはアップデートするiSNSメッセージで主要なメッセージとして使用されるかもしれません。 この例はSNMPが管理にセクション2.10で説明されるように使用される時です。 Index SHALLがサーバと同じくらい長い間固持する未成年者不適当映画のために割り当てられた値はアクティブです。
Tseng, et al. Standards Track [Page 90] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[90ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
6.5.6. Portal Group Next Index
6.5.6. 入り口は次のインデックスを分類します。
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.
未成年者不適当映画Next Indexは次の利用可能な(すなわち、未使用の)未成年者不適当映画Index価値を示す4バイトの整数値を含む仮想の属性です。 この属性は質問されるだけであるかもしれません。 iSNSサーバSHALLはこの属性のために値を示すのを試みるどんなクライアントにも3(無効のRegistration)のエラーコードを返します。 この属性のために排他的に質問するとき、Message Keyは必要ではありません。
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.
Portal Group Next Indexは、iSNSサーバにおけるエントリーを作成するのにSNMPクライアントによって使用されるかもしれません。SNMP要件はセクション2.10で説明されます。
6.6. FC Port Name-Keyed Attributes
6.6. FCは名前で合わせられた属性を移植します。
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.
以下の属性は、iSNSデータベースにキーとしてFC Port World Wide Name(WWPN)属性を使用することで示されます。 それぞれのセットのFC Portによって合わせられた属性は1個のEntity Identifierオブジェクトキーに関連しています。
Although the FC Port World Wide Name is associated with one Entity Identifier, it is also globally unique.
FC Port World Wide Nameは1Entity Identifierに関連していますが、また、それもグローバルにユニークです。
6.6.1. FC Port Name (WWPN)
6.6.1. FCポート名(WWPN)
This 64-bit identifier uniquely defines the FC Port, and it is the World Wide Port Name (WWPN) of the corresponding Fibre Channel device. This attribute is the key for the iFCP Storage Node. This globally unique identifier is used during the device registration process, and it uses a value conforming to IEEE EUI-64 [EUI-64].
この64ビットの識別子は唯一FC Portを定義します、そして、それは対応するFibre ChannelデバイスのWorld Wide Port Name(WWPN)です。 この属性はiFCP Storage Nodeのためのキーです。 このグローバルにユニークな識別子はデバイス登録手続の間、使用されます、そして、それはIEEE EUI-64[EUI-64]に従う値を使用します。
6.6.2. Port ID (FC_ID)
6.6.2. IDを移植してください。(FC_ID)
The Port Identifier is a Fibre Channel address identifier assigned to an N_Port or NL_Port during fabric login. The format of the Port Identifier is defined in [FC-FS]. The least significant 3 bytes contain this address identifier. The most significant byte is RESERVED.
Port IdentifierはN_Portに割り当てられたFibre Channelアドレス識別子であるか骨組みの間のNL_Portがログインします。 Port Identifierの書式は[FC-FS]で定義されます。 最も重要でない3バイトはこのアドレス識別子を含んでいます。 最も重要なバイトはRESERVEDです。
Tseng, et al. Standards Track [Page 91] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[91ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
6.6.3. FC Port Type
6.6.3. FCポートタイプ
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
型記述---- ----------- 0×0000 予約された未確認の、または、ヌルのエントリーの繊維チャンネルNL_ポート0×0003繊維0×0001繊維チャンネルN_ポート0×0002チャンネルF/NLのF_ポート0×0082繊維チャンネル_ポート0×0004-0080 0×0081繊維チャンネルフロリダ_ポート0x0083は0×0085 00FFの予約された0xFF11予約された0xFF12 iFCPポート0xFF13-FFFFが予約した0×0084繊維チャンネルE_ポートを予約しました。
6.6.4. Symbolic Port Name
6.6.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 FC Port Name in the network.
これによる可変長のUTF-8がネットワークでiSNSの登録されたFC Port Nameに関連している最大256バイトのNULLによって終えられたテキストベースの記述をコード化したということです。
6.6.5. Fabric Port Name (FWWN)
6.6.5. 骨組みのポート名(FWWN)
This 64-bit identifier uniquely defines the fabric port. If the port of the FC Device is attached to a Fibre Channel fabric port with a registered Port Name, then that fabric Port Name SHALL be indicated in this field.
この64ビットの識別子は唯一骨組みのポートを定義します。 FC Deviceのポートが登録されたPort Nameと共にFibre Channel骨組みのポートに取り付けられるなら、骨組みのPort Name SHALLがこの分野で示されるその時です。
6.6.6. Hard Address
6.6.6. 困難なアドレス
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.
この分野はFibre Channel Arbitrated Loopデバイスとtopologiesとの互換性のためのiSNSPに含まれていた要求された困難なアドレスの24ビットのNL Port Identifierです。 この分野の最も重要でない3バイトはアドレスを含んでいます。 最も重要なバイトはRESERVEDです。
6.6.7. Port IP Address
6.6.7. ポートIPアドレス
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.
Fibre Channel IPアドレスはFC Portと交際しました。 この分野がIPv4値を含むとき、それはIPv4によって写像されたIPv6アドレスとして保存されます。 すなわち、最も重要な10バイトは0xFFFFに設定された次の2バイトで0×00に設定されます[RFC2373]。 IPv6値がこの分野に保管されていると、全体の16バイトの分野は使用されています。
Tseng, et al. Standards Track [Page 92] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[92ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
6.6.8. Class of Service (COS)
6.6.8. サービスのクラス(COS)
This 32-bit bit-map field indicates the Fibre Channel Class of Service types that are supported by the registered port. In the following table, a set bit (1) indicates a Class of Service supported.
この32ビットのビットマップ分野は登録されたポートによってサポートされるServiceタイプのFibre Channel Classを示します。 以下のテーブルでは、セット・ビット(1)は、ServiceのClassがサポートしたのを示します。
Bit Position Description
------------ -----------
29 Fibre Channel Class 2 Supported
28 Fibre Channel Class 3 Supported
ビット位置記述------------ ----------- 29 サポートしている28繊維チャンネルのクラス3がサポートした繊維チャンネルのクラス2
6.6.9. FC-4 Types
6.6.9. FC-4はタイプします。
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プロトコルタイプを示します。 この分野は、Fibre Channelにデバイスを支えるのに使用できて、FC GS4と一致しています。
6.6.10. FC-4 Descriptor
6.6.10. FC-4記述子
This is a variable-length UTF-8 encoded NULL-terminated text-based description of up to 256 bytes that is associated with the iSNS- registered device port in the network. This field can be used to support Fibre Channel devices and is consistent with FC-GS-4.
これによる可変長のUTF-8がネットワークでiSNSの登録されたデバイスポートに関連している最大256バイトのNULLによって終えられたテキストベースの記述をコード化したということです。 この分野は、Fibre Channelにデバイスを支えるのに使用できて、FC GS4と一致しています。
6.6.11. FC-4 Features
6.6.11. FC-4の特徴
This is a 128-byte array, 4 bits per type, for the FC-4 protocol types supported by the associated port. This field can be used to support Fibre Channel devices and is consistent with FC-GS-4.
これは128バイトの配列、1タイプあたり関連ポートによってサポートされたFC-4プロトコルタイプのための4ビットです。 この分野は、Fibre Channelにデバイスを支えるのに使用できて、FC GS4と一致しています。
6.6.12. iFCP SCN Bitmap
6.6.12. iFCP SCNビットマップ
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クライアントが興味を持っているイベントを示します。 これらのイベントで、SCNsを生成することができます。 SCNsはそれがアップデートされるオブジェクトの情報を提供します、ソースと目的地がメンバーである加えられたかディスカバリーから取り外されたDomains。 管理SCNsはネットワークへのすべての変化の情報を提供します。 セット・ビット(1)はSCNのタイプを以下のビットマップに示します:
Tseng, et al. Standards Track [Page 93] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[93ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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
ビット位置旗の記述------------ ---------------- 24INITIATOR AND SELF INFORMATION ONLY25TARGET AND SELF INFORMATION ONLY26MANAGEMENT REGISTRATION/SCN27OBJECT REMOVED28OBJECT ADDED29OBJECT UPDATED30DD/DDS MEMBER REMOVED(管理レッジ/SCN専用)31(Lsb)DD/DDS MEMBER ADDED(管理レッジ/SCN専用)はすべて、他のものRESERVEDです。
Further information on the use of the bit positions specified above can be found in Section 6.4.4.
セクション6.4.4で上で指定されたビット位置の使用に関する詳細を見つけることができます。
6.6.13. Port Role
6.6.13. ポートの役割
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 Storage Nodeのタイプを示すビットマップです。 噛み付いている分野は以下で定義されます。 セット・ビットは、Nodeには対応する特性があるのを示します。
Bit Position Node Type
------------ ---------
29 Control
30 FCP Initiator
31 (Lsb) FCP Target
All Others RESERVED
ビット位置ノード種別------------ --------- 29 すべての他のものが予約したコントロール30FCP創始者31(Lsb)FCP目標
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クライアントSHALL NOT、iSNSPを使用することでこのビットを変えさせてください。
Tseng, et al. Standards Track [Page 94] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[94ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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サーバ実装は、目標だけが、ESIsを受け取るか、またはControl Nodesだけが発見ドメインを加えるか、変更するか、または削除するのを可能にするのを許容するために行政上構成されるかもしれません。
6.6.14. Permanent Port Name (PPN)
6.6.14. 永久的なポート名(PPN)
The Permanent Port Name can be used to support Fibre Channel devices and is consistent with the PPN description in FC-GS-4 [FC-GS-4]. The format of the PPN is identical to the FC Port Name WWPN attribute format.
Permanent Port NameはFibre Channelにデバイスを支えるのに使用できて、FC GS4[FC GS4]でPPN記述と一致しています。 PPNの形式はFC Port Name WWPN属性形式と同じです。
6.7. Node-Keyed Attributes
6.7. ノードで合わせられた属性
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.
以下の属性は、iSNSデータベースにキーとしてFC Node Name(WWNN)属性を使用することで示されます。 それぞれのセットのFC Nodeの合わせられた属性は、単一のデバイスを表して、多くのFC Portsに関連づけることができます。
The FC Node Name is unique across the entire iSNS database.
FC Node Nameは全体のiSNSデータベースの向こう側にユニークです。
6.7.1. FC Node Name (WWNN)
6.7.1. FCノード名(WWNN)
The FC Node Name is a 64-bit identifier that is the World Wide Node Name (WWNN) of the corresponding Fibre Channel device. This attribute is the key for the FC Device. This globally unique identifier is used during the device registration process, and it uses a value conforming to IEEE EUI-64 [EUI-64].
FC Node Nameは対応するFibre ChannelデバイスのWorld Wide Node Name(WWNN)である64ビットの識別子です。 この属性はFC Deviceのためのキーです。 このグローバルにユニークな識別子はデバイス登録手続の間、使用されます、そして、それはIEEE EUI-64[EUI-64]に従う値を使用します。
6.7.2. Symbolic Node Name
6.7.2. シンボリックなノード名
This is a variable-length UTF-8 encoded NULL-terminated text-based description of up to 256 bytes that is associated with the iSNS- registered FC Device in the network.
これによる可変長のUTF-8がネットワークでiSNSの登録されたFC Deviceに関連している最大256バイトのNULLによって終えられたテキストベースの記述をコード化したということです。
6.7.3. Node IP Address
6.7.3. ノードIPアドレス
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アドレスはネットワークでデバイスNodeに関連しています。 この分野はFibre Channelとの互換性のために含まれています。 この分野がIPv4値を含むとき、それはIPv4によって写像されたIPv6アドレスとして保存されます。 すなわち、最も重要な10バイトは0xFFFFに設定された次の2バイトで0×00に設定されます[RFC2373]。 IPv6値がこの分野に保管されているとき、全体の16バイトの分野は使用されています。
Tseng, et al. Standards Track [Page 95] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[95ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
6.7.4. Node IPA
6.7.4. ノードIPA
This field is the 8-byte Fibre Channel Initial Process Associator (IPA) associated with the device Node in the network. The initial process associator is used for communication between Fibre Channel devices.
この分野はネットワークでデバイスNodeに関連している8バイトのFibre Channel Initial Process Associator(IPA)です。 初めの過程連想装置はFibre Channelデバイスのコミュニケーションに使用されます。
6.7.5. Proxy iSCSI Name
6.7.5. プロキシiSCSI名
This is a variable-length UTF-8 encoded NULL-terminated text-based field that contains the iSCSI Name used to represent the FC Node in the IP network. It is used as a pointer to the matching iSCSI Name entry in the iSNS server. Its value is usually registered by an FC- iSCSI gateway connecting the IP network to the fabric containing the FC device.
これによる可変長のUTF-8がIPネットワークでFC Nodeを表すのに使用されるiSCSI Nameを含むNULLによって終えられたテキストベースの分野をコード化したということです。 それは指針としてiSNSサーバに合っているiSCSI Nameエントリーに使用されます。通常、値はFCデバイスを含む骨組みにIPネットワークを接続する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.
この分野がそこで使用されるならそれに注意してください、SHOULD、iSCSI名によって指定されたiSCSIデバイスのためのiSNSデータベースにおける合っているエントリーになってください。 データベースエントリーは発見に必要である最大限の範囲のiSCSI属性とFCデバイスの「iSCSIプロキシイメージ」の管理を含むべきです。
6.8. Other Attributes
6.8. 他の属性
The following are not attributes of the previously-defined objects.
↓これは以前に定義されたオブジェクトの属性ではありません。
6.8.1. FC-4 Type Code
6.8.1. FC-4はコードをタイプします。
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 Type質問の間、FC-4タイプを提供するのにおいて中古の4バイトの分野です。 FC-4タイプはFC-FSで定義されるようにFC-4 Typesと一致しています。 バイト0はFC-4タイプを含んでいます。 他のすべてのバイトが予約されています。
6.8.2. iFCP Switch Name
6.8.2. iFCPスイッチ名
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 Switch Nameはネットワークで唯一異なったiFCPゲートウェイを特定する64ビットのWorld Wide Name(WWN)識別子です。 このグローバルにユニークな識別子はスイッチ登録/FC_DOMAIN_ID課題プロセスの間、使用されます。 値が使用したiFCP Switch NameはWorld Wide Namesのために[FC-FS]に述べられた要件に従わなければなりません。 iSNSサーバSHALLは各iFCP Switch Nameに割り当てられたすべてのFC_DOMAIN_ID値の状態を追跡します。 与えられたiFCP Switch Nameを反登録するなら、iSNSデータベース、次にDOMAIN_ID値が割り当てたすべてのFC_からそのiFCP Switch Name SHALLまで、値の未使用のプールに返してください。
Tseng, et al. Standards Track [Page 96] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[96ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
6.8.3. iFCP Transparent Mode Commands
6.8.3. iFCP透過モードコマンド
6.8.3.1. Preferred ID
6.8.3.1. 都合のよい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サーバSHALLはFC_DOMAIN_IDとしてiSNSクライアントの要求された値の使用を承諾します、要求された値が既に割り当てられていないなら。 要求された値が利用可能でないなら、iSNSサーバSHALLは割り当てられていない異価を返します。
6.8.3.2. Assigned ID
6.8.3.2. 割り当てられたID
This is a 4-byte unsigned integer field that is used by an iFCP gateway to reserve its own unique FC_DOMAIN_ID value from the range 1 to 239. When a FC_DOMAIN_ID is no longer required, it SHALL be released by the iFCP gateway using the RlseDomId message. The iSNS server MUST use the Entity Status Inquiry message to determine whether an iFCP gateway is still present on the network.
これはiFCPゲートウェイによって使用される、範囲からそれ自身のユニークなFC_DOMAIN_ID価値を1〜239に予約する4バイトの符号のない整数分野です。 FC_DOMAIN_であるときに、IDはもう必要でなく、それはSHALLです。iFCPゲートウェイで、RlseDomIdメッセージを使用することで、リリースされます。 iSNSサーバはiFCPゲートウェイがネットワークにまだ存在しているかどうか決定するEntity Status Inquiryメッセージを使用しなければなりません。
6.8.3.3. Virtual_Fabric_ID
6.8.3.3. 仮想の_骨組み_ID
This is a variable-length UTF-8 encoded NULL-terminated text-based field of up to 256 bytes. The Virtual_Fabric_ID string is used as a key attribute to identify a range of non-overlapping FC_DOMAIN_ID values to be allocated using RqstDomId. Each Virtual_Fabric_ID string submitted by an iSNS client SHALL have its own range of non- overlapping FC_DOMAIN_ID values to be allocated to iSNS clients.
これによる可変長のUTF-8が最大256バイトのNULLによって終えられたテキストベースの分野をコード化したということです。 Virtual_Fabric_IDストリングは、RqstDomIdを使用することで割り当てるためにさまざまな非重なっているFC_DOMAIN_ID値を特定するのに主要な属性として使用されます。 それぞれ、_IDストリングが提出したVirtual_FabricはiSNSクライアントSHALLでそれ自身のiSNSクライアントに割り当てられる非重なっているFC_DOMAIN_ID値の範囲を持っています。
6.9. iSNS Server-Specific Attributes
6.9. iSNSのサーバ特有の属性
Access to the following attributes may be administratively controlled. These attributes are specific to the iSNS server instance; the same value is returned for all iSNS clients accessing the iSNS server. Only query messages may be performed on these attributes. Attempted registrations of values for these attributes SHALL return a status code of 3 (Invalid Registration).
以下の属性へのアクセスは行政上制御されるかもしれません。 これらの属性はiSNSサーバインスタンスに特定です。 iSNSサーバにアクセスするすべてのiSNSクライアントのために同じ値を返します。これらの属性に質問メッセージだけを実行するかもしれません。 SHALLが3(無効のRegistration)のステータスコードを返すこれらの属性のための値の試みられた登録証明書。
A query for an iSNS Server-Specific attribute MUST contain the identifying key attribute (i.e., iSCSI Name or FC Port Name WWPN) of the Node originating the registration or query message as the Source and Message Key attributes. The Operating Attributes are the server-specific attributes being registered or queried.
iSNS Server特有の属性のための質問はSourceとMessage Key属性として登録か質問メッセージを溯源するNodeの特定の主要な属性(すなわち、iSCSI NameかFC Port Name WWPN)を含まなければなりません。 Operating Attributesは登録されるか、または質問されるサーバ特有の属性です。
Tseng, et al. Standards Track [Page 97] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[97ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
6.9.1. iSNS Server Vendor OUI
6.9.1. iSNSサーバベンダーOUI
This attribute is the OUI (Organizationally Unique Identifier) [802-1990] identifying the specific vendor implementing the iSNS server. This attribute can only be queried; iSNS clients SHALL NOT be allowed to register a value for the iSNS Server Vendor OUI.
この属性はOUIです。(組織的では、Unique Identifier) サーバiSNSがこの属性であると実装しながら特定のベンダーを特定する[802-1990]について質問できるだけです。 iSNSクライアントSHALL NOT、値はiSNS Server Vendor OUIのために示さされてください。
6.10. Vendor-Specific Attributes
6.10. ベンダー特有の属性
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サーバSHALL NOTのベンダーの特定の属性のどんな実装も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を所有している、(組織的である、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 Std802-1990で定義されて、48ビットがUniversal LAN MACアドレスであると生成するのにおいて中古の同じ定数です。 ベンダーの自己のiSNS実装は、属性分野でOUIを認識して、その時、属性のベンダー特有の取り扱いを実行できるでしょう。
6.10.1. Vendor-Specific Server Attributes
6.10.1. ベンダー特有のサーバ属性
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サーバインスタンスに、これらの属性はユニークです。 これらの属性SHALLへの質問メッセージはSource属性とMessage Keyが結果と考える両方に、主要な識別子(すなわち、iSCSI NameかFC Port Name WWPN)を使用します。 これらの属性について質問できるだけです。 iSNSクライアントSHALL NOT、値はサーバ属性のために示さされてください。
6.10.2. Vendor-Specific Entity Attributes
6.10.2. ベンダー特有の実体属性
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の属性がベンダー特有であるか、またはサイトの特定の属性は以前はよくNetwork Entityオブジェクトについて説明していました。 これらの属性はEntity Identifier属性(タグ=1)によって合わせられます。
Tseng, et al. Standards Track [Page 98] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[98ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
6.10.3. Vendor-Specific Portal Attributes
6.10.3. ベンダー特有の入り口の属性
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の属性がベンダー特有であるか、またはサイトの特定の属性は以前はよくPortalオブジェクトについて説明していました。 これらの属性はPortal IP-アドレス(タグ=16)とPortal TCP/UDP Port(タグ=17)によって合わせられます。
6.10.4. Vendor-Specific iSCSI Node Attributes
6.10.4. ベンダー特有のiSCSIノード属性
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 Nodeオブジェクトについて説明していました。 これらの属性はiSCSI Name(タグ=32)によって合わせられます。
6.10.5. Vendor-Specific FC Port Name Attributes
6.10.5. ベンダー特有のFCポート名前属性
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 Port Name WWPN(タグ=64)によって合わせられます。
6.10.6. Vendor-Specific FC Node Name Attributes
6.10.6. ベンダー特有のFCノード名属性
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 Node Nameオブジェクトについて説明していました。 これらの属性はFC Node Name WWNN(タグ=96)によって合わせられます。
6.10.7. Vendor-Specific Discovery Domain Attributes
6.10.7. ベンダー特有の発見ドメイン属性
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の属性がベンダー特有であるか、またはサイトの特定の属性は以前はよくディスカバリーDomainオブジェクトについて説明していました。 これらの属性はDD_ID(タグ=104)によって合わせられます。
6.10.8. Vendor-Specific Discovery Domain Set Attributes
6.10.8. ベンダー特有の発見ドメインセット属性
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の属性がベンダー特有であるか、またはサイトの特定の属性は以前はよくディスカバリーDomain Setオブジェクトについて説明していました。 これらの属性はDD Set IDによって合わせられます。(タグ=101)
6.10.9. Other Vendor-Specific Attributes
6.10.9. 他のベンダー特有の属性
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.
ベンダーのiSNSサーバ実装に特定の新しいベンダー特有のオブジェクトについて説明する主要で非主要な属性に範囲1537年から2048の属性を使用できます。
Tseng, et al. Standards Track [Page 99] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[99ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
6.11. Discovery Domain Registration Attributes
6.11. 発見ドメインの取得属性
6.11.1. DD Set ID Keyed Attributes
6.11.1. DDセットIDは属性を合わせました。
6.11.1.1. Discovery Domain Set ID (DDS ID)
6.11.1.1. 発見ドメインセットID(DDS ID)
The DDS ID is an unsigned non-zero integer identifier used in the iSNS directory database as a key to indicate a Discovery Domain Set uniquely. A DDS is a collection of Discovery Domains that can be enabled or disabled by a management station. This value is used as a key for DDS attribute queries. When a Discovery Domain is registered, it is initially not in any DDS.
DDS IDは唯一ディスカバリーDomain Setを示すのにキーとしてiSNSディレクトリデータベースで使用される未署名の非ゼロ整数識別子です。 DDSは管理局で有効にするか、または無効にすることができるディスカバリーDomainsの収集です。 この値はDDS属性質問にキーとして使用されます。 ディスカバリーDomainが初めは登録されているとき、それはどんな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_IDをDDS登録要求メッセージに提供しないなら、iSNSサーバSHALLは、DDS_IDがその新しいDDSのためのiSNSデータベースの中でユニークな値であると生成します。 返されたコネが応答メッセージであったならDDS ID SHALLを作成しました。 0のDDS ID値は予約されています、そして、1のDDS ID値はデフォルトDDSに使用されます(セクション2.2.2を見てください)。
6.11.1.2. Discovery Domain Set Symbolic Name
6.11.1.2. 発見のドメインのセットのシンボリックな名
A variable-length UTF-8 encoded NULL-terminated text-based field of up to 256 bytes. This is a user-readable field used to assist a network administrator in tracking the DDS function. When a client registers a DDS symbolic name, the iSNS server SHALL verify it is unique. If the name is not unique, then the DDS registration SHALL be rejected with an "Invalid Registration" Status Code. The invalid attribute(s), in this case the DDS symbolic name, SHALL be included in the response.
可変長のUTF-8は最大256バイトのNULLによって終えられたテキストベースの分野をコード化しました。 これはDDS機能を追跡するのにネットワーク管理者を助けるのに使用されるユーザ読み込み可能な分野です。 iSNSサーバSHALLは、クライアントがいつDDS英字名を登録するかを確かめます。それはユニークです。 名前はユニークでなく、次に、DDS登録はSHALLです。「無効の登録」Status Codeと共に拒絶されます。 病人は含まれているコネが応答であったなら(s)、この場合SHALLというDDSのシンボリックな名を結果と考えます。
6.11.1.3. Discovery Domain Set Status
6.11.1.3. 発見ドメインセット状態
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がEnabled(1)かそれともDisabled(0)であるかを示します。 DDS Enabled旗のためのデフォルト値はDisabled(0)です。
Bit Position DDS Status
------------ ---------
31 (Lsb) DDS Enabled (1) / DDS Disabled (0)
All others RESERVED
ビット位置DDS状態------------ --------- 31 (Lsb)DDSはすべての他のものが予約した(0)であることが無効にされた(1)/DDSを有効にしました。
6.11.1.4. Discovery Domain Set Next ID
6.11.1.4. ドメインが次のIDを設定したという発見
This is a virtual attribute containing a 4-byte integer value that indicates the next available (i.e., unused) Discovery Domain Set Index value. This attribute may only be queried; the iSNS server
これは次の利用可能な(すなわち、未使用の)発見Domain Set Index価値を示す4バイトの整数値を含む仮想の属性です。 この属性は質問されるだけであるかもしれません。 iSNSサーバ
Tseng, et al. Standards Track [Page 100] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[100ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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.
SHALLはこの属性のために値を示すのを試みるどんなクライアントにも3(無効のRegistration)のエラーコードを返します。 この属性のために排他的に質問するとき、Message Keyは必要ではありません。
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.
ディスカバリーDomain Set Next Indexは、iSNSサーバにおけるエントリーを作成するのにSNMPクライアントによって使用されるかもしれません。SNMP要件はセクション2.10で説明されます。
6.11.2. DD ID Keyed Attributes
6.11.2. DD IDは属性を合わせました。
6.11.2.1. Discovery Domain ID (DD ID)
6.11.2.1. 発見ドメインID(DD ID)
The DD ID is an unsigned non-zero integer identifier used in the iSNS directory database as a key to identify a Discovery Domain uniquely. This value is used as the key for any DD attribute query. If the iSNS client does not provide a DD_ID in a DD registration request message, the iSNS server SHALL generate a DD_ID value that is unique within the iSNS database for that new DD (i.e., the iSNS client will be registered in a new DD). The created DD ID SHALL be returned in the response message. The DD ID value of 0 is reserved, and the DD ID value of 1 is used for the default DD (see Section 2.2.2).
DD IDは唯一ディスカバリーDomainを特定するのにキーとしてiSNSディレクトリデータベースで使用される未署名の非ゼロ整数識別子です。 この値はどんなDD属性質問にもキーとして使用されます。 iSNSクライアントがDD_IDをDD登録要求メッセージに提供しないなら、iSNSサーバSHALLは、DD_IDがその新しいDDのためのiSNSデータベースの中でユニークな値であると生成します(すなわち、iSNSクライアントは新しいDDに登録されるでしょう)。 返されたコネが応答メッセージであったならDD ID SHALLを作成しました。 0のDD ID値は予約されています、そして、1のDD ID値はデフォルトDDに使用されます(セクション2.2.2を見てください)。
6.11.2.2. Discovery Domain Symbolic Name
6.11.2.2. 発見のドメインのシンボリックな名
A variable-length UTF-8 encoded NULL-terminated text-based field of up to 256 bytes. When a client registers a DD symbolic name, the iSNS server SHALL verify it is unique. If the name is not unique, then the DD registration SHALL be rejected with an "Invalid Registration" Status Code. The invalid attribute(s), in this case the DD symbolic name, SHALL be included in the response.
可変長のUTF-8は最大256バイトのNULLによって終えられたテキストベースの分野をコード化しました。 iSNSサーバSHALLは、クライアントがいつDD英字名を登録するかを確かめます。それはユニークです。 名前はユニークでなく、次に、DD登録はSHALLです。「無効の登録」Status Codeと共に拒絶されます。 病人は含まれているコネが応答であったなら(s)、この場合SHALLというDDのシンボリックな名を結果と考えます。
6.11.2.3. Discovery Domain Member: iSCSI Node Index
6.11.2.3. 発見ドメインメンバー: iSCSIノードインデックス
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のメンバーであるStorage NodeのiSCSI Node Indexです。 DDには、0〜nメンバーのリストがあるかもしれません。 iSCSI Node IndexはディスカバリーDomain(iSCSI Nameであるもう片方の代替手段)の会員資格の1つの代替の表現です。 ディスカバリー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 Nameが使用できないくらい長い状況でDDメンバーの代理をするのにiSCSI Node Indexを使用できます。 この例はSNMPが管理にセクション2.10で説明されるように使用される時です。
The iSCSI Node Index and the iSCSI Name stored as a member in a DD SHALL be consistent with the iSCSI Node Index and iSCSI Name attributes registered for the Storage Node object in the iSNS server.
DD SHALLでは、iSCSI Node Indexと一致していて、iSCSI Node IndexとiSCSI Nameはaとしてメンバーを保存しました。iSCSI Name属性はiSNSサーバでStorage Nodeオブジェクトに登録しました。
Tseng, et al. Standards Track [Page 101] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[101ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
6.11.2.4. Discovery Domain Member: iSCSI Name
6.11.2.4. 発見ドメインメンバー: iSCSI名
A variable-length UTF-8 encoded NULL-terminated text-based field of up to 224 bytes. It indicates membership for the specified iSCSI Storage Node in the Discovery Domain. Note that the referenced Storage Node does not need to be actively registered in the iSNS database before the iSNS client uses this attribute. There is no limit to the number of members that may be in a DD. Membership is represented by the iSCSI Name of the iSCSI Storage Node.
可変長のUTF-8は最大224バイトのNULLによって終えられたテキストベースの分野をコード化しました。 それはディスカバリーDomainの指定されたiSCSI Storage Nodeのために会員資格を示します。 iSNSクライアントがこの属性を使用する前にiSNSデータベースに参照をつけられたStorage Nodeによって活発に登録される必要はないことに注意してください。 DDにあるかもしれない会員数への限界が全くありません。 会員資格はiSCSI Storage NodeのiSCSI Nameによって表されます。
6.11.2.5. Discovery Domain Member: FC Port Name
6.11.2.5. 発見ドメインメンバー: FCポート名
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ビットの識別子属性はディスカバリーDomainのiFCP Storage Node(FC Port)のために会員資格を示します。 iSNSクライアントがこの属性を使用する前にiSNSデータベースに参照をつけられたStorage Nodeによって活発に登録される必要はないことに注意してください。 DDにあるかもしれない会員数への限界が全くありません。 会員資格はiFCP Storage NodeのFC Port Name(WWPN)によって表されます。
6.11.2.6. Discovery Domain Member: Portal Index
6.11.2.6. 発見ドメインメンバー: 入り口のインデックス
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.
この属性はPortalのためにディスカバリーDomainで会員資格を示します。 それはPortal IP AddressとPortal TCP/UDP PortへのPortal会員資格の代替の表現です。 iSNSクライアントがこの属性を使用する前にiSNSデータベースに活発に参照をつけられたPortalを登録しなければなりません。
6.11.2.7. Discovery Domain Member: Portal IP Address
6.11.2.7. 発見ドメインメンバー: 入り口のIPアドレス
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.
この属性とPortal TCP/UDP Port属性は指定されたPortalのためにディスカバリーDomainで会員資格を示します。 iSNSクライアントがこの属性を使用する前にiSNSデータベースに参照をつけられたPortalによって活発に登録される必要はないことに注意してください。
6.11.2.8. Discovery Domain Member: Portal TCP/UDP Port
6.11.2.8. 発見ドメインメンバー: 入り口のTCP/UDP港
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.
この属性とPortal IP Address属性は指定されたPortalのためにディスカバリーDomainで会員資格を示します。 iSNSクライアントがこの属性を使用する前にiSNSデータベースに参照をつけられたPortalによって活発に登録される必要はないことに注意してください。
6.11.2.9. Discovery Domain Features
6.11.2.9. 発見ドメイン機能
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.
ディスカバリーDomain FeaturesはこのDDの特徴を示すビットマップです。 ビット位置は以下で定義されます。 少し、1へのセットは、DDには対応する特性があるのを示します。
Tseng, et al. Standards Track [Page 102] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[102ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
Bit Position DD Feature
------------ ----------
31 (Lsb) Boot List Enabled (1)/Boot List Disabled (0)
All others RESERVED
ビット位置DDの特徴------------ ---------- 31 (Lsb)はすべての他のものが予約した(0)であることが無効にされたリストの可能にされた(1)/ブーツリストをブートします。
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-ブーツ]で説明されるようにこのDDの目標がブーツ能力をメンバー創始者に提供するのを示します。
6.11.2.10. Discovery Domain Next ID
6.11.2.10. 次の発見Domain ID
This is a virtual attribute containing a 4-byte integer value that indicates the next available (i.e., unused) Discovery Domain Index value. This attribute may only be queried; the iSNS server SHALL return an error code of 3 (Invalid Registration) to any client that attempts to register a value for this attribute. A Message Key is not required when exclusively querying for this attribute.
これは次の利用可能な(すなわち、未使用の)発見Domain Index価値を示す4バイトの整数値を含む仮想の属性です。 この属性は質問されるだけであるかもしれません。 iSNSサーバSHALLはこの属性のために値を示すのを試みるどんなクライアントにも3(無効のRegistration)のエラーコードを返します。 この属性のために排他的に質問するとき、Message Keyは必要ではありません。
7. Security Considerations
7. セキュリティ問題
7.1. iSNS Security Threat Analysis
7.1. iSNS軍事的脅威分析
When the iSNS protocol is deployed, the interaction between iSNS server and iSNS clients is subject to the following security threats:
iSNSプロトコルが配布されるとき、iSNSサーバとiSNSクライアントとの相互作用は以下の軍事的脅威を受けることがあります:
a) An attacker could alter iSNS protocol messages, such as to direct
iSCSI and iFCP devices to establish connections with rogue peer
devices, or to weaken/eliminate IPSec protection for iSCSI or
iFCP traffic.
a) 攻撃者はiSNSプロトコルメッセージ(iSCSIのためのIPSec保護かiFCPトラフィックを凶暴な同輩デバイスで関係を樹立するか、弱めるか、または排除するようiSCSIとiFCPデバイスに指示するようなもの)を変更できました。
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) 攻撃者は、iSCSIとiFCPデバイスの周りでiSNSプロトコルメッセージについて詮索することによって、知識を得ることができるでしょう。 そのような情報は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プロトコルメッセージは、認証される必要があるかもしれません。 さらに、iSNSサーバのある機能が利用されているとき、秘密性サポートは、脅威c)から守るためには、望ましく、REQUIREDです。
Tseng, et al. Standards Track [Page 103] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[103ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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プロトコルメッセージは、認証される必要があるかもしれません。 重要情報を漏らさないので、これらのメッセージは秘密である必要はありません。
7.2. iSNS Security Implementation and Usage Requirements
7.2. iSNSセキュリティ実装と用法要件
If the iSNS server is used to distribute authorizations for communications between iFCP and iSCSI peer devices, IPsec ESP with null transform MUST be implemented, and non-null transform MAY be implemented. If a non-null transform is implemented, then the DES encryption algorithm SHOULD NOT be used.
iSNSサーバがコミュニケーションのために承認を分配するのに使用されるなら、iFCPとiSCSI同輩デバイス、IPsecの間では、ヌル変換がある超能力を実装しなければなりません、そして、非ヌル変換は実装されるかもしれません。 変換は非ヌルであるなら実装されて、次に、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デバイスのために安全保障政策を分配するのに使用されるなら、認証、データ保全、および秘密性をサポートされて、使用しなければなりません。 秘密性が望まれているか、または必要であり、IPSecが非ヌル変換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.
iSNSサーバがセクション6.11.2で.9について説明するのでブーツリストをクライアントに提供するのに使用されるなら、iSCSIブーツクライアントSHOULDは、安全なiSNSが接続であると実装します。
In order to protect against an attacker masquerading as an iSNS server, client devices MUST support the ability to authenticate broadcast or multicast messages such as the iSNS heartbeat. The iSNS authentication block (which is identical in format to the SLP authentication block) SHALL be used for this purpose. iSNS clients MUST implement the iSNS authentication block and MUST support BSD value 0x002. If the iSNS server supports broadcast or multicast iSNS messages (i.e., the heartbeat), then the server MUST implement the iSNS authentication block and MUST support BSD value 0x002. Note that the authentication block is used only for iSNS broadcast or multicast messages and MUST NOT be used in unicast iSNS messages.
iSNSサーバのふりをしている攻撃者から守るために、クライアントデバイスはiSNS鼓動などの放送かマルチキャストメッセージを認証する能力をサポートしなければなりません。 iSNS認証ブロック(形式がSLP認証ブロックと同じである)SHALLは. iSNSクライアントがiSNS認証ブロックを実装しなければならないこの目的に使用されて、BSDが値0x002であるとサポートしなければなりません。 iSNSサーバが、放送かマルチキャストiSNSメッセージが(すなわち、鼓動)であるとサポートするなら、サーバは、iSNS認証ブロックを実装しなければならなくて、BSDが値0x002であることを支えなければなりません。 認証ブロックはiSNS放送かマルチキャストメッセージにだけ使用して、ユニキャストiSNSメッセージで使用してはいけないことに注意してください。
There is no requirement that the communicating identities in iSNS protocol messages be kept confidential. Specifically, the identity and location of the iSNS server is not considered confidential.
iSNSプロトコルメッセージの交信のアイデンティティが秘密にされるという要件が全くありません。 明確に、iSNSサーバのアイデンティティと位置は秘密であると考えられません。
For protecting unicast iSNS protocol messages, iSNS servers supporting security MUST implement ESP in tunnel mode and MAY implement transport mode.
ユニキャストiSNSプロトコルメッセージを保護するために、セキュリティをサポートするiSNSサーバは、トンネルモードにおける超能力を実装しなければならなくて、輸送がモードであると実装するかもしれません。
All iSNS implementations supporting security MUST support the replay protection mechanisms of IPsec.
セキュリティをサポートするすべてのiSNS実装が、反復操作による保護がIPsecのメカニズムであるとサポートしなければなりません。
iSNS security implementations MUST support both IKE Main Mode and Aggressive Mode for authentication, negotiation of security associations, and key management, using the IPSec DOI [RFC2407].
iSNSセキュリティ実装は認証、セキュリティ協会の交渉、およびかぎ管理のためにIKE Main ModeとAggressive Modeの両方をサポートしなければなりません、IPSec DOI[RFC2407]を使用して。
Tseng, et al. Standards Track [Page 104] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[104ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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.
手動、SHOULD NOTを合わせて、サポートを「再-合わせ」ながら金策しないので、使用されてください。 iSNSセキュリティ実装を従わせると、あらかじめ共有されたキーを使用して、認証がサポートしなければならなくて、デジタル署名を使用して、証明書ベースの同輩認証はサポートするかもしれません。 公開鍵暗号化メソッドを使用する同輩認証がIKEsセクション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 Main ModeとAggressive Modeの両方がサポートしなければなりません。 同輩のどちらかであるときに、あらかじめ共有された主要な認証SHOULD NOTが使用されているIKE Main Modeはダイナミックに割り当てられたIPアドレスを使用します。 あらかじめ共有された主要な認証があるMain Modeは多くの場合優れた警備体制を提供しますが、ダイナミックに割り当てられたアドレスがそうである状況は武力行使しました。グループの使用はキー(介入者攻撃に被害を受け易いもの)をあらかじめ共有しました。 IKE Identity有効搭載量ID_KEY_IDを使用してはいけません。
When digital signatures are used for authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used. In all cases, access to locally stored secret information (pre-shared key or private key for digital signing) MUST be suitably restricted, since compromise of the secret information nullifies the security properties of the IKE/IPsec protocols.
デジタル署名が認証に使用されるとき、IKE Main ModeかIKE Aggressive Modeのどちらかが使用されるかもしれません。 すべての場合では、適当に局所的に保存された秘密の情報(デジタル署名のためにキーか秘密鍵をあらかじめ共有する)へのアクセスを制限しなければなりません、秘密の情報の感染が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を達成するために、交渉者SHOULDは認証局(または、当局)を指定するローカルの方針によると、信じられるIKE Certificate Request有効搭載量を使用します。 PKI証明書を受け入れる前に、IKE交渉者SHOULDはIKEの認証手順における使用がないかどうか適切なCertificate Revocation List(CRL)をチェックします。
When the iSNS server is used without security, IP block storage protocol implementations MUST support a negative cache for authentication failures. This allows implementations to avoid continually contacting discovered endpoints that fail authentication within IPsec or at the application layer (in the case of iSCSI Login). The negative cache need not be maintained within the IPsec implementation, but rather within the IP block storage protocol implementation.
iSNSサーバがセキュリティなしで使用されるとき、認証失敗によって、IPブロックストレージプロトコル実装は否定的キャッシュをサポートしなければなりません。 これで、実装は、IPsec以内か応用層(iSCSI Loginの場合における)で認証に失敗する発見された終点に絶えず接触するのを避けることができます。 否定的キャッシュはIPsec実装、しかし、むしろIPブロックストレージプロトコル実装の中で維持される必要はありません。
7.3. Discovering Security Requirements of Peer Devices
7.3. 同輩デバイスのセキュリティ要件を発見します。
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デバイスに供給します。
Tseng, et al. Standards Track [Page 105] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[105ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
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、Main Mode、およびAggressive Modeの非使用を含んでいます。 例えば、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サーバから学習されるべきである最小の情報は、IKEと各iFCPかiSCSI同輩デバイス・インタフェースのそばのIPSecの使用か非使用です。 この情報は、同輩デバイスのそれぞれのPortalのSecurity Bitmap分野でコード化されて、同輩デバイスの1インタフェースあたり1個のベースで適切です。IPSec/超能力認証で同輩デバイスに関するセキュリティ設定データを取得するためのiSNS質問を保護しなければなりません。
7.4. Configuring Security Policies of iFCP/iSCSI Devices
7.4. iFCP/iSCSIデバイスの安全保障政策を構成します。
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が安全保障政策を分配するのに使用されるなら、すべてのiSNSプロトコルメッセージを保護するのに当時のIPSec認証、データ保全、および秘密性を使用しなければなりません。
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.
iSNSサーバでそれぞれのiFCP、そして/または、iSCSIデバイスの完全なIKE/IPSec構成を保存できます、クライアントデバイスの間のIKE Phase1とPhase2つの交渉に使用される方針を含んでいて。 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.
また、さらに、iSNSサーバでそれぞれのiSCSIデバイスによって使用されるiSCSI Authentication Methodsは保存できます。iSCSI AuthMethod分野(タグ=42)はテキスト値がそのiSCSIデバイスによって使用されるべきiSCSI認証方法を示していて埋め込まれたヌルで終えられたストリングを含んでいます。
Note that iSNS distribution of security policy is not necessary if the security settings can be determined by other means, such as manual configuration or IPsec security policy distribution. If a network entity has already obtained its security configuration via other mechanisms, then it MUST NOT request security policy via iSNS.
安全保障政策のiSNS分配はセキュリティー設定であるなら必要でないというメモが手動の構成かIPsec安全保障政策分配などの他の手段で決定できます。 ネットワーク実体が他のメカニズムで既にセキュリティ設定を得たなら、それはiSNSを通して安全保障政策を要求してはいけません。
Tseng, et al. Standards Track [Page 106] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[106ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
7.5. Resource Issues
7.5. リソース問題
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要件を実現させるのにこれらの既存の要件は使用できます。
7.6. iSNS Interaction with IKE and IPSec
7.6. IKEとIPSecとのiSNS相互作用
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データベースSHALLに登録される少なくとも1Storage NodeをもっているそれぞれのiSNSクライアントは、iSNSのサーバiSNSクライアントの間のすべてのiSNSプロトコルメッセージとiSNSサーバSHALLとの少なくとも1つのフェーズ-1セキュリティ協会がフェーズ-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.
Network Entityが取り外されるとき、iSNSデータベース、SHALLが送るiSNSサーバから、フェーズ-1は、関連iSNSクライアントIKE同輩にメッセージを削除して、すべてのフェーズ-1とそのiSNSクライアントに関連しているフェーズ-2SAsを取りこわします。
8. IANA Considerations
8. IANA問題
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プロトコルのものです。 2番目の登録は標準のサーバを登録して、iSNSから質問できるiSNS属性の詳細な登録です。このRFCがService Locationプロトコルのセクション15でBlock Structure Descriptor(BSD)のために作成された登録を使用することに注意してください、バージョン2[RFC2608。]
8.1. Registry of Block Storage Protocols
8.1. ブロックストレージプロトコルの登録
In order to maintain a registry of block storage protocols supported by iSNSP, IANA will assign a 32-bit unsigned integer number for each block storage protocol supported by iSNS. This number is stored in the iSNS database as the Entity Protocol. The initial set of values to be maintained by IANA for Entity Protocol is indicated in the
iSNSPによってサポートされたブロックストレージプロトコルの登録を維持するために、IANAはiSNSによってサポートされたそれぞれのブロックストレージプロトコルの32ビットの符号のない整数番号を割り当てるでしょう。 この数はEntityプロトコルとしてiSNSデータベースに保存されます。 EntityプロトコルのためにIANAによって維持される値の始発は中に示されます。
Tseng, et al. Standards Track [Page 107] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[107ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
table in Section 6.2.2. Additional values for new block storage protocols to be supported by iSNS SHALL be assigned by the IPS WG Chairperson, or by a Designated Expert [RFC2434] appointed by the IETF Transport Area Director.
セクション6.2.2では、テーブルの上に置きます。 新しいブロックストレージプロトコルがIPS WG理事長によって割り当てられるか、またはDesignated Expert[RFC2434]によってIETF Transport Areaディレクターによって任命されたiSNS SHALLによってサポートされる加算値。
8.2. Registry of Standard iSNS Attributes
8.2. 標準のiSNS属性の登録
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はStandard iSNS AttributesのRegistryを作成して、維持するのに責任があります。 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.
Standard iSNS Attributes SHALLのRegistryへの新しい標準の属性の追加はIETF Consensus[RFC2434]を必要とします。 このプロセスSHALLに必要であるRFCはセクション6.1でIANA配分のために予約されたタグ値の使用を指定します。 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 Consensus、提案されたRFC、および解説文書SHALLを入手するプロセスの一部として、IPS WGメーリングリストに利用可能であるかIPS WGが当時、解散されるならIETF Transport Areaディレクターによってメーリングリストに指定されているのに作られてください。 IETF Transport Areaディレクターによって任命されたIPS WG議長か人が、提案を拒絶するか、または公表のためにRFCとして草稿をIESGに送ると決める少なくとも3カ月前にレビューとコメント期間のSHALLは持続します。 仕様がRFCとして発表されると、IANAは新しいiSNS属性を示して、登録を共同体に利用可能にするでしょう。
8.3. Block Structure Descriptor (BSD) Registry
8.3. ブロック構造記述子(BSD)登録
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 Authentication BlockのためにBlock Structure Descriptorに使用される値を割り当てて、維持するのに責任があることに注意してください(セクション5.5を見てください)。 [RFC2608]のセクション15は新しいBSD値の配分のためにプロセスについて説明します。
Tseng, et al. Standards Track [Page 108] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[108ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
9. Normative References
9. 引用規格
[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.、メタンフェタミン、K.、Sapuntzakis、C.、Chadalapaka、M.、およびE.Zeidner、「インターネットの小さいコンピュータ・システムは(iSCSI)を連結します」、RFC3720、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.エドワーズ、「iFCP--インターネット繊維のためのプロトコルはストレージネットワークを向けます」、RFC4172、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.、ツェン、J.、およびK.ギボンズ、IPv4Dynamic Host Configuration Protocol(DHCP)オプションはサービスを命名します、RFC4174、2005年9月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2 ", RFC 2608, June
1999.
[RFC2608]Guttman、E.、パーキンス、C.、Veizades、J.、およびM.日、「サービス位置のプロトコル、バージョン2」RFC2608、6月1999日
[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] 「2005年4月にUsing Service Locationプロトコルバージョン2(SLP)、RFC4018年までにインターネットSmallコンピュータシステムズInterface(iSCSI)目標とName Serversを見つける」バッキー、M.、Hufferd、J.、Voruganti、K.、クルーガー、M.、およびT.スペリー。
[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-ブーツ]のサルカール、P.、Missimer、D.、およびC.Sapuntzakis、「インターネットSamllコンピュータシステム・インタフェース(iSCSI)を使用しているブートストラップ法クライアントが議定書を作ります」、RFC4173、2005年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[STRINGPREP] Bakke, M., "String Profile for Internet Small Computer
Systems Interface (iSCSI) Names", RFC 3722, April 2004.
[STRINGPREP]バッキー、M.、「インターネットの小さいコンピュータ・システムインタフェース(iSCSI)名のためのストリングプロフィール」、RFC3722、2004年4月。
[NAMEPREP] Hoffman, P. Nameprep: A Stringprep Profile for
Internationalized Domain Names, July 2002.
[NAMEPREP]ホフマン、P.Nameprep: 国際化ドメイン名のための2002年7月のStringprepプロフィール。
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2407]パイパー、D.、「ISAKMPのための解釈のインターネットIPセキュリティー領域」、RFC2407、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.、シュナイダー、M.、およびJ.ターナー、「インターネットセキュリティ協会とKey Managementは(ISAKMP)について議定書の中で述べます」、RFC2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。
Tseng, et al. Standards Track [Page 109] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[109ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
[EUI-64] Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority, May 2001, IEEE
64ビットのグローバルな識別子(EUI-64)登録局、2001年5月、IEEEのための[EUI-64]ガイドライン
[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.、ポーク、W.、およびR.Housley、「インターネットX.509公開鍵暗号基盤証明書と証明書取消しのためのアルゴリズムと識別子は(CRL)プロフィールをリストアップします」、RFC3279、2002年4月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3280] Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(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
NCITSが草稿プロジェクト1331-Dを扱って、[FC-FS]繊維チャンネル縁どりとシグナリングは連結します。
10. Informative References
10. 有益な参照
[iSNSMIB] Gibbons, K., et al., "Definitions of Managed Objects for
iSNS (Internet Storage name Service)", Work in Progress,
July 2003.
[iSNSMIB] ギボンズ、K.、他、「iSNS(インターネットStorage名前Service)のためのManaged Objectsの定義」、Progress、2003年7月のWork。
[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(1997E): 情報技術--オープン・システム・インターコネクション--ディレクトリ: 認証フレームワーク、1997年6月
[FC-GS-4] Fibre Channel Generic Services-4 (work in progress),
NCITS Working Draft Project 1505-D
[FC GS4] 繊維Channel Generic Services-4(処理中の作業)、NCITS作業草案Project 1505-D
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
[RFC1510]コールとJ.とC.ヌーマン、「ケルベロスネットワーク認証サービス(V5)」、RFC1510 1993年9月。
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
(SPKM)", RFC 2025, October 1996.
C.、「簡単な公開鍵GSS-APIメカニズム(SPKM)」、RFC2025 1996年10月の[RFC2025]アダムス。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange
System", RFC 2945, September 2000.
[RFC2945] ウーと、T.と、「SRP認証と主要な交換システム」、RFC2945、9月2000日
Tseng, et al. Standards Track [Page 110] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[110ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC1994] シンプソン、W.、「pppチャレンジハンドシェイク式認証プロトコル(やつ)」、RFC1994、1996年8月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、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.、マンディ、R.、パーテイン、D.、およびB.スチュワート、「インターネット標準の管理フレームワークのための序論と適用性声明」、RFC3410(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] ハリントン、D.、Presuhn、R.、およびB.Wijnen、「簡単なネットワーク管理プロトコル(SNMP)管理フレームワークについて説明するためのアーキテクチャ」、STD62、RFC3411(2002年12月)。
Tseng, et al. Standards Track [Page 111] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[111ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
Appendix A: iSNS Examples
付録A: iSNSの例
A.1. iSCSI Initialization Example
A.1iSCSI初期設定の例
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 Serviceエージェント(SA)がiSNSホストの上で実装されたと思います、そして、SLP Userエージェント(UA)はiSNS創始者の上で実装されました。 さらに詳しい明細についてはSAsとUAsで見てください[RFC2608]。 また、この例は、目標がiSNSサーバを使用して、iSNSサーバにアクセス制御方針を従属させているために構成されると仮定します。
A.1.1. Simple iSCSI Target Registration
A.1.1。 簡単なiSCSI目標登録
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サーバとともに記名します。1Storage Node、1Portal、およびStorage NodeとPortalとの関係を提供するそれとなく登録されたPortal Groupを含んでいて、目標はiSNSにEntityによって表されます。 Fully Qualified Domain Name(FQDN)は管理者によって目標に割り当てられていません。 この例では、未成年者不適当映画オブジェクトが明らかに登録されないので、1のPGTとPortal Groupはそれとなく登録されます。 この例では、SLPは、iSNS Serverの位置を発見するのに使用されます。代替手段はiSNSサーバを発見するのに、iSNS DHCPオプション[iSNSOption]を使用することです。
+--------------------------+------------------+-------------------+ | iSCSI Target Device | iSNS Server |Management Station | +--------------------------+------------------+-------------------+ |Discover iSNS--SLP------->| |/*mgmt station is | | |<--SLP--iSNS Here:| administratively | | | 192.0.2.100 | authorized to view| | | | all DDs. Device | | DevAttrReg--------->| | NAMEabcd was | |Src:(tag=32) "NAMEabcd" | | previously placed | |Key: <none present> | | into DDabcd along | |Oper Attrs: | | with devpdq and | |tag=1: NULL | | devrst. | |tag=2: "iSCSI" | | | |tag=16: 192.0.2.5 | | | |tag=17: 5001 | | | |tag=32: "NAMEabcd" | | | |tag=33: target | | | |tag=34: "disk 1" | | | | |<---DevAttrRegRsp | | | |SUCCESS | | | |Key:(tag=1) "isns:0001" | | |Oper Attrs: | | | |tag=1: "isns:0001"| | | |tag=2: "iSCSI" | |
+--------------------------+------------------+-------------------+ | iSCSI対象装置| iSNSサーバ|管理局| +--------------------------+------------------+-------------------+ |iSNSを発見してください--、SLP------->| |/*管理ステーションはそうです。| | | <--SLP--、iSNS Here:、|、行政上。| | | 192.0.2.100 | 視点に認可されます。| | | | すべてのDDs。 デバイス| | DevAttrReg--------->|、| NAMEabcdはそうでした。| |Src: (タグ=32)"NAMEabcd"| | 以前に、入賞します。| |キー: >をなにも寄贈しない<。| | DDabcd、ずっと。| |Oper Attrs: | | そしてdevpdq。| |=1にタグ付けをしてください: ヌル| | devrst。 | |=2にタグ付けをしてください: "iSCSI"| | | |=16にタグ付けをしてください: 192.0.2.5 | | | |=17にタグ付けをしてください: 5001 | | | |=32にタグ付けをしてください: "NAMEabcd"| | | |=33にタグ付けをしてください: 目標| | | |=34にタグ付けをしてください: 「ディスク1インチ」| | | | | <、-、--DevAttrRegRsp| | | |成功| | | |キー: (タグ=1)「isns: 1インチ」| | |Oper Attrs: | | | |=1にタグ付けをしてください: 「isns: 1インチ」| | | |=2にタグ付けをしてください: "iSCSI"| |
Tseng, et al. Standards Track [Page 112] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[112ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
| |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"| | +--------------------------+------------------+-------------------+
| |=16にタグ付けをしてください: 192.0.2.5 | | | |=17にタグ付けをしてください: 5001 | | | |=32にタグ付けをしてください: "NAMEabcd"|/、*以前に。| | |=33にタグ付けをしてください: 目標| DD*/では、入賞します。| | |=34にタグ付けをしてください: 「ディスク1インチ」| | | | | | | | SCN-------->|、|、| |(または、SNMP通知) | | |dest: (タグ=32): "MGMTname1""| | |時間: (タグ=4): <現在の時間>。| | |=35にタグ付けをしてください: 「MGT-SCN、OBJ加えてください」| | |=32にタグ付けをしてください: "NAMEabcd"| | | | | <、-、-、-、-、-、--SCNRsp| | DevAttrQry--------->|、|、| |Src: (タグ=32)"NAMEabcd"| | | |キー: (タグ=33)「創始者」| | | |Oper Attrs: | | | |=16にタグ付けをしてください: ヌル| | | |=17にタグ付けをしてください: ヌル| | | |=32にタグ付けをしてください: ヌル| | | |/*質問はすべてのinitrを求めます。| | | |デバイスのIPアドレス、ポート| <、-、--DevAttrQryRsp| | |数、およびName*/|成功| | | |タグ=16: 192.0 .2、.1| | | |=17:50000にタグ付けをしてください。| | | |タグ=32: "devpdq"| | | |タグ=16: 192.0 .2、.2| | | |=17:50000にタグ付けをしてください。| | | |タグ=32: "devrst"| | |/*************************| | <、-、-、-、--DevAttrQry| |私たちの目標"NAMEabcd"| |src: "MGMTname1""| |2人の創始者を発見します。| キー: (タグ=32)"NAMEabcd"|共有されたDDsで。 それはそうするでしょう。| |オプアートAttrs: | |iSCSIログインを受け入れます。| |=16にタグ付けをしてください: ヌル| |特定されたこれらの2| |=17にタグ付けをしてください: ヌル| |紹介された創始者| |=32にタグ付けをしてください: ヌル| |iSNS| | | |*************************/| DevAttrQryRsp--->|、|、| |成功| | | |=16にタグ付けをしてください: 192.0.2.5 | | | |=17にタグ付けをしてください: 5001 | | | |=32にタグ付けをしてください: "NAMEabcd"| | +--------------------------+------------------+-------------------+
Tseng, et al. Standards Track [Page 113] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[113ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
A.1.2. Target Registration and DD Configuration
A.1.2。 目標登録とDD構成
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.
この例では、2Storage Nodesと2PortalsがESIモニターを使用している状態で、より複雑な目標はiSNSとともに記名します。 Fully Qualified Domain Name(FQDN)によってこの目標はDNSサーバで構成されました、そして、ユーザはデバイスにこの識別子を使用したがっています。 目標は、各Portalがどう各Storage Nodeへのアクセスを提供するかを説明するために明らかにPortal Groupsを登録します。 Storage Nodeが許容する1個の目標が両方のPortalsを通したアクセスを調整しました。 もう片方のStorage Nodeは連携アクセスではなく、両方のPortalsを通したアクセスを許します。
+--------------------------+------------------+-------------------+ | iSCSI Target Device | iSNS Server |Management Station | +--------------------------+------------------+-------------------+ |Discover iSNS--SLP--> | |/*mgmt station is | | |<--SLP--iSNS Here:| administratively | | | 192.0.2.100 | authorized to view| | DevAttrReg--> | | all DDs */ | |Src: | | | |tag=32: "NAMEabcd" | | | |Msg Key: | | | |tag=1: "jbod1.example.com"| | | |Oper Attrs: | | | |tag=1: "jbod1.example.com"| | | |tag=2: "iSCSI" | | | |tag=16: 192.0.2.4 | | | |tag=17: 5001 | | | |tag=19: 5 | | | |tag=20: 5002 | | | |tag=16: 192.0.2.5 | | | |tag=17: 5001 | | | |tag=19: 5 | | | |tag=20: 5002 | | | |tag=32: "NAMEabcd" | | | |tag=33: "Target" | | | |tag=34: "Storage Array 1" | | | |tag=51: 10 | | | |tag=49: 192.0.2.4 | | | |tag=50: 5001 | | | |tag=49: 192.0.2.5 | | | |tag=50: 5001 | | | |tag=32: "NAMEefgh" | | | |tag=33: "Target" | | | |tag=34: "Storage Array 2" |/*****************| | |tag=51: 20 |jbod1.example.com is | |tag=49: 192.0.2.4 |now registered in | | |tag=50: 5001 |iSNS, but is not | |
+--------------------------+------------------+-------------------+ | iSCSI対象装置| iSNSサーバ|管理局| +--------------------------+------------------+-------------------+ |iSNS--SLP-->を発見してください。| |/*管理ステーションはそうです。| | | <--SLP--、iSNS Here:、|、行政上。| | | 192.0.2.100 | 視点に認可されます。| | DevAttrReg-->。| | すべてのDDs*/| |Src: | | | |=32にタグ付けをしてください: "NAMEabcd"| | | |エムエスジーキー: | | | |=1にタグ付けをしてください: "jbod1.example.com"| | | |Oper Attrs: | | | |=1にタグ付けをしてください: "jbod1.example.com"| | | |=2にタグ付けをしてください: "iSCSI"| | | |=16にタグ付けをしてください: 192.0.2.4 | | | |=17にタグ付けをしてください: 5001 | | | |=19にタグ付けをしてください: 5 | | | |=20にタグ付けをしてください: 5002 | | | |=16にタグ付けをしてください: 192.0.2.5 | | | |=17にタグ付けをしてください: 5001 | | | |=19にタグ付けをしてください: 5 | | | |=20にタグ付けをしてください: 5002 | | | |=32にタグ付けをしてください: "NAMEabcd"| | | |=33にタグ付けをしてください: 「目標」| | | |=34にタグ付けをしてください: 「ストレージ配列1インチ」| | | |=51にタグ付けをしてください: 10 | | | |=49にタグ付けをしてください: 192.0.2.4 | | | |=50にタグ付けをしてください: 5001 | | | |=49にタグ付けをしてください: 192.0.2.5 | | | |=50にタグ付けをしてください: 5001 | | | |=32にタグ付けをしてください: "NAMEefgh"| | | |=33にタグ付けをしてください: 「目標」| | | |=34にタグ付けをしてください: 「ストレージ配列2インチ」|/*****************| | |=51にタグ付けをしてください: 20 |jbod1.example.comはそうです。| |=49にタグ付けをしてください: 192.0.2.4 |現在、登録されます。| | |=50にタグ付けをしてください: 5001 |iSNS、存在でない| |
Tseng, et al. Standards Track [Page 114] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[114ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
|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" |
| =51にタグ付けをしてください: 30 |どんなDDでも。 したがって| |=49にタグ付けをしてください: 192.0.2.5 |対向機器がありません。| | |=50にタグ付けをしてください: 5001 |それを「見ることができます」。 | | | |*****************/| | | | <--DevAttrRegRsp| | | |成功| | | |エムエスジーキー: | | | |=1にタグ付けをしてください: "jbod1.example.com"| | |Oper Attrs: | | | |=1にタグ付けをしてください: "jbod1.example.com"| | |=2にタグ付けをしてください: "iSCSI"| | | |=16にタグ付けをしてください: 192.0.2.4 | | | |=17にタグ付けをしてください: 5001 | | | |=19にタグ付けをしてください: 5 | | | |=20にタグ付けをしてください: 5002 | | | |=16にタグ付けをしてください: 192.0.2.5 | | | |=17にタグ付けをしてください: 5001 | | | |=19にタグ付けをしてください: 5 | | | |=20にタグ付けをしてください: 5002 | | | |=32にタグ付けをしてください: "NAMEabcd"| | | |=33にタグ付けをしてください: 「目標」| | | |=34にタグ付けをしてください: 「ストレージ配列1インチ」| | |=48にタグ付けをしてください: "NAMEabcd"| | | |=49にタグ付けをしてください: 192.0.2.4 | | | |=50にタグ付けをしてください: 5001 | | | |=51にタグ付けをしてください: 10 | | | |=48にタグ付けをしてください: "NAMEabcd"| | | |=49にタグ付けをしてください: 192.0.2.5 | | | |=50にタグ付けをしてください: 5001 | | | |=51にタグ付けをしてください: 10 | | | |=32にタグ付けをしてください: "NAMEefgh"| | | |=33にタグ付けをしてください: 「目標」| | | |=34にタグ付けをしてください: 「ストレージ配列2インチ」| | |=43にタグ付けをしてください: X.509本命| | | |=48にタグ付けをしてください: "NAMEefgh"| | | |=49にタグ付けをしてください: 192.0.2.4 | | | |=50にタグ付けをしてください: 5001 | | | |=51にタグ付けをしてください: 20 | | | |=48にタグ付けをしてください: "NAMEefgh"| | | |=49にタグ付けをしてください: 192.0.2.5 | | | |=50にタグ付けをしてください: 5001 | | | |=51にタグ付けをしてください: 30 | | | | | | | | SCN------>|、|、|、| (または、SNMP通知) | | |dest: (タグ=32)"mgmt.example.com"| | |時間: (タグ=4): <現在の時間>。| | |=35にタグ付けをしてください: 「MGT-SCN、OBJ加えてください」|
Tseng, et al. Standards Track [Page 115] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[115ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
| |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
| |=32にタグ付けをしてください: "NAMEabcd"| | | |=35にタグ付けをしてください: 「MGT-SCN、OBJ加えてください」| | |=32にタグ付けをしてください: "NAMEefgh"| | | | | <--SCNRsp| | | |成功| | | タグ=32: "mgmt.example.com"| | | | | | | | <--DevAttrQry| | | |Src: | | | タグ=32: "mgmt.example.com"| | |エムエスジーキー: | | | |=32にタグ付けをしてください: "NAMEabcd"| | | |Oper Attrs: | | | |=16にタグ付けをしてください: <0長さの>。| | | |=17にタグ付けをしてください: <0長さの>。| | | |=32にタグ付けをしてください: <0長さの>。| | | | | | | DevAttrQryRsp-->。| | | |成功| | | |エムエスジーキー: | | | |=32にタグ付けをしてください: "NAMEabcd"| | | |Oper Attrs: | | | |=16にタグ付けをしてください: 192.0.2.4 | | | |=17にタグ付けをしてください: 5001 | | | |タグ=32: "NAMEabcd"| | | |=16にタグ付けをしてください: 192.0.2.5 | | | |=17にタグ付けをしてください: 5001 | | | |タグ=32: "NAMEabcd"| | | | |Src: | | | タグ=32: "mgmt.example.com"| | |エムエスジーキー: | | | |=32にタグ付けをしてください: "NAMEefgh"| | | |Oper Attrs: | | | |=16にタグ付けをしてください: <0長さの>。| | | |=17にタグ付けをしてください: <0長さの>。| | | |=32にタグ付けをしてください: <0長さの>。| | | | | | | DevAttrQryRsp-->。| | | |成功| | | |エムエスジーキー: | | | |=32にタグ付けをしてください: "NAMEefgh"| | | |Oper Attrs: | | | |=16にタグ付けをしてください: 192.0.2.4 | | | |=17にタグ付けをしてください: 5001 | | | |タグ=32: "NAMEefgh"| | | |=16にタグ付けをしてください: 192.0.2.5 |/**管理駅***| | |=17にタグ付けをしてください: 5001 |デバイスを表示します。| | |タグ=32: "NAMEefgh"|オペレータは決めます。
Tseng, et al. Standards Track [Page 116] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[116ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
| | |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 | | +--------------------------+------------------+-------------------+
| | |"NAMEabcd"を置くために| | | |ドメイン"DDxyz"に| |/*************************| |******************/| |目標は現在、登録されます。| | | |iSNSで。 そして、それは置かれます。| | <--DDReg| |先在のDD| |Src: | |管理によるDD_ID123| タグ=32: "mgmt.example.com"|ステーション。 | |エムエスジーキー: | |*************************/| |=2065にタグ付けをしてください: 123 | | | |Oper Attrs: | | | |=2068にタグ付けをしてください: "NAMEabcd"| | DDRegRsp----->|、|、| |成功| | | |エムエスジーキー: | | | |=2065にタグ付けをしてください: 123 | | | |Oper Attrs: | | | |=2065にタグ付けをしてください: 123 | | +--------------------------+------------------+-------------------+
A.1.3. Initiator Registration and Target Discovery
A.1.3。 創始者登録と目標発見
The following example illustrates a new initiator registering with the iSNS, and discovering the target NAMEabcd from the example in A.1.2.
以下の例はA.1.2の例からiSNSとともに記名して、目標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 | | |
+--------------------------+------------------+-------------------+ | iSCSI創始者| iSNS|管理局| +--------------------------+------------------+-------------------+ |iSNS--SLP-->を発見してください。| |/*管理ステーションはそうです。| | | <--SLP--、iSNS Here:、|、行政上。| | | 192.36.53.1 | 視点に認可されます。| |DevAttrReg-->。| | すべてのDDs********/| |Src: | | | |=32にタグ付けをしてください: "NAMEijkl"| | | |エムエスジーキー: | | | |=1にタグ付けをしてください: "svr1.example.com"| | | |Oper Attrs: | | | |=1にタグ付けをしてください: "svr1.example.com"| | | |=2にタグ付けをしてください: "iSCSI"| | | |=16にタグ付けをしてください: 192.20.3.1 |/*****************| | |=17にタグ付けをしてください: 5001 |いずれでないところのデバイス| | |=19にタグ付けをしてください: 5 |それはDDによってです| | |=20にタグ付けをしてください: 5002 |近づきがたい| | |=32にタグ付けをしてください: "NAMEijkl"|対向機器| | |=33にタグ付けをしてください: 「創始者」|*****************/| | |=34にタグ付けをしてください: "Server1""| | | |=51にタグ付けをしてください: 11 | | | |=49にタグ付けをしてください: 192.20.3.1 | | |
Tseng, et al. Standards Track [Page 117] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[117ページ]RFC4171インターネットストレージ名前サービス(iSNS)2005年9月
|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> |
| =50にタグ付けをしてください: 5001 | | | | | <--DevAttrRegRsp| | | |成功| | | |エムエスジーキー: | | | |=1にタグ付けをしてください: "svr1.example.com"| | |Oper Attrs: | | | |=1にタグ付けをしてください: "svr1.example.com"| | |=2にタグ付けをしてください: "iSCSI"| | | |=16にタグ付けをしてください: 192.20.3.1| | | |=17にタグ付けをしてください: 5001 | | | |=19にタグ付けをしてください: 5 | | | |=20にタグ付けをしてください: 5002 | | | |=32にタグ付けをしてください: "NAMEijkl"| | | |=33にタグ付けをしてください: 「創始者」| | |=34にタグ付けをしてください: "Server1""| | | |=48にタグ付けをしてください: "NAMEijkl"| | | |=49にタグ付けをしてください: 192.20.3.1| | | |=50にタグ付けをしてください: 5001 | | | |=51にタグ付けをしてください: 11 | | | | | | | | SCN------>|、|、|、| (または、SNMP通知) | | |dest: (タグ=32)"mgmt.example.com"| | |時間: (タグ=4): <現在の時間>。| | |=35にタグ付けをしてください: 「MGT-SCN、OBJ加えてください」| | |=32にタグ付けをしてください: "NAMEijkl"| | | | | | | | | <、-、-、-、-、--SCNRsp| | | |成功| | | タグ=32: "mgmt.example.com"| | | | |SCNReg-->。| | | |Src: | | | |=32にタグ付けをしてください: "NAMEijkl"| | | |エムエスジーキー: | | | |=32にタグ付けをしてください: "NAMEijkl"| | | |Oper Attrs: | | | |=35にタグ付けをしてください: <ターグと自己、OBJ-RMV/は/UPD>を加えます。| | | | <--SCNRegRsp| | | |成功| | | | | | | | | <、-、-、--DevAttrQry| | | |Src: | | | タグ=32: "mgmt.example.com"| | |エムエスジーキー: | | | |=32にタグ付けをしてください: "NAMEijkl"| | | |Oper Attrs: | | | |=16にタグ付けをしてください: <0長さの>。|
Tseng, et al. Standards Track [Page 118] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[118ページ]RFC4171インターネット格納名前サービス(iSNS)2005年9月
| | |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> |
| | |=17にタグ付けをしてください: <0長さの>。| | | |=32にタグ付けをしてください: <0長さの>。| | | DevAttrQryRsp--->|、|、| |成功| | | |エムエスジーキー: | | | |=32にタグ付けをしてください: "NAMEijkl"| | | |Oper Attrs: | | | |タグ=16: 192.20 .3、.1| | | |=17にタグ付けをしてください: 5001 | | | |タグ=32: "NAMEijkl"| | | | |/**管理駅***| | | |装置を表示します。| | |オペレータは、決めます。| | | |"NAMEijkl"を置きます。| | |Discを先在させます。| | | |ドメイン"DDxyz"| | | |装置NAMEabcd| | | |******************/| | | | <--DDReg| | | |Src: | | | タグ=32: "mgmt.example.com"| | |エムエスジーキー: | | | |=2065にタグ付けをしてください: 123 | | | |Oper Attrs: | | | |=2068にタグ付けをしてください: "NAMEijkl"| | | | | | DDRegRsp---->|、|、| |成功| | | |エムエスジーキー: | | | |=2065にタグ付けをしてください: 123 | | | |Oper Attrs: | | | |=2065にタグ付けをしてください: 123 |/******************| | | |"NAMEijkl"がありました。| | | |"DDxyz"に動かされます。| | | |******************/| | | SCN------>|、|、| |dest: (タグ=32)"mgmt.example.com"| | |時間: (タグ=4): <現在の時間>。| | |=35にタグ付けをしてください: <MGT-SCN、>をDD/DDS-MBR加えてください。| | |=2065にタグ付けをしてください: 123 | | | |=2068にタグ付けをしてください: "NAMEijkl"| | | | | | | | <、-、-、-、-、--SCNRsp| | | |成功| | | タグ=32: "mgmt.example.com"| | <、-、-、-、--SCN| | | |dest: (タグ=32)"NAMEijkl"| | |時間: (タグ=4): <現在の時間>。|
Tseng, et al. Standards Track [Page 119] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[119ページ]RFC4171インターネット格納名前サービス(iSNS)2005年9月
| |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"| |
| |=35にタグ付けをしてください: <ターグと自己は>をOBJ加えてください。| | |=32にタグ付けをしてください: "NAMEijkl"| | | SCNRsp------>|、|、| |成功| | | |タグ=32: "NAMEijkl"| | | | | | | | |/*****************| | | |そのNAMEabcdに注意してください。| | | |また、受信します。| | | |SCNはそのNAMEijklです。| | | |同じDDに、あります。| | | |*****************/| | | ("NAMEabcd"への)| <、-、-、-、--SCN| | | |dest: (タグ=32)"NAMEabcd"| | |時間: (タグ=4): <現在の時間>。| | |=35にタグ付けをしてください: <イニットと自己は>をOBJ加えてください。| | |=32にタグ付けをしてください: "NAMEijkl"| | | SCNRsp------>|、|、| |成功| | | |タグ=32: "NAMEabcd"| | | | | | | | DevAttrQry----------->|、|、| |Src: | | | |=32にタグ付けをしてください: "NAMEijkl"| | | |エムエスジーキー: | | | |=33にタグ付けをしてください: 「目標」| | | |Oper Attrs: | | | |=16にタグ付けをしてください: <0長さの>。| | | |=17にタグ付けをしてください: <0長さの>。| | | |=32にタグ付けをしてください: <0長さの>。| | | |=34にタグ付けをしてください: <0長さの>。| | | |=43にタグ付けをしてください: <0長さの>。| | | |=48にタグ付けをしてください: <0長さの>。| | | |=49にタグ付けをしてください: <0長さの>。| | | |=50にタグ付けをしてください: <0長さの>。| | | |=51にタグ付けをしてください: <0長さの>。| | | | | <--DevAttrQryRsp| | | |成功| | | |エムエスジーキー: | | | |タグ=33: 「目標」| | | |Oper Attrs: | | | |=16にタグ付けをしてください: 192.0.2.4 | | | |=17にタグ付けをしてください: 5001 | | | |=32にタグ付けをしてください: "NAMEabcd"| | | |=34にタグ付けをしてください: 「格納アレイ1インチ」| | |=16にタグ付けをしてください: 192.0.2.5 | | | |=17にタグ付けをしてください: 5001 | | | |=32にタグ付けをしてください: "NAMEabcd"| |
Tseng, et al. Standards Track [Page 120] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[120ページ]RFC4171インターネット格納名前サービス(iSNS)2005年9月
| |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.************/ | | +--------------------------+------------------+-------------------+
| |=34にタグ付けをしてください: 「格納アレイ1インチ」| | |=43にタグ付けをしてください: X.509本命| | | |=48にタグ付けをしてください: "NAMEabcd"| | | |=49にタグ付けをしてください: 192.0.2.4 | | | |=50にタグ付けをしてください: 5001 | | | |=51にタグ付けをしてください: 10 | | | |=48にタグ付けをしてください: "NAMEabcd"| | | |=49にタグ付けをしてください: 192.0.2.5 | | | |=50にタグ付けをしてください: 5001 | | | |=51にタグ付けをしてください: 10 | | | | | | |創始者が発見した/***| | |すべてを狙って、持っています。| | |iSCSIログインを終了するために、必要です。| | |同じ過程は起こります。| | |側を狙ってください。 SCNはうながします。| | |リストをダウンロードする目標| | |創始者に権限を与えます。| | |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).
多数の個人は彼らの慎重なレビューによるこのドキュメントの創造とコメントと推薦の差出に貢献しました。 私たちはこのドキュメントへの彼らの技術的な貢献のために以下の人々を承認します: バッキーが(シスコ)であるとマークしてください、ジョンHufferd(IBM)、ジュリアンSatran(IBM)、Kaladhar Voruganti(IBM)、ジョーCzap(IBM)、ジョンDowdy(IBM)、トムMcSweeney(IBM)、ジム・ハーフナー(IBM)、Chadグレゴリー(インテル)、ヤロンクライン(Sanrad)、ラリーLamers(Adaptec)、ジャックHarwood(EMC)、デヴィッドBlack(EMC)、デイビッド・ロビンソン(Sun); アランウォリック(マイクロソフト)、ボブ・スニード(マイクロソフト)、ファYoeu(Intransa)、ジョー・ホワイト(McDATA)、チャールズMonia(McDATA)、ラリーホーファー(McDATA)、ケン平田(Vixel)、ハワードHall(Pirus)、Malikarjun Chadalapaka(hp)、マージョリー・クルーガー(hp)、シバVaddepuri(McDATA)、およびVinaiシン(アメリカの大勢)。
Tseng, et al. Standards Track [Page 121] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[121ページ]RFC4171インターネット格納名前サービス(iSNS)2005年9月
Authors' Addresses
作者のアドレス
Josh Tseng Riverbed Technology 501 2nd Street, Suite 410 San Francisco, CA 94107
第2通り、ジョッシュツェン川床技術501Suite410サンフランシスコ、カリフォルニア 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
グレート・アメリカParkwayサンタクララ、ケビンギボンズMcDATA社4555のカリフォルニア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
フランコTravostinoノーテル600技術公園Drive MA01821ビルリカ(米国)
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
北部ウィルモットRoad、そっけないduレーニーリンコンResearch社101のSuite101ツーソン・アリゾナ 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
ジョースザマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052-6399
Phone: (425) 706-3135 EMail: joes@exmsft.com
以下に電話をしてください。 (425) 706-3135 メールしてください: joes@exmsft.com
Tseng, et al. Standards Track [Page 122] RFC 4171 Internet Storage Name Service (iSNS) September 2005
ツェン、他 標準化過程[122ページ]RFC4171インターネット格納名前サービス(iSNS)2005年9月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Tseng, et al. Standards Track [Page 123]
ツェン、他 標準化過程[123ページ]
一覧
スポンサーリンク
