[要約] RFC 4172は、iFCP（Internet Fibre Channel Storage Networking）プロトコルに関するものであり、Fibre Channelストレージネットワーキングをインターネット上で実現するためのプロトコルです。このRFCの目的は、Fibre Channelストレージネットワーキングをインターネット上で拡張し、柔軟性と効率性を向上させることです。
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
IFCP-インターネットファイバーチャネルストレージネットワーキングのプロトコル
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document specifies 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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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コンベンションは、T11ファイバーチャネル標準の挿入に使用されるものとは異なり、ビット0は最も有意なビットです。
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_PORTファブリックの範囲がローカルに接続されたデバイスのアドレスの範囲が、デバイスが存在する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_PORTファブリックのスコープがすべてのファイバーチャネルデバイスのアドレスの範囲が、ゲートウェイが属する境界付きIFCPファブリックに固有のゲートウェイ操作のモードです。
Bounded iFCP Fabric -- The union of two or more gateway regions configured to interoperate in address-transparent mode.
Bounded 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_PORTを接続し、ファイバーチャネルフレームのアドレス情報のみを使用してフレームをルーティングできるエンティティ」。
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_PORTSのコレクション。ノードは、[FC-FS]で説明されているN_portインターフェイスを使用して、ファイバーチャネルファブリックに取り付けられています。
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フレームカプセル化仕様[cap]およびこの仕様に従ってカプセル化されたファイバーチャネルフレーム。
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ポータルのネットワークアドレスは、IPCPセッションのためにTCP接続が作成されたときにリクエストが送信されるIPアドレスと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_portsのペアとそれらの間のトラフィックを運ぶ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エイリアス-IFCPプロトコルを介してアクセスされるリモートN_PORTを表すためにゲートウェイによって割り当てられたN_PORTアドレス。
N_PORT fabric address -- The address of an N_PORT within the fibre channel fabric.
N_PORTファブリックアドレス - ファイバーチャネルファブリック内の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_PORT ID-ゲートウェイ領域内のローカルに添付されたN_PORTのアドレス。N_PORT 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_PORT 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） - 発信元のN_PORTと応答するN_PORTの間の識別パラメーターと操作パラメーターの交換を通じてIFCPセッションを確立するファイバーチャネル拡張リンクサービス（ELS）。
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.
Fiber Channelは、ギガビット速度のデバイス間のピアツーピアコミュニケーションのために設計されたフレームベースのシリアルテクノロジーです。
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].
読者は、[kemcmp]と[kemalp]でテクノロジーの詳細な扱いを見つけます。
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_PORTS-ファイバーチャネルトラフィックのエンドポイント。FC標準では、N_PORTインターフェイスには、接続されているファブリックのトポロジーに応じて、いくつかのバリアントがあります。この仕様で使用されているように、この用語はバリアントのいずれかに適用されます。
b) FC Devices -- The fibre channel devices to which the N_PORTs provide access.
b) FCデバイス - N_PORTSがアクセスを提供するファイバーチャネルデバイス。
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_PORTS間にフレームトラフィックを運ぶためのネットワークインフラストラクチャ。
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.ファイバーチャネルネットワーク
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_ports。[fc-fs]では、ループ接続されたn_portsは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_PORT）は、L_PORTを介してループに接続され、FL_PORTを使用してファブリックにアクセスします。
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_port経由のfl_portを混合します
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_PORTは機能的に同一です。
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_PORTS間の通信のプロトコルは、ファブリックトポロジ、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-一般的なサービス。
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_PORTSとして表示されます。サービスリクエストは、N_PORT-to-N_PORT通信に標準のファイバーチャネルメカニズムを使用します。
All switched fabrics must provide the following services:
すべての切り替えられた生地は、次のサービスを提供する必要があります。
Fabric F_PORT server -- Services N_PORT requests to access the fabric for communications.
Fabric F_Port Server -Services 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がファブリックを終了または入力したときに他のFCデバイスに通知するための状態変更情報を提供します（セクション3.5を参照）。
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_PORTSがデータベースに情報を登録し、他のN_PORTに関する情報を取得し、セクション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.
ブロードキャストアドレス/サーバー - すべてのN_PORTSにシングルフレーム、クラス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_portsがあります。ノードとそのn_portsには、次の関連する識別子があります。
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について、セクション3.7.1で定義されているプロパティを備えた24ビットファブリックユニークアドレス。ファブリックアドレスは、フレームが送信されるアドレスです。
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].
Name Serverには、ファイバーチャネルデバイスがファブリックにその存在を登録し、他のデバイスの存在を発見できる登録およびクエリサービスを提供します。たとえば、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.
このフレームワーク内で、上層層プロトコルは、取引所によって運ばれるトランザクションの観点から定義されます。次に、各トランザクションはプロトコル情報ユニットで構成され、それぞれが交換内の個々のシーケンスによって運ばれます。
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_ports間のフレームをルーティングし、交換とシーケンスを管理するために必要な制御情報が含まれています。次の図は、フレームの概略図を示しています。
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.
ソースおよび宛先N_PORTファブリックは、S_IDおよびD_IDフィールドに埋め込まれたアドレスを、それぞれN_PORTSの発信および受信の物理アドレスを表します。
N_PORT fabric addresses are 24-bit values with the following format, defined by the fibre channel specification [FC-FS]:
N_PORTファブリックアドレスは、次の形式の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.
[FC-AL2]で説明されているループ初期化プロセス中に、ループアタッチされたNL_PORT（図3を参照）は、アドレスのポートIDコンポーネントを取得します。領域とドメインIDは、ファブリックログイン（flogi）が実行されると、ファブリックによって提供されます。
N_PORTs communicate by means of the following classes of service, which are specified in the fibre channel standard ([FC-FS]):
N_PORTSは、ファイバーチャネル標準（[FC-FS]）で指定されている次のクラスのサービスを使用して通信します。
Class 1 - A dedicated physical circuit connecting two N_PORTs.
クラス1- 2つのN_PORTを接続する専用の物理回路。
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 Datagramサービスに似ています。このクラスのサービスを使用したファイバーチャネルストレージデバイスは、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:
ログインプロセスは、N_PORTがファブリック、その他のN_PORTS、およびN_PORTを介してアクセスされるULP実装と通信するのに必要な動作環境を確立できるようにするFC-2操作です。3つのログイン操作がサポートされています。
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) Fabric Login（Flogi） - N_PORTがファブリックにその存在を登録し、サポートされているサービスのクラスなどのファブリックパラメーターを取得し、N_PORTアドレスを受け取る操作、N_PORTアドレスを受け取ります。
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） - ファイバーチャネルSCSIマッピングであるFCP-2などの特定のFC-4 ULPに関連するプロセス間通信を確立する操作。
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アドレスは揮発性であるため、N_PORTはログイン（PLOGI）操作を発信するN_PORTが名前サーバークエリを実行して、リモートデバイスのファイバーチャネルアドレスを発見します。一般的なクエリタイプには、N_PORTの世界的な非公式名を使用して、PLOGIリクエストが送信される24ビット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コンポーネントとテクノロジーを置き換える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_portです。
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_PORTおよびファイバーチャネルデバイスで構成されています。
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.ファイバーチャネルネットワーク
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ファブリックの1つの例を図7に示します。ファブリックは、それぞれが単一のIFCPゲートウェイでアクセスする2つのゲートウェイ領域で構成されています。
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.
各ゲートウェイには、IPネットワークに添付するための2つの標準に準拠したf_portsと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_PORTSがファブリックに取り付けられたデバイスとして表示されます。逆に、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_portまたはさまざまなファイバーチャネルスイッチベンダーによって提供される独自のインターフェイスの1つをサポートする場合があります。この場合、ゲートウェイはゲートウェイ領域をIPネットワークに接続するボーダースイッチとして機能します。
FL_PORT -- An interface that provides fabric access for loop-attached fibre channel devices, as specified in [FC-FLA].
FL_PORT- [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_PORTSがループアタッチされたデバイスとして表示されます。
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.
a) ゲートウェイは、各N_PORTに1つのアドレスのみが1つしかないように、N_PORT 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_portペア間のすべての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:
TCP/IPネットワークを横断するN_PORTへのN_PORT通信は、ゲートウェイ内のIFCPレイヤーの介入を必要とします。これは次の操作で構成されています。
a) Execution of the frame-addressing and -mapping functions described in Section 4.4.
a) セクション4.4で説明されているフレームアドレスおよびマッピング関数の実行。
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.
c) リモートデバイスに向けられたPLOGIに応じて、IFCPセッションの確立。
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_Ports間の通信透明性を実現するために使用される方法について説明します。
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.
IFCPファブリックは、[FC-FS]で指定されているように、クラス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) セクション3.3.1で説明されているファイバーチャネル名サーバーが提供するサービスをエミュレートします。これには、IFCPファブリック構成の変更を非同期的に通知するメカニズムが含まれます。
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.
固定されていないIFCPファブリックのゲートウェイは、セクション4.6で説明されているように、アドレス変換モードで動作します。このモードでは、N_PORTアドレスの範囲はゲートウェイ領域のローカルです。領域間のファイバーチャネルトラフィックの場合、フレーム埋め込まれた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 IDSを運ぶベンダーまたはユーザー固有のプロトコルおよびリンクサービスの実装もサポートする場合があります。フレームペイロード。
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.
N_portファイバーチャネルアドレスは、無制限のIFCPファブリックでは生地全体ではないため、ファイバーチャネルアドレスの割り当てによって課される制限は、ゲートウェイ領域内にのみ適用されます。地域全体で、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ファブリックでは、新しいゲートウェイ領域の追加など、障害または再構成によって引き起こされる再割り当てに対処します。さらに、新しいゲートウェイをファブリックにマージする前に、ISNSサーバーを、ドメインIDの発行を集中化するために、境界付きファブリックのISNSサーバーに奴隷にする必要があります。固定されていないIFCPファブリックでは、ISNSデータベースを調整するには、ISNSサーバーがクライアントの属性を互いに交換することのみが必要です。
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.
このセクションでは、セクション3.7.1のファイバーチャネルアドレス指定モデルへのIFCP拡張機能について説明します。これは、ローカルとリモートで接続されたN_portsの間のフレームの透明なルーティングに必要です。
In the iFCP protocol, an N_PORT is represented by the following addresses:
IFCPプロトコルでは、N_portは次のアドレスで表されます。
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_PORT ID。ローカルに接続されたデバイスのファイバーチャネルN_portアドレス。ゲートウェイアドレス指定モードに応じて、スコープは領域または境界のあるIFCPファブリックのいずれかにローカルです。どちらのモードでも、同じゲートウェイ領域のN_Ports間の通信がN_PORT 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_PORTを識別します。フレームトラフィックは、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_PORTSを識別します。
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ネットワークアドレスを表すファイバーチャネルアドレスの関連性を反映したIFCPセッション記述子（セクション5.2.2.2を参照）を維持する必要があります。この関連性を確立するために、IFCPゲートウェイは、次の段落で説明されているように、ファイバーチャネルN_portファブリックアドレスを割り当てて管理します。
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アドレスは、2つの方法のいずれかで割り当てられる場合があります。
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.
b) アドレス透過モード - n_portファイバーチャネルアドレスの範囲が、境界付きIFCPファブリックを含むゲートウェイ領域のセット全体で一意であるN_portアドレスの割り当てのモード。
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_PORTSへのアドレスの割り当てに協力します。セクション4.5.1で説明されているように、地域を制御する各ゲートウェイは、アドレス割り当て機関から一意のドメインIDを取得および配布する責任があります。したがって、境界のあるファブリックの範囲内で、各N_portのアドレスは一意です。そのため、リモートN_portsを表現するためには、ゲートウェイが割り当てられたエイリアスは必要ありません。
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ゲートウェイ自体。Gatewayは、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) 境界のある生地ごとに、ファブリックの各ゲートウェイを識別する世界的な名前が識別されます。アドレス透過モードのゲートウェイは、1つの境界布地のみに存在する必要があります。
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ゲートウェイは、カプセル化ヘッダーのIFCPフラグフィールドにTRPビットが1に設定されていないフレームを発生または受け入れてはなりません（セクション5.3.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_portsから送信および受信したフレームのフレームヘッダーに埋め込まれた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_PORT 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ネットワークから受信したインバウンドフレームの場合、受信ゲートウェイはセッション記述子を参照して、D_IDフィールドを宛先N_PORT IDとS_IDフィールドに割り当てたN_PORTエイリアスでS_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ゲートウェイは、カプセル化ヘッダーのIFCPフラグフィールドでTRPビットを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_PORTSとリモートで接続されたN_PORTS間でファイバーチャネルフレーム画像を輸送することです。
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_PORTログイン要求（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_PORTアドレスをその基準フレームに変換できるようにする追加情報でペイロードを補完する必要があります。
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_PORTSのペアで構成されています。N_PORTSの特定のペアの間には、1つのIFCPセッションが存在するものではありません。
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) IPアドレスとTCPポート番号で構成されるIFCPポータルアドレス。
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.
N_PORTSのペア間にIFCPセッションが1つだけ存在する可能性があるため、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接続は、「バインド」または「バウンド」のいずれかです。Unbound接続は、IFCPセッションを積極的にサポートしていないTCP接続です。ゲートウェイの実装は、セッションのセットアップ時間を短縮するために、バインドされていない接続のプールを確立する場合があります。IFCPポータル間のこのような既存のTCP接続は、CBINDメッセージを介してIFCPセッションに割り当てられるまで、UnboundとCommittedのままです（セクション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接続を確立し、CbindメッセージをTCP接続に送信する場合があります。これにより、その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.
n_port Worldwideユニークな名前-64ビットN_PORT WORLDWIDE NAME [FC-FS]で指定されています。リモート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ポータルアドレス - IFCPセッションに関連付けられたTCP接続の作成が要求されたときに参照されるIPアドレスとTCPポート番号が参照されます。
N_PORT ID -- N_PORT fibre channel address assigned to the remote device by the remote iFCP gateway.
N_PORT ID -N_PORTファイバーチャネルアドレスは、リモートIFCPゲートウェイによってリモートデバイスに割り当てられています。
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エイリアス-N_PORTファイバーチャネルアドレスは、アドレス変換モードで動作するときに「ローカル」IFCPゲートウェイによってリモートデバイスに割り当てられました。
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つの記述子が1つだけあります。記述子が存在しない場合、ISNS名サーバークエリによって返される情報を使用して作成されます。このようなクエリは次のとおりです。
a) a fibre channel Name Server request originated by a locally attached N_PORT (see Sections 3.5 and 9.3), or
a) 局所的に添付されたN_port（セクション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ペイロード内のソース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_PORTログインがないことです。その結果、古い記述子のために、このような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 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.
オープン保留-Gatewayが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.
接続が作成されると、セクション5.2.2.1で指定されているリモートN_port記述子を参照することにより、IPアドレスとTCPポート番号を取得するものとします。
c) If the TCP connection cannot be allocated or cannot be created due to limited resources, the gateway SHALL terminate session creation.
c) リソースが限られているためにTCP接続を割り当てることができない、または作成できない場合、ゲートウェイはセッションの作成を終了するものとします。
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.
d) IFCPセッションがオープン状態に入る前にTCP接続が何らかの理由で中止された場合、ゲートウェイはセクション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を参照）、セッションをオープン保留状態に配置するものとします。
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.
f) 「成功」または「IFCPセッションが既に存在する」以外のステータスでcbind応答が返される場合、セッションは終了し、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_ports間にIFCPセッションを作成するためにCBIND要求を同時に開始したことを示しています。このような応答を受信するゲートウェイは、この試みを終了し、セクション5.2.2.3に従って着信cbindリクエストを処理するものとします。
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:
セッションがオープン状態に配置されたら、図11に示す情報を含むIFCPセッション記述子を作成するものとします。
+-----------------------+
|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_PORT ID -N_PORT IDローカル接続されたファイバーチャネルデバイスのID。
Remote N_PORT ID -- N_PORT ID assigned to the remote device by the remote gateway.
リモートN_PORT 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.
a) 受信者が開いている保留状態で重複したIFCPセッションを持っている場合、受信ゲートウェイは、着信CBINDペイロードのソースN_PORT名を宛先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.
b) ソースN_port名が大きい場合、受信者は「成功」の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.
c) ソースN_PORT名が少ない場合、受信者は失敗した-N_PORTセッションのCBIND応答を発行するものとします。受信機が開始した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.
d) オープン保留状態で重複したIFCPセッションがない場合、受信ゲートウェイはCBIND応答を発行するものとします。成功のステータスが返された場合、受信ゲートウェイはIFCPセッションを作成し、オープン状態に配置するものとします。IFCPセッション記述子は、セクション5.2.2.2で説明されているように作成するものとします。
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.
e) リモートN_port記述子が存在しない場合、セクション5.2.2.1で説明されているように作成および埋められます。
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.
延長された不活性期間中、ゲートウェイ内のハードウェア障害またはTCP/IP接続の損失により、IFCPセッションが終了する場合があります。後者は、セッションが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で説明されているリテストメッセージを定期的に送信することを要求することによりセッションを監視することができます。すべてのIFCPゲートウェイは、この仕様に記載されているように、livenessテストをサポートするものとします。
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.
Gatewayは、セクション6.1で説明されているように、CBind要求または応答メッセージのlivenivesテスト間隔の非ゼロ値を指定することにより、Ltest Heartbeatを要求します。両方のゲートウェイが快適さを監視しようとする場合、それぞれがcbindリクエストまたは応答でlivening livensionテスト間隔を設定する必要があります。
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セッションがオープン状態に入るとすぐに送信されます。IFCPセッションがオープン状態にない場合、LTESTメッセージは送信されません。
An iFCP session SHALL be terminated as described in Section 5.2.3 if:
IFCPセッションは、セクション5.2.3で説明されているように終了するものとします。
a) the contents of the LTEST message are incorrect, or
a) 最新のメッセージの内容は間違っています、または
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) 指定されたインターバルの2倍以内に、LTESTメッセージは受信されません。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メッセージを受信するゲートウェイは、セッションがオープン状態に配置されたときから、最初の予想されるリテストメッセージの間隔を測定するものとします。その後、間隔は、受信した最後のルテストメッセージに対して測定するものとします。
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.
livensionテストカバレッジを最大化するために、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
表1.オプションのTCP機能の使用
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レベルで同等のKeep Alive機能を実装できます。あるいは、セクション5.2.2.4で説明されているように、定期的なlivening liveningsテストメッセージを発行することができます。これらのより包括的なエンドツーエンドのメカニズムと[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要求が含まれています。ナグルアルゴリズムの伝送遅延により、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のイベントの1つに応じて終了するものとします。
+-------------------------------------------+---------------------+
| 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接続は、バインドを実行せずに接続リセット（RST）によって中止されます。それ以外の場合、イベントに続いて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) バインドされていないセッション制御メッセージを除き、すべての着信トラフィックを破棄します。
c) If an UNBIND message is received at any time, return a response in accordance with Section 6.2.
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で説明されているように、アンバインドセッション制御メッセージを発行します。
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.
e) Unbindメッセージが成功のステータスで完了した場合、TCP接続はいずれかのGatewayの裁量で開いたままであり、新しいIFCPセッションの作成を加速するために、Unbound接続のプールに保持される場合があります。
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).
何らかの理由でアンバインドが失敗した場合、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接続を自発的に閉じることができます。GatewayがTCPの緊密な動作で接続を終了する場合、Peer Gatewayは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デリミッターワード、FCフレーム（ファイバーチャネルCRCを含む）、およびEOFデリミッターワードで構成されています。ヘッダーと区切りの形式については、次のセクションで説明します。
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.
プロトコル＃カプセル化を使用してプロトコルを識別するProtocol＃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.
- バージョンを補完するバージョン。
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カプセル化ヘッダーとFCフレーム（SOFおよびEOFワードを含む）を32ビット語の単位のFCフレーム（SOFおよびEOFワードを含む）を含むFCカプセル化フレーム全体の長さが含まれます。
-Flags Ones complement of the Flags field.
- フラグフィールドを補完するものをフラッグします。
-Frame Length Ones complement of the Frame Length field.
- フレームの長さのフィールドを補完するフレーム長。
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.
LS_COMMAND_ACC IFCPによって処理される特別なリンクサービスACC応答については、LS_COMMAND_ACCフィールドには、ACCが適用されるLS_Commandのビット0〜7のコピーが含まれます。それ以外の場合、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
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のビット0-7およびビット8-15）：IFCPは、[encap]で指定されたSOFフィールドの次のサブセットを使用します。便利なため、これらを表3に再現します。権威あるエンコーディングは[akap]から取得する必要があります。
+-------+----------+
| FC | |
| SOF | SOF Code |
+-------+----------+
| SOFi2 | 0x2D |
| SOFn2 | 0x35 |
| SOFi3 | 0x2E |
| SOFn3 | 0x36 |
+-------+----------+
Table 3. Translation of FC SOF Values to SOF Field Contents
表3. FC SOF値のSOFフィールドの内容への翻訳
-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（Word Nのビット0-7および8-15）：IFCPは、[encap]で指定されたEOFフィールドの次のサブセットを使用します。便利なため、これらを表4に再現します。権威あるエンコーディングは[akap]から取得する必要があります。
+-------+----------+
| FC | |
| EOF | EOF Code |
+-------+----------+
| EOFn | 0x41 |
| EOFt | 0x42 |
+-------+----------+
Table 4. Translation of FC EOF Values to EOF Field Contents
表4. FC EOF値のEOFフィールドコンテンツへの翻訳
-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の場合、セクション7.3.1.7で説明されているように、IFCPセッションの作成はカプセル化の前にあります。セッションが作成されたら、フレームのカプセル化は次のように進行します。
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セッション記述子を検索するために参照するものとします（セクション5.2.2.2を参照）。IFCPセッション記述子が存在しない場合、フレームは破棄されます。
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.
IPネットワークでのカプセル化と転送用に提出されたフレームタイプには、表3にSOFデリミターの1つ、表4のEOFデリミターがあります。他の有効なフレームタイプは、適切なファイバーチャネル仕様で指定されているようにゲートウェイで内部で処理する必要があります。
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のエラー条件の1つが検出された場合、ゲートウェイはセクション5.2.3で指定されているようにエラーを処理するものとします。
+------------------------------+-------------------------+
| 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で説明されているように、フレーム伝播遅延を検証するものとします。伝播遅延が長すぎる場合、フレームは破棄されます。それ以外の場合、ゲートウェイは、カプセル化ヘッダーのSOFとEOFをチェックしなければなりません。表3にないSOFコードまたは表4にないEOFコードがある場合、フレームは破棄されます。
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) アドレス変換モードで操作する場合は、S_IDフィールドをフレームオリジネーターのN_PORTエイリアスに置き、D_IDをフレーム受信者のN_PORT 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で指定されたルールに従ってカプセル化および脱カプセル化するものとします。
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
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メッセージと応答は、N_portログインを特定のTCP接続にバインドし、IFCPセッションを確立するために使用されます。CBind要求メッセージでは、ソースと宛先N_PORTSが世界的なポート名によって識別されます。カプセル化ヘッダーのタイムスタンプワードは、リクエストおよび応答メッセージフレームでゼロに設定する必要があります。
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 Ver：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.
livensionゼロの場合は、受信間隔：ゲートウェイが指定された間隔で秒単位でltestメッセージを送信することを要求します。ゼロに設定されている場合、リテストメッセージは送信されません。
USER INFO: Contains any data desired by the requestor. This information MUST be echoed by the recipient in the CBIND response message.
ユーザー情報：requestorが望むデータが含まれています。この情報は、cbind応答メッセージの受信者が反映する必要があります。
SOURCE N_PORT NAME: The Worldwide Port Name (WWPN) of the N_PORT locally attached to the gateway originating the CBIND request.
ソースN_PORT名：CBINDリクエストを発信するゲートウェイにローカルに接続されているN_PORTの世界的なポート名（wwpn）。
DESTINATION N_PORT The Worldwide Port Name (WWPN) of the NAME: N_PORT locally attached to the gateway receiving the CBIND request.
宛先N_ポート名の世界的なポート名（wwpn）：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 Ver：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.
livensionゼロの場合は、ゲートウェイ間隔：cbind応答を受信することを要求します。ゼロの場合、リテストメッセージは送信されません。
USER INFO: Echoes the value received in the USER INFO field of the CBIND request message.
ユーザー情報：cbind要求メッセージのユーザー情報フィールドで受信された値をエコーします。
SOURCE N_PORT NAME: Contains the Worldwide Port Name (WWPN) of the N_PORT locally attached to the gateway issuing the CBIND request.
ソース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.
宛先N_PORTには、名前の世界的なポート名（WWPN）が含まれています。N_PORTは、CBIND応答を発行するゲートウェイにローカルに接続されています。
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
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.
バインドされていないメッセージは、接続の上に送信されます。カプセル化ヘッダーのタイムスタンプワードは、リクエストおよび応答メッセージフレームでゼロに設定する必要があります。
The following is the format of the UNBIND request message.
以下は、バインドリクエストメッセージの形式です。
+------+------------+------------+-----------+----------+
| 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.
ユーザー情報には、リクエスターが望むデータが含まれています。この情報は、アンバインド応答メッセージの受信者が反映する必要があります。
CONNECTION HANDLE: Contains the gateway-assigned value from the CBIND request.
接続ハンドル：cbindリクエストからゲートウェイ割り当ての値が含まれています。
The following shows the format of the UNBIND response message.
以下は、Unbind Responseメッセージの形式を示しています。
+------+------------+------------+-----------+----------+
| 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 Requestメッセージのユーザー情報フィールドで受信された値をエコーします。
CONNECTION HANDLE: Echoes the CONNECTION HANDLE specified in the UNBIND request message.
接続ハンドル：Unbind Requestメッセージで指定された接続ハンドルをエコーします。
UNBIND STATUS: Indicates the success or failure of the UNBIND request as follows:
バインドステータス：次のように、アンバインドリクエストの成功または失敗を示します。
Unbind Status Description
------------- -----------
0 Successful - No other status 1 - 15 Reserved 16 Failed - Unspecified Reason 18 Failed - Connection ID Invalid Others Reserved
0成功 - 他のステータスなし1-15予約済み16失敗 - 不特定の理由18失敗 - 接続IDが無効なその他
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リクエストまたは応答ペイロードで指定された間隔で送信されます。ラテストカプセル化のタイムスタンプは、セクション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.
livension livension test interval intervalのliveningsテストコピー：cbind要求または返信メッセージで指定されています。
COUNT: Monotonically increasing value, initialized to 0 and incremented by one for each successive LTEST message.
カウント：単調に増加する値は、連続する最新メッセージごとに0に初期化され、1つずつ増加します。
SOURCE N_PORT NAME: Contains a copy of the SOURCE N_PORT NAME specified in the CBIND request.
ソースN_PORT名：CBINDリクエストで指定されたソースN_PORT名のコピーが含まれています。
DESTINATION N_PORT Contains a copy of the DESTINATION N_PORT NAME: NAME specified in the CBIND request.
宛先N_PORTには、宛先N_PORT名のコピーが含まれています：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.
Link Servicesは、ポートが制御情報を送信できるか、特定の制御関数を実行するように別のポートを要求できるファイバーチャネル関数のセットを提供します。
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) Special-リンクサービスの返信またはリクエストに適用され、IFCPレイヤーの介入を要求するリクエストは、宛先N_PORTに転送する前に介入します。このようなメッセージには、ペイロード内のファイバーチャネルアドレスが含まれている場合や、他の特別な処理が必要になる場合があります。
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.
このようなメッセージは、拡張リンクサービスについては図18に示す形式を使用して、ファイバーチャネルフレームで送信され、FC-4リンクサービスの図19に送信されます。
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
図19. FC-4リンクサービスフレームの形式
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_PORTアドレスを受信ゲートウェイのアドレススペースの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.
0x00 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
0x00 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.
0x00 00 03 -IPネットワークからフレームを受信するゲートウェイは、指定された補足データを参照してフィールドの内容を設定する必要があります。補足情報は、ファイバーチャネル仕様[FC-FS]に記載されているように、N_PORTの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.
ファイバーチャネルアドレス指定ルールは、ドメインIDが0のファブリックアドレスの割り当てを禁止するため、上記のコードは有効なN_PORTファブリック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_port識別子）に設定されます。
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_portアドレスに置き換えるものとします。
+------------------+------------------------------------+
| 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の場合、受信ゲートウェイは、指定されたN_PORTワールドワイド識別子をゲートウェイIPアドレスとN_PORT IDに変換することにより、リンクサービスフレームペイロードのフィールドに記入するために必要な情報を取得するものとします。この情報は、ISNS名サーバークエリを介して取得する必要があります。クエリが失敗した場合、ゲートウェイは[FC-FS]で説明されているように、LS_RJT応答メッセージでリクエストを終了するものとします。理由コードは0x07（プロトコルエラー）に設定され、理由の説明は0x1F（無効なN_port識別子）に設定されます。
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で指定されているように、カプセル化ヘッダーのIFCPフラグフィールドのSPCビットを1に設定する必要があります。ACCリンクサービスの応答に特別な処理が必要な場合、応答するゲートウェイは、ACCカプセル化ヘッダーのLS_Command_ACCフィールドに、LS_Command Bits 0から7のコピーをリンクサービス要求フレームから配置するものとします。補足データ（ある場合）は、次のセクションで説明されているように追加する必要があります。
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:
ELS形式：
+------+------------+------------+-----------+----------+
| 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
Exchange Originator 1、2 N/A S_ID
Other Special Processing:
その他の特別な処理：
None.
なし。
Format of ADISC ELS:
Adisc Elsの形式：
+------+------------+------------+-----------+----------+
| 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
ELS 1 N/A Originatorの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 acc elsの形式：
+------+------------+------------+-----------+----------+
| 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
ELS 1 N/A Originatorの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は、FARP-REQ ELS（セクション7.3.1.5を参照）と組み合わせて使用され、FC-VIプロトコル[FC-VI]に必要なアドレス解像度サービスと、指定されたIPおよびARPのファイバーチャネルマッピングを実行します。RFC 2625 [RFC2625]。
Format of FARP-REPLY ELS:
FARP-REPLY ELSの形式：
+------+------------+------------+-----------+----------+
| 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-VIプロトコル[FC-VI]およびRFC 2625 [RFC2625]のIP-FCマッピングと組み合わせて使用され、FCファブリックの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 ELSの形式：
+------+------------+------------+-----------+----------+
| 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
Responding N_PORT 3 Responding N_PORT
Identifier Port Name
Other Special Processing:
None.
なし。
ELS Format:
ELS形式：
+------+------------+------------+-----------+----------+
| 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.
このELは、有効な翻訳モードに関係なく、常に特別なELとして送信されます。
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は、2つのN_ports間のファイバーチャネル通信を確立し、存在しない場合は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がログイン要求を受け入れる場合、その機能を指定するAccept Response（PlogiペイロードのACCフレーム）が送信されます。この交換は、2つのN_PORTSの動作環境を確立します。
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]から複製されており、リクエストと受け入れ（ACC）応答の両方のPlogiメッセージ形式を示しています。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
図21. PlogiリクエストとACCペイロードの形式
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で指定されているように、リモートに添付されたN_PORTに宛てられたPLOGIリクエストは、存在しない場合はIFCPセッションの作成を引き起こす必要があります。それ以外の場合、既存のIFCPセッションを使用して、宛先N_portに変更せずに、PlogiおよびPlogi ACCペイロードを通過する必要があります。どちらの場合でも、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
表8. CBIND障害の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
Exchange Originator 1、2、または3つのポート名S_ID Exchange Originatorの名前
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つの単語で拡張されなければなりません。Originatorアドレス識別子またはレスポンダーアドレス識別子の翻訳タイプが1または2の場合、対応する8バイトポート名はすべてのゼロに設定されます。
Other Special Processing:
その他の特別な処理：
None.
なし。
ELS Format:
ELS形式：
+------+------------+------------+-----------+----------+
| 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
Exchange Originator 1、2、または3つのポート名S_ID Exchange Originatorの名前
Other Special Processing:
その他の特別な処理：
None.
なし。
Format of ELS Accept Response:
ELSの形式は応答を受け入れます。
+------+------------+------------+-----------+----------+
| 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
N_PORT ID Exchange OriginatorのExchange Originator1、2、または3ポート名
Exchange Responder 1, 2, or 3 Port Name of the N_PORT ID Exchange Responder
N_PORT ID Exchange ResponderのResponder1、2、または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語で拡張されなければなりません。Exchange Originator N_Port IDまたはExchange Responder N_Port IDの翻訳タイプが1または2の場合、対応する8バイトポート名はすべてのゼロに設定されます。
Other Special Processing:
その他の特別な処理：
None.
なし。
ELS Format:
ELS形式：
+------+------------+------------+-----------+----------+
| 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_port識別子1、2、または3ポート名N_portの名前
Other Special Processing:
その他の特別な処理：
None.
なし。
ELS Format:
ELS形式：
+------+------------+------------+-----------+----------+
| 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
Exchange Originator 1、2、または3つのポート名S_ID Exchange Originatorの名前
Other Special Processing:
その他の特別な処理：
None.
なし。
ELS Format:
ELS形式：
+------+------------+------------+-----------+----------+
| 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
Exchange Originator 1または2 N/A S_ID
Other Special Processing:
その他の特別な処理：
None.
なし。
ELS Format:
ELS形式：
+------+------------+------------+-----------+----------+
| 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
Exchange Originator 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:
ELS形式：
+------+------------+------------+-----------+----------+
| 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
アドレス識別子3 fl_portの世界的な名前リモートfl_port
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フィールドは、リモートループに関連付けられたドメインコントローラーのアドレスです。ドメインコントローラーアドレスの形式は、hex '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.
フラグフィールドは、SRLの範囲を定義します。0に設定すると、指定されたスイッチ要素またはゲートウェイのすべてのループポートインターフェイスがスキャンされます。1に設定する場合、スキャンするゲートウェイまたはスイッチ要素のループポートインターフェイスをビット8〜31で指定する必要があります。
If the Flag field is zero, the SRL request SHALL NOT be sent as a special ELS.
フラグフィールドがゼロの場合、SRL要求は特別なELとして送信されません。
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セッションを作成するものとします。
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_PORTとコマンドで指定されたその他のN_PORTの間に存在する1つ以上のプロセスログインセッションを削除するメカニズムを提供します。このコマンドには、1つ以上のTPRLOログアウトパラメーターページが含まれます。それぞれが、宛先N_PORTと組み合わせると、コマンドによって終了するプロセスログインを識別します。
+--------+------------+--------------------+----------------------+
| 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
図22. TPRLO ELSの形式
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プロトコルタイプに共通する単一のFC-4プロトコルタイプに関連付けられている可能性があります。アドレス変換を必要とするTPRLOページの形式を図23に示します。TPRLOの追加情報は[FC-FS]にあります。
+------+------------+------------+-----------+----------+
| 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
図23.拡張されたTPRLOパラメーターページの形式
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_PORTのすべての画像ペアが無効になることを示しています。このビットの値が1つの場合、TPRLOペイロードで許可されているログアウトパラメーターページは1つだけです。
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は特別なELとして送信されません。
Otherwise, the originating gateway SHALL process the ELS as follows:
それ以外の場合、発生するゲートウェイは次のようにELを処理するものとします。
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.
b) 図23に示すように、各TPRLOパラメーターページは2つの単語で拡張されなければなりません。
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.
c) Word 0、Bit 18（サードパーティオリジネーターN_PORT IDの有効性）の場合、TPRLOフラグフィールドのフィールドには1つの値があります。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オリジネーターは、ELSを含む各拡張フレームのカプセル化ヘッダーにSPCビットを設定するものとします（セクション5.3.1を参照）。
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.
e) ELSに単一のTPRLOパラメーターページが含まれている場合、オリジネーターは、拡張パラメーターページを含めるために必要に応じてフレーム長を増やすものとします。
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.
f) 拡張されるELSに複数のTPRLOパラメーターページが含まれている場合、拡張されたELSペイロードを含むように作成されたFCフレームは、宛先N_PORTで受け入れられる最大フレームサイズを超えてはなりません。
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ページの拡張に起因する新しいフレームは、Fiberチャネルフレームヘッダーに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ペイロードのワード0をコピーして、次のように各拡張パラメーターページの処理を行うことにより、宛先N_portに送信されるELSフレームを生成するものとします。
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.
a) 単語0、ビット18の値が1の場合、拡張パラメーターページのワード0〜2をコピーしてパラメーターページを作成します。Word 3のサードパーティオリジネーターN_Port 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.
b) 単語0、ビット18の値がゼロの場合、拡張パラメーターページの単語0〜3をコピーしてパラメーターページを作成します。
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が受け入れることができる最大フレームサイズを超えてはなりません。各フレームヘッダーのシーケンス識別子は、拡張されたELからコピーされ、シーケンスカウントが単調に増加するものとします。
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
図24. TPRLO ACC ELSの形式
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.
ファイバーチャネルプロトコルエラー条件からの回復には、交換リソースを安全に再利用する前に、ファブリックからの故障または中止された交換排水に関連付けられたフレームが必要です。
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 x 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.
IFCPゲートウェイは、セクション8.2.1で説明されているように、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_PORTSの送信および受信のゲートウェイ領域を介した伝播遅延の手当に加えて、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互換タイムサーバーのアドレスを取得する必要があります。複数の時間サーバーアドレスがクエリによって返される場合、サーバーは同期し、ゲートウェイはリスト内の任意のサーバーを使用する必要があります。または、サーバーは、Anycastモードでの操作をサポートするマルチキャストグループアドレスを返すことができます。Anycastモードの実装は、[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サーバーとゲートウェイ時間ベースの安定性は、100 ppm以上でなければなりません。
With regard to its time base, the gateway is in either the Synchronized or Unsynchronized state.
その時間帯に関しては、ゲートウェイは同期された状態または非シヌーナイズされていない状態にあります。
When in the synchronized state, the gateway 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;
b) セクション5.3.4で説明されているように、カプセル化ヘッダー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;
c) 着信フレームのタイムスタンプは0,0で、0,0のタイムスタンプを必要とするセッション制御フレームの1つではない場合（セクション6を参照）、フレームは破棄されます。
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％を超える場合、ゲートウェイは非シヌクロ化状態に入ることをお勧めします。（すべてのタイマーの精度が100 ppmで、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-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で説明されているように、[FC-FS]で指定された以下のELSをサポートするものとします。
a) Request for fabric service parameters (FDISC).
a) ファブリックサービスパラメーター（FDISC）のリクエスト。
b) Request for the link error status (RLS).
b) リンクエラーステータス（RLS）のリクエスト。
c) Read Fabric Timeout Values (RTV).
c) ファブリックタイムアウト値（RTV）を読み取ります。
The Fabric Controller SHALL support the following ELSs as specified in [FC-FS]:
ファブリックコントローラーは、[FC-FS]で指定されている次のELSをサポートするものとします。
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_PORTSの情報をデータベースに記録またはクエリできるようにする登録サービスを提供します。サービスは[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ディスカバリードメイン。Discoveryドメインには、グローバルブロードキャストサーバーとサポートするローカルサーバーのセットが入力されています。
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ポータルアドレスと、FCブロードキャストサーバー（0xFF-FF-FF）の有名なファイバーチャネルアドレスに設定されたN_PORT IDで構成されるN_PORTネットワークアドレスがあります。
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_PORTは、Fiber Channel Broadcast Serverにフレームトラフィックを向けることにより、ブロードキャストを発信します。Gateway-Resident Local Serverは、フレームのコピーをローカルに配布し、他のゲートウェイのローカルサーバーに再分配するためにグローバルサーバーにコピーを転送します。グローバルサーバーは、ブロードキャストフレームを発信するローカルサーバーにエコーしてはなりません。
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) 管理インターフェイスを使用して、各ブロードキャストサーバーは、ブロードキャストドメインのIDとともにプリセットされます。
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) サーバーは、属性によってISNS名サーバーを照会して、グローバルブロードキャストサービスを提供するために事前に構成されたN_PORTの世界的なポート名を取得するものとします。
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_PORTSのグローバルブロードキャスト関数を実行してはなりません。
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セッションを開始することにより、状態変更通知を受け取り、応答します。ゲートウェイは、Lossless Deliveryの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 10.3 describes the resulting design choices, their requirement levels, and how they apply to the iFCP protocol.
IFCPは、データの機密性と認証サービスを提供するためにIPSECプロトコルスイートに依存しており、IKEにキー管理プロトコルとして依存しています。セクション10.2では、IFCPの動作環境から生じるセキュリティ要件について説明し、セクション10.3では、結果の設計の選択、要件レベル、およびIFCPプロトコルへの適用方法について説明します。
Detailed considerations for use of IPsec and IKE with the iFCP protocol can be found in [SECIPS].
IFCPプロトコルを使用したIPSECおよびIKEの使用に関する詳細な考慮事項は、[SECIP]に記載されています。
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対サンへの接続をサポートするために、セキュリティゲートウェイを通過する必要がある場合があります。
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 IDは、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]で説明されている再キーイングシナリオでは、10 gbpsレートで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.
Basic Access Controlプロパティは、IFCP交換に参加する前に、1つ以上のISNSサーバーに対して2つの通信IFCPゲートウェイが知られているという要件に起因します。ディスカバリードメイン[ISNS]、IDペイロード（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ポータル解像度が必要です。管理者は、管理インターフェイスまたはISNとの適切に保護された対話を通じて、セキュリティポリシーを制御することができます。
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).
ISNS [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]インターネットセキュリティ協会と主要な管理プロトコル（ISAKMP）
[RFC2409] The Internet Key Exchange (IKE)
[RFC2409]インターネットキーエクスチェンジ（IKE）
[RFC2410] The NULL Encryption Algorithm and Its Use With IPSEC
[RFC2410]ヌル暗号化アルゴリズムと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.
セキュリティペイロード（ESP）[RFC2406]をカプセル化するIPのサポートは、実装するのに必須です。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 [RFC2404]を使用したHMACを実装する必要があり、拡張された暗号ブロックチェーンを備えたCBC MACモードの高度な暗号化標準[AES]を[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]の3DEを実装する必要があり、AESカウンターモード暗号化[AESCTR]を実装する必要があります。[RFC2410]で定義されているように、ヌル暗号化もサポートする必要があります。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プロトコルの実装は、トンネルモード[RFC2401]でIPSEC ESP [RFC2406]を実装し、輸送モードで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.
Phase-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メインモードを事前に共有キーと組み合わせて使用しないでください。このシナリオでは、代わりに積極的なモードを使用する必要があります。[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またはID_IPV6_ADDR識別タイプの値のいずれかを使用する必要があります（IPサポートのバージョンによる）。その他の識別タイプの値を使用しないでください。セクション5.2.2で説明したように、IFCPセッションを作成するゲートウェイは、ISNSサーバーを照会して、関連するTCP接続を開始する適切なポートを決定する必要があります。IKEフェーズ2の交換が成功すると、IKEレスポンダーはIPSEC SASでネゴシエートされたセレクターを実施します。その後のIFCPセッションの作成では、IFCPピアがアクセス制御のためにISNSサーバーを照会する必要があります（セクション5.2.2.1で指定されたセッション作成要件に従って）。
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ポータルは、1つ以上のIKE Phase-1セキュリティ協会（SAS）をピアIFCPポータルに確立することができます。IFCPポータルが初期化されている場合、またはセキュリティ要件との最初の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 Phase-2 SAは、同じIFCPポータル内の1つ以上のTCP接続を保護します。より具体的には、IKE Phase-2 SAの確立が成功すると、Tuple <SPI、宛先IPアドレス、ESP>によって完全に適格になった2つの単方向IPSEC SASが作成されます。
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接続の数、およびSASの数は、セキュリティポリシーの考慮事項（つまり、セキュリティサービスは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 Phase-1 SASが存在します、
-- each IKE Phase-1 SA has 0..N IKE Phase-2 SAs, and
- 各IKE Phase-1 SAには0..n IKE Phase-2 SASがあり、
-- each IKE Phase-2 SA protects 0..Z TCP connections.
- 各IKE Phase-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 Phase-2 SAの作成は、管理インターフェイスを介して提供されるポリシールールまたはISNSサーバーに登録されたIFCPポータルプロパティによってトリガーされる場合があります。同様に、完全なフォワードの秘密のためにクイックモードでキーエクスチェンジペイロードを使用することは、管理インターフェイスまたはISNSサーバーに登録されたIFCPポータルポリシールールによって決定される場合があります。
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実装がUnbound TCP接続を使用し、そのような接続がセキュリティ要件を備えたIFCPポータルに属している場合、バインドされた接続と同じように、常に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 Phase-2削除メッセージを受信すると、保護されたTCP接続を終了するか、関連するIKE Phase-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 SASの数を最小限に抑えるために、IKE Phase-2削除メッセージは、TCP接続がしばらくデータトラフィックを処理していないフェーズ2 SASに対して送信される場合があります。関連する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にバインドされる場合があります。機械証明書の値は、攻撃者が誤ったふりをして容易に容易になることに反比例するため、マシン証明書の登録プロセスを厳密に制御することをお勧めします。たとえば、管理者のみがマシン証明書を使用してマシンを登録する機能を持つ場合があります。IFCPセッションを保護するSASの確立のために、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) ISAKMP証明書リクエストペイロード（CRP）[RFC2408]を使用して、ピアIFCPゲートウェイから直接証明書を要求します。
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.
証明書チェーンが十分に長い場合、IKEはUDPを基礎となる輸送として使用してIPフラグメントを生成する可能性があり、介在するルーター、ファイアウォール、およびNa（P）Tボックスで不十分に機能することが知られています。その結果、エンドポイントは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はドメイン内の使用に最も適しています。断片化問題の既知のソリューションには、チェーンではなくエンドエントリマシン証明書を送信すること、証明書チェーンのサイズを縮小すること、PATH MTU発見とブラックに対するコードによって支援された信頼できる輸送プロトコル（例：TCP）を使用して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実装は、発見および管理サービスにISNを使用する必要があります。その結果、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ゲートウェイのセキュリティを提供するには、IFCPゲートウェイではトンネルモードのIPSEC ESPプロトコルをサポートする必要があります。ISNSセキュリティの実装要件のさらなる議論は、[ISNS]にあります。ISNSセキュリティ要件は、セクション10.3で説明したIFCPのセキュリティ要件と一致することに注意してください。
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ポータルのセキュリティメカニズムを無効にすることができる場合があります。結果として、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セキュリティポリシーは、IFCPゲートウェイが[ISNS]で説明されているように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領域全体で、ゲートウェイからゲートウェイへのゲートウェイへのゲートウェイを正しく通信するものとします。ただし、このようなゲートウェイツーゲートウェイ通信が実行されるタイミングは、BER、パケット損失、レイテンシ、およびジッターがベストエフォルトIP領域全体で経験するジッターに大きく依存します。これらのパラメーターが高いほど、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] QO、および
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）をロードできます。MPLSと差別化されたサービスとの相補性と互換性は、[MPSLDS]で検討され、PHBビットがMPLSシムヘッダーのEXPビットにコピーされます。
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 service contract are expected to be non-technical and thus are outside of the IETF scope.
最も一般的な定義では、2つのIFCPゲートウェイが、上記のQoSソリューションの一部を実装する1つまたは複数の独立した管理されたIP領域によって区切られています。QOS対応IP地域は、地域を通じて転送サービスを指定するサービス契約の交渉と確立をサポートします。このような契約および交渉規則は、この文書の範囲外です。DiffServ QOSを持つIP領域の場合、リーダーはサービスレベル仕様（SLS）およびトラフィックコンディショニング仕様（TCS）（[difterm]で定義）を参照する必要があります。サービス契約の他の側面は非技術的であると予想されるため、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技術に応じて、転送サービスの規定には、入場制御や帯域幅ブローカーなどのネットワーク補助機能との相互作用が必要になる場合があります（IP領域が受け入れる可能性のあるRSVPまたはその他のシグナル伝達プロトコルを介して）。
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セッションの1つ、複数、またはすべてのIPリージョンを使用して転送サービスを交渉する場合があります。あるいは、この責任は、下流のノードに委任される場合があります。1つのTCP接続は各IFCPセッション専用であるため、個々のN_PORTからN_PORTセッションのトラフィックは、IFCP-Unawareネットワーク機器によってもシングルアウトできます。
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領域は、EF DSCPをIFCPトラフィックに適用することにより、この性質のSLSをサポートする場合があります。
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ポータルは、各ポート番号が一意である場合、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。、「IPSECがセキュリティペイロードをカプセル化した高度な暗号化標準（AES）カウンターモード（ESP）を使用して」、RFC 3686、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] Weber、R.、Rajagopal、M.、Travostino、F.、O'Donnell、M.、Monia、C。、およびM. Merhar、「Fiber Channel（FC）Frame Capsulation」、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）、Rev 1.70、Incits Project 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）」、Revision 7.01、Incits Project 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] DPANS X3.XXX-2000X、「ファイバーチャネルスイッチファブリック-2（FC-SW2）」、リビジョン5.2、2001年5月、プロジェクト1305-Dをインストール
[FCP-2] dpANS T10, "Fibre Channel Protocol for SCSI, Second Version", revision 8, INCITS Project 1144D, September 2002
[FCP-2] DPANS T10、「SCSIのファイバーチャネルプロトコル、2番目のバージョン」、リビジョン8、2002年9月プロジェクト1144D
[ISNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171, September 2005.
[ISNS] Tseng、J.、Gibbons、K.、Travostino、F.、Du Laney、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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. Glenn、「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] Kent、S。およびR. Atkinson、「IPカプセンシングセキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, N.
[RFC2407] Piper、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] Maughan、D.、Schertler、M.、Schneider、M.、およびJ. Turner、「Internet Security Association and Key Management Protocol（ISAKMP）」、RFC 2408、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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] Glenn、R。、およびS. Kent、「Null暗号化アルゴリズムとIPSECでの使用」、RFC 2410、1998年11月。
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451] Pereira、R。およびR. Adams、「ESP CBC-Mode Cipher Algorithms」、RFC 2451、1998年11月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、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.
[Secips] Aboba、B.、Tseng、J.、Walker、J.、Rangan、V。、およびF. Travostino、「IPを介したブロックストレージプロトコルの保護」、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 Publication XXX、「Advanced Encryption Standard（AES）」、Draft、2001、http：//csrc.nist.gov/publications/drafts/dfips-aes.pdfから入手可能
[DIFTERM] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[Difterm] Grossman、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-AL-2）」、Revision 7.0、NCITS Project 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 Project 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。、「The Fiber Channel Consultant、Arbitrated Loop」、Robert W. Kembel、Northwest Learning Associates、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。、「ファイバーチャネル、包括的な紹介」、Northwest Learning Associates Inc.、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] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P.、およびJ. Heinanen、 "Multi-protocolラベルスイッチング（MPLS）差別化されたサービスのサポート」、RFC 3270、2002年5月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、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] Jacobson、V.、Braden、R。、およびD. Borman、「高性能のための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] Braden、R.、Clark、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] Mills、D。、「IPv4、IPv6およびOSI用のSimple Network Time Protocol（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、「ESP Des-CBC暗号アルゴリズムを備えたIVを備えた」、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「Distementiated Serviceの建築」、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. Rickard、「IP and ARP Over Fiber Channel」、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] Lahey、K。、「Path MTU DiscoveryのTCP問題」、RFC 2923、2000年9月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC896] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.
[RFC896] Nagle、J。、「IP/TCPインターネットワークスの混雑制御」、RFC 896、1984年1月。
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プロトコルに固有のリンクサービスの名前は、プロトコルを識別するニーモニックによって包括されています。
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)
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
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
Table 10. Pass-Through Link Services
表10.パススルーリンクサービス
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
Table 11. Special Link Services
表11.特別なリンクサービス
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_PORTパブリックループインターフェイスを実装します。
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セッションで送信してはなりません。
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_portアドレス識別子を表すエイリアスを提供する必要があります。
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_PORTアドレス識別子はどちらも、LINITおよびSRL拡張リンクサービスメッセージに含まれるリモートループ管理リクエストにサービスを提供するN_PORTを表します。これらのメッセージをサポートするために、ゲートウェイはNL_PORTエイリアスを割り当てる必要があります。これにより、LFAまたはFL_PORTアドレス識別子の対応するエイリアスを導き出すことができます。
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).
著者は、資料を提供し、David Black（EMC）、Rory Bolt（Quantum/ATL）、Victor Firoiu（Nortel）、Robert Peglar（Xiotech）、David Robinsonなどのこの仕様を慎重にレビューして批評するために時間をかけた人々に感謝しています。（Sun）、Elizabeth Rodriguez、Joshua Tseng（Nishan）、Naoke Watanabe（HDS）、およびIPSワーキンググループのメンバー。IFCPセキュリティポリシーのレビューのために、著者はさらに、バーナードアボバ（Microsoft）、Ofer Biran（IBM）、Uri Elzer（Broadcom）、Charles Kunziger（IBM）を含むIPSセキュリティドキュメント[SECIPS]の著者にさらに感謝しています。、Venkat Rangan（Rhapsody Networks）、Julian Satran（IBM）、Joseph Tardo（Broadcom）、Jesse Walker（Intel）。
Author's Addresses
著者のアドレス
Comments should be sent to the ips mailing list (ips@ece.cmu.edu) or to the authors.
コメントは、IPSメーリングリスト（ips@ece.cmu.edu）または著者に送信する必要があります。
Charles Monia 7553 Morevern Circle San Jose, CA 95135
チャールズモニア7553モアバーンサークルサンノゼ、カリフォルニア95135
EMail: charles_monia@yahoo.com
Rod Mullendore McDATA 4555 Great America Pkwy Suite 301 Santa Clara, CA 95054
ロッド・マレンドア・マクダタ4555グレート・アメリカPKWYスイート301サンタクララ、カリフォルニア州95054
Phone: 408-519-3986 EMail: Rod.Mullendore@MCDATA.com
電話：408-519-3986メール：rod.mullendore@mcdata.com
Franco Travostino Nortel 600 Technology Park Drive Billerica, MA 01821 USA
Franco Travostino Nortel 600 Technology Park Drive Billerica、MA 01821 USA
Phone: 978-288-7708 EMail: travos@nortel.com
電話：978-288-7708メール：travos@nortel.com
Wayland Jeong TROIKA Networks, Inc. 2555 Townsgate Road, Suite 105 Westlake Village, CA 91361
Wayland Jeong Troika Networks、Inc。2555 Townsgate Road、Suite 105 Westlake Village、CA 91361
Phone: 805-371-1377 EMail: wayland@TroikaNetworks.com
電話：805-371-1377メール：wayland@troikanetworks.com
Mark Edwards Adaptec (UK) Ltd. 4th Floor, Howard House Queens Ave, UK. BS8 1SD
Mark Edwards Adaptec（UK）Ltd。4階、ハワードハウスクイーンズアベニュー、英国。BS8 1SD
Phone: +44 (0)117 930 9600
EMail: mark_edwards@adaptec.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。