[要約] RFC 3643は、Fibre Channel (FC)フレームのカプセル化に関する標準仕様です。このRFCの目的は、異なるネットワーク技術間でのFCフレームの相互運用性を確保することです。
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
ファイバーチャネル（FC）フレームカプセル化
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.
Copyright（c）The Internet Society（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 Technical Committee 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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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フレームの輸送を容易にするには、図1に示すように、わずかに大きな構造にネイティブFCフレームを含める（カプセル化）する必要があります。
+--------------------+
| 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.
バージョン：バージョンフィールドには、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＃フィールドには、プロトコル＃フィールドの内容の補完物を含めるものとします。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フィールドには、バージョンフィールドの内容の補体が含まれます。FCカプセル化レシーバーは、CRCを検証するか、バージョンとバージョンフィールドを比較して、FCカプセル化ヘッダーがカプセル化プロトコルによって定義されたポリシーに従って処理されていることを確認する必要があります。
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カプセル化ヘッダーとFCフレーム（SOFおよびEOFワードを含む）を含む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フィールドには、フラグフィールドの内容の補完物を含めるものとします。FCカプセル化レシーバーは、CRCを検証するか、フラグと-FLAGSフィールドを比較して、FCカプセル化ヘッダーがカプセル化プロトコルによって定義されたポリシーに従って処理されていることを確認する必要があります。
-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.
- フレーム長： - フレーム長フィールドには、フレーム長フィールドの内容の補体が含まれます。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.
タイムスタンプ[秒]：タイムスタンプ[秒]フィールドには、FCカプセル化されたフレームが発信データストリームに配置された時点で、1900年1月1日の0時間以降のゼロまたは秒数が含まれます。
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.
タイムスタンプ[秒分数]：タイムスタンプ[2番目の分数]フィールドには、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秒）、最も重要なビット（タイムスタンプのビット[秒]）が設定されており、2036年にフィールドがしばらくオーバーフローすることに注意してください。FCIPが2036年に使用されている場合、1900年と2036年（および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フィールドには、FC-FS [3]のファイバーチャネルで定義された方程式、多項式、初期値、およびビット順序を使用して計算されたFCカプセル化ヘッダーの0〜5の単語のCRCを含めるものとします。このアルゴリズムを使用して、結果のCRCのビット順序はFC-1層のビット順序に対応します。IPネットワークを介して送信されたCRCは、FC-FSで指定されているようにFC-2形式に変換された等価値に対応するものとします。
Two mechanisms are provided for validating an FC Encapsulation Header:
FCカプセル化ヘッダーを検証するための2つのメカニズムが提供されています。
- Redundancy based - CRC based
- 冗長性ベース-CRCベース
The two mechanisms address the needs of two different design and operating environments.
2つのメカニズムは、2つの異なる設計環境と動作環境のニーズに対応しています。
Redundancy based validation of an FC Encapsulation Header relies on duplicated and one's complemented fields in the header.
FCカプセル化ヘッダーの冗長性ベースの検証は、ヘッダー内の重複および補完されたフィールドに依存しています。
Encapsulating protocols that use redundancy based validation SHOULD define how receiving devices use one's complement fields to verify header validity.
冗長性ベースの検証を使用するカプセル化プロトコルは、受信デバイスが自分の補完フィールドを使用してヘッダーの有効性を検証する方法を定義する必要があります。
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ファブリックでは、フレームの寿命の1つのコンポーネントは、接続を通過するのに必要な時間です。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) 両方のタイムスタンプの単語の値がゼロの場合、受信エンティティは通過時間を計算せずにフレームをエンカプセルします。フレームの処分と受信者によるその他のアクションは、カプセル化プロトコル仕様によって定義されるものとします。
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ビットリンクエンコードを参照しています。これらの単語は、ASCII、Unicode、またはその他の形式のテキスト文字を指すものではありませんが、このような文字のオクテットは、このエンコードの8ビット「文字」として発生します。この使用法は、ファイバーチャネルを指定する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フレームコンテンツは、FC-FS [3]で指定されているFC-1からFC-2形式への変換後、EOFとSOFのデリミター（FC CRCを含む）の間のデータとして定義されます[3]。
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フレームコンテンツをFC-0の物理輸送に変換する場合、冗長性や低レベルのタイミング同期を含む理由で、FCフレームコンテンツ（たとえば、ギグビットイーサネットで使用される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文字を採用しています。したがって、SOFとEOFを表すには、特別なバイト配置と8ビット文字エンコードが必要です。
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は、標準のネットワークバイト順序または標準形式に対応するBig Endianバイトの順序付けを使用して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
表2 FC SOF値のSOFフィールドコンテンツへの翻訳
-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フィールドの値の補完が含まれています。カプセル化レシーバーは、カプセル化プロトコルによって定義されたポリシーに従って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
表3 FC EOF値のEOFフィールドコンテンツへの翻訳
-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フィールドの値の補体が含まれています。カプセル化レシーバーは、カプセル化プロトコルによって定義されたポリシーに従って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]には、表2および表3に示されていないSOFおよびEOFコードがリストされています（例えば、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] Bradner、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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インカット。373：2003、2003年10月27日。注：公開されたT11標準は、インセットオンラインストア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、2002年12月12日。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、2002年12月1日。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、2003年7月25日。注：公開されたT11標準は、INCITS ONLINE STORE 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. Burton、「リンク層アドレスの標準的な順序付けに関する注意」、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、2002年11月1日。オンラインストア、http：//www.ansi.org。
[9] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[9] Mills、D。、「IPv4、IPv6およびOSI用のSimple Network Time Protocol（SNTP）バージョン4」、RFC 2030、1996年10月。
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[10] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[11] Rajagopal, M., Rodriguez, E., Weber, R., "Fibre Channel Over TCP/IP (FCIP)", Work in Progress.
[11] Rajagopal、M.、Rodriguez、E.、Weber、R。、「TCP/IP（FCIP）上のファイバーチャネル」、進行中の作業。
[12] Monia, C., et. al., "iFCP - A Protocol for Internet Fibre Channel Storage Networking", Work in Progress.
[12] Monia、C.、et。al。、「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 Chau氏（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.
著者は、この仕様のレビューについて、デイビッド・ブラック博士、マリカルジュン・チャダラパカ氏、ロバート・エリオット氏にも感謝しています。
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:
このカプセル化を採用するプロトコルのカプセル化は次のとおりです。
- 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.
- Protocol＃Values 240-255 Inclusiveは、協力システム間で私的使用のために確保する必要があります。
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によって承認されたRFCSトラックの標準トラックにのみ割り当てられます。
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].
- Protocol＃値1 FCIP（TCP/ IP上のファイバーチャネル）に割り当てられたプロトコル[11]。
- Protocol# value 2 assigned to the iFCP (A Protocol for Internet Fibre Channel Storage Networking) encapsulating protocol [12].
- プロトコル＃値2 IFCP（インターネットファイバーチャネルストレージネットワーキングのプロトコル）に割り当てられたプロトコル[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
Brocade Commを代表するRalph Weber Endl Texas。スイート102 PMB 178 18484プレストンロードダラス、テキサス75252 USA
Phone: +1 214 912 1373
EMail: roweber@ieee.org
Murali Rajagopal Broadcom 16215 Alton Parkway PO Box 57013 Irvine, CA 92619 USA
Murali Rajagopal Broadcom 16215 Alton Parkway PO Box 57013 Irvine、CA 92619 USA
Phone: +1 949 450 8700
EMail: muralir@broadcom.com
Franco Travostino Technology Center Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA
Franco Travostino Technology Center Nortel Networks、Inc。600 Technology Park Billerica、MA 01821 USA
Phone: +1 978 288 7708
EMail: travos@nortelnetworks.com
Michael E. O'Donnell McDATA Corporation 4 McDATA Parkway Broomfield, Co. 80021 USA
マイケルE.オドネルマクダタコーポレーション4マクダタパークウェイブルームフィールド、コロラド州80021アメリカ
Phone +1 720 558 4142 Fax +1 720 558 8999 EMail: mike.o'donnell@mcdata.com Charles Monia
電話1 720 558 4142ファックス1 720 558 8999メール：mike.o'donnell@mcdata.comチャールズモニア
EMail: cmonia@pacbell.net
Milan J. Merhar Sun Microsystems 43 Nagog Park Acton, MA 01720 USA
ミラノJ.メルハールサンマイクロシステムズ43ナゴグパークアクトン、マサチューセッツ州01720 USA
Phone: +1 978 206 9124
EMail: milan.merhar@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。