[要約] RFC 3821は、Fibre Channel Over TCP/IP（FCIP）プロトコルに関する仕様を提供します。FCIPは、Fibre ChannelストレージネットワークをTCP/IPネットワーク上で拡張するために使用されます。このRFCの目的は、FCIPの動作と機能を定義し、異なるストレージネットワークを接続するためのガイドラインを提供することです。
Network Working Group M. Rajagopal
Request for Comments: 3821 E. Rodriguez
Category: Standards Track R. Weber
July 2004
Fibre Channel Over TCP/IP (FCIP)
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）The Internet Society（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）は、主にストレージエリアネットワーク（SANS）を実装するために使用されるギガビットまたはマルチギガビット速度ネットワーキングテクノロジーです。ファイバーチャネルの標準化方法と、この仕様とファイバーチャネル標準の関係については、セクション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ネットワーク上の繊維チャネルSANSの島の相互接続を可能にして、単一のファイバーチャネルファブリックで統一された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、MAN、およびWANSにまたがる場合があります。
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フレームカプセル化を使用して、ファイバーチャネル（FC）フレームのカプセル化とマッピングを指定します[19]。
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) 1）で説明されているメカニズムを、FCファブリック内の2つ以上の島間の相互接続としてIPネットワークを使用してFCファブリックに適用します。
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ベースのネットワーク上のTunneling 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) FCファブリックを拡張するために使用されるIPネットワークを他の合理的な目的で同時に使用できるように、適用されるすべての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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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は、T11技術委員会のINCITS（国際情報技術基準委員会）によって開発されたアメリカ国家基準の家族として標準化されています。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 -FIBERチャネルバックボーン[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は、FCファブリックと、ファイバーチャネル標準（ATMやSONETなど）で定義されていない相互接続テクノロジーとの関係を説明しています。FC-BB-2は、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アクティビティに関する追加情報は、委員会のWebサイト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ファブリックをトンネルする製品は、実装固有のインターフェイスを使用してFCIPエンティティとFCエンティティ（セクション5.3を参照）を組み合わせる必要があります。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を定義する試みは行われていません。アプローチは、FCIPエンティティとFCエンティティ（どちらもIPネットワーク全体で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エンティティ - FCIPエンティティと組み合わせてFCファブリックとIPネットワークの間にインターフェイスを形成するファイバーチャネル固有の機能コンポーネント（セクション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 Fabric-さまざまなNX_PORTS（[5]を参照）を相互接続するエンティティ（[5]を参照）に接続されており、FCフレームヘッダーの宛先ID情報のみを使用してFCフレームをルーティングできます（付録Fを参照）。
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ファブリックエンティティ - 1つ以上のinterconnect_ports（FC-SW-2 [4]を参照）および1つ以上のFC/FCIPエンティティペアを含むファイバーチャネル固有の要素。FCファブリックエンティティの詳細については、FC-BB-2 [3]を参照してください。
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フレームとタイムスタンプがFCIPデータエンジンをFCエンティティに残すアクセスポイント。
FC/FCIP Entity pair - The combination of one FC Entity and one FCIP entity.
FC/FCIPエンティティペア - 1つのFCエンティティと1つの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 Data Engine（FCIP_DE） - FCフレームのカプセル化、脱カプセル化、および送信FCIPフレームを単一のTCP接続を介して処理する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]ヘッダー、Encoded SOF、およびFCフレームを含むEOFをエンコードしたEOF（セクション5.6.1を参照）。
FCIP Link - One or more TCP Connections that connect one FCIP_LEP to another (see section 5.2).
FCIPリンク-1つのFCIP_LEPを別のFCIP_LEPに接続する1つ以上のTCP接続（セクション5.2を参照）。
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リンクを処理し、1つ以上のFCIP_DESを含むFCIPエンティティのコンポーネント（セクション5.5を参照）。
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 Special Frame（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ファブリックの観点から見ると、FCIPエンティティのペアは、関連するFCエンティティと組み合わせて、FCファブリック要素間のFCフレームを転送します。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].
4) FCプリミティブシグナル、プリミティブシーケンス、およびクラス1 FCフレームは、FCフレームカプセル化を使用してエンコードできないため、FCIPリンク全体に送信されません[19]。
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）は、他の1つの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.
7) 複数のFCIP_DEを持つ複数のFCIP_LEPが使用されている場合、特定のFCフレームのカプセル化と送信に使用するFCIP_DEの選択は、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制御およびサービスモジュールは、TCP/IPのサービス機能を使用する場合があります（セクション10.2を参照）。
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) 各FCIPエンティティを、通信を開始することが期待されるFCIPエンティティに対応するIPアドレスとTCPポート番号を使用して、各FCIPエンティティを静的または動的に構成する必要があります。参加しているFCIPエンティティの動的発見がサポートされている場合、サービスはサービスロケーションプロトコル（SLPV2）[17]を使用して実行されます。参加する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ファブリックエンティティワールドワイド名、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アドレスの発見（FCIPエンティティを介してアクセス可能）は、FC-FS [5]およびFC-SW-2 [4]に記載されているように、FCアーキテクチャ内の技術とプロトコルによって提供されます。
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-インターネットプロトコルリンク - IPリンクレイヤーPHY -IP Physical層
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リンクは、FCIPプロトコルがFCファブリックに提供する基本的なサービスユニットです。図2に示すように、FCIPリンクは、IPネットワークを使用してトランスポートとして単一のFCファブリックを形成する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.
FCIPリンクの端がFCファブリックの一部を満たしているポイントでは、FCIPエンティティ（セクション5.4を参照）がFC 5.3で説明されているようにFCエンティティと組み合わせて、FCとIPの間のインターフェイスとして機能します。
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.
IPネットワークを介してFCファブリックをトンネルする実装では、FCエンティティとFCIPエンティティを組み合わせて（セクション5.4を参照）、図3に示すようにFCファブリックとIPネットワークの間に完全なインターフェイスを形成する必要があります。図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エンティティは、管理するFCIP_LEPSに代わってTCP Connectリクエストを受信します。これをサポートして、FCIPエンティティは、TCP接続を形成するために使用される少なくとも1つのTCPポート/IPアドレスの組み合わせの唯一の所有者です。TCPポートは、特定のIPアドレスのFCIPよく知られているポートである可能性があります。FCファブリックからIPネットワークインターフェイス製品は、製品に含まれる各FC/FCIPエンティティペアを、FC Fabric Entity World Wide IdentifierとFC/FCIPエンティティ識別子値の独自の組み合わせを提供します（セクション7を参照）。
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リンクの初期化、FCIPリンク溶解を制御し、FCエンティティに主要なIPネットワーク機能へのインターフェイスを提供します。
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接続が新しいFC/FCIPエンティティペア（セクション8.1で説明されているすべてのアクションを含む）で形成されるたびに、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のペアがFCIPリンクを作成してFCファブリックの2つの島に参加し、FCファブリックを1つ生産します。
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は、通常のTCPベースのフロー制御メカニズムを使用して、内部リソースを管理し、広告されたTCPレシーバーウィンドウサイズと一致させます（セクション8.3.2、8.5を参照）。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の1つのモデルを図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.
P1）FCフレームレシーバーポータル - FCフレームとタイムスタンプがFCエンティティからFCIP_DEに入るインターフェイス。
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フレームがFCIP_DEによって受信される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フレームカプセル化[19]およびこのドキュメントのセクション5.6.1で説明されているカプセル化形式を使用して、FCフレームをカプセル化および脱カプセル化します。
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_DEを接続した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エンティティがFCフレームカプセル化[19]の仕様に記載されているタイムベースに関して、非シヌクロ化状態にある場合、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) カプセル化エンジンでは、FCフレームカプセル化[19]およびこのドキュメントのセクション5.6.1で説明されているカプセル化形式を適用して、FCフレームとIPネットワーク上の伝送のための関連するタイムスタンプを準備するものとします。
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) カプセル化されたFCフレーム全体（別名FCIPフレーム）は、カプセル化されたフレームトランスミッターポータルに渡され、そこで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エンティティに到着し、カプセル化されたフレームレシーバーポータルを介してFCIP_DEに入り、処理のために脱カプセル化エンジンに渡されます。
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) 脱カプセル化エンジンは、セクション5.6.2.2で説明されているように着信TCPバイトストリームを検証し、FCフレームのカプセル化[19]およびセクション5.6.1で説明されているカプセル化形式に従ってFCフレームと関連するタイムスタンプを脱カプセル化するものとします。このドキュメントの。
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.
FCフレームレシーバーポータルに到着するすべてのFCフレームは、上記の手順1〜4で説明されているように、IPネットワークに送信されます。エラーがない場合、カプセル化されたフレームレシーバーポータルに到着するデータバイトは、ステップ5〜7で説明されているように、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フレームカプセル化のIANA考慮事項の付録に従って1が含まれます[19]。
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]にWord 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フレームが含まれている場合、SFビットは0になります。FCIPフレームがFSFである場合、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.
FSFは、新しく形成されたTCP接続で各方向に送信された最初のバイトとしてのみ送信され、その時点で各方向に1つの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（変更）ビットは、エコーされたFSFが意図的に変更されたかどうかを示します（セクション8.1.3を参照）。FSFビットが1でない限り、CHビットは0でなければなりません。初期TCP接続FSFが送信される場合、CHビットは0になります。TCP接続要求のレシピエントが変更なしでFSFをエコーした場合、CHビットは継続します。0.になります。TCP接続要求の受信者がエコーする前にFSFを変更する場合、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チェックサムのチェックで必要です。したがって、TCPからFCIP_LEPに渡されたバイトストリームは、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カプセル化ヘッダーがどこにあるかを決定します。カプセル化されたフレームレシーバーポータルに入るバイトストリームとの同期を確認するために、次のテストを実行し、テストのいずれかが失敗した場合、同期は失われたと見なされます。
1) Frame Length field validation -- 15 < Frame Length < 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) BITS 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つの単語、エンコードされたSOF値とEOF値にそれぞれ1つの単語が必要で、FCフレームヘッダーは6つの単語で、FC CRCは1つの単語を必要とし、ベースフレーム長は16（7 1 1 6 1）言葉、FCペイロードが存在しない場合。FCペイロードはオプションであるため、15を超えるフレーム長い値は有効です。最大FCペイロードサイズは528ワードです。つまり、544（528 16）までのフレーム長値が有効です。
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がカプセル化されたフレームレシーバーポータルを介して配信されたバイトを破棄する場合はいつでも、FCIPエンティティにFCエンティティに条件を通知し、理由の適切な説明を提供します。
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) カプセル化されたフレームレシーバーポータルによって配信されたバイトを検索して、正しいプロパティを備えた有効なFCIPフレームヘッダーを検索することにより、同期を回復し（セクション5.6.2.2を参照）、有効な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）で説明されているように同期を回復しようとします。また、同期を回復できない場合は、a）で説明されているように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) 同期前に識別されたFCフレームとFCフレームの断片は、EOFA（付録セクションF.1を参照）で廃棄または識別します。転送されていない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]は、FCフレームカプセル化[19]仕様に記載されている要件に基づいて、IPネットワークトランジット時間の測定がどのように実行されるかを定義します。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がタイムスタンプ[整数]およびタイムスタンプ[分数]フィールドに配置するタイムスタンプ値を添付するものとします。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エンティティは、FCIPリンクで通信しているFCエンティティが、ファイバーチャネルサービスまたは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_DEに1つの同期時間値のみが必要であることを意味することに注意してください。
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接続で各方向に送信された最初のバイトとしてのみ送信され、各方向に1つの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には、PFLAGS SFビットが1に設定されている必要があります（セクション5.6.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ファブリックエンティティワールドワイドネームフィールドには、（エコーとは対照的に）FSFを生成するFC/FCIPエンティティペアに関連付けられたFCファブリックエンティティのファイバーチャネルname_identifier [5]が含まれます。たとえば、FCファブリックエンティティがFCスイッチの場合、FC Fabric Entity World Wide Name Fieldには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エンティティペアの一意の識別子を含めるものとします。この値は、World Wide NameがSource FC Fabric Entity World Wide Name Fieldに表示される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エンティティワールドワイドネームとソース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]のランダム性推奨事項に従う必要があります。
The Connection Usage Flags field identifies the types of SOF values [19] to be carried on the connection as shown in figure 10.
接続使用フラグフィールドは、図10に示すように、接続に掲載されるSOF値のタイプ[19]を識別します。
|------------------------------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接続情報の「共有」データベースに適切なQoS設定を見つけ（セクション8.1.1を参照）、それらの設定を新しく形成された接続に適用するものとします。
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ファブリックエンティティワールドワイドネームフィールドには、FC/FCIPエンティティペアに関連付けられたFCファブリックエンティティのファイバーチャネルname_identifier [5]が含まれている場合があります。
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フィールドには、FC-BB-2で指定されているように、新しいTCP接続に適用されるFC Keep Alive Timeout値が含まれます。
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 Connectリクエストとその後のFSFを受け取った各FCIPエンティティは、ソースFCファブリックエンティティワールドワイドネーム、ソースFC/FCIP識別子、接続使用フラグ、接続使用法コードフィールドのコンテンツをFCエンティティに送信するものとします。その他の接続情報（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接続操作を開始するFCIPエンティティから1回の往復を行い、TCP Connectリクエストを受信して戻ってきます。この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.
注：FSFのこの使用は、新しく作成されたTCP接続をFCファブリックの初期化が開始する前に正しいFCIPリンクに関連付けられている必要があるため、完全に排除することはできません。
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 Connect Request Initiatorから受信機に送信された最初のバイトは、送信者と送信者が受信機であると考える人の両方を識別するFSFです。このFSFの内容が正しい場合、受信機が受け入れられる場合、変更されていないFSFが送信者に反映されます。この送信/エコープロセスは、FCファブリックトラフィックを運ぶためにTCP接続を使用できるようにする唯一のアクションセットです。送信および変更されていないエコープロセスが発生しない場合、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.
注：FSFが使用される方法が限られているため、およびTCP接続がユーザーデータを伝達する前に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接続を閉じることが含まれます。これは、TCP Connect要求のイニシエーターが、その要求のターゲット（たとえばSLPを使用）であるFCIPエンティティのIDを事前に知るために、およびFSFを通じて「私は私が思う」と効果的に言うことを事前に知ることを要求すると見なすことができます。Xと話している。 "TCP Connectリクエストの反対側のパーティーが本当に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ベースのディスカバリーは、「私は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ファブリックエンティティワールドワイドネーム値に置き換えられます。これは依然として変更されていないエコーで送信するルールの対象となるため、エコーされたFSFがTCP Connectイニシエーターによって受信された後に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 Connectイニシエーターは、特定のIPアドレスでのFCIPエンティティのWorld Wide Name IDの正しい宛先FCファブリックエンティティのアイデンティティを知っており、その後のTCP接続セットアップシーケンスが成功する可能性があります。
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フィールドのCHビット（セクション5.6.1を参照）では、送信エラーから生じる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接続を確立する必要があることを発見した場合、セクション9で説明されているように、TCP接続を作成する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ファブリックエンティティTCP接続が行われているFC/FCIPエンティティペアのワールドワイド名
- 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エンティティは、指定されたIPアドレスで3225（またはその他の構成固有のポート番号）のFCIP有名なポートにTCP接続要求[6]を生成するものとします。
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 Connect要求が拒否された場合、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 Connectリクエストが受け入れられた場合、FCIPエンティティは、セクション8.1.2.3で説明した手順に従って、新しいFCIP_DEの確立を完了するものとします。
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使用法[20]で定義された方法で、サービスロケーションプロトコル（SLPV2）[17]を使用して機能を実行するものとします。
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:
動的発見が使用されることを発見すると、FCIPエンティティは[20]および次のように、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発見ドメインのPEER 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:
SLPV2ユーザーエージェントを介して動的に発見された各ピアFCIPエンティティについて、FCIPエンティティは、セクション9で説明されているように、発見された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ファブリックエンティティTCP接続が行われているFC/FCIPエンティティペアのワールドワイド名
- 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有名なポート（またはその他の構成固有のポート番号）にTCP接続要求[6]を生成するものとします。TCP Connect要求が拒否された場合、同様の接続を確立する試みの不必要な繰り返しを制限するように行動します。TCP Connectリクエストが受け入れられた場合、FCIPエンティティは、セクション8.1.2.3で説明した手順に従って、新しいFCIP_DEの確立を完了するものとします。
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 Connectリクエストが受け入れられた後、FCIPエンティティは、新しく形成された接続に送信された最初のバイトとしてFCIP特別フレーム（FSF、セクション7を参照）を送信し、後で比較するためにそれらのバイトのコピーを保持するものとします。FSF内のすべてのフィールドは、特にセクション7で説明されているように記入するものとします。
- 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ファブリックエンティティワールドワイドネームフィールドには、TCP Connectリクエストを発信しているFC/FCIPエンティティペアのFCファブリックエンティティワールドワイド名を含めるものとします。
- 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エンティティ識別子フィールドには、Source FC Fabric Entity World Wide Name Fieldにワールドワイド名が表示される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
- 接続ノンセフィールドには、最近使用されている接続nonce値とは値が異なる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ファブリックエンティティワールドワイドネームフィールドには、宛先がTCP ConnectリクエストであるFC/FCIPエンティティペアの0または予想されるFCファブリックエンティティワールドワイド名を含むものとします。
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がエコーされるのを待つものとします。
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.
FCIPエンティティは、エコーされたFSFバイトを待っている間、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ファブリックエンティティワールドワイドネームフィールドにゼロが含まれている場合、FCIPエンティティはTCP接続を閉じ、FCエンティティに通知し、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).
FCIPエンティティは、エコーされたFSFバイトが送信されたFSFバイトと正確に一致する場合にのみ、次の手順を実行するものとします（単語7〜17インクルーシブ）。
1) Instantiate the appropriate Quality of Service (see section 10) conditions on the newly created TCP Connection,
1) 新しく作成されたTCP接続の適切な品質（セクション10を参照）条件をインスタンス化します。
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_LEPに関連付けられていない場合、新しいFCIPリンクの新しいFCIP_LEPを作成します。
3) Create a new FCIP_DE within the newly created FCIP_LEP to service the new TCP Connection, and
3) 新しく作成されたFCIP_LEP内に新しいFCIP_DEを作成して、新しいTCP接続にサービスを提供し、
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) FCエンティティに、新しいFCIP_LEP、FCIP_DE、宛先FCファブリックエンティティワールドワイド名、接続使用フラグ、および接続使用コードを通知します。
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）で新しいTCP接続要求[6]をリッスンするものとします。FCIPエンティティは、この仕様の範囲外でネットワーク管理者によって構成されているように、FCIPよく知られているポート以外の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 Connectリクエストを受け入れるものとします。
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 Connectリクエストが受け入れられた後、FCIPエンティティは、受け入れられた接続で受信された最初のバイトとして、TCP Connectリクエスト（セクション8.1.2を参照）から送信されたFSFを待機します。
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.
FCIPエンティティは、FSFバイトを待っている間に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.
注：FCIPリンクフォーメーションプロセスのセキュリティを攻撃する1つの方法（セクション9.1で詳細）は、FSFを送信せずにTCP接続要求を開いたままにすることに依存します。FSFがタイムリーに送信されないTCP接続要求の処理において、実装を念頭に置く必要があります。
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 Connectリクエストの発信者から送信されたFSFを受け取ると、FCIPエンティティは次のフィールドの内容を検査するものとします。
- Connection Nonce, - Destination FC Fabric Entity World Wide Name, - Connection Usage Flags, and - Connection Usage Code.
- 接続nonce、 - 宛先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アドレスから最近受信した接続nonceと同一の値が含まれている場合、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ファブリックエンティティワールドワイド名に0が含まれている場合、FCIPエンティティは次の3つのアクションのいずれかを取得するものとします。
1) Leave the Destination FC Fabric Entity World Wide Name field and Ch bit both 0;
1) Destination FC Fabric Entity World Wide Name Fieldを残し、Ch Bitの両方を0にします。
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) 宛先FCファブリックエンティティワールドワイドネームフィールドを変更して、TCP Connectリクエストを受け取ってCHビットを1に変更したFCIPエンティティに関連するFCファブリックエンティティワールドワイド名を一致させます。または
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ファブリックエンティティワールドワイド名には、TCP Connectリクエストを受け取ったFCIPエンティティに関連するFC Fabric Entity World Wide Nameと一致しない非ゼロ値が含まれています。
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 Connectリクエストを受信したFCIPエンティティには受け入れられません。FCIPエンティティは、次の2つのアクションのいずれかをとるものとします。
1) Change the contents of the unacceptable fields to correct/ acceptable values and set the Ch bit to 1; or
1) 受け入れられないフィールドの内容を変更して、容認できる値を修正/許容できる値を変更し、CHビットを1に設定します。または
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のコンテンツに変更を加えた場合、CHビットを1に設定するものとします。
If any changes have been made in the received FSF during the processing described above, the following steps SHALL be performed: 1) The changed FSF SHALL be echoed to the originator of the TCP connect request as the only bytes transmitted on the accepted connection;
上記の処理中に受信したFSFで変更が行われた場合、次の手順を実行するものとします。1）変更されたFSFは、受け入れられた接続で送信された唯一のバイトとしてTCP Connectリクエストの発信元に反映されます。
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) このセクションで説明する追加の処理はすべてスキップするものとします。
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:
ソースFCファブリックエンティティワールドワイド名とソースFC/FCIPエンティティ識別子FSFのフィールド値は、ソースFCファブリックエンティティワールドワイドネームとソース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 Connectリクエストのオリジネーターに変更されていない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) 新しく作成されたFCIP_LEP内に新しいFCIP_DEを作成して、新しいTCP接続にサービスを提供し、
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:
ソースFCファブリックエンティティワールドワイド名とソースFC/FCIPエンティティ識別子FCIP特別フレームのフィールド値は、ソースFCファブリックエンティティワールドワイドネームおよびソースFC/FCIPエンティティ識別子既存のFCIP_LEPに関連付けられている場合、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 Connectリクエストのソースを認証すること（FC-BB-2 [3]を参照）をリクエストし、認証のためにFCエンティティに次の情報を提供します。A）ソースFCファブリックエンティティワールドワイド名、b）ソースfc/fcipエンティティ識別子、およびc）接続nonce。
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.
FCIPエンティティは、FCエンティティがTCP Connectリクエストのソースを認証するまで、新しいTCP接続をいかなる目的で使用してはなりません。FCエンティティがTCP Connect要求を適切に認証できないことを示した場合、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接続要求ソースに応答して、使用する認証メカニズムを含めるものとします。この認証メカニズムは、既存のFCIPリンクで以前に認証されたTCP接続を使用して、新しい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 Connectリクエストのオリジネーターに変更されていない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) 既存のFCIP_LEP内に新しいFCIP_DEを作成して、新しいTCP接続にサービスを提供し、
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) FCエンティティにFCIP_LEP、ソースFCファブリックエンティティワールドワイドネーム、ソース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 Connectリクエストのオリジネーターは、IPアドレスとTCPポートを使用して、どのTCP接続がFCIP_LEPSに属しているかを識別し、TCP Connectリクエストの受信者はソースFCファブリックエンティティワールドワイド名、およびソースFC/FCIPエンティティ識別子フィールドを使用します。どのTCP接続がどのfcip_lepsに属しているかを識別するFSF。このため、TCP Connectリクエストの発信および受信の両方のFCIPエンティティは、受信したTCP Connectリクエストに関連付けられたFCIP_LEPSに関連付けられた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接続をいつでも閉鎖することができるという認識を備えたメカニズムを提供するものとします。これにより、FCエンティティは、あまりにも多くのエラーなどを生成しているTCP接続を閉じることができます。
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サックの使用を交渉し、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]を使用すると、16ビットの制限が大きいTCPウィンドウサイズを受信機によって宣伝できます。長い脂肪ネットワークのデータが利用可能なパイプを埋めることを許可する必要があります。これはまた、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エンティティは、ラップされたシーケンス番号PAWに対する保護を実装することをお勧めします[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.
FCIPエンティティは、RFC 1122 [7]セクション4.2.3.4で説明されているように、Nagleアルゴリズムを無効にする必要があります。伝統により、これはTCP_NODELAYオプションをローカルTCPインターフェイスのオプションに設定することで実現できます。
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接続「Keep Alive」オプションは、通常、接続を生かし続けるために使用されます。ただし、このタイムアウトはかなり大きく、接続性の喪失の早期検出を防ぐ可能性があります。接続の損失のより速い検出を容易にするために、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エンティティがTCPフロー制御をFCエンティティへのステータス通知にマッピングする方法に関するガイドラインを提供します。
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エンティティは、FC Frame Receiverポータルでのフロー制御のためにファイバーチャネルメカニズムを使用して、FCIPエンティティから提供された情報に基づいて、カプセル化されたフレーム送信機ポータルでのフロー制約に関する情報に基づいています。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.
これらのフロー制御メカニズムの調整は、クレジットベースであり、もう1つはウィンドウベースであり、この仕様の範囲外の骨の折れるデザインに依存します。
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 Interconnect Cablingは通常、外部アクセスから物理的に保護されています。パブリック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内容を観察し、観測されたNonCE、ソースFC/FCIPエンティティ識別子、およびその他のFSF内容を使用して、攻撃者自身の確立された接続を使用してFCIPリンクを形成し、リセッティング/ブロッキング中にFCIPリンクを形成することができます。観察された接続。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.
4) FCIPエンティティが展開されると、通常、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.
機密性が有効になっていないが、データの整合性が有効になっている場合、ESPを使用した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を実装する必要があります[11] - XCBC拡張機能[23]でCBC MACモードでAESを実装する必要があります[23] -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モードで3DEを実装する必要があります[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エンティティは、IPEEC DOI [13]を使用したピア認証、セキュリティ協会の交渉（SA）、および主要な管理についてIKE [14]をサポートする必要があります。SAを確立するために手動キーを使用してはなりません。これは、再キーイングに必要な要素を提供しないためです（セクション9.3.3を参照）。コンフォーマントFCIP実装は、事前に共有キーを使用したピア認証をサポートする必要があり、デジタル証明書を使用してピア認証をサポートする必要があります。IKE [14]セクション5.2および5.3で概説されている公開キー暗号化方法を使用したピア認証は使用しないでください。
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 Phase 1は、IKEフェーズ2で使用するための通信のための安全でMAC認証されたチャネルを確立します。FCIP実装は、IKEメインモードをサポートする必要があり、積極的なモードをサポートする必要があります。
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またはID_IPV6_ADDR識別タイプの値（サポートされているIPのバージョンに基づく）を使用する必要があります。その他の識別タイプの値を使用しないでください。
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 SASの数は制限される可能性があるため、フェーズ2の削除メッセージはアイドルSASに対して送信される場合があります。フェーズ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キーをサポートする必要があります。 - デジタル署名を使用した証明書ベースのピア認証をサポートできます。 - [14]のセクション5.2および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アドレスのサポートがメインモードと組み合わせて試行される場合、グループの事前共有キーの使用が強制され、メインモードと組み合わせたグループの事前共有キーの使用は、展開された環境を展開するため、推奨されません。中間の攻撃。したがって、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 Oakleyグループ[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接続を含めることができます。この場合、各FCIPエンドポイントIPアドレスペアに対してIKEフェーズ1 SAが確立されます。IKEフェーズ1内では、FCIP実装はID_IPv4_addr、ID_IPV6_ADDR（プロトコルスタックがIPv6をサポートしている場合）、およびID_FQDN IDペイロードをサポートする必要があります。FCIPエンドポイントアドレスが動的に割り当てられている場合、ID_FQDNを使用することが有益である可能性があり、このため、IP_FQDN IDペイロードをサポートする必要があります。その他の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パラメーターをSAデータベース（SAD）に保存します。悲しいことは、IPSEC [10]セクション4.4.3に記載されています。SADには、アクティブなSAエントリのセットが含まれています。各エントリには、シーケンスカウンターオーバーフロー、シーケンス番号カウンター、アンチレプレイウィンドウ、およびSAの寿命が含まれています。FCIPエンティティは、デフォルトのSA寿命1時間と、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.
2つのFCIP_DES間にTCP接続が確立されると、その接続のために2つの単方向SASが作成され、各SAはセキュリティパラメーターインデックス（SPI）の形式で識別されます。1つのSAは、入ってくる交通の流れに関連付けられており、もう1つの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.
FCIPエンティティは、[14]で説明されているように、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フェーズ1の交渉の結果を使用して、IKEフェーズ2の「クイックモード」交換を開始し、新しいSASを確立する必要があります。
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.
SASのスムーズな遷移を有効にするには、シーケンス番号カウンターが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カプセル化フレームに使用を開始します。TCPの再送信などにより、飛行中または再セントのあるフレームは、新しいSPIまたは交換されているもののいずれかを使用する場合があります。
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 TCP接続が確立される前にFCIPリンクが初期化されると、ローカル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フェーズ1を開始する前に、IKEフェーズ1を完了する必要があります。IKEフェーズ1とフェーズ2トランザクションの両方がUDPポート500を使用します。IKEフェーズ1が失敗した場合、FCIPリンクの初期化は終了し、終了の理由をFCエンティティに終了および通知します。それ以外の場合、FCIPリンクの初期化はTCP接続の初期化に移動します。
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エンティティはFSFをFCIPリンクの形成と交換します。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によって保護する必要があります。1つ以上のTCP接続からのトラフィックは、各IPSECフェーズ2 SA内に流れる場合があります。IKEフェーズ2 SAが複数のTCP接続を保護することは可能ですが、TCP接続のすべてのパケットは1つの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.
実装では、いくつかのIKEフェーズ2交渉を実行してローカルスピスでキャッシュできますが、このようなキャッシュのエントリは現在のSA寿命設定に従ってフラッシュできます。
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ネットワークに関係する距離に適した高度なスループットと低レイテンシを確保するための多くのオプションが存在します。たとえば、FCIPエンティティの唯一の使用のためにプライベートIPネットワークが構築される場合があります。この仕様の範囲内にあるオプションについては、ここで説明します。
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 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.
FCIPデータストリームが低レイテンシと高スループットが発生する確率を増やすための1つのオプションは、セクション10.2で説明されているIP QOSテクニックです。このオプションは、単一の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エンティティはFCIPエンティティに、その接続の寿命に使用されるQOS特性（IP（ホップごとの行動を含むがこれらに限定されない）を指定するものとします。これは、次のことによって達成される場合があります。
a) only one set of QoS characteristics for all TCP Connections;
a) すべてのTCP接続のQoS特性のセットのみ。
b) a default set of QoS characteristics that the FCIP Entity applies in the absence of differing instructions from the FC Entity; or
b) FCIPエンティティがFCエンティティからの異なる指示がない場合に適用されるQOS特性のデフォルトセット。または
c) a sophisticated mechanism for exchanging QoS requirements information between the FC Entity and FCIP Entity each time a new TCP Connection is created.
c) 新しいTCP接続が作成されるたびに、FCエンティティとFCIPエンティティ間でQoS要件情報を交換するための洗練されたメカニズム。
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が大規模な（帯域幅*遅延）製品を備えたネットワークで使用される場合、FCIP_LEPSは、RFC 1323 [24]で定義されている長脂肪ネットワーク（LFN）に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 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.
- マルチプロトコルラベルスイッチング（MPLS） - RFC 3031 [32] - 差別化されたサービスアーキテクチャ（DIFFSERV）-RFC 2474 [28]、RFC 2475 [29]、RFC 2597 [30]、およびRFC 2598 [31] - そして、他の形式のper -hop -behavior（PHB） - 統合サービス、RFC 1633 [25] -IEEE 802.1pこの仕様の目的は、特定の形式のIP QOを指定することではなく、むしろそれらの問題のみを指定することです。さまざまなベンダーによって製造されている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.
FCIPトラフィックに何らかの形式の優先Qosを使用して、レイテンシとパケットドロップを最小限に抑えることをお勧めします。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と相互操作することをお勧めします（RFC 2474 [28]、RFC 2475 [29]、RFC 2597 [30]、およびRFC 2598 [31]を参照）。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Fibre Channel Backbone (FC-BB), ANSI INCITS.342:2001, December 12, 2001.
[2] ファイバーチャネルバックボーン（FC-BB）、ANSIがインセッツ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がインキュウツ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がインキュウツ355：2001年12月12日、2001年12月12日。
[5] Fibre Channel Framing and Signaling (FC-FS), ANSI INCITS.373:2003, October 27, 2003.
[5] ファイバーチャネルのフレーミングとシグナル伝達（FC-FS）、ANSIインセット373：2003、2003年10月27日。
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[6] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[7] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[7] Braden、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] Jacobson、V.、Braden、R。、およびD. Borman、「高性能のためのTCP拡張」、RFC 1323、1992年5月。
[9] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[9] Eastlake、D.、Crocker、S。、およびJ. Schiller、「セキュリティのためのランダム性の推奨」、RFC 1750、1994年12月。
[10] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[10] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、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.、Bellare、M。、およびR. Canetti、「HMAC：Keyed- Hashing for Message Authentication」、RFC 2104、1997年2月。
[12] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[12] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[13] Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998.
[13] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[14] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[14] Harkins、D。およびD. Carrel、「The Internet Key Exchange（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] Glenn、R。およびS. Kent、「Null暗号化アルゴリズムとIPSECでの使用」、RFC 2410、1998年11月。
[16] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[16] Pereira、R。およびR. Adams、「ESP CBC-Mode Cipher Algorithms」、RFC 2451、1998年11月。
[17] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, version 2", RFC 2608, July 1999.
[17] Guttman、E.、Perkins、C.、Veizades、J。and M. Day、「サービスロケーションプロトコル、バージョン2」、RFC 2608、1999年7月。
[18] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "SACK Extension", RFC 2883, July 2000.
[18] Floyd、S.、Mahdavi、J.、Mathis、M。and M. Podolsky、「Sack Extension」、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] Weber、R.、Rajagopal、M.、Travostino、F.、O'Donnell、M.、Monia、C。、およびM. Merhar、「Fiber Channel（FC）Frame Capsulation」、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.
[20] Peterson、D。、「サービスロケーションプロトコルバージョン2（SLPV2）を使用したTCP/IP（FCIP）エンティティを介してファイバーチャネルを見つける」、RFC 3822、2004年7月。
[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.、Tseng、J.、Walker、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] Frankel、S.、Glenn、R。、およびS. Kelly、「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] Frankel、S。およびH. Herbert、「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] Jacobson、V.、Braden、R。、およびD. Borman、「高性能のための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] Braden、R.、Clark、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] Mills、D。、「IPv4、IPv6およびOSI用のSimple Network Time Protocol（SNTP）バージョン4」、RFC 2030、1996年10月。
[27] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[27] Orman、H。、「The Oakley Key Deicination Protocol」、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] Nichols、K.、Blake、S.、Baker、F。and D. Black、「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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、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.、Baker、F.、Weiss、W。and J. Wroclawski、「Ansured Forwarding PHB」、RFC 2597、1999年6月。
[31] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB Group", RFC 2598, June 1999.
[31] Jacobson、V.、Nichols、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] Rosen、E.、Viswanathan、A。およびR. Callon、「Multiprotocol Label Switching Architecture」、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] Patel、B.、Aboba、B.、Kelly、S。and V. Gupta、「Ipsecトンネルモードの動的ホスト構成プロトコル（DHCPV4）構成」、RFC 3456、2003年1月。
[34] Kembel, R., "The Fibre Channel Consultant: A Comprehensive Introduction", Northwest Learning Associates, 1998.
[34] ケンベル、R。、「ファイバーチャネルコンサルタント：包括的な紹介」、ノースウェストラーニングアソシエイツ、1998年。
The developers of this specification thank Mr. Jim Nelson for his assistance with FC-FS related issues.
この仕様の開発者は、FC-FS関連の問題を支援してくれたJim Nelson氏に感謝します。
The developers of this specification express their appreciation to Mr. Mallikarjun Chadalapaka and Mr. David Black for their detailed and helpful reviews.
この仕様の開発者は、Mallikarjun Chadalapaka氏とDavid Black氏に、詳細で有益なレビューについて感謝を表明しています。
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-port 3225/tcp fcip-fcip-port 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.
IANAがポートを割り当てているにもかかわらず、FCIPでUDPの使用は禁止されています。
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フレームカプセル化は、FCフレームカプセル化[19]仕様の付録で説明されているように、プロトコル＃値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はIPアドレスを使用してFCIPエンティティまたはFCIP_LEPSを識別しません。識別のためのIPアドレスの唯一の使用は、TCP ConnectリクエストのIPアドレス宛先が質問に答えるために使用される新しいTCP Connectリクエストを開始するときに発生します。宛先FCIPエンティティ？」この仮定の正しさは、FCIPスペシャルフレーム（FSF）に宛先FCファブリックエンティティワールドワイド名を送信し、TCP Connectリクエストと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エンティティは、Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identity Identity Identifier Fieldsによって最初の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ファブリックエンティティワールドワイド名。
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.
- FCIPエンティティが受信したTCP接続要求から生じる接続。
Within each of these two groups, the following information is used to further identify each FCIP_LEP:
これら2つのグループのそれぞれ内で、次の情報を使用して、各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ファブリックエンティティワールドワイド名。
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データストリームに2176バイトごとに少なくとも1つの有効なヘッダー（カプセル化された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.
図14に示すケースを考慮してください。おそらくトレースからの一連の短いFCIPフレームは、トレースファイルがあるディスクから別のディスクに転送された結果として、より大きな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フレームを見つけます。ただし、2176バイトプラスまたはマイナス以内に、再同期の試みは、LFHが短いFCIPフレームの中央に落ち、次のヘッダーがバイトストリームのさらに遠くに押し出されるため、次の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フレーム送信機ポータルに将来の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）バージョンフィールド、c）プロトコルフィールドを補完するもの、d）バージョンフィールドの補体、e）ワード1のカプセル化ワード0の複製、およびf）pflagsフィールドとその補完。
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.
強力な候補ヘッダーは、少なくとも4352バイト（FCIPフレームの最大長の2倍）で、この方法で引き続き検証されています。確認テストがいつでも失敗した場合、ステップ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フレームまたはその後の強力な候補ヘッダーが最終的にバイトストリームの実際のヘッダーを越えます。その結果、実際のヘッダーを強力な候補ヘッダーとして識別するか、長さが28バイトの余分な28バイトのために再び同期を失い、上記のようにステップ1に戻ります。
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.
着信バイトは、次の検証済みの候補ヘッダーに到達するまで検査および破棄されます。着信バイトの検査には、ステップ1で説明されている基準を使用して、他の候補ヘッダーのテストが含まれます。各検証済みの候補ヘッダーは、通常そうであるようにセクション5.6.2.2にリストされているテストに対してテストされます。
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 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.
検証済みの候補ヘッダーは、最低4352バイト（FCIPフレームの最大長の2倍）でこのように配置され、テストされています。遭遇したすべての検証済みの候補ヘッダーが有効である場合、最後の検証済み候補ヘッダーは有効なヘッダーです。この時点で、FCIP_DEはバイトの破棄を停止し、同期が失われてから初めて、通常のFCIPルールに従ってFCフレーム送信機ポータルを介したFCフレームの配信を含め、通常のFCIP脱カプセル化を開始します。
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に戻ります）。検証済みの候補ヘッダーが無効であり、強力な候補ヘッダーのテストを満たしていない場合、または検証済みの候補ヘッダー間のバイトの検査が候補ヘッダーを発見した場合、再試行カウンターを増やしてステップに戻ります。再試行、再同期が失敗し、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は、TCPセグメントのFCフレームのカプセル化について説明します。これは、IPネットワークを介して輸送するためにIPパケット内にカプセル化されています。カプセル化されているFCフレームのタイプを考慮しません。したがって、FCフレームには、FC仕様を介してIPに記載されているように、実際にIPパケットを含める場合があります（RFC 2625）。そのような場合、データパケットには次のようになります。
- 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ヘッダーは互いに同一ではありません。1つは最終目的地に関する情報を持ち、もう1つは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.
2つのドキュメントは、異なる目的に焦点を当てています。上記のように、FCIPの実装はIP内のIPカプセル化につながります。おそらく非効率的ですが、これはIP通信の問題につながるべきではありません。1つの注意事項：ファイバーチャネルデバイスがFCフレーム（IPFCデバイスなど）にIPパケットをカプセル化している場合、そのデバイスが非FCメディアでIPを実行しているデバイスと通信している場合、2番目の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-Over-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ビットリンクエンコードを参照します。これらの単語は、ASCII、Unicode、またはその他の形式のテキスト文字を指すものではありませんが、このような文字のオクテットは、このエンコードの8ビット「文字」として発生します。この使用法は、ファイバーチャネルを指定する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フレームの正確なサイズは、変数フィールドのサイズによって異なります。変数フィールドのサイズは、図16のFCフレーム形式に示されているように0〜2112バイトの範囲で、36バイトの最小サイズFCフレームと2148バイトの最大サイズFCフレームになります。有効な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）から構築された特別な単語として送信され、3つの追加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フレームを終了するために使用されます。FCIPエンティティは、FCファブリックの残りの部分に関して伝送リンクのように機能するため、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宛先に転送する前に、受信FCIPエンティティが元のSOF形式で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が特定の値を必要とする場合、それらの値は括弧内の16進数で表示されます。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フレームには、FCIPリンクのもう一方の端にあるFCエンティティが維持するクロックと同期した時間値を添付する必要があります（セクション6を参照）。同期された時間値が利用できない場合、ゼロの値は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.
3) FCフレームFCフレームデータエンジンをFCフレームトランスミッターポータルを介して出口する場合、FCエンティティはFCファブリックに転送する必要があります。ただし、FCフレームを転送する前に、FCエンティティは、FCIP_DE（FCIPヘッダーから取得）と同期時間値（セクション6を参照）で提供される時間値を使用して、FCフレームのエンドツーエンドトランジット時間を計算する必要があります。。エンドツーエンドのトランジット時間が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によって提供される唯一の配信順序付け保証は、FCフレームのFCIPデータエンジンのペア間で正しく注文されます。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.
5) TCP Connect要求が受信され、その要求が既存のFCIP_LEPに新しいTCP接続を追加する場合、FCエンティティは、新しいTCP接続を使用する前にTCP Connect要求のソースを認証する必要があります。
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エンティティは、FCIPエンティティがTCPの緊密なリクエストを実行することを要求する場合があります。
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エンティティが処理できないイベントから回復する必要があります。A）TCP接続をリセットする必要があるカプセル化されたフレームレシーバーポータルからのFCIPフレームヘッダーとの同期の損失。そして
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) 同期の問題の結果として破棄されるFCIPフレームからの回復（セクション5.6.2.2およびセクション5.6.2.3を参照）。
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エンティティは、FCIPエンティティと協力して、IPネットワークまたはFCファブリックのフロー制御問題を管理する必要があります。
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.
FCエンティティに配置された要件を完全に理解するために、ファイバーチャネル標準に相談する必要があることに注意してください。
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エンティティペアインタラクション（パート1 〜5）
+-------------+-----------------+-----------------------------------+
| | | 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エンティティペアインタラクション（パート2 of 5）
+-------------+-----------------+-----------------------------------+
| | | 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エンティティペアの相互作用（パート3/5）
+-------------+-----------------+-----------------------------------+
| | | 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エンティティペアの相互作用（パート4/5）
+-------------+-----------------+-----------------------------------+
| | | 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.
この仕様の開発中、Murali Rajagopal、Elizabeth Rodriguez、VI Chau、およびRalph Weberは、編集者として連続して奉仕しました。Raj Bhagwatは、初期の基本的なFCIP概念に大きく貢献しました。
Venkat Rangan contributed the Security section and continues to coordinate security issues with the ips Working Group and IETF.
Venkat Ranganはセキュリティセクションに貢献し、IPSワーキンググループおよびIETFとセキュリティの問題を調整し続けています。
Andy Helland contributed a substantial revision of Performance section, aligning it with TCP/IP QoS concepts.
Andy Hellandは、パフォーマンスセクションの実質的な改訂版に貢献し、TCP/IP QoSコンセプトに合わせました。
Dave Peterson contributed the dynamic discovery section and edits to RFC 3822.
Dave Petersonは、動的な発見セクションに貢献し、RFC 3822に編集しました。
Anil Rijhsinghani contributed material related to the FCIP MIB and edits the FCIP MIB document.
Anil 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.
Lawrence J. Lamersは、FCIPをB_PORTデバイスと互換性のあるものに保つことに焦点を当てた多くのアイデアを貢献しました。
Milan Merhar contributed several of the FCIP conceptual modifications necessary to support NATs.
ミラノ・マーハーは、NATをサポートするために必要なFCIPの概念的修正のいくつかを貢献しました。
Don Fraser contributed material related to link failure detection and reporting.
Don Fraserは、リンク障害検出とレポートに関連する資料を提供しました。
Bill Krieg contributed a restructuring of the TCP Connection setup sections that made them more linear with respect to time and more readable.
Bill Kriegは、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リーダーは、ジムネルソン（フレーミングとシグナリング）、ニールワナメーカー（フレーミングとシグナリング）、クレイグカールソン（ジェネリックサービス）、ケンヒラタ（スイッチファブリック）、ムーラリラジャゴパル（バックボーン）、スティーブウィルソン（スイッチファブリック）、マイケルO'Donnell（セキュリティプロトコル）。
Editors and Contributors Addresses
編集者と貢献者のアドレス
Neil Wanamaker Akara 10624 Icarus Court Austin, TX 78726 USA
ニール・ワナメーカーアカラ10624イカロス裁判所オースティン、テキサス78726 USA
Phone: +1 512 257 7633
Fax: +1 512 257 7877
EMail: nwanamaker@akara.com
Ralph Weber ENDL Texas, representing Brocade Suite 102 PMB 178 18484 Preston Road Dallas, TX 75252 USA
Ralph Weber Endl Texas、Brocade Suite 102 PMB 178 18484 PRESTON ROAD DALLAS、TX 75252 USAを代表する
Phone: +1 214 912 1373
EMail: roweber@ieee.org
Elizabeth G. Rodriguez Dot Hill Systems Corp. 6305 El Camino Real Carlsbad, CA 92009 USA
エリザベスG.ロドリゲスドットヒルシステムコーポレーション6305エルカミノリアルカールスバッド、カリフォルニア州92009 USA
Phone: +1 760 431 4435
EMail: elizabeth.rodriguez@dothill.com
Steve Wilson Brocade Comm. Systems, Inc. 1745 Technology Drive San Jose, CA. 95110 USA
スティーブ・ウィルソン・ブロケード・コム。Systems、Inc。1745テクノロジードライブサンノゼ、カリフォルニア95110 USA
Phone: +1 408 333 8128 EMail: swilson@brocade.com Bob Snively Brocade Comm. Systems, Inc. 1745 Technology Drive San Jose, CA 95110 USA
電話：1 408 333 8128メール：swilson@brocade.com bob snively brocade comm。Systems、Inc。1745 Technology Drive San Jose、CA 95110 USA
Phone: +1 408 303 8135
EMail: rsnively@brocade.com
David Peterson Cisco Systems - SRBU 6450 Wedgwood Road Maple Grove, MN 55311 USA
David Peterson Cisco Systems -SRBU 6450 Wedgwood Road Maple Grove、MN 55311 USA
Phone: +1 763 398 1007
Cell: +1 612 802 3299
EMail: dap@cisco.com
Donald R. Fraser Hewlett-Packard 301 Rockrimmon Blvd., Bldg. 5 Colorado Springs, CO 80919 USA
Donald R. Fraser Hewlett-Packard 301 Rockrimmon Blvd.、Bldg。5コロラドスプリングス、コロラド州80919 USA
Phone: +1 719 548 3272
EMail: Don.Fraser@HP.com
R. Andy Helland LightSand Communications, Inc. 375 Los Coches Street Milpitas, CA 95035 USA
R. Andy Helland Lightsand Communications、Inc。375 Los Coches Street Milpitas、CA 95035 USA
Phone: +1 408 404 3119
Fax: +1 408 941 2166
EMail: andyh@lightsand.com
Raj Bhagwat LightSand Communications, Inc. 24411 Ridge Route Dr. Suite 135 Laguna Hills, CA 92653 USA
Raj Bhagwat Lightsand Communications、Inc。24411 Ridge Route Dr. Suite 135 Laguna Hills、CA 92653 USA
Phone: +1 949 837 1733 x104 EMail: rajb@lightsand.com Bill Krieg Lucent Technologies 200 Lucent Lane Cary, NC 27511 USA
電話：1 949 837 1733 X104メール：rajb@lightsand.comビルKrieg Lucent Technologies 200 Lucent Lane Cary、NC 27511 USA
Phone: +1 919 463 4020
Fax: +1 919 463 4041
EMail: bkrieg@lucent.com
Michael E. O'Donnell McDATA Corporation 310 Interlocken Parkway Broomfield, CO 80021 USA
マイケルE.オドネルマクダタコーポレーション310インターロッケンパークウェイブルームフィールド、コロラド州80021アメリカ
Phone: +1 303 460 4142
Fax: +1 303 465 4996
EMail: modonnell@mcdata.com
Anil Rijhsinghani McDATA Corporation 310 Interlocken Parkway Broomfield, CO 80021 USA
Anil Rijhsinghani McData Corporation 310 Interlocken Parkway Broomfield、Co 80021 USA
Phone: +1 508 870 6593
EMail: anil.rijhsinghani@mcdata.com
Milan J. Merhar 43 Nagog Park Pirus Networks Acton, MA 01720 USA
ミラノJ.メルハール43ナゴグパークピラスネットワークアクトン、マサチューセッツ州01720 USA
Phone: +1 978 206 9124
EMail: Milan@pirus.com
Craig W. Carlson QLogic Corporation 6321 Bury Drive Eden Prairie, MN 55346 USA
Craig W. Carlson Qlogic Corporation 6321 Bury Drive Eden Prairie、MN 55346 USA
Phone: +1 952 932 4064 EMail: craig.carlson@qlogic.com Venkat Rangan Rhapsody Networks Inc. 3450 W. Warren Ave. Fremont, CA 94538 USA
電話：1 952 932 4064メール：craig.carlson@qlogic.com Venkat Rangan Rhapsody Networks Inc. 3450 W. Warren Ave. Fremont、CA 94538 USA
Phone: +1 510 743 3018
Fax: +1 510 687 0136
EMail: venkat@rhapsodynetworks.com
Lawrence J. Lamers SAN Valley Systems, Inc. 6320 San Ignacio Ave. San Jose, CA 95119-1209 USA
ローレンスJ.ラマーズサンバレーシステムズ、インク6320サンイグナシオアベニュー。サンノゼ、カリフォルニア州95119-1209 USA
Phone: +1 408 234 0071
EMail: ljlamers@ieee.org
Murali Rajagopal Broadcom Corporation 16215 Alton Parkway Irvine,CA 92619 USA
Murali Rajagopal Broadcom Corporation 16215 Alton Parkway Irvine、CA 92619 USA
Phone: +1 949 450 8700
EMail: muralir@broadcom.com
Ken Hirata Vixel Corporation 15245 Alton Parkway, Suite 100 Irvine, CA 92618 USA
Ken Hirata Vixel Corporation 15245 Alton Parkway、Suite 100 Irvine、CA 92618 USA
Phone: +1 949 788 6368
Fax: +1 949 753 9500
EMail: ken.hirata@vixel.com
Vi Chau USA Email: vchau1@cox.net
vi Chau USAメール：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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。