Network Working Group C. Monia
Request for Comments: 4172 Consultant
Category: Standards Track R. Mullendore
McDATA
F. Travostino
Nortel
W. Jeong
Troika Networks
M. Edwards
Adaptec (UK) Ltd.
September 2005
iFCP - A Protocol for Internet Fibre Channel Storage Networking
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This document specifies an architecture and a gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network. This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards. The architecture enables internetworking of fibre channel devices through gateway-accessed regions with the fault isolation properties of autonomous systems and the scalability of the IP network.
この文書では、IPネットワークを介してファイバチャネルファブリック機能を実装するためのアーキテクチャとゲートウェイ間のプロトコルを指定します。この機能は、ファイバチャネルフレーム転送のためのTCPプロトコルおよびファイバチャネル規格で指定された分散型ファブリックサービスを通じて提供されます。アーキテクチャは、自律システムの障害分離特性とIPネットワークのスケーラビリティとゲートウェイアクセス領域を通してファイバチャネルデバイスのインターネットワーキングを可能にします。
Table of Contents
目次
1. Introduction.................................................. 4
1.1. Conventions used in This Document....................... 4
1.1.1. Data Structures Internal to an Implementation... 4
1.2. Purpose of This Document................................ 4
2. iFCP Introduction............................................. 4
2.1. Definitions............................................. 5
3. Fibre Channel Communication Concepts.......................... 7
3.1. The Fibre Channel Network............................... 8
3.2. Fibre Channel Network Topologies........................ 9
3.2.1. Switched Fibre Channel Fabrics.................. 11
3.2.2. Mixed Fibre Channel Fabric...................... 12
3.3. Fibre Channel Layers and Link Services.................. 12
3.3.1. Fabric-Supplied Link Services................... 13
3.4. Fibre Channel Nodes..................................... 14
3.5. Fibre Channel Device Discovery.......................... 14
3.6. Fibre Channel Information Elements...................... 15
3.7. Fibre Channel Frame Format.............................. 15
3.7.1. N_PORT Address Model............................ 16
3.8. Fibre Channel Transport Services........................ 17
3.9. Login Processes......................................... 18
4. The iFCP Network Model........................................ 18
4.1. iFCP Transport Services................................. 21
4.1.1. Fibre Channel Transport Services Supported by
iFCP............................................ 21
4.2. iFCP Device Discovery and Configuration Management...... 21
4.3. iFCP Fabric Properties.................................. 22
4.3.1. Address Transparency............................ 22
4.3.2. Configuration Scalability....................... 23
4.3.3. Fault Tolerance................................. 23
4.4. The iFCP N_PORT Address Model........................... 24
4.5. Operation in Address Transparent Mode................... 25
4.5.1. Transparent Mode Domain ID Management........... 26
4.5.2. Incompatibility with Address Translation Mode... 26
4.6. Operation in Address Translation Mode................... 27
4.6.1. Inbound Frame Address Translation............... 28
4.6.2. Incompatibility with Address Transparent Mode... 29
5. iFCP Protocol................................................. 29
5.1. Overview ............................................... 29
5.1.1. iFCP Transport Services......................... 29
5.1.2. iFCP Support for Link Services.................. 30
5.2. TCP Stream Transport of iFCP Frames..................... 30
5.2.1. iFCP Session Model.............................. 30
5.2.2. iFCP Session Management......................... 31
5.2.3. Terminating iFCP Sessions....................... 39
5.3. Fibre Channel Frame Encapsulation....................... 40
5.3.1. Encapsulation Header Format..................... 41
5.3.2. SOF and EOF Delimiter Fields.................... 44
5.3.3. Frame Encapsulation............................. 45
5.3.4. Frame De-encapsulation.......................... 46
6. TCP Session Control Messages.................................. 47
6.1. Connection Bind (CBIND)................................. 50
6.2. Unbind Connection (UNBIND).............................. 52
6.3. LTEST -- Test Connection Liveness....................... 54
7. Fibre Channel Link Services................................... 55
7.1. Special Link Service Messages........................... 56
7.2. Link Services Requiring Payload Address Translation..... 58
7.3. Fibre Channel Link Services Processed by iFCP........... 61
7.3.1. Special Extended Link Services.................. 63
7.3.2. Special FC-4 Link Services...................... 83
7.4. FLOGI Service Parameters Supported by an iFCP Gateway... 84
8. iFCP Error Detection.......................................... 86
8.1. Overview................................................ 86
8.2. Stale Frame Prevention.................................. 86
8.2.1. Enforcing R_A_TOV Limits........................ 86
9. Fabric Services Supported by an iFCP Implementation........... 88
9.1. F_PORT Server........................................... 88
9.2. Fabric Controller....................................... 89
9.3. Directory/Name Server................................... 89
9.4. Broadcast Server........................................ 89
9.4.1. Establishing the Broadcast Configuration........ 90
9.4.2. Broadcast Session Management.................... 91
9.4.3. Standby Global Broadcast Server................. 91
10. iFCP Security................................................. 91
10.1. Overview................................................ 91
10.2. iFCP Security Threats and Scope......................... 92
10.2.1. Context......................................... 92
10.2.2. Security Threats................................ 92
10.2.3. Interoperability with Security Gateways......... 93
10.2.4. Authentication.................................. 93
10.2.5. Confidentiality................................. 93
10.2.6. Rekeying........................................ 93
10.2.7. Authorization................................... 94
10.2.8. Policy Control.................................. 94
10.2.9. iSNS Role....................................... 94
10.3. iFCP Security Design.................................... 94
10.3.1. Enabling Technologies........................... 94
10.3.2. Use of IKE and IPsec............................ 96
10.3.3. Signatures and Certificate-Based Authentication. 98
10.4. iSNS and iFCP Security.................................. 99
10.5. Use of iSNS to Distribute Security Policy............... 99
10.6. Minimal Security Policy for an iFCP Gateway............. 99
11. Quality of Service Considerations.............................100
11.1. Minimal Requirements....................................100
11.2. High Assurance..........................................100
12. IANA Considerations...........................................101
13. Normative References..........................................101
14. Informative References........................................103
Appendix A. iFCP Support for Fibre Channel Link Services.........105
A.1. Basic Link Services.....................................105
A.2. Pass-Through Link Services..............................105
A.3. Special Link Services...................................107
Appendix B. Supporting the Fibre Channel Loop Topology...........108
B.1. Remote Control of a Public Loop.........................108
Acknowledgements..................................................109
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 BCP 14, RFC 2119 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
Unless specified otherwise, numeric quantities are given as decimal values.
特に指定しない限り、数値数量は小数点値として与えられています。
All diagrams that portray bit and byte ordering, including the depiction of structures defined by fibre channel standards, adhere to the IETF conventions whereby bit 0 is the most significant bit and the first addressable byte is in the upper left corner. This IETF convention differs from that used for INCITS T11 fibre channel standards, in which bit 0 is the least significant bit.
ファイバチャネル規格で定義された構造の描写を含むビットとバイト順を描くすべての図は、ビット0が最上位ビットであり、第一のアドレス指定バイトが左上隅にあることにより、IETFの規則に準拠しています。このIETF規則は0が最下位ビットであるビットたINCITS T11ファイバチャネル規格に使用されるものとは異なります。
To facilitate the specification of required behavior, this document may define and refer to internal data structures within an iFCP implementation. Such structures are intended for explanatory purposes only and need not be instantiated within an implementation as described in this specification.
必要な動作の指定を容易にするために、このドキュメントは、定義とのiFCP実装内の内部データ構造を参照することができます。このような構造は、説明の目的のために意図されており、本明細書に記載されるように実装内でインスタンス化される必要はありません。
This is a standards-track document that specifies a protocol for the implementation of fibre channel transport services on a TCP/IP network. Some portions of this document contain material from standards controlled by INCITS T10 and T11. This material is included here for informational purposes only. The authoritative information is given in the appropriate NCITS standards document.
これは、TCP / IPネットワーク上のファイバー・チャネル・トランスポート・サービスの実装のためのプロトコルを指定する標準トラック文書です。このドキュメントの一部はINCITS T10とT11によって制御の基準から材料を含んでいます。この材料は、情報提供のみを目的としてここに含まれます。正式な情報は、適切なNCITS規格文書に記載されています。
The authoritative portions of this document specify the mapping of standards-compliant fibre channel protocol implementations to TCP/IP. This mapping includes sections of this document that describe the "iFCP Protocol" (see Section 5).
このドキュメントの正式な部分は、TCP / IPの標準に準拠したファイバ・チャネル・プロトコル実装のマッピングを指定します。このマッピングは、「のiFCPプロトコル」（5節を参照）を記述し、この文書のセクションが含まれています。
iFCP is a gateway-to-gateway protocol that provides fibre channel fabric services to fibre channel devices over a TCP/IP network. iFCP uses TCP to provide congestion control, error detection, and recovery. iFCP's primary objective is to allow interconnection and networking of existing fibre channel devices at wire speeds over an IP network.
iFCPゲートは、TCP / IPネットワークを介してファイバチャネルデバイスにファイバチャネルファブリックサービスを提供するゲートウェイ間のプロトコルです。 iFCPは、輻輳制御、エラー検出、およびリカバリを実現するためにTCPを使用しています。 iFCPゲートの第一の目的は、IPネットワーク上でワイヤスピードで既存のファイバー・チャネル・デバイスの相互接続およびネットワーキングを可能にすることです。
The protocol and method of frame address translation described in this document permit the attachment of fibre channel storage devices to an IP-based fabric by means of transparent gateways.
この文書に記載されたフレームアドレス変換のプロトコルおよび方法は、透明ゲートウェイによってIPベースのファブリックへのファイバ・チャネル・ストレージ・デバイスの取り付けを可能にします。
The protocol achieves this transparency by allowing normal fibre channel frame traffic to pass through the gateway directly, with provisions, where necessary, for intercepting and emulating the fabric services required by a fibre channel device.
プロトコルは、通常のファイバ・チャネル・フレーム・トラフィックは、ファイバチャネルデバイスによって要求されるファブリックサービスを遮断し、エミュレートするため、必要な規定を用いて、直接ゲートウェイを通過させることにより、この透明度を達成します。
Terms needed to describe the concepts presented in this document are presented here.
この文書で説明する概念を記述するために必要な用語がここに提示されています。
Address-translation mode -- A mode of gateway operation in which the scope of N_PORT fabric addresses, for locally attached devices, are local to the iFCP gateway region in which the devices reside.
アドレス変換モード - Nポートのファブリック・アドレスの範囲は、ローカルに接続されたデバイスのために、デバイスが存在するのiFCPゲートウェイ領域にローカルされたゲートウェイの動作モード。
Address-transparent mode -- A mode of gateway operation in which the scope of N_PORT fabric addresses, for all fibre channel devices, are unique to the bounded iFCP fabric to which the gateway belongs.
アドレストランスペアレントモード - Nポートのファブリック・アドレスの範囲は、すべてのファイバチャネルデバイスのために、ゲートウェイが属する境界のiFCPファブリックに一意されたゲートウェイの動作モード。
Bounded iFCP Fabric -- The union of two or more gateway regions configured to interoperate in address-transparent mode.
有界のiFCPファブリック - アドレストランスペアレントモードで相互運用するように構成された2つの以上のゲートウェイ領域の和集合。
DOMAIN_ID -- The value contained in the high-order byte of a 24-bit N_PORT fibre channel address.
DOMAIN_ID - 24ビットN_PORTファイバ・チャネル・アドレスの上位バイトに含まれる値。
F_PORT -- The interface used by an N_PORT to access fibre channel switched-fabric functionality.
F_PORT - ファイバチャネルスイッチ・ファブリックの機能にアクセスするN_PORTによって使用されるインタフェース。
Fabric -- From [FC-FS]: "The entity that interconnects N_PORTs attached to it and is capable of routing frames by using only the address information in the fibre channel frame."
ファブリック - [FC-FS]から：「それに取り付けられたN_ポートを相互に接続し、ファイバチャネルフレームにのみアドレス情報を用いてフレームをルーティングすることが可能である実体。」
Fabric Port -- The interface through which an N_PORT accesses a fibre channel fabric. The type of fabric port depends on the fibre channel fabric topology. In this specification, all fabric port interfaces are considered functionally equivalent.
ファブリックポート - N_PORTは、ファイバチャネルファブリックにアクセスするためのインターフェイス。ファブリックポートの種類は、ファイバチャネルファブリックトポロジに依存します。本明細書では、すべてのファブリック・ポート・インターフェースは、機能的に等価であると考えられます。
FC-2 -- The fibre channel transport services layer, described in [FC-FS].
FC-2 - [FC-FS]に記載のファイバチャネルトランスポート・サービス層、。
FC-4 -- The fibre channel mapping of an upper-layer protocol, such as [FCP-2], the fibre channel to SCSI mapping.
FC-4 - 上位層プロトコルのファイバ・チャネル・マッピング、など[FCP-2]、SCSIへのマッピングファイバチャネル。
Fibre Channel Device -- An entity implementing the functionality accessed through an FC-4 application protocol.
ファイバチャネルデバイス - FC-4アプリケーションプロトコルを介してアクセス機能を実装するエンティティ。
Fibre Channel Network -- A native fibre channel fabric and all attached fibre channel nodes.
ファイバチャネルネットワーク - ネイティブのファイバ・チャネル・ファブリックおよび接続されているすべてのファイバー・チャネル・ノード。
Fibre Channel Node -- A collection of one or more N_PORTs controlled by a level above the FC-2 layer. A node is attached to a fibre channel fabric by means of the N_PORT interface, described in [FC-FS].
ファイバ・チャネル・ノード - FC-2層以上のレベルによって制御される1つのまたは複数のN_ポートのコレクション。ノードは、[FC-FS]に記載の、N_ポートインタフェースによって、ファイバチャネルファブリックに接続されています。
Gateway Region -- The portion of an iFCP fabric accessed through an iFCP gateway by a remotely attached N_PORT. Fibre channel devices in the region consist of all those locally attached to the gateway.
ゲートウェイリージョン - リモート取り付けN_PORTによってiFCPゲートゲートウェイを介してアクセスのiFCP布の部分。領域内のファイバ・チャネル・デバイスは、ローカルゲートウェイに接続されているすべてのものから成ります。
iFCP -- The protocol discussed in this document.
iFCP - 本書で説明したプロトコル。
iFCP Frame -- A fibre channel frame encapsulated in accordance with the FC Frame Encapsulation Specification [ENCAP] and this specification.
iFCPフレーム - FCフレームのカプセル化仕様[ENCAP]本明細書に従ったカプセル化されたファイバチャネルフレーム。
iFCP Portal -- An entity representing the point at which a logical or physical iFCP device is attached to the IP network. The network address of the iFCP portal consists of the IP address and TCP port number to which a request is sent when the TCP connection is created for an iFCP session (see Section 5.2.1).
iFCPポータル - 論理的または物理的のiFCPデバイスがIPネットワークに接続される点を表すエンティティ。 iFCPポータルのネットワークアドレスは、IPアドレスやTCP接続がのiFCPセッションのために作成されたときに、要求が送信されるTCPポート番号（5.2.1項を参照）で構成されています。
iFCP Session -- An association comprised of a pair of N_PORTs and a TCP connection that carries traffic between them. An iFCP session may be created as the result of a PLOGI fibre channel login operation.
iFCPセッション - のN_Portのペアとそれらの間のトラフィックを運ぶTCPコネクションで構成される団体。 iFCPセッションはPLOGIファイバチャネルログイン操作の結果として作成されてもよいです。
iSNS -- The server functionality and IP protocol that provide storage name services in an iFCP network. Fibre channel name services are implemented by an iSNS name server, as described in [ISNS].
iSNS - サーバーの機能とのiFCPネットワーク内のストレージネームサービスを提供するIPプロトコル。 [ISNS]で説明されるように、ファイバチャネルネームサービスは、iSNSのネームサーバによって実装されます。
Locally Attached Device -- With respect to a gateway, a fibre channel device accessed through the fibre channel fabric to which the gateway is attached.
ゲートウェイが接続されているゲートウェイ、ファイバ・チャネル・ファブリックを介してアクセスファイバチャネルデバイスに関して - ローカルデバイスが取り付けられています。
Logical iFCP Device -- The abstraction representing a single fibre channel device as it appears on an iFCP network.
論理のiFCPデバイス - それはのiFCPネットワークに表示される単一のファイバチャネルデバイスを表す抽象。
N_PORT -- An iFCP or fibre channel entity representing the interface to fibre channel device functionality. This interface implements the fibre channel N_PORT semantics, specified in [FC-FS]. Fibre channel defines several variants of this interface that depend on the fibre channel fabric topology. As used in this document, the term applies equally to all variants.
N_PORT - ファイバ・チャネル・デバイスの機能へのインタフェースを表すのiFCPまたはファイバチャネルエンティティ。このインタフェースは、[FC-FS]で指定されたファイバチャネルN_PORTセマンティクスを実装します。ファイバーチャネルは、ファイバー・チャネル・ファブリック・トポロジに依存し、このインタフェースのいくつかのバリアントを定義しています。この文書で使用されるように、用語は、全ての変異体にも同様に適用されます。
N_PORT Alias -- The N_PORT address assigned by a gateway to represent a remote N_PORT accessed via the iFCP protocol.
N_PORT別名 - ゲートウェイによって割り当てられたN_PORTアドレスのiFCPプロトコルを介してアクセスされるリモートN_PORTを表現します。
N_PORT fabric address -- The address of an N_PORT within the fibre channel fabric.
Nポートのファブリックアドレス - ファイバ・チャネル・ファブリック内N_PORTのアドレス。
N_PORT ID -- The address of a locally attached N_PORT within a gateway region. N_PORT IDs are assigned in accordance with the fibre channel rules for address assignment, specified in [FC-FS].
NポートID - ゲートウェイ領域内のローカル接続N_PORTのアドレス。 NポートIDは、[FC-FS]で指定され、アドレス割り当てのためのファイバチャネル規則に従って割り当てられます。
N_PORT Network Address -- The address of an N_PORT in the iFCP fabric. This address consists of the IP address and TCP port number of the iFCP Portal and the N_PORT ID of the locally attached fibre channel device.
N_PORTネットワークアドレス - のiFCPファブリック内のN_PORTのアドレス。このアドレスは、iFCPゲートポータルのIPアドレスとTCPポート番号とローカルに接続されたファイバ・チャネル・デバイスのNポートIDから成ります。
Port Login (PLOGI) -- The fibre channel Extended Link Service (ELS) that establishes an iFCP session through the exchange of identification and operation parameters between an originating N_PORT and a responding N_PORT.
ポートログイン（PLOGI） - リンクサービス（ELS）拡張ファイバチャネル発信N_PORTと応答N_PORT間の識別及び動作パラメータの交換を介してのiFCPセッションを確立します。
Remotely Attached Device -- With respect to a gateway, a fibre channel device accessed from the gateway by means of the iFCP protocol.
ゲートウェイに関して、iFCPゲートプロトコルによりゲートウェイからアクセスファイバチャネルデバイス - リモートデバイスに取り付けられています。
Unbounded iFCP Fabric -- The union of two or more gateway regions configured to interoperate in address-translation mode.
無制限のiFCPファブリック - アドレス変換モードで相互運用するように構成された2つの以上のゲートウェイ領域の和集合。
Fibre channel is a frame-based, serial technology designed for peer-to-peer communication between devices at gigabit speeds and with low overhead and latency.
ファイバチャネルは、ギガビット速度で、低オーバーヘッドと待ち時間とのデバイス間のピアツーピア通信のために設計されたフレームに基づく、シリアル技術です。
This section contains a discussion of the fibre channel concepts that form the basis for the iFCP network architecture and protocol described in this document. Readers familiar with this material may skip to Section 4.
このセクションでは、この文書に記載のiFCPネットワークアーキテクチャとプロトコルの基礎を形成するファイバチャネルの概念の議論を含んでいます。この資料に精通している読者は、セクション4にスキップできます。
Material presented in this section is drawn from the following T11 specifications:
このセクションに提示された資料は、次のT11仕様から引き出されます。
-- The Fibre Channel Framing and Signaling Interface, [FC-FS]
- ファイバチャネルフレーミングとシグナリングインターフェイス、[FC-FS]
-- Fibre Channel Switch Fabric -2, [FC-SW2]
- ファイバチャネルファブリック-2スイッチ、[FC-SW2]
-- Fibre Channel Generic Services, [FC-GS3]
- ファイバチャネル汎用サービス、[FC-GS3]
-- Fibre Channel Fabric Loop Attachment, [FC-FLA]
- ファイバチャネルファブリックループアタッチメント、[FC-FLA]
The reader will find an in-depth treatment of the technology in [KEMCMP] and [KEMALP].
読者は[KEMALP] [KEMCMP]における技術の詳細な処理を見つけます。
The fundamental entity in fibre channel is the fibre channel network. Unlike a layered network architecture, a fibre channel network is largely specified by functional elements and the interfaces between them. As shown in Figure 1, these consist, in part, of the following:
ファイバチャネルにおける基本的なエンティティは、ファイバチャネルネットワークです。層状ネットワークアーキテクチャとは異なり、ファイバ・チャネル・ネットワークは、主機能要素と、それらの間のインターフェイスで指定されています。図1に示すように、これらは、以下の、部分的には、構成されています。
a) N_PORTs -- The end points for fibre channel traffic. In the FC standards, N_PORT interfaces have several variants, depending on the topology of the fabric to which they are attached. As used in this specification, the term applies to any one of the variants.
A）N_ポート - ファイバーチャネルトラフィックのエンドポイント。 FC規格では、N_PORTインタフェースは、それらが結合している、ファブリックのトポロジに応じて、いくつかのバリエーションがあります。本明細書中で使用されるように、用語は、変種のいずれかに適用されます。
b) FC Devices -- The fibre channel devices to which the N_PORTs provide access.
B）FCデバイス - N_ポートがアクセスを提供するのファイバチャネルデバイス。
c) Fabric Ports -- The interfaces within a fibre channel network that provide attachment for an N_PORT. The types of fabric port depend on the fabric topology and are discussed in Section 3.2.
C）ファブリックポート - N_PORT用アタッチメントを提供するファイバチャネルネットワーク内のインターフェイス。ファブリックポートのタイプは、ファブリックトポロジに依存し、3.2節で議論されています。
d) The network infrastructure for carrying frame traffic between N_PORTs.
D）N_ポート間のフレームのトラフィックを搬送するためのネットワークインフラストラクチャ。
e) Within a switched or mixed fabric (see Section 3.2), a set of auxiliary servers, including a name server for device discovery and network address resolution. The types of service depend on the network topology.
e）の交換または混合ファブリック内（セクション3.2を参照）、装置発見及びネットワークアドレス解決のためのネームサーバを含む補助サーバのセットを、。サービスの種類は、ネットワークトポロジに依存します。
+--------+ +--------+ +--------+ +--------+
| FC | | FC | | FC | | FC |
| Device | | Device |<-------->| Device | | Device |
|........| |........| |........| |........|
| N_PORT | | N_PORT | | N_PORT | | N_PORT |
+---+----+ +----+---+ +----+---+ +----+---+
| | | |
+---+----+ +----+---+ +----+---+ +----+---+
| Fabric | | Fabric | | Fabric | | Fabric |
| Port | | Port | | Port | | Port |
+========+===+========+==========+========+==+========+
| Fabric |
| & |
| Fabric Services |
+-----------------------------------------------------+
Figure 1. A Fibre Channel Network
図1. Aファイバー・チャネル・ネットワーク
The following sections describe fibre channel network topologies and give an overview of the fibre channel communications model.
以下のセクションでは、ファイバ・チャネル・ネットワークトポロジを記述し、ファイバチャネル通信モデルの概要を与えます。
The principal fibre channel network topologies consist of the following:
主ファイバ・チャネル・ネットワーク・トポロジは、以下から成ります：
a) Arbitrated Loop -- A series of N_PORTs connected together in daisy-chain fashion. In [FC-FS], loop-connected N_PORTs are referred to as NL_PORTs. Data transmission between NL_PORTs requires arbitration for control of the loop in a manner similar to that of a token ring network.
A）調停ループ - デイジーチェーン方式で互いに接続N_ポートの一連。 [FC-FS]において、ループ接続N_ポートはNL_PORTsと呼ばれます。 NL_PORTs間のデータ伝送は、トークンリングネットワークと同様に、ループの制御のための調停が必要となります。
b) Switched Fabric -- A network consisting of switching elements, as described in Section 3.2.1.
B）ファブリックスイッチ - セクション3.2.1で説明したように、ネットワークは、スイッチング素子からなります。
c) Mixed Fabric -- A network consisting of switches and "fabric-attached" loops. A description can be found in [FC-FLA]. A loop-attached N_PORT (NL_PORT) is connected to the loop through an L_PORT and accesses the fabric by way of an FL_PORT.
C）混合ファブリック - スイッチと「ファブリック接続」ループからなるネットワーク。説明は、[FC-FLA]に見出すことができます。ループ付きN_PORT（NLポート）L_PORTをループに接続され、FLポートを介してファブリックにアクセスされます。
Depending on the topology, the N_PORT and its means of network attachment may be one of the following:
トポロジに応じて、ネットワーク接続のN_PORTとその手段は、次のいずれかを指定できます。
FC Network
Topology Network Interface N_PORT Variant
--------------- ----------------- --------------
Loop L_PORT NL_PORT
Switched F_PORT N_PORT
スイッチドF_PORT N_PORT
Mixed FL_PORT via L_PORT NL_PORT
L_PORT NLポートを経由して混合FLポート
F_PORT N_PORT
F_PORT N_PORT
The differences in each N_PORT variant and its corresponding fabric port are confined to the interactions between them. To an external N_PORT, all fabric ports are transparent, and all remote N_PORTs are functionally identical.
各N_PORT変異体とそれに対応するファブリックポートの違いは、それらの間の相互作用に限定されます。外部N_PORTに、すべてのファブリックポートは透明であり、そしてすべてのリモートN_ポートは機能的に同一です。
An example of a multi-switch fibre channel fabric is shown in Figure 2.
マルチスイッチファイバチャネルファブリックの例が図2に示されています。
+----------+ +----------+
| FC | | FC |
| Device | | Device |
|..........| |..........|
| N_PORT |<........>| N_PORT |
+----+-----+ +-----+----+
| |
+----+-----+ +-----+----+
| F_PORT | | F_PORT |
==========+==========+==========+==========+==============
| FC | | FC |
| Switch | | Switch |
+----------+ +----------+ Fibre Channel
|Inter- | |Inter- | Fabric
|Switch | |Switch |
|Interface | |Interface |
+-----+----+ +-----+----+
| |
| |
+-----+----+----------+-----+----+
|Inter- | |Inter- |
|Switch | |Switch |
|Interface | |Interface |
+----------+ +----------+
| FC Switch |
| |
+--------------------------------+
Figure 2. Multi-Switch Fibre Channel Fabric
図2.マルチスイッチのファイバチャネルファブリック
The interface between switch elements is either a proprietary interface or the standards-compliant E_PORT interface, which is described by the FC-SW2 specification, [FC-SW2].
スイッチ素子との間のインターフェースはプロプライエタリインターフェースまたはFC-SW2仕様、[FC-SW2]によって記載されている標準準拠のE_Portインタフェース、のいずれかです。
A mixed fabric contains one or more arbitrated loops connected to a switched fabric as shown in Figure 3.
混合した生地は、図3に示すように、スイッチドファブリックに接続された1つのまたは複数の調停ループを含んでいます。
+----------+ +----------+ +---------+
| FC | | FC | | FC |
| Device | | Device | | Device |
|..........| FC |..........| |.........|
| N_PORT |<........>| NL_PORT +---+ NL_PORT |
+----+-----+ Traffic +-----+----+ +----+----+
| | FC Loop |
+----+-----+ +-----+----+ |
| F_PORT | | FL_PORT +--------+
| | | |
==========+==========+==========+==========+==============
| FC | | FC |
| Switch | | Switch |
+----------+ +----------+
|Inter- | |Inter- |
|Switch | |Switch |
|Interface | |Interface |
+-----+----+ +-----+----+
| |
| |
+-----+----+----------+-----+----+
|Inter- | |Inter- |
|Switch | |Switch |
|Interface | |Interface |
+----------+ +----------+
| FC Switch |
| |
+--------------------------------+
Figure 3. Mixed Fibre Channel Fabric
図3.混合ファイバチャネルファブリック
As noted previously, the protocol for communications between peer N_PORTs is independent of the fabric topology, N_PORT variant, and type of fabric port to which an N_PORT is attached.
先に述べたように、ピアN_ポート間の通信のためのプロトコルは、ファブリックトポロジ、N_PORT変異体、およびN_PORTが取り付けられるファブリックポートのタイプとは無関係です。
A fibre channel consists of the following layers:
ファイバチャネルは、次の層から成っています：
FC-0 -- The interface to the physical media.
FC-0 - 物理メディアへのインターフェイス。
FC-1 -- The encoding and decoding of data and out-of-band physical link control information for transmission over the physical media.
FC-1 - データおよび物理メディアを介した送信のためにアウトオブバンド物理リンク制御情報の符号化および復号化。
FC-2 -- The transfer of frames, sequences, and Exchanges comprising protocol information units.
FC-2 - プロトコルの情報ユニットを含むフレーム、配列、及び交換の転送。
FC-3 -- Common Services.
FC-3 - Common Servicesの。
FC-4 -- Application protocols such as the fibre channel protocol for SCSI (FCP).
FC-4 - 例えばSCSI（FCP）のためのファイバチャネルプロトコル等のアプリケーションプロトコル。
In addition to the layers defined above, a fibre channel defines a set of auxiliary operations, some of which are implemented within the transport layer fabric, called link services. These are required in order to manage the fibre channel environment, establish communications with other devices, retrieve error information, perform error recovery, and provide other similar services. Some link services are executed by the N_PORT. Others are implemented internally within the fabric. These internal services are described in the next section.
上記で定義された層の他に、ファイバチャネルは、トランスポート層のファブリック内に実装されているいくつかの補助操作、と呼ばれるリンクサービスのセットを定義します。これらは、ファイバチャネル環境を管理し、他のデバイスとの通信を確立し、エラー情報を取得し、エラー回復を実行し、他の同様のサービスを提供するために必要とされています。いくつかのリンクサービスはN_PORTによって実行されています。その他は、ファブリック内で内部的に実装されています。これらの内部サービスは、次のセクションで説明されています。
Servers that are internal to a switched fabric handle certain classes of Link Service requests and service-specific commands. The servers appear as N_PORTs located at the 'well-known' N_PORT fabric addresses specified in [FC-FS]. Service requests use the standard fibre channel mechanisms for N_PORT-to-N_PORT communications.
スイッチファブリックの内部にあるサーバーは、リンクサービス要求とサービス固有のコマンドの特定のクラスを処理します。サーバーは、[FC-FS]で指定した「よく知られた」N_PORTファブリックアドレスに配置のN_Portとして表示されます。サービス要求は、N_PORTツーN_PORTコミュニケーションのための標準的なファイバチャネルメカニズムを使用しています。
All switched fabrics must provide the following services:
すべてのスイッチファブリックは、以下のサービスを提供する必要があります。
Fabric F_PORT server -- Services N_PORT requests to access the fabric for communications.
ファブリックF_PORTサーバ - 通信用ファブリックにアクセスするためのサービスN_PORT要求。
Fabric Controller -- Provides state change information to inform other FC devices when an N_PORT exits or enters the fabric (see Section 3.5).
ファブリックコントローラは - N_PORTが終了するかは、ファブリックを（3.5節を参照）に入ったとき、他のFCデバイスに通知する状態変化の情報を提供します。
Directory/Name Server - Allows N_PORTs to register information in a database, retrieve information about other N_PORTs, and to discover other devices as described in Section 3.5.
ディレクトリ/ネームサーバ - のN_Portは、データベース内の情報を登録し、他のNポートに関する情報を取得し、3.5節で説明したように、他のデバイスを検出するようにします。
A switched fabric may also implement the following optional services:
スイッチファブリックは、次のオプションサービスを実装することがあります。
Broadcast Address/Server -- Transmits single-frame, class 3 sequences to all N_PORTs.
ブロードキャストアドレス/ Serverは - 単一フレーム、クラスのすべてのN_Portに3列を送信します。
Time Server -- Intended for the management of fabric-wide expiration timers or elapsed time values; not intended for precise time synchronization.
タイムサーバ - ファブリック全体の有効期限タイマーや経過時間値の管理を対象。正確な時刻同期のためのものではありません。
Management Server - Collects and reports management information, such as link usage, error statistics, link quality, and similar items.
管理サーバーは、 - そのようなリンクの使用状況、エラー統計、リンク品質、および類似項目として、管理情報を収集し、レポートします。
Quality of Service Facilitator - Performs fabric-wide bandwidth and latency management.
サービスファシリテーターの質は - ファブリック全体の帯域幅と遅延の管理を行います。
A fibre channel node has one or more fabric-attached N_PORTs. The node and its N_PORTs have the following associated identifiers:
ファイバ・チャネル・ノードは、1つまたは複数のファブリック接続N_ポートを有しています。ノードとそののN_Portは、以下の関連する識別子を持っています：
a) A worldwide-unique identifier for the node.
a）はノードのための世界的な一意の識別子。
b) A worldwide-unique identifier for each N_PORT associated with the node.
B）ノードに関連付けられた各N_PORTの世界的な一意の識別子。
c) For each N_PORT attached to a fabric, a 24-bit fabric-unique address with the properties defined in Section 3.7.1. The fabric address is the address to which frames are sent.
C）ファブリックに接続された各N_PORTについて、特性を有する24ビットファブリック固有のアドレスは、セクション3.7.1で定義されています。ファブリックアドレスは、フレームの送信先となるアドレスです。
Each worldwide-unique identifier is a 64-bit binary quantity with the format defined in [FC-FS].
各ワールドワイド・一意の識別子は、[FC-FS]で定義されたフォーマットで64ビットのバイナリ数です。
In a switched or mixed fabric, fibre channel devices and changes in the device configuration may be discovered by means of services provided by the fibre channel Name Server and Fabric Controller.
交換または混合ファブリックでは、ファイバチャネルデバイス及びデバイス構成の変更は、ファイバチャネルネームサーバおよびファブリックコントローラによって提供されるサービスによって発見されてもよいです。
The Name Server provides registration and query services that allow a fibre channel device to register its presence on the fabric and to discover the existence of other devices. For example, one type of query obtains the fabric address of an N_PORT from its 64-bit worldwide-unique name. The full set of supported fibre channel name server queries is specified in [FC-GS3].
ネームサーバは、ファイバ・チャネル・デバイスがファブリック上でその存在を登録し、他のデバイスの存在を発見することができ、登録およびクエリサービスを提供しています。たとえば、クエリの1種類は、その64ビットの世界的に固有の名前からN_PORTのファブリックアドレスを取得します。サポートされているファイバーチャネルネームサーバクエリのフルセットは、[FC-GS3]で指定されています。
The Fabric Controller complements the static discovery capabilities provided by the Name Server through a service that dynamically alerts a fibre channel device whenever an N_PORT is added or removed from the configuration. A fibre channel device receives these notifications by subscribing to the service as specified in [FC-FS].
ファブリックコントローラはN_PORTが設定から追加または削除されるたびに動的にファイバ・チャネル・デバイスに警告サービスを介してネームサーバによって提供される静的検出機能を補完します。ファイバ・チャネル・デバイスは、[FC-FS]で指定されたサービスに加入することにより、これらの通知を受信します。
The fundamental element of information in fibre channel is the frame. A frame consists of a fixed header and up to 2112 bytes of payload with the structure described in Section 3.7. The maximum frame size that may be transmitted between a pair of fibre channel devices is negotiable up to the payload limit, based on the size of the frame buffers in each fibre channel device and the path maximum transmission unit (MTU) supported by the fabric.
ファイバチャネルの情報の基本的な要素は、フレームです。フレームが固定ヘッダから成り、セクション3.7に記載された構造を有するペイロードの最大2112バイト。ファイバ・チャネル・デバイスのペア間で送信することができる最大フレームサイズは、各ファイバチャネルデバイスのフレームバッファのサイズとファブリックによって支持経路最大送信ユニット（MTU）に基づいて、ペイロード限界まで交渉可能です。
Operations involving the transfer of information between N_PORT pairs are performed through 'Exchanges'. In an Exchange, information is transferred in one or more ordered series of frames, referred to as Sequences.
N_PORTペア間の情報の転送を伴う操作は、「交流」を介して実行されます。引き換えに、情報は、1つで転送以上の配列と呼ばれるフレーム、一連の順序付けされます。
Within this framework, an upper layer protocol is defined in terms of transactions carried by Exchanges. In turn, each transaction consists of protocol information units, each of which is carried by an individual Sequence within an Exchange.
この枠組みの中で、上位層プロトコルは、交換によって運ばトランザクションの観点で定義されています。順番に、各トランザクションは、Exchange内の個々のシーケンスによって運ばれる各々はプロトコル情報単位から成ります。
A fibre channel frame consists of a header, payload and 32-bit CRC bracketed by SOF and EOF delimiters. The header contains the control information necessary to route frames between N_PORTs and manage Exchanges and Sequences. The following diagram gives a schematic view of the frame.
ファイバ・チャネル・フレームは、ヘッダ、ペイロード及びSOFとEOF区切り記号で囲まれた32ビットCRCで構成されています。ヘッダはN_ポート間で交換およびシーケンスの管理、ルートフレームに必要な制御情報を含みます。次の図は、フレームの概略図を与えます。
Bit 0 31
+-----------------------------+
Word 0 | Start-of-frame Delimiter |
+-----+-----------------------+<----+
| | Destination N_PORT | |
1 | | Fabric Address (D_ID) | |
| | (24 bits) | |
+-----+-----------------------+ 24-byte
| | Source N_PORT | Frame
2 | | Fabric Address (S_ID) | Header
| | (24 bits) | |
+-----+-----------------------+ |
3 | Control information for | |
. | frame type, Exchange | |
. | management, IU | |
. | segmentation and | |
6 | re-assembly | |
+-----------------------------+<----+
7 | |
. | Frame payload |
. | (0 - 2112 bytes) |
. | |
. | |
. | |
+-----------------------------+
. | CRC |
+-----------------------------+
n | End-of-Frame Delimiter |
+-----------------------------+
Figure 4. Fibre Channel Frame Format
図4.ファイバチャネルフレームフォーマット
The source and destination N_PORT fabric addresses embedded in the S_ID and D_ID fields represent the physical addresses of originating and receiving N_PORTs, respectively.
S_IDとD_IDフィールドに埋め込まれた送信元および宛先N_PORTファブリックアドレスは、それぞれ、発信及び受信N_ポートの物理アドレスを表します。
N_PORT fabric addresses are 24-bit values with the following format, defined by the fibre channel specification [FC-FS]:
Nポートのファブリック・アドレスは、ファイバチャネル規格によって定義された次の形式の24ビット値、[FC-FS]です。
Bit 0 7 8 15 16 23
+-----------+------------+----------+
| Domain ID | Area ID | Port ID |
+-----------+------------+----------+
Figure 5. Fibre Channel Address Format
図5.ファイバー・チャネル・アドレス形式
A fibre channel device acquires an address when it logs into the fabric. Such addresses are volatile and subject to change based on modifications in the fabric configuration.
それは、ファブリックにログインしたときに、ファイバ・チャネル・デバイスは、アドレスを取得します。そのようなアドレスは、揮発性であり、ファブリック構成における変更に基づいて変更されます。
In a fibre channel fabric, each switch element has a unique Domain ID assigned by the principal switch. The value of the Domain ID ranges from 1 to 239 (0xEF). Each switch element, in turn, administers a block of addresses divided into area and port IDs. An N_PORT connected to an F_PORT receives a unique fabric address, consisting of the switch's Domain ID concatenated with switch-assigned area and port IDs.
ファイバ・チャネル・ファブリックに、各スイッチ素子は、主要スイッチによって割り当てられた固有のドメインIDを有しています。ドメインIDの値は1から239（0xEFという）の範囲です。各スイッチ素子は、順番に、領域およびポートIDのに分けアドレスのブロックを管理します。 F_PORTに接続されたN_PORTは、スイッチに割り当てられた領域及びポートIDとの連結スイッチのドメインIDからなる、一意のファブリックアドレスを受信します。
A loop-attached NL_PORT (see Figure 3) obtains the Port ID component of its address during the loop initialization process described in [FC-AL2]. The area and domain IDs are supplied by the fabric when the fabric login (FLOGI) is executed.
ループ付きNLポート（図3参照）FC-AL2]に記載のループ初期化プロセスの間にそのアドレスのポートIDのコンポーネントを取得します。ファブリックログイン（FLOGI）が実行されるときに領域ドメインIDは、ファブリックによって供給されます。
N_PORTs communicate by means of the following classes of service, which are specified in the fibre channel standard ([FC-FS]):
N_ポートは、ファイバチャネル規格（[FC-FS]）で指定されたサービスの次のクラスの手段によって通信します。
Class 1 - A dedicated physical circuit connecting two N_PORTs.
クラス1 - 2つのNポートを接続する専用物理回路。
Class 2 - A frame-multiplexed connection with end-to-end flow control and delivery confirmation.
クラス2 - エンド・ツー・エンドのフロー制御および送達確認とフレーム多重接続。
Class 3 - A frame-multiplexed connection with no provisions for end-to-end flow control or delivery confirmation.
クラス3 - エンドツーエンドのフロー制御や送達確認のためのない規定にフレーム多重接続。
Class 4 -- A connection-oriented service, based on a virtual circuit model, providing confirmed delivery with bandwidth and latency guarantees.
クラス4 - 接続指向のサービス、仮想回路モデルに基づいて、帯域幅と遅延の保証と確認された送達を提供します。
Class 6 -- A reliable multicast service derived from class 1.
クラス6 - クラス1から派生し信頼性の高いマルチキャストサービス。
Classes 2 and 3 are the predominant services supported by deployed fibre channel storage and clustering systems.
クラス2及び3は、展開ファイバチャネルストレージとクラスタリングシステムによってサポートされる主なサービスです。
Class 3 service is similar to UDP or IP datagram service. Fibre channel storage devices using this class of service rely on the ULP implementation to detect and recover from transient device and transport errors.
クラス3サービスは、UDPまたはIPデータグラムサービスに似ています。このサービスクラスを使用して、ファイバ・チャネル・ストレージ・デバイスを検出し、過渡デバイス、輸送エラーから回復するためにULPの実装に依存しています。
For class 2 and class 3 service, the fibre channel fabric is not required to provide in-order delivery of frames unless it is explicitly requested by the frame originator (and supported by the fabric). If ordered delivery is not in effect, it is the responsibility of the frame recipient to reconstruct the order in which frames were sent, based on information in the frame header.
クラス2とクラス3サービスのために、ファイバ・チャネル・ファブリックは、それが明示的にフレームの発信者によって要求された（及び布地によって支持）されない限り、フレームの順序配信を提供するために必要とされません。順序付けられた配信が有効でない場合は、フレームは、フレームヘッダ内の情報に基づいて、送信された順序を再構築するフレーム受信者の責任です。
The Login processes are FC-2 operations that allow an N_PORT to establish the operating environment necessary to communicate with the fabric, other N_PORTs, and ULP implementations accessed via the N_PORT. Three login operations are supported:
ログインプロセスは、FC-2 N_PORTファブリックと通信するために必要な動作環境を確立することを可能にする操作、他のN_ポート、およびN_PORTを介してアクセスULP実装されています。三つのログイン操作がサポートされています。
a) Fabric Login (FLOGI) -- An operation whereby the N_PORT registers its presence on the fabric, obtains fabric parameters, such as classes of service supported, and receives its N_PORT address,
A）ファブリックログイン（FLOGI） - N_PORTがファブリックにその存在を登録する動作は、そのようなサポートサービスのクラスとしてファブリックパラメータを取得し、そのNポートのアドレスを受信し、
b) Port Login (PLOGI) -- An operation by which an N_PORT establishes communication with another N_PORT.
B）ポートログイン（PLOGI） - N_PORTが他N_PORTとの通信を確立する動作。
c) Process Login (PRLOGI) -- An operation that establishes the process-to-process communications associated with a specific FC-4 ULP, such as FCP-2, the fibre channel SCSI mapping.
C）プロセスログイン（PRLOGI） - 特定のFC-4 ULP、例えばFCP-2、ファイバチャネル、SCSIマッピングなどに関連付けられているプロセス間通信を確立する操作。
Since N_PORT addresses are volatile, an N_PORT originating a login (PLOGI) operation executes a Name Server query to discover the fibre channel address of the remote device. A common query type involves use of the worldwide-unique name of an N_PORT to obtain the 24-bit N_PORT fibre channel address to which the PLOGI request is sent.
N_PORTアドレスは揮発性であるので、ログイン（PLOGI）の操作を発信するN_PORTは、リモートデバイスのファイバチャネルアドレスを発見するためにネームサーバーのクエリを実行します。共通クエリタイプは、PLOGI要求が送信される24ビットのN_PORTファイバーチャネルアドレスを取得するN_PORTのワールドワイド・一意の名前の使用を含みます。
The iFCP protocol enables the implementation of fibre channel fabric functionality on an IP network in which IP components and technology replace the fibre channel switching and routing infrastructure described in Section 3.2.
iFCPプロトコルは、IPコンポーネントおよび技術が、セクション3.2に記載のファイバチャネルスイッチングおよびルーティングインフラを交換するIPネットワーク上のファイバ・チャネル・ファブリックの機能の実装を可能にします。
The example of Figure 6 shows a fibre channel network with attached devices. Each device accesses the network through an N_PORT connected to an interface whose behavior is specified in [FC-FS] or [FC-AL2]. In this case, the N_PORT represents any of the variants described in Section 3.2. The interface to the fabric may be an L_PORT, F_PORT, or FL_PORT.
図6の例では、接続デバイスとファイバ・チャネル・ネットワークを示します。各デバイスは、その挙動[FC-FS]または[FC-AL2]で指定されたインターフェイスに接続されているN_PORTを介してネットワークにアクセスします。この場合、N_PORTは、3.2節で説明した変種のいずれかを表します。ファブリックへのインタフェースはL_PORT、F_PORT、またはFLポートであってもよいです。
Within the fibre channel device domain, addressable entities consist of other N_PORTs and fibre channel devices internal to the network that perform the fabric services defined in [FC-GS3].
ファイバ・チャネル・デバイス・ドメイン内に、アドレス指定可能なエンティティは、[FC-GS3]で定義されたファブリックサービスを行うネットワークの内部の他のNポートとファイバチャネルデバイスから成ります。
Fibre Channel Network
+--------+ +--------+
| FC | | FC |
| Device | | Device |
|........| FC |........| Fibre Channel
| N_PORT |<......>| N_PORT | Device Domain
+---+----+ Traffic+----+---+ ^
| | |
+---+----+ +----+---+ |
| Fabric | | Fabric | |
| Port | | Port | |
==========+========+========+========+==============
| FC Network & | |
| Fabric Services | v
| | Fibre Channel
+--------------------------+ Network Domain
Figure 6. A Fibre Channel Network
図6. Aファイバー・チャネル・ネットワーク
Gateway Region Gateway Region
+--------+ +--------+ +--------+ +--------+
| FC | | FC | | FC | | FC |
| Device | | Device | | Device | | Device | Fibre
|........| |........| FC |........| |........| Channel
| N_PORT | | N_PORT |<.........>| N_PORT | | N_PORT | Device
+---+----+ +---+----+ Traffic +----+---+ +----+---+ Domain
| | | | ^
+---+----+ +---+----+ +----+---+ +----+---+ |
| F_PORT | | F_PORT | | F_PORT | | F_PORT | |
=+========+==+========+===========+========+==+========+==========
| iFCP Layer |<--------->| iFCP Layer | |
|....................| ^ |....................| |
| iFCP Portal | | | iFCP Portal | v
+--------+-----------+ | +----------+---------+ IP
iFCP|Gateway Control iFCP|Gateway Network
| Data |
| |
| |
|<------Encapsulated Frames------->|
| +------------------+ |
| | | |
+------+ IP Network +--------+
| |
+------------------+
Figure 7. An iFCP Fabric Example
図7のiFCPファブリック例
One example of an equivalent iFCP fabric is shown in Figure 7. The fabric consists of two gateway regions, each accessed by a single iFCP gateway.
同等のiFCP布の一例が図7に示されているファブリックは、二つのゲートウェイ領域、単一のiFCPゲートウェイによってアクセス各々から成ります。
Each gateway contains two standards-compliant F_PORTs and an iFCP Portal for attachment to the IP network. Fibre channel devices in the region are those locally connected to the iFCP fabric through the gateway fabric ports.
各ゲートウェイは、両規格に準拠したF_PORTsおよびIPネットワークへの接続のためのiFCPポータルが含まれています。領域内のファイバ・チャネル・デバイスは、ローカルゲートウェイファブリックポートを通してのiFCPファブリックに接続されたものです。
Looking into the fabric port, the gateway appears as a fibre channel switch element. At this interface, remote N_PORTs are presented as fabric-attached devices. Conversely, on the IP network side, the gateway presents each locally connected N_PORT as a logical fibre channel device.
ファブリックポートを見ると、ゲートウェイは、ファイバチャネルスイッチ素子として表示されます。このインターフェイスで、リモートN_ポートがファブリック接続デバイスとして提示されます。逆に、IPネットワーク側で、ゲートウェイは、論理ファイバチャネルデバイスとして各ローカルに接続されたN_PORTを提示します。
Extrapolating to the general case, each gateway region behaves like an autonomous system whose configuration is invisible to the IP network and other gateway regions. Consequently, in addition to the F_PORT shown in the example, a gateway implementation may transparently support the following fibre channel interfaces:
一般的な場合に外挿する、各ゲートウェイ領域は、その構成のIPネットワークと他のゲートウェイ領域に不可視である自律システムのように振る舞います。従って、例に示すF_PORTに加えて、ゲートウェイ実装は透過以下ファイバチャネルインターフェイスをサポートすることができます。
Inter-Switch Link -- A fibre channel switch-to-switch interface used to access a region containing fibre channel switch elements. An implementation may support the E_PORT defined by [FC-SW2] or one of the proprietary interfaces provided by various fibre channel switch vendors. In this case, the gateway acts as a border switch connecting the gateway region to the IP network.
スイッチ間リンク - ファイバ・チャネル・スイッチ素子を含む領域にアクセスするために使用されるファイバチャネルスイッチ間のインターフェイス。実装は、[FC-SW2]によって定義されたEポートまたは種々のファイバ・チャネル・スイッチ・ベンダーによって提供される独自のインターフェースのいずれかをサポートすることができます。この場合、ゲートウェイは、IPネットワークへのゲートウェイ領域を接続する境界スイッチとして作用します。
FL_PORT -- An interface that provides fabric access for loop-attached fibre channel devices, as specified in [FC-FLA].
FLポート - [FC-FLA]で指定されるように、ループ付きファイバ・チャネル・デバイスのためのファブリックのアクセスを提供するインターフェイス。
L_PORT -- An interface through which a gateway may emulate the fibre channel loop environment specified in [FC-AL2]. As discussed in appendix B, the gateway presents remotely accessed N_PORTS as loop-attached devices.
L_PORT - ゲートウェイは[FC-AL2]で指定されたファイバ・チャネル・ループの環境をエミュレートすることができるのインターフェイス。付録Bで説明したように、ゲートウェイは、ループ接続されたデバイスなどのリモートアクセスN_ポートを提示します。
The manner in which these interfaces are provided by a gateway is implementation specific and therefore beyond the scope of this document.
これらのインタフェースは、ゲートウェイによって提供される方法は実装特有ので、この文書の範囲外です。
Although each region is connected to the IP network through one gateway, a region may incorporate multiple gateways for added performance and fault tolerance if the following conditions are met:
各領域は、1つのゲートウェイを介してIPネットワークに接続されているが、以下の条件が満たされた場合、領域が追加の性能およびフォールトトレランスのために複数のゲートウェイを組み込むことができます。
a) The gateways MUST coordinate the assignment of N_PORT IDs and aliases so that each N_PORT has one and only one address.
各N_PORTは、唯一のアドレスを有するようにA）ゲートウェイは、NポートIDおよびエイリアスの割り当てを調整しなければなりません。
b) All iFCP traffic between a given remote and local N_PORT pair MUST flow through the same iFCP session (see Section 5.2.1). However, iFCP sessions to a given remotely attached N_PORT need not traverse the same gateway.
B）指定されたリモートおよびローカルNポート対間のすべてのiFCPトラフィックは同じのiFCPセッションを介して流れなければならない（セクション5.2.1を参照）。しかし、所与の遠隔取り付けN_PORTへのiFCPセッションが同じゲートウェイを通過する必要はありません。
Coordinating address assignments and managing the flow of traffic is implementation specific and outside the scope of this specification.
アドレスの割り当てを調整し、トラフィックのフローを管理することは、実装固有の、この仕様の範囲外です。
N_PORT to N_PORT communications that traverse a TCP/IP network require the intervention of the iFCP layer within the gateway. This consists of the following operations:
ゲートウェイ内のiFCP層の介入を必要とするTCP / IPネットワークを横断N_PORT通信にN_PORT。これは、以下の操作で構成されています。
a) Execution of the frame-addressing and -mapping functions described in Section 4.4.
セクション4.4で説明フレームアドレッシング及び-mapping関数のa）の実行。
b) Encapsulation of fibre channel frames for injection into the TCP/IP network and de-encapsulation of fibre channel frames received from the TCP/IP network.
b）は、TCP / IPネットワークへの注入とファイバチャネルフレームの脱カプセル化のためのファイバ・チャネル・フレームのカプセル化は、TCP / IPネットワークから受信しました。
c) Establishment of an iFCP session in response to a PLOGI directed to a remote device.
遠隔装置に向けPLOGIに応答してのiFCPセッションのC）設立。
Section 4.4 discusses the iFCP frame-addressing mechanism and the way that it is used to achieve communications transparency between N_PORTs.
セクション4.4のiFCPフレームアドレッシング機構及びN_ポート間の通信の透明性を達成するために使用される方法について説明します。
An iFCP fabric supports Class 2 and Class 3 fibre channel transport services, as specified in [FC-FS]. An iFCP fabric does not support Class 4, Class 6, or Class 1 (dedicated connection) service. An N_PORT discovers the classes of transport services supported by the fabric during fabric login.
[FC-FS]で指定されているのiFCPファブリックは、クラス2及びクラス3つのファイバチャネル・トランスポート・サービスをサポートします。 iFCPファブリックは、クラス4、クラス6、またはクラス1（専用接続）サービスをサポートしていません。 N_PORTは、ファブリックログイン中にファブリックでサポートされている輸送サービスのクラスを検出します。
An iFCP implementation performs device discovery and iFCP fabric management through the Internet Storage Name Service defined in [ISNS]. Access to an iSNS server is required to perform the following functions:
iFCP実装は[ISNS]で定義されたインターネットストレージネームサービスを介して、デバイスディスカバリとのiFCPファブリック管理を行います。 iSNSサーバへのアクセスは、以下の機能を実行するために必要とされています。
a) Emulate the services provided by the fibre channel name server described in Section 3.3.1, including a mechanism for asynchronously notifying an N_PORT of changes in the iFCP fabric configuration.
a）は、非同期のiFCPファブリック構成の変化のN_PORTを通知するための機構を備え、セクション3.3.1に記載のファイバチャネルネームサーバによって提供されるサービスをエミュレートします。
b) Aggregate gateways into iFCP fabrics for interoperation.
b）の相互運用のためのiFCP生地に集計ゲートウェイ。
c) Segment an iFCP fabric into fibre channel zones through the definition and management of device discovery scopes, referred to as 'discovery domains'.
C）装置発見スコープの定義および管理を介してファイバチャネルゾーンにセグメントのiFCPファブリックは、「ディスカバリドメイン」と呼ばれます。
d) Store and distribute security policies, as described in Section 10.2.9.
d）のストアと、セクション10.2.9で説明したように、セキュリティポリシーを配布します。
e) Implementation of the fibre channel broadcast mechanism.
ファイバー・チャネル・放送機構のe）の実装。
A collection of iFCP gateways may be configured for interoperation as either a bounded or an unbounded iFCP fabric.
iFCPゲートゲートウェイの集合は、有界または無制限のiFCP布のいずれかと相互運用するように構成することができます。
Gateways in a bounded iFCP fabric operate in address transparent mode, as described in Section 4.5. In this mode, the scope of a fibre channel N_PORT address is fabric-wide and is derived from domain IDs issued by the iSNS server from a common pool. As discussed in Section 4.3.2, the maximum number of domain IDs allowed by the fibre channel limits the configuration of a bounded iFCP fabric.
4.5節で説明したように有界のiFCPファブリック内のゲートウェイは、アドレストランスペアレントモードで動作します。このモードでは、ファイバチャネルN_PORTアドレスの範囲は、ファブリック全体で、共通プールからiSNSサーバーから発行されたドメインIDに由来しています。 4.3.2項で説明したように、ファイバチャネルによって許可ドメインIDの最大数は、境界のiFCPファブリックの構成を制限します。
Gateways in an unbounded iFCP fabric operate in address translation mode as described in Section 4.6. In this mode, the scope of an N_PORT address is local to a gateway region. For fibre channel traffic between regions, the translation of frame-embedded N_PORT addresses is performed by the gateway. As discussed below, the number of switch elements and gateways in an unbounded iFCP fabric may exceed the limits of a conventional fibre channel fabric.
4.6節で説明したように無制限のiFCPファブリック内のゲートウェイは、アドレス変換モードで動作します。このモードでは、N_ポートのアドレスの範囲は、ゲートウェイ領域に局所的です。領域間のファイバチャネルトラフィックの場合、フレーム内蔵N_PORTアドレスの変換は、ゲートウェイによって実行されます。以下に説明するように、無制限のiFCPファブリックのスイッチ素子とゲートウェイの数は、従来のファイバ・チャネル・ファブリックの限界を超えることができます。
All iFCP gateways MUST support unbounded iFCP fabrics. Support for bounded iFCP fabrics is OPTIONAL.
すべてのiFCPゲートウェイは、無制限のiFCPファブリックをサポートしなければなりません。有界のiFCPファブリックのサポートはオプションです。
The decision to support bounded iFCP fabrics in a gateway implementation depends on the address transparency, configuration scalability, and fault tolerance considerations given in the following sections.
ゲートウェイの実装で有界のiFCPファブリックをサポートするという決定は、以下のセクションで指定されたアドレスの透明性、設定のスケーラビリティ、およびフォールトトレランスの考慮事項に依存します。
Although iFCP gateways in an unbounded fabric will convert N_PORT addresses in the frame header and payload of standard link service messages, a gateway cannot convert such addresses in the payload of vendor- or user-specific fibre channel frame traffic.
無限ファブリック内のiFCPゲートウェイは、フレームヘッダと標準リンク・サービス・メッセージのペイロードにN_PORTアドレスを変換するが、ゲートウェイは、ベンダまたはユーザ固有のファイバ・チャネル・フレーム・トラフィックのペイロードにそのようなアドレスを変換することはできません。
Consequently, although both bounded and unbounded iFCP fabrics support standards-compliant FC-4 protocol implementations and link services used by mainstream fibre channel applications, a bounded iFCP fabric may also support vendor- or user-specific protocol and link service implementations that carry N_PORT IDs in the frame payload.
両方が境界と無制限のiFCPファブリックサポート標準準拠FC-4プロトコル実装と主流ファイバ・チャネル・アプリケーションで使用されるリンクサービスが結果として、境界のiFCPファブリックはN_PORT IDを運ぶベンダまたはユーザ固有のプロトコルとリンクサービス実装をもサポートすることができますフレームペイロードインチ
The scalability limits of a bounded fabric configuration are a consequence of the fibre channel address allocation policy discussed in Section 3.7.1. As noted, a bounded iFCP fabric using this address allocation scheme is limited to a combined total of 239 gateways and fibre channel switch elements. As the system expands, the network may grow to include many switch elements and gateways, each of which controls a small number of devices. In this case, the limitation in switch and gateway count may become a barrier to extending and fully integrating the storage network.
有界ファブリック構成のスケーラビリティの制限は、セクション3.7.1で説明したファイバーチャネルアドレス割当政策の結果です。述べたように、このアドレス割り当て方式を使用して境界のiFCPファブリック239のゲートウェイとファイバチャネルスイッチ素子の合計に限定されます。システムは、膨張すると、ネットワークは、デバイスの小さな数を制御各々が、多くのスイッチ素子及びゲートウェイを含むように成長することができます。この場合、スイッチおよびゲートウェイ数の制限が延びると完全にストレージネットワークの統合に対する障壁になることができます。
Since N_PORT fibre channel addresses in an unbounded iFCP fabric are not fabric-wide, the limits imposed by fibre channel address allocation only apply within the gateway region. Across regions, the number of iFCP gateways, fibre channel devices, and switch elements that may be internetworked are not constrained by these limits. In exchange for improved scalability, however, implementations must consider the incremental overhead of address conversion, as well as the address transparency issues discussed in Section 4.3.1.
無制限のiFCPファブリック内N_PORTファイバーチャネルアドレスがファブリック全体ではないので、ファイバーチャネルアドレス割り当てによって課される制限は、ゲートウェイ領域内に適用します。領域を横切って、インターネットワークことができるのiFCPゲートウェイ、ファイバ・チャネル・デバイス、およびスイッチ素子の数は、これらの制限によって制約されません。改善されたスケーラビリティと引き換えに、しかし、実装は、アドレス変換の増分オーバーヘッド、並びに4.3.1項で説明したアドレス透明性の問題を考慮しなければなりません。
In a bounded iFCP fabric, address reassignment caused by a fault or reconfiguration, such as the addition of a new gateway region, may cascade to other regions, causing fabric-wide disruption as new N_PORT addresses are assigned. Furthermore, before a new gateway can be merged into the fabric, its iSNS server must be slaved to the iSNS server in the bounded fabric to centralize the issuance of domain IDs. In an unbounded iFCP fabric, coordinating the iSNS databases requires only that the iSNS servers exchange client attributes with one another.
境界のiFCPファブリックにおいて、アドレスの再割り当ては、新規のN_ポートアドレスが割り当てられているように、ファブリック全体の破壊を引き起こし、他の領域にカスケード接続することができる、新たなゲートウェイ領域の追加など、障害または再構成によって生じます。新しいゲートウェイは、ファブリックにマージすることができます前に、さらに、そのiSNSサーバーは、ドメインIDの発行を集中するために有界ファブリック内のiSNSサーバーに従属する必要があります。無制限のiFCPファブリックでは、iSNSのデータベースを調整することのiSNSサーバのExchangeクライアントが互いに属性だけを要求します。
A bounded iFCP fabric also has an increased dependency on the availability of the iSNS server, which must act as the central address assignment authority. If connectivity with the server is lost, new DOMAIN_ID values cannot be automatically allocated as gateways and fibre channel switch elements are added.
有界のiFCP生地は、中央アドレス割り当て機関として行動しなければならないiSNSサーバーの可用性、に増加した依存関係を持っています。サーバとの接続が失われた場合、新たなDOMAIN_ID値が自動的にゲートウェイとファイバチャネルスイッチ素子が追加されるように割り当てることができません。
This section discusses iFCP extensions to the fibre channel addressing model of Section 3.7.1, which are required for the transparent routing of frames between locally and remotely attached N_PORTs.
このセクションでは、ローカルおよびリモート取り付けN_ポート間のフレームの透明なルーティングに必要とされるセクション3.7.1のモデルをアドレッシングファイバチャネルへのiFCP拡張を論じています。
In the iFCP protocol, an N_PORT is represented by the following addresses:
iFCPプロトコルでは、N_ポートは、以下のアドレスで表されます。
a) A 24-bit N_PORT ID. The fibre channel N_PORT address of a locally attached device. Depending on the gateway addressing mode, the scope is local either to a region or to a bounded iFCP fabric. In either mode, communications between N_PORTs in the same gateway region use the N_PORT ID.
a）は、24ビットのNポートID。ローカルに接続されたデバイスのファイバーチャネルN_PORTアドレス。ゲートウェイ・アドレッシング・モードに応じて、範囲が領域または境界のiFCPファブリックに、ローカルです。どちらのモードでは、同一のゲートウェイ領域におけるN_ポート間の通信は、NポートIDを使用します。
b) A 24-bit N_PORT alias. The fibre channel N_PORT address assigned by each gateway operating in address translation mode to identify a remotely attached N_PORT. Frame traffic is intercepted by an iFCP gateway and directed to a remotely attached N_PORT by means of the N_PORT alias. The address assigned by each gateway is unique within the scope of the gateway region.
b）は、24ビットのN_PORTエイリアス。リモート添付N_PORTを識別するためにアドレス変換モードで動作する各ゲートウェイによって割り当てられたファイバチャネルNポートアドレス。フレームトラフィックはiFCPゲートゲートウェイによって傍受およびN_PORT別名によって遠隔取り付けN_PORTに向けられています。各ゲートウェイによって割り当てられたアドレスがゲートウェイ領域の範囲内で一意です。
c) An N_PORT network address. A tuple consisting of the gateway IP address, TCP port number, and N_PORT ID. The N_PORT network address identifies the source and destination N_PORTs for fibre channel traffic on the IP network.
C）N_PORTネットワークアドレス。ゲートウェイIPアドレス、TCPポート番号、およびN_PORT IDからなるタプル。 N_PORTネットワークアドレスは、IPネットワーク上のファイバ・チャネル・トラフィックの送信元および宛先N_ポートを識別する。
To provide transparent communications between a remote and local N_PORT, a gateway MUST maintain an iFCP session descriptor (see Section 5.2.2.2) reflecting the association between the fibre channel address representing the remote N_PORT and the remote device's N_PORT network address. To establish this association, the iFCP gateway assigns and manages fibre channel N_PORT fabric addresses as described in the following paragraphs.
リモートおよびローカルN_PORTの間に透明な通信を提供するために、ゲートウェイは、リモートN_PORTを表すファイバーチャネルアドレスとリモートデバイスのN_PORTネットワークアドレスの間の関連付けを反映する（セクション5.2.2.2参照）のiFCPセッション記述子を維持しなければなりません。以下の段落で説明したようにこの関連付けを確立するために、iFCPゲートゲートウェイは、ファイバチャネルNポートのファブリック・アドレスを割り当て、管理します。
In an iFCP fabric, the iFCP gateway performs the address assignment and frame routing functions of an FC switch element. Unlike an FC switch, however, an iFCP gateway must also direct frames to external devices attached to remote gateways on the IP network.
iFCPゲートファブリックで、iFCPゲートゲートウェイは、FCスイッチ素子のアドレス割り当てとフレームルーティング機能を実行します。 FCスイッチとは異なり、しかし、iFCPゲートゲートウェイIPネットワーク上のリモートゲートウェイに接続された外部機器にも直接フレームなければなりません。
In order to be transparent to FC devices, the gateway must deliver such frames using only the 24-bit destination address in the frame header. By exploiting its control of address allocation and access to frame traffic entering or leaving the gateway region, the gateway is able to achieve the necessary transparency.
FCデバイスに対して透明であるために、ゲートウェイは、フレームヘッダにのみ24ビット宛先アドレスを使用してこのようなフレームを提供しなければなりません。フレームトラフィック入るアドレス割り当て及びアクセスのそのコントロールを利用またはゲートウェイ領域を残すことによって、ゲートウェイは、必要な透明性を達成することができます。
N_PORT addresses within a gateway region may be allocated in one of two ways:
ゲートウェイ領域内N_PORTアドレスは、次のいずれかの方法で割り当てることができます。
a) Address Translation Mode - A mode of N_PORT address assignment in which the scope of an N_PORT fibre channel address is unique to the gateway region. The address of a remote device is represented in that gateway region by its gateway-assigned N_PORT alias.
A）変換モードアドレス - N_PORTファイバーチャネルアドレスの範囲がゲートウェイ領域にユニークであるN_PORTアドレス割り当てのモード。遠隔デバイスのアドレスは、そのゲートウェイに割り当てられたN_PORT別名によってそのゲートウェイ領域に示されています。
b) Address Transparent Mode - A mode of N_PORT address assignment in which the scope of an N_PORT fibre channel address is unique across the set of gateway regions comprising a bounded iFCP fabric.
N_PORTファイバーチャネルアドレスの範囲は境界のiFCPファブリックを含むゲートウェイ領域のセット全体で一意であるN_PORTアドレス割り当てのモード - B）透過モードアドレス。
In address transparent mode, gateways within a bounded fabric cooperate in the assignment of addresses to locally attached N_PORTs. Each gateway in control of a region is responsible for obtaining and distributing unique domain IDs from the address assignment authority, as described in Section 4.5.1. Consequently, within the scope of a bounded fabric, the address of each N_PORT is unique. For that reason, gateway-assigned aliases are not required for representing remote N_PORTs.
アドレストランスペアレントモードでは、有界ファブリック内のゲートウェイは、ローカル接続N_ポートへのアドレスの割り当てに協力します。セクション4.5.1に記載したように領域の制御における各ゲートウェイは、アドレス割り当て機関から一意のドメインIDを取得し、配布する責任があります。従って、制限された織物の範囲内で、各N_PORTのアドレスは一意です。そのため、ゲートウェイに割り当てられた別名は、リモートN_ポートを表すために必要とされません。
All iFCP implementations MUST support operations in address translation mode. Implementation of address transparent mode is OPTIONAL but, of course, must be provided if bounded iFCP fabric configurations are to be supported.
すべてのiFCP実装は、アドレス変換モードでの操作をサポートしなければなりません。アドレス透過モードの実装はもちろん、有界のiFCPファブリック構成がサポートされる場合に提供されなければならない、オプションですが。
The mode of gateway operation is settable in an implementation-specific manner. The implementation MUST NOT:
ゲートウェイの動作モードは、実装固有の方法で設定可能です。実装はいけません。
a) allow the mode to be changed after the gateway begins processing fibre channel frame traffic,
A）は、ゲートウェイは、ファイバーチャネルフレームトラフィックの処理を開始した後にモードを変更することを可能にします
b) permit operation in more than one mode at a time, or
b）の許可一度に複数のモードでの動作、または
c) establish an iFCP session with a gateway that is not in the same mode.
C）同じモードになっていないゲートウェイとのiFCPセッションを確立します。
The following considerations and requirements apply to this mode of operation:
以下の考慮事項および要件は、この動作モードに適用されます。
a) iFCP gateways in address transparent mode will not interoperate with iFCP gateways that are not in address transparent mode.
a）のアドレス透過モードでのiFCPゲートウェイは、アドレストランスペアレントモードではないのiFCPゲートウェイとの相互運用性はありません。
b) When interoperating with locally attached fibre channel switch elements, each iFCP gateway MUST assume control of DOMAIN_ID assignments in accordance with the appropriate fibre channel standard or vendor-specific protocol specification. As described in Section 4.5.1, DOMAIN_ID values that are assigned to FC switches internal to the gateway region must be issued by the iSNS server.
ローカルに接続されたファイバチャネルスイッチ素子と相互運用する場合b）に示すように、それぞれのiFCPゲートウェイは、適切なファイバチャネル標準またはベンダー固有のプロトコル仕様に従ってDOMAIN_ID割り当ての制御を想定しなければなりません。セクション4.5.1で説明したように、FCに割り当てられるDOMAIN_ID値がゲートウェイ領域へ内部スイッチiSNSサーバによって発行されなければなりません。
c) When operating in address transparent Mode, fibre channel address translation SHALL NOT take place.
アドレス透過モードで動作している場合c）は、ファイバー・チャネル・アドレス変換は行わないものとします。
When operating in address transparent mode, however, the gateway MUST establish and maintain the context of each iFCP session in accordance with Section 5.2.2.
アドレストランスペアレントモードで動作している場合、しかし、ゲートウェイはセクション5.2.2に従って各のiFCPセッションのコンテキストを確立し、維持しなければなりません。
As described in Section 4.5, each gateway and fibre channel switch in a bounded iFCP fabric has a unique domain ID. In a gateway region containing fibre channel switch elements, each element obtains a domain ID by querying the principal switch as described in [FC-SW2] -- in this case, the iFCP gateway itself. The gateway, in turn, obtains domain IDs on demand from the iSNS name server acting as the central address allocation authority. In effect, the iSNS server assumes the role of principal switch for the bounded fabric. In that case, the iSNS database contains:
セクション4.5で説明したように、境界のiFCPファブリック内の各ゲートウェイとファイバチャネルスイッチは、固有のドメインIDを有しています。ファイバチャネルスイッチ素子を含むゲートウェイ領域において、各要素は[FC-SW2]に記載されているように主スイッチを照会することにより、ドメインIDを取得する - この場合、のiFCPゲートウェイ自体。ゲートウェイは、順番に、中央のアドレス割り当て機関として機能するのiSNSネームサーバからオンデマンドでドメインIDを取得します。実際には、iSNSサーバは、有界ファブリックの主スイッチの役割を想定しています。その場合には、iSNSのデータベースが含まれています。
a) The definition for one or more bounded iFCP fabrics, and
a）1種以上の定義は、のiFCP生地を有界、および
b) For each bounded fabric, a worldwide-unique name identifying each gateway in the fabric. A gateway in address transparent mode MUST reside in one, and only one, bounded fabric.
B）各有界ファブリックは、ファブリック内の各ゲートウェイを識別する世界的に一意の名前。アドレストランスペアレントモードで、ゲートウェイは、一つに存在する必要があり、そして一方のみが、生地を有界。
As the Principal Switch within the gateway region, an iFCP gateway in address transparent mode SHALL obtain domain IDs for use in the gateway region by issuing the appropriate iSNS query, using its worldwide name.
ゲートウェイ領域内の主要スイッチとして、アドレス透過モードでのiFCPゲートウェイは、その世界的な名前を使用して、適切にiSNSクエリーを発行することにより、ゲートウェイ地域で使用するドメインIDを得なければなりません。
Except for the session control frames specified in Section 6, iFCP gateways in address transparent mode SHALL NOT originate or accept frames that do not have the TRP bit set to one in the iFCP flags field of the encapsulation header (see Section 5.3.1). The iFCP gateway SHALL immediately terminate all iFCP sessions with the iFCP gateway from which it receives such frames.
第6節で指定されたセッション制御フレームを除き、アドレス透過モードでのiFCPゲートウェイは、TRPビットが（5.3.1項を参照）をカプセル化ヘッダーのiFCPゲートフラグフィールド内の1に設定されていないフレームを発信するか、受け入れないものとします。 iFCPゲートゲートウェイは直ちにそのようなフレームを受信し、そこからのiFCPゲートウェイとのすべてのiFCPセッションを終了するもの。
This section describes the process for managing the assignment of addresses within a gateway region that is part of an unbounded iFCP fabric, including the modification of FC frame addresses embedded in the frame header for frames sent and received from remotely attached N_PORTs.
このセクションでは、送信されたフレームのフレームヘッダに埋め込まれ、リモート取り付けN_ポートから受信したFCフレームアドレスの変更を含む無制限のiFCPファブリックの一部であるゲートウェイ領域内のアドレスの割り当てを管理するための方法が記載されています。
As described in Section 4.4, the scope of N_PORT addresses in this mode is local to the gateway region. A principal switch within the gateway region, possibly the iFCP gateway itself, oversees the assignment of such addresses, in accordance with the rules specified in [FC-FS] and [FC-FLA].
セクション4.4で説明したように、このモードでN_PORTアドレスの範囲は、ゲートウェイ領域に局所的です。ゲートウェイ領域内の主要スイッチは、おそらくのiFCPゲートウェイ自体は、[FC-FS]で指定された規則および[FC-FLA]に応じて、そのようなアドレスの割り当てを監督します。
The assignment of N_PORT addresses to locally attached devices is controlled by the switch element to which the device is connected.
ローカルに接続されたデバイスへのN_PORTアドレスの割り当ては、デバイスが接続されるスイッチ素子によって制御されます。
The assignment of N_PORT addresses for remotely attached devices is controlled by the gateway by which the remote device is accessed. In this case, the gateway MUST assign a locally significant N_PORT alias to be used in place of the N_PORT ID assigned by the remote gateway. The N_PORT alias is assigned during device discovery, as described in Section 5.2.2.1.
リモート接続装置のN_PORTアドレスの割り当ては、リモートデバイスがアクセスされるゲートウェイによって制御されます。この場合、ゲートウェイは、リモート・ゲートウェイによって割り当てられたNポートIDの代わりに使用されるローカルで有効なN_PORT別名を割り当てる必要があります。セクション5.2.2.1に記載されるようにN_PORT別名は、デバイス発見時に割り当てられています。
To perform address conversion and to enable the appropriate routing, the gateway MUST establish an iFCP session and generate the information required to map each N_PORT alias to the appropriate TCP/IP connection context and N_PORT ID of the remotely accessed N_PORT. These mappings are created and updated by means specified in Section 5.2.2.2. As described in that section, the required mapping information is represented by the iFCP session descriptor reproduced in Figure 8.
アドレス変換を実行し、適切なルーティングを可能にするために、ゲートウェイは、のiFCPセッションを確立し、リモートアクセスN_PORTの適切なTCP / IP接続コンテキストとN_PORT IDに各N_PORT別名をマッピングするために必要な情報を生成しなければなりません。これらのマッピングは、セクション5.2.2.2で指定された手段によって作成され、更新されます。そのセクションで説明したように、必要なマッピング情報は、図8に再現のiFCPセッション記述子によって表されます。
+-----------------------+
|TCP Connection Context |
+-----------------------+
| Local N_PORT ID |
+-----------------------+
| Remote N_PORT ID |
+-----------------------+
| Remote N_PORT Alias |
+-----------------------+
Figure 8. iFCP Session Descriptor (from Section 5.2.2.2)
図8のiFCPセッション記述（セクション5.2.2.2から）
Except for frames comprising special link service messages (see Section 7.2), outbound frames are encapsulated and sent without modification. Address translation is deferred until receipt from the IP network, as specified in Section 4.6.1.
特別なリンクサービスメッセージを（7.2節を参照）を含むフレームを除いて、アウトバウンドフレームは修正なしでカプセル化して送信されます。 4.6.1項で指定されたアドレス変換は、IPネットワークから受信するまで延期されます。
For inbound frames received from the IP network, the receiving gateway SHALL reference the session descriptor to fill in the D_ID field with the destination N_PORT ID and the S_ID field with the N_PORT alias it assigned. The translation process for inbound frames is shown in Figure 9.
着信フレームがIPネットワークから受信するため、受信側ゲートウェイは、宛先N_PORT IDとが割り当てられたN_PORT別名とS_IDフィールドとD_IDフィールドを埋めるために、セッション記述を参照するものとします。受信フレームのための変換プロセスは、図9に示されています。
Network Format of Inbound Frame
+--------------------------------------------+ iFCP
| FC Encapsulation Header | Session
+--------------------------------------------+ Descriptor
| SOF Delimiter Word | |
+========+===================================+ V
| | D_ID Field | +--------+-----+
+--------+-----------------------------------+ | Lookup source|
| | S_ID Field | | N_PORT Alias |
+--------+-----------------------------------+ | and |
| Control Information, Payload, | | destination |
| and FC CRC | | N_PORT ID |
| | +--------+-----+
| | |
| | |
+============================================+ |
| EOF Delimiter Word | |
+--------------------------------------------+ |
|
|
Frame after Address Translation and De-encapsulation |
+--------+-----------------------------------+ |
| | Destination N_PORT ID |<-------------+
+--------+-----------------------------------+ |
| | Source N_PORT Alias |<-------------+
+--------+-----------------------------------+
| |
| Control information, Payload, |
| and FC CRC |
+--------------------------------------------+
Figure 9. Inbound Frame Address Translation
図9.受信フレームアドレス変換
The receiving gateway SHALL consider the contents of the S_ID and D_ID fields to be undefined when received. After replacing these fields, the gateway MUST recalculate the FC CRC.
受信ゲートウェイは、受信された場合、未定義であることがS_IDとD_IDフィールドの内容を考慮しなければなりません。これらのフィールドを交換した後、ゲートウェイは、FC CRCを再計算しなければなりません。
iFCP gateways in address translation mode SHALL NOT originate or accept frames that have the TRP bit set to one in the iFCP flags field of the encapsulation header. The iFCP gateway SHALL immediately abort all iFCP sessions with the iFCP gateway from which it receives frames such as those described in Section 5.2.3.
アドレス変換モードでのiFCPゲートウェイは、発信またはTRPビットがカプセル化ヘッダーのiFCPゲートフラグフィールド内の1に設定されているフレームを受け付けないものとします。 iFCPゲートゲートウェイは直ちにそのようなセクション5.2.3に記載されるもののようなフレームを受信し、そこからのiFCPゲートウェイとのすべてのiFCPセッションを中断します。
The main function of the iFCP protocol layer is to transport fibre channel frame images between locally and remotely attached N_PORTs.
iFCPプロトコル層の主な機能は、ローカルおよびリモート取り付けN_ポート間のファイバチャネルフレーム画像を輸送することです。
When transporting frames to a remote N_PORT, the iFCP layer encapsulates and routes the fibre channel frames comprising each fibre channel Information Unit via a predetermined TCP connection for transport across the IP network.
リモートN_PORTにフレームを輸送するとき、のiFCP層は、IPネットワークを介して輸送するための所定のTCP接続を介してファイバチャネル情報ユニットを含むファイバ・チャネル・フレームをカプセル化経路。
When receiving fibre channel frame images from the IP network, the iFCP layer de-encapsulates and delivers each frame to the appropriate N_PORT.
IPネットワークからファイバチャネルフレーム画像のiFCP層脱カプセル化を受けて適切なN_PORTに各フレームを配信します。
The iFCP layer processes the following types of traffic:
iFCP層は、以下のタイプのトラフィックを処理します。
a) FC-4 frame images associated with a fibre channel application protocol.
A）FC-4のフレーム画像は、ファイバ・チャネル・アプリケーション・プロトコルに関連付けられています。
b) FC-2 frames comprising fibre channel link service requests and responses.
B）FC-2は、ファイバチャネルリンクサービス要求と応答を含むフレーム。
c) Fibre channel broadcast frames.
C）ファイバー・チャネル・ブロードキャストフレーム。
d) iFCP control messages required to set up, manage, or terminate an iFCP session.
D）のiFCPコントロールメッセージは、セットアップ、管理、またはのiFCPセッションを終了するために必要。
For FC-4 N_PORT traffic and most FC-2 messages, the iFCP layer never interprets the contents of the frame payload.
FC-4 N_PORTトラフィックと最もFC-2メッセージのために、iFCPゲート層は、フレームペイロードの内容を解釈することはありません。
iFCP does interpret and process iFCP control messages and certain link service messages, as described in Section 5.1.2.
iFCPは解釈して、セクション5.1.2で説明したように、のiFCPコントロールメッセージと特定のリンクサービスメッセージを処理しません。
iFCP must intervene in the processing of those fibre channel link service messages that contain N_PORT addresses in the message payload or that require other special handling, such as an N_PORT login request (PLOGI).
iFCPは、メッセージペイロード内N_PORTアドレスを含むか、そのようなNポートログイン要求（PLOGI）など、他の特別な処理を必要とするものファイバチャネルリンクサービスメッセージの処理に介入しなければなりません。
In the former case, an iFCP gateway operating in address translation mode MUST supplement the payload with additional information that enables the receiving gateway to convert such embedded N_PORT addresses to its frame of reference.
前者の場合、アドレス変換モードで動作するのiFCPゲートウェイを参照のそのフレームに埋め込まれたそのようなNポートアドレスを変換する受信側ゲートウェイを可能にする追加情報をペイロードを補足しなければなりません。
For out bound fibre channel frames comprising such a link service, the iFCP layer creates the supplemental information based on frame content, modifies the frame payload, and then transmits the resulting fibre channel frame with supplemental data through the appropriate TCP connection.
このようなリンクサービスを含むアウト結合ファイバ・チャネル・フレームのために、iFCPゲート層は、フレームの内容に基づいて補足情報を生成するフレームペイロードを修正し、適切なTCP接続を介して補足データを有する得られたファイバ・チャネル・フレームを送信します。
For incoming iFCP frames containing supplemented fibre channel link service frames, iFCP must interpret the frame, including any supplemental information, modify the frame content, and forward the resulting frame to the destination N_PORT for further processing.
補充ファイバチャネルリンク・サービス・フレームを含む着信のiFCPフレームに対して、iFCPゲートは、任意の補足情報を含むフレームを、解釈フレーム内容を変更し、さらなる処理のために先N_PORTに得られたフレームを転送しなければなりません。
Section 7.1 describes the processing of these link service messages in detail.
7.1節では詳細にこれらのリンクサービスメッセージの処理を説明します。
An iFCP session consists of the pair of N_PORTs comprising the session endpoints joined by a single TCP/IP connection. No more than one iFCP session SHALL exist between a given pair of N_PORTs.
iFCPセッションは、単一のTCP / IP接続によって接合されたセッション・エンドポイントを含むN_ポートのペアから構成されています。いいえつ以上のiFCPセッションはN_ポートの所与の対の間に存在しないものとします。
An N_PORT is identified by its network address, consisting of:
N_PORTは以下からなる、そのネットワークアドレスによって識別されます。
a) the N_PORT ID assigned by the gateway to which the N_PORT is locally attached, and
A）N_PORTがローカルに接続されたゲートウェイによって割り当てられたN_PORT IDを、そして
b) the iFCP Portal address, consisting of its IP address and TCP port number.
B）のiFCP Portalのアドレス、そのIPアドレスとTCPポート番号からなります。
Because only one iFCP session may exist between a pair of N_PORTs, the iFCP session is uniquely identified by the network addresses of the session end points.
唯一のiFCPセッションはN_ポートの対の間に存在する可能性があるため、のiFCPセッションを一意セッションエンドポイントのネットワークアドレスで識別されます。
TCP connections that may be used for iFCP sessions between pairs of iFCP portals are either "bound" or "unbound". An unbound connection is a TCP connection that is not actively supporting an iFCP session. A gateway implementation MAY establish a pool of unbound connections to reduce the session setup time. Such pre-existing TCP connections between iFCP Portals remain unbound and uncommitted until allocated to an iFCP session through a CBIND message (see Section 6.1).
iFCPポータルのペア間のiFCPセッションのために使用することができるTCP接続が「バウンド」または「結合していない」のいずれかです。結合していない接続が積極的のiFCPセッションをサポートしていないTCP接続です。ゲートウェイの実装では、セッションセットアップ時間を短縮するために結合していない接続のプールを確立することができます。 CBINDメッセージを通じてのiFCPセッションに割り当てまでのiFCPポータルとの間のこのような既存のTCP接続（セクション6.1を参照）を結合していないと、コミットされていないままです。
When the iFCP layer creates an iFCP session, it may select an existing unbound TCP connection or establish a new TCP connection and send the CBIND message down that TCP connection. This allocates the TCP connection to that iFCP session.
iFCP層はのiFCPセッションを作成するときに、既存の結合していないTCP接続を選択するか、新しいTCP接続を確立し、そのTCPコネクションダウンCBINDメッセージを送信することができます。これは、のiFCPセッションへのTCP接続を割り当てます。
This section describes the protocols and data structures required to establish and terminate an iFCP session.
このセクションでは、のiFCPセッションを確立し、終了するのに必要なプロトコルとデータ構造を説明しています。
In order to establish an iFCP session, an iFCP gateway MUST maintain information allowing it to locate a remotely attached N_PORT. For explanatory purposes, such information is assumed to reside in a descriptor with the format shown in Figure 10.
iFCPセッションを確立するために、iFCPゲートゲートウェイは、リモート取り付けN_PORTを探しすることを可能にする情報を維持しなければなりません。説明の目的のために、そのような情報は、図10に示すフォーマットで記述内に存在すると仮定されます。
+--------------------------------+
| N_PORT Worldwide Unique Name |
+--------------------------------+
| iFCP Portal Address |
+--------------------------------+
| N_PORT ID of Remote N_PORT |
+--------------------------------+
| N_PORT Alias |
+--------------------------------+
Figure 10. Remote N_PORT Descriptor
図10.リモートN_PORT記述子
Each descriptor aggregates the following information about a remotely attached N_PORT:
各記述子は、リモートで接続N_PORTに関する次の情報を集約します。
N_PORT Worldwide Unique Name -- 64-bit N_PORT worldwide name as specified in [FC-FS]. A Remote N_PORT descriptor is uniquely identified by this parameter.
[FC-FS]で指定された64ビットのN_PORT世界的に名 - N_PORT世界のユニークな名前。リモートN_PORT記述子が一意に、このパラメータによって識別されます。
iFCP Portal Address -- The IP address and TCP port number referenced when creation of the TCP connection associated with an iFCP session is requested.
iFCP Portalの住所 - のiFCPセッションに関連付けられているTCPコネクションの作成が要求されたときに参照IPアドレスとTCPポート番号。
N_PORT ID -- N_PORT fibre channel address assigned to the remote device by the remote iFCP gateway.
NポートID - リモートのiFCPゲートウェイによって遠隔デバイスに割り当てられたN_PORTファイバ・チャネル・アドレス。
N_PORT Alias -- N_PORT fibre channel address assigned to the remote device by the 'local' iFCP gateway when it operates in address translation mode.
N_PORTエイリアス - それはアドレス変換モードで動作する「ローカル」のiFCPゲートウェイによって遠隔デバイスに割り当てられたN_PORTファイバ・チャネル・アドレス。
An iFCP gateway SHALL have one and only one descriptor for each remote N_PORT it accesses. If a descriptor does not exist, one SHALL be created using the information returned by an iSNS name server query. Such queries may result from:
iFCPゲートゲートウェイは、それがアクセスする各リモートN_PORTのための、唯一の記述を持たなければなりません。記述子が存在しない場合は、1は、iSNSネームサーバのクエリによって返された情報を使用して作成するものとします。このようなクエリはに起因することがあります。
a) a fibre channel Name Server request originated by a locally attached N_PORT (see Sections 3.5 and 9.3), or
ローカル接続N_PORTによって発信a）はファイバーチャネルネームサーバ要求（セクション3.5および9.3を参照されたい）、又は
b) a CBIND request received from a remote fibre channel device (see Section 5.2.2.2).
B）CBIND要求は、リモートファイバチャネルデバイス（セクション5.2.2.2を参照）から受け取りました。
When creating a descriptor in response to an incoming CBIND request, the iFCP gateway SHALL perform an iSNS name server query using the worldwide port name of the remote N_PORT in the SOURCE N_PORT NAME field within the CBIND payload. The descriptor SHALL be filled in using the query results.
着信CBIND要求に応答して記述子を作成する場合、iFCPゲートゲートウェイはCBINDペイロード内SOURCE N_PORT名フィールドにリモートN_PORTのワールド・ワイド・ポート名を使用したiSNSネームサーバクエリを実行しなければなりません。記述子は、クエリ結果を用いて充填するものとします。
After creating the descriptor, a gateway operating in address translation mode SHALL create and add the 24-bit N_PORT alias.
ディスクリプタを作成した後、アドレス変換モードで動作するゲートウェイは、24ビットのN_PORTエイリアスを作成して追加しないものとします。
A Remote N_PORT descriptor SHALL only be updated as the result of an iSNS query to obtain information for the specified worldwide port name or from information returned by an iSNS state change notification. Following such an update, a new N_PORT alias SHALL NOT be assigned.
リモートN_PORT記述子には、必ず指定のワールドワイド・ポート名またはiSNSの状態変化通知によって返された情報から情報を取得するためのiSNSクエリの結果として更新されるものとします。このような更新に続いて、新しいN_PORT別名を割り当てることがないものとします。
Before such an update, the contents of a descriptor may have become stale because of an event that invalidated or triggered a change in the N_PORT network address of the remote device, such as a fabric reconfiguration or the device's removal or replacement.
このような更新の前に、記述の内容があるため、このようなファブリックの再構成やデバイスの取り外しや交換など、リモートデバイスのN_PORTネットワークアドレスの変更を無効またはトリガしたイベントの古くなっている可能性があります。
A collateral effect of such an event is that a fibre channel device that has been added or whose N_PORT ID has changed will have no active N_PORT logins. Consequently, FC-4 traffic directed to such an N_PORT, because of a stale descriptor, will be rejected or discarded.
そのようなイベントの担保効果が追加されたファイバ・チャネル・デバイスまたはそのN_PORT ID変更されたが、アクティブなNポートログインを持たないことです。従って、なぜなら陳腐ディスクリプタのようなN_PORTに向けFC-4トラフィックは、拒否または廃棄されます。
Once the originating N_PORT learns of the reconfiguration, usually through the name server state change notification mechanism, information returned in the notification or the subsequent name server lookup needed to reestablish the iFCP session will automatically purge such stale data from the gateway.
N_PORTは、再構成を学習し、発信すると、通常ネームサーバの状態変化通知機構を介して、通知やのiFCPセッションを再確立するために必要な、その後のネームサーバのルックアップで返された情報が自動的にゲートウェイから、このような古いデータを消去します。
Deleting a remote N_PORT descriptor is equivalent to freeing up the corresponding N_PORT alias for reuse. Consequently, the descriptor MUST NOT be deleted while there are any iFCP sessions that reference the remote N_PORT.
リモートN_PORT記述子を削除すると、再利用のため、対応するN_PORT別名を解放することと同じです。リモートN_PORTを参照するのiFCPセッションがある一方、その結果、記述は削除しないでください。
Descriptors eligible for deletion should be removed based on a last in, first out policy.
削除対象の記述子が最初に出て政策、の最後に基づいて削除する必要があります。
An iFCP session may be in one of the following states:
iFCPセッションは、次のいずれかの状態であってもよいです。
OPEN -- The session state in which fibre channel frame images may be sent and received.
OPEN - ファイバ・チャネル・フレーム画像を送受信可能なセッション状態。
OPEN PENDING -- The session state after a gateway has issued a CBIND request but no response has yet been received. No fibre channel frames may be sent.
OPEN PENDING - ゲートウェイ後のセッション状態がCBIND要求を発行したが、応答がまだ受信していません。いいえファイバー・チャネル・フレームが送信されないことがあります。
The session may be initiated in response to a PLOGI ELS (see Section 7.3.1.7) or for any other implementation-specific reason.
セッションはPLOGI ELSに応答して開始することができる（セクション7.3.1.7を参照）、または任意の他の実装固有の理由。
The gateway SHALL create the iFCP session as follows:
次のようにゲートウェイは、のiFCPセッションを作成しなければなりません。
a) Locate the remote N_PORT descriptor corresponding to the session end point. If the session is created in order to forward a fibre channel frame, then the session endpoint may be obtained by referencing the remote N_PORT alias contained in the frame header D_ID field. If no descriptor exists, an iFCP session SHALL NOT be created.
a）は、セッション終了点に対応するリモートN_PORT記述子を見つけ。セッションは、ファイバチャネルフレームを転送するために作成されている場合、セッション・エンドポイントは、フレームヘッダD_IDフィールドに含まれるリモートN_PORTエイリアスを参照することによって得ることができます。何の記述子が存在しない場合、のiFCPセッションが作成されないものとします。
b) Allocate a TCP connection to the gateway to which the remote N_PORT is locally attached. An implementation may use an existing connection in the Unbound state, or a new connection may be created and placed in the Unbound state.
B）リモートN_PORTがローカルに接続されたゲートウェイへのTCP接続を割り当てます。実装は、結合していない状態で既存の接続を使用することができる、または新しい接続が作成され、結合していない状態に置かれてもよいです。
When a connection is created, the IP address and TCP Port number SHALL be obtained by referencing the remote N_PORT descriptor as specified in Section 5.2.2.1.
接続が作成されると、IPアドレスとTCPポート番号は5.2.2.1項で指定されたリモートN_PORT記述子を参照することによって得られるものとします。
c) If the TCP connection cannot be allocated or cannot be created due to limited resources, the gateway SHALL terminate session creation.
TCP接続を割り当てることができないか、限られた資源のために作成することができない場合c）に、ゲートウェイは、セッションの作成を終了するものとします。
d) If the TCP connection is aborted for any reason before the iFCP session enters the OPEN state, the gateway SHALL respond in accordance with Section 5.2.3 and MAY terminate the attempt to create a session or MAY try to establish the TCP connection again.
iFCPセッションがOPEN状態に入る前に、TCP接続が何らかの理由で中止された場合d）に、ゲートウェイは、5.2.3項に従って応答しなければならないし、セッションを作成しようとする試みを終了することができたり、再びTCP接続を確立しようとします。
e) The gateway SHALL then issue a CBIND session control message (see Section 6.1) and place the session in the OPEN PENDING state.
e）のゲートウェイは、CBINDセッション制御メッセージを発行する（6.1節を参照）、OPEN PENDING状態でセッションを置くものとします。
f) If a CBIND response is returned with a status other than "Success" or "iFCP session already exists", the session SHALL be terminated, and the TCP connection returned to the Unbound state.
CBIND応答が「成功」または「のiFCPセッションが既に存在する」以外のステータスで返された場合f）は、セッションは終了するものとし、TCP接続が結合していない状態に戻りました。
g) A CBIND STATUS of "iFCP session already exists" indicates that the remote gateway has concurrently initiated a CBIND request to create an iFCP session between the same pair of N_PORTs. A gateway receiving such a response SHALL terminate this attempt and process the incoming CBIND request in accordance with Section 5.2.2.3.
G）「のiFCPセッションが既に存在する」のCBIND状況は、リモート・ゲートウェイが同時にN_ポートの同一の対の間のiFCPセッションを作成するためにCBIND要求を開始したことを示します。そのような応答を受信したゲートウェイは、この試みを終了し、セクション5.2.2.3に従って着信CBIND要求を処理SHALL。
h) In response to a CBIND STATUS of "Success", the gateway SHALL place the session in the OPEN state.
h）が「成功」のCBIND状況に応じて、ゲートウェイが開いた状態でセッションを置くものとします。
Once the session is placed in the OPEN state, an iFCP session descriptor SHALL be created, containing the information shown in Figure 11:
セッションが開いた状態で配置されると、のiFCPセッション記述は、図11に示す情報を含む、作成しなければなりません。
+-----------------------+
|TCP Connection Context |
+-----------------------+
| Local N_PORT ID |
+-----------------------+
| Remote N_PORT ID |
+-----------------------+
| Remote N_PORT Alias |
+-----------------------+
Figure 11. iFCP Session Descriptor
図11のiFCPセッション記述子
TCP Connection Context -- Information required to identify the TCP connection associated with the iFCP session.
TCP接続コンテキスト - のiFCPセッションに関連付けられているTCPコネクションを識別するために必要な情報。
Local N_PORT ID -- N_PORT ID of the locally attached fibre channel device.
ローカルNポートID - ローカルに接続され、ファイバチャネルデバイスのN_PORT ID。
Remote N_PORT ID -- N_PORT ID assigned to the remote device by the remote gateway.
リモートNポートID - リモート・ゲートウェイによって遠隔装置に割り当てられたN_PORT ID。
Remote N_PORT Alias -- Alias assigned to the remote N_PORT by the local gateway when it operates in address translation mode. If in this mode, the gateway SHALL copy this parameter from the Remote N_PORT descriptor. Otherwise, it is not filled in.
リモートN_PORTエイリアス - それはアドレス変換モードで動作ローカルゲートウェイによってリモートN_PORTに割り当てられた別名。このモードでの場合は、ゲートウェイは、リモートN_PORT記述子から、このパラメータをコピーするものとします。それ以外の場合は、記入されていません。
The gateway receiving a CBIND request SHALL respond as follows:
次のようにCBIND要求を受信したゲートウェイが応答しなければなりません。
a) If the receiver has a duplicate iFCP session in the OPEN PENDING state, then the receiving gateway SHALL compare the Source N_PORT Name in the incoming CBIND payload with the Destination N_PORT Name.
受信機は、OPEN PENDING状態に重複のiFCPセッションがある場合は、A）は、受信側ゲートウェイは、宛先N_PORT名と着信CBINDペイロードにソースN_PORT名を比較しなければなりません。
b) If the Source N_PORT Name is greater, the receiver SHALL issue a CBIND response of "Success" and SHALL place the session in the OPEN state.
ソースN_PORT Nameが大きい場合b）に、受信機は、「成功」のCBIND応答を発行しなければならないし、オープン状態でセッションを置くものとします。
c) If the Source N_PORT Name is less, the receiver shall issue a CBIND RESPONSE of Failed - N_PORT session already exists. The state of the receiver-initiated iFCP session SHALL BE unchanged.
ソースN_PORT Nameが小さい場合c）は、受信機は失敗したのCBIND応答を発行するもの - N_PORTセッションがすでに存在しています。受信機が開始したのiFCPセッションの状態は変わらないことがすべてです。
d) If there is no duplicate iFCP session in the OPEN PENDING state, the receiving gateway SHALL issue a CBIND response. If a status of Success is returned, the receiving gateway SHALL create the iFCP session and place it in the OPEN state. An iFCP session descriptor SHALL be created as described in Section 5.2.2.2.
OPEN PENDING状態にある重複のiFCPセッションがない場合d）に、受信側ゲートウェイは、CBIND応答を発行しなければなりません。成功のステータスが返された場合、受信側ゲートウェイは、のiFCPセッションを作成し、OPEN状態に置くものとします。 5.2.2.2項で説明したようにのiFCPセッション記述子が作成されるものとします。
e) If a remote N_PORT descriptor does not exist, one SHALL be created and filled in as described in Section 5.2.2.1.
リモートN_PORT記述子が存在しない場合は、セクション5.2.2.1で説明したように電子）、1が作成され、記入されるものとする（SHALL）。
During extended periods of inactivity, an iFCP session may be terminated due to a hardware failure within the gateway or through loss of TCP/IP connectivity. The latter may occur when the session traverses a stateful intermediate device, such as a NA(P)T box or firewall, that detects and purges connections it believes are unused.
非アクティブの長い期間の間、のiFCPセッションは、ゲートウェイ内またはTCP / IP接続の切断を介してハードウェア障害による終了してもよいです。セッションは、それが未使用であると考えている接続を検出し、パージNA（P）Tボックスまたはファイアウォールなどのステートフル中間デバイスを横断する場合、後者が発生する可能性があります。
To test session liveness, expedite the detection of connectivity failures, and avoid spontaneous connection termination, an iFCP gateway may maintain a low level of session activity and monitor the session by requesting that the remote gateway periodically transmit the LTEST message described in Section 6.3. All iFCP gateways SHALL support liveness testing as described in this specification.
、セッションの生存性をテストする接続障害の検出を促進し、自発的接続の終了を回避するために、iFCPゲートゲートウェイは、セッション活動の低レベルを維持し、リモートゲートウェイが周期的セクション6.3に記載LTESTメッセージを送信することを要求することによって、セッションを監視することができます。本明細書に記載されているすべてのiFCPゲートウェイは生存性のテストをサポートします。
A gateway requests the LTEST heartbeat by specifying a non-zero value for the LIVENESS TEST INTERVAL in the CBIND request or response message as described in Section 6.1. If both gateways seek to monitor liveness, each must set the LIVENESS TEST INTERVAL in the CBIND request or response.
ゲートウェイは、第6.1節で説明したようにCBIND要求または応答メッセージ内LIVENESS試験間隔に対する非ゼロ値を指定することによってLTESTハートビートを要求します。両方のゲートウェイが生存性を監視しようとした場合、それぞれがCBIND要求または応答でLIVENESSテスト間隔を設定する必要があります。
Upon receiving such a request, the gateway providing the heartbeat SHALL transmit LTEST messages at the specified interval. The first message SHALL be sent as soon as the iFCP session enters the OPEN state. LTEST messages SHALL NOT be sent when the iFCP session is not in the OPEN state.
このような要求を受信すると、ハートビートを提供するゲートウェイが指定された間隔でLTESTメッセージを送付します。 iFCPセッションがOPEN状態に入ると、最初のメッセージは、すぐに送付されなければなりません。 iFCPセッションがOPEN状態でない場合LTESTメッセージが送信されないものとします。
An iFCP session SHALL be terminated as described in Section 5.2.3 if:
場合は、セクション5.2.3で説明したようにのiFCPセッションが終了しなければなりません。
a) the contents of the LTEST message are incorrect, or
A）LATESTメッセージの内容が間違っている、または
b) an LTEST message is not received within twice the specified interval or the iFCP session has been quiescent for longer than twice the specified interval.
B）LTESTメッセージが2度指定期間内に受信されないかのiFCPセッションが長い2倍以上指定間隔で静止してきました。
The gateway to receive the LTEST message SHALL measure the interval for the first expected LTEST message from when the session is placed in the OPEN state. Thereafter, the interval SHALL be measured relative to the last LTEST message received.
LTESTメッセージを受信するゲートウェイは、最初にセッションが開放状態に置かれたときからLTESTメッセージを予想するための間隔を測定しなければなりません。その後、間隔は、メッセージが受信された最後のLTESTに対して測定しなければなりません。
To maximize liveness test coverage, LTEST messages SHOULD flow through all the gateway components used to enter and retrieve fibre channel frames from the IP network, including the mechanisms for encapsulating and de-encapsulating fibre channel frames.
ライブネステストカバレッジを最大にするために、LTESTメッセージはカプセル化と脱カプセル化ファイバ・チャネル・フレームのためのメカニズムを含むIPネットワークからファイバチャネルフレームを入力し、検索するために使用されるすべてのゲートウェイコンポーネント、流れるべきです。
In addition to monitoring a session, information in the LTEST message encapsulation header may also be used to compute an estimate of network propagation delay, as described in Section 8.2.1. However, the propagation delay limit SHALL NOT be enforced for LTEST traffic.
8.2.1項で説明したように、セッションを監視することに加えて、LTESTメッセージのカプセル化ヘッダ内の情報はまた、ネットワーク伝播遅延の推定値を計算するために使用することができます。しかし、伝搬遅延の上限はLTESTトラフィックに適用されないものとします。
This section describes ground rules for the use of TCP features in an iFCP session. The core TCP protocol is defined in [RFC793]. TCP implementation requirements and guidelines are specified in [RFC1122].
このセクションでは、のiFCPセッションにおけるTCPの機能を使用するための基本原則を説明しています。コアTCPプロトコルは、[RFC793]で定義されています。 TCPの実装要件とガイドラインは[RFC1122]で指定されています。
+-----------+------------+--------------+------------+------------+
| Feature | Applicable | RFC | Peer-Wise | Requirement|
| | RFCs | Status | Agreement | Level |
| | | | Required? | |
+===========+============+==============+============+============+
| Keep Alive| [RFC1122] | None | No | Should not |
| |(discussion)| | | use |
+-----------+------------+--------------+------------+------------+
| Tiny | [RFC896] | Standard | No | Should not |
| Segment | | | | use |
| Avoidance | | | | |
| (Nagle) | | | | |
+-----------+------------+--------------+------------+------------+
| Window | [RFC1323] | Proposed | No | Should use |
| Scale | | Standard | | |
+-----------+------------+--------------+------------+------------+
| Wrapped | [RFC1323] | Proposed | No | SHOULD use |
| Sequence | | Standard | | |
| Protection| | | | |
| (PAWS) | | | | |
+-----------+------------+--------------+------------+------------+
Table 1. Usage of Optional TCP Features
オプションのTCPの機能の表1使用法
The following sections describe these options in greater detail.
次のセクションでは、より詳細に、これらのオプションについて説明します。
Keep Alive speeds the detection and cleanup of dysfunctional TCP connections by sending traffic when a connection would otherwise be idle. The issues are discussed in [RFC1122].
アライブは、接続がアイドル状態になる際にトラフィックを送信することによって、機能不全TCPコネクションの検出とクリーンアップを高速化してください。問題は[RFC1122]に記載されています。
In order to test the device more comprehensively, fibre channel applications, such as storage, may implement an equivalent keep alive function at the FC-4 level. Alternatively, periodic liveness test messages may be issued as described in Section 5.2.2.4. Because of these more comprehensive end-to-end mechanisms and the considerations described in [RFC1122], keep alive at the transport layer should not be implemented.
より包括的デバイスをテストするために、このような記憶のようなファイバ・チャネル・アプリケーションは、同等のFC-4レベルで生きている機能を保持する実装することができます。セクション5.2.2.4で説明したように別の方法として、定期的なライブネステストメッセージを発行することができます。なぜなら、これらのより包括的なエンドツーエンドのメカニズム及び[RFC1122]に記載の考慮、実施されるべきではないトランスポート層でキープアライブ。
The Nagle algorithm described in [RFC896] is designed to avoid the overhead of small segments by delaying transmission in order to agglomerate transfer requests into a large segment. In iFCP, such small transfers often contain I/O requests. The transmission delay of the Nagle algorithm may decrease I/O throughput. Therefore, the Nagle algorithm should not be used.
[RFC896]に記載のNagleアルゴリズムは、大きなセグメントに転送要求を凝集させるために送信を遅延させることにより、小さなセグメントのオーバーヘッドを回避するように設計されています。 iFCPゲートでは、このような小さな転送は、多くの場合、I / O要求が含まれています。 Nagleアルゴリズムの伝送遅延は、I / Oスループットを減少させることができます。そのため、Nagleアルゴリズムを使用すべきではありません。
Window scaling, as specified in [RFC1323], allows full use of links with large bandwidth - delay products and should be supported by an iFCP implementation.
ウィンドウスケーリングは、[RFC1323]で指定されるように、大きな帯域幅を有するリンクを完全に利用可能にする - 遅延製品とのiFCP実装によってサポートされなければなりません。
TCP segments are identified with 32-bit sequence numbers. In networks with large bandwidth - delay products, it is possible for more than one TCP segment with the same sequence number to be in flight. In iFCP, receipt of such a sequence out of order may cause out-of-order frame delivery or data corruption. Consequently, this feature SHOULD be supported as described in [RFC1323].
TCPセグメントは、32ビットのシーケンス番号で識別されます。大規模な帯域幅のネットワークでは - 同じシーケンス番号を持つ複数のTCPセグメントが飛行中であるために遅延製品、それが可能です。 iFCPゲートにおいて、注文のうち、このようなシーケンスの受信は、アウトオブオーダーフレーム送達またはデータの破損を引き起こす可能性があります。 [RFC1323]に記載されているように、結果として、この機能がサポートされてください。
iFCP sessions SHALL be terminated in response to one of the events in Table 2:
iFCPセッションは、表2のイベントの一つに対応して終了しなければなりません。
+-------------------------------------------+---------------------+
| Event | iFCP Sessions |
| | to Terminate |
+===========================================+=====================+
| PLOGI terminated with LS_RJT response | Peer N_PORT |
+-------------------------------------------+---------------------+
| State change notification indicating | All iFCP Sessions |
| N_PORT removal or reconfiguration. | from the |
| | reconfigured N_PORT |
+-------------------------------------------+---------------------+
| LOGO ACC response from peer N_PORT | Peer N_PORT |
+-------------------------------------------+---------------------+
| ACC response to LOGO ELS sent to F_PORT | All iFCP sessions |
| server (D_ID = 0xFF-FF-FE) (fabric | from the originating|
| logout) | N_PORT |
+-------------------------------------------+---------------------+
| Implicit N_PORT LOGO as defined in | All iFCP sessions |
| [FC-FS] | from the N_PORT |
| | logged out |
+-------------------------------------------+---------------------+
| LTEST Message Error (see Section 5.2.2.4) | Peer N_PORT |
+-------------------------------------------+---------------------+
| Non fatal encapsulation error as | Peer N_PORT |
| specified in Section 5.3.3 | |
+-------------------------------------------+---------------------+
| Failure of the TCP connection associated | Peer N_PORT |
| with the iFCP session | |
+-------------------------------------------+---------------------+
| Receipt of an UNBIND session control | Peer N_PORT |
| message | |
+-------------------------------------------+---------------------+
| Gateway enters the Unsynchronized state | All iFCP sessions |
| (see Section 8.2.1) | |
+-------------------------------------------+---------------------+
| Gateway detects incorrect address mode | All iFCP sessions |
| to peer gateway(see Section 4.6.2) | with peer gateway |
+-------------------------------------------+---------------------+
Table 2. Session Termination Events
表2セッション終了イベント
If a session is being terminated due to an incorrect address mode with the peer gateway, the TCP connection SHALL be aborted by means of a connection reset (RST) without performing an UNBIND. Otherwise, if the TCP connection is still open following the event, the gateway SHALL shut down the connection as follows:
セッションが原因ピアゲートウェイとの誤ったアドレスモードに終端されている場合、TCP接続はUNBINDを行うことなく、接続リセット（RST）によって中断されSHALL。 TCP接続がイベントに続いて、まだ開いている場合は、次のようにそれ以外の場合は、ゲートウェイが接続をシャットダウンしなければなりません。
a) Stop sending fibre channel frames over the TCP connection.
a）はTCP接続上でファイバチャネルフレームの送信を停止します。
b) Discard all incoming traffic, except for an UNBIND session control message.
B）UNBINDセッション制御メッセージを除き、すべての着信トラフィックを破棄します。
c) If an UNBIND message is received at any time, return a response in accordance with Section 6.2.
UNBINDメッセージは、任意の時点で受信された場合c）に示すように、セクション6.2に従って、応答を返します。
d) If session termination was not triggered by an UNBIND message, issue the UNBIND session control message, as described in Section 6.2.
d）の6.2節で説明したように、セッションの終了が、UNBINDセッション制御メッセージを発行し、UNBINDメッセージによってトリガされていなかった場合。
e) If the UNBIND message completes with a status of Success, the TCP connection MAY remain open at the discretion of either gateway and may be kept in a pool of unbound connections in order to speed up the creation of a new iFCP session.
UNBINDメッセージが成功の状態で完了した場合e）は、TCPコネクションは、ゲートウェイのいずれかの裁量で開いたままかもしれなくて、新しいのiFCPセッションの作成をスピードアップするために、結合していない接続のプールに保持することができます。
If the UNBIND fails for any reason, the TCP connection MUST be terminated. In this case, the connection SHOULD be aborted with a connection reset (RST).
UNBINDが何らかの理由で失敗した場合、TCP接続は終了されなければなりません。この場合、接続は、接続リセット（RST）で中止されるべきです。
For each terminated session, the session descriptor SHALL be deleted. If a session was terminated by an event other than an implicit LOGO or a LOGO ACC response, the gateway shall issue a LOGO to the locally attached N_PORT on behalf of the remote N_PORT.
各セッション終了の場合は、セッション記述子が削除されるものとします。セッションが暗黙のロゴやロゴACC応答以外のイベントにより終了した場合、ゲートウェイはリモートN_PORTに代わって、ローカルに接続されたN_PORTにロゴを発行しなければなりません。
To recover resources, either gateway may spontaneously close an unbound TCP connection at any time. If a gateway terminates a connection with a TCP close operation, the peer gateway MUST respond by executing a TCP close.
資源を回復するには、いずれかのゲートウェイが自発的にいつでも結合していないTCP接続を閉じることができます。ゲートウェイは、TCPクローズ操作との接続を終了した場合、ピアゲートウェイは、TCPクローズを実行することによって応答しなければなりません。
This section describes the iFCP encapsulation of fibre channel frames. The encapsulation complies with the common encapsulation format defined in [ENCAP], portions of which are included here for convenience.
このセクションでは、ファイバ・チャネル・フレームのカプセル化のiFCPを説明しています。カプセル化は[ENCAP]で定義された一般的なカプセル化フォーマットに準拠して、の部分は、ここで便宜上含まれます。
The format of an encapsulated frame is shown below:
カプセル化されたフレームのフォーマットを以下に示します。
+--------------------+
| Header |
+--------------------+-----+
| SOF | f |
+--------------------+ F r |
| FC frame content | C a |
+--------------------+ m |
| EOF | e |
+--------------------+-----+
Figure 12. Encapsulation Format
図12.カプセル化形式
The encapsulation consists of a 7-word header, an SOF delimiter word, the FC frame (including the fibre channel CRC), and an EOF delimiter word. The header and delimiter formats are described in the following sections.
カプセル化は7ワードヘッダ、SOFデリミタワード、およびEOF区切り文字ワード（ファイバチャンネルCRCを含む）FCフレームから成ります。ヘッダとデリミタフォーマットは、以下のセクションに記載されています。
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------+---------------+---------------+---------------+
0| Protocol# | Version | -Protocol# | -Version |
+---------------+---------------+---------------+---------------+
1| Reserved (must be zero) |
+---------------+---------------+---------------+---------------+
2| LS_COMMAND_ACC| iFCP Flags | SOF | EOF |
+-----------+---+---------------+-----------+---+---------------+
3| Flags | Frame Length | -Flags | -Frame Length |
+-----------+-------------------+-----------+-------------------+
4| Time Stamp [integer] |
+---------------------------------------------------------------+
5| Time Stamp [fraction] |
+---------------------------------------------------------------+
6| CRC |
+---------------------------------------------------------------+
Figure 13. Encapsulation Header Format
図13.カプセル化ヘッダー形式
Common Encapsulation Fields:
一般的なカプセル化フィールド：
Protocol# IANA-assigned protocol number identifying the protocol using the encapsulation. For iFCP, the value assigned by [ENCAP] is 2.
カプセル化を使用してプロトコルを識別するプロトコル＃1 IANAによって割り当てられたプロトコル番号。 iFCPゲートは、[ENCAP]によって割り当てられる値は2です。
Version Encapsulation version, as specified in [ENCAP].
バージョンカプセル化バージョン、[ENCAP]で指定されています。
-Protocol# Ones complement of the Protocol#.
-protocol＃プロトコル番号の補数。
-Version Ones complement of the version.
バージョンの補数を-version。
Flags Encapsulation flags (see 5.3.1.1).
フラグカプセル化フラグ（5.3.1.1を参照）。
Frame Length Contains the length of the entire FC Encapsulated frame, including the FC Encapsulation Header and the FC frame (including SOF and EOF words) in units of 32-bit words.
フレーム長は、FCカプセル化ヘッダと32ビットワード単位で（SOFとEOFの単語を含む）FCフレームを含む全体FCカプセル化されたフレームの長さを含みます。
-Flags Ones complement of the Flags field.
Flagsフィールドの補数を-flags。
-Frame Length Ones complement of the Frame Length field.
-frame長フレーム長フィールドの補数。
Time Stamp [integer] Integer component of the frame time stamp, as specified in [ENCAP].
[ENCAP]で指定されたタイムスタンプ[整数]フレームのタイムスタンプの整数成分、。
Time Stamp Fractional component of the time stamp, [fraction] as specified in [ENCAP].
[ENCAP]で指定されたタイムスタンプのタイムスタンプ分数成分、[分数]。
CRC Header CRC. MUST be valid for iFCP.
CRCヘッダCRC。 iFCPのために有効である必要があります。
The time stamp fields are used to enforce the limit on the lifetime of a fibre channel frame as described in Section 8.2.1.
タイムスタンプフィールドは、セクション8.2.1に記載したように、ファイバ・チャネル・フレームの寿命に制限を強制するために使用されます。
iFCP-Specific Fields:
iFCP固有のフィールド：
LS_COMMAND_ACC For a special link service ACC response to be processed by iFCP, the LS_COMMAND_ACC field SHALL contain a copy of bits 0 through 7 of the LS_COMMAND to which the ACC applies. Otherwise, the LS_COMMAND_ACC field SHALL be set to zero.
iFCPによって処理される特別なリンクサービスACC応答をLS_COMMAND_ACC、LS_COMMAND_ACCフィールドはACCが適用されるLS_COMMANDの7を通じてビット0のコピーを含まなければなりません。それ以外の場合は、LS_COMMAND_ACCフィールドがゼロに設定されなければなりません。
iFCP Flags iFCP-specific flags (see below).
iFCPフラグのiFCP固有のフラグ（下記参照）。
SOF Copy of the SOF delimiter encoding (see Section 5.3.2).
SOF区切り文字エンコーディングのSOFコピー（5.3.2項を参照してください）。
EOF Copy of the EOF delimiter encoding (see Section 5.3.2).
EOFデリミタのエンコーディングのEOFコピー（5.3.2項を参照してください）。
The iFCP flags word has the following format:
iFCPフラグワードの形式は次のとおりです。
|------------------------Bit----------------------------|
| |
| 8 9 10 11 12 13 14 15 |
+------+------+------+------+------+------+------+------+
| Reserved | SES | TRP | SPC |
+------+------+------+------+------+------+------+------+
Figure 14. iFCP Flags Word
図14のiFCP国旗ワード
iFCP Flags:
iFCPフラグ：
SES 1 = Session control frame (TRP and SPC MUST be 0)
SES 1 =セッション制御フレーム（TRPとSPCは0でなければなりません）
TRP 1 = Address transparent mode enabled
透過モードが有効になってTRP 1 =住所
0 = Address translation mode enabled
0 =アドレス変換モードが有効になって
SPC 1 = Frame is part of a link service message requiring special processing by iFCP prior to forwarding to the destination N_PORT.
SPC 1 =フレームは、宛先N_PORTに転送する前のiFCPによる特別な処理を必要とするリンクサービスメッセージの一部です。
The iFCP usage of the common encapsulation flags defined in [ENCAP] is shown in Figure 15:
[ENCAP]で定義された一般的なカプセル化フラグのiFCPゲートの使用は、図15に示されています。
|------------------------Bit--------------------------|
| |
| 0 1 2 3 4 5 |
+--------------------------------------------+--------+
| Reserved | CRCV |
+--------------------------------------------+--------+
Figure 15. iFCP Common Encapsulation Flags
図15のiFCP一般的なカプセル化フラグ
For iFCP, the CRC field MUST be valid, and CRCV MUST be set to one.
iFCPゲートについて、CRCフィールドが有効でなければならない、とCRCVは1に設定しなければなりません。
The format of the delimiter fields is shown below.
デリミタフィールドのフォーマットを以下に示します。
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------+---------------+---------------+---------------+
0| SOF | SOF | -SOF | -SOF |
+---------------+---------------+---------------+---------------+
1| |
+----- FC frame content -----+
| |
+---------------+---------------+---------------+---------------+
n| EOF | EOF | -EOF | -EOF |
+---------------+---------------+---------------+---------------+
Figure 16. FC Frame Encapsulation Format
図16. FCフレームのカプセル化形式
SOF (bits 0-7 and bits 8-15 in word 0): iFCP uses the following subset of the SOF fields specified in [ENCAP]. For convenience, these are reproduced in Table 3. The authoritative encodings should be obtained from [ENCAP].
SOF（ビット0-7及びビットワード0で8-15）のiFCPは[ENCAP]で指定されたSOFフィールドの次のサブセットを使用します。便宜上、これらは、権限のエンコーディングが[ENCAP]から得られるべきである表3に再生されます。
+-------+----------+
| FC | |
| SOF | SOF Code |
+-------+----------+
| SOFi2 | 0x2D |
| SOFn2 | 0x35 |
| SOFi3 | 0x2E |
| SOFn3 | 0x36 |
+-------+----------+
Table 3. Translation of FC SOF Values to SOF Field Contents
SOFフィールド内容にFC SOF値の表3翻訳
-SOF (bits 16-23 and 24-31 in word 0): The -SOF fields contain the ones complement the value in the SOF fields.
-SOF（ワード0のビット16-23及び24-31）：-SOFフィールドはものがSOFフィールドに値を補完含みます。
EOF (bits 0-7 and 8-15 in word n): iFCP uses the following subset of EOF fields specified in [ENCAP]. For convenience, these are reproduced in Table 4. The authoritative encodings should be obtained from [ENCAP].
EOF（ビット0-7及びワードnの8-15）のiFCPは[ENCAP]で指定EOFフィールドの次のサブセットを使用します。便宜上、これらは、権限のエンコーディングが[ENCAP]から得なければならない表4に再現されます。
+-------+----------+
| FC | |
| EOF | EOF Code |
+-------+----------+
| EOFn | 0x41 |
| EOFt | 0x42 |
+-------+----------+
Table 4. Translation of FC EOF Values to EOF Field Contents
EOFフィールド内容にFC EOF値の表4.翻訳
-EOF (bits 16-23 and 24-31 in word n): The -EOF fields contain the ones complement the value in the EOF fields.
-EOF（ワードNのビット16-23及び24-31）：-EOFフィールドはものがEOFフィールドに値を補完含みます。
iFCP implementations SHALL place a copy of the SOF and EOF delimiter codes in the appropriate header fields.
iFCP実装は、適切なヘッダフィールドにSOFとEOF区切りコードのコピーを配置するものとします。
A fibre channel Frame to be encapsulated MUST first be validated as described in [FC-FS]. Any frames received from a locally attached fibre channel device that do not pass the validity tests in [FC-FS] SHALL be discarded by the gateway.
[FC-FS]に記載されているようにカプセル化するファイバチャネルフレームが最初に検証されなければなりません。 [FC-FS]における有効性テストに合格しないローカルに接続され、ファイバチャネル装置から受信したフレームは、ゲートウェイによって捨てられるもの。
If the frame is a PLOGI ELS, the creation of an iFCP session, as described in Section 7.3.1.7, may precede encapsulation. Once the session has been created, frame encapsulation SHALL proceed as follows.
フレームはPLOGI ELS、のiFCPセッションの作成である場合、セクション7.3.1.7に記載されるように、カプセル化に先行してもよいです。セッションが作成されたら、次のように、フレームのカプセル化が進むものとします。
The S_ID and D_ID fields in the frame header SHALL be referenced to look up the iFCP session descriptor (see Section 5.2.2.2). If no iFCP session descriptor exists, the frame SHALL be discarded.
フレームヘッダ内のS_IDとD_IDフィールドはのiFCPセッション記述子をルックアップするために参照されるものとする（SHALL）（5.2.2.2項を参照してください）。何のiFCPセッション記述子が存在しない場合、フレームは破棄されるものとする（SHALL）。
Frame types submitted for encapsulation and forwarding on the IP network SHALL have one of the SOF delimiters in Table 3 and an EOF delimiter from Table 4. Other valid frame types MUST be processed internally by the gateway as specified in the appropriate fibre channel specification.
適切なファイバチャネル仕様で指定され、表3及び表4のその他の有効なフレームタイプからEOF区切り文字でSOFデリミタのいずれかを有するものとするIPネットワーク上のカプセル化および転送のために提出フレームタイプは、ゲートウェイによって内部的に処理されなければなりません。
If operating in address translation mode and processing a special link service message requiring the inclusion of supplemental data, the gateway SHALL format the frame payload and add the supplemental information specified in Section 7.1. The gateway SHALL then calculate a new FC CRC on the reformatted frame.
アドレス変換モードで動作し、補足データの包含を必要と特別なリンクサービスメッセージを処理する場合、ゲートウェイは、フレームペイロードをフォーマットし、セクション7.1で指定された補足情報を追加すること。ゲートウェイは、その後、再フォーマット、フレームに新しいFC CRCを計算するものとします。
Otherwise, the frame contents SHALL NOT be modified and the gateway MAY encapsulate and transmit the frame image without recalculating the FC CRC.
そうでなければ、フレームの内容を変更することはならず、ゲートウェイは、FC CRCを再計算することなく、フレーム画像をカプセル化し、送信することができます。
The frame originator MUST then create and fill in the header and the SOF and EOF delimiter words, as specified in Sections 5.3.1 and 5.3.2.
フレームの発信者は、次に作成し、セクション5.3.1及び5.3.2で指定されるように、ヘッダとSOFとEOF区切り単語を記入しなければなりません。
The receiving gateway SHALL perform de-encapsulation as follows:
次のように受信側ゲートウェイは、脱カプセル化を実行しなければなりません。
Upon receiving the encapsulated frame, the gateway SHALL check the header CRC. If the header CRC is valid, the receiving gateway SHALL check the iFCP flags field. If one of the error conditions in Table 5 is detected, the gateway SHALL handle the error as specified in Section 5.2.3.
カプセル化されたフレームを受信すると、ゲートウェイは、ヘッダCRCをチェックしなければなりません。ヘッダCRCが有効な場合、受信側ゲートウェイは、のiFCPフラグフィールドをチェックしなければなりません。表5中のエラー条件のいずれかが検出された場合、セクション5.2.3で指定されるように、ゲートウェイは、エラーを処理SHALL。
+------------------------------+-------------------------+
| Condition | Error Type |
+==============================+=========================+
| Header CRC Invalid | Encapsulation error |
+------------------------------+-------------------------+
| SES = 1, TRP or SPC not 0 | Encapsulation error |
+------------------------------+-------------------------+
| SES = 0, TRP set incorrectly | Incorrect address mode |
+------------------------------+-------------------------+
Table 5. Encapsulation Header Errors
表5.カプセル化ヘッダーエラー
The receiving gateway SHALL then verify the frame propagation delay as described in Section 8.2.1. If the propagation delay is too long, the frame SHALL be discarded. Otherwise, the gateway SHALL check the SOF and EOF in the encapsulation header. A frame SHALL be discarded if it has an SOF code that is not in Table 3 or an EOF code that is not in Table 4.
8.2.1項で説明したように受信側ゲートウェイは、次いで、フレーム伝搬遅延を検証しなければなりません。伝播遅延が長すぎる場合、フレームは破棄されるものとする（SHALL）。そうでない場合、ゲートウェイは、カプセル化ヘッダにSOFとEOFをチェックしなければなりません。それは、表3または表4にないEOFコードでないSOFコードを持っている場合、フレームは廃棄され。
The gateway SHALL then de-encapsulate the frame as follows:
次のように、ゲートウェイは、次いで、フレームを非カプセル化しなければなりません。
a) Check the FC CRC and discard the frame if the CRC is invalid.
A）FC CRCをチェックし、CRCが無効な場合、フレームを廃棄します。
b) If operating in address translation mode, replace the S_ID field with the N_PORT alias of the frame originator, and the D_ID with the N_PORT ID, of the frame recipient. Both parameters SHALL be obtained from the iFCP session descriptor.
アドレス変換モードで動作している場合b）は、フレームの発信元のN_PORTエイリアス、およびフレーム受信者のN_PORT IDとD_IDとS_IDフィールドを交換してください。両方のパラメータがのiFCPセッション記述子から得られるものとします。
c) If processing a special link service message, replace the frame with a copy whose payload has been modified as specified in Section 7.1.
C）特別なリンクサービスメッセージを処理する場合は、ペイロードセクション7.1で指定されるように変更されたコピーでフレームを交換してください。
The de-encapsulated frame SHALL then be forwarded to the N_PORT specified in the D_ID field. If the frame contents have been modified by the receiving gateway, a new FC CRC SHALL be calculated.
脱カプセル化されたフレームは、次に、D_IDフィールドに指定されたN_PORTに送付されるもの。フレームの内容は、受信ゲートウェイによって修飾されている場合は、新しいFC CRCを計算しなければなりません。
TCP session control messages are used to create and manage an iFCP session as described in Section 5.2.2. They are passed between peer iFCP Portals and are only processed within the iFCP layer.
TCPセッション制御メッセージは、5.2.2項で説明したようにのiFCPセッションを作成し、管理するために使用されています。彼らは、ピアのiFCPポータル間で渡されるだけのiFCP層内で処理されています。
The message format is based on the fibre channel extended link service message template shown below.
メッセージフォーマットは、以下に示すファイバチャネル拡張リンク・サービス・メッセージ・テンプレートに基づいています。
Word
0<--Bits-->7 8<---------------Bits------------------------>31
+------------+------------------------------------------------+
0| R_CTL | D_ID [0x00 00 00] |
|[Req = 0x22]| [Destination of extended link Service request] |
|[Rep = 0x23]| |
+------------+------------------------------------------------+
1| CS_CTL | S_ID [0x00 00 00] |
| [0x0] | [Source of extended link service request] |
+------------+------------------------------------------------+
2|TYPE [0x1] | F_CTL [0] |
+------------+------------------+-----------------------------+
3|SEQ_ID | DF_CTL [0x00] | SEQ_CNT [0x00] |
|[0x0] | | |
+------------+------------------+-----------------------------+
4| OX_ID [0x0000] | RX_ID_[0x0000] |
+-------------------------------+-----------------------------+
5| Parameter |
| [ 00 00 00 00 ] |
+-------------------------------------------------------------+
6| LS_COMMAND |
| [Session Control Command Code] |
+-------------------------------------------------------------+
7| |
.| Additional Session Control Parameters |
.| ( if any ) |
n| |
+=============================================================+
n| Fibre Channel CRC |
+| |
1+=============================================================+
Figure 17. Format of Session Control Message
セッション制御メッセージの図17.フォーマット
The LS_COMMAND value for the response remains the same as that used for the request.
応答用LS_COMMAND値を要求するために用いたものと同じままです。
The session control frame is terminated with a fibre channel CRC. The frame SHALL be encapsulated and de-encapsulated according to the rules specified in Section 5.3.
セッション制御フレームは、ファイバチャンネルCRCで終了します。フレームは、セクション5.3で指定された規則に従って、カプセル化および脱カプセル化することがSHALL。
The encapsulation header for the link Service frame carrying a session control message SHALL be set as follows:
次のようにセッション制御メッセージを搬送するリンクサービスフレームのカプセル化ヘッダが設定されなければなりません。
Encapsulation Header Fields:
カプセル化ヘッダフィールド：
LS_COMMAND_ACC 0
LS_COMMAND_ACC 0
iFCP Flags SES = 1
iFCPフラグSES = 1
TRP = 0
TRP = 0
INT = 0
INT = 0
SOF code SOFi3 encoding (0x2E)
SOFコードSOFi3エンコード（0x2E）
EOF code EOFt encoding (0x42)
EOFコードEOFtエンコード（0x42に）
The encapsulation time stamp words SHALL be set as described for each message type.
各メッセージタイプについて説明したようにカプセル化タイムスタンプワードが設定されなければなりません。
The SOF and EOF delimiter words SHALL be set based on the SOF and EOF codes specified above.
SOFとEOF区切り単語は、上記指定されたSOFとEOFコードに基づいて設定されなければなりません。
Table 6 lists the values assigned to byte 0 of the LS_COMMAND field for iFCP session control messages.
表6のiFCPセッション制御メッセージのためLS_COMMANDフィールドのバイト0に割り当てられた値。
+--------------+-------------------------+----------+-------------+
| LS_COMMAND | Function | Mnemonic | iFCP |
| field, byte 0| | | Support |
+--------------+-------------------------+----------+-------------+
| 0xE0 | Connection Bind | CBIND | REQUIRED |
+--------------+-------------------------+----------+-------------+
| 0xE4 | Unbind Connection | UNBIND | REQUIRED |
+--------------+-------------------------+----------+-------------+
| 0xE5 | Test Connection Liveness| LTEST | REQUIRED |
+--------------+-------------------------+----------+-------------+
| 0x01-0x7F | Vendor-Specific | | |
+--------------+-------------------------+----------+-------------+
| 0x00 | Reserved -- Unassignable| | |
+--------------+-------------------------+----------+-------------+
| All other | Reserved | | |
| values | | | |
+--------------+-------------------------+----------+-------------+
Table 6. Session Control LS_COMMAND Field, Byte 0 Values
表6.セッション制御LS_COMMANDフィールド、バイト0の値
As described in Section 5.2.2.2, the CBIND message and response are used to bind an N_PORT login to a specific TCP connection and establish an iFCP session. In the CBIND request message, the source and destination N_PORTs are identified by their worldwide port names. The time stamp words in the encapsulation header SHALL be set to zero in the request and response message frames.
5.2.2.2項で説明したように、CBINDメッセージと応答は、特定のTCP接続にN_PORTログインをバインドするとのiFCPセッションを確立するために使用されています。 CBIND要求メッセージでは、送信元と送信先のN_Portは、彼らのワールドワイド・ポート名によって識別されます。カプセル化ヘッダ内のタイムスタンプの単語は、要求と応答メッセージフレームにゼロに設定されなければなりません。
The following shows the format of the CBIND request.
以下はCBIND要求のフォーマットを示します。
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver |
| | (Seconds) | | |
+------+-------------------------+-----------+----------+
| 2 | USER INFO |
+------+------------+------------+-----------+----------+
| 3 | |
+------+ SOURCE N_PORT NAME |
| 4 | |
+------+------------------------------------------------+
| 5 | |
+------+ DESTINATION N_PORT NAME |
| 6 | |
+------+------------------------------------------------+
Addr Mode: The addressing mode of the originating gateway. 0 = Address Translation mode; 1 = Address Transparent mode.
ADDRモード：発信元ゲートウェイのアドレス指定モード。 0 =アドレス変換モード。 1 =トランスペアレントモードアドレス。
iFCP Ver: iFCP version number. SHALL be set to 1.
iFCP版：のiFCPバージョン番号。 1に設定されなければなりません。
LIVENESS TEST If non-zero, requests that the receiving INTERVAL: gateway transmit an LTEST message at the specified interval in seconds. If set to zero, LTEST messages SHALL NOT be sent.
ゲートウェイ秒で指定された間隔でLTESTメッセージを送信：LIVENESS TESTは、ゼロ以外の場合、受信間隔にすることを要求します。ゼロに設定した場合、LTESTメッセージが送信されないものとします。
USER INFO: Contains any data desired by the requestor. This information MUST be echoed by the recipient in the CBIND response message.
USER情報：要求者が希望する任意のデータが含まれています。この情報は、CBIND応答メッセージに受信者によってエコーされなければなりません。
SOURCE N_PORT NAME: The Worldwide Port Name (WWPN) of the N_PORT locally attached to the gateway originating the CBIND request.
SOURCE N_PORT名：N_PORTのワールドワイド・ポート名（WWPN）は、局所的にCBIND要求を発信ゲートウェイに取り付けられています。
DESTINATION N_PORT The Worldwide Port Name (WWPN) of the NAME: N_PORT locally attached to the gateway receiving the CBIND request.
NAMEのDESTINATION N_PORTザ・ワールドワイド・ポート名（WWPN）：N_PORTは、局所的にCBIND要求を受信したゲートウェイに取り付けられています。
The following shows the format of the CBIND response.
以下はCBIND応答のフォーマットを示します。
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver |
| | (Seconds) | | |
+------+-------------------------+-----------+----------+
| 2 | USER INFO |
+------+------------+------------+-----------+----------+
| 3 | |
+------+ SOURCE N_PORT NAME |
| 4 | |
+------+------------------------------------------------+
| 5 | |
+------+ DESTINATION N_PORT NAME |
| 6 | |
+------+-------------------------+----------------------+
| 7 | Reserved | CBIND Status |
+------+-------------------------+----------------------+
| 8 | Reserved | CONNECTION HANDLE |
+------+-------------------------+----------------------+
Total Length = 36
全長= 36
Addr Mode: The address translation mode of the responding gateway. 0 = Address Translation mode, 1 = Address Transparent mode.
ADDRモード：応答ゲートウェイのアドレス変換モード。 0 =アドレス変換モード、1 =アドレストランスペアレントモード。
iFCP Ver: iFCP version number. Shall be set to 1.
iFCP版：のiFCPバージョン番号。 1に設定されなければなりません。
LIVENESS TEST If non-zero, requests that the gateway INTERVAL: receiving the CBIND RESPONSE transmit an LTEST message at the specified interval in seconds. If zero, LTEST messages SHALL NOT be sent.
受信CBINDのRESPONSE秒で指定された間隔でLTESTメッセージを送信：LIVENESS TESTは、ゼロ以外の場合、ゲートウェイ間隔ことを要求します。ゼロの場合は、LTESTメッセージが送信されないものとします。
USER INFO: Echoes the value received in the USER INFO field of the CBIND request message.
USER情報：CBIND要求メッセージのユーザ情報フィールドに受信した値をエコーします。
SOURCE N_PORT NAME: Contains the Worldwide Port Name (WWPN) of the N_PORT locally attached to the gateway issuing the CBIND request.
SOURCE N_PORT名：ローカルCBIND要求を発行するゲートウェイに取り付けられたN_PORTのワールドワイド・ポート名（WWPN）が含ま。
DESTINATION N_PORT Contains the Worldwide Port Name (WWPN) of NAME: the N_PORT locally attached to the gateway issuing the CBIND response.
局所的にCBIND応答を発行ゲートウェイに取り付けN_PORT：DESTINATION N_PORTはNAMEのワールド・ワイド・ポート名（WWPN）が含ま。
CBIND STATUS: Indicates success or failure of the CBIND request. CBIND values are shown below.
CBINDステータス：CBIND要求の成功または失敗を示します。 CBIND値を以下に示します。
CONNECTION HANDLE: Contains a value assigned by the gateway to identify the connection. The connection handle is required when the UNBIND request is issued.
接続ハンドルは：接続を識別するためにゲートウェイによって割り当てられた値を含みます。 UNBIND要求が発行されたときに、接続ハンドルが必要です。
CBIND Status Description
------------ -----------
0 Success 1 - 15 Reserved 16 Failed - Unspecified Reason 17 Failed - No such device 18 Failed - iFCP session already exists 19 Failed - Lack of resources 20 Failed - Incompatible address translation mode 21 Failed - Incorrect protocol version number 22 Failed - Gateway not Synchronized (see Section 8.2) Others Reserved
0成功1 - 15予約16は失敗しました - 予期しない理由17が失敗した - そのようなデバイス18失敗しました - のiFCPセッションは既に19失敗存在しない - 失敗したリソース20の欠如 - 互換性のないアドレス変換モード21失敗 - 誤ったプロトコルバージョン番号22失敗 - ゲートウェイ同期していませんその他予約（8.2節を参照してください）
UNBIND is used to terminate an iFCP session and disassociate the TCP connection as described in Section 5.2.3.
UNBINDはのiFCPセッションを終了し、5.2.3項で説明したように、TCPコネクションの関連付けを解除するために使用されます。
The UNBIND message is transmitted over the connection that is to be unbound. The time stamp words in the encapsulation header shall be set to zero in the request and response message frames.
UNBINDメッセージは、結合していないことがある接続を介して送信されます。カプセル化ヘッダ内のタイムスタンプの単語は、要求と応答メッセージフレームにゼロに設定されなければなりません。
The following is the format of the UNBIND request message.
以下は、UNBIND要求メッセージのフォーマットです。
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | USER INFO |
+------+------------+------------+-----------+----------+
| 2 | Reserved | CONNECTION HANDLE |
+------+------------+------------+----------------------+
| 3 | Reserved |
+------+------------+------------+-----------+----------+
| 4 | Reserved |
+------+------------+------------+-----------+----------+
USER INFO Contains any data desired by the requestor. This information MUST be echoed by the recipient in the UNBIND response message.
ユーザ情報は、要求者が希望する任意のデータが含まれています。この情報はUNBIND応答メッセージに受信者によってエコーされなければなりません。
CONNECTION HANDLE: Contains the gateway-assigned value from the CBIND request.
接続ハンドルは：CBIND要求からゲートウェイに割り当てられた値を含みます。
The following shows the format of the UNBIND response message.
以下はUNBIND応答メッセージのフォーマットを示します。
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | USER INFO |
+------+------------+------------+-----------+----------+
| 2 | Reserved | CONNECTION HANDLE |
+------+------------+------------+-----------+----------+
| 3 | Reserved |
+------+------------+------------+-----------+----------+
| 4 | Reserved |
+------+------------+------------+-----------+----------+
| 5 | Reserved | UNBIND STATUS |
+------+------------+------------+-----------+----------+
USER INFO Echoes the value received in the USER INFO field of the UNBIND request message.
ユーザ情報は、UNBIND要求メッセージのユーザ情報フィールドに受信した値をエコー。
CONNECTION HANDLE: Echoes the CONNECTION HANDLE specified in the UNBIND request message.
接続ハンドルは：UNBIND要求メッセージに指定された接続ハンドルをエコーします。
UNBIND STATUS: Indicates the success or failure of the UNBIND request as follows:
UNBIND STATUSは次のようにUNBIND要求の成功または失敗を示します。
Unbind Status Description
------------- -----------
0 Successful - No other status
1 - 15 Reserved
16 Failed - Unspecified Reason
18 Failed - Connection ID Invalid
Others Reserved
The LTEST message is sent at the interval specified in the CBIND request or response payload. The LTEST encapsulation time stamp SHALL be set as described in Section 8.2.1 and may be used by the receiver to compute an estimate of propagation delay. However, the propagation delay limit SHALL NOT be enforced.
LTESTメッセージはCBIND要求または応答ペイロードで指定された間隔で送信されます。 LTESTカプセル化タイムスタンプは、セクション8.2.1に記載されるように設定されなければならないと伝搬遅延の推定値を計算するために受信機によって使用されてもよいです。しかし、伝搬遅延の制限が適用されないものとします。
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE5 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | LIVENESS TEST INTERVAL | Reserved |
| | (Seconds) | |
+------+-------------------------+----------------------+
| 2 | COUNT |
+------+------------+------------+-----------+----------+
| 3 | |
+------+ SOURCE N_PORT NAME |
| 4 | |
+------+------------------------------------------------+
| 5 | |
+------+ DESTINATION N_PORT NAME |
| 6 | |
+------+------------------------------------------------+
LIVENESS TEST Copy of the LIVENESS TEST INTERVAL INTERVAL: specified in the CBIND request or reply message.
LIVENESS TEST INTERVAL INTERVALのLIVENESS TESTコピー：CBIND要求または応答メッセージに指定されました。
COUNT: Monotonically increasing value, initialized to 0 and incremented by one for each successive LTEST message.
COUNT：各連続する最新のメッセージのいずれかによって0と増加に初期化単調に増加する値を、。
SOURCE N_PORT NAME: Contains a copy of the SOURCE N_PORT NAME specified in the CBIND request.
SOURCE N_PORT NAMEは：CBIND要求で指定されたSOURCE N_PORTのNAMEのコピーが含まれています。
DESTINATION N_PORT Contains a copy of the DESTINATION N_PORT NAME: NAME specified in the CBIND request.
DESTINATIONのN_PORTはDESTINATION N_PORTのNAMEのコピーが含まれています：CBIND要求で指定された名前。
Link services provide a set of fibre channel functions that allow a port to send control information or request another port to perform a specific control function.
リンクサービスは、ポートは、制御情報を送信することができたり、特定の制御機能を実行するために別のポートを要求するファイバチャネル機能のセットを提供します。
There are three types of link services:
リンクサービスの3つのタイプがあります。
a) Basic
a）基本
b) Extended
b）の拡張
c) ULP-specific (FC-4)
C）ULP固有（FC-4）
Each link service message (request and reply) is carried by a fibre channel sequence and can be segmented into multiple frames.
各リンク・サービス・メッセージ（要求と応答）は、ファイバ・チャネル・シーケンスによって運ばれ、複数のフレームに分割することができます。
The iFCP layer is responsible for transporting link service messages across the IP network. This includes mapping link service messages appropriately from the domain of the fibre channel transport to that of the IP network. This process may require special processing and the inclusion of supplemental data by the iFCP layer.
iFCP層は、IPネットワークを介してリンクサービスメッセージを輸送するための責任があります。これは、ファイバ・チャネル・トランスポートのドメインからIPネットワークのに適切にマッピングリンクサービスメッセージを含んでいます。このプロセスは、特別な処理とのiFCP層によって補足データを含めることを必要とするかもしれません。
Each link service MUST be processed according to one of the following rules:
各リンクサービスは、次のいずれかのルールに従って処理しなければなりません。
a) Pass-through - The link service message and reply MUST be delivered to the receiving N_PORT by the iFCP protocol layer without altering the message payload. The link service message and reply are not processed by the iFCP protocol layer.
A）パススルー - リンク・サービス・メッセージと応答メッセージのペイロードを変更することなくのiFCPプロトコル層によって受信N_PORTに送達されなければなりません。リンク・サービス・メッセージと応答がのiFCPプロトコル層によって処理されません。
b) Special - Applies to a link service reply or request requiring the intervention of the iFCP layer before forwarding to the destination N_PORT. Such messages may contain fibre channel addresses in the payload or may require other special processing.
B）特別 - リンクサービス応答または宛先N_PORTに転送する前のiFCP層の介入を必要とする要求に適用されます。そのようなメッセージは、ペイロード内のファイバーチャネルアドレスを含んでいてもよく、または他の特別な処理を必要とするかもしれません。
c) Rejected - When issued by a locally attached N_PORT, the specified link service request MUST be rejected by the iFCP gateway. The gateway SHALL return an LS_RJT response with a Reason Code of 0x0B (Command Not Supported), and a Reason Code Explanation of 0x0 (No Additional Explanation).
C）拒否 - ローカルに接続されているN_PORTによって発行された場合は、指定したリンクサービス要求は、iFCPゲートゲートウェイによって拒絶しなければなりません。ゲートウェイは、0x0Bの（コマンドはサポートされない）の理由コード、および0x0のの理由コード説明（追加説明）とLS_RJT応答を返します。
This section describes the processing for special link services, including the manner in which supplemental data is added to the message payload.
このセクションでは、補足データがメッセージペイロードに付加される方法を含む特別なリンクサービスのための処理について説明します。
Appendix A enumerates all link services and the iFCP processing policy that applies to each.
付録Aには、すべてのリンクサービスとそれぞれに適用されるのiFCP処理政策を列挙します。
Special link service messages require the intervention of the iFCP layer before forwarding to the destination N_PORT. Such intervention is required in order to:
特別なリンクサービスメッセージは、宛先N_PORTに転送する前のiFCP層の介入を必要とします。このような介入はするために必要とされています。
a) service any link service message that requires special handling, such as a PLOGI, and
a）は、このようなPLOGIなど特別な処理を必要とし、任意のリンクサービスメッセージをサービス、
b) service any link service message that has an N_PORT address in the payload in address translation mode only .
b）のサービスのみアドレス変換モードでのペイロードでのN_PORTアドレスを持つ任意のリンクサービスメッセージ。
Unless the link service description specifies otherwise, support for each special link service is MANDATORY.
リンクサービスの説明が別途定める場合を除き、各特別なリンクサービスのサポートが必須です。
Such messages SHALL be transmitted in a fibre channel frame with the format shown in Figure 18 for extended link services or Figure 19 for FC-4 link services.
そのようなメッセージは、拡張されたリンクサービスまたはFC-4リンクサービスのために、図19は、図18に示したフォーマットとファイバチャネルフレームで送信されなければなりません。
Word
0<---Bit-->7 8<-------------------------------------------->31
+------------+------------------------------------------------+
0| R_CTL | D_ID |
|[Req = 0x22]|[Destination of extended link Service request] |
|[Rep = 0x23]| |
+------------+------------------------------------------------+
1| CS_CTL | S_ID |
| | [Source of extended link service request] |
+------------+------------------------------------------------+
2| TYPE | F_CTL |
| [0x01] | |
+------------+------------------+-----------------------------+
3| SEQ_ID | DF_CTL | SEQ_CNT |
+------------+------------------+-----------------------------+
4| OX_ID | RX_ID |
+-------------------------------+-----------------------------+
5| Parameter |
| [ 00 00 00 00 ] |
+-------------------------------------------------------------+
6| LS_COMMAND |
| [Extended Link Service Command Code] |
+-------------==----------------------------------------------+
7| |
.| Additional Service Request Parameters |
.| ( if any ) |
n| |
+-------------------------------------------------------------+
Figure 18. Format of an Extended Link Service Frame
拡張リンクサービスフレームの図18.フォーマット
Word
0<---Bit-->7 8<-------------------------------------------->31
+------------+------------------------------------------------+
0| R_CTL | D_ID |
|[Req = 0x32]| [Destination of FC-4 link Service request] |
|[Rep = 0x33]| |
+------------+------------------------------------------------+
1| CS_CTL | S_ID |
| | [Source of FC-4 link service request] |
+------------+------------------------------------------------+
2| TYPE | F_CTL |
| (FC-4 | |
| specific) | |
+------------+------------------+-----------------------------+
3| SEQ_ID | DF_CTL | SEQ_CNT |
+------------+------------------+-----------------------------+
4| OX_ID | RX_ID |
+-------------------------------+-----------------------------+
5| Parameter |
| [ 00 00 00 00 ] |
+-------------------------------------------------------------+
6| LS_COMMAND |
| [FC-4 Link Service Command Code] |
+-------------------------------------------------------------+
7| |
.| Additional Service Request Parameters |
.| ( if any ) |
n| |
+-------------------------------------------------------------+
Figure 19. Format of an FC-4 Link Service Frame
FC-4リンクサービスフレームの図19.フォーマット
This section describes the handling for link service frames containing N_PORT addresses in the frame payload. Such addresses SHALL only be translated when the gateway is operating in address translation mode. When operating in address transparent mode, these addresses SHALL NOT be translated, and such link service messages SHALL NOT be sent as special frames unless other processing by the iFCP layer is required.
このセクションでは、フレームのペイロードにN_PORTアドレスを含むリンクサービスフレームの取り扱いを説明しています。ゲートウェイはアドレス変換モードで動作しているとき、そのようなアドレスにのみ翻訳するもの。アドレス透過モードで動作している場合、これらのアドレスを翻訳することがないもの、とのiFCP層によって他の処理が必要とされない限り、このようなリンクサービスメッセージは、特別なフレームとして送信されないものとします。
Supplemental data includes information required by the receiving gateway to convert an N_PORT address in the payload to an N_PORT address in the receiving gateway's address space. The following rules define the manner in which such supplemental data shall be packaged and referenced.
補足データは、受信側ゲートウェイのアドレス空間内のNポートアドレスにペイロードにN_PORTアドレスを変換する受信側ゲートウェイが必要とする情報を含みます。以下のルールは、補足データがパッケージ化され、参照されるものとする方法を定義します。
For an N_PORT address field, the gateway originating the frame MUST set the value in the payload to identify the address translation type as follows:
N_PORTアドレスフィールドは、フレームを発信側ゲートウェイは、以下のようにアドレス変換の種類を識別するために、ペイロードに値を設定する必要があります。
0x00 00 01 - The gateway receiving the frame from the IP network MUST replace the contents of the field with the N_PORT alias of the frame originator. This translation type MUST be used when the address to be converted is that of the source N_PORT.
$ 00 00 01 - IPネットワークからフレームを受信したゲートウェイは、フレームの発信元のN_PORT別名とフィールドの内容を交換する必要があります。アドレスはソースN_PORTのものである変換するときに、この変換タイプを使用しなければなりません。
0x00 00 02 - The gateway receiving the frame from the IP network MUST replace the contents of the field with the N_PORT ID of the destination N_PORT. This translation type MUST be used when the address to be converted is that of the destination N_PORT
$ 00 00 02 - IPネットワークからフレームを受信したゲートウェイは、宛先N_PORTのN_PORT IDとフィールドの内容を交換する必要があります。アドレスを変換するときに、この変換タイプを使用しなければなりません先のN_PORTのことです
0x00 00 03 - The gateway receiving the frame from the IP network MUST reference the specified supplemental data to set the field contents. The supplemental information is the 64-bit worldwide identifier of the N_PORT, as set forth in the fibre channel specification [FC-FS]. If not otherwise part of the link service payload, this information MUST be appended in accordance with the applicable link service description. Unless specified otherwise, this translation type SHALL NOT be used if the address to be converted corresponds to that of the frame originator or recipient.
$ 00 00 03 - IPネットワークからフレームを受信したゲートウェイは、フィールドの内容を設定するために、指定された補足データを参照しなければなりません。ファイバチャネル仕様[FC-FS]に記載の補足情報は、N_ポートの64ビットの世界的な識別子です。リンク・サービス・ペイロードのない、さもなければ部分場合、この情報は該当するリンクサービス記述に従い、添付されなければなりません。特に指定しない限り、変換するアドレスは、フレームの発信元または受信者のそれに対応する場合、この変換タイプを使用してはなりません。
Since fibre channel addressing rules prohibit the assignment of fabric addresses with a domain ID of 0, the above codes will never correspond to valid N_PORT fabric IDs.
ファイバーチャネルアドレス指定規則が0のドメインIDとファブリックアドレスの割り当てを禁止しているので、上記のコードは、有効なNポートのファブリックIDに対応することはありません。
If the sending gateway cannot obtain the worldwide identifier of an N_PORT, the gateway SHALL terminate the request with an LS_RJT message as described in [FC-FS]. The Reason Code SHALL be set to 0x07 (protocol error), and the Reason Explanation SHALL be set to 0x1F (Invalid N_PORT identifier).
送信ゲートウェイはN_PORTの世界的識別子を取得できない場合、[FC-FS]に記載されているように、ゲートウェイは、LS_RJTメッセージで要求を終了するもの。理由コードが0x07の（プロトコルエラー）に設定すると、理由説明0x1Fの（無効なNポート識別子）に設定します。
Supplemental data is sent with the link service request or ACC frames in one of the following ways:
補足データは、以下のいずれかの方法でリンクサービス要求またはACCフレームで送信されます。
a) By appending the necessary data to the end of the link service frame.
A）リンクサービスフレームの最後に必要なデータを追加することによって。
b) By extending the sequence with additional frames.
B）追加フレームとのシーケンスを拡張することによって。
In the first case, a new frame SHALL be created whose length includes the supplemental data. The procedure for extending the link service sequence with additional frames is dependent on the link service type.
最初のケースでは、新たなフレームは、長さが補足データを含む作成するものとします。追加フレームでリンクサービスのシーケンスを拡張するための手順は、リンクサービスの種類に依存しています。
For each field requiring address translation, the receiving gateway SHALL reference the translation type encoded in the field and replace it with the N_PORT address as shown in Table 7.
アドレス変換を必要とするフィールドごとに、受信側ゲートウェイは、フィールドに符号化された変換タイプを参照するものとし、表7に示すようにNポートアドレスに置き換えます。
+------------------+------------------------------------+
| Translation | N_PORT Translation |
| Type Code | |
+------------------+------------------------------------+
| 0x00 00 01 | Replace field contents with N_PORT |
| | alias of frame originator. |
+------------------+------------------------------------+
| 0x00 00 02 | Replace field contents with N_PORT |
| | ID of frame recipient. |
+------------------+------------------------------------+
| | Lookup N_PORT via iSNS query. |
| | If locally attached, replace with |
| 0x00 00 03 | N_PORT ID. |
| | If remotely attached, replace with |
| | N_PORT alias from remote N_PORT. |
| | descriptor (see Section 5.2.2.1). |
+------------------+------------------------------------+
Table 7. Link Service Address Translation
表7.リンクサービスのアドレス変換
For translation type 3, the receiving gateway SHALL obtain the information needed to fill in the field in the link service frame payload by converting the specified N_PORT worldwide identifier to a gateway IP address and N_PORT ID. This information MUST be obtained through an iSNS name server query. If the query is unsuccessful, the gateway SHALL terminate the request with an LS_RJT response message as described in [FC-FS]. The Reason Code SHALL be set to 0x07 (protocol error), and the Reason Explanation SHALL be set to 0x1F (Invalid N_PORT identifier).
変換タイプ3のために、受信側ゲートウェイは、ゲートウェイのIPアドレスとNポートIDに、指定されたN_PORTワールドワイド識別子を変換することによって、リンク・サービス・フレームのペイロード内のフィールドを埋めるために必要な情報を得なければなりません。この情報は、iSNSネームサーバクエリを介して取得しなければなりません。クエリが失敗した場合、[FC-FS]に記載されているように、ゲートウェイは、LS_RJT応答メッセージで要求を終了するもの。理由コードが0x07の（プロトコルエラー）に設定すると、理由説明0x1Fの（無効なNポート識別子）に設定します。
After applying the supplemental data, the receiving gateway SHALL forward the resulting link service frames to the destination N_PORT with the supplemental information removed.
補足データを適用した後、受信側ゲートウェイが除去補足情報と宛先N_PORTに得られたリンク・サービス・フレームを送付しなければなりません。
The following Extended and FC-4 Link Service Messages must receive special processing.
以下の拡張およびFC-4リンクサービスメッセージは、特別な処理を受けなければなりません。
Extended Link Service LS_COMMAND Mnemonic
Messages ---------- --------
----------------------
Abort Exchange 0x06 00 00 00 ABTX
Discover Address 0x52 00 00 00 ADISC
Discover Address Accept 0x02 00 00 00 ADISC ACC
FC Address Resolution 0x55 00 00 00 FARP-REPLY
Protocol Reply
FC Address Resolution 0x54 00 00 00 FARP-REQ
Protocol Request
Logout 0x05 00 00 00 LOGO
Port Login 0x30 00 00 00 PLOGI
Read Exchange Concise 0x13 00 00 00 REC
Read Exchange Concise 0x02 00 00 00 REC ACC
Accept
Read Exchange Status Block 0x08 00 00 00 RES
Read Exchange Status Block 0x02 00 00 00 RES ACC
Accept
Read Link Error Status 0x0F 00 00 00 RLS
Block
Read Sequence Status Block 0x09 00 00 00 RSS
Reinstate Recovery 0x12 00 00 00 RRQ
Qualifier
Request Sequence 0x0A 00 00 00 RSI
Initiative
Scan Remote Loop 0x7B 00 00 00 SRL
Third Party Process Logout 0x24 00 00 00 TPRLO
Third Party Process Logout 0x02 00 00 00 TPRLO ACC
Accept
FC-4 Link Service Messages LS_COMMAND Mnemonic
-------------------------- ---------- --------
FCP Read Exchange Concise 0x13 00 00 00 FCP REC
FCP Read Exchange Concise 0x02 00 00 00 FCP REC
Accept ACC
Each encapsulated fibre channel frame that is part of a special link service MUST have the SPC bit set to one in the iFCP FLAGS field of the encapsulation header, as specified in Section 5.3.1. If an ACC link service response requires special processing, the responding gateway SHALL place a copy of LS_COMMAND bits 0 through 7, from the link service request frame, in the LS_COMMAND_ACC field of the ACC encapsulation header. Supplemental data (if any) MUST be appended as described in the following section.
特別なリンクサービスの一部である各カプセル化されたファイバ・チャネル・フレームはセクション5.3.1で指定されるようにSPCは、カプセル化ヘッダのiFCPフラグフィールド内の1つにビットセットがなければなりません。 ACCリンクサービス応答が特別な処理を必要とする場合、応答ゲートウェイはACCカプセル化ヘッダのLS_COMMAND_ACCフィールドに、リンクサービス要求フレームから、0〜7 LS_COMMANDビットのコピーを配置するものとします。次のセクションで説明したように、補足データ（もしあれば）を添付しなければなりません。
The format of each special link service message, including supplemental data, where applicable, is shown in the following sections. Each description shows the basic format, as specified in the applicable FC standard, followed by supplemental data as shown in the example below.
適用は、以下のセクションで示された補足データを含む各特別なリンクサービスメッセージのフォーマット、。該当FC標準で指定されるように、以下の例に示すように、各記述は、補足データ、続いて、基本的なフォーマットを示しています。
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | LS_COMMAND |
+------+------------+------------+-----------+----------+
| 1 | |
| . | |
| . | Link Service Frame Payload |
| | |
| n | |
+======+============+============+===========+==========+
| n+1 | |
| . | Supplemental Data |
| . | (if any) |
| n+k | |
+======+================================================+
Figure 20. Special Link Service Frame Payload
図20.特別なリンクサービスフレームペイロード
The following sections define extended link services for which special processing is required.
次のセクションでは、特別な処理が必要とされている拡張リンクサービスを定義します。
ELS Format:
フォーマット：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x6 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | RRQ Status | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID of Tgt exchange | RX_ID of tgt exchange|
+------+------------+------------+-----------+----------+
| 3-10 | Optional association header (32 bytes |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------
-----------
Exchange Originator 1, 2 N/A S_ID
交換発信1、2 N / A S_ID
Other Special Processing:
その他の特殊処理：
None.
無し。
Format of ADISC ELS:
ADISC THEのフォーマット：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x52 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Reserved | Hard address of ELS Originator |
+------+------------+------------+-----------+----------+
| 2-3 | Port Name of Originator |
+------+------------+------------+-----------+----------+
| 4-5 | Node Name of originator |
+------+------------+------------+-----------+----------+
| 6 | Rsvd | N_PORT ID of ELS Originator |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -------------
------------
N_PORT ID of ELS 1 N/A Originator
1 N /発信者のN_PORT ID
Other Special Processing:
その他の特殊処理：
The Hard Address of the ELS originator SHALL be set to 0.
ELSの発信元のハードアドレスは0に設定されなければなりません。
Format of ADISC ACC ELS:
ADISC THE ACCのフォーマット：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x20 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Reserved | Hard address of ELS Originator |
+------+------------+------------+-----------+----------+
| 2-3 | Port Name of Originator |
+------+------------+------------+-----------+----------+
| 4-5 | Node Name of originator |
+------+------------+------------+-----------+----------+
| 6 | Rsvd | N_PORT ID of ELS Originator |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -------------
------------
N_PORT ID of ELS 1 N/A Originator
1 N /発信者のN_PORT ID
Other Special Processing:
その他の特殊処理：
The Hard Address of the ELS originator SHALL be set to 0.
ELSの発信元のハードアドレスは0に設定されなければなりません。
The FARP-REPLY ELS is used in conjunction with the FARP-REQ ELS (see Section 7.3.1.5) to perform the address resolution services required by the FC-VI protocol [FC-VI] and the fibre channel mapping of IP and ARP specified in RFC 2625 [RFC2625].
FARP-REPLY ELSは、[FC-VI] FC-VIプロトコルによって必要とされるアドレス解決サービスを実行する（セクション7.3.1.5を参照）FARP-REQ ELSと組み合わせて使用され、IPとARPのファイバ・チャネル・マッピングが指定されましたRFC 2625 [RFC2625]インチ
Format of FARP-REPLY ELS:
FARP-REPLY TOのフォーマット：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x55 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Match Addr | Requesting N_PORT Identifier |
| | Code Points| |
+------+------------+------------+-----------+----------+
| 2 | Responder | Responding N_PORT Identifier |
| | Action | |
+------+------------+------------+-----------+----------+
| 3-4 | Requesting N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 5-6 | Requesting N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 7-8 | Responding N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 9-10 | Responding N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 11-14| Requesting N_PORT IP Address |
+------+------------+------------+-----------+----------+
| 15-18| Responding N_PORT IP Address |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
------------
Requesting N_PORT 2 N/A Identifier
N_PORT 2 N / Aの識別子を要求します
Responding N_PORT 1 N/A Identifier
N_PORT 1 N / A識別子を応答
Other Special Processing:
その他の特殊処理：
None.
無し。
The FARP-REQ ELS is used in conjunction with the FC-VI protocol [FC-VI] and IP-to-FC mapping of RFC 2625 [RFC2625] to perform IP and FC address resolution in an FC fabric. The FARP-REQ ELS is usually directed to the fabric broadcast server at well-known address 0xFF-FF-FF for retransmission to all attached N_PORTs.
FARP-REQ ELSは、FCファブリックにIPとFCアドレス解決を実行するFC-VIプロトコル[FC-VI]およびRFC 2625 [RFC2625]のIP対FCマッピングと組み合わせて使用されます。 FARP-REQ ELSは通常、取り付けられているすべてのN_Portへの再送信のためのよく知られたアドレスは0xFF-FF-FFでファブリックブロードキャストサーバーに向けられています。
Section 9.4 describes the iFCP implementation of FC broadcast server functionality in an iFCP fabric.
9.4節はのiFCPファブリック内のFCブロードキャストサーバー機能ののiFCP実装について説明します。
Format of FARP_REQ ELS:
FARP_REQ THEのフォーマット：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x54 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Match Addr | Requesting N_PORT Identifier |
| | Code Points| |
+------+------------+------------+-----------+----------+
| 2 | Responder | Responding N_PORT Identifier |
| | Action | |
+------+------------+------------+-----------+----------+
| 3-4 | Requesting N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 5-6 | Requesting N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 7-8 | Responding N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 9-10 | Responding N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 11-14| Requesting N_PORT IP Address |
+------+------------+------------+-----------+----------+
| 15-18| Responding N_PORT IP Address |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
-----------
Requesting N_PORT 3 Requesting N_PORT Identifier Port Name
N_PORT識別子ポート名を要求する要求N_PORT 3
Responding N_PORT 3 Responding N_PORT Identifier Port Name
N_PORT識別子ポート名を受けての対応N_PORT 3
Other Special Processing:
その他の特殊処理：
None.
無し。
ELS Format:
フォーマット：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x5 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | N_PORT ID being logged out |
+------+------------+------------+-----------+----------+
| 2-3 | Port name of the LOGO originator (8 bytes) |
+======+============+============+===========+==========+
This ELS SHALL always be sent as a special ELS regardless of the translation mode in effect.
このELSは関係なく、常に有効な変換モードの特別なELSとして送付されなければなりません。
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ---------------
-----------
N_PORT ID Being 1 N/A Logged Out
N_PORT IDビーイング1 N / Aはログアウト
Other Special Processing:
その他の特殊処理：
See Section 5.2.3.
5.2.3項を参照してください。
A PLOGI ELS establishes fibre channel communications between two N_PORTs and triggers the creation of an iFCP session if one does not exist.
PLOGI ELSは、二つのN_ポート間のファイバチャネル通信を確立し、一方が存在しない場合のiFCPセッションの作成をトリガします。
The PLOGI request and ACC response carry information identifying the originating N_PORT, including a specification of its capabilities. If the destination N_PORT accepts the login request, it sends an Accept response (an ACC frame with PLOGI payload) specifying its capabilities. This exchange establishes the operating environment for the two N_PORTs.
PLOGI要求及びACC応答は、その機能の仕様を含め、発信N_PORTを識別する情報を運びます。目的地N_PORTは、ログイン要求を受け入れた場合、それはその機能を指定して受け入れ応答（PLOGIペイロードを持つACCフレーム）を送信します。この交換は2つのNポートの動作環境を確立します。
The following figure is duplicated from [FC-FS], and shows the PLOGI message format for both the request and Accept (ACC) response. An N_PORT will reject a PLOGI request by transmitting an LS_RJT message containing no payload.
次の図は、[FC-FS]から複製、および要求の両方のためにPLOGIメッセージのフォーマットを示し、（ACC）の応答を受け入れています。 N_PORTにはペイロードを含まないLS_RJTメッセージを送信することにより、PLOGI要求を拒否します。
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x3 | 0x00 | 0x00 | 0x00 |
| | Acc = 0x2 | | | |
+------+------------+------------+-----------+----------+
| 1-4 | Common Service Parameters |
+------+------------+------------+-----------+----------+
| 5-6 | N_PORT Name |
+------+------------+------------+-----------+----------+
| 7-8 | Node Name |
+------+------------+------------+-----------+----------+
| 9-12 | Class 1 Service Parameters |
+------+------------+------------+-----------+----------+
|13-17 | Class 2 Service Parameters |
+------+------------+------------+-----------+----------+
|18-21 | Class 3 Service Parameters |
+------+------------+------------+-----------+----------+
|22-25 | Class 4 Service Parameters |
+------+------------+------------+-----------+----------+
|26-29 | Vendor Version Level |
+======+============+============+===========+==========+
Figure 21. Format of PLOGI Request and ACC Payloads
PLOGI要求とACCペイロードの図21.フォーマット
Details of the above fields, including common and class-based service parameters, can be found in [FC-FS].
一般的なクラスベースのサービスパラメータを含む、上記項目の詳細は、[FC-FS]に見出すことができます。
Special Processing
特殊加工
As specified in Section 5.2.2.2, a PLOGI request addressed to a remotely attached N_PORT MUST cause the creation of an iFCP session if one does not exist. Otherwise, the PLOGI and PLOGI ACC payloads MUST be passed through without modification to the destination N_PORT using the existing iFCP session. In either case, the SPC bit must be set in the frame encapsulation header as specified in 5.3.3.
5.2.2.2項に規定されているように、PLOGI要求は1つが存在しない場合のiFCPセッションの作成を引き起こすしなければならないリモートで接続N_PORT宛。それ以外の場合は、PLOGIおよびPLOGI ACCペイロードは、既存のiFCPセッションを使用して宛先N_PORTを変更することなく通過しなければなりません。 5.3.3で指定されるようにいずれの場合にも、SPCビットはフレームのカプセル化ヘッダに設定されなければなりません。
If the CBIND to create the iFCP session fails, the issuing gateway SHALL terminate the PLOGI with an LS_RJT response. The Reason Code and Reason Code Explanation SHALL be selected from Table 8 based on the CBIND failure status.
iFCPセッションを作成するためにCBINDが失敗した場合、発行ゲートウェイはLS_RJT応答でPLOGIを終了するものとします。理由コードおよび理由コード説明CBIND故障状態に基づいて、表8から選択されなければなりません。
+---------------+-------------------+---------------------+
| CBIND Failure | LS_RJT Reason | LS_RJT Reason Code |
| Status | Code | Explanation |
+===============+===================+=====================+
| Unspecified | Unable to Perform | No Additional |
| Reason (16) | Command Request | Explanation (0x00) |
| | (0x09) | |
+---------------+-------------------+---------------------+
| No Such | Unable to Perform | Invalid N_PORT |
| Device (17) | Command Request | Name (0x0D) |
| | (0x09) | |
+---------------+-------------------+---------------------+
| Lack of | Unable to Perform | Insufficient |
| Resources (19)| Command Request | Resources to Support|
| | (0x09) | Login (0x29) |
+---------------+-------------------+---------------------+
| Incompatible | Unable to Perform | No Additional |
| Address | Command Request | Explanation (0x00) |
| Translation | (0x09) | |
| Mode (20) | | |
+---------------+-------------------+---------------------+
| Incorrect iFCP| Unable to Perform | No Additional |
| Protocol | Command Request | Explanation (0x00) |
| version Number| (0x09) | |
| (21) | | |
+---------------+-------------------+---------------------+
| Gateway Not | Unable to Perform | No Additional |
| Synchronized | Command Request | Explanation (0x00) |
| (22) | (0x09) | |
+---------------+-------------------+---------------------+
Table 8. PLOGI LS_RJT Status for CBIND Failures
CBIND障害表8. PLOGI LS_RJTステータス
Link Service Request Format:
リンクサービス・リクエスト・フォーマット：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+======+============+============+===========+==========+
| 3-4 |Port Name of the Exchange Originator (8 bytes) |
| | (present only for translation type 3) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
-----------
Exchange Originator 1, 2, or 3 Port Name of the S_ID Exchange Originator
取引発信1、2、またはS_ID交換オリジネーターの3ポート名
Other Special Processing:
その他の特殊処理：
None.
無し。
Format of REC ACC Response:
REC ACCレスポンスのフォーマット：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 2 | Rsvd | Originator Address Identifier |
+------+------------+------------+-----------+----------+
| 3 | Rsvd | Responder Address Identifier |
+------+------------+------------+-----------+----------+
| 4 | FC4VALUE (FC-4-Dependent Value) |
+------+------------+------------+-----------+----------+
| 5 | E_STAT (Exchange Status) |
+======+============+============+===========+==========+
| 6-7 |Port Name of the Exchange Originator (8 bytes) |
+======+============+============+===========+==========+
| 8-9 |Port Name of the Exchange Responder (8 bytes) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Originator Address 1, 2, or 3 Port Name of the Identifier Exchange Originator
識別子為替発信者の発信アドレス1、2、または3ポート名
Responder Address 1, 2, or 3 Port Name of the Identifier Exchange Responder
識別子交換レスポンダのレスポンダアドレス1、2、または3ポート名
When supplemental data is required, the frame SHALL always be extended by 4 words as shown above. If the translation type for the Originator Address Identifier or the Responder Address Identifier is 1 or 2, the corresponding 8-byte port name SHALL be set to all zeros.
補足データが要求される場合に上記のように、フレームは常に4つのワードによって延長されます。発信元アドレス識別子またはレスポンダアドレス識別子の変換タイプが1又は2である場合、対応する8バイトのポート名は、すべてゼロに設定されます。
Other Special Processing:
その他の特殊処理：
None.
無し。
ELS Format:
フォーマット：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 3-10 | Association Header (may be optionally req**d) |
+======+============+============+===========+==========+
| 11-12| Port Name of the Exchange Originator (8 bytes) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Exchange Originator 1, 2, or 3 Port Name of the S_ID Exchange Originator
取引発信1、2、またはS_ID交換オリジネーターの3ポート名
Other Special Processing:
その他の特殊処理：
None.
無し。
Format of ELS Accept Response:
レスポンスのフォーマットは受け付けます。
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 2 | Rsvd | Exchange Originator N_PORT ID |
+------+------------+------------+-----------+----------+
| 3 | Rsvd | Exchange Responder N_PORT ID |
+------+------------+------------+-----------+----------+
| 4 | Exchange Status Bits |
+------+------------+------------+-----------+----------+
| 5 | Reserved |
+------+------------+------------+-----------+----------+
| 6-n | Service Parameters and Sequence Statuses |
| | as described in [FC-FS] |
+======+============+============+===========+==========+
|n+1- | Port Name of the Exchange Originator (8 bytes) |
|n+2 | |
+======+============+============+===========+==========+
|n+3- | Port Name of the Exchange Responder (8 bytes) |
|n+4 | |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Exchange Originator 1, 2, or 3 Port Name of the N_PORT ID Exchange Originator
取引発信1、2、またはN_PORT ID交換オリジネーターの3ポート名
Exchange Responder 1, 2, or 3 Port Name of the N_PORT ID Exchange Responder
取引レスポンダ1、2、またはN_PORT ID所レスポンダの3ポート名
When supplemental data is required, the ELS SHALL be extended by 4 words as shown above. If the translation type for the Exchange Originator N_PORT ID or the Exchange Responder N_PORT ID is 1 or 2, the corresponding 8-byte port name SHALL be set to all zeros.
補足データが要求される場合に上記のように、ELSは4つのワードによって延長されます。翻訳交換発信NポートIDの型またはExchangeレスポンダN_PORT IDが1又は2である場合、対応する8バイトのポート名は、すべてゼロに設定されます。
Other Special Processing:
その他の特殊処理：
None.
無し。
ELS Format:
フォーマット：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x0F | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | N_PORT Identifier |
+======+============+============+===========+==========+
| 2-3 | Port Name of the N_PORT (8 bytes) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
-----------
N_PORT Identifier 1, 2, or 3 Port Name of the N_PORT
Nポート識別子1、2、またはN_PORTの3ポート名
Other Special Processing:
その他の特殊処理：
None.
無し。
ELS Format:
フォーマット：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x09 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | SEQ_ID | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+======+============+============+===========+==========+
| 3-4 |Port Name of the Exchange Originator (8 bytes) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Exchange Originator 1, 2, or 3 Port Name of the S_ID Exchange Originator
取引発信1、2、またはS_ID交換オリジネーターの3ポート名
Other Special Processing:
その他の特殊処理：
None.
無し。
ELS Format:
フォーマット：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x12 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 3-10 | Association Header (may be optionally req**d) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Exchange Originator 1 or 2 N/A S_ID
交換発信1又は2 N / A S_ID
Other Special Processing:
その他の特殊処理：
None.
無し。
ELS Format:
フォーマット：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x0A | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 3-10 | Association Header (may be optionally req**d) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Exchange Originator 1 or 2 N/A S_ID
交換発信1又は2 N / A S_ID
Other Special Processing:
その他の特殊処理：
None.
無し。
SRL allows a remote loop to be scanned to detect changes in the device configuration. Any changes will trigger a fibre channel state change notification and subsequent update of the iSNS database.
SRLは、リモート・ループがデバイス構成の変化を検出するためにスキャンされることを可能にします。すべての変更は、iSNSデータベースのファイバチャネル状態変化通知とその後の更新をトリガします。
ELS Format:
フォーマット：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x7B | Reserved |
+------+------------+------------+-----------+----------+
| 1 | Flag | Address Identifier of the FL_PORT |
| | | (see B.1) |
+======+============+============+===========+==========+
| 2-3 | Worldwide Name of the Remote FL_PORT |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Address Identifier 3 Worldwide Name of of the FL_PORT the Remote FL_PORT
アドレス識別子FLポートのリモートFLポートの3世界的な名前
Other Special Processing:
その他の特殊処理：
The D_ID field is the address of the Domain Controller associated with the remote loop. The format of the Domain Controller address is the hex 'FF FC' || Domain_ID, where Domain_ID is the gateway-assigned alias representing the remote gateway or switch element being queried. After translation by the remote gateway, the D_ID identifies the gateway or switch element to be scanned within the remote gateway region.
D_IDフィールドは、リモート・ループに関連するドメインコントローラのアドレスです。ドメインコントローラアドレスの形式は、六角「FF FC」です|| Domain_IDがリモートゲートウェイまたはスイッチ要素を表すゲートウェイに割り当てられたエイリアスでのDomain_IDは、照会されます。リモートゲートウェイによって翻訳後に、D_IDは、リモートゲートウェイ領域内にスキャンするゲートウェイまたはスイッチ要素を識別する。
The FLAG field defines the scope of the SRL. If set to 0, all loop port interfaces on the given switch element or gateway are scanned. If set to one, the loop port interface on the gateway or switch element to be scanned MUST be specified in bits 8 through 31.
FLAGフィールドは、SRLの範囲を定義します。 0に設定した場合、所定のスイッチ素子またはゲートウェイ上のすべてのループ・ポート・インターフェースが走査されます。いずれかに設定した場合、スキャンするゲートウェイまたはスイッチ素子にループ・ポート・インターフェース31を介してビット8で指定する必要があります。
If the Flag field is zero, the SRL request SHALL NOT be sent as a special ELS.
フラグフィールドがゼロの場合、SRL要求は、特別なELSとして送信されないものとします。
If the Domain_ID represents a remote switch or gateway and an iFCP session to the remote Domain Controller does not exist, the requesting gateway SHALL create the iFCP session.
Domain_IDは、リモートスイッチを表すか、またはゲートウェイとリモート・ドメイン・コントローラへのiFCPセッションが存在しない場合、要求はゲートウェイのiFCPセッションを作成SHALL。
TPRLO provides a mechanism for an N_PORT (third party) to remove one or more process login sessions that exist between the destination N_PORT and other N_PORTs specified in the command. This command includes one or more TPRLO LOGOUT PARAMETER PAGEs, each of which, when combined with the destination N_PORT, identifies a process login to be terminated by the command.
TPRLO宛先N_PORTとコマンドで指定された他のNポートとの間に存在する1つ以上のプロセス・ログイン・セッションを削除するN_PORT（第三者）ためのメカニズムを提供します。このコマンドは、宛先N_PORTと組み合わされた場合、コマンドによって終了されるプロセス・ログインを識別それぞれが一つ以上のTPRLOログアウトPARAMETERページを含みます。
+--------+------------+--------------------+----------------------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16 - 31 |
+--------+------------+--------------------+----------------------+
| 0 | Cmd = 0x24 | Page Length (0x10) | Payload Length |
+--------+------------+--------------------+----------------------+
| 1 | TPRLO Logout Parameter Page 0 |
+--------+--------------------------------------------------------+
| 5 | TPRLO Logout Parameter Page 1 |
+--------+--------------------------------------------------------+
....
+--------+--------------------------------------------------------+
|(4*n)+1 | TPRLO Logout Parameter Page n |
+--------+--------------------------------------------------------+
Figure 22. Format of TPRLO ELS
TPRLO THEの図22.フォーマット
Each TPRLO parameter page contains parameters identifying one or more image pairs and may be associated with a single FC-4 protocol type that is common to all FC-4 protocol types between the specified image pair or global to all specified image pairs. The format of a TPRLO page requiring address translation is shown in Figure 23. Additional information on TPRLO can be found in [FC-FS].
各TPRLOパラメータページは、1つまたは複数の画像ペアを識別するパラメータを含み、指定された画像ペア又は指定されたすべての画像対のグローバル間のすべてのFC-4プロトコルタイプに共通である単一のFC-4プロトコルタイプに関連付けることができます。アドレス変換を必要とTPRLOページのフォーマットはTPRLOに関する追加情報は、[FC-FS]に見ることができる図23に示されています。
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-31 |
+------+------------+------------+-----------+----------+
| 0 | TYPE Code | TYPE CODE | |
| | or | EXTENSION | TPRLO Flags |
| | Common SVC | | |
| | Parameters | | |
+------+------------+------------+-----------+----------+
| 1 | Third Party Process Associator |
+------+------------+------------+-----------+----------+
| 2 | Responder Process Associator |
+------+------------+------------+-----------+----------+
| 3 | Reserved | Third Party Originator N_PORT ID |
+======+============+============+===========+==========+
| 4-5 | Worldwide Name of Third Party Originator |
| | N_PORT |
+------+------------------------------------------------+
Figure 23. Format of an Augmented TPRLO Parameter Page
増補TPRLOパラメータページの図23.フォーマット
The TPRLO flags that affect supplemented ELS processing are as follows:
次のように補足したELSの処理に影響を与えるTPRLOフラグは次のとおりです。
Bit 18: Third party Originator N_PORT Validity. When set to one, this bit indicates that word 3, bits 8-31 (Third Party Originator N_PORT ID), are meaningful.
ビット18：サードパーティ発信N_PORTの妥当性。 1に設定されると、このビットはそのワード3を示し、ビット8-31（第三者オリジネーターN_PORT ID）は、意味があります。
Bit 19: Global Process logout. When set to one, this bit indicates that all image pairs for all N_PORTs of the specified FC-4 protocol shall be invalidated. When the value of this bit is one, only one logout parameter page is permitted in the TPRLO payload.
ビット19：グローバルプロセスログアウト。 1に設定されると、このビットは、指定されたFC-4プロトコルのすべてのN_ポートに対するすべての画像対が無効化されなければならないことを示しています。このビットの値が1である場合、一つだけログアウトパラメータページはTPRLOペイロードに許容されます。
If bit 18 has a value of zero and bit 19 has a value of one in the TPRLO flags field, then the ELS SHALL NOT be sent as a special ELS.
ビット18がゼロの値を有し、19ビットTPRLOフラグフィールドに1の値を有する場合、ELSは、特別なELSとして送信することがないもの。
Otherwise, the originating gateway SHALL process the ELS as follows:
次のようにそうでなければ、発信側ゲートウェイはELSを処理しなければなりません。
a) The first word of the TPRLO payload SHALL NOT be modified.
A）TPRLOペイロードの最初のワードは変更されないもの。
b) Each TPRLO parameter page shall be extended by two words as shown in Figure 23.
図23に示すようにb）はTPRLOパラメータページは二つの単語によって拡張されなければなりません。
c) If word 0, bit 18 (Third Party Originator N_PORT ID validity), in the TPRLO flags field has a value of one, then the sender shall place the worldwide port name of the fibre channel device's N_PORT in the extension words. The N_PORT ID SHALL be set to 3. Otherwise, the contents of the extension words and the Third Party Originator N_PORT ID SHALL be set to zero.
ワード0は、（第三者オリジネーターN_PORT IDの妥当性）18ビットた場合は1の値を持つC）、TPRLOフラグフィールドに、送信者は、拡張言葉で、ファイバチャネルデバイスのN_PORTのワールドワイド・ポート名を置くものとします。 N_PORT IDは、それ以外の場合は3に設定されなければならない、拡張単語やサードパーティのオリジネータN_PORT IDの内容をゼロに設定しなければなりません。
d) The ELS originator SHALL set the SPC bit in the encapsulation header of each augmented frame comprising the ELS (see Section 5.3.1).
D）ELSオリジネータ（セクション5.3.1を参照）ELSを含む各拡張フレームのカプセル化ヘッダにSPCビットを設定しなければなりません。
e) If the ELS contains a single TPRLO parameter page, the originator SHALL increase the frame length as necessary to include the extended parameter page.
ELSは、単一TPRLOパラメータページが含まれている場合、E）、発信者は拡張パラメータページを含むように必要に応じてフレーム長を増大させるものとします。
f) If the ELS to be augmented contains multiple TPRLO parameter pages, the FC frames created to contain the augmented ELS payload SHALL NOT exceed the maximum frame size that can be accepted by the destination N_PORT.
ELSが増大する場合、F）複数TPRLOパラメータページ、先N_PORTによって受け入れ可能な最大フレームサイズを超えてはならない拡張ELSペイロードを含むように作成されたFCフレームを含んでいます。
Each fibre channel frame SHALL contain an integer number of extended TPRLO parameter pages. The maximum number of extended TPRLO parameter pages in a frame SHALL be limited to the number that can be held without exceeding the above upper limit. New frames resulting from the extension of the TPRLO pages to include the supplemental data SHALL be created by extending the SEQ_CNT in the fibre channel frame header. The SEQ_ID SHALL NOT be modified.
各ファイバ・チャネル・フレームは、拡張TPRLOパラメータページの整数を含まなければなりません。フレームの拡張TPRLOパラメータページの最大数が前記上限を超えることなく保持することができる数に制限されるもの。補足データを含むようにTPRLOページの拡張に起因する新たなフレームは、ファイバチャネルフレームヘッダーのSEQ_CNTを拡張することによって作成されるものとします。 SEQ_IDを変更することはないものとします。
The gateway receiving the augmented TPRLO ELS SHALL generate ELS frames to be sent to the destination N_PORT by copying word 0 of the ELS payload and processing each augmented parameter page as follows:
拡張TPRLO ELSを受け取るゲートウェイは、ELSを生成するものとELSペイロードのワード0をコピーし、次のように各拡張パラメータページを処理することによって、宛先N_PORTに送信されるフレーム。
a) If word 0, bit 18, has a value of one, create a parameter page by copying words 0 through 2 of the augmented parameter page. The Third Party Originator N_PORT ID in word 3 shall be generated by referencing the supplemental data as described in Section 7.2.
ワード0、18ビット場合a）に示すように、拡張パラメータページの2を介してワード0をコピーすることによって、パラメータページを作成し、1の値を有します。ワード3のサードパーティ発信NポートIDは、セクション7.2で説明したように、補足データを参照することにより生成されなければなりません。
b) If word 0, bit 18, has a value of zero, create a parameter page by copying words 0 through 3 of the augmented parameter page.
ワード0、18ビット場合b）に示すように、拡張パラメータページの3を介してワード0をコピーすることによって、パラメータページを作成し、ゼロの値を有します。
The size of each frame to be sent to the destination N_PORT MUST NOT exceed the maximum frame size that the destination N_PORT can accept. The sequence identifier in each frame header SHALL be copied from the augmented ELS, and the sequence count SHALL be monotonically increasing.
N_PORT宛先N_PORTが受け入れることができる最大フレームサイズを超えてはならない宛先に送信される各フレームのサイズ。各フレームヘッダ内のシーケンス識別子は、拡張ELSからコピーするものとし、シーケンスカウントが、単調に増加するものとします。
The format of the TPRLO ACC frame is shown in Figure 24.
TPRLO ACCフレームのフォーマットは図24に示されています。
+--------+------------+--------------------+----------------------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16 - 31 |
+--------+------------+--------------------+----------------------+
| 0 | Cmd = 0x2 | Page Length (0x10) | Payload Length |
+--------+------------+--------------------+----------------------+
| 1 | TPRLO Logout Parameter Page 0 |
+--------+--------------------------------------------------------+
| 5 | TPRLO Logout Parameter Page 1 |
+--------+--------------------------------------------------------+
....
+--------+--------------------------------------------------------+
|(4*n)+1 | TPRLO Logout Parameter Page n |
+--------+--------------------------------------------------------+
Figure 24. Format of TPRLO ACC ELS
TPRLO THE ACCの図24.フォーマット
The format of the parameter page and rules for parameter page augmentation are as specified in Section 7.3.1.17.
セクション7.3.1.17で指定されたパラメータページ増強のためのパラメータページとルールのフォーマットがあります。
The following sections define FC-4 link services for which special processing is required.
以下のセクションでは、特別な処理が必要とされているFC-4リンクサービスを定義します。
The format of FC-4 link service frames defined by FCP can be found in [FCP-2].
FCPによって定義されたFC-4リンク・サービス・フレームのフォーマットは、[FCP-2]に見出すことができます。
The payload format for this link service is identical to the REC extended link service specified in Section 7.3.1.8 and SHALL be processed as described in that section. The FC-4 version will become obsolete in [FCP-2]. However, in order to support devices implemented against early revisions of FCP-2, an iFCP gateway MUST support both versions.
このリンクサービスのためのペイロード・フォーマットは、セクション7.3.1.8で指定されたREC拡張リンクサービスと同じであり、そのセクションで説明したように処理されます。 FC-4のバージョンは[FCP-2]に時代遅れになるであろう。しかし、FCP-2の初期のリビジョンに対して実装デバイスをサポートするために、iFCPゲートゲートウェイは両方のバージョンをサポートしなければなりません。
The payload format for this link service is identical to the REC ACC extended link service specified in Section 7.3.1.9 and SHALL be processed as described in that section. The FC-4 version will become obsolete in [FCP-2]. However, in order to support devices implemented against earlier revisions of FCP-2, an iFCP gateway MUST support both versions.
このリンクサービスのためのペイロード・フォーマットは、セクション7.3.1.9で指定されたREC ACC拡張リンクサービスと同じであり、そのセクションで説明したように処理されます。 FC-4のバージョンは[FCP-2]に時代遅れになるであろう。しかし、FCP-2の以前のリビジョンに対して実装デバイスをサポートするために、iFCPゲートゲートウェイは両方のバージョンをサポートしなければなりません。
The FLOGI ELS is issued by an N_PORT that wishes to access the fabric transport services.
FLOGI ELSは、ファブリック輸送サービスにアクセスしたいN_PORTによって発行されます。
The format of the FLOGI request and FLOGI ACC payloads are identical to the PLOGI request and ACC payloads described in Section 7.3.1.7.
FLOGI要求とFLOGI ACCペイロードの形式はセクション7.3.1.7に記載PLOGI要求及びACCペイロードと同一です。
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x4 | 0x00 | 0x00 | 0x00 |
| | Acc = 0x2 | | | |
+------+------------+------------+-----------+----------+
| 1-4 | Common Service Parameters |
+------+------------+------------+-----------+----------+
| 5-6 | N_PORT Name |
+------+------------+------------+-----------+----------+
| 7-8 | Node Name |
+------+------------+------------+-----------+----------+
| 9-12 | Class 1 Service Parameters |
+------+------------+------------+-----------+----------+
|13-17 | Class 2 Service Parameters |
+------+------------+------------+-----------+----------+
|18-21 | Class 3 Service Parameters |
+------+------------+------------+-----------+----------+
|22-25 | Class 4 Service Parameters |
+------+------------+------------+-----------+----------+
|26-29 | Vendor Version Level |
+======+============+============+===========+==========+
Figure 25. FLOGI Request and ACC Payload Format
図25. FLOGI要求とACCペイロードフォーマット
A full description of each parameter is given in [FC-FS].
各パラメータの詳細な説明は、[FC-FS]で与えられます。
This section tabulates the protocol-dependent service parameters supported by a fabric port attached to an iFCP gateway.
このセクションでは、iFCPゲートゲートウェイに取り付けられたファブリックポートによってサポートされるプロトコルに依存するサービスパラメータを表にしたものです。
The service parameters carried in the payload of an FLOGI extended link service request MUST be set in accordance with Table 9.
FLOGI拡張リンク・サービス・リクエストのペイロードで運ばれたサービスパラメータを表9に応じて設定されなければなりません。
+-----------------------------------------+---------------+
| | Fabric Login |
| Service Parameter | Class |
| +---+---+---+---+
| | 1 | 2 | 3 | 4 |
+-----------------------------------------+---+---+---+---+
| Class Validity | n | M | M | n |
+-----------------------------------------+---+---+---+---+
| Service Options | |
+-----------------------------------------+---+---+---+---+
| Intermix Mode | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Stacked Connect-Requests | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Sequential Delivery | n | M | M | n |
+-----------------------------------------+---+---+---+---+
| Dedicated Simplex | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Camp On | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Buffered Class 1 | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Priority | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Initiator/Recipient Control | |
+-----------------------------------------+---+---+---+---+
| Clock Synchronization ELS Capable | n | n | n | n |
+-----------------------------------------+---+---+---+---+
Table 9. FLOGI Service Parameter Settings
表9. FLOGIサービスパラメータの設定値
Notes:
ノート：
1) "n" indicates a parameter or capability that is not supported by the iFCP protocol.
1）「n」個のiFCPプロトコルによってサポートされていないパラメータまたは機能を示しています。
2) "M" indicates an applicable parameter that MUST be supported by an iFCP gateway.
2）「M」とのiFCPゲートウェイによってサポートしなければならない適用可能なパラメータを示しています。
This section specifies provisions for error detection and recovery in addition to those in [FC-FS], which continue to be available in the iFCP network environment.
このセクションでは、のiFCPネットワーク環境で利用できるようにしていき[FC-FS]のものに加えて、エラーの検出と回復のための規定を、指定します。
Recovery from fibre channel protocol error conditions requires that frames associated with a failed or aborted exchange drain from the fabric before exchange resources can be safely reused.
ファイバチャネルプロトコルのエラー条件からの回復は、Exchangeリソースの前に生地から失敗したか中断された交換ドレインに関連付けられているフレームが安全に再利用できることが必要です。
Since a fibre channel fabric may not preserve frame order, there is no deterministic way to purge such frames. Instead, the fabric guarantees that frame the lifetime will not exceed a specific limit (R_A_TOV).
ファイバ・チャネル・ファブリックは、フレーム順序を維持しないかもしれないので、そのようなフレームをパージするいかなる決定論的方法は存在しません。代わりに、ライフタイムフレームファブリック保証は、特定の限界（R_A_TOV）を超えないであろう。
R_A_TOV is defined in [FC-FS] as "the maximum transit time within a fabric to guarantee that a lost frame will never emerge from the fabric". For example, a value of 2 x R_A_TOV is the minimum time that the originator of an ELS request or FC-4 link service request must wait for the response to that request. The fibre channel default value for R_A_TOV is 10 seconds.
R_A_TOVは、「失われたフレームは、ファブリックから出てくることはありませんことを保証するために、ファブリック内の最大通過時間」として[FC-FS]で定義されています。例えば、2×R_A_TOVの値は、ELS要求またはFC-4リンクサービス要求の発信者がその要求に対する応答を待たなければならない最小時間です。 R_A_TOVのためのファイバチャネルのデフォルト値は10秒です。
An iFCP gateway SHALL actively enforce limits on R_A_TOV as described in Section 8.2.1.
8.2.1項で説明したようにiFCPゲートゲートウェイは積極R_A_TOVの制限を実施しなければなりません。
The R_A_TOV limit on frame lifetimes SHALL be enforced by means of the time stamp in the encapsulation header (see Section 5.3.1) as described in this section.
このセクションで説明するように、フレーム寿命にR_A_TOV限界（セクション5.3.1を参照）のカプセル化ヘッダ内のタイムスタンプによって施行します。
The budget for R_A_TOV SHOULD include allowances for the propagation delay through the gateway regions of the sending and receiving N_PORTs, plus the propagation delay through the IP network. This latter component is referred to in this specification as IP_TOV.
R_A_TOVのための予算は、送受信N_ポートのゲートウェイ領域を通って伝搬遅延、プラスIPネットワークを介して伝播遅延の許容量を含むべきです。この後者の成分はIP_TOVとして本明細書で言及されています。
IP_TOV should be set well below the value of R_A_TOV specified for the iFCP fabric and should be stored in the iSNS server. IP_TOV should be set to 50 percent of R_A_TOV.
IP_TOVはウェルのiFCPファブリックに指定されたR_A_TOVの値以下に設定する必要があり、iSNSサーバに格納されるべきです。 IP_TOVはR_A_TOVの50％に設定する必要があります。
The following paragraphs describe the requirements for synchronizing gateway time bases and the rules for measuring and enforcing propagation delay limits.
以下の段落では、ゲートウェイの時間ベースを同期させるための要件と測定および伝搬遅延の制限を適用するためのルールが記載されています。
The protocol for synchronizing a gateway time base is SNTP [RFC2030]. In order to ensure that all gateways are time aligned, a gateway SHOULD obtain the address of an SNTP-compatible time server via an iSNS query. If multiple time server addresses are returned by the query, the servers must be synchronized and the gateway may use any server in the list. Alternatively, the server may return a multicast group address in support of operation in Anycast mode. Implementation of Anycast mode is as specified in [RFC2030], including the precautions defined in that document. Multicast mode SHOULD NOT be used.
ゲートウェイのタイムベースを同期するためのプロトコルは、SNTP [RFC2030]です。すべてのゲートウェイが時間整列されることを保証するために、ゲートウェイは、iSNSクエリを介しSNTP互換タイムサーバのアドレスを得なければなりません。複数のタイムサーバーのアドレスは、クエリによって返された場合、サーバを同期させる必要がありますし、ゲートウェイは、リスト内の任意のサーバーを使用することができます。代替的に、サーバは、エニーキャストモードでの動作をサポートするマルチキャストグループアドレスを返すことができます。その文書で定義された注意事項を含む、[RFC2030]で指定されるようにエニーキャストモードの実装です。マルチキャストモードを使用しないでください。
An SNTP server may use any one of the time reference sources listed in [RFC2030]. The resolution of the time reference MUST be 125 milliseconds or better.
SNTPサーバは、[RFC2030]に記載されている時間基準源のいずれかを使用することができます。時間基準の解像度は、125ミリ秒以上でなければなりません。
Stability of the SNTP server and gateway time bases should be 100 ppm or better.
SNTPサーバとゲートウェイの時間ベースの安定性は、100ppmの又はより良好であるべきです。
With regard to its time base, the gateway is in either the Synchronized or Unsynchronized state.
その時間ベースに関しては、ゲートウェイが同期または非同期状態のいずれかです。
When in the synchronized state, the gateway SHALL
場合に同期状態では、ゲートウェイはSHALL
a) set the time stamp field for each outgoing frame in accordance with the gateway's internal time base;
a）は、ゲートウェイの内部タイムベースに従って各送信フレームのタイムスタンプ・フィールドを設定します。
b) check the time stamp field of each incoming frame, following validation of the encapsulation header CRC, as described in Section 5.3.4;
セクション5.3.4で説明したようにb）に示すように、カプセル化ヘッダCRCの検証以下、各入力フレームのタイムスタンプフィールドを確認。
c) if the incoming frame has a time stamp of 0,0 and is not one of the session control frames that require a 0,0 time stamp (see Section 6), the frame SHALL be discarded;
着信フレーム（セクション6を参照）0,0のタイムスタンプを有し、0,0タイムスタンプを必要とするセッション制御フレームの1つでない場合、C）、フレームは廃棄しなければなりません。
d) if the incoming frame has a non-zero time stamp, the receiving gateway SHALL compute the absolute value of the time in flight and SHALL compare it against the value of IP_TOV specified for the IP fabric;
D）着信フレームが非ゼロのタイムスタンプを有する場合、受信側ゲートウェイは、飛行時間の絶対値を計算するものとし、IPファブリックに指定IP_TOVの値に対してそれを比較しなければなりません。
e) if the result in step (d) exceeds IP_TOV, the encapsulated frame shall be discarded. Otherwise, the frame shall be de-encapsulated as described in Section 5.3.4.
e）の場合には、ステップ（d）において、結果はIP_TOV、カプセル化されたフレームを廃棄しなければならない超えます。セクション5.3.4で説明したようにそうでなければ、フレームは、脱カプセル化しなければなりません。
A gateway SHALL enter the Synchronized state upon receiving a successful response to an SNTP query.
ゲートウェイは、SNTPクエリに成功した応答を受信すると同期状態に入ること。
A gateway shall enter the Unsynchronized state:
ゲートウェイは非同期状態に入るものとします。
a) upon power-up and before successful completion of an SNTP query, and
a）の電源投入時およびSNTPクエリが正常に完了する前に、と
b) whenever the gateway looses contact with the SNTP server, such that the gateway's time base may no longer be in alignment with that of the SNTP server. The criterion for determining loss of contact is implementation specific.
B）たびに、ゲートウェイは、ゲートウェイのタイムベースがもはやSNTPサーバのそれと整合しなくてもよいように、SNTPサーバとの接触を失います。接触の損失を決定するための基準は、実装固有のものです。
Following loss of contact, it is recommended that the gateway enter the Unsynchronized state when the estimated time base drift relative to the SNTP reference is greater than ten percent of the IP_TOV limit. (Assuming that all timers have an accuracy of 100 ppm and IP_TOV equals 5 seconds, the maximum allowable loss of contact duration would be about 42 minutes.)
接触の損失に続いて、SNTP基準に推定された時間ベースドリフト相対IP_TOV限界の10％よりも大きい場合、ゲートウェイが非同期状態に入ることをお勧めします。 （すべてのタイマーが100ppmの精度を有し、IP_TOV 5秒に等しいと仮定すると、接触時間の最大許容損失は約42分であろう。）
As the result of a transition from the Synchronized to the Unsynchronized state, a gateway MUST abort all iFCP sessions as described in Section 5.2.3. While in the Unsynchronized state, a gateway SHALL NOT permit the creation of new iFCP sessions.
5.2.3項で説明したように非同期状態に同期からの移行の結果、ゲートウェイは、すべてのiFCPセッションを中止しなければなりません。非同期状態にある間、ゲートウェイは新しいのiFCPセッションの作成を許可してはなりません。
An iFCP gateway implementation MUST support the following fabric services:
iFCPゲートウェイの実装は、次のファブリックサービスをサポートする必要があります。
N_PORT ID Value Description Section
--------------- ----------- -------
0xFF-FF-FE F_PORT Server 9.1
0xFF-FF-FD Fabric Controller 9.2
0xFFの-FF-FDファブリックコントローラ9.2
0xFF-FF-FC Directory/Name Server 9.3
0xFFの-FF-FCディレクトリ/ネームサーバ9.3
In addition, an iFCP gateway MAY support the FC broadcast server functionality described in Section 9.4.
加えて、iFCPゲートゲートウェイは、セクション9.4で説明FC放送サーバ機能をサポートするかもしれません。
The F_PORT server SHALL support the FLOGI ELS, as described in Section 7.4, as well as the following ELSs specified in [FC-FS]:
F_PORTサーバは、セクション7.4で説明したように、FLOGI ELSをサポートし、ならびに[FC-FS]で指定された次のELSSなければなりません。
a) Request for fabric service parameters (FDISC).
ファブリックサービスパラメータのa）の要求（FDISC）。
b) Request for the link error status (RLS).
リンクエラーステータス（RLS）のためのb）の要求。
c) Read Fabric Timeout Values (RTV).
C）ファブリックタイムアウト値（RTV）を読みます。
The Fabric Controller SHALL support the following ELSs as specified in [FC-FS]:
[FC-FS]で指定されるようにファブリックコントローラは、次ELSSをサポートしなければなりません。
a) State Change Notification (SCN).
a）の状態変更通知（SCN）。
b) Registered State Change Notification (RSCN).
b）の登録状態変更通知（RSCN）。
c) State Change Registration (SCR).
c）の状態変更登録（SCR）。
The Directory/Name server provides a registration service allowing an N_PORT to record or query the database for information about other N_PORTs. The services are defined in [FC-GS3]. The queries are issued as FC-4 transactions using the FC-CT command transport protocol specified in [FC-GS3].
ディレクトリ/ネームサーバは、記録またはその他のN_Portに関する情報のデータベースを照会するN_PORTを許可する登録サービスを提供します。サービスは、[FC-GS3]で定義されています。クエリは、[FC-GS3]で指定されたFC-CT命令をトランスポート・プロトコルを使用してFC-4トランザクションとして発行されています。
In iFCP, each name server request MUST be translated to the appropriate iSNS query defined in [ISNS]. The definitions of name server objects are specified in [FC-GS3].
iFCPゲートにおいて、各ネームサーバ要求は、[ISNS]で定義された適切なiSNSのクエリに変換されなければなりません。ネームサーバーオブジェクトの定義は、[FC-GS3]で指定されています。
The name server SHALL support record and query operations for directory subtype 0x02 (Name Server) and 0x03 (IP Address Server) and MAY support the FC-4 specific services as defined in [FC-GS3].
ネームサーバーは、ディレクトリのサブタイプが0x02（ネームサーバー）と0x03の（IPアドレスサーバー）のレコードやクエリ操作をサポートすると、[FC-GS3]で定義されているFC-4の特定のサービスをサポートすることができます。
Fibre channel frames are broadcast throughout the fabric by addressing them to the fibre channel broadcast server at the well-known fibre channel address 0xFF-FF-FF. The broadcast server then replicates and delivers the frame to each attached N_PORT in all zones to which the originating device belongs. Only class 3 (datagram) service is supported.
ファイバー・チャネル・フレームは、よく知られたファイバ・チャネル・アドレスは0xFF-FF-FFでファイバ・チャネル・ブロードキャスト・サーバーにアドレス指定することにより、ファブリック全体に放送されています。ブロードキャストサーバは、複製し、発信側デバイスが属するすべてのゾーン内の各取り付けN_PORTにフレームを送出します。唯一のクラス3（データグラム）サービスがサポートされています。
In an iFCP system, the fibre channel broadcast function is emulated by means of a two-tier architecture comprising the following elements:
iFCPシステムでは、ファイバ・チャネル・ブロードキャスト機能は、以下の要素を含む2層アーキテクチャによってエミュレートされます。
a) A local broadcast server residing in each iFCP gateway. The local server distributes broadcast traffic within the gateway region and forwards outgoing broadcast traffic to a global server for distribution throughout the iFCP fabric.
A）それぞれのiFCPゲートウェイに常駐するローカル放送サーバ。ローカルサーバは、ゲートウェイ領域内でブロードキャストトラフィックを配信とのiFCP布を通して分配のためのグローバルサーバに送信ブロードキャストトラフィックを転送します。
b) A global broadcast server that re-distributes broadcast traffic to the local server in each participating gateway.
B）グローバル放送サーバ各参加ゲートウェイでローカルサーバにブロードキャストトラフィックを再分配します。
c) An iSNS discovery domain defining the scope over which broadcast traffic is propagated. The discovery domain is populated with a global broadcast server and the set of local servers it supports.
c）のトラフィックをブロードキャストを超える範囲を定義するのiSNS検出ドメインが伝播されます。ディスカバリドメインは、グローバルな放送サーバとそれがサポートするローカルサーバのセットが移入されます。
The local and global broadcast servers are logical iFCP devices that communicate using the iFCP protocol. The servers have an N_PORT Network Address consisting of an iFCP portal address and an N_PORT ID set to the well-known fibre channel address of the FC broadcast server (0xFF-FF-FF).
ローカルおよびグローバルな放送サーバは、のiFCPプロトコルを使用して通信する論理のiFCPデバイスです。サーバーは、のiFCPポータルアドレスからなるN_PORTネットワークアドレスとFCブロードキャストサーバ（0xFFで-FF-FF）のよく知られたファイバ・チャネル・アドレスに設定N_PORT IDを持っています。
As noted above, an N_PORT originates a broadcast by directing frame traffic to the fibre channel broadcast server. The gateway-resident local server distributes a copy of the frame locally and forwards a copy to the global server for redistribution to the local servers on other gateways. The global server MUST NOT echo a broadcast frame to the originating local server.
上述したように、N_ポートは、ファイバチャネルの放送サーバにフレームトラフィックを向けることによって、放送を発信します。ゲートウェイ常駐ローカルサーバーは、ローカルフレームのコピーを配布し、他のゲートウェイ上のローカルサーバへの再配布のためのグローバルサーバにコピーを転送します。グローバルサーバは、発信ローカルサーバにブロードキャストフレームをエコーてはなりません。
The broadcast configuration is managed with facilities provided by the iSNS server by the following means:
ブロードキャストの設定は以下の手段によって、iSNSサーバが提供する機能で管理されています。
a) An iSNS discovery domain is created and seeded with the network address of the global broadcast server N_PORT. The global server is identified as such by setting the appropriate N_PORT entity attribute.
A）のiSNS発見ドメインが作成され、グローバルな放送サーバN_PORTのネットワークアドレスを接種されます。グローバルサーバは、適切なN_PORT実体属性を設定することによって、そのように識別されます。
b) Using the management interface, each broadcast server is preset with the identity of the broadcast domain.
b）は、管理インターフェイスを使用して、各放送サーバは、ブロードキャストドメインのアイデンティティと予め設定されています。
During power up, each gateway SHALL invoke the iSNS service to register its local broadcast server in the broadcast discovery domain. After registration, the local server SHALL wait for the global broadcast server to establish an iFCP session.
電源投入時には、各ゲートウェイは、ブロードキャストディスカバリドメインにそのローカルブロードキャストサーバを登録するにiSNSサービスを呼び出すものとします。登録後、ローカルサーバーはのiFCPセッションを確立するために、グローバルな放送サーバを待つものとします。
The global server SHALL register with the iSNS server as follows:
次のようにグローバルサーバは、iSNSサーバに登録しなければなりません。
a) The server SHALL query the iSNS name server by attribute to obtain the worldwide port name of the N_PORT pre-configured to provide global broadcast services.
a）は、サーバは、グローバルな放送サービスを提供するために、N_PORT事前設定済みのワールドワイド・ポート名を取得する属性でのiSNSネームサーバを照会しないものとします。
b) If the worldwide port name obtained above does not correspond to that of the server issuing the query, the N_PORT SHALL NOT perform global broadcast functions for N_PORTs in that discovery domain.
B）上記で得られたワールドワイド・ポート名は、クエリを発行し、サーバーのものに対応していない場合は、N_PORTは、そのディスカバリドメインでのN_Portのグローバルブロードキャスト機能を実行しないものとします。
c) Otherwise, the global server N_PORT SHALL register with the discovery domain and query the iSNS server to identify all currently registered local servers.
C）そうでなければ、グローバルサーバN_PORTは、ディスカバリドメインに登録し、現在登録されているすべてのローカルサーバーを識別するために、iSNSサーバーを照会しないものとします。
d) The global broadcast server SHALL initiate an iFCP session with each local broadcast server in the domain. When a new local server registers, the global server SHALL receive a state change notification and respond by initiating an iFCP session with the newly added server. The gateway SHALL obtain these notifications using the iSNS provisions for lossless delivery.
d）のグローバルブロードキャスト・サーバーは、ドメイン内の各ローカル放送サーバとのiFCPセッションを開始しなければなりません。新しいローカルサーバーが登録すると、グローバルサーバは、状態変化通知を受信して、新しく追加されたサーバとのiFCPセッションを開始することによって応答しなければなりません。ゲートウェイは、可逆送達のためのiSNS規定を使用してこれらの通知を受けなければなりません。
Upon receiving the CBIND request to initiate the iFCP session, the local server SHALL record the worldwide port name and N_PORT network address of the global server.
iFCPセッションを開始するCBIND要求を受信すると、ローカルサーバは、グローバルサーバのワールドワイド・ポート名とN_PORTネットワークアドレスを記録しなければなりません。
After the initial broadcast session is established, the local or global broadcast server MAY choose to manage the session in one of the following ways, depending on resource requirements and the anticipated level of broadcast traffic:
最初の放送セッションが確立された後、ローカルまたはグローバルな放送サーバがリソース要件およびブロードキャストトラフィックの予想されるレベルに応じて、次のいずれかの方法でセッションを管理することを選択することがあります。
a) A server MAY keep the session open continuously. Since broadcast sessions are often quiescent for long periods of time, the server SHOULD monitor session connectivity as described in Section 5.2.2.4.
a）は、サーバが継続的に開いているセッションを保持してもよいです。ブロードキャストセッションは、多くの場合、長時間静止しているので、セクション5.2.2.4で説明したように、サーバは、セッションの接続を監視する必要があります。
b) A server MAY open the broadcast session on demand only when broadcast traffic is to be sent. If the session is reopened by the global server, the local server SHALL replace the previously recorded network address of the global broadcast server.
b）のサーバは、ブロードキャストトラフィックが送信されるだけオンデマンドで放送セッションを開くことができます。セッションがグローバルサーバーで再び開かれている場合、ローカルサーバーは、グローバル放送サーバの以前に記録されたネットワークアドレスを交換するものとします。
An implementation may designate a local server to assume the duties of the global broadcast server in the event of a failure. The local server may use the LTEST message to determine whether the global server is functioning and may assume control if it is not.
実装は、障害発生時にグローバルな放送サーバの職務を想定し、ローカルサーバーを指定することができます。ローカルサーバは、グローバル・サーバが機能しているとそうでない場合、コントロールをとることができるかどうかを決定するLTESTメッセージを使用してもよいです。
When assuming control, the standby server must register with the iSNS server as the global broadcast server in place of the failed server and must install itself in the broadcast discovery domain as specified in steps c) and d) of Section 9.4.1.
コントロールを想定した場合、スタンバイサーバが故障したサーバの代わりに、グローバルな放送サーバとしてiSNSサーバーに登録する必要がありますし、9.4.1項の放送ディスカバリステップcで指定されたドメイン）およびd）に自身をインストールする必要があります。
iFCP relies upon the IPSec protocol suite to provide data confidentiality and authentication services, and it relies upon IKE as the key management protocol. Section 10.2 describes the security requirements arising from iFCP's operating environment, and Section
iFCPは、データの機密性と認証サービスを提供するために、IPSecプロトコルスイートに依存し、それが鍵管理プロトコルとしてIKEに依存しています。 10.2節はiFCPゲートの動作環境に起因するセキュリティ要件を記述し、セクション
10.3 describes the resulting design choices, their requirement levels, and how they apply to the iFCP protocol.
10.3は、得られた設計上の選択、その要求レベル、およびそれらがどのようにのiFCPプロトコルに適用さを説明しています。
Detailed considerations for use of IPsec and IKE with the iFCP protocol can be found in [SECIPS].
iFCPプロトコルIPsecとIKEを使用するための詳細な考察は[SECIPS]に見出すことができます。
iFCP is a protocol designed for use by gateway devices deployed in enterprise data centers. Such environments typically have security gateways designed to provide network security through isolation from public networks. Furthermore, iFCP data may have to traverse security gateways in order to support SAN-to-SAN connectivity across public networks.
iFCPは、企業データセンターに配備ゲートウェイ装置で使用するために設計されたプロトコルです。このような環境では、通常、パブリックネットワークからの隔離を介してネットワークのセキュリティを提供するために設計されたセキュリティゲートウェイを持っています。さらに、のiFCPデータが公衆ネットワークを介してSANツーSAN接続をサポートするために、セキュリティゲートウェイを通過する必要があります。
Communicating iFCP gateways may be subjected to attacks, including attempts by an adversary to:
通信のiFCPゲートウェイは、に敵によって試みなど、攻撃にさらされてもよいです。
a) acquire confidential data and identities by snooping data packets,
a）は、データパケットをスヌーピングにより、機密データやアイデンティティを獲得し、
b) modify packets containing iFCP data and control messages,
B）のiFCPデータ及び制御メッセージを含むパケットを変更し、
c) inject new packets into the iFCP session,
C）のiFCPセッションに新しいパケットを注入し、
d) hijack the TCP connection carrying the iFCP session,
D）のiFCPセッションを運ぶTCP接続をハイジャック、
e) launch denial-of-service attacks against the iFCP gateway,
e）は、iFCPゲートゲートウェイに対するサービス拒否攻撃を開始します
f) disrupt the security negotiation process,
f）は、セキュリティ交渉プロセスを混乱させる
g) impersonate a legitimate security gateway, or
g）を正当セキュリティゲートウェイになりすまし、又は
h) compromise communication with the iSNS server.
H）iSNSサーバとの妥協通信。
It is imperative to thwart these attacks, given that an iFCP gateway is the last line of defense for a whole fibre channel island, which may include several hosts and fibre channel switches. To do so, the iFCP gateway must implement and may use confidentiality, data origin authentication, integrity, and replay protection on a per-datagram basis. The iFCP gateway must implement and may use bi-directional authentication of the communication endpoints. Finally, it must implement and may use a scalable approach to key management.
のiFCPゲートウェイは、複数のホストとファイバチャネルスイッチを含むことができる全体のファイバ・チャネル・アイランドに対する最後の防衛線であることを考えると、これらの攻撃を阻止することが不可欠です。そうするために、iFCPゲートゲートウェイが実装しなければならないと当たりのデータグラムベースで機密性、データ発信元認証、完全性、および再生保護を使用することができます。 iFCPゲートゲートウェイが実装しなければならないとの通信エンドポイントの双方向認証を使用することができます。最後に、それが実装しなければならないと鍵の管理にスケーラブルなアプローチを使用することができます。
Enterprise data center networks are considered mission-critical facilities that must be isolated and protected from all possible security threats. Such networks are usually protected by security gateways, which, at a minimum, provide a shield against denial-of-service attacks. The iFCP security architecture is capable of leveraging the protective services of the existing security infrastructure, including firewall protection, NAT and NAPT services, and IPSec VPN services available on existing security gateways. Considerations regarding intervening NAT and NAPT boxes along the iFCP-iSNS path can be found in [ISNS].
エンタープライズデータセンターのネットワークが分離し、すべての可能なセキュリティ上の脅威から保護されなければならないミッションクリティカルな施設と考えられています。このようなネットワークは通常、最低でも、サービス拒否攻撃に対するシールドを提供し、セキュリティゲートウェイによって保護されています。 iFCPセキュリティアーキテクチャは、ファイアウォール保護、NATやNAPTサービス、および既存のセキュリティゲートウェイで利用できるのIPSec VPNサービスを含め、既存のセキュリティインフラストラクチャの保護サービスを活用することが可能です。 iFCP、iSNSの経路に沿ってNATとNAPTボックスを介在に関する考察は[ISNS]に見出すことができます。
iFCP is a peer-to-peer protocol. iFCP sessions may be initiated by either peer gateway or both. Consequently, bi-directional authentication of peer gateways must be provided in accordance with the requirement levels specified in Section 10.3.1.
iFCPゲートは、ピアツーピアプロトコルです。 iFCPセッションは、ピアゲートウェイまたは両方のいずれかによって開始することができます。したがって、ピアゲートウェイの双方向認証は、セクション10.3.1で指定された要求レベルに応じて提供されなければなりません。
N_PORT identities used in the Port Login (PLOGI) process shall be considered authenticated if the PLOGI request is received from the remote gateway over a secure, IPSec-protected connection.
ポートログイン（PLOGI）プロセスで使用されるN_PORTアイデンティティはPLOGI要求はセキュアな、IPSecで保護された接続を介してリモート・ゲートウェイから受信された場合、認証と見なさなければなりません。
There is no requirement that the identities used in authentication be kept confidential.
認証に使用されるアイデンティティが秘密にする必要はありません。
iFCP traffic may traverse insecure public networks, and therefore implementations must have per-packet encryption capabilities to provide confidentiality in accordance with the requirements specified in Section 10.3.1.
iFCPトラフィックは安全でない公衆ネットワークを横断してもよいので、実装は、セクション10.3.1で指定された要件に従って機密性を提供するために、パケット単位の暗号化機能を持っている必要があります。
Due to the high data transfer rates and the amount of data involved, an iFCP implementation must support the capability to rekey each phase 2 security association in the time intervals dictated by sequence number space exhaustion at a given link rate. In the rekeying scenario described in [SECIPS], for example, rekeying events happen as often as every 27.5 seconds at a 10 Gbps rate.
高いデータ転送速度と関連するデータの量、のiFCP実装は、所与のリンクレートでシーケンス番号空間の枯渇によって決まる時間間隔で各フェーズ2セキュリティアソシエーションをリキーする能力をサポートしなければなりません。 【SECIPS]に記載リキーシナリオでは、例えば、リキーイベントは、10Gbpsの速度での頻度毎に27.5秒として起こります。
The iFCP gateway must provide the capability for forward secrecy in the rekeying process.
iFCPゲートゲートウェイは、再入力プロセスの前進の秘密保持のための能力を提供しなければなりません。
Basic access control properties stem from the requirement that two communicating iFCP gateways be known to one or more iSNS servers before they can engage in iFCP exchanges. The optional use of discovery domains [ISNS], Identity Payloads (e.g., ID_FQDNs), and certificate-based authentication (e.g., with X509v3 certificates) enables authorization schemas of increasing complexity. The definition of such schemas (e.g., role-based access control) is outside of the scope of this specification.
基本的なアクセスコントロールのプロパティは、彼らがのiFCP交換に従事することができます前に、2つの通信のiFCPゲートウェイは、1つまたは複数のiSNSサーバーに知られていることが要件に由来します。ディスカバリドメイン[ISNS]、アイデンティティ・ペイロード（例えば、ID_FQDNs）、及び（書X509v3証明書と、例えば、）証明書ベースの認証の任意の使用は、複雑化の許可スキーマを可能にします。このようなスキーマの定義（例えば、役割ベースのアクセス制御）は、本明細書の範囲外です。
This specification allows any and all security mechanisms in an iFCP gateway to be administratively disabled. Security policies MUST have, at most, iFCP Portal resolution. Administrators may gain control over security policies through an adequately secured interaction with a management interface or with iSNS.
この仕様は、iFCPゲートゲートウェイ内の任意のおよびすべてのセキュリティメカニズムが管理上無効にされることを可能にします。セキュリティポリシーは、高々、のiFCP Portalの解像度を持っていなければなりません。管理者は、管理インターフェイスまたはiSNSので十分に確保相互作用を介して、セキュリティポリシーの制御を取得します。
iSNS [ISNS] is an invariant in all iFCP deployments. iFCP gateways MUST use iSNS for discovery services and MAY use security policies configured in the iSNS database as the basis for algorithm negotiation in IKE. The iSNS specification defines mechanisms for securing communication between an iFCP gateway and iSNS server(s). Additionally, the specification indicates how elements of security policy concerning individual iFCP sessions can be retrieved from iSNS server(s).
ISNは[ISNS]すべてのiFCP展開では不変です。 iFCPゲートゲートウェイは、ディスカバリサービスのためにiSNSを使用しなければならないし、IKEにおけるアルゴリズムの交渉の基礎としてのiSNSデータベースで構成されたセキュリティポリシーを使用するかもしれません。 iSNSの仕様は、iFCPゲートゲートウェイとiSNSサーバ（複数可）との間の通信を確保するためのメカニズムを定義します。また、仕様は、個々のiFCPセッションに関するセキュリティポリシーの要素は、iSNSサーバ（複数可）から取得することができるかを示します。
Applicable technology from IPsec and IKE is defined in the following suite of specifications:
IPsecとIKEからの適用技術は、仕様の以下のスイートで定義されています。
[RFC2401] Security Architecture for the Internet Protocol
[RFC2401]インターネットプロトコルのためのセキュリティアーキテクチャ
[RFC2402] IP Authentication Header
[RFC2402] IP認証ヘッダ
[RFC2404] The Use of HMAC-SHA-1-96 within ESP and AH
[RFC2404] ESPおよびAH内HMAC-SHA-1-96の使用
[RFC2405] The ESP DES-CBC Cipher Algorithm with Explicit IV
[RFC2405]明示的なIVとESP DES-CBC暗号アルゴリズム
[RFC2406] IP Encapsulating Security Payload
[RFC2406] IPカプセル化セキュリティペイロード
[RFC2407] The Internet IP Security Domain of Interpretation for ISAKMP
[RFC2407] ISAKMPのための解釈のインターネットIPセキュリティドメイン
[RFC2408] Internet Security Association and Key Management Protocol (ISAKMP)
[RFC2408]インターネットSecurity AssociationとKey Managementプロトコル（ISAKMP）
[RFC2409] The Internet Key Exchange (IKE)
[RFC2409]インターネット鍵交換（IKE）
[RFC2410] The NULL Encryption Algorithm and Its Use With IPSEC
[RFC2410] NULL暗号化アルゴリズムおよびIPSecでの使用
[RFC2451] The ESP CBC-Mode Cipher Algorithms
[RFC2451] ESP CBCモード暗号アルゴリズム
[RFC2709] Security Model with Tunnel-mode IPsec for NAT Domains
[RFC2709] NATドメインのトンネルモードのIPsecとセキュリティモデル
The implementation of IPsec and IKE is required according to the following guidelines.
IPsecとIKEの実装は、以下のガイドラインに従って必要とされます。
Support for the IP Encapsulating Security Payload (ESP) [RFC2406] is MANDATORY to implement. When ESP is used, per-packet data origin authentication, integrity, and replay protection MUST be used.
IPカプセル化セキュリティペイロード（ESP）[RFC2406]のサポートは、実装が必須です。 ESPを使用する場合は、パケットごとのデータ発信元認証、完全性、および再生保護を使用しなければなりません。
For data origin authentication and integrity with ESP, HMAC with SHA1 [RFC2404] MUST be implemented, and the Advanced Encryption Standard [AES] in CBC MAC mode with Extended Cipher Block Chaining SHOULD be implemented in accordance with [AESCBC].
ESPとデータ発信元認証と完全性のために、SHA1とHMAC [RFC2404]は実装しなければならない、とのAdvanced Encryption Standardは、[AES] CBC MACモードで拡張暗号ブロック連鎖は[AESCBC]に従って実施されるべきであると。
For confidentiality with ESP, 3DES in CBC mode [RFC2451] MUST be implemented, and AES counter mode encryption [AESCTR] SHOULD be implemented. NULL encryption MUST be supported as well, as defined in [RFC2410]. DES in CBC mode SHOULD NOT be used due to its inherent weakness. Since it is known to be crackable with modest computation resources, it is inappropriate for use in any iFCP deployment scenario.
ESPとの機密保持のために、CBCモード[RFC2451]で3DESを実装しなければならない、とAESカウンタモードの暗号化は、[AESCTR]実装する必要があります。 [RFC2410]で定義されているNULL暗号化は、同様にサポートしなければなりません。 CBCモードのDESは、その固有の弱点に使用しないでください。それは控えめな計算資源とクラックできることが知られているので、それはどんなのiFCP展開シナリオでの使用には不適切です。
A conforming iFCP protocol implementation MUST implement IPsec ESP [RFC2406] in tunnel mode [RFC2401] and MAY implement IPsec ESP in transport mode.
適合のiFCPプロトコルの実装は、トンネル・モードのIPsec ESP [RFC2406]、[RFC2401]を実装しなければならなくて、トランスポート・モードのIPsec ESPを実装することができます。
Regarding key management, iFCP implementations MUST support IKE [RFC2409] for bi-directional peer authentication, negotiation of security associations, and key management, using the IPsec DOI. There is no requirement that the identities used in authentication be kept confidential. Manual keying MUST NOT be used since it does not provide the necessary keying support. According to [RFC2409], pre-shared secret key authentication is MANDATORY to implement, whereas certificate-based peer authentication using digital signatures MAY be implemented (see Section 10.3.3 regarding the use of certificates). [RFC2409] defines the following requirement levels for IKE Modes:
鍵管理に関する、のiFCP実装は、IPsec DOIを使用して、IKE双方向ピア認証のために[RFC2409]、セキュリティアソシエーションのネゴシエーション、および鍵管理をサポートしなければなりません。認証に使用されるアイデンティティが秘密にする必要はありません。それは必要なキーイングサポートを提供していませんので、手動キーを使用してはいけません。デジタル署名を使用して、証明書ベースのピア認証を実施することができるのに対し、[RFC2409]によれば、事前共有秘密鍵認証は、実装が必須であり（証明書の使用に関するセクション10.3.3を参照のこと）。 [RFC2409]はIKEモードのための次の要求レベルを定義しています。
Phase-1 Main Mode MUST be implemented.
フェーズ1メインモードを実装する必要があります。
Phase-1 Aggressive Mode SHOULD be implemented.
フェーズ1アグレッシブモードが実施されるべきです。
Phase-2 Quick Mode MUST be implemented.
フェーズ2のクイックモードを実装する必要があります。
Phase-2 Quick Mode with key exchange payload MUST be implemented.
鍵交換ペイロードを持つフェーズ2のクイックモードを実装する必要があります。
With iFCP, Phase-1 Main Mode SHOULD NOT be used in conjunction with pre-shared keys, due to Main Mode's vulnerability to man-in-the-middle-attackers when group pre-shared keys are used. In this scenario, Aggressive Mode SHOULD be used instead. Peer authentication using the public key encryption methods outlined in [RFC2409] SHOULD NOT be used.
iFCPゲートでは、フェーズ1メインモードが原因のman-in-the-middle-攻撃するグループ事前共有キーが使用されている場合、メインモードの脆弱性に、事前共有キーと組み合わせて使用されるべきではありません。このシナリオでは、アグレッシブモードを代わりに使用してください。 [RFC2409]に概説された公開鍵暗号方式を使用してピア認証を使用しないでください。
The DOI [RFC2407] provides for several types of Identification Payloads.
DOI [RFC2407]は同定ペイロードのいくつかのタイプを提供します。
When used for iFCP, IKE Phase 1 exchanges MUST explicitly carry the Identification Payload fields (IDii and IDir). Conforming iFCP implementations MUST use ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6), or ID_FQDN Identification Type values. The ID_USER_FQDN, IP Subnet, IP Address Range, ID_DER_ASN1_DN, ID_DER_ASN1_GN Identification Type values SHOULD NOT be used. The ID_KEY_ID Identification Type values MUST NOT be used. As described in [RFC2407], the port and protocol fields in the Identification Payload MUST be set to zero or UDP port 500.
iFCPゲートに使用する場合、IKEフェーズ1つの交換は、明示的に識別ペイロードフィールド（IDiiとIDIR）を運ばなければなりません。 iFCP実装を従わせるID_IPV4_ADDR、ID_IPV6_ADDR（プロトコルスタックがIPv6をサポートしている場合）、またはID_FQDN識別タイプ値を使用しなければなりません。 ID_USER_FQDN、IPサブネット、IPアドレス範囲、ID_DER_ASN1_DN、ID_DER_ASN1_GN識別型の値を使用しないでください。 ID_KEY_ID識別型の値を使用してはいけません。 [RFC2407]に記載されているように、識別ペイロードにポート、プロトコルフィールドは、ゼロまたはUDPポート500に設定されなければなりません。
When used for iFCP, IKE Phase 2 exchanges MUST explicitly carry the Identification Payload fields (IDci and IDcr). Conforming iFCP implementations MUST use either ID_IPV4_ADDR or ID_IPV6_ADDR Identification Type values (according to the version of IP supported). Other Identification Type values MUST NOT be used. As described in Section 5.2.2, the gateway creating the iFCP session must query the iSNS server to determine the appropriate port on which to initiate the associated TCP connection. Upon a successful IKE Phase 2 exchange, the IKE responder enforces the negotiated selectors on the IPsec SAs. Any subsequent iFCP session creation requires the iFCP peer to query its iSNS server for access control (in accordance with the session creation requirements specified in Section 5.2.2.1).
iFCPゲートに使用する場合、IKEフェーズ2つの交換は、明示的に識別ペイロードフィールド（IDci及びIDCR）を運ばなければなりません。適合のiFCP実装はID_IPV4_ADDRまたは（サポートされているIPのバージョンに応じて）ID_IPV6_ADDR識別タイプ値のいずれかを使用しなければなりません。他の識別型の値を使用してはいけません。 5.2.2項で説明したように、のiFCPセッションを作成ゲートウェイは、関連するTCP接続を開始するための適切なポートを決定するために、iSNSサーバに照会しなければなりません。成功したIKEフェーズ2交換の際に、IKE応答者は、IPsec SAの上で交渉セレクタを強制します。これ以降のiFCPセッションの作成（セクション5.2.2.1で指定されたセッションの作成要件に従って）アクセス制御のためのiSNSサーバーを照会するためのiFCPピアが必要です。
A conforming iFCP Portal is capable of establishing one or more IKE Phase-1 Security Associations (SAs) to a peer iFCP Portal. A Phase-1 SA may be established when an iFCP Portal is initialized or may be deferred until the first TCP connection with security requirements is established.
適合のiFCPポータルは、ピアのiFCPポータルへの1つ以上のIKEフェーズ1セキュリティアソシエーション（SA）を確立することができます。 iFCP Portalが初期化されたり、セキュリティ要件を持つ最初のTCP接続が確立されるまで延期することができるときフェーズ1 SAを確立することができます。
An IKE Phase-2 SA protects one or more TCP connections within the same iFCP Portal. More specifically, the successful establishment of an IKE Phase-2 SA results in the creation of two uni-directional IPsec SAs fully qualified by the tuple <SPI, destination IP address, ESP>.
IKEフェーズ2 SAは、同じのiFCPポータル内の1つ以上のTCP接続を保護します。より具体的には、2つの単方向のIPsec SAの作成にIKEフェーズ2 SAの結果の成功確立が完全<ESP、SPI、宛先IPアドレス>タプルによって修飾します。
These SAs protect the setup process of the underlying TCP connections and all their subsequent TCP traffic. The number of TCP connections in an IPsec SA, as well as the number of SAs, is practically driven by security policy considerations (i.e., security services are defined at the granularity of an IPsec SA only), QoS considerations (e.g., multiple QoS classes within the same IPsec SA increase odds of packet reordering, possibly falling outside the replay window), and failure compartmentalization considerations. Each of the TCP connections protected by an IPsec SA is either in the unbound state, or bound to a specific iFCP session.
これらのSAは、基礎となるTCP接続と、すべての彼らのその後のTCPトラフィックのセットアッププロセスを保護します。 IPsecのSAでのTCP接続の数だけでなく、SAの数、実質的に（つまり、セキュリティサービスのみのIPsec SAの粒度で定義されています）セキュリティポリシーの考慮によって駆動され、QoSの考慮事項（例えば、複数のQoSクラスパケットの並べ替え、おそらく再生ウィンドウから外れ）、及び故障区画の考慮の同一のIPsec SAの増加オッズ内。 IPsecのSAで保護されたTCP接続のそれぞれは、いずれかの結合していない状態で、または特定のiFCPセッションにバインドされています。
In summary, at any point in time:
要約すると、任意の時点で：
-- there exist 0..M IKE Phase-1 SAs between peer iFCP portals,
- ピアのiFCPポータル間0..M IKEフェーズ1のSAが存在し、
-- each IKE Phase-1 SA has 0..N IKE Phase-2 SAs, and
- 各IKEフェーズ1 SAが0..N IKEフェーズ2 SAを有し、そして
-- each IKE Phase-2 SA protects 0..Z TCP connections.
- 各IKEフェーズ2 SAは、0..Z TCP接続を保護します。
The creation of an IKE Phase-2 SA may be triggered by a policy rule supplied through a management interface or by iFCP Portal properties registered with the iSNS server. Similarly, the use of a Key Exchange payload in Quick Mode for perfect forward secrecy may be dictated through a management interface or by an iFCP Portal policy rule registered with the iSNS server.
IKEフェーズ2 SAの作成は、管理インターフェイスを介して供給されるポリシールールによって、またはiSNSサーバに登録のiFCPポータル特性によってトリガされてもよいです。同様に、完全転送秘密のクイックモードのキー交換ペイロードの使用は、管理インターフェイスを介して、または、iSNSサーバに登録されているのiFCP Portalのポリシールールによって決定することができます。
If an iFCP implementation makes use of unbound TCP connections, and such connections belong to an iFCP Portal with security requirements, then the unbound connections MUST be protected by an SA at all times just like bound connections.
iFCP実装が結合していないTCPコネクションを利用して、このような接続は、セキュリティ要件とのiFCP Portalに属している場合には、結合していない接続がちょうどバインド接続のような常時SAで保護する必要があります。
Upon receipt of an IKE Phase-2 delete message, there is no requirement to terminate the protected TCP connections or delete the associated IKE Phase-1 SA. Since an IKE Phase-2 SA may be associated with multiple TCP connections, terminating these connections might in fact be inappropriate and untimely.
IKEフェーズ2削除メッセージを受信すると、保護されたTCP接続を終了または関連IKEフェーズ1 SAを削除する必要はありません。 IKEフェーズ2 SAので、実際には不適切と早すぎるかもしれないこれらの接続を終了する、複数のTCP接続に関連付けられてもよいです。
To minimize the number of active Phase-2 SAs, IKE Phase-2 delete messages may be sent for Phase-2 SAs whose TCP connections have not handled data traffic for a while. To minimize the use of SA resources while the associated TCP connections are idle, creation of a new SA should be deferred until new data are to be sent over the connections.
アクティブフェーズ2 SAの数を最小限にするために、IKEフェーズ2削除メッセージは、そのTCP接続はしばらくの間、データトラフィックを処理していないフェーズ2のSAのために送信されることがあります。新しいデータが接続を介して送信されるまで、関連するTCP接続がアイドル状態にある間、SAリソースの使用を最小限に抑えるために、新しいSAの作成は延期されなければなりません。
Conforming iFCP implementations MAY support peer authentication via digital signatures and certificates. When certificate authentication is chosen within IKE, each iFCP gateway needs the certificate credentials of each peer iFCP gateway in order to establish a security association with that peer.
準拠のiFCP実装は、デジタル署名と証明書を経由してピアの認証をサポートするかもしれません。証明書認証がIKE内で選択された場合、各のiFCPゲートウェイはそのピアとのセキュリティアソシエーションを確立するために、各ピアのiFCPゲートウェイの証明書認証情報を必要とします。
Certificate credentials used by iFCP gateways MUST be those of the machine. Certificate credentials MAY be bound to the interface (IP Address or FQDN) of the iFCP gateway used for the iFCP session, or to the fabric WWN of the iFCP gateway itself. Since the value of a machine certificate is inversely proportional to the ease with which an attacker can obtain one under false pretenses, it is advisable that the machine certificate enrollment process be strictly controlled. For example, only administrators may have the ability to enroll a machine with a machine certificate. User certificates SHOULD NOT be used by iFCP gateways for establishment of SAs protecting iFCP sessions.
iFCPゲートウェイによって使用される証明書の資格情報は、マシンのものでなければなりません。証明書の資格情報は、のiFCPセッションに使用されるのiFCPゲートウェイのインターフェース（IPアドレスまたはFQDN）に、またはのiFCPゲートウェイ自体のファブリックWWNに結合させることができます。マシン証明書の値は、攻撃者が偽っ下で1を得ることができる容易さに反比例するので、マシン証明書の登録プロセスを厳密に制御することが賢明です。たとえば、管理者のみがマシン証明書を持つマシンを登録する機能を有することができます。ユーザー証明書は、SAの確立はのiFCPセッションを保護するためのiFCPゲートウェイで使用することはできません。
If the gateway does not have the peer iFCP gateway's certificate credentials, then it can obtain them:
ゲートウェイは、ピアのiFCPゲートウェイの証明書の資格情報を持っていない場合、それはそれらを得ることができます。
a) by using the iSNS protocol to query for the peer gateway's certificate(s) stored in a trusted iSNS server, or
A）信頼iSNSサーバに格納されたピアゲートウェイの証明書（複数可）を照会するのiSNSプロトコルを使用することによって、又は
b) through use of the ISAKMP Certificate Request Payload (CRP) [RFC2408] to request the certificate(s) directly from the peer iFCP gateway.
B）ピアのiFCPゲートウェイから直接証明書を要求するISAKMP証明書要求ペイロード（CRP）の使用[RFC2408]を介し。
When certificate chains are long enough, IKE exchanges using UDP as the underlying transport may yield IP fragments, which are known to work poorly across some intervening routers, firewalls, and NA(P)T boxes. As a result, the endpoints may be unable to establish an IPsec security association.
証明書チェーンが十分な長さである場合には、基礎となるトランスポートとしてUDPを使用してIKE交換は、いくつかの介在ルータ、ファイアウォール、およびNA（P）Tボックス間で十分に機能しないことが知られているIPフラグメントを、もたらすことがあります。その結果、エンドポイントは、IPsecセキュリティアソシエーションを確立できない場合があります。
Due to these fragmentation shortcomings, IKE is most appropriate for intra-domain usage. Known solutions to the fragmentation problem include sending the end-entry machine certificate rather than the chain, reducing the size of the certificate chain, using IKE implementations over a reliable transport protocol (e.g., TCP) assisted by Path MTU discovery and code against black-holing as per [RFC2923], or installing network components that can properly handle fragments.
これらの断片化の欠点に、IKEは、ドメイン内の使用のために最も適切です。断片化の問題に対する既知の解決策は、（例えば、TCP）黒色に対するパスMTU発見およびコードによって支援信頼できるトランスポートプロトコル上でIKE実装を使用して、証明書チェーンのサイズを小さく、チェーンではなく、エンドエントリマシン証明書を送ることを含みます[RFC2923]に従って穴形成、又は適切フラグメントを処理することができるネットワーク・コンポーネントをインストールします。
IKE negotiators SHOULD check the pertinent Certificate Revocation List (CRL) [RFC2408] before accepting a certificate for use in IKE's authentication procedures.
IKE交渉はIKEの認証手順で使用するための証明書を受け入れる前に、適切な証明書失効リスト（CRL）[RFC2408]をチェックする必要があります。
iFCP implementations MUST use iSNS for discovery and management services. Consequently, the security of the iSNS protocol has an impact on the security of iFCP gateways. For a discussion of potential threats to iFCP gateways through use of iSNS, see [ISNS].
iFCP実装は発見および管理サービスのためのiSNSを使用しなければなりません。したがって、のiSNSプロトコルのセキュリティは、iFCPゲートゲートウェイのセキュリティに影響を与えます。 iSNSを使用してのiFCPゲートウェイへの潜在的な脅威の議論に関しては、[ISNS]を参照してください。
To provide security for iFCP gateways using the iSNS protocol for discovery and management services, the IPSec ESP protocol in tunnel mode MUST be supported for iFCP gateways. Further discussion of iSNS security implementation requirements is found in [ISNS]. Note that iSNS security requirements match those for iFCP described in Section 10.3.
発見および管理サービスのためのiSNSプロトコルを使用してのiFCPゲートウェイのセキュリティを提供するために、トンネルモードでのIPSec ESPプロトコルはiFCPゲートゲートウェイにサポートしなければなりません。 iSNSのセキュリティ実装要件のさらなる議論は[ISNS]で発見されました。 iSNSのセキュリティ要件はiFCPゲートのものは、セクション10.3で説明一致していることに注意してください。
Once communication between iFCP gateways and the iSNS server has been secured through use of IPSec, the iFCP gateways have the capability to discover the security settings that they need to use (or not use) to protect iFCP traffic. This provides a potential scaling advantage over device-by-device configuration of individual security policies for each iFCP gateway. It also provides an efficient means for each iFCP gateway to discover the use or non-use of specific security capabilities by peer gateways.
iFCPゲートウェイと、iSNSサーバ間の通信は、IPSecを使用して確保された後、iFCPゲートゲートウェイは、彼らがのiFCPトラフィックを保護するために（使用するか、しない）を使用する必要があるセキュリティ設定を発見する能力を有しています。これは、それぞれのiFCPゲートウェイの個々のセキュリティポリシーのデバイスによってデバイス構成上の潜在的スケーリングの利点を提供します。それはまた、ピア・ゲートウェイによって、特定のセキュリティ機能の使用または不使用を発見するそれぞれのiFCPゲートウェイのための効率的な手段を提供します。
Further discussion on use of iSNS to distribute security policies is found in [ISNS].
セキュリティポリシーを配布するISNの使用についての更なる議論は[ISNS]で発見されました。
An iFCP implementation may be able to disable security mechanisms for an iFCP Portal administratively through a management interface or through security policy elements set in the iSNS server. As a consequence, IKE or IPsec security associations will not be established for any iFCP sessions that traverse the portal.
iFCP実装は、管理インタフェースを介して、またはiSNSサーバに設定されたセキュリティポリシーの要素を管理上のiFCP Portalのセキュリティ・メカニズムを無効にすることができるかもしれません。その結果、IKEやIPsecセキュリティアソシエーションは、ポータルを通過する任意ののiFCPセッションのために確立されることはありません。
For most IP networks, it is inappropriate to assume physical security, administrative security, and correct configuration of the network and all attached nodes (a physically isolated network in a test lab may be an exception). Therefore, authentication SHOULD be used in order to provide minimal assurance that connections have initially been opened with the intended counterpart. The minimal iFCP security policy only states that an iFCP gateway SHOULD authenticate its iSNS server(s) as described in [ISNS].
ほとんどのIPネットワークの場合、それは物理的なセキュリティ、管理、セキュリティ、およびネットワークの適切な構成および接続されているすべてのノードを想定することは不適切である（試験ラボで物理的に分離されたネットワークは例外であってもよいです）。そのため、認証は、接続が最初に意図した相手と開かれていることを最低限の保証を提供するために使用されるべきです。最小のiFCPセキュリティポリシーは、[ISNS]で説明されるようにiFCPゲートゲートウェイがiSNSサーバ（複数可）を認証すべきであると述べています。
Conforming iFCP protocol implementations SHALL correctly communicate gateway-to-gateway, even across one or more intervening best-effort IP regions. The timings with which such gateway-to gateway communication is performed, however, will greatly depend upon BER, packet losses, latency, and jitter experienced throughout the best-effort IP regions. The higher these parameters, the higher the gap measured between iFCP observed behaviors and baseline iFCP behaviors (i.e., as produced by two iFCP gateways directly connected to one another).
準拠のiFCPプロトコルの実装が正しくでも、1つまたは複数の介在するベストエフォート型のIP領域を越え、ゲートウェイ間の通信を行うものとします。そのようなゲートウェイへの通信をゲートウェイが実行されるタイミングが、しかし、非常にベストエフォートIP領域にわたって経験BER、パケット損失、遅延、およびジッタに依存するであろう。 iFCP間で測定高く、これらのパラメータより高いギャップが行動とベースラインのiFCP挙動を観察した（すなわち、互いに直接に接続された2つのiFCPゲートウェイによって生成されます）。
It is expected that many iFCP deployments will benefit from a high degree of assurance regarding the behavior of intervening IP regions, with resulting high assurance on the overall end-to-end path, as directly experienced by fibre channel applications. Such assurance on the IP behaviors stems from the intervening IP regions supporting standard Quality-of-Service (QoS) techniques that are fully complementary to iFCP, such as:
多くのiFCP展開がとして直接ファイバー・チャネル・アプリケーションが経験する全体的なエンド・ツー・エンドのパス上の高い保証を得られて、IP領域を介在の行動に関する保証度の高い恩恵を受けることが期待されます。 IP行動上のこのような保証は、次のようなのiFCPに完全に相補的な技術を、標準のサービス品質（QoS）をサポートする介在IP領域からの茎：
a) congestion avoidance by over-provisioning of the network,
ネットワークのオーバープロビジョニングによってA）輻輳回避、
b) integrated Services [RFC1633] QoS,
b）の統合サービス[RFC1633]のQoS、
c) differentiated Services [RFC2475] QoS, and
C）差別化サービス[RFC2475] QoS、および
d) Multi-Protocol Label Switching [RFC3031].
d）のマルチプロトコルラベルは、[RFC3031]を切り替えます。
One may load an MPLS forwarding equivalence class (FEC) with QoS class significance, in addition to other considerations such as protection and diversity for the given path. The complementarity and compatibility of MPLS with Differentiated Services is explored in [MPSLDS], wherein the PHB bits are copied to the EXP bits of the MPLS shim header.
一つは、そのような指定されたパスの保護および多様性のような他の考慮事項に加えて、QoSクラス有意とMPLS転送等価クラス（FEC）をロードすることができます。 PHBビットがMPLSシムヘッダのEXPビットにコピーされる差別化サービスとの相補及びMPLSの互換性は、[MPSLDS]で検討されています。
In the most general definition, two iFCP gateways are separated by one or more independently managed IP regions that implement some of the QoS solutions mentioned above. A QoS-capable IP region supports the negotiation and establishment of a service contract specifying the forwarding service through the region. Such contract and negotiation rules are outside the scope of this document. In the case of IP regions with DiffServ QoS, the reader should refer to Service Level Specifications (SLS) and Traffic Conditioning Specifications (TCS) (as defined in [DIFTERM]). Other aspects of a
最も一般的な定義では、二つのiFCPゲートウェイは1で区切られた以上の独立して上記のQoSソリューションの一部を実装するIP領域を管理されています。 QoSの対応のIP領域は、領域を介して転送サービスを指定するサービス契約の交渉と設立をサポートしています。このような契約や交渉のルールは、この文書の範囲外です。 DiffServのQoSをIP領域の場合には、リーダは、サービスレベル仕様（SLS）及びトラフィックコンディショニング仕様（TCS）（[DIFTERM]で定義される）を参照されたいです。の他の態様
service contract are expected to be non-technical and thus are outside of the IETF scope.
サービス契約は、非技術的なことが期待ので、IETF範囲の外にされています。
Because fibre channel Class 2 and Class 3 do not currently support fractional bandwidth guarantees, and because iFCP is committed to supporting fibre channel semantics, it is impossible for an iFCP gateway to infer bandwidth requirements autonomously from streaming fibre channel traffic. Rather, the requirements on bandwidth or other network parameters need to be administratively set into an iFCP gateway, or into the entity that will actually negotiate the forwarding service on the gateway's behalf. Depending on the QoS techniques available, the stipulation of a forwarding service may require interaction with network ancillary functions, such as admission control and bandwidth brokers (via RSVP or other signaling protocols that an IP region may accept).
ファイバチャネルクラス2とクラス3は、現在、比帯域保証をサポートしていない、とのiFCPは、ファイバチャネルのセマンティクスをサポートすることを約束されているためのiFCPゲートウェイは、ファイバチャネルトラフィックを流すから自律的に帯域幅の要件を推測することは不可能だからです。むしろ、帯域幅または他のネットワークパラメータ上の要件は、管理上のiFCPゲートウェイへの、または実際にゲートウェイに代わって転送サービスを交渉しますエンティティに設定する必要があります。利用可能なQoS技術に応じて、転送サービスの規定は、（RSVPまたはIP領域が受け入れることができる他のシグナリングプロトコルを介して）そのようなアドミッション制御と帯域幅ブローカーのようなネットワークの補助機能との相互作用を必要とするかもしれません。
The administrator of a iFCP gateway may negotiate a forwarding service with IP region(s) for one, several, or all of an iFCP gateway's TCP sessions used by an iFCP gateway. Alternately, this responsibility may be delegated to a node downstream. Since one TCP connection is dedicated to each iFCP session, the traffic in an individual N_PORT to N_PORT session can be singled out by iFCP-unaware network equipment as well.
iFCPゲートゲートウェイの管理者は、いくつかの一つ、又はiFCPゲートゲートウェイによって使用されるのiFCPゲートウェイのTCPセッションのすべてのIP領域（S）と転送サービスを交渉することができます。代わりに、この責任は下流のノードに委任することができます。 1つのTCP接続がそれぞれのiFCPセッションに専用されているので、N_PORTセッションに個々のN_PORT内のトラフィックは、同様のiFCP非対応のネットワーク機器によって選抜することができます。
For rendering the best emulation of fibre channel possible over IP, it is anticipated that typical forwarding services will specify a fixed amount of bandwidth, null losses, and, to a lesser degree of relevance, low latency and low jitter. For example, an IP region using DiffServ QoS may support SLSes of this nature by applying EF DSCPs to the iFCP traffic.
IP経由の可能なファイバチャネルの最高のエミュレーションをレンダリングするためには、典型的な転送サービスは、ヌル損失を一定の帯域幅を指定し、そして、関連性、さらに低ジッタのより少ない程度になると予想されます。例えば、DiffServのQoSを使用してIP領域がのiFCPトラフィックにEFのDSCPを適用することによって、このような性質のSLSesをサポートすることができます。
The IANA-assigned port for iFCP traffic is port number 3420.
iFCPトラフィックのためのIANAによって割り当てられたポートは、ポート番号3420です。
An iFCP Portal may initiate a connection using any TCP port number consistent with its implementation of the TCP/IP stack, provided each port number is unique. To prevent the receipt of stale data associated with a previous connection using a given port number, the provisions of [RFC1323], Appendix B, SHOULD be observed.
iFCP Portalは、各ポート番号は一意である設けTCP / IPスタックの実装と一致する任意のTCPポート番号を使用して接続を開始することができます。特定のポート番号を使用して、以前の接続に関連付けられている古いデータの受信を防止するために、[RFC1323]、付録Bの規定は、観察されるはずです。
[AESCBC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[AESCBC]フランケル、S.およびH.ハーバート、 "AES-XCBC-MAC-96アルゴリズムとIPsecでの使用"、RFC 3566、2003年9月。
[AESCTR] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[AESCTR] Housley氏、R.、RFC 3686 "IPsecのカプセル化セキュリティペイロード（ESP）でのAdvanced Encryption Standard（AES）カウンタモードの使用" を、2004年1月。
[ENCAP] Weber, R., Rajagopal, M., Travostino, F., O'Donnell, M., Monia, C., and M. Merhar, "Fibre Channel (FC) Frame Encapsulation", RFC 3643, December 2003.
[ENCAP]ウェーバー、R.、Rajagopal、M.、Travostino、F.、オドネル、M.、モニア、C.、およびM. Merhar、 "ファイバチャネル（FC）フレームカプセル化"、RFC 3643、2003年12月。
[FC-FS] dpANS INCITS.XXX-200X, "Fibre Channel Framing and Signaling (FC-FS), Rev 1.70, INCITS Project 1331D, February 2002
[FC-FS] dpANS INCITS.XXX-200X、「ファイバチャネルフレーミングおよびシグナリング（FC-FS）、改訂1.70、INCITSプロジェクト1331D、2002年2月
[FC-GS3] dpANS X3.XXX-200X, "Fibre Channel Generic Services -3 (FC-GS3)", revision 7.01, INCITS Project 1356-D, November 2000
[FC-GS3] dpANS X3.XXX-200X、 "ファイバ・チャネル汎用サービス-3（FC-GS3）"、改訂7.01、INCITSプロジェクト1356-D、2000年11月
[FC-SW2] dpANS X3.XXX-2000X, "Fibre Channel Switch Fabric -2 (FC-SW2)", revision 5.2, INCITS Project 1305-D, May 2001
[FC-SW2]、 "ファイバチャネルスイッチファブリック-2（FC-SW2）"、改訂5.2、INCITSプロジェクト1305-D、2001年5月dpANS X3.XXX-2000X
[FCP-2] dpANS T10, "Fibre Channel Protocol for SCSI, Second Version", revision 8, INCITS Project 1144D, September 2002
[FCP-2] dpANS T10、 "SCSI、セカンドバージョンのためのファイバ・チャネル・プロトコル"、リビジョン8、INCITSプロジェクト1144D、2002年9月
[ISNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171, September 2005.
[ISNS]ツェン、J.、ギボンズ、K.、Travostino、F.、デュレイニー、C.、およびJ. Souzaの、 "インターネットストレージネームサービス（iSNSの）"、RFC 4171、2005年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404] Madson、C.とR.グレン、 "ESPおよびAH内のHMAC-SHA-1-96の使用"、RFC 2404、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, N.
[RFC2407]パイパー、D.、 "ISAKMPのための解釈のインターネットIPセキュリティー領域"、RFC 2407、N.
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2408]モーガン、D.、Schertler、M.、シュナイダー、M.、およびJ.ターナー、 "インターネットセキュリティ協会と鍵管理プロトコル（ISAKMP）"、RFC 2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2410]グレン、R.とS.ケント、 "NULL暗号化アルゴリズムとIPsecでの使用"、RFC 2410、1998年11月。
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451]ペレイラ、R.とR.アダムス、 "ESP CBCモード暗号アルゴリズム"、RFC 2451、1998年11月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[SECIPS] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols Over IP", RFC 3723, April 2004.
"ブロック・ストレージプロトコルでIPを保護" [SECIPS] Aboba、B.、ツェン、J.、ウォーカー、J.、Rangan、V.、およびF. Travostino、RFC 3723、2004年4月。
[AES] FIPS Publication XXX, "Advanced Encryption Standard (AES)", Draft, 2001, Available from http://csrc.nist.gov/publications/drafts/dfips-AES.pdf
[AES] FIPS公開XXX、 "高度暗号化標準（AES）"、ドラフト、2001年から利用可能http://csrc.nist.gov/publications/drafts/dfips-AES.pdf
[DIFTERM] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[DIFTERM]グロスマン、D.、 "Diffservのための新しい用語と明確化"、RFC 3260、2002年4月。
[FC-AL2] dpANS X3.XXX-199X, "Fibre Channel Arbitrated Loop (FC-AL-2)", revision 7.0, NCITS Project 1133D, April 1999
[FC-AL2] dpANS X3.XXX-199X、 "ファイバチャネル調停ループ（FC-AL2）"、リビジョン7.0、NCITSプロジェクト1133D、1999年4月
[FC-FLA] TR-20-199X, "Fibre Channel Fabric Loop Attachment (FC-FLA)", revision 2.7, NCITS Project 1235-D, August 1997
[FC-FLA] TR-20-199X、 "ファイバーチャネルファブリックループアタッチメント（FC-FLA）"、改訂2.7、NCITSプロジェクト1235-D、1997年8月
[FC-VI] ANSI/INCITS 357:2002, "Fibre Channel Virtual Interface Architecture Mapping Protocol (FC-VI)", NCITS Project 1332-D, July 2000.
[FC-VI] ANSI / INCITS 357：2002、 "ファイバチャネル仮想インタフェース・アーキテクチャのマッピングプロトコル（FC-VI）"、NCITSプロジェクト1332-D、2000年7月。
[KEMALP] Kembel, R., "The Fibre Channel Consultant, Arbitrated Loop", Robert W. Kembel, Northwest Learning Associates, 2000, ISBN 0-931836-84-0
[KEMALP] Kembel、R.、 "ファイバー・チャネル・コンサルタント、アービトレーテッドループ"、ロバートW. Kembel、北西ラーニング・アソシエイツ、2000、ISBN 0-931836-84-0
[KEMCMP] Kembel, R., "Fibre Channel, A Comprehensive Introduction", Northwest Learning Associates Inc., 2000, ISBN 0-931836-84-0
[KEMCMP] Kembel、R.、 "ファイバチャネル、包括的な入門"、北西部の学習アソシエイツ株式会社、2000年、ISBN 0-931836-84-0
[MPSLDS] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
【MPSLDS】ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング（MPLS）差別化サービスのサポート」、RFC 3270、2002年5月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、R.、およびD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]ブレーデン、R.、クラーク、D.、およびS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC2030]ミルズ、D.、 "IPv4、IPv6、およびOSIのため簡易ネットワークタイムプロトコル（SNTP）バージョン4"、RFC 2030、1996年10月。
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2405] Madson、C.およびN. Doraswamy、 "明示的なIVとESP DES-CBC暗号アルゴリズム"、RFC 2405、1998年11月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.、およびW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC2625] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP over Fibre Channel", RFC 2625, June 1999.
[RFC2625] Rajagopal、M.、Bhagwat、R.、およびW.リカード、 "ファイバチャネルを介したIPとARP"、RFC 2625、1999年6月。
[RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for NAT Domains", RFC 2709, October 1999.
[RFC2709] Srisuresh、P.、 "NATドメインのトンネルモードのIPsecとセキュリティモデル"、RFC 2709、1999年10月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]レイヒー、K.、 "パスMTUディスカバリとTCPの問題"、RFC 2923、2000年9月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC896] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.
[RFC896]ネーグル、J.、 "IP / TCPインターネットワークにおける輻輳制御"、RFC 896、1984年1月。
Appendix A. iFCP Support for Fibre Channel Link Services
ファイバチャネルリンクサービスの付録A.のiFCPサポート
For reference purposes, this appendix enumerates all the fibre channel link services and the manner in which each shall be processed by an iFCP implementation. The iFCP processing policies are defined in Section 7.
参考のために、この付録では、すべてのファイバチャネルリンクサービス、それぞれのiFCP実装によって処理される様子を列挙する。 iFCP処理方針は、第7節で定義されています。
In the following sections, the name of a link service specific to a particular FC-4 protocol is prefaced by a mnemonic identifying the protocol.
以下のセクションでは、特定のFC-4プロトコルに固有のリンクサービスの名前は、プロトコルを識別ニーモニックによって前置きされます。
A.1. Basic Link Services
A.1。基本的なリンクサービス
The basic link services are shown in the following table:
基本的なリンクサービスは、次の表に示します。
Basic Link Services
基本的なリンクサービス
Name Description iFCP Policy
---- ----------- ----------
ABTS Abort Sequence Transparent BA_ACC Basic Accept Transparent BA_RJT Basic Reject Transparent NOP No Operation Transparent PRMT Preempted Rejected (Applies to Class 1 only) RMC Remove Connection Rejected (Applies to Class 1 only)
ABTSアボートシーケンス透明BA_ACC基本的には透明BA_RJT Basicを受け入れる（唯一のクラス1に適用）RMCが接続拒否を取り外します（のみクラス1に適用されます）拒否された優先処理の透明NOPノーオペレーション透明PRMTを拒否します
A.2. Pass-Through Link Services
A.2。パススルーリンクサービス
As specified in Section 7, the link service requests of Table 10 and the associated ACC response frames MUST be passed to the receiving N_PORT without altering the payload.
セクション7で指定されるように、表10のリンクサービス要求と関連付けられたACC応答フレームは、ペイロードを変更することなく、受信N_PORTに渡さなければなりません。
Name Description
---- -----------
ADVC Advise Credit CSR Clock Synchronization Request CSU Clock Synchronization Update ECHO Echo ESTC Estimate Credit ESTS Establish Streaming FACT Fabric Activate Alias_ID FAN Fabric Address Notification
ADVCはストリーミングFACTファブリックアクティブAlias_ID FANファブリックアドレス通知を確立クレジットCSRクロック同期要求CSUクロック同期更新ECHOエコーESTC推定クレジットESTSに助言します
FCP_RJT FCP FC-4 Link Service Reject FCP SRR FCP Sequence Retransmission Request FDACT Fabric Deactivate Alias_ID FDISC Discover F_Port Service Parameters FLOGI F_Port Login GAID Get Alias_ID LCLM Login Control List Management LINIT Loop Initialize LIRR Link Incident Record Registration LPC Loop Port Control LS_RJT Link Service Reject LSTS Loop Status NACT N_Port Activate Alias_ID NDACT N_Port Deactivate Alias_ID PDISC Discover N_Port Service Parameters PRLI Process Login PRLO Process Logout QoSR Quality of Service Request RCS Read Connection Status RLIR Registered Link Incident Report RNC Report Node Capability RNFT Report Node FC-4 Types RNID Request Node Identification Data RPL Read Port List RPS Read Port Status Block RPSC Report Port Speed Capabilities RSCN Registered State Change Notification RTV Read Timeout Value RVCS Read Virtual Circuit Status SBRP Set Bit-Error Reporting Parameters SCN State Change Notification SCR State Change Registration TEST Test TPLS Test Process Login State
FCP_RJTのFCP FC-4リンクサービスは、FCP SRRのFCPシーケンス再送要求FDACTファブリック無効Alias_ID FDISC出会うFポートサービスパラメータFLOGI FポートログインGAIDゲットAlias_ID LCLMログイン制御リスト管理LINITループ初期化LIRRリンクインシデントレコード登録LPCループポート制御LS_RJTリンクサービスが拒否拒否しますLSTSループ状態NACT NポートをアクティブAlias_ID NDACT Nポートの無効化サービスリクエストRCS読むの接続状態RLIR登録したリンクインシデントレポートRNCレポートノード機能RNFTレポートノードFC-4タイプRNID要求ノードのAlias_ID PDISC出会うNポートサービスパラメータPRLIプロセスログインPRLOプロセスログアウトQoSR品質識別データRPLリードポート一覧RPS読むポートステータスブロックRPSCレポートポート速度能力RSCN登録状態変更通知RTV読むタイムアウト値RVCS読む仮想回線ステータスSBRP設定ビット・エラーレポートのパラメータSCN状態変更通知SCR状態変更登録TESTテストTPLSのテストプロセスログインする 状態
Table 10. Pass-Through Link Services
表10.パススルーリンクサービス
A.3. Special Link Services
A.3。特別なリンクサービス
The extended and FC-4 link services of Table 11 are processed by an iFCP implementation as described in the sections referenced in the table.
テーブルで参照セクションに記載されているように、表11の拡張及びFC-4リンクサービスは、のiFCP実装によって処理されます。
Name Description Section
---- ----------- -------
ABTX Abort Exchange 7.3.1.1 ADISC Discover Address 7.3.1.2 ADISC Discover Address Accept 7.3.1.3 ACC FARP- Fibre Channel Address 7.3.1.4 REPLY Resolution Protocol Reply FARP- Fibre Channel Address 7.3.1.5 REQ Resolution Protocol Request LOGO N_PORT Logout 7.3.1.6 PLOGI Port Login 7.3.1.7 REC Read Exchange Concise 7.3.1.8 REC ACC Read Exchange Concise 7.3.1.9 Accept FCP REC FCP Read Exchange 7.3.2.1.1 Concise (see [FCP-2]) FCP REC FCP Read Exchange 7.3.2.1.2 ACC Concise Accept (see [FCP-2]) RES Read Exchange Status 7.3.1.10 Block RES ACC Read Exchange Status 7.3.1.11 Block Accept RLS Read Link Error Status 7.3.1.12 Block RRQ Reinstate Recovery 7.3.1.14 Qualifier RSI Request Sequence 7.3.1.15 Initiative RSS Read Sequence Status 7.3.1.13 Block SRL Scan Remote Loop 7.3.1.16 TPRLO Third Party Process 7.3.1.17 Logout TPRLO Third Party Process 7.3.1.18 ACC Logout Accept
ABTX中止交換7.3.1.1 ADISC出会うアドレス7.3.1.2 ADISC出会うアドレス7.3.1.3 ACC FARP-ファイバチャネルアドレス7.3.1.4 REPLY解決プロトコルがFARP-ファイバーチャネルアドレス7.3.1.5 REQ解決プロトコル要求LOGO N_PORTログアウト7.3.1.6返信受け入れますPLOGIポートログイン7.3.1.7 REC読む所簡潔7.3.1.8 REC ACC読む交換簡潔7.3.1.9は、7.3.2.1.1コンサイス（[FCP-2]を参照してください）FCP REC FCP読む交換7.3.2.1 FCP REC FCP読む交換を受け入れます。 2 ACC簡潔受け入れRES読む交換ステータス7.3.1.10ブロックRES ACC読む交換ステータス7.3.1.11ブロック受け入れるRLS読むリンクエラーステータス7.3.1.12ブロックRRQ回復回復7.3.1.14予選RSI要求シーケンス7.3（[FCP-2]を参照してください） .1.15イニシアティブRSS読むシーケンス状態7.3.1.13ブロックSRLスキャンリモートループ7.3.1.16 TPRLO第三者プロセス7.3.1.17ログアウトTPRLO第三者プロセス7.3.1.18 ACCログアウト受け入れます
Table 11. Special Link Services
表11.特別なリンクサービス
Appendix B. Supporting the Fibre Channel Loop Topology
付録B.は、ファイバチャネルループトポロジをサポート
A loop topology may be optionally supported by a gateway implementation in one of the following ways:
ループトポロジは、必要に応じて以下のいずれかの方法でゲートウェイの実装によってサポートされてもよいです。
a) By implementing the FL_PORT public loop interface specified in [FC-FLA].
A）[FC-FLA]で指定されたFLポートパブリックループインタフェースを実装すること。
b) By emulating the private loop environment specified in [FC-AL2].
B）[FC-AL2]で指定されたプライベートループ環境をエミュレートすることによって。
Private loop emulation allows the attachment of fibre channel devices that do not support fabrics or public loops. The gateway presents such devices to the fabric as though they were fabric-attached. Conversely, the gateway presents devices on the fabric, whether they are locally or remotely attached, as though they were connected to the private loop.
プライベートループエミュレーションは、ファブリックまたはパブリックループをサポートしていないファイバー・チャネル・デバイスの接続を可能にします。彼らはファブリック接続であるかのようゲートウェイは、ファブリックにこのようなデバイスを提供します。逆に、ゲートウェイは、彼らはプライベートループに接続されたかのように、それらはローカルまたはリモートで、取り付けられているかどうか、ファブリック上のデバイスを示します。
Private loop support requires gateway emulation of the loop primitives and control frames specified in [FC-AL2]. These frames and primitives MUST be locally emulated by the gateway. Loop control frames MUST NOT be sent over an iFCP session.
プライベートループサポートは、ループプリミティブと[FC-AL2]で指定された制御フレームのゲートウェイエミュレーションを必要とします。これらのフレームとプリミティブは、ローカルゲートウェイによってエミュレートされなければなりません。ループ制御フレームはのiFCPセッションで送ってはいけません。
B.1. Remote Control of a Public Loop
B.1。パブリックループのリモートコントロール
A gateway MAY disclose that a remotely attached device is connected to a public loop. If it does, it MUST also provide aliases representing the corresponding Loop Fabric Address (LFA), DOMAIN_ID, and FL_PORT Address Identifier through which the public loop may be remotely controlled.
ゲートウェイは、リモート接続されたデバイスは、パブリックループに接続されていることを開示することができます。それがない場合、それはまた、対応するループファブリックアドレス（LFA）、DOMAIN_ID、およびパブリックループを遠隔制御することができるを通じてFLポートアドレス識別子を表すエイリアスを提供しなければなりません。
The LFA and FL_PORT address identifier both represent an N_PORT that services remote loop management requests contained in the LINIT and SRL extended link service messages. To support these messages, the gateway MUST allocate an NL_PORT alias so that the corresponding alias for the LFA or FL_PORT address identifier can be derived by setting the Port ID component of the NL_PORT alias to zero.
LFAとFLポートアドレス識別子の両方がLINITに含まれているリモートループ管理要求にサービスを提供し、SRLは、リンクサービスメッセージを拡張N_PORTを表します。 LFAまたはFLポートアドレス識別子の対応する別名をゼロにNLポートエイリアスのポートIDのコンポーネントを設定することによって導出することができるように、これらのメッセージをサポートするために、ゲートウェイは、NLポートエイリアスを割り当てる必要があります。
Acknowledgements
謝辞
The authors are indebted to those who contributed material and who took the time to carefully review and critique this specification including David Black (EMC), Rory Bolt (Quantum/ATL), Victor Firoiu (Nortel), Robert Peglar (XIOtech), David Robinson (Sun), Elizabeth Rodriguez, Joshua Tseng (Nishan), Naoke Watanabe (HDS) and members of the IPS working group. For review of the iFCP security policy, the authors are further indebted to the authors of the IPS security document [SECIPS], which include Bernard Aboba (Microsoft), Ofer Biran (IBM), Uri Elzer (Broadcom), Charles Kunziger (IBM), Venkat Rangan (Rhapsody Networks), Julian Satran (IBM), Joseph Tardo (Broadcom), and Jesse Walker (Intel).
著者は、材料を拠出し、誰が慎重にデヴィッド・ブラック（EMC）、ロリー・ボルト（量子/ ATL）、ビクターFiroiu（ノーテル）、ロバート・Peglar（のXiotech）、デビッド・ロビンソンなど、この仕様を見直し、批判に時間がかかった人たちにお世話になっています（日）、エリザベス・ロドリゲス、ジョシュア・ツェン（ニシャン）、Naoke渡辺（HDS）とIPSワーキンググループのメンバー。 iFCPセキュリティポリシーの見直しについては、作者はバーナードAboba（マイクロソフト）、オフェルBiran（IBM）、ウリElzer（ブロードコム）、チャールズ・Kunziger（IBM）が含まIPSのセキュリティ文書の作者[SECIPS]、をさらにお世話になっています、ベンカット・ランガン（ラプソディ・ネットワーク）、ジュリアンSatran（IBM）、ジョセフ・Tardo（ブロードコム）、およびジェシー・ウォーカー（インテル）。
Author's Addresses
著者のアドレス
Comments should be sent to the ips mailing list (ips@ece.cmu.edu) or to the authors.
コメントは、（ips@ece.cmu.edu）や作者へのIPSメーリングリストに送信する必要があります。
Charles Monia 7553 Morevern Circle San Jose, CA 95135
チャールズ・モニア7553 Morevernサークルサンノゼ、CA 95135
EMail: charles_monia@yahoo.com
メールアドレス：charles_monia@yahoo.com
Rod Mullendore McDATA 4555 Great America Pkwy Suite 301 Santa Clara, CA 95054
ロッドMullendoreマクデータ4555グレートアメリカパークウェイスイート301サンタクララ、CA 95054
Phone: 408-519-3986 EMail: Rod.Mullendore@MCDATA.com
電話：408-519-3986 Eメール：Rod.Mullendore@MCDATA.com
Franco Travostino Nortel 600 Technology Park Drive Billerica, MA 01821 USA
フランコTravostinoノーテル600テクノロジーパークドライブビレリカ、MA 01821 USA
Phone: 978-288-7708 EMail: travos@nortel.com
電話：978-288-7708 Eメール：travos@nortel.com
Wayland Jeong TROIKA Networks, Inc. 2555 Townsgate Road, Suite 105 Westlake Village, CA 91361
ウェイランドチョンTROIKAネットワークス株式会社2555 Townsgate道路、スイート105ウェストレイク・ビレッジ、CA 91361
Phone: 805-371-1377 EMail: wayland@TroikaNetworks.com
電話：805-371-1377 Eメール：wayland@TroikaNetworks.com
Mark Edwards Adaptec (UK) Ltd. 4th Floor, Howard House Queens Ave, UK. BS8 1SD
マーク・エドワーズアダプテック（UK）リミテッド4階、ハワードハウスクイーンズアベニュー、英国。 BS8 1SD
Phone: +44 (0)117 930 9600 EMail: mark_edwards@adaptec.com
電話：+44（0）117 930 9600 Eメール：mark_edwards@adaptec.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。