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
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.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes the common Fibre Channel (FC) frame encapsulation format and a procedure for the measurement and calculation of frame transit time through the IP network. This specification is intended for use by any IETF protocol that encapsulates FC frames.
本文档介绍了通用光纤通道（FC）帧封装格式以及通过IP网络测量和计算帧传输时间的过程。本规范适用于封装FC帧的任何IETF协议。
Table Of Contents
目录
1. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Encapsulation Concepts . . . . . . . . . . . . . . . . . . . . 3
3. The FC Encapsulation Header. . . . . . . . . . . . . . . . . . 4
3.1. FC Encapsulation Header Format . . . . . . . . . . . . . 4
3.2. FC Encapsulation Header Validation . . . . . . . . . . . 7
3.2.1. Redundancy Based FC Encapsulation
Header Validation. . . . . . . . . . . . . . . . 7
3.2.2. CRC Based FC Encapsulation Header Validation . . 7
4. Measuring Fibre Channel Frame Transit Time . . . . . . . . . . 8
5. The FC Frame . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. FC Frame Content . . . . . . . . . . . . . . . . . . . . 10
5.2. Bit and Byte Ordering. . . . . . . . . . . . . . . . . . 10
5.3. FC SOF and EOF . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix
A Fibre Channel Bit and Byte Numbering Guidance . . . . . . . . . 15
B Encapsulating Protocol Requirements . . . . . . . . . . . . . . 15
C IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16
D Intellectual Property Rights Statement. . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 20
1. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Encapsulation Concepts . . . . . . . . . . . . . . . . . . . . 3
3. The FC Encapsulation Header. . . . . . . . . . . . . . . . . . 4
3.1. FC Encapsulation Header Format . . . . . . . . . . . . . 4
3.2. FC Encapsulation Header Validation . . . . . . . . . . . 7
3.2.1. Redundancy Based FC Encapsulation
Header Validation. . . . . . . . . . . . . . . . 7
3.2.2. CRC Based FC Encapsulation Header Validation . . 7
4. Measuring Fibre Channel Frame Transit Time . . . . . . . . . . 8
5. The FC Frame . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. FC Frame Content . . . . . . . . . . . . . . . . . . . . 10
5.2. Bit and Byte Ordering. . . . . . . . . . . . . . . . . . 10
5.3. FC SOF and EOF . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix
A Fibre Channel Bit and Byte Numbering Guidance . . . . . . . . . 15
B Encapsulating Protocol Requirements . . . . . . . . . . . . . . 15
C IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16
D Intellectual Property Rights Statement. . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 20
This document describes common mechanisms for the transport of Fibre Channel frames over an IP network, including the encapsulation format and a mechanism for enforcing the Fibre Channel frame lifetime limits.
本文档描述了通过IP网络传输光纤通道帧的常见机制，包括封装格式和强制执行光纤通道帧寿命限制的机制。
Warning to Readers Familiar With Fibre Channel: Both Fibre Channel and IETF standards use the same byte transmission order. However, the bit and byte numbering is different. See Appendix A for guidance.
向熟悉光纤通道的读者发出警告：光纤通道和IETF标准都使用相同的字节传输顺序。但是，位和字节编号是不同的。有关指南，请参见附录A。
The organization responsible for the Fibre Channel standards (INCITS Technical Committee T11) has determined that some functions and modes of operation are not interoperable to the degree required by the IETF (see FC-MI [8]). This document includes applicable T11 interoperability determinations in the form of restrictions on the use of this encapsulation mechanism.
负责光纤通道标准的组织（INCITS技术委员会T11）已确定，某些功能和操作模式不具备IETF要求的互操作性（见FC-MI[8]）。本文档包括适用的T11互操作性确定，其形式为对使用该封装机制的限制。
Use of these mechanisms in an encapsulating protocol requires an additional document to specify the encapsulating protocol specific functionality and appropriate security considerations. Because security considerations for this encapsulation depend on how it is used by encapsulating protocols, they are taken up in encapsulating protocol specific documents.
在封装协议中使用这些机制需要额外的文档来指定封装协议特定的功能和适当的安全注意事项。由于此封装的安全考虑因素取决于封装协议如何使用它，因此在封装特定于协议的文档时会用到这些考虑因素。
Conventions used in this document
本文件中使用的公约
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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帧是可变长度的。为了便于通过基于IP的传输（如TCP）传输FC帧，本机FC帧需要包含在（封装在）稍大的结构中，如图1所示。
+--------------------+
| Header |
+--------------------+-----+
| SOF | f |
+--------------------+ F r |
| FC frame content | C a |
+--------------------+ m |
| EOF | e |
+--------------------+-----+
+--------------------+
| 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]）中进行了描述。对于这种封装来说，最重要的是FC要求所有帧都应包含CRC以检测传输错误。
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 |
+---------------------------------------------------------------+
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.
版本：版本字段应包含0x01，以指示正在使用此版本的FC封装。所有其他值保留给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#字段应包含协议#字段内容的补码。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.
-版本：版本字段应包含版本字段内容的补码。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.
标志：标志位提供有关FC封装头使用的信息，如图3所示。
|------------------------Bit--------------------------|
| |
| 0 1 2 3 4 5 |
+--------------------------------------------+--------+
| Reserved | CRCV |
+--------------------------------------------+--------+
|------------------------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位值为1表示CRC字段的内容有效。CRCV位值为零表示CRC字段的内容无效。对于给定连接上发送的所有FC封装头，CRCV位的值应为常量。
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封装头和FC帧（包括SOF和EOF字）。此长度基于32位字的单位。所有FC帧均为32位字对齐，FC封装头始终为字对齐；因此，32位字长是可以接受的。
-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.
-标志：标志字段应包含标志字段内容的补码。FC封装接收器应验证CRC或比较标志和-标志字段，以验证正在根据封装协议定义的策略处理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.
时间戳[Seconds]：时间戳[Seconds]字段包含零或自1900年1月1日0小时起的秒数，此时FC封装帧被放入传出数据流中。
Time Stamp [Seconds Fraction]: The Time Stamp [Second Fraction] field contains the fraction of the second at the time the FC Encapsulated frame is place in the outgoing data stream. Non-significant low order bits may be set to zero. Table 1 shows some example Time Stamp [Seconds Fraction] values.
时间戳[秒分数]：时间戳[秒分数]字段包含FC封装帧放入传出数据流时的秒分数。非有效低位可设置为零。表1显示了一些示例时间戳[秒分数]值。
+------------+--------------------+
| | Time Stamp |
| Second | [Seconds Fraction] |
+------------+--------------------+
| n.50000... | 0x80000000 |
| n.25000... | 0x40000000 |
| n.12500... | 0x20000000 |
+------------+--------------------+
+------------+--------------------+
| | 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年某个时间（秒2147483648）以来，最高有效位（时间戳[Seconds]的位0）已设置，并且该字段将在2036年某个时间溢出（秒4294967296）。如果2036年使用FCIP，则需要一些外部手段来限定相对于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封装头的字0到5的CRC，该字使用FC-FS中为光纤通道定义的方程式、多项式、初始值和位顺序计算[3]。使用该算法，得到的CRC的比特顺序与FC-1层的比特顺序相对应。通过IP网络传输的CRC应与FC-FS中规定的转换为FC-2格式的等效值相对应。
Two mechanisms are provided for validating an FC Encapsulation Header:
为验证FC封装标头提供了两种机制：
- Redundancy based - CRC based
- 基于冗余-基于CRC
The two mechanisms address the needs of two different design and operating environments.
这两种机制满足两种不同设计和操作环境的需求。
Redundancy based validation of an FC Encapsulation Header relies on duplicated and one's complemented fields in the header.
FC封装报头的基于冗余的验证依赖于报头中的重复字段和补充字段。
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.
基于冗余的报头验证是一个逐步的过程，即先验证第一个字，然后验证第二个字，然后验证第三个字，依此类推。在完整报头可用之前，可能会做出候选报头无效的决定。
CRC based validation of an FC Encapsulation Header relies on a CRC located in the last word of the header.
FC封装报头的基于CRC的验证依赖于报头最后一个字中的CRC。
Header validation based on the CRC defined in section 3.1 requires computing the CRC for all bytes preceding the CRC word, and comparing the results to the CRC word's contents.
基于第3.1节中定义的CRC的报头验证要求计算CRC字之前所有字节的CRC，并将结果与CRC字的内容进行比较。
To comply with FC-FS [3], an FC Fabric must specify and limit the lifetime of a frame. In an FC Fabric comprised of IP-connected elements, one component of the frame's lifetime is the time required to traverse the connection. To ensure that the total frame lifetime remains within the limits required by the FC Fabric, the encapsulation described in this specification contains provisions for recording the departure time of an encapsulated frame injected into a connection. If the encapsulated frame originator and recipient have access to aligned and synchronized time bases, the transit time through the IP network can then be computed.
为了符合FC-FS[3]，FC结构必须指定并限制帧的寿命。在由IP连接的元素组成的FC结构中，帧生命周期的一个组成部分是遍历连接所需的时间。为确保总帧寿命保持在FC结构要求的限制范围内，本规范中描述的封装包含用于记录注入连接的封装帧的离开时间的规定。如果封装的帧发起者和接收者可以访问对齐和同步的时基，则可以计算通过IP网络的传输时间。
When originating an encapsulated frame, an entity that does not support transit time calculation SHALL always set the Time Stamp [Seconds] and Time Stamp [Seconds Fraction] fields to zero. When receiving an encapsulated frame, an entity that does not support transit time calculation SHALL ignore the contents of the Time Stamp words.
发起封装帧时，不支持传输时间计算的实体应始终将时间戳[秒]和时间戳[秒分数]字段设置为零。接收封装帧时，不支持传输时间计算的实体应忽略时间戳字的内容。
The encapsulating protocol SHALL specify whether or not implementation support is required. The encapsulating protocol SHALL specify those conditions under which a received encapsulated frame MUST have its transit time checked before forwarding.
封装协议应规定是否需要实现支持。封装协议应规定接收到的封装帧在转发前必须检查其传输时间的条件。
Encapsulating and de-encapsulating entities that support this feature MUST have access to:
支持此功能的封装和反封装实体必须能够访问：
a) An internal time base having the stability and resolution necessary to comply with the requirements of the encapsulating protocol specification; and
a) 具有满足封装协议规范要求所需的稳定性和分辨率的内部时基；和
b) A time base that is synchronized and aligned with the time base of other entities to which encapsulated frames may be sent or received. The encapsulating protocol specification MUST describe the synchronization and alignment procedure.
b) 与可向其发送或接收封装帧的其他实体的时基同步和对齐的时基。封装协议规范必须描述同步和对齐过程。
With respect to its ability to measure and set transit time for encapsulated frames exchanged with another device, an entity is either in the Synchronized or Unsynchronized state. An entity is in the Unsynchronized state upon power-up and transitions to the Synchronized state once it has aligned its time base in accordance with the applicable encapsulating protocol specification.
就其测量和设置与另一设备交换的封装帧的传输时间的能力而言，实体处于同步或非同步状态。实体在通电时处于非同步状态，并在根据适用的封装协议规范调整其时基后转换为同步状态。
An entity MUST return to the Unsynchronized state if it is unable to maintain synchronization of its time base as required by the encapsulating protocol specification.
如果实体无法按照封装协议规范的要求保持其时基的同步，则必须返回到未同步状态。
The policy for forwarding frames while in the Unsynchronized state SHALL be defined by the encapsulating protocol specification.
在非同步状态下转发帧的策略应由封装协议规范定义。
If processing frames in the Unsynchronized state is permitted by the encapsulating protocol specification, the entity SHALL:
如果封装协议规范允许以非同步状态处理帧，则实体应：
a) When de-encapsulating a frame, ignore the Time Stamp words. For example, if a calculated transit time exceeds a value that could cause the frame to violate FC maximum time in transit limits, the encapsulating protocol may specify that the frame is to be discarded; and
a) 取消封装帧时，忽略时间戳字。例如，如果计算的传输时间超过可能导致帧违反FC最大传输时间限制的值，则封装协议可以指定丢弃该帧；和
b) When encapsulating a frame set the Time Stamp [Seconds] and Time Stamp [Seconds Fraction] words to zero. For example, an encapsulating protocol may specify that frames for which transit time cannot be determined are never to be forwarded over FC.
b) 封装帧时，将时间戳[秒]和时间戳[秒分数]字设置为零。例如，封装协议可以指定不能确定传输时间的帧永远不会通过FC转发。
When encapsulating a frame, an entity in the Synchronized state SHALL record the value of the time base in the Time Stamp [Seconds] and Time Stamp [Seconds Fraction] words in the encapsulation header.
封装帧时，处于同步状态的实体应在封装头中的时间戳[Seconds]和时间戳[Seconds Fraction]字中记录时基值。
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 |
+------------------+
+------------------+
| 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-1转换为FC-2格式（如FC-FS[3]所述）后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.
当光纤通道设备将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使用特殊的10b字符，没有8b等效字符。因此，需要特殊的字节位置和8位字符编码来表示SOF和EOF。
The Encapsulation Header, SOF, FC frame content (see section 5.1), and EOF are mapped to TCP using the big endian byte ordering, which corresponds to the standard network byte order or canonical form [7].
封装头、SOF、FC帧内容（见第5.1节）和EOF使用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 |
+---------------+---------------+-------------------------------+
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 |
+-------+------+-------+
+-------+------+-------+ +-------+------+-------+
| 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 |
+-------+------+---------+ +--------+------+-------+
+-------+------+---------+ +--------+------+-------+
| 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 INCITS.373:2003，2003年10月27日。注：发布的T11标准可从INCITS在线商店获得http://www.incits.org，或ANSI在线商店，http://www.ansi.org.
[4] Fibre Channel Switch Fabric -2 (FC-SW-2), ANSI NCITS.355:2001, December 12, 2002. Note: Published T11 standards are available from the INCITS online store http://www.incits.org, or the ANSI online store, http://www.ansi.org.
[4] 光纤通道交换结构-2（FC-SW-2），ANSI NCITS.355:2001，2002年12月12日。注：发布的T11标准可从INCITS在线商店获得http://www.incits.org，或ANSI在线商店，http://www.ansi.org.
[5] Fibre Channel Physical Interfaces (FC-PI), ANSI NCITS.352:2002, December 1, 2002. Note: Published T11 standards are available from the INCITS online store http://www.incits.org, or the ANSI online store, http://www.ansi.org.
[5] 光纤通道物理接口（FC-PI），ANSI NCITS.352:2002，2002年12月1日。注：发布的T11标准可从INCITS在线商店获得http://www.incits.org，或ANSI在线商店，http://www.ansi.org.
[6] Fibre Channel Backbone -2 (FC-BB-2), ANSI INCITS.372:2003, July 25, 2003. Note: Published T11 standards are available from the INCITS online store http://www.incits.org, or the ANSI online store, http://www.ansi.org.
[6] 光纤通道主干网-2（FC-BB-2），ANSI INCITS.372:2003，2003年7月25日。注：发布的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.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日。注：发布的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] Mills，D.，“IPv4、IPv6和OSI的简单网络时间协议（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.等人，“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.
提交人对周维先生表示感谢(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.
作者还感谢David Black博士、Mallikarjun Chadalapaka先生和Robert Elliott先生对本规范的审查。
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|
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的顶部，则可以观察到Flags字段的光纤通道位编号。
|------------------------Bit--------------------------|
| |
| 31 30 29 28 27 26 |
|------------------------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.
Protocol#（Protocol Number）字段是一个标识符编号，用于区分采用此FC帧封装的封装协议。协议#字段中使用的值将从IANA维护的新的单独注册表中分配。
All values in the Protocol# field are to be registered with and assigned by IANA with the following exceptions.
协议#字段中的所有值均应向IANA注册并由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（含240-255）必须留作合作系统之间的私人使用。
Following the policies outlined in [10], Protocol# values not listed above are to be assigned only for Standards Track RFCs approved by the IESG.
按照[10]中概述的政策，上述未列出的协议值仅分配给IESG批准的标准跟踪RFC。
In addition to creating the FC Frame Encapsulation Protocol Number Registry, the standards action of this RFC allocates the following two values from the registry:
除了创建FC帧封装协议编号注册表外，此RFC的标准操作还从注册表中分配以下两个值：
- Protocol# value 1 assigned to the FCIP (Fibre Channel Over TCP/ IP) encapsulating protocol [11].
- 协议#分配给FCIP（TCP/IP上的光纤通道）封装协议的值1[11]。
- Protocol# value 2 assigned to the iFCP (A Protocol for Internet Fibre Channel Storage Networking) encapsulating protocol [12].
- 协议#分配给封装协议的iFCP（用于Internet光纤通道存储网络的协议）的值2[12]。
Appendix D - Intellectual Property Rights Statement
附录D-知识产权声明
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Authors' Addresses
作者地址
Ralph Weber ENDL Texas representing Brocade Comm. Suite 102 PMB 178 18484 Preston Road Dallas, TX 75252 USA
拉尔夫·韦伯·恩德尔（Ralph Weber ENDL Texas）代表Brocade Comm.Suite 102 PMB 178 18484美国德克萨斯州达拉斯普雷斯顿路75252号
Phone: +1 214 912 1373
EMail: roweber@ieee.org
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美国加利福尼亚州欧文市阿尔顿大道邮政信箱57013号，邮编92619
Phone: +1 949 450 8700
EMail: muralir@broadcom.com
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技术中心Nortel Networks，Inc.美国马萨诸塞州比尔里卡600科技园01821
Phone: +1 978 288 7708
EMail: travos@nortelnetworks.com
Phone: +1 978 288 7708
EMail: travos@nortelnetworks.com
Michael E. O'Donnell McDATA Corporation 4 McDATA Parkway Broomfield, Co. 80021 USA
Michael E.O'Donnell McDATA Corporation 4 McDATA Parkway Broomfield，Co.美国80021
Phone +1 720 558 4142 Fax +1 720 558 8999 EMail: mike.o'donnell@mcdata.com
电话+1 720 558 4142传真+1 720 558 8999电子邮件：mike.o'donnell@mcdata.com
Charles Monia
查尔斯·莫尼亚
EMail: cmonia@pacbell.net
EMail: cmonia@pacbell.net
Milan J. Merhar Sun Microsystems 43 Nagog Park Acton, MA 01720 USA
Milan J.Merhar Sun Microsystems 43 Nagog Park Acton，马萨诸塞州01720美国
Phone: +1 978 206 9124
EMail: milan.merhar@sun.com
Phone: +1 978 206 9124
EMail: milan.merhar@sun.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。