Network Working Group M. Rajagopal
Request for Comments: 3821 E. Rodriguez
Category: Standards Track R. Weber
July 2004
Network Working Group M. Rajagopal
Request for Comments: 3821 E. Rodriguez
Category: Standards Track R. Weber
July 2004
Fibre Channel Over TCP/IP (FCIP)
TCP/IP上的光纤通道（FCIP）
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks.
TCP/IP光纤通道（FCIP）描述了允许光纤通道存储区域网络孤岛通过基于IP的网络互连以在单个光纤通道结构中形成统一存储区域网络的机制。FCIP依靠基于IP的网络服务通过局域网、城域网或广域网提供存储区域网络孤岛之间的连接。
Table Of Contents
目录
1. Purpose, Motivation, and Objectives. . . . . . . . . . . . . . 3
2. Relationship to Fibre Channel Standards. . . . . . . . . . . . 4
2.1. Relevant Fibre Channel Standards . . . . . . . . . . . . 4
2.2. This Specification and Fibre Channel Standards . . . . . 5
3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 7
5. The FCIP Model . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. FCIP Protocol Model. . . . . . . . . . . . . . . . . . . 9
5.2. FCIP Link. . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. FC Entity. . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. FCIP Entity. . . . . . . . . . . . . . . . . . . . . . . 12
5.5. FCIP Link Endpoint (FCIP_LEP). . . . . . . . . . . . . . 13
5.6. FCIP Data Engine (FCIP_DE) . . . . . . . . . . . . . . . 14
5.6.1. FCIP Encapsulation of FC Frames. . . . . . . . . 16
5.6.2. FCIP Data Engine Error Detection and Recovery. . 19
6. Checking FC Frame Transit Times in the IP Network. . . . . . . 22
1. Purpose, Motivation, and Objectives. . . . . . . . . . . . . . 3
2. Relationship to Fibre Channel Standards. . . . . . . . . . . . 4
2.1. Relevant Fibre Channel Standards . . . . . . . . . . . . 4
2.2. This Specification and Fibre Channel Standards . . . . . 5
3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . 7
5. The FCIP Model . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. FCIP Protocol Model. . . . . . . . . . . . . . . . . . . 9
5.2. FCIP Link. . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. FC Entity. . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. FCIP Entity. . . . . . . . . . . . . . . . . . . . . . . 12
5.5. FCIP Link Endpoint (FCIP_LEP). . . . . . . . . . . . . . 13
5.6. FCIP Data Engine (FCIP_DE) . . . . . . . . . . . . . . . 14
5.6.1. FCIP Encapsulation of FC Frames. . . . . . . . . 16
5.6.2. FCIP Data Engine Error Detection and Recovery. . 19
6. Checking FC Frame Transit Times in the IP Network. . . . . . . 22
7. The FCIP Special Frame (FSF) . . . . . . . . . . . . . . . . . 23
7.1. FCIP Special Frame Format. . . . . . . . . . . . . . . . 23
7.2. Overview of FSF Usage in Connection Establishment. . . . 26
8. TCP Connection Management. . . . . . . . . . . . . . . . . . . 28
8.1. TCP Connection Establishment . . . . . . . . . . . . . . 28
8.1.1. Connection Establishment Model . . . . . . . . . 28
8.1.2. Creating New TCP Connections . . . . . . . . . . 29
8.1.3. Processing Incoming TCP Connect Requests . . . . 32
8.1.4. Simultaneous Connection Establishment. . . . . . 36
8.2. Closing TCP Connections. . . . . . . . . . . . . . . . . 36
8.3. TCP Connection Parameters. . . . . . . . . . . . . . . . 36
8.3.1. TCP Selective Acknowledgement Option . . . . . . 36
8.3.2. TCP Window Scale Option. . . . . . . . . . . . . 36
8.3.3. Protection Against Sequence Number Wrap. . . . . 37
8.3.4. TCP_NODELAY Option . . . . . . . . . . . . . . . 37
8.4. TCP Connection Considerations. . . . . . . . . . . . . . 37
8.5. Flow Control Mapping between TCP and FC. . . . . . . . . 37
9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Threat Models. . . . . . . . . . . . . . . . . . . . . . 38
9.2. FC Fabric and IP Network Deployment Models . . . . . . . 40
9.3. FCIP Security Components . . . . . . . . . . . . . . . . 40
9.3.1. IPsec ESP Authentication and Confidentiality . . 40
9.3.2. Key Management . . . . . . . . . . . . . . . . . 41
9.3.3. ESP Replay Protection and Rekeying Issues. . . . 43
9.4. Secure FCIP Link Operation . . . . . . . . . . . . . . . 44
9.4.1. FCIP Link Initialization Steps . . . . . . . . . 44
9.4.2. TCP Connection Security Associations (SAs) . . . 44
9.4.3. Handling Data Integrity and Confidentiality
Violations . . . . . . . . . . . . . . . . . . . 45
10. Performance. . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1. Performance Considerations . . . . . . . . . . . . . . . 45
10.2. IP Quality of Service (QoS) Support. . . . . . . . . . . 46
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
11.1. Normative References . . . . . . . . . . . . . . . . . . 47
11.2. Informative References . . . . . . . . . . . . . . . . . 49
12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 50
Appendix A Fibre Channel Bit and Byte Numbering Guidance. . . . . 51
B IANA Considerations. . . . . . . . . . . . . . . . . . 51
C FCIP Usage of Addresses and Identifiers. . . . . . . . 52
D Example of synchronization Recovery Algorithm. . . . . 53
E Relationship between FCIP and IP over FC (IPFC). . . . 58
F FC Frame Format. . . . . . . . . . . . . . . . . . . . 59
G FC Encapsulation Format. . . . . . . . . . . . . . . . 61
H FCIP Requirements on an FC Entity. . . . . . . . . . . 63
Editors and Contributors Acknowledgements. . . . . . . . . . . . . 69
Editors and Contributors Addresses . . . . . . . . . . . . . . . . 70
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 74
7. The FCIP Special Frame (FSF) . . . . . . . . . . . . . . . . . 23
7.1. FCIP Special Frame Format. . . . . . . . . . . . . . . . 23
7.2. Overview of FSF Usage in Connection Establishment. . . . 26
8. TCP Connection Management. . . . . . . . . . . . . . . . . . . 28
8.1. TCP Connection Establishment . . . . . . . . . . . . . . 28
8.1.1. Connection Establishment Model . . . . . . . . . 28
8.1.2. Creating New TCP Connections . . . . . . . . . . 29
8.1.3. Processing Incoming TCP Connect Requests . . . . 32
8.1.4. Simultaneous Connection Establishment. . . . . . 36
8.2. Closing TCP Connections. . . . . . . . . . . . . . . . . 36
8.3. TCP Connection Parameters. . . . . . . . . . . . . . . . 36
8.3.1. TCP Selective Acknowledgement Option . . . . . . 36
8.3.2. TCP Window Scale Option. . . . . . . . . . . . . 36
8.3.3. Protection Against Sequence Number Wrap. . . . . 37
8.3.4. TCP_NODELAY Option . . . . . . . . . . . . . . . 37
8.4. TCP Connection Considerations. . . . . . . . . . . . . . 37
8.5. Flow Control Mapping between TCP and FC. . . . . . . . . 37
9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.1. Threat Models. . . . . . . . . . . . . . . . . . . . . . 38
9.2. FC Fabric and IP Network Deployment Models . . . . . . . 40
9.3. FCIP Security Components . . . . . . . . . . . . . . . . 40
9.3.1. IPsec ESP Authentication and Confidentiality . . 40
9.3.2. Key Management . . . . . . . . . . . . . . . . . 41
9.3.3. ESP Replay Protection and Rekeying Issues. . . . 43
9.4. Secure FCIP Link Operation . . . . . . . . . . . . . . . 44
9.4.1. FCIP Link Initialization Steps . . . . . . . . . 44
9.4.2. TCP Connection Security Associations (SAs) . . . 44
9.4.3. Handling Data Integrity and Confidentiality
Violations . . . . . . . . . . . . . . . . . . . 45
10. Performance. . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.1. Performance Considerations . . . . . . . . . . . . . . . 45
10.2. IP Quality of Service (QoS) Support. . . . . . . . . . . 46
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
11.1. Normative References . . . . . . . . . . . . . . . . . . 47
11.2. Informative References . . . . . . . . . . . . . . . . . 49
12. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 50
Appendix A Fibre Channel Bit and Byte Numbering Guidance. . . . . 51
B IANA Considerations. . . . . . . . . . . . . . . . . . 51
C FCIP Usage of Addresses and Identifiers. . . . . . . . 52
D Example of synchronization Recovery Algorithm. . . . . 53
E Relationship between FCIP and IP over FC (IPFC). . . . 58
F FC Frame Format. . . . . . . . . . . . . . . . . . . . 59
G FC Encapsulation Format. . . . . . . . . . . . . . . . 61
H FCIP Requirements on an FC Entity. . . . . . . . . . . 63
Editors and Contributors Acknowledgements. . . . . . . . . . . . . 69
Editors and Contributors Addresses . . . . . . . . . . . . . . . . 70
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 74
Warning to Readers Familiar With Fibre Channel: Both Fibre Channel and IETF standards use the same byte transmission order. However, the bit and byte numbering is different. See appendix A for guidance.
向熟悉光纤通道的读者发出警告：光纤通道和IETF标准都使用相同的字节传输顺序。但是，位和字节编号是不同的。有关指南，请参见附录A。
Fibre Channel (FC) is a gigabit or multi-gigabit speed networking technology primarily used to implement Storage Area Networks (SANs). See section 2 for information about how Fibre Channel is standardized and the relationship of this specification to Fibre Channel standards. An overview of Fibre Channel can be found in [34].
光纤通道（FC）是一种千兆或多千兆速度的网络技术，主要用于实现存储区域网络（SAN）。有关光纤通道如何标准化以及本规范与光纤通道标准的关系的信息，请参见第2节。光纤通道概述见[34]。
This specification describes mechanisms that allow the interconnection of islands of Fibre Channel SANs over IP Networks to form a unified SAN in a single Fibre Channel fabric. The motivation behind defining these interconnection mechanisms is a desire to connect physically remote FC sites allowing remote disk access, tape backup, and live mirroring.
本规范描述了允许通过IP网络互连光纤通道SAN孤岛以在单个光纤通道结构中形成统一SAN的机制。定义这些互连机制背后的动机是希望连接物理远程FC站点，从而允许远程磁盘访问、磁带备份和实时镜像。
Fibre Channel standards have chosen nominal distances between switch elements that are less than the distances available in an IP Network. Since Fibre Channel and IP Networking technologies are compatible, it is logical to turn to IP Networking for extending the allowable distances between Fibre Channel switch elements.
光纤通道标准选择的交换机元件之间的标称距离小于IP网络中可用的距离。由于光纤通道和IP网络技术是兼容的，因此采用IP网络来扩展光纤通道交换机元件之间的允许距离是合乎逻辑的。
The fundamental assumption made in this specification is that the Fibre Channel traffic is carried over the IP Network in such a manner that the Fibre Channel Fabric and all Fibre Channel devices on the Fabric are unaware of the presence of the IP Network. This means that the FC datagrams must be delivered in such time as to comply with existing Fibre Channel specifications. The FC traffic may span LANs, MANs, and WANs, so long as this fundamental assumption is adhered to.
本规范中的基本假设是，光纤通道流量通过IP网络传输，其传输方式使光纤通道结构和结构上的所有光纤通道设备都不知道IP网络的存在。这意味着必须在符合现有光纤通道规范的时间内交付FC数据报。只要遵守这一基本假设，FC流量可能跨越LAN、MAN和WAN。
The objectives of this document are to:
本文件的目标是：
1) specify the encapsulation and mapping of Fibre Channel (FC) frames employing FC Frame Encapsulation [19].
1) 指定采用FC帧封装的光纤通道（FC）帧的封装和映射[19]。
2) apply the mechanism described in 1) to an FC Fabric using an IP network as an interconnect between two or more islands in an FC Fabric.
2) 使用IP网络作为FC结构中两个或多个孤岛之间的互连，将1）中描述的机制应用于FC结构。
3) address any FC concerns arising from tunneling FC traffic over an IP-based network, including security, data integrity (loss), congestion, and performance. This will be accomplished by utilizing the existing IETF-specified suite of protocols.
3) 解决在基于IP的网络上通过隧道传输FC流量引起的任何FC问题，包括安全性、数据完整性（丢失）、拥塞和性能。这将通过利用现有的IETF指定的协议套件来实现。
4) be compatible with the referenced FC standards. While new work may be undertaken in T11 to optimize and enhance FC Fabrics, this specification REQUIRES conformance only to the referenced FC standards.
4) 与参考的FC标准兼容。虽然T11中可能会进行新的工作来优化和增强FC结构，但本规范仅要求符合参考的FC标准。
5) be compatible with all applicable IETF standards so that the IP Network used to extend an FC Fabric can be used concurrently for other reasonable purposes.
5) 与所有适用的IETF标准兼容，以便用于扩展FC结构的IP网络可以同时用于其他合理目的。
The objectives of this document do not include using an IP Network as a replacement for the Fibre Channel Arbitrated Loop interconnect. No definition is provided for encapsulating loop primitive signals for transmission over an IP Network.
本文档的目标不包括使用IP网络替代光纤通道仲裁环路互连。没有提供用于封装环路基本信号以通过IP网络传输的定义。
Conventions used in this document
本文件中使用的公约
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。
FC is standardized as a family of American National Standards developed by the T11 technical committee of INCITS (InterNational Committee for Information Technology Standards). T11 has specified a number of documents describing FC protocols, operations, and services. T11 documents of interest to readers of this specification include (but are not limited to):
FC是由INCITS的T11技术委员会（国际信息技术标准委员会）制定的一系列美国国家标准。T11指定了许多描述FC协议、操作和服务的文档。T11本规范读者感兴趣的文件包括（但不限于）：
- FC-BB - Fibre Channel Backbone [2] - FC-BB-2 - Fibre Channel Backbone -2 [3] - FC-SW-2 - Fibre Channel Switch Fabric -2 [4] - FC-FS - Fibre Channel Framing and Signaling [5]
- FC-BB-光纤通道主干[2]-FC-BB-2-光纤通道主干-2[3]-FC-SW-2-光纤通道交换结构-2[4]-FC-FS-光纤通道成帧和信令[5]
FC-BB and FC-BB-2 describe the relationship between an FC Fabric and interconnect technologies not defined by Fibre Channel standards (e.g., ATM and SONET). FC-BB-2 is the Fibre Channel document describing the relationships between FC and TCP/IP, including the FC use of FCIP.
FC-BB和FC-BB-2描述了光纤通道标准（如ATM和SONET）未定义的FC结构和互连技术之间的关系。FC-BB-2是光纤通道文档，描述了FC与TCP/IP之间的关系，包括FC对FCIP的使用。
FC-SW-2 describes the switch components of an FC Fabric and FC-FS describes the FC Frame format and basic control features of Fibre Channel.
FC-SW-2描述了FC结构的交换机组件，FC-FS描述了光纤通道的FC帧格式和基本控制功能。
Additional information regarding T11 activities is available on the committee's web site www.t11.org.
关于T11活动的更多信息可在委员会网站www.T11.org上查阅。
When considering the challenge of transporting FC Frames over an IP Network, it is logical to divide the standardization effort between TCP/IP requirements and Fibre Channel requirements. This specification covers the TCP/IP requirements for transporting FC Frames; the Fibre Channel documents described in section 2.1 cover the Fibre Channel requirements.
在考虑通过IP网络传输FC帧的挑战时，合理的做法是将标准化工作划分为TCP/IP要求和光纤通道要求。本规范涵盖传输FC帧的TCP/IP要求；第2.1节中描述的光纤通道文件涵盖了光纤通道要求。
This specification addresses only the requirements necessary to properly utilize an IP Network as a conduit for FC Frames. The result is a specification for an FCIP Entity (see section 5.4).
本规范仅解决了将IP网络作为FC框架导管的必要要求。结果是FCIP实体的规范（见第5.4节）。
A product that tunnels an FC Fabric through an IP Network MUST combine the FCIP Entity with an FC Entity (see section 5.3) using an implementation specific interface. The requirements placed on an FC Entity by this specification to achieve proper delivery of FC Frames are summarized in appendix H. More information about FC Entities can be found in the Fibre Channel standards and an example of an FC Entity can be found in FC-BB-2 [3].
通过IP网络对FC结构进行隧道传输的产品必须使用特定于实现的接口将FCIP实体与FC实体相结合（参见第5.3节）。附录H总结了本规范对FC实体的要求，以实现FC帧的正确交付。光纤通道标准中提供了有关FC实体的更多信息，FC-BB-2[3]中提供了FC实体的示例。
No attempt is being made to define a specific API between an FCIP Entity and an FC Entity. The approach is to specify required functional interactions between an FCIP Entity and an FC Entity (both of which are required to forward FC frames across an IP Network), but allow implementers to choose how these interactions will be realized.
未尝试在FCIP实体和FC实体之间定义特定API。该方法是指定FCIP实体和FC实体之间所需的功能交互（这两者都是通过IP网络转发FC帧所必需的），但允许实现者选择如何实现这些交互。
Terms used to describe FCIP concepts are defined in this section.
本节定义了用于描述FCIP概念的术语。
FC End Node - An FC device that uses the connection services provided by the FC Fabric.
FC端节点—使用FC结构提供的连接服务的FC设备。
FC Entity - The Fibre Channel specific functional component that combines with an FCIP Entity to form an interface between an FC Fabric and an IP Network (see section 5.3).
FC实体—光纤通道特定的功能组件，与FCIP实体相结合，在FC结构和IP网络之间形成接口（请参阅第5.3节）。
FC Fabric - An entity that interconnects various Nx_Ports (see [5]) attached to it, and is capable of routing FC Frames using only the destination ID information in an FC Frame header (see appendix F).
FC结构-一种互连连接到其上的各种Nx_端口（参见[5]）的实体，能够仅使用FC帧头中的目标ID信息路由FC帧（参见附录F）。
FC Fabric Entity - A Fibre Channel specific element containing one or more Interconnect_Ports (see FC-SW-2 [4]) and one or more FC/FCIP Entity pairs. See FC-BB-2 [3] for details about FC Fabric Entities.
FC结构实体—一种光纤通道特定元素，包含一个或多个互连端口（请参阅FC-SW-2[4]）和一个或多个FC/FCIP实体对。有关FC结构实体的详细信息，请参见FC-BB-2[3]。
FC Frame - The basic unit of Fibre Channel data transfer (see appendix F).
FC帧—光纤通道数据传输的基本单元（见附录F）。
FC Frame Receiver Portal - The access point through which an FC Frame and time stamp enter an FCIP Data Engine from the FC Entity.
FC帧接收器入口-FC帧和时间戳通过其从FC实体进入FCIP数据引擎的接入点。
FC Frame Transmitter Portal - The access point through which a reconstituted FC Frame and time stamp leave an FCIP Data Engine to the FC Entity.
FC帧发送器入口-重建的FC帧和时间戳通过其将FCIP数据引擎留给FC实体的接入点。
FC/FCIP Entity pair - The combination of one FC Entity and one FCIP entity.
FC/FCIP实体对-一个FC实体和一个FCIP实体的组合。
FCIP Data Engine (FCIP_DE) - The component of an FCIP Entity that handles FC Frame encapsulation, de-encapsulation, and transmission FCIP Frames through a single TCP Connection (see section 5.6).
FCIP数据引擎（FCIP_DE）-FCIP实体的组件，通过单个TCP连接处理FC帧封装、反封装和传输FCIP帧（参见第5.6节）。
FCIP Entity - The entity responsible for the FCIP protocol exchanges on the IP Network and encompasses FCIP_LEP(s) and FCIP Control and Services module (see section 5.4).
FCIP实体-负责IP网络上FCIP协议交换的实体，包括FCIP_LEP和FCIP控制与服务模块（见第5.4节）。
FCIP Frame - An FC Frame plus the FC Frame Encapsulation [19] header, encoded SOF and encoded EOF that contains the FC Frame (see section 5.6.1).
FCIP帧-一个FC帧加上包含FC帧的FC帧封装[19]头、编码SOF和编码EOF（见第5.6.1节）。
FCIP Link - One or more TCP Connections that connect one FCIP_LEP to another (see section 5.2).
FCIP链路-将一个FCIP_LEP连接到另一个FCIP_LEP的一个或多个TCP连接（见第5.2节）。
FCIP Link Endpoint (FCIP_LEP) - The component of an FCIP Entity that handles a single FCIP Link and contains one or more FCIP_DEs (see section 5.5).
FCIP链路端点（FCIP_LEP）-处理单个FCIP链路并包含一个或多个FCIP_DE的FCIP实体的组件（见第5.5节）。
Encapsulated Frame Receiver Portal - The TCP access point through which an FCIP Frame is received from the IP Network by an FCIP Data Engine.
封装帧接收器入口-TCP接入点，FCIP数据引擎通过该接入点从IP网络接收FCIP帧。
Encapsulated Frame Transmitter Portal - The TCP access point through which an FCIP Frame is transmitted to the IP Network by an FCIP Data Engine.
封装帧发送器入口-TCP接入点，FCIP帧通过该接入点通过FCIP数据引擎传输到IP网络。
FCIP Special Frame (FSF) - A specially formatted FC Frame containing information used by the FCIP protocol (see section 7).
FCIP特殊帧（FSF）-一种特殊格式的FC帧，包含FCIP协议使用的信息（见第7节）。
The FCIP protocol is summarized as follows:
FCIP协议概述如下：
1) The primary function of an FCIP Entity is forwarding FC Frames, employing FC Frame Encapsulation described in [19].
1) FCIP实体的主要功能是转发FC帧，采用[19]中描述的FC帧封装。
2) Viewed from the IP Network perspective, FCIP Entities are peers and communicate using TCP/IP. Each FCIP Entity contains one or more TCP endpoints in the IP-based network.
2) 从IP网络的角度来看，FCIP实体是对等体，使用TCP/IP进行通信。每个FCIP实体在基于IP的网络中包含一个或多个TCP端点。
3) Viewed from the FC Fabric perspective, pairs of FCIP Entities, in combination with their associated FC Entities, forward FC Frames between FC Fabric elements. The FC End Nodes are unaware of the existence of the FCIP Link.
3) 从FC结构的角度来看，成对的FCIP实体及其关联的FC实体在FC结构元素之间转发FC帧。FC端节点不知道FCIP链路的存在。
4) FC Primitive Signals, Primitive Sequences, and Class 1 FC Frames are not transmitted across an FCIP Link because they cannot be encoded using FC Frame Encapsulation [19].
4) FC基本信号、基本序列和1类FC帧不会通过FCIP链路传输，因为它们无法使用FC帧封装进行编码[19]。
5) The path (route) taken by an encapsulated FC Frame follows the normal routing procedures of the IP Network.
5) 封装FC帧采用的路径（路由）遵循IP网络的正常路由过程。
6) An FCIP Entity MAY contain multiple FCIP Link Endpoints, but each FCIP Link Endpoint (FCIP_LEP) communicates with exactly one other FCIP_LEP.
6) 一个FCIP实体可能包含多个FCIP链路端点，但每个FCIP链路端点（FCIP_LEP）只与另一个FCIP_LEP通信。
7) When multiple FCIP_LEPs with multiple FCIP_DEs are in use, selection of which FCIP_DE to use for encapsulating and transmitting a given FC Frame is covered in FC-BB-2 [3]. FCIP Entities do not actively participate in FC Frame routing.
7) 当使用具有多个FCIP_DE的多个FCIP_LEP时，FC-BB-2[3]中涵盖了用于封装和传输给定FC帧的FCIP_DE的选择。FCIP实体不主动参与FC帧路由。
8) The FCIP Control and Services module MAY use TCP/IP quality of service features (see section 10.2).
8) FCIP控制和服务模块可使用TCP/IP服务质量功能（见第10.2节）。
9) It is necessary to statically or dynamically configure each FCIP entity with the IP addresses and TCP port numbers corresponding to FCIP Entities with which it is expected to initiate communication. If dynamic discovery of participating FCIP Entities is supported, the function SHALL be performed using the Service Location Protocol (SLPv2) [17]. It is outside the scope of this specification to describe any static configuration method for participating FCIP Entity discovery. Refer to section 8.1.2.2 for a detailed description of dynamic discovery of participating FCIP Entities using SLPv2.
9) 有必要静态或动态地配置每个FCIP实体的IP地址和TCP端口号，这些IP地址和TCP端口号与FCIP实体对应，FCIP实体将与FCIP实体启动通信。如果支持参与FCIP实体的动态发现，则应使用服务位置协议（SLPv2）[17]执行该功能。描述参与FCIP实体发现的任何静态配置方法不在本规范的范围内。有关使用SLPv2动态发现参与FCIP实体的详细说明，请参阅第8.1.2.2节。
10) Before creating a TCP Connection to a peer FCIP Entity, the FCIP Entity attempting to create the TCP connection SHALL statically or dynamically determine the IP address, TCP port, expected FC Fabric Entity World Wide Name, TCP Connection Parameters, and Quality of Service Information.
10） 在创建到对等FCIP实体的TCP连接之前，尝试创建TCP连接的FCIP实体应静态或动态确定IP地址、TCP端口、预期FC结构实体全球通用名称、TCP连接参数和服务质量信息。
11) FCIP Entities do not actively participate in the discovery of FC source and destination identifiers. Discovery of FC addresses (accessible via the FCIP Entity) is provided by techniques and protocols within the FC architecture as described in FC-FS [5] and FC-SW-2 [4].
11） FCIP实体不主动参与FC源和目标标识符的发现。FC地址的发现（可通过FCIP实体访问）由FC架构内的技术和协议提供，如FC-FS[5]和FC-SW-2[4]所述。
12) To support IP Network security (see section 9), FCIP Entities MUST: 1) implement cryptographically protected authentication and cryptographic data integrity keyed to the authentication process, and 2) implement data confidentiality security features.
12） 为了支持IP网络安全（见第9节），FCIP实体必须：1）实施加密保护的身份验证和加密数据完整性，并将其键入身份验证过程，2）实施数据机密性安全功能。
13) On an individual TCP Connection, this specification relies on TCP/IP to deliver a byte stream in the same order that it was sent.
13） 在单个TCP连接上，此规范依赖于TCP/IP以发送字节流的相同顺序发送字节流。
14) This specification assumes the presence of and requires the use of TCP and FC data loss and corruption mechanisms. The error detection and recovery features described in this specification complement and support these existing mechanisms.
14） 本规范假设存在并要求使用TCP和FC数据丢失和损坏机制。本规范中描述的错误检测和恢复功能补充并支持这些现有机制。
The relationship between FCIP and other protocols is illustrated in figure 1.
FCIP和其他协议之间的关系如图1所示。
+------------------------+ FCIP Link +------------------------+
| FCIP |===========| FCIP |
+--------+------+--------+ +--------+------+--------+
| FC-2 | | TCP | | TCP | | FC-2 |
+--------+ +--------+ +--------+ +--------+
| FC-1 | | IP | | IP | | FC-1 |
+--------+ +--------+ +--------+ +--------+
| FC-0 | | LINK | | LINK | | FC-0 |
+--------+ +--------+ +--------+ +--------+
| | PHY | | PHY | |
| +--------+ +--------+ |
| | | |
| | IP Network | |
V +--------------------+ V
to Fibre to Fibre
Channel Channel
Fabric Fabric
+------------------------+ FCIP Link +------------------------+
| FCIP |===========| FCIP |
+--------+------+--------+ +--------+------+--------+
| FC-2 | | TCP | | TCP | | FC-2 |
+--------+ +--------+ +--------+ +--------+
| FC-1 | | IP | | IP | | FC-1 |
+--------+ +--------+ +--------+ +--------+
| FC-0 | | LINK | | LINK | | FC-0 |
+--------+ +--------+ +--------+ +--------+
| | PHY | | PHY | |
| +--------+ +--------+ |
| | | |
| | IP Network | |
V +--------------------+ V
to Fibre to Fibre
Channel Channel
Fabric Fabric
Key: FC-0 - Fibre Channel Physical Media Layer FC-1 - Fibre Channel Encode and Decode Layer FC-2 - Fibre Channel Framing and Flow Control Layer TCP - Transmission Control Protocol IP - Internet Protocol LINK - IP Link Layer PHY - IP Physical Layer
密钥：FC-0-光纤通道物理媒体层FC-1-光纤通道编码和解码层FC-2-光纤通道帧和流控制层TCP-传输控制协议IP-互联网协议链路-IP链路层物理层-IP物理层
Figure 1: FCIP Protocol Stack Model
图1:FCIP协议栈模型
Note that the objective of the FCIP Protocol is to create and maintain one or more FCIP Links to transport data.
请注意，FCIP协议的目标是创建和维护一个或多个FCIP链路以传输数据。
The FCIP Link is the basic unit of service provided by the FCIP Protocol to an FC Fabric. As shown in figure 2, an FCIP Link connects two portions of an FC Fabric using an IP Network as a transport to form a single FC Fabric.
FCIP链路是FCIP协议向FC结构提供的基本服务单元。如图2所示，FCIP链路使用IP网络作为传输连接FC结构的两部分，以形成单个FC结构。
/\/\/\/\/\/\ /\/\/\/\/\/\ /\/\/\/\/\/\
\ FC / \ IP / \ FC /
/ Fabric \=========/ Network \=========/ Fabric \
\/\/\/\/\/\/ \/\/\/\/\/\/ \/\/\/\/\/\/
| |
|<--------- FCIP Link -------->|
/\/\/\/\/\/\ /\/\/\/\/\/\ /\/\/\/\/\/\
\ FC / \ IP / \ FC /
/ Fabric \=========/ Network \=========/ Fabric \
\/\/\/\/\/\/ \/\/\/\/\/\/ \/\/\/\/\/\/
| |
|<--------- FCIP Link -------->|
Figure: 2 FCIP Link Model
图2：FCIP链路模型
At the points where the ends of the FCIP Link meet portions of the FC Fabric, an FCIP Entity (see section 5.4) combines with an FC Entity as described in section 5.3 to serve as the interface between FC and IP.
在FCIP链路端部与FC结构部分相交的点处，FCIP实体（见第5.4节）与第5.3节所述的FC实体相结合，作为FC和IP之间的接口。
An FCIP Link SHALL contain at least one TCP Connection and MAY contain more than one TCP Connection. The endpoints of a single TCP Connection are FCIP Data Engines (see section 5.6). The endpoints of a single FCIP Link are FCIP Link Endpoints (see section 5.5).
FCIP链路应至少包含一个TCP连接，并且可以包含多个TCP连接。单个TCP连接的端点是FCIP数据引擎（参见第5.6节）。单个FCIP链路的端点为FCIP链路端点（见第5.5节）。
An implementation that tunnels an FC Fabric through an IP Network MUST combine an FC Entity with an FCIP Entity (see section 5.4) to form a complete interface between the FC Fabric and IP Network as shown in figure 3. An FC Fabric Entity may contain multiple instances of the FC/FCIP Entity pair shown on either the right-hand or left-hand side of figure 3.
通过IP网络隧道FC结构的实现必须将FC实体与FCIP实体相结合（参见第5.4节），以在FC结构和IP网络之间形成完整的接口，如图3所示。FC结构实体可能包含图3右侧或左侧显示的FC/FCIP实体对的多个实例。
|<--------- FCIP Link -------->|
| |
+----------+ /\/\/\/\/\/\ +----------+
| FCIP | \ IP / | FCIP |
| Entity |=========/ Network \=========| Entity |
+----------+ \/\/\/\/\/\/ +----------+
| FC | | FC |
| Entity | | Entity |
+----------+ +----------+
| |
/\/\/\/\/\/\ /\/\/\/\/\/\
\ FC / \ FC /
/ Fabric \ / Fabric \
\/\/\/\/\/\/ \/\/\/\/\/\/
|<--------- FCIP Link -------->|
| |
+----------+ /\/\/\/\/\/\ +----------+
| FCIP | \ IP / | FCIP |
| Entity |=========/ Network \=========| Entity |
+----------+ \/\/\/\/\/\/ +----------+
| FC | | FC |
| Entity | | Entity |
+----------+ +----------+
| |
/\/\/\/\/\/\ /\/\/\/\/\/\
\ FC / \ FC /
/ Fabric \ / Fabric \
\/\/\/\/\/\/ \/\/\/\/\/\/
Figure 3: Model for Two Connected FC/FCIP Entity Pairs
图3：两个连接的FC/FCIP实体对的模型
In general, the combination of an FCIP Link and two FC/FCIP Entity pairs is intended to provide a non-Fibre Channel backbone transport between Fibre Channel components. For example, this combination can be used to function as the hard-wire connection between two Fibre Channel switches.
通常，FCIP链路和两个FC/FCIP实体对的组合旨在提供光纤通道组件之间的非光纤通道主干传输。例如，此组合可用作两个光纤通道交换机之间的硬线连接。
The interface between the FC and FCIP Entities is implementation specific. The functional requirements placed on an FC Entity by this specification are listed in appendix H. More information about FC Entities can be found in the Fibre Channel standards and an example of an FC Entity can be found in FC-BB-2 [3].
FC和FCIP实体之间的接口是特定于实现的。附录H列出了本规范对FC实体的功能要求。光纤通道标准中提供了有关FC实体的更多信息，FC-BB-2[3]中提供了FC实体的示例。
The model for an FCIP Entity is shown in figure 4.
FCIP实体的模型如图4所示。
.......................................................
: FCIP Entity :
: :
: +-----------+ :
: | FCIP | :
: |Control and|------------------------------------+ :
: | Services | | :
: | Module | | :
: +-----------+ | :
: | +--------------------+ | :
: | +-------+--------------------+|----+ | :
: | |+-----+--------------------+|----+| | :
: | ||+----| FCIP Link Endpoint |----+|| | :
: | ||| +--------------------+ ||| | :
:.............................................|||.....:
| ||| ||| |
| ||| ||| o<--+
| ||| unique TCP ||| | |
| ||| connections-->||| | |
| ||| ||| | |
+----------+ /\/\/\/\/\/\ |
| FC | \ IP / |
| Entity | / Network \ |
+----------+ \/\/\/\/\/\/ |
| |
/\/\/\/\/\/\ +------------------+
\ FC / +->TCP port for
/ Fabric \ incoming
\/\/\/\/\/\/ connections
.......................................................
: FCIP Entity :
: :
: +-----------+ :
: | FCIP | :
: |Control and|------------------------------------+ :
: | Services | | :
: | Module | | :
: +-----------+ | :
: | +--------------------+ | :
: | +-------+--------------------+|----+ | :
: | |+-----+--------------------+|----+| | :
: | ||+----| FCIP Link Endpoint |----+|| | :
: | ||| +--------------------+ ||| | :
:.............................................|||.....:
| ||| ||| |
| ||| ||| o<--+
| ||| unique TCP ||| | |
| ||| connections-->||| | |
| ||| ||| | |
+----------+ /\/\/\/\/\/\ |
| FC | \ IP / |
| Entity | / Network \ |
+----------+ \/\/\/\/\/\/ |
| |
/\/\/\/\/\/\ +------------------+
\ FC / +->TCP port for
/ Fabric \ incoming
\/\/\/\/\/\/ connections
Figure 4: FCIP Entity Model
图4:FCIP实体模型
The FCIP Entity receives TCP connect requests on behalf of the FCIP_LEPs that it manages. In support of this, the FCIP Entity is the sole owner of at least one TCP port/IP Address combination used to form TCP Connections. The TCP port may be the FCIP well known port at a given IP Address. An FC Fabric to IP Network interface product SHALL provide each FC/FCIP Entity pair contained in the product with a unique combination of FC Fabric Entity World Wide Identifier and FC/FCIP Entity Identifier values (see section 7).
FCIP实体代表其管理的FCIP接收TCP连接请求。为了支持这一点，FCIP实体是用于形成TCP连接的至少一个TCP端口/IP地址组合的唯一所有者。TCP端口可以是给定IP地址的FCIP已知端口。FC结构到IP网络接口产品应为产品中包含的每个FC/FCIP实体对提供FC结构实体全球标识符和FC/FCIP实体标识符值的唯一组合（见第7节）。
An FCIP Entity contains an FCIP Control and Services Module to control FCIP link initialization, FCIP link dissolution, and to provide the FC Entity with an interface to key IP Network features.
FCIP实体包含FCIP控制和服务模块，用于控制FCIP链路初始化、FCIP链路解除，并为FC实体提供与关键IP网络功能的接口。
The interfaces to the IP Network features are implementation specific, however, REQUIRED TCP/IP functional support is specified in this document, including:
IP网络功能的接口是特定于实现的，但是，本文件规定了所需的TCP/IP功能支持，包括：
- TCP Connections - see section 8 - Security - see section 9 - Performance - see section 10 - Dynamic Discovery - see section 8.1.2.2
- TCP连接-参见第8节-安全-参见第9节-性能-参见第10节-动态发现-参见第8.1.2.2节
The FCIP Link Endpoints in an FCIP Entity provide the FC Frame encapsulation and transmission features of FCIP.
FCIP实体中的FCIP链路端点提供FCIP的FC帧封装和传输特性。
As shown in figure 5, the FCIP Link Endpoint contains one FCIP Data Engine for each TCP Connection in the FCIP Link.
如图5所示，FCIP链路端点为FCIP链路中的每个TCP连接包含一个FCIP数据引擎。
................................................
: FCIP Link Endpoint :
: +------------------+ :
: +-------+------------------+|----+ :
: |+-----+------------------+|----+| :
: ||+----| FCIP Data Engine |----+|| :
: ||| +------------------+ ||| :
:..............................................:
||| |||
+----------+ /\/\/\/\/\/\
| FC | \ IP /
| Entity | / Network \
+----------+ \/\/\/\/\/\/
|
/\/\/\/\/\/\
\ FC /
/ Fabric \
\/\/\/\/\/\/
................................................
: FCIP Link Endpoint :
: +------------------+ :
: +-------+------------------+|----+ :
: |+-----+------------------+|----+| :
: ||+----| FCIP Data Engine |----+|| :
: ||| +------------------+ ||| :
:..............................................:
||| |||
+----------+ /\/\/\/\/\/\
| FC | \ IP /
| Entity | / Network \
+----------+ \/\/\/\/\/\/
|
/\/\/\/\/\/\
\ FC /
/ Fabric \
\/\/\/\/\/\/
Figure 5: FCIP Link Endpoint Model
图5:FCIP链路端点模型
Each time a TCP Connection is formed with a new FC/FCIP Entity pair (including all the actions described in section 8.1), the FCIP Entity SHALL create a new FCIP Link Endpoint containing one FCIP Data Engine.
每次使用新FC/FCIP实体对（包括第8.1节中描述的所有操作）形成TCP连接时，FCIP实体应创建包含一个FCIP数据引擎的新FCIP链路端点。
An FCIP_LEP is a transparent data translation point between an FC Entity and an IP Network. A pair of FCIP_LEPs communicating over one or more TCP Connections create an FCIP Link to join two islands of an FC Fabric, producing a single FC Fabric.
FCIP_LEP是FC实体和IP网络之间的透明数据转换点。通过一个或多个TCP连接进行通信的一对FCIP_LEP创建一个FCIP链路，以连接FC结构的两个孤岛，从而生成一个FC结构。
The IP Network over which the two FCIP_LEPs communicate is not aware of the FC payloads that it is carrying. Likewise, the FC End Nodes connected to the FC Fabric are unaware of the TCP/IP based transport employed in the structure of the FC Fabric.
两个FCIP_LEP通过其通信的IP网络不知道其承载的FC有效负载。同样，连接到FC结构的FC端节点不知道FC结构中采用的基于TCP/IP的传输。
An FCIP_LEP uses normal TCP based flow control mechanisms for managing its internal resources and matching them with the advertised TCP Receiver Window Size (see sections 8.3.2, 8.5). An FCIP_LEP MAY communicate with its local FC Entity counterpart to coordinate flow control.
FCIP_LEP使用普通的基于TCP的流量控制机制来管理其内部资源，并将其与公布的TCP接收器窗口大小相匹配（参见第8.3.2、8.5节）。FCIP_LEP可与其本地FC实体通信，以协调流量控制。
The model for one of the multiple FCIP_DEs that MAY be present in an FCIP_LEP is shown in figure 6.
图6显示了FCIP_LEP中可能存在的多个FCIP_DE之一的模型。
+--------------------------------+
| |
F |-+ +------------------+ +-|
C |p| | Encapsulation | |p| N
-->|1|--->| Engine |--->|2|--> e
E |-+ +------------------+ +-| t
n | | I w
t |-+ +------------------+ +-| P o
i |p| | De-Encapsulation | |p| r
t <--|4|<---| Engine |<---|3|<-- k
y |-+ +------------------+ +-|
| |
+--------------------------------+
+--------------------------------+
| |
F |-+ +------------------+ +-|
C |p| | Encapsulation | |p| N
-->|1|--->| Engine |--->|2|--> e
E |-+ +------------------+ +-| t
n | | I w
t |-+ +------------------+ +-| P o
i |p| | De-Encapsulation | |p| r
t <--|4|<---| Engine |<---|3|<-- k
y |-+ +------------------+ +-|
| |
+--------------------------------+
Figure 6: FCIP Data Engine Model
图6:FCIP数据引擎模型
Data enters and leaves the FCIP_DE through four portals (p1 - p4). The portals do not process or examine the data that passes through them. They are only the named access points where the FCIP_DE interfaces with the external world. The names of the portals are as follows:
数据通过四个入口（p1-p4）进入和离开FCIP。门户不处理或检查通过它们的数据。它们只是FCIP_DE与外部世界接口的命名接入点。门户的名称如下：
p1) FC Frame Receiver Portal - The interface through which an FC Frame and time stamp enters an FCIP_DE from the FC Entity.
p1）FC帧接收器入口-FC帧和时间戳从FC实体进入FCIP_DE的接口。
p2) Encapsulated Frame Transmitter Portal - The TCP interface through which an FCIP Frame is transmitted to the IP Network by an FCIP_DE.
p2）封装的帧发送器入口-TCP接口，FCIP帧通过该接口通过FCIP设备传输到IP网络。
p3) Encapsulated Frame Receiver Portal - The TCP interface through which an FCIP Frame is received from the IP Network by an FCIP_DE.
p3）封装帧接收器入口-TCP接口，FCIP DE通过该接口从IP网络接收FCIP帧。
p4) FC Frame Transmitter Portal - The interface through which a reconstituted FC Frame and time stamp exits an FCIP_DE to the FC Entity.
p4）FC帧发送器入口-重建的FC帧和时间戳通过其退出FCIP到FC实体的接口。
The work of the FCIP_DE is done by the Encapsulation and De-Encapsulation Engines. The Engines have two functions:
FCIP_DE的工作由封装和反封装引擎完成。发动机有两个功能：
1) Encapsulating and de-encapsulating FC Frames using the encapsulation format described in FC Frame Encapsulation [19] and in section 5.6.1 of this document, and
1) 使用FC帧封装[19]和本文件第5.6.1节中描述的封装格式封装和反封装FC帧，以及
2) Detecting some data transmission errors and performing minimal error recovery as described in section 5.6.2.
2) 如第5.6.2节所述，检测一些数据传输错误并执行最小错误恢复。
Data flows through a pair of IP Network connected FCIP_DEs in the following seven steps:
数据通过一对连接FCIP_DEs的IP网络流动，步骤如下：
1) An FC Frame and time stamp arrives at the FC Frame Receiver Portal and is passed to the Encapsulation Engine. The FC Frame is assumed to have been processed by the FC Entity according to the applicable FC rules and is not validated by the FCIP_DE. If the FC Entity is in the Unsynchronized state with respect to a time base as described in the FC Frame Encapsulation [19] specification, the time stamp delivered with the FC Frame SHALL be zero.
1) FC帧和时间戳到达FC帧接收器入口并传递给封装引擎。假设FC帧已由FC实体根据适用的FC规则进行处理，且未经FCIP_DE验证。如果FC实体在FC帧封装[19]规范中描述的时基方面处于非同步状态，则随FC帧交付的时间戳应为零。
2) In the Encapsulation Engine, the encapsulation format described in FC Frame Encapsulation [19] and in section 5.6.1 of this document SHALL be applied to prepare the FC Frame and associated time stamp for transmission over the IP Network.
2) 在封装引擎中，应采用FC帧封装[19]和本文件第5.6.1节中描述的封装格式来准备FC帧和相关时间戳，以便通过IP网络传输。
3) The entire encapsulated FC Frame (a.k.a. the FCIP Frame) SHALL be passed to the Encapsulated Frame Transmitter Portal where it SHALL be inserted in the TCP byte stream.
3) 整个封装的FC帧（也称为FCIP帧）应传递至封装的帧发送器入口，并在此处插入TCP字节流。
4) Transmission of the FCIP Frame over the IP Network follows all the TCP rules of operation. This includes, but is not limited to, the in-order delivery of bytes in the stream, as specified by TCP [6].
4) 通过IP网络传输FCIP帧遵循所有TCP操作规则。这包括但不限于TCP[6]规定的流中字节的顺序传递。
5) The FCIP Frame arrives at the partner FCIP Entity where it enters the FCIP_DE through the Encapsulated Frame Receiver Portal and is passed to the De-Encapsulation Engine for processing.
5) FCIP帧到达合作伙伴FCIP实体，通过封装的帧接收器入口进入FCIP_DE，并传递给反封装引擎进行处理。
6) The De-Encapsulation Engine SHALL validate the incoming TCP byte stream as described in section 5.6.2.2 and SHALL de-encapsulate the FC Frame and associated time stamp according to the encapsulation format described in FC Frame Encapsulation [19] and in section 5.6.1 of this document.
6) 解封装引擎应按照第5.6.2.2节所述验证传入TCP字节流，并根据FC帧封装[19]和本文件第5.6.1节所述的封装格式解封装FC帧和相关时间戳。
7) In the absence of errors, the de-encapsulated FC Frame and time stamp SHALL be passed to the FC Frame Transmitter Portal for delivery to the FC Entity. Error handling is discussed in section 5.6.2.2.
7) 在没有错误的情况下，应将解除封装的FC帧和时间戳传递给FC帧发送器入口，以交付给FC实体。第5.6.2.2节讨论了错误处理。
Every FC Frame that arrives at the FC Frame Receiver Portal SHALL be transmitted on the IP Network as described in steps 1 through 4 above. In the absence of errors, data bytes arriving at the Encapsulated Frame Receiver Portal SHALL be de-encapsulated and forwarded to the FC Frame Transmitter Portal as described in steps 5 through 7.
到达FC帧接收器入口的每个FC帧应在IP网络上传输，如上述步骤1至4所述。在没有错误的情况下，到达封装帧接收器入口的数据字节应按照步骤5至7中所述进行反封装并转发至FC帧发射器入口。
The FCIP encapsulation of FC Frames employs FC Frame Encapsulation [19].
FC帧的FCIP封装采用FC帧封装[19]。
The features from FC Frame Encapsulation that are unique to individual protocols SHALL be applied as follows for the FCIP encapsulation of FC Frames.
对于FC帧的FCIP封装，各个协议特有的FC帧封装特性应按如下方式应用。
The Protocol# field SHALL contain 1 in accordance with the IANA Considerations annex of FC Frame Encapsulation [19].
根据FC帧封装[19]的IANA注意事项附录，协议#字段应包含1。
The Protocol Specific field SHALL have the format shown in figure 7. Note: the word numbers in figure 7 are relative to the complete FC Frame Encapsulation header, not to the Protocol Specific field.
协议特定字段的格式如图7所示。注意：图7中的字号与完整的FC帧封装头相关，而不是与协议特定字段相关。
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------------------------------------------------------+
1| replication of encapsulation word 0 |
+---------------+---------------+---------------+---------------+
2| pFlags | Reserved | -pFlags | -Reserved |
+---------------+---------------+---------------+---------------+
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------------------------------------------------------+
1| replication of encapsulation word 0 |
+---------------+---------------+---------------+---------------+
2| pFlags | Reserved | -pFlags | -Reserved |
+---------------+---------------+---------------+---------------+
Figure 7: FCIP Usage of FC Frame Encapsulation Protocol Specific field
图7:FC帧封装协议特定字段的FCIP使用
Word 1 of the Protocol Specific field SHALL contain an exact copy of word 0 in FC Frame Encapsulation [19].
协议特定字段的字1应包含FC帧封装中字0的精确副本[19]。
The pFlags (protocol specific flags) field provides information about the protocol specific usage of the FC Encapsulation Header. Figure 8 shows the defined pFlags bits.
pFlags（协议特定标志）字段提供有关FC封装头的协议特定用法的信息。图8显示了定义的pFlags位。
|----------------Bit--------------------|
| |
| 0 1 2 3 4 5 6 7 |
+----+-----------------------------+----+
| Ch | Reserved | SF |
+----+-----------------------------+----+
|----------------Bit--------------------|
| |
| 0 1 2 3 4 5 6 7 |
+----+-----------------------------+----+
| Ch | Reserved | SF |
+----+-----------------------------+----+
Figure 8: pFlags Field Bits
图8:pFlags字段位
The SF (Special Frame) bit indicates whether the FCIP Frame is an encapsulated FC Frame or an FSF (FCIP Special Frame, see section 7). When the FCIP Frame contains an encapsulated FC Frame, the SF bit SHALL be 0. When the FCIP Frame is an FSF, the SF bit SHALL be 1.
SF（特殊帧）位表示FCIP帧是封装的FC帧还是FSF（FCIP特殊帧，见第7节）。当FCIP帧包含封装的FC帧时，SF位应为0。当FCIP帧为FSF时，SF位应为1。
The FSF SHALL only be sent as the first bytes transmitted in each direction on a newly formed TCP Connection and only one FSF SHALL be transmitted in each direction at that time (see section 8.1). After that all FCIP Frames SHALL have the SF bit set to 0.
在新形成的TCP连接上，FSF只能作为每个方向上传输的第一个字节发送，此时每个方向上只能传输一个FSF（见第8.1节）。之后，所有FCIP帧的SF位应设置为0。
The Ch (Changed) bit indicates whether an echoed FSF has been intentionally altered (see section 8.1.3). The Ch bit SHALL be 0 unless the FSF bit is 1. When the initial TCP Connection FSF is sent, the Ch bit SHALL be 0. If the recipient of a TCP connect request echoes the FSF without any changes, then the Ch bit SHALL continue to be 0. If the recipient of a TCP connect request alters the FSF before echoing it, then the Ch bit SHALL be changed to 1.
Ch（更改）位表示回声FSF是否被有意更改（见第8.1.3节）。除非FSF位为1，否则Ch位应为0。发送初始TCP连接FSF时，Ch位应为0。如果TCP连接请求的接收者在没有任何更改的情况下回显FSF，则Ch位应继续为0。如果TCP连接请求的接收者在回显前更改了FSF，则Ch位应更改为1。
The -pFlags field SHALL contain the ones complement of the contents of the pFlags field.
-pFlags字段应包含pFlags字段内容的补码。
Table 1 summarizes the usage of the pFlags SF and Ch bits.
表1总结了pFlags SF和Ch位的使用情况。
+----+----+------------+--------------------------------------+
| | | Originated | |
| SF | Ch | or Echoed | Validity/Description |
+----+----+------------+--------------------------------------+
| 0 | 0 | n/a | Encapsulated FC Frame |
+----+----+------------+--------------------------------------+
| 0 | 1 | n/a | Always Illegal |
+----+----+------------+--------------------------------------+
| 1 | 0 | Originated | Originated FSF |
+----+----+------------+--------------------------------------+
| 1 | 1 | Originated | Always Illegal |
+----+----+------------+--------------------------------------+
| 1 | 0 | Echoed | Echoed FSF without changes |
+----+----+------------+--------------------------------------+
| 1 | 1 | Echoed | Echoed FSF with changes |
+----+----+------------+--------------------------------------+
| Note 1: Echoed FSFs may contain changes resulting from |
| transmission errors, necessitating the comparison between |
| sent and received FSF bytes by the FSF originator described |
| in section 8.1.2.3. |
| |
| Note 2: Column positions in this table do not reflect the |
| bit positions of the SF and Ch bits in the pFlags field. |
+-------------------------------------------------------------+
+----+----+------------+--------------------------------------+
| | | Originated | |
| SF | Ch | or Echoed | Validity/Description |
+----+----+------------+--------------------------------------+
| 0 | 0 | n/a | Encapsulated FC Frame |
+----+----+------------+--------------------------------------+
| 0 | 1 | n/a | Always Illegal |
+----+----+------------+--------------------------------------+
| 1 | 0 | Originated | Originated FSF |
+----+----+------------+--------------------------------------+
| 1 | 1 | Originated | Always Illegal |
+----+----+------------+--------------------------------------+
| 1 | 0 | Echoed | Echoed FSF without changes |
+----+----+------------+--------------------------------------+
| 1 | 1 | Echoed | Echoed FSF with changes |
+----+----+------------+--------------------------------------+
| Note 1: Echoed FSFs may contain changes resulting from |
| transmission errors, necessitating the comparison between |
| sent and received FSF bytes by the FSF originator described |
| in section 8.1.2.3. |
| |
| Note 2: Column positions in this table do not reflect the |
| bit positions of the SF and Ch bits in the pFlags field. |
+-------------------------------------------------------------+
Table 1: pFlags SF and Ch bit usage summary
表1:pFlags SF和Ch位使用汇总
The Reserved pFlags bits SHALL be 0.
保留的pFlags位应为0。
The Reserved field (bits 23-16 in word 2): SHALL contain 0.
保留字段（字2中的位23-16）：应包含0。
The -Reserved field (bits 7-0 in word 2): SHALL contain 255 (or 0xFF).
-保留字段（字2中的位7-0）：应包含255（或0xFF）。
The CRCV (CRC Valid) Flag SHALL be set to 0.
CRCV（CRC有效）标志应设置为0。
The CRC field SHALL be set to 0.
CRC字段应设置为0。
In FCIP, the SOF and EOF codes listed as Class 2, Class 3, and Class 4 in the FC Frame Encapsulation [19] are legal.
在FCIP中，FC帧封装[19]中列为Class 2、Class 3和Class 4的SOF和EOF代码是合法的。
TCP [6] requires in order delivery, generation of TCP checksums, and checking of TCP checksums. Thus, the byte stream passed from TCP to the FCIP_LEP will be in order and free of errors detectable by the TCP checksum. The FCIP_LEP relies on TCP to perform these functions.
TCP[6]要求订单交付、生成TCP校验和以及检查TCP校验和。因此，从TCP传递到FCIP_LEP的字节流将是有序的，并且没有TCP校验和检测到的错误。FCIP_LEP依靠TCP来执行这些功能。
Bytes delivered through the Encapsulated Frame Receiver Portal that are not correctly delimited as defined by the FC Frame Encapsulation [19] are considered to be in error.
通过封装的帧接收器入口传送的字节，如果没有按照FC帧封装[19]的定义正确分隔，则视为存在错误。
The failure of the Protocol# and Version fields in the FCIP Frame header to contain the values defined for an FCIP Frame SHALL be considered an error.
FCIP帧头中的协议#和版本字段未能包含为FCIP帧定义的值应视为错误。
Further, some errors in the encapsulation will result in the FCIP_DE losing synchronization with the FC Frames in the byte stream entering through the Encapsulated Frame Receiver Portal.
此外，封装中的一些错误将导致FCIP_DE与通过封装帧接收器入口进入的字节流中的FC帧失去同步。
The Frame Length field in the FC Frame Encapsulation header is used to determine where in the data stream the next FC Encapsulated Header is located. The following tests SHALL be performed to verify synchronization with the byte stream entering the Encapsulated Frame Receiver Portal, and synchronization SHALL be considered lost if any of the tests fail:
FC帧封装报头中的帧长度字段用于确定下一个FC封装报头在数据流中的位置。应执行以下测试，以验证与进入封装帧接收器入口的字节流的同步，如果任何测试失败，则应认为同步丢失：
1) Frame Length field validation -- 15 < Frame Length < 545;
1) Frame Length field validation -- 15 < Frame Length < 545;
2) Comparison of Frame Length field to its ones complement; and
2) 帧长字段与其补码的比较；和
3) A valid EOF is found in the word preceding the start of the next FCIP header as indicated by the Frame Length field, to be tested as follows:
3) 如帧长度字段所示，在下一个FCIP头开始之前的单词中找到有效的EOF，将按如下方式进行测试：
1) Bits 24-31 and 16-23 contain identical legal EOF values (the list of legal EOF values is in the FC Frame Encapsulation [19]); and
1) 位24-31和16-23包含相同的合法EOF值（合法EOF值列表在FC帧封装中[19]）；和
2) Bits 8-15 and 0-7 contain the ones complement of the EOF value found in bits 24-31.
2) 位8-15和0-7包含位24-31中EOF值的1补码。
Note: The range of valid Frame Length values is derived as follows. The FCIP Frame header is seven words, one word each is required for the encoded SOF and EOF values, the FC Frame header is six words, and
注意：有效帧长度值的范围如下所示。FCIP帧头为七个字，编码的SOF和EOF值各需要一个字，FC帧头为六个字，以及
the FC CRC requires one word, yielding a base Frame Length of 16 (7+1+1+6+1) words, if no FC Payload is present. Since the FC Payload is optional, any Frame Length value greater than 15 is valid. The maximum FC Payload size is 528 words, meaning that any Frame Length value up to and including 544 (528+16) is valid.
如果不存在FC有效负载，FC CRC需要一个字，产生16（7+1+1+6+1）个字的基本帧长度。由于FC有效负载是可选的，因此任何大于15的帧长度值都是有效的。最大FC有效负载大小为528个字，这意味着任何小于等于544（528+16）的帧长度值都是有效的。
If synchronization is lost, the FC Frame SHALL NOT be forwarded on to the FC Entity and further recovery SHALL be handled as defined by section 5.6.2.3.
如果同步丢失，则不得将FC帧转发给FC实体，并应按照第5.6.2.3节的规定处理进一步的恢复。
In addition to the tests above, the validity and positioning of the following FCIP Frame information SHOULD be used to detect encapsulation errors that may or may not affect synchronization:
除上述测试外，还应使用以下FCIP帧信息的有效性和定位来检测可能影响或不影响同步的封装错误：
a) Protocol# ones complement field (1 test);
b) Version ones complement field (1 test);
c) Replication of encapsulation word 0 in word 1 (1 test);
d) Reserved field and its ones complement (2 tests);
e) Flags field and its ones complement (2 tests);
f) CRC field is equal to zero (1 test);
g) SOF fields and ones complement fields (4 tests);
h) Format and values of FC header (1 test);
i) CRC of FC Frame (2 tests);
j) FC Frame Encapsulation header information in the next FCIP
Frame (1 test).
a) Protocol# ones complement field (1 test);
b) Version ones complement field (1 test);
c) Replication of encapsulation word 0 in word 1 (1 test);
d) Reserved field and its ones complement (2 tests);
e) Flags field and its ones complement (2 tests);
f) CRC field is equal to zero (1 test);
g) SOF fields and ones complement fields (4 tests);
h) Format and values of FC header (1 test);
i) CRC of FC Frame (2 tests);
j) FC Frame Encapsulation header information in the next FCIP
Frame (1 test).
At least 3 of the 16 tests listed above SHALL be performed. Failure of any of the above tests actually performed SHALL indicate an encapsulation error and the FC Frame SHALL NOT be forwarded on to the FC Entity. Further, such errors SHOULD be considered carefully, since some may be synchronization errors.
应进行上述16项试验中的至少3项。实际执行的任何上述测试失败应表明存在封装错误，且不得将FC帧转发给FC实体。此外，应仔细考虑此类错误，因为其中一些可能是同步错误。
Whenever an FCIP_DE discards bytes delivered through the Encapsulated Frame Receiver Portal, it SHALL cause the FCIP Entity to notify the FC Entity of the condition and provide a suitable description of the reason bytes were discarded.
每当FCIP_DE丢弃通过封装帧接收器入口传送的字节时，它应使FCIP实体通知FC实体该情况，并提供丢弃字节原因的适当说明。
The burden for recovering from discarded data falls on the FC Entity and other components of the FC Fabric, and is outside the scope of this specification.
从丢弃数据中恢复的负担落在FC实体和FC结构的其他组件上，不在本规范的范围内。
If an FCIP_DE determines that it cannot find the next FCIP Frame header in the byte stream entering through the Encapsulated Frame Receiver Portal, the FCIP_DE SHALL do one of the following:
如果FCIP DE确定在通过封装帧接收器入口进入的字节流中找不到下一个FCIP帧头，FCIP DE应执行以下操作之一：
a) close the TCP Connection [6] [7] and notify the FC Entity with the reason for the closure;
a) 关闭TCP连接[6][7]，并通知FC实体关闭的原因；
b) recover synchronization by searching the bytes delivered by the Encapsulated Frame Receiver Portal for a valid FCIP Frame header having the correct properties (see section 5.6.2.2), and discarding bytes delivered by the Encapsulated Frame Receiver Portal until a valid FCIP Frame header is found; or
b) 通过搜索由封装的帧接收器入口交付的字节，寻找具有正确属性的有效FCIP帧头（见第5.6.2.2节），并丢弃由封装的帧接收器入口交付的字节，直到找到有效的FCIP帧头，恢复同步；或
c) attempt to recover synchronization as described in b) and if synchronization cannot be recovered, close the TCP Connection as described in a), including notification of the FC Entity with the reason for the closure.
c) 尝试恢复b）中所述的同步，如果无法恢复同步，请关闭a）中所述的TCP连接，包括通知FC实体关闭原因。
If the FCIP_DE attempts to recover synchronization, the resynchronization algorithm used SHALL meet the following requirements:
如果FCIP_DE试图恢复同步，则使用的重新同步算法应满足以下要求：
a) discard or identify with an EOFa (see appendix section F.1) those FC Frames and fragments of FC Frames identified before synchronization has again been completely verified. The number of FC Frames not forwarded may vary based on the algorithm used;
a) 丢弃或使用EOFa（见附录F.1节）识别同步再次完全验证之前识别的FC帧和FC帧片段。未转发的FC帧的数目可以根据所使用的算法而变化；
b) return to forwarding FC Frames through the FC Frame Transmitter Portal only after synchronization on the transmitted FCIP Frame stream has been verified; and
b) 仅在验证传输的FCIP帧流上的同步后，才返回到通过FC帧发送器入口转发FC帧；和
c) close the TCP/IP connection if the algorithm ends without verifying successful synchronization. The probability of failing to synchronize successfully and the time necessary to determine whether or not synchronization was successful may vary with the algorithm used.
c) 如果算法在未验证同步成功的情况下结束，请关闭TCP/IP连接。无法成功同步的概率以及确定同步是否成功所需的时间可能因所使用的算法而异。
An example algorithm meeting these requirements can be found in appendix D.
满足这些要求的示例算法见附录D。
The burden for recovering from the discarding of FCIP Frames during the optional resynchronization process described in this section falls on the FC Entity and other components of the FC Fabric, and is outside the scope of this specification.
在本节所述的可选重新同步过程中，从FCIP帧丢弃中恢复的负担由FC实体和FC结构的其他组件承担，不在本规范的范围内。
FC-BB-2 [3] defines how the measurement of IP Network transit time is performed, based on the requirements stated in the FC Frame Encapsulation [19] specification. The choice to place this implementation requirement on the FC Entity is based on a desire to include the transit time through the FCIP Entities when computing the IP Network transit time experienced by the FC Frames.
FC-BB-2[3]定义了如何根据FC帧封装[19]规范中规定的要求执行IP网络传输时间的测量。将该实现要求放置在FC实体上的选择基于在计算FC帧经历的IP网络传输时间时包括通过FCIP实体的传输时间的愿望。
Each FC Frame that enters the FCIP_DE through the FC Frame Receiver Portal SHALL be accompanied by a time stamp value that the FCIP_DE SHALL place in the Time Stamp [integer] and Time Stamp [fraction] fields of the encapsulation header of the FCIP Frame that contains the FC Frame. If no synchronized time stamp value is available to accompany the entering FC Frame, a value of zero SHALL be used.
通过FC帧接收器入口进入FCIP_DE的每个FC帧应附有时间戳值，FCIP_DE应将该时间戳值放入包含FC帧的FCIP帧的封装头的时间戳[integer]和时间戳[fraction]字段中。如果输入的FC帧没有同步时间戳值，则应使用零值。
Each FC Frame that exits the FCIP_DE through the FC Frame Transmitter Portal SHALL be accompanied by the time stamp value taken from the FCIP Frame that encapsulated the FC Frame.
通过FC帧发送器入口退出FCIP_DE的每个FC帧应附有从封装FC帧的FCIP帧中获取的时间戳值。
The FC Entity SHALL use suitable internal clocks and either Fibre Channel services or an SNTP Version 4 server [26] to establish and maintain the required synchronized time value. The FC Entity SHALL verify that the FC Entity it is communicating with on an FCIP Link is using the same synchronized time source, either Fibre Channel services or SNTP server.
FC实体应使用适当的内部时钟和光纤通道服务或SNTP版本4服务器[26]来建立和维护所需的同步时间值。FC实体应验证其在FCIP链路上与之通信的FC实体是否使用相同的同步时间源（光纤通道服务或SNTP服务器）。
Note that since the FC Fabric is expected to have a single synchronized time value throughout, reliance on the Fibre Channel services means that only one synchronized time value is needed for all FCIP_DEs regardless of their connection characteristics.
请注意，由于FC结构预计在整个过程中都有一个同步时间值，因此依赖光纤通道服务意味着所有FCIP_de只需要一个同步时间值，而不管它们的连接特征如何。
Figure 9 shows the FSF format.
图9显示了FSF格式。
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------+---------------+---------------+---------------+
0| Protocol# | Version | -Protocol# | -Version |
| (0x01) | (0x01) | (0xFE) | (0xFE) |
+---------------+---------------+---------------+---------------+
1| Protocol# | Version | -Protocol# | -Version |
| (0x01) | (0x01) | (0xFE) | (0xFE) |
+---------------+---------------+---------------+---------------+
2| pFlags | Reserved | -pFlags | -Reserved |
| | (0x00) | | (0xFF) |
+-----------+---+---------------+-----------+---+---------------+
3| Flags | Frame Length | -Flags | -Frame Length |
| (0b000000)| (0b0000010011) | (0b111111)| (0b1111101100) |
+-----------+-------------------+-----------+-------------------+
4| Time Stamp [integer] |
+---------------------------------------------------------------+
5| Time Stamp [fraction] |
+---------------------------------------------------------------+
6| CRC (Reserved in FCIP) |
| (0x00-00-00-00) |
+-------------------------------+-------------------------------+
7| Reserved | -Reserved |
| (0x00-00) | (0xFF-FF) |
+-------------------------------+-------------------------------+
8| |
+----- Source FC Fabric Entity World Wide Name -----+
9| |
+---------------------------------------------------------------+
10| |
+----- Source FC/FCIP Entity Identifier -----+
11| |
+---------------------------------------------------------------+
12| |
+----- Connection Nonce -----+
13| |
+---------------+---------------+-------------------------------+
(Continued)
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------+---------------+---------------+---------------+
0| Protocol# | Version | -Protocol# | -Version |
| (0x01) | (0x01) | (0xFE) | (0xFE) |
+---------------+---------------+---------------+---------------+
1| Protocol# | Version | -Protocol# | -Version |
| (0x01) | (0x01) | (0xFE) | (0xFE) |
+---------------+---------------+---------------+---------------+
2| pFlags | Reserved | -pFlags | -Reserved |
| | (0x00) | | (0xFF) |
+-----------+---+---------------+-----------+---+---------------+
3| Flags | Frame Length | -Flags | -Frame Length |
| (0b000000)| (0b0000010011) | (0b111111)| (0b1111101100) |
+-----------+-------------------+-----------+-------------------+
4| Time Stamp [integer] |
+---------------------------------------------------------------+
5| Time Stamp [fraction] |
+---------------------------------------------------------------+
6| CRC (Reserved in FCIP) |
| (0x00-00-00-00) |
+-------------------------------+-------------------------------+
7| Reserved | -Reserved |
| (0x00-00) | (0xFF-FF) |
+-------------------------------+-------------------------------+
8| |
+----- Source FC Fabric Entity World Wide Name -----+
9| |
+---------------------------------------------------------------+
10| |
+----- Source FC/FCIP Entity Identifier -----+
11| |
+---------------------------------------------------------------+
12| |
+----- Connection Nonce -----+
13| |
+---------------+---------------+-------------------------------+
(Continued)
Figure 9: FSF Format (part 1 of 2)
图9:FSF格式（第1部分，共2部分）
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
| |
| (Concluded) |
+---------------------------------------------------------------+
14| Connection | Reserved | Connection Usage Code |
| Usage Flags | (0x00) | <defined in FC-BB-2> |
+---------------+---------------+-------------------------------+
15| |
+----- Destination FC Fabric Entity World Wide Name -----+
16| |
+---------------------------------------------------------------+
17| K_A_TOV |
+-------------------------------+-------------------------------+
18| Reserved | -Reserved |
| (0x00-00) | (0xFF-FF) |
+-------------------------------+-------------------------------+
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
| |
| (Concluded) |
+---------------------------------------------------------------+
14| Connection | Reserved | Connection Usage Code |
| Usage Flags | (0x00) | <defined in FC-BB-2> |
+---------------+---------------+-------------------------------+
15| |
+----- Destination FC Fabric Entity World Wide Name -----+
16| |
+---------------------------------------------------------------+
17| K_A_TOV |
+-------------------------------+-------------------------------+
18| Reserved | -Reserved |
| (0x00-00) | (0xFF-FF) |
+-------------------------------+-------------------------------+
Figure 9: FSF Format (part 2 of 2)
图9:FSF格式（第2部分，共2部分）
The FSF SHALL only be sent as the first bytes transmitted in each direction on a newly formed TCP Connection, and only one FSF SHALL be transmitted in each direction.
FSF只能作为新形成的TCP连接上每个方向上传输的第一个字节发送，并且每个方向上只能传输一个FSF。
The contents of the FSF SHALL be as described for encapsulated FC Frames, except for the fields described in this section.
FSF的内容应如封装FC帧所述，本节所述字段除外。
All FSFs SHALL have the pFlags SF bit set to 1 (see section 5.6.1).
所有FSF应将pFlags SF位设置为1（见第5.6.1节）。
The Source FC Fabric Entity World Wide Name field SHALL contain the Fibre Channel Name_Identifier [5] for the FC Fabric entity associated with the FC/FCIP Entity pair that generates (as opposed to echoes) the FSF. For example, if the FC Fabric entity is a FC Switch, the FC Fabric Entity World Wide Name field SHALL contain the Switch_Name [4]. The Source FC Fabric Entity World Wide Name SHALL be world wide unique.
源FC结构实体全球通用名称字段应包含与生成FSF（与回声相反）的FC/FCIP实体对关联的FC结构实体的光纤通道名称_标识符[5]。例如，如果FC结构实体是FC交换机，则FC结构实体全球通用名称字段应包含交换机名称[4]。源FC结构实体全球通用名称应为全球唯一名称。
The Source FC/FCIP Entity Identifier field SHALL contain a unique identifier for the FC/FCIP Entity pair that generates (as opposed to echoes) the FSF. The value is assigned by the FC Fabric entity whose world wide name appears in the Source FC Fabric Entity World Wide Name field.
源FC/FCIP实体标识符字段应包含生成（与回波相反）FSF的FC/FCIP实体对的唯一标识符。该值由全球通用名称出现在源FC结构实体全球通用名称字段中的FC结构实体指定。
Note: The combination of the Source FC Entity World Wide Name and Source FC/FCIP Entity Identifier fields uniquely identifies every FC/FCIP Entity pair in the IP Network.
注意：源FC实体全球通用名称和源FC/FCIP实体标识符字段的组合唯一标识IP网络中的每个FC/FCIP实体对。
The Connection Nonce field shall contain a 64-bit random number generated to uniquely identify a single TCP connect request. In order to provide sufficient security for the connection nonce, the Randomness Recommendations for Security [9] SHOULD be followed.
连接Nonce字段应包含生成的64位随机数，以唯一标识单个TCP连接请求。为了为连接提供足够的安全性，应遵循安全性的随机性建议[9]。
The Connection Usage Flags field identifies the types of SOF values [19] to be carried on the connection as shown in figure 10.
Connection Usage Flags字段标识要在连接上执行的SOF值[19]的类型，如图10所示。
|------------------------------Bit------------------------------|
| |
| 0 1 2 3 4 5 6 7 |
+-------+-------+-------+-------+-------------------------------+
| SOFf | SOF?2 | SOF?3 | SOF?4 | Reserved |
+-------+-------+-------+-------+-------------------------------+
|------------------------------Bit------------------------------|
| |
| 0 1 2 3 4 5 6 7 |
+-------+-------+-------+-------+-------------------------------+
| SOFf | SOF?2 | SOF?3 | SOF?4 | Reserved |
+-------+-------+-------+-------+-------------------------------+
Figure 10: Connection Usage Flags Field Format
图10：连接使用标志字段格式
If the SOFf bit is one, then FC Frames containing SOFf are intended to be carried on the connection.
如果SOFf位为1，则包含SOFf的FC帧将在连接上承载。
If the SOF?2 bit is one, then FC Frames containing SOFi2 and SOFn2 are intended to be carried on the connection.
如果SOF？2位为1，则包含SOFi2和SOFn2的FC帧将在连接上承载。
If the SOF?3 bit is one, then FC Frames containing SOFi3 and SOFn3 are intended to be carried on the connection.
如果SOF？3位为1，则包含SOFi3和SOFn3的FC帧将在连接上承载。
If the SOF?4 bit is one, then FC Frames containing SOFi4, SOFn4, and SOFc4 are intended to be carried on the connection.
如果SOF？4位为1，则包含SOFi4、SOFn4和SOFc4的FC帧将在连接上承载。
All or none of the SOFf, SOF?2, SOF?3, and SOF?4 bits MAY be set to one. If all of the SOFf, SOF?2, SOF?3, and SOF?4 bits are zero, then the types of FC Frames intended to be carried on the connection have no specific relationship to the SOF code.
SOFf、SOF？2、SOF？3和SOF？4位中的所有或任何一位都可以设置为一位。如果所有SOFf、SOF？2、SOF？3和SOF？4位均为零，则拟在连接上承载的FC帧类型与SOF代码没有特定关系。
The FCIP Entity SHALL NOT enforce the SOF usage described by the Connection Usage Flags field and SHALL only use the contents of the field as described below.
FCIP实体不得强制执行“连接使用标志”字段所述的SOF使用，只能使用以下字段的内容。
The Connection Usage Code field contains Fibre Channel defined information regarding the intended usage of the connection as specified in FC-BB-2 [3].
Connection Usage Code（连接使用代码）字段包含光纤通道定义的有关FC-BB-2[3]中规定的连接预期使用的信息。
The FCIP Entity SHALL use the contents of the Connection Usage Flags and Connection Usage Code fields to locate appropriate QoS settings in the "shared" database of TCP Connection information (see section 8.1.1) and apply those settings to a newly formed connection.
FCIP实体应使用连接使用标志和连接使用代码字段的内容，在TCP连接信息的“共享”数据库中定位适当的QoS设置（见第8.1.1节），并将这些设置应用于新形成的连接。
The Destination FC Fabric Entity World Wide Name field MAY contain the Fibre Channel Name_Identifier [5] for the FC Fabric entity associated with the FC/FCIP Entity pair that echoes (as opposed to generates) the Special Frame.
目标FC结构实体全球通用名称字段可能包含与回显（而不是生成）特殊帧的FC/FCIP实体对关联的FC结构实体的光纤通道名称_标识符[5]。
The K_A_TOV field SHALL contain the FC Keep Alive Timeout value to be applied to the new TCP Connection as specified in FC-BB-2 [3].
K_A_TOV字段应包含FC-BB-2[3]中规定的应用于新TCP连接的FC保持活动超时值。
For each new incoming TCP connect request and subsequent FSF received, the FCIP Entity SHALL send the contents of the Source FC Fabric Entity World Wide Name, Source FC/FCIP Identifier, Connection Usage Flags and Connection Usage Code fields to the FC Entity along with the other connection information (e.g., FCIP_LEP and FCIP_DE information).
对于收到的每个新传入TCP连接请求和后续FSF，FCIP实体应将源FC结构实体全球通用名称、源FC/FCIP标识符、连接使用标志和连接使用代码字段的内容以及其他连接信息（例如FCIP_LEP和FCIP_DE信息）发送给FC实体。
When a new TCP Connection is established, an FCIP Special Frame makes one round trip from the FCIP Entity initiating the TCP connect operation to the FCIP Entity receiving the TCP connect request and back. This FSF usage serves three functions:
当建立新的TCP连接时，FCIP特殊帧从启动TCP连接操作的FCIP实体到接收TCP连接请求的FCIP实体进行一次往返。使用FSF有三个功能：
- Identification of the FCIP Link endpoints
- FCIP链路端点的标识
- Conveyance of a few critical parameters shared by the FC/FCIP Entity pairs involved in the FCIP Link
- 传输FCIP链路中涉及的FC/FCIP实体对共享的几个关键参数
- Configuration discovery (used in place of SLP only when allowed by site security policies)
- 配置发现（仅当站点安全策略允许时，才用于替代SLP）
The specific format and protocol requirements for this usage of the FSF are found in sections 7.1 and 8.1.2.3. This section provides an overview of the FSF usage without stating requirements.
FSF使用的具体格式和协议要求见第7.1节和第8.1.2.3节。本节概述了FSF的使用，但未说明要求。
Because FCIP is only a tunnel for a Fibre Channel Fabric and because the Fabric has its own complex link setup algorithm that can be employed for many FCIP link setup needs, it is desirable to minimize the complexity of the FSF usage during TCP Connection setup. With this in mind, this FSF usage is not a login or parameter negotiation mechanism. A single FSF transits each newly established TCP connection as the first bytes sent in each direction.
由于FCIP只是光纤通道结构的一个隧道，而且该结构有其自己的复杂链路设置算法，可用于许多FCIP链路设置需要，因此希望在TCP连接设置期间将FSF使用的复杂性降至最低。记住这一点，FSF的使用不是登录或参数协商机制。单个FSF将每个新建立的TCP连接作为每个方向上发送的第一个字节进行传输。
Note: This usage of the FSF cannot be eliminated entirely because a newly created TCP Connection must be associated with the correct FCIP Link before FC Fabric initialization of the connection can commence.
注意：FSF的这种用法不能完全消除，因为新创建的TCP连接必须与正确的FCIP链接相关联，然后才能开始连接的FC结构初始化。
The first bytes sent from the TCP connect request initiator to the receiver are an FSF identifying both the sender and who the sender thinks is the receiver. If the contents of this FSF are correct and acceptable to the receiver, the unchanged FSF is echoed back to the sender. This send/echo process is the only set of actions that allows the TCP Connection to be used to carry FC Fabric traffic. If the send and unchanged echo process does not occur, the algorithm followed at one or both ends of the TCP Connection results in the closure of the TCP Connection (see section 8.1 for specific algorithm requirements).
从TCP连接请求发起方发送到接收方的第一个字节是一个FSF，标识发送方和发送方认为是接收方的人。如果此FSF的内容正确且接收器可接受，则未更改的FSF将回显给发送者。此发送/回送过程是唯一一组允许TCP连接用于承载FC结构流量的操作。如果未发生发送和未更改的回显过程，则TCP连接一端或两端遵循的算法将导致TCP连接关闭（具体算法要求见第8.1节）。
Note: Owing to the limited manner in which the FSF is used and the requirement that the FSF be echoed without changes before a TCP Connection is allowed to carry user data, no error checking beyond that provided by TCP is deemed necessary.
注：由于FSF的使用方式有限，并且要求在允许TCP连接传输用户数据之前，FSF应在不做任何更改的情况下进行回显，因此认为没有必要进行TCP以外的错误检查。
As described above, the primary purpose of the FSF usage during TCP Connection setup is identifying the FCIP Link to which the new TCP Connection belongs. From these beginnings, it is only a small stretch to envision using the FSF as a simplified configuration discovery tool, and the mechanics of such a usage are described in section 8.1.
如上所述，在TCP连接设置期间使用FSF的主要目的是识别新TCP连接所属的FCIP链路。从这些开始，设想使用FSF作为简化的配置发现工具只是一个小小的延伸，第8.1节描述了这种使用的机制。
However, use of the FSF for configuration discovery lacks the broad range of capabilities provided by SLPv2 and most particularly lacks the security capabilities of SLPv2. For these reasons, using the FSF for configuration discovery is not appropriate for all environments. Thus the choice to use the FSF for discovery purposes is a policy choice to be included in the TCP Connection Establishment "shared" database described in section 8.1.1.
然而，使用FSF进行配置发现缺乏SLPv2提供的广泛功能，尤其缺乏SLPv2的安全功能。由于这些原因，使用FSF进行配置发现并不适用于所有环境。因此，选择使用FSF进行查找是一种策略选择，将包含在第8.1.1节所述的TCP连接建立“共享”数据库中。
When FSF-based configuration discovery is enabled, the normal TCP Connection setup rules outlined above are modified as follows.
当启用基于FSF的配置发现时，上面概述的正常TCP连接设置规则将修改如下。
Normally, the algorithm executed by an FCIP Entity receiving an FSF includes verifying that its own identification information in the arriving FSF is correct and closing the TCP Connection if it is not. This can be viewed as requiring the initiator of a TCP connect request to know in advance the identity of the FCIP Entity that is the target of that request (using SLP, for example), and through the FSF effectively saying, "I think I'm talking to X." If the party at the other end of the TCP connect request is really Y, then it simply hangs up.
通常，由接收FSF的FCIP实体执行的算法包括验证到达的FSF中其自身的标识信息是否正确，如果不正确，则关闭TCP连接。这可以被视为要求TCP连接请求的发起人提前知道作为该请求目标的FCIP实体的身份（例如，使用SLP），并通过FSF有效地说：“我想我在和X说话。”如果TCP连接请求的另一端的一方真的是Y，那么它只是挂断。
FSF-based discovery allows the "I think I'm talking to X" to be replaced with "Please tell me who I am talking to?", which is accomplished by replacing an explicit value in the Destination FC Fabric Entity World Wide Name field with zero.
基于FSF的发现允许将“我想我在跟X说话”替换为“请告诉我我在跟谁说话？”，这是通过将目标FC结构实体全球通用名称字段中的显式值替换为零来实现的。
If the policy at the receiving FCIP Entity allows FSF-based discovery, the zero is replaced with the correct Destination FC Fabric Entity World Wide Name value in the echoed FSF. This is still subject to the rules of sending with unchanged echo, and so closure of TCP Connection occurs after the echoed FSF is received by the TCP connect initiator.
如果接收FCIP实体的策略允许基于FSF的发现，则零将替换为回显FSF中正确的目标FC结构实体全球通用名称值。这仍然受未更改回显的发送规则的约束，因此TCP连接启动器收到回显的FSF后会关闭TCP连接。
Despite the TCP Connection closure, however, the TCP connect initiator now knows the correct Destination FC Fabric Entity World Wide Name identity of the FCIP Entity at a given IP Address and a subsequent TCP Connection setup sequence probably will be successful.
尽管TCP连接已关闭，但TCP连接启动器现在知道给定IP地址处FCIP实体的正确目标FC结构实体全球通用名称标识，后续TCP连接设置序列可能会成功。
The Ch bit in the pFlags field (see section 5.6.1) allows for differentiation between changes in the FSF resulting from transmission errors and changes resulting from intentional acts by the FSF recipient.
pFlags字段中的Ch位（见第5.6.1节）允许区分传输错误引起的FSF变化和FSF接收者故意行为引起的变化。
The description of the connection establishment process is a model for the interactions between an FC Entity and an FCIP Entity during TCP Connection establishment. The model is written in terms of a "shared" database that the FCIP Entity consults to determine the properties of the TCP Connections to be formed combined with routine calls to the FC Entity when connections are successfully established. Whether the FC Entity contributes information to the "shared" database is not critical to this model. However, the fact that the FCIP Entity MAY consult the database at any time to determine its actions relative to TCP Connection establishment is important.
连接建立过程的描述是TCP连接建立期间FC实体和FCIP实体之间交互的模型。该模型以FCIP实体参考的“共享”数据库的形式编写，以确定连接成功建立时将与对FC实体的例行调用相结合形成的TCP连接的属性。FC实体是否向“共享”数据库提供信息对该模型并不重要。但是，FCIP实体可以随时查阅数据库以确定其与TCP连接建立相关的操作这一事实很重要。
It is important to remember that this description is only a model for the interactions between an FC Entity and an FCIP Entity. Any implementation that has the same effects on the FC Fabric and IP Network as those described using the model meets the requirements of this specification. For example, an implementation might replace the "shared" database with a routine interface between the FC and FCIP Entities.
请务必记住，此描述仅是FC实体和FCIP实体之间交互的模型。在FC结构和IP网络上具有与使用模型描述的相同效果的任何实现都符合本规范的要求。例如，一个实现可以用FC和FCIP实体之间的例程接口替换“共享”数据库。
When an FCIP Entity discovers that a new TCP Connection needs to be established, it SHALL determine the IP Address to which the TCP Connection is to be made and establish all enabled IP security features for that IP Address as described in section 9. Then the FCIP Entity SHALL determine the following information about the new connection in addition to the IP Address:
当FCIP实体发现需要建立新的TCP连接时，它应确定要建立TCP连接的IP地址，并为该IP地址建立所有启用的IP安全功能，如第9节所述。除IP地址外，FCIP实体还应确定关于新连接的以下信息：
- The expected Destination FC Fabric Entity World Wide Name of the FC/FCIP Entity pair to which the TCP Connection is being made
- 与TCP连接的FC/FCIP实体对的预期目标FC结构实体全球通用名称
- TCP Connection Parameters (see section 8.3)
- TCP连接参数（见第8.3节）
- Quality of Service Information (see section 10)
- 服务质量信息（见第10节）
Based on this information, the FCIP Entity SHALL generate a TCP connect request [6] to the FCIP Well-Known Port of 3225 (or other configuration specific port number) at the specified IP Address.
基于此信息，FCIP实体应在指定IP地址生成一个到FCIP已知端口3225（或其他配置特定端口号）的TCP连接请求[6]。
If the TCP connect request is rejected, the FCIP Entity SHALL act to limit unnecessary repetition of attempts to establish similar connections. For example, the FCIP Entity might wait 60 seconds before trying to re-establish the connection.
如果TCP连接请求被拒绝，FCIP实体应限制不必要的重复尝试以建立类似连接。例如，FCIP实体可能会在尝试重新建立连接之前等待60秒。
If the TCP connect request is accepted, the FCIP Entity SHALL follow the steps described in section 8.1.2.3 to complete the establishment of a new FCIP_DE.
如果TCP连接请求被接受，FCIP实体应按照第8.1.2.3节所述步骤完成新FCIP的建立。
It is RECOMMENDED that an FCIP Entity not initiate TCP connect requests to another FCIP Entity if incoming TCP connect requests from that FCIP Entity have already been accepted.
如果来自另一个FCIP实体的传入TCP连接请求已被接受，建议该FCIP实体不要向该FCIP实体发起TCP连接请求。
If dynamic discovery of participating FCIP Entities is supported, the function SHALL be performed using the Service Location Protocol (SLPv2) [17] in the manner defined for FCIP usage [20].
如果支持参与FCIP实体的动态发现，则应使用服务位置协议（SLPv2）[17]以FCIP使用定义的方式执行该功能[20]。
Upon discovering that dynamic discovery is to be used, the FCIP Entity SHALL enable IP security features for the SLP discovery process as described in [20] and then:
一旦发现要使用动态发现，FCIP实体应按照[20]中所述为SLP发现过程启用IP安全功能，然后：
1) Determine the one or more FCIP Discovery Domain(s) to be used in the dynamic discovery process;
1) 确定要在动态发现过程中使用的一个或多个FCIP发现域；
2) Establish an SLPv2 Service Agent to advertise the availability of this FCIP Entity to peer FCIP Entities in the identified FCIP Discovery Domain(s); and
2) 建立一个SLPv2服务代理，向已识别FCIP发现域中的对等FCIP实体公布此FCIP实体的可用性；和
3) Establish an SLPv2 User Agent to locate service advertisements for peer FCIP Entities in the identified FCIP Discovery Domain(s).
3) 建立SLPv2用户代理，以定位已标识FCIP发现域中对等FCIP实体的服务播发。
For each peer FCIP Entity dynamically discovered through the SLPv2 User Agent, the FCIP Entity SHALL establish all enabled IP security features for the discovered IP Address as described in section 9 and then determine the following information about the new connection:
对于通过SLPv2用户代理动态发现的每个对等FCIP实体，FCIP实体应按照第9节所述为发现的IP地址建立所有启用的IP安全功能，然后确定有关新连接的以下信息：
- The expected Destination FC Fabric Entity World Wide Name of the FC/FCIP Entity pair to which the TCP Connection is being made
- 与TCP连接的FC/FCIP实体对的预期目标FC结构实体全球通用名称
- TCP Connection Parameters (see section 8.3)
- TCP连接参数（见第8.3节）
- Quality of Service Information (see section 10)
- 服务质量信息（见第10节）
Based on this information, the FCIP Entity SHALL generate a TCP connect request [6] to the FCIP Well-Known Port of 3225 (or other configuration specific port number) at the IP Address specified by the service advertisement. If the TCP connect request is rejected, act to limit unnecessary repetition of attempts to establish similar connections. If the TCP connect request is accepted, the FCIP Entity SHALL follow the steps described in section 8.1.2.3 to complete the establishment of a new FCIP_DE.
基于此信息，FCIP实体应在服务公告指定的IP地址处生成到FCIP已知端口3225（或其他配置特定端口号）的TCP连接请求[6]。如果TCP连接请求被拒绝，请采取措施限制尝试建立类似连接的不必要重复。如果TCP连接请求被接受，FCIP实体应按照第8.1.2.3节所述步骤完成新FCIP的建立。
It is recommended that an FCIP Entity not initiate TCP connect requests to another FCIP Entity if incoming TCP connect requests from that FCIP Entity have already been accepted.
如果来自另一个FCIP实体的传入TCP连接请求已被接受，建议该FCIP实体不要向该FCIP实体发起TCP连接请求。
Whether Non-Dynamic TCP Connection creation (see section 8.1.2.1) or Dynamic TCP Connection creation (see section 8.1.2.2) is used, the steps described in this section SHALL be followed to take the TCP Connection setup process to completion.
无论使用非动态TCP连接创建（参见第8.1.2.1节）还是动态TCP连接创建（参见第8.1.2.2节），都应遵循本节中描述的步骤完成TCP连接设置过程。
After the TCP connect request has been accepted, the FCIP Entity SHALL send an FCIP Special Frame (FSF, see section 7) as the first bytes transmitted on the newly formed connection, and retain a copy of those bytes for later comparisons. All fields in the FSF SHALL be filled in as described in section 7, particularly:
TCP连接请求被接受后，FCIP实体应发送一个FCIP特殊帧（FSF，见第7节），作为新形成的连接上传输的第一个字节，并保留这些字节的副本以供以后比较。FSF中的所有字段应按照第7节所述填写，特别是：
- The Source FC Fabric Entity World Wide Name field SHALL contain the FC Fabric Entity World Wide Name for the FC/FCIP Entity pair that is originating the TCP connect request;
- 源FC结构实体全球通用名称字段应包含发起TCP连接请求的FC/FCIP实体对的FC结构实体全球通用名称；
- The Source FC/FCIP Entity Identifier field SHALL contain a unique identifier that is assigned by the FC Fabric entity whose world wide name appears in the Source FC Fabric Entity World Wide Name field;
- 源FC/FCIP实体标识符字段应包含由全球通用名称出现在源FC结构实体全球通用名称字段中的FC结构实体分配的唯一标识符；
- The Connection Nonce field SHALL contain a 64-bit random number that differs in value from any recently used Connection Nonce value. In order to provide sufficient security for the connection nonce, the Randomness Recommendations for Security [9] SHOULD be followed; and
- 连接Nonce字段应包含一个64位随机数，其值与任何最近使用的连接Nonce值不同。为了为连接提供足够的安全性，应遵循安全性的随机性建议[9]；和
- The Destination FC Fabric Entity World Wide Name field SHALL contain 0 or the expected FC Fabric Entity World Wide Name for the FC/FCIP Entity pair whose destination is the TCP connect request.
- 对于目标为TCP连接请求的FC/FCIP实体对，目标FC结构实体全球通用名称字段应包含0或预期的FC结构实体全球通用名称。
After the FSF is sent on the newly formed connection, the FCIP Entity SHALL wait for the FSF to be echoed as the first bytes received on the newly formed connection.
在新形成的连接上发送FSF后，FCIP实体应等待FSF作为新形成的连接上接收到的第一个字节进行回显。
The FCIP Entity MAY apply a timeout of not less than 90 seconds while waiting for the echoed FSF bytes. If the timeout expires, the FCIP Entity SHALL close the TCP Connection and notify the FC Entity with the reason for the closure.
FCIP实体可在等待回显FSF字节时应用不少于90秒的超时。如果超时过期，FCIP实体应关闭TCP连接，并通知FC实体关闭原因。
If the echoed FSF bytes do not exactly match the FSF bytes sent (words 7 through 17 inclusive) or if the echoed Destination FC Fabric Entity World Wide Name field contains zero, the FCIP Entity SHALL close the TCP Connection and notify the FC Entity with the reason for the closure.
如果回显的FSF字节与发送的FSF字节（包括7到17个字）不完全匹配，或者如果回显的目标FC结构实体全球通用名称字段包含零，则FCIP实体应关闭TCP连接，并通知FC实体关闭的原因。
The FCIP Entity SHALL only perform the following steps if the echoed FSF bytes exactly match the FSF bytes sent (words 7 through 17 inclusive).
如果回显的FSF字节与发送的FSF字节完全匹配（包括字7到17），则FCIP实体只能执行以下步骤。
1) Instantiate the appropriate Quality of Service (see section 10) conditions on the newly created TCP Connection,
1) 在新创建的TCP连接上实例化适当的服务质量（参见第10节）条件，
2) If the IP Address and TCP Port to which the TCP Connection was made is not associated with any other FCIP_LEP, create a new FCIP_LEP for the new FCIP Link,
2) 如果TCP连接的IP地址和TCP端口未与任何其他FCIP_LEP关联，请为新FCIP链路创建新FCIP_LEP，
3) Create a new FCIP_DE within the newly created FCIP_LEP to service the new TCP Connection, and
3) 在新创建的FCIP_LEP内创建一个新的FCIP_DE，为新的TCP连接提供服务，以及
4) Inform the FC Entity of the new FCIP_LEP, FCIP_DE, Destination FC Fabric Entity World Wide Name, Connection Usage Flags, and Connection Usage Code.
4) 通知FC实体新的FCIP_LEP、FCIP_DE、目标FC结构实体全球通用名称、连接使用标志和连接使用代码。
The FCIP Entity SHALL listen for new TCP Connection requests [6] on the FCIP Well-Known Port (3225). An FCIP Entity MAY also accept and establish TCP Connections to a TCP port number other than the FCIP Well-Known Port, as configured by the network administrator in a manner outside the scope of this specification.
FCIP实体应侦听FCIP已知端口（3225）上的新TCP连接请求[6]。FCIP实体还可以接受并建立到TCP端口号（FCIP已知端口除外）的TCP连接，该端口号由网络管理员以本规范范围之外的方式配置。
The FCIP Entity SHALL determine the following information about the requested connection:
FCIP实体应确定有关请求连接的以下信息：
- Whether the "shared" database (see section 8.1.1) allows the requested connection
- “共享”数据库（见第8.1.1节）是否允许请求的连接
- Whether IP security setup has been performed for the IP security features enabled on the connection (see section 9)
- 是否对连接上启用的IP安全功能执行了IP安全设置（请参阅第9节）
If the requested connection is not allowed, the FCIP Entity SHALL reject the connect request using appropriate TCP means. If the requested connection is allowed, the FC Entity SHALL ensure that required IP security features are enabled and accept the TCP connect request.
如果不允许请求的连接，FCIP实体应使用适当的TCP方式拒绝连接请求。如果允许请求的连接，FC实体应确保启用所需的IP安全功能，并接受TCP连接请求。
After the TCP connect request has been accepted, the FCIP Entity SHALL wait for the FSF sent by the originator of the TCP connect request (see section 8.1.2) as the first bytes received on the accepted connection.
TCP连接请求被接受后，FCIP实体应等待TCP连接请求的发起人发送的FSF（见第8.1.2节）作为在接受的连接上接收的第一个字节。
The FCIP Entity MAY apply a timeout of no less than 90 seconds while waiting for the FSF bytes. If the timeout expires, the FCIP Entity SHALL close the TCP Connection and notify the FC Entity with the reason for the closure.
FCIP实体在等待FSF字节时可应用不少于90秒的超时。如果超时过期，FCIP实体应关闭TCP连接，并通知FC实体关闭原因。
Note: One method for attacking the security of the FCIP Link formation process (detailed in section 9.1) depends on keeping a TCP connect request open without sending an FSF. Implementations should bear this in mind in the handling of TCP connect requests where the FSF is not sent in a timely manner.
注：攻击FCIP链路形成过程安全性的一种方法（详见第9.1节）取决于在不发送FSF的情况下保持TCP连接请求打开。在处理未及时发送FSF的TCP连接请求时，实现应记住这一点。
Upon receipt of the FSF sent by the originator of the TCP connect request, the FCIP Entity SHALL inspect the contents of the following fields:
收到TCP连接请求发起人发送的FSF后，FCIP实体应检查以下字段的内容：
- Connection Nonce, - Destination FC Fabric Entity World Wide Name, - Connection Usage Flags, and - Connection Usage Code.
- 连接Nonce、-目标FC结构实体全球通用名称、-连接使用标志和-连接使用代码。
If the Connection Nonce field contains a value identical to the most recently received Connection Nonce from the same IP Address, the FCIP Entity SHALL close the TCP Connection and notify the FC Entity with the reason for the closure.
如果Connection Nonce字段包含与最近从同一IP地址收到的连接Nonce相同的值，则FCIP实体应关闭TCP连接，并通知FC实体关闭原因。
If an FCIP Entity receives a duplicate FSF during the FCIP Link formation process, it SHALL close that TCP Connection and notify the FC Entity with the reason for the closure.
如果FCIP实体在FCIP链路形成过程中收到重复的FSF，则应关闭该TCP连接，并通知FC实体关闭的原因。
If the Destination FC Fabric Entity World Wide Name contains 0, the FCIP Entity SHALL take one of the following three actions:
如果目标FC结构实体全球通用名称包含0，则FCIP实体应采取以下三种操作之一：
1) Leave the Destination FC Fabric Entity World Wide Name field and Ch bit both 0;
1) 将目标FC结构实体全球通用名称字段和Ch位都保留为0；
2) Change the Destination FC Fabric Entity World Wide Name field to match FC Fabric Entity World Wide Name associated with the FCIP Entity that received the TCP connect request and change the Ch bit to 1; or
2) 更改目标FC结构实体全球通用名称字段，以匹配与接收TCP连接请求的FCIP实体关联的FC结构实体全球通用名称，并将Ch位更改为1；或
3) Close the TCP Connection without sending any response.
3) 关闭TCP连接而不发送任何响应。
The choice between the above actions depends on the anticipated usage of the FCIP Entity. The FCIP Entity may consult the "shared" database when choosing between the above actions.
上述操作之间的选择取决于FCIP实体的预期用途。FCIP实体在选择上述操作时可查阅“共享”数据库。
If: a) The Destination FC Fabric Entity World Wide Name contains a non-zero value that does not match the FC Fabric Entity World Wide Name associated with the FCIP Entity that received the TCP connect request, or
如果：a）目标FC结构实体全球通用名称包含与接收TCP连接请求的FCIP实体关联的FC结构实体全球通用名称不匹配的非零值，或
b) The contents of the Connection Usage Flags and Connection Usage Code fields is not acceptable to the FCIP Entity that received the TCP connect request, then the FCIP Entity SHALL take one of the following two actions:
b) 接收TCP连接请求的FCIP实体不接受连接使用标志和连接使用代码字段的内容，则FCIP实体应采取以下两种操作之一：
1) Change the contents of the unacceptable fields to correct/ acceptable values and set the Ch bit to 1; or
1) 将不可接受字段的内容更改为正确/可接受值，并将Ch位设置为1；或
2) Close the TCP Connection without sending any response.
2) 关闭TCP连接而不发送任何响应。
If the FCIP Entity makes any changes in the content of the FSF, it SHALL also set the Ch bit to 1.
如果FCIP实体对FSF的内容进行任何更改，它还应将Ch位设置为1。
If any changes have been made in the received FSF during the processing described above, the following steps SHALL be performed:
如果在上述处理过程中收到的FSF发生了任何变化，则应执行以下步骤：
1) The changed FSF SHALL be echoed to the originator of the TCP connect request as the only bytes transmitted on the accepted connection;
1) 更改后的FSF应作为在接受的连接上传输的唯一字节回传给TCP连接请求的发起人；
2) The TCP Connection SHALL be closed (the FC Entity need not be notified of the TCP Connection closure in this case because it is not indicative of an error); and
2) TCP连接应关闭（在这种情况下，不需要通知FC实体TCP连接关闭，因为这并不表示错误）；和
3) All of the additional processing described in this section SHALL be skipped.
3) 应跳过本节中描述的所有附加处理。
The remaining steps in this section SHALL be performed only if the FCIP Entity has not changed the contents of the above mentioned fields to correct/acceptable values.
仅当FCIP实体未将上述字段的内容更改为正确/可接受的值时，才应执行本节中的其余步骤。
If the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier field values in the FSF do not match the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier associated with any other FCIP_LEP, the FCIP Entity SHALL:
如果FSF中的源FC结构实体全球通用名称和源FC/FCIP实体标识符字段值与与与任何其他FCIP_LEP关联的源FC结构实体全球通用名称和源FC/FCIP实体标识符不匹配，则FCIP实体应：
1) Echo the unchanged FSF to the originator of the TCP connect request as the first bytes transmitted on the accepted connection;
1) 将未更改的FSF作为已接受连接上传输的第一个字节回送给TCP连接请求的发起人；
2) Instantiate the appropriate Quality of Service (see section 10.2) conditions on the newly created TCP Connection, considering the Connection Usage Flags and Connection Usage Code fields, and "shared" database information (see section 8.1.1) as appropriate,
2) 在新创建的TCP连接上实例化适当的服务质量（见第10.2节）条件，并酌情考虑连接使用标志和连接使用代码字段以及“共享”数据库信息（见第8.1.1节），
3) Create a new FCIP_LEP for the new FCIP Link,
3) 为新FCIP链路创建新FCIP_LEP，
4) Create a new FCIP_DE within the newly created FCIP_LEP to service the new TCP Connection, and
4) 在新创建的FCIP_LEP内创建一个新的FCIP_DE，为新的TCP连接提供服务，以及
5) Inform the FC Entity of the new FCIP_LEP, FCIP_DE, Source FC Fabric Entity World Wide Name, Source FC/FCIP Entity Identifier, Connection Usage Flags, and Connection Usage Code.
5) 将新FCIP_LEP、FCIP_DE、源FC结构实体全球通用名称、源FC/FCIP实体标识符、连接使用标志和连接使用代码通知FC实体。
If the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier field values in the FCIP Special Frame match the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier associated with an existing FCIP_LEP, the FCIP Entity SHALL:
如果FCIP特殊帧中的源FC结构实体全球通用名称和源FC/FCIP实体标识符字段值与与与现有FCIP_LEP关联的源FC结构实体全球通用名称和源FC/FCIP实体标识符匹配，则FCIP实体应：
1) Request that the FC Entity authenticate the source of the TCP connect request (see FC-BB-2 [3]), providing the following information to the FC Entity for authentication purposes:
1) 请求FC实体验证TCP连接请求的来源（请参阅FC-BB-2[3]），为验证目的向FC实体提供以下信息：
a) Source FC Fabric Entity World Wide Name, b) Source FC/FCIP Entity Identifier, and c) Connection Nonce.
a) 源FC结构实体全球通用名称，b）源FC/FCIP实体标识符，以及c）连接当前值。
The FCIP Entity SHALL NOT use the new TCP Connection for any purpose until the FC Entity authenticates the source of the TCP connect request. If the FC Entity indicates that the TCP connect request cannot be properly authenticated, the FCIP Entity SHALL close the TCP Connection and skip all of the remaining steps in this section.
FCIP实体不得将新TCP连接用于任何目的，除非FC实体验证TCP连接请求的来源。如果FC实体指示TCP连接请求无法正确验证，则FCIP实体应关闭TCP连接并跳过本节剩余的所有步骤。
The definition of the FC Entity SHALL include an authentication mechanism for use in response to a TCP connect request source that communicates with the partner FC/FCIP Entity pair on an existing FCIP Link. This authentication mechanism should use a previously authenticated TCP Connection in the existing FCIP Link to authenticate the Connection Nonce sent in the new TCP Connection setup process. The FCIP Entity SHALL treat failure of this authentication as an authentication failure for the new TCP Connection setup process.
FC实体的定义应包括用于响应TCP连接请求源的认证机制，该TCP连接请求源在现有FCIP链路上与合作伙伴FC/FCIP实体对通信。此身份验证机制应在现有FCIP链路中使用以前经过身份验证的TCP连接，以对新TCP连接设置过程中发送的连接进行身份验证。FCIP实体应将此身份验证失败视为新TCP连接设置过程的身份验证失败。
2) Echo the unchanged FSF to the originator of the TCP connect request as the first bytes transmitted on the accepted connection;
2) 将未更改的FSF作为已接受连接上传输的第一个字节回送给TCP连接请求的发起人；
3) Instantiate the appropriate Quality of Service (see section 10.2) conditions on the newly created TCP Connection, considering the Connection Usage Flags and Connection Usage Code fields, and "shared" database information (see section 8.1.1) as appropriate,
3) 在新创建的TCP连接上实例化适当的服务质量（见第10.2节）条件，并酌情考虑连接使用标志和连接使用代码字段以及“共享”数据库信息（见第8.1.1节），
4) Create a new FCIP_DE within the existing FCIP_LEP to service the new TCP Connection, and
4) 在现有FCIP_LEP内创建一个新FCIP_DE，为新TCP连接提供服务，以及
5) Inform the FC Entity of the FCIP_LEP, Source FC Fabric Entity World Wide Name, Source FC/FCIP Entity Identifier, Connection Usage Flags, Connection Usage Code, and new FCIP_DE.
5) 通知FC实体FCIP\u LEP、源FC结构实体全球通用名称、源FC/FCIP实体标识符、连接使用标志、连接使用代码和新FCIP\u DE。
Note that the originator of TCP connect requests uses the IP Address and TCP Port to identify which TCP Connections belong to which FCIP_LEPs while the recipient of TCP connect requests uses the Source FC Fabric Entity World Wide Name, and Source FC/FCIP Entity Identifier fields from the FSF to identify which TCP Connection belong to which FCIP_LEPs. For this reason, an FCIP Entity that both originates and receives TCP connect requests is unable to match the FCIP_LEPs associated with originated TCP connect requests to the FCIP_LEPs associated with received TCP connect requests.
请注意，TCP connect请求的发起人使用IP地址和TCP端口来标识哪些TCP连接属于哪个FCIP\u LEP，而TCP connect请求的接收方使用源FC结构实体的全球通用名称，以及来自FSF的源FC/FCIP实体标识符字段，以标识哪个TCP连接属于哪个FCIP。因此，发起和接收TCP连接请求的FCIP实体无法将与发起的TCP连接请求关联的FCIP_LEP与与接收的TCP连接请求关联的FCIP_LEP相匹配。
If two FCIP Entities perform simultaneous open operations, then two TCP Connections are formed and the SF originates at one end on one connection and at the other end on the other. Connection setup proceeds as described above on both connections, and the steps described above properly result in the formation of two FCIP Links between the same FCIP Entities.
如果两个FCIP实体同时执行打开操作，则会形成两个TCP连接，SF在一个连接的一端和另一端发起。如上所述，在两个连接上进行连接设置，并且上述步骤正确地导致在相同FCIP实体之间形成两个FCIP链路。
This is not an error. Fibre Channel is perfectly capable of handling two approximately equal connections between FC Fabric elements.
这不是一个错误。光纤通道完全能够处理FC结构元素之间的两个近似相等的连接。
The decision to setup pairs of FCIP Links in this manner is considered to be a site policy decision that can be covered in the "shared" database described in section 8.1.1.
以这种方式设置FCIP链路对的决定被视为站点策略决定，可在第8.1.1节所述的“共享”数据库中涵盖。
The FCIP Entity SHALL provide a mechanism with acknowledgement by which the FC Entity is able to cause the closing of an existing TCP Connection at any time. This allows the FC Entity to close TCP Connections that are producing too many errors, etc.
FCIP实体应提供一种机制，通过该机制，FC实体能够在任何时候关闭现有TCP连接。这允许FC实体关闭产生过多错误等的TCP连接。
In order to provide efficient management of FCIP_LEP resources as well as FCIP Link resources, consideration of certain TCP Connection parameters is recommended.
为了有效管理FCIP_LEP资源以及FCIP链路资源，建议考虑某些TCP连接参数。
The Selective Acknowledgement option RFC 2883 [18] allows the receiver to acknowledge multiple lost packets in a single ACK, enabling faster recovery. An FCIP Entity MAY negotiate use of TCP SACK and use it for faster recovery from lost packets and holes in TCP sequence number space.
选择性确认选项RFC 2883[18]允许接收机在单个ACK中确认多个丢失的数据包，从而实现更快的恢复。FCIP实体可以协商TCP SACK的使用，并使用它从TCP序列号空间中丢失的数据包和漏洞中更快地恢复。
The TCP Window Scale option [8] allows TCP window sizes larger than 16-bit limits to be advertised by the receiver. It is necessary to allow data in long fat networks to fill the available pipe. This also implies buffering on the TCP sender that matches the (bandwidth*delay) product of the TCP Connection. An FCIP_LEP uses locally available mechanisms to set a window size that matches the available local buffer resources and the desired throughput.
TCP窗口缩放选项[8]允许接收器公布大于16位限制的TCP窗口大小。有必要允许长fat网络中的数据填充可用管道。这也意味着TCP发送方上的缓冲与TCP连接的（带宽*延迟）乘积相匹配。FCIP_LEP使用本地可用机制来设置与可用本地缓冲区资源和所需吞吐量相匹配的窗口大小。
It is RECOMMENDED that FCIP Entities implement protection against wrapped sequence numbers PAWS [8]. It is quite possible that within a single connection, TCP sequence numbers wrap within a timeout window.
建议FCIP实体针对包装序列号PAW实施保护[8]。很可能在单个连接中，TCP序列号会在超时窗口内换行。
FCIP Entities should disable the Nagle Algorithm as described in RFC 1122 [7] section 4.2.3.4. By tradition, this can be accomplished by setting the TCP_NODELAY option to one at the local TCP interface.
FCIP实体应禁用RFC 1122[7]第4.2.3.4节所述的Nagle算法。按照传统，这可以通过在本地TCP接口上将TCP_NODELAY选项设置为1来实现。
In idle mode, a TCP Connection "keep alive" option of TCP is normally used to keep a connection alive. However, this timeout is fairly large and may prevent early detection of loss of connectivity. In order to facilitate faster detection of loss of connectivity, FC Entities SHOULD implement some form of Fibre Channel connection failure detection (see FC-BB-2 [3]).
在空闲模式下，TCP的TCP连接“保持活动”选项通常用于保持连接活动。但是，此超时相当大，可能会阻止早期检测到连接丢失。为了便于更快地检测连接丢失，FC实体应实施某种形式的光纤通道连接故障检测（请参阅FC-BB-2[3]）。
When an FCIP Entity discovers that TCP connectivity has been lost, the FCIP Entity SHALL notify the FC Entity of the failure including information about the reason for the failure.
当FCIP实体发现TCP连接已丢失时，FCIP实体应将故障通知FC实体，包括有关故障原因的信息。
The FCIP Entity and FC Entity are connected to the IP Network and FC Fabric, respectively, and they need to follow the flow control mechanisms of both TCP and FC, which work independently of each other.
FCIP实体和FC实体分别连接到IP网络和FC结构，它们需要遵循TCP和FC各自独立工作的流量控制机制。
This section provides guidelines as to how the FCIP Entity can map TCP flow control to status notifications to the FC Entity.
本节提供了有关FCIP实体如何将TCP流控制映射到FC实体的状态通知的指南。
There are two scenarios in which the flow control management becomes crucial:
在两种情况下，流量控制管理变得至关重要：
1) When there is line speed mismatch between the FC and IP interfaces.
1) 当FC和IP接口之间存在线路速度不匹配时。
Even though it is RECOMMENDED that both of the FC and IP interfaces to the FC Entity and FCIP Entity, respectively, be of comparable speeds, it is possible to carry FC traffic over an IP Network that has a different line speed and bit error rate.
即使建议FC实体和FCIP实体的FC和IP接口分别具有可比速度，也可以通过具有不同线路速度和误码率的IP网络承载FC流量。
2) When the FC Fabric or IP Network encounters congestion.
2) 当FC结构或IP网络遇到拥塞时。
Even when both the FC Fabric or IP network are of comparable speeds, during the course of operation, the FC Fabric or the IP Network could encounter congestion due to transient conditions.
即使当FC结构或IP网络的速度相当时，在操作过程中，FC结构或IP网络也可能因瞬态条件而遇到拥塞。
The FC Entity uses Fibre Channel mechanisms for flow control at the FC Frame Receiver Portal based on information supplied by the FCIP Entity regarding flow constraints at the Encapsulated Frame Transmitter Portal. The FCIP Entity uses TCP mechanisms for flow control at the Encapsulated Frame Receiver Portal based on information supplied by the FC Entity regarding flow constraints at the FC Frame Transmitter Portal.
FC实体根据FCIP实体提供的有关封装帧发送器入口的流约束的信息，在FC帧接收器入口使用光纤通道机制进行流控制。FCIP实体基于FC实体提供的有关FC帧发送器入口的流约束的信息，使用TCP机制在封装帧接收器入口进行流控制。
Coordination of these flow control mechanisms, one of which is credit based and the other of which is window based, depends on a painstaking design that is outside the scope of this specification.
这些流控制机制（其中一个基于信用，另一个基于窗口）的协调取决于本规范范围之外的精心设计。
FCIP utilizes the IPsec protocol suite to provide data confidentiality and authentication services, and IKE as the key management protocol. This section describes the requirements for various components of these protocols as used by FCIP, based on FCIP operating environments. Additional consideration for use of IPsec and IKE with the FCIP protocol can be found in [21]. In the event that requirements in [21] conflict with requirements stated in this document, the requirements in this document SHALL prevail.
FCIP利用IPsec协议套件提供数据保密和身份验证服务，IKE作为密钥管理协议。本节描述了FCIP根据FCIP操作环境使用的这些协议的各种组件的要求。在FCIP协议中使用IPsec和IKE的其他注意事项见[21]。如果[21]中的要求与本文件中规定的要求相冲突，应以本文件中的要求为准。
Using a general purpose, wide-area network, such as an IP Network, as a functional replacement for physical cabling introduces some security problems not normally encountered in Fibre Channel Fabrics. FC interconnect cabling is typically protected physically from outside access. Public IP Networks allow hostile parties to impact the security of the transport infrastructure.
使用通用广域网（如IP网络）作为物理布线的功能替代品会带来光纤通道结构中通常不会遇到的一些安全问题。FC互连布线通常受到外部访问的物理保护。公共IP网络允许敌对各方影响运输基础设施的安全。
The general effect is that the security of an FC Fabric is only as good as the security of the entire IP Network that carries the FCIP Links used by that FC Fabric. The following broad classes of attacks are possible:
一般来说，FC结构的安全性仅与承载该FC结构使用的FCIP链路的整个IP网络的安全性相同。可能会发生以下各类攻击：
1) Unauthorized Fibre Channel elements can gain access to resources through normal Fibre Channel Fabric and processes. Although this is a valid threat, securing the Fibre Channel Fabrics is outside the scope of this document. Securing the IP Network is the issue considered in this specification.
1) 未经授权的光纤通道元素可以通过正常的光纤通道结构和进程访问资源。尽管这是一个有效的威胁，但保护光纤通道结构的安全不在本文档的范围之内。保护IP网络是本规范中考虑的问题。
2) Unauthorized agents can monitor and manipulate Fibre Channel traffic flowing over physical media used by the IP Network and accessible to the agent.
2) 未经授权的代理可以监视和操纵流经IP网络使用的物理介质的光纤通道流量，并可供代理访问。
3) TCP Connections may be hijacked and used to instantiate an invalid FCIP Link between two peer FCIP Entities.
3) TCP连接可能被劫持，并用于实例化两个对等FCIP实体之间的无效FCIP链路。
4) Valid and invalid FCIP Frames may be injected on the TCP Connections.
4) 可以在TCP连接上注入有效和无效的FCIP帧。
5) The payload of an FCIP Frame may be altered or transformed. The TCP checksum, FCIP ones complement checks, and FC frame CRC do not protect against this because all of them can be modified or regenerated by a malicious and determined adversary.
5) FCIP帧的有效载荷可以改变或变换。TCP校验和、FCIP ONE补码校验和FC帧CRC不能防止这种情况发生，因为恶意且确定的对手可以修改或重新生成所有这些校验和、FCIP ONE补码校验和FC帧CRC。
6) Unauthorized agents can masquerade as valid FCIP Entities and disturb proper operation of the Fibre Channel Fabric.
6) 未经授权的代理可以伪装为有效的FCIP实体，并干扰光纤通道结构的正常运行。
7) Denial of Service attacks can be mounted by injecting TCP Connection requests and other resource exhaustion operations.
7) 拒绝服务攻击可以通过注入TCP连接请求和其他资源耗尽操作进行。
8) An adversary may launch a variety of attacks against the discovery process [17].
8) 对手可能会对发现过程发起各种攻击[17]。
9) An attacker may exploit the FSF authentication mechanism of the FCIP Link formation process (see section 8.1.3). The attacker could observe the FSF contents sent on an initial connection of an FCIP Link and use the observed nonce, Source FC/FCIP Entity Identifier, and other FSF contents to form an FCIP Link using the attacker's own previously established connection, while resetting/blocking the observed connection. Although the use of timeout for reception of FSF reduces the risk of this attack, such an attack is possible. See section 9.3.1 to protect against this specific attack.
9) 攻击者可利用FCIP链路形成过程的FSF身份验证机制进行攻击（请参阅第8.1.3节）。攻击者可以观察FCIP链路初始连接上发送的FSF内容，并使用观察到的nonce、源FC/FCIP实体标识符和其他FSF内容使用攻击者自己先前建立的连接形成FCIP链路，同时重置/阻止观察到的连接。虽然使用超时接收FSF降低了这种攻击的风险，但这种攻击是可能的。请参见第9.3.1节，以防止这种特定攻击。
The existing IPsec Security Architecture and protocol suite [10] offers protection from these threats. An FCIP Entity MUST implement portions of the IPsec protocol suite as described in this section.
现有的IPsec安全体系结构和协议套件[10]提供了针对这些威胁的保护。FCIP实体必须实现本节所述的IPsec协议套件的部分。
In the context of enabling a secure FCIP tunnel between FC SANs, the following characteristics of the IP Network deployment are useful to note.
在启用FC SAN之间的安全FCIP隧道的上下文中，需要注意IP网络部署的以下特征。
1) The FCIP Entities share a peer-to-peer relationship. Therefore, the administration of security policies applies to all FCIP Entities in an equal manner. This differs from a true Client-Server relationship, where there is an inherent difference in how security policies are administered.
1) FCIP实体共享对等关系。因此，安全策略的管理以平等的方式适用于所有FCIP实体。这与真正的客户机-服务器关系不同，在客户机-服务器关系中，安全策略的管理方式存在固有的差异。
2) Policy administration as well as security deployment and configuration are constrained to the set of FCIP Entities, thereby posing less of a requirement on a scalable mechanism. For example, the validation of credentials can be relaxed to the point where deploying a set of pre-shared keys is a viable technique.
2) 策略管理以及安全部署和配置都限制在一组FCIP实体上，因此对可伸缩机制的要求较少。例如，凭证的验证可以放宽到部署一组预共享密钥是一种可行的技术的程度。
3) TCP Connections and the IP Network are terminated at the FCIP Entity. The granularity of security implementation is at the level of the FCIP tunnel endpoint (or FCIP Entity), unlike other applications where there is a user-level termination of TCP Connections. User-level objects are not controllable by or visible to FCIP Entities. All user-level security related to FCIP is the responsibility of the Fibre Channel standards and is outside the scope of this specification.
3) TCP连接和IP网络在FCIP实体处终止。安全实现的粒度在FCIP隧道端点（或FCIP实体）级别，这与其他存在TCP连接的用户级终止的应用程序不同。FCIP实体无法控制或查看用户级对象。与FCIP相关的所有用户级安全由光纤通道标准负责，不在本规范的范围内。
4) When an FCIP Entity is deployed, its IP addresses will typically be statically assigned. However, support for dynamic IP address assignment, as described in [33], while typically not required, cannot be ruled out.
4) 部署FCIP实体时，通常会静态分配其IP地址。然而，不能排除[33]中所述的对动态IP地址分配的支持，尽管通常不需要这种支持。
FCIP Security compliant implementations MUST implement ESP and the IPsec protocol suite based cryptographic authentication and data integrity [10], as well as confidentiality using algorithms and transforms as described in this section. Also, FCIP implementations MUST meet the secure key management requirements of IPsec protocol suite.
FCIP安全兼容实施必须实现ESP和基于IPsec协议套件的加密身份验证和数据完整性[10]，以及使用本节所述算法和转换的保密性。此外，FCIP实现必须满足IPsec协议套件的安全密钥管理要求。
FCIP Entities MUST implement IPsec ESP [12] in Tunnel Mode for providing Data Integrity and Confidentiality. FCIP Entities MAY implement IPsec ESP in Transport Mode, if deployment considerations require use of Transport Mode. When ESP is utilized, per-packet data origin authentication, integrity, and replay protection MUST be used.
FCIP实体必须在隧道模式下实现IPsec ESP[12]，以提供数据完整性和机密性。如果部署考虑需要使用传输模式，FCIP实体可以在传输模式下实现IPsec ESP。使用ESP时，必须使用每包数据源身份验证、完整性和重播保护。
If Confidentiality is not enabled but Data Integrity is enabled, ESP with NULL Encryption [15] MUST be used.
如果未启用机密性，但已启用数据完整性，则必须使用带空加密的ESP[15]。
IPsec ESP for message authentication computes a cryptographic hash over the payload that is protected. While IPsec ESP mandates compliant implementations to support certain algorithms for deriving this hash, FCIP implementations:
用于消息身份验证的IPsec ESP在受保护的负载上计算加密哈希。虽然IPsec ESP强制要求兼容的实现支持用于派生此哈希的某些算法，但FCIP实现：
- MUST implement HMAC with SHA-1 [11] - SHOULD implement AES in CBC MAC mode with XCBC extensions [23] - DES in CBC mode SHOULD NOT be used due to inherent weaknesses
- 必须使用SHA-1实现HMAC[11]-应使用XCBC扩展实现CBC MAC模式下的AES[23]-由于固有的弱点，不应使用CBC模式下的DES
For ESP Confidentiality, FCIP Entities:
对于ESP保密性，FCIP实体：
- MUST implement 3DES in CBC mode [16] - SHOULD implement AES in CTR mode [22] - MUST implement NULL Encryption [15]
- 必须在CBC模式下实现3DES[16]-应在CTR模式下实现AES[22]-必须实现空加密[15]
FCIP Entities MUST support IKE [14] for peer authentication, negotiation of Security Associations (SA), and Key Management using the IPsec DOI [13]. Manual keying SHALL NOT be used for establishing an SA since it does not provide the necessary elements for rekeying (see section 9.3.3). Conformant FCIP implementations MUST support peer authentication using pre-shared keys and MAY support peer authentication using digital certificates. Peer authentication using public key encryption methods outlined in IKE [14] sections 5.2 and 5.3 SHOULD NOT be used.
FCIP实体必须支持IKE[14]，以便使用IPsec DOI进行对等身份验证、安全关联协商（SA）和密钥管理[13]。手动键控不得用于建立SA，因为它不提供重新键控所需的元素（见第9.3.3节）。一致的FCIP实现必须支持使用预共享密钥的对等身份验证，并且可能支持使用数字证书的对等身份验证。不应使用IKE[14]第5.2和5.3节中概述的使用公钥加密方法的对等身份验证。
IKE Phase 1 establishes a secure, MAC-authenticated channel for communications for use by IKE Phase 2. FCIP implementations MUST support IKE Main Mode and SHOULD support Aggressive Mode.
IKE阶段1为IKE阶段2使用的通信建立一个安全的、MAC认证的信道。FCIP实现必须支持IKE主模式，并应支持主动模式。
IKE Phase 1 exchanges MUST explicitly carry the Identification Payload fields (IDii and IDir). Conformant FCIP implementations MUST use ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6), or ID_FQDN Identification Type values. The ID_USER_FQDN, IP Subnet, IP Address Range, ID_DER_ASN1_DN, and ID_DER_ASN1_GN Identification Type values SHOULD NOT be used. The ID_KEY_ID Identification Type values MUST NOT be used. As described in [13], the port and protocol fields in the Identification Payload MUST be set to zero or UDP port 500.
IKE阶段1交换必须显式地携带标识有效负载字段（IDii和IDir）。一致的FCIP实现必须使用ID\u IPV4\u ADDR、ID\u IPV6\u ADDR（如果协议栈支持IPV6）或ID\u FQDN标识类型值。不应使用ID_USER_FQDN、IP子网、IP地址范围、ID_DER_ASN1_DN和ID_DER_ASN1_GN标识类型值。不得使用ID\u键\u ID标识类型值。如[13]所述，标识有效负载中的端口和协议字段必须设置为零或UDP端口500。
FCIP Entities negotiate parameters for SA during IKE Phase 2 only using "Quick Mode". For FCIP Entities engaged in IKE "Quick Mode", there is no requirement for PFS (Perfect Forward Secrecy). FCIP
FCIP实体在IKE阶段2期间仅使用“快速模式”协商SA的参数。对于参与IKE“快速模式”的FCIP实体，不需要PFS（完美前向保密）。FCIP
implementations MUST use either ID_IPV4_ADDR or ID_IPV6_ADDR Identification Type values (based on the version of IP supported). Other Identification Type values MUST NOT be used.
实现必须使用ID\u IPV4\u ADDR或ID\u IPV6\u ADDR标识类型值（基于支持的IP版本）。不得使用其他标识类型值。
Since the number of Phase 2 SAs may be limited, Phase 2 delete messages may be sent for idle SAs. The receipt of a Phase 2 delete message SHOULD NOT be interpreted as a reason for tearing down an FCIP Link or any of its TCP connections. When there is new activity on that idle link, a new Phase 2 SA MUST be re-established.
由于阶段2 SA的数量可能有限，因此可能会为空闲SA发送阶段2删除消息。收到第2阶段删除消息不应被解释为中断FCIP链路或其任何TCP连接的原因。当该空闲链路上有新活动时，必须重新建立新的阶段2 SA。
For a given pair of FCIP Entities, the same IKE Phase 1 negotiation can be used for all Phase 2 negotiations; i.e., all TCP Connections that are bundled into the single FCIP Link can share the same Phase 1 results.
对于给定的一对FCIP实体，相同的IKE阶段1协商可用于所有阶段2协商；i、 例如，捆绑到单个FCIP链路中的所有TCP连接可以共享相同的第1阶段结果。
Repeated rekeying using "Quick Mode" on the same shared secret will reduce the cryptographic properties of that secret over time. To overcome this, Phase 1 SHOULD be invoked periodically to create a new set of IKE shared secrets and related security parameters.
在同一共享秘密上使用“快速模式”重复密钥更新将随着时间的推移降低该秘密的加密属性。为了克服这一问题，应该定期调用阶段1来创建一组新的IKE共享机密和相关安全参数。
IKE Phase 1 establishment requires the following key distribution and FCIP Entities:
IKE第1阶段建立需要以下密钥分发和FCIP实体：
- MUST support pre-shared IKE keys. - MAY support certificate-based peer authentication using digital signatures. - SHOULD NOT use peer authentication using the public key encryption methods outlined in sections 5.2 and 5.3 of [14].
- 必须支持预共享IKE密钥。-可能支持使用数字签名的基于证书的对等身份验证。-不应使用[14]第5.2节和第5.3节中概述的公钥加密方法进行对等身份验证。
When pre-shared keys are used, IKE Main Mode is usable only when both peers of an FCIP Link use statically assigned IP addresses. When support for dynamically assigned IP Addresses is attempted in conjunction with Main Mode, use of group pre-shared keys would be forced, and the use of group pre-shared keys in combination with Main Mode is not recommended as it exposes the deployed environment to man-in-the-middle attacks. Therefore, if either peer of an FCIP Link uses dynamically assigned addresses, Aggressive Mode SHOULD be used and Main Mode SHOULD NOT be used.
使用预共享密钥时，只有当FCIP链路的两个对等方都使用静态分配的IP地址时，IKE主模式才可用。当尝试结合主模式支持动态分配的IP地址时，将强制使用组预共享密钥，不建议结合主模式使用组预共享密钥，因为这会使部署的环境暴露于中间人攻击。因此，如果FCIP链路的任一对等方使用动态分配的地址，则应使用主动模式，而不应使用主模式。
When Digital Signatures are used, either IKE Main Mode or IKE Aggressive Mode may be used. In all cases, access to locally stored secret information (pre-shared key, or private key for digital signing) MUST be suitably restricted, since compromise of secret information nullifies the security properties of IKE/IPsec protocols. Such mechanisms are outside the scope of this document. Support for IKE Oakley Groups [27] is not required.
当使用数字签名时，可以使用IKE主模式或IKE攻击模式。在所有情况下，必须适当限制对本地存储的机密信息（预共享密钥或用于数字签名的私钥）的访问，因为机密信息的泄露会使IKE/IPsec协议的安全属性无效。这些机制不在本文件的范围之内。不需要支持IKE Oakley Group[27]。
For the purpose of establishing a secure FCIP Link, the two participating FCIP Entities consult a Security Policy Database (SPD). The SPD is described in IPsec [10] Section 4.4.1. FCIP Entities may have more than one interface and IP Address, and it is possible for an FCIP Link to contain multiple TCP connections whose FCIP endpoint IP Addresses are different. In this case, an IKE Phase 1 SA is established for each FCIP endpoint IP Address pair. Within IKE Phase 1, FCIP implementations must support the ID_IPV4_ADDR, ID_IPV6_ADDR (if the protocol stack supports IPv6), and ID_FQDN Identity Payloads. If FCIP Endpoint addresses are dynamically assigned, it may be beneficial to use ID_FQDN, and for this reason, IP_FQDN Identity Payload MUST be supported. Other identity payloads (ID_USER_FQDN, ID_DER_ASN1_GN, ID_KEY_ID) SHOULD NOT be used.
为了建立安全的FCIP链路，两个参与FCIP的实体查阅安全策略数据库（SPD）。IPsec[10]第4.4.1节中描述了SPD。FCIP实体可能有多个接口和IP地址，FCIP链路可能包含多个TCP连接，其FCIP端点IP地址不同。在这种情况下，为每个FCIP端点IP地址对建立IKE阶段1 SA。在IKE阶段1中，FCIP实现必须支持ID_IPV4_ADDR、ID_IPV6_ADDR（如果协议栈支持IPV6）和ID_FQDN标识有效负载。如果FCIP端点地址是动态分配的，则使用ID_FQDN可能是有益的，因此，必须支持IP_FQDN标识有效负载。不应使用其他身份有效载荷（ID\U USER\U FQDN、ID\U DER\U ASN1\U GN、ID\U KEY\U ID）。
At the end of successful IKE negotiations both FCIP Entities store the SA parameters in their SA database (SAD). The SAD is described in IPsec [10] Section 4.4.3. The SAD contains the set of active SA entries, each entry containing Sequence Counter Overflow, Sequence Number Counter, Anti-replay Window, and the Lifetime of the SA. FCIP Entities SHALL employ a default SA Lifetime of one hour and a default Anti-replay window of 32 sequence numbers.
在成功的IKE协商结束时，两个FCIP实体将SA参数存储在其SA数据库（SAD）中。SAD在IPsec[10]第4.4.3节中进行了描述。SAD包含一组活动SA条目，每个条目包含序列计数器溢出、序列号计数器、防重播窗口和SA的生存期。FCIP实体应采用一小时的默认SA生存期和32个序列号的默认防重播窗口。
When a TCP Connection is established between two FCIP_DEs, two unidirectional SAs are created for that connection and each SA is identified in the form of a Security Parameter Index (SPI). One SA is associated with the incoming traffic flow and the other SA is associated with the outgoing traffic flow. The FCIP_DEs at each end of the TCP connection MUST maintain the SPIs for both its incoming and outgoing FCIP Encapsulated Frames.
当在两个FCIP_de之间建立TCP连接时，将为该连接创建两个单向SA，每个SA以安全参数索引（SPI）的形式标识。一个SA与传入业务流关联，另一个SA与传出业务流关联。TCP连接两端的FCIP_DEs必须为其传入和传出FCIP封装帧维护SPI。
FCIP Entities MAY provide administrative management of Confidentiality usage. These management interfaces SHOULD be provided in a secure manner, so as to prevent an attacker from subverting the security process by attacking the management interface.
FCIP实体可提供保密使用的行政管理。这些管理接口应以安全的方式提供，以防止攻击者通过攻击管理接口破坏安全过程。
FCIP Entities MUST implement Replay Protection against ESP Sequence Number wrap, as described in [14]. In addition, based on the cipher algorithm and the number of bits in the cipher block size, the validity of the key may become compromised. In both cases, the SA needs to be re-established.
FCIP实体必须针对ESP序列号换行实施重播保护，如[14]所述。此外，根据密码算法和密码块大小中的位数，密钥的有效性可能会受到影响。在这两种情况下，SA都需要重新建立。
FCIP Entities MUST use the results of IKE Phase 1 negotiation for initiating an IKE Phase 2 "Quick Mode" exchange and establish new SAs.
FCIP实体必须使用IKE第1阶段协商的结果来启动IKE第2阶段“快速模式”交换并建立新SA。
To enable smooth transition of SAs, it is RECOMMENDED that both FCIP Entities refresh the SPI when the sequence number counter reaches 2^31 (i.e., half the sequence number space). It also is RECOMMENDED that the receiver operate with multiple SPIs for the same TCP Connection for a period of 2^31 sequence number packets before aging out an SPI.
为实现SA的平稳过渡，建议两个FCIP实体在序列号计数器达到2^31（即序列号空间的一半）时刷新SPI。还建议接收器在使SPI老化之前，对同一TCP连接使用多个SPI运行2^31个序列号数据包。
When a new SPI is created for the outgoing direction, the sending side SHALL begin using it for all new FCIP Encapsulated Frames. Frames that are either in-flight, or re-sent due to TCP retransmissions, etc. MAY use either the new SPI or the one being replaced.
当为输出方向创建新的SPI时，发送端应开始将其用于所有新的FCIP封装帧。由于TCP重传等原因正在传输或重新发送的帧可以使用新的SPI或被替换的SPI。
FCIP implementations may allow enabling and disabling security mechanisms at the granularity of an FCIP Link. If enabled, the following FCIP Link Initialization steps MUST be followed.
FCIP实现可能允许在FCIP链路的粒度上启用和禁用安全机制。如果启用，则必须遵循以下FCIP链路初始化步骤。
When an FCIP Link is initialized, before any FCIP TCP Connections are established, the local SPD is consulted to determine if IKE Phase 1 has been completed with the FCIP Entity in the peer FCIP Entity, as identified by the WWN.
当FCIP链路初始化时，在建立任何FCIP TCP连接之前，将咨询本地SPD，以确定IKE阶段1是否已完成，对等FCIP实体中的FCIP实体由WWN标识。
If Phase 1 is already completed, IKE Phase 2 proceeds. Otherwise, IKE Phase 1 MUST be completed before IKE Phase 2 can start. Both IKE Phase 1 and Phase 2 transactions use UDP Port 500. If IKE Phase 1 fails, the FCIP Link initialization terminates and notifies the FC entity with the reason for the termination. Otherwise, the FCIP Link initialization moves to TCP Connection Initialization.
如果阶段1已经完成，IKE阶段2将继续。否则，IKE阶段1必须在IKE阶段2开始之前完成。IKE阶段1和阶段2事务都使用UDP端口500。如果IKE阶段1失败，FCIP链路初始化将终止，并通知FC实体终止的原因。否则，FCIP链路初始化将移至TCP连接初始化。
As described in section 8.1, FCIP Entities exchange an FSF for forming an FCIP Link. The use of ESP Confidentiality is an effective countermeasure against any perceived security risks of FSF.
如第8.1节所述，FCIP实体交换FSF以形成FCIP链路。使用ESP保密性是防范FSF任何感知安全风险的有效对策。
Each TCP connection MUST be protected by an IKE Phase 2 SA. Traffic from one or more than one TCP connection may flow within each IPsec Phase 2 SA. While it is possible for an IKE Phase 2 SA to protect multiple TCP connections, all packets of a TCP connection are protected using only one IKE Phase 2 SA.
每个TCP连接必须由IKE阶段2 SA保护。来自一个或多个TCP连接的流量可能在每个IPsec阶段2 SA内流动。虽然IKE阶段2 SA可以保护多个TCP连接，但TCP连接的所有数据包仅使用一个IKE阶段2 SA进行保护。
If different Quality of Service settings are applied to TCP connections, it is advisable to use a different IPsec SA for these connections. Attempting to apply a different quality of service to connections handled by the same IPsec SA can result in reordering, and falling outside the replay window. For additional details, see [21].
如果对TCP连接应用了不同的服务质量设置，建议对这些连接使用不同的IPsec SA。试图对同一IPsec SA处理的连接应用不同的服务质量可能会导致重新排序，并超出重播窗口。有关更多详细信息，请参见[21]。
FCIP implementations need not verify that the IP addresses and port numbers in the packet match any locally stored per-connection values, leaving this check to be performed by the IPsec layer.
FCIP实现不需要验证数据包中的IP地址和端口号是否与本地存储的每个连接的值匹配，将此检查留给IPsec层执行。
An implementation is free to perform several IKE Phase 2 negotiations and cache them in its local SPIs, although entries in such a cache can be flushed per current SA Lifetime settings.
一个实现可以自由地执行几个IKE阶段2协商，并将它们缓存在其本地SPI中，尽管这样的缓存中的条目可以根据当前SA生存期设置刷新。
Upon datagram reception, when the ESP packet fails an integrity check, the receiver MUST drop the datagram, which will trigger TCP retransmission. If many such datagrams are dropped, a receiving FCIP Entity MAY close the TCP Connection and notify the FC Entity with the reason for the closure.
在接收数据报时，当ESP数据包未通过完整性检查时，接收器必须丢弃数据报，这将触发TCP重新传输。如果许多这样的数据报被丢弃，接收FCIP实体可能会关闭TCP连接，并通知FC实体关闭的原因。
An implementation SHOULD follow guidelines for auditing all auditable ESP events per IPsec [10] Section 7.
实施应遵循IPsec[10]第7节规定的审核所有可审核ESP事件的指南。
Integrity checks MUST be performed if Confidentiality is enabled.
如果启用了机密性，则必须执行完整性检查。
Traditionally, the links between FC Fabric components have been characterized by low latency and high throughput. The purpose of FCIP is to provide functionality equivalent to these links using an IP Network, where low latency and high throughput are not as certain. It follows that FCIP Entities and their counterpart FC Entities probably will be interested in optimal use of the IP Network.
传统上，FC结构组件之间的链路具有低延迟和高吞吐量的特点。FCIP的目的是提供与使用IP网络的这些链路等效的功能，在IP网络中，低延迟和高吞吐量是不确定的。因此，FCIP实体及其对应FC实体可能对IP网络的最佳使用感兴趣。
Many options exist for ensuring high throughput and low latency appropriate for the distances involved in an IP Network. For example, a private IP Network might be constructed for the sole use of FCIP Entities. The options that are within the scope of this specification are discussed here.
有许多选项可确保高吞吐量和低延迟，适合IP网络中涉及的距离。例如，可以构建专用IP网络以供FCIP实体单独使用。此处讨论了本规范范围内的选项。
One option for increasing the probability that FCIP data streams will experience low latency and high throughput is the IP QoS techniques discussed in section 10.2. This option can have value when applied
提高FCIP数据流低延迟和高吞吐量概率的一个选择是第10.2节中讨论的IP QoS技术。此选项在应用时可能有价值
to a single TCP Connection. Depending on the sophistication of the FC Entity, further value may be obtained by having multiple TCP Connections with differing QoS characteristics.
到单个TCP连接。根据FC实体的复杂程度，可通过具有具有不同QoS特征的多个TCP连接来获得进一步的价值。
There are many reasons why an FC Entity might request the creation of multiple TCP Connections within an FCIP_LEP. These reasons include a desire to provide differentiated services for different TCP data connections between FCIP_LEPs, or a preference to separately queue different streams of traffic not having a common in-order delivery requirement.
FC实体请求在FCIP_LEP内创建多个TCP连接的原因有很多。这些原因包括希望为FCIP_LEP之间的不同TCP数据连接提供不同的服务，或者倾向于对没有共同顺序交付要求的不同流量单独排队。
At the time a new TCP Connection is created, the FC Entity SHALL specify to the FCIP Entity the QoS characteristics (including but not limited to IP per-hop-behavior) to be used for the lifetime of that connection. This MAY be achieved by having:
在创建新TCP连接时，FC实体应向FCIP实体指定在该连接的生存期内使用的QoS特征（包括但不限于IP每跳行为）。这可以通过以下方式实现：
a) only one set of QoS characteristics for all TCP Connections;
a) 所有TCP连接只有一组QoS特征；
b) a default set of QoS characteristics that the FCIP Entity applies in the absence of differing instructions from the FC Entity; or
b) FCIP实体在没有与FC实体不同的指令的情况下应用的QoS特征的默认集合；或
c) a sophisticated mechanism for exchanging QoS requirements information between the FC Entity and FCIP Entity each time a new TCP Connection is created.
c) 每次创建新TCP连接时，FC实体和FCIP实体之间交换QoS要求信息的复杂机制。
Once established, the QoS characteristics of a TCP Connection SHALL NOT be changed, since this specification provides no mechanism for the FC Entity to control such changes. The mechanism for providing different QoS characteristics in FCIP is the establishment of a different TCP Connections and associated FCIP_DEs.
一旦建立，TCP连接的QoS特征不得改变，因为本规范未提供FC实体控制此类改变的机制。在FCIP中提供不同QoS特征的机制是建立不同的TCP连接和相关的FCIP节点。
When FCIP is used with a network with a large (bandwidth*delay) product, it is RECOMMENDED that FCIP_LEPs use the TCP mechanisms (window scaling and wrapped sequence protection) for Long Fat Networks (LFNs) as defined in RFC 1323 [24].
当FCIP与具有大（带宽*延迟）产品的网络一起使用时，建议FCIP_LEP对RFC 1323[24]中定义的长Fat网络（LFN）使用TCP机制（窗口缩放和包装序列保护）。
Many methods of providing QoS have been devised or proposed. These include (but are not limited to) the following:
已经设计或提出了许多提供QoS的方法。这些包括（但不限于）以下内容：
- Multi-Protocol Label Switching (MPLS) -- RFC 3031 [32] - Differentiated Services Architecture (diffserv) -- RFC 2474 [28], RFC 2475 [29], RFC 2597 [30], and RFC 2598 [31] -- and other forms of per-hop-behavior (PHB) - Integrated Services, RFC 1633 [25] - IEEE 802.1p
- 多协议标签交换（MPLS）——RFC 3031[32]——区分服务体系结构（diffserv）——RFC 2474[28]、RFC 2475[29]、RFC 2597[30]和RFC 2598[31]——以及其他形式的每跳行为（PHB）——集成服务、RFC 1633[25]——IEEE 802.1p
The purpose of this specification is not to specify any particular form of IP QoS, but rather to specify only those issues that must be addressed in order to maximize interoperability between FCIP equipment that has been manufactured by different vendors.
本规范的目的不是指定任何特定形式的IP QoS，而是仅指定必须解决的问题，以最大限度地提高不同供应商生产的FCIP设备之间的互操作性。
It is RECOMMENDED that some form of preferential QoS be used for FCIP traffic to minimize latency and packet drops. No particular form of QoS is recommended.
建议对FCIP流量使用某种形式的优先QoS，以最小化延迟和数据包丢失。不建议使用特定形式的QoS。
If a PHB IP QoS is implemented, it is RECOMMENDED that it interoperate with diffserv (see RFC 2474 [28], RFC 2475 [29], RFC 2597 [30], and RFC 2598 [31]).
如果实现了PHB IP QoS，建议它与diffserv互操作（参见RFC 2474[28]、RFC 2475[29]、RFC 2597[30]和RFC 2598[31]）。
If no form of preferential QoS is implemented, the DSCP field SHOULD be set to '000000' to avoid negative impacts on other network components and services that may be caused by uncontrolled usage of non-zero values of the DSCP field.
如果未实施任何形式的优先QoS，则应将DSCP字段设置为“000000”，以避免不受控制地使用DSCP字段的非零值对其他网络组件和服务造成负面影响。
The references in this section were current as of the time this specification was approved. This specification is intended to operate with newer versions of the referenced documents and looking for newer reference documents is recommended.
本节中的参考文件在本规范获得批准时是最新的。本规范适用于较新版本的参考文件，建议寻找较新的参考文件。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Fibre Channel Backbone (FC-BB), ANSI INCITS.342:2001, December 12, 2001.
[2] 光纤通道主干网（FC-BB），ANSI INCITS.342:2001，2001年12月12日。
[3] Fibre Channel Backbone -2 (FC-BB-2), ANSI INCITS.372:2003, July 25, 2003.
[3] 光纤通道主干网-2（FC-BB-2），ANSI INCITS.372:2003，2003年7月25日。
[4] Fibre Channel Switch Fabric -2 (FC-SW-2), ANSI INCITS.355:2001, December 12, 2001.
[4] 光纤通道交换结构-2（FC-SW-2），ANSI INCITS.355:2001，2001年12月12日。
[5] Fibre Channel Framing and Signaling (FC-FS), ANSI INCITS.373:2003, October 27, 2003.
[5] 光纤通道成帧和信令（FC-FS），ANSI INCITS.373:2003，2003年10月27日。
[6] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[6] 《传输控制协议》，标准7，RFC 793，1981年9月。
[7] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[7] Braden，R.，“互联网主机的要求——通信层”，STD 3，RFC 1122，1989年10月。
[8] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[8] Jacobson，V.，Braden，R.和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[9] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[9] Eastlake，D.，Crocker，S.和J.Schiller，“安全性的随机性建议”，RFC 1750，1994年12月。
[10] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[10] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[11] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997.
[11] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控-哈希”，RFC2104，1997年2月。
[12] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[12] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[13] Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998.
[13] Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[14] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[14] Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[15] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[15] Glenn，R.和S.Kent，“空加密算法及其在IPsec中的使用”，RFC 2410，1998年11月。
[16] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[16] Pereira，R.和R.Adams，“ESP CBC模式密码算法”，RFC 2451，1998年11月。
[17] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, version 2", RFC 2608, July 1999.
[17] Guttman，E.，Perkins，C.，Veizades，J.和M.Day，“服务位置协议，版本2”，RFC 26081999年7月。
[18] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "SACK Extension", RFC 2883, July 2000.
[18] Floyd，S.，Mahdavi，J.，Mathis，M.和M.Podolsky，“SACK扩展”，RFC 28832000年7月。
[19] Weber, R., Rajagopal, M., Travostino, F., O'Donnell, M., Monia, C. and M. Merhar, "Fibre Channel (FC) Frame Encapsulation", RFC 3643, December 2003.
[19] 韦伯，R.，拉贾戈帕尔，M.，特拉沃斯蒂诺，F.，O'Donnell，M.，莫尼亚，C.和M.梅哈尔，“光纤通道（FC）帧封装”，RFC 36432003年12月。
[20] Peterson, D., "Finding Fibre Channel over TCP/IP (FCIP) Entities Using Service Location Protocol version 2 (SLPv2)", RFC 3822, July 2004.
[20] Peterson，D.，“使用服务位置协议版本2（SLPv2）查找TCP/IP（FCIP）上的光纤通道实体”，RFC 3822，2004年7月。
[21] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[21] Aboba，B.，Tseng，J.，Walker，J.，Rangan，V.和F.Travostino，“通过IP保护块存储协议”，RFC 37232004年4月。
[22] Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003.
[22] Frankel，S.，Glenn，R.和S.Kelly，“AES-CBC密码算法及其在IPsec中的使用”，RFC 3602，2003年9月。
[23] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[23] Frankel，S.和H.Herbert，“AES-XCBC-MAC-96算法及其在IPsec中的使用”，RFC 3566，2003年9月。
[24] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[24] Jacobson，V.，Braden，R.和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[25] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[25] Braden，R.，Clark，D.和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC16331994年6月。
[26] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[26] Mills，D.，“IPv4、IPv6和OSI的简单网络时间协议（SNTP）第4版”，RFC 2030，1996年10月。
[27] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998.
[27] Orman，H.，“奥克利密钥确定协议”，RFC 2412，1998年11月。
[28] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and Ipv6 Headers", RFC 2474, December 1998.
[28] Nichols，K.，Blake，S.，Baker，F.和D.Black，“IPv4和Ipv6标头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[29] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[29] Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[30] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "An Assured Forwarding PHB", RFC 2597, June 1999.
[30] Heinanen，J.，Baker，F.，Weiss，W.和J.Wroclawski，“有保证的货运PHB”，RFC 25971999年6月。
[31] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB Group", RFC 2598, June 1999.
[31] Jacobson，V.，Nichols，K.和K.Poduri，“一个快速转发PHB组”，RFC 2598，1999年6月。
[32] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January, 2001.
[32] Rosen，E.，Viswanathan，A.和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[33] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003.
[33] Patel，B.，Aboba，B.，Kelly，S.和V.Gupta，“IPsec隧道模式的动态主机配置协议（DHCPv4）配置”，RFC 3456，2003年1月。
[34] Kembel, R., "The Fibre Channel Consultant: A Comprehensive Introduction", Northwest Learning Associates, 1998.
[34] Kembel，R.，“光纤通道顾问：全面介绍”，西北学习协会，1998年。
The developers of this specification thank Mr. Jim Nelson for his assistance with FC-FS related issues.
本规范的开发人员感谢Jim Nelson先生对FC-FS相关问题的帮助。
The developers of this specification express their appreciation to Mr. Mallikarjun Chadalapaka and Mr. David Black for their detailed and helpful reviews.
本规范的开发人员对Mallikarjun Chadalapaka先生和David Black先生的详细和有用的评论表示感谢。
Appendix A - Fibre Channel Bit and Byte Numbering Guidance
附录A-光纤通道位和字节编号指南
Both Fibre Channel and IETF standards use the same byte transmission order. However, the bit and byte numbering is different.
光纤通道和IETF标准都使用相同的字节传输顺序。但是，位和字节编号是不同的。
Fibre Channel bit and byte numbering can be observed if the data structure heading, shown in figure 11, is cut and pasted at the top of figure 7, figure 9, and figure 17.
如果将图11所示的数据结构标题剪切并粘贴在图7、图9和图17的顶部，则可以观察到光纤通道位和字节编号。
W|------------------------------Bit------------------------------|
o| |
r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 |
d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0|
W|------------------------------Bit------------------------------|
o| |
r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 |
d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0|
Figure 11: Fibre Channel Data Structure Bit and Byte Numbering
图11：光纤通道数据结构位和字节编号
Fibre Channel bit numbering for the pFlags field can be observed if the data structure heading, shown in figure 12, is cut and pasted at the top of figure 8.
如果在图8顶部剪切并粘贴数据结构标题（如图12所示），则可以观察到pFlags字段的光纤通道位编号。
|----------------Bit--------------------|
| |
| 31 30 29 28 27 26 25 24 |
|----------------Bit--------------------|
| |
| 31 30 29 28 27 26 25 24 |
Figure 12: Fibre Channel pFlags Bit Numbering
图12：光纤通道pFlags位编号
Fibre Channel bit numbering for the Connection Usage Flags field can be observed if the data structure heading, shown in figure 13, is cut and pasted at the top of figure 10.
如果将图13所示的数据结构标题剪切并粘贴到图10的顶部，则可以观察到Connection Usage Flags字段的光纤通道位编号。
|------------------------------Bit------------------------------|
| |
| 31 30 29 28 27 26 25 24 |
|------------------------------Bit------------------------------|
| |
| 31 30 29 28 27 26 25 24 |
Figure 13: Fibre Channel Connection Usage Flags Bit Numbering
图13：光纤通道连接使用标志位编号
Appendix B - IANA Considerations
附录B-IANA注意事项
IANA has made the following port assignments to FCIP:
IANA已将以下端口分配给FCIP：
- fcip-port 3225/tcp FCIP - fcip-port 3225/udp FCIP
- fcip端口3225/tcp fcip-fcip端口3225/udp fcip
IANA has changed the authority for these port allocations to reference this RFC.
IANA已将这些端口分配的权限更改为引用此RFC。
Use of UDP with FCIP is prohibited even though IANA has allocated a port.
即使IANA已分配端口，也禁止将UDP与FCIP一起使用。
The FC Frame encapsulation used by this specification employs Protocol# value 1, as described in the IANA Considerations appendix of the FC Frame Encapsulation [19] specification.
本规范使用的FC帧封装采用协议#值1，如FC帧封装[19]规范的IANA注意事项附录所述。
Appendix C - FCIP Usage of Addresses and Identifiers
附录C-地址和标识符的FCIP使用
In support of network address translators, FCIP does not use IP Addresses to identify FCIP Entities or FCIP_LEPs. The only use of IP Addresses for identification occurs when initiating new TCP connect requests (see section 8.1.2.3) where the IP Address destination of the TCP connect request is used to answer the question: "Have previous TCP connect requests been made to the same destination FCIP Entity?" The correctness of this assumption is further checked by sending the Destination FC Fabric Entity World Wide Name in the FCIP Special Frame (FSF) and having the value checked by the FCIP Entity that receives the TCP connect request and FSF (see section 8.1.3).
为了支持网络地址转换器，FCIP不使用IP地址来标识FCIP实体或FCIP_LEP。只有在启动新的TCP连接请求（见第8.1.2.3节）时，才会使用IP地址进行标识，其中TCP连接请求的IP地址目标用于回答以下问题：“以前的TCP连接请求是否已发送到相同的目标FCIP实体？”通过在FCIP特殊帧（FSF）中发送目标FC结构实体全球通用名称，并由接收TCP连接请求和FSF的FCIP实体检查该值，进一步检查该假设的正确性（参见第8.1.3节）。
For the purposes of processing incoming TCP connect requests, the source FCIP Entity is identified by the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier fields in the FSF sent from the TCP connect requestor to the TCP connect recipient as the first bytes following the TCP connect request (see section 8.1.2.3 and section 8.1.3).
为了处理传入的TCP连接请求，源FCIP实体由TCP连接请求者发送给TCP连接接收者的FSF中的源FC结构实体全球通用名称和源FC/FCIP实体标识符字段标识为TCP连接请求后的第一个字节（见第8.1.2.3节和第8.1.3节）。
FC-BB-2 [3] provides the definitions for each of the following FSF fields:
FC-BB-2[3]提供了以下每个FSF字段的定义：
- Source FC Fabric Entity World Wide Name, - Source FC/FCIP Entity Identifier, and - Destination FC Fabric Entity World Wide Name.
- 源FC结构实体全球通用名称、-源FC/FCIP实体标识符和-目标FC结构实体全球通用名称。
As described in section 8.1.3, FCIP Entities segregate their FCIP_LEPs between:
如第8.1.3节所述，FCIP实体将其FCIP_LEP划分为：
- Connections resulting from TCP connect requests initiated by the FCIP Entity, and
- 由FCIP实体发起的TCP连接请求产生的连接，以及
- Connections resulting from TCP connect requests received by the FCIP Entity.
- 由FCIP实体接收的TCP连接请求产生的连接。
Within each of these two groups, the following information is used to further identify each FCIP_LEP:
在这两组中，以下信息用于进一步识别每个FCIP_LEP：
- Source FC Fabric Entity World Wide Name, - Source FC/FCIP Entity Identifier, and - Destination FC Fabric Entity World Wide Name.
- 源FC结构实体全球通用名称、-源FC/FCIP实体标识符和-目标FC结构实体全球通用名称。
Appendix D - Example of Synchronization Recovery Algorithm
附录D-同步恢复算法示例
The contents of this annex are informative.
本附件的内容仅供参考。
Synchronization may be recovered as specified in section 5.6.2.3. An example of an algorithm for searching the bytes delivered to the Encapsulated Frame Receiver Portal for a valid FCIP Frame header is provided in this annex.
可按照第5.6.2.3节的规定恢复同步。本附录中提供了一个算法示例，该算法用于搜索发送至封装帧接收器入口的字节，以获得有效的FCIP帧头。
This resynchronization uses the principle that a valid FCIP data stream must contain at least one valid header every 2176 bytes (the maximum length of an encapsulated FC Frame). Although other data patterns containing apparently valid headers may be contained in the stream, the FC CRC or FCIP Frame validity of the data patterns contained in the data stream will always be either interrupted by or resynchronized with the valid FCIP Frame headers.
此重新同步使用以下原则：有效FCIP数据流必须每2176字节（封装FC帧的最大长度）至少包含一个有效标头。尽管流中可能包含包含明显有效的报头的其他数据模式，但数据流中包含的数据模式的FC CRC或FCIP帧有效性将始终被有效的FCIP帧报头中断或与之重新同步。
Consider the case shown in figure 14. A series of short FCIP Frames, perhaps from a trace, are embedded in larger FCIP Frames, say as a result of a trace file being transferred from one disk to another. The headers for the short FCIP Frames are denoted SFH and the long FCIP Frame headers are marked as LFH.
考虑图14中所示的情况。一系列短FCIP帧（可能来自跟踪）嵌入在较大的FCIP帧中，例如跟踪文件从一个磁盘传输到另一个磁盘。短FCIP帧的头表示为SFH，长FCIP帧头标记为LFH。
+-+--+-+----+-+----+-+----+-+-+-+---+-+---
|L| |S| |S| |S| |S| |L| |S|
|F| |F| |F| |F| |F| |F| |F|...
|H| |H| |H| |H| |H| |H| |H|
+-+--+-+----+-+----+-+----+-+-+-+---+-+---
| |
|<---------2176 bytes-------->|
+-+--+-+----+-+----+-+----+-+-+-+---+-+---
|L| |S| |S| |S| |S| |L| |S|
|F| |F| |F| |F| |F| |F| |F|...
|H| |H| |H| |H| |H| |H| |H|
+-+--+-+----+-+----+-+----+-+-+-+---+-+---
| |
|<---------2176 bytes-------->|
Figure 14: Example of resynchronization data stream
图14：重新同步数据流的示例
A resynchronization attempt that starts just to the right of an LFH will find several SFH FCIP Frames before discovering that they do not represent the transmitted stream of FCIP Frames. Within 2176 bytes plus or minus, however, the resynchronization attempt will encounter an SFH whose length does not match up with the next SFH because the LFH will fall in the middle of the short FCIP Frame pushing the next header farther out in the byte stream.
仅从LFH右侧开始的重新同步尝试将在发现几个SFH FCIP帧不代表FCIP帧的传输流之前找到它们。然而，在2176字节加或减的情况下，重新同步尝试将遇到SFH，其长度与下一SFH不匹配，因为LFH将落在短FCIP帧的中间，将下一个报头进一步推送到字节流中。
Note that the resynchronization algorithm cannot forward any prospective FC Frames to the FC Frame Transmitter Portal because, until synchronization is completely established, there is no certainty that anything that looked like an FCIP Frame really was one. For example, an SFH might fortuitously contain a length that
请注意，重新同步算法无法将任何预期的FC帧转发到FC帧发送器入口，因为在完全建立同步之前，无法确定看起来像FCIP帧的任何帧是否真的是FCIP帧。例如，SFH可能偶然包含以下长度：
points exactly to the beginning of an LFH. The LFH would identify the correct beginning of a transmitted FCIP Frame, but that in no way guarantees that the SFH was also a correct FCIP Frame header.
精确指向LFH的开始。LFH将识别传输的FCIP帧的正确开始，但这不能保证SFH也是正确的FCIP帧头。
There exist some data streams that cannot be resynchronized by this algorithm. If such a data stream is encountered, the algorithm causes the TCP Connection to be closed.
存在一些无法通过此算法重新同步的数据流。如果遇到这样的数据流，算法会导致TCP连接关闭。
The resynchronization assumes that security and authentication procedures outside the FCIP Entity are protecting the valid data stream from being replaced by an intruding data stream containing valid FCIP data.
重新同步假定FCIP实体之外的安全和身份验证过程正在保护有效数据流，使其不会被包含有效FCIP数据的入侵数据流替换。
The following steps are one example of how an FCIP_DE might resynchronize with the data stream entering the Encapsulated Frame Receiver Portal.
以下步骤是FCIP_DE如何与进入封装帧接收器入口的数据流重新同步的一个示例。
1) Search for candidate and strong headers:
1) 搜索候选标题和强标题：
The data stream entering the Encapsulated Frame Receiver Portal is searched for 12 bytes in a row containing the required values for:
在包含以下所需值的行中搜索进入封装帧接收器入口的数据流12个字节：
a) Protocol field, b) Version field, c) ones complement of the Protocol field, d) ones complement of the Version field, e) replication of encapsulation word 0 in word 1, and f) pFlags field and its ones complement.
a) 协议字段，b）版本字段，c）协议字段的一个补码，d）版本字段的一个补码，e）在字1中复制封装字0，以及f）pFlags字段及其一个补码。
If such a 12-byte grouping is found, the FCIP_DE assumes that it has identified bytes 0-2 of a candidate FCIP encapsulation header.
如果发现这样一个12字节的分组，则FCIP_DE假定它已识别候选FCIP封装头的字节0-2。
All bytes up to and including the candidate header byte are discarded.
所有小于或包括候选标头字节的字节都将被丢弃。
If no candidate header has been found after searching a specified number of bytes greater than some multiple of 2176 (the maximum length of an FCIP Frame), resynchronization has failed and the TCP/IP connection is closed.
如果在搜索大于2176的某个倍数（FCIP帧的最大长度）的指定字节数后未找到候选标头，则重新同步失败，TCP/IP连接关闭。
Word 3 of the candidate header contains the Frame Length and Flags fields and their ones complements. If the fields are consistent with their ones complements, the candidate header is considered a strong candidate header. The Frame Length field is used to determine where in the byte stream the next strong candidate header should be and processing continues at step 2).
候选标题的单词3包含帧长度和标志字段及其补充字段。如果字段与其补充字段一致，则候选标头被视为强候选标头。帧长度字段用于确定下一个强候选报头应该在字节流中的何处，处理将在步骤2）继续。
2) Use multiple strong candidate headers to locate a verified candidate header:
2) 使用多个强候选标头定位已验证的候选标头：
The Frame Length in one strong candidate header is used to skip incoming bytes until the expected location of the next strong candidate header is reached. Then the tests described in step 1) are applied to see if another strong candidate header has successfully been located.
一个强候选报头中的帧长度用于跳过传入字节，直到到达下一个强候选报头的预期位置。然后应用步骤1）中描述的测试，以查看是否已成功找到另一个强候选标头。
All bytes skipped and all bytes in all strong candidate headers processed are discarded.
跳过所有字节，并丢弃处理的所有强候选标头中的所有字节。
Strong candidate headers continue to be verified in this way for at least 4352 bytes (twice the maximum length of an FCIP Frame). If at any time a verification test fails, processing restarts at step 1 and a retry counter is incremented. If the retry counter exceeds 3 retries, resynchronization has failed and the TCP Connection is closed, and the FC entity is notified with the reason for the closure.
强候选头继续以这种方式验证至少4352字节（FCIP帧最大长度的两倍）。如果在任何时候验证测试失败，处理将在步骤1重新启动，重试计数器将递增。如果重试计数器超过3次重试，则重新同步失败，TCP连接关闭，并通知FC实体关闭原因。
After strong candidate headers have been verified for at least 4352 bytes, the next header identified is a verified candidate header, and processing continues at step 3).
在验证强候选报头至少4352字节后，标识的下一个报头是已验证的候选报头，处理在步骤3）继续。
Note: If a strong candidate header was part of the data content of an FCIP Frame, the FCIP Frame defined by that or a subsequent strong candidate header will eventually cross an actual header in the byte stream. As a result it will either identify the actual header as a strong candidate header or it will lose synchronization again because of the extra 28 bytes in the length, returning to step 1 as described above.
注意：如果强候选报头是FCIP帧数据内容的一部分，则由该报头或后续强候选报头定义的FCIP帧最终将与字节流中的实际报头交叉。因此，它要么将实际报头识别为强候选报头，要么由于长度中额外的28字节，它将再次失去同步，返回到如上所述的步骤1。
3) Use multiple strong candidate headers to locate a verified candidate header:
3) 使用多个强候选标头定位已验证的候选标头：
Incoming bytes are inspected and discarded until the next verified candidate header is reached. Inspection of the incoming bytes includes testing for other candidate headers using the criteria described in step 1. Each verified candidate header is tested against the tests listed in section 5.6.2.2 as would normally be the case.
在到达下一个已验证的候选标头之前，将检查并丢弃传入字节。对传入字节的检查包括使用步骤1中描述的标准测试其他候选头。按照第5.6.2.2节中列出的测试，对每个经验证的候选标题进行测试，通常情况下也是如此。
Verified candidate headers continue to be located and tested in this way for a minimum of 4352 bytes (twice the maximum length of an FCIP Frame). If all verified candidate headers encountered are valid, the last verified candidate header is a valid header. At this point the FCIP_DE stops discarding bytes and begins normal
经过验证的候选报头将继续以这种方式定位和测试至少4352字节（FCIP帧最大长度的两倍）。如果遇到的所有已验证的候选标头均有效，则最后一个已验证的候选标头为有效标头。此时，FCIP_DE停止丢弃字节并开始正常运行
FCIP de-encapsulation, including for the first time since synchronization was lost, delivery of FC Frames through the FC Frame Transmitter Portal according to normal FCIP rules.
FCIP解除封装，包括自同步丢失以来第一次根据正常FCIP规则通过FC帧发送器入口传送FC帧。
If any verified candidate headers are invalid but meet all the requirements of a strong candidate header, increment the retry counter and return to step 2). If any verified candidate headers are invalid and fail to meet the tests for a strong candidate header, or if inspection of the bytes between verified candidate headers discovers any candidate headers, increment the retry counter and return to step 1. If the retry counter exceeds 4 retries, resynchronization has failed and the TCP/IP connection is closed.
如果任何已验证的候选标头无效，但满足强候选标头的所有要求，请增加重试计数器并返回步骤2）。如果任何已验证的候选标头无效且无法满足强候选标头的测试，或者如果已验证的候选标头之间的字节检查发现任何候选标头，则增加重试计数器并返回步骤1。如果重试计数器超过4次重试，则重新同步失败，TCP/IP连接关闭。
A flowchart for this algorithm can be found in figure 15.
该算法的流程图如图15所示。
Synchronization is lost
|
_____________v_______________
| |
| Search for candidate header |
+----------->| |
| | Found Not Found |
| | (Strong candidate) |
| |_____________________________|
| | |
| | + --------->close TCP
| _______v_____________________ Connection
| | | and notify
| | Enough strong candidate | the FC Entity
| +---->| headers identified? | with the reason
| | | | for closure
| | | No Yes |
| | | (Verified candidate) |
| | |_____________________________|
|___________________| |
^ | |
| | |
| | _______________________v_____
| | | |
| | | Enough verified candidate |
| | | headers validated? |
| | | |
| | | No Yes |
| | | (Resynchronized) |
| | |_____________________________|
| | | |
| | ______v__________ | Resume
| | | | + ---> Normal
| | | Synchronization | De-encapsulation
| | | Lost? |
| | | |
| | | No Yes |
| | |_________________|
| | | |
| |________| |
|___________________________|
Synchronization is lost
|
_____________v_______________
| |
| Search for candidate header |
+----------->| |
| | Found Not Found |
| | (Strong candidate) |
| |_____________________________|
| | |
| | + --------->close TCP
| _______v_____________________ Connection
| | | and notify
| | Enough strong candidate | the FC Entity
| +---->| headers identified? | with the reason
| | | | for closure
| | | No Yes |
| | | (Verified candidate) |
| | |_____________________________|
|___________________| |
^ | |
| | |
| | _______________________v_____
| | | |
| | | Enough verified candidate |
| | | headers validated? |
| | | |
| | | No Yes |
| | | (Resynchronized) |
| | |_____________________________|
| | | |
| | ______v__________ | Resume
| | | | + ---> Normal
| | | Synchronization | De-encapsulation
| | | Lost? |
| | | |
| | | No Yes |
| | |_________________|
| | | |
| |________| |
|___________________________|
Figure 15: Flow diagram of simple synchronization example
图15：简单同步示例的流程图
Appendix E - Relationship between FCIP and IP over FC (IPFC)
附录E-FCIP和IP over FC（IPFC）之间的关系
The contents of this annex are informative.
本附件的内容仅供参考。
IPFC (RFC 2625) describes the encapsulation of IP packets in FC Frames. It is intended to facilitate IP communication over an FC network.
IPFC（RFC 2625）描述了FC帧中IP数据包的封装。它旨在促进FC网络上的IP通信。
FCIP describes the encapsulation of FC Frames in TCP segments, which in turn are encapsulated inside IP packets for transporting over an IP network. It gives no consideration to the type of FC Frame that is being encapsulated. Therefore, the FC Frame may actually contain an IP packet as described in the IP over FC specification (RFC 2625). In such a case, the data packet would have:
FCIP描述了TCP段中FC帧的封装，而TCP段又封装在IP数据包中，用于通过IP网络传输。它没有考虑要封装的FC帧的类型。因此，如IP over FC规范（RFC 2625）中所述，FC帧实际上可以包含IP分组。在这种情况下，数据分组将具有：
- Data Link Header - IP Header - TCP Header - FCIP Header - FC Header - IP Header
- 数据链路头-IP头-TCP头-FCIP头-FC头-IP头
Note: The two IP headers would not be identical to each other. One would have information pertaining to the final destination, while the other would have information pertaining to the FCIP Entity.
注意：这两个IP头彼此不相同。其中一个将具有与最终目的地相关的信息，而另一个将具有与FCIP实体相关的信息。
The two documents focus on different objectives. As mentioned above, implementation of FCIP will lead to IP encapsulation within IP. While perhaps inefficient, this should not lead to issues with IP communication. One caveat: if a Fibre Channel device is encapsulating IP packets in an FC Frame (e.g., an IPFC device), and that device is communicating with a device running IP over a non-FC medium, a second IPFC device may need to act as a gateway between the two networks. This scenario is not specifically addressed by FCIP.
这两份文件侧重于不同的目标。如上所述，FCIP的实现将导致IP内的IP封装。虽然可能效率低下，但这不应导致IP通信问题。一个警告：如果光纤通道设备正在FC帧中封装IP数据包（例如，IPFC设备），并且该设备正在通过非FC介质与运行IP的设备通信，则第二个IPFC设备可能需要充当两个网络之间的网关。FCIP未专门解决此情况。
There is nothing in either of the specifications to prevent a single device from implementing both FCIP and IP-over-FC (IPFC), but this is implementation specific, and is beyond the scope of this document.
这两个规范中都没有阻止单个设备同时实现FCIP和IP over FC（IPFC），但这是特定于实现的，超出了本文档的范围。
Appendix F - FC Frame Format
附录F-FC帧格式
Note: All users of the words "character" or "characters" in this section refer to 8bit/10bit link encoding wherein each 8 bit "character" within a link frame is encoded as a 10 bit "character" for link transmission. These words do not refer to ASCII, Unicode, or any other form of text characters, although octets from such characters will occur as 8 bit "characters" for this encoding. This usage is employed here for consistency with the ANSI T11 standards that specify Fibre Channel.
注：本节中“字符”一词或“字符”一词的所有用户均指8位/10位链路编码，其中链路帧内的每个8位“字符”被编码为用于链路传输的10位“字符”。这些单词不涉及ASCII、Unicode或任何其他形式的文本字符，尽管对于这种编码，这些字符的八位字节将作为8位“字符”出现。此处使用此用法是为了与指定光纤通道的ANSI T11标准保持一致。
The contents of this annex are informative.
本附件的内容仅供参考。
All FC Frames have a standard format (see FC-FS [5]) much like LAN's 802.x protocols. However, the exact size of each FC Frame varies depending on the size of the variable fields. The size of the variable field ranges from 0 to 2112-bytes as shown in the FC Frame Format in figure 16, resulting in the minimum size FC Frame of 36 bytes and the maximum size FC Frame of 2148 bytes. Valid FC Frame lengths are always a multiple of four bytes.
所有FC帧都有一个标准格式（见FC-FS[5]），与LAN的802.x协议非常相似。但是，每个FC帧的确切大小取决于变量字段的大小。变量字段的大小范围为0到2112字节，如图16中的FC帧格式所示，导致FC帧的最小大小为36字节，FC帧的最大大小为2148字节。有效的FC帧长度始终是四个字节的倍数。
+------+--------+-----------+----//-------+------+------+
| SOF |Frame |Optional | Frame | CRC | EOF |
| (4B) |Header |Header | Payload | (4B) | (4B) |
| |(24B) |<----------------------->| | |
| | | Data Field = (0-2112B) | | |
+------+--------+-----------+----//-------+------+------+
+------+--------+-----------+----//-------+------+------+
| SOF |Frame |Optional | Frame | CRC | EOF |
| (4B) |Header |Header | Payload | (4B) | (4B) |
| |(24B) |<----------------------->| | |
| | | Data Field = (0-2112B) | | |
+------+--------+-----------+----//-------+------+------+
Figure 16: FC Frame Format
图16:FC帧格式
SOF and EOF Delimiters
SOF和EOF分隔符
On an FC link, Start-of-Frame (SOF) and End-Of-Frame (EOF) are called Ordered Sets and are sent as special words constructed from the 8B/10B comma character (K28.5) followed by three additional 8B/10B data characters making them uniquely identifiable in the data stream.
在FC链路上，帧开始（SOF）和帧结束（EOF）称为有序集，并作为特殊字发送，这些字由8B/10B逗号字符（K28.5）构成，后跟三个额外的8B/10B数据字符，使它们在数据流中唯一可识别。
On an FC link, the SOF delimiter serves to identify the beginning of an FC Frame and prepares the receiver for FC Frame reception. The SOF contains information about the FC Frame's Class of Service, position within a sequence, and in some cases, connection status.
在FC链路上，SOF定界符用于识别FC帧的开始，并为接收FC帧做好准备。SOF包含有关FC帧的服务类别、序列中的位置以及某些情况下的连接状态的信息。
The EOF delimiter identifies the end of the FC Frame and the final FC Frame of a sequence. In addition, it serves to force the running disparity to negative. The EOF is used to end the connection in connection-oriented classes of service.
EOF分隔符标识序列的FC帧结束和最终FC帧。此外，它还迫使跑步差距为负。EOF用于在面向连接的服务类中结束连接。
A special EOF delimiter called EOFa (End Of Frame - Abort) is used to terminate a partial FC Frame resulting from a malfunction in a link facility during transmission. Since an FCIP Entity functions like a transmission link with respect to the rest of the FC Fabric, FCIP_DEs may use EOFa in their error recovery procedures.
一个称为EOFa（帧结束-中止）的特殊EOF定界符用于终止由于传输期间链路设施故障而导致的部分FC帧。由于FCIP实体的功能与FC结构其余部分的传输链路类似，FCIP_DEs可在其错误恢复过程中使用EOFa。
It is therefore important to preserve the information conveyed by the delimiters across the IP-based network, so that the receiving FCIP Entity can correctly reconstruct the FC Frame in its original SOF and EOF format before forwarding it to its ultimate FC destination on the FC link.
因此，在基于IP的网络上保留定界符传递的信息非常重要，以便接收FCIP实体能够在将FC帧转发到FC链路上的最终FC目的地之前，以其原始SOF和EOF格式正确地重建FC帧。
When an FC Frame is encapsulated and sent over a byte-oriented interface, the SOF and EOF delimiters are represented as sequences of four consecutive bytes, which carry the equivalent Class of Service and FC Frame termination information as the FC ordered sets.
当FC帧被封装并通过面向字节的接口发送时，SOF和EOF定界符表示为四个连续字节的序列，它们携带与FC有序集相同的服务类别和FC帧终止信息。
The representation of SOF and EOF in an encapsulation FC Frame is described in FC Frame Encapsulation [19].
FC帧封装[19]中描述了封装FC帧中SOF和EOF的表示。
Frame Header
帧头
The FC Frame Header is transparent to the FCIP Entity. The FC Frame Header is 24 bytes long and has several fields that are associated with the identification and control of the payload. Current FC Standards allow up to 3 Optional Header fields [5]:
FC帧头对FCIP实体是透明的。FC帧报头的长度为24字节，具有多个与有效负载的标识和控制相关联的字段。当前FC标准最多允许3个可选的标题字段[5]：
- Network_Header (16-bytes) - Association_Header (32-bytes) - Device_Header (up to 64-bytes).
- 网络_头（16字节）-关联_头（32字节）-设备_头（最多64字节）。
Frame Payload
帧有效载荷
The FC Frame Payload is transparent to the FCIP Entity. An FC application level payload is called an Information Unit at the FC-4 Level. This is mapped into the FC Frame Payload of the FC Frame. A large Information Unit is segmented using a structure consisting of FC Sequences. Typically, a Sequence consists of more than one FC Frame. FCIP does not maintain any state information regarding the relationship of FC Frames within an FC Sequence.
FC帧有效负载对FCIP实体是透明的。FC应用级有效负载称为FC-4级的信息单元。这被映射到FC帧的FC帧有效负载中。使用由FC序列组成的结构对大型信息单元进行分割。通常，一个序列由多个FC帧组成。FCIP不维护有关FC序列中FC帧关系的任何状态信息。
CRC
华润
The FC CRC is 4 bytes long and uses the same 32-bit polynomial used in FDDI and is specified in ANSI X3.139 Fiber Distributed Data Interface. This CRC value is calculated over the entire FC
FC CRC长度为4字节，使用FDDI中使用的相同32位多项式，并在ANSI X3.139光纤分布式数据接口中指定。该CRC值是在整个FC上计算的
header and the FC payload; it does not include the SOF and EOF delimiters.
报头和FC有效载荷；它不包括SOF和EOF分隔符。
Note: When FC Frames are encapsulated into FCIP Frames, the FC Frame CRC is untouched by the FCIP Entity.
注意：当FC帧封装到FCIP帧中时，FCIP实体不会触及FC帧CRC。
Appendix G - FC Encapsulation Format
附录G-FC封装格式
This annex contains a reproduction of the FC Encapsulation Format [19] as it applies to FCIP Frames that encapsulate FC Frames. The information in this annex is not intended to represent the FCIP Special Frame (FSF) that is described in section 7.
本附录包含FC封装格式[19]的副本，因为其适用于封装FC帧的FCIP帧。本附件中的信息不代表第7节中描述的FCIP特殊框架（FSF）。
The information in this annex was correct as of the time this specification was approved. The information in this annex is informative only.
本附件中的信息在本规范获得批准时是正确的。本附件中的信息仅供参考。
If there are any differences between the information here and the FC Encapsulation Format specification [19], the FC Encapsulation Format specification takes precedence.
如果此处的信息与FC封装格式规范[19]之间存在任何差异，则以FC封装格式规范为准。
If there are any differences between the information here and the contents of section 5.6.1, then the contents of section 5.6.1 take precedence.
如果此处的信息与第5.6.1节的内容存在任何差异，则以第5.6.1节的内容为准。
Figure 17 applies the requirements stated in section 5.6.1 and in the FC Encapsulation Frame format resulting in a summary of the FC Frame format. Where FCIP requires specific values, those values are shown in hexadecimal in parentheses. Detailed requirements for the FCIP usage of the FC Encapsulation Format are in section 5.6.1.
图17应用了第5.6.1节和FC封装帧格式中规定的要求，从而总结了FC帧格式。当FCIP需要特定值时，这些值以十六进制形式显示在括号中。FC封装格式的FCIP使用的详细要求见第5.6.1节。
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------+---------------+---------------+---------------+
0| Protocol# | Version | -Protocol# | -Version |
| (0x01) | (0x01) | (0xFE) | (0xFE) |
+---------------+---------------+---------------+---------------+
1| Protocol# | Version | -Protocol# | -Version |
| (0x01) | (0x01) | (0xFE) | (0xFE) |
+---------------+---------------+---------------+---------------+
2| pFlags | Reserved | -pFlags | -Reserved |
| (0x00) | (0x00) | (0xFF) | (0xFF) |
+-----------+---+---------------+-----------+---+---------------+
3| Flags | Frame Length | -Flags | -Frame Length |
| (0x00) | | (0x3F) | |
+-----------+-------------------+-----------+-------------------+
4| Time Stamp [integer] |
+---------------------------------------------------------------+
5| Time Stamp [fraction] |
+---------------------------------------------------------------+
6| CRC (Reserved in FCIP) |
| (0x00-00-00-00) |
+---------------+---------------+---------------+---------------+
7| SOF | SOF | -SOF | -SOF |
+---------------+---------------+---------------+---------------+
8| |
+----- FC Frame content (see appendix F) -----+
| |
+---------------+---------------+---------------+---------------+
n| EOF | EOF | -EOF | -EOF |
+---------------+---------------+---------------+---------------+
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------+---------------+---------------+---------------+
0| Protocol# | Version | -Protocol# | -Version |
| (0x01) | (0x01) | (0xFE) | (0xFE) |
+---------------+---------------+---------------+---------------+
1| Protocol# | Version | -Protocol# | -Version |
| (0x01) | (0x01) | (0xFE) | (0xFE) |
+---------------+---------------+---------------+---------------+
2| pFlags | Reserved | -pFlags | -Reserved |
| (0x00) | (0x00) | (0xFF) | (0xFF) |
+-----------+---+---------------+-----------+---+---------------+
3| Flags | Frame Length | -Flags | -Frame Length |
| (0x00) | | (0x3F) | |
+-----------+-------------------+-----------+-------------------+
4| Time Stamp [integer] |
+---------------------------------------------------------------+
5| Time Stamp [fraction] |
+---------------------------------------------------------------+
6| CRC (Reserved in FCIP) |
| (0x00-00-00-00) |
+---------------+---------------+---------------+---------------+
7| SOF | SOF | -SOF | -SOF |
+---------------+---------------+---------------+---------------+
8| |
+----- FC Frame content (see appendix F) -----+
| |
+---------------+---------------+---------------+---------------+
n| EOF | EOF | -EOF | -EOF |
+---------------+---------------+---------------+---------------+
Figure 17: FCIP Frame Format
图17:FCIP帧格式
The names of fields are generally descriptive on their contents and the FC Encapsulation Format specification [19] is referenced for details. Field names preceded by a minus sign are ones complement values of the named field.
字段名称通常对其内容进行描述，详细信息请参考FC封装格式规范[19]。以减号开头的字段名是对命名字段值的补码。
Note: Figure 17 does not represent the FSF that is described in section 7.
注：图17不代表第7节中描述的FSF。
Appendix H - FCIP Requirements on an FC Entity
附录H-FC实体的FCIP要求
The contents of this annex are informative for FCIP but might be considered normative on FC-BB-2.
本附录的内容为FCIP的信息性内容，但可能被视为FC-BB-2的规范性内容。
The capabilities that FCIP requires of an FC Entity include:
FCIP要求FC实体具备的能力包括：
1) The FC Entity must deliver FC Frames to the correct FCIP Data Engine (in the correct FCIP Link Endpoint).
1) FC实体必须将FC帧传送到正确的FCIP数据引擎（在正确的FCIP链路端点中）。
2) Each FC Frame delivered to an FCIP_DE must be accompanied by a time value synchronized with the clock maintained by the FC Entity at the other end of the FCIP Link (see section 6). If a synchronized time value is not available, a value of zero must accompany the FC Frame.
2) 交付给FCIP_DE的每个FC帧必须附有一个与FCIP链路另一端FC实体保持的时钟同步的时间值（见第6节）。如果同步时间值不可用，则FC帧必须随附零值。
3) When FC Frames exit FCIP Data Engine(s) via the FC Frame Transmitter Portal(s), the FC Entity should forward them to the FC Fabric. However, before forwarding an FC Frame, the FC Entity must compute the end-to-end transit time for the FC Frame using the time value supplied by the FCIP_DE (taken from the FCIP header) and a synchronized time value (see section 6). If the end-to-end transit time exceeds the requirements of the FC Fabric, the FC Entity is responsible for discarding the FC Frame.
3) 当FC帧通过FC帧发送器入口退出FCIP数据引擎时，FC实体应将其转发到FC结构。但是，在转发FC帧之前，FC实体必须使用FCIP提供的时间值（取自FCIP报头）和同步时间值（参见第6节）计算FC帧的端到端传输时间。如果端到端传输时间超过FC结构的要求，FC实体负责丢弃FC帧。
4) The only delivery ordering guarantee provided by FCIP is correctly ordered delivery of FC Frames between a pair of FCIP Data Engines. FCIP expects the FC Entity to implement all other FC Frame delivery ordering requirements.
4) FCIP提供的唯一交付订购保证是在一对FCIP数据引擎之间正确订购FC帧的交付。FCIP期望FC实体实施所有其他FC帧交付订购要求。
5) When a TCP connect request is received and that request would add a new TCP Connection to an existing FCIP_LEP, the FC Entity must authenticate the source of the TCP connect request before use of the new TCP connection is allowed.
5) 当收到TCP连接请求且该请求将向现有FCIP_LEP添加新的TCP连接时，FC实体必须在允许使用新的TCP连接之前验证TCP连接请求的源。
6) The FC Entity may participate in determining allowed TCP Connections, TCP Connection parameters, quality of service usage, and security usage by modifying interactions with the FCIP Entity that are modelled as a "shared" database in section 8.1.1.
6) FC实体可通过修改与第8.1.1节中建模为“共享”数据库的FCIP实体的交互，参与确定允许的TCP连接、TCP连接参数、服务质量使用和安全使用。
7) The FC Entity may require the FCIP Entity to perform TCP close requests.
7) FC实体可能要求FCIP实体执行TCP关闭请求。
8) The FC Entity may recover from connection failures.
8) FC实体可以从连接故障中恢复。
9) The FC Entity must recover from events that the FCIP Entity cannot handle, such as:
9) FC实体必须从FCIP实体无法处理的事件中恢复，例如：
a) loss of synchronization with FCIP Frame headers from the Encapsulated Frame Receiver Portal requiring resetting the TCP Connection; and
a) 与封装帧接收器入口的FCIP帧头的同步丢失，需要重置TCP连接；和
b) recovering from FCIP Frames that are discarded as a result of synchronization problems (see section 5.6.2.2 and section 5.6.2.3).
b) 从因同步问题而丢弃的FCIP帧中恢复（参见第5.6.2.2节和第5.6.2.3节）。
10) The FC Entity must work cooperatively with the FCIP Entity to manage flow control problems in either the IP Network or FC Fabric.
10） FC实体必须与FCIP实体协作，以管理IP网络或FC结构中的流量控制问题。
11) The FC Entity may test for failed TCP Connections.
11） FC实体可能会测试失败的TCP连接。
Note that the Fibre Channel standards must be consulted for a complete understanding of the requirements placed on an FC Entity.
请注意，为了全面了解FC实体的要求，必须参考光纤通道标准。
Table 2 shows the explicit interactions between the FCIP Entity and the FC Entity.
表2显示了FCIP实体和FC实体之间的显式交互。
+-------------+-----------------+-----------------------------------+
| | | Information/Parameter Passed and |
| | | Direction |
| Reference | +-----------------+-----------------+
| Section | Condition | FCIP Entity---> | <---FC Entity |
+-------------+-----------------+-----------------+-----------------+
| 5.6 | FC Frame ready | | Provide FC |
| FCIP Data | for IP transfer | | Frame and |
| Engine | | | time stamp at |
| | | | FC Frame |
| | | | Receiver Portal |
+-------------+-----------------+-----------------+-----------------+
| WWN = World Wide Name |
+-------------------------------------------------------------------+
| continued |
+-------------------------------------------------------------------+
+-------------+-----------------+-----------------------------------+
| | | Information/Parameter Passed and |
| | | Direction |
| Reference | +-----------------+-----------------+
| Section | Condition | FCIP Entity---> | <---FC Entity |
+-------------+-----------------+-----------------+-----------------+
| 5.6 | FC Frame ready | | Provide FC |
| FCIP Data | for IP transfer | | Frame and |
| Engine | | | time stamp at |
| | | | FC Frame |
| | | | Receiver Portal |
+-------------+-----------------+-----------------+-----------------+
| WWN = World Wide Name |
+-------------------------------------------------------------------+
| continued |
+-------------------------------------------------------------------+
Table 2: FC/FCIP Entity pair interactions (part 1 of 5)
表2:FC/FCIP实体对交互（第1部分，共5部分）
+-------------+-----------------+-----------------------------------+
| | | Information/Parameter Passed and |
| | | Direction |
| Reference | +-----------------+-----------------+
| Section | Condition | FCIP Entity---> | <---FC Entity |
+-------------+-----------------+-----------------+-----------------+
| continued |
+-------------+-----------------+-----------------+-----------------+
| 5.6 | FCIP Frame | Provide FC | |
| FCIP Data | received from | Frame and | |
| Engine | IP Network | time stamp at | |
| | | FC Frame Trans- | |
| | | mitter Portal | |
+-------------+-----------------+-----------------+-----------------+
| 5.6.2.2 | FCIP_DE | Inform FC | |
| Errors | discards bytes | Entity that | |
| in FCIP | delivered | bytes have been | |
| Headers and | through | discarded with | |
| Discarding | Encapsulated | reason | |
| FCIP Frames | Frame Receiver | | |
| | Portal | | |
+-------------+-----------------+-----------------+-----------------+
| 5.6.2.3 | FCIP Entity | Inform FC | |
| Synchron- | closes TCP | Entity that TCP | |
| ization | Connection due | Connection has | |
| Failures | to synchron- | been closed | |
| | ization failure | with reason | |
| | | for closure | |
+-------------+-----------------+-----------------+-----------------+
| 8.1.2.3 | Receipt of the | Inform FC | |
| Connection | echoed FSF | Entity that TCP | |
| Setup | takes too long | Connection has | |
| Following a | or the FSF | been closed | |
| Successful | contents have | with reason | |
| TCP Connect | changed | for closure | |
| Request | | | |
+-------------+-----------------+-----------------+-----------------+
| WWN = World Wide Name |
+-------------------------------------------------------------------+
| continued |
+-------------------------------------------------------------------+
+-------------+-----------------+-----------------------------------+
| | | Information/Parameter Passed and |
| | | Direction |
| Reference | +-----------------+-----------------+
| Section | Condition | FCIP Entity---> | <---FC Entity |
+-------------+-----------------+-----------------+-----------------+
| continued |
+-------------+-----------------+-----------------+-----------------+
| 5.6 | FCIP Frame | Provide FC | |
| FCIP Data | received from | Frame and | |
| Engine | IP Network | time stamp at | |
| | | FC Frame Trans- | |
| | | mitter Portal | |
+-------------+-----------------+-----------------+-----------------+
| 5.6.2.2 | FCIP_DE | Inform FC | |
| Errors | discards bytes | Entity that | |
| in FCIP | delivered | bytes have been | |
| Headers and | through | discarded with | |
| Discarding | Encapsulated | reason | |
| FCIP Frames | Frame Receiver | | |
| | Portal | | |
+-------------+-----------------+-----------------+-----------------+
| 5.6.2.3 | FCIP Entity | Inform FC | |
| Synchron- | closes TCP | Entity that TCP | |
| ization | Connection due | Connection has | |
| Failures | to synchron- | been closed | |
| | ization failure | with reason | |
| | | for closure | |
+-------------+-----------------+-----------------+-----------------+
| 8.1.2.3 | Receipt of the | Inform FC | |
| Connection | echoed FSF | Entity that TCP | |
| Setup | takes too long | Connection has | |
| Following a | or the FSF | been closed | |
| Successful | contents have | with reason | |
| TCP Connect | changed | for closure | |
| Request | | | |
+-------------+-----------------+-----------------+-----------------+
| WWN = World Wide Name |
+-------------------------------------------------------------------+
| continued |
+-------------------------------------------------------------------+
Table 2: FC/FCIP Entity pair interactions (part 2 of 5)
表2:FC/FCIP实体对交互（第2部分，共5部分）
+-------------+-----------------+-----------------------------------+
| | | Information/Parameter Passed and |
| | | Direction |
| Reference | +-----------------+-----------------+
| Section | Condition | FCIP Entity---> | <---FC Entity |
+-------------+-----------------+-----------------+-----------------+
| continued |
+-------------+-----------------+-----------------+-----------------+
| 8.1.2.1 | New TCP | Inform FC | |
| Non-Dynamic | Connection | Entity of | |
| Creation of | created based | new or existing | |
| a New TCP | on "shared" | FCIP_LEP and | |
| Connections | database | new FCIP_DE | |
| | information | along with | |
| | | Destination FC | |
| | | Fabric Entity | |
| | | WWN, Connection | |
| | | Usage Flags, | |
| | | Connection | |
| | | Usage Code and | |
| | | Connection | |
| | | Nonce | |
+-------------+-----------------+-----------------+-----------------+
| 8.1.2.2 | New TCP | Inform FC | |
| Dynamic | Connection | Entity of | |
| Creation of | created based | new or existing | |
| a New TCP | on SLP service | FCIP_LEP and | |
| Connections | advertisement | new FCIP_DE | |
| | and "shared" | along with | |
| | database | Destination FC | |
| | information | Fabric Entity | |
| | | WWN, Connection | |
| | | Usage Flags, | |
| | | Connection | |
| | | Usage Code and | |
| | | Connection | |
| | | Nonce | |
+-------------+-----------------+-----------------+-----------------+
| WWN = World Wide Name |
+-------------------------------------------------------------------+
| continued |
+-------------------------------------------------------------------+
+-------------+-----------------+-----------------------------------+
| | | Information/Parameter Passed and |
| | | Direction |
| Reference | +-----------------+-----------------+
| Section | Condition | FCIP Entity---> | <---FC Entity |
+-------------+-----------------+-----------------+-----------------+
| continued |
+-------------+-----------------+-----------------+-----------------+
| 8.1.2.1 | New TCP | Inform FC | |
| Non-Dynamic | Connection | Entity of | |
| Creation of | created based | new or existing | |
| a New TCP | on "shared" | FCIP_LEP and | |
| Connections | database | new FCIP_DE | |
| | information | along with | |
| | | Destination FC | |
| | | Fabric Entity | |
| | | WWN, Connection | |
| | | Usage Flags, | |
| | | Connection | |
| | | Usage Code and | |
| | | Connection | |
| | | Nonce | |
+-------------+-----------------+-----------------+-----------------+
| 8.1.2.2 | New TCP | Inform FC | |
| Dynamic | Connection | Entity of | |
| Creation of | created based | new or existing | |
| a New TCP | on SLP service | FCIP_LEP and | |
| Connections | advertisement | new FCIP_DE | |
| | and "shared" | along with | |
| | database | Destination FC | |
| | information | Fabric Entity | |
| | | WWN, Connection | |
| | | Usage Flags, | |
| | | Connection | |
| | | Usage Code and | |
| | | Connection | |
| | | Nonce | |
+-------------+-----------------+-----------------+-----------------+
| WWN = World Wide Name |
+-------------------------------------------------------------------+
| continued |
+-------------------------------------------------------------------+
Table 2: FC/FCIP Entity pair interactions (part 3 of 5)
表2:FC/FCIP实体对交互（第3部分，共5部分）
+-------------+-----------------+-----------------------------------+
| | | Information/Parameter Passed and |
| | | Direction |
| Reference | +-----------------+-----------------+
| Section | Condition | FCIP Entity---> | <---FC Entity |
+-------------+-----------------+-----------------+-----------------+
| continued |
+-------------+-----------------+-----------------+-----------------+
| 8.1.3 | New TCP | Inform FC | |
| Processing | Connection | Entity of | |
| Incoming | created based | new or existing | |
| TCP Connect | on incoming TCP | FCIP_LEP and | |
| Requests | Connect request | new FCIP_DE | |
| | and "shared" | along with | |
| | database | Source FC | |
| | information | Fabric Entity | |
| | | WWN, Source | |
| | | FC/FCIP Entity | |
| | | Identifier, | |
| | | Connection | |
| | | Usage Flags, | |
| | | Connection | |
| | | Usage Code and | |
| | | Connection | |
| | | Nonce | |
+-------------+-----------------+-----------------+-----------------+
| 8.1.3 | TCP Connect | Request FC | Yes or No |
| Processing | Request wants | Entity to | answer about |
| Incoming | to add a new | authenticate | whether the |
| TCP Connect | TCP Connection | the source of | source of the |
| Requests | to an existing | the TCP Connect | TCP Connect |
| | FCIP_LEP | Request | Request can be |
| | | | authenticated |
+-------------+-----------------+-----------------+-----------------+
| 8.1.3 | Receipt of the | Inform FC | |
| Processing | FSF takes too | Entity that TCP | |
| Incoming | long or | Connection has | |
| TCP Connect | duplicate | been closed | |
| Requests | Connection | with reason | |
| | Nonce value | for closure | |
+-------------+-----------------+-----------------+-----------------+
| WWN = World Wide Name |
+-------------------------------------------------------------------+
| continued |
+-------------------------------------------------------------------+
+-------------+-----------------+-----------------------------------+
| | | Information/Parameter Passed and |
| | | Direction |
| Reference | +-----------------+-----------------+
| Section | Condition | FCIP Entity---> | <---FC Entity |
+-------------+-----------------+-----------------+-----------------+
| continued |
+-------------+-----------------+-----------------+-----------------+
| 8.1.3 | New TCP | Inform FC | |
| Processing | Connection | Entity of | |
| Incoming | created based | new or existing | |
| TCP Connect | on incoming TCP | FCIP_LEP and | |
| Requests | Connect request | new FCIP_DE | |
| | and "shared" | along with | |
| | database | Source FC | |
| | information | Fabric Entity | |
| | | WWN, Source | |
| | | FC/FCIP Entity | |
| | | Identifier, | |
| | | Connection | |
| | | Usage Flags, | |
| | | Connection | |
| | | Usage Code and | |
| | | Connection | |
| | | Nonce | |
+-------------+-----------------+-----------------+-----------------+
| 8.1.3 | TCP Connect | Request FC | Yes or No |
| Processing | Request wants | Entity to | answer about |
| Incoming | to add a new | authenticate | whether the |
| TCP Connect | TCP Connection | the source of | source of the |
| Requests | to an existing | the TCP Connect | TCP Connect |
| | FCIP_LEP | Request | Request can be |
| | | | authenticated |
+-------------+-----------------+-----------------+-----------------+
| 8.1.3 | Receipt of the | Inform FC | |
| Processing | FSF takes too | Entity that TCP | |
| Incoming | long or | Connection has | |
| TCP Connect | duplicate | been closed | |
| Requests | Connection | with reason | |
| | Nonce value | for closure | |
+-------------+-----------------+-----------------+-----------------+
| WWN = World Wide Name |
+-------------------------------------------------------------------+
| continued |
+-------------------------------------------------------------------+
Table 2: FC/FCIP Entity pair interactions (part 4 of 5)
表2:FC/FCIP实体对交互（第4部分，共5部分）
+-------------+-----------------+-----------------------------------+
| | | Information/Parameter Passed and |
| | | Direction |
| Reference | +-----------------+-----------------+
| Section | Condition | FCIP Entity---> | <---FC Entity |
+-------------+-----------------+-----------------+-----------------+
| concluded |
+-------------+-----------------+-----------------+-----------------+
| 8.2 | FC Entity | Acknowledgement | Identification |
| Closing TCP | determines | of TCP | of the FCIP_DE |
| Connections | that a TCP | Connection | whose TCP |
| | Connection | closure | Connection |
| | needs to be | | needs to be |
| | closed | | closed |
+-------------+-----------------+-----------------+-----------------+
| 8.4 | Discovery that | Inform FC | |
| TCP | TCP connectiv- | Entity that TCP | |
| Connection | ity has been | Connection has | |
| Considera- | lost | been closed | |
| tions | | with reason | |
| | | for closure | |
+-------------+-----------------+-----------------+-----------------+
| 9.4.1 | IKE phase 1 | Inform FC | |
| FCIP | failed, result- | Entity that TCP | |
| Link | ing in termin- | Connection can | |
| Initializ- | ation of link | not be opened | |
| ation Steps | initialization | with reason for | |
| | | failure | |
+-------------+-----------------+-----------------+-----------------+
| 9.4.3 | Excessive | Inform FC | |
| Handling | numbers of | Entity that TCP | |
| data | dropped | Connection has | |
| integrity | datagrams | been closed | |
| and confi- | detected and | with reason | |
| dentiality | TCP Connection | for closure | |
| violations | closed | | |
+-------------+-----------------+-----------------+-----------------+
| RFC 3723 | TCP Connection | Inform FC | |
| | closed due to | Entity that TCP | |
| Handling SA | SA parameter | Connection has | |
| parameter | mismatch | been closed | |
| mismatches | problems | with reason | |
| | | for closure | |
+-------------+-----------------+-----------------+-----------------+
| WWN = World Wide Name |
+-------------------------------------------------------------------+
+-------------+-----------------+-----------------------------------+
| | | Information/Parameter Passed and |
| | | Direction |
| Reference | +-----------------+-----------------+
| Section | Condition | FCIP Entity---> | <---FC Entity |
+-------------+-----------------+-----------------+-----------------+
| concluded |
+-------------+-----------------+-----------------+-----------------+
| 8.2 | FC Entity | Acknowledgement | Identification |
| Closing TCP | determines | of TCP | of the FCIP_DE |
| Connections | that a TCP | Connection | whose TCP |
| | Connection | closure | Connection |
| | needs to be | | needs to be |
| | closed | | closed |
+-------------+-----------------+-----------------+-----------------+
| 8.4 | Discovery that | Inform FC | |
| TCP | TCP connectiv- | Entity that TCP | |
| Connection | ity has been | Connection has | |
| Considera- | lost | been closed | |
| tions | | with reason | |
| | | for closure | |
+-------------+-----------------+-----------------+-----------------+
| 9.4.1 | IKE phase 1 | Inform FC | |
| FCIP | failed, result- | Entity that TCP | |
| Link | ing in termin- | Connection can | |
| Initializ- | ation of link | not be opened | |
| ation Steps | initialization | with reason for | |
| | | failure | |
+-------------+-----------------+-----------------+-----------------+
| 9.4.3 | Excessive | Inform FC | |
| Handling | numbers of | Entity that TCP | |
| data | dropped | Connection has | |
| integrity | datagrams | been closed | |
| and confi- | detected and | with reason | |
| dentiality | TCP Connection | for closure | |
| violations | closed | | |
+-------------+-----------------+-----------------+-----------------+
| RFC 3723 | TCP Connection | Inform FC | |
| | closed due to | Entity that TCP | |
| Handling SA | SA parameter | Connection has | |
| parameter | mismatch | been closed | |
| mismatches | problems | with reason | |
| | | for closure | |
+-------------+-----------------+-----------------+-----------------+
| WWN = World Wide Name |
+-------------------------------------------------------------------+
Table 2: FC/FCIP Entity pair interactions (part 5 of 5)
表2:FC/FCIP实体对交互（第5部分，共5部分）
Editors and Contributors Acknowledgements
编辑和贡献者致谢
During the development of this specification, Murali Rajagopal, Elizabeth Rodriguez, Vi Chau, and Ralph Weber served consecutively as editors. Raj Bhagwat contributed substantially to the initial basic FCIP concepts.
在本规范的制定过程中，Murali Rajagopal、Elizabeth Rodriguez、Vi Chau和Ralph Weber连续担任编辑。Raj Bhagwat对最初的基本FCIP概念做出了重大贡献。
Venkat Rangan contributed the Security section and continues to coordinate security issues with the ips Working Group and IETF.
Venkat Rangan为安全科做出了贡献，并继续与ips工作组和IETF协调安全问题。
Andy Helland contributed a substantial revision of Performance section, aligning it with TCP/IP QoS concepts.
Andy Helland对性能部分进行了重大修订，使其与TCP/IP QoS概念保持一致。
Dave Peterson contributed the dynamic discovery section and edits to RFC 3822.
Dave Peterson贡献了动态发现部分并编辑了RFC 3822。
Anil Rijhsinghani contributed material related to the FCIP MIB and edits the FCIP MIB document.
Anil Rijhsinghani提供了与FCIP MIB相关的资料，并编辑了FCIP MIB文档。
Bob Snively contributed material related to error detection and recovery including the bulk of the synchronization recovery example annex.
Bob Snivly提供了与错误检测和恢复相关的资料，包括同步恢复示例附件的大部分内容。
Lawrence J. Lamers contributed numerous ideas focused on keeping FCIP compatible with B_Port devices.
Lawrence J.Lamers就保持FCIP与B_端口设备的兼容性提出了许多想法。
Milan Merhar contributed several of the FCIP conceptual modifications necessary to support NATs.
Milan Merhar对FCIP概念进行了一些必要的修改，以支持NATs。
Don Fraser contributed material related to link failure detection and reporting.
Don Fraser提供了与链路故障检测和报告相关的资料。
Bill Krieg contributed a restructuring of the TCP Connection setup sections that made them more linear with respect to time and more readable.
Bill Krieg对TCP连接设置部分进行了重构，使它们在时间上更具线性，可读性更强。
Several T11 leaders supported this effort and advised the editors of this specification regarding coordination with T11 documents and projects. These T11 leaders are: Jim Nelson (Framing and Signaling), Neil Wanamaker (Framing and Signaling), Craig Carlson (Generic Services), Ken Hirata (Switch Fabric), Murali Rajagopal (Backbone), Steve Wilson (Switch Fabric), and Michael O'Donnell (Security Protocols).
一些T11领导人支持这项工作，并就与T11文件和项目的协调向本规范的编辑提供建议。这些T11领导人是：吉姆·纳尔逊（框架和信号）、尼尔·瓦纳梅克（框架和信号）、克雷格·卡尔森（通用服务）、肯·海拉塔（交换结构）、穆拉里·拉贾戈帕尔（主干）、史蒂夫·威尔逊（交换结构）和迈克尔·奥唐纳（安全协议）。
Editors and Contributors Addresses
编辑和投稿人地址
Neil Wanamaker Akara 10624 Icarus Court Austin, TX 78726 USA
Neil Wanamaker Akara 10624伊卡洛斯法院奥斯汀，德克萨斯州78726美国
Phone: +1 512 257 7633
Fax: +1 512 257 7877
EMail: nwanamaker@akara.com
Phone: +1 512 257 7633
Fax: +1 512 257 7877
EMail: nwanamaker@akara.com
Ralph Weber ENDL Texas, representing Brocade Suite 102 PMB 178 18484 Preston Road Dallas, TX 75252 USA
Ralph Weber ENDL Texas，代表Brocade Suite 102 PMB 178 18484美国德克萨斯州达拉斯普雷斯顿路75252号
Phone: +1 214 912 1373
EMail: roweber@ieee.org
Phone: +1 214 912 1373
EMail: roweber@ieee.org
Elizabeth G. Rodriguez Dot Hill Systems Corp. 6305 El Camino Real Carlsbad, CA 92009 USA
Elizabeth G.Rodriguez Dot Hill系统公司6305 El Camino Real Carlsbad，加利福尼亚州，美国92009
Phone: +1 760 431 4435
EMail: elizabeth.rodriguez@dothill.com
Phone: +1 760 431 4435
EMail: elizabeth.rodriguez@dothill.com
Steve Wilson Brocade Comm. Systems, Inc. 1745 Technology Drive San Jose, CA. 95110 USA
Steve Wilson Brocade Comm.Systems，Inc.美国加利福尼亚州圣何塞市科技大道1745号，邮编95110
Phone: +1 408 333 8128
EMail: swilson@brocade.com
Phone: +1 408 333 8128
EMail: swilson@brocade.com
Bob Snively Brocade Comm. Systems, Inc. 1745 Technology Drive San Jose, CA 95110 USA
美国加利福尼亚州圣何塞市科技大道1745号Bob Snifly Brocade通信系统公司，邮编95110
Phone: +1 408 303 8135
EMail: rsnively@brocade.com
Phone: +1 408 303 8135
EMail: rsnively@brocade.com
David Peterson Cisco Systems - SRBU 6450 Wedgwood Road Maple Grove, MN 55311 USA
David Peterson Cisco Systems-SRBU 6450美国明尼苏达州枫树林韦奇伍德路55311号
Phone: +1 763 398 1007
Cell: +1 612 802 3299
EMail: dap@cisco.com
Phone: +1 763 398 1007
Cell: +1 612 802 3299
EMail: dap@cisco.com
Donald R. Fraser Hewlett-Packard 301 Rockrimmon Blvd., Bldg. 5 Colorado Springs, CO 80919 USA
Donald R.Fraser Hewlett-Packard美国科罗拉多州科罗拉多斯普林斯5号楼罗克林蒙大道301号，邮编：80919
Phone: +1 719 548 3272
EMail: Don.Fraser@HP.com
Phone: +1 719 548 3272
EMail: Don.Fraser@HP.com
R. Andy Helland LightSand Communications, Inc. 375 Los Coches Street Milpitas, CA 95035 USA
R.Andy Helland LightSand Communications，Inc.美国加利福尼亚州米尔皮塔斯市洛斯科克斯街375号，邮编95035
Phone: +1 408 404 3119
Fax: +1 408 941 2166
EMail: andyh@lightsand.com
Phone: +1 408 404 3119
Fax: +1 408 941 2166
EMail: andyh@lightsand.com
Raj Bhagwat LightSand Communications, Inc. 24411 Ridge Route Dr. Suite 135 Laguna Hills, CA 92653 USA
Raj Bhagwat LightSand Communications，Inc.24411 Ridge Route Dr.美国加利福尼亚州拉古纳山135号套房92653
Phone: +1 949 837 1733 x104
EMail: rajb@lightsand.com
Phone: +1 949 837 1733 x104
EMail: rajb@lightsand.com
Bill Krieg Lucent Technologies 200 Lucent Lane Cary, NC 27511 USA
比尔·克里格·朗讯科技公司，美国北卡罗来纳州朗讯巷200号，邮编27511
Phone: +1 919 463 4020
Fax: +1 919 463 4041
EMail: bkrieg@lucent.com
Phone: +1 919 463 4020
Fax: +1 919 463 4041
EMail: bkrieg@lucent.com
Michael E. O'Donnell McDATA Corporation 310 Interlocken Parkway Broomfield, CO 80021 USA
美国密苏里州布鲁姆菲尔德公园路310号迈可E.O'Donnell McDATA公司，邮编：80021
Phone: +1 303 460 4142
Fax: +1 303 465 4996
EMail: modonnell@mcdata.com
Phone: +1 303 460 4142
Fax: +1 303 465 4996
EMail: modonnell@mcdata.com
Anil Rijhsinghani McDATA Corporation 310 Interlocken Parkway Broomfield, CO 80021 USA
美国科罗拉多州布鲁姆菲尔德市安尼尔·里贾辛哈尼·麦卡塔公司310 Interlocken Parkway Broomfield
Phone: +1 508 870 6593
EMail: anil.rijhsinghani@mcdata.com
Phone: +1 508 870 6593
EMail: anil.rijhsinghani@mcdata.com
Milan J. Merhar 43 Nagog Park Pirus Networks Acton, MA 01720 USA
米兰J.梅哈尔43美国马萨诸塞州纳戈公园皮勒斯网络阿克顿01720
Phone: +1 978 206 9124
EMail: Milan@pirus.com
Phone: +1 978 206 9124
EMail: Milan@pirus.com
Craig W. Carlson QLogic Corporation 6321 Bury Drive Eden Prairie, MN 55346 USA
Craig W.Carlson QLogic Corporation 6321美国明尼苏达州伊甸草原伯里大道55346号
Phone: +1 952 932 4064
EMail: craig.carlson@qlogic.com
Phone: +1 952 932 4064
EMail: craig.carlson@qlogic.com
Venkat Rangan Rhapsody Networks Inc. 3450 W. Warren Ave. Fremont, CA 94538 USA
Venkat Rangan Rhapsody Networks Inc.美国加利福尼亚州弗里蒙特沃伦大道西3450号，邮编94538
Phone: +1 510 743 3018
Fax: +1 510 687 0136
EMail: venkat@rhapsodynetworks.com
Phone: +1 510 743 3018
Fax: +1 510 687 0136
EMail: venkat@rhapsodynetworks.com
Lawrence J. Lamers SAN Valley Systems, Inc. 6320 San Ignacio Ave. San Jose, CA 95119-1209 USA
美国加利福尼亚州圣何塞市圣伊格纳西奥大道6320号劳伦斯J.拉默斯圣谷系统公司，邮编95119-1209
Phone: +1 408 234 0071
EMail: ljlamers@ieee.org
Phone: +1 408 234 0071
EMail: ljlamers@ieee.org
Murali Rajagopal Broadcom Corporation 16215 Alton Parkway Irvine,CA 92619 USA
Murali Rajagopal Broadcom Corporation 16215美国加利福尼亚州埃尔文市阿尔顿大道16215号，邮编92619
Phone: +1 949 450 8700
EMail: muralir@broadcom.com
Phone: +1 949 450 8700
EMail: muralir@broadcom.com
Ken Hirata Vixel Corporation 15245 Alton Parkway, Suite 100 Irvine, CA 92618 USA
Ken Hirata Vixel Corporation美国加利福尼亚州欧文市阿尔顿大道15245号100室，邮编92618
Phone: +1 949 788 6368
Fax: +1 949 753 9500
EMail: ken.hirata@vixel.com
Phone: +1 949 788 6368
Fax: +1 949 753 9500
EMail: ken.hirata@vixel.com
Vi Chau USA Email: vchau1@cox.net
Vi Chau USA电子邮件：vchau1@cox.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。