RFC3643 日本語訳
3643 Fibre Channel (FC) Frame Encapsulation. R. Weber, M. Rajagopal,F. Travostino, M. O'Donnell, C. Monia, M. Merhar. December 2003. (Format: TXT=39980 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループR.ウェーバー要求をネットワークでつないでください: 3643年の錦のカテゴリ: 規格はM.オドネルMcDATA C.Monia NishanシステムM.Merharサン・マイクロシステムズ2003年12月にM.Rajagopal Broadcom社のF.Travostinoノーテルネットワークを追跡します。
Fibre Channel (FC) Frame Encapsulation
繊維チャンネル(FC)フレームカプセル化
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
このドキュメントは一般的なFibre Channel(FC)フレームカプセル化形式とIPネットワークを通したフレームトランジット時間の測定と計算のための手順について説明します。 この仕様は使用のためにFCフレームを要約するどんなIETFプロトコルでも意図します。
Weber, et al. Standards Track [Page 1] RFC 3643 FC Frame Encapsulation December 2003
ウェーバー、他 規格はFCフレームカプセル化2003年12月にRFC3643を追跡します[1ページ]。
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
1. 範囲。 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. カプセル化概念. . . . . . . . . . . . . . . . . . . . 3 3。 FCカプセル化ヘッダー。 . . . . . . . . . . . . . . . . . 4 3.1. FCカプセル化ヘッダー形式. . . . . . . . . . . . . 4 3.2。 FCカプセル化ヘッダー合法化. . . . . . . . . . . 7 3.2.1。 冗長はFCカプセル化ヘッダー合法化を基礎づけました。 . . . . . . . . . . . . . . . 7 3.2.2. CRCはFCカプセル化ヘッダー合法化. . 7 4を基礎づけました。 繊維チャンネルフレームトランジット時間. . . . . . . . . . 8 5を測定します。 FCは.105.1を縁どっています。 FCは内容. . . . . . . . . . . . . . . . . . . . 10 5.2を縁どっています。 ビットとバイト順。 . . . . . . . . . . . . . . . . . 10 5.3. FC SOFとEOF. . . . . . . . . . . . . . . . . . . . . 11 6。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 12 7. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1。 引用規格. . . . . . . . . . . . . . . . . . 12 7.2。 有益な参照. . . . . . . . . . . . . . . . . 13 8。 繊維チャンネルが噛み付いた承認. . . . . . . . . . . . . . . . . . . . . . . 14付録とバイト付番指導. . . . . . . . . 15B要約は要件. . . . . . . . . . . . . . 15C IANA問題. . . . . . . . . . . . . . . . . . . . . . 16D知的所有権声明について議定書の中で述べます。 . . . . . . . . . . . . 17人の作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 18の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 20
1. Scope
1. 範囲
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.
このドキュメントはFibre Channelフレームの輸送のためにIPネットワークの上で一般的なメカニズムについて説明します、Fibre Channelフレーム生涯限界を実施するためのカプセル化形式とメカニズムを含んでいて。
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.
繊維チャンネルに詳しい読者への警告: Fibre ChannelとIETF規格の両方が同じバイトトランスミッション命令を使用します。 しかしながら、ビットとバイト付番は異なっています。 指導に関してAppendix 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.
Fibre Channel規格(INCITS Technical Committee T11)に責任がある組織は、いくつかの機能と運転モードがIETFによって必要とされた程度に共同利用できないことを決定しました。(FC-MI[8])を見てください。 このドキュメントはこのカプセル化メカニズムの使用の制限の形に適切なT11相互運用性決断を含んでいます。
Weber, et al. Standards Track [Page 2] RFC 3643 FC Frame Encapsulation December 2003
ウェーバー、他 規格はFCフレームカプセル化2003年12月にRFC3643を追跡します[2ページ]。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[2])で説明されるように本書では解釈されることであるべきです。
2. Encapsulation Concepts
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.
Fibre Channel(FC)のデータ伝送とルーティングの最小単位はフレームです。 FCフレームはStart Of Frame(SOF)、End Of Frame(EOF)、およびFibre Channelフレームのコンテンツを含んでいます。 Fibre Channelフレームはフレームのコンテンツのための誤り検出を提供するCyclic Redundancy Check(CRC)コードを含んでいます。 FCフレームは可変長です。 TCPなどのIPのベースの輸送の上でFCフレームを輸送するのを容易にするために、ネイティブのFCフレームは、図1に示されるように(要約されます)わずかに大きい構造に含まれる必要があります。
+--------------------+
| Header |
+--------------------+-----+
| SOF | f |
+--------------------+ F r |
| FC frame content | C a |
+--------------------+ m |
| EOF | e |
+--------------------+-----+
+--------------------+ | ヘッダー| +--------------------+-----+ | SOF| f| +--------------------+ F r| | FCフレーム内容| C a| +--------------------+ m| | EOF| e| +--------------------+-----+
Figure 1 - FC frame Encapsulation
図1--FCフレームEncapsulation
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])。 このカプセル化への重要性はすべてのフレームSHALLが伝送エラーの検出のためのCRCを含んでいるというFC要件です。
Weber, et al. Standards Track [Page 3] RFC 3643 FC Frame Encapsulation December 2003
ウェーバー、他 規格はFCフレームカプセル化2003年12月にRFC3643を追跡します[3ページ]。
3. The FC Encapsulation Header
3. FCカプセル化ヘッダー
3.1. FC Encapsulation Header Format
3.1. FCカプセル化ヘッダー形式
Figure 2 shows the format of the required FC Encapsulation Header.
図2は必要なFC Encapsulation Headerの書式を示しています。
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 |
+---------------------------------------------------------------+
W|------------------------------ビット------------------------------| 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| プロトコル#| バージョン| -プロトコル#| -バージョン| +---------------+---------------+---------------+---------------+ 1| | +----- 要約プロトコル特有です。----+ 2| | +-----------+-------------------+-----------+-------------------+ 3| 旗| フレームの長さ| -旗| -フレームの長さ| +-----------+-------------------+-----------+-------------------+ 4| タイムスタンプ[秒]| +---------------------------------------------------------------+ 5| タイムスタンプ[秒断片]| +---------------------------------------------------------------+ 6| CRC| +---------------------------------------------------------------+
Figure 2 - FC Encapsulation Header Format
図2--FCカプセル化ヘッダー形式
The fields in the FC Encapsulation Header are defined as follows.
FC Encapsulation Headerの分野は以下の通り定義されます。
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).
プロトコル#: プロトコル#分野SHALLはどの要約が議定書を作るかがFC Encapsulationを使っているのを示す数を含んでいます。 プロトコル#分野の値はIANAによって割り当てられます(Appendix 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.
バージョン: バージョン分野SHALLはFC Encapsulationのこのバージョンが使用されているのを示す0×01を含んでいます。 他のすべての値がFC Encapsulationの将来のバージョンのために予約されます。
-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.
-プロトコル#: -プロトコル#分野SHALLはプロトコル#分野のコンテンツの1の補数を含んでいます。 そして、FC Encapsulation受信機SHOULDがCRCを有効にするか、またはプロトコル#を比較する、--#分野について議定書の中で述べて、要約プロトコルによって定義された方針によると、FC Encapsulation Headerが処理されていることを確かめてください。
Weber, et al. Standards Track [Page 4] RFC 3643 FC Frame Encapsulation December 2003
ウェーバー、他 規格はFCフレームカプセル化2003年12月にRFC3643を追跡します[4ページ]。
-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.
-バージョン: バージョン分野SHALLはバージョン分野のコンテンツの1の補数を含んでいます。 FC Encapsulation受信機SHOULDは、CRCを有効にするか、または要約プロトコルによって定義された方針によると、FC Encapsulation Headerが処理されていることを確かめるためにバージョンとバージョン分野を比較します。
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.
旗: Flagsビットは図3に示されるようにFC Encapsulation Headerの使用法の情報を提供します。
|------------------------Bit--------------------------|
| |
| 0 1 2 3 4 5 |
+--------------------------------------------+--------+
| Reserved | CRCV |
+--------------------------------------------+--------+
|------------------------ビット--------------------------| | | | 0 1 2 3 4 5 | +--------------------------------------------+--------+ | 予約されます。| 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.
予約されたFlagsビット: これらのビットは使用のためにFC EncapsulationとSHALLの未来のバージョンによって予約されます。セットがゼロにオンであったなら、発信してください。 プロトコルを要約して、これで説明されたカプセル化を使うと、仕様がしかしながら、受信して、そうするときゼロがないかどうかチェックするのが必要であるかもしれないこのカプセル化の将来のバージョンで両立し難いことを作成する可能性は持たれています。 バージョン分野のコンテンツにおける変化でReserved Flagsビットの使用法における変化を特定しなければなりません。 プロトコルを要約して、この仕様で説明されたカプセル化を使うと、この仕様で説明される以外に、Reserved Flagsビットはどんなファッションでも利用されてはいけません。
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の有効な旗): 1のCRCVビット価値は、CRC分野の内容が有効であることを示します。 ゼロのCRCVビット価値は、CRC分野の内容が無効であることを示します。 CRCVの値は転送されたすべてのFC Encapsulation Headersのための定数が与えられた接続であったならSHALLに噛み付きました。
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.
長さを縁どってください: Frame Length分野はFC Encapsulation HeaderとFCフレームを含む全体のFC Encapsulatedフレームの長さを含んでいます(SOFとEOF単語を含んでいて)。 この長さは32ビットの単語のユニットに基づいています。 すべてのFCフレームが32ビットの単語によって並べられてFC Encapsulation Headerである、いつも単語によって並べられます。 したがって、a32-ビット語長は許容できます。
Weber, et al. Standards Track [Page 5] RFC 3643 FC Frame Encapsulation December 2003
ウェーバー、他 規格はFCフレームカプセル化2003年12月にRFC3643を追跡します[5ページ]。
-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.
-旗: 旗の分野SHALLはFlags分野のコンテンツの1の補数を含んでいます。 FC Encapsulation受信機SHOULDは、CRCを有効にするか、または要約プロトコルによって定義された方針によると、FC Encapsulation Headerが処理されていることを確かめるために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.
-長さを縁どってください: フレームLength分野SHALLはFrame Length分野のコンテンツの1の補数を含んでいます。 FC Encapsulation受信機SHOULDは、CRCを有効にするか、または要約プロトコルによって定義された方針によると、FC Encapsulation Headerが処理されていることを確かめるためにFrame LengthとフレームLength分野を比較します。
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.
タイムスタンプ[秒]: Time Stamp[秒]分野は、FC Encapsulatedが縁どる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.
タイムスタンプ[秒断片]: FC Encapsulatedフレームが発信データストリームにおいて場所であるときに、Time Stamp[第2Fraction]分野は秒の何分の一を含んでいます。 非重要な下位のビットはゼロに設定されるかもしれません。 テーブル1はいくつかの例のTime Stamp[秒Fraction]値を示しています。
+------------+--------------------+
| | Time Stamp |
| Second | [Seconds Fraction] |
+------------+--------------------+
| n.50000... | 0x80000000 |
| n.25000... | 0x40000000 |
| n.12500... | 0x20000000 |
+------------+--------------------+
+------------+--------------------+ | | タイムスタンプ| | 2番目| [秒断片]| +------------+--------------------+ | n.50000… | 0×80000000| | n.25000… | 0×40000000| | n.12500… | 0×20000000| +------------+--------------------+
Table 1 Example Time Stamp [Seconds Fraction] values
テーブル1 Example Time Stamp[秒Fraction]値
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番目の21億4748万3648)に、最も重要なビット(Time Stamp[秒]のビット0)が設定されて、分野が2036年(2番目の42億9496万7296)にいつかあふれるいつかの時間以来それに注意してください。 FCIPが2036年に使用中であるなら、いくつかの外部の手段が、2036(そして、136年の他の倍数)に比例して1900に比例した時間と時間に資格を与えるために必要になるでしょう。 64ビットの分野が0になるときの今後は136年毎に無視された無効の、または、入手できないタイムスタンプとしてコンベンションによって解釈される200ピコセコンドの間隔は存在するでしょう。
Weber, et al. Standards Track [Page 6] RFC 3643 FC Frame Encapsulation December 2003
ウェーバー、他 規格はFCフレームカプセル化2003年12月にRFC3643を追跡します[6ページ]。
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.
形式が時間内にSimple Network Timeプロトコル(SNTP)バージョンで4[9]について説明したとき、Time Stamp[秒]とTime Stamp[秒Fraction]単語は従います。 Time Stamp[秒]とTime Stamp[秒Fraction]のコンテンツはセクションで説明されるセットが4であったならSHALLを言い表します。
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 Flagビットがゼロであるときに、CRC分野SHALLはゼロを含んでいます。 CRCV Flagビットが1であるときに、CRC分野SHALLは、オーダーがFibre ChannelのためにFC-FS[3]で定義した方程式、多項式、初期の値、およびビットを使用することで0〜5FC Encapsulation Headerが計算した単語のためのCRCを含んでいます。 このアルゴリズムを使用して、結果として起こるCRCの噛み付いている注文はFC-1層のものに対応しています。 IPネットワークの上に伝えられたCRCはFC-FSの指定されるとしてのFC-2形式に変換された同等な値に対応するものとします。
3.2. FC Encapsulation Header Validation
3.2. FCカプセル化ヘッダー合法化
Two mechanisms are provided for validating an FC Encapsulation Header:
2つのメカニズムがFC Encapsulation Headerを有効にしながら、備えられます:
- Redundancy based - CRC based
- 基づく冗長--基づくCRC
The two mechanisms address the needs of two different design and operating environments.
2つのメカニズムが2つの意匠相違と操作環境の必要性を記述します。
3.2.1. Redundancy Based FC Encapsulation Header Validation
3.2.1. 冗長はFCカプセル化ヘッダー合法化を基礎づけました。
Redundancy based validation of an FC Encapsulation Header relies on duplicated and one's complemented fields in the header.
コピーされて、FC Encapsulation Headerのベースの合法化が当てにする冗長と1つはヘッダーの分野の補足となりました。
Encapsulating protocols that use redundancy based validation SHOULD define how receiving devices use one's complement fields to verify header validity.
冗長を使用するプロトコルを要約して、ベースの合法化SHOULDは受信装置がヘッダーの正当性について確かめるのにどう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番目の、そして、とてもオンなその時。 完全なヘッダーが手があいている前に候補ヘッダーが有効でないという決定に達するかもしれません。
3.2.2. CRC Based FC Encapsulation Header Validation
3.2.2. CRCはFCカプセル化ヘッダー合法化を基礎づけました。
CRC based validation of an FC Encapsulation Header relies on a CRC located in the last word of the header.
FC Encapsulation Headerの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単語のコンテンツに結果をたとえるのを必要とします。
Weber, et al. Standards Track [Page 7] RFC 3643 FC Frame Encapsulation December 2003
ウェーバー、他 規格はFCフレームカプセル化2003年12月にRFC3643を追跡します[7ページ]。
4. Measuring Fibre Channel Frame Transit Time
4. 測定繊維チャンネルフレームトランジット時間
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 Fabricは、FC-FS[3]に従うために、フレームの生涯を指定して、制限しなければなりません。 IPによって接続された要素から成るFC Fabricでは、フレームの生涯の1つのコンポーネントが接続を横断するのに必要である時間です。 限界の中の総フレーム生涯の残りがFC Fabricが必要であることを保証するために、この仕様で説明されたカプセル化は接続に注がれた要約のフレームの出発時間を記録するための条項を含んでいます。 要約のフレーム創始者と受取人が並べられて連動している時間ベースに近づく手段を持っているなら、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.
要約のフレームを溯源するとき、トランジット時間計算SHALLを支持しない実体はいつもTime Stamp[秒]とTime Stamp[秒Fraction]分野をゼロに設定しました。 要約のフレームを受けるとき、存在しています計算SHALLがTime Stamp単語のコンテンツを無視するトランジット時間を支持しない。
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.
要約プロトコルSHALLは、実現サポートが必要であるかどうか指定します。 要約プロトコルSHALLは推進の前に容認された要約のフレームでトランジット時間をチェックしなければならないそれらの状態を指定します。
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.
別の装置で交換された要約のフレームへのトランジット時間を測定して、設定する性能に関して、実体がSynchronizedかUnsynchronized状態にあります。 実体がパワーアップするところのUnsynchronized状態にあります、そして、適切な要約に従っていったん時間ベースを並べると、Synchronized状態への変遷は仕様を議定書の中で述べます。
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.
必要に応じて要約プロトコル仕様で時間ベースの同期を維持できないなら、実体はUnsynchronized状態に戻らなければなりません。
Weber, et al. Standards Track [Page 8] RFC 3643 FC Frame Encapsulation December 2003
ウェーバー、他 規格はFCフレームカプセル化2003年12月にRFC3643を追跡します[8ページ]。
The policy for forwarding frames while in the Unsynchronized state SHALL be defined by the encapsulating protocol specification.
Unsynchronized州のSHALLで要約プロトコル仕様で定義されている間、フレームを進めるための方針。
If processing frames in the Unsynchronized state is permitted by the encapsulating protocol specification, the entity SHALL:
Unsynchronizedでフレームを処理するなら、状態は要約プロトコル仕様、実体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) 反-フレームを要約するときには、Time Stamp単語を無視してください。 例えば、計算されたトランジット時間が最大の時間フレームがトランジット限界で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) フレームを要約するときには、Time Stamp[秒]とTime Stamp[秒Fraction]単語をゼロに設定してください。 例えば、要約プロトコルは、トランジット時間を測定できないフレームを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.
フレームを要約するとき、Time Stamp[秒]とTime Stamp[秒Fraction]の時間ベースの値がカプセル化ヘッダーに言い表すSynchronized州のSHALL記録では、存在しています。
When de-encapsulating a frame, an entity in the Synchronized state SHALL:
Synchronized州の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) Time Stamp単語をテストして、それらが[9]の指定されるとしての時間を含むかどうか決定してください。 タイムスタンプが有効であるなら、受信実体SHALLは、フレームヘッダーに記録された時間ベースと出発時間の違いについて計算することによって、トランジット時間を計算します。 受信実体SHALLは適切な要約プロトコル仕様通りに計算されたトランジット時間と反-要約されたフレームを処理します。 または
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) 両方のTime Stamp単語にゼロの値があるなら、トランジット時間を計算しないで、受信実体SHALLは反-フレームを要約します。 気質、受取人SHALLによるフレームといかなる他の動作ではも、要約プロトコル仕様で、定義されてください。
Note: For most purposes, communication between entities is possible only while in the Synchronized state.
以下に注意してください。 Synchronized状態にあるだけである間、ほとんどの目的のために、実体のコミュニケーションは可能です。
Weber, et al. Standards Track [Page 9] RFC 3643 FC Frame Encapsulation December 2003
ウェーバー、他 規格はFCフレームカプセル化2003年12月にRFC3643を追跡します[9ページ]。
5. The FC Frame
5. FCフレーム
5.1. FC Frame Content
5.1. FCフレーム内容
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について言及しません、ユニコード、またはいかなる他のフォームのテキストキャラクタ、8がこのコード化のために「キャラクタ」に噛み付いたとき、そのようなキャラクタからの八重奏は起こるでしょうが。 この用法は一貫性にここでFibre Channelを指定するANSI T11規格で使われます。
Figure 4 shows the structure of a general FC-2 frame format.
図4は一般的なFC-2フレーム形式の構造を示しています。
+------------------+
| SOF |
+------------------+
| FC frame content |
+------------------+
| EOF |
+------------------+
+------------------+ | SOF| +------------------+ | FCフレーム内容| +------------------+ | 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を含んでいる)の間のデータと定義されます。
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.
Fibre Channel装置がFCフレーム内容をFC-0の物理的な輸送に変換するとき、コード化は冗長を含んでいる理由と送付者と受信機の間の同期を調節する低レベルのための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.
直接IP Networkの上のトランスミッションのためにFCフレーム内容の8ビットのバイトを翻訳できます。 しかしながら、FC SOFとEOFは8b同等物を全く持っていない特別な10bキャラクタを雇います。 したがって、特別なバイトプレースメントと8ビットのキャラクタencodingsはSOFとEOFを表さなければなりません。
5.2. Bit and Byte Ordering
5.2. ビットとバイト順
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].
Encapsulation Header、SOF、FCフレーム内容(セクション5.1を見る)、およびEOFは、ビッグエンディアンバイト順(標準のネットワークバイトオーダーか標準形[7]に対応している)を使用することでTCPに写像されます。
Weber, et al. Standards Track [Page 10] RFC 3643 FC Frame Encapsulation December 2003
ウェーバー、他 規格はFCフレームカプセル化2003年12月にRFC3643を追跡します[10ページ]。
5.3. FC SOF and EOF
5.3. FC SOFとEOF
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 Networkバイト・ストリームのFC SOFとEOFの表現は特別な形式と8ビットのコード定義を必要とします。 したがって、要約のFCフレームSHALLには、図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 |
+---------------+---------------+-------------------------------+
W|------------------------------ビット------------------------------| 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フレーム内容-----+ | | +---------------+---------------+-------------------------------+ 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 | +-------+------+-------+
+-------+------+-------+ +-------+------+-------+ | FC| SOF| | | FC| SOF| | | SOF| コード| クラス| | SOF| コード| クラス| +-------+------+-------+ +-------+------+-------+ | SOFf| 0×28| F| | SOFi4| 0×29| 4 | | SOFi2| 0x2D| 2 | | SOFn4| 0×31| 4 | | SOFn2| 0×35| 2 | | SOFc4| 0×39| 4 | | SOFi3| 0x2E| 3 | +-------+------+-------+ | SOFn3| 0×36| 3 | +-------+------+-------+
Table 2 Translation of FC SOF values to SOF field contents
テーブル2 SOF分野コンテンツへのFC SOF値のTranslation
-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の補数を含んでいます。 要約プロトコルによって定義された方針によると、カプセル化受信機SHOULDはSOF分野を有効にします。
Weber, et al. Standards Track [Page 11] RFC 3643 FC Frame Encapsulation December 2003
ウェーバー、他 規格はFCフレームカプセル化2003年12月にRFC3643を追跡します[11ページ]。
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 | +-------+------+---------+ +--------+------+-------+
+-------+------+---------+ +--------+------+-------+ | FC| EOF| | | FC| EOF| | | EOF| コード| クラス| | EOF| コード| クラス| +-------+------+---------+ +--------+------+-------+ | EOFn| 0×41| 2 3、4、F| | EOFdt| 0×46| 4 | | EOFt| 0×42| 2 3、4、F| | EOFdti| 0x4E| 4 | | EOFni| 0×49| 2 3、4、F| | EOFrt| 0×44| 4 | | EOFa| 0×50| 2 3、4、F| | EOFrti| 0x4F| 4 | +-------+------+---------+ +--------+------+-------+
Table 3 Translation of FC EOF values to EOF field contents
テーブル3 EOF分野コンテンツへのFC EOF値のTranslation
-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の補数を含んでいます。 要約プロトコルによって定義された方針によると、カプセル化受信機SHOULDは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掲示板2[6]はテーブル2とテーブル3(例えば、SOFi1とSOFn1)で見せられなかったSOFとEOFコードを記載します。 しかしながら、FC-MI[8]が、これらのコードが共同利用できないと認識するので、それらはこの仕様に記載されていません。
6. Security Considerations
6. セキュリティ問題
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.
このドキュメントはカプセル化形式だけについて説明します。 要約プロトコルにおけるこの形式の実際の使用は、要約のプロトコルの機能性と適切なセキュリティ問題を指定するために追加ドキュメントを必要とします。 このカプセル化のためのセキュリティ問題がそれがプロトコルを要約することによって使用されて、それらがどうSHALLであるかによるので、プロトコルの特定のドキュメントを要約する際に、説明されてください。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Weber, et al. Standards Track [Page 12] RFC 3643 FC Frame Encapsulation December 2003
ウェーバー、他 規格はFCフレームカプセル化2003年12月にRFC3643を追跡します[12ページ]。
[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.
2003年10月27日、[3] 繊維チャンネルの縁どりとシグナリング(FC-FS)、ANSI INCITS.373: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.
2001年12月12日、[4] 繊維チャンネルスイッチ織物-2(FC-SW-2)、ANSI NCITS.355: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.
2002年12月1日、[5] 繊維チャンネル物理インターフェース(FC-パイ)、ANSI NCITS.352: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.
2003年7月25日、[6] 繊維チャンネル背骨-2(FC掲示板2)、ANSI INCITS.372: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.バートン、「リンクレイヤアドレスの正準な注文での警告」、RFC2469、1998年12月。
7.2. Informative References
7.2. 有益な参照
[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)、2002年11月1日、2002年のANSI INCITS/TR-30:繊維チャンネル方法論。 以下に注意してください。 発行された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.
[9] 工場、D.、「IPv4、IPv6、およびOSIのための簡単なネットワーク時間プロトコル(SNTP)バージョン4」、RFC2030、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[11] Rajagopal, M., Rodriguez, E., Weber, R., "Fibre Channel Over
TCP/IP (FCIP)", Work in Progress.
[11] M.、ロドリゲス、E.、ウェーバー、R.、「TCP/IP(FCIP)の上の繊維チャンネル」というRajagopalは進行中で働いています。
[12] Monia, C., et. al., "iFCP - A Protocol for Internet Fibre
Channel Storage Networking", Work in Progress.
et[12]Monia、C.、アル、「iFCP--Aはインターネット繊維河道貯留ネットワークのために議定書を作る」、ProgressのWork。
Weber, et al. Standards Track [Page 13] RFC 3643 FC Frame Encapsulation December 2003
ウェーバー、他 規格はFCフレームカプセル化2003年12月にRFC3643を追跡します[13ページ]。
8. Acknowledgements
8. 承認
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 )に彼らの感謝を申し上げます。 Chauさんはもうこの技術で働いていません。
The authors are also grateful to Dr. David Black, Mr. Mallikarjun Chadalapaka, and Mr. Robert Elliott for their reviews of this specification.
また、作者もデヴィッドBlack博士、Mallikarjun Chadalapakaさん、およびロバート・エリオットさんに彼らのこの仕様のレビューに感謝しています。
Weber, et al. Standards Track [Page 14] RFC 3643 FC Frame Encapsulation December 2003
ウェーバー、他 規格はFCフレームカプセル化2003年12月にRFC3643を追跡します[14ページ]。
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.
Fibre Channelと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.
データ構造見出しが図2と図5の先端で図6で目立って、切られて、貼られるなら、繊維Channelビットとバイト付番を観察できます。
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|
W|------------------------------ビット------------------------------| 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.
データ構造見出しが図3の先端で図7で目立って、切られて、貼られるなら、Flags分野のための繊維Channelビット付番を観測できます。
|------------------------Bit--------------------------| | | | 31 30 29 28 27 26 |
|------------------------ビット--------------------------| | | | 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プロトコルSpecific分野のコンテンツを指定してください。
Encapsulating protocols employing this encapsulation SHALL define the procedures and policies necessary for verifying that an FC Encapsulation Header is being processed.
プロトコルを要約して、このカプセル化を使って、SHALLはFC Encapsulation Headerが処理されていることを確かめるのに必要な手順と方針を定義します。
Weber, et al. Standards Track [Page 15] RFC 3643 FC Frame Encapsulation December 2003
ウェーバー、他 規格はFCフレームカプセル化2003年12月にRFC3643を追跡します[15ページ]。
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:
プロトコルを要約して、SHALLが検出に必要な手順と方針を定義するこのカプセル化を使って、フレームはオーバー年をとります。 指定されるべき項目と要約プロトコル仕様に利用可能な選択は以下の通りです:
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) SynchronizedとUnsynchronized州に入る評価基準を含む実体の時間ベースを同期させるための手順。
d) The forwarding (or lack of forwarding) of frame traffic while in
the Unsynchronized state.
d) Unsynchronized状態でフレーム交通の推進(または、推進の不足)。
The specification MAY allow an entity in the Unsynchronized state
to continue processing frame traffic.
仕様で、Unsynchronized状態の実体は、フレーム交通を処理し続けることができるかもしれません。
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.
プロトコル#(プロトコルNumber)分野はこの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 包括的に#値について議定書の中で述べてください。
Weber, et al. Standards Track [Page 16] RFC 3643 FC Frame Encapsulation December 2003
ウェーバー、他 規格はFCフレームカプセル化2003年12月にRFC3643を追跡します[16ページ]。
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によって承認されたStandards Track 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 Frame EncapsulationプロトコルNumber Registryを作成することに加えて、このRFCの規格機能は登録から以下の2つの値を割り当てます:
- Protocol# value 1 assigned to the FCIP (Fibre Channel Over TCP/
IP) encapsulating protocol [11].
- プロトコル#値1は、プロトコル[11]を要約しながら、(繊維Channel Over TCP/IP)をFCIPに割り当てました。
- Protocol# value 2 assigned to the iFCP (A Protocol for Internet
Fibre Channel Storage Networking) encapsulating protocol [12].
- プロトコル#値2は、プロトコル[12]を要約しながら、(インターネットFibre Channel Storage Networkingのためのプロトコル)をiFCPに割り当てました。
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はどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を記述してください。
Weber, et al. Standards Track [Page 17] RFC 3643 FC Frame Encapsulation December 2003
ウェーバー、他 規格はFCフレームカプセル化2003年12月にRFC3643を追跡します[17ページ]。
Authors' Addresses
作者のアドレス
Ralph Weber ENDL Texas representing Brocade Comm. Suite 102 PMB 178 18484 Preston Road Dallas, TX 75252 USA
Brocade Commを表すラルフ・ウェーバー・ENDLテキサス。 スイート102PMB178 18484プレストン・ロード・テキサス75252ダラス(米国)
Phone: +1 214 912 1373 EMail: roweber@ieee.org
以下に電話をしてください。 +1 1373年の214 912メール: roweber@ieee.org
Murali Rajagopal Broadcom 16215 Alton Parkway PO Box 57013 Irvine, CA 92619 USA
Murali Rajagopal Broadcom16215オールトン公園道路PO Box57013カリフォルニア92619アーバイン(米国)
Phone: +1 949 450 8700 EMail: muralir@broadcom.com
以下に電話をしてください。 +1 8700年の949 450メール: muralir@broadcom.com
Franco Travostino Technology Center Nortel Networks, Inc. 600 Technology Park Billerica, MA 01821 USA
フランコTravostino技術センターノーテルはInc.600技術Park MA01821ビルリカ(米国)をネットワークでつなぎます。
Phone: +1 978 288 7708 EMail: travos@nortelnetworks.com
以下に電話をしてください。 +1 7708年の978 288メール: travos@nortelnetworks.com
Michael E. O'Donnell McDATA Corporation 4 McDATA Parkway Broomfield, Co. 80021 USA
マイケルE.オドネルMcDATA社4のMcDATAパークウェイの社80021のブルームフィールド(米国)
Phone +1 720 558 4142 Fax +1 720 558 8999 EMail: mike.o'donnell@mcdata.com
+1 8999がメールする4142年の720 558ファックス+1 720 558に電話をしてください: mike.o' donnell@mcdata.com '
Weber, et al. Standards Track [Page 18] RFC 3643 FC Frame Encapsulation December 2003
ウェーバー、他 規格はFCフレームカプセル化2003年12月にRFC3643を追跡します[18ページ]。
Charles Monia
チャールズMonia
EMail: cmonia@pacbell.net
メール: cmonia@pacbell.net
Milan J. Merhar Sun Microsystems 43 Nagog Park Acton, MA 01720 USA
ミラノJ.Merharサン・マイクロシステムズ43Nagog Park MA01720アクトン(米国)
Phone: +1 978 206 9124 EMail: milan.merhar@sun.com
以下に電話をしてください。 +1 9124年の978 206メール: milan.merhar@sun.com
Weber, et al. Standards Track [Page 19] RFC 3643 FC Frame Encapsulation December 2003
ウェーバー、他 規格はFCフレームカプセル化2003年12月にRFC3643を追跡します[19ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Weber, et al. Standards Track [Page 20]
ウェーバー、他 標準化過程[20ページ]
一覧
スポンサーリンク
