Network Working Group M. Rajagopal
Request for Comments: 3821 E. Rodriguez
Category: Standards Track R. Weber
July 2004
Fibre Channel Over TCP/IP (FCIP)
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 (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks.
ファイバチャネルを介したTCP / IP（FCIP）は、IPベースのネットワーク上でファイバチャネルストレージエリアネットワークの島々の相互接続は、単一のファイバー・チャネル・ファブリックに統合ストレージ・エリア・ネットワークを形成することを可能にするメカニズムについて説明します。 FCIPは、ローカルエリアネットワーク、メトロポリタンエリアネットワーク、またはワイド・エリア・ネットワーク上のストレージ・エリア・ネットワークの島の間の接続性を提供するために、IPベースのネットワークサービスに依存しています。
Table Of Contents
目次
1. Purpose, Motivation, and Objectives. . . . . . . . . . . . . . 3
2. Relationship to Fibre Channel Standards. . . . . . . . . . . . 4
2.1. Relevant Fibre Channel Standards . . . . . . . . . . . . 4
2.2. This Specification and Fibre Channel Standards . . . . . 5
3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 7
5. The FCIP Model . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. FCIP Protocol Model. . . . . . . . . . . . . . . . . . . 9
5.2. FCIP Link. . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. FC Entity. . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. FCIP Entity. . . . . . . . . . . . . . . . . . . . . . . 12
5.5. FCIP Link Endpoint (FCIP_LEP). . . . . . . . . . . . . . 13
5.6. FCIP Data Engine (FCIP_DE) . . . . . . . . . . . . . . . 14
5.6.1. FCIP Encapsulation of FC Frames. . . . . . . . . 16
5.6.2. FCIP Data Engine Error Detection and Recovery. . 19
6. Checking FC Frame Transit Times in the IP Network. . . . . . . 22
7. The FCIP Special Frame (FSF) . . . . . . . . . . . . . . . . . 23
7.1. FCIP Special Frame Format. . . . . . . . . . . . . . . . 23
7.2. Overview of FSF Usage in Connection Establishment. . . . 26
8. TCP Connection Management. . . . . . . . . . . . . . . . . . . 28
8.1. TCP Connection Establishment . . . . . . . . . . . . . . 28
8.1.1. Connection Establishment Model . . . . . . . . . 28
8.1.2. Creating New TCP Connections . . . . . . . . . . 29
8.1.3. Processing Incoming TCP Connect Requests . . . . 32
8.1.4. Simultaneous Connection Establishment. . . . . . 36
8.2. Closing TCP Connections. . . . . . . . . . . . . . . . . 36
8.3. TCP Connection Parameters. . . . . . . . . . . . . . . . 36
8.3.1. TCP Selective Acknowledgement Option . . . . . . 36
8.3.2. TCP Window Scale Option. . . . . . . . . . . . . 36
8.3.3. Protection Against Sequence Number Wrap. . . . . 37
8.3.4. TCP_NODELAY Option . . . . . . . . . . . . . . . 37
8.4. TCP Connection Considerations. . . . . . . . . . . . . . 37
8.5. Flow Control Mapping between TCP and FC. . . . . . . . . 37
9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Threat Models. . . . . . . . . . . . . . . . . . . . . . 38
9.2. FC Fabric and IP Network Deployment Models . . . . . . . 40
9.3. FCIP Security Components . . . . . . . . . . . . . . . . 40
9.3.1. IPsec ESP Authentication and Confidentiality . . 40
9.3.2. Key Management . . . . . . . . . . . . . . . . . 41
9.3.3. ESP Replay Protection and Rekeying Issues. . . . 43
9.4. Secure FCIP Link Operation . . . . . . . . . . . . . . . 44
9.4.1. FCIP Link Initialization Steps . . . . . . . . . 44
9.4.2. TCP Connection Security Associations (SAs) . . . 44
9.4.3. Handling Data Integrity and Confidentiality
Violations . . . . . . . . . . . . . . . . . . . 45
10. Performance. . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1. Performance Considerations . . . . . . . . . . . . . . . 45
10.2. IP Quality of Service (QoS) Support. . . . . . . . . . . 46
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
11.1. Normative References . . . . . . . . . . . . . . . . . . 47
11.2. Informative References . . . . . . . . . . . . . . . . . 49
12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 50
Appendix A Fibre Channel Bit and Byte Numbering Guidance. . . . . 51
B IANA Considerations. . . . . . . . . . . . . . . . . . 51
C FCIP Usage of Addresses and Identifiers. . . . . . . . 52
D Example of synchronization Recovery Algorithm. . . . . 53
E Relationship between FCIP and IP over FC (IPFC). . . . 58
F FC Frame Format. . . . . . . . . . . . . . . . . . . . 59
G FC Encapsulation Format. . . . . . . . . . . . . . . . 61
H FCIP Requirements on an FC Entity. . . . . . . . . . . 63
Editors and Contributors Acknowledgements. . . . . . . . . . . . . 69
Editors and Contributors Addresses . . . . . . . . . . . . . . . . 70
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 74
Warning to Readers Familiar With Fibre Channel: Both Fibre Channel and IETF standards use the same byte transmission order. However, the bit and byte numbering is different. See appendix A for guidance.
ファイバチャネルに精通している読者への警告：ファイバチャネルとIETF標準の両方が同じバイト送信順序を使用します。しかし、ビットおよびバイトの番号が異なっています。指導のための付録Aを参照してください。
Fibre Channel (FC) is a gigabit or multi-gigabit speed networking technology primarily used to implement Storage Area Networks (SANs). See section 2 for information about how Fibre Channel is standardized and the relationship of this specification to Fibre Channel standards. An overview of Fibre Channel can be found in [34].
ファイバチャネル（FC）は、主にストレージエリアネットワーク（SAN）を実装するために使用されるギガビットまたはマルチギガビット高速ネットワーク技術です。ファイバチャネルが標準化された方法については、セクション2およびファイバチャネル規格にこの仕様の関係を参照してください。ファイバーチャネルの概要は、[34]に記載されています。
This specification describes mechanisms that allow the interconnection of islands of Fibre Channel SANs over IP Networks to form a unified SAN in a single Fibre Channel fabric. The motivation behind defining these interconnection mechanisms is a desire to connect physically remote FC sites allowing remote disk access, tape backup, and live mirroring.
この仕様は、IPネットワーク上でファイバチャネルSANの島々の相互接続は、単一のファイバチャネルファブリックで統一SANを形成することを可能にするメカニズムについて説明します。これらの相互接続メカニズムを定義するの背後にある動機は、リモートディスクアクセス、テープバックアップ、およびライブミラーリングが可能に物理的に離れFCのサイトを接続したいです。
Fibre Channel standards have chosen nominal distances between switch elements that are less than the distances available in an IP Network. Since Fibre Channel and IP Networking technologies are compatible, it is logical to turn to IP Networking for extending the allowable distances between Fibre Channel switch elements.
ファイバチャネル規格は、IPネットワークで利用可能な距離よりも小さいスイッチ素子間の公称距離を選択しました。ファイバチャネルおよびIPネットワーキング技術に互換性があるので、ファイバチャネルスイッチ素子間の許容距離を拡張するためのIPネットワークに頼るのが論理的です。
The fundamental assumption made in this specification is that the Fibre Channel traffic is carried over the IP Network in such a manner that the Fibre Channel Fabric and all Fibre Channel devices on the Fabric are unaware of the presence of the IP Network. This means that the FC datagrams must be delivered in such time as to comply with existing Fibre Channel specifications. The FC traffic may span LANs, MANs, and WANs, so long as this fundamental assumption is adhered to.
この仕様で作られた基本的な前提は、ファイバチャネルトラフィックは、ファイバチャネルファブリックおよびファブリック上のすべてのファイバチャネルデバイスは、IPネットワークの存在に気づいていないように、IPネットワーク上で伝送されていることです。これは、FCデータグラムは、既存のファイバチャネル仕様に準拠するような時間に送達されなければならないことを意味しています。 FCトラフィックは限り、この基本的な前提が守られるよう、LANを、マン、およびWANにまたがることがあります。
The objectives of this document are to:
このドキュメントの目的は次のとおりです。
1) specify the encapsulation and mapping of Fibre Channel (FC) frames employing FC Frame Encapsulation [19].
1）FCフレームのカプセル化[19]を用いてフレームのファイバチャネル（FC）のカプセル化およびマッピングを指定します。
2) apply the mechanism described in 1) to an FC Fabric using an IP network as an interconnect between two or more islands in an FC Fabric.
2）FCファブリックの2つの以上のアイランド間の相互接続としてIPネットワークを使用してFCファブリックに）1に記載の機構を適用します。
3) address any FC concerns arising from tunneling FC traffic over an IP-based network, including security, data integrity (loss), congestion, and performance. This will be accomplished by utilizing the existing IETF-specified suite of protocols.
3）セキュリティ、データの整合性（損失）、輻輳、およびパフォーマンスを含む、IPベースのネットワークを介してFCトラフィックをトンネリングから生じるいかなるFCの懸念に対処。これは、プロトコルの既存のIETF指定のスイートを利用することによって達成されます。
4) be compatible with the referenced FC standards. While new work may be undertaken in T11 to optimize and enhance FC Fabrics, this specification REQUIRES conformance only to the referenced FC standards.
4）参照FC規格と互換性があります。新しい仕事はFCファブリックを最適化し、強化するためにT11に着手することができるが、この仕様は、参照のみFC規格への適合性を必要とします。
5) be compatible with all applicable IETF standards so that the IP Network used to extend an FC Fabric can be used concurrently for other reasonable purposes.
5）IPネットワークFCファブリックを拡張するために使用される他の合理的な目的のために同時に使用することができるように、該当するすべてのIETF標準規格と互換性があります。
The objectives of this document do not include using an IP Network as a replacement for the Fibre Channel Arbitrated Loop interconnect. No definition is provided for encapsulating loop primitive signals for transmission over an IP Network.
このドキュメントの目的は、ファイバチャネルアービトレーテッドループ相互接続のための代替としてIPネットワークを使用して含まれていません。何の定義がIPネットワークを介して送信するためのループプリミティブ信号をカプセル化するために提供されていません。
Conventions used in this document
この文書で使用されている表記
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 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[1]。
FC is standardized as a family of American National Standards developed by the T11 technical committee of INCITS (InterNational Committee for Information Technology Standards). T11 has specified a number of documents describing FC protocols, operations, and services. T11 documents of interest to readers of this specification include (but are not limited to):
FCは、INCITS（情報技術規格国際委員会）のT11技術委員会によって開発された米国規格の家族として標準化されています。 T11は、FCプロトコル、運用、およびサービスを記述する文書の数を指定しています。この仕様の読者への関心のT11文書が含まれます（ただし、これらに限定されません）。
- FC-BB - Fibre Channel Backbone [2] - FC-BB-2 - Fibre Channel Backbone -2 [3] - FC-SW-2 - Fibre Channel Switch Fabric -2 [4] - FC-FS - Fibre Channel Framing and Signaling [5]
- FC-BB - ファイバチャネルバックボーン[2] - FC-BB-2 - ファイバチャネルバックボーン-2 [3] - FC-SW-2 - ファイバチャネルスイッチファブリック-2 [4] - FC-FS - ファイバ・チャネル・フレーミングそしてシグナリング[5]
FC-BB and FC-BB-2 describe the relationship between an FC Fabric and interconnect technologies not defined by Fibre Channel standards (e.g., ATM and SONET). FC-BB-2 is the Fibre Channel document describing the relationships between FC and TCP/IP, including the FC use of FCIP.
FC-BBおよびFC-BB-2は、ファイバチャネル規格（例えば、ATM及びSONET）によって定義されていないFCファブリックとの相互接続技術との間の関係を記述する。 FC-BB-2は、FCIPのFCの使用を含むFCとTCP / IPの間の関係を記述するファイバ・チャネル・ドキュメントです。
FC-SW-2 describes the switch components of an FC Fabric and FC-FS describes the FC Frame format and basic control features of Fibre Channel.
FC-SW-2は、FCファブリックとFC-FSのスイッチコンポーネントは、ファイバチャネルのFCフレームフォーマットと基本的な制御機能を説明について説明します。
Additional information regarding T11 activities is available on the committee's web site www.t11.org.
T11の活動に関する追加情報は、委員会のウェブサイトwww.t11.orgで提供されています。
When considering the challenge of transporting FC Frames over an IP Network, it is logical to divide the standardization effort between TCP/IP requirements and Fibre Channel requirements. This specification covers the TCP/IP requirements for transporting FC Frames; the Fibre Channel documents described in section 2.1 cover the Fibre Channel requirements.
IPネットワーク上でFCフレームを輸送するという課題を考えるとき、TCP / IPの要件およびファイバチャネルの要件間の標準化作業を分割する論理的です。この仕様は、FCフレームを転送するためのTCP / IPの要件をカバー。 2.1節で説明したファイバチャネル文書は、ファイバチャネル要件をカバー。
This specification addresses only the requirements necessary to properly utilize an IP Network as a conduit for FC Frames. The result is a specification for an FCIP Entity (see section 5.4).
この仕様は、適切FCフレームのための導管としてIPネットワークを利用するために必要な唯一の要件に対応しています。結果は、FCIPエンティティの仕様（セクション5.4を参照）です。
A product that tunnels an FC Fabric through an IP Network MUST combine the FCIP Entity with an FC Entity (see section 5.3) using an implementation specific interface. The requirements placed on an FC Entity by this specification to achieve proper delivery of FC Frames are summarized in appendix H. More information about FC Entities can be found in the Fibre Channel standards and an example of an FC Entity can be found in FC-BB-2 [3].
IPネットワークを介してFCファブリックのトンネル生成物は、実装固有のインターフェースを使用して（セクション5.3を参照）FCエンティティとFCIPエンティティを結合しなければなりません。 FCフレームの適切な送達を達成するために、この仕様でFCエンティティに対する要求は、付録Hに要約されているFCエンティティの詳細については、ファイバチャネル規格で見つけることができるとFCエンティティの例は、FC-BBで見つけることができます-2 [3]。
No attempt is being made to define a specific API between an FCIP Entity and an FC Entity. The approach is to specify required functional interactions between an FCIP Entity and an FC Entity (both of which are required to forward FC frames across an IP Network), but allow implementers to choose how these interactions will be realized.
試みはFCIPエンティティとFCエンティティ間の特定のAPIを定義するために作らされていません。アプローチは、（IPネットワークを介してFCフレームを転送するために必要とされる両方とも）FCIPエンティティとFCエンティティとの間の必要な機能的相互作用を指定するが、実装者は、これらの相互作用が実現される方法を選択できるようにすることです。
Terms used to describe FCIP concepts are defined in this section.
FCIPの概念を記述するために使用される用語は、このセクションで定義されています。
FC End Node - An FC device that uses the connection services provided by the FC Fabric.
FCエンドノード - FCファブリックが提供する接続サービスを利用するFCデバイス。
FC Entity - The Fibre Channel specific functional component that combines with an FCIP Entity to form an interface between an FC Fabric and an IP Network (see section 5.3).
FCエンティティ - FCファブリックとIPネットワークとの間の界面を形成するFCIPエンティティと結合し、ファイバチャネルの特定の機能性成分は、（セクション5.3を参照します）。
FC Fabric - An entity that interconnects various Nx_Ports (see [5]) attached to it, and is capable of routing FC Frames using only the destination ID information in an FC Frame header (see appendix F).
FCファブリック - 各種Nx_Portsを相互接続するエンティティは、（付録Fを参照）、それに取り付けられた（[5]参照）、FCフレームヘッダ内の唯一の宛先ID情報を用いてFCフレームをルーティングすることが可能です。
FC Fabric Entity - A Fibre Channel specific element containing one or more Interconnect_Ports (see FC-SW-2 [4]) and one or more FC/FCIP Entity pairs. See FC-BB-2 [3] for details about FC Fabric Entities.
FCファブリックエンティティ - 一つ以上のInterconnect_Portsを含むファイバ・チャネルの特定の要素は、および1つまたは複数のFC / FCIPエンティティペア（FC-SW-2 [4]を参照します）。 FCファブリックエンティティの詳細については、[3] FC-BB-2を参照してください。
FC Frame - The basic unit of Fibre Channel data transfer (see appendix F).
FCフレーム - ファイバチャネルデータ転送の基本単位（付録Fを参照してください）。
FC Frame Receiver Portal - The access point through which an FC Frame and time stamp enter an FCIP Data Engine from the FC Entity.
FCフレームレシーバーポータル - FCフレームおよびタイムスタンプは、FCエンティティからFCIPデータエンジンを入力し、それを通してアクセスポイント。
FC Frame Transmitter Portal - The access point through which a reconstituted FC Frame and time stamp leave an FCIP Data Engine to the FC Entity.
FCフレームトランスミッタポータル - 再構成されたFCフレームおよびタイムスタンプは、FCエンティティにFCIPデータエンジンを残して、それを通してアクセスポイント。
FC/FCIP Entity pair - The combination of one FC Entity and one FCIP entity.
FC / FCIPエンティティ対 - オンFCエンティティと一つFCIPエンティティの組み合わせ。
FCIP Data Engine (FCIP_DE) - The component of an FCIP Entity that handles FC Frame encapsulation, de-encapsulation, and transmission FCIP Frames through a single TCP Connection (see section 5.6).
FCIPデータエンジン（FCIP_DE） - 単一のTCP接続を介してFCフレームのカプセル化、脱カプセル化し、送信FCIPフレームを処理するFCIPエンティティのコンポーネント（セクション5.6を参照）。
FCIP Entity - The entity responsible for the FCIP protocol exchanges on the IP Network and encompasses FCIP_LEP(s) and FCIP Control and Services module (see section 5.4).
FCIPエンティティ - IPネットワーク上のFCIPプロトコル交換を担当するエンティティとを包含するFCIP_LEP（S）とFCIP制御およびサービスモジュール（セクション5.4を参照します）。
FCIP Frame - An FC Frame plus the FC Frame Encapsulation [19] header, encoded SOF and encoded EOF that contains the FC Frame (see section 5.6.1).
FCIPフレーム - FCフレームプラスFCフレームのカプセル化[19]ヘッダー、FCフレームを含む符号化されたSOFとEOF符号化（セクション5.6.1を参照）。
FCIP Link - One or more TCP Connections that connect one FCIP_LEP to another (see section 5.2).
FCIPリンク - 別のFCIP_LEPを（5.2節を参照）を接続する1つのまたは複数のTCPコネクション。
FCIP Link Endpoint (FCIP_LEP) - The component of an FCIP Entity that handles a single FCIP Link and contains one or more FCIP_DEs (see section 5.5).
FCIPリンクのエンドポイント（FCIP_LEP） - 単一FCIPリンクを処理し、一つ以上のFCIP_DEs（セクション5.5を参照）が含まれていFCIPエンティティのコンポーネント。
Encapsulated Frame Receiver Portal - The TCP access point through which an FCIP Frame is received from the IP Network by an FCIP Data Engine.
カプセル化されたフレームレシーバーポータル - FCIPフレームがFCIPデータエンジンにより、IPネットワークから受信されてTCPアクセスポイント。
Encapsulated Frame Transmitter Portal - The TCP access point through which an FCIP Frame is transmitted to the IP Network by an FCIP Data Engine.
カプセル化されたフレームトランスミッタポータル - FCIPフレームがFCIPデータエンジンによってIPネットワークへ伝送されるTCPアクセスポイント。
FCIP Special Frame (FSF) - A specially formatted FC Frame containing information used by the FCIP protocol (see section 7).
FCIP特殊フレーム（FSF） - FCIPプロトコルによって使用される情報を含む、特別にフォーマットされたFCフレーム（セクション7参照）。
The FCIP protocol is summarized as follows:
次のようにFCIPプロトコルが要約されます。
1) The primary function of an FCIP Entity is forwarding FC Frames, employing FC Frame Encapsulation described in [19].
1）FCIPエンティティの主な機能は、[19]に記載のFCフレームのカプセル化を用いて、FCフレームを転送しています。
2) Viewed from the IP Network perspective, FCIP Entities are peers and communicate using TCP/IP. Each FCIP Entity contains one or more TCP endpoints in the IP-based network.
2）IPネットワークの観点から見ると、FCIPエンティティはピアであり、TCP / IPを使用して通信します。各FCIPエンティティは、IPベースのネットワーク内の1つまたは複数のTCPエンドポイントが含まれています。
3) Viewed from the FC Fabric perspective, pairs of FCIP Entities, in combination with their associated FC Entities, forward FC Frames between FC Fabric elements. The FC End Nodes are unaware of the existence of the FCIP Link.
3）FCファブリック観点から見ると、それらの関連するFCエンティティ、FCファブリック素子の間に順FCフレームと組み合わせてFCIPエンティティの対。 FCエンドノードはFCIPリンクの存在に気づいていません。
4) FC Primitive Signals, Primitive Sequences, and Class 1 FC Frames are not transmitted across an FCIP Link because they cannot be encoded using FC Frame Encapsulation [19].
これらはFCフレームのカプセル化[19]を使用して符号化することができないので、4）FCプリミティブ信号プリミティブシーケンス、およびクラス1のFCフレームは、FCIPリンクを介して送信されません。
5) The path (route) taken by an encapsulated FC Frame follows the normal routing procedures of the IP Network.
5）カプセル化されたFCフレームで撮影されたパス（経路）は、IPネットワークの通常のルーティング手順に従います。
6) An FCIP Entity MAY contain multiple FCIP Link Endpoints, but each FCIP Link Endpoint (FCIP_LEP) communicates with exactly one other FCIP_LEP.
6）アンFCIPエンティティは、複数のFCIPリンクエンドポイントを含んでいてもよいが、各FCIPリンクエンドポイント（FCIP_LEP）は正確に一つの他のFCIP_LEPと通信します。
7) When multiple FCIP_LEPs with multiple FCIP_DEs are in use, selection of which FCIP_DE to use for encapsulating and transmitting a given FC Frame is covered in FC-BB-2 [3]. FCIP Entities do not actively participate in FC Frame routing.
複数FCIP_DEs有する複数FCIP_LEPsが使用されている場合7）、選択のFCIP_DEは、カプセル化し、所与のFCフレームをFC-BB-2 [3]で覆われている送信するために使用します。 FCIPエンティティは、積極的にFCフレームのルーティングに参加しません。
8) The FCIP Control and Services module MAY use TCP/IP quality of service features (see section 10.2).
8）FCIP制御およびサービスモジュールは、（セクション10.2を参照）サービス機能のTCP / IPの品質を使用するかもしれません。
9) It is necessary to statically or dynamically configure each FCIP entity with the IP addresses and TCP port numbers corresponding to FCIP Entities with which it is expected to initiate communication. If dynamic discovery of participating FCIP Entities is supported, the function SHALL be performed using the Service Location Protocol (SLPv2) [17]. It is outside the scope of this specification to describe any static configuration method for participating FCIP Entity discovery. Refer to section 8.1.2.2 for a detailed description of dynamic discovery of participating FCIP Entities using SLPv2.
9）静的または動的IPアドレスとTCPポート番号は、通信を開始すると予想されるFCIPエンティティに対応する各FCIPエンティティを設定する必要があります。参加FCIPエンティティの動的検出がサポートされている場合、関数は、サービスロケーションプロトコル（SLPv2の）[17]を用いて行うことがSHALL。これは、FCIPエンティティの発見に参加するための任意の静的構成方法を説明するために本明細書の範囲外です。 SLPv2のを使用してFCIPエンティティの参加の動的検出の詳細については、セクション8.1.2.2を参照。
10) Before creating a TCP Connection to a peer FCIP Entity, the FCIP Entity attempting to create the TCP connection SHALL statically or dynamically determine the IP address, TCP port, expected FC Fabric Entity World Wide Name, TCP Connection Parameters, and Quality of Service Information.
10）ピアFCIPエンティティへのTCP接続を作成する前に、TCP接続を作成しようとするFCIPエンティティは、静的または動的IPアドレス、TCPポートを決定するものと、FCファブリックエンティティのWorld Wide名、TCP接続パラメータ、およびサービス品質を期待情報。
11) FCIP Entities do not actively participate in the discovery of FC source and destination identifiers. Discovery of FC addresses (accessible via the FCIP Entity) is provided by techniques and protocols within the FC architecture as described in FC-FS [5] and FC-SW-2 [4].
11）FCIPエンティティは、積極的にFCの送信元と送信先の識別子の発見に参加しません。 FC-FSに記載されているように（FCIPエンティティを介してアクセス可能）FCアドレスの発見は、FCアーキテクチャ内技術およびプロトコルによって提供されている[5]及びFC-SW-2 [4]。
12) To support IP Network security (see section 9), FCIP Entities MUST: 1) implement cryptographically protected authentication and cryptographic data integrity keyed to the authentication process, and 2) implement data confidentiality security features.
12）IPネットワークのセキュリティをサポートするために（セクション9を参照）、FCIPエンティティをしなければならない：1）暗号で保護された認証および認証プロセスにキーの暗号データの整合性を実装し、2）データの機密性のセキュリティ機能を実装しています。
13) On an individual TCP Connection, this specification relies on TCP/IP to deliver a byte stream in the same order that it was sent.
13）個々のTCPコネクションでは、この仕様は、それが送られたのと同じ順序でバイトストリームを提供するためにTCP / IPに依存しています。
14) This specification assumes the presence of and requires the use of TCP and FC data loss and corruption mechanisms. The error detection and recovery features described in this specification complement and support these existing mechanisms.
14）この仕様は存在することを前提とTCPとFCデータの損失や破損のメカニズムの使用を必要とします。エラー検出とリカバリ機能は、この仕様書の補足に記載されており、これらの既存のメカニズムをサポートしています。
The relationship between FCIP and other protocols is illustrated in figure 1.
FCIPと他のプロトコルとの間の関係は、図1に示されています。
+------------------------+ FCIP Link +------------------------+
| FCIP |===========| FCIP |
+--------+------+--------+ +--------+------+--------+
| FC-2 | | TCP | | TCP | | FC-2 |
+--------+ +--------+ +--------+ +--------+
| FC-1 | | IP | | IP | | FC-1 |
+--------+ +--------+ +--------+ +--------+
| FC-0 | | LINK | | LINK | | FC-0 |
+--------+ +--------+ +--------+ +--------+
| | PHY | | PHY | |
| +--------+ +--------+ |
| | | |
| | IP Network | |
V +--------------------+ V
to Fibre to Fibre
Channel Channel
Fabric Fabric
Key: FC-0 - Fibre Channel Physical Media Layer FC-1 - Fibre Channel Encode and Decode Layer FC-2 - Fibre Channel Framing and Flow Control Layer TCP - Transmission Control Protocol IP - Internet Protocol LINK - IP Link Layer PHY - IP Physical Layer
キー：FC-0 - ファイバチャネル物理メディアレイヤFC-1 - ファイバチャネルエンコードおよびデコードレイヤFC-2 - ファイバチャネルフレーミングとフロー制御層TCP - 伝送制御プロトコルIP - インターネットプロトコルLINK - IPリンクレイヤPHY - IP物理層
Figure 1: FCIP Protocol Stack Model
図1：FCIPプロトコルスタックモデル
Note that the objective of the FCIP Protocol is to create and maintain one or more FCIP Links to transport data.
FCIPプロトコルの目的は、データを転送するための1つ以上のFCIPリンクを作成し、維持することであることに注意してください。
The FCIP Link is the basic unit of service provided by the FCIP Protocol to an FC Fabric. As shown in figure 2, an FCIP Link connects two portions of an FC Fabric using an IP Network as a transport to form a single FC Fabric.
FCIPリンクは、FCファブリックにFCIPプロトコルによって提供されるサービスの基本単位です。図2に示すように、FCIPリンクは、単一のFCファブリックを形成するためのトランスポートとしてIPネットワークを使用してFCファブリックの2つの部分を接続します。
/\/\/\/\/\/\ /\/\/\/\/\/\ /\/\/\/\/\/\
\ FC / \ IP / \ FC /
/ Fabric \=========/ Network \=========/ Fabric \
\/\/\/\/\/\/ \/\/\/\/\/\/ \/\/\/\/\/\/
| |
|<--------- FCIP Link -------->|
Figure: 2 FCIP Link Model
図：2 FCIPリンクモデル
At the points where the ends of the FCIP Link meet portions of the FC Fabric, an FCIP Entity (see section 5.4) combines with an FC Entity as described in section 5.3 to serve as the interface between FC and IP.
FCとIPとの間のインターフェースとして機能するセクション5.3に記載されているようにFCIPリンクの両端がFCファブリック、FCIPエンティティの部分を満たす点でFCエンティティと組み合わせた（セクション5.4を参照）。
An FCIP Link SHALL contain at least one TCP Connection and MAY contain more than one TCP Connection. The endpoints of a single TCP Connection are FCIP Data Engines (see section 5.6). The endpoints of a single FCIP Link are FCIP Link Endpoints (see section 5.5).
FCIPリンクは、少なくとも1つのTCPコネクションを含まなければならないし、複数のTCPコネクションを含むかもしれません。単一のTCP接続のエンドポイントは、FCIPデータエンジン（セクション5.6を参照）です。単一FCIPリンクのエンドポイントは、FCIPリンクのエンドポイント（5.5節を参照）です。
An implementation that tunnels an FC Fabric through an IP Network MUST combine an FC Entity with an FCIP Entity (see section 5.4) to form a complete interface between the FC Fabric and IP Network as shown in figure 3. An FC Fabric Entity may contain multiple instances of the FC/FCIP Entity pair shown on either the right-hand or left-hand side of figure 3.
図に示すように、FCIPエンティティとFCエンティティを結合する必要があり、IPネットワークを介してFCファブリックのトンネル実装3.アンFCファブリックエンティティが複数含まれていてもよいFCファブリックとIPネットワークとの間の完全なインタフェースを形成する（セクション5.4を参照します）右または図3の左側のいずれかに示されるFC / FCIPエンティティペアのインスタンス。
|<--------- FCIP Link -------->|
| |
+----------+ /\/\/\/\/\/\ +----------+
| FCIP | \ IP / | FCIP |
| Entity |=========/ Network \=========| Entity |
+----------+ \/\/\/\/\/\/ +----------+
| FC | | FC |
| Entity | | Entity |
+----------+ +----------+
| |
/\/\/\/\/\/\ /\/\/\/\/\/\
\ FC / \ FC /
/ Fabric \ / Fabric \
\/\/\/\/\/\/ \/\/\/\/\/\/
Figure 3: Model for Two Connected FC/FCIP Entity Pairs
図3：2つの接続されたFC / FCIPエンティティペアのためのモデル
In general, the combination of an FCIP Link and two FC/FCIP Entity pairs is intended to provide a non-Fibre Channel backbone transport between Fibre Channel components. For example, this combination can be used to function as the hard-wire connection between two Fibre Channel switches.
一般的には、FCIPリンクおよび2 FC / FCIPエンティティペアの組み合わせは、ファイバー・チャネル・コンポーネント間の非ファイバチャネルバックボーン・トランスポートを提供することを意図しています。例えば、この組み合わせは、2つのファイバチャネルスイッチ間のハードワイヤ接続として機能するように使用することができます。
The interface between the FC and FCIP Entities is implementation specific. The functional requirements placed on an FC Entity by this specification are listed in appendix H. More information about FC Entities can be found in the Fibre Channel standards and an example of an FC Entity can be found in FC-BB-2 [3].
FCとFCIPエンティティ間のインターフェースは、実装固有です。この仕様でFCエンティティ上に配置された機能要件は、付録Hに記載されているFCエンティティの詳細については、ファイバチャネル規格に見出すことができ、FCエンティティの例は、FC-BB-2に見ることができる[3]。
The model for an FCIP Entity is shown in figure 4.
FCIPエンティティのモデルは、図4に示されています。
.......................................................
: FCIP Entity :
: :
: +-----------+ :
: | FCIP | :
: |Control and|------------------------------------+ :
: | Services | | :
: | Module | | :
: +-----------+ | :
: | +--------------------+ | :
: | +-------+--------------------+|----+ | :
: | |+-----+--------------------+|----+| | :
: | ||+----| FCIP Link Endpoint |----+|| | :
: | ||| +--------------------+ ||| | :
:.............................................|||.....:
| ||| ||| |
| ||| ||| o<--+
| ||| unique TCP ||| | |
| ||| connections-->||| | |
| ||| ||| | |
+----------+ /\/\/\/\/\/\ |
| FC | \ IP / |
| Entity | / Network \ |
+----------+ \/\/\/\/\/\/ |
| |
/\/\/\/\/\/\ +------------------+
\ FC / +->TCP port for
/ Fabric \ incoming
\/\/\/\/\/\/ connections
Figure 4: FCIP Entity Model
図4：FCIPエンティティモデル
The FCIP Entity receives TCP connect requests on behalf of the FCIP_LEPs that it manages. In support of this, the FCIP Entity is the sole owner of at least one TCP port/IP Address combination used to form TCP Connections. The TCP port may be the FCIP well known port at a given IP Address. An FC Fabric to IP Network interface product SHALL provide each FC/FCIP Entity pair contained in the product with a unique combination of FC Fabric Entity World Wide Identifier and FC/FCIP Entity Identifier values (see section 7).
FCIPエンティティは、TCPは、それが管理してFCIP_LEPsに代わって接続要求を受け取ります。これを支持するもの、FCIPエンティティは、TCPコネクションを形成するために使用される少なくとも1つのTCPポート/ IPアドレスの組み合わせの唯一の所有者です。 TCPポートは、与えられたIPアドレスでのFCIP既知のポートかもしれません。 FCファブリックIPへのネットワークインタフェース製品は、FCファブリックエンティティワールドワイド識別子とFC / FCIPエンティティ識別子の値（セクション7参照）のユニークな組み合わせを有する生成物に含まれる各FC / FCIPエンティティの対を提供しなければなりません。
An FCIP Entity contains an FCIP Control and Services Module to control FCIP link initialization, FCIP link dissolution, and to provide the FC Entity with an interface to key IP Network features.
FCIPエンティティは、FCIPリンクの初期化、FCIPリンクの溶解を制御するために、キーIPネットワーク機能へのインタフェースでFCエンティティを提供するために、FCIP制御およびサービスモジュールが含まれています。
The interfaces to the IP Network features are implementation specific, however, REQUIRED TCP/IP functional support is specified in this document, including:
：機能は実装固有であるIPネットワークへのインタフェースは、しかし、必要なTCP / IP機能のサポートを含め、この文書で指定されています
- TCP Connections - see section 8 - Security - see section 9 - Performance - see section 10 - Dynamic Discovery - see section 8.1.2.2
- TCPコネクション - セキュリティ - - セクション8を参照してくださいパフォーマンス - - セクション9を参照してください動的検出 - - セクション10を参照してください8.1.2.2を参照してください
The FCIP Link Endpoints in an FCIP Entity provide the FC Frame encapsulation and transmission features of FCIP.
FCIPエンティティでのFCIPリンクのエンドポイントは、FCIPのFCフレームのカプセル化と伝送機能を提供します。
As shown in figure 5, the FCIP Link Endpoint contains one FCIP Data Engine for each TCP Connection in the FCIP Link.
図5に示すように、FCIPリンクのエンドポイントは、FCIPリンクの各TCPコネクションのために1 FCIPデータエンジンが含まれています。
................................................
: FCIP Link Endpoint :
: +------------------+ :
: +-------+------------------+|----+ :
: |+-----+------------------+|----+| :
: ||+----| FCIP Data Engine |----+|| :
: ||| +------------------+ ||| :
:..............................................:
||| |||
+----------+ /\/\/\/\/\/\
| FC | \ IP /
| Entity | / Network \
+----------+ \/\/\/\/\/\/
|
/\/\/\/\/\/\
\ FC /
/ Fabric \
\/\/\/\/\/\/
Figure 5: FCIP Link Endpoint Model
図5：FCIPリンクエンドポイントモデル
Each time a TCP Connection is formed with a new FC/FCIP Entity pair (including all the actions described in section 8.1), the FCIP Entity SHALL create a new FCIP Link Endpoint containing one FCIP Data Engine.
TCP接続が（セクション8.1で説明するすべてのアクションを含む）、新たなFC / FCIPエンティティペアが形成されているたびに、FCIPエンティティは1 FCIPデータエンジンを含む新しいFCIPリンクエンドポイントを作成するものとします。
An FCIP_LEP is a transparent data translation point between an FC Entity and an IP Network. A pair of FCIP_LEPs communicating over one or more TCP Connections create an FCIP Link to join two islands of an FC Fabric, producing a single FC Fabric.
FCIP_LEPは、FCエンティティとIPネットワークの間で透過的なデータ変換ポイントです。 1つ以上のTCPコネクションを介して通信FCIP_LEPsのペアは、単一のFCファブリックを生産、FCファブリックの二つの島に参加するFCIPリンクを作成します。
The IP Network over which the two FCIP_LEPs communicate is not aware of the FC payloads that it is carrying. Likewise, the FC End Nodes connected to the FC Fabric are unaware of the TCP/IP based transport employed in the structure of the FC Fabric.
2 FCIP_LEPsが通信するためのIPネットワークは、それが運んでいるFCペイロードを認識しません。同様に、FCファブリックに接続されているFCエンドノードは、FCファブリックの構造に採用TCP / IPベースのトランスポートの気づいていません。
An FCIP_LEP uses normal TCP based flow control mechanisms for managing its internal resources and matching them with the advertised TCP Receiver Window Size (see sections 8.3.2, 8.5). An FCIP_LEP MAY communicate with its local FC Entity counterpart to coordinate flow control.
FCIP_LEPは（セクション8.3.2、8.5を参照）、その内部リソースを管理し、宣伝TCPレシーバウィンドウサイズとそれらをマッチングするための通常のTCPベースのフロー制御メカニズムを使用しています。 FCIP_LEPは、フロー制御を調整するためにそのローカルFCエンティティ相手と通信することができます。
The model for one of the multiple FCIP_DEs that MAY be present in an FCIP_LEP is shown in figure 6.
FCIP_LEP中に存在し得る複数FCIP_DEsのいずれかのモデルは、図6に示されています。
+--------------------------------+
| |
F |-+ +------------------+ +-|
C |p| | Encapsulation | |p| N
-->|1|--->| Engine |--->|2|--> e
E |-+ +------------------+ +-| t
n | | I w
t |-+ +------------------+ +-| P o
i |p| | De-Encapsulation | |p| r
t <--|4|<---| Engine |<---|3|<-- k
y |-+ +------------------+ +-|
| |
+--------------------------------+
Figure 6: FCIP Data Engine Model
図6：FCIPデータエンジンモデル
Data enters and leaves the FCIP_DE through four portals (p1 - p4). The portals do not process or examine the data that passes through them. They are only the named access points where the FCIP_DE interfaces with the external world. The names of the portals are as follows:
データが入り、4つのポータル（P1 - P4）を介してFCIP_DEを離れます。ポータルは、それらを通過するデータを処理するか検討していません。彼らはFCIP_DEは、外部世界とのインタフェースのみという名前のアクセスポイントです。次のようにポータルの名前は次のとおりです。
p1) FC Frame Receiver Portal - The interface through which an FC Frame and time stamp enters an FCIP_DE from the FC Entity.
FCフレームおよびタイムスタンプは、FCエンティティからFCIP_DEを入力するためのインターフェイス - P1）FCは、Receiverポータルフレーム。
p2) Encapsulated Frame Transmitter Portal - The TCP interface through which an FCIP Frame is transmitted to the IP Network by an FCIP_DE.
P2）カプセル化されたフレームトランスミッタポータル - FCIPフレームがFCIP_DEによってIPネットワークへ伝送されるTCPインターフェース。
p3) Encapsulated Frame Receiver Portal - The TCP interface through which an FCIP Frame is received from the IP Network by an FCIP_DE.
P3）カプセル化されたフレームレシーバーポータル - FCIPフレームがFCIP_DEによりIPネットワークから受信されてTCPインタフェース。
p4) FC Frame Transmitter Portal - The interface through which a reconstituted FC Frame and time stamp exits an FCIP_DE to the FC Entity.
P4）FCフレームトランスミッタポータル - 再構成されたFCフレームおよびタイムスタンプは、FCエンティティにFCIP_DEを終了するためのインターフェイス。
The work of the FCIP_DE is done by the Encapsulation and De-Encapsulation Engines. The Engines have two functions:
FCIP_DEの仕事は、カプセル化とカプセル化解除エンジンによって行われます。エンジンは2つの機能を持っています：
1) Encapsulating and de-encapsulating FC Frames using the encapsulation format described in FC Frame Encapsulation [19] and in section 5.6.1 of this document, and
1）カプセル化と脱カプセル化するFCフレームをFCフレームのカプセル化に記載のカプセル化フォーマットを使用して[19]、このドキュメントのセクション5.6.1で、および
2) Detecting some data transmission errors and performing minimal error recovery as described in section 5.6.2.
2）いくつかのデータ伝送エラーを検出し、セクション5.6.2に記載したように、最小のエラー回復を行います。
Data flows through a pair of IP Network connected FCIP_DEs in the following seven steps:
データは、以下の7つのステップでFCIP_DEs接続IPネットワークのペアを通って流れ：
1) An FC Frame and time stamp arrives at the FC Frame Receiver Portal and is passed to the Encapsulation Engine. The FC Frame is assumed to have been processed by the FC Entity according to the applicable FC rules and is not validated by the FCIP_DE. If the FC Entity is in the Unsynchronized state with respect to a time base as described in the FC Frame Encapsulation [19] specification, the time stamp delivered with the FC Frame SHALL be zero.
1）FCフレームおよびタイムスタンプは、FCレシーバポータルフレームに到着し、カプセル化エンジンに渡されます。 FCフレームは、適用FC規則に従ってFCエンティティによって処理されているものとするとFCIP_DEによって検証されていません。 FCフレームのカプセル化[19]明細書に記載されるようにFCエンティティは、時間ベースに対して非同期状態にある場合、FCフレームで提供タイムスタンプはゼロでなければなりません。
2) In the Encapsulation Engine, the encapsulation format described in FC Frame Encapsulation [19] and in section 5.6.1 of this document SHALL be applied to prepare the FC Frame and associated time stamp for transmission over the IP Network.
2）[19]カプセル化エンジン、FCフレームのカプセル化に記載のカプセル化フォーマットでは、このドキュメントのセクション5.6.1には、IPネットワークを介して送信するためのFCフレームおよび関連するタイムスタンプを製造するために適用しなければなりません。
3) The entire encapsulated FC Frame (a.k.a. the FCIP Frame) SHALL be passed to the Encapsulated Frame Transmitter Portal where it SHALL be inserted in the TCP byte stream.
3）FCIPフレーム別名全体カプセル化FCフレーム（）は、TCPバイトストリームに挿入されるものとカプセル化されたフレーム送信ポータルに渡されるものとします。
4) Transmission of the FCIP Frame over the IP Network follows all the TCP rules of operation. This includes, but is not limited to, the in-order delivery of bytes in the stream, as specified by TCP [6].
4）IPネットワークを介したFCIPフレームの送信は、操作のすべてのTCP規則に従います。これには、TCPによって指定されるように[6]、ストリーム内のバイトの順序配信が、これらに限定されません。
5) The FCIP Frame arrives at the partner FCIP Entity where it enters the FCIP_DE through the Encapsulated Frame Receiver Portal and is passed to the De-Encapsulation Engine for processing.
5）FCIPフレームは、それがカプセル化されたフレームレシーバーポータルを通じてFCIP_DEに入り、処理のために非カプセル化エンジンに渡され、パートナーFCIPエンティティに到着します。
6) The De-Encapsulation Engine SHALL validate the incoming TCP byte stream as described in section 5.6.2.2 and SHALL de-encapsulate the FC Frame and associated time stamp according to the encapsulation format described in FC Frame Encapsulation [19] and in section 5.6.1 of this document.
6）FCフレームのカプセル化[19]に、セクション5.6に記載のカプセル化フォーマットに従ってセクション5.6.2.2に記載され、FCフレームを非カプセル化するものとし、タイムスタンプを対応付けて着信TCPバイトストリームを検証するものと脱カプセル化エンジンこのドキュメントの0.1。
7) In the absence of errors, the de-encapsulated FC Frame and time stamp SHALL be passed to the FC Frame Transmitter Portal for delivery to the FC Entity. Error handling is discussed in section 5.6.2.2.
7）エラーの非存在下で、脱カプセル化されたFCフレームおよびタイムスタンプは、FCエンティティへの配信のために、FCフレーム送信ポータルに渡されるものとします。エラー処理はセクション5.6.2.2で説明されています。
Every FC Frame that arrives at the FC Frame Receiver Portal SHALL be transmitted on the IP Network as described in steps 1 through 4 above. In the absence of errors, data bytes arriving at the Encapsulated Frame Receiver Portal SHALL be de-encapsulated and forwarded to the FC Frame Transmitter Portal as described in steps 5 through 7.
上記4を介して手順1に記載されているように、FCフレーム受信ポータルに到達する毎に、FCフレームは、IPネットワーク上で送信されなければなりません。 7を介して、ステップ5に記載したようにエラーの不存在下で、カプセル化されたフレームに到着するデータバイトが受信ポータルは、脱カプセル化されなければならず、FCフレーム送信ポータルに転送されます。
The FCIP encapsulation of FC Frames employs FC Frame Encapsulation [19].
FCフレームのFCIPカプセル化は、FCフレームのカプセル化[19]を用います。
The features from FC Frame Encapsulation that are unique to individual protocols SHALL be applied as follows for the FCIP encapsulation of FC Frames.
FCフレームのFCIPカプセル化のために、以下のように個々のプロトコルに固有のFCフレームのカプセル化から機能を適用しなければなりません。
The Protocol# field SHALL contain 1 in accordance with the IANA Considerations annex of FC Frame Encapsulation [19].
プロトコル番号フィールドは、FCフレームのカプセル化[19]のIANAの考慮の附属書に従って、1を含まなければなりません。
The Protocol Specific field SHALL have the format shown in figure 7. Note: the word numbers in figure 7 are relative to the complete FC Frame Encapsulation header, not to the Protocol Specific field.
プロトコル特定フィールドには、図7（注）に示すフォーマットを有するものとする：図7中のワード数は、完全なFCフレームのカプセル化ヘッダにはなく、プロトコル特定フィールドに対するものです。
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------------------------------------------------------+
1| replication of encapsulation word 0 |
+---------------+---------------+---------------+---------------+
2| pFlags | Reserved | -pFlags | -Reserved |
+---------------+---------------+---------------+---------------+
Figure 7: FCIP Usage of FC Frame Encapsulation Protocol Specific field
図7：FCフレームのカプセル化プロトコル固有フィールドのFCIPの使い方
Word 1 of the Protocol Specific field SHALL contain an exact copy of word 0 in FC Frame Encapsulation [19].
プロトコル特定フィールドのワード1は、FCフレームのカプセル化[19]にワード0の正確なコピーを含まなければなりません。
The pFlags (protocol specific flags) field provides information about the protocol specific usage of the FC Encapsulation Header. Figure 8 shows the defined pFlags bits.
PFLAGS（プロトコル固有のフラグ）フィールドFCカプセル化ヘッダのプロトコル固有の使用状況に関する情報を提供します。図8は、定義されたPFLAGSビットを示します。
|----------------Bit--------------------|
| |
| 0 1 2 3 4 5 6 7 |
+----+-----------------------------+----+
| Ch | Reserved | SF |
+----+-----------------------------+----+
Figure 8: pFlags Field Bits
図8：PFLAGSフィールドビット
The SF (Special Frame) bit indicates whether the FCIP Frame is an encapsulated FC Frame or an FSF (FCIP Special Frame, see section 7). When the FCIP Frame contains an encapsulated FC Frame, the SF bit SHALL be 0. When the FCIP Frame is an FSF, the SF bit SHALL be 1.
SF（特別なフレーム）のビットは、FCIPフレームがカプセル化されたFCフレームまたはFSF（FCIP特殊フレーム、セクション7を参照）であるか否かを示します。 FCIPフレームがカプセル化されたFCフレームを含む場合FCIPフレームがFSFある場合、SFビットは0でなければならない、SFビットは1でなければなりません。
The FSF SHALL only be sent as the first bytes transmitted in each direction on a newly formed TCP Connection and only one FSF SHALL be transmitted in each direction at that time (see section 8.1). After that all FCIP Frames SHALL have the SF bit set to 0.
新たに形成されたTCP接続とつのみFSF上の各方向に送信される最初のバイトは、その時点で各方向に送信されるとおりでなければならないFSFのみ（セクション8.1を参照）を送付しなければなりません。その後、すべてのFCIPフレームはSFビットが0に設定されているものとします。
The Ch (Changed) bit indicates whether an echoed FSF has been intentionally altered (see section 8.1.3). The Ch bit SHALL be 0 unless the FSF bit is 1. When the initial TCP Connection FSF is sent, the Ch bit SHALL be 0. If the recipient of a TCP connect request echoes the FSF without any changes, then the Ch bit SHALL continue to be 0. If the recipient of a TCP connect request alters the FSF before echoing it, then the Ch bit SHALL be changed to 1.
CH（変更）ビット（セクション8.1.3を参照）エコーFSFが意図的に改変されているか否かを示します。 FSFビットが1初期TCP接続FSFが送信されるTCPの受信者は、要求が変更なしFSFをエコー接続した場合、Chのビットは0でなければならない、次いでCHビットが継続SHALLでない限り、Chのビットは0でなければなりませんTCPの受信者は、要求がそれをエコーする前にFSFを変える接続する場合は0に、次にCHビットが1に変更されるものとします。
The -pFlags field SHALL contain the ones complement of the contents of the pFlags field.
-pFlagsフィールドはPFLAGSフィールドの内容の一の補数を含まなければなりません。
Table 1 summarizes the usage of the pFlags SF and Ch bits.
表1は、PFLAGS SFとChのビットの使用状況をまとめました。
+----+----+------------+--------------------------------------+
| | | Originated | |
| SF | Ch | or Echoed | Validity/Description |
+----+----+------------+--------------------------------------+
| 0 | 0 | n/a | Encapsulated FC Frame |
+----+----+------------+--------------------------------------+
| 0 | 1 | n/a | Always Illegal |
+----+----+------------+--------------------------------------+
| 1 | 0 | Originated | Originated FSF |
+----+----+------------+--------------------------------------+
| 1 | 1 | Originated | Always Illegal |
+----+----+------------+--------------------------------------+
| 1 | 0 | Echoed | Echoed FSF without changes |
+----+----+------------+--------------------------------------+
| 1 | 1 | Echoed | Echoed FSF with changes |
+----+----+------------+--------------------------------------+
| Note 1: Echoed FSFs may contain changes resulting from |
| transmission errors, necessitating the comparison between |
| sent and received FSF bytes by the FSF originator described |
| in section 8.1.2.3. |
| |
| Note 2: Column positions in this table do not reflect the |
| bit positions of the SF and Ch bits in the pFlags field. |
+-------------------------------------------------------------+
Table 1: pFlags SF and Ch bit usage summary
表1：PFLAGS SFとChのビット使用量の概要
The Reserved pFlags bits SHALL be 0.
予約PFLAGSビットは0でなければなりません。
The Reserved field (bits 23-16 in word 2): SHALL contain 0.
予約フィールド（ワード2のビット23-16）は、0を含まなければなりません。
The -Reserved field (bits 7-0 in word 2): SHALL contain 255 (or 0xFF).
-Reservedフィールド（ワード2のビット7-0）は：255（または0xFF）を含まなければなりません。
The CRCV (CRC Valid) Flag SHALL be set to 0.
CRCV（CRC有効）フラグは0に設定されます。
The CRC field SHALL be set to 0.
CRCフィールドは0に設定されなければなりません。
In FCIP, the SOF and EOF codes listed as Class 2, Class 3, and Class 4 in the FC Frame Encapsulation [19] are legal.
FCIPにおいて、FCフレームのカプセル化[19]のクラス2、クラス3、クラス4として記載されているSOFとEOFコードは合法です。
TCP [6] requires in order delivery, generation of TCP checksums, and checking of TCP checksums. Thus, the byte stream passed from TCP to the FCIP_LEP will be in order and free of errors detectable by the TCP checksum. The FCIP_LEP relies on TCP to perform these functions.
TCPは、[6]次の送達、TCPチェックサムの生成、TCPチェックサムの確認に必要となります。したがって、FCIP_LEPにTCPから渡されたバイトストリームは、順序とTCPチェックサムによって検出エラーの自由になります。 FCIP_LEPは、これらの機能を実行するためにTCPに依存しています。
Bytes delivered through the Encapsulated Frame Receiver Portal that are not correctly delimited as defined by the FC Frame Encapsulation [19] are considered to be in error.
FCフレームのカプセル化[19]によって定義されるように正確に区切られていないカプセル化されたフレーム受信ポータルを介して配信バイトがエラーであると考えられます。
The failure of the Protocol# and Version fields in the FCIP Frame header to contain the values defined for an FCIP Frame SHALL be considered an error.
FCIPフレームの定義された値を格納するためのFCIPフレームヘッダ内のプロトコル番号とバージョンフィールドの失敗はエラーとみなします。
Further, some errors in the encapsulation will result in the FCIP_DE losing synchronization with the FC Frames in the byte stream entering through the Encapsulated Frame Receiver Portal.
さらに、カプセル化に多少の誤差がFCIP_DEがカプセル化されたフレームレシーバーポータルを通って入るバイトストリームにFCフレームとの同期を失うことになります。
The Frame Length field in the FC Frame Encapsulation header is used to determine where in the data stream the next FC Encapsulated Header is located. The following tests SHALL be performed to verify synchronization with the byte stream entering the Encapsulated Frame Receiver Portal, and synchronization SHALL be considered lost if any of the tests fail:
データは次のFCカプセル化ヘッダが配置されているストリーム中のFCフレームのカプセル化ヘッダ内のフレーム長フィールドは、場所を決定するために使用されます。次のテストでは、バイトストリームがカプセル化されたフレームレシーバーポータルに入るとの同期を確認するために行われるものとする（SHALL）、およびテストのいずれかが失敗した場合に同期が失われたと考えなければなりません。
1) Frame Length field validation -- 15 < Frame Length < 545;
1）フレーム長フィールド検証 - 15 <フレーム長<545。
2) Comparison of Frame Length field to its ones complement; and
2）そのものへのフレーム長フィールドの比較を補完します。そして
3) A valid EOF is found in the word preceding the start of the next FCIP header as indicated by the Frame Length field, to be tested as follows:
3）有効なEOFは、以下のように試験される、フレームの長さフィールドによって示されるように、次のFCIPヘッダの開始に先行する単語に見出されます。
1) Bits 24-31 and 16-23 contain identical legal EOF values (the list of legal EOF values is in the FC Frame Encapsulation [19]); and
1）24-31及び16-23は同じ法的EOF値（法定EOF値のリストFCフレームをカプセル化しているが含まれているビット[19]）。そして
2) Bits 8-15 and 0-7 contain the ones complement of the EOF value found in bits 24-31.
2）8-15ビット、0-7ビット24-31に見られるEOF値のものの相補体を含みます。
Note: The range of valid Frame Length values is derived as follows. The FCIP Frame header is seven words, one word each is required for the encoded SOF and EOF values, the FC Frame header is six words, and the FC CRC requires one word, yielding a base Frame Length of 16 (7+1+1+6+1) words, if no FC Payload is present. Since the FC Payload is optional, any Frame Length value greater than 15 is valid. The maximum FC Payload size is 528 words, meaning that any Frame Length value up to and including 544 (528+16) is valid.
注意：次のように有効なフレーム長値の範囲が導出されます。 FCIPフレームヘッダは7つのワード1つのワード毎に符号化されたSOFとEOFの値のために必要とされ、FCフレームヘッダは、6つの言葉であり、FC CRCは、16のベースフレーム長（7 + 1 + 1を得、一つのワードを必要とします+ 6 + 1）単語、何FCペイロードが存在しない場合。 FCペイロードは任意であるため、任意のフレームの長さより大きい値15が有効です。最大FCペイロードサイズが544（+ 16 528）を含むアップ任意のフレーム長の値が有効であることを意味し、528ワードです。
If synchronization is lost, the FC Frame SHALL NOT be forwarded on to the FC Entity and further recovery SHALL be handled as defined by section 5.6.2.3.
同期が失われた場合、FCフレームは、FCエンティティへ転送されてはならず、セクション5.6.2.3で定義された更なる回復が処理されるものとします。
In addition to the tests above, the validity and positioning of the following FCIP Frame information SHOULD be used to detect encapsulation errors that may or may not affect synchronization:
上記試験に加えて、有効性および以下FCIPフレーム情報の位置決めや同期に影響してもしなくてもよいカプセル化エラーを検出するために使用されるべきです。
a) Protocol# ones complement field (1 test);
b) Version ones complement field (1 test);
c) Replication of encapsulation word 0 in word 1 (1 test);
d) Reserved field and its ones complement (2 tests);
e) Flags field and its ones complement (2 tests);
f) CRC field is equal to zero (1 test);
g) SOF fields and ones complement fields (4 tests);
h) Format and values of FC header (1 test);
i) CRC of FC Frame (2 tests);
j) FC Frame Encapsulation header information in the next FCIP
Frame (1 test).
At least 3 of the 16 tests listed above SHALL be performed. Failure of any of the above tests actually performed SHALL indicate an encapsulation error and the FC Frame SHALL NOT be forwarded on to the FC Entity. Further, such errors SHOULD be considered carefully, since some may be synchronization errors.
上記の16回の試験の少なくとも3つが実行されなければなりません。実際に行っ上記のテストのいずれかの失敗は、FCエンティティへと転送されないものとカプセル化エラーとFCフレームを表示しなければなりません。いくつかは、同期エラー可能性があるのでさらに、このようなエラーは、慎重に検討する必要があります。
Whenever an FCIP_DE discards bytes delivered through the Encapsulated Frame Receiver Portal, it SHALL cause the FCIP Entity to notify the FC Entity of the condition and provide a suitable description of the reason bytes were discarded.
FCIP_DEがカプセル化されたフレームレシーバーポータルを介して配信さバイトを破棄するたびに、それは条件のFCエンティティに通知し、バイトが破棄された理由の適切な説明を提供するために、FCIPエンティティせなければなりません。
The burden for recovering from discarded data falls on the FC Entity and other components of the FC Fabric, and is outside the scope of this specification.
廃棄されたデータから回復するための負担は、FCエンティティとFCファブリックの他の構成要素上に落下し、この仕様の範囲外です。
If an FCIP_DE determines that it cannot find the next FCIP Frame header in the byte stream entering through the Encapsulated Frame Receiver Portal, the FCIP_DE SHALL do one of the following:
FCIP_DEは、それがカプセル化されたフレームレシーバーポータルを通って入るバイトストリーム内の次のFCIPフレームヘッダを見つけることができないと判断した場合、FCIP_DEは、次のいずれかを実行しなければなりません。
a) close the TCP Connection [6] [7] and notify the FC Entity with the reason for the closure;
a）は、TCP接続を閉じる[6] [7]及び閉鎖の理由とFCエンティティに通知します。
b) recover synchronization by searching the bytes delivered by the Encapsulated Frame Receiver Portal for a valid FCIP Frame header having the correct properties (see section 5.6.2.2), and discarding bytes delivered by the Encapsulated Frame Receiver Portal until a valid FCIP Frame header is found; or
B）（セクション5.6.2.2を参照）が正しい特性を有する有効なFCIPフレームヘッダのカプセル化されたフレーム受信ポータルによって送達バイトを検索し、有効なFCIPフレームヘッダになるまでカプセル化されたフレーム受信ポータルによって送達バイトを廃棄することにより、同期を回復見つかりました。または
c) attempt to recover synchronization as described in b) and if synchronization cannot be recovered, close the TCP Connection as described in a), including notification of the FC Entity with the reason for the closure.
C）Bに記載したように、同期を回復しようとする）との同期を回復することができない場合で説明したように、閉鎖の理由とFCエンティティの通知を含む）TCP接続を閉じます。
If the FCIP_DE attempts to recover synchronization, the resynchronization algorithm used SHALL meet the following requirements:
FCIP_DEが同期を回復しようとすると、使用再同期アルゴリズムは、次の要件を満たしていなければなりません。
a) discard or identify with an EOFa (see appendix section F.1) those FC Frames and fragments of FC Frames identified before synchronization has again been completely verified. The number of FC Frames not forwarded may vary based on the algorithm used;
A）同期が再び完全に検証された前に識別された廃棄又はEOFa（付録セクションF.1参照）、それらのFCフレームおよびFCフレームの断片と同定します。転送されないFCフレームの数は、使用されるアルゴリズムに基づいて変化してもよいです。
b) return to forwarding FC Frames through the FC Frame Transmitter Portal only after synchronization on the transmitted FCIP Frame stream has been verified; and
B）のみ検証された送信FCIPフレームストリームに同期後FCフレーム送信ポータルを介してFCフレームを転送に戻ります。そして
c) close the TCP/IP connection if the algorithm ends without verifying successful synchronization. The probability of failing to synchronize successfully and the time necessary to determine whether or not synchronization was successful may vary with the algorithm used.
アルゴリズムが成功した同期を検証せずに終了した場合c）のTCP / IP接続を閉じます。正常に同期して、同期が成功したか否かを決定するのに必要な時間は、使用されるアルゴリズムに応じて変化することができる失敗の確率。
An example algorithm meeting these requirements can be found in appendix D.
これらの要件を満たすアルゴリズム例は、付録D.で見つけることができます
The burden for recovering from the discarding of FCIP Frames during the optional resynchronization process described in this section falls on the FC Entity and other components of the FC Fabric, and is outside the scope of this specification.
このセクションで説明するオプションの再同期プロセス中FCIPフレームの廃棄から回復するための負担は、FCエンティティとFCファブリックの他の構成要素上に落下し、この仕様の範囲外です。
FC-BB-2 [3] defines how the measurement of IP Network transit time is performed, based on the requirements stated in the FC Frame Encapsulation [19] specification. The choice to place this implementation requirement on the FC Entity is based on a desire to include the transit time through the FCIP Entities when computing the IP Network transit time experienced by the FC Frames.
FC-BB-2 [3] IPネットワーク通過時間の測定は、FCフレームのカプセル化[19]明細書に記載された要件に基づいて、実行される方法を定義します。 FCエンティティにこの実装要件を配置する選択は、FCフレームが経験したIPネットワーク通過時間を計算するときにFCIPエンティティを通じて通過時間を含めたいという願望に基づいています。
Each FC Frame that enters the FCIP_DE through the FC Frame Receiver Portal SHALL be accompanied by a time stamp value that the FCIP_DE SHALL place in the Time Stamp [integer] and Time Stamp [fraction] fields of the encapsulation header of the FCIP Frame that contains the FC Frame. If no synchronized time stamp value is available to accompany the entering FC Frame, a value of zero SHALL be used.
レシーバポータルフレームFCを通してFCIP_DEに入る各FCフレームはFCIP_DEタイムスタンプ[整数]タイムスタンプ[分数]含有FCIPフレームのカプセル化ヘッダのフィールドに配置するものとタイムスタンプ値を添付しなければなりませんFCフレーム。何の同期タイムスタンプ値が入力FCフレームを伴うために使用できない場合は、ゼロの値を使用しなければなりません。
Each FC Frame that exits the FCIP_DE through the FC Frame Transmitter Portal SHALL be accompanied by the time stamp value taken from the FCIP Frame that encapsulated the FC Frame.
FCフレームトランスミッタポータルを通じてFCIP_DEを終了した各FCフレームは、FCフレームをカプセル化FCIPフレームから取られたタイムスタンプ値を添付しなければなりません。
The FC Entity SHALL use suitable internal clocks and either Fibre Channel services or an SNTP Version 4 server [26] to establish and maintain the required synchronized time value. The FC Entity SHALL verify that the FC Entity it is communicating with on an FCIP Link is using the same synchronized time source, either Fibre Channel services or SNTP server.
FCエンティティは、適切な内部クロックおよびファイバチャネルサービスや必要な同期時間値を確立し、維持するために、SNTPバージョン4サーバー[26]のいずれかを使用しなければなりません。 FCエンティティは、FCエンティティそれは同じ時刻同期ソースを使用しているFCIPリンク上で通信しているファイバチャネルサービスやSNTPサーバのどちらかを検証しなければなりません。
Note that since the FC Fabric is expected to have a single synchronized time value throughout, reliance on the Fibre Channel services means that only one synchronized time value is needed for all FCIP_DEs regardless of their connection characteristics.
FCファブリックは、全体で一つの同期時刻の値を持つことが期待されているので、ファイバチャネルサービスへの依存度が唯一の同期時間値は関係なく、接続特性の全てFCIP_DEsのために必要であることを意味することに注意してください。
Figure 9 shows the FSF format.
図9は、FSFのフォーマットを示します。
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 |
| (0x01) | (0x01) | (0xFE) | (0xFE) |
+---------------+---------------+---------------+---------------+
1| Protocol# | Version | -Protocol# | -Version |
| (0x01) | (0x01) | (0xFE) | (0xFE) |
+---------------+---------------+---------------+---------------+
2| pFlags | Reserved | -pFlags | -Reserved |
| | (0x00) | | (0xFF) |
+-----------+---+---------------+-----------+---+---------------+
3| Flags | Frame Length | -Flags | -Frame Length |
| (0b000000)| (0b0000010011) | (0b111111)| (0b1111101100) |
+-----------+-------------------+-----------+-------------------+
4| Time Stamp [integer] |
+---------------------------------------------------------------+
5| Time Stamp [fraction] |
+---------------------------------------------------------------+
6| CRC (Reserved in FCIP) |
| (0x00-00-00-00) |
+-------------------------------+-------------------------------+
7| Reserved | -Reserved |
| (0x00-00) | (0xFF-FF) |
+-------------------------------+-------------------------------+
8| |
+----- Source FC Fabric Entity World Wide Name -----+
9| |
+---------------------------------------------------------------+
10| |
+----- Source FC/FCIP Entity Identifier -----+
11| |
+---------------------------------------------------------------+
12| |
+----- Connection Nonce -----+
13| |
+---------------+---------------+-------------------------------+
(Continued)
Figure 9: FSF Format (part 1 of 2)
図9：FSFフォーマット（1/2）
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|
| |
| (Concluded) |
+---------------------------------------------------------------+
14| Connection | Reserved | Connection Usage Code |
| Usage Flags | (0x00) | <defined in FC-BB-2> |
+---------------+---------------+-------------------------------+
15| |
+----- Destination FC Fabric Entity World Wide Name -----+
16| |
+---------------------------------------------------------------+
17| K_A_TOV |
+-------------------------------+-------------------------------+
18| Reserved | -Reserved |
| (0x00-00) | (0xFF-FF) |
+-------------------------------+-------------------------------+
Figure 9: FSF Format (part 2 of 2)
図9：FSFフォーマット（2/2）
The FSF SHALL only be sent as the first bytes transmitted in each direction on a newly formed TCP Connection, and only one FSF SHALL be transmitted in each direction.
FSFは、新たに形成されたTCP接続上で各方向に送信される最初のバイトとして送信されるものとし、一方のみFSFは、各方向に送信されなければなりません。
The contents of the FSF SHALL be as described for encapsulated FC Frames, except for the fields described in this section.
FSFの内容は、このセクションで説明するフィールドを除いて、カプセル化されたFCフレームのために説明します。
All FSFs SHALL have the pFlags SF bit set to 1 (see section 5.6.1).
すべてFSFSは（セクション5.6.1を参照）PFLAGS SFビットが1に設定されているものとします。
The Source FC Fabric Entity World Wide Name field SHALL contain the Fibre Channel Name_Identifier [5] for the FC Fabric entity associated with the FC/FCIP Entity pair that generates (as opposed to echoes) the FSF. For example, if the FC Fabric entity is a FC Switch, the FC Fabric Entity World Wide Name field SHALL contain the Switch_Name [4]. The Source FC Fabric Entity World Wide Name SHALL be world wide unique.
ソースFCファブリックエンティティのWorld Wide Name]フィールドには、FSF（エコーではなく）を生成FC / FCIPエンティティのペアに関連付けられているFCファブリックエンティティのために[5]ファイバチャネルName_Identifierを含まなければなりません。 FCファブリックエンティティは、FCスイッチであれば、例えば、FCファブリックエンティティのWorld Wide Name]フィールドには、SWITCH_NAMEを含まなければならない[4]。ソースFCファブリックエンティティのワールドワイドネームは、世界全体で一意なものでなければなりません。
The Source FC/FCIP Entity Identifier field SHALL contain a unique identifier for the FC/FCIP Entity pair that generates (as opposed to echoes) the FSF. The value is assigned by the FC Fabric entity whose world wide name appears in the Source FC Fabric Entity World Wide Name field.
ソースFC / FCIPエンティティ識別子フィールドは、FSF（エコーとは対照的に）を生成するFC / FCIPエンティティペアの一意の識別子を含まなければなりません。値は、そのワールドワイド名ソースFCファブリックエンティティのWorld Wide Nameフィールドに表示されますFCファブリックエンティティによって割り当てられます。
Note: The combination of the Source FC Entity World Wide Name and Source FC/FCIP Entity Identifier fields uniquely identifies every FC/FCIP Entity pair in the IP Network.
注意：ソースFCエンティティのWorld Wide NameとソースFC / FCIPエンティティの識別子フィールドの組み合わせはユニークIPネットワーク内のすべてのFC / FCIPエンティティペアを識別します。
The Connection Nonce field shall contain a 64-bit random number generated to uniquely identify a single TCP connect request. In order to provide sufficient security for the connection nonce, the Randomness Recommendations for Security [9] SHOULD be followed.
接続ノンスフィールドを一意単一のTCP接続要求を識別するために生成された64ビットの乱数を含まなければなりません。接続ナンスのための十分なセキュリティを提供するために、セキュリティ[9]の乱数勧告に従うべきである（SHOULD）。
The Connection Usage Flags field identifies the types of SOF values [19] to be carried on the connection as shown in figure 10.
接続使用フラグフィールドは、図10に示すように、接続上で搬送される[19] SOF値のタイプを識別する。
|------------------------------Bit------------------------------|
| |
| 0 1 2 3 4 5 6 7 |
+-------+-------+-------+-------+-------------------------------+
| SOFf | SOF?2 | SOF?3 | SOF?4 | Reserved |
+-------+-------+-------+-------+-------------------------------+
Figure 10: Connection Usage Flags Field Format
図10：接続の使用フラグフィールドのフォーマット
If the SOFf bit is one, then FC Frames containing SOFf are intended to be carried on the connection.
SOFFビットが1である場合は、SOFFを含むFCフレームは、接続上で搬送されることが意図されます。
If the SOF?2 bit is one, then FC Frames containing SOFi2 and SOFn2 are intended to be carried on the connection.
SOF？2ビットが1である場合、SOFi2とSOFn2を含むFCフレームは、接続上で搬送されることが意図されます。
If the SOF?3 bit is one, then FC Frames containing SOFi3 and SOFn3 are intended to be carried on the connection.
SOF？3ビットが1である場合、SOFi3とSOFn3を含むFCフレームは、接続上で搬送されることが意図されます。
If the SOF?4 bit is one, then FC Frames containing SOFi4, SOFn4, and SOFc4 are intended to be carried on the connection.
SOF？4ビットが1である場合、SOFi4、SOFn4、及びSOFc4を含むFCフレームは、接続上で搬送されることが意図されます。
All or none of the SOFf, SOF?2, SOF?3, and SOF?4 bits MAY be set to one. If all of the SOFf, SOF?2, SOF?3, and SOF?4 bits are zero, then the types of FC Frames intended to be carried on the connection have no specific relationship to the SOF code.
全て又はSOFFのいずれも、SOF？2、SOF？3、及びSOF？4ビットは1に設定されなくてもよいです。 SOFF、SOFの全て？2、SOF？3、及びSOF？4ビットがゼロである場合、FCフレームの種類は、接続上で搬送されることを意図SOFコードへの特定の関係を持ちません。
The FCIP Entity SHALL NOT enforce the SOF usage described by the Connection Usage Flags field and SHALL only use the contents of the field as described below.
FCIPエンティティは、接続使用フラグフィールドによって記述さSOFの使用を強制してはならず、後述のようにのみフィールドの内容を使用しなければなりません。
The Connection Usage Code field contains Fibre Channel defined information regarding the intended usage of the connection as specified in FC-BB-2 [3].
接続使用コードフィールドは、ファイバチャネルFC-BB-2で指定されている接続の意図された使用状況に関する情報を定義含ま[3]。
The FCIP Entity SHALL use the contents of the Connection Usage Flags and Connection Usage Code fields to locate appropriate QoS settings in the "shared" database of TCP Connection information (see section 8.1.1) and apply those settings to a newly formed connection.
FCIPエンティティは、TCPコネクション情報（セクション8.1.1を参照）の「共有」のデータベースに適切なQoS設定を探し、新たに形成された接続にそれらの設定を適用するには、接続使用フラグとの接続使用コードフィールドの内容を使用しなければなりません。
The Destination FC Fabric Entity World Wide Name field MAY contain the Fibre Channel Name_Identifier [5] for the FC Fabric entity associated with the FC/FCIP Entity pair that echoes (as opposed to generates) the Special Frame.
先のFCファブリックエンティティのWorld Wide Name]フィールドには、（対照的なに生成）エコーFC / FCIPエンティティペア特別枠に関連したFCファブリックエンティティのために[5]ファイバチャネルName_Identifierを含むかもしれません。
The K_A_TOV field SHALL contain the FC Keep Alive Timeout value to be applied to the new TCP Connection as specified in FC-BB-2 [3].
K_A_TOVフィールドは、[3] FC-BB-2で指定された、新しいTCPコネクションに適用するアライブタイムアウト値をキープFCを含まなければなりません。
For each new incoming TCP connect request and subsequent FSF received, the FCIP Entity SHALL send the contents of the Source FC Fabric Entity World Wide Name, Source FC/FCIP Identifier, Connection Usage Flags and Connection Usage Code fields to the FC Entity along with the other connection information (e.g., FCIP_LEP and FCIP_DE information).
それぞれの新しい着信TCPの場合は、受信した要求とそれに続くFSFを接続し、FCIPエンティティと一緒にFCエンティティにソースFCファブリックエンティティのWorld Wide名、ソースFC / FCIP識別子、接続使用フラグと接続使用コードフィールドの内容を送信しなければなりません他の接続情報（例えば、FCIP_LEPとFCIP_DE情報）。
When a new TCP Connection is established, an FCIP Special Frame makes one round trip from the FCIP Entity initiating the TCP connect operation to the FCIP Entity receiving the TCP connect request and back. This FSF usage serves three functions:
新しいTCPコネクションが確立されると、FCIP特殊フレームは、TCPは、TCP接続要求をして戻って受信FCIPエンティティへの接続操作開始FCIPエンティティから1往復します。このFSFの使用量は、3つの機能を果たします。
- Identification of the FCIP Link endpoints
- FCIPリンクエンドポイントの識別
- Conveyance of a few critical parameters shared by the FC/FCIP Entity pairs involved in the FCIP Link
- FCIPリンクに関与FC / FCIPエンティティのペアが共有するいくつかの重要なパラメータの搬送
- Configuration discovery (used in place of SLP only when allowed by site security policies)
- コンフィギュレーションの発見（SLPの代わりに使用されるサイトのセキュリティポリシーによって許可された場合にのみ）
The specific format and protocol requirements for this usage of the FSF are found in sections 7.1 and 8.1.2.3. This section provides an overview of the FSF usage without stating requirements.
FSFのこの使用のための特定のフォーマットおよびプロトコルの要件は、セクション7.1および8.1.2.3に見出されます。このセクションでは、要件を述べることなく、FSFの使用状況の概要を説明します。
Because FCIP is only a tunnel for a Fibre Channel Fabric and because the Fabric has its own complex link setup algorithm that can be employed for many FCIP link setup needs, it is desirable to minimize the complexity of the FSF usage during TCP Connection setup. With this in mind, this FSF usage is not a login or parameter negotiation mechanism. A single FSF transits each newly established TCP connection as the first bytes sent in each direction.
FCIPは、ファイバチャネルファブリックのためのトンネルで、ファブリックは、多くのFCIPリンク設定ニーズに合わせて使用することができる独自の複雑なリンク設定アルゴリズムを持っているので、TCP接続のセットアップ時にFSFの使用状況の複雑さを最小限に抑えることが望ましいので。これを念頭に置いて、このFSFの使用量は、ログインまたはパラメータネゴシエーションメカニズムではありません。単一FSFは、各方向に送信される最初のバイトとしてそれぞれ新たに確立されたTCPコネクションを通過します。
Note: This usage of the FSF cannot be eliminated entirely because a newly created TCP Connection must be associated with the correct FCIP Link before FC Fabric initialization of the connection can commence.
注意：接続のFCファブリックの初期化が開始する前に、新しく作成されたTCP接続が正しいFCIPリンクに関連付けされなければならないので、FSFのこの用法は完全に排除することはできません。
The first bytes sent from the TCP connect request initiator to the receiver are an FSF identifying both the sender and who the sender thinks is the receiver. If the contents of this FSF are correct and acceptable to the receiver, the unchanged FSF is echoed back to the sender. This send/echo process is the only set of actions that allows the TCP Connection to be used to carry FC Fabric traffic. If the send and unchanged echo process does not occur, the algorithm followed at one or both ends of the TCP Connection results in the closure of the TCP Connection (see section 8.1 for specific algorithm requirements).
TCPから送信された最初のバイトは、受信機に要求イニシエータを接続は、送信者と送信者が考えていることは、受信機の両方を識別FSFあります。このFSFの内容が正しいと受信機に許容されている場合は、そのままFSFは、送信者にエコーバックされます。この送信/エコープロセスは、TCPコネクションがFCファブリックトラフィックを運ぶために使用することができますアクションのセットのみです。送信及び不変エコー処理が発生しない場合、アルゴリズムは、一つまたはTCP接続の閉鎖にTCP接続結果の両端（特定のアルゴリズムの要件についてはセクション8.1を参照）に続きます。
Note: Owing to the limited manner in which the FSF is used and the requirement that the FSF be echoed without changes before a TCP Connection is allowed to carry user data, no error checking beyond that provided by TCP is deemed necessary.
注：TCP接続は、ユーザデータを運ぶために許可される前に、FSFは変更せずにエコーさFSFが使用される限られた方法及び要件のために、TCPによって提供されるものを超えてチェックエラーが必要と判断されません。
As described above, the primary purpose of the FSF usage during TCP Connection setup is identifying the FCIP Link to which the new TCP Connection belongs. From these beginnings, it is only a small stretch to envision using the FSF as a simplified configuration discovery tool, and the mechanics of such a usage are described in section 8.1.
上述したように、TCP接続のセットアップ時にFSFの使用の主な目的は、新たなTCPコネクションが属するFCIPリンクを識別しています。これらの始まりから、簡易な構成発見ツールとしてFSFを使用して想像するだけの小さなストレッチであり、そのような使用の力学は、セクション8.1に記載されています。
However, use of the FSF for configuration discovery lacks the broad range of capabilities provided by SLPv2 and most particularly lacks the security capabilities of SLPv2. For these reasons, using the FSF for configuration discovery is not appropriate for all environments. Thus the choice to use the FSF for discovery purposes is a policy choice to be included in the TCP Connection Establishment "shared" database described in section 8.1.1.
ただし、構成発見のためFSFの使用はSLPv2のが提供する機能の広い範囲を欠いており、最も特にSLPv2ののセキュリティ機能を欠いています。これらの理由から、コンフィギュレーション・発見のためFSFを使用すると、すべての環境には適していません。従って、発見のためにFSFを使用するための選択肢は、セクション8.1.1で説明したTCP接続の確立「共有」データベースに含まれる方針の選択です。
When FSF-based configuration discovery is enabled, the normal TCP Connection setup rules outlined above are modified as follows.
FSFベースの構成発見が有効になっている場合、次のように、上記で概説した通常のTCP接続設定規則が修正されます。
Normally, the algorithm executed by an FCIP Entity receiving an FSF includes verifying that its own identification information in the arriving FSF is correct and closing the TCP Connection if it is not. This can be viewed as requiring the initiator of a TCP connect request to know in advance the identity of the FCIP Entity that is the target of that request (using SLP, for example), and through the FSF effectively saying, "I think I'm talking to X." If the party at the other end of the TCP connect request is really Y, then it simply hangs up.
通常、FSFを受信FCIPエンティティによって実行されるアルゴリズムは、到着FSFに自身の識別情報が正しいことを検証し、そうでない場合はTCP接続を閉じる含みます。これは、事前に（例えば、SLPを使用して）その要求のターゲットであるFCIPエンティティの身元を知っているTCP接続要求のイニシエータを必要と見て、FSFを通じて効果的に私は「だと思う」、と言ってすることができますM「X.に話しTCPのもう一方の端の当事者は、要求が実際にYで接続する場合、それは単に電話を切りました。
FSF-based discovery allows the "I think I'm talking to X" to be replaced with "Please tell me who I am talking to?", which is accomplished by replacing an explicit value in the Destination FC Fabric Entity World Wide Name field with zero.
FSFベースの検出は、先のFCファブリックエンティティのWorld Wide Name]フィールドに明示的な値を置き換えることにより実現され、「私が話している人を教えてください？」に置き換えられる「私はXに話していると思う」ことができますゼロと。
If the policy at the receiving FCIP Entity allows FSF-based discovery, the zero is replaced with the correct Destination FC Fabric Entity World Wide Name value in the echoed FSF. This is still subject to the rules of sending with unchanged echo, and so closure of TCP Connection occurs after the echoed FSF is received by the TCP connect initiator.
受信FCIPエンティティのポリシーはFSFベースの検出を可能にした場合、ゼロはエコーされFSFで正しい宛先FCファブリックエンティティのWorld Wide Nameの値に置き換えられます。これはまだ変わらず、エコーを送るのルールが適用され、そしてエコーFSFは、TCPイニシエータを接続することにより、受信された後、そのTCPコネクションの閉鎖が発生します。
Despite the TCP Connection closure, however, the TCP connect initiator now knows the correct Destination FC Fabric Entity World Wide Name identity of the FCIP Entity at a given IP Address and a subsequent TCP Connection setup sequence probably will be successful.
TCPコネクションの閉鎖にもかかわらず、しかし、TCPは、イニシエータを接続し、今与えられたIPアドレスとそれに続くTCPコネクション設定シーケンスでのFCIPエンティティの正しい宛先FCファブリックエンティティのワールドワイドネームのアイデンティティは、おそらく成功するだろう知っています。
The Ch bit in the pFlags field (see section 5.6.1) allows for differentiation between changes in the FSF resulting from transmission errors and changes resulting from intentional acts by the FSF recipient.
PFLAGSフィールド（セクション5.6.1を参照）中のCHのビットは、FSFの受信者による意図的な行為に起因する送信エラーに起因するFSFの変化と変化の間の区別を可能にします。
The description of the connection establishment process is a model for the interactions between an FC Entity and an FCIP Entity during TCP Connection establishment. The model is written in terms of a "shared" database that the FCIP Entity consults to determine the properties of the TCP Connections to be formed combined with routine calls to the FC Entity when connections are successfully established. Whether the FC Entity contributes information to the "shared" database is not critical to this model. However, the fact that the FCIP Entity MAY consult the database at any time to determine its actions relative to TCP Connection establishment is important.
接続確立プロセスの説明は、TCP接続確立時FCエンティティとFCIPエンティティとの間の相互作用のためのモデルです。モデルは、FCIPエンティティは、接続が正常に確立されているFCエンティティへのルーチン呼び出しと組み合わさ形成されるTCP接続の特性を決定するために調べ「共有」データベースの用語で記述されています。 FCエンティティは、「共有」のデータベースに情報を貢献するかどうかは、このモデルには重要ではありません。しかし、FCIPエンティティは、TCPコネクションの確立に対するそのアクションを決定するために任意の時点でデータベースを調べることができるという事実は重要です。
It is important to remember that this description is only a model for the interactions between an FC Entity and an FCIP Entity. Any implementation that has the same effects on the FC Fabric and IP Network as those described using the model meets the requirements of this specification. For example, an implementation might replace the "shared" database with a routine interface between the FC and FCIP Entities.
この説明はFCエンティティとFCIPエンティティ間の相互作用のための唯一のモデルであることを覚えておくことが重要です。モデルを使って説明したものとFCファブリックおよびIPネットワーク上で同じ効果を持つすべての実装は、この仕様書の要件を満たしています。例えば、実装はFCとFCIPエンティティ間のルーチンのインタフェースと「共有」のデータベースを置き換える可能性があります。
When an FCIP Entity discovers that a new TCP Connection needs to be established, it SHALL determine the IP Address to which the TCP Connection is to be made and establish all enabled IP security features for that IP Address as described in section 9. Then the FCIP Entity SHALL determine the following information about the new connection in addition to the IP Address:
FCIPエンティティが新しいTCPコネクションを確立する必要があることを発見した場合は、TCPコネクションが続い部9 FCIPで説明するように作られ、そのIPアドレスのための有効なすべてのIPセキュリティ機能を確立する対象のIPアドレスを決定するものエンティティは、IPアドレスに加えて、新たな接続に関する次の情報を決定しなければなりません。
- The expected Destination FC Fabric Entity World Wide Name of the FC/FCIP Entity pair to which the TCP Connection is being made
- FC / FCIPエンティティペアの予想先のFCファブリックエンティティワールドワイドネームTCPコネクションが作らされているに
- TCP Connection Parameters (see section 8.3)
- TCP接続パラメータ（セクション8.3を参照してください）
- Quality of Service Information (see section 10)
- サービス情報の品質は、（セクション10を参照します）
Based on this information, the FCIP Entity SHALL generate a TCP connect request [6] to the FCIP Well-Known Port of 3225 (or other configuration specific port number) at the specified IP Address.
この情報に基づいて、FCIPエンティティは、TCP接続要求を生成するものと[6]指定したIPアドレスで、3225のFCIP well-knownポート（または他の構成特定のポート番号）へ。
If the TCP connect request is rejected, the FCIP Entity SHALL act to limit unnecessary repetition of attempts to establish similar connections. For example, the FCIP Entity might wait 60 seconds before trying to re-establish the connection.
TCP接続要求が拒否された場合、FCIPエンティティは、同様の接続を確立しようとする試みの不必要な繰り返しを制限するように作用するものとします。たとえば、FCIPエンティティは、接続を再確立しようとする前に60秒待っかもしれません。
If the TCP connect request is accepted, the FCIP Entity SHALL follow the steps described in section 8.1.2.3 to complete the establishment of a new FCIP_DE.
TCP接続要求が受け入れられた場合、FCIPエンティティが新しいFCIP_DEの設立を完了するために、セクション8.1.2.3で説明する手順に従います。
It is RECOMMENDED that an FCIP Entity not initiate TCP connect requests to another FCIP Entity if incoming TCP connect requests from that FCIP Entity have already been accepted.
FCIPエンティティが着信TCPがFCIPエンティティが既に受け入れられていることからの要求を接続している場合、TCPは別のFCIPエンティティへの接続要求を開始しないことをお勧めします。
If dynamic discovery of participating FCIP Entities is supported, the function SHALL be performed using the Service Location Protocol (SLPv2) [17] in the manner defined for FCIP usage [20].
参加FCIPエンティティの動的検出がサポートされている場合、関数は、FCIPの使用のために定義された方法でサービスロケーションプロトコル（SLPv2の）[17] [20]を用いて行うことSHALL。
Upon discovering that dynamic discovery is to be used, the FCIP Entity SHALL enable IP security features for the SLP discovery process as described in [20] and then:
その動的な発見を発見することに使用される際に、次に、[20]とに記載されているように、FCIPエンティティSLP発見プロセスのためにIPセキュリティ機能を有効にしなければなりません。
1) Determine the one or more FCIP Discovery Domain(s) to be used in the dynamic discovery process;
1）動的な発見プロセスで使用される1つまたは複数のFCIPディスカバリドメイン（単数または複数）を決定します。
2) Establish an SLPv2 Service Agent to advertise the availability of this FCIP Entity to peer FCIP Entities in the identified FCIP Discovery Domain(s); and
2）特定さFCIPディスカバリードメイン（複数可）でのFCIPエンティティをピアにこのFCIPエンティティの可用性を宣伝するためにSLPv2のサービスエージェントを確立します。そして
3) Establish an SLPv2 User Agent to locate service advertisements for peer FCIP Entities in the identified FCIP Discovery Domain(s).
3）特定されFCIPディスカバリードメイン（複数可）でのピアFCIPエンティティのためのサービスの広告を見つけるためにSLPv2のユーザーエージェントを確立します。
For each peer FCIP Entity dynamically discovered through the SLPv2 User Agent, the FCIP Entity SHALL establish all enabled IP security features for the discovered IP Address as described in section 9 and then determine the following information about the new connection:
セクション9で説明してから、新しい接続に関する以下の情報を決定するので、それぞれに対してFCIPエンティティが動的にSLPv2のユーザエージェントによって発見されたピア、FCIPエンティティは、すべてが発見されたIPアドレスのIPセキュリティ機能を有効に確立しなければなりません。
- The expected Destination FC Fabric Entity World Wide Name of the FC/FCIP Entity pair to which the TCP Connection is being made
- FC / FCIPエンティティペアの予想先のFCファブリックエンティティワールドワイドネームTCPコネクションが作らされているに
- TCP Connection Parameters (see section 8.3)
- TCP接続パラメータ（セクション8.3を参照してください）
- Quality of Service Information (see section 10)
- サービス情報の品質は、（セクション10を参照します）
Based on this information, the FCIP Entity SHALL generate a TCP connect request [6] to the FCIP Well-Known Port of 3225 (or other configuration specific port number) at the IP Address specified by the service advertisement. If the TCP connect request is rejected, act to limit unnecessary repetition of attempts to establish similar connections. If the TCP connect request is accepted, the FCIP Entity SHALL follow the steps described in section 8.1.2.3 to complete the establishment of a new FCIP_DE.
この情報に基づいて、FCIPエンティティは、サービス広告で指定されたIPアドレスで、3225のFCIP well-knownポート（または他の構成特定のポート番号）へのTCP接続要求[6]を生成するものとします。 TCP接続要求が拒否された場合、同様の接続を確立しようとする試みの不必要な繰り返しを制限するように作用します。 TCP接続要求が受け入れられた場合、FCIPエンティティが新しいFCIP_DEの設立を完了するために、セクション8.1.2.3で説明する手順に従います。
It is recommended that an FCIP Entity not initiate TCP connect requests to another FCIP Entity if incoming TCP connect requests from that FCIP Entity have already been accepted.
FCIPエンティティが着信TCPがFCIPエンティティが既に受け入れられていることからの要求を接続している場合、TCPは別のFCIPエンティティへの接続要求を開始しないことをお勧めします。
Whether Non-Dynamic TCP Connection creation (see section 8.1.2.1) or Dynamic TCP Connection creation (see section 8.1.2.2) is used, the steps described in this section SHALL be followed to take the TCP Connection setup process to completion.
非動的TCPコネクションの作成（セクション8.1.2.1を参照）、またはダイナミックTCPコネクションの作成は（セクション8.1.2.2を参照）が使用されているかどうかは、このセクションで説明する手順は、完了するまでTCP接続のセットアッププロセスを取るために従わなければなりません。
After the TCP connect request has been accepted, the FCIP Entity SHALL send an FCIP Special Frame (FSF, see section 7) as the first bytes transmitted on the newly formed connection, and retain a copy of those bytes for later comparisons. All fields in the FSF SHALL be filled in as described in section 7, particularly:
TCP接続要求が受け入れられた後、FCIPエンティティ（FSFセクション7参照）FCIP特別フレームを送信し、新たに形成された接続上で送信される最初のバイトとして、および後で比較するためにこれらのバイトのコピーを保管しなければなりません。特に第7章に記載されているようにFSFのすべてのフィールドが記入されなければなりません。
- The Source FC Fabric Entity World Wide Name field SHALL contain the FC Fabric Entity World Wide Name for the FC/FCIP Entity pair that is originating the TCP connect request;
- ソースFCファブリックエンティティのWorld Wide Name]フィールドには、TCP接続要求を発信しているFC / FCIPエンティティペアのFCファブリックエンティティのWorld Wide Name]を含まなければなりません。
- The Source FC/FCIP Entity Identifier field SHALL contain a unique identifier that is assigned by the FC Fabric entity whose world wide name appears in the Source FC Fabric Entity World Wide Name field;
- ソースFC / FCIPエンティティの識別子フィールドは、そのワールドワイド名ソースFCファブリックエンティティのWorld Wide Nameフィールドに表示されますFCファブリックエンティティによって割り当てられた一意の識別子を含まなければなりません。
- The Connection Nonce field SHALL contain a 64-bit random number that differs in value from any recently used Connection Nonce value. In order to provide sufficient security for the connection nonce, the Randomness Recommendations for Security [9] SHOULD be followed; and
- 接続ノンスフィールドは、任意の最近使用された接続ノンス値から値が異なる64ビットの乱数を含まなければなりません。接続ナンスのために十分なセキュリティを提供するために、セキュリティのためのランダム推奨[9]に続くべきです。そして
- The Destination FC Fabric Entity World Wide Name field SHALL contain 0 or the expected FC Fabric Entity World Wide Name for the FC/FCIP Entity pair whose destination is the TCP connect request.
- デスティネーションFCファブリックエンティティのWorld Wide Name]フィールドには、宛先TCP接続要求をされたFC / FCIPエンティティペアの0または予想されるFCファブリックエンティティのWorld Wide Name]を含まなければなりません。
After the FSF is sent on the newly formed connection, the FCIP Entity SHALL wait for the FSF to be echoed as the first bytes received on the newly formed connection.
FSFは、新たに形成された接続上で送信された後、FCIPエンティティは、新たに形成された接続上で受信された最初のバイトとしてエコーするFSF待つSHALL。
The FCIP Entity MAY apply a timeout of not less than 90 seconds while waiting for the echoed FSF bytes. If the timeout expires, the FCIP Entity SHALL close the TCP Connection and notify the FC Entity with the reason for the closure.
エコーFSFのバイトを待っている間にFCIPエンティティが90秒未満ではないのタイムアウトを適用することができます。タイムアウトが満了すると、FCIPエンティティは、TCPコネクションを閉じ、閉鎖の理由でFCエンティティに通知しなければなりません。
If the echoed FSF bytes do not exactly match the FSF bytes sent (words 7 through 17 inclusive) or if the echoed Destination FC Fabric Entity World Wide Name field contains zero, the FCIP Entity SHALL close the TCP Connection and notify the FC Entity with the reason for the closure.
エコーFSFのバイトが正確にFSFの送信されたバイト（言葉7 17を含めて）、またはエコーされたデスティネーションFCファブリックエンティティのWorld Wide Nameフィールドにはゼロが含まれている場合、FCIPエンティティは、TCPコネクションを閉じてとFCエンティティに通知するものと一致しない場合閉鎖の理由。
The FCIP Entity SHALL only perform the following steps if the echoed FSF bytes exactly match the FSF bytes sent (words 7 through 17 inclusive).
エコーFSFは正確に（言葉7包括〜17）送られたFSFのバイトに一致するバイト場合FCIPエンティティにのみ、次の手順を実行しなければなりません。
1) Instantiate the appropriate Quality of Service (see section 10) conditions on the newly created TCP Connection,
1）、サービスの適切な品質を（セクション10を参照）、新しく作成されたTCPコネクション上の条件をインスタンス化
2) If the IP Address and TCP Port to which the TCP Connection was made is not associated with any other FCIP_LEP, create a new FCIP_LEP for the new FCIP Link,
2）TCPコネクションが行われたためにIPアドレスとTCPポートは、新しいFCIPリンクのための新しいFCIP_LEPを作成し、他のFCIP_LEPに関連付けられていない場合
3) Create a new FCIP_DE within the newly created FCIP_LEP to service the new TCP Connection, and
3）新しいTCP接続のサービスを提供するために、新しく作成されたFCIP_LEP内の新しいFCIP_DEを作成し、
4) Inform the FC Entity of the new FCIP_LEP, FCIP_DE, Destination FC Fabric Entity World Wide Name, Connection Usage Flags, and Connection Usage Code.
4）新しいFCIP_LEP、FCIP_DEのFCエンティティ、先のFCファブリックエンティティのWorld Wide名、接続使用フラグ、および接続の使用コードを通知します。
The FCIP Entity SHALL listen for new TCP Connection requests [6] on the FCIP Well-Known Port (3225). An FCIP Entity MAY also accept and establish TCP Connections to a TCP port number other than the FCIP Well-Known Port, as configured by the network administrator in a manner outside the scope of this specification.
FCIPエンティティは、FCIP既知のポート（3225）の[6]新しいTCP接続要求をリッスンものとします。 FCIPエンティティも受け入れ、この仕様の範囲外の方法でネットワーク管理者によって設定され、FCIP、well-knownポート以外のTCPポート番号にTCPコネクションを確立することができます。
The FCIP Entity SHALL determine the following information about the requested connection:
FCIPエンティティは、要求された接続に関する次の情報を決定しなければなりません。
- Whether the "shared" database (see section 8.1.1) allows the requested connection
- 「共有」データベース（セクション8.1.1を参照）が要求された接続を許可するかどうか
- Whether IP security setup has been performed for the IP security features enabled on the connection (see section 9)
- IPセキュリティの設定が接続で有効IPセキュリティ機能のために行われているかどうか（セクション9を参照してください）
If the requested connection is not allowed, the FCIP Entity SHALL reject the connect request using appropriate TCP means. If the requested connection is allowed, the FC Entity SHALL ensure that required IP security features are enabled and accept the TCP connect request.
要求された接続が許可されていない場合は、FCIPエンティティは、適切なTCPの手段を用いて接続要求を拒否しなければなりません。要求された接続が許可されている場合、FCエンティティは、必要なIPのセキュリティ機能が有効になっていることを確認し、TCP接続要求を受け入れるものとします。
After the TCP connect request has been accepted, the FCIP Entity SHALL wait for the FSF sent by the originator of the TCP connect request (see section 8.1.2) as the first bytes received on the accepted connection.
TCP接続要求が受け入れられた後、FCIPエンティティは、最初のバイトが受け入れ接続上で受信される（セクション8.1.2参照）TCP接続要求の発信元によって送信されたFSF待つSHALL。
The FCIP Entity MAY apply a timeout of no less than 90 seconds while waiting for the FSF bytes. If the timeout expires, the FCIP Entity SHALL close the TCP Connection and notify the FC Entity with the reason for the closure.
FSFのバイトを待っている間にFCIPエンティティは、劣らず90秒以上のタイムアウトを適用することができます。タイムアウトが満了すると、FCIPエンティティは、TCPコネクションを閉じ、閉鎖の理由でFCエンティティに通知しなければなりません。
Note: One method for attacking the security of the FCIP Link formation process (detailed in section 9.1) depends on keeping a TCP connect request open without sending an FSF. Implementations should bear this in mind in the handling of TCP connect requests where the FSF is not sent in a timely manner.
注：（セクション9.1で詳述）FCIPリンク形成プロセスのセキュリティを攻撃するための一つの方法は、FSFを送信せずに開いているTCP接続要求を維持するに依存します。実装は、TCPの取り扱いには注意して負うべきFSFがタイムリーに送信されていない要求を接続します。
Upon receipt of the FSF sent by the originator of the TCP connect request, the FCIP Entity SHALL inspect the contents of the following fields:
TCPの発信要求を接続することにより、送信されたFSFを受信すると、FCIPエンティティは、次のフィールドの内容を検査しなければなりません。
- Connection Nonce, - Destination FC Fabric Entity World Wide Name, - Connection Usage Flags, and - Connection Usage Code.
- 接続ナンス、 - デスティネーションFCファブリックエンティティのワールドワイドネーム、 - 接続の使用フラグ、および - 接続使用コード。
If the Connection Nonce field contains a value identical to the most recently received Connection Nonce from the same IP Address, the FCIP Entity SHALL close the TCP Connection and notify the FC Entity with the reason for the closure.
接続ナンスフィールドが同じIPアドレスから最後に受信した接続ナンスに値が同一含まれている場合は、FCIPエンティティは、TCPコネクションを閉じ、閉鎖の理由でFCエンティティに通知しなければなりません。
If an FCIP Entity receives a duplicate FSF during the FCIP Link formation process, it SHALL close that TCP Connection and notify the FC Entity with the reason for the closure.
FCIPエンティティは、FCIPリンク形成プロセス中に重複FSFを受信した場合、そのTCPコネクションを閉じ、閉鎖の理由でFCエンティティに通知しなければなりません。
If the Destination FC Fabric Entity World Wide Name contains 0, the FCIP Entity SHALL take one of the following three actions:
先のFCファブリックエンティティのWorld Wide Nameは0が含まれている場合は、FCIPエンティティは、以下の3つのいずれかのアクションをとります。
1) Leave the Destination FC Fabric Entity World Wide Name field and Ch bit both 0;
1）両方の0デスティネーションFCファブリックエンティティのWorld Wide NameフィールドとChのビットを残します。
2) Change the Destination FC Fabric Entity World Wide Name field to match FC Fabric Entity World Wide Name associated with the FCIP Entity that received the TCP connect request and change the Ch bit to 1; or
2）TCP接続要求をし、1にChのビットを変更する受信FCIPエンティティに関連付けられたFCファブリックエンティティのWorld Wide名と一致するように、先のFCファブリックエンティティのWorld Wide Name]フィールドを変更します。または
3) Close the TCP Connection without sending any response.
3）任意の応答を送信せずにTCPコネクションを閉じます。
The choice between the above actions depends on the anticipated usage of the FCIP Entity. The FCIP Entity may consult the "shared" database when choosing between the above actions.
上記のアクションの間の選択は、FCIPエンティティの予想される使用方法に依存します。上記のアクション間で選択する際FCIPエンティティは、「共有」データベースを協議することができます。
If: a) The Destination FC Fabric Entity World Wide Name contains a non-zero value that does not match the FC Fabric Entity World Wide Name associated with the FCIP Entity that received the TCP connect request, or
場合は、a）先のFCファブリックエンティティのWorld Wide Nameは、TCP接続要求を受けたFCIPエンティティに関連付けられたFCファブリックエンティティのWorld Wide名と一致しないゼロ以外の値が含まれていますか
b) The contents of the Connection Usage Flags and Connection Usage Code fields is not acceptable to the FCIP Entity that received the TCP connect request, then the FCIP Entity SHALL take one of the following two actions:
B）接続使用フラグと接続使用コードフィールドの内容は、TCP接続要求を受けたFCIPエンティティに受け入れられない場合、FCIPエンティティは、次の2つのいずれかのアクションをとります。
1) Change the contents of the unacceptable fields to correct/ acceptable values and set the Ch bit to 1; or
1）/許容可能な値を修正し、1 Chのビットを設定することが許容されないフィールドの内容を変更します。または
2) Close the TCP Connection without sending any response.
2）任意の応答を送信せずにTCPコネクションを閉じます。
If the FCIP Entity makes any changes in the content of the FSF, it SHALL also set the Ch bit to 1.
FCIPエンティティは、FSFの内容の変更を行った場合、それはまた、1にChのビットを設定しなければなりません。
If any changes have been made in the received FSF during the processing described above, the following steps SHALL be performed:
すべての変更は、上述の処理中に受信したFSFになされている場合は、以下のステップが実行されなければなりません。
1) The changed FSF SHALL be echoed to the originator of the TCP connect request as the only bytes transmitted on the accepted connection;
1）変更FSFが受け付けられた接続上で送信のみバイトとして要求をTCP接続の発信元にエコーしなければなりません。
2) The TCP Connection SHALL be closed (the FC Entity need not be notified of the TCP Connection closure in this case because it is not indicative of an error); and
2）TCP接続が（FCエンティティ）は、それがエラーを示すものではないため、この場合のTCP接続の閉鎖を通知する必要はない閉じなければなりません。そして
3) All of the additional processing described in this section SHALL be skipped.
3）このセクションで説明する追加の処理の全てをスキップすることSHALL。
The remaining steps in this section SHALL be performed only if the FCIP Entity has not changed the contents of the above mentioned fields to correct/acceptable values.
FCIPエンティティ/許容可能な値を修正するために、上述したフィールドの内容を変更していない場合にのみ、このセクションの残りのステップが実行されなければなりません。
If the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier field values in the FSF do not match the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier associated with any other FCIP_LEP, the FCIP Entity SHALL:
FSFでソースFCファブリックエンティティのWorld Wide NameとソースFC / FCIP実体識別子フィールド値が他のFCIP_LEPに関連付けられているソースFCファブリックエンティティのWorld Wide NameとソースFC / FCIPエンティティの識別子と一致しない場合は、FCIPエンティティがなければなりません。
1) Echo the unchanged FSF to the originator of the TCP connect request as the first bytes transmitted on the accepted connection;
1）受け入れられた接続上で送信される最初のバイトとして接続要求TCPの発信者に不変のFSFをエコー。
2) Instantiate the appropriate Quality of Service (see section 10.2) conditions on the newly created TCP Connection, considering the Connection Usage Flags and Connection Usage Code fields, and "shared" database information (see section 8.1.1) as appropriate,
2）適切なサービス品質（10.2節を参照してください）新しく作成されたTCPコネクション上の条件、接続使用フラグと接続使用コードフィールドを考慮し、「共有」データベース情報（セクション8.1.1を参照）などの適切なを、インスタンス化
3) Create a new FCIP_LEP for the new FCIP Link,
3）、新しいFCIPリンクのための新しいFCIP_LEPを作成します。
4) Create a new FCIP_DE within the newly created FCIP_LEP to service the new TCP Connection, and
4）新しいTCP接続のサービスを提供するために、新しく作成されたFCIP_LEP内の新しいFCIP_DEを作成し、
5) Inform the FC Entity of the new FCIP_LEP, FCIP_DE, Source FC Fabric Entity World Wide Name, Source FC/FCIP Entity Identifier, Connection Usage Flags, and Connection Usage Code.
5）FCエンティティ新しいFCIP_LEP、FCIP_DE、ソースFCファブリックエンティティのワールドワイド名、ソースFC / FCIPエンティティの識別子、接続使用フラグ、および接続の使用コードを通知します。
If the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier field values in the FCIP Special Frame match the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier associated with an existing FCIP_LEP, the FCIP Entity SHALL:
FCIP特殊フレームにおけるソースFCファブリックエンティティのWorld Wide NameとソースFC / FCIPエンティティの識別子フィールドの値は、既存のFCIP_LEPに関連付けられているソースFCファブリックエンティティのWorld Wide NameとソースFC / FCIPエンティティの識別子と一致する場合、FCIPエンティティがなければなりません。
1) Request that the FC Entity authenticate the source of the TCP connect request (see FC-BB-2 [3]), providing the following information to the FC Entity for authentication purposes: a) Source FC Fabric Entity World Wide Name, b) Source FC/FCIP Entity Identifier, and c) Connection Nonce.
1）FCエンティティは、TCP接続要求の送信元を認証要求は、（参照FC-BB-2 [3]）、認証目的のためにFCエンティティに以下の情報を提供する：a）ソースFCファブリックエンティティのWorld Wide名、B ）ソースFC / FCIPエンティティ識別子、およびc）接続ナンス。
The FCIP Entity SHALL NOT use the new TCP Connection for any purpose until the FC Entity authenticates the source of the TCP connect request. If the FC Entity indicates that the TCP connect request cannot be properly authenticated, the FCIP Entity SHALL close the TCP Connection and skip all of the remaining steps in this section.
FCエンティティは、TCP接続要求の送信元を認証するまで、FCIPエンティティは、いかなる目的のために新しいTCP接続を使用してはなりません。 FCエンティティは、TCPが接続されていることを示している場合、要求が正しく認証することができない、FCIPエンティティは、TCPコネクションを閉じて、このセクションの残りの手順をすべてスキップするものとします。
The definition of the FC Entity SHALL include an authentication mechanism for use in response to a TCP connect request source that communicates with the partner FC/FCIP Entity pair on an existing FCIP Link. This authentication mechanism should use a previously authenticated TCP Connection in the existing FCIP Link to authenticate the Connection Nonce sent in the new TCP Connection setup process. The FCIP Entity SHALL treat failure of this authentication as an authentication failure for the new TCP Connection setup process.
FCエンティティの定義は、既存のFCIPリンク上のパートナーFC / FCIPエンティティペアと通信を要求元のTCP接続に応じて、使用する認証メカニズムを含まなければなりません。この認証機構は、nonceが新しいTCP接続のセットアッププロセスで送信された接続を認証するために、既存のFCIPリンクで以前に認証されたTCP接続を使用する必要があります。 FCIPエンティティは、新しいTCP接続のセットアッププロセスの認証失敗として、この認証の失敗を扱うものとします。
2) Echo the unchanged FSF to the originator of the TCP connect request as the first bytes transmitted on the accepted connection;
2）受け入れられた接続上で送信される最初のバイトとして接続要求TCPの発信者に不変のFSFをエコー。
3) Instantiate the appropriate Quality of Service (see section 10.2) conditions on the newly created TCP Connection, considering the Connection Usage Flags and Connection Usage Code fields, and "shared" database information (see section 8.1.1) as appropriate,
3）適切なサービス品質（10.2節を参照してください）新しく作成されたTCPコネクション上の条件、接続使用フラグと接続使用コードフィールドを考慮し、「共有」データベース情報（セクション8.1.1を参照）などの適切なを、インスタンス化
4) Create a new FCIP_DE within the existing FCIP_LEP to service the new TCP Connection, and
4）新しいTCPコネクションにサービスを提供するために、既存のFCIP_LEP内の新しいFCIP_DEを作成し、
5) Inform the FC Entity of the FCIP_LEP, Source FC Fabric Entity World Wide Name, Source FC/FCIP Entity Identifier, Connection Usage Flags, Connection Usage Code, and new FCIP_DE.
5）FCIP_LEPのFCエンティティ、ソースFCファブリックエンティティのWorld Wide名、ソースFC / FCIPエンティティの識別子、接続使用フラグ、接続使用コード、および新しいFCIP_DEを通知します。
Note that the originator of TCP connect requests uses the IP Address and TCP Port to identify which TCP Connections belong to which FCIP_LEPs while the recipient of TCP connect requests uses the Source FC Fabric Entity World Wide Name, and Source FC/FCIP Entity Identifier fields from the FSF to identify which TCP Connection belong to which FCIP_LEPs. For this reason, an FCIP Entity that both originates and receives TCP connect requests is unable to match the FCIP_LEPs associated with originated TCP connect requests to the FCIP_LEPs associated with received TCP connect requests.
TCPの発信元が要求を接続することに注意してくださいTCPの受信者が要求を接続している間の接続がFCIP_LEPsいるに属するTCP識別するために、IPアドレスとTCPポートを使用していますから、ソースFCファブリックエンティティのワールドワイドネームを使用し、ソースFC / FCIPエンティティの識別子フィールドどのFCIP_LEPs属しているTCPコネクションを識別するためにFSF。このため、両方の発信および受信TCPが要求を接続することFCIPエンティティは、TCPはTCPの接続要求を受けたに関連付けられているFCIP_LEPsへの接続要求を発し関連付けられたFCIP_LEPsと一致することができません。
If two FCIP Entities perform simultaneous open operations, then two TCP Connections are formed and the SF originates at one end on one connection and at the other end on the other. Connection setup proceeds as described above on both connections, and the steps described above properly result in the formation of two FCIP Links between the same FCIP Entities.
2つのFCIPエンティティが同時オープンの操作を行う場合、2つのTCP接続が形成され、SFは、一つの接続上の一端で、その他にもう一方の端で発生しています。接続設定両方の接続に上記のように進行し、上記適切同じFCIPエンティティ間の2つのFCIPリンクの形成をもたらすの工程。
This is not an error. Fibre Channel is perfectly capable of handling two approximately equal connections between FC Fabric elements.
これはエラーではありません。ファイバチャネルは、FCファブリック要素間のほぼ等しい2つの接続を処理する完全に可能です。
The decision to setup pairs of FCIP Links in this manner is considered to be a site policy decision that can be covered in the "shared" database described in section 8.1.1.
このようにFCIPリンクの設定ペアに決定は、セクション8.1.1に記載されている「共有」データベースにカバーすることができるサイトの政策決定であると考えられています。
The FCIP Entity SHALL provide a mechanism with acknowledgement by which the FC Entity is able to cause the closing of an existing TCP Connection at any time. This allows the FC Entity to close TCP Connections that are producing too many errors, etc.
FCIPエンティティは、FCエンティティは、任意の時点で、既存のTCPコネクションの閉鎖を引き起こすことができるとすることにより、確認応答とメカニズムを提供しなければなりません。これは、あまりにも多くのエラーを生産しているTCPコネクションなどを閉鎖するFCエンティティを可能に
In order to provide efficient management of FCIP_LEP resources as well as FCIP Link resources, consideration of certain TCP Connection parameters is recommended.
効率的なFCIP_LEP資源の管理だけでなく、FCIPリンクのリソースを提供するために、特定のTCP接続のパラメータを考慮することをお勧めします。
The Selective Acknowledgement option RFC 2883 [18] allows the receiver to acknowledge multiple lost packets in a single ACK, enabling faster recovery. An FCIP Entity MAY negotiate use of TCP SACK and use it for faster recovery from lost packets and holes in TCP sequence number space.
選択確認応答オプションRFC 2883 [18]は迅速な復旧を可能に、受信機は、単一のACKで複数の失われたパケットを確認することができます。 FCIPエンティティは、TCP SACKの使用を交渉し、失われたパケットとTCPシーケンス番号空間の穴からの迅速な復旧のためにそれを使用するかもしれません。
The TCP Window Scale option [8] allows TCP window sizes larger than 16-bit limits to be advertised by the receiver. It is necessary to allow data in long fat networks to fill the available pipe. This also implies buffering on the TCP sender that matches the (bandwidth*delay) product of the TCP Connection. An FCIP_LEP uses locally available mechanisms to set a window size that matches the available local buffer resources and the desired throughput.
TCPウィンドウスケールオプションは、[8] TCPウィンドウは、受信機によって通知される16ビットの限界より大きいサイズ可能にします。長い脂肪ネットワーク内のデータが利用できるパイプを埋めるためにできるようにする必要があります。また、これは、TCPコネクションの（帯域幅*遅延）製品と一致するTCP送信側でバッファリングを意味します。 FCIP_LEPは、利用可能なローカルバッファリソースおよび所望のスループットに一致するウィンドウサイズを設定するために局所的に使用可能なメカニズムを使用します。
It is RECOMMENDED that FCIP Entities implement protection against wrapped sequence numbers PAWS [8]. It is quite possible that within a single connection, TCP sequence numbers wrap within a timeout window.
FCIPエンティティが包まれたシーケンス番号PAWS [8]に対する保護を実装することをお勧めします。単一の接続中に、TCPシーケンス番号がタイムアウトウィンドウ内で折り返すことにかなり可能です。
FCIP Entities should disable the Nagle Algorithm as described in RFC 1122 [7] section 4.2.3.4. By tradition, this can be accomplished by setting the TCP_NODELAY option to one at the local TCP interface.
RFC 1122 [7]のセクション4.2.3.4に記載されるようにFCIPエンティティはNagleアルゴリズムを無効にする必要があります。伝統では、これはローカルのTCPインタフェースで一つにTCP_NODELAYオプションを設定することによって達成することができます。
In idle mode, a TCP Connection "keep alive" option of TCP is normally used to keep a connection alive. However, this timeout is fairly large and may prevent early detection of loss of connectivity. In order to facilitate faster detection of loss of connectivity, FC Entities SHOULD implement some form of Fibre Channel connection failure detection (see FC-BB-2 [3]).
アイドルモードでは、TCPコネクションは、TCPのオプションは、通常アライブ接続を維持するために使用される「キープアライブ」。しかし、このタイムアウトはかなり大きく、接続性の損失の早期発見を防ぐことができます。接続性の損失のより速い検出を容易にするために、FCエンティティは、ファイバー・チャネル接続故障検出のいくつかのフォームを実装する必要がある（FC-BB-2 [3]）。
When an FCIP Entity discovers that TCP connectivity has been lost, the FCIP Entity SHALL notify the FC Entity of the failure including information about the reason for the failure.
FCIPエンティティは、TCP接続が失われたことを検出すると、FCIPエンティティは、失敗の理由についての情報を含め、障害のFCエンティティに通知しなければなりません。
The FCIP Entity and FC Entity are connected to the IP Network and FC Fabric, respectively, and they need to follow the flow control mechanisms of both TCP and FC, which work independently of each other.
FCIPエンティティとFCエンティティは、それぞれIPネットワークとFCファブリックに接続され、それらは互いに独立して動作するTCPとFCの両方のフロー制御メカニズムを追従する必要があります。
This section provides guidelines as to how the FCIP Entity can map TCP flow control to status notifications to the FC Entity.
このセクションでは、FCIPエンティティがFCエンティティへのステータス通知にTCPフロー制御をマッピングすることができる方法についてのガイドラインを提供します。
There are two scenarios in which the flow control management becomes crucial:
フロー制御管理が重要となっている2つのシナリオがあります。
1) When there is line speed mismatch between the FC and IP interfaces.
1）FCとIPインターフェイス間の回線速度のミスマッチがある場合。
Even though it is RECOMMENDED that both of the FC and IP interfaces to the FC Entity and FCIP Entity, respectively, be of comparable speeds, it is possible to carry FC traffic over an IP Network that has a different line speed and bit error rate.
FCエンティティとFCIPエンティティへのFCとIPインターフェイスの両方は、それぞれ、同等の速度であることが推奨されていても、異なるライン速度及びビットエラーレートを有するIPネットワーク上のFCトラフィックを伝送することが可能です。
2) When the FC Fabric or IP Network encounters congestion.
2）FCファブリックやIPネットワークの輻輳を検出した場合。
Even when both the FC Fabric or IP network are of comparable speeds, during the course of operation, the FC Fabric or the IP Network could encounter congestion due to transient conditions.
FCファブリックやIPネットワークの両方が同等の速度である場合でも、操作の途中で、FCファブリックやIPネットワークによる過渡状態に輻輳が発生する可能性があります。
The FC Entity uses Fibre Channel mechanisms for flow control at the FC Frame Receiver Portal based on information supplied by the FCIP Entity regarding flow constraints at the Encapsulated Frame Transmitter Portal. The FCIP Entity uses TCP mechanisms for flow control at the Encapsulated Frame Receiver Portal based on information supplied by the FC Entity regarding flow constraints at the FC Frame Transmitter Portal.
FCエンティティは、カプセル化されたフレームトランスミッタポータルでの流れの制約に関するFCIPエンティティによって提供された情報に基づいて、FCフレームレシーバーポータルでのフロー制御のためのファイバー・チャネル・メカニズムを使用しています。 FCIPエンティティは、カプセル化されたフレームFCフレーム送信ポータルにおける流れの制約に関するFCエンティティによって供給される情報に基づいて受信機ポータルにおけるフロー制御のためのTCPメカニズムを使用します。
Coordination of these flow control mechanisms, one of which is credit based and the other of which is window based, depends on a painstaking design that is outside the scope of this specification.
ウィンドウベースとなっているクレジットが基づいている一つは、これらのフロー制御メカニズム、および他の調整は、本明細書の範囲外である骨の折れる設計に依存します。
FCIP utilizes the IPsec protocol suite to provide data confidentiality and authentication services, and IKE as the key management protocol. This section describes the requirements for various components of these protocols as used by FCIP, based on FCIP operating environments. Additional consideration for use of IPsec and IKE with the FCIP protocol can be found in [21]. In the event that requirements in [21] conflict with requirements stated in this document, the requirements in this document SHALL prevail.
FCIPは、鍵管理プロトコルとして、データの機密性と認証サービスを提供するために、IPsecプロトコルスイートを利用し、IKE。 FCIPの動作環境に基づいて、FCIPによって使用されるこのセクションでは、これらのプロトコルの様々な構成要素の要件を記載しています。 FCIPプロトコルIPsecとIKEを使用するための追加の考慮事項は、[21]に見出すことができます。この文書に記載されている要件を持つ[21]競合の要求は、この文書の要件が優先するものイベントで。
Using a general purpose, wide-area network, such as an IP Network, as a functional replacement for physical cabling introduces some security problems not normally encountered in Fibre Channel Fabrics. FC interconnect cabling is typically protected physically from outside access. Public IP Networks allow hostile parties to impact the security of the transport infrastructure.
物理的なケーブル接続のための機能の交換は、通常、ファイバチャネルファブリックに遭遇していないいくつかのセキュリティ上の問題を紹介したように、このようなIPネットワークなどの汎用、広域ネットワークを使用。 FC相互接続ケーブルは、典型的には、外部アクセスから物理的に保護されます。公衆IPネットワークは、敵対的な当事者が輸送インフラのセキュリティに影響を与えることができます。
The general effect is that the security of an FC Fabric is only as good as the security of the entire IP Network that carries the FCIP Links used by that FC Fabric. The following broad classes of attacks are possible:
一般的な効果は、FCファブリックのセキュリティは、そのFCファブリックが使用するFCIPリンクを運ぶ全体のIPネットワークのセキュリティと同じくらい良いということです。攻撃の次の広いクラスが可能です。
1) Unauthorized Fibre Channel elements can gain access to resources through normal Fibre Channel Fabric and processes. Although this is a valid threat, securing the Fibre Channel Fabrics is outside the scope of this document. Securing the IP Network is the issue considered in this specification.
1）不正なファイバチャネル要素は、通常のファイバチャネルファブリックとプロセスを通じて、リソースへのアクセスを得ることができます。これが有効な脅威ですが、ファイバーチャネルファブリックを確保することは、この文書の範囲外です。 IPネットワークのセキュリティ保護することは、この仕様書で考慮問題です。
2) Unauthorized agents can monitor and manipulate Fibre Channel traffic flowing over physical media used by the IP Network and accessible to the agent.
2）不正なエージェントは、IPネットワークとエージェントへのアクセスが使用する物理メディア上を流れるファイバチャネルトラフィックを監視し、操作することができます。
3) TCP Connections may be hijacked and used to instantiate an invalid FCIP Link between two peer FCIP Entities.
3）TCP接続をハイジャックし、2つのピアFCIPエンティティ間無効FCIPリンクをインスタンス化するために使用することができます。
4) Valid and invalid FCIP Frames may be injected on the TCP Connections.
4）有効および無効FCIPフレームは、TCP接続に注入することができます。
5) The payload of an FCIP Frame may be altered or transformed. The TCP checksum, FCIP ones complement checks, and FC frame CRC do not protect against this because all of them can be modified or regenerated by a malicious and determined adversary.
5）FCIPフレームのペイロードは、変更または変形することができます。 TCPチェックサムは、FCIPのものはチェックを補完し、それらのすべてが変更または悪意のあると決定した敵によって再生することができるので、FCフレームのCRCは、この保護することはできません。
6) Unauthorized agents can masquerade as valid FCIP Entities and disturb proper operation of the Fibre Channel Fabric.
6）不正なエージェントは、有効なFCIPエンティティをマスカレードおよびファイバチャネルファブリックの適切な動作を妨げることができます。
7) Denial of Service attacks can be mounted by injecting TCP Connection requests and other resource exhaustion operations.
7）サービス妨害攻撃は、TCP接続要求およびその他のリソースの枯渇操作を注入することにより、マウントすることができます。
8) An adversary may launch a variety of attacks against the discovery process [17].
8）敵対者は発見プロセス[17]に対する攻撃の多様を起動してもよいです。
9) An attacker may exploit the FSF authentication mechanism of the FCIP Link formation process (see section 8.1.3). The attacker could observe the FSF contents sent on an initial connection of an FCIP Link and use the observed nonce, Source FC/FCIP Entity Identifier, and other FSF contents to form an FCIP Link using the attacker's own previously established connection, while resetting/blocking the observed connection. Although the use of timeout for reception of FSF reduces the risk of this attack, such an attack is possible. See section 9.3.1 to protect against this specific attack.
9）攻撃者は、FCIPリンク形成プロセスのFSF認証機構（セクション8.1.3を参照）を利用することができます。攻撃者は、FCIPリンクの初期接続に送られたFSFの内容を観察し、攻撃者自身の以前に確立された接続を使用してFCIPリンクを形成するために観測されたナンス、ソースFC / FCIPエンティティの識別子、およびその他のFSFの内容を使用し、リセット/ブロックしながらでした観察接続。 FSFの受信のためのタイムアウトを使用するが、この攻撃のリスクを低減しますが、このような攻撃が可能です。この特定の攻撃から保護するためにセクション9.3.1を参照してください。
The existing IPsec Security Architecture and protocol suite [10] offers protection from these threats. An FCIP Entity MUST implement portions of the IPsec protocol suite as described in this section.
既存のIPsecセキュリティアーキテクチャとプロトコルスイート[10]は、これらの脅威からの保護を提供しています。このセクションで説明するようにFCIPエンティティは、IPsecプロトコルスイートの一部を実装しなければなりません。
In the context of enabling a secure FCIP tunnel between FC SANs, the following characteristics of the IP Network deployment are useful to note.
FC SANの間の安全なFCIPトンネルを可能にする文脈において、IPネットワークの展開の次の特性に注意するのに有用です。
1) The FCIP Entities share a peer-to-peer relationship. Therefore, the administration of security policies applies to all FCIP Entities in an equal manner. This differs from a true Client-Server relationship, where there is an inherent difference in how security policies are administered.
1）FCIPエンティティは、ピア・ツー・ピア関係を共有します。そのため、セキュリティポリシーの投与は、同じ方法で、すべてのFCIPエンティティに適用されます。これは、セキュリティポリシーが投与される方法に固有の差がある真のクライアントサーバーの関係とは異なります。
2) Policy administration as well as security deployment and configuration are constrained to the set of FCIP Entities, thereby posing less of a requirement on a scalable mechanism. For example, the validation of credentials can be relaxed to the point where deploying a set of pre-shared keys is a viable technique.
2）ポリシー管理、ならびにセキュリティの配置及び構成は、これにより、スケーラブルな機構上の要件の少ないポーズ、FCIPエンティティのセットに制約されます。例えば、資格情報の検証は、事前共有鍵のセットを展開する実行可能な技術である点に緩和することができます。
3) TCP Connections and the IP Network are terminated at the FCIP Entity. The granularity of security implementation is at the level of the FCIP tunnel endpoint (or FCIP Entity), unlike other applications where there is a user-level termination of TCP Connections. User-level objects are not controllable by or visible to FCIP Entities. All user-level security related to FCIP is the responsibility of the Fibre Channel standards and is outside the scope of this specification.
3）TCP接続とIPネットワークは、FCIPエンティティで終端されています。セキュリティ実装の粒度は、TCP接続のユーザーレベルの終端がある他のアプリケーションとは異なり、FCIPトンネルエンドポイント（またはFCIPエンティティ）のレベルです。ユーザーレベルのオブジェクトは、FCIPエンティティにすることによって制御または表示されません。 FCIPに関連するすべてのユーザーレベルのセキュリティは、ファイバチャネル規格の責任であり、この仕様の範囲外です。
4) When an FCIP Entity is deployed, its IP addresses will typically be statically assigned. However, support for dynamic IP address assignment, as described in [33], while typically not required, cannot be ruled out.
FCIPエンティティが配備されている場合4）、そのIPアドレスは、典型的には、静的に割り当てられます。 [33]に記載されているように、典型的には必要ないがしかし、動的IPアドレスの割り当てのためのサポートは、除外することはできません。
FCIP Security compliant implementations MUST implement ESP and the IPsec protocol suite based cryptographic authentication and data integrity [10], as well as confidentiality using algorithms and transforms as described in this section. Also, FCIP implementations MUST meet the secure key management requirements of IPsec protocol suite.
FCIPセキュリティ準拠の実装は、ESPおよびIPsecプロトコルスイート基づく暗号認証およびデータ完全性[10]、ならびに機密使用してアルゴリズムを実装し、このセクションで説明するように変換しなければなりません。また、FCIPの実装は、IPsecプロトコルスイートの安全な鍵管理要件を満たす必要があります。
FCIP Entities MUST implement IPsec ESP [12] in Tunnel Mode for providing Data Integrity and Confidentiality. FCIP Entities MAY implement IPsec ESP in Transport Mode, if deployment considerations require use of Transport Mode. When ESP is utilized, per-packet data origin authentication, integrity, and replay protection MUST be used.
FCIPエンティティは、データ整合性と機密性を提供するためのトンネルモードのIPsec ESP [12]を実装しなければなりません。展開の考慮事項は、転送モードを使用する必要があればFCIPエンティティは、トランスポートモードでIPsecのESPを実施することができます。 ESPを利用する場合、パケット単位のデータ発信元認証、完全性、および再生保護を使用しなければなりません。
If Confidentiality is not enabled but Data Integrity is enabled, ESP with NULL Encryption [15] MUST be used.
機密性が有効になっていないが、データの整合性が有効になっている場合は、NULL暗号化とESP [15]は使用しなければなりません。
IPsec ESP for message authentication computes a cryptographic hash over the payload that is protected. While IPsec ESP mandates compliant implementations to support certain algorithms for deriving this hash, FCIP implementations:
メッセージ認証用のIPsec ESPは、保護されたペイロードに対する暗号化ハッシュを計算します。 IPsecのESPは、このハッシュを導出するための特定のアルゴリズムをサポートするために準拠した実装を義務付けている間、FCIPの実装：
- MUST implement HMAC with SHA-1 [11] - SHOULD implement AES in CBC MAC mode with XCBC extensions [23] - DES in CBC mode SHOULD NOT be used due to inherent weaknesses
- SHA-1 [11]とHMACを実装しなければなりません - XCBC拡張子[23]を用いてCBC MACモードでAESを実装する必要 - CBCモードでのDESが原因固有の弱点には使用しないでください
For ESP Confidentiality, FCIP Entities:
ESP機密性のために、FCIPエンティティ：
- MUST implement 3DES in CBC mode [16] - SHOULD implement AES in CTR mode [22] - MUST implement NULL Encryption [15]
- CBCモードで3DESを実装しなければならない[16] - CTRモードでAESを実装する必要があり[22] - NULL暗号化を実装しなければならない[15]
FCIP Entities MUST support IKE [14] for peer authentication, negotiation of Security Associations (SA), and Key Management using the IPsec DOI [13]. Manual keying SHALL NOT be used for establishing an SA since it does not provide the necessary elements for rekeying (see section 9.3.3). Conformant FCIP implementations MUST support peer authentication using pre-shared keys and MAY support peer authentication using digital certificates. Peer authentication using public key encryption methods outlined in IKE [14] sections 5.2 and 5.3 SHOULD NOT be used.
FCIPエンティティは、IPsec DOIを使用してピア認証、セキュリティアソシエーション（SA）の交渉、およびキー管理のための[13] IKE [14]をサポートしなければなりません。それが鍵の再生成のために必要な要素を提供していないので、手動キーイング（セクション9.3.3を参照）SAを確立するために使用してはなりません。適合FCIP実装は、事前共有キーを使用してピア認証をサポートしなければならなくて、デジタル証明書を使用してピア認証をサポートするかもしれません。 [14]のセクション5.2と5.3をIKEに概説された公開鍵暗号方式を使用してピア認証を使用しないでください。
IKE Phase 1 establishes a secure, MAC-authenticated channel for communications for use by IKE Phase 2. FCIP implementations MUST support IKE Main Mode and SHOULD support Aggressive Mode.
IKEフェーズ1は、IKEメインモードをサポートしなければならないIKEフェーズ2 FCIP実装で使用するための通信用のセキュアなMAC認証チャネルを確立し、アグレッシブモードをサポートしなければなりません。
IKE Phase 1 exchanges MUST explicitly carry the Identification Payload fields (IDii and IDir). Conformant FCIP 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, and 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 [13], the port and protocol fields in the Identification Payload MUST be set to zero or UDP port 500.
IKEフェーズ1つの交換は、明示的に識別ペイロードフィールド（IDiiとIDIR）を運ばなければなりません。適合FCIP実装は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識別型の値を使用してはいけません。 [13]に記載されているように、識別ペイロードにポート、プロトコルフィールドは、ゼロまたはUDPポート500に設定されなければなりません。
FCIP Entities negotiate parameters for SA during IKE Phase 2 only using "Quick Mode". For FCIP Entities engaged in IKE "Quick Mode", there is no requirement for PFS (Perfect Forward Secrecy). FCIP implementations MUST use either ID_IPV4_ADDR or ID_IPV6_ADDR Identification Type values (based on the version of IP supported). Other Identification Type values MUST NOT be used.
FCIPエンティティは、「クイックモード」を使用してIKEフェーズ2 SAのパラメータを交渉します。 IKE「クイックモード」に従事しFCIPエンティティについては、PFS（完全転送秘密）のための必要はありません。 FCIP実装はID_IPV4_ADDRまたは（サポートされているIPのバージョンに基づいて）ID_IPV6_ADDR識別タイプ値のいずれかを使用しなければなりません。他の識別型の値を使用してはいけません。
Since the number of Phase 2 SAs may be limited, Phase 2 delete messages may be sent for idle SAs. The receipt of a Phase 2 delete message SHOULD NOT be interpreted as a reason for tearing down an FCIP Link or any of its TCP connections. When there is new activity on that idle link, a new Phase 2 SA MUST be re-established.
フェーズ2つのSAの数が制限される可能性があるので、フェーズ2つの削除メッセージは、アイドルのSAのために送信されてもよいです。フェーズ2削除メッセージの受信は、FCIPリンクまたはそのTCP接続のいずれかを切断する理由として解釈すべきではありません。そのアイドルリンク上の新しいアクティビティがある場合、新しいフェーズ2 SAを再確立する必要があります。
For a given pair of FCIP Entities, the same IKE Phase 1 negotiation can be used for all Phase 2 negotiations; i.e., all TCP Connections that are bundled into the single FCIP Link can share the same Phase 1 results.
FCIPエンティティの所与の対について、同じIKEフェーズ1ネゴシエーションは、すべてのフェーズ2つのネゴシエーションのために使用することができます。即ち、単一のFCIPリンクにバンドルされているすべてのTCP接続が同じフェーズ1件の結果を共有することができます。
Repeated rekeying using "Quick Mode" on the same shared secret will reduce the cryptographic properties of that secret over time. To overcome this, Phase 1 SHOULD be invoked periodically to create a new set of IKE shared secrets and related security parameters.
同じ共有秘密の「クイックモード」を使用して繰り返し再キーイングは、時間の経過とともにその秘密の暗号化プロパティを削減します。これを克服するために、フェーズ1 IKEの新しいセットを作成するために、定期的に呼び出されるべき秘密と関連するセキュリティパラメータを共有しました。
IKE Phase 1 establishment requires the following key distribution and FCIP Entities:
IKEフェーズ1個の確立には、以下のキーを配布し、FCIPエンティティが必要です。
- MUST support pre-shared IKE keys. - MAY support certificate-based peer authentication using digital signatures. - SHOULD NOT use peer authentication using the public key encryption methods outlined in sections 5.2 and 5.3 of [14].
- 事前共有IKEキーをサポートしなければなりません。 - デジタル署名を使用して、証明書ベースのピア認証をサポートするかもしれません。 - 公開鍵暗号セクション5.2に概説された方法及び[14]の5.3を使用してピア認証を使用しないでください。
When pre-shared keys are used, IKE Main Mode is usable only when both peers of an FCIP Link use statically assigned IP addresses. When support for dynamically assigned IP Addresses is attempted in conjunction with Main Mode, use of group pre-shared keys would be forced, and the use of group pre-shared keys in combination with Main Mode is not recommended as it exposes the deployed environment to man-in-the-middle attacks. Therefore, if either peer of an FCIP Link uses dynamically assigned addresses, Aggressive Mode SHOULD be used and Main Mode SHOULD NOT be used.
事前共有キーを使用する場合には、IKEメインモードは、FCIPリンクの両方のピアが静的に割り当てられたIPアドレスを使用する場合にのみ使用可能です。動的に割り当てられたIPアドレスのサポートがメインモード、グループ事前共有キーの使用と一緒にしようとしているときにそれが展開された環境を公開するように強制されるだろう、とメインモードとの組み合わせでグループ事前共有キーの使用は推奨されませんman-in-the-middle攻撃。 FCIPリンクのいずれかのピアは、動的に割り当てられたアドレスを使用している場合そのため、アグレッシブモードを使用する必要があり、メインモードを使用しないでください。
When Digital Signatures are used, either IKE Main Mode or IKE Aggressive Mode may be used. In all cases, access to locally stored secret information (pre-shared key, or private key for digital signing) MUST be suitably restricted, since compromise of secret information nullifies the security properties of IKE/IPsec protocols. Such mechanisms are outside the scope of this document. Support for IKE Oakley Groups [27] is not required.
デジタル署名を使用する場合、IKEメインモードまたはIKEアグレッシブモードのいずれかを使用することができます。秘密情報の妥協がIKE / IPsecプロトコルのセキュリティプロパティを無効にするので、すべてのケースでは、ローカルに保存された秘密情報（事前共有キー、またはデジタル署名用の秘密鍵）へのアクセスが適切に制限されなければなりません。そのようなメカニズムは、この文書の範囲外です。 IKEオークリーグループ[27]のサポートは必要ありません。
For the purpose of establishing a secure FCIP Link, the two participating FCIP Entities consult a Security Policy Database (SPD). The SPD is described in IPsec [10] Section 4.4.1. FCIP Entities may have more than one interface and IP Address, and it is possible for an FCIP Link to contain multiple TCP connections whose FCIP endpoint IP Addresses are different. In this case, an IKE Phase 1 SA is established for each FCIP endpoint IP Address pair. Within IKE Phase 1, FCIP implementations must support the ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6), and ID_FQDN Identity Payloads. If FCIP Endpoint addresses are dynamically assigned, it may be beneficial to use ID_FQDN, and for this reason, IP_FQDN Identity Payload MUST be supported. Other identity payloads (ID_USER_FQDN, ID_DER_ASN1_GN, ID_KEY_ID) SHOULD NOT be used.
安全なFCIPリンクを確立するために、2つの参加FCIPエンティティは、セキュリティポリシーデータベース（SPD）を参照してください。 SPDは、IPSec [10]のセクション4.4.1に記載されています。 FCIPエンティティは、複数のインターフェイスとIPアドレスを持っていること、およびFCIPリンクはそのFCIPエンドポイントのIPアドレスが異なる複数のTCP接続を含めることが可能です。この場合には、IKEフェーズ1 SAは各FCIPエンドポイントIPアドレスのペアのために確立されています。 IKEフェーズ1内で、FCIP実装はID_IPV4_ADDR、ID_IPV6_ADDR（プロトコルスタックがIPv6をサポートしている場合）、およびID_FQDNアイデンティティペイロードをサポートしなければなりません。 FCIPエンドポイントアドレスが動的に割り当てられている場合、ID_FQDNを使用することが有益であり得る、そしてこのような理由のために、IP_FQDNアイデンティティペイロードをサポートしなければなりません。他のIDペイロード（ID_USER_FQDN、ID_DER_ASN1_GN、ID_KEY_ID）が使用されるべきではありません。
At the end of successful IKE negotiations both FCIP Entities store the SA parameters in their SA database (SAD). The SAD is described in IPsec [10] Section 4.4.3. The SAD contains the set of active SA entries, each entry containing Sequence Counter Overflow, Sequence Number Counter, Anti-replay Window, and the Lifetime of the SA. FCIP Entities SHALL employ a default SA Lifetime of one hour and a default Anti-replay window of 32 sequence numbers.
成功のIKEネゴシエーションの両方FCIPエンティティの終わりに彼らのSAデータベース（SAD）でSAパラメータを格納します。 SADは、IPSec [10]のセクション4.4.3に記載されています。 SADはアクティブSAエントリのセットを含む、シーケンスカウンタオーバーフロー、シーケンス番号カウンタ、アンチリプレイウィンドウを含む各エントリ、およびSAの寿命。 FCIPエンティティは、1時間のデフォルトSAのライフタイムと32個のシーケンス番号のデフォルトのアンチリプレイウィンドウを採用するものとします。
When a TCP Connection is established between two FCIP_DEs, two unidirectional SAs are created for that connection and each SA is identified in the form of a Security Parameter Index (SPI). One SA is associated with the incoming traffic flow and the other SA is associated with the outgoing traffic flow. The FCIP_DEs at each end of the TCP connection MUST maintain the SPIs for both its incoming and outgoing FCIP Encapsulated Frames.
TCPコネクションが2 FCIP_DEs間で確立されると、2つの単方向のSAは、その接続のために作成され、各SAはセキュリティパラメータインデックス（SPI）の形で識別されます。一つのSAは、着信トラフィックフローと関連付けられ、他のSAは、送信トラフィックフローに関連付けられています。 TCP接続の各端部FCIP_DEsは、着信および発信FCIPカプセル化フレームの両方のためのSPIを維持しなければなりません。
FCIP Entities MAY provide administrative management of Confidentiality usage. These management interfaces SHOULD be provided in a secure manner, so as to prevent an attacker from subverting the security process by attacking the management interface.
FCIPエンティティは、機密性の使用状況の管理運営を提供することができます。管理インターフェイスを攻撃することによって、セキュリティプロセスを破壊するから攻撃を防止するように、これらの管理インターフェイスは、安全な方法で提供されるべきです。
FCIP Entities MUST implement Replay Protection against ESP Sequence Number wrap, as described in [14]. In addition, based on the cipher algorithm and the number of bits in the cipher block size, the validity of the key may become compromised. In both cases, the SA needs to be re-established.
[14]で説明したようにFCIPエンティティは、ESPシーケンス番号ラップに対してリプレイ保護を実装しなければなりません。また、暗号アルゴリズムと暗号ブロックサイズのビット数に基づいて、鍵の有効性が損なわになることができます。どちらの場合も、SAを再確立する必要があります。
FCIP Entities MUST use the results of IKE Phase 1 negotiation for initiating an IKE Phase 2 "Quick Mode" exchange and establish new SAs.
FCIPエンティティは、IKEフェーズ2「クイックモード」の交換を開始するためのIKEフェーズ1回の交渉の結果を使用して、新しいSAを確立しなければなりません。
To enable smooth transition of SAs, it is RECOMMENDED that both FCIP Entities refresh the SPI when the sequence number counter reaches 2^31 (i.e., half the sequence number space). It also is RECOMMENDED that the receiver operate with multiple SPIs for the same TCP Connection for a period of 2^31 sequence number packets before aging out an SPI.
SAの円滑な移行を可能にするために、シーケンス番号カウンタが2 ^ 31（すなわち、半シーケンス番号空間）に達したとき、両方のFCIPエンティティは、SPIを更新することが推奨されます。また、受信機は、SPIをエージング前に2 ^ 31のシーケンス番号のパケットの期間に対して同じTCP接続のための複数のSPIで動作することが推奨されます。
When a new SPI is created for the outgoing direction, the sending side SHALL begin using it for all new FCIP Encapsulated Frames. Frames that are either in-flight, or re-sent due to TCP retransmissions, etc. MAY use either the new SPI or the one being replaced.
新しいSPIは、発信方向のために作成された場合、送信側は、すべての新しいFCIPカプセル化フレームのためにそれを使用し始めるものとします。新しいSPIまたは1のいずれかを使用するかもしれ等のいずれかで飛行、またはTCP再送信が原因で再送信されたフレームは、交換されます。
FCIP implementations may allow enabling and disabling security mechanisms at the granularity of an FCIP Link. If enabled, the following FCIP Link Initialization steps MUST be followed.
FCIP実装は、FCIPリンクの粒度でセキュリティメカニズムを有効化および無効化可能にすることができます。有効にした場合、以下のFCIPリンク初期化の手順に従わなければなりません。
When an FCIP Link is initialized, before any FCIP TCP Connections are established, the local SPD is consulted to determine if IKE Phase 1 has been completed with the FCIP Entity in the peer FCIP Entity, as identified by the WWN.
FCIPリンクが初期化されると任意のFCIP TCP接続が確立される前に、ローカルSPDはWWNによって識別されるIKEフェーズ1は、ピアFCIPエンティティにFCIPエンティティで完了しているかどうかを判断するために調べています。
If Phase 1 is already completed, IKE Phase 2 proceeds. Otherwise, IKE Phase 1 MUST be completed before IKE Phase 2 can start. Both IKE Phase 1 and Phase 2 transactions use UDP Port 500. If IKE Phase 1 fails, the FCIP Link initialization terminates and notifies the FC entity with the reason for the termination. Otherwise, the FCIP Link initialization moves to TCP Connection Initialization.
フェーズ1がすでに完了している場合は、IKEフェーズ2に進みます。 IKEフェーズ2が開始する前にそれ以外の場合は、IKEフェーズ1が完了しなければなりません。 IKEフェーズ1が失敗した場合は、IKEフェーズ1とフェーズ2つのトランザクションの両方がUDPポート500を使用して、FCIPリンクの初期化が終了した理由でFCエンティティを終了し、通知します。それ以外の場合は、TCP接続の初期化にFCIPリンクの初期化動きます。
As described in section 8.1, FCIP Entities exchange an FSF for forming an FCIP Link. The use of ESP Confidentiality is an effective countermeasure against any perceived security risks of FSF.
セクション8.1で説明したように、FCIPエンティティは、FCIPリンクを形成するためのFSFを交換します。 ESP機密性の使用は、FSFの任意の認知セキュリティリスク対策として有効です。
Each TCP connection MUST be protected by an IKE Phase 2 SA. Traffic from one or more than one TCP connection may flow within each IPsec Phase 2 SA. While it is possible for an IKE Phase 2 SA to protect multiple TCP connections, all packets of a TCP connection are protected using only one IKE Phase 2 SA.
各TCP接続には、IKEフェーズ2 SAで保護する必要があります。一つまたは複数のTCP接続からのトラフィックは、各IPSecフェーズ2 SA内に流れることができます。 IKEフェーズ2 SAは、複数のTCP接続を保護することは可能ですが、TCP接続のすべてのパケットが一つだけIKEフェーズ2 SAを使用して保護されています。
If different Quality of Service settings are applied to TCP connections, it is advisable to use a different IPsec SA for these connections. Attempting to apply a different quality of service to connections handled by the same IPsec SA can result in reordering, and falling outside the replay window. For additional details, see [21].
サービス設定の異なる品質がTCP接続に適用されている場合は、これらの接続に異なるのIPsec SAを使用することをお勧めします。並べ替えをもたらすことができる同じのIPsec SAが取り扱う接続に異なるサービス品質を適用しようとすると、再生ウィンドウから外れます。その他の詳細については、[21]を参照してください。
FCIP implementations need not verify that the IP addresses and port numbers in the packet match any locally stored per-connection values, leaving this check to be performed by the IPsec layer.
FCIP実装は、パケット内のIPアドレスとポート番号がIPSecレイヤによって実行されるこのチェックを残して、任意のローカルに格納された接続ごとの値と一致することを確認する必要はありません。
An implementation is free to perform several IKE Phase 2 negotiations and cache them in its local SPIs, although entries in such a cache can be flushed per current SA Lifetime settings.
こうしたキャッシュ内のエントリは、現在のSAライフタイムの設定ごとに洗い流すことができるが、実装は、いくつかのIKEフェーズ2ネゴシエーションを実行し、そのローカルのSPIでそれらをキャッシュして自由です。
Upon datagram reception, when the ESP packet fails an integrity check, the receiver MUST drop the datagram, which will trigger TCP retransmission. If many such datagrams are dropped, a receiving FCIP Entity MAY close the TCP Connection and notify the FC Entity with the reason for the closure.
ESPパケットが整合性チェックに失敗したときにデータグラムを受信すると、受信機は、TCPの再送をトリガーするデータグラムを、削除する必要があります。多くのそのようなデータグラムが破棄された場合は、受信FCIPエンティティは、TCPコネクションを閉じ、閉鎖の理由でFCエンティティに通知することができます。
An implementation SHOULD follow guidelines for auditing all auditable ESP events per IPsec [10] Section 7.
実装は、IPsec [10] 7節あたりのすべての監査可能なESPのイベントを監査するためのガイドラインに従ってください。
Integrity checks MUST be performed if Confidentiality is enabled.
機密性が有効になっている場合、整合性チェックを実行しなければなりません。
Traditionally, the links between FC Fabric components have been characterized by low latency and high throughput. The purpose of FCIP is to provide functionality equivalent to these links using an IP Network, where low latency and high throughput are not as certain. It follows that FCIP Entities and their counterpart FC Entities probably will be interested in optimal use of the IP Network.
伝統的に、FCファブリックコンポーネント間のリンクは、低レイテンシと高スループットによって特徴付けられています。 FCIPの目的は、低レイテンシと高スループットをなどの特定されないIPネットワークを使用して、これらのリンクと同等の機能を提供することです。 FCIPエンティティとその相手FCエンティティは、おそらくIPネットワークの最適な使用に興味があるだろうということになります。
Many options exist for ensuring high throughput and low latency appropriate for the distances involved in an IP Network. For example, a private IP Network might be constructed for the sole use of FCIP Entities. The options that are within the scope of this specification are discussed here.
多くのオプションがIPネットワークに関与した距離に適した高スループットと低遅延を確保するために存在します。たとえば、プライベートIPネットワークは、FCIPエンティティの唯一の使用のために構築される可能性があります。この仕様の範囲内にあるオプションは、ここで説明されています。
One option for increasing the probability that FCIP data streams will experience low latency and high throughput is the IP QoS techniques discussed in section 10.2. This option can have value when applied
FCIPデータ・ストリームは、低レイテンシと高スループットを経験する確率を高めるための1つのオプションは、セクション10.2で説明するIP QoS技術です。適用される場合、このオプションは値を持つことができます
to a single TCP Connection. Depending on the sophistication of the FC Entity, further value may be obtained by having multiple TCP Connections with differing QoS characteristics.
単一のTCPコネクションへ。 FCエンティティの精巧さに応じて、さらなる値は、異なるQoS特性を有する複数のTCP接続を有することによって得ることができます。
There are many reasons why an FC Entity might request the creation of multiple TCP Connections within an FCIP_LEP. These reasons include a desire to provide differentiated services for different TCP data connections between FCIP_LEPs, or a preference to separately queue different streams of traffic not having a common in-order delivery requirement.
FCエンティティはFCIP_LEP内で複数のTCPコネクションの作成を要求するかもしれない多くの理由があります。これらの理由はFCIP_LEPs間で異なるTCPデータ接続のための差別化サービスを提供したいという要望、又は別々に共通のインオーダー配信要件を有さないトラフィックの異なるストリームをキューに優先順位を含みます。
At the time a new TCP Connection is created, the FC Entity SHALL specify to the FCIP Entity the QoS characteristics (including but not limited to IP per-hop-behavior) to be used for the lifetime of that connection. This MAY be achieved by having:
新しいTCP接続が作成された時点では、FCエンティティは、（含むがIPホップごとの行動に限定されない）QoS特性は、その接続の存続期間に使用するFCIPエンティティに指定します。これは持っていることによって達成することができます。
a) only one set of QoS characteristics for all TCP Connections;
すべてのTCP接続のためのQoS特性のa）は一組だけ。
b) a default set of QoS characteristics that the FCIP Entity applies in the absence of differing instructions from the FC Entity; or
FCIPエンティティは、FCエンティティから命令を異なるが存在しない場合に適用されるQoS特性のb）のデフォルトセット。または
c) a sophisticated mechanism for exchanging QoS requirements information between the FC Entity and FCIP Entity each time a new TCP Connection is created.
FCエンティティとFCIPエンティティ間の新しいTCP接続が作成されるたびに、QoS要件情報を交換するためのc）の洗練されたメカニズム。
Once established, the QoS characteristics of a TCP Connection SHALL NOT be changed, since this specification provides no mechanism for the FC Entity to control such changes. The mechanism for providing different QoS characteristics in FCIP is the establishment of a different TCP Connections and associated FCIP_DEs.
設立後は、この仕様は、FCエンティティは、そのような変更を制御するためのメカニズムを提供しないため、TCPコネクションのQoS特性は、変更することはないものとします。 FCIPで異なるQoS特性を提供するためのメカニズムが異なるTCPコネクションとの関連FCIP_DEsの確立です。
When FCIP is used with a network with a large (bandwidth*delay) product, it is RECOMMENDED that FCIP_LEPs use the TCP mechanisms (window scaling and wrapped sequence protection) for Long Fat Networks (LFNs) as defined in RFC 1323 [24].
FCIPは、大（帯域幅*遅延）製品とネットワークで使用する場合には、RFC 1323 [24]で定義されているようFCIP_LEPsロングファットネットワーク（LFNs）のためのTCPメカニズム（ウィンドウスケーリングと包まれたシーケンスの保護）を使用することをお勧めします。
Many methods of providing QoS have been devised or proposed. These include (but are not limited to) the following:
QoSを提供する多くの方法が考案または提案されています。これらは、（これに限定されないが）、以下：
- Multi-Protocol Label Switching (MPLS) -- RFC 3031 [32] - Differentiated Services Architecture (diffserv) -- RFC 2474 [28], RFC 2475 [29], RFC 2597 [30], and RFC 2598 [31] -- and other forms of per-hop-behavior (PHB) - Integrated Services, RFC 1633 [25] - IEEE 802.1p
- マルチプロトコルラベルスイッチング（MPLS） - RFC 3031 [32] - 差別化サービスアーキテクチャ（のDiffServ） - RFC 2474 [28]、RFC 2475 [29]、RFC 2597 [30]、およびRFC 2598 [31] - - ホップごとの行動のおよび他の形態（PHB） - 統合サービス、RFC 1633 [25] - IEEE 802.1P
The purpose of this specification is not to specify any particular form of IP QoS, but rather to specify only those issues that must be addressed in order to maximize interoperability between FCIP equipment that has been manufactured by different vendors.
この仕様の目的は、IPのQoSの任意の特定の形式を指定するのではなく、異なるベンダーによって製造されたFCIP機器間の相互運用性を最大にするために取り組まなければならない問題のみを指定することではありません。
It is RECOMMENDED that some form of preferential QoS be used for FCIP traffic to minimize latency and packet drops. No particular form of QoS is recommended.
優先のQoSのいくつかのフォームは、待ち時間を最小限に抑えるためにFCIPトラフィックに使用すると、パケットが低下することが推奨されます。 QoSのいかなる特定の形式が推奨されません。
If a PHB IP QoS is implemented, it is RECOMMENDED that it interoperate with diffserv (see RFC 2474 [28], RFC 2475 [29], RFC 2597 [30], and RFC 2598 [31]).
PHB IP QoSが実施される場合、のDiffServと相互運用することが推奨される（[28]、RFC 2475 [29]、RFC 2597 [30]、およびRFC 2598 [31] RFC 2474を参照）。
If no form of preferential QoS is implemented, the DSCP field SHOULD be set to '000000' to avoid negative impacts on other network components and services that may be caused by uncontrolled usage of non-zero values of the DSCP field.
優先的なQoSのいかなる形態が実装されていない場合は、DSCPフィールドは、DSCPフィールドの非ゼロ値の制御不能な使用によって引き起こされる可能性が他のネットワークコンポーネントとサービスへの悪影響を避けるために、「000000」に設定されるべきです。
The references in this section were current as of the time this specification was approved. This specification is intended to operate with newer versions of the referenced documents and looking for newer reference documents is recommended.
このセクションの参照は、この仕様が承認された時現在のものでした。この仕様は、参照文書の新しいバージョンで動作するように意図されており、新しい参考文献を探してお勧めします。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Fibre Channel Backbone (FC-BB), ANSI INCITS.342:2001, December 12, 2001.
[2]ファイバチャネルバックボーン（FC-BB）、ANSI INCITS.342：2001、2001年12月12日。
[3] Fibre Channel Backbone -2 (FC-BB-2), ANSI INCITS.372:2003, July 25, 2003.
[3]ファイバチャネルバックボーン-2（FC-BB-2）、ANSI INCITS.372：2003、2003年7月25日。
[4] Fibre Channel Switch Fabric -2 (FC-SW-2), ANSI INCITS.355:2001, December 12, 2001.
[4]ファイバチャネルファブリックスイッチ-2（FC-SW-2）、ANSI INCITS.355：2001、2001年12月12日。
[5] Fibre Channel Framing and Signaling (FC-FS), ANSI INCITS.373:2003, October 27, 2003.
[5]ファイバチャネルフレーミングおよびシグナリング（FC-FS）、ANSI INCITS.373：2003、2003年10月27日。
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[6]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[7] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[7]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[8] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[8]ジェーコブソン、V.、ブレーデン、R.とD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992月。
[9] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[9]イーストレイク、D.、クロッカー、S.とJ.シラー、 "セキュリティのためのランダム性に関する推奨事項"、RFC 1750、1994年12月。
[10] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[10]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[11] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997.
[11] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のためのKeyed-ハッシュ"、RFC 2104、1997年2月。
[12] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[12]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[13] Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998.
パイパー、D.、 "ISAKMPの解釈のインターネットIPセキュリティー領域"、RFC 2407、1998年11月[13]。
[14] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[14]ハーキンズ、D.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[15] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[15]グレン、R.とS.ケント、 "NULL暗号化アルゴリズムとIPsecでの使用"、RFC 2410、1998年11月。
[16] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[16]ペレイラ、R.とR.アダムス、 "ESP CBCモード暗号アルゴリズム"、RFC 2451、1998年11月。
[17] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, version 2", RFC 2608, July 1999.
[17]ガットマン、E.、パーキンス、C.、Veizades、J.とM.日、 "サービスロケーションプロトコル、バージョン2"、RFC 2608、1999年7月。
[18] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "SACK Extension", RFC 2883, July 2000.
[18]フロイド、S.、Mahdavi、J.、マティス、M.およびM.ポドルスキー、 "SACK拡張"、RFC 2883、2000年7月。
[19] Weber, R., Rajagopal, M., Travostino, F., O'Donnell, M., Monia, C. and M. Merhar, "Fibre Channel (FC) Frame Encapsulation", RFC 3643, December 2003.
[19]ウェーバー、R.、Rajagopal、M.、Travostino、F.、オドネル、M.、モニア、C.及びM. Merhar、 "ファイバチャネル（FC）フレームカプセル化"、RFC 3643、2003年12月。
[20] Peterson, D., "Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)", RFC 3822, July 2004.
、RFC 3822、2004年7月 "サービスロケーションプロトコルバージョン2（SLPv2の）を使用して、TCP / IP（FCIP）エンティティを超える検索ファイバーチャネル" [20]ピーターソン、D.、。
[21] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[21] Aboba、B.、ツェン、J.、ウォーカー、J.、Rangan、V.とF. Travostino、 "IP上のセキュリティブロックストレージプロトコル"、RFC 3723、2004年4月。
[22] Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[22]フランケル、S.、グレン、R.とS.ケリー、 "AES-CBC暗号アルゴリズムおよびIPSecでの使用"、RFC 3602、2003年9月。
[23] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[23]フランケル、S.およびH.ハーバート、 "AES-XCBC-MAC-96アルゴリズムおよびIPsecとのその使用"、RFC 3566、2003年9月。
[24] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[24]ジェーコブソン、V.、ブレーデン、R.とD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[25] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[25]ブレーデン、R.、クラーク、D.とS. Shenker、 "インターネットアーキテクチャにおける統合サービス：概要"、RFC 1633、1994年6月。
[26] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[26]ミルズ、D.、 "IPv4、IPv6、およびOSIのため簡易ネットワークタイムプロトコル（SNTP）バージョン4"、RFC 2030、1996年10月。
[27] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[27]オーマン、H.、 "OAKLEYキー決意プロトコル"、RFC 2412、1998年11月。
[28] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and Ipv6 Headers", RFC 2474, December 1998.
[28]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[29] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[29]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[30] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "An Assured Forwarding PHB", RFC 2597, June 1999.
[30] Heinanen、J.、ベーカー、F.、ワイス、W.及びJ. Wroclawski、 "保証転送PHB"、RFC 2597、1999年6月。
[31] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB Group", RFC 2598, June 1999.
[31]ジェーコブソン、V.、ニコルズ、K.とK. Poduri、 "緊急転送PHBグループ"、RFC 2598、1999年6月。
[32] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January, 2001.
[32]ローゼン、E.、Viswanathanの、A.とR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[33] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.
[33]パテル、B.、Aboba、B.、ケリー、S.とV.グプタ、 "動的ホスト構成プロトコル（DHCPv4の）IPsecトンネルモードの設定"、RFC 3456、2003年1月。
[34] Kembel, R., "The Fibre Channel Consultant: A Comprehensive Introduction", Northwest Learning Associates, 1998.
[34] Kembel、R.、 "ファイバーチャネル・コンサルタント：総合入門"、北西部ラーニング・アソシエイツ、1998。
The developers of this specification thank Mr. Jim Nelson for his assistance with FC-FS related issues.
この仕様の開発者は、FC-FS関連の問題との彼の援助のために氏はジム・ネルソンに感謝します。
The developers of this specification express their appreciation to Mr. Mallikarjun Chadalapaka and Mr. David Black for their detailed and helpful reviews.
この仕様の開発者は、詳細かつ有用なレビューのために氏Mallikarjun Chadalapaka氏とデビッド・ブラックへの感謝の意を表明します。
Appendix A - Fibre Channel Bit and Byte Numbering Guidance
付録A - ファイバチャネルビットおよびバイト番号順ガイダンス
Both Fibre Channel and IETF standards use the same byte transmission order. However, the bit and byte numbering is different.
ファイバチャネルおよびIETF標準の両方が同じバイト送信順序を使用します。しかし、ビットおよびバイトの番号が異なっています。
Fibre Channel bit and byte numbering can be observed if the data structure heading, shown in figure 11, is cut and pasted at the top of figure 7, figure 9, and figure 17.
ファイバ・チャネル・ビット及びバイトの番号は、図11に示すように、データ構造見出した場合に観察することができ、カット＆ペースト、図7の上部に、図9、図17れます。
W|------------------------------Bit------------------------------|
o| |
r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 |
d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0|
Figure 11: Fibre Channel Data Structure Bit and Byte Numbering
図11：ファイバチャネルデータ構造ビットおよびバイト番号順
Fibre Channel bit numbering for the pFlags field can be observed if the data structure heading, shown in figure 12, is cut and pasted at the top of figure 8.
ファイバチャネルは、図12に示すデータ構造の見出しは、図8の上部で切断し、貼り付けられた場合に観察することができるPFLAGSフィールドの番号のビット。
|----------------Bit--------------------|
| |
| 31 30 29 28 27 26 25 24 |
Figure 12: Fibre Channel pFlags Bit Numbering
図12：ファイバチャネルPFLAGSビット番号
Fibre Channel bit numbering for the Connection Usage Flags field can be observed if the data structure heading, shown in figure 13, is cut and pasted at the top of figure 10.
ファイバチャネルは、図13に示すデータ構造の見出しは、図10の上部で切断し、貼り付けられた場合に観察することができる接続の使用フラグフィールドの番号のビット。
|------------------------------Bit------------------------------|
| |
| 31 30 29 28 27 26 25 24 |
Figure 13: Fibre Channel Connection Usage Flags Bit Numbering
図13：ファイバチャネル接続の使用フラグビット番号
Appendix B - IANA Considerations
付録B - IANAの考慮事項
IANA has made the following port assignments to FCIP:
IANAは、FCIPに次のポート割り当てを行っています。
- fcip-port 3225/tcp FCIP - fcip-port 3225/udp FCIP
- FCIPポート3225 / TCPのFCIP - FCIPポート3225 / udpのFCIP
IANA has changed the authority for these port allocations to reference this RFC.
IANAは、このRFCを参照するために、これらのポート割り当ての権限を変更しました。
Use of UDP with FCIP is prohibited even though IANA has allocated a port.
FCIPとUDPの使用はIANAポートを割り当てられているにもかかわらず禁止されています。
The FC Frame encapsulation used by this specification employs Protocol# value 1, as described in the IANA Considerations appendix of the FC Frame Encapsulation [19] specification.
FCフレームのカプセル化[19]仕様のIANAの考慮事項の付録に記載されているように本明細書で使用されるFCフレームのカプセル化は、プロトコル＃値1を採用しています。
Appendix C - FCIP Usage of Addresses and Identifiers
付録C - アドレスと識別子のFCIPの使い方
In support of network address translators, FCIP does not use IP Addresses to identify FCIP Entities or FCIP_LEPs. The only use of IP Addresses for identification occurs when initiating new TCP connect requests (see section 8.1.2.3) where the IP Address destination of the TCP connect request is used to answer the question: "Have previous TCP connect requests been made to the same destination FCIP Entity?" The correctness of this assumption is further checked by sending the Destination FC Fabric Entity World Wide Name in the FCIP Special Frame (FSF) and having the value checked by the FCIP Entity that receives the TCP connect request and FSF (see section 8.1.3).
ネットワークアドレス変換のサポートでは、FCIPは、FCIPエンティティまたはFCIP_LEPsを識別するために、IPアドレスを使用していません。識別は、新しいTCPはTCPのIPアドレス先の接続要求が質問に答えるために使用されている要求を（セクション8.1.2.3を参照）接続開始時に発生するためにIPの使用のみがアドレス：「同じになって、以前のTCPが接続要求を持っています先FCIPエンティティの？」この仮定の正しさをさらにFCIP特殊フレーム（FSF）の宛先FCファブリックエンティティのWorld Wide Name]を送信し、TCP要求とFSFを接続する受信FCIPエンティティによって確認された値を持つことによってチェックされている（セクション8.1.3を参照してください） 。
For the purposes of processing incoming TCP connect requests, the source FCIP Entity is identified by the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier fields in the FSF sent from the TCP connect requestor to the TCP connect recipient as the first bytes following the TCP connect request (see section 8.1.2.3 and section 8.1.3).
着信TCPの接続要求を処理のために、ソースFCIPエンティティが最初と受信者を接続するTCPへの要求者を接続するTCPから送られたFSFでソースFCファブリックエンティティのWorld Wide NameとソースFC / FCIP実体識別子フィールドで識別されますTCP、次のバイトは、要求を（セクション8.1.2.3とセクション8.1.3を参照）を接続します。
FC-BB-2 [3] provides the definitions for each of the following FSF fields:
FC-BB-2 [3]は、以下のFSFの各フィールドの定義を提供します。
- Source FC Fabric Entity World Wide Name, - Source FC/FCIP Entity Identifier, and - Destination FC Fabric Entity World Wide Name.
- ソースFCファブリックエンティティのワールドワイドネーム、 - ソースFC / FCIPエンティティの識別子、および - 宛先のFCファブリックエンティティのWorld Wide名。
As described in section 8.1.3, FCIP Entities segregate their FCIP_LEPs between:
セクション8.1.3で説明したように、FCIPエンティティは、そのFCIP_LEPs間を分離します：
- Connections resulting from TCP connect requests initiated by the FCIP Entity, and
- FCIPエンティティによって開始されたTCP接続要求の結果の接続、および
- Connections resulting from TCP connect requests received by the FCIP Entity.
- TCP起因する接続はFCIPエンティティが受信した要求を接続してください。
Within each of these two groups, the following information is used to further identify each FCIP_LEP:
これら二つのグループのそれぞれの中に、以下の情報は、各FCIP_LEPを識別するために使用されます。
- Source FC Fabric Entity World Wide Name, - Source FC/FCIP Entity Identifier, and - Destination FC Fabric Entity World Wide Name.
- ソースFCファブリックエンティティのワールドワイドネーム、 - ソースFC / FCIPエンティティの識別子、および - 宛先のFCファブリックエンティティのWorld Wide名。
Appendix D - Example of Synchronization Recovery Algorithm
付録D - 同期回復アルゴリズムの例
The contents of this annex are informative.
この附属書の内容は有益です。
Synchronization may be recovered as specified in section 5.6.2.3. An example of an algorithm for searching the bytes delivered to the Encapsulated Frame Receiver Portal for a valid FCIP Frame header is provided in this annex.
セクション5.6.2.3で指定されるように同期を回復することができます。有効なFCIPフレームヘッダのカプセル化されたフレーム受信ポータルに配信バイトを検索するためのアルゴリズムの一例は、この附属書に提供されます。
This resynchronization uses the principle that a valid FCIP data stream must contain at least one valid header every 2176 bytes (the maximum length of an encapsulated FC Frame). Although other data patterns containing apparently valid headers may be contained in the stream, the FC CRC or FCIP Frame validity of the data patterns contained in the data stream will always be either interrupted by or resynchronized with the valid FCIP Frame headers.
この再同期は、有効なFCIPデータストリームは少なくとも1つの有効なヘッダごとに2176バイト（カプセル化されたFCフレームの最大長さ）を含まなければならないという原理を利用します。明らかに有効なヘッダーを含む他のデータパターンをストリームに含まれていてもよいが、FC CRCまたはデータストリームに含まれるデータパターンのFCIPフレームの有効性は、常にどちらかによって中断または有効なFCIPフレームヘッダと再同期されます。
Consider the case shown in figure 14. A series of short FCIP Frames, perhaps from a trace, are embedded in larger FCIP Frames, say as a result of a trace file being transferred from one disk to another. The headers for the short FCIP Frames are denoted SFH and the long FCIP Frame headers are marked as LFH.
大きなFCIPフレーム内に埋め込まれている、おそらくトレースから、図14に短いFCIPフレームの一連を示す場合を考え、別のディスクから転送されるトレース・ファイルの結果として言います。短いFCIPフレームのヘッダは、SFHを付し、長いFCIPフレームヘッダは、LFHとしてマークされています。
+-+--+-+----+-+----+-+----+-+-+-+---+-+---
|L| |S| |S| |S| |S| |L| |S|
|F| |F| |F| |F| |F| |F| |F|...
|H| |H| |H| |H| |H| |H| |H|
+-+--+-+----+-+----+-+----+-+-+-+---+-+---
| |
|<---------2176 bytes-------->|
Figure 14: Example of resynchronization data stream
図14：再同期データ・ストリームの例
A resynchronization attempt that starts just to the right of an LFH will find several SFH FCIP Frames before discovering that they do not represent the transmitted stream of FCIP Frames. Within 2176 bytes plus or minus, however, the resynchronization attempt will encounter an SFH whose length does not match up with the next SFH because the LFH will fall in the middle of the short FCIP Frame pushing the next header farther out in the byte stream.
ちょうどLFHの右側に開始し、再同期の試みは、彼らがFCIPフレームの送信ストリームを表すものではないことを発見する前に、いくつかのSFH FCIPフレームを見つけます。 LFHはバイトストリームに遠くて次のヘッダを短押しFCIPフレームの真ん中に落ちるので、2176バイトプラスまたはマイナスの中で、しかし、長さSFHに遭遇する再同期しようとすると、次のSFHと一致しません。
Note that the resynchronization algorithm cannot forward any prospective FC Frames to the FC Frame Transmitter Portal because, until synchronization is completely established, there is no certainty that anything that looked like an FCIP Frame really was one. For example, an SFH might fortuitously contain a length that points exactly to the beginning of an LFH. The LFH would identify the correct beginning of a transmitted FCIP Frame, but that in no way guarantees that the SFH was also a correct FCIP Frame header.
同期が完全に確立されるまで、FCIPフレームのように見えたものは、本当に1だったという確信がない、ので、再同期アルゴリズムは、FCフレームトランスミッタPortalに任意の将来のFCフレームを転送することができないことに注意してください。例えば、SFHは、偶然にLFHの初めに正確に指し示す長さが含まれている場合があります。 LFHは、送信されたFCIPフレームの正しい始まりを特定するだろうが、決してそれはSFHも正しいFCIPフレームヘッダたことを保証します。
There exist some data streams that cannot be resynchronized by this algorithm. If such a data stream is encountered, the algorithm causes the TCP Connection to be closed.
このアルゴリズムによって再同期することができないいくつかのデータストリームが存在します。そのようなデータストリームが発生した場合、アルゴリズムはクローズするTCPコネクションの原因となります。
The resynchronization assumes that security and authentication procedures outside the FCIP Entity are protecting the valid data stream from being replaced by an intruding data stream containing valid FCIP data.
再同期は、FCIPエンティティ外のセキュリティと認証の手続きが有効なFCIPデータを含む侵入、データストリームに置き換えられてから有効なデータ・ストリームを保護していることを前提としています。
The following steps are one example of how an FCIP_DE might resynchronize with the data stream entering the Encapsulated Frame Receiver Portal.
次の手順はFCIP_DEがカプセル化されたフレームレシーバーポータルに入るデータ・ストリームと再同期する方法をの一例です。
1) Search for candidate and strong headers:
1）候補者と強力なヘッダを検索します：
The data stream entering the Encapsulated Frame Receiver Portal is searched for 12 bytes in a row containing the required values for:
カプセル化されたフレーム受信ポータルを入力データストリームは、のために必要な値を含む行に12のバイトを探索します。
a) Protocol field, b) Version field, c) ones complement of the Protocol field, d) ones complement of the Version field, e) replication of encapsulation word 0 in word 1, and f) pFlags field and its ones complement.
a）のプロトコルフィールド、B）バージョンフィールド、Protocolフィールド、d）のワード1におけるカプセル化ワード0のバージョンフィールド、e）の複製の補数、およびF）PFLAGSフィールドとそのものは補完のc）の補数。
If such a 12-byte grouping is found, the FCIP_DE assumes that it has identified bytes 0-2 of a candidate FCIP encapsulation header.
そのような12バイトのグループ化が見つかった場合、FCIP_DEは、候補FCIPカプセル化ヘッダのバイト0-2を識別したと仮定しています。
All bytes up to and including the candidate header byte are discarded.
候補ヘッダーバイトまでを含むすべてのバイトは破棄されます。
If no candidate header has been found after searching a specified number of bytes greater than some multiple of 2176 (the maximum length of an FCIP Frame), resynchronization has failed and the TCP/IP connection is closed.
いかなる候補ヘッダは、2176の倍数（FCIPフレームの最大長さ）より大きい指定されたバイト数を検索した後に発見されていない場合、再同期は失敗しており、TCP / IP接続が閉じられます。
Word 3 of the candidate header contains the Frame Length and Flags fields and their ones complements. If the fields are consistent with their ones complements, the candidate header is considered a strong candidate header. The Frame Length field is used to determine where in the byte stream the next strong candidate header should be and processing continues at step 2).
候補ヘッダのワード3は、フレーム長とフラグフィールドが含まれており、そのものが補完します。フィールドは彼らのものの補数と一致している場合は、候補ヘッダは、強力な候補ヘッダーと考えられています。フレーム長フィールドは、ここ）バイトストリーム内の次の強力な候補ヘッダがあるべきであり、処理は、ステップ2に続く決定するために使用されます。
2) Use multiple strong candidate headers to locate a verified candidate header:
2）検証候補ヘッダを見つけるために、複数の有力な候補ヘッダを使用します。
The Frame Length in one strong candidate header is used to skip incoming bytes until the expected location of the next strong candidate header is reached. Then the tests described in step 1) are applied to see if another strong candidate header has successfully been located.
1つの強い候補ヘッダにおけるフレーム長は次の強力な候補ヘッダの予想される位置に到達するまで、着信バイトをスキップするために使用されます。ステップ1で説明したテスト）は、別の強力な候補ヘッダが正常に配置されているかどうかを確認するために適用されます。
All bytes skipped and all bytes in all strong candidate headers processed are discarded.
すべてのバイトがスキップされ、処理されるすべての強力な候補ヘッダーのすべてのバイトは破棄されます。
Strong candidate headers continue to be verified in this way for at least 4352 bytes (twice the maximum length of an FCIP Frame). If at any time a verification test fails, processing restarts at step 1 and a retry counter is incremented. If the retry counter exceeds 3 retries, resynchronization has failed and the TCP Connection is closed, and the FC entity is notified with the reason for the closure.
有力な候補ヘッダは（2回FCIPフレームの最大長）は、少なくとも4352バイトのために、このように検証され続けます。検証テストに失敗した任意の時点であれば、処理はステップ1で再起動し、再試行カウンタがインクリメントされます。リトライカウンタが3回のリトライを超えた場合、再同期は失敗し、TCP接続が閉じられ、FCエンティティは閉鎖の理由が通知されます。
After strong candidate headers have been verified for at least 4352 bytes, the next header identified is a verified candidate header, and processing continues at step 3).
有力候補ヘッダは、少なくとも4352バイトのために検証された後、識別された次のヘッダを検証候補ヘッダであり、そして処理）ステップ3に進みます。
Note: If a strong candidate header was part of the data content of an FCIP Frame, the FCIP Frame defined by that or a subsequent strong candidate header will eventually cross an actual header in the byte stream. As a result it will either identify the actual header as a strong candidate header or it will lose synchronization again because of the extra 28 bytes in the length, returning to step 1 as described above.
注：強力な候補ヘッダはFCIPフレームのデータ内容の一部であった場合、その又は後続の有力な候補のヘッダによって定義されたFCIPフレームは、最終的にバイトストリーム中の実際のヘッダを横切ることになります。結果として、それは、強力な候補ヘッダとして実際のヘッダを識別するか、またはそれは、上述したようにステップ1に戻り、なぜなら、長さが余分に28バイトで再び同期を失うことになります。
3) Use multiple strong candidate headers to locate a verified candidate header:
3）検証候補ヘッダを見つけるために、複数の有力な候補ヘッダを使用します。
Incoming bytes are inspected and discarded until the next verified candidate header is reached. Inspection of the incoming bytes includes testing for other candidate headers using the criteria described in step 1. Each verified candidate header is tested against the tests listed in section 5.6.2.2 as would normally be the case.
着信バイトを検査し、次の検証候補ヘッダに到達するまで破棄されます。着信バイトの検査は、通常の場合であろうように、各検証候補ヘッダはセクション5.6.2.2に記載されているテストに対してテストされ、ステップ1に記載した基準を用いて、他の候補ヘッダの検査を含みます。
Verified candidate headers continue to be located and tested in this way for a minimum of 4352 bytes (twice the maximum length of an FCIP Frame). If all verified candidate headers encountered are valid, the last verified candidate header is a valid header. At this point the FCIP_DE stops discarding bytes and begins normal
検証候補ヘッダが位置し、4352バイトの最小（FCIPフレームの倍の最大長さ）のために、この方法で試験され続けます。発生したすべての検証候補ヘッダが有効であれば、最後の検証候補ヘッダーが有効なヘッダです。この時点で、FCIP_DEは破棄バイトを停止し、通常の始まり
FCIP de-encapsulation, including for the first time since synchronization was lost, delivery of FC Frames through the FC Frame Transmitter Portal according to normal FCIP rules.
FCIP脱カプセル化同期が正常FCIP規則に従ってFCフレーム送信ポータルを介して、FCフレームの送達を失ったので、初めて含みます。
If any verified candidate headers are invalid but meet all the requirements of a strong candidate header, increment the retry counter and return to step 2). If any verified candidate headers are invalid and fail to meet the tests for a strong candidate header, or if inspection of the bytes between verified candidate headers discovers any candidate headers, increment the retry counter and return to step 1. If the retry counter exceeds 4 retries, resynchronization has failed and the TCP/IP connection is closed.
任意の検証候補ヘッダーは無効であるが、強力な候補ヘッダのすべての要件を満たしているリトライカウンタをインクリメントし、ステップ2に戻る場合）。任意の検証候補ヘッダは無効であり、強力な候補ヘッダのテストを満たすことができない、または検証候補ヘッダ間バイトの検査は、任意の候補ヘッダを検出した場合、リトライカウンタをインクリメントし、再試行カウンタが4を超える場合はステップ1に戻ると再試行は、再同期は失敗し、TCP / IP接続が閉じられています。
A flowchart for this algorithm can be found in figure 15.
このアルゴリズムのフローチャートを図15に見出すことができます。
Synchronization is lost
|
_____________v_______________
| |
| Search for candidate header |
+----------->| |
| | Found Not Found |
| | (Strong candidate) |
| |_____________________________|
| | |
| | + --------->close TCP
| _______v_____________________ Connection
| | | and notify
| | Enough strong candidate | the FC Entity
| +---->| headers identified? | with the reason
| | | | for closure
| | | No Yes |
| | | (Verified candidate) |
| | |_____________________________|
|___________________| |
^ | |
| | |
| | _______________________v_____
| | | |
| | | Enough verified candidate |
| | | headers validated? |
| | | |
| | | No Yes |
| | | (Resynchronized) |
| | |_____________________________|
| | | |
| | ______v__________ | Resume
| | | | + ---> Normal
| | | Synchronization | De-encapsulation
| | | Lost? |
| | | |
| | | No Yes |
| | |_________________|
| | | |
| |________| |
|___________________________|
Figure 15: Flow diagram of simple synchronization example
図15：単純な同期の例のフロー図
Appendix E - Relationship between FCIP and IP over FC (IPFC)
付録E - FCオーバーFCIPおよびIPとの関係（IPFC）
The contents of this annex are informative.
この附属書の内容は有益です。
IPFC (RFC 2625) describes the encapsulation of IP packets in FC Frames. It is intended to facilitate IP communication over an FC network.
IPFC（RFC 2625）は、FCフレーム内のIPパケットのカプセル化について説明します。 FCネットワーク上でIP通信を容易にすることを意図しています。
FCIP describes the encapsulation of FC Frames in TCP segments, which in turn are encapsulated inside IP packets for transporting over an IP network. It gives no consideration to the type of FC Frame that is being encapsulated. Therefore, the FC Frame may actually contain an IP packet as described in the IP over FC specification (RFC 2625). In such a case, the data packet would have:
FCIPは、順番に、IPネットワークを介して輸送するためのIPパケット内にカプセル化されたTCPセグメントにおけるFCフレームのカプセル化を記載しています。これは、カプセル化されているFCフレームの種類に何ら考慮されていません。 IP FCオーバー仕様（RFC 2625）に記載されているように、したがって、FCフレームは、実際にIPパケットを含んでいてもよいです。そのような場合には、データパケットがなければなりません。
- Data Link Header - IP Header - TCP Header - FCIP Header - FC Header - IP Header
- データリンクヘッダ - IPヘッダー - TCPヘッダー - FCIPヘッダー - FCヘッダ - IPヘッダー
Note: The two IP headers would not be identical to each other. One would have information pertaining to the final destination, while the other would have information pertaining to the FCIP Entity.
注：2つのIPヘッダは互いに同一ではないでしょう。他のFCIPエンティティに関する情報を持っているだろうが一つは、最終目的地に関する情報を持っているでしょう。
The two documents focus on different objectives. As mentioned above, implementation of FCIP will lead to IP encapsulation within IP. While perhaps inefficient, this should not lead to issues with IP communication. One caveat: if a Fibre Channel device is encapsulating IP packets in an FC Frame (e.g., an IPFC device), and that device is communicating with a device running IP over a non-FC medium, a second IPFC device may need to act as a gateway between the two networks. This scenario is not specifically addressed by FCIP.
二つの文書は、異なる目的に焦点を当てます。前述したように、FCIPの実装は、IP内IPカプセル化につながります。おそらく非効率的なが、これはIP通信の問題につながるべきではありません。 1つの警告：ファイバチャネルデバイス（例えば、IPFCデバイス）FCフレームにIPパケットをカプセル化され、そのデバイスは非FC媒体を介してIPを実行しているデバイスと通信している、第二IPFCデバイスとして行動する必要性がある場合2つのネットワーク間のゲートウェイ。このシナリオは、特にFCIPによって対処されていません。
There is nothing in either of the specifications to prevent a single device from implementing both FCIP and IP-over-FC (IPFC), but this is implementation specific, and is beyond the scope of this document.
そこFCIPおよびIP-オーバーFC（IPFC）の両方を実装するから、単一のデバイスを防ぐための仕様のどちらかには何もありませんが、これは実装固有であり、この文書の範囲を超えています。
Appendix F - FC Frame Format
付録F - FCフレームフォーマット
Note: All users of the words "character" or "characters" in this section refer to 8bit/10bit link encoding wherein each 8 bit "character" within a link frame is encoded as a 10 bit "character" for link transmission. These words do not refer to ASCII, Unicode, or any other form of text characters, although octets from such characters will occur as 8 bit "characters" for this encoding. This usage is employed here for consistency with the ANSI T11 standards that specify Fibre Channel.
注：このセクションのすべての単語「文字」のユーザーまたは「文字」とは、リンク・フレーム内の各8ビットの「文字」がリンク送信のための10ビットの「文字」として符号化される8ビット/ 10ビット・リンク・エンコーディングを指します。そのような文字からオクテットは、このエンコーディングのための8ビットの「文字」として発生しますが、これらの言葉は、ASCII、Unicode文字、またはテキスト文字の任意の他の形式を指すものではありません。この使用法は、ファイバチャネルを指定するANSI T11規格との整合性のために、ここで採用されています。
The contents of this annex are informative.
この附属書の内容は有益です。
All FC Frames have a standard format (see FC-FS [5]) much like LAN's 802.x protocols. However, the exact size of each FC Frame varies depending on the size of the variable fields. The size of the variable field ranges from 0 to 2112-bytes as shown in the FC Frame Format in figure 16, resulting in the minimum size FC Frame of 36 bytes and the maximum size FC Frame of 2148 bytes. Valid FC Frame lengths are always a multiple of four bytes.
すべてのFCフレームはあまりLANの802.Xプロトコルのような（FC-FS [5]を参照）標準フォーマットを持っています。しかし、各FCフレームの正確なサイズは可変フィールドの大きさに応じて変化します。可変フィールドの大きさは、0から36バイトの最小サイズFCフレームと2148バイトの最大サイズFCフレームで、その結果、図16にFCフレームフォーマットに示すように2112バイトの範囲です。有効なFCフレームの長さは常に4バイトの倍数です。
+------+--------+-----------+----//-------+------+------+
| SOF |Frame |Optional | Frame | CRC | EOF |
| (4B) |Header |Header | Payload | (4B) | (4B) |
| |(24B) |<----------------------->| | |
| | | Data Field = (0-2112B) | | |
+------+--------+-----------+----//-------+------+------+
Figure 16: FC Frame Format
図16：FCフレームフォーマット
SOF and EOF Delimiters
SOFとEOFデリミタ
On an FC link, Start-of-Frame (SOF) and End-Of-Frame (EOF) are called Ordered Sets and are sent as special words constructed from the 8B/10B comma character (K28.5) followed by three additional 8B/10B data characters making them uniquely identifiable in the data stream.
FCリンク上、（SOF）の-フレームスタートとエンドオブフレーム（EOF）セットを注文し、8B / 10Bのコンマ文字（K28.5）から構築された特別な言葉は三つの追加8Bが続くとして送信されますと呼ばれています/ 10Bデータの文字データ・ストリームでそれらを一意に識別すること。
On an FC link, the SOF delimiter serves to identify the beginning of an FC Frame and prepares the receiver for FC Frame reception. The SOF contains information about the FC Frame's Class of Service, position within a sequence, and in some cases, connection status.
FCリンク上で、SOFデリミタは、FCフレームの先頭を識別するためのものであり、FCフレーム受信のために受信機を準備します。 SOFは、サービスのFCフレームのクラス、シーケンス内の位置、およびいくつかのケースでは、接続状態に関する情報が含まれています。
The EOF delimiter identifies the end of the FC Frame and the final FC Frame of a sequence. In addition, it serves to force the running disparity to negative. The EOF is used to end the connection in connection-oriented classes of service.
EOF区切り文字はFCフレームおよびシーケンスの最終のFCフレームの終了を識別する。また、負のランニングディスパリティを強制するのに役立ちます。 EOFは、サービスの接続指向のクラスでの接続を終了するために使用されます。
A special EOF delimiter called EOFa (End Of Frame - Abort) is used to terminate a partial FC Frame resulting from a malfunction in a link facility during transmission. Since an FCIP Entity functions like a transmission link with respect to the rest of the FC Fabric, FCIP_DEs may use EOFa in their error recovery procedures.
EOFa（フレームの終わり - アボート）と呼ばれる特別なEOF区切り記号は、送信時のリンク機構の故障に起因する部分的なFCフレームを終端するために使用されます。 FCファブリックの残りの部分に対する伝送リンクのようなFCIPエンティティ機能するので、FCIP_DEsは、それらのエラー回復手順でEOFaを使用することができます。
It is therefore important to preserve the information conveyed by the delimiters across the IP-based network, so that the receiving FCIP Entity can correctly reconstruct the FC Frame in its original SOF and EOF format before forwarding it to its ultimate FC destination on the FC link.
受信FCIPエンティティが正しくFCリンク上の最終的なFC宛先に転送する前に、元のSOFとEOFの形式でFCフレームを再構成することができるように、IPベースのネットワークを介してデリミタによって伝達される情報を保持することが重要です。
When an FC Frame is encapsulated and sent over a byte-oriented interface, the SOF and EOF delimiters are represented as sequences of four consecutive bytes, which carry the equivalent Class of Service and FC Frame termination information as the FC ordered sets.
FCフレームがカプセル化され、バイト指向のインターフェースを介して送信されたときに、SOFとEOF区切り記号は、FCがセットを注文としてサービスとFCフレーム終端情報の等価クラスを運ぶ4つの連続バイトのシーケンスとして表されます。
The representation of SOF and EOF in an encapsulation FC Frame is described in FC Frame Encapsulation [19].
封入FCフレームにおけるSOFとEOFの表現は、FCフレームのカプセル化[19]に記載されています。
Frame Header
フレームヘッダ
The FC Frame Header is transparent to the FCIP Entity. The FC Frame Header is 24 bytes long and has several fields that are associated with the identification and control of the payload. Current FC Standards allow up to 3 Optional Header fields [5]:
FCフレームヘッダは、FCIPエンティティに対して透過的です。 FCフレームヘッダは24バイト長であり、ペイロードの識別と制御に関連付けられているいくつかのフィールドを有しています。現在のFC規格は3つのオプショナルヘッダフィールド[5]まで許可します：
- Network_Header (16-bytes) - Association_Header (32-bytes) - Device_Header (up to 64-bytes).
- Network_Header（16バイト） - Association_Header（32バイト） - Device_Header（64バイトまで）。
Frame Payload
フレームペイロード
The FC Frame Payload is transparent to the FCIP Entity. An FC application level payload is called an Information Unit at the FC-4 Level. This is mapped into the FC Frame Payload of the FC Frame. A large Information Unit is segmented using a structure consisting of FC Sequences. Typically, a Sequence consists of more than one FC Frame. FCIP does not maintain any state information regarding the relationship of FC Frames within an FC Sequence.
FCフレームペイロードは、FCIPエンティティに対して透過的です。 FCアプリケーションレベルのペイロードは、FC-4レベルでの情報単位と呼ばれています。これは、FCフレームのFCフレームペイロードにマッピングされています。大きな情報単位FC配列からなる構造を使用してセグメント化されます。典型的には、配列は、複数のFCフレームで構成されています。 FCIPは、Fc配列内のFCフレームの関係についてどのような状態情報を維持しません。
CRC
CRC
The FC CRC is 4 bytes long and uses the same 32-bit polynomial used in FDDI and is specified in ANSI X3.139 Fiber Distributed Data Interface. This CRC value is calculated over the entire FC header and the FC payload; it does not include the SOF and EOF delimiters.
FC CRCは、4バイト長であり、FDDIで使用したのと同じ32ビットの多項式を使用し、ANSI X3.139ファイバ分散データインタフェースで指定されています。このCRC値は、全体のFCヘッダとFCペイロードに対して計算されます。それはSOFとEOF区切り文字が含まれていません。
Note: When FC Frames are encapsulated into FCIP Frames, the FC Frame CRC is untouched by the FCIP Entity.
注意：FCフレームがFCIPフレームにカプセル化されている場合は、FCフレームCRCは、FCIPエンティティによって変更されません。
Appendix G - FC Encapsulation Format
付録G - FCカプセル化形式
This annex contains a reproduction of the FC Encapsulation Format [19] as it applies to FCIP Frames that encapsulate FC Frames. The information in this annex is not intended to represent the FCIP Special Frame (FSF) that is described in section 7.
それはFCフレームをカプセル化するFCIPフレームに適用されるように、この附属書は、FCカプセル化形式[19]の再生が含まれています。この附属書に記載されている情報は、セクション7に記載されているFCIP特殊フレーム（FSF）を表すことを意図するものではありません。
The information in this annex was correct as of the time this specification was approved. The information in this annex is informative only.
この附属書に記載されている情報は、この仕様が承認された時点の正しかったです。この附属書に記載されている情報は有益です。
If there are any differences between the information here and the FC Encapsulation Format specification [19], the FC Encapsulation Format specification takes precedence.
ここでの情報との差異及びFCカプセル化形式仕様[19]がある場合は、FCカプセル化形式の指定が優先されます。
If there are any differences between the information here and the contents of section 5.6.1, then the contents of section 5.6.1 take precedence.
ここでの情報とセクション5.6.1の内容に違いがある場合、セクション5.6.1の内容が優先されます。
Figure 17 applies the requirements stated in section 5.6.1 and in the FC Encapsulation Frame format resulting in a summary of the FC Frame format. Where FCIP requires specific values, those values are shown in hexadecimal in parentheses. Detailed requirements for the FCIP usage of the FC Encapsulation Format are in section 5.6.1.
図17は、セクション5.6.1およびFCフレームフォーマットの概要をもたらすFCカプセル化フレームフォーマットに記載されている要件を適用します。 FCIPは、特定の値を必要とする場合、これらの値は括弧内に進数で示されています。 FCカプセル化形式のFCIPを使用するための詳細な要件は、セクション5.6.1です。
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 |
| (0x01) | (0x01) | (0xFE) | (0xFE) |
+---------------+---------------+---------------+---------------+
1| Protocol# | Version | -Protocol# | -Version |
| (0x01) | (0x01) | (0xFE) | (0xFE) |
+---------------+---------------+---------------+---------------+
2| pFlags | Reserved | -pFlags | -Reserved |
| (0x00) | (0x00) | (0xFF) | (0xFF) |
+-----------+---+---------------+-----------+---+---------------+
3| Flags | Frame Length | -Flags | -Frame Length |
| (0x00) | | (0x3F) | |
+-----------+-------------------+-----------+-------------------+
4| Time Stamp [integer] |
+---------------------------------------------------------------+
5| Time Stamp [fraction] |
+---------------------------------------------------------------+
6| CRC (Reserved in FCIP) |
| (0x00-00-00-00) |
+---------------+---------------+---------------+---------------+
7| SOF | SOF | -SOF | -SOF |
+---------------+---------------+---------------+---------------+
8| |
+----- FC Frame content (see appendix F) -----+
| |
+---------------+---------------+---------------+---------------+
n| EOF | EOF | -EOF | -EOF |
+---------------+---------------+---------------+---------------+
Figure 17: FCIP Frame Format
図17：FCIPフレームフォーマット
The names of fields are generally descriptive on their contents and the FC Encapsulation Format specification [19] is referenced for details. Field names preceded by a minus sign are ones complement values of the named field.
フィールドの名前は、その内容とFCカプセル化形式仕様に[19]一般に記述されている詳細は、参照されます。マイナス記号が先行するフィールド名はものがという名前のフィールドの値を補完しています。
Note: Figure 17 does not represent the FSF that is described in section 7.
注：図17は、セクション7に記載されているFSFを表すものではありません。
Appendix H - FCIP Requirements on an FC Entity
付録H - FCエンティティのFCIPの要件
The contents of this annex are informative for FCIP but might be considered normative on FC-BB-2.
この附属書の内容は、FCIPのために有益ですが、FC-BB-2に規範的と考えられるかもしれません。
The capabilities that FCIP requires of an FC Entity include:
FCIPはFCエンティティの要求する機能が含まれます：
1) The FC Entity must deliver FC Frames to the correct FCIP Data Engine (in the correct FCIP Link Endpoint).
1）FCエンティティは、正しいFCIPリンクエンドポイントで正しいFCIPデータエンジン（）にFCフレームを提供しなければなりません。
2) Each FC Frame delivered to an FCIP_DE must be accompanied by a time value synchronized with the clock maintained by the FC Entity at the other end of the FCIP Link (see section 6). If a synchronized time value is not available, a value of zero must accompany the FC Frame.
2）FCIP_DEに送達各FCフレーム（セクション6を参照）FCIPリンクの他方の端部にFCエンティティによって維持されるクロックに同期した時刻値を添付しなければなりません。同期時間値が使用できない場合は、ゼロの値は、FCフレームを添付しなければなりません。
3) When FC Frames exit FCIP Data Engine(s) via the FC Frame Transmitter Portal(s), the FC Entity should forward them to the FC Fabric. However, before forwarding an FC Frame, the FC Entity must compute the end-to-end transit time for the FC Frame using the time value supplied by the FCIP_DE (taken from the FCIP header) and a synchronized time value (see section 6). If the end-to-end transit time exceeds the requirements of the FC Fabric, the FC Entity is responsible for discarding the FC Frame.
ときにFCフレーム出口FCIPデータエンジン（S）FCフレームトランスミッタポータル（複数可）を経由して3）、FCエンティティは、FCファブリックに転送しなければなりません。しかし、FCフレームを転送する前に、FCエンティティはFCIP_DE（FCIPヘッダから取得）と同期した時刻値によって供給された時間値を使用して、FCフレーム用のエンドツーエンドの通過時間を計算しなければならない（セクション6を参照） 。エンドツーエンドの通過時間は、FCファブリックの要件を超える場合は、FCエンティティは、FCフレームを廃棄する責任があります。
4) The only delivery ordering guarantee provided by FCIP is correctly ordered delivery of FC Frames between a pair of FCIP Data Engines. FCIP expects the FC Entity to implement all other FC Frame delivery ordering requirements.
4）FCIPが提供する唯一の配信順序保証が正しくFCIPデータエンジンのペア間のFCフレームの配信を命じています。 FCIPはFCエンティティは、他のすべてのFCフレーム配信の順序付けの要件を実装する予定です。
5) When a TCP connect request is received and that request would add a new TCP Connection to an existing FCIP_LEP, the FC Entity must authenticate the source of the TCP connect request before use of the new TCP connection is allowed.
TCP接続要求を受信し、その要求は、既存のFCIP_LEPへの新しいTCPコネクションを追加した場合5）、FCエンティティは、TCPのソースが許可されている新しいTCP接続の使用前に、接続要求を認証する必要があります。
6) The FC Entity may participate in determining allowed TCP Connections, TCP Connection parameters, quality of service usage, and security usage by modifying interactions with the FCIP Entity that are modelled as a "shared" database in section 8.1.1.
6）FCエンティティは、セクション8.1.1で「共有」データベースとしてモデル化されるFCIPエンティティとの相互作用を変更することにより、許可されたTCP接続、TCP接続パラメータ、サービス利用の品質、およびセキュリティの使用を決定することに関与し得ます。
7) The FC Entity may require the FCIP Entity to perform TCP close requests.
7）FCエンティティは、TCPのクローズ要求を実行するためにFCIPエンティティが必要な場合があります。
8) The FC Entity may recover from connection failures.
8）FCエンティティは、接続障害から回復することができます。
9) The FC Entity must recover from events that the FCIP Entity cannot handle, such as: a) loss of synchronization with FCIP Frame headers from the Encapsulated Frame Receiver Portal requiring resetting the TCP Connection; and
9）FCエンティティは、次のようなFCIPエンティティを扱うことができない事象から回復しなければならない：カプセル化されたフレーム受信ポータルからFCIPフレームヘッダがTCP接続をリセットする必要との同期a）の喪失;そして
b) recovering from FCIP Frames that are discarded as a result of synchronization problems (see section 5.6.2.2 and section 5.6.2.3).
b）は、同期化の問題（セクション5.6.2.2と5.6.2.3節を参照）の結果として廃棄されるFCIPフレームから回収します。
10) The FC Entity must work cooperatively with the FCIP Entity to manage flow control problems in either the IP Network or FC Fabric.
10）FCエンティティは、IPネットワークまたはFCファブリックのいずれかでフロー制御の問題を管理するために、FCIPエンティティと協調動作する必要があります。
11) The FC Entity may test for failed TCP Connections.
11）FCエンティティは、失敗したTCP接続をテストすることがあります。
Note that the Fibre Channel standards must be consulted for a
complete understanding of the requirements placed on an FC
Entity.
Table 2 shows the explicit interactions between the FCIP Entity and the FC Entity.
表2は、FCIPエンティティとFCエンティティとの間の明示的な相互作用を示しています。
+-------------+-----------------+-----------------------------------+
| | | Information/Parameter Passed and |
| | | Direction |
| Reference | +-----------------+-----------------+
| Section | Condition | FCIP Entity---> | <---FC Entity |
+-------------+-----------------+-----------------+-----------------+
| 5.6 | FC Frame ready | | Provide FC |
| FCIP Data | for IP transfer | | Frame and |
| Engine | | | time stamp at |
| | | | FC Frame |
| | | | Receiver Portal |
+-------------+-----------------+-----------------+-----------------+
| WWN = World Wide Name |
+-------------------------------------------------------------------+
| continued |
+-------------------------------------------------------------------+
Table 2: FC/FCIP Entity pair interactions (part 1 of 5)
表2：FC / FCIPエンティティ対相互作用（5のパート1）
+-------------+-----------------+-----------------------------------+
| | | Information/Parameter Passed and |
| | | Direction |
| Reference | +-----------------+-----------------+
| Section | Condition | FCIP Entity---> | <---FC Entity |
+-------------+-----------------+-----------------+-----------------+
| continued |
+-------------+-----------------+-----------------+-----------------+
| 5.6 | FCIP Frame | Provide FC | |
| FCIP Data | received from | Frame and | |
| Engine | IP Network | time stamp at | |
| | | FC Frame Trans- | |
| | | mitter Portal | |
+-------------+-----------------+-----------------+-----------------+
| 5.6.2.2 | FCIP_DE | Inform FC | |
| Errors | discards bytes | Entity that | |
| in FCIP | delivered | bytes have been | |
| Headers and | through | discarded with | |
| Discarding | Encapsulated | reason | |
| FCIP Frames | Frame Receiver | | |
| | Portal | | |
+-------------+-----------------+-----------------+-----------------+
| 5.6.2.3 | FCIP Entity | Inform FC | |
| Synchron- | closes TCP | Entity that TCP | |
| ization | Connection due | Connection has | |
| Failures | to synchron- | been closed | |
| | ization failure | with reason | |
| | | for closure | |
+-------------+-----------------+-----------------+-----------------+
| 8.1.2.3 | Receipt of the | Inform FC | |
| Connection | echoed FSF | Entity that TCP | |
| Setup | takes too long | Connection has | |
| Following a | or the FSF | been closed | |
| Successful | contents have | with reason | |
| TCP Connect | changed | for closure | |
| Request | | | |
+-------------+-----------------+-----------------+-----------------+
| WWN = World Wide Name |
+-------------------------------------------------------------------+
| continued |
+-------------------------------------------------------------------+
Table 2: FC/FCIP Entity pair interactions (part 2 of 5)
表2：FC / FCIPエンティティ対相互作用（5のパート2）
+-------------+-----------------+-----------------------------------+
| | | Information/Parameter Passed and |
| | | Direction |
| Reference | +-----------------+-----------------+
| Section | Condition | FCIP Entity---> | <---FC Entity |
+-------------+-----------------+-----------------+-----------------+
| continued |
+-------------+-----------------+-----------------+-----------------+
| 8.1.2.1 | New TCP | Inform FC | |
| Non-Dynamic | Connection | Entity of | |
| Creation of | created based | new or existing | |
| a New TCP | on "shared" | FCIP_LEP and | |
| Connections | database | new FCIP_DE | |
| | information | along with | |
| | | Destination FC | |
| | | Fabric Entity | |
| | | WWN, Connection | |
| | | Usage Flags, | |
| | | Connection | |
| | | Usage Code and | |
| | | Connection | |
| | | Nonce | |
+-------------+-----------------+-----------------+-----------------+
| 8.1.2.2 | New TCP | Inform FC | |
| Dynamic | Connection | Entity of | |
| Creation of | created based | new or existing | |
| a New TCP | on SLP service | FCIP_LEP and | |
| Connections | advertisement | new FCIP_DE | |
| | and "shared" | along with | |
| | database | Destination FC | |
| | information | Fabric Entity | |
| | | WWN, Connection | |
| | | Usage Flags, | |
| | | Connection | |
| | | Usage Code and | |
| | | Connection | |
| | | Nonce | |
+-------------+-----------------+-----------------+-----------------+
| WWN = World Wide Name |
+-------------------------------------------------------------------+
| continued |
+-------------------------------------------------------------------+
Table 2: FC/FCIP Entity pair interactions (part 3 of 5)
表2：FC / FCIPエンティティ対相互作用（5のパート3）
+-------------+-----------------+-----------------------------------+
| | | Information/Parameter Passed and |
| | | Direction |
| Reference | +-----------------+-----------------+
| Section | Condition | FCIP Entity---> | <---FC Entity |
+-------------+-----------------+-----------------+-----------------+
| continued |
+-------------+-----------------+-----------------+-----------------+
| 8.1.3 | New TCP | Inform FC | |
| Processing | Connection | Entity of | |
| Incoming | created based | new or existing | |
| TCP Connect | on incoming TCP | FCIP_LEP and | |
| Requests | Connect request | new FCIP_DE | |
| | and "shared" | along with | |
| | database | Source FC | |
| | information | Fabric Entity | |
| | | WWN, Source | |
| | | FC/FCIP Entity | |
| | | Identifier, | |
| | | Connection | |
| | | Usage Flags, | |
| | | Connection | |
| | | Usage Code and | |
| | | Connection | |
| | | Nonce | |
+-------------+-----------------+-----------------+-----------------+
| 8.1.3 | TCP Connect | Request FC | Yes or No |
| Processing | Request wants | Entity to | answer about |
| Incoming | to add a new | authenticate | whether the |
| TCP Connect | TCP Connection | the source of | source of the |
| Requests | to an existing | the TCP Connect | TCP Connect |
| | FCIP_LEP | Request | Request can be |
| | | | authenticated |
+-------------+-----------------+-----------------+-----------------+
| 8.1.3 | Receipt of the | Inform FC | |
| Processing | FSF takes too | Entity that TCP | |
| Incoming | long or | Connection has | |
| TCP Connect | duplicate | been closed | |
| Requests | Connection | with reason | |
| | Nonce value | for closure | |
+-------------+-----------------+-----------------+-----------------+
| WWN = World Wide Name |
+-------------------------------------------------------------------+
| continued |
+-------------------------------------------------------------------+
Table 2: FC/FCIP Entity pair interactions (part 4 of 5)
表2：FC / FCIPエンティティ対相互作用（5のパート4）
+-------------+-----------------+-----------------------------------+
| | | Information/Parameter Passed and |
| | | Direction |
| Reference | +-----------------+-----------------+
| Section | Condition | FCIP Entity---> | <---FC Entity |
+-------------+-----------------+-----------------+-----------------+
| concluded |
+-------------+-----------------+-----------------+-----------------+
| 8.2 | FC Entity | Acknowledgement | Identification |
| Closing TCP | determines | of TCP | of the FCIP_DE |
| Connections | that a TCP | Connection | whose TCP |
| | Connection | closure | Connection |
| | needs to be | | needs to be |
| | closed | | closed |
+-------------+-----------------+-----------------+-----------------+
| 8.4 | Discovery that | Inform FC | |
| TCP | TCP connectiv- | Entity that TCP | |
| Connection | ity has been | Connection has | |
| Considera- | lost | been closed | |
| tions | | with reason | |
| | | for closure | |
+-------------+-----------------+-----------------+-----------------+
| 9.4.1 | IKE phase 1 | Inform FC | |
| FCIP | failed, result- | Entity that TCP | |
| Link | ing in termin- | Connection can | |
| Initializ- | ation of link | not be opened | |
| ation Steps | initialization | with reason for | |
| | | failure | |
+-------------+-----------------+-----------------+-----------------+
| 9.4.3 | Excessive | Inform FC | |
| Handling | numbers of | Entity that TCP | |
| data | dropped | Connection has | |
| integrity | datagrams | been closed | |
| and confi- | detected and | with reason | |
| dentiality | TCP Connection | for closure | |
| violations | closed | | |
+-------------+-----------------+-----------------+-----------------+
| RFC 3723 | TCP Connection | Inform FC | |
| | closed due to | Entity that TCP | |
| Handling SA | SA parameter | Connection has | |
| parameter | mismatch | been closed | |
| mismatches | problems | with reason | |
| | | for closure | |
+-------------+-----------------+-----------------+-----------------+
| WWN = World Wide Name |
+-------------------------------------------------------------------+
Table 2: FC/FCIP Entity pair interactions (part 5 of 5)
表2：FC / FCIPエンティティ対相互作用（5の一部5）
Editors and Contributors Acknowledgements
編集者や協力者謝辞
During the development of this specification, Murali Rajagopal, Elizabeth Rodriguez, Vi Chau, and Ralph Weber served consecutively as editors. Raj Bhagwat contributed substantially to the initial basic FCIP concepts.
この仕様の開発中に、ムラリRajagopal、エリザベス・ロドリゲス、Viのチャウ、そしてラルフ・ウェーバーは、編集者として連続して務めました。ラジBhagwatは、最初の基本的なFCIPの概念に大きく貢献しました。
Venkat Rangan contributed the Security section and continues to coordinate security issues with the ips Working Group and IETF.
ベンカット・ランガンは、セキュリティセクションを拠出し、IPSワーキンググループとIETFでのセキュリティ上の問題を調整し続けています。
Andy Helland contributed a substantial revision of Performance section, aligning it with TCP/IP QoS concepts.
アンディHellandは、TCP / IPのQoSの概念とそれを合わせて、パフォーマンス]セクションの実質的な改正に貢献しました。
Dave Peterson contributed the dynamic discovery section and edits to RFC 3822.
デイブ・ピーターソンは、RFC 3822に動的検出部と、編集内容を貢献しました。
Anil Rijhsinghani contributed material related to the FCIP MIB and edits the FCIP MIB document.
アニルRijhsinghaniはFCIP MIBに関連する材料を拠出し、FCIP MIBドキュメントを編集します。
Bob Snively contributed material related to error detection and recovery including the bulk of the synchronization recovery example annex.
ボブSnivelyは、同期回復例附属書のバルクを含む検出と回復をエラーに関連材料に貢献しました。
Lawrence J. Lamers contributed numerous ideas focused on keeping FCIP compatible with B_Port devices.
ローレンス・J. LamersはB_portとデバイスとの互換性を維持するFCIPに焦点を当てた数々のアイデアを貢献しました。
Milan Merhar contributed several of the FCIP conceptual modifications necessary to support NATs.
ミラノMerharは、NATのをサポートするために必要なFCIP概念の改変のいくつかの貢献しました。
Don Fraser contributed material related to link failure detection and reporting.
ドン・フレーザーは、障害検出および報告をリンクする関連材料を貢献しました。
Bill Krieg contributed a restructuring of the TCP Connection setup sections that made them more linear with respect to time and more readable.
ビル・クリーグは、彼らがより多くの時間とより読みやすいに対して線形作られたTCP接続のセットアップセクションの再構築に貢献しました。
Several T11 leaders supported this effort and advised the editors of this specification regarding coordination with T11 documents and projects. These T11 leaders are: Jim Nelson (Framing and Signaling), Neil Wanamaker (Framing and Signaling), Craig Carlson (Generic Services), Ken Hirata (Switch Fabric), Murali Rajagopal (Backbone), Steve Wilson (Switch Fabric), and Michael O'Donnell (Security Protocols).
いくつかのT11の指導者たちは、この努力を支持し、T11文書やプロジェクトとの連携については、この仕様の編集者を助言しました。これらのT11の指導者は、次のとおりです。ジム・ネルソン（フレーミングおよびシグナリング）、ニール・ワナメーカー（フレーミングおよびシグナリング）、クレイグカールソン（ジェネリックサービス）、ケン・平田（スイッチファブリック）、ムラリRajagopal（バックボーン）、スティーブ・ウィルソン（スイッチファブリック）、そしてマイケルオドネル（セキュリティプロトコル）。
Editors and Contributors Addresses
編集者や協力者のアドレス
Neil Wanamaker Akara 10624 Icarus Court Austin, TX 78726 USA
ニール・ワナメーカーアカラ10624イカルス裁判所オースティン、TX 78726 USA
Phone: +1 512 257 7633 Fax: +1 512 257 7877 EMail: nwanamaker@akara.com
電話：+1 512 257 7633ファックス：+1 512 257 7877 Eメール：nwanamaker@akara.com
Ralph Weber ENDL Texas, representing Brocade Suite 102 PMB 178 18484 Preston Road Dallas, TX 75252 USA
ブロケードスイート102 PMB 178 18484のプレストンロードダラス、TX 75252 USAを代表するラルフ・ウェーバーENDLテキサス、
Phone: +1 214 912 1373 EMail: roweber@ieee.org
電話：+1 214 912 1373 Eメール：roweber@ieee.org
Elizabeth G. Rodriguez Dot Hill Systems Corp. 6305 El Camino Real Carlsbad, CA 92009 USA
エリザベスG.ロドリゲスドットヒルシステムズ株式会社6305エル・カミノレアルカールスバッド、CA 92009 USA
Phone: +1 760 431 4435 EMail: elizabeth.rodriguez@dothill.com
電話：+1 760 431 4435 Eメール：elizabeth.rodriguez@dothill.com
Steve Wilson Brocade Comm. Systems, Inc. 1745 Technology Drive San Jose, CA. 95110 USA
スティーブ・ウィルソンブロケードコム。 Systems、Inc.の1745年テクノロジー・ドライブサンノゼ、CA。 95110 USA
Phone: +1 408 333 8128 EMail: swilson@brocade.com
電話：+1 408 333 8128 Eメール：swilson@brocade.com
Bob Snively Brocade Comm. Systems, Inc. 1745 Technology Drive San Jose, CA 95110 USA
ボブSnivelyブロケードコム。 Systems、Inc.の1745年テクノロジー・ドライブサンノゼ、CA 95110 USA
Phone: +1 408 303 8135 EMail: rsnively@brocade.com
電話：+1 408 303 8135 Eメール：rsnively@brocade.com
David Peterson Cisco Systems - SRBU 6450 Wedgwood Road Maple Grove, MN 55311 USA
デヴィッド・ピーターソンシスコシステムズ - SRBU 6450ウェッジウッド道路メープルグローブ、MN 55311 USA
Phone: +1 763 398 1007 Cell: +1 612 802 3299 EMail: dap@cisco.com
電話：+1 763 398 1007セル：+1 612 802 3299 Eメール：dap@cisco.com
Donald R. Fraser Hewlett-Packard 301 Rockrimmon Blvd., Bldg. 5 Colorado Springs, CO 80919 USA
ドナルドR.フレーザーヒューレットパッカード301 Rockrimmonブルバード、ビル。 5つのコロラドスプリングズ、コロラド州80919 USA
Phone: +1 719 548 3272 EMail: Don.Fraser@HP.com
電話：+1 719 548 3272 Eメール：Don.Fraser@HP.com
R. Andy Helland LightSand Communications, Inc. 375 Los Coches Street Milpitas, CA 95035 USA
R.アンディHelland LightSandコミュニケーションズ株式会社375ロスCochesのストリートミルピタス、CA 95035 USA
Phone: +1 408 404 3119 Fax: +1 408 941 2166 EMail: andyh@lightsand.com
電話：+1 408 404 3119ファックス：+1 408 941 2166 Eメール：andyh@lightsand.com
Raj Bhagwat LightSand Communications, Inc. 24411 Ridge Route Dr. Suite 135 Laguna Hills, CA 92653 USA
ラジBhagwat LightSandコミュニケーションズ株式会社24411リッジルート博士スイート135ラグーナヒルズ、CA 92653 USA
Phone: +1 949 837 1733 x104 EMail: rajb@lightsand.com
電話：+1 949 837 1733 x104電子メール：rajb@lightsand.com
Bill Krieg Lucent Technologies 200 Lucent Lane Cary, NC 27511 USA
ビル・戦争ルーセント・テクノロジーズ・ルーセント200レーンカリー、NC 27511 USA
Phone: +1 919 463 4020 Fax: +1 919 463 4041 EMail: bkrieg@lucent.com
電話：+1 919 463 4020ファックス：+1 919 463 4041 Eメール：bkrieg@lucent.com
Michael E. O'Donnell McDATA Corporation 310 Interlocken Parkway Broomfield, CO 80021 USA
マイケルE.オドネルマクデータ社310インターパークウェイブルームフィールド、CO 80021 USA
Phone: +1 303 460 4142 Fax: +1 303 465 4996 EMail: modonnell@mcdata.com
電話：+1 303 460 4142ファックス：+1 303 465 4996 Eメール：modonnell@mcdata.com
Anil Rijhsinghani McDATA Corporation 310 Interlocken Parkway Broomfield, CO 80021 USA
アニルRijhsinghaniマクデータ社310インターパークウェイブルームフィールド、CO 80021 USA
Phone: +1 508 870 6593 EMail: anil.rijhsinghani@mcdata.com
電話：+1 508 870 6593 Eメール：anil.rijhsinghani@mcdata.com
Milan J. Merhar 43 Nagog Park Pirus Networks Acton, MA 01720 USA
ミラノJ. Merhar 43 NagogパークPirus Networksのアクトン、MA 01720 USA
Phone: +1 978 206 9124 EMail: Milan@pirus.com
電話：+1 978 206 9124 Eメール：Milan@pirus.com
Craig W. Carlson QLogic Corporation 6321 Bury Drive Eden Prairie, MN 55346 USA
クレイグW.カールソンのQLogic社6321ドライブイーデンプレーリー、MN 55346 USAベリー
Phone: +1 952 932 4064 EMail: craig.carlson@qlogic.com
電話：+1 952 932 4064 Eメール：craig.carlson@qlogic.com
Venkat Rangan Rhapsody Networks Inc. 3450 W. Warren Ave. Fremont, CA 94538 USA
ベンカット・ランガンラプソディ・ネットワーク株式会社3450 W.ウォーレン・アベニュー。フリーモント、CA 94538 USA
Phone: +1 510 743 3018 Fax: +1 510 687 0136 EMail: venkat@rhapsodynetworks.com
電話：+1 510 743 3018ファックス：+1 510 687 0136 Eメール：venkat@rhapsodynetworks.com
Lawrence J. Lamers SAN Valley Systems, Inc. 6320 San Ignacio Ave. San Jose, CA 95119-1209 USA
ローレンス・J. Lamers SANバレーシステムズ株式会社6320サンイグナチオアベニュー。サンノゼ、CA 95119-1209 USA
Phone: +1 408 234 0071 EMail: ljlamers@ieee.org
電話：+1 408 234 0071 Eメール：ljlamers@ieee.org
Murali Rajagopal Broadcom Corporation 16215 Alton Parkway Irvine,CA 92619 USA
ムラリRajagopalブロードコム・コーポレーション16215アルトンパークウェイアーバイン、CA 92619 USA
Phone: +1 949 450 8700 EMail: muralir@broadcom.com
電話：+1 949 450 8700 Eメール：muralir@broadcom.com
Ken Hirata Vixel Corporation 15245 Alton Parkway, Suite 100 Irvine, CA 92618 USA
ケン・平田のVixel社15245アルトンパークウェイ、スイート100アーバイン、CA 92618 USA
Phone: +1 949 788 6368 Fax: +1 949 753 9500 EMail: ken.hirata@vixel.com
電話：+1 949 788 6368ファックス：+1 949 753 9500 Eメール：ken.hirata@vixel.com
Vi Chau USA Email: vchau1@cox.net
ViのチャウUSA Eメール：vchau1@cox.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). 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.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。