Network Working Group R. Weber
Request for Comments: 3643 Brocade
Category: Standards Track M. Rajagopal
Broadcom Corporation
F. Travostino
Nortel Networks
M. O'Donnell
McDATA
C. Monia
Nishan Systems
M. Merhar
Sun Microsystems
December 2003
Fibre Channel (FC) Frame Encapsulation
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 (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document describes the common Fibre Channel (FC) frame encapsulation format and a procedure for the measurement and calculation of frame transit time through the IP network. This specification is intended for use by any IETF protocol that encapsulates FC frames.
この文書は、共通のファイバチャネル（FC）フレームのカプセル化フォーマットと、IPネットワークを介して、フレーム通過時間の測定と計算のための手順を記載しています。この仕様は、FCフレームをカプセル化し、任意のIETFプロトコルでの使用のために意図されています。
Table Of Contents
目次
1. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Encapsulation Concepts . . . . . . . . . . . . . . . . . . . . 3
3. The FC Encapsulation Header. . . . . . . . . . . . . . . . . . 4
3.1. FC Encapsulation Header Format . . . . . . . . . . . . . 4
3.2. FC Encapsulation Header Validation . . . . . . . . . . . 7
3.2.1. Redundancy Based FC Encapsulation
Header Validation. . . . . . . . . . . . . . . . 7
3.2.2. CRC Based FC Encapsulation Header Validation . . 7
4. Measuring Fibre Channel Frame Transit Time . . . . . . . . . . 8
5. The FC Frame . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. FC Frame Content . . . . . . . . . . . . . . . . . . . . 10
5.2. Bit and Byte Ordering. . . . . . . . . . . . . . . . . . 10
5.3. FC SOF and EOF . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix
A Fibre Channel Bit and Byte Numbering Guidance . . . . . . . . . 15
B Encapsulating Protocol Requirements . . . . . . . . . . . . . . 15
C IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16
D Intellectual Property Rights Statement. . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 20
This document describes common mechanisms for the transport of Fibre Channel frames over an IP network, including the encapsulation format and a mechanism for enforcing the Fibre Channel frame lifetime limits.
この文書では、カプセル化フォーマットおよびファイバチャネルフレーム寿命の制限を強制するための機構を含むIPネットワークを介してファイバチャネルフレームの輸送のための共通のメカニズムが記載されています。
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を参照してください。
The organization responsible for the Fibre Channel standards (INCITS Technical Committee T11) has determined that some functions and modes of operation are not interoperable to the degree required by the IETF (see FC-MI [8]). This document includes applicable T11 interoperability determinations in the form of restrictions on the use of this encapsulation mechanism.
ファイバチャネル規格を担当する組織（INCITS T11技術委員会）は、いくつかの機能や動作モードは、IETFによって必要な程度に相互運用可能でないと判断した（FC-MIを参照してください[8]）。この文書では、このカプセル化メカニズムの使用制限の形で適用T11の相互運用性の決定を含んでいます。
Use of these mechanisms in an encapsulating protocol requires an additional document to specify the encapsulating protocol specific functionality and appropriate security considerations. Because security considerations for this encapsulation depend on how it is used by encapsulating protocols, they are taken up in encapsulating protocol specific documents.
カプセル化プロトコルでこれらのメカニズムを使用すると、カプセル化プロトコル固有の機能と適切なセキュリティの考慮事項を指定するには、追加の書類が必要です。このカプセル化のためのセキュリティの考慮事項は、それがプロトコルをカプセル化することによってどのように使われるかに依存しているため、彼らは、プロトコル特定の文書をカプセル化するに取り込まれます。
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 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[2]。
The smallest unit of data transmission and routing in Fibre Channel (FC) is the frame. FC frames include a Start Of Frame (SOF), End Of Frame (EOF), and the contents of the Fibre Channel frame. The Fibre Channel frame includes a Cyclic Redundancy Check (CRC) code that provides error detection for the contents of the frame. FC frames are variable length. To facilitate transporting FC frames over an IP based transport such as TCP the native FC frame needs to be contained in (encapsulated in) a slightly larger structure as shown in Figure 1.
ファイバチャネル（FC）におけるデータ送信およびルーティングの最小単位は、フレームです。 FCフレームは、フレームの開始（SOF）、フレームの終わり（EOF）、およびファイバ・チャネル・フレームの内容が含まれています。ファイバ・チャネル・フレームは、フレームの内容のエラー検出を提供する巡回冗長検査（CRC）コードを含みます。 FCフレームは可変長です。 TCPなどのIPベースのトランスポートを介してネイティブFCフレームをFCフレームを搬送容易にするために（中にカプセル化された）に含まれる、図1に示すようにわずかに大きい構造を必要とします。
+--------------------+
| Header |
+--------------------+-----+
| SOF | f |
+--------------------+ F r |
| FC frame content | C a |
+--------------------+ m |
| EOF | e |
+--------------------+-----+
Figure 1 - FC frame Encapsulation
図1 - FCフレームのカプセル化
The format and content of an FC frame are described in the FC standards (e.g., FC-FS [3], FC-SW-2 [4], and FC-PI [5]). Of importance to this encapsulation is the FC requirement that all frames SHALL contain a CRC for detection of transmission errors.
FCフレームのフォーマット及びコンテンツは、FC規格に記載されている（例えば、FC-FS [3]、FC-SW-2 [4]、及びFC-PI [5]）。このカプセル化に重要なのは、すべてのフレームが送信エラーの検出のためのCRCを含まなければならないFCの要件があります。
Figure 2 shows the format of the required FC Encapsulation Header.
図2は、必要なFCカプセル化ヘッダのフォーマットを示しています。
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------+---------------+---------------+---------------+
0| Protocol# | Version | -Protocol# | -Version |
+---------------+---------------+---------------+---------------+
1| |
+----- Encapsulating Protocol Specific ----+
2| |
+-----------+-------------------+-----------+-------------------+
3| Flags | Frame Length | -Flags | -Frame Length |
+-----------+-------------------+-----------+-------------------+
4| Time Stamp [Seconds] |
+---------------------------------------------------------------+
5| Time Stamp [Seconds Fraction] |
+---------------------------------------------------------------+
6| CRC |
+---------------------------------------------------------------+
Figure 2 - FC Encapsulation Header Format
図2 - FCカプセル化ヘッダー形式
The fields in the FC Encapsulation Header are defined as follows.
次のようにFCカプセル化ヘッダ内のフィールドが定義されています。
Protocol#: The Protocol# field SHALL contain a number that indicates which encapsulating protocol is employing the FC Encapsulation. The values in the Protocol# field are assigned by IANA (see Appendix C).
プロトコル番号：プロトコル番号フィールドは、カプセル化プロトコルがFCカプセル化を用いているかを示す番号を含まなければなりません。プロトコル番号フィールドの値は、IANAによって割り当てられている（付録Cを参照されたいです）。
Version: The Version field SHALL contain 0x01 to indicate that this version of the FC Encapsulation is being used. All other values are reserved for future versions of the FC Encapsulation.
バージョン：VersionフィールドはFCカプセル化のこのバージョンが使用されていることを示すためには0x01を含まなければなりません。他のすべての値は、FCカプセル化の将来のバージョンのために予約されています。
-Protocol#: The -Protocol# field SHALL contain the one's complement of the contents of the Protocol# field. FC Encapsulation receivers SHOULD either validate the CRC or compare the Protocol# and - Protocol# fields to verify that an FC Encapsulation Header is being processed according to a policy defined by the encapsulating protocol.
-protocol＃：-protocol＃フィールドには、プロトコル番号フィールドの内容の1の補数を含まなければなりません。 FCカプセル化受信機は、CRCを検証またはプロトコル＃と比較してくださいいずれか - FCカプセル化ヘッダをカプセル化プロトコルで定義されたポリシーに従って処理されていることを確認するために、プロトコル番号フィールド。
-Version: The -Version field SHALL contain the one's complement of the contents of the Version field. FC Encapsulation receivers SHOULD either validate the CRC or compare the Version and -Version fields to verify that an FC Encapsulation Header is being processed according to a policy defined by the encapsulating protocol.
-version：-versionフィールドは、Versionフィールドの内容の1の補数を含まなければなりません。 FCカプセル化受信機は、いずれかのCRCを検証またはFCカプセル化ヘッダをカプセル化プロトコルで定義されたポリシーに従って処理されていることを確認するためのバージョンと-Versionフィールドを比較する必要があります。
Encapsulating Protocol Specific: The usage of these words differs based on the contents of the Protocol# field, i.e., the usage of these words is defined by the encapsulating protocol that is employing this encapsulation.
プロトコルは、特定のカプセル化：これらの言葉の使用は、プロトコル番号フィールドの内容によって異なり、すなわち、これらの単語の使用は、このカプセル化を用いているカプセル化プロトコルによって定義されます。
Flags: The Flags bits provide information about the usage of the FC Encapsulation Header as shown in Figure 3.
フラグ：フラグビット、図3に示すように、FCカプセル化ヘッダの使用状況に関する情報を提供します。
|------------------------Bit--------------------------|
| |
| 0 1 2 3 4 5 |
+--------------------------------------------+--------+
| Reserved | CRCV |
+--------------------------------------------+--------+
Figure 3 - Flags Field Format
図3 - フラグフィールドのフォーマット
Reserved Flags bits: These bits are reserved for use by future versions of the FC Encapsulation and SHALL be set to zero on send. Encapsulating protocols employing the encapsulation described in this specification MAY require checking for zero on receive, however doing so has the potential to create incompatibilities with future versions of this encapsulation. Changes in the usage of the Reserved Flags bits MUST be identified by changes in the contents of the Version field. Encapsulating protocols employing the encapsulation described in this specification MUST NOT make use of the Reserved Flags bits in any fashion other than that described in this specification.
予約フラグビット：これらのビットは、FCカプセル化の将来のバージョンで使用するために予約され、送信時にゼロに設定されます。本明細書に記載されたカプセル化を使用するプロトコルをカプセル化すると、受信時にゼロをチェックする必要かもしれない、しかし、そうすることは、このカプセル化の将来のバージョンとの互換性の問題を作成する可能性を秘めています。予約フラグビットの使い方の変化はバージョンフィールドの内容の変化によって識別されなければなりません。本明細書に記載されたカプセル化を使用するカプセル化プロトコルでは、この仕様書に記載されている以外の方法で予約フラグビットを使用してはなりません。
CRCV (CRC Valid Flag): A CRCV bit value of one indicates that the contents of the CRC field are valid. A CRCV bit value of zero indicates that the contents of the CRC field are invalid. The value of the CRCV bit SHALL be constant for all FC Encapsulation Headers sent on a given connection.
CRCV（CRC有効フラグ）：一方のCRCVビット値はCRCフィールドの内容が有効であることを示しています。ゼロのCRCVビット値はCRCフィールドの内容が無効であることを示しています。 CRCVビットの値は、与えられた接続上で送信されるすべてのFCカプセル化ヘッダに対して一定でなければなりません。
Frame Length: The Frame Length field contains the length of the entire FC Encapsulated frame including the FC Encapsulation Header and the FC frame (including SOF and EOF words). This length is based on a unit of 32-bit words. All FC frames are 32-bit-word-aligned and the FC Encapsulation Header is always word-aligned; therefore a32-bit word length is acceptable.
フレーム長：フレーム長フィールドは、FCカプセル化ヘッダと（SOFとEOFの単語を含む）FCフレームを含む全体FCカプセル化されたフレームの長さを含みます。この長さは32ビットワード単位に基づいています。すべてのFCフレームは、32ビット・ワード・アラインされ、FCカプセル化ヘッダは常にワード境界で整列です。従ってA32ビット・ワード長が許容されます。
-Flags: The -Flags field SHALL contain the one's complement of the contents of the Flags field. FC Encapsulation receivers SHOULD either validate the CRC or compare the Flags and -Flags fields to verify that an FC Encapsulation Header is being processed according to a policy defined by the encapsulating protocol.
-flags：-flagsフィールドはFlagsフィールドの内容の1の補数を含まなければなりません。 FCカプセル化受信機は、いずれかのCRCを検証またはFCカプセル化ヘッダをカプセル化プロトコルで定義されたポリシーに従って処理されていることを確認するためにフラグと-flagsフィールドを比較する必要があります。
-Frame Length: The -Frame Length field SHALL contain the one's complement of the contents of the Frame Length field. FC Encapsulation receivers SHOULD either validate the CRC or compare the Frame Length and -Frame Length fields to verify that an FC Encapsulation Header is being processed according to a policy defined by the encapsulating protocol.
-frame長さ： - フレーム長さフィールドは、フレーム長フィールドの内容の1の補数を含まなければなりません。 FCカプセル化受信機は、いずれかのCRCを検証またはFCカプセル化ヘッダをカプセル化プロトコルで定義されたポリシーに従って処理されていることを確認するために、フレーム長と - フレーム長フィールドを比較する必要があります。
Time Stamp [Seconds]: The Time Stamp [Seconds] field contains zero or the number of seconds since 0 hour on 1 January 1900 at the time the FC Encapsulated frame is place in the outgoing data stream.
タイムスタンプは[秒]は：タイムスタンプは[秒]フィールドはゼロに含まれているか、一度に1900年1月1日の0時からの秒数は、FCカプセル化されたフレームは、発信データ・ストリーム内の場所です。
Time Stamp [Seconds Fraction]: The Time Stamp [Second Fraction] field contains the fraction of the second at the time the FC Encapsulated frame is place in the outgoing data stream. Non-significant low order bits may be set to zero. Table 1 shows some example Time Stamp [Seconds Fraction] values.
タイムスタンプ[秒の端数]：タイムスタンプは[第二の画分は】フィールドは、FCカプセル化されたフレームは、出力データストリーム内の場所であるときの第2の部分を含んでいます。非有意下位ビットがゼロに設定されてもよいです。表1は、いくつかの例示的なタイムスタンプ[秒の端数]値を示します。
+------------+--------------------+
| | Time Stamp |
| Second | [Seconds Fraction] |
+------------+--------------------+
| n.50000... | 0x80000000 |
| n.25000... | 0x40000000 |
| n.12500... | 0x20000000 |
+------------+--------------------+
Table 1 Example Time Stamp [Seconds Fraction] values
表1実施例タイムスタンプ[秒の端数]値
Note that, since some time in 1968 (second 2,147,483,648) the most significant bit (bit 0 of Time Stamp [Seconds]) has been set and that the field will overflow some time in 2036 (second 4,294,967,296). Should FCIP be in use in 2036, some external means will be necessary to qualify time relative to 1900 and time relative to 2036 (and other multiples of 136 years). There will exist a 200-picosecond interval, henceforth ignored, every 136 years when the 64-bit field will be 0, which by convention is interpreted as an invalid or unavailable timestamp.
1968年にいくつかの時間（秒2,147,483,648）ので、最上位ビット（タイムスタンプのビット0 [秒]）が設定され、フィールドは（4,294,967,296秒）2036年にいくつかの時間をオーバーフローすることがされていることに留意されたいです。 2036年に使用されている可能FCIPなければならない、いくつかの外部手段は、2036年に1900年に比べて時間と時間の相対を修飾する必要がある（と136年の他の倍数）されます。 64ビットのフィールドは、慣例により無効または利用できないタイムスタンプとして解釈され、0になりときごとに136年、今後無視、200ピコ秒の間隔が存在します。
The Time Stamp [Seconds] and Time Stamp [Seconds Fraction] words follow the in time format described in Simple Network Time Protocol (SNTP) Version 4 [9]. The contents of the Time Stamp [Seconds] and Time Stamp [Seconds Fraction] words SHALL be set as described in section 4.
タイムスタンプ[秒]とタイムスタンプ[秒の端数]言葉は簡易ネットワークタイムプロトコル（SNTP）バージョン4 [9]に記載の時間フォーマットに従います。セクション4で説明したようにタイムスタンプ[秒]とタイムスタンプ[秒の端数]語の内容が設定されなければなりません。
CRC: When the CRCV Flag bit is zero, the CRC field SHALL contain zero. When the CRCV Flag bit is one, the CRC field SHALL contain a CRC for words 0 to 5 of the FC Encapsulation Header computed using the equations, polynomial, initial value, and bit order defined for Fibre Channel in FC-FS [3]. Using this algorithm, the bit order of the resulting CRC corresponds to that of FC-1 layer. The CRC transmitted over the IP network shall correspond to the equivalent value converted to FC-2 format as specified in FC-FS.
CRC：CRCVフラグビットがゼロの場合は、CRCフィールドはゼロを含まなければなりません。 CRCVフラグビットが1である場合、CRCフィールドは、ワード0 FCカプセル化ヘッダの5ためのCRCを含まなければならない式、多項式、初期値、及びFC-FSにおけるファイバチャネルに対して定義されたビット順[3]を用いて計算。このアルゴリズムを用いて、得られたCRCのビット順序はFC-1層のそれに相当します。 IPネットワークを介して送信されるCRCは、FC-FSで指定されたFC-2フォーマットに変換同等の値に対応しなければなりません。
Two mechanisms are provided for validating an FC Encapsulation Header:
二つの機構がFCカプセル化ヘッダを検証するために設けられています。
- Redundancy based - CRC based
- 冗長性は、ベース - CRCベース
The two mechanisms address the needs of two different design and operating environments.
二つのメカニズムは、二つの異なるデザインや動作環境のニーズに対応しています。
Redundancy based validation of an FC Encapsulation Header relies on duplicated and one's complemented fields in the header.
FCカプセル化ヘッダの冗長性ベースの検証が重複し、ヘッダ内の1つの補完フィールドに依存しています。
Encapsulating protocols that use redundancy based validation SHOULD define how receiving devices use one's complement fields to verify header validity.
冗長性ベースの検証を使用するプロトコルをカプセル化する受信装置は、ヘッダの妥当性を確認するために、1の補数のフィールドを使用する方法を定義する必要があります。
Header validation based on redundancy is a stepwise process in that the first word is validated, then the second, then the third and so on. A decision that a candidate header is not valid may be reached before the complete header is available.
冗長性に基づくヘッダー検証が最初のワードが検証されることで、段階的プロセスであり、第2、第3など。完全なヘッダが使用可能になる前に候補ヘッダーが有効でない決定が到達することができます。
CRC based validation of an FC Encapsulation Header relies on a CRC located in the last word of the header.
FCカプセル化ヘッダのCRCベースの検証は、ヘッダの最後のワード内に位置CRCに依存しています。
Header validation based on the CRC defined in section 3.1 requires computing the CRC for all bytes preceding the CRC word, and comparing the results to the CRC word's contents.
セクション3.1で定義されたCRCに基づいて、ヘッダの検証はCRCワードに先行するすべてのバイトのCRCを計算し、CRCワードの内容に結果を比較することが必要です。
To comply with FC-FS [3], an FC Fabric must specify and limit the lifetime of a frame. In an FC Fabric comprised of IP-connected elements, one component of the frame's lifetime is the time required to traverse the connection. To ensure that the total frame lifetime remains within the limits required by the FC Fabric, the encapsulation described in this specification contains provisions for recording the departure time of an encapsulated frame injected into a connection. If the encapsulated frame originator and recipient have access to aligned and synchronized time bases, the transit time through the IP network can then be computed.
FC-FS [3]に準拠するために、FCファブリックは、指定したフレームの寿命を制限しなければなりません。 IP接続要素で構成FCファブリックにおいて、フレームの寿命の一つの成分は、接続を通過するのに要する時間です。総フレーム寿命がFCファブリックによって必要とされる限界内に留まることを保証するために、本明細書に記載のカプセル化を接続に注入カプセル化されたフレームの出発時刻を記録するための規定を含んでいます。カプセル化されたフレームの創始者と受信者が整列し、同期タイムベースへのアクセス権を持っている場合は、IPネットワークを介して通過時間が計算することができます。
When originating an encapsulated frame, an entity that does not support transit time calculation SHALL always set the Time Stamp [Seconds] and Time Stamp [Seconds Fraction] fields to zero. When receiving an encapsulated frame, an entity that does not support transit time calculation SHALL ignore the contents of the Time Stamp words.
カプセル化されたフレームを発信する際、通過時間の計算をサポートしていないエンティティが常にゼロにタイムスタンプ[秒]とタイムスタンプ[秒の端数]フィールドを設定しなければなりません。カプセル化されたフレームを受信した場合、通過時間の計算をサポートしていないエンティティは、タイムスタンプワードの内容を無視します。
The encapsulating protocol SHALL specify whether or not implementation support is required. The encapsulating protocol SHALL specify those conditions under which a received encapsulated frame MUST have its transit time checked before forwarding.
カプセル化プロトコルは、実装のサポートが必要かどうかを規定しなければなりません。カプセル化プロトコルは、受信したカプセル化されたフレームが転送前にチェックその通過時間を有する必要がある下でこれらの条件を規定しなければなりません。
Encapsulating and de-encapsulating entities that support this feature MUST have access to:
カプセル化して、この機能をサポートするデカプセル化エンティティは、へのアクセス権を持っている必要があります。
a) An internal time base having the stability and resolution necessary to comply with the requirements of the encapsulating protocol specification; and
a）は、安定性およびカプセル化プロトコル仕様の要件に準拠するために必要な解像度を有する内部タイムベース。そして
b) A time base that is synchronized and aligned with the time base of other entities to which encapsulated frames may be sent or received. The encapsulating protocol specification MUST describe the synchronization and alignment procedure.
フレームが送信または受信されるカプセル化された他のエンティティのタイムベースに同期して整列されるB）タイムベース。カプセル化プロトコル仕様は、同期および位置合わせ手順を記述しなければなりません。
With respect to its ability to measure and set transit time for encapsulated frames exchanged with another device, an entity is either in the Synchronized or Unsynchronized state. An entity is in the Unsynchronized state upon power-up and transitions to the Synchronized state once it has aligned its time base in accordance with the applicable encapsulating protocol specification.
測定し、カプセル化されたフレームのための通過時間を設定する能力に関しては、他のデバイスと交換して、エンティティが同期または非同期状態のいずれかです。それが適用カプセル化プロトコル仕様に従ってその時間ベースに整列いったんエンティティが同期状態にパワーアップおよび遷移時に非同期状態にあります。
An entity MUST return to the Unsynchronized state if it is unable to maintain synchronization of its time base as required by the encapsulating protocol specification.
カプセル化プロトコル仕様によって必要とされるその時間ベースの同期を維持することができない場合にエンティティが非同期状態に戻らなければなりません。
The policy for forwarding frames while in the Unsynchronized state SHALL be defined by the encapsulating protocol specification.
非同期状態にある間にフレームを転送するためのポリシーは、カプセル化プロトコル仕様によって定義されなければなりません。
If processing frames in the Unsynchronized state is permitted by the encapsulating protocol specification, the entity SHALL:
非同期状態での処理フレームがカプセル化プロトコル仕様によって許可された場合、エンティティがなければなりません。
a) When de-encapsulating a frame, ignore the Time Stamp words. For example, if a calculated transit time exceeds a value that could cause the frame to violate FC maximum time in transit limits, the encapsulating protocol may specify that the frame is to be discarded; and
脱カプセル化する際にフレームa）に示すように、タイムスタンプの単語を無視します。算出走行時間が走行限界におけるFC最大時間に違反するフレームを引き起こす可能性がある値を超えた場合、例えば、カプセル化プロトコルは、フレームが廃棄されることを指定してもよいです。そして
b) When encapsulating a frame set the Time Stamp [Seconds] and Time Stamp [Seconds Fraction] words to zero. For example, an encapsulating protocol may specify that frames for which transit time cannot be determined are never to be forwarded over FC.
b）は、タイムスタンプ[秒]とタイムスタンプ[秒の端数]ゼロに単語を設定フレームをカプセル化します。例えば、カプセル化プロトコルが通過時間を決定することができないためフレームがFCを介して転送することはありませんことを指定してもよいです。
When encapsulating a frame, an entity in the Synchronized state SHALL record the value of the time base in the Time Stamp [Seconds] and Time Stamp [Seconds Fraction] words in the encapsulation header.
フレームをカプセル化するとき、同期状態におけるエンティティは、タイムスタンプ[秒]とカプセル化ヘッダ内のタイムスタンプ[秒の端数]言葉で時間ベースの値を記録しなければなりません。
When de-encapsulating a frame, an entity in the Synchronized state SHALL:
脱カプセル化するときにフレームを同期状態にエンティティがなければなりません。
a) Test the Time Stamp words to determine if they contain a time as specified in [9]. If the time stamp is valid, the receiving entity SHALL compute the transit time by calculating the difference between its time base and the departure time recorded in the frame header. The receiving entity SHALL process the calculated transit time and the de-encapsulated frame in accordance with the applicable encapsulating protocol specification; or
a）は、彼らが[9]で指定された時間が含まれているかどうかを決定するためにタイムスタンプ単語をテスト。タイムスタンプが有効である場合、受信エンティティは、タイムベース及びフレームヘッダに記録された出発時刻の差を計算することによって、通過時間を計算するものとします。受信エンティティは、計算された通過時間と該当カプセル化プロトコル仕様に従って脱カプセル化されたフレームを処理しなければなりません。または
b) If both Time Stamp words have a value of zero, the receiving entity SHALL de-encapsulate the frame without computing the transit time. The disposition of the frame and any other actions by the recipient SHALL be defined by the encapsulating protocol specification.
両方のタイムスタンプワードがゼロの値を持っている場合b）に示すように、受信エンティティは、通過時間を計算せずにフレームを非カプセル化SHALL。フレームの配置と受信者によって任意の他のアクションがカプセル化プロトコル仕様によって定義されなければなりません。
Note: For most purposes, communication between entities is possible only while in the Synchronized state.
注意：ほとんどの目的のために、エンティティ間の通信は、唯一の同期状態にしながら、可能です。
NOTE: All uses of the words "character" or "characters" in this section refer to 8bit/10bit link encoding wherein each 8 bit "character" within a link frame is encoded as a 10 bit "character" for link transmission. These words do not refer to ASCII, Unicode, or any other form of text characters, although octets from such characters will occur as 8 bit "characters" for this encoding. This usage is employed here for consistency with the ANSI T11 standards that specify Fibre Channel.
注：このセクションの単語「文字」または「文字」のすべての使用は、リンクフレーム内の各8ビットの「文字」がリンク送信のための10ビットの「文字」として符号化される8ビット/ 10ビット・リンク・エンコーディングを指します。そのような文字からオクテットは、このエンコーディングのための8ビットの「文字」として発生しますが、これらの言葉は、ASCII、Unicode文字、またはテキスト文字の任意の他の形式を指すものではありません。この使用法は、ファイバチャネルを指定するANSI T11規格との整合性のために、ここで採用されています。
Figure 4 shows the structure of a general FC-2 frame format.
図4は、一般的なFC-2フレームフォーマットの構成を示しています。
+------------------+
| SOF |
+------------------+
| FC frame content |
+------------------+
| EOF |
+------------------+
Figure 4 - General FC-2 Frame Format
図4 - 一般的なFC-2フレーム形式
As shown in Figure 4, the FC frame content is defined as the data between the EOF and SOF delimiters (including the FC CRC) after conversion from FC-1 to FC-2 format as specified by FC-FS [3].
図4に示すように、FC-FSによって指定されるように、FCフレームの内容は、[3] FC-2フォーマットのFC-1からの変換後（FC CRCを含む）EOFとSOFデリミタとの間のデータとして定義されます。
When Fibre Channel devices convert the FC frame content to the FC-0 physical transport, an encoding is applied to the FC frame content (e.g., 8b/10b encoding like that used in Gigbit Ethernet) for reasons that include redundancy and low level timing synchronization between sender and receiver. With the exceptions of SOF and EOF [3] all discussion of FC frame content in this document is at the 8-bit byte level, prior to the application of any such encoding.
ファイバ・チャネル・デバイスは、FC-0の物理トランスポートにFCフレームの内容を変換すると、符号化は、FCフレームの内容に適用される（例えば、Gigbitイーサネット（登録商標）で使用されるような8B / 10B符号化）冗長性と低レベルのタイミング同期を含む理由のために送信者と受信者の間で。 SOFとEOFの例外を除いて、[3]この文書に記載されているFCの全ての議論フレームコンテンツは、任意のそのような符号化の適用前に、8ビットのバイトレベルです。
The 8-bit bytes in the FC frame content can be translated directly for transmission over an IP Network. However, the FC SOF and EOF employ special 10b characters that have no 8b equivalents. Therefore, special byte placement and 8-bit character encodings are required to represent SOF and EOF.
FCフレームの内容に8ビット・バイトがIPネットワーク上での伝送のために直接変換することができます。しかし、FC SOFとEOFには図8Bの等価物を持っていない特殊文字10Bを採用しています。そのため、特別なバイトの配置と8ビット文字エンコーディングがSOFとEOFを表現するために必要とされます。
The Encapsulation Header, SOF, FC frame content (see section 5.1), and EOF are mapped to TCP using the big endian byte ordering, which corresponds to the standard network byte order or canonical form [7].
カプセル化ヘッダー、SOF、FCフレームの内容（セクション5.1を参照）、およびEOFは、標準のネットワークバイト順または標準形式に対応するビッグエンディアンバイト順を使用して、TCPにマッピングされている[7]。
As described in section 5.1, representation of FC SOF and EOF in an IP Network byte stream requires special formatting and 8-bit code definitions. Therefore, the encapsulated FC frame SHALL have the format shown in Figure 5. The redundancy of the SOF/EOF representation in the encapsulation format results from concerns that the information be protected from transmission errors.
セクション5.1で説明したように、IPネットワークバイトストリーム中のFC SOFとEOFの表現は、特別なフォーマットと8ビットコードの定義を必要とします。したがって、カプセル化されたFCフレームは、フォーマットは、図5に情報を伝送誤りから保護されることが懸念からカプセル化フォーマット結果のSOF / EOF表現の冗長性を示さなければなりません。
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------+---------------+-------------------------------+
0| SOF | SOF | -SOF | -SOF |
+---------------+---------------+-------------------------------+
1| |
+----- FC frame content -----+
| |
+---------------+---------------+-------------------------------+
n| EOF | EOF | -EOF | -EOF |
+---------------+---------------+-------------------------------+
Figure 5 - FC Frame Encapsulation Format
図5 - FCフレームのカプセル化形式
Note: The number of 8-bit bytes in the FC frame content is always a multiple of four.
注：FCフレームの内容に8ビット・バイトの数は常に4の倍数です。
SOF: The SOF fields contain the encoded SOF value selected from table 2.
SOF：SOFフィールドは表2から選択された符号化されたSOF値を含みます。
+-------+------+-------+ +-------+------+-------+
| FC | SOF | | | FC | SOF | |
| SOF | Code | Class | | SOF | Code | Class |
+-------+------+-------+ +-------+------+-------+
| SOFf | 0x28 | F | | SOFi4 | 0x29 | 4 |
| SOFi2 | 0x2D | 2 | | SOFn4 | 0x31 | 4 |
| SOFn2 | 0x35 | 2 | | SOFc4 | 0x39 | 4 |
| SOFi3 | 0x2E | 3 | +-------+------+-------+
| SOFn3 | 0x36 | 3 |
+-------+------+-------+
Table 2 Translation of FC SOF values to SOF field contents
SOFフィールドの内容にFC SOF値の表2翻訳
-SOF: The -SOF fields contain the one's complement of the value in the SOF fields. Encapsulation receivers SHOULD validate the SOF field according to a policy defined by the encapsulating protocol.
-SOF：-SOFフィールドはSOFフィールドの値の1の補数が含まれています。封入受信機は、カプセル化プロトコルによって定義されたポリシーに従ってSOFフィールドを検証する必要があります。
EOF: The EOF fields contain the encoded EOF value selected from table 3.
EOF：EOFフィールドが表3から選択された符号化されたEOF値を含みます。
+-------+------+---------+ +--------+------+-------+
| FC | EOF | | | FC | EOF | |
| EOF | Code | Class | | EOF | Code | Class |
+-------+------+---------+ +--------+------+-------+
| EOFn | 0x41 | 2,3,4,F | | EOFdt | 0x46 | 4 |
| EOFt | 0x42 | 2,3,4,F | | EOFdti | 0x4E | 4 |
| EOFni | 0x49 | 2,3,4,F | | EOFrt | 0x44 | 4 |
| EOFa | 0x50 | 2,3,4,F | | EOFrti | 0x4F | 4 |
+-------+------+---------+ +--------+------+-------+
Table 3 Translation of FC EOF values to EOF field contents
EOFフィールドの内容にFC EOF値の表3翻訳
-EOF: The -EOF fields contain the one's complement of the value in the EOF fields. Encapsulation receivers SHOULD validate the EOF field according to a policy defined by the encapsulating protocol.
-EOF：-EOFフィールドはEOFフィールドの値の1の補数が含まれています。封入受信機は、カプセル化プロトコルによって定義されたポリシーに従ってEOFフィールドを検証する必要があります。
Note: FC-BB-2 [6] lists SOF and EOF codes not shown in table 2 and table 3 (e.g., SOFi1 and SOFn1). However, FC-MI [8] identifies these codes as not interoperable, so they are not listed in this specification.
注：FC-BB-2 [6] SOFとEOFコードを示し、表2に示されていないと表3（例えば、SOFi1及びSOFn1）。しかし、FC-MI [8]相互運用しないようにこれらのコードを識別し、従ってそれらは本明細書に記載されていません。
This document describes the encapsulation format only. Actual use of this format in a encapsulating protocol requires an additional document to specify the encapsulating protocol functionality and appropriate security considerations. Because security considerations for this encapsulation depend on how it is used by encapsulating protocols, they SHALL be described in encapsulating protocol specific documents.
この文書では、唯一のカプセル化フォーマットを説明しています。カプセル化プロトコルでは、この形式の実際の使用は、カプセル化プロトコル機能と適切なセキュリティの考慮事項を指定するには、追加の書類が必要です。このカプセル化のためのセキュリティの考慮事項は、それがプロトコルをカプセル化することによってどのように使われるかに依存しているため、彼らは、プロトコル特定の文書をカプセル化して説明します。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Fibre Channel Framing and Signaling (FC-FS), ANSI INCITS.373:2003, October 27, 2003. Note: Published T11 standards are available from the INCITS online store http://www.incits.org, or the ANSI online store, http://www.ansi.org.
[3]ファイバチャネルフレーミングおよびシグナリング（FC-FS）、ANSI INCITS.373：2003年10月27日は、2003年注：公開されたT11規格は、INCITSオンラインストアhttp://www.incits.orgから入手可能であるか、またはANSIオンラインストア、http://www.ansi.org。
[4] Fibre Channel Switch Fabric -2 (FC-SW-2), ANSI NCITS.355:2001, December 12, 2002. Note: Published T11 standards are available from the INCITS online store http://www.incits.org, or the ANSI online store, http://www.ansi.org.
[4]ファイバチャネルスイッチファブリック-2（FC-SW-2）、ANSI NCITS.355：2001年12月12は、2002年注：公開T11規格はINCITSオンラインストアから入手可能であるhttp://www.incits.org 、またはANSIオンラインストア、http://www.ansi.org。
[5] Fibre Channel Physical Interfaces (FC-PI), ANSI NCITS.352:2002, December 1, 2002. Note: Published T11 standards are available from the INCITS online store http://www.incits.org, or the ANSI online store, http://www.ansi.org.
[5]ファイバチャネル物理インターフェイス（FC-PI）、ANSI NCITS.352：2002年12月1日は、2002年注：公開されたT11規格は、INCITSオンラインストアhttp://www.incits.org、またはANSIからご利用いただけますオンラインストア、http://www.ansi.org。
[6] Fibre Channel Backbone -2 (FC-BB-2), ANSI INCITS.372:2003, July 25, 2003. Note: Published T11 standards are available from the INCITS online store http://www.incits.org, or the ANSI online store, http://www.ansi.org.
[6]ファイバチャネルバックボーン-2（FC-BB-2）、ANSI INCITS.372：2003年7月25、2003年注：公開T11規格はINCITSオンラインストアhttp://www.incits.orgから入手可能です、またはANSIオンラインストア、http://www.ansi.org。
[7] Narten, T. and C. Burton, "A Caution on The Canonical Ordering of Link-Layer Addresses", RFC 2469, December 1998.
[7] Narten氏、T.とC.バートン、「リンク層アドレスの正規順序に注意」、RFC 2469、1998年12月。
[8] Fibre Channel Methodologies for Interconnects (FC-MI), ANSI INCITS/TR-30:2002, November 1, 2002. Note: Published T11 standards are available from the INCITS online store http://www.incits.org, or the ANSI online store, http://www.ansi.org.
[8]相互接続のためのファイバ・チャネル方法論を（FC-MI）、ANSI INCITS / TR-30：2002年11月1日、2002年注：公開されたT11規格は、INCITSオンラインストアhttp://www.incits.orgから入手可能です。またはANSIオンラインストア、http://www.ansi.org。
[9] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
、RFC 2030 [9]ミルズ、D.、 "IPv4、IPv6、およびOSIのため簡易ネットワークタイムプロトコル（SNTP）バージョン4"、1996年10月。
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
、BCP 26、RFC 2434、1998年10月[10] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。
[11] Rajagopal, M., Rodriguez, E., Weber, R., "Fibre Channel Over TCP/IP (FCIP)", Work in Progress.
[11] Rajagopal、M.、ロドリゲス、E.、ウェーバー、R.、 "ファイバーチャネルを介したTCP / IP（FCIP）" が進行中で働いています。
[12] Monia, C., et. al., "iFCP - A Protocol for Internet Fibre Channel Storage Networking", Work in Progress.
[12]モニア、C.、ら。 。アル、「のiFCP - インターネットファイバチャネルストレージネットワーキングのための議定書」が進行中で働いています。
The authors express their appreciation to Mr. Vi Chau (vchau1@cox.net) for his contributions to the design team that developed this document. Mr. Chau is no longer working in this technology.
作者はこのドキュメントを開発し、設計チームへの貢献のための氏Viのチャウ（vchau1@cox.net）に感謝の意を表明します。ミスターチャウは、もはやこの技術で作業していません。
The authors are also grateful to Dr. David Black, Mr. Mallikarjun Chadalapaka, and Mr. Robert Elliott for their reviews of this specification.
著者らはまた、この仕様の彼らのレビューのためのデビッド・ブラック氏Mallikarjun Chadalapaka、と氏はロバート・エリオットに感謝しています。
Appendix A - Fibre Channel Bit and Byte Numbering Guidance
付録A - ファイバチャネルビットおよびバイト番号順ガイダンス
Both Fibre Channel and IETF standards use the same byte transmission order. However, the bit and byte numbering is different.
ファイバチャネルおよびIETF標準の両方が同じバイト送信順序を使用します。しかし、ビットおよびバイトの番号が異なっています。
Fibre Channel bit and byte numbering can be observed if the data structure heading shown in Figure 6, is cut and pasted at the top of Figure 2 and Figure 5.
ファイバ・チャネル・ビット及びバイトの番号は、データ構造を図6に示す見出した場合に観察することができ、切断され、図2及び図5の上部に貼り付けられました。
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 6 - Fibre Channel Data Structure Bit and Byte Numbering
図6 - ファイバチャネルデータ構造ビットおよびバイト番号順
Fibre Channel bit numbering for the Flags field can be observed if the data structure heading shown in Figure 7, is cut and pasted at the top of Figure 3.
ファイバチャネルは、図7に示すデータ構造の見出しは、図3の上部で切断し、貼り付けられた場合に観察することができるフラグフィールドの番号のビット。
|------------------------Bit--------------------------|
| |
| 31 30 29 28 27 26 |
Figure 7 - Fibre Channel Flags Bit Numbering
図7 - ファイバチャネルフラグビット番号
Appendix B - Encapsulating Protocol Requirements
付録B - カプセル化プロトコル要件
This appendix lists the requirements placed on the encapsulating protocols that employ this encapsulation. The requirements listed here are suggested or described elsewhere in this document, but their collection in this appendix serves to assist encapsulating protocol authors in meeting all obligations placed upon them.
この付録では、このカプセル化を採用してカプセル化プロトコルに配置要件を示しています。ここに記載されている要件は、提案や、この文書の他の場所で説明するが、この付録の彼らのコレクションは、彼らの上に配置されるすべての義務を満たす上でカプセル化プロトコルの作成者を支援するために提供されています。
Encapsulating Protocol Specific Data
プロトコル固有データをカプセル化
Encapsulating protocols employing this encapsulation SHALL:
SHALLこのカプセル化を採用するプロトコルをカプセル化：
- specify the IANA assigned number used in the Protocol# field - specify the contents of the Encapsulating Protocol Specific field
- カプセル化プロトコル特定フィールドの内容を指定 - プロトコル番号フィールドで使用されるIANA割り当てられた番号を指定します
Encapsulating protocols employing this encapsulation SHALL define the procedures and policies necessary for verifying that an FC Encapsulation Header is being processed.
このカプセル化を使用するカプセル化プロトコルは、FCカプセル化ヘッダが処理されていることを確認するために必要な手順およびポリシーを定義しなければなりません。
Encapsulating protocols employing this encapsulation SHALL define the procedures and policies necessary for the detection of over age frames. The items to be specified and the choices available to an encapsulating protocol specification are as follows:
このカプセル化を使用するカプセル化プロトコルは年齢枠を超えるの検出のために必要な手順およびポリシーを定義しなければなりません。項目を指定すると、次のようにカプセル化プロトコル仕様に利用可能な選択肢があります。
a) The encapsulating protocol requirements for measuring transit times. The encapsulating protocol MAY allow implementation of transit time measurement to be optional.
A）通過時間を測定するためのカプセル化プロトコル要件。カプセル化プロトコルは、走行時間測定の実施は任意であることを可能にすることができます。
b) The requirements or guidelines for stability and resolution of the entity's time base.
b）企業のタイムベースの安定性と解決のための要件やガイドラインを。
c) The procedure for synchronizing an entity's time base, including the criteria for entering the Synchronized and Unsynchronized states.
c）の同期および非同期の状態を入力するための基準を含む、エンティティのタイムベースを同期するための手順。
d) The forwarding (or lack of forwarding) of frame traffic while in the Unsynchronized state.
D）非同期状態にある間、フレームトラフィックの転送（または転送の欠如）。
The specification MAY allow an entity in the Unsynchronized state to continue processing frame traffic.
仕様は、非同期状態のエンティティは、フレームのトラフィックの処理を継続することを可能にします。
e) The procedure to be followed when frames are received that do not have a valid time stamp.
e）のフレームを受信したときの手順に従うことへの有効なタイムスタンプを持っていないこと。
The specification MAY allow such frames to be accepted by the entity.
仕様では、そのようなフレームは、エンティティによって受け入れられることを可能にすることができます。
f) Requirements for setting and testing the transit time limit and the procedure to be followed when a received frame is discarded due to its transit time exceeding the limit.
F）通過時間制限と、受信したフレームを伴う限界を超え、その通過時間に破棄された場合の処理手順を設定し、テストするための要件。
Appendix C - IANA Considerations
付録C - IANAの考慮事項
The Protocol# (Protocol Number) field is an identifier number used to distinguish between the encapsulating protocols that employ this FC frame encapsulation. Values used in the Protocol# field are to be assigned from a new, separate registry that is maintained by IANA.
プロトコル＃（プロトコル番号）フィールドこのFCフレームのカプセル化を使用するカプセル化プロトコルを区別するために使用される識別番号です。プロトコル＃フィールドで使用される値は、IANAによって維持され、新しい、別のレジストリから割り当てられることになっています。
All values in the Protocol# field are to be registered with and assigned by IANA with the following exceptions.
プロトコル番号フィールド内のすべての値はに登録され、次の例外を除いてIANAによって割り当てられることになっています。
- Protocol# value 0 should not be assigned until after all other values have been assigned.
- プロトコル番号値0は、他のすべての値が割り当てられた後まで割り当てすべきではありません。
- Protocol# values 240-255 inclusive must be set aside for private use amongst cooperating systems.
- 包括的なプロトコル＃値240から255は、システムを協力の中で私的使用のために確保されなければなりません。
Following the policies outlined in [10], Protocol# values not listed above are to be assigned only for Standards Track RFCs approved by the IESG.
[10]に概説された方針に続いて、上記に記載されていないプロトコル＃値はIESGによって承認された標準化過程のRFCのために割り当てられることになっています。
In addition to creating the FC Frame Encapsulation Protocol Number Registry, the standards action of this RFC allocates the following two values from the registry:
FCフレームのカプセル化プロトコル番号レジストリの作成に加えて、このRFCの標準アクションは、レジストリから以下の2つの値を割り当てます。
- Protocol# value 1 assigned to the FCIP (Fibre Channel Over TCP/ IP) encapsulating protocol [11].
- FCIP（ファイバチャネルを介してTCP / IP）に割り当てられたプロトコル＃値1プロトコル[11]カプセル化。
- Protocol# value 2 assigned to the iFCP (A Protocol for Internet Fibre Channel Storage Networking) encapsulating protocol [12].
- のiFCP（インターネットファイバチャネルストレージネットワークのためのプロトコル）に割り当てられたプロトコル番号値2プロトコル[12]を封入します。
Appendix D - Intellectual Property Rights Statement
付録D - 知的財産権に関する声明
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
Authors' Addresses
著者のアドレス
Ralph Weber ENDL Texas representing Brocade Comm. Suite 102 PMB 178 18484 Preston Road Dallas, TX 75252 USA
ブロケードコムを表すラルフ・ウェーバーENDLテキサス。スイート102 PMB 178 18484プレストンロードダラス、TX 75252 USA
Phone: +1 214 912 1373 EMail: roweber@ieee.org
電話：+1 214 912 1373 Eメール：roweber@ieee.org
Murali Rajagopal Broadcom 16215 Alton Parkway PO Box 57013 Irvine, CA 92619 USA
ムラリRajagopalのBroadcom 16215アルトンパークウェイ私書箱57013アーバイン、CA 92619 USA
Phone: +1 949 450 8700 EMail: muralir@broadcom.com
電話：+1 949 450 8700 Eメール：muralir@broadcom.com
Franco Travostino Technology Center Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA
フランコTravostino技術センターノーテルネットワークス株式会社600テクノロジーパークビレリカ、MA 01821 USA
Phone: +1 978 288 7708 EMail: travos@nortelnetworks.com
電話：+1 978 288 7708 Eメール：travos@nortelnetworks.com
Michael E. O'Donnell McDATA Corporation 4 McDATA Parkway Broomfield, Co. 80021 USA
マイケルE.オドネルマクデータ社4マクデータ・パークウェイブルームフィールド、株式会社80021 USA
Phone +1 720 558 4142 Fax +1 720 558 8999 EMail: mike.o'donnell@mcdata.com
電話+1 720 558 4142ファックス+1 720 558 8999 Eメール：mike.o'donnell@mcdata.com
Charles Monia
チャールズの多くは
EMail: cmonia@pacbell.net
メールアドレス：cmonia@pacbell.net
Milan J. Merhar Sun Microsystems 43 Nagog Park Acton, MA 01720 USA
ミラノJ. Merhar Sun Microsystemsの43 Nagog公園、アクトン、MA 01720 USA
Phone: +1 978 206 9124 EMail: milan.merhar@sun.com
電話：+1 978 206 9124 Eメール：milan.merhar@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。