Network Working Group C. Monia
Request for Comments: 4172 Consultant
Category: Standards Track R. Mullendore
McDATA
F. Travostino
Nortel
W. Jeong
Troika Networks
M. Edwards
Adaptec (UK) Ltd.
September 2005
Network Working Group C. Monia
Request for Comments: 4172 Consultant
Category: Standards Track R. Mullendore
McDATA
F. Travostino
Nortel
W. Jeong
Troika Networks
M. Edwards
Adaptec (UK) Ltd.
September 2005
iFCP - A Protocol for Internet Fibre Channel Storage Networking
iFCP-用于Internet光纤通道存储网络的协议
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document specifies an architecture and a gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network. This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards. The architecture enables internetworking of fibre channel devices through gateway-accessed regions with the fault isolation properties of autonomous systems and the scalability of the IP network.
本文档指定了用于在IP网络上实现光纤通道结构功能的体系结构和网关到网关协议。此功能通过光纤通道帧传输的TCP协议和光纤通道标准指定的分布式结构服务提供。该体系结构通过网关访问的区域实现光纤通道设备的互连，具有自治系统的故障隔离特性和IP网络的可扩展性。
Table of Contents
目录
1. Introduction.................................................. 4
1.1. Conventions used in This Document....................... 4
1.1.1. Data Structures Internal to an Implementation... 4
1.2. Purpose of This Document................................ 4
2. iFCP Introduction............................................. 4
2.1. Definitions............................................. 5
3. Fibre Channel Communication Concepts.......................... 7
3.1. The Fibre Channel Network............................... 8
1. Introduction.................................................. 4
1.1. Conventions used in This Document....................... 4
1.1.1. Data Structures Internal to an Implementation... 4
1.2. Purpose of This Document................................ 4
2. iFCP Introduction............................................. 4
2.1. Definitions............................................. 5
3. Fibre Channel Communication Concepts.......................... 7
3.1. The Fibre Channel Network............................... 8
3.2. Fibre Channel Network Topologies........................ 9
3.2.1. Switched Fibre Channel Fabrics.................. 11
3.2.2. Mixed Fibre Channel Fabric...................... 12
3.3. Fibre Channel Layers and Link Services.................. 12
3.3.1. Fabric-Supplied Link Services................... 13
3.4. Fibre Channel Nodes..................................... 14
3.5. Fibre Channel Device Discovery.......................... 14
3.6. Fibre Channel Information Elements...................... 15
3.7. Fibre Channel Frame Format.............................. 15
3.7.1. N_PORT Address Model............................ 16
3.8. Fibre Channel Transport Services........................ 17
3.9. Login Processes......................................... 18
4. The iFCP Network Model........................................ 18
4.1. iFCP Transport Services................................. 21
4.1.1. Fibre Channel Transport Services Supported by
iFCP............................................ 21
4.2. iFCP Device Discovery and Configuration Management...... 21
4.3. iFCP Fabric Properties.................................. 22
4.3.1. Address Transparency............................ 22
4.3.2. Configuration Scalability....................... 23
4.3.3. Fault Tolerance................................. 23
4.4. The iFCP N_PORT Address Model........................... 24
4.5. Operation in Address Transparent Mode................... 25
4.5.1. Transparent Mode Domain ID Management........... 26
4.5.2. Incompatibility with Address Translation Mode... 26
4.6. Operation in Address Translation Mode................... 27
4.6.1. Inbound Frame Address Translation............... 28
4.6.2. Incompatibility with Address Transparent Mode... 29
5. iFCP Protocol................................................. 29
5.1. Overview ............................................... 29
5.1.1. iFCP Transport Services......................... 29
5.1.2. iFCP Support for Link Services.................. 30
5.2. TCP Stream Transport of iFCP Frames..................... 30
5.2.1. iFCP Session Model.............................. 30
5.2.2. iFCP Session Management......................... 31
5.2.3. Terminating iFCP Sessions....................... 39
5.3. Fibre Channel Frame Encapsulation....................... 40
5.3.1. Encapsulation Header Format..................... 41
5.3.2. SOF and EOF Delimiter Fields.................... 44
5.3.3. Frame Encapsulation............................. 45
5.3.4. Frame De-encapsulation.......................... 46
6. TCP Session Control Messages.................................. 47
6.1. Connection Bind (CBIND)................................. 50
6.2. Unbind Connection (UNBIND).............................. 52
6.3. LTEST -- Test Connection Liveness....................... 54
7. Fibre Channel Link Services................................... 55
7.1. Special Link Service Messages........................... 56
7.2. Link Services Requiring Payload Address Translation..... 58
3.2. Fibre Channel Network Topologies........................ 9
3.2.1. Switched Fibre Channel Fabrics.................. 11
3.2.2. Mixed Fibre Channel Fabric...................... 12
3.3. Fibre Channel Layers and Link Services.................. 12
3.3.1. Fabric-Supplied Link Services................... 13
3.4. Fibre Channel Nodes..................................... 14
3.5. Fibre Channel Device Discovery.......................... 14
3.6. Fibre Channel Information Elements...................... 15
3.7. Fibre Channel Frame Format.............................. 15
3.7.1. N_PORT Address Model............................ 16
3.8. Fibre Channel Transport Services........................ 17
3.9. Login Processes......................................... 18
4. The iFCP Network Model........................................ 18
4.1. iFCP Transport Services................................. 21
4.1.1. Fibre Channel Transport Services Supported by
iFCP............................................ 21
4.2. iFCP Device Discovery and Configuration Management...... 21
4.3. iFCP Fabric Properties.................................. 22
4.3.1. Address Transparency............................ 22
4.3.2. Configuration Scalability....................... 23
4.3.3. Fault Tolerance................................. 23
4.4. The iFCP N_PORT Address Model........................... 24
4.5. Operation in Address Transparent Mode................... 25
4.5.1. Transparent Mode Domain ID Management........... 26
4.5.2. Incompatibility with Address Translation Mode... 26
4.6. Operation in Address Translation Mode................... 27
4.6.1. Inbound Frame Address Translation............... 28
4.6.2. Incompatibility with Address Transparent Mode... 29
5. iFCP Protocol................................................. 29
5.1. Overview ............................................... 29
5.1.1. iFCP Transport Services......................... 29
5.1.2. iFCP Support for Link Services.................. 30
5.2. TCP Stream Transport of iFCP Frames..................... 30
5.2.1. iFCP Session Model.............................. 30
5.2.2. iFCP Session Management......................... 31
5.2.3. Terminating iFCP Sessions....................... 39
5.3. Fibre Channel Frame Encapsulation....................... 40
5.3.1. Encapsulation Header Format..................... 41
5.3.2. SOF and EOF Delimiter Fields.................... 44
5.3.3. Frame Encapsulation............................. 45
5.3.4. Frame De-encapsulation.......................... 46
6. TCP Session Control Messages.................................. 47
6.1. Connection Bind (CBIND)................................. 50
6.2. Unbind Connection (UNBIND).............................. 52
6.3. LTEST -- Test Connection Liveness....................... 54
7. Fibre Channel Link Services................................... 55
7.1. Special Link Service Messages........................... 56
7.2. Link Services Requiring Payload Address Translation..... 58
7.3. Fibre Channel Link Services Processed by iFCP........... 61
7.3.1. Special Extended Link Services.................. 63
7.3.2. Special FC-4 Link Services...................... 83
7.4. FLOGI Service Parameters Supported by an iFCP Gateway... 84
8. iFCP Error Detection.......................................... 86
8.1. Overview................................................ 86
8.2. Stale Frame Prevention.................................. 86
8.2.1. Enforcing R_A_TOV Limits........................ 86
9. Fabric Services Supported by an iFCP Implementation........... 88
9.1. F_PORT Server........................................... 88
9.2. Fabric Controller....................................... 89
9.3. Directory/Name Server................................... 89
9.4. Broadcast Server........................................ 89
9.4.1. Establishing the Broadcast Configuration........ 90
9.4.2. Broadcast Session Management.................... 91
9.4.3. Standby Global Broadcast Server................. 91
10. iFCP Security................................................. 91
10.1. Overview................................................ 91
10.2. iFCP Security Threats and Scope......................... 92
10.2.1. Context......................................... 92
10.2.2. Security Threats................................ 92
10.2.3. Interoperability with Security Gateways......... 93
10.2.4. Authentication.................................. 93
10.2.5. Confidentiality................................. 93
10.2.6. Rekeying........................................ 93
10.2.7. Authorization................................... 94
10.2.8. Policy Control.................................. 94
10.2.9. iSNS Role....................................... 94
10.3. iFCP Security Design.................................... 94
10.3.1. Enabling Technologies........................... 94
10.3.2. Use of IKE and IPsec............................ 96
10.3.3. Signatures and Certificate-Based Authentication. 98
10.4. iSNS and iFCP Security.................................. 99
10.5. Use of iSNS to Distribute Security Policy............... 99
10.6. Minimal Security Policy for an iFCP Gateway............. 99
11. Quality of Service Considerations.............................100
11.1. Minimal Requirements....................................100
11.2. High Assurance..........................................100
12. IANA Considerations...........................................101
13. Normative References..........................................101
14. Informative References........................................103
Appendix A. iFCP Support for Fibre Channel Link Services.........105
A.1. Basic Link Services.....................................105
A.2. Pass-Through Link Services..............................105
A.3. Special Link Services...................................107
Appendix B. Supporting the Fibre Channel Loop Topology...........108
B.1. Remote Control of a Public Loop.........................108
Acknowledgements..................................................109
7.3. Fibre Channel Link Services Processed by iFCP........... 61
7.3.1. Special Extended Link Services.................. 63
7.3.2. Special FC-4 Link Services...................... 83
7.4. FLOGI Service Parameters Supported by an iFCP Gateway... 84
8. iFCP Error Detection.......................................... 86
8.1. Overview................................................ 86
8.2. Stale Frame Prevention.................................. 86
8.2.1. Enforcing R_A_TOV Limits........................ 86
9. Fabric Services Supported by an iFCP Implementation........... 88
9.1. F_PORT Server........................................... 88
9.2. Fabric Controller....................................... 89
9.3. Directory/Name Server................................... 89
9.4. Broadcast Server........................................ 89
9.4.1. Establishing the Broadcast Configuration........ 90
9.4.2. Broadcast Session Management.................... 91
9.4.3. Standby Global Broadcast Server................. 91
10. iFCP Security................................................. 91
10.1. Overview................................................ 91
10.2. iFCP Security Threats and Scope......................... 92
10.2.1. Context......................................... 92
10.2.2. Security Threats................................ 92
10.2.3. Interoperability with Security Gateways......... 93
10.2.4. Authentication.................................. 93
10.2.5. Confidentiality................................. 93
10.2.6. Rekeying........................................ 93
10.2.7. Authorization................................... 94
10.2.8. Policy Control.................................. 94
10.2.9. iSNS Role....................................... 94
10.3. iFCP Security Design.................................... 94
10.3.1. Enabling Technologies........................... 94
10.3.2. Use of IKE and IPsec............................ 96
10.3.3. Signatures and Certificate-Based Authentication. 98
10.4. iSNS and iFCP Security.................................. 99
10.5. Use of iSNS to Distribute Security Policy............... 99
10.6. Minimal Security Policy for an iFCP Gateway............. 99
11. Quality of Service Considerations.............................100
11.1. Minimal Requirements....................................100
11.2. High Assurance..........................................100
12. IANA Considerations...........................................101
13. Normative References..........................................101
14. Informative References........................................103
Appendix A. iFCP Support for Fibre Channel Link Services.........105
A.1. Basic Link Services.....................................105
A.2. Pass-Through Link Services..............................105
A.3. Special Link Services...................................107
Appendix B. Supporting the Fibre Channel Loop Topology...........108
B.1. Remote Control of a Public Loop.........................108
Acknowledgements..................................................109
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
Unless specified otherwise, numeric quantities are given as decimal values.
除非另有规定，数字量以十进制值给出。
All diagrams that portray bit and byte ordering, including the depiction of structures defined by fibre channel standards, adhere to the IETF conventions whereby bit 0 is the most significant bit and the first addressable byte is in the upper left corner. This IETF convention differs from that used for INCITS T11 fibre channel standards, in which bit 0 is the least significant bit.
描述位和字节顺序的所有图表，包括光纤通道标准定义的结构的描述，都遵守IETF惯例，其中位0为最高有效位，第一个可寻址字节位于左上角。此IETF约定不同于INCITS T11光纤通道标准所用的约定，其中位0是最低有效位。
To facilitate the specification of required behavior, this document may define and refer to internal data structures within an iFCP implementation. Such structures are intended for explanatory purposes only and need not be instantiated within an implementation as described in this specification.
为了便于规范所需的行为，本文档可以定义和引用iFCP实现中的内部数据结构。此类结构仅用于解释目的，不需要在本规范所述的实现中实例化。
This is a standards-track document that specifies a protocol for the implementation of fibre channel transport services on a TCP/IP network. Some portions of this document contain material from standards controlled by INCITS T10 and T11. This material is included here for informational purposes only. The authoritative information is given in the appropriate NCITS standards document.
这是一份标准跟踪文档，指定了在TCP/IP网络上实现光纤通道传输服务的协议。本文件的某些部分包含INCITS T10和T11控制的标准材料。本资料仅供参考。权威信息见相应的NCITS标准文件。
The authoritative portions of this document specify the mapping of standards-compliant fibre channel protocol implementations to TCP/IP. This mapping includes sections of this document that describe the "iFCP Protocol" (see Section 5).
本文档的权威部分指定了符合标准的光纤通道协议实现到TCP/IP的映射。该映射包括本文件中描述“iFCP协议”的章节（见第5节）。
iFCP is a gateway-to-gateway protocol that provides fibre channel fabric services to fibre channel devices over a TCP/IP network. iFCP uses TCP to provide congestion control, error detection, and recovery. iFCP's primary objective is to allow interconnection and
iFCP是一种网关到网关协议，它通过TCP/IP网络向光纤通道设备提供光纤通道结构服务。iFCP使用TCP提供拥塞控制、错误检测和恢复。iFCP的主要目标是允许互连和
networking of existing fibre channel devices at wire speeds over an IP network.
通过IP网络以线速连接现有光纤通道设备。
The protocol and method of frame address translation described in this document permit the attachment of fibre channel storage devices to an IP-based fabric by means of transparent gateways.
本文档中描述的帧地址转换协议和方法允许通过透明网关将光纤通道存储设备连接到基于IP的结构。
The protocol achieves this transparency by allowing normal fibre channel frame traffic to pass through the gateway directly, with provisions, where necessary, for intercepting and emulating the fabric services required by a fibre channel device.
该协议通过允许正常的光纤通道帧通信量直接通过网关来实现这种透明性，并在必要时提供拦截和模拟光纤通道设备所需的结构服务。
Terms needed to describe the concepts presented in this document are presented here.
此处介绍了描述本文件中所述概念所需的术语。
Address-translation mode -- A mode of gateway operation in which the scope of N_PORT fabric addresses, for locally attached devices, are local to the iFCP gateway region in which the devices reside.
地址转换模式——网关操作的一种模式，其中本地连接设备的N_端口结构地址范围位于设备所在的iFCP网关区域的本地。
Address-transparent mode -- A mode of gateway operation in which the scope of N_PORT fabric addresses, for all fibre channel devices, are unique to the bounded iFCP fabric to which the gateway belongs.
地址透明模式--网关操作的一种模式，其中所有光纤通道设备的N_端口结构地址的范围对于网关所属的有界iFCP结构是唯一的。
Bounded iFCP Fabric -- The union of two or more gateway regions configured to interoperate in address-transparent mode.
有界iFCP结构——配置为在地址透明模式下互操作的两个或多个网关区域的联合。
DOMAIN_ID -- The value contained in the high-order byte of a 24-bit N_PORT fibre channel address.
DOMAIN_ID—包含在24位N_端口光纤通道地址的高阶字节中的值。
F_PORT -- The interface used by an N_PORT to access fibre channel switched-fabric functionality.
F_端口—N_端口用于访问光纤通道交换结构功能的接口。
Fabric -- From [FC-FS]: "The entity that interconnects N_PORTs attached to it and is capable of routing frames by using only the address information in the fibre channel frame."
Fabric--From[FC-FS]：“连接连接到它的N_端口的实体，它能够通过仅使用光纤通道帧中的地址信息来路由帧。”
Fabric Port -- The interface through which an N_PORT accesses a fibre channel fabric. The type of fabric port depends on the fibre channel fabric topology. In this specification, all fabric port interfaces are considered functionally equivalent.
结构端口--N_端口访问光纤通道结构的接口。结构端口的类型取决于光纤通道结构拓扑。在本规范中，所有结构端口接口都被视为功能等效。
FC-2 -- The fibre channel transport services layer, described in [FC-FS].
FC-2—光纤通道传输服务层，如[FC-FS]所述。
FC-4 -- The fibre channel mapping of an upper-layer protocol, such as [FCP-2], the fibre channel to SCSI mapping.
FC-4——上层协议的光纤通道映射，如[FCP-2]，光纤通道到SCSI的映射。
Fibre Channel Device -- An entity implementing the functionality accessed through an FC-4 application protocol.
光纤通道设备——实现通过FC-4应用程序协议访问的功能的实体。
Fibre Channel Network -- A native fibre channel fabric and all attached fibre channel nodes.
光纤通道网络—本机光纤通道结构和所有连接的光纤通道节点。
Fibre Channel Node -- A collection of one or more N_PORTs controlled by a level above the FC-2 layer. A node is attached to a fibre channel fabric by means of the N_PORT interface, described in [FC-FS].
光纤通道节点--由FC-2层以上的级别控制的一个或多个N_端口的集合。节点通过N_端口接口连接到光纤通道结构，如[FC-FS]中所述。
Gateway Region -- The portion of an iFCP fabric accessed through an iFCP gateway by a remotely attached N_PORT. Fibre channel devices in the region consist of all those locally attached to the gateway.
网关区域——由远程连接的N_端口通过iFCP网关访问的iFCP结构部分。区域中的光纤通道设备由本地连接到网关的所有设备组成。
iFCP -- The protocol discussed in this document.
iFCP——本文档中讨论的协议。
iFCP Frame -- A fibre channel frame encapsulated in accordance with the FC Frame Encapsulation Specification [ENCAP] and this specification.
iFCP帧——根据FC帧封装规范[ENCAP]和本规范封装的光纤通道帧。
iFCP Portal -- An entity representing the point at which a logical or physical iFCP device is attached to the IP network. The network address of the iFCP portal consists of the IP address and TCP port number to which a request is sent when the TCP connection is created for an iFCP session (see Section 5.2.1).
iFCP门户--表示逻辑或物理iFCP设备连接到IP网络的点的实体。iFCP门户的网络地址由IP地址和TCP端口号组成，当为iFCP会话创建TCP连接时，请求将发送到IP地址和TCP端口号（参见第5.2.1节）。
iFCP Session -- An association comprised of a pair of N_PORTs and a TCP connection that carries traffic between them. An iFCP session may be created as the result of a PLOGI fibre channel login operation.
iFCP会话——由一对N_端口和在它们之间传输流量的TCP连接组成的关联。iFCP会话可以作为PLOGI光纤通道登录操作的结果创建。
iSNS -- The server functionality and IP protocol that provide storage name services in an iFCP network. Fibre channel name services are implemented by an iSNS name server, as described in [ISNS].
iSNS--在iFCP网络中提供存储名称服务的服务器功能和IP协议。光纤通道名称服务由iSNS名称服务器实现，如[iSNS]中所述。
Locally Attached Device -- With respect to a gateway, a fibre channel device accessed through the fibre channel fabric to which the gateway is attached.
本地连接设备——对于网关，指通过网关连接到的光纤通道结构访问的光纤通道设备。
Logical iFCP Device -- The abstraction representing a single fibre channel device as it appears on an iFCP network.
逻辑iFCP设备——表示单个光纤通道设备在iFCP网络上出现时的抽象。
N_PORT -- An iFCP or fibre channel entity representing the interface to fibre channel device functionality. This interface implements the fibre channel N_PORT semantics, specified in [FC-FS]. Fibre channel defines several variants of this interface that depend on the fibre channel fabric topology. As used in this document, the term applies equally to all variants.
N_PORT—表示光纤通道设备功能接口的iFCP或光纤通道实体。此接口实现[FC-FS]中指定的光纤通道N_端口语义。光纤通道定义了此接口的几个变体，这些变体取决于光纤通道结构拓扑。本文件中使用的术语同样适用于所有变体。
N_PORT Alias -- The N_PORT address assigned by a gateway to represent a remote N_PORT accessed via the iFCP protocol.
N_端口别名——网关分配的N_端口地址，表示通过iFCP协议访问的远程N_端口。
N_PORT fabric address -- The address of an N_PORT within the fibre channel fabric.
N_端口结构地址--光纤通道结构中N_端口的地址。
N_PORT ID -- The address of a locally attached N_PORT within a gateway region. N_PORT IDs are assigned in accordance with the fibre channel rules for address assignment, specified in [FC-FS].
N_端口ID—网关区域内本地连接的N_端口的地址。N_端口ID根据[FC-FS]中指定的光纤通道地址分配规则进行分配。
N_PORT Network Address -- The address of an N_PORT in the iFCP fabric. This address consists of the IP address and TCP port number of the iFCP Portal and the N_PORT ID of the locally attached fibre channel device.
N_端口网络地址——iFCP结构中N_端口的地址。此地址由iFCP入口的IP地址和TCP端口号以及本地连接的光纤通道设备的N_端口ID组成。
Port Login (PLOGI) -- The fibre channel Extended Link Service (ELS) that establishes an iFCP session through the exchange of identification and operation parameters between an originating N_PORT and a responding N_PORT.
端口登录（PLOGI）——光纤通道扩展链路服务（ELS），它通过在发起N_端口和响应N_端口之间交换标识和操作参数来建立iFCP会话。
Remotely Attached Device -- With respect to a gateway, a fibre channel device accessed from the gateway by means of the iFCP protocol.
远程连接设备——对于网关，指通过iFCP协议从网关访问的光纤通道设备。
Unbounded iFCP Fabric -- The union of two or more gateway regions configured to interoperate in address-translation mode.
无界iFCP结构——配置为在地址转换模式下互操作的两个或多个网关区域的联合。
Fibre channel is a frame-based, serial technology designed for peer-to-peer communication between devices at gigabit speeds and with low overhead and latency.
光纤通道是一种基于帧的串行技术，设计用于以千兆速度、低开销和低延迟在设备之间进行对等通信。
This section contains a discussion of the fibre channel concepts that form the basis for the iFCP network architecture and protocol described in this document. Readers familiar with this material may skip to Section 4.
本节讨论构成本文档中所述iFCP网络体系结构和协议基础的光纤通道概念。熟悉本材料的读者可跳至第4节。
Material presented in this section is drawn from the following T11 specifications:
本节中提供的材料取自以下T11规范：
-- The Fibre Channel Framing and Signaling Interface, [FC-FS]
--光纤通道成帧和信令接口[FC-FS]
-- Fibre Channel Switch Fabric -2, [FC-SW2]
--光纤通道交换机结构-2，[FC-SW2]
-- Fibre Channel Generic Services, [FC-GS3]
--光纤通道通用服务[FC-GS3]
-- Fibre Channel Fabric Loop Attachment, [FC-FLA]
--光纤通道结构环路连接，[FC-FLA]
The reader will find an in-depth treatment of the technology in [KEMCMP] and [KEMALP].
读者将在[KEMCMP]和[KEMALP]中找到对该技术的深入介绍。
The fundamental entity in fibre channel is the fibre channel network. Unlike a layered network architecture, a fibre channel network is largely specified by functional elements and the interfaces between them. As shown in Figure 1, these consist, in part, of the following:
光纤通道中的基本实体是光纤通道网络。与分层网络体系结构不同，光纤通道网络主要由功能元素及其之间的接口指定。如图1所示，这些部分包括以下内容：
a) N_PORTs -- The end points for fibre channel traffic. In the FC standards, N_PORT interfaces have several variants, depending on the topology of the fabric to which they are attached. As used in this specification, the term applies to any one of the variants.
a) N_端口--光纤通道流量的端点。在FC标准中，N_端口接口有几种变体，具体取决于它们所连接的结构的拓扑。本规范中使用的术语适用于任何一种变体。
b) FC Devices -- The fibre channel devices to which the N_PORTs provide access.
b) FC设备—N_端口提供访问的光纤通道设备。
c) Fabric Ports -- The interfaces within a fibre channel network that provide attachment for an N_PORT. The types of fabric port depend on the fabric topology and are discussed in Section 3.2.
c) 结构端口--光纤通道网络中为N_端口提供连接的接口。结构端口的类型取决于结构拓扑，将在第3.2节中讨论。
d) The network infrastructure for carrying frame traffic between N_PORTs.
d) 在N_端口之间承载帧通信的网络基础设施。
e) Within a switched or mixed fabric (see Section 3.2), a set of auxiliary servers, including a name server for device discovery and network address resolution. The types of service depend on the network topology.
e) 在交换或混合结构中（参见第3.2节），一组辅助服务器，包括用于设备发现和网络地址解析的名称服务器。服务类型取决于网络拓扑。
+--------+ +--------+ +--------+ +--------+
| FC | | FC | | FC | | FC |
| Device | | Device |<-------->| Device | | Device |
|........| |........| |........| |........|
| N_PORT | | N_PORT | | N_PORT | | N_PORT |
+---+----+ +----+---+ +----+---+ +----+---+
| | | |
+---+----+ +----+---+ +----+---+ +----+---+
| Fabric | | Fabric | | Fabric | | Fabric |
| Port | | Port | | Port | | Port |
+========+===+========+==========+========+==+========+
| Fabric |
| & |
| Fabric Services |
+-----------------------------------------------------+
+--------+ +--------+ +--------+ +--------+
| FC | | FC | | FC | | FC |
| Device | | Device |<-------->| Device | | Device |
|........| |........| |........| |........|
| N_PORT | | N_PORT | | N_PORT | | N_PORT |
+---+----+ +----+---+ +----+---+ +----+---+
| | | |
+---+----+ +----+---+ +----+---+ +----+---+
| Fabric | | Fabric | | Fabric | | Fabric |
| Port | | Port | | Port | | Port |
+========+===+========+==========+========+==+========+
| Fabric |
| & |
| Fabric Services |
+-----------------------------------------------------+
Figure 1. A Fibre Channel Network
图1。光纤通道网络
The following sections describe fibre channel network topologies and give an overview of the fibre channel communications model.
以下各节介绍光纤通道网络拓扑，并概述光纤通道通信模型。
The principal fibre channel network topologies consist of the following:
主要光纤通道网络拓扑包括以下内容：
a) Arbitrated Loop -- A series of N_PORTs connected together in daisy-chain fashion. In [FC-FS], loop-connected N_PORTs are referred to as NL_PORTs. Data transmission between NL_PORTs requires arbitration for control of the loop in a manner similar to that of a token ring network.
a) 仲裁环路——以菊花链方式连接在一起的一系列N_端口。在[FC-FS]中，环路连接的N_端口称为NL_端口。NL_端口之间的数据传输需要仲裁，以类似于令牌环网的方式控制环路。
b) Switched Fabric -- A network consisting of switching elements, as described in Section 3.2.1.
b) 交换结构——由交换元件组成的网络，如第3.2.1节所述。
c) Mixed Fabric -- A network consisting of switches and "fabric-attached" loops. A description can be found in [FC-FLA]. A loop-attached N_PORT (NL_PORT) is connected to the loop through an L_PORT and accesses the fabric by way of an FL_PORT.
c) 混合结构——由交换机和“结构连接”环路组成的网络。有关说明，请参见[FC-FLA]。环路连接的N_端口（NL_端口）通过L_端口连接到环路，并通过FL_端口访问结构。
Depending on the topology, the N_PORT and its means of network attachment may be one of the following:
根据拓扑结构，N_端口及其网络连接方式可能是以下之一：
FC Network
Topology Network Interface N_PORT Variant
--------------- ----------------- --------------
Loop L_PORT NL_PORT
FC Network
Topology Network Interface N_PORT Variant
--------------- ----------------- --------------
Loop L_PORT NL_PORT
Switched F_PORT N_PORT
交换F_端口N_端口
Mixed FL_PORT via L_PORT NL_PORT
通过L_端口NL_端口的混合FL_端口
F_PORT N_PORT
F_端口N_端口
The differences in each N_PORT variant and its corresponding fabric port are confined to the interactions between them. To an external N_PORT, all fabric ports are transparent, and all remote N_PORTs are functionally identical.
每个N_端口变体及其对应的结构端口之间的差异仅限于它们之间的相互作用。对于外部N_端口，所有结构端口都是透明的，所有远程N_端口在功能上都是相同的。
An example of a multi-switch fibre channel fabric is shown in Figure 2.
多交换机光纤通道结构的示例如图2所示。
+----------+ +----------+
| FC | | FC |
| Device | | Device |
|..........| |..........|
| N_PORT |<........>| N_PORT |
+----+-----+ +-----+----+
| |
+----+-----+ +-----+----+
| F_PORT | | F_PORT |
==========+==========+==========+==========+==============
| FC | | FC |
| Switch | | Switch |
+----------+ +----------+ Fibre Channel
|Inter- | |Inter- | Fabric
|Switch | |Switch |
|Interface | |Interface |
+-----+----+ +-----+----+
| |
| |
+-----+----+----------+-----+----+
|Inter- | |Inter- |
|Switch | |Switch |
|Interface | |Interface |
+----------+ +----------+
| FC Switch |
| |
+--------------------------------+
+----------+ +----------+
| FC | | FC |
| Device | | Device |
|..........| |..........|
| N_PORT |<........>| N_PORT |
+----+-----+ +-----+----+
| |
+----+-----+ +-----+----+
| F_PORT | | F_PORT |
==========+==========+==========+==========+==============
| FC | | FC |
| Switch | | Switch |
+----------+ +----------+ Fibre Channel
|Inter- | |Inter- | Fabric
|Switch | |Switch |
|Interface | |Interface |
+-----+----+ +-----+----+
| |
| |
+-----+----+----------+-----+----+
|Inter- | |Inter- |
|Switch | |Switch |
|Interface | |Interface |
+----------+ +----------+
| FC Switch |
| |
+--------------------------------+
Figure 2. Multi-Switch Fibre Channel Fabric
图2。多交换机光纤通道结构
The interface between switch elements is either a proprietary interface or the standards-compliant E_PORT interface, which is described by the FC-SW2 specification, [FC-SW2].
交换机元件之间的接口为专有接口或符合标准的E_端口接口，如FC-SW2规范[FC-SW2]所述。
A mixed fabric contains one or more arbitrated loops connected to a switched fabric as shown in Figure 3.
混合结构包含一个或多个连接到交换结构的仲裁环，如图3所示。
+----------+ +----------+ +---------+
| FC | | FC | | FC |
| Device | | Device | | Device |
|..........| FC |..........| |.........|
| N_PORT |<........>| NL_PORT +---+ NL_PORT |
+----+-----+ Traffic +-----+----+ +----+----+
| | FC Loop |
+----+-----+ +-----+----+ |
| F_PORT | | FL_PORT +--------+
| | | |
==========+==========+==========+==========+==============
| FC | | FC |
| Switch | | Switch |
+----------+ +----------+
|Inter- | |Inter- |
|Switch | |Switch |
|Interface | |Interface |
+-----+----+ +-----+----+
| |
| |
+-----+----+----------+-----+----+
|Inter- | |Inter- |
|Switch | |Switch |
|Interface | |Interface |
+----------+ +----------+
| FC Switch |
| |
+--------------------------------+
+----------+ +----------+ +---------+
| FC | | FC | | FC |
| Device | | Device | | Device |
|..........| FC |..........| |.........|
| N_PORT |<........>| NL_PORT +---+ NL_PORT |
+----+-----+ Traffic +-----+----+ +----+----+
| | FC Loop |
+----+-----+ +-----+----+ |
| F_PORT | | FL_PORT +--------+
| | | |
==========+==========+==========+==========+==============
| FC | | FC |
| Switch | | Switch |
+----------+ +----------+
|Inter- | |Inter- |
|Switch | |Switch |
|Interface | |Interface |
+-----+----+ +-----+----+
| |
| |
+-----+----+----------+-----+----+
|Inter- | |Inter- |
|Switch | |Switch |
|Interface | |Interface |
+----------+ +----------+
| FC Switch |
| |
+--------------------------------+
Figure 3. Mixed Fibre Channel Fabric
图3。混合光纤通道结构
As noted previously, the protocol for communications between peer N_PORTs is independent of the fabric topology, N_PORT variant, and type of fabric port to which an N_PORT is attached.
如前所述，对等N_端口之间的通信协议独立于结构拓扑、N_端口变体和连接N_端口的结构端口类型。
A fibre channel consists of the following layers:
光纤通道由以下层组成：
FC-0 -- The interface to the physical media.
FC-0——与物理介质的接口。
FC-1 -- The encoding and decoding of data and out-of-band physical link control information for transmission over the physical media.
FC-1——用于在物理介质上传输的数据和带外物理链路控制信息的编码和解码。
FC-2 -- The transfer of frames, sequences, and Exchanges comprising protocol information units.
FC-2——包括协议信息单元的帧、序列和交换的传输。
FC-3 -- Common Services.
FC-3——共同事务。
FC-4 -- Application protocols such as the fibre channel protocol for SCSI (FCP).
FC-4—应用程序协议，如SCSI光纤通道协议（FCP）。
In addition to the layers defined above, a fibre channel defines a set of auxiliary operations, some of which are implemented within the transport layer fabric, called link services. These are required in order to manage the fibre channel environment, establish communications with other devices, retrieve error information, perform error recovery, and provide other similar services. Some link services are executed by the N_PORT. Others are implemented internally within the fabric. These internal services are described in the next section.
除了上面定义的层之外，光纤通道还定义了一组辅助操作，其中一些操作在传输层结构中实现，称为链路服务。为了管理光纤通道环境、建立与其他设备的通信、检索错误信息、执行错误恢复以及提供其他类似服务，这些都是必需的。某些链路服务由N_端口执行。其他的则在结构内部实现。下一节将介绍这些内部服务。
Servers that are internal to a switched fabric handle certain classes of Link Service requests and service-specific commands. The servers appear as N_PORTs located at the 'well-known' N_PORT fabric addresses specified in [FC-FS]. Service requests use the standard fibre channel mechanisms for N_PORT-to-N_PORT communications.
交换结构内部的服务器处理特定类别的链路服务请求和特定于服务的命令。服务器显示为N_端口，位于[FC-FS]中指定的“已知”N_端口结构地址。服务请求使用标准光纤通道机制进行N_端口到N_端口通信。
All switched fabrics must provide the following services:
所有交换结构必须提供以下服务：
Fabric F_PORT server -- Services N_PORT requests to access the fabric for communications.
结构F_端口服务器——服务N_端口请求以访问结构进行通信。
Fabric Controller -- Provides state change information to inform other FC devices when an N_PORT exits or enters the fabric (see Section 3.5).
结构控制器——提供状态更改信息，以便在N_端口退出或进入结构时通知其他FC设备（请参阅第3.5节）。
Directory/Name Server - Allows N_PORTs to register information in a database, retrieve information about other N_PORTs, and to discover other devices as described in Section 3.5.
目录/名称服务器-允许N_端口在数据库中注册信息，检索有关其他N_端口的信息，并发现第3.5节中描述的其他设备。
A switched fabric may also implement the following optional services:
交换结构还可以实现以下可选服务：
Broadcast Address/Server -- Transmits single-frame, class 3 sequences to all N_PORTs.
广播地址/服务器——将单帧3级序列传输到所有N_端口。
Time Server -- Intended for the management of fabric-wide expiration timers or elapsed time values; not intended for precise time synchronization.
时间服务器——用于管理结构范围的过期计时器或已用时间值；不用于精确的时间同步。
Management Server - Collects and reports management information, such as link usage, error statistics, link quality, and similar items.
管理服务器-收集和报告管理信息，如链接使用情况、错误统计、链接质量和类似项目。
Quality of Service Facilitator - Performs fabric-wide bandwidth and latency management.
服务质量促进者-执行结构宽带和延迟管理。
A fibre channel node has one or more fabric-attached N_PORTs. The node and its N_PORTs have the following associated identifiers:
光纤通道节点具有一个或多个连接到结构的N_端口。节点及其N_端口具有以下关联标识符：
a) A worldwide-unique identifier for the node.
a) 节点的全球唯一标识符。
b) A worldwide-unique identifier for each N_PORT associated with the node.
b) 与节点关联的每个N_端口的全球唯一标识符。
c) For each N_PORT attached to a fabric, a 24-bit fabric-unique address with the properties defined in Section 3.7.1. The fabric address is the address to which frames are sent.
c) 对于连接到结构的每个N_端口，一个具有第3.7.1节中定义的属性的24位结构唯一地址。结构地址是帧发送到的地址。
Each worldwide-unique identifier is a 64-bit binary quantity with the format defined in [FC-FS].
每个全球唯一标识符都是一个64位二进制量，其格式在[FC-FS]中定义。
In a switched or mixed fabric, fibre channel devices and changes in the device configuration may be discovered by means of services provided by the fibre channel Name Server and Fabric Controller.
在交换或混合结构中，可以通过光纤通道名称服务器和结构控制器提供的服务来发现光纤通道设备和设备配置中的更改。
The Name Server provides registration and query services that allow a fibre channel device to register its presence on the fabric and to discover the existence of other devices. For example, one type of query obtains the fabric address of an N_PORT from its 64-bit worldwide-unique name. The full set of supported fibre channel name server queries is specified in [FC-GS3].
名称服务器提供注册和查询服务，允许光纤通道设备注册其在结构上的存在并发现其他设备的存在。例如，一种查询类型从N_端口的64位全球唯一名称获取其结构地址。[FC-GS3]中指定了受支持的全套光纤通道名称服务器查询。
The Fabric Controller complements the static discovery capabilities provided by the Name Server through a service that dynamically alerts a fibre channel device whenever an N_PORT is added or removed from the configuration. A fibre channel device receives these notifications by subscribing to the service as specified in [FC-FS].
结构控制器通过一项服务补充名称服务器提供的静态发现功能，该服务可在配置中添加或删除N_端口时动态提醒光纤通道设备。光纤通道设备通过订阅[FC-FS]中指定的服务来接收这些通知。
The fundamental element of information in fibre channel is the frame. A frame consists of a fixed header and up to 2112 bytes of payload with the structure described in Section 3.7. The maximum frame size that may be transmitted between a pair of fibre channel devices is negotiable up to the payload limit, based on the size of the frame buffers in each fibre channel device and the path maximum transmission unit (MTU) supported by the fabric.
光纤通道中信息的基本元素是帧。帧由一个固定的报头和最多2112字节的有效载荷组成，其结构如第3.7节所述。基于每个光纤通道设备中帧缓冲区的大小和结构支持的路径最大传输单元（MTU），可在一对光纤通道设备之间传输的最大帧大小可协商到有效负载限制。
Operations involving the transfer of information between N_PORT pairs are performed through 'Exchanges'. In an Exchange, information is transferred in one or more ordered series of frames, referred to as Sequences.
涉及N_端口对之间信息传输的操作通过“交换”执行。在交换中，信息在一个或多个有序的帧序列（称为序列）中传输。
Within this framework, an upper layer protocol is defined in terms of transactions carried by Exchanges. In turn, each transaction consists of protocol information units, each of which is carried by an individual Sequence within an Exchange.
在这个框架内，上层协议是根据交易所进行的交易定义的。反过来，每个事务都由协议信息单元组成，每个协议信息单元由一个交换中的单个序列携带。
A fibre channel frame consists of a header, payload and 32-bit CRC bracketed by SOF and EOF delimiters. The header contains the control information necessary to route frames between N_PORTs and manage Exchanges and Sequences. The following diagram gives a schematic view of the frame.
光纤通道帧由标头、有效负载和32位CRC组成，CRC由SOF和EOF分隔符括起。标头包含在N_端口之间路由帧和管理交换和序列所需的控制信息。下图给出了框架的示意图。
Bit 0 31
+-----------------------------+
Word 0 | Start-of-frame Delimiter |
+-----+-----------------------+<----+
| | Destination N_PORT | |
1 | | Fabric Address (D_ID) | |
| | (24 bits) | |
+-----+-----------------------+ 24-byte
| | Source N_PORT | Frame
2 | | Fabric Address (S_ID) | Header
| | (24 bits) | |
+-----+-----------------------+ |
3 | Control information for | |
. | frame type, Exchange | |
. | management, IU | |
. | segmentation and | |
6 | re-assembly | |
+-----------------------------+<----+
7 | |
. | Frame payload |
. | (0 - 2112 bytes) |
. | |
. | |
. | |
+-----------------------------+
. | CRC |
+-----------------------------+
n | End-of-Frame Delimiter |
+-----------------------------+
Bit 0 31
+-----------------------------+
Word 0 | Start-of-frame Delimiter |
+-----+-----------------------+<----+
| | Destination N_PORT | |
1 | | Fabric Address (D_ID) | |
| | (24 bits) | |
+-----+-----------------------+ 24-byte
| | Source N_PORT | Frame
2 | | Fabric Address (S_ID) | Header
| | (24 bits) | |
+-----+-----------------------+ |
3 | Control information for | |
. | frame type, Exchange | |
. | management, IU | |
. | segmentation and | |
6 | re-assembly | |
+-----------------------------+<----+
7 | |
. | Frame payload |
. | (0 - 2112 bytes) |
. | |
. | |
. | |
+-----------------------------+
. | CRC |
+-----------------------------+
n | End-of-Frame Delimiter |
+-----------------------------+
Figure 4. Fibre Channel Frame Format
图4。光纤通道帧格式
The source and destination N_PORT fabric addresses embedded in the S_ID and D_ID fields represent the physical addresses of originating and receiving N_PORTs, respectively.
嵌入在S_ID和D_ID字段中的源和目标N_端口结构地址分别表示发起和接收N_端口的物理地址。
N_PORT fabric addresses are 24-bit values with the following format, defined by the fibre channel specification [FC-FS]:
N_端口结构地址是由光纤通道规范[FC-FS]定义的具有以下格式的24位值：
Bit 0 7 8 15 16 23
+-----------+------------+----------+
| Domain ID | Area ID | Port ID |
+-----------+------------+----------+
Bit 0 7 8 15 16 23
+-----------+------------+----------+
| Domain ID | Area ID | Port ID |
+-----------+------------+----------+
Figure 5. Fibre Channel Address Format
图5。光纤通道地址格式
A fibre channel device acquires an address when it logs into the fabric. Such addresses are volatile and subject to change based on modifications in the fabric configuration.
光纤通道设备在登录到结构时获取地址。这些地址是不稳定的，并且会根据结构配置中的修改进行更改。
In a fibre channel fabric, each switch element has a unique Domain ID assigned by the principal switch. The value of the Domain ID ranges from 1 to 239 (0xEF). Each switch element, in turn, administers a block of addresses divided into area and port IDs. An N_PORT connected to an F_PORT receives a unique fabric address, consisting of the switch's Domain ID concatenated with switch-assigned area and port IDs.
在光纤通道结构中，每个交换机元素都有一个由主交换机分配的唯一域ID。域ID的值范围为1到239（0xEF）。每个交换机元素依次管理一个地址块，地址块分为区域ID和端口ID。连接到F_端口的N_端口接收唯一的结构地址，该地址由交换机的域ID与交换机分配的区域和端口ID连接而成。
A loop-attached NL_PORT (see Figure 3) obtains the Port ID component of its address during the loop initialization process described in [FC-AL2]. The area and domain IDs are supplied by the fabric when the fabric login (FLOGI) is executed.
循环连接的NL_端口（见图3）在[FC-AL2]中描述的循环初始化过程中获取其地址的端口ID组件。当执行结构登录（FLOGI）时，结构提供区域和域ID。
N_PORTs communicate by means of the following classes of service, which are specified in the fibre channel standard ([FC-FS]):
N_端口通过光纤通道标准（[FC-FS]）中指定的以下服务类别进行通信：
Class 1 - A dedicated physical circuit connecting two N_PORTs.
1类-连接两个N_端口的专用物理电路。
Class 2 - A frame-multiplexed connection with end-to-end flow control and delivery confirmation.
2类-具有端到端流量控制和交付确认的帧多路复用连接。
Class 3 - A frame-multiplexed connection with no provisions for end-to-end flow control or delivery confirmation.
3级-帧多路复用连接，不提供端到端流量控制或交付确认。
Class 4 -- A connection-oriented service, based on a virtual circuit model, providing confirmed delivery with bandwidth and latency guarantees.
类别4——基于虚拟电路模型的面向连接的服务，提供带宽和延迟保证的确认交付。
Class 6 -- A reliable multicast service derived from class 1.
类6——从类1派生的可靠多播服务。
Classes 2 and 3 are the predominant services supported by deployed fibre channel storage and clustering systems.
第2类和第3类是部署的光纤通道存储和群集系统支持的主要服务。
Class 3 service is similar to UDP or IP datagram service. Fibre channel storage devices using this class of service rely on the ULP implementation to detect and recover from transient device and transport errors.
第3类服务类似于UDP或IP数据报服务。使用此类服务的光纤通道存储设备依靠ULP实现来检测瞬时设备和传输错误并从中恢复。
For class 2 and class 3 service, the fibre channel fabric is not required to provide in-order delivery of frames unless it is explicitly requested by the frame originator (and supported by the fabric). If ordered delivery is not in effect, it is the
对于第2类和第3类服务，光纤通道结构不需要提供按顺序交付的帧，除非帧发起人明确要求（并由结构支持）。如果订单交付无效，则为
responsibility of the frame recipient to reconstruct the order in which frames were sent, based on information in the frame header.
帧接收者根据帧头中的信息重建帧发送顺序的责任。
The Login processes are FC-2 operations that allow an N_PORT to establish the operating environment necessary to communicate with the fabric, other N_PORTs, and ULP implementations accessed via the N_PORT. Three login operations are supported:
登录过程是FC-2操作，允许N_端口建立与结构、其他N_端口和通过N_端口访问的ULP实现通信所需的操作环境。支持三种登录操作：
a) Fabric Login (FLOGI) -- An operation whereby the N_PORT registers its presence on the fabric, obtains fabric parameters, such as classes of service supported, and receives its N_PORT address,
a) 结构登录（FLOGI）——一种操作，其中N_端口在结构上注册其存在，获取结构参数，如支持的服务类，并接收其N_端口地址，
b) Port Login (PLOGI) -- An operation by which an N_PORT establishes communication with another N_PORT.
b) 端口登录（PLOGI）——一个N_端口与另一个N_端口建立通信的操作。
c) Process Login (PRLOGI) -- An operation that establishes the process-to-process communications associated with a specific FC-4 ULP, such as FCP-2, the fibre channel SCSI mapping.
c) 进程登录（PRLOGI）——建立与特定FC-4 ULP（如光纤通道SCSI映射FCP-2）相关联的进程到进程通信的操作。
Since N_PORT addresses are volatile, an N_PORT originating a login (PLOGI) operation executes a Name Server query to discover the fibre channel address of the remote device. A common query type involves use of the worldwide-unique name of an N_PORT to obtain the 24-bit N_PORT fibre channel address to which the PLOGI request is sent.
由于N_端口地址是可变的，因此发起登录（PLOGI）操作的N_端口会执行名称服务器查询，以发现远程设备的光纤通道地址。常见的查询类型包括使用N_端口的全球唯一名称来获取PLOGI请求发送到的24位N_端口光纤通道地址。
The iFCP protocol enables the implementation of fibre channel fabric functionality on an IP network in which IP components and technology replace the fibre channel switching and routing infrastructure described in Section 3.2.
iFCP协议支持在IP网络上实现光纤通道结构功能，其中IP组件和技术取代了第3.2节所述的光纤通道交换和路由基础设施。
The example of Figure 6 shows a fibre channel network with attached devices. Each device accesses the network through an N_PORT connected to an interface whose behavior is specified in [FC-FS] or [FC-AL2]. In this case, the N_PORT represents any of the variants described in Section 3.2. The interface to the fabric may be an L_PORT, F_PORT, or FL_PORT.
图6的示例显示了带有连接设备的光纤通道网络。每个设备通过一个N_端口访问网络，该端口连接到一个接口，该接口的行为在[FC-FS]或[FC-AL2]中有规定。在这种情况下，N_端口表示第3.2节中描述的任何变体。结构的接口可以是L_端口、F_端口或FL_端口。
Within the fibre channel device domain, addressable entities consist of other N_PORTs and fibre channel devices internal to the network that perform the fabric services defined in [FC-GS3].
在光纤通道设备域内，可寻址实体由网络内部的其他N_端口和光纤通道设备组成，这些设备执行[FC-GS3]中定义的结构服务。
Fibre Channel Network
+--------+ +--------+
| FC | | FC |
| Device | | Device |
|........| FC |........| Fibre Channel
| N_PORT |<......>| N_PORT | Device Domain
+---+----+ Traffic+----+---+ ^
| | |
+---+----+ +----+---+ |
| Fabric | | Fabric | |
| Port | | Port | |
==========+========+========+========+==============
| FC Network & | |
| Fabric Services | v
| | Fibre Channel
+--------------------------+ Network Domain
Fibre Channel Network
+--------+ +--------+
| FC | | FC |
| Device | | Device |
|........| FC |........| Fibre Channel
| N_PORT |<......>| N_PORT | Device Domain
+---+----+ Traffic+----+---+ ^
| | |
+---+----+ +----+---+ |
| Fabric | | Fabric | |
| Port | | Port | |
==========+========+========+========+==============
| FC Network & | |
| Fabric Services | v
| | Fibre Channel
+--------------------------+ Network Domain
Figure 6. A Fibre Channel Network
图6。光纤通道网络
Gateway Region Gateway Region
+--------+ +--------+ +--------+ +--------+
| FC | | FC | | FC | | FC |
| Device | | Device | | Device | | Device | Fibre
|........| |........| FC |........| |........| Channel
| N_PORT | | N_PORT |<.........>| N_PORT | | N_PORT | Device
+---+----+ +---+----+ Traffic +----+---+ +----+---+ Domain
| | | | ^
+---+----+ +---+----+ +----+---+ +----+---+ |
| F_PORT | | F_PORT | | F_PORT | | F_PORT | |
=+========+==+========+===========+========+==+========+==========
| iFCP Layer |<--------->| iFCP Layer | |
|....................| ^ |....................| |
| iFCP Portal | | | iFCP Portal | v
+--------+-----------+ | +----------+---------+ IP
iFCP|Gateway Control iFCP|Gateway Network
| Data |
| |
| |
|<------Encapsulated Frames------->|
| +------------------+ |
| | | |
+------+ IP Network +--------+
| |
+------------------+
Gateway Region Gateway Region
+--------+ +--------+ +--------+ +--------+
| FC | | FC | | FC | | FC |
| Device | | Device | | Device | | Device | Fibre
|........| |........| FC |........| |........| Channel
| N_PORT | | N_PORT |<.........>| N_PORT | | N_PORT | Device
+---+----+ +---+----+ Traffic +----+---+ +----+---+ Domain
| | | | ^
+---+----+ +---+----+ +----+---+ +----+---+ |
| F_PORT | | F_PORT | | F_PORT | | F_PORT | |
=+========+==+========+===========+========+==+========+==========
| iFCP Layer |<--------->| iFCP Layer | |
|....................| ^ |....................| |
| iFCP Portal | | | iFCP Portal | v
+--------+-----------+ | +----------+---------+ IP
iFCP|Gateway Control iFCP|Gateway Network
| Data |
| |
| |
|<------Encapsulated Frames------->|
| +------------------+ |
| | | |
+------+ IP Network +--------+
| |
+------------------+
Figure 7. An iFCP Fabric Example
图7。iFCP结构示例
One example of an equivalent iFCP fabric is shown in Figure 7. The fabric consists of two gateway regions, each accessed by a single iFCP gateway.
图7显示了等效iFCP结构的一个示例。该结构由两个网关区域组成，每个区域由单个iFCP网关访问。
Each gateway contains two standards-compliant F_PORTs and an iFCP Portal for attachment to the IP network. Fibre channel devices in the region are those locally connected to the iFCP fabric through the gateway fabric ports.
每个网关包含两个符合标准的F_端口和一个用于连接到IP网络的iFCP入口。区域中的光纤通道设备是通过网关结构端口本地连接到iFCP结构的设备。
Looking into the fabric port, the gateway appears as a fibre channel switch element. At this interface, remote N_PORTs are presented as fabric-attached devices. Conversely, on the IP network side, the gateway presents each locally connected N_PORT as a logical fibre channel device.
查看结构端口，网关显示为光纤通道交换机元素。在此接口上，远程N_端口作为连接到结构的设备显示。相反，在IP网络端，网关将每个本地连接的N_端口表示为逻辑光纤通道设备。
Extrapolating to the general case, each gateway region behaves like an autonomous system whose configuration is invisible to the IP network and other gateway regions. Consequently, in addition to the F_PORT shown in the example, a gateway implementation may transparently support the following fibre channel interfaces:
根据一般情况推断，每个网关区域的行为类似于自治系统，其配置对IP网络和其他网关区域不可见。因此，除了示例中所示的F_端口外，网关实现还可以透明地支持以下光纤通道接口：
Inter-Switch Link -- A fibre channel switch-to-switch interface used to access a region containing fibre channel switch elements. An implementation may support the E_PORT defined by [FC-SW2] or one of the proprietary interfaces provided by various fibre channel switch vendors. In this case, the gateway acts as a border switch connecting the gateway region to the IP network.
交换机间链路--用于访问包含光纤通道交换机元素的区域的光纤通道交换机到交换机接口。实现可能支持[FC-SW2]定义的E_端口或各种光纤通道交换机供应商提供的专有接口之一。在这种情况下，网关充当将网关区域连接到IP网络的边界交换机。
FL_PORT -- An interface that provides fabric access for loop-attached fibre channel devices, as specified in [FC-FLA].
FL_端口——为环路连接光纤通道设备提供结构访问的接口，如[FC-FLA]中所述。
L_PORT -- An interface through which a gateway may emulate the fibre channel loop environment specified in [FC-AL2]. As discussed in appendix B, the gateway presents remotely accessed N_PORTS as loop-attached devices.
L_端口——网关可通过其模拟[FC-AL2]中指定的光纤通道环路环境的接口。如附录B所述，网关将远程访问的N_端口表示为环路连接设备。
The manner in which these interfaces are provided by a gateway is implementation specific and therefore beyond the scope of this document.
网关提供这些接口的方式是特定于实现的，因此超出了本文档的范围。
Although each region is connected to the IP network through one gateway, a region may incorporate multiple gateways for added performance and fault tolerance if the following conditions are met:
尽管每个区域通过一个网关连接到IP网络，但如果满足以下条件，则一个区域可以包含多个网关以提高性能和容错性：
a) The gateways MUST coordinate the assignment of N_PORT IDs and aliases so that each N_PORT has one and only one address.
a) 网关必须协调N_端口ID和别名的分配，以便每个N_端口只有一个地址。
b) All iFCP traffic between a given remote and local N_PORT pair MUST flow through the same iFCP session (see Section 5.2.1). However, iFCP sessions to a given remotely attached N_PORT need not traverse the same gateway.
b) 给定远程和本地N_端口对之间的所有iFCP流量必须通过相同的iFCP会话（见第5.2.1节）。但是，到给定远程连接N_端口的iFCP会话不需要穿过同一网关。
Coordinating address assignments and managing the flow of traffic is implementation specific and outside the scope of this specification.
协调地址分配和管理流量是特定于实现的，不在本规范的范围内。
N_PORT to N_PORT communications that traverse a TCP/IP network require the intervention of the iFCP layer within the gateway. This consists of the following operations:
穿越TCP/IP网络的N_端口到N_端口通信需要网关内的iFCP层的干预。这包括以下操作：
a) Execution of the frame-addressing and -mapping functions described in Section 4.4.
a) 执行第4.4节中描述的帧寻址和映射功能。
b) Encapsulation of fibre channel frames for injection into the TCP/IP network and de-encapsulation of fibre channel frames received from the TCP/IP network.
b) 封装光纤通道帧以注入TCP/IP网络，并解除从TCP/IP网络接收的光纤通道帧的封装。
c) Establishment of an iFCP session in response to a PLOGI directed to a remote device.
c) 建立iFCP会话以响应指向远程设备的PLOGI。
Section 4.4 discusses the iFCP frame-addressing mechanism and the way that it is used to achieve communications transparency between N_PORTs.
第4.4节讨论了iFCP帧寻址机制及其用于实现N_端口之间通信透明的方式。
An iFCP fabric supports Class 2 and Class 3 fibre channel transport services, as specified in [FC-FS]. An iFCP fabric does not support Class 4, Class 6, or Class 1 (dedicated connection) service. An N_PORT discovers the classes of transport services supported by the fabric during fabric login.
iFCP结构支持[FC-FS]中规定的第2类和第3类光纤通道传输服务。iFCP结构不支持4级、6级或1级（专用连接）服务。N_端口在结构登录期间发现结构支持的传输服务类。
An iFCP implementation performs device discovery and iFCP fabric management through the Internet Storage Name Service defined in [ISNS]. Access to an iSNS server is required to perform the following functions:
iFCP实现通过[ISNS]中定义的Internet存储名称服务执行设备发现和iFCP结构管理。需要访问iSNS服务器才能执行以下功能：
a) Emulate the services provided by the fibre channel name server described in Section 3.3.1, including a mechanism for asynchronously notifying an N_PORT of changes in the iFCP fabric configuration.
a) 模拟第3.3.1节中描述的光纤通道名称服务器提供的服务，包括异步通知N_端口iFCP结构配置更改的机制。
b) Aggregate gateways into iFCP fabrics for interoperation.
b) 将网关聚合到iFCP结构中以实现互操作。
c) Segment an iFCP fabric into fibre channel zones through the definition and management of device discovery scopes, referred to as 'discovery domains'.
c) 通过定义和管理设备发现范围（称为“发现域”），将iFCP结构分为光纤通道区域。
d) Store and distribute security policies, as described in Section 10.2.9.
d) 存储和分发安全策略，如第10.2.9节所述。
e) Implementation of the fibre channel broadcast mechanism.
e) 光纤通道广播机制的实现。
A collection of iFCP gateways may be configured for interoperation as either a bounded or an unbounded iFCP fabric.
可以将iFCP网关集合配置为有界或无界iFCP结构，以实现互操作。
Gateways in a bounded iFCP fabric operate in address transparent mode, as described in Section 4.5. In this mode, the scope of a fibre channel N_PORT address is fabric-wide and is derived from domain IDs issued by the iSNS server from a common pool. As discussed in Section 4.3.2, the maximum number of domain IDs allowed by the fibre channel limits the configuration of a bounded iFCP fabric.
有界iFCP结构中的网关以地址透明模式运行，如第4.5节所述。在此模式下，光纤通道N_端口地址的作用域为结构范围，并从iSNS服务器从公共池发出的域ID派生。如第4.3.2节所述，光纤通道允许的最大域ID数限制了有界iFCP结构的配置。
Gateways in an unbounded iFCP fabric operate in address translation mode as described in Section 4.6. In this mode, the scope of an N_PORT address is local to a gateway region. For fibre channel traffic between regions, the translation of frame-embedded N_PORT addresses is performed by the gateway. As discussed below, the number of switch elements and gateways in an unbounded iFCP fabric may exceed the limits of a conventional fibre channel fabric.
无界iFCP结构中的网关在地址转换模式下运行，如第4.6节所述。在此模式下，N_端口地址的范围是网关区域的本地范围。对于区域之间的光纤通道通信，帧嵌入N_端口地址的转换由网关执行。如下所述，无界iFCP结构中的交换机元件和网关数量可能超过传统光纤通道结构的限制。
All iFCP gateways MUST support unbounded iFCP fabrics. Support for bounded iFCP fabrics is OPTIONAL.
所有iFCP网关必须支持无限的iFCP结构。对有界iFCP结构的支持是可选的。
The decision to support bounded iFCP fabrics in a gateway implementation depends on the address transparency, configuration scalability, and fault tolerance considerations given in the following sections.
在网关实现中支持有界iFCP结构的决定取决于以下部分给出的地址透明度、配置可伸缩性和容错注意事项。
Although iFCP gateways in an unbounded fabric will convert N_PORT addresses in the frame header and payload of standard link service messages, a gateway cannot convert such addresses in the payload of vendor- or user-specific fibre channel frame traffic.
尽管无界结构中的iFCP网关将转换标准链路服务消息的帧头和有效负载中的N_端口地址，但网关无法转换供应商或用户特定光纤通道帧通信的有效负载中的此类地址。
Consequently, although both bounded and unbounded iFCP fabrics support standards-compliant FC-4 protocol implementations and link services used by mainstream fibre channel applications, a bounded iFCP fabric may also support vendor- or user-specific protocol and link service implementations that carry N_PORT IDs in the frame payload.
因此，尽管有界和无界iFCP结构都支持符合标准的FC-4协议实现和主流光纤通道应用程序使用的链路服务，但有界iFCP结构也可能支持在帧负载中携带N_端口ID的供应商或用户特定的协议和链路服务实现。
The scalability limits of a bounded fabric configuration are a consequence of the fibre channel address allocation policy discussed in Section 3.7.1. As noted, a bounded iFCP fabric using this address allocation scheme is limited to a combined total of 239 gateways and fibre channel switch elements. As the system expands, the network may grow to include many switch elements and gateways, each of which controls a small number of devices. In this case, the limitation in switch and gateway count may become a barrier to extending and fully integrating the storage network.
有界结构配置的可扩展性限制是第3.7.1节中讨论的光纤通道地址分配策略的结果。如前所述，使用此地址分配方案的有界iFCP结构限制为总共239个网关和光纤通道交换机元件。随着系统的扩展，网络可能会扩展到包括许多交换机元件和网关，每个交换机元件和网关控制少量设备。在这种情况下，交换机和网关数量的限制可能成为扩展和完全集成存储网络的障碍。
Since N_PORT fibre channel addresses in an unbounded iFCP fabric are not fabric-wide, the limits imposed by fibre channel address allocation only apply within the gateway region. Across regions, the number of iFCP gateways, fibre channel devices, and switch elements that may be internetworked are not constrained by these limits. In exchange for improved scalability, however, implementations must consider the incremental overhead of address conversion, as well as the address transparency issues discussed in Section 4.3.1.
由于无界iFCP结构中的N_端口光纤通道地址不是结构范围，因此光纤通道地址分配施加的限制仅适用于网关区域。跨地区，可能联网的iFCP网关、光纤通道设备和交换机元件的数量不受这些限制。然而，为了改进可伸缩性，实现必须考虑地址转换的增量开销，以及4.3.1节中讨论的地址透明问题。
In a bounded iFCP fabric, address reassignment caused by a fault or reconfiguration, such as the addition of a new gateway region, may cascade to other regions, causing fabric-wide disruption as new N_PORT addresses are assigned. Furthermore, before a new gateway can be merged into the fabric, its iSNS server must be slaved to the iSNS server in the bounded fabric to centralize the issuance of domain IDs. In an unbounded iFCP fabric, coordinating the iSNS databases requires only that the iSNS servers exchange client attributes with one another.
在有界iFCP结构中，由故障或重新配置（如添加新网关区域）引起的地址重新分配可能会级联到其他区域，在分配新的N_端口地址时造成结构范围的中断。此外，在将新网关合并到结构中之前，其iSNS服务器必须从属于绑定结构中的iSNS服务器，以集中发布域ID。在无边界的iFCP结构中，协调iSNS数据库只需要iSNS服务器彼此交换客户端属性。
A bounded iFCP fabric also has an increased dependency on the availability of the iSNS server, which must act as the central address assignment authority. If connectivity with the server is lost, new DOMAIN_ID values cannot be automatically allocated as gateways and fibre channel switch elements are added.
有界的iFCP结构还增加了对iSNS服务器可用性的依赖性，iSNS服务器必须充当中心地址分配机构。如果与服务器的连接丢失，则在添加网关和光纤通道交换机元件时，无法自动分配新的域ID值。
This section discusses iFCP extensions to the fibre channel addressing model of Section 3.7.1, which are required for the transparent routing of frames between locally and remotely attached N_PORTs.
本节讨论对第3.7.1节光纤通道寻址模型的iFCP扩展，这是本地和远程连接的N_端口之间的帧透明路由所必需的。
In the iFCP protocol, an N_PORT is represented by the following addresses:
在iFCP协议中，N_端口由以下地址表示：
a) A 24-bit N_PORT ID. The fibre channel N_PORT address of a locally attached device. Depending on the gateway addressing mode, the scope is local either to a region or to a bounded iFCP fabric. In either mode, communications between N_PORTs in the same gateway region use the N_PORT ID.
a) 24位N_端口ID。本地连接设备的光纤通道N_端口地址。根据网关寻址模式，作用域对于区域或有界iFCP结构是本地的。在任一模式下，同一网关区域中的N_端口之间的通信使用N_端口ID。
b) A 24-bit N_PORT alias. The fibre channel N_PORT address assigned by each gateway operating in address translation mode to identify a remotely attached N_PORT. Frame traffic is intercepted by an iFCP gateway and directed to a remotely attached N_PORT by means of the N_PORT alias. The address assigned by each gateway is unique within the scope of the gateway region.
b) 24位N_端口别名。由在地址转换模式下运行的每个网关分配的光纤通道N_端口地址，用于标识远程连接的N_端口。帧流量由iFCP网关拦截，并通过N_端口别名定向到远程连接的N_端口。每个网关分配的地址在网关区域的范围内是唯一的。
c) An N_PORT network address. A tuple consisting of the gateway IP address, TCP port number, and N_PORT ID. The N_PORT network address identifies the source and destination N_PORTs for fibre channel traffic on the IP network.
c) N_端口网络地址。由网关IP地址、TCP端口号和N_端口ID组成的元组。N_端口网络地址标识IP网络上光纤通道流量的源和目标N_端口。
To provide transparent communications between a remote and local N_PORT, a gateway MUST maintain an iFCP session descriptor (see Section 5.2.2.2) reflecting the association between the fibre channel address representing the remote N_PORT and the remote device's N_PORT network address. To establish this association, the iFCP gateway assigns and manages fibre channel N_PORT fabric addresses as described in the following paragraphs.
为了在远程和本地N_端口之间提供透明通信，网关必须维护一个iFCP会话描述符（见第5.2.2.2节），以反映表示远程N_端口的光纤通道地址与远程设备的N_端口网络地址之间的关联。要建立此关联，iFCP网关将按照以下段落中的说明分配和管理光纤通道N_端口结构地址。
In an iFCP fabric, the iFCP gateway performs the address assignment and frame routing functions of an FC switch element. Unlike an FC switch, however, an iFCP gateway must also direct frames to external devices attached to remote gateways on the IP network.
在iFCP结构中，iFCP网关执行FC交换机元件的地址分配和帧路由功能。但是，与FC交换机不同，iFCP网关还必须将帧定向到连接到IP网络上远程网关的外部设备。
In order to be transparent to FC devices, the gateway must deliver such frames using only the 24-bit destination address in the frame header. By exploiting its control of address allocation and access to frame traffic entering or leaving the gateway region, the gateway is able to achieve the necessary transparency.
为了对FC设备透明，网关必须仅使用帧报头中的24位目标地址来传送此类帧。通过利用其对地址分配的控制和对进出网关区域的帧流量的访问，网关能够实现必要的透明度。
N_PORT addresses within a gateway region may be allocated in one of two ways:
网关区域内的N_端口地址可通过以下两种方式之一分配：
a) Address Translation Mode - A mode of N_PORT address assignment in which the scope of an N_PORT fibre channel address is unique to the gateway region. The address of a remote device is represented in that gateway region by its gateway-assigned N_PORT alias.
a) 地址转换模式—一种N_端口地址分配模式，其中N_端口光纤通道地址的范围对于网关区域是唯一的。远程设备的地址在该网关区域中由其网关分配的N_端口别名表示。
b) Address Transparent Mode - A mode of N_PORT address assignment in which the scope of an N_PORT fibre channel address is unique across the set of gateway regions comprising a bounded iFCP fabric.
b) 地址透明模式—一种N_端口地址分配模式，其中N_端口光纤通道地址的范围在包含有界iFCP结构的网关区域集中是唯一的。
In address transparent mode, gateways within a bounded fabric cooperate in the assignment of addresses to locally attached N_PORTs. Each gateway in control of a region is responsible for obtaining and distributing unique domain IDs from the address assignment authority, as described in Section 4.5.1. Consequently, within the scope of a bounded fabric, the address of each N_PORT is unique. For that reason, gateway-assigned aliases are not required for representing remote N_PORTs.
在地址透明模式下，有界结构中的网关协作将地址分配给本地连接的N_端口。如第4.5.1节所述，控制区域的每个网关负责从地址分配机构获取和分发唯一的域ID。因此，在有界结构的范围内，每个N_端口的地址是唯一的。因此，不需要网关分配的别名来表示远程N_端口。
All iFCP implementations MUST support operations in address translation mode. Implementation of address transparent mode is OPTIONAL but, of course, must be provided if bounded iFCP fabric configurations are to be supported.
所有iFCP实现必须支持地址转换模式下的操作。地址透明模式的实现是可选的，但如果要支持有界的iFCP结构配置，则必须提供。
The mode of gateway operation is settable in an implementation-specific manner. The implementation MUST NOT:
网关操作模式可通过特定于实现的方式进行设置。实施不得：
a) allow the mode to be changed after the gateway begins processing fibre channel frame traffic,
a) 允许在网关开始处理光纤通道帧流量后更改模式，
b) permit operation in more than one mode at a time, or
b) 允许一次以多个模式运行，或
c) establish an iFCP session with a gateway that is not in the same mode.
c) 与不处于相同模式的网关建立iFCP会话。
The following considerations and requirements apply to this mode of operation:
以下注意事项和要求适用于此操作模式：
a) iFCP gateways in address transparent mode will not interoperate with iFCP gateways that are not in address transparent mode.
a) 处于地址透明模式的iFCP网关将不会与不处于地址透明模式的iFCP网关进行互操作。
b) When interoperating with locally attached fibre channel switch elements, each iFCP gateway MUST assume control of DOMAIN_ID assignments in accordance with the appropriate fibre channel standard or vendor-specific protocol specification. As described in Section 4.5.1, DOMAIN_ID values that are assigned to FC switches internal to the gateway region must be issued by the iSNS server.
b) 当与本地连接的光纤通道交换机元件进行互操作时，每个iFCP网关必须根据适当的光纤通道标准或特定于供应商的协议规范控制域ID分配。如第4.5.1节所述，分配给网关区域内部FC交换机的域ID值必须由iSNS服务器发布。
c) When operating in address transparent Mode, fibre channel address translation SHALL NOT take place.
c) 在地址透明模式下运行时，不得进行光纤通道地址转换。
When operating in address transparent mode, however, the gateway MUST establish and maintain the context of each iFCP session in accordance with Section 5.2.2.
但是，在地址透明模式下运行时，网关必须根据第5.2.2节建立和维护每个iFCP会话的上下文。
As described in Section 4.5, each gateway and fibre channel switch in a bounded iFCP fabric has a unique domain ID. In a gateway region containing fibre channel switch elements, each element obtains a domain ID by querying the principal switch as described in [FC-SW2] -- in this case, the iFCP gateway itself. The gateway, in turn, obtains domain IDs on demand from the iSNS name server acting as the central address allocation authority. In effect, the iSNS server assumes the role of principal switch for the bounded fabric. In that case, the iSNS database contains:
如第4.5节所述，有界iFCP结构中的每个网关和光纤通道交换机都有一个唯一的域ID。在包含光纤通道交换机元素的网关区域中，每个元素通过查询[FC-SW2]中所述的主交换机（在本例中为iFCP网关本身）来获得域ID。网关则根据需要从作为中央地址分配机构的iSNS名称服务器获取域ID。实际上，iSNS服务器承担了绑定结构的主体交换机角色。在这种情况下，iSNS数据库包含：
a) The definition for one or more bounded iFCP fabrics, and
a) 一个或多个有界iFCP结构的定义，以及
b) For each bounded fabric, a worldwide-unique name identifying each gateway in the fabric. A gateway in address transparent mode MUST reside in one, and only one, bounded fabric.
b) 对于每个有界结构，一个标识结构中每个网关的全球唯一名称。处于地址透明模式的网关必须驻留在一个且仅一个有界结构中。
As the Principal Switch within the gateway region, an iFCP gateway in address transparent mode SHALL obtain domain IDs for use in the gateway region by issuing the appropriate iSNS query, using its worldwide name.
作为网关区域内的主要交换机，地址透明模式下的iFCP网关应通过使用其全球名称发出适当的iSNS查询来获取用于网关区域的域ID。
Except for the session control frames specified in Section 6, iFCP gateways in address transparent mode SHALL NOT originate or accept frames that do not have the TRP bit set to one in the iFCP flags field of the encapsulation header (see Section 5.3.1). The iFCP gateway SHALL immediately terminate all iFCP sessions with the iFCP gateway from which it receives such frames.
除第6节规定的会话控制帧外，地址透明模式下的iFCP网关不得发起或接受封装头的iFCP标志字段中TRP位未设置为1的帧（见第5.3.1节）。iFCP网关应立即终止与接收到这些帧的iFCP网关的所有iFCP会话。
This section describes the process for managing the assignment of addresses within a gateway region that is part of an unbounded iFCP fabric, including the modification of FC frame addresses embedded in the frame header for frames sent and received from remotely attached N_PORTs.
本节描述了在作为无界iFCP结构一部分的网关区域内管理地址分配的过程，包括修改嵌入帧头中的FC帧地址，以用于从远程连接的N_端口发送和接收的帧。
As described in Section 4.4, the scope of N_PORT addresses in this mode is local to the gateway region. A principal switch within the gateway region, possibly the iFCP gateway itself, oversees the assignment of such addresses, in accordance with the rules specified in [FC-FS] and [FC-FLA].
如第4.4节所述，此模式下N_端口地址的范围是网关区域的本地范围。网关区域内的主交换机（可能是iFCP网关本身）根据[FC-FS]和[FC-FLA]中规定的规则监督此类地址的分配。
The assignment of N_PORT addresses to locally attached devices is controlled by the switch element to which the device is connected.
将N_端口地址分配给本地连接的设备由设备所连接的交换机元件控制。
The assignment of N_PORT addresses for remotely attached devices is controlled by the gateway by which the remote device is accessed. In this case, the gateway MUST assign a locally significant N_PORT alias to be used in place of the N_PORT ID assigned by the remote gateway. The N_PORT alias is assigned during device discovery, as described in Section 5.2.2.1.
远程连接设备的N_端口地址分配由访问远程设备的网关控制。在这种情况下，网关必须分配一个本地有效的N_端口别名，以代替远程网关分配的N_端口ID。N_端口别名在设备发现期间分配，如第5.2.2.1节所述。
To perform address conversion and to enable the appropriate routing, the gateway MUST establish an iFCP session and generate the information required to map each N_PORT alias to the appropriate TCP/IP connection context and N_PORT ID of the remotely accessed N_PORT. These mappings are created and updated by means specified in Section 5.2.2.2. As described in that section, the required mapping information is represented by the iFCP session descriptor reproduced in Figure 8.
要执行地址转换并启用适当的路由，网关必须建立iFCP会话，并生成将每个N_端口别名映射到适当的TCP/IP连接上下文和远程访问N_端口的N_端口ID所需的信息。这些映射通过第5.2.2.2节规定的方式创建和更新。如该部分所述，所需的映射信息由图8中重现的iFCP会话描述符表示。
+-----------------------+
|TCP Connection Context |
+-----------------------+
| Local N_PORT ID |
+-----------------------+
| Remote N_PORT ID |
+-----------------------+
| Remote N_PORT Alias |
+-----------------------+
+-----------------------+
|TCP Connection Context |
+-----------------------+
| Local N_PORT ID |
+-----------------------+
| Remote N_PORT ID |
+-----------------------+
| Remote N_PORT Alias |
+-----------------------+
Figure 8. iFCP Session Descriptor (from Section 5.2.2.2)
图8。iFCP会话描述符（来自第5.2.2.2节）
Except for frames comprising special link service messages (see Section 7.2), outbound frames are encapsulated and sent without modification. Address translation is deferred until receipt from the IP network, as specified in Section 4.6.1.
除了包含特殊链路服务消息的帧（参见第7.2节），出站帧被封装并发送，无需修改。按照第4.6.1节的规定，地址转换延迟至从IP网络接收。
For inbound frames received from the IP network, the receiving gateway SHALL reference the session descriptor to fill in the D_ID field with the destination N_PORT ID and the S_ID field with the N_PORT alias it assigned. The translation process for inbound frames is shown in Figure 9.
对于从IP网络接收到的入站帧，接收网关应参考会话描述符，用目标N_端口ID填写D_ID字段，用分配的N_端口别名填写S_ID字段。入站帧的转换过程如图9所示。
Network Format of Inbound Frame
+--------------------------------------------+ iFCP
| FC Encapsulation Header | Session
+--------------------------------------------+ Descriptor
| SOF Delimiter Word | |
+========+===================================+ V
| | D_ID Field | +--------+-----+
+--------+-----------------------------------+ | Lookup source|
| | S_ID Field | | N_PORT Alias |
+--------+-----------------------------------+ | and |
| Control Information, Payload, | | destination |
| and FC CRC | | N_PORT ID |
| | +--------+-----+
| | |
| | |
+============================================+ |
| EOF Delimiter Word | |
+--------------------------------------------+ |
|
|
Frame after Address Translation and De-encapsulation |
+--------+-----------------------------------+ |
| | Destination N_PORT ID |<-------------+
+--------+-----------------------------------+ |
| | Source N_PORT Alias |<-------------+
+--------+-----------------------------------+
| |
| Control information, Payload, |
| and FC CRC |
+--------------------------------------------+
Network Format of Inbound Frame
+--------------------------------------------+ iFCP
| FC Encapsulation Header | Session
+--------------------------------------------+ Descriptor
| SOF Delimiter Word | |
+========+===================================+ V
| | D_ID Field | +--------+-----+
+--------+-----------------------------------+ | Lookup source|
| | S_ID Field | | N_PORT Alias |
+--------+-----------------------------------+ | and |
| Control Information, Payload, | | destination |
| and FC CRC | | N_PORT ID |
| | +--------+-----+
| | |
| | |
+============================================+ |
| EOF Delimiter Word | |
+--------------------------------------------+ |
|
|
Frame after Address Translation and De-encapsulation |
+--------+-----------------------------------+ |
| | Destination N_PORT ID |<-------------+
+--------+-----------------------------------+ |
| | Source N_PORT Alias |<-------------+
+--------+-----------------------------------+
| |
| Control information, Payload, |
| and FC CRC |
+--------------------------------------------+
Figure 9. Inbound Frame Address Translation
图9。入站帧地址转换
The receiving gateway SHALL consider the contents of the S_ID and D_ID fields to be undefined when received. After replacing these fields, the gateway MUST recalculate the FC CRC.
接收网关应考虑SID ID和DYID字段在接收时未定义的内容。替换这些字段后，网关必须重新计算FC CRC。
iFCP gateways in address translation mode SHALL NOT originate or accept frames that have the TRP bit set to one in the iFCP flags field of the encapsulation header. The iFCP gateway SHALL immediately abort all iFCP sessions with the iFCP gateway from which it receives frames such as those described in Section 5.2.3.
地址转换模式下的iFCP网关不得发起或接受在封装报头的iFCP标志字段中将TRP位设置为1的帧。iFCP网关应立即中止与接收帧（如第5.2.3节所述）的iFCP网关的所有iFCP会话。
The main function of the iFCP protocol layer is to transport fibre channel frame images between locally and remotely attached N_PORTs.
iFCP协议层的主要功能是在本地和远程连接的N_端口之间传输光纤通道帧映像。
When transporting frames to a remote N_PORT, the iFCP layer encapsulates and routes the fibre channel frames comprising each fibre channel Information Unit via a predetermined TCP connection for transport across the IP network.
当将帧传输到远程N_端口时，iFCP层通过预定的TCP连接封装并路由包含每个光纤通道信息单元的光纤通道帧，以便在IP网络上传输。
When receiving fibre channel frame images from the IP network, the iFCP layer de-encapsulates and delivers each frame to the appropriate N_PORT.
当从IP网络接收光纤通道帧映像时，iFCP层将对每个帧进行反封装并将其传送到相应的N_端口。
The iFCP layer processes the following types of traffic:
iFCP层处理以下类型的流量：
a) FC-4 frame images associated with a fibre channel application protocol.
a) 与光纤通道应用程序协议关联的FC-4帧映像。
b) FC-2 frames comprising fibre channel link service requests and responses.
b) FC-2帧，包括光纤通道链路服务请求和响应。
c) Fibre channel broadcast frames.
c) 光纤通道广播帧。
d) iFCP control messages required to set up, manage, or terminate an iFCP session.
d) 设置、管理或终止iFCP会话所需的iFCP控制消息。
For FC-4 N_PORT traffic and most FC-2 messages, the iFCP layer never interprets the contents of the frame payload.
对于FC-4 N_端口流量和大多数FC-2消息，iFCP层从不解释帧有效负载的内容。
iFCP does interpret and process iFCP control messages and certain link service messages, as described in Section 5.1.2.
如第5.1.2节所述，iFCP确实解释和处理iFCP控制消息和某些链路服务消息。
iFCP must intervene in the processing of those fibre channel link service messages that contain N_PORT addresses in the message payload or that require other special handling, such as an N_PORT login request (PLOGI).
iFCP必须干预那些在消息负载中包含N_端口地址或需要其他特殊处理（如N_端口登录请求（PLOGI））的光纤通道链路服务消息的处理。
In the former case, an iFCP gateway operating in address translation mode MUST supplement the payload with additional information that enables the receiving gateway to convert such embedded N_PORT addresses to its frame of reference.
在前一种情况下，在地址转换模式下运行的iFCP网关必须使用附加信息来补充有效负载，以使接收网关能够将此类嵌入式N_端口地址转换为其参考帧。
For out bound fibre channel frames comprising such a link service, the iFCP layer creates the supplemental information based on frame content, modifies the frame payload, and then transmits the resulting fibre channel frame with supplemental data through the appropriate TCP connection.
对于包含此类链路服务的外联光纤通道帧，iFCP层基于帧内容创建补充信息，修改帧有效负载，然后通过适当的TCP连接传输带有补充数据的结果光纤通道帧。
For incoming iFCP frames containing supplemented fibre channel link service frames, iFCP must interpret the frame, including any supplemental information, modify the frame content, and forward the resulting frame to the destination N_PORT for further processing.
对于包含补充光纤通道链路服务帧的传入iFCP帧，iFCP必须解释该帧，包括任何补充信息，修改帧内容，并将生成的帧转发到目标N_端口进行进一步处理。
Section 7.1 describes the processing of these link service messages in detail.
第7.1节详细描述了这些链路服务消息的处理。
An iFCP session consists of the pair of N_PORTs comprising the session endpoints joined by a single TCP/IP connection. No more than one iFCP session SHALL exist between a given pair of N_PORTs.
iFCP会话由一对N_端口组成，这些端口由单个TCP/IP连接连接的会话端点组成。给定的N_端口对之间不得存在多个iFCP会话。
An N_PORT is identified by its network address, consisting of:
N_端口由其网络地址标识，包括：
a) the N_PORT ID assigned by the gateway to which the N_PORT is locally attached, and
a) N_端口本地连接到的网关分配的N_端口ID，以及
b) the iFCP Portal address, consisting of its IP address and TCP port number.
b) iFCP入口地址，由其IP地址和TCP端口号组成。
Because only one iFCP session may exist between a pair of N_PORTs, the iFCP session is uniquely identified by the network addresses of the session end points.
由于一对N_端口之间可能只存在一个iFCP会话，因此iFCP会话由会话端点的网络地址唯一标识。
TCP connections that may be used for iFCP sessions between pairs of iFCP portals are either "bound" or "unbound". An unbound connection
可用于成对iFCP门户之间的iFCP会话的TCP连接为“绑定”或“未绑定”。未绑定的连接
is a TCP connection that is not actively supporting an iFCP session. A gateway implementation MAY establish a pool of unbound connections to reduce the session setup time. Such pre-existing TCP connections between iFCP Portals remain unbound and uncommitted until allocated to an iFCP session through a CBIND message (see Section 6.1).
是不主动支持iFCP会话的TCP连接。网关实现可建立未绑定连接池以减少会话设置时间。在通过CBIND消息分配给iFCP会话之前，iFCP门户之间的此类预先存在的TCP连接保持未绑定和未提交状态（参见第6.1节）。
When the iFCP layer creates an iFCP session, it may select an existing unbound TCP connection or establish a new TCP connection and send the CBIND message down that TCP connection. This allocates the TCP connection to that iFCP session.
当iFCP层创建一个iFCP会话时，它可以选择一个现有的未绑定的TCP连接，或者建立一个新的TCP连接，并向该TCP连接发送CBIND消息。这会将TCP连接分配给该iFCP会话。
This section describes the protocols and data structures required to establish and terminate an iFCP session.
本节介绍建立和终止iFCP会话所需的协议和数据结构。
In order to establish an iFCP session, an iFCP gateway MUST maintain information allowing it to locate a remotely attached N_PORT. For explanatory purposes, such information is assumed to reside in a descriptor with the format shown in Figure 10.
为了建立iFCP会话，iFCP网关必须维护信息，以便定位远程连接的N_端口。出于解释目的，假定此类信息位于图10所示格式的描述符中。
+--------------------------------+
| N_PORT Worldwide Unique Name |
+--------------------------------+
| iFCP Portal Address |
+--------------------------------+
| N_PORT ID of Remote N_PORT |
+--------------------------------+
| N_PORT Alias |
+--------------------------------+
+--------------------------------+
| N_PORT Worldwide Unique Name |
+--------------------------------+
| iFCP Portal Address |
+--------------------------------+
| N_PORT ID of Remote N_PORT |
+--------------------------------+
| N_PORT Alias |
+--------------------------------+
Figure 10. Remote N_PORT Descriptor
图10。远程N_端口描述符
Each descriptor aggregates the following information about a remotely attached N_PORT:
每个描述符聚合有关远程连接的N_端口的以下信息：
N_PORT Worldwide Unique Name -- 64-bit N_PORT worldwide name as specified in [FC-FS]. A Remote N_PORT descriptor is uniquely identified by this parameter.
N_端口全球唯一名称--[FC-FS]中指定的64位N_端口全球唯一名称。远程N_端口描述符由此参数唯一标识。
iFCP Portal Address -- The IP address and TCP port number referenced when creation of the TCP connection associated with an iFCP session is requested.
iFCP入口地址——请求创建与iFCP会话关联的TCP连接时引用的IP地址和TCP端口号。
N_PORT ID -- N_PORT fibre channel address assigned to the remote device by the remote iFCP gateway.
N_端口ID—由远程iFCP网关分配给远程设备的N_端口光纤通道地址。
N_PORT Alias -- N_PORT fibre channel address assigned to the remote device by the 'local' iFCP gateway when it operates in address translation mode.
N_端口别名--“本地”iFCP网关在地址转换模式下运行时分配给远程设备的N_端口光纤通道地址。
An iFCP gateway SHALL have one and only one descriptor for each remote N_PORT it accesses. If a descriptor does not exist, one SHALL be created using the information returned by an iSNS name server query. Such queries may result from:
iFCP网关应为其访问的每个远程N_端口具有且仅具有一个描述符。如果描述符不存在，则应使用iSNS名称服务器查询返回的信息创建一个描述符。此类查询可能来自：
a) a fibre channel Name Server request originated by a locally attached N_PORT (see Sections 3.5 and 9.3), or
a) 由本地连接的N_端口发起的光纤通道名称服务器请求（请参见第3.5节和第9.3节），或
b) a CBIND request received from a remote fibre channel device (see Section 5.2.2.2).
b) 从远程光纤通道设备接收的CBIND请求（请参阅第5.2.2.2节）。
When creating a descriptor in response to an incoming CBIND request, the iFCP gateway SHALL perform an iSNS name server query using the worldwide port name of the remote N_PORT in the SOURCE N_PORT NAME field within the CBIND payload. The descriptor SHALL be filled in using the query results.
当响应传入的CBIND请求创建描述符时，iFCP网关应使用CBIND有效负载内的源N_端口名称字段中远程N_端口的全球端口名称执行iSNS名称服务器查询。描述符应使用查询结果填写。
After creating the descriptor, a gateway operating in address translation mode SHALL create and add the 24-bit N_PORT alias.
创建描述符后，在地址转换模式下运行的网关应创建并添加24位N_端口别名。
A Remote N_PORT descriptor SHALL only be updated as the result of an iSNS query to obtain information for the specified worldwide port name or from information returned by an iSNS state change notification. Following such an update, a new N_PORT alias SHALL NOT be assigned.
远程N_端口描述符只能作为iSNS查询的结果进行更新，以获取指定全球端口名的信息，或从iSNS状态更改通知返回的信息中进行更新。更新后，不应分配新的N_端口别名。
Before such an update, the contents of a descriptor may have become stale because of an event that invalidated or triggered a change in the N_PORT network address of the remote device, such as a fabric reconfiguration or the device's removal or replacement.
在这样的更新之前，描述符的内容可能已经过时，因为发生了使远程设备的N_端口网络地址无效或触发了更改的事件，例如结构重新配置或设备的移除或替换。
A collateral effect of such an event is that a fibre channel device that has been added or whose N_PORT ID has changed will have no active N_PORT logins. Consequently, FC-4 traffic directed to such an N_PORT, because of a stale descriptor, will be rejected or discarded.
此类事件的附带影响是，已添加或其N_端口ID已更改的光纤通道设备将没有活动的N_端口登录。因此，由于描述符过时，定向到此类N_端口的FC-4通信将被拒绝或丢弃。
Once the originating N_PORT learns of the reconfiguration, usually through the name server state change notification mechanism, information returned in the notification or the subsequent name server lookup needed to reestablish the iFCP session will automatically purge such stale data from the gateway.
一旦发起N_端口得知重新配置，通常通过名称服务器状态更改通知机制，通知中返回的信息或重新建立iFCP会话所需的后续名称服务器查找将自动从网关清除此类过时数据。
Deleting a remote N_PORT descriptor is equivalent to freeing up the corresponding N_PORT alias for reuse. Consequently, the descriptor MUST NOT be deleted while there are any iFCP sessions that reference the remote N_PORT.
删除远程N_端口描述符相当于释放相应的N_端口别名以供重用。因此，当存在引用远程N_端口的任何iFCP会话时，不得删除描述符。
Descriptors eligible for deletion should be removed based on a last in, first out policy.
应根据后进先出策略删除符合删除条件的描述符。
An iFCP session may be in one of the following states:
iFCP会话可能处于以下状态之一：
OPEN -- The session state in which fibre channel frame images may be sent and received.
OPEN--可以发送和接收光纤通道帧映像的会话状态。
OPEN PENDING -- The session state after a gateway has issued a CBIND request but no response has yet been received. No fibre channel frames may be sent.
OPEN PENDING--网关发出CBIND请求但尚未收到响应后的会话状态。不能发送光纤通道帧。
The session may be initiated in response to a PLOGI ELS (see Section 7.3.1.7) or for any other implementation-specific reason.
会话可以响应PLOGI ELS（见第7.3.1.7节）或出于任何其他特定于实施的原因而启动。
The gateway SHALL create the iFCP session as follows:
网关应按如下方式创建iFCP会话：
a) Locate the remote N_PORT descriptor corresponding to the session end point. If the session is created in order to forward a fibre channel frame, then the session endpoint may be obtained by referencing the remote N_PORT alias contained in the frame header D_ID field. If no descriptor exists, an iFCP session SHALL NOT be created.
a) 找到与会话终结点对应的远程N_端口描述符。如果创建会话是为了转发光纤通道帧，则可以通过引用帧头D_ID字段中包含的远程N_端口别名来获取会话端点。如果不存在描述符，则不应创建iFCP会话。
b) Allocate a TCP connection to the gateway to which the remote N_PORT is locally attached. An implementation may use an existing connection in the Unbound state, or a new connection may be created and placed in the Unbound state.
b) 将TCP连接分配到远程N_端口本地连接的网关。实现可以使用处于未绑定状态的现有连接，也可以创建新连接并将其置于未绑定状态。
When a connection is created, the IP address and TCP Port number SHALL be obtained by referencing the remote N_PORT descriptor as specified in Section 5.2.2.1.
创建连接时，应通过参考第5.2.2.1节中规定的远程N_端口描述符获取IP地址和TCP端口号。
c) If the TCP connection cannot be allocated or cannot be created due to limited resources, the gateway SHALL terminate session creation.
c) 如果由于资源有限而无法分配或创建TCP连接，网关应终止会话创建。
d) If the TCP connection is aborted for any reason before the iFCP session enters the OPEN state, the gateway SHALL respond in accordance with Section 5.2.3 and MAY terminate the attempt to create a session or MAY try to establish the TCP connection again.
d) 如果在iFCP会话进入打开状态之前，TCP连接因任何原因被中止，则网关应根据第5.2.3节作出响应，并可终止创建会话的尝试或再次尝试建立TCP连接。
e) The gateway SHALL then issue a CBIND session control message (see Section 6.1) and place the session in the OPEN PENDING state.
e) 然后，网关应发出CBIND会话控制消息（见第6.1节），并将会话置于打开挂起状态。
f) If a CBIND response is returned with a status other than "Success" or "iFCP session already exists", the session SHALL be terminated, and the TCP connection returned to the Unbound state.
f) 如果返回的CBIND响应的状态不是“成功”或“iFCP会话已存在”，则应终止会话，并将TCP连接返回到未绑定状态。
g) A CBIND STATUS of "iFCP session already exists" indicates that the remote gateway has concurrently initiated a CBIND request to create an iFCP session between the same pair of N_PORTs. A gateway receiving such a response SHALL terminate this attempt and process the incoming CBIND request in accordance with Section 5.2.2.3.
g) CBIND状态为“iFCP会话已存在”表示远程网关已同时启动CBIND请求，以在同一对N_端口之间创建iFCP会话。收到此类响应的网关应根据第5.2.2.3节终止该尝试并处理传入的CBIND请求。
h) In response to a CBIND STATUS of "Success", the gateway SHALL place the session in the OPEN state.
h) 作为对CBIND状态“成功”的响应，网关应将会话置于打开状态。
Once the session is placed in the OPEN state, an iFCP session descriptor SHALL be created, containing the information shown in Figure 11:
一旦会话处于打开状态，应创建一个iFCP会话描述符，其中包含图11所示的信息：
+-----------------------+
|TCP Connection Context |
+-----------------------+
| Local N_PORT ID |
+-----------------------+
| Remote N_PORT ID |
+-----------------------+
| Remote N_PORT Alias |
+-----------------------+
+-----------------------+
|TCP Connection Context |
+-----------------------+
| Local N_PORT ID |
+-----------------------+
| Remote N_PORT ID |
+-----------------------+
| Remote N_PORT Alias |
+-----------------------+
Figure 11. iFCP Session Descriptor
图11。会话描述符
TCP Connection Context -- Information required to identify the TCP connection associated with the iFCP session.
TCP连接上下文—标识与iFCP会话关联的TCP连接所需的信息。
Local N_PORT ID -- N_PORT ID of the locally attached fibre channel device.
本地N_端口ID--本地连接的光纤通道设备的N_端口ID。
Remote N_PORT ID -- N_PORT ID assigned to the remote device by the remote gateway.
远程N_端口ID--由远程网关分配给远程设备的N_端口ID。
Remote N_PORT Alias -- Alias assigned to the remote N_PORT by the local gateway when it operates in address translation mode. If in this mode, the gateway SHALL copy this parameter from the Remote N_PORT descriptor. Otherwise, it is not filled in.
远程N_端口别名--本地网关在地址转换模式下运行时分配给远程N_端口的别名。如果处于该模式，网关应从远程N_端口描述符复制该参数。否则不填写。
The gateway receiving a CBIND request SHALL respond as follows:
接收CBIND请求的网关应作出如下响应：
a) If the receiver has a duplicate iFCP session in the OPEN PENDING state, then the receiving gateway SHALL compare the Source N_PORT Name in the incoming CBIND payload with the Destination N_PORT Name.
a) 如果接收器在打开挂起状态下有重复的iFCP会话，则接收网关应将传入CBIND有效负载中的源N_端口名称与目标N_端口名称进行比较。
b) If the Source N_PORT Name is greater, the receiver SHALL issue a CBIND response of "Success" and SHALL place the session in the OPEN state.
b) 如果源N_端口名称更大，接收器应发出“成功”的CBIND响应，并将会话置于打开状态。
c) If the Source N_PORT Name is less, the receiver shall issue a CBIND RESPONSE of Failed - N_PORT session already exists. The state of the receiver-initiated iFCP session SHALL BE unchanged.
c) 如果源N_端口名称较小，则接收器应发出失败的CBIND响应-N_端口会话已存在。接收器启动的iFCP会话的状态应保持不变。
d) If there is no duplicate iFCP session in the OPEN PENDING state, the receiving gateway SHALL issue a CBIND response. If a status of Success is returned, the receiving gateway SHALL create the iFCP session and place it in the OPEN state. An iFCP session descriptor SHALL be created as described in Section 5.2.2.2.
d) 如果在打开挂起状态下没有重复的iFCP会话，则接收网关应发出CBIND响应。如果返回成功状态，接收网关应创建iFCP会话并将其置于打开状态。应按照第5.2.2.2节所述创建iFCP会话描述符。
e) If a remote N_PORT descriptor does not exist, one SHALL be created and filled in as described in Section 5.2.2.1.
e) 如果不存在远程N_端口描述符，则应按照第5.2.2.1节所述创建并填写一个。
During extended periods of inactivity, an iFCP session may be terminated due to a hardware failure within the gateway or through loss of TCP/IP connectivity. The latter may occur when the session traverses a stateful intermediate device, such as a NA(P)T box or firewall, that detects and purges connections it believes are unused.
在长时间不活动期间，iFCP会话可能由于网关内的硬件故障或TCP/IP连接丢失而终止。后者可能发生在会话遍历有状态的中间设备时，如NA（P）T盒或防火墙，该设备检测并清除它认为未使用的连接。
To test session liveness, expedite the detection of connectivity failures, and avoid spontaneous connection termination, an iFCP gateway may maintain a low level of session activity and monitor the session by requesting that the remote gateway periodically transmit the LTEST message described in Section 6.3. All iFCP gateways SHALL support liveness testing as described in this specification.
为了测试会话活跃度，加快连接故障的检测，并避免自发的连接终止，iFCP网关可以保持较低级别的会话活动，并通过请求远程网关定期发送第6.3节中描述的LTEST消息来监视会话。所有iFCP网关应支持本规范所述的活性测试。
A gateway requests the LTEST heartbeat by specifying a non-zero value for the LIVENESS TEST INTERVAL in the CBIND request or response message as described in Section 6.1. If both gateways seek to monitor liveness, each must set the LIVENESS TEST INTERVAL in the CBIND request or response.
网关通过在CBIND请求或响应消息中为活跃度测试间隔指定非零值来请求LTEST心跳，如第6.1节所述。如果两个网关都试图监视活跃度，则每个网关都必须在CBIND请求或响应中设置活跃度测试间隔。
Upon receiving such a request, the gateway providing the heartbeat SHALL transmit LTEST messages at the specified interval. The first message SHALL be sent as soon as the iFCP session enters the OPEN state. LTEST messages SHALL NOT be sent when the iFCP session is not in the OPEN state.
在接收到这样的请求时，提供心跳的网关应以指定的间隔发送LTEST消息。iFCP会话进入打开状态后，应立即发送第一条消息。iFCP会话未处于打开状态时，不得发送LTEST消息。
An iFCP session SHALL be terminated as described in Section 5.2.3 if:
如果出现以下情况，应按照第5.2.3节所述终止iFCP会话：
a) the contents of the LTEST message are incorrect, or
a) LTEST消息的内容不正确，或
b) an LTEST message is not received within twice the specified interval or the iFCP session has been quiescent for longer than twice the specified interval.
b) 在指定间隔的两倍内未收到LTEST消息，或者iFCP会话的静止时间超过指定间隔的两倍。
The gateway to receive the LTEST message SHALL measure the interval for the first expected LTEST message from when the session is placed in the OPEN state. Thereafter, the interval SHALL be measured relative to the last LTEST message received.
接收LTEST消息的网关应从会话处于打开状态时开始测量第一个预期LTEST消息的间隔。此后，应相对于接收到的最后一条LTEST消息测量间隔。
To maximize liveness test coverage, LTEST messages SHOULD flow through all the gateway components used to enter and retrieve fibre channel frames from the IP network, including the mechanisms for encapsulating and de-encapsulating fibre channel frames.
为了最大限度地提高活动性测试覆盖率，LTEST消息应该流经用于从IP网络进入和检索光纤通道帧的所有网关组件，包括封装和解封光纤通道帧的机制。
In addition to monitoring a session, information in the LTEST message encapsulation header may also be used to compute an estimate of network propagation delay, as described in Section 8.2.1. However, the propagation delay limit SHALL NOT be enforced for LTEST traffic.
除监控会话外，LTEST消息封装报头中的信息还可用于计算网络传播延迟的估计值，如第8.2.1节所述。但是，对于LTEST业务，不应实施传播延迟限制。
This section describes ground rules for the use of TCP features in an iFCP session. The core TCP protocol is defined in [RFC793]. TCP implementation requirements and guidelines are specified in [RFC1122].
This section describes ground rules for the use of TCP features in an iFCP session. The core TCP protocol is defined in [RFC793]. TCP implementation requirements and guidelines are specified in [RFC1122].translate error, please retry
+-----------+------------+--------------+------------+------------+
| Feature | Applicable | RFC | Peer-Wise | Requirement|
| | RFCs | Status | Agreement | Level |
| | | | Required? | |
+===========+============+==============+============+============+
| Keep Alive| [RFC1122] | None | No | Should not |
| |(discussion)| | | use |
+-----------+------------+--------------+------------+------------+
| Tiny | [RFC896] | Standard | No | Should not |
| Segment | | | | use |
| Avoidance | | | | |
| (Nagle) | | | | |
+-----------+------------+--------------+------------+------------+
| Window | [RFC1323] | Proposed | No | Should use |
| Scale | | Standard | | |
+-----------+------------+--------------+------------+------------+
| Wrapped | [RFC1323] | Proposed | No | SHOULD use |
| Sequence | | Standard | | |
| Protection| | | | |
| (PAWS) | | | | |
+-----------+------------+--------------+------------+------------+
+-----------+------------+--------------+------------+------------+
| Feature | Applicable | RFC | Peer-Wise | Requirement|
| | RFCs | Status | Agreement | Level |
| | | | Required? | |
+===========+============+==============+============+============+
| Keep Alive| [RFC1122] | None | No | Should not |
| |(discussion)| | | use |
+-----------+------------+--------------+------------+------------+
| Tiny | [RFC896] | Standard | No | Should not |
| Segment | | | | use |
| Avoidance | | | | |
| (Nagle) | | | | |
+-----------+------------+--------------+------------+------------+
| Window | [RFC1323] | Proposed | No | Should use |
| Scale | | Standard | | |
+-----------+------------+--------------+------------+------------+
| Wrapped | [RFC1323] | Proposed | No | SHOULD use |
| Sequence | | Standard | | |
| Protection| | | | |
| (PAWS) | | | | |
+-----------+------------+--------------+------------+------------+
Table 1. Usage of Optional TCP Features
表1。使用可选的TCP功能
The following sections describe these options in greater detail.
以下各节将更详细地描述这些选项。
Keep Alive speeds the detection and cleanup of dysfunctional TCP connections by sending traffic when a connection would otherwise be idle. The issues are discussed in [RFC1122].
Keep Alive通过在连接可能处于空闲状态时发送流量来加快检测和清除功能异常的TCP连接。[RFC1122]中讨论了这些问题。
In order to test the device more comprehensively, fibre channel applications, such as storage, may implement an equivalent keep alive function at the FC-4 level. Alternatively, periodic liveness test messages may be issued as described in Section 5.2.2.4. Because of these more comprehensive end-to-end mechanisms and the considerations described in [RFC1122], keep alive at the transport layer should not be implemented.
为了更全面地测试设备，光纤通道应用程序（如存储）可以在FC-4级别实现等效的保持活动功能。或者，可按照第5.2.2.4节所述发布定期活性测试消息。由于这些更全面的端到端机制和[RFC1122]中所述的注意事项，不应在传输层实现keep alive。
The Nagle algorithm described in [RFC896] is designed to avoid the overhead of small segments by delaying transmission in order to agglomerate transfer requests into a large segment. In iFCP, such small transfers often contain I/O requests. The transmission delay of the Nagle algorithm may decrease I/O throughput. Therefore, the Nagle algorithm should not be used.
[RFC896]中描述的Nagle算法旨在通过延迟传输避免小段的开销，以便将传输请求聚合到大段中。在iFCP中，这样的小传输通常包含I/O请求。Nagle算法的传输延迟可能会降低I/O吞吐量。因此，不应使用Nagle算法。
Window scaling, as specified in [RFC1323], allows full use of links with large bandwidth - delay products and should be supported by an iFCP implementation.
[RFC1323]中规定的窗口缩放允许充分使用具有大带宽延迟产品的链路，并且应该由iFCP实现支持。
TCP segments are identified with 32-bit sequence numbers. In networks with large bandwidth - delay products, it is possible for more than one TCP segment with the same sequence number to be in flight. In iFCP, receipt of such a sequence out of order may cause out-of-order frame delivery or data corruption. Consequently, this feature SHOULD be supported as described in [RFC1323].
TCP段由32位序列号标识。在具有大带宽延迟产品的网络中，可能有多个具有相同序列号的TCP段在传输中。在iFCP中，无序接收此类序列可能会导致无序帧传递或数据损坏。因此，应按照[RFC1323]中的说明支持此功能。
iFCP sessions SHALL be terminated in response to one of the events in Table 2:
iFCP会议应根据表2中的事件之一终止：
+-------------------------------------------+---------------------+
| Event | iFCP Sessions |
| | to Terminate |
+===========================================+=====================+
| PLOGI terminated with LS_RJT response | Peer N_PORT |
+-------------------------------------------+---------------------+
| State change notification indicating | All iFCP Sessions |
| N_PORT removal or reconfiguration. | from the |
| | reconfigured N_PORT |
+-------------------------------------------+---------------------+
| LOGO ACC response from peer N_PORT | Peer N_PORT |
+-------------------------------------------+---------------------+
| ACC response to LOGO ELS sent to F_PORT | All iFCP sessions |
| server (D_ID = 0xFF-FF-FE) (fabric | from the originating|
| logout) | N_PORT |
+-------------------------------------------+---------------------+
| Implicit N_PORT LOGO as defined in | All iFCP sessions |
| [FC-FS] | from the N_PORT |
| | logged out |
+-------------------------------------------+---------------------+
| LTEST Message Error (see Section 5.2.2.4) | Peer N_PORT |
+-------------------------------------------+---------------------+
| Non fatal encapsulation error as | Peer N_PORT |
| specified in Section 5.3.3 | |
+-------------------------------------------+---------------------+
| Failure of the TCP connection associated | Peer N_PORT |
| with the iFCP session | |
+-------------------------------------------+---------------------+
| Receipt of an UNBIND session control | Peer N_PORT |
| message | |
+-------------------------------------------+---------------------+
| Gateway enters the Unsynchronized state | All iFCP sessions |
| (see Section 8.2.1) | |
+-------------------------------------------+---------------------+
| Gateway detects incorrect address mode | All iFCP sessions |
| to peer gateway(see Section 4.6.2) | with peer gateway |
+-------------------------------------------+---------------------+
+-------------------------------------------+---------------------+
| Event | iFCP Sessions |
| | to Terminate |
+===========================================+=====================+
| PLOGI terminated with LS_RJT response | Peer N_PORT |
+-------------------------------------------+---------------------+
| State change notification indicating | All iFCP Sessions |
| N_PORT removal or reconfiguration. | from the |
| | reconfigured N_PORT |
+-------------------------------------------+---------------------+
| LOGO ACC response from peer N_PORT | Peer N_PORT |
+-------------------------------------------+---------------------+
| ACC response to LOGO ELS sent to F_PORT | All iFCP sessions |
| server (D_ID = 0xFF-FF-FE) (fabric | from the originating|
| logout) | N_PORT |
+-------------------------------------------+---------------------+
| Implicit N_PORT LOGO as defined in | All iFCP sessions |
| [FC-FS] | from the N_PORT |
| | logged out |
+-------------------------------------------+---------------------+
| LTEST Message Error (see Section 5.2.2.4) | Peer N_PORT |
+-------------------------------------------+---------------------+
| Non fatal encapsulation error as | Peer N_PORT |
| specified in Section 5.3.3 | |
+-------------------------------------------+---------------------+
| Failure of the TCP connection associated | Peer N_PORT |
| with the iFCP session | |
+-------------------------------------------+---------------------+
| Receipt of an UNBIND session control | Peer N_PORT |
| message | |
+-------------------------------------------+---------------------+
| Gateway enters the Unsynchronized state | All iFCP sessions |
| (see Section 8.2.1) | |
+-------------------------------------------+---------------------+
| Gateway detects incorrect address mode | All iFCP sessions |
| to peer gateway(see Section 4.6.2) | with peer gateway |
+-------------------------------------------+---------------------+
Table 2. Session Termination Events
表2。会话终止事件
If a session is being terminated due to an incorrect address mode with the peer gateway, the TCP connection SHALL be aborted by means of a connection reset (RST) without performing an UNBIND. Otherwise, if the TCP connection is still open following the event, the gateway SHALL shut down the connection as follows:
如果由于对等网关的地址模式不正确而终止会话，则应通过连接重置（RST）中止TCP连接，而不执行解除绑定。否则，如果事件发生后TCP连接仍处于打开状态，则网关应按如下方式关闭连接：
a) Stop sending fibre channel frames over the TCP connection.
a) 停止通过TCP连接发送光纤通道帧。
b) Discard all incoming traffic, except for an UNBIND session control message.
b) 放弃所有传入的通信量，但取消绑定会话控制消息除外。
c) If an UNBIND message is received at any time, return a response in accordance with Section 6.2.
c) 如果在任何时候收到解除绑定消息，根据第6.2节返回响应。
d) If session termination was not triggered by an UNBIND message, issue the UNBIND session control message, as described in Section 6.2.
d) 如果会话终止不是由解除绑定消息触发的，则发出解除绑定会话控制消息，如第6.2节所述。
e) If the UNBIND message completes with a status of Success, the TCP connection MAY remain open at the discretion of either gateway and may be kept in a pool of unbound connections in order to speed up the creation of a new iFCP session.
e) 如果解除绑定消息以成功状态完成，则TCP连接可由任一网关自行决定保持打开状态，并可保留在未绑定连接池中，以加快新iFCP会话的创建。
If the UNBIND fails for any reason, the TCP connection MUST be terminated. In this case, the connection SHOULD be aborted with a connection reset (RST).
如果解除绑定因任何原因失败，则必须终止TCP连接。在这种情况下，应通过连接重置（RST）中止连接。
For each terminated session, the session descriptor SHALL be deleted. If a session was terminated by an event other than an implicit LOGO or a LOGO ACC response, the gateway shall issue a LOGO to the locally attached N_PORT on behalf of the remote N_PORT.
对于每个终止的会话，应删除会话描述符。如果会话被非隐式徽标或徽标ACC响应的事件终止，网关应代表远程N_端口向本地连接的N_端口发出徽标。
To recover resources, either gateway may spontaneously close an unbound TCP connection at any time. If a gateway terminates a connection with a TCP close operation, the peer gateway MUST respond by executing a TCP close.
为了恢复资源，任一网关都可以随时自动关闭未绑定的TCP连接。如果网关通过TCP关闭操作终止连接，对等网关必须通过执行TCP关闭来响应。
This section describes the iFCP encapsulation of fibre channel frames. The encapsulation complies with the common encapsulation format defined in [ENCAP], portions of which are included here for convenience.
本节介绍光纤通道帧的iFCP封装。封装符合[ENCAP]中定义的通用封装格式，为方便起见，此处包含了部分封装格式。
The format of an encapsulated frame is shown below:
封装帧的格式如下所示：
+--------------------+
| Header |
+--------------------+-----+
| SOF | f |
+--------------------+ F r |
| FC frame content | C a |
+--------------------+ m |
| EOF | e |
+--------------------+-----+
+--------------------+
| Header |
+--------------------+-----+
| SOF | f |
+--------------------+ F r |
| FC frame content | C a |
+--------------------+ m |
| EOF | e |
+--------------------+-----+
Figure 12. Encapsulation Format
图12。封装格式
The encapsulation consists of a 7-word header, an SOF delimiter word, the FC frame (including the fibre channel CRC), and an EOF delimiter word. The header and delimiter formats are described in the following sections.
封装由7字头、SOF分隔符字、FC帧（包括光纤通道CRC）和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 |
+---------------+---------------+---------------+---------------+
1| Reserved (must be zero) |
+---------------+---------------+---------------+---------------+
2| LS_COMMAND_ACC| iFCP Flags | SOF | EOF |
+-----------+---+---------------+-----------+---+---------------+
3| Flags | Frame Length | -Flags | -Frame Length |
+-----------+-------------------+-----------+-------------------+
4| Time Stamp [integer] |
+---------------------------------------------------------------+
5| Time Stamp [fraction] |
+---------------------------------------------------------------+
6| CRC |
+---------------------------------------------------------------+
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------+---------------+---------------+---------------+
0| Protocol# | Version | -Protocol# | -Version |
+---------------+---------------+---------------+---------------+
1| Reserved (must be zero) |
+---------------+---------------+---------------+---------------+
2| LS_COMMAND_ACC| iFCP Flags | SOF | EOF |
+-----------+---+---------------+-----------+---+---------------+
3| Flags | Frame Length | -Flags | -Frame Length |
+-----------+-------------------+-----------+-------------------+
4| Time Stamp [integer] |
+---------------------------------------------------------------+
5| Time Stamp [fraction] |
+---------------------------------------------------------------+
6| CRC |
+---------------------------------------------------------------+
Figure 13. Encapsulation Header Format
图13。封装头格式
Common Encapsulation Fields:
通用封装字段：
Protocol# IANA-assigned protocol number identifying the protocol using the encapsulation. For iFCP, the value assigned by [ENCAP] is 2.
协议#IANA分配的协议编号，用于标识使用封装的协议。对于iFCP，[ENCAP]指定的值为2。
Version Encapsulation version, as specified in [ENCAP].
版本封装版本，如[ENCAP]中所述。
-Protocol# Ones complement of the Protocol#.
-协议是协议的补充。
-Version Ones complement of the version.
-版本是版本的补充。
Flags Encapsulation flags (see 5.3.1.1).
标志封装标志（见5.3.1.1）。
Frame Length Contains the length of the entire FC Encapsulated frame, including the FC Encapsulation Header and the FC frame (including SOF and EOF words) in units of 32-bit words.
帧长度包含整个FC封装帧的长度，包括FC封装头和FC帧（包括SOF和EOF字），以32位字为单位。
-Flags Ones complement of the Flags field.
-标志是标志字段的补充。
-Frame Length Ones complement of the Frame Length field.
-帧长度是帧长度字段的补充。
Time Stamp [integer] Integer component of the frame time stamp, as specified in [ENCAP].
时间戳[integer]帧时间戳的整数组件，如[ENCAP]中所指定。
Time Stamp Fractional component of the time stamp, [fraction] as specified in [ENCAP].
[ENCAP]中指定的时间戳分数分量[fraction]。
CRC Header CRC. MUST be valid for iFCP.
CRC头CRC。必须对iFCP有效。
The time stamp fields are used to enforce the limit on the lifetime of a fibre channel frame as described in Section 8.2.1.
时间戳字段用于强制执行第8.2.1节所述的光纤通道帧寿命限制。
iFCP-Specific Fields:
iFCP特定字段：
LS_COMMAND_ACC For a special link service ACC response to be processed by iFCP, the LS_COMMAND_ACC field SHALL contain a copy of bits 0 through 7 of the LS_COMMAND to which the ACC applies. Otherwise, the LS_COMMAND_ACC field SHALL be set to zero.
LS_命令\u ACC对于将由iFCP处理的特殊链路服务ACC响应，LS_命令\u ACC字段应包含ACC适用的LS_命令第0位到第7位的副本。否则，LS_命令_ACC字段应设置为零。
iFCP Flags iFCP-specific flags (see below).
iFCP标志iFCP特定标志（见下文）。
SOF Copy of the SOF delimiter encoding (see Section 5.3.2).
SOF分隔符编码的SOF副本（见第5.3.2节）。
EOF Copy of the EOF delimiter encoding (see Section 5.3.2).
EOF定界符编码的EOF副本（见第5.3.2节）。
The iFCP flags word has the following format:
iFCP标志字的格式如下：
|------------------------Bit----------------------------|
| |
| 8 9 10 11 12 13 14 15 |
+------+------+------+------+------+------+------+------+
| Reserved | SES | TRP | SPC |
+------+------+------+------+------+------+------+------+
|------------------------Bit----------------------------|
| |
| 8 9 10 11 12 13 14 15 |
+------+------+------+------+------+------+------+------+
| Reserved | SES | TRP | SPC |
+------+------+------+------+------+------+------+------+
Figure 14. iFCP Flags Word
图14。iFCP标志字
iFCP Flags:
iFCP标志：
SES 1 = Session control frame (TRP and SPC MUST be 0)
SES 1=会话控制帧（TRP和SPC必须为0）
TRP 1 = Address transparent mode enabled
TRP 1=地址透明模式已启用
0 = Address translation mode enabled
0 = Address translation mode enabled
SPC 1 = Frame is part of a link service message requiring special processing by iFCP prior to forwarding to the destination N_PORT.
SPC 1=帧是链路服务消息的一部分，需要在转发到目标N_端口之前由iFCP进行特殊处理。
The iFCP usage of the common encapsulation flags defined in [ENCAP] is shown in Figure 15:
[ENCAP]中定义的通用封装标志的iFCP用法如图15所示：
|------------------------Bit--------------------------|
| |
| 0 1 2 3 4 5 |
+--------------------------------------------+--------+
| Reserved | CRCV |
+--------------------------------------------+--------+
|------------------------Bit--------------------------|
| |
| 0 1 2 3 4 5 |
+--------------------------------------------+--------+
| Reserved | CRCV |
+--------------------------------------------+--------+
Figure 15. iFCP Common Encapsulation Flags
图15。通用封装标志
For iFCP, the CRC field MUST be valid, and CRCV MUST be set to one.
对于iFCP，CRC字段必须有效，并且CRCV必须设置为1。
The format of the delimiter fields is shown below.
分隔符字段的格式如下所示。
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------+---------------+---------------+---------------+
0| SOF | SOF | -SOF | -SOF |
+---------------+---------------+---------------+---------------+
1| |
+----- FC frame content -----+
| |
+---------------+---------------+---------------+---------------+
n| EOF | EOF | -EOF | -EOF |
+---------------+---------------+---------------+---------------+
W|------------------------------Bit------------------------------|
o| |
r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 3 3|
d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
+---------------+---------------+---------------+---------------+
0| SOF | SOF | -SOF | -SOF |
+---------------+---------------+---------------+---------------+
1| |
+----- FC frame content -----+
| |
+---------------+---------------+---------------+---------------+
n| EOF | EOF | -EOF | -EOF |
+---------------+---------------+---------------+---------------+
Figure 16. FC Frame Encapsulation Format
图16。FC帧封装格式
SOF (bits 0-7 and bits 8-15 in word 0): iFCP uses the following subset of the SOF fields specified in [ENCAP]. For convenience, these are reproduced in Table 3. The authoritative encodings should be obtained from [ENCAP].
SOF（字0中的位0-7和位8-15）：iFCP使用[ENCAP]中指定的SOF字段的以下子集。为方便起见，表3中重现了这些数据。权威编码应从[ENCAP]获取。
+-------+----------+
| FC | |
| SOF | SOF Code |
+-------+----------+
| SOFi2 | 0x2D |
| SOFn2 | 0x35 |
| SOFi3 | 0x2E |
| SOFn3 | 0x36 |
+-------+----------+
+-------+----------+
| FC | |
| SOF | SOF Code |
+-------+----------+
| SOFi2 | 0x2D |
| SOFn2 | 0x35 |
| SOFi3 | 0x2E |
| SOFn3 | 0x36 |
+-------+----------+
Table 3. Translation of FC SOF Values to SOF Field Contents
表3。将FC SOF值转换为SOF字段内容
-SOF (bits 16-23 and 24-31 in word 0): The -SOF fields contain the ones complement the value in the SOF fields.
-SOF（字0中的位16-23和24-31）：-SOF字段包含补充SOF字段中值的字段。
EOF (bits 0-7 and 8-15 in word n): iFCP uses the following subset of EOF fields specified in [ENCAP]. For convenience, these are reproduced in Table 4. The authoritative encodings should be obtained from [ENCAP].
EOF（字n中的位0-7和8-15）：iFCP使用[ENCAP]中指定的以下EOF字段子集。为方便起见，表4中重现了这些数据。权威编码应从[ENCAP]获取。
+-------+----------+
| FC | |
| EOF | EOF Code |
+-------+----------+
| EOFn | 0x41 |
| EOFt | 0x42 |
+-------+----------+
+-------+----------+
| FC | |
| EOF | EOF Code |
+-------+----------+
| EOFn | 0x41 |
| EOFt | 0x42 |
+-------+----------+
Table 4. Translation of FC EOF Values to EOF Field Contents
表4。将FC EOF值转换为EOF字段内容
-EOF (bits 16-23 and 24-31 in word n): The -EOF fields contain the ones complement the value in the EOF fields.
-EOF（字n中的位16-23和24-31）：-EOF字段包含补充EOF字段值的字段。
iFCP implementations SHALL place a copy of the SOF and EOF delimiter codes in the appropriate header fields.
iFCP实施应将SOF和EOF分隔符代码的副本放在适当的标题字段中。
A fibre channel Frame to be encapsulated MUST first be validated as described in [FC-FS]. Any frames received from a locally attached fibre channel device that do not pass the validity tests in [FC-FS] SHALL be discarded by the gateway.
要封装的光纤通道帧必须首先按照[FC-FS]中的说明进行验证。网关应丢弃从本地连接的光纤通道设备接收的未通过[FC-FS]中有效性测试的任何帧。
If the frame is a PLOGI ELS, the creation of an iFCP session, as described in Section 7.3.1.7, may precede encapsulation. Once the session has been created, frame encapsulation SHALL proceed as follows.
如果框架是PLOGI ELS，则如第7.3.1.7节所述，可在封装之前创建iFCP会话。创建会话后，帧封装应按以下步骤进行。
The S_ID and D_ID fields in the frame header SHALL be referenced to look up the iFCP session descriptor (see Section 5.2.2.2). If no iFCP session descriptor exists, the frame SHALL be discarded.
帧头中的S_ID和D_ID字段应被引用以查找iFCP会话描述符（见第5.2.2.2节）。如果不存在iFCP会话描述符，则应丢弃该帧。
Frame types submitted for encapsulation and forwarding on the IP network SHALL have one of the SOF delimiters in Table 3 and an EOF delimiter from Table 4. Other valid frame types MUST be processed internally by the gateway as specified in the appropriate fibre channel specification.
提交用于IP网络封装和转发的帧类型应具有表3中的一个SOF分隔符和表4中的一个EOF分隔符。其他有效帧类型必须由网关按照相应光纤通道规范中的规定在内部处理。
If operating in address translation mode and processing a special link service message requiring the inclusion of supplemental data, the gateway SHALL format the frame payload and add the supplemental information specified in Section 7.1. The gateway SHALL then calculate a new FC CRC on the reformatted frame.
如果在地址转换模式下运行并处理需要包含补充数据的特殊链路服务消息，网关应格式化帧有效载荷并添加第7.1节中规定的补充信息。然后，网关应在重新格式化的帧上计算新的FC CRC。
Otherwise, the frame contents SHALL NOT be modified and the gateway MAY encapsulate and transmit the frame image without recalculating the FC CRC.
否则，不应修改帧内容，网关可封装和传输帧图像，而无需重新计算FC CRC。
The frame originator MUST then create and fill in the header and the SOF and EOF delimiter words, as specified in Sections 5.3.1 and 5.3.2.
然后，框架发起人必须按照第5.3.1节和第5.3.2节的规定，创建并填写标题以及SOF和EOF分隔符。
The receiving gateway SHALL perform de-encapsulation as follows:
接收网关应按如下方式进行反封装：
Upon receiving the encapsulated frame, the gateway SHALL check the header CRC. If the header CRC is valid, the receiving gateway SHALL check the iFCP flags field. If one of the error conditions in Table 5 is detected, the gateway SHALL handle the error as specified in Section 5.2.3.
收到封装帧后，网关应检查报头CRC。如果报头CRC有效，接收网关应检查iFCP标志字段。如果检测到表5中的一种错误情况，网关应按照第5.2.3节的规定处理该错误。
+------------------------------+-------------------------+
| Condition | Error Type |
+==============================+=========================+
| Header CRC Invalid | Encapsulation error |
+------------------------------+-------------------------+
| SES = 1, TRP or SPC not 0 | Encapsulation error |
+------------------------------+-------------------------+
| SES = 0, TRP set incorrectly | Incorrect address mode |
+------------------------------+-------------------------+
+------------------------------+-------------------------+
| Condition | Error Type |
+==============================+=========================+
| Header CRC Invalid | Encapsulation error |
+------------------------------+-------------------------+
| SES = 1, TRP or SPC not 0 | Encapsulation error |
+------------------------------+-------------------------+
| SES = 0, TRP set incorrectly | Incorrect address mode |
+------------------------------+-------------------------+
Table 5. Encapsulation Header Errors
表5。封装头错误
The receiving gateway SHALL then verify the frame propagation delay as described in Section 8.2.1. If the propagation delay is too long, the frame SHALL be discarded. Otherwise, the gateway SHALL check the SOF and EOF in the encapsulation header. A frame SHALL be discarded if it has an SOF code that is not in Table 3 or an EOF code that is not in Table 4.
然后，接收网关应按照第8.2.1节所述验证帧传播延迟。如果传播延迟太长，则应丢弃该帧。否则，网关应检查封装头中的SOF和EOF。如果帧的SOF代码不在表3中或EOF代码不在表4中，则应丢弃该帧。
The gateway SHALL then de-encapsulate the frame as follows:
然后，网关应按如下方式解除框架的封装：
a) Check the FC CRC and discard the frame if the CRC is invalid.
a) 检查FC CRC，如果CRC无效，则丢弃帧。
b) If operating in address translation mode, replace the S_ID field with the N_PORT alias of the frame originator, and the D_ID with the N_PORT ID, of the frame recipient. Both parameters SHALL be obtained from the iFCP session descriptor.
b) 如果在地址转换模式下操作，请将S_ID字段替换为帧发起者的N_端口别名，将D_ID替换为帧收件人的N_端口ID。这两个参数都应从iFCP会话描述符中获取。
c) If processing a special link service message, replace the frame with a copy whose payload has been modified as specified in Section 7.1.
c) 如果处理特殊链路服务消息，则用有效载荷已按第7.1节规定修改的副本替换帧。
The de-encapsulated frame SHALL then be forwarded to the N_PORT specified in the D_ID field. If the frame contents have been modified by the receiving gateway, a new FC CRC SHALL be calculated.
然后，应将解除封装的帧转发至D_ID字段中指定的N_端口。如果接收网关修改了帧内容，则应计算新的FC CRC。
TCP session control messages are used to create and manage an iFCP session as described in Section 5.2.2. They are passed between peer iFCP Portals and are only processed within the iFCP layer.
TCP会话控制消息用于创建和管理iFCP会话，如第5.2.2节所述。它们在对等iFCP门户之间传递，并且仅在iFCP层内处理。
The message format is based on the fibre channel extended link service message template shown below.
消息格式基于如下所示的光纤通道扩展链路服务消息模板。
Word
0<--Bits-->7 8<---------------Bits------------------------>31
+------------+------------------------------------------------+
0| R_CTL | D_ID [0x00 00 00] |
|[Req = 0x22]| [Destination of extended link Service request] |
|[Rep = 0x23]| |
+------------+------------------------------------------------+
1| CS_CTL | S_ID [0x00 00 00] |
| [0x0] | [Source of extended link service request] |
+------------+------------------------------------------------+
2|TYPE [0x1] | F_CTL [0] |
+------------+------------------+-----------------------------+
3|SEQ_ID | DF_CTL [0x00] | SEQ_CNT [0x00] |
|[0x0] | | |
+------------+------------------+-----------------------------+
4| OX_ID [0x0000] | RX_ID_[0x0000] |
+-------------------------------+-----------------------------+
5| Parameter |
| [ 00 00 00 00 ] |
+-------------------------------------------------------------+
6| LS_COMMAND |
| [Session Control Command Code] |
+-------------------------------------------------------------+
7| |
.| Additional Session Control Parameters |
.| ( if any ) |
n| |
+=============================================================+
n| Fibre Channel CRC |
+| |
1+=============================================================+
Word
0<--Bits-->7 8<---------------Bits------------------------>31
+------------+------------------------------------------------+
0| R_CTL | D_ID [0x00 00 00] |
|[Req = 0x22]| [Destination of extended link Service request] |
|[Rep = 0x23]| |
+------------+------------------------------------------------+
1| CS_CTL | S_ID [0x00 00 00] |
| [0x0] | [Source of extended link service request] |
+------------+------------------------------------------------+
2|TYPE [0x1] | F_CTL [0] |
+------------+------------------+-----------------------------+
3|SEQ_ID | DF_CTL [0x00] | SEQ_CNT [0x00] |
|[0x0] | | |
+------------+------------------+-----------------------------+
4| OX_ID [0x0000] | RX_ID_[0x0000] |
+-------------------------------+-----------------------------+
5| Parameter |
| [ 00 00 00 00 ] |
+-------------------------------------------------------------+
6| LS_COMMAND |
| [Session Control Command Code] |
+-------------------------------------------------------------+
7| |
.| Additional Session Control Parameters |
.| ( if any ) |
n| |
+=============================================================+
n| Fibre Channel CRC |
+| |
1+=============================================================+
Figure 17. Format of Session Control Message
图17。会话控制消息的格式
The LS_COMMAND value for the response remains the same as that used for the request.
响应的LS_命令值与请求的LS_命令值相同。
The session control frame is terminated with a fibre channel CRC. The frame SHALL be encapsulated and de-encapsulated according to the rules specified in Section 5.3.
会话控制帧以光纤通道CRC终止。框架应根据第5.3节规定的规则进行封装和去封装。
The encapsulation header for the link Service frame carrying a session control message SHALL be set as follows:
承载会话控制消息的链路服务帧的封装头应设置如下：
Encapsulation Header Fields:
封装头字段：
LS_COMMAND_ACC 0
LS_命令_附件0
iFCP Flags SES = 1
iFCP标志SES=1
TRP = 0
TRP = 0
INT = 0
INT = 0
SOF code SOFi3 encoding (0x2E)
SOF代码SOFi3编码（0x2E）
EOF code EOFt encoding (0x42)
EOF代码EOFt编码（0x42）
The encapsulation time stamp words SHALL be set as described for each message type.
封装时间戳字应按照每种消息类型的说明进行设置。
The SOF and EOF delimiter words SHALL be set based on the SOF and EOF codes specified above.
SOF和EOF分隔符应根据上述SOF和EOF代码进行设置。
Table 6 lists the values assigned to byte 0 of the LS_COMMAND field for iFCP session control messages.
表6列出了分配给iFCP会话控制消息LS_命令字段字节0的值。
+--------------+-------------------------+----------+-------------+
| LS_COMMAND | Function | Mnemonic | iFCP |
| field, byte 0| | | Support |
+--------------+-------------------------+----------+-------------+
| 0xE0 | Connection Bind | CBIND | REQUIRED |
+--------------+-------------------------+----------+-------------+
| 0xE4 | Unbind Connection | UNBIND | REQUIRED |
+--------------+-------------------------+----------+-------------+
| 0xE5 | Test Connection Liveness| LTEST | REQUIRED |
+--------------+-------------------------+----------+-------------+
| 0x01-0x7F | Vendor-Specific | | |
+--------------+-------------------------+----------+-------------+
| 0x00 | Reserved -- Unassignable| | |
+--------------+-------------------------+----------+-------------+
| All other | Reserved | | |
| values | | | |
+--------------+-------------------------+----------+-------------+
+--------------+-------------------------+----------+-------------+
| LS_COMMAND | Function | Mnemonic | iFCP |
| field, byte 0| | | Support |
+--------------+-------------------------+----------+-------------+
| 0xE0 | Connection Bind | CBIND | REQUIRED |
+--------------+-------------------------+----------+-------------+
| 0xE4 | Unbind Connection | UNBIND | REQUIRED |
+--------------+-------------------------+----------+-------------+
| 0xE5 | Test Connection Liveness| LTEST | REQUIRED |
+--------------+-------------------------+----------+-------------+
| 0x01-0x7F | Vendor-Specific | | |
+--------------+-------------------------+----------+-------------+
| 0x00 | Reserved -- Unassignable| | |
+--------------+-------------------------+----------+-------------+
| All other | Reserved | | |
| values | | | |
+--------------+-------------------------+----------+-------------+
Table 6. Session Control LS_COMMAND Field, Byte 0 Values
表6。会话控制LS_命令字段，字节0值
As described in Section 5.2.2.2, the CBIND message and response are used to bind an N_PORT login to a specific TCP connection and establish an iFCP session. In the CBIND request message, the source and destination N_PORTs are identified by their worldwide port names. The time stamp words in the encapsulation header SHALL be set to zero in the request and response message frames.
如第5.2.2.2节所述，CBIND消息和响应用于将N_端口登录绑定到特定TCP连接并建立iFCP会话。在CBIND请求消息中，源和目标N_端口由其全球端口名标识。在请求和响应消息帧中，封装头中的时间戳字应设置为零。
The following shows the format of the CBIND request.
下面显示了CBIND请求的格式。
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver |
| | (Seconds) | | |
+------+-------------------------+-----------+----------+
| 2 | USER INFO |
+------+------------+------------+-----------+----------+
| 3 | |
+------+ SOURCE N_PORT NAME |
| 4 | |
+------+------------------------------------------------+
| 5 | |
+------+ DESTINATION N_PORT NAME |
| 6 | |
+------+------------------------------------------------+
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver |
| | (Seconds) | | |
+------+-------------------------+-----------+----------+
| 2 | USER INFO |
+------+------------+------------+-----------+----------+
| 3 | |
+------+ SOURCE N_PORT NAME |
| 4 | |
+------+------------------------------------------------+
| 5 | |
+------+ DESTINATION N_PORT NAME |
| 6 | |
+------+------------------------------------------------+
Addr Mode: The addressing mode of the originating gateway. 0 = Address Translation mode; 1 = Address Transparent mode.
Addr模式：发起网关的寻址模式。0=地址转换模式；1=地址透明模式。
iFCP Ver: iFCP version number. SHALL be set to 1.
iFCP版本：iFCP版本号。应设置为1。
LIVENESS TEST If non-zero, requests that the receiving INTERVAL: gateway transmit an LTEST message at the specified interval in seconds. If set to zero, LTEST messages SHALL NOT be sent.
活跃度测试如果非零，则请求接收间隔：网关以指定的间隔（秒）发送LTEST消息。如果设置为零，则不应发送LTEST消息。
USER INFO: Contains any data desired by the requestor. This information MUST be echoed by the recipient in the CBIND response message.
用户信息：包含请求者所需的任何数据。收件人必须在CBIND响应消息中回显此信息。
SOURCE N_PORT NAME: The Worldwide Port Name (WWPN) of the N_PORT locally attached to the gateway originating the CBIND request.
源N_端口名称：本地连接到发起CBIND请求的网关的N_端口的全球端口名称（WWPN）。
DESTINATION N_PORT The Worldwide Port Name (WWPN) of the NAME: N_PORT locally attached to the gateway receiving the CBIND request.
DESTINATION N_PORT名称的全球端口名（WWPN）：本地连接到接收CBIND请求的网关的N_PORT。
The following shows the format of the CBIND response.
下面显示了CBIND响应的格式。
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver |
| | (Seconds) | | |
+------+-------------------------+-----------+----------+
| 2 | USER INFO |
+------+------------+------------+-----------+----------+
| 3 | |
+------+ SOURCE N_PORT NAME |
| 4 | |
+------+------------------------------------------------+
| 5 | |
+------+ DESTINATION N_PORT NAME |
| 6 | |
+------+-------------------------+----------------------+
| 7 | Reserved | CBIND Status |
+------+-------------------------+----------------------+
| 8 | Reserved | CONNECTION HANDLE |
+------+-------------------------+----------------------+
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver |
| | (Seconds) | | |
+------+-------------------------+-----------+----------+
| 2 | USER INFO |
+------+------------+------------+-----------+----------+
| 3 | |
+------+ SOURCE N_PORT NAME |
| 4 | |
+------+------------------------------------------------+
| 5 | |
+------+ DESTINATION N_PORT NAME |
| 6 | |
+------+-------------------------+----------------------+
| 7 | Reserved | CBIND Status |
+------+-------------------------+----------------------+
| 8 | Reserved | CONNECTION HANDLE |
+------+-------------------------+----------------------+
Total Length = 36
总长度=36
Addr Mode: The address translation mode of the responding gateway. 0 = Address Translation mode, 1 = Address Transparent mode.
Addr Mode：响应网关的地址转换模式。0=地址转换模式，1=地址透明模式。
iFCP Ver: iFCP version number. Shall be set to 1.
iFCP版本：iFCP版本号。应设置为1。
LIVENESS TEST If non-zero, requests that the gateway INTERVAL: receiving the CBIND RESPONSE transmit an LTEST message at the specified interval in seconds. If zero, LTEST messages SHALL NOT be sent.
活跃度测试如果非零，则请求网关间隔：接收CBIND响应以秒为单位以指定间隔发送LTEST消息。如果为零，则不应发送LTEST消息。
USER INFO: Echoes the value received in the USER INFO field of the CBIND request message.
用户信息：回显在CBIND请求消息的用户信息字段中接收到的值。
SOURCE N_PORT NAME: Contains the Worldwide Port Name (WWPN) of the N_PORT locally attached to the gateway issuing the CBIND request.
源N_端口名称：包含本地连接到发出CBIND请求的网关的N_端口的全球端口名称（WWPN）。
DESTINATION N_PORT Contains the Worldwide Port Name (WWPN) of NAME: the N_PORT locally attached to the gateway issuing the CBIND response.
目标N_端口包含名称的全球端口名（WWPN）：本地连接到发出CBIND响应的网关的N_端口。
CBIND STATUS: Indicates success or failure of the CBIND request. CBIND values are shown below.
CBIND状态：指示CBIND请求的成功或失败。CBIND值如下所示。
CONNECTION HANDLE: Contains a value assigned by the gateway to identify the connection. The connection handle is required when the UNBIND request is issued.
连接句柄：包含网关分配的用于标识连接的值。发出解除绑定请求时需要连接句柄。
CBIND Status Description
------------ -----------
CBIND Status Description
------------ -----------
0 Success 1 - 15 Reserved 16 Failed - Unspecified Reason 17 Failed - No such device 18 Failed - iFCP session already exists 19 Failed - Lack of resources 20 Failed - Incompatible address translation mode 21 Failed - Incorrect protocol version number 22 Failed - Gateway not Synchronized (see Section 8.2) Others Reserved
0成功1-15保留16失败-未指定原因17失败-无此类设备18失败-iFCP会话已存在19失败-资源不足20失败-不兼容的地址转换模式21失败-不正确的协议版本号22失败-网关未同步（请参阅第8.2节）其他保留
UNBIND is used to terminate an iFCP session and disassociate the TCP connection as described in Section 5.2.3.
解除绑定用于终止iFCP会话并解除TCP连接的关联，如第5.2.3节所述。
The UNBIND message is transmitted over the connection that is to be unbound. The time stamp words in the encapsulation header shall be set to zero in the request and response message frames.
解除绑定消息通过要解除绑定的连接传输。在请求和响应消息帧中，封装头中的时间戳字应设置为零。
The following is the format of the UNBIND request message.
以下是解除绑定请求消息的格式。
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | USER INFO |
+------+------------+------------+-----------+----------+
| 2 | Reserved | CONNECTION HANDLE |
+------+------------+------------+----------------------+
| 3 | Reserved |
+------+------------+------------+-----------+----------+
| 4 | Reserved |
+------+------------+------------+-----------+----------+
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | USER INFO |
+------+------------+------------+-----------+----------+
| 2 | Reserved | CONNECTION HANDLE |
+------+------------+------------+----------------------+
| 3 | Reserved |
+------+------------+------------+-----------+----------+
| 4 | Reserved |
+------+------------+------------+-----------+----------+
USER INFO Contains any data desired by the requestor. This information MUST be echoed by the recipient in the UNBIND response message.
用户信息包含请求者所需的任何数据。收件人必须在解除绑定响应消息中回显此信息。
CONNECTION HANDLE: Contains the gateway-assigned value from the CBIND request.
连接句柄：包含来自CBIND请求的网关分配值。
The following shows the format of the UNBIND response message.
以下显示解除绑定响应消息的格式。
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | USER INFO |
+------+------------+------------+-----------+----------+
| 2 | Reserved | CONNECTION HANDLE |
+------+------------+------------+-----------+----------+
| 3 | Reserved |
+------+------------+------------+-----------+----------+
| 4 | Reserved |
+------+------------+------------+-----------+----------+
| 5 | Reserved | UNBIND STATUS |
+------+------------+------------+-----------+----------+
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | USER INFO |
+------+------------+------------+-----------+----------+
| 2 | Reserved | CONNECTION HANDLE |
+------+------------+------------+-----------+----------+
| 3 | Reserved |
+------+------------+------------+-----------+----------+
| 4 | Reserved |
+------+------------+------------+-----------+----------+
| 5 | Reserved | UNBIND STATUS |
+------+------------+------------+-----------+----------+
USER INFO Echoes the value received in the USER INFO field of the UNBIND request message.
用户信息回显在解除绑定请求消息的用户信息字段中接收到的值。
CONNECTION HANDLE: Echoes the CONNECTION HANDLE specified in the UNBIND request message.
连接句柄：回显在取消绑定请求消息中指定的连接句柄。
UNBIND STATUS: Indicates the success or failure of the UNBIND request as follows:
解除绑定状态：表示解除绑定请求的成功或失败，如下所示：
Unbind Status Description
------------- -----------
Unbind Status Description
------------- -----------
0 Successful - No other status 1 - 15 Reserved 16 Failed - Unspecified Reason 18 Failed - Connection ID Invalid Others Reserved
0成功-无其他状态1-15保留16失败-未指定原因18失败-连接ID无效其他保留
The LTEST message is sent at the interval specified in the CBIND request or response payload. The LTEST encapsulation time stamp SHALL be set as described in Section 8.2.1 and may be used by the receiver to compute an estimate of propagation delay. However, the propagation delay limit SHALL NOT be enforced.
LTEST消息以CBIND请求或响应有效负载中指定的间隔发送。LTEST封装时间戳应按照第8.2.1节所述进行设置，并可由接收器用于计算传播延迟的估计值。但是，不得强制执行传播延迟限制。
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE5 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | LIVENESS TEST INTERVAL | Reserved |
| | (Seconds) | |
+------+-------------------------+----------------------+
| 2 | COUNT |
+------+------------+------------+-----------+----------+
| 3 | |
+------+ SOURCE N_PORT NAME |
| 4 | |
+------+------------------------------------------------+
| 5 | |
+------+ DESTINATION N_PORT NAME |
| 6 | |
+------+------------------------------------------------+
+------+------------+------------+-----------+----------+
| Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 |
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0xE5 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | LIVENESS TEST INTERVAL | Reserved |
| | (Seconds) | |
+------+-------------------------+----------------------+
| 2 | COUNT |
+------+------------+------------+-----------+----------+
| 3 | |
+------+ SOURCE N_PORT NAME |
| 4 | |
+------+------------------------------------------------+
| 5 | |
+------+ DESTINATION N_PORT NAME |
| 6 | |
+------+------------------------------------------------+
LIVENESS TEST Copy of the LIVENESS TEST INTERVAL INTERVAL: specified in the CBIND request or reply message.
活跃度测试间隔的活跃度测试副本：在CBIND请求或回复消息中指定。
COUNT: Monotonically increasing value, initialized to 0 and incremented by one for each successive LTEST message.
计数：单调递增的值，初始化为0，并为每个连续LTEST消息递增1。
SOURCE N_PORT NAME: Contains a copy of the SOURCE N_PORT NAME specified in the CBIND request.
SOURCE N_端口名：包含在CBIND请求中指定的SOURCE N_端口名的副本。
DESTINATION N_PORT Contains a copy of the DESTINATION N_PORT NAME: NAME specified in the CBIND request.
目标N_端口包含CBIND请求中指定的目标N_端口名称的副本。
Link services provide a set of fibre channel functions that allow a port to send control information or request another port to perform a specific control function.
链路服务提供一组光纤通道功能，允许一个端口发送控制信息或请求另一个端口执行特定的控制功能。
There are three types of link services:
有三种类型的链接服务：
a) Basic
a) 基本的
b) Extended
b) 延伸
c) ULP-specific (FC-4)
c) ULP专用（FC-4）
Each link service message (request and reply) is carried by a fibre channel sequence and can be segmented into multiple frames.
每个链路服务消息（请求和回复）都由光纤通道序列承载，可以分割为多个帧。
The iFCP layer is responsible for transporting link service messages across the IP network. This includes mapping link service messages appropriately from the domain of the fibre channel transport to that of the IP network. This process may require special processing and the inclusion of supplemental data by the iFCP layer.
iFCP层负责在IP网络上传输链路服务消息。这包括适当地将链路服务消息从光纤通道传输的域映射到IP网络的域。该过程可能需要iFCP层进行特殊处理和包含补充数据。
Each link service MUST be processed according to one of the following rules:
必须根据以下规则之一处理每个链接服务：
a) Pass-through - The link service message and reply MUST be delivered to the receiving N_PORT by the iFCP protocol layer without altering the message payload. The link service message and reply are not processed by the iFCP protocol layer.
a) 直通-链路服务消息和应答必须由iFCP协议层发送到接收N_端口，而不改变消息负载。链路服务消息和应答不由iFCP协议层处理。
b) Special - Applies to a link service reply or request requiring the intervention of the iFCP layer before forwarding to the destination N_PORT. Such messages may contain fibre channel addresses in the payload or may require other special processing.
b) 特殊-适用于在转发到目标N_端口之前需要iFCP层干预的链路服务应答或请求。此类消息可能在有效负载中包含光纤通道地址，或者可能需要其他特殊处理。
c) Rejected - When issued by a locally attached N_PORT, the specified link service request MUST be rejected by the iFCP gateway. The gateway SHALL return an LS_RJT response with a Reason Code of 0x0B (Command Not Supported), and a Reason Code Explanation of 0x0 (No Additional Explanation).
c) 拒绝-当由本地连接的N_端口发出时，指定的链路服务请求必须被iFCP网关拒绝。网关应返回一个LS_RJT响应，原因码为0x0B（不支持命令），原因码解释为0x0（无其他解释）。
This section describes the processing for special link services, including the manner in which supplemental data is added to the message payload.
本节描述特殊链路服务的处理，包括向消息有效负载添加补充数据的方式。
Appendix A enumerates all link services and the iFCP processing policy that applies to each.
附录A列举了所有链路服务以及适用于每个链路服务的iFCP处理策略。
Special link service messages require the intervention of the iFCP layer before forwarding to the destination N_PORT. Such intervention is required in order to:
特殊链路服务消息在转发到目标N_端口之前需要iFCP层的干预。需要进行此类干预，以便：
a) service any link service message that requires special handling, such as a PLOGI, and
a) 服务任何需要特殊处理的链接服务消息，如PLOGI，以及
b) service any link service message that has an N_PORT address in the payload in address translation mode only .
b) 仅在地址转换模式下，服务有效负载中具有N_端口地址的任何链路服务消息。
Unless the link service description specifies otherwise, support for each special link service is MANDATORY.
除非链接服务说明另有规定，否则必须支持每个特殊链接服务。
Such messages SHALL be transmitted in a fibre channel frame with the format shown in Figure 18 for extended link services or Figure 19 for FC-4 link services.
此类消息应在光纤通道帧中传输，扩展链路服务的格式如图18所示，FC-4链路服务的格式如图19所示。
Word
0<---Bit-->7 8<-------------------------------------------->31
+------------+------------------------------------------------+
0| R_CTL | D_ID |
|[Req = 0x22]|[Destination of extended link Service request] |
|[Rep = 0x23]| |
+------------+------------------------------------------------+
1| CS_CTL | S_ID |
| | [Source of extended link service request] |
+------------+------------------------------------------------+
2| TYPE | F_CTL |
| [0x01] | |
+------------+------------------+-----------------------------+
3| SEQ_ID | DF_CTL | SEQ_CNT |
+------------+------------------+-----------------------------+
4| OX_ID | RX_ID |
+-------------------------------+-----------------------------+
5| Parameter |
| [ 00 00 00 00 ] |
+-------------------------------------------------------------+
6| LS_COMMAND |
| [Extended Link Service Command Code] |
+-------------==----------------------------------------------+
7| |
.| Additional Service Request Parameters |
.| ( if any ) |
n| |
+-------------------------------------------------------------+
Word
0<---Bit-->7 8<-------------------------------------------->31
+------------+------------------------------------------------+
0| R_CTL | D_ID |
|[Req = 0x22]|[Destination of extended link Service request] |
|[Rep = 0x23]| |
+------------+------------------------------------------------+
1| CS_CTL | S_ID |
| | [Source of extended link service request] |
+------------+------------------------------------------------+
2| TYPE | F_CTL |
| [0x01] | |
+------------+------------------+-----------------------------+
3| SEQ_ID | DF_CTL | SEQ_CNT |
+------------+------------------+-----------------------------+
4| OX_ID | RX_ID |
+-------------------------------+-----------------------------+
5| Parameter |
| [ 00 00 00 00 ] |
+-------------------------------------------------------------+
6| LS_COMMAND |
| [Extended Link Service Command Code] |
+-------------==----------------------------------------------+
7| |
.| Additional Service Request Parameters |
.| ( if any ) |
n| |
+-------------------------------------------------------------+
Figure 18. Format of an Extended Link Service Frame
图18。扩展链路服务帧的格式
Word
0<---Bit-->7 8<-------------------------------------------->31
+------------+------------------------------------------------+
0| R_CTL | D_ID |
|[Req = 0x32]| [Destination of FC-4 link Service request] |
|[Rep = 0x33]| |
+------------+------------------------------------------------+
1| CS_CTL | S_ID |
| | [Source of FC-4 link service request] |
+------------+------------------------------------------------+
2| TYPE | F_CTL |
| (FC-4 | |
| specific) | |
+------------+------------------+-----------------------------+
3| SEQ_ID | DF_CTL | SEQ_CNT |
+------------+------------------+-----------------------------+
4| OX_ID | RX_ID |
+-------------------------------+-----------------------------+
5| Parameter |
| [ 00 00 00 00 ] |
+-------------------------------------------------------------+
6| LS_COMMAND |
| [FC-4 Link Service Command Code] |
+-------------------------------------------------------------+
7| |
.| Additional Service Request Parameters |
.| ( if any ) |
n| |
+-------------------------------------------------------------+
Word
0<---Bit-->7 8<-------------------------------------------->31
+------------+------------------------------------------------+
0| R_CTL | D_ID |
|[Req = 0x32]| [Destination of FC-4 link Service request] |
|[Rep = 0x33]| |
+------------+------------------------------------------------+
1| CS_CTL | S_ID |
| | [Source of FC-4 link service request] |
+------------+------------------------------------------------+
2| TYPE | F_CTL |
| (FC-4 | |
| specific) | |
+------------+------------------+-----------------------------+
3| SEQ_ID | DF_CTL | SEQ_CNT |
+------------+------------------+-----------------------------+
4| OX_ID | RX_ID |
+-------------------------------+-----------------------------+
5| Parameter |
| [ 00 00 00 00 ] |
+-------------------------------------------------------------+
6| LS_COMMAND |
| [FC-4 Link Service Command Code] |
+-------------------------------------------------------------+
7| |
.| Additional Service Request Parameters |
.| ( if any ) |
n| |
+-------------------------------------------------------------+
Figure 19. Format of an FC-4 Link Service Frame
图19。FC-4链路服务帧的格式
This section describes the handling for link service frames containing N_PORT addresses in the frame payload. Such addresses SHALL only be translated when the gateway is operating in address translation mode. When operating in address transparent mode, these addresses SHALL NOT be translated, and such link service messages SHALL NOT be sent as special frames unless other processing by the iFCP layer is required.
本节描述对帧有效负载中包含N_端口地址的链路服务帧的处理。只有当网关在地址转换模式下运行时，才能转换此类地址。在地址透明模式下运行时，这些地址不应被翻译，除非需要iFCP层进行其他处理，否则此类链路服务消息不应作为特殊帧发送。
Supplemental data includes information required by the receiving gateway to convert an N_PORT address in the payload to an N_PORT address in the receiving gateway's address space. The following rules define the manner in which such supplemental data shall be packaged and referenced.
补充数据包括接收网关将有效负载中的N_端口地址转换为接收网关地址空间中的N_端口地址所需的信息。以下规则规定了此类补充数据的打包和引用方式。
For an N_PORT address field, the gateway originating the frame MUST set the value in the payload to identify the address translation type as follows:
对于N_端口地址字段，发起帧的网关必须设置有效负载中的值，以标识地址转换类型，如下所示：
0x00 00 01 - The gateway receiving the frame from the IP network MUST replace the contents of the field with the N_PORT alias of the frame originator. This translation type MUST be used when the address to be converted is that of the source N_PORT.
0x00 01-从IP网络接收帧的网关必须将字段内容替换为帧发起人的N_端口别名。当要转换的地址是源N_端口的地址时，必须使用此转换类型。
0x00 00 02 - The gateway receiving the frame from the IP network MUST replace the contents of the field with the N_PORT ID of the destination N_PORT. This translation type MUST be used when the address to be converted is that of the destination N_PORT
0x00 02-从IP网络接收帧的网关必须将字段内容替换为目标N_端口的N_端口ID。当要转换的地址是目标N_端口的地址时，必须使用此转换类型
0x00 00 03 - The gateway receiving the frame from the IP network MUST reference the specified supplemental data to set the field contents. The supplemental information is the 64-bit worldwide identifier of the N_PORT, as set forth in the fibre channel specification [FC-FS]. If not otherwise part of the link service payload, this information MUST be appended in accordance with the applicable link service description. Unless specified otherwise, this translation type SHALL NOT be used if the address to be converted corresponds to that of the frame originator or recipient.
0x00 03-从IP网络接收帧的网关必须引用指定的补充数据以设置字段内容。补充信息是N_端口的64位全球标识符，如光纤通道规范[FC-FS]中所述。如果不是链路服务有效载荷的一部分，则必须根据适用的链路服务说明附加该信息。除非另有规定，如果要转换的地址与帧发起者或接收者的地址相对应，则不得使用此翻译类型。
Since fibre channel addressing rules prohibit the assignment of fabric addresses with a domain ID of 0, the above codes will never correspond to valid N_PORT fabric IDs.
由于光纤通道寻址规则禁止分配域ID为0的结构地址，因此上述代码永远不会对应于有效的N_端口结构ID。
If the sending gateway cannot obtain the worldwide identifier of an N_PORT, the gateway SHALL terminate the request with an LS_RJT message as described in [FC-FS]. The Reason Code SHALL be set to 0x07 (protocol error), and the Reason Explanation SHALL be set to 0x1F (Invalid N_PORT identifier).
如果发送网关无法获得N_端口的全球标识符，则网关应使用[FC-FS]中所述的LS_RJT消息终止请求。原因代码应设置为0x07（协议错误），原因解释应设置为0x1F（无效N_端口标识符）。
Supplemental data is sent with the link service request or ACC frames in one of the following ways:
补充数据通过以下方式之一随链路服务请求或ACC帧一起发送：
a) By appending the necessary data to the end of the link service frame.
a) 通过将必要的数据附加到链接服务帧的末尾。
b) By extending the sequence with additional frames.
b) 通过使用附加帧扩展序列。
In the first case, a new frame SHALL be created whose length includes the supplemental data. The procedure for extending the link service sequence with additional frames is dependent on the link service type.
在第一种情况下，应创建一个新框架，其长度包括补充数据。使用附加帧扩展链路服务序列的过程取决于链路服务类型。
For each field requiring address translation, the receiving gateway SHALL reference the translation type encoded in the field and replace it with the N_PORT address as shown in Table 7.
对于需要地址转换的每个字段，接收网关应参考字段中编码的转换类型，并将其替换为表7中所示的N_端口地址。
+------------------+------------------------------------+
| Translation | N_PORT Translation |
| Type Code | |
+------------------+------------------------------------+
| 0x00 00 01 | Replace field contents with N_PORT |
| | alias of frame originator. |
+------------------+------------------------------------+
| 0x00 00 02 | Replace field contents with N_PORT |
| | ID of frame recipient. |
+------------------+------------------------------------+
| | Lookup N_PORT via iSNS query. |
| | If locally attached, replace with |
| 0x00 00 03 | N_PORT ID. |
| | If remotely attached, replace with |
| | N_PORT alias from remote N_PORT. |
| | descriptor (see Section 5.2.2.1). |
+------------------+------------------------------------+
+------------------+------------------------------------+
| Translation | N_PORT Translation |
| Type Code | |
+------------------+------------------------------------+
| 0x00 00 01 | Replace field contents with N_PORT |
| | alias of frame originator. |
+------------------+------------------------------------+
| 0x00 00 02 | Replace field contents with N_PORT |
| | ID of frame recipient. |
+------------------+------------------------------------+
| | Lookup N_PORT via iSNS query. |
| | If locally attached, replace with |
| 0x00 00 03 | N_PORT ID. |
| | If remotely attached, replace with |
| | N_PORT alias from remote N_PORT. |
| | descriptor (see Section 5.2.2.1). |
+------------------+------------------------------------+
Table 7. Link Service Address Translation
表7。链接服务地址转换
For translation type 3, the receiving gateway SHALL obtain the information needed to fill in the field in the link service frame payload by converting the specified N_PORT worldwide identifier to a gateway IP address and N_PORT ID. This information MUST be obtained through an iSNS name server query. If the query is unsuccessful, the gateway SHALL terminate the request with an LS_RJT response message as described in [FC-FS]. The Reason Code SHALL be set to 0x07 (protocol error), and the Reason Explanation SHALL be set to 0x1F (Invalid N_PORT identifier).
对于转换类型3，接收网关应通过将指定的N_PORT worldwide标识符转换为网关IP地址和N_PORT ID，获得填写链路服务帧有效载荷字段所需的信息。该信息必须通过iSNS名称服务器查询获得。如果查询不成功，网关应使用[FC-FS]中所述的LS_RJT响应消息终止请求。原因代码应设置为0x07（协议错误），原因解释应设置为0x1F（无效N_端口标识符）。
After applying the supplemental data, the receiving gateway SHALL forward the resulting link service frames to the destination N_PORT with the supplemental information removed.
在应用补充数据之后，接收网关应在删除补充信息的情况下，将产生的链路服务帧转发到目的地N_端口。
The following Extended and FC-4 Link Service Messages must receive special processing.
以下扩展和FC-4链路服务消息必须接受特殊处理。
Extended Link Service LS_COMMAND Mnemonic
Messages ---------- --------
----------------------
Abort Exchange 0x06 00 00 00 ABTX
Discover Address 0x52 00 00 00 ADISC
Discover Address Accept 0x02 00 00 00 ADISC ACC
FC Address Resolution 0x55 00 00 00 FARP-REPLY
Protocol Reply
FC Address Resolution 0x54 00 00 00 FARP-REQ
Protocol Request
Logout 0x05 00 00 00 LOGO
Port Login 0x30 00 00 00 PLOGI
Read Exchange Concise 0x13 00 00 00 REC
Read Exchange Concise 0x02 00 00 00 REC ACC
Accept
Read Exchange Status Block 0x08 00 00 00 RES
Read Exchange Status Block 0x02 00 00 00 RES ACC
Accept
Read Link Error Status 0x0F 00 00 00 RLS
Block
Read Sequence Status Block 0x09 00 00 00 RSS
Reinstate Recovery 0x12 00 00 00 RRQ
Qualifier
Request Sequence 0x0A 00 00 00 RSI
Initiative
Scan Remote Loop 0x7B 00 00 00 SRL
Third Party Process Logout 0x24 00 00 00 TPRLO
Third Party Process Logout 0x02 00 00 00 TPRLO ACC
Accept
Extended Link Service LS_COMMAND Mnemonic
Messages ---------- --------
----------------------
Abort Exchange 0x06 00 00 00 ABTX
Discover Address 0x52 00 00 00 ADISC
Discover Address Accept 0x02 00 00 00 ADISC ACC
FC Address Resolution 0x55 00 00 00 FARP-REPLY
Protocol Reply
FC Address Resolution 0x54 00 00 00 FARP-REQ
Protocol Request
Logout 0x05 00 00 00 LOGO
Port Login 0x30 00 00 00 PLOGI
Read Exchange Concise 0x13 00 00 00 REC
Read Exchange Concise 0x02 00 00 00 REC ACC
Accept
Read Exchange Status Block 0x08 00 00 00 RES
Read Exchange Status Block 0x02 00 00 00 RES ACC
Accept
Read Link Error Status 0x0F 00 00 00 RLS
Block
Read Sequence Status Block 0x09 00 00 00 RSS
Reinstate Recovery 0x12 00 00 00 RRQ
Qualifier
Request Sequence 0x0A 00 00 00 RSI
Initiative
Scan Remote Loop 0x7B 00 00 00 SRL
Third Party Process Logout 0x24 00 00 00 TPRLO
Third Party Process Logout 0x02 00 00 00 TPRLO ACC
Accept
FC-4 Link Service Messages LS_COMMAND Mnemonic
-------------------------- ---------- --------
FCP Read Exchange Concise 0x13 00 00 00 FCP REC
FCP Read Exchange Concise 0x02 00 00 00 FCP REC
Accept ACC
FC-4 Link Service Messages LS_COMMAND Mnemonic
-------------------------- ---------- --------
FCP Read Exchange Concise 0x13 00 00 00 FCP REC
FCP Read Exchange Concise 0x02 00 00 00 FCP REC
Accept ACC
Each encapsulated fibre channel frame that is part of a special link service MUST have the SPC bit set to one in the iFCP FLAGS field of the encapsulation header, as specified in Section 5.3.1. If an ACC link service response requires special processing, the responding gateway SHALL place a copy of LS_COMMAND bits 0 through 7, from the
根据第5.3.1节的规定，作为特殊链路服务一部分的每个封装光纤通道帧必须在封装头的iFCP标志字段中将SPC位设置为1。如果ACC链路服务响应需要特殊处理，则响应网关应从
link service request frame, in the LS_COMMAND_ACC field of the ACC encapsulation header. Supplemental data (if any) MUST be appended as described in the following section.
链路服务请求帧，位于ACC封装头的LS_命令_ACC字段中。补充数据（如有）必须按照下一节所述追加。
The format of each special link service message, including supplemental data, where applicable, is shown in the following sections. Each description shows the basic format, as specified in the applicable FC standard, followed by supplemental data as shown in the example below.
每个特殊链接服务消息（包括补充数据，如适用）的格式如以下部分所示。每个描述都显示了适用FC标准中规定的基本格式，后面是补充数据，如以下示例所示。
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | LS_COMMAND |
+------+------------+------------+-----------+----------+
| 1 | |
| . | |
| . | Link Service Frame Payload |
| | |
| n | |
+======+============+============+===========+==========+
| n+1 | |
| . | Supplemental Data |
| . | (if any) |
| n+k | |
+======+================================================+
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | LS_COMMAND |
+------+------------+------------+-----------+----------+
| 1 | |
| . | |
| . | Link Service Frame Payload |
| | |
| n | |
+======+============+============+===========+==========+
| n+1 | |
| . | Supplemental Data |
| . | (if any) |
| n+k | |
+======+================================================+
Figure 20. Special Link Service Frame Payload
图20。特殊链路服务帧有效载荷
The following sections define extended link services for which special processing is required.
以下各节定义了需要特殊处理的扩展链接服务。
ELS Format:
ELS格式：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x6 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | RRQ Status | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID of Tgt exchange | RX_ID of tgt exchange|
+------+------------+------------+-----------+----------+
| 3-10 | Optional association header (32 bytes |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x6 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | RRQ Status | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID of Tgt exchange | RX_ID of tgt exchange|
+------+------------+------------+-----------+----------+
| 3-10 | Optional association header (32 bytes |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------
-----------
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------
-----------
Exchange Originator 1, 2 N/A S_ID
交易所发起人1，2不适用S_ID
Other Special Processing:
其他特殊处理：
None.
没有一个
Format of ADISC ELS:
ADISC ELS的格式：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x52 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Reserved | Hard address of ELS Originator |
+------+------------+------------+-----------+----------+
| 2-3 | Port Name of Originator |
+------+------------+------------+-----------+----------+
| 4-5 | Node Name of originator |
+------+------------+------------+-----------+----------+
| 6 | Rsvd | N_PORT ID of ELS Originator |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x52 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Reserved | Hard address of ELS Originator |
+------+------------+------------+-----------+----------+
| 2-3 | Port Name of Originator |
+------+------------+------------+-----------+----------+
| 4-5 | Node Name of originator |
+------+------------+------------+-----------+----------+
| 6 | Rsvd | N_PORT ID of ELS Originator |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -------------
------------
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -------------
------------
N_PORT ID of ELS 1 N/A Originator
ELS 1不适用发起人的N_端口ID
Other Special Processing:
其他特殊处理：
The Hard Address of the ELS originator SHALL be set to 0.
ELS发起人的硬地址应设置为0。
Format of ADISC ACC ELS:
ADISC ACC ELS的格式：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x20 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Reserved | Hard address of ELS Originator |
+------+------------+------------+-----------+----------+
| 2-3 | Port Name of Originator |
+------+------------+------------+-----------+----------+
| 4-5 | Node Name of originator |
+------+------------+------------+-----------+----------+
| 6 | Rsvd | N_PORT ID of ELS Originator |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x20 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Reserved | Hard address of ELS Originator |
+------+------------+------------+-----------+----------+
| 2-3 | Port Name of Originator |
+------+------------+------------+-----------+----------+
| 4-5 | Node Name of originator |
+------+------------+------------+-----------+----------+
| 6 | Rsvd | N_PORT ID of ELS Originator |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -------------
------------
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -------------
------------
N_PORT ID of ELS 1 N/A Originator
ELS 1不适用发起人的N_端口ID
Other Special Processing:
其他特殊处理：
The Hard Address of the ELS originator SHALL be set to 0.
ELS发起人的硬地址应设置为0。
The FARP-REPLY ELS is used in conjunction with the FARP-REQ ELS (see Section 7.3.1.5) to perform the address resolution services required by the FC-VI protocol [FC-VI] and the fibre channel mapping of IP and ARP specified in RFC 2625 [RFC2625].
FARP-REPLY ELS与FARP-REQ ELS（见第7.3.1.5节）一起使用，以执行FC-VI协议[FC-VI]和RFC 2625[RFC2625]中规定的IP和ARP的光纤通道映射所需的地址解析服务。
Format of FARP-REPLY ELS:
FARP-ELS回复格式：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x55 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Match Addr | Requesting N_PORT Identifier |
| | Code Points| |
+------+------------+------------+-----------+----------+
| 2 | Responder | Responding N_PORT Identifier |
| | Action | |
+------+------------+------------+-----------+----------+
| 3-4 | Requesting N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 5-6 | Requesting N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 7-8 | Responding N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 9-10 | Responding N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 11-14| Requesting N_PORT IP Address |
+------+------------+------------+-----------+----------+
| 15-18| Responding N_PORT IP Address |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x55 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Match Addr | Requesting N_PORT Identifier |
| | Code Points| |
+------+------------+------------+-----------+----------+
| 2 | Responder | Responding N_PORT Identifier |
| | Action | |
+------+------------+------------+-----------+----------+
| 3-4 | Requesting N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 5-6 | Requesting N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 7-8 | Responding N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 9-10 | Responding N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 11-14| Requesting N_PORT IP Address |
+------+------------+------------+-----------+----------+
| 15-18| Responding N_PORT IP Address |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
------------
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
------------
Requesting N_PORT 2 N/A Identifier
正在请求N_端口2不适用标识符
Responding N_PORT 1 N/A Identifier
响应N_端口1不适用标识符
Other Special Processing:
其他特殊处理：
None.
没有一个
The FARP-REQ ELS is used in conjunction with the FC-VI protocol [FC-VI] and IP-to-FC mapping of RFC 2625 [RFC2625] to perform IP and FC address resolution in an FC fabric. The FARP-REQ ELS is usually directed to the fabric broadcast server at well-known address 0xFF-FF-FF for retransmission to all attached N_PORTs.
FARP-REQ ELS与FC-VI协议[FC-VI]和RFC 2625[RFC2625]的IP到FC映射一起使用，以在FC结构中执行IP和FC地址解析。FARP-REQ ELS通常定向到已知地址0xFF处的结构广播服务器，以便重新传输到所有连接的N_端口。
Section 9.4 describes the iFCP implementation of FC broadcast server functionality in an iFCP fabric.
第9.4节描述了iFCP结构中FC广播服务器功能的iFCP实现。
Format of FARP_REQ ELS:
FARP_要求ELS的格式：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x54 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Match Addr | Requesting N_PORT Identifier |
| | Code Points| |
+------+------------+------------+-----------+----------+
| 2 | Responder | Responding N_PORT Identifier |
| | Action | |
+------+------------+------------+-----------+----------+
| 3-4 | Requesting N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 5-6 | Requesting N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 7-8 | Responding N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 9-10 | Responding N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 11-14| Requesting N_PORT IP Address |
+------+------------+------------+-----------+----------+
| 15-18| Responding N_PORT IP Address |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x54 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Match Addr | Requesting N_PORT Identifier |
| | Code Points| |
+------+------------+------------+-----------+----------+
| 2 | Responder | Responding N_PORT Identifier |
| | Action | |
+------+------------+------------+-----------+----------+
| 3-4 | Requesting N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 5-6 | Requesting N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 7-8 | Responding N_PORT Port_Name |
+------+------------+------------+-----------+----------+
| 9-10 | Responding N_PORT Node_Name |
+------+------------+------------+-----------+----------+
| 11-14| Requesting N_PORT IP Address |
+------+------------+------------+-----------+----------+
| 15-18| Responding N_PORT IP Address |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
-----------
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
-----------
Requesting N_PORT 3 Requesting N_PORT Identifier Port Name
请求N_端口3请求N_端口标识符端口名称
Responding N_PORT 3 Responding N_PORT Identifier Port Name
响应N_端口3响应N_端口标识符端口名称
Other Special Processing:
其他特殊处理：
None.
没有一个
ELS Format:
ELS格式：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x5 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | N_PORT ID being logged out |
+------+------------+------------+-----------+----------+
| 2-3 | Port name of the LOGO originator (8 bytes) |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x5 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | N_PORT ID being logged out |
+------+------------+------------+-----------+----------+
| 2-3 | Port name of the LOGO originator (8 bytes) |
+======+============+============+===========+==========+
This ELS SHALL always be sent as a special ELS regardless of the translation mode in effect.
无论有效的翻译模式如何，该ELS应始终作为特殊ELS发送。
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ---------------
-----------
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ---------------
-----------
N_PORT ID Being 1 N/A Logged Out
N\u端口ID为1 N/A已注销
Other Special Processing:
其他特殊处理：
See Section 5.2.3.
见第5.2.3节。
A PLOGI ELS establishes fibre channel communications between two N_PORTs and triggers the creation of an iFCP session if one does not exist.
PLOGI ELS在两个N_端口之间建立光纤通道通信，如果不存在iFCP会话，则触发iFCP会话的创建。
The PLOGI request and ACC response carry information identifying the originating N_PORT, including a specification of its capabilities. If the destination N_PORT accepts the login request, it sends an Accept response (an ACC frame with PLOGI payload) specifying its capabilities. This exchange establishes the operating environment for the two N_PORTs.
PLOGI请求和ACC响应携带标识原始N_端口的信息，包括其能力的规范。如果目标N_端口接受登录请求，它将发送一个接受响应（带有PLOGI负载的ACC帧），指定其功能。此交换为两个N_端口建立操作环境。
The following figure is duplicated from [FC-FS], and shows the PLOGI message format for both the request and Accept (ACC) response. An N_PORT will reject a PLOGI request by transmitting an LS_RJT message containing no payload.
下图与[FC-FS]重复，显示了请求和接受（ACC）响应的PLOGI消息格式。N_端口将通过发送不包含有效负载的LS_RJT消息来拒绝PLOGI请求。
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x3 | 0x00 | 0x00 | 0x00 |
| | Acc = 0x2 | | | |
+------+------------+------------+-----------+----------+
| 1-4 | Common Service Parameters |
+------+------------+------------+-----------+----------+
| 5-6 | N_PORT Name |
+------+------------+------------+-----------+----------+
| 7-8 | Node Name |
+------+------------+------------+-----------+----------+
| 9-12 | Class 1 Service Parameters |
+------+------------+------------+-----------+----------+
|13-17 | Class 2 Service Parameters |
+------+------------+------------+-----------+----------+
|18-21 | Class 3 Service Parameters |
+------+------------+------------+-----------+----------+
|22-25 | Class 4 Service Parameters |
+------+------------+------------+-----------+----------+
|26-29 | Vendor Version Level |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x3 | 0x00 | 0x00 | 0x00 |
| | Acc = 0x2 | | | |
+------+------------+------------+-----------+----------+
| 1-4 | Common Service Parameters |
+------+------------+------------+-----------+----------+
| 5-6 | N_PORT Name |
+------+------------+------------+-----------+----------+
| 7-8 | Node Name |
+------+------------+------------+-----------+----------+
| 9-12 | Class 1 Service Parameters |
+------+------------+------------+-----------+----------+
|13-17 | Class 2 Service Parameters |
+------+------------+------------+-----------+----------+
|18-21 | Class 3 Service Parameters |
+------+------------+------------+-----------+----------+
|22-25 | Class 4 Service Parameters |
+------+------------+------------+-----------+----------+
|26-29 | Vendor Version Level |
+======+============+============+===========+==========+
Figure 21. Format of PLOGI Request and ACC Payloads
图21。PLOGI请求和ACC有效载荷的格式
Details of the above fields, including common and class-based service parameters, can be found in [FC-FS].
上述字段的详细信息，包括通用和基于类的服务参数，可在[FC-FS]中找到。
Special Processing
特殊处理
As specified in Section 5.2.2.2, a PLOGI request addressed to a remotely attached N_PORT MUST cause the creation of an iFCP session if one does not exist. Otherwise, the PLOGI and PLOGI ACC payloads MUST be passed through without modification to the destination N_PORT using the existing iFCP session. In either case, the SPC bit must be set in the frame encapsulation header as specified in 5.3.3.
如第5.2.2.2节所述，如果不存在iFCP会话，则发往远程连接N_端口的PLOGI请求必须导致创建iFCP会话。否则，必须通过PLOGI和PLOGI ACC有效负载，而不使用现有的iFCP会话修改目标N_端口。在任何一种情况下，都必须按照5.3.3中的规定在帧封装头中设置SPC位。
If the CBIND to create the iFCP session fails, the issuing gateway SHALL terminate the PLOGI with an LS_RJT response. The Reason Code and Reason Code Explanation SHALL be selected from Table 8 based on the CBIND failure status.
如果用于创建iFCP会话的CBIND失败，则发出网关应使用LS_RJT响应终止PLOGI。应根据CBIND故障状态从表8中选择原因代码和原因代码解释。
+---------------+-------------------+---------------------+
| CBIND Failure | LS_RJT Reason | LS_RJT Reason Code |
| Status | Code | Explanation |
+===============+===================+=====================+
| Unspecified | Unable to Perform | No Additional |
| Reason (16) | Command Request | Explanation (0x00) |
| | (0x09) | |
+---------------+-------------------+---------------------+
| No Such | Unable to Perform | Invalid N_PORT |
| Device (17) | Command Request | Name (0x0D) |
| | (0x09) | |
+---------------+-------------------+---------------------+
| Lack of | Unable to Perform | Insufficient |
| Resources (19)| Command Request | Resources to Support|
| | (0x09) | Login (0x29) |
+---------------+-------------------+---------------------+
| Incompatible | Unable to Perform | No Additional |
| Address | Command Request | Explanation (0x00) |
| Translation | (0x09) | |
| Mode (20) | | |
+---------------+-------------------+---------------------+
| Incorrect iFCP| Unable to Perform | No Additional |
| Protocol | Command Request | Explanation (0x00) |
| version Number| (0x09) | |
| (21) | | |
+---------------+-------------------+---------------------+
| Gateway Not | Unable to Perform | No Additional |
| Synchronized | Command Request | Explanation (0x00) |
| (22) | (0x09) | |
+---------------+-------------------+---------------------+
+---------------+-------------------+---------------------+
| CBIND Failure | LS_RJT Reason | LS_RJT Reason Code |
| Status | Code | Explanation |
+===============+===================+=====================+
| Unspecified | Unable to Perform | No Additional |
| Reason (16) | Command Request | Explanation (0x00) |
| | (0x09) | |
+---------------+-------------------+---------------------+
| No Such | Unable to Perform | Invalid N_PORT |
| Device (17) | Command Request | Name (0x0D) |
| | (0x09) | |
+---------------+-------------------+---------------------+
| Lack of | Unable to Perform | Insufficient |
| Resources (19)| Command Request | Resources to Support|
| | (0x09) | Login (0x29) |
+---------------+-------------------+---------------------+
| Incompatible | Unable to Perform | No Additional |
| Address | Command Request | Explanation (0x00) |
| Translation | (0x09) | |
| Mode (20) | | |
+---------------+-------------------+---------------------+
| Incorrect iFCP| Unable to Perform | No Additional |
| Protocol | Command Request | Explanation (0x00) |
| version Number| (0x09) | |
| (21) | | |
+---------------+-------------------+---------------------+
| Gateway Not | Unable to Perform | No Additional |
| Synchronized | Command Request | Explanation (0x00) |
| (22) | (0x09) | |
+---------------+-------------------+---------------------+
Table 8. PLOGI LS_RJT Status for CBIND Failures
表8。CBIND故障的PLOGI LS_RJT状态
Link Service Request Format:
链接服务请求格式：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+======+============+============+===========+==========+
| 3-4 |Port Name of the Exchange Originator (8 bytes) |
| | (present only for translation type 3) |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+======+============+============+===========+==========+
| 3-4 |Port Name of the Exchange Originator (8 bytes) |
| | (present only for translation type 3) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
-----------
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
-----------
Exchange Originator 1, 2, or 3 Port Name of the S_ID Exchange Originator
Exchange发起人1、2或3 S_ID Exchange发起人的端口名称
Other Special Processing:
其他特殊处理：
None.
没有一个
Format of REC ACC Response:
REC ACC响应的格式：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 2 | Rsvd | Originator Address Identifier |
+------+------------+------------+-----------+----------+
| 3 | Rsvd | Responder Address Identifier |
+------+------------+------------+-----------+----------+
| 4 | FC4VALUE (FC-4-Dependent Value) |
+------+------------+------------+-----------+----------+
| 5 | E_STAT (Exchange Status) |
+======+============+============+===========+==========+
| 6-7 |Port Name of the Exchange Originator (8 bytes) |
+======+============+============+===========+==========+
| 8-9 |Port Name of the Exchange Responder (8 bytes) |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 2 | Rsvd | Originator Address Identifier |
+------+------------+------------+-----------+----------+
| 3 | Rsvd | Responder Address Identifier |
+------+------------+------------+-----------+----------+
| 4 | FC4VALUE (FC-4-Dependent Value) |
+------+------------+------------+-----------+----------+
| 5 | E_STAT (Exchange Status) |
+======+============+============+===========+==========+
| 6-7 |Port Name of the Exchange Originator (8 bytes) |
+======+============+============+===========+==========+
| 8-9 |Port Name of the Exchange Responder (8 bytes) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Originator Address 1, 2, or 3 Port Name of the Identifier Exchange Originator
发起人地址1、2或3标识符交换发起人的端口名称
Responder Address 1, 2, or 3 Port Name of the Identifier Exchange Responder
标识符交换响应程序的响应程序地址1、2或3端口名称
When supplemental data is required, the frame SHALL always be extended by 4 words as shown above. If the translation type for the Originator Address Identifier or the Responder Address Identifier is 1 or 2, the corresponding 8-byte port name SHALL be set to all zeros.
当需要补充数据时，框架应始终延长4个字，如上所示。如果发起者地址标识符或响应者地址标识符的转换类型为1或2，则相应的8字节端口名称应设置为全零。
Other Special Processing:
其他特殊处理：
None.
没有一个
ELS Format:
ELS格式：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 3-10 | Association Header (may be optionally req**d) |
+======+============+============+===========+==========+
| 11-12| Port Name of the Exchange Originator (8 bytes) |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 3-10 | Association Header (may be optionally req**d) |
+======+============+============+===========+==========+
| 11-12| Port Name of the Exchange Originator (8 bytes) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Exchange Originator 1, 2, or 3 Port Name of the S_ID Exchange Originator
Exchange发起人1、2或3 S_ID Exchange发起人的端口名称
Other Special Processing:
其他特殊处理：
None.
没有一个
Format of ELS Accept Response:
ELS接受响应的格式：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 2 | Rsvd | Exchange Originator N_PORT ID |
+------+------------+------------+-----------+----------+
| 3 | Rsvd | Exchange Responder N_PORT ID |
+------+------------+------------+-----------+----------+
| 4 | Exchange Status Bits |
+------+------------+------------+-----------+----------+
| 5 | Reserved |
+------+------------+------------+-----------+----------+
| 6-n | Service Parameters and Sequence Statuses |
| | as described in [FC-FS] |
+======+============+============+===========+==========+
|n+1- | Port Name of the Exchange Originator (8 bytes) |
|n+2 | |
+======+============+============+===========+==========+
|n+3- | Port Name of the Exchange Responder (8 bytes) |
|n+4 | |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 2 | Rsvd | Exchange Originator N_PORT ID |
+------+------------+------------+-----------+----------+
| 3 | Rsvd | Exchange Responder N_PORT ID |
+------+------------+------------+-----------+----------+
| 4 | Exchange Status Bits |
+------+------------+------------+-----------+----------+
| 5 | Reserved |
+------+------------+------------+-----------+----------+
| 6-n | Service Parameters and Sequence Statuses |
| | as described in [FC-FS] |
+======+============+============+===========+==========+
|n+1- | Port Name of the Exchange Originator (8 bytes) |
|n+2 | |
+======+============+============+===========+==========+
|n+3- | Port Name of the Exchange Responder (8 bytes) |
|n+4 | |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Exchange Originator 1, 2, or 3 Port Name of the N_PORT ID Exchange Originator
Exchange发起人1、2或3端口N_端口ID Exchange发起人的名称
Exchange Responder 1, 2, or 3 Port Name of the N_PORT ID Exchange Responder
Exchange响应程序1、2或3 N_端口ID Exchange响应程序的端口名称
When supplemental data is required, the ELS SHALL be extended by 4 words as shown above. If the translation type for the Exchange Originator N_PORT ID or the Exchange Responder N_PORT ID is 1 or 2, the corresponding 8-byte port name SHALL be set to all zeros.
当需要补充数据时，ELS应如上所示扩展4个字。如果Exchange发起者N_端口ID或Exchange响应者N_端口ID的转换类型为1或2，则相应的8字节端口名称应设置为全零。
Other Special Processing:
其他特殊处理：
None.
没有一个
ELS Format:
ELS格式：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x0F | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | N_PORT Identifier |
+======+============+============+===========+==========+
| 2-3 | Port Name of the N_PORT (8 bytes) |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x0F | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | N_PORT Identifier |
+======+============+============+===========+==========+
| 2-3 | Port Name of the N_PORT (8 bytes) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
-----------
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) -----------------
-----------
N_PORT Identifier 1, 2, or 3 Port Name of the N_PORT
N_端口标识符N_端口的1、2或3端口名称
Other Special Processing:
其他特殊处理：
None.
没有一个
ELS Format:
ELS格式：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x09 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | SEQ_ID | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+======+============+============+===========+==========+
| 3-4 |Port Name of the Exchange Originator (8 bytes) |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x09 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | SEQ_ID | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+======+============+============+===========+==========+
| 3-4 |Port Name of the Exchange Originator (8 bytes) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Exchange Originator 1, 2, or 3 Port Name of the S_ID Exchange Originator
Exchange发起人1、2或3 S_ID Exchange发起人的端口名称
Other Special Processing:
其他特殊处理：
None.
没有一个
ELS Format:
ELS格式：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x12 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 3-10 | Association Header (may be optionally req**d) |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x12 | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 3-10 | Association Header (may be optionally req**d) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Exchange Originator 1 or 2 N/A S_ID
交换发起人1或2不适用S\U ID
Other Special Processing:
其他特殊处理：
None.
没有一个
ELS Format:
ELS格式：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x0A | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 3-10 | Association Header (may be optionally req**d) |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x0A | 0x00 | 0x00 | 0x00 |
+------+------------+------------+-----------+----------+
| 1 | Rsvd | Exchange Originator S_ID |
+------+------------+------------+-----------+----------+
| 2 | OX_ID | RX_ID |
+------+------------+------------+-----------+----------+
| 3-10 | Association Header (may be optionally req**d) |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Exchange Originator 1 or 2 N/A S_ID
交换发起人1或2不适用S\U ID
Other Special Processing:
其他特殊处理：
None.
没有一个
SRL allows a remote loop to be scanned to detect changes in the device configuration. Any changes will trigger a fibre channel state change notification and subsequent update of the iSNS database.
SRL允许扫描远程环路，以检测设备配置中的更改。任何更改都将触发光纤通道状态更改通知，并随后更新iSNS数据库。
ELS Format:
ELS格式：
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x7B | Reserved |
+------+------------+------------+-----------+----------+
| 1 | Flag | Address Identifier of the FL_PORT |
| | | (see B.1) |
+======+============+============+===========+==========+
| 2-3 | Worldwide Name of the Remote FL_PORT |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-24|Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x7B | Reserved |
+------+------------+------------+-----------+----------+
| 1 | Flag | Address Identifier of the FL_PORT |
| | | (see B.1) |
+======+============+============+===========+==========+
| 2-3 | Worldwide Name of the Remote FL_PORT |
+======+============+============+===========+==========+
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Fields Requiring Translation Supplemental Data
Address Translation Type (see (type 3 only)
------------------- Section 7.2) ------------------
-----------
Address Identifier 3 Worldwide Name of of the FL_PORT the Remote FL_PORT
地址标识符3 FLU端口的全球名称远程FLU端口
Other Special Processing:
其他特殊处理：
The D_ID field is the address of the Domain Controller associated with the remote loop. The format of the Domain Controller address is the hex 'FF FC' || Domain_ID, where Domain_ID is the gateway-assigned alias representing the remote gateway or switch element being queried. After translation by the remote gateway, the D_ID identifies the gateway or switch element to be scanned within the remote gateway region.
D_ID字段是与远程循环关联的域控制器的地址。域控制器地址的格式为十六进制“FF FC”| | Domain_ID，其中Domain_ID是网关分配的别名，表示正在查询的远程网关或交换机元素。在远程网关进行转换后，D_ID标识要在远程网关区域内扫描的网关或交换机元件。
The FLAG field defines the scope of the SRL. If set to 0, all loop port interfaces on the given switch element or gateway are scanned. If set to one, the loop port interface on the gateway or switch element to be scanned MUST be specified in bits 8 through 31.
标志字段定义SRL的范围。如果设置为0，则扫描给定交换机元素或网关上的所有环路端口接口。如果设置为1，则必须在位8到31中指定要扫描的网关或交换机元件上的环路端口接口。
If the Flag field is zero, the SRL request SHALL NOT be sent as a special ELS.
如果标志字段为零，则SRL请求不应作为特殊ELS发送。
If the Domain_ID represents a remote switch or gateway and an iFCP session to the remote Domain Controller does not exist, the requesting gateway SHALL create the iFCP session.
如果域ID表示远程交换机或网关，并且到远程域控制器的iFCP会话不存在，则请求网关应创建iFCP会话。
TPRLO provides a mechanism for an N_PORT (third party) to remove one or more process login sessions that exist between the destination N_PORT and other N_PORTs specified in the command. This command includes one or more TPRLO LOGOUT PARAMETER PAGEs, each of which, when combined with the destination N_PORT, identifies a process login to be terminated by the command.
TPRLO为N_端口（第三方）提供了一种机制，用于删除目标N_端口和命令中指定的其他N_端口之间存在的一个或多个进程登录会话。此命令包括一个或多个TPRLO LOGOUT参数页，当与目标N_端口组合时，每个参数页都标识将由该命令终止的进程登录。
+--------+------------+--------------------+----------------------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16 - 31 |
+--------+------------+--------------------+----------------------+
| 0 | Cmd = 0x24 | Page Length (0x10) | Payload Length |
+--------+------------+--------------------+----------------------+
| 1 | TPRLO Logout Parameter Page 0 |
+--------+--------------------------------------------------------+
| 5 | TPRLO Logout Parameter Page 1 |
+--------+--------------------------------------------------------+
....
+--------+--------------------------------------------------------+
|(4*n)+1 | TPRLO Logout Parameter Page n |
+--------+--------------------------------------------------------+
+--------+------------+--------------------+----------------------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16 - 31 |
+--------+------------+--------------------+----------------------+
| 0 | Cmd = 0x24 | Page Length (0x10) | Payload Length |
+--------+------------+--------------------+----------------------+
| 1 | TPRLO Logout Parameter Page 0 |
+--------+--------------------------------------------------------+
| 5 | TPRLO Logout Parameter Page 1 |
+--------+--------------------------------------------------------+
....
+--------+--------------------------------------------------------+
|(4*n)+1 | TPRLO Logout Parameter Page n |
+--------+--------------------------------------------------------+
Figure 22. Format of TPRLO ELS
图22。TPRLO格式
Each TPRLO parameter page contains parameters identifying one or more image pairs and may be associated with a single FC-4 protocol type that is common to all FC-4 protocol types between the specified image pair or global to all specified image pairs. The format of a TPRLO page requiring address translation is shown in Figure 23. Additional information on TPRLO can be found in [FC-FS].
每个TPRLO参数页包含标识一个或多个图像对的参数，并且可以与指定图像对之间的所有FC-4协议类型通用的单个FC-4协议类型或所有指定图像对的全局FC-4协议类型相关联。需要地址转换的TPRLO页面格式如图23所示。有关TPRLO的更多信息，请参见[FC-FS]。
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-31 |
+------+------------+------------+-----------+----------+
| 0 | TYPE Code | TYPE CODE | |
| | or | EXTENSION | TPRLO Flags |
| | Common SVC | | |
| | Parameters | | |
+------+------------+------------+-----------+----------+
| 1 | Third Party Process Associator |
+------+------------+------------+-----------+----------+
| 2 | Responder Process Associator |
+------+------------+------------+-----------+----------+
| 3 | Reserved | Third Party Originator N_PORT ID |
+======+============+============+===========+==========+
| 4-5 | Worldwide Name of Third Party Originator |
| | N_PORT |
+------+------------------------------------------------+
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16-31 |
+------+------------+------------+-----------+----------+
| 0 | TYPE Code | TYPE CODE | |
| | or | EXTENSION | TPRLO Flags |
| | Common SVC | | |
| | Parameters | | |
+------+------------+------------+-----------+----------+
| 1 | Third Party Process Associator |
+------+------------+------------+-----------+----------+
| 2 | Responder Process Associator |
+------+------------+------------+-----------+----------+
| 3 | Reserved | Third Party Originator N_PORT ID |
+======+============+============+===========+==========+
| 4-5 | Worldwide Name of Third Party Originator |
| | N_PORT |
+------+------------------------------------------------+
Figure 23. Format of an Augmented TPRLO Parameter Page
图23。扩充TPRLO参数页的格式
The TPRLO flags that affect supplemented ELS processing are as follows:
影响ELS处理的TPRLO标志如下：
Bit 18: Third party Originator N_PORT Validity. When set to one, this bit indicates that word 3, bits 8-31 (Third Party Originator N_PORT ID), are meaningful.
第18位：第三方发起人N_端口有效性。当设置为1时，该位表示字3位8-31（第三方发起人N_端口ID）有意义。
Bit 19: Global Process logout. When set to one, this bit indicates that all image pairs for all N_PORTs of the specified FC-4 protocol shall be invalidated. When the value of this bit is one, only one logout parameter page is permitted in the TPRLO payload.
第19位：全局进程注销。当设置为1时，该位表示指定FC-4协议的所有N_端口的所有图像对应无效。当该位的值为1时，TPRLO有效负载中只允许一个注销参数页。
If bit 18 has a value of zero and bit 19 has a value of one in the TPRLO flags field, then the ELS SHALL NOT be sent as a special ELS.
如果TPRLO标志字段中位18的值为零，位19的值为一，则ELS不得作为特殊ELS发送。
Otherwise, the originating gateway SHALL process the ELS as follows:
否则，始发网关应按如下方式处理ELS：
a) The first word of the TPRLO payload SHALL NOT be modified.
a) 不得修改TPRLO有效载荷的第一个字。
b) Each TPRLO parameter page shall be extended by two words as shown in Figure 23.
b) 每个TPRLO参数页应扩展两个字，如图23所示。
c) If word 0, bit 18 (Third Party Originator N_PORT ID validity), in the TPRLO flags field has a value of one, then the sender shall place the worldwide port name of the fibre channel device's N_PORT in the extension words. The N_PORT ID SHALL be set to 3. Otherwise, the contents of the extension words and the Third Party Originator N_PORT ID SHALL be set to zero.
c) 如果TPRLO flags字段中的字0第18位（第三方发起人N_端口ID有效性）的值为1，则发送方应将光纤通道设备N_端口的全球端口名放在扩展字中。N_端口ID应设置为3。否则，扩展词和第三方发起人N_端口ID的内容应设置为零。
d) The ELS originator SHALL set the SPC bit in the encapsulation header of each augmented frame comprising the ELS (see Section 5.3.1).
d) ELS发起人应在构成ELS的每个增强帧的封装头中设置SPC位（见第5.3.1节）。
e) If the ELS contains a single TPRLO parameter page, the originator SHALL increase the frame length as necessary to include the extended parameter page.
e) 如果ELS包含单个TPRLO参数页，发起者应根据需要增加帧长度，以包括扩展参数页。
f) If the ELS to be augmented contains multiple TPRLO parameter pages, the FC frames created to contain the augmented ELS payload SHALL NOT exceed the maximum frame size that can be accepted by the destination N_PORT.
f) 如果要增强的ELS包含多个TPRLO参数页，则为包含增强ELS有效载荷而创建的FC帧不得超过目标N_端口可接受的最大帧大小。
Each fibre channel frame SHALL contain an integer number of extended TPRLO parameter pages. The maximum number of extended TPRLO parameter pages in a frame SHALL be limited to the number that can be held without exceeding the above upper limit. New frames resulting from the extension of the TPRLO pages to include the supplemental data SHALL be created by extending the SEQ_CNT in the fibre channel frame header. The SEQ_ID SHALL NOT be modified.
每个光纤通道帧应包含整数个扩展TPRLO参数页。帧中扩展TPRLO参数页面的最大数量应限制在不超过上述上限的情况下可保持的数量。扩展TPRLO页面以包含补充数据产生的新帧应通过扩展光纤通道帧头中的SEQ_CNT来创建。不得修改序号ID。
The gateway receiving the augmented TPRLO ELS SHALL generate ELS frames to be sent to the destination N_PORT by copying word 0 of the ELS payload and processing each augmented parameter page as follows:
接收增强TPRLO ELS的网关应通过复制ELS有效载荷的字0并按如下方式处理每个增强参数页来生成ELS帧，以发送到目的地N_端口：
a) If word 0, bit 18, has a value of one, create a parameter page by copying words 0 through 2 of the augmented parameter page. The Third Party Originator N_PORT ID in word 3 shall be generated by referencing the supplemental data as described in Section 7.2.
a) 如果字0第18位的值为1，则通过复制扩充参数页的字0到2来创建参数页。word 3中的第三方发起人N_端口ID应参考第7.2节所述的补充数据生成。
b) If word 0, bit 18, has a value of zero, create a parameter page by copying words 0 through 3 of the augmented parameter page.
b) 如果字0第18位的值为零，则通过复制扩充参数页的字0到3来创建参数页。
The size of each frame to be sent to the destination N_PORT MUST NOT exceed the maximum frame size that the destination N_PORT can accept. The sequence identifier in each frame header SHALL be copied from the augmented ELS, and the sequence count SHALL be monotonically increasing.
要发送到目标N_端口的每个帧的大小不得超过目标N_端口可以接受的最大帧大小。每个帧头中的序列标识符应从增强ELS中复制，并且序列计数应单调递增。
The format of the TPRLO ACC frame is shown in Figure 24.
TPRLO ACC帧的格式如图24所示。
+--------+------------+--------------------+----------------------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16 - 31 |
+--------+------------+--------------------+----------------------+
| 0 | Cmd = 0x2 | Page Length (0x10) | Payload Length |
+--------+------------+--------------------+----------------------+
| 1 | TPRLO Logout Parameter Page 0 |
+--------+--------------------------------------------------------+
| 5 | TPRLO Logout Parameter Page 1 |
+--------+--------------------------------------------------------+
....
+--------+--------------------------------------------------------+
|(4*n)+1 | TPRLO Logout Parameter Page n |
+--------+--------------------------------------------------------+
+--------+------------+--------------------+----------------------+
| Word | Bits 0-7 | Bits 8-15 | Bits 16 - 31 |
+--------+------------+--------------------+----------------------+
| 0 | Cmd = 0x2 | Page Length (0x10) | Payload Length |
+--------+------------+--------------------+----------------------+
| 1 | TPRLO Logout Parameter Page 0 |
+--------+--------------------------------------------------------+
| 5 | TPRLO Logout Parameter Page 1 |
+--------+--------------------------------------------------------+
....
+--------+--------------------------------------------------------+
|(4*n)+1 | TPRLO Logout Parameter Page n |
+--------+--------------------------------------------------------+
Figure 24. Format of TPRLO ACC ELS
图24。TPRLO ACC ELS格式
The format of the parameter page and rules for parameter page augmentation are as specified in Section 7.3.1.17.
参数页的格式和参数页扩充规则如第7.3.1.17节所述。
The following sections define FC-4 link services for which special processing is required.
以下各节定义了需要特殊处理的FC-4链路服务。
The format of FC-4 link service frames defined by FCP can be found in [FCP-2].
FCP定义的FC-4链路服务帧格式见[FCP-2]。
The payload format for this link service is identical to the REC extended link service specified in Section 7.3.1.8 and SHALL be processed as described in that section. The FC-4 version will become obsolete in [FCP-2]. However, in order to support devices implemented against early revisions of FCP-2, an iFCP gateway MUST support both versions.
该链路服务的有效载荷格式与第7.3.1.8节中规定的REC扩展链路服务相同，并应按照该节中的说明进行处理。FC-4版本将在[FCP-2]中过时。但是，为了支持针对FCP-2早期版本实施的设备，iFCP网关必须支持这两个版本。
The payload format for this link service is identical to the REC ACC extended link service specified in Section 7.3.1.9 and SHALL be processed as described in that section. The FC-4 version will become obsolete in [FCP-2]. However, in order to support devices implemented against earlier revisions of FCP-2, an iFCP gateway MUST support both versions.
该链路服务的有效载荷格式与第7.3.1.9节中规定的REC ACC扩展链路服务相同，并应按照该节中的说明进行处理。FC-4版本将在[FCP-2]中过时。但是，为了支持针对FCP-2早期版本实施的设备，iFCP网关必须支持这两个版本。
The FLOGI ELS is issued by an N_PORT that wishes to access the fabric transport services.
FLOGI ELS由希望访问结构传输服务的N_端口发布。
The format of the FLOGI request and FLOGI ACC payloads are identical to the PLOGI request and ACC payloads described in Section 7.3.1.7.
FLOGI请求和FLOGI ACC有效载荷的格式与第7.3.1.7节中描述的PLOGI请求和ACC有效载荷相同。
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x4 | 0x00 | 0x00 | 0x00 |
| | Acc = 0x2 | | | |
+------+------------+------------+-----------+----------+
| 1-4 | Common Service Parameters |
+------+------------+------------+-----------+----------+
| 5-6 | N_PORT Name |
+------+------------+------------+-----------+----------+
| 7-8 | Node Name |
+------+------------+------------+-----------+----------+
| 9-12 | Class 1 Service Parameters |
+------+------------+------------+-----------+----------+
|13-17 | Class 2 Service Parameters |
+------+------------+------------+-----------+----------+
|18-21 | Class 3 Service Parameters |
+------+------------+------------+-----------+----------+
|22-25 | Class 4 Service Parameters |
+------+------------+------------+-----------+----------+
|26-29 | Vendor Version Level |
+======+============+============+===========+==========+
+------+------------+------------+-----------+----------+
| Word | Bits 0-7 | Bits 8-15 |Bits 16-24 |Bits 25-31|
+------+------------+------------+-----------+----------+
| 0 | Cmd = 0x4 | 0x00 | 0x00 | 0x00 |
| | Acc = 0x2 | | | |
+------+------------+------------+-----------+----------+
| 1-4 | Common Service Parameters |
+------+------------+------------+-----------+----------+
| 5-6 | N_PORT Name |
+------+------------+------------+-----------+----------+
| 7-8 | Node Name |
+------+------------+------------+-----------+----------+
| 9-12 | Class 1 Service Parameters |
+------+------------+------------+-----------+----------+
|13-17 | Class 2 Service Parameters |
+------+------------+------------+-----------+----------+
|18-21 | Class 3 Service Parameters |
+------+------------+------------+-----------+----------+
|22-25 | Class 4 Service Parameters |
+------+------------+------------+-----------+----------+
|26-29 | Vendor Version Level |
+======+============+============+===========+==========+
Figure 25. FLOGI Request and ACC Payload Format
图25。FLOGI请求和ACC有效负载格式
A full description of each parameter is given in [FC-FS].
[FC-FS]中给出了每个参数的完整描述。
This section tabulates the protocol-dependent service parameters supported by a fabric port attached to an iFCP gateway.
本节列出了连接到iFCP网关的结构端口支持的协议相关服务参数。
The service parameters carried in the payload of an FLOGI extended link service request MUST be set in accordance with Table 9.
FLOGI扩展链路服务请求有效载荷中承载的服务参数必须按照表9进行设置。
+-----------------------------------------+---------------+
| | Fabric Login |
| Service Parameter | Class |
| +---+---+---+---+
| | 1 | 2 | 3 | 4 |
+-----------------------------------------+---+---+---+---+
| Class Validity | n | M | M | n |
+-----------------------------------------+---+---+---+---+
| Service Options | |
+-----------------------------------------+---+---+---+---+
| Intermix Mode | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Stacked Connect-Requests | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Sequential Delivery | n | M | M | n |
+-----------------------------------------+---+---+---+---+
| Dedicated Simplex | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Camp On | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Buffered Class 1 | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Priority | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Initiator/Recipient Control | |
+-----------------------------------------+---+---+---+---+
| Clock Synchronization ELS Capable | n | n | n | n |
+-----------------------------------------+---+---+---+---+
+-----------------------------------------+---------------+
| | Fabric Login |
| Service Parameter | Class |
| +---+---+---+---+
| | 1 | 2 | 3 | 4 |
+-----------------------------------------+---+---+---+---+
| Class Validity | n | M | M | n |
+-----------------------------------------+---+---+---+---+
| Service Options | |
+-----------------------------------------+---+---+---+---+
| Intermix Mode | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Stacked Connect-Requests | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Sequential Delivery | n | M | M | n |
+-----------------------------------------+---+---+---+---+
| Dedicated Simplex | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Camp On | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Buffered Class 1 | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Priority | n | n | n | n |
+-----------------------------------------+---+---+---+---+
| Initiator/Recipient Control | |
+-----------------------------------------+---+---+---+---+
| Clock Synchronization ELS Capable | n | n | n | n |
+-----------------------------------------+---+---+---+---+
Table 9. FLOGI Service Parameter Settings
表9。FLOGI服务参数设置
Notes:
笔记：
1) "n" indicates a parameter or capability that is not supported by the iFCP protocol.
1) “n”表示iFCP协议不支持的参数或功能。
2) "M" indicates an applicable parameter that MUST be supported by an iFCP gateway.
2) “M”表示iFCP网关必须支持的适用参数。
This section specifies provisions for error detection and recovery in addition to those in [FC-FS], which continue to be available in the iFCP network environment.
除[FC-FS]中的规定外，本节还规定了错误检测和恢复的规定，这些规定在iFCP网络环境中仍然可用。
Recovery from fibre channel protocol error conditions requires that frames associated with a failed or aborted exchange drain from the fabric before exchange resources can be safely reused.
从光纤通道协议错误条件中恢复要求在exchange资源可以安全地重新使用之前，必须先从结构中恢复与失败或中止的exchange排放相关联的帧。
Since a fibre channel fabric may not preserve frame order, there is no deterministic way to purge such frames. Instead, the fabric guarantees that frame the lifetime will not exceed a specific limit (R_A_TOV).
由于光纤通道结构可能不会保留帧顺序，因此没有确定的方法来清除这些帧。相反，结构保证帧的寿命不会超过特定的限制（R_a_TOV）。
R_A_TOV is defined in [FC-FS] as "the maximum transit time within a fabric to guarantee that a lost frame will never emerge from the fabric". For example, a value of 2 x R_A_TOV is the minimum time that the originator of an ELS request or FC-4 link service request must wait for the response to that request. The fibre channel default value for R_A_TOV is 10 seconds.
R_A__TOV在[FC-FS]中定义为“确保丢失帧不会从结构中出现的结构内的最大传输时间”。例如，2 x R_a_TOV的值是ELS请求或FC-4链路服务请求的发起人必须等待该请求响应的最短时间。R_A_TOV的光纤通道默认值为10秒。
An iFCP gateway SHALL actively enforce limits on R_A_TOV as described in Section 8.2.1.
iFCP网关应积极实施第8.2.1节所述的R_A_TOV限制。
The R_A_TOV limit on frame lifetimes SHALL be enforced by means of the time stamp in the encapsulation header (see Section 5.3.1) as described in this section.
帧寿命的R_A_TOV限制应通过本节所述的封装头中的时间戳（见第5.3.1节）来实施。
The budget for R_A_TOV SHOULD include allowances for the propagation delay through the gateway regions of the sending and receiving N_PORTs, plus the propagation delay through the IP network. This latter component is referred to in this specification as IP_TOV.
R_A_TOV的预算应包括通过发送和接收N_端口的网关区域的传播延迟，加上通过IP网络的传播延迟。后一个组件在本规范中称为IP_TOV。
IP_TOV should be set well below the value of R_A_TOV specified for the iFCP fabric and should be stored in the iSNS server. IP_TOV should be set to 50 percent of R_A_TOV.
IP_TOV应设置为远低于为iFCP结构指定的R_A_TOV值，并应存储在iSNS服务器中。IP_-TOV应设置为R_-A_-TOV的50%。
The following paragraphs describe the requirements for synchronizing gateway time bases and the rules for measuring and enforcing propagation delay limits.
以下段落描述了同步网关时基的要求以及测量和实施传播延迟限制的规则。
The protocol for synchronizing a gateway time base is SNTP [RFC2030]. In order to ensure that all gateways are time aligned, a gateway SHOULD obtain the address of an SNTP-compatible time server via an iSNS query. If multiple time server addresses are returned by the query, the servers must be synchronized and the gateway may use any server in the list. Alternatively, the server may return a multicast group address in support of operation in Anycast mode. Implementation of Anycast mode is as specified in [RFC2030], including the precautions defined in that document. Multicast mode SHOULD NOT be used.
同步网关时基的协议是SNTP[RFC2030]。为了确保所有网关都是时间对齐的，网关应该通过iSNS查询获得与SNTP兼容的时间服务器的地址。如果查询返回多个时间服务器地址，则必须同步服务器，网关可以使用列表中的任何服务器。或者，服务器可以返回多播组地址以支持选播模式下的操作。任意广播模式的实施如[RFC2030]所述，包括该文件中定义的预防措施。不应使用多播模式。
An SNTP server may use any one of the time reference sources listed in [RFC2030]. The resolution of the time reference MUST be 125 milliseconds or better.
SNTP服务器可以使用[RFC2030]中列出的任何一个时间参考源。时间参考的分辨率必须为125毫秒或更高。
Stability of the SNTP server and gateway time bases should be 100 ppm or better.
SNTP服务器和网关时基的稳定性应为100ppm或更高。
With regard to its time base, the gateway is in either the Synchronized or Unsynchronized state.
就其时基而言，网关处于同步或非同步状态。
When in the synchronized state, the gateway SHALL
当处于同步状态时，网关应
a) set the time stamp field for each outgoing frame in accordance with the gateway's internal time base;
a) 根据网关的内部时基设置每个传出帧的时间戳字段；
b) check the time stamp field of each incoming frame, following validation of the encapsulation header CRC, as described in Section 5.3.4;
b) 如第5.3.4节所述，验证封装头CRC后，检查每个传入帧的时间戳字段；
c) if the incoming frame has a time stamp of 0,0 and is not one of the session control frames that require a 0,0 time stamp (see Section 6), the frame SHALL be discarded;
c) 如果传入帧具有0,0的时间戳，并且不是需要0,0时间戳的会话控制帧之一（参见第6节），则应丢弃该帧；
d) if the incoming frame has a non-zero time stamp, the receiving gateway SHALL compute the absolute value of the time in flight and SHALL compare it against the value of IP_TOV specified for the IP fabric;
d) 如果传入帧具有非零时间戳，则接收网关应计算飞行时间的绝对值，并将其与为IP结构指定的IP_TOV值进行比较；
e) if the result in step (d) exceeds IP_TOV, the encapsulated frame shall be discarded. Otherwise, the frame shall be de-encapsulated as described in Section 5.3.4.
e) 如果步骤（d）中的结果超过IP_TOV，则应丢弃封装框架。否则，应按照第5.3.4节所述对框架进行去封装。
A gateway SHALL enter the Synchronized state upon receiving a successful response to an SNTP query.
网关在收到对SNTP查询的成功响应后应进入同步状态。
A gateway shall enter the Unsynchronized state:
网关应进入非同步状态：
a) upon power-up and before successful completion of an SNTP query, and
a) 通电后和成功完成SNTP查询前，以及
b) whenever the gateway looses contact with the SNTP server, such that the gateway's time base may no longer be in alignment with that of the SNTP server. The criterion for determining loss of contact is implementation specific.
b) 每当网关与SNTP服务器失去联系时，网关的时基可能不再与SNTP服务器的时基对齐。确定接触损失的标准是具体实施的。
Following loss of contact, it is recommended that the gateway enter the Unsynchronized state when the estimated time base drift relative to the SNTP reference is greater than ten percent of the IP_TOV limit. (Assuming that all timers have an accuracy of 100 ppm and IP_TOV equals 5 seconds, the maximum allowable loss of contact duration would be about 42 minutes.)
在失去联系后，当相对于SNTP参考的估计时基漂移大于IP_TOV限制的10%时，建议网关进入非同步状态。（假设所有计时器的精度为100 ppm，IP_TOV等于5秒，最大允许的接触损失持续时间约为42分钟。）
As the result of a transition from the Synchronized to the Unsynchronized state, a gateway MUST abort all iFCP sessions as described in Section 5.2.3. While in the Unsynchronized state, a gateway SHALL NOT permit the creation of new iFCP sessions.
从同步状态转换到非同步状态后，网关必须中止所有iFCP会话，如第5.2.3节所述。处于非同步状态时，网关不允许创建新的iFCP会话。
An iFCP gateway implementation MUST support the following fabric services:
iFCP网关实现必须支持以下结构服务：
N_PORT ID Value Description Section
--------------- ----------- -------
0xFF-FF-FE F_PORT Server 9.1
N_PORT ID Value Description Section
--------------- ----------- -------
0xFF-FF-FE F_PORT Server 9.1
0xFF-FF-FD Fabric Controller 9.2
0xFF FD结构控制器9.2
0xFF-FF-FC Directory/Name Server 9.3
0xFF FC目录/名称服务器9.3
In addition, an iFCP gateway MAY support the FC broadcast server functionality described in Section 9.4.
此外，iFCP网关可支持第9.4节所述的FC广播服务器功能。
The F_PORT server SHALL support the FLOGI ELS, as described in Section 7.4, as well as the following ELSs specified in [FC-FS]:
F_端口服务器应支持第7.4节所述的FLOGI ELS，以及[FC-FS]中规定的以下ELS：
a) Request for fabric service parameters (FDISC).
a) 请求结构服务参数（FDISC）。
b) Request for the link error status (RLS).
b) 请求链路错误状态（RLS）。
c) Read Fabric Timeout Values (RTV).
c) 读取结构超时值（RTV）。
The Fabric Controller SHALL support the following ELSs as specified in [FC-FS]:
结构控制器应支持[FC-FS]中规定的以下ELS：
a) State Change Notification (SCN).
a) 状态更改通知（SCN）。
b) Registered State Change Notification (RSCN).
b) 注册状态更改通知（RSCN）。
c) State Change Registration (SCR).
c) 州变更登记（SCR）。
The Directory/Name server provides a registration service allowing an N_PORT to record or query the database for information about other N_PORTs. The services are defined in [FC-GS3]. The queries are issued as FC-4 transactions using the FC-CT command transport protocol specified in [FC-GS3].
目录/名称服务器提供注册服务，允许N_端口记录或查询数据库中有关其他N_端口的信息。服务在[FC-GS3]中定义。使用[FC-GS3]中指定的FC-CT命令传输协议，将查询作为FC-4事务发出。
In iFCP, each name server request MUST be translated to the appropriate iSNS query defined in [ISNS]. The definitions of name server objects are specified in [FC-GS3].
在iFCP中，必须将每个名称服务器请求转换为[iSNS]中定义的相应iSNS查询。名称服务器对象的定义在[FC-GS3]中指定。
The name server SHALL support record and query operations for directory subtype 0x02 (Name Server) and 0x03 (IP Address Server) and MAY support the FC-4 specific services as defined in [FC-GS3].
名称服务器应支持目录子类型0x02（名称服务器）和0x03（IP地址服务器）的记录和查询操作，并可支持[FC-GS3]中定义的FC-4特定服务。
Fibre channel frames are broadcast throughout the fabric by addressing them to the fibre channel broadcast server at the well-known fibre channel address 0xFF-FF-FF. The broadcast server then replicates and delivers the frame to each attached N_PORT in all zones to which the originating device belongs. Only class 3 (datagram) service is supported.
通过将光纤通道帧寻址到光纤通道广播服务器（位于众所周知的光纤通道地址0xFF），可以在整个结构中广播光纤通道帧。然后，广播服务器复制帧并将其传送到发起设备所属的所有区域中的每个连接的N_端口。仅支持第3类（数据报）服务。
In an iFCP system, the fibre channel broadcast function is emulated by means of a two-tier architecture comprising the following elements:
在iFCP系统中，光纤通道广播功能通过包含以下元素的两层体系结构进行模拟：
a) A local broadcast server residing in each iFCP gateway. The local server distributes broadcast traffic within the gateway region and forwards outgoing broadcast traffic to a global server for distribution throughout the iFCP fabric.
a) 驻留在每个iFCP网关中的本地广播服务器。本地服务器在网关区域内分发广播流量，并将传出广播流量转发到全局服务器，以便在整个iFCP结构中分发。
b) A global broadcast server that re-distributes broadcast traffic to the local server in each participating gateway.
b) 一种全局广播服务器，将广播流量重新分配给每个参与网关中的本地服务器。
c) An iSNS discovery domain defining the scope over which broadcast traffic is propagated. The discovery domain is populated with a global broadcast server and the set of local servers it supports.
c) 定义广播流量传播范围的iSNS发现域。发现域由全局广播服务器及其支持的本地服务器集填充。
The local and global broadcast servers are logical iFCP devices that communicate using the iFCP protocol. The servers have an N_PORT Network Address consisting of an iFCP portal address and an N_PORT ID set to the well-known fibre channel address of the FC broadcast server (0xFF-FF-FF).
本地和全局广播服务器是使用iFCP协议进行通信的逻辑iFCP设备。这些服务器具有一个N_端口网络地址，该地址由一个iFCP入口地址和一个N_端口ID组成，该ID设置为FC广播服务器的著名光纤通道地址（0xFF）。
As noted above, an N_PORT originates a broadcast by directing frame traffic to the fibre channel broadcast server. The gateway-resident local server distributes a copy of the frame locally and forwards a copy to the global server for redistribution to the local servers on other gateways. The global server MUST NOT echo a broadcast frame to the originating local server.
如上所述，N_端口通过将帧流量定向到光纤通道广播服务器来发起广播。驻留网关的本地服务器在本地分发帧的副本，并将副本转发到全局服务器，以便重新分发到其他网关上的本地服务器。全局服务器不得向原始本地服务器回显广播帧。
The broadcast configuration is managed with facilities provided by the iSNS server by the following means:
使用iSNS服务器提供的设施通过以下方式管理广播配置：
a) An iSNS discovery domain is created and seeded with the network address of the global broadcast server N_PORT. The global server is identified as such by setting the appropriate N_PORT entity attribute.
a) 将创建一个iSNS发现域，并使用全局广播服务器N_端口的网络地址作为种子。通过设置适当的N_PORT entity属性，可以识别全局服务器。
b) Using the management interface, each broadcast server is preset with the identity of the broadcast domain.
b) 使用管理界面，每个广播服务器都预设了广播域的标识。
During power up, each gateway SHALL invoke the iSNS service to register its local broadcast server in the broadcast discovery domain. After registration, the local server SHALL wait for the global broadcast server to establish an iFCP session.
通电期间，每个网关应调用iSNS服务，在广播发现域中注册其本地广播服务器。注册后，本地服务器应等待全局广播服务器建立iFCP会话。
The global server SHALL register with the iSNS server as follows:
全球服务器应按照以下方式向iSNS服务器注册：
a) The server SHALL query the iSNS name server by attribute to obtain the worldwide port name of the N_PORT pre-configured to provide global broadcast services.
a) 服务器应按属性查询iSNS名称服务器，以获取预配置为提供全球广播服务的N_端口的全球端口名。
b) If the worldwide port name obtained above does not correspond to that of the server issuing the query, the N_PORT SHALL NOT perform global broadcast functions for N_PORTs in that discovery domain.
b) 如果上述获得的全球端口名称与发出查询的服务器的名称不一致，则N_端口不得对该发现域中的N_端口执行全局广播功能。
c) Otherwise, the global server N_PORT SHALL register with the discovery domain and query the iSNS server to identify all currently registered local servers.
c) 否则，全局服务器N_端口应向发现域注册，并查询iSNS服务器以识别当前注册的所有本地服务器。
d) The global broadcast server SHALL initiate an iFCP session with each local broadcast server in the domain. When a new local server registers, the global server SHALL receive a state change notification and respond by initiating an iFCP session with the newly added server. The gateway SHALL obtain these notifications using the iSNS provisions for lossless delivery.
d) 全局广播服务器应与域中的每个本地广播服务器启动iFCP会话。当新的本地服务器注册时，全局服务器将收到状态更改通知，并通过与新添加的服务器启动iFCP会话进行响应。网关应使用iSNS关于无损传送的规定获取这些通知。
Upon receiving the CBIND request to initiate the iFCP session, the local server SHALL record the worldwide port name and N_PORT network address of the global server.
在收到启动iFCP会话的CBIND请求后，本地服务器应记录全球服务器的全球端口名称和N_端口网络地址。
After the initial broadcast session is established, the local or global broadcast server MAY choose to manage the session in one of the following ways, depending on resource requirements and the anticipated level of broadcast traffic:
在建立初始广播会话之后，本地或全局广播服务器可以根据资源需求和广播业务的预期水平，选择以以下方式之一管理会话：
a) A server MAY keep the session open continuously. Since broadcast sessions are often quiescent for long periods of time, the server SHOULD monitor session connectivity as described in Section 5.2.2.4.
a) 服务器可以保持会话持续打开。由于广播会话通常长时间处于静止状态，服务器应按照第5.2.2.4节所述监控会话连接。
b) A server MAY open the broadcast session on demand only when broadcast traffic is to be sent. If the session is reopened by the global server, the local server SHALL replace the previously recorded network address of the global broadcast server.
b) 只有在发送广播流量时，服务器才可以按需打开广播会话。如果会话被全局服务器重新打开，则本地服务器应替换先前记录的全局广播服务器的网络地址。
An implementation may designate a local server to assume the duties of the global broadcast server in the event of a failure. The local server may use the LTEST message to determine whether the global server is functioning and may assume control if it is not.
实现可以指定本地服务器在发生故障时承担全局广播服务器的职责。本地服务器可以使用LTEST消息来确定全局服务器是否正在工作，如果没有，则可以承担控制。
When assuming control, the standby server must register with the iSNS server as the global broadcast server in place of the failed server and must install itself in the broadcast discovery domain as specified in steps c) and d) of Section 9.4.1.
在进行控制时，备用服务器必须向iSNS服务器注册为全局广播服务器，以代替出现故障的服务器，并且必须按照第9.4.1节步骤c）和d）中的规定将其自身安装在广播发现域中。
iFCP relies upon the IPSec protocol suite to provide data confidentiality and authentication services, and it relies upon IKE as the key management protocol. Section 10.2 describes the security requirements arising from iFCP's operating environment, and Section
iFCP依赖IPSec协议套件提供数据机密性和身份验证服务，并依赖IKE作为密钥管理协议。第10.2节描述了因iFCP的运行环境而产生的安全要求，以及第
10.3 describes the resulting design choices, their requirement levels, and how they apply to the iFCP protocol.
10.3 描述最终的设计选择、它们的需求级别以及它们如何应用于iFCP协议。
Detailed considerations for use of IPsec and IKE with the iFCP protocol can be found in [SECIPS].
有关在iFCP协议中使用IPsec和IKE的详细注意事项，请参见[SECIPS]。
iFCP is a protocol designed for use by gateway devices deployed in enterprise data centers. Such environments typically have security gateways designed to provide network security through isolation from public networks. Furthermore, iFCP data may have to traverse security gateways in order to support SAN-to-SAN connectivity across public networks.
iFCP是为部署在企业数据中心的网关设备设计的协议。此类环境通常具有安全网关，设计用于通过与公共网络隔离来提供网络安全。此外，iFCP数据可能必须通过安全网关才能支持跨公共网络的SAN到SAN连接。
Communicating iFCP gateways may be subjected to attacks, including attempts by an adversary to:
通信的iFCP网关可能会受到攻击，包括对手试图：
a) acquire confidential data and identities by snooping data packets,
a) 通过窥探数据包获取机密数据和身份，
b) modify packets containing iFCP data and control messages,
b) 修改包含iFCP数据和控制消息的数据包，
c) inject new packets into the iFCP session,
c) 将新数据包注入iFCP会话，
d) hijack the TCP connection carrying the iFCP session,
d) 劫持承载iFCP会话的TCP连接，
e) launch denial-of-service attacks against the iFCP gateway,
e) 对iFCP网关发起拒绝服务攻击，
f) disrupt the security negotiation process,
f) 破坏安全谈判进程，
g) impersonate a legitimate security gateway, or
g) 模拟合法的安全网关，或
h) compromise communication with the iSNS server.
h) 破坏与iSNS服务器的通信。
It is imperative to thwart these attacks, given that an iFCP gateway is the last line of defense for a whole fibre channel island, which may include several hosts and fibre channel switches. To do so, the iFCP gateway must implement and may use confidentiality, data origin authentication, integrity, and replay protection on a per-datagram basis. The iFCP gateway must implement and may use bi-directional authentication of the communication endpoints. Finally, it must implement and may use a scalable approach to key management.
鉴于iFCP网关是整个光纤通道岛（可能包括多台主机和光纤通道交换机）的最后一道防线，因此必须阻止这些攻击。为此，iFCP网关必须在每个数据报的基础上实现并可能使用机密性、数据源身份验证、完整性和重播保护。iFCP网关必须实现并可能使用通信端点的双向身份验证。最后，它必须实现并可能使用可扩展的密钥管理方法。
Enterprise data center networks are considered mission-critical facilities that must be isolated and protected from all possible security threats. Such networks are usually protected by security gateways, which, at a minimum, provide a shield against denial-of-service attacks. The iFCP security architecture is capable of leveraging the protective services of the existing security infrastructure, including firewall protection, NAT and NAPT services, and IPSec VPN services available on existing security gateways. Considerations regarding intervening NAT and NAPT boxes along the iFCP-iSNS path can be found in [ISNS].
企业数据中心网络被视为任务关键型设施，必须隔离并保护其免受所有可能的安全威胁。这类网络通常由安全网关保护，安全网关至少为拒绝服务攻击提供防护。iFCP安全体系结构能够利用现有安全基础设施的保护服务，包括防火墙保护、NAT和NAPT服务以及现有安全网关上可用的IPSec VPN服务。有关沿iFCP iSNS路径插入NAT和NAPT盒的注意事项，请参见[iSNS]。
iFCP is a peer-to-peer protocol. iFCP sessions may be initiated by either peer gateway or both. Consequently, bi-directional authentication of peer gateways must be provided in accordance with the requirement levels specified in Section 10.3.1.
iFCP是一种对等协议。iFCP会话可以由对等网关启动，也可以由两者都启动。因此，必须按照第10.3.1节规定的要求级别提供对等网关的双向认证。
N_PORT identities used in the Port Login (PLOGI) process shall be considered authenticated if the PLOGI request is received from the remote gateway over a secure, IPSec-protected connection.
如果通过安全的、受IPSec保护的连接从远程网关接收到PLOGI请求，则端口登录（PLOGI）过程中使用的N_端口标识应被视为经过身份验证。
There is no requirement that the identities used in authentication be kept confidential.
认证中使用的身份无需保密。
iFCP traffic may traverse insecure public networks, and therefore implementations must have per-packet encryption capabilities to provide confidentiality in accordance with the requirements specified in Section 10.3.1.
iFCP流量可能会穿越不安全的公共网络，因此实现必须具有每包加密能力，以根据第10.3.1节规定的要求提供机密性。
Due to the high data transfer rates and the amount of data involved, an iFCP implementation must support the capability to rekey each phase 2 security association in the time intervals dictated by sequence number space exhaustion at a given link rate. In the rekeying scenario described in [SECIPS], for example, rekeying events happen as often as every 27.5 seconds at a 10 Gbps rate.
由于高数据传输速率和涉及的数据量，iFCP实现必须支持在序列号空间耗尽以给定链路速率规定的时间间隔内对每个阶段2安全关联重新设置密钥的能力。例如，在[SECIPS]中描述的密钥更新场景中，每27.5秒以10 Gbps的速率发生一次密钥更新事件。
The iFCP gateway must provide the capability for forward secrecy in the rekeying process.
iFCP网关必须在密钥更新过程中提供前向保密能力。
Basic access control properties stem from the requirement that two communicating iFCP gateways be known to one or more iSNS servers before they can engage in iFCP exchanges. The optional use of discovery domains [ISNS], Identity Payloads (e.g., ID_FQDNs), and certificate-based authentication (e.g., with X509v3 certificates) enables authorization schemas of increasing complexity. The definition of such schemas (e.g., role-based access control) is outside of the scope of this specification.
基本访问控制属性源于一个或多个iSNS服务器在进行iFCP交换之前必须知道两个正在通信的iFCP网关。可选地使用发现域[ISNS]、身份有效负载（例如，ID_FQDNs）和基于证书的身份验证（例如，使用X509v3证书）使授权模式变得越来越复杂。此类模式的定义（例如，基于角色的访问控制）超出了本规范的范围。
This specification allows any and all security mechanisms in an iFCP gateway to be administratively disabled. Security policies MUST have, at most, iFCP Portal resolution. Administrators may gain control over security policies through an adequately secured interaction with a management interface or with iSNS.
此规范允许以管理方式禁用iFCP网关中的任何和所有安全机制。安全策略最多必须具有iFCP门户解析。管理员可以通过与管理界面或iSNS进行充分安全的交互来控制安全策略。
iSNS [ISNS] is an invariant in all iFCP deployments. iFCP gateways MUST use iSNS for discovery services and MAY use security policies configured in the iSNS database as the basis for algorithm negotiation in IKE. The iSNS specification defines mechanisms for securing communication between an iFCP gateway and iSNS server(s). Additionally, the specification indicates how elements of security policy concerning individual iFCP sessions can be retrieved from iSNS server(s).
iSNS[iSNS]在所有iFCP部署中都是不变的。iFCP网关必须将iSNS用于发现服务，并且可以使用iSNS数据库中配置的安全策略作为IKE中算法协商的基础。iSNS规范定义了确保iFCP网关和iSNS服务器之间通信安全的机制。此外，该规范还说明了如何从iSNS服务器检索有关单个iFCP会话的安全策略元素。
Applicable technology from IPsec and IKE is defined in the following suite of specifications:
IPsec和IKE的适用技术在以下规范套件中定义：
[RFC2401] Security Architecture for the Internet Protocol
[RFC2401]互联网协议的安全体系结构
[RFC2402] IP Authentication Header
[RFC2402]IP身份验证头
[RFC2404] The Use of HMAC-SHA-1-96 within ESP and AH
[RFC2404]在ESP和AH中使用HMAC-SHA-1-96
[RFC2405] The ESP DES-CBC Cipher Algorithm with Explicit IV
[RFC2405]带显式IV的ESP DES-CBC密码算法
[RFC2406] IP Encapsulating Security Payload
[RFC2406]IP封装安全有效负载
[RFC2407] The Internet IP Security Domain of Interpretation for ISAKMP
[RFC2407]ISAKMP解释的互联网IP安全域
[RFC2408] Internet Security Association and Key Management Protocol (ISAKMP)
[RFC2408]互联网安全关联和密钥管理协议（ISAKMP）
[RFC2409] The Internet Key Exchange (IKE)
[RFC2409]互联网密钥交换（IKE）
[RFC2410] The NULL Encryption Algorithm and Its Use With IPSEC
[RFC2410]空加密算法及其在IPSEC中的使用
[RFC2451] The ESP CBC-Mode Cipher Algorithms
[RFC2451]ESP CBC模式密码算法
[RFC2709] Security Model with Tunnel-mode IPsec for NAT Domains
[RFC2709]NAT域的隧道模式IPsec安全模型
The implementation of IPsec and IKE is required according to the following guidelines.
根据以下指导原则，需要实现IPsec和IKE。
Support for the IP Encapsulating Security Payload (ESP) [RFC2406] is MANDATORY to implement. When ESP is used, per-packet data origin authentication, integrity, and replay protection MUST be used.
必须实现对IP封装安全有效负载（ESP）[RFC2406]的支持。使用ESP时，必须使用每包数据源身份验证、完整性和重播保护。
For data origin authentication and integrity with ESP, HMAC with SHA1 [RFC2404] MUST be implemented, and the Advanced Encryption Standard [AES] in CBC MAC mode with Extended Cipher Block Chaining SHOULD be implemented in accordance with [AESCBC].
对于ESP的数据源身份验证和完整性，必须实施带有SHA1[RFC2404]的HMAC，并且应按照[AESCBC]的规定实施CBC MAC模式下的高级加密标准[AES]，并使用扩展密码块链。
For confidentiality with ESP, 3DES in CBC mode [RFC2451] MUST be implemented, and AES counter mode encryption [AESCTR] SHOULD be implemented. NULL encryption MUST be supported as well, as defined in [RFC2410]. DES in CBC mode SHOULD NOT be used due to its inherent weakness. Since it is known to be crackable with modest computation resources, it is inappropriate for use in any iFCP deployment scenario.
为了与ESP保密，必须在CBC模式[RFC2451]下实施3DES，并且应实施AES计数器模式加密[AESCTR]。如[RFC2410]中所定义，还必须支持空加密。CBC模式下的DES由于其固有的弱点不应使用。由于已知它可以用有限的计算资源破解，因此不适合在任何iFCP部署场景中使用。
A conforming iFCP protocol implementation MUST implement IPsec ESP [RFC2406] in tunnel mode [RFC2401] and MAY implement IPsec ESP in transport mode.
符合要求的iFCP协议实现必须在隧道模式[RFC2401]下实现IPsec ESP[RFC2406]，并且可以在传输模式下实现IPsec ESP。
Regarding key management, iFCP implementations MUST support IKE [RFC2409] for bi-directional peer authentication, negotiation of security associations, and key management, using the IPsec DOI. There is no requirement that the identities used in authentication be kept confidential. Manual keying MUST NOT be used since it does not provide the necessary keying support. According to [RFC2409], pre-shared secret key authentication is MANDATORY to implement, whereas certificate-based peer authentication using digital signatures MAY be implemented (see Section 10.3.3 regarding the use of certificates). [RFC2409] defines the following requirement levels for IKE Modes:
关于密钥管理，iFCP实现必须支持IKE[RFC2409]，以便使用IPsec DOI进行双向对等身份验证、安全关联协商和密钥管理。认证中使用的身份无需保密。不得使用手动键控，因为它不提供必要的键控支持。根据[RFC2409]，必须实施预共享密钥认证，而可以实施使用数字签名的基于证书的对等认证（关于证书的使用，请参见第10.3.3节）。[RFC2409]定义了IKE模式的以下要求级别：
Phase-1 Main Mode MUST be implemented.
必须实施阶段1主模式。
Phase-1 Aggressive Mode SHOULD be implemented.
应实施第1阶段积极模式。
Phase-2 Quick Mode MUST be implemented.
必须实施第二阶段快速模式。
Phase-2 Quick Mode with key exchange payload MUST be implemented.
必须实施具有密钥交换有效负载的第2阶段快速模式。
With iFCP, Phase-1 Main Mode SHOULD NOT be used in conjunction with pre-shared keys, due to Main Mode's vulnerability to man-in-the-middle-attackers when group pre-shared keys are used. In this scenario, Aggressive Mode SHOULD be used instead. Peer authentication using the public key encryption methods outlined in [RFC2409] SHOULD NOT be used.
在iFCP中，由于主模式在使用组预共享密钥时容易受到中间人攻击者的攻击，因此第1阶段主模式不应与预共享密钥一起使用。在这种情况下，应改用攻击性模式。不应使用[RFC2409]中概述的使用公钥加密方法的对等身份验证。
The DOI [RFC2407] provides for several types of Identification Payloads.
DOI[RFC2407]提供了几种类型的识别有效载荷。
When used for iFCP, IKE Phase 1 exchanges MUST explicitly carry the Identification Payload fields (IDii and IDir). Conforming iFCP 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, 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 [RFC2407], the port and protocol fields in the Identification Payload MUST be set to zero or UDP port 500.
当用于iFCP时，IKE阶段1交换必须显式地携带标识有效负载字段（IDii和IDir）。符合条件的iFCP实现必须使用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标识类型值。如[RFC2407]所述，标识有效负载中的端口和协议字段必须设置为零或UDP端口500。
When used for iFCP, IKE Phase 2 exchanges MUST explicitly carry the Identification Payload fields (IDci and IDcr). Conforming iFCP implementations MUST use either ID_IPV4_ADDR or ID_IPV6_ADDR Identification Type values (according to the version of IP supported). Other Identification Type values MUST NOT be used. As described in Section 5.2.2, the gateway creating the iFCP session must query the iSNS server to determine the appropriate port on which to initiate the associated TCP connection. Upon a successful IKE Phase 2 exchange, the IKE responder enforces the negotiated selectors on the IPsec SAs. Any subsequent iFCP session creation requires the iFCP peer to query its iSNS server for access control (in accordance with the session creation requirements specified in Section 5.2.2.1).
当用于iFCP时，IKE阶段2交换必须显式地携带标识有效负载字段（IDci和IDcr）。符合要求的iFCP实施必须使用ID\u IPV4\u ADDR或ID\u IPV6\u ADDR标识类型值（根据支持的IP版本）。不得使用其他标识类型值。如第5.2.2节所述，创建iFCP会话的网关必须查询iSNS服务器，以确定启动相关TCP连接的适当端口。IKE第2阶段交换成功后，IKE响应者在IPsec SAs上强制执行协商选择器。任何后续的iFCP会话创建都要求iFCP对等方查询其iSNS服务器以进行访问控制（根据第5.2.2.1节中规定的会话创建要求）。
A conforming iFCP Portal is capable of establishing one or more IKE Phase-1 Security Associations (SAs) to a peer iFCP Portal. A Phase-1 SA may be established when an iFCP Portal is initialized or may be deferred until the first TCP connection with security requirements is established.
一致性iFCP门户能够与对等iFCP门户建立一个或多个IKE第一阶段安全关联（SA）。第一阶段SA可在初始化iFCP门户时建立，也可推迟到建立具有安全要求的第一个TCP连接时建立。
An IKE Phase-2 SA protects one or more TCP connections within the same iFCP Portal. More specifically, the successful establishment of an IKE Phase-2 SA results in the creation of two uni-directional IPsec SAs fully qualified by the tuple <SPI, destination IP address, ESP>.
IKE阶段2 SA保护同一iFCP门户内的一个或多个TCP连接。更具体地说，成功建立IKE阶段2 SA导致创建两个完全由tuple<SPI，destination IP address，ESP>限定的单向IPsec SA。
These SAs protect the setup process of the underlying TCP connections and all their subsequent TCP traffic. The number of TCP connections in an IPsec SA, as well as the number of SAs, is practically driven by security policy considerations (i.e., security services are defined at the granularity of an IPsec SA only), QoS considerations (e.g., multiple QoS classes within the same IPsec SA increase odds of packet reordering, possibly falling outside the replay window), and failure compartmentalization considerations. Each of the TCP connections protected by an IPsec SA is either in the unbound state, or bound to a specific iFCP session.
这些SA保护底层TCP连接的设置过程及其所有后续TCP流量。IPsec SA中TCP连接的数量以及SA的数量实际上是由安全策略考虑因素（即，安全服务仅在IPsec SA的粒度上定义）、QoS考虑因素驱动的（例如，同一IPsec SA中的多个QoS类会增加数据包重新排序的可能性，可能会超出重播窗口）和故障划分注意事项。受IPsec SA保护的每个TCP连接要么处于未绑定状态，要么绑定到特定的iFCP会话。
In summary, at any point in time:
总之，在任何时间点：
-- there exist 0..M IKE Phase-1 SAs between peer iFCP portals,
--对等iFCP门户之间存在0..M IKE第1阶段SA，
-- each IKE Phase-1 SA has 0..N IKE Phase-2 SAs, and
--每个IKE阶段1 SA具有0..N IKE阶段2 SA，并且
-- each IKE Phase-2 SA protects 0..Z TCP connections.
--每个IKE阶段2 SA保护0..Z TCP连接。
The creation of an IKE Phase-2 SA may be triggered by a policy rule supplied through a management interface or by iFCP Portal properties registered with the iSNS server. Similarly, the use of a Key Exchange payload in Quick Mode for perfect forward secrecy may be dictated through a management interface or by an iFCP Portal policy rule registered with the iSNS server.
IKE阶段2 SA的创建可能由通过管理界面提供的策略规则或iSNS服务器注册的iFCP门户属性触发。类似地，可通过管理界面或iSNS服务器注册的iFCP门户策略规则，规定在快速模式下使用密钥交换有效负载以实现完美的前向保密。
If an iFCP implementation makes use of unbound TCP connections, and such connections belong to an iFCP Portal with security requirements, then the unbound connections MUST be protected by an SA at all times just like bound connections.
如果iFCP实现使用未绑定的TCP连接，并且此类连接属于具有安全要求的iFCP门户，则未绑定的连接必须始终由SA保护，就像绑定的连接一样。
Upon receipt of an IKE Phase-2 delete message, there is no requirement to terminate the protected TCP connections or delete the associated IKE Phase-1 SA. Since an IKE Phase-2 SA may be associated with multiple TCP connections, terminating these connections might in fact be inappropriate and untimely.
收到IKE第2阶段删除消息后，无需终止受保护的TCP连接或删除相关IKE第1阶段SA。由于IKE阶段2 SA可能与多个TCP连接相关联，因此终止这些连接实际上可能是不适当和不及时的。
To minimize the number of active Phase-2 SAs, IKE Phase-2 delete messages may be sent for Phase-2 SAs whose TCP connections have not handled data traffic for a while. To minimize the use of SA
为了尽量减少活动的第2阶段SA的数量，可以为TCP连接有一段时间没有处理数据通信的第2阶段SA发送IKE第2阶段删除消息。尽量减少SA的使用
resources while the associated TCP connections are idle, creation of a new SA should be deferred until new data are to be sent over the connections.
资源当关联的TCP连接空闲时，应推迟创建新SA，直到通过连接发送新数据。
Conforming iFCP implementations MAY support peer authentication via digital signatures and certificates. When certificate authentication is chosen within IKE, each iFCP gateway needs the certificate credentials of each peer iFCP gateway in order to establish a security association with that peer.
符合要求的iFCP实施可通过数字签名和证书支持对等身份验证。在IKE中选择证书身份验证时，每个iFCP网关都需要每个对等iFCP网关的证书凭据，以便与该对等建立安全关联。
Certificate credentials used by iFCP gateways MUST be those of the machine. Certificate credentials MAY be bound to the interface (IP Address or FQDN) of the iFCP gateway used for the iFCP session, or to the fabric WWN of the iFCP gateway itself. Since the value of a machine certificate is inversely proportional to the ease with which an attacker can obtain one under false pretenses, it is advisable that the machine certificate enrollment process be strictly controlled. For example, only administrators may have the ability to enroll a machine with a machine certificate. User certificates SHOULD NOT be used by iFCP gateways for establishment of SAs protecting iFCP sessions.
iFCP网关使用的证书凭据必须是计算机的证书凭据。证书凭据可以绑定到用于iFCP会话的iFCP网关的接口（IP地址或FQDN），或者绑定到iFCP网关本身的结构WWN。由于机器证书的值与攻击者在虚假情况下获取证书的难易程度成反比，因此建议严格控制机器证书注册过程。例如，只有管理员才能使用计算机证书注册计算机。iFCP网关不应使用用户证书来建立保护iFCP会话的SA。
If the gateway does not have the peer iFCP gateway's certificate credentials, then it can obtain them:
如果网关没有对等iFCP网关的证书凭据，则可以获取它们：
a) by using the iSNS protocol to query for the peer gateway's certificate(s) stored in a trusted iSNS server, or
a) 通过使用iSNS协议查询存储在受信任iSNS服务器中的对等网关证书，或
b) through use of the ISAKMP Certificate Request Payload (CRP) [RFC2408] to request the certificate(s) directly from the peer iFCP gateway.
b) 通过使用ISAKMP证书请求有效负载（CRP）[RFC2408]直接从对等iFCP网关请求证书。
When certificate chains are long enough, IKE exchanges using UDP as the underlying transport may yield IP fragments, which are known to work poorly across some intervening routers, firewalls, and NA(P)T boxes. As a result, the endpoints may be unable to establish an IPsec security association.
当证书链足够长时，使用UDP作为底层传输的IKE交换可能会产生IP片段，已知这些片段在一些中间路由器、防火墙和NA（P）T盒中工作不良。因此，端点可能无法建立IPsec安全关联。
Due to these fragmentation shortcomings, IKE is most appropriate for intra-domain usage. Known solutions to the fragmentation problem include sending the end-entry machine certificate rather than the chain, reducing the size of the certificate chain, using IKE implementations over a reliable transport protocol (e.g., TCP) assisted by Path MTU discovery and code against black-holing as per [RFC2923], or installing network components that can properly handle fragments.
由于这些碎片缺点，IKE最适合于域内使用。碎片化问题的已知解决方案包括发送终端入口机器证书而不是证书链，减少证书链的大小，通过可靠的传输协议（如TCP）使用IKE实现，并根据[RFC2923]通过路径MTU发现和代码防止黑洞，或者安装能够正确处理碎片的网络组件。
IKE negotiators SHOULD check the pertinent Certificate Revocation List (CRL) [RFC2408] before accepting a certificate for use in IKE's authentication procedures.
IKE谈判者在接受用于IKE认证过程的证书之前，应检查相关证书撤销列表（CRL）[RFC2408]。
iFCP implementations MUST use iSNS for discovery and management services. Consequently, the security of the iSNS protocol has an impact on the security of iFCP gateways. For a discussion of potential threats to iFCP gateways through use of iSNS, see [ISNS].
iFCP实施必须将iSNS用于发现和管理服务。因此，iSNS协议的安全性会影响iFCP网关的安全性。有关使用iSNS对iFCP网关的潜在威胁的讨论，请参阅[iSNS]。
To provide security for iFCP gateways using the iSNS protocol for discovery and management services, the IPSec ESP protocol in tunnel mode MUST be supported for iFCP gateways. Further discussion of iSNS security implementation requirements is found in [ISNS]. Note that iSNS security requirements match those for iFCP described in Section 10.3.
要使用iSNS协议为发现和管理服务为iFCP网关提供安全性，iFCP网关必须支持隧道模式下的IPSec ESP协议。[iSNS]中进一步讨论了iSNS安全实施要求。请注意，iSNS安全要求与第10.3节中描述的iFCP安全要求相匹配。
Once communication between iFCP gateways and the iSNS server has been secured through use of IPSec, the iFCP gateways have the capability to discover the security settings that they need to use (or not use) to protect iFCP traffic. This provides a potential scaling advantage over device-by-device configuration of individual security policies for each iFCP gateway. It also provides an efficient means for each iFCP gateway to discover the use or non-use of specific security capabilities by peer gateways.
一旦通过使用IPSec保护了iFCP网关和iSNS服务器之间的通信，iFCP网关就能够发现它们需要使用（或不使用）来保护iFCP流量的安全设置。这为每个iFCP网关的单个安全策略的逐设备配置提供了潜在的扩展优势。它还为每个iFCP网关提供了一种有效的方法，以发现对等网关是否使用了特定的安全功能。
Further discussion on use of iSNS to distribute security policies is found in [ISNS].
[iSNS]中有关于使用iSNS分发安全策略的进一步讨论。
An iFCP implementation may be able to disable security mechanisms for an iFCP Portal administratively through a management interface or through security policy elements set in the iSNS server. As a consequence, IKE or IPsec security associations will not be established for any iFCP sessions that traverse the portal.
iFCP实现可以通过管理界面或iSNS服务器中设置的安全策略元素，在管理上禁用iFCP门户的安全机制。因此，不会为通过门户的任何iFCP会话建立IKE或IPsec安全关联。
For most IP networks, it is inappropriate to assume physical security, administrative security, and correct configuration of the network and all attached nodes (a physically isolated network in a test lab may be an exception). Therefore, authentication SHOULD be used in order to provide minimal assurance that connections have initially been opened with the intended counterpart. The minimal iFCP security policy only states that an iFCP gateway SHOULD authenticate its iSNS server(s) as described in [ISNS].
对于大多数IP网络，假设网络和所有连接节点的物理安全性、管理安全性和正确配置是不合适的（测试实验室中的物理隔离网络可能是例外）。因此，应该使用身份验证，以提供最低限度的保证，即连接最初已与预期的对应方打开。最低iFCP安全策略仅规定iFCP网关应按照[iSNS]中所述对其iSNS服务器进行身份验证。
Conforming iFCP protocol implementations SHALL correctly communicate gateway-to-gateway, even across one or more intervening best-effort IP regions. The timings with which such gateway-to gateway communication is performed, however, will greatly depend upon BER, packet losses, latency, and jitter experienced throughout the best-effort IP regions. The higher these parameters, the higher the gap measured between iFCP observed behaviors and baseline iFCP behaviors (i.e., as produced by two iFCP gateways directly connected to one another).
符合要求的iFCP协议实施应正确地将网关与网关进行通信，即使是在一个或多个介入的尽力而为IP区域之间。然而，执行这种网关到网关通信的定时将在很大程度上取决于在尽力而为IP区域中经历的BER、分组丢失、延迟和抖动。这些参数越高，观测到的iFCP行为和基线iFCP行为之间的差距越大（即，由两个直接连接到另一个的iFCP网关产生的差距）。
It is expected that many iFCP deployments will benefit from a high degree of assurance regarding the behavior of intervening IP regions, with resulting high assurance on the overall end-to-end path, as directly experienced by fibre channel applications. Such assurance on the IP behaviors stems from the intervening IP regions supporting standard Quality-of-Service (QoS) techniques that are fully complementary to iFCP, such as:
预计许多iFCP部署将受益于对干预IP区域行为的高度保证，从而在整个端到端路径上获得高度保证，正如光纤通道应用程序直接体验到的那样。对IP行为的此类保证源于支持标准服务质量（QoS）技术的中间IP区域，这些技术是对iFCP的完全补充，例如：
a) congestion avoidance by over-provisioning of the network,
a) 通过过度配置网络避免拥塞，
b) integrated Services [RFC1633] QoS,
b) 综合业务[RFC1633]QoS，
c) differentiated Services [RFC2475] QoS, and
c) 区分服务[RFC2475]QoS，以及
d) Multi-Protocol Label Switching [RFC3031].
d) 多协议标签交换[RFC3031]。
One may load an MPLS forwarding equivalence class (FEC) with QoS class significance, in addition to other considerations such as protection and diversity for the given path. The complementarity and compatibility of MPLS with Differentiated Services is explored in [MPSLDS], wherein the PHB bits are copied to the EXP bits of the MPLS shim header.
除了诸如给定路径的保护和分集等其他考虑之外，还可以加载具有QoS类重要性的MPLS转发等价类（FEC）。[MPSLDS]中探讨了MPLS与区分服务的互补性和兼容性，其中PHB位被复制到MPLS垫片报头的EXP位。
In the most general definition, two iFCP gateways are separated by one or more independently managed IP regions that implement some of the QoS solutions mentioned above. A QoS-capable IP region supports the negotiation and establishment of a service contract specifying the forwarding service through the region. Such contract and negotiation rules are outside the scope of this document. In the case of IP regions with DiffServ QoS, the reader should refer to Service Level Specifications (SLS) and Traffic Conditioning Specifications (TCS) (as defined in [DIFTERM]). Other aspects of a
在最一般的定义中，两个iFCP网关由一个或多个独立管理的IP区域分隔，这些IP区域实现了上述一些QoS解决方案。具有QoS能力的IP区域支持协商和建立服务契约，该服务契约指定通过该区域的转发服务。此类合同和谈判规则不在本文件范围内。对于具有DiffServ QoS的IP区域，读取器应参考服务级别规范（SLS）和流量调节规范（TCS）（定义见[DIFTERM]）。a.方案的其他方面
service contract are expected to be non-technical and thus are outside of the IETF scope.
服务合同应为非技术性合同，因此不在IETF范围内。
Because fibre channel Class 2 and Class 3 do not currently support fractional bandwidth guarantees, and because iFCP is committed to supporting fibre channel semantics, it is impossible for an iFCP gateway to infer bandwidth requirements autonomously from streaming fibre channel traffic. Rather, the requirements on bandwidth or other network parameters need to be administratively set into an iFCP gateway, or into the entity that will actually negotiate the forwarding service on the gateway's behalf. Depending on the QoS techniques available, the stipulation of a forwarding service may require interaction with network ancillary functions, such as admission control and bandwidth brokers (via RSVP or other signaling protocols that an IP region may accept).
由于光纤通道类别2和类别3目前不支持分数带宽保证，并且由于iFCP致力于支持光纤通道语义，因此iFCP网关不可能从流式光纤通道流量自动推断带宽需求。相反，对带宽或其他网络参数的要求需要在管理上设置到iFCP网关中，或者设置到实际代表网关协商转发服务的实体中。根据可用的QoS技术，转发服务的规定可能需要与网络辅助功能交互，例如准入控制和带宽代理（通过RSVP或IP区域可以接受的其他信令协议）。
The administrator of a iFCP gateway may negotiate a forwarding service with IP region(s) for one, several, or all of an iFCP gateway's TCP sessions used by an iFCP gateway. Alternately, this responsibility may be delegated to a node downstream. Since one TCP connection is dedicated to each iFCP session, the traffic in an individual N_PORT to N_PORT session can be singled out by iFCP-unaware network equipment as well.
iFCP网关的管理员可以与IP区域协商转发服务，以用于iFCP网关使用的一个、多个或所有iFCP网关TCP会话。或者，可以将该责任委托给下游节点。由于每个iFCP会话专用一个TCP连接，因此单个N_端口到N_端口会话中的流量也可以由iFCP网络设备单独挑出。
For rendering the best emulation of fibre channel possible over IP, it is anticipated that typical forwarding services will specify a fixed amount of bandwidth, null losses, and, to a lesser degree of relevance, low latency and low jitter. For example, an IP region using DiffServ QoS may support SLSes of this nature by applying EF DSCPs to the iFCP traffic.
为了通过IP实现光纤通道的最佳模拟，预计典型的转发服务将指定固定的带宽、零损耗，以及低延迟和低抖动（相关性较小）。例如，使用区分服务QoS的IP区域可以通过将EF-dscp应用于iFCP业务来支持这种性质的slse。
The IANA-assigned port for iFCP traffic is port number 3420.
IANA为iFCP流量分配的端口号为3420。
An iFCP Portal may initiate a connection using any TCP port number consistent with its implementation of the TCP/IP stack, provided each port number is unique. To prevent the receipt of stale data associated with a previous connection using a given port number, the provisions of [RFC1323], Appendix B, SHOULD be observed.
iFCP门户可以使用与其TCP/IP堆栈实现一致的任何TCP端口号启动连接，前提是每个端口号都是唯一的。为防止使用给定端口号接收与先前连接相关的陈旧数据，应遵守[RFC1323]附录B的规定。
[AESCBC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003.
[AESCBC]Frankel，S.和H.Herbert，“AES-XCBC-MAC-96算法及其与IPsec的使用”，RFC 3566，2003年9月。
[AESCTR] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
[AESCTR]Housley，R.，“使用高级加密标准（AES）计数器模式和IPsec封装安全有效载荷（ESP）”，RFC 3686，2004年1月。
[ENCAP] Weber, R., Rajagopal, M., Travostino, F., O'Donnell, M., Monia, C., and M. Merhar, "Fibre Channel (FC) Frame Encapsulation", RFC 3643, December 2003.
[ENCAP]韦伯，R.，拉贾戈帕尔，M.，特拉沃斯蒂诺，F.，O'Donnell，M.，莫尼亚，C.，和M.梅哈尔，“光纤通道（FC）帧封装”，RFC 36432003年12月。
[FC-FS] dpANS INCITS.XXX-200X, "Fibre Channel Framing and Signaling (FC-FS), Rev 1.70, INCITS Project 1331D, February 2002
[FC-FS]dpANS INCITS.XXX-200X，“光纤通道成帧和信令（FC-FS），版本1.70，INCITS项目1331D，2002年2月
[FC-GS3] dpANS X3.XXX-200X, "Fibre Channel Generic Services -3 (FC-GS3)", revision 7.01, INCITS Project 1356-D, November 2000
[FC-GS3]dpANS X3.XXX-200X，“光纤通道通用服务-3（FC-GS3）”，第7.01版，INCITS项目1356-D，2000年11月
[FC-SW2] dpANS X3.XXX-2000X, "Fibre Channel Switch Fabric -2 (FC-SW2)", revision 5.2, INCITS Project 1305-D, May 2001
[FC-SW2]dpANS X3.XXX-2000X，“光纤通道交换结构-2（FC-SW2）”，第5.2版，INCITS项目1305-D，2001年5月
[FCP-2] dpANS T10, "Fibre Channel Protocol for SCSI, Second Version", revision 8, INCITS Project 1144D, September 2002
[FCP-2]dpANS T10，“SCSI光纤通道协议，第二版”，第8版，INCITS项目1144D，2002年9月
[ISNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C., and J. Souza, "Internet Storage Name Service (iSNS)", RFC 4171, September 2005.
[ISNS]Tseng，J.，Gibbons，K.，Travostino，F.，Du Laney，C.，和J.Souza，“互联网存储名称服务（ISNS）”，RFC 41712005年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998.
[RFC2404]Madson，C.和R.Glenn，“在ESP和AH中使用HMAC-SHA-1-96”，RFC 2404，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, N.
[RFC2407]Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，N。
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
[RFC2408]Maughan，D.，Schertler，M.，Schneider，M.，和J.Turner，“互联网安全协会和密钥管理协议（ISAKMP）”，RFC 2408，1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998.
[RFC2410]Glenn，R.和S.Kent，“空加密算法及其在IPsec中的使用”，RFC 2410，1998年11月。
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998.
[RFC2451]Pereira，R.和R.Adams，“ESP CBC模式密码算法”，RFC 2451，1998年11月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[SECIPS] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols Over IP", RFC 3723, April 2004.
[SECIPS]Aboba，B.，Tseng，J.，Walker，J.，Rangan，V.，和F.Travostino，“通过IP保护块存储协议”，RFC 37232004年4月。
[AES] FIPS Publication XXX, "Advanced Encryption Standard (AES)",
Draft, 2001, Available from
http://csrc.nist.gov/publications/drafts/dfips-AES.pdf
[AES] FIPS Publication XXX, "Advanced Encryption Standard (AES)",
Draft, 2001, Available from
http://csrc.nist.gov/publications/drafts/dfips-AES.pdf
[DIFTERM] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[DIFTERM]Grossman，D.，“区分服务的新术语和澄清”，RFC3260，2002年4月。
[FC-AL2] dpANS X3.XXX-199X, "Fibre Channel Arbitrated Loop (FC-AL-2)", revision 7.0, NCITS Project 1133D, April 1999
[FC-AL2]dpANS X3.XXX-199X，“光纤通道仲裁环路（FC-AL-2）”，第7.0版，NCITS项目1133D，1999年4月
[FC-FLA] TR-20-199X, "Fibre Channel Fabric Loop Attachment (FC-FLA)", revision 2.7, NCITS Project 1235-D, August 1997
[FC-FLA]TR-20-199X，“光纤通道结构环路连接（FC-FLA）”，修订版2.7，NCITS项目1235-D，1997年8月
[FC-VI] ANSI/INCITS 357:2002, "Fibre Channel Virtual Interface Architecture Mapping Protocol (FC-VI)", NCITS Project 1332-D, July 2000.
[FC-VI]ANSI/INCITS 357:2002，“光纤通道虚拟接口体系结构映射协议（FC-VI）”，NCITS项目1332-D，2000年7月。
[KEMALP] Kembel, R., "The Fibre Channel Consultant, Arbitrated Loop", Robert W. Kembel, Northwest Learning Associates, 2000, ISBN 0-931836-84-0
[KEMALP]Kembel，R.，“光纤通道顾问，仲裁环路”，Robert W.Kembel，西北学习协会，2000年，ISBN 0-931836-84-0
[KEMCMP] Kembel, R., "Fibre Channel, A Comprehensive Introduction", Northwest Learning Associates Inc., 2000, ISBN 0-931836-84-0
[KEMCMP]Kembel，R.，“光纤通道，全面介绍”，西北学习协会，2000年，ISBN 0-931836-84-0
[MPSLDS] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[MPSLDS]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，R.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.
[RFC1633]Braden，R.，Clark，D.，和S.Shenker，“互联网体系结构中的综合服务：概述”，RFC 16331994年6月。
[RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996.
[RFC2030]Mills，D.“IPv4、IPv6和OSI的简单网络时间协议（SNTP）第4版”，RFC 2030，1996年10月。
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2405]Madson，C.和N.Doraswamy，“带显式IV的ESP DES-CBC密码算法”，RFC 2405，1998年11月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.，和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[RFC2625] Rajagopal, M., Bhagwat, R., and W. Rickard, "IP and ARP over Fibre Channel", RFC 2625, June 1999.
[RFC2625]Rajagopal，M.，Bhagwat，R.，和W.Rickard，“光纤通道上的IP和ARP”，RFC 26251999年6月。
[RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for NAT Domains", RFC 2709, October 1999.
[RFC2709]Srisuresh，P.，“NAT域的隧道模式IPsec安全模型”，RFC 2709，1999年10月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]Lahey，K.，“路径MTU发现的TCP问题”，RFC 29232000年9月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC896] Nagle, J., "Congestion control in IP/TCP internetworks", RFC 896, January 1984.
[RFC896]Nagle，J.，“IP/TCP网络中的拥塞控制”，RFC896，1984年1月。
For reference purposes, this appendix enumerates all the fibre channel link services and the manner in which each shall be processed by an iFCP implementation. The iFCP processing policies are defined in Section 7.
出于参考目的，本附录列举了所有光纤通道链路服务，以及iFCP实现处理每项服务的方式。第7节定义了iFCP处理策略。
In the following sections, the name of a link service specific to a particular FC-4 protocol is prefaced by a mnemonic identifying the protocol.
在以下部分中，特定于特定FC-4协议的链路服务的名称以识别该协议的助记符开头。
The basic link services are shown in the following table:
基本链路服务如下表所示：
Basic Link Services
基本链接服务
Name Description iFCP Policy
---- ----------- ----------
Name Description iFCP Policy
---- ----------- ----------
ABTS Abort Sequence Transparent BA_ACC Basic Accept Transparent BA_RJT Basic Reject Transparent NOP No Operation Transparent PRMT Preempted Rejected (Applies to Class 1 only) RMC Remove Connection Rejected (Applies to Class 1 only)
ABTS中止序列透明BA_ACC基本接受透明BA_RJT基本拒绝透明NOP无操作透明PRMT抢占拒绝（仅适用于1级）RMC删除连接拒绝（仅适用于1级）
As specified in Section 7, the link service requests of Table 10 and the associated ACC response frames MUST be passed to the receiving N_PORT without altering the payload.
如第7节所述，表10中的链路服务请求和相关的ACC响应帧必须在不改变有效负载的情况下传递到接收N_端口。
Name Description
---- -----------
Name Description
---- -----------
ADVC Advise Credit CSR Clock Synchronization Request CSU Clock Synchronization Update ECHO Echo ESTC Estimate Credit ESTS Establish Streaming FACT Fabric Activate Alias_ID FAN Fabric Address Notification
ADVC advice Credit CSR Clock Synchronization Request CSU Clock Synchronization Update ECHO ECHO ESTC evaluate Credit ESTS building Streaming FACT Fabric Activate Alias_ID FAN FAN FAN Fabric Address Notification
FCP_RJT FCP FC-4 Link Service Reject FCP SRR FCP Sequence Retransmission Request FDACT Fabric Deactivate Alias_ID FDISC Discover F_Port Service Parameters FLOGI F_Port Login GAID Get Alias_ID LCLM Login Control List Management LINIT Loop Initialize LIRR Link Incident Record Registration LPC Loop Port Control LS_RJT Link Service Reject LSTS Loop Status NACT N_Port Activate Alias_ID NDACT N_Port Deactivate Alias_ID PDISC Discover N_Port Service Parameters PRLI Process Login PRLO Process Logout QoSR Quality of Service Request RCS Read Connection Status RLIR Registered Link Incident Report RNC Report Node Capability RNFT Report Node FC-4 Types RNID Request Node Identification Data RPL Read Port List RPS Read Port Status Block RPSC Report Port Speed Capabilities RSCN Registered State Change Notification RTV Read Timeout Value RVCS Read Virtual Circuit Status SBRP Set Bit-Error Reporting Parameters SCN State Change Notification SCR State Change Registration TEST Test TPLS Test Process Login State
FCP_RJT FCP FC-4链路服务拒绝FCP SRR FCP序列重传请求FDACT结构停用别名ID FDISC发现F_端口服务参数FLOGI F_端口登录GAID获取别名ID LCLM登录控制列表管理LINIT循环初始化LIRR链路事件记录注册LPC循环端口控制LS_RJT链路服务拒绝LSTS循环状态NACT N_端口激活别名ID NDACT N_端口停用别名ID PDISC发现N_端口服务参数PRLI进程登录PRLO进程注销QoSR服务质量请求RCS读取连接状态RLIR已注册链路事件报告RNC报告节点能力RNFT报告节点FC-4类型RNID请求节点标识数据RPL读取端口列表RPS读取端口状态块RPSC报告端口速度功能RSCN注册状态更改通知RTV读取超时值RVCS读取虚拟电路状态SBRP设置位错误报告参数SCN状态更改通知SCR状态更改注册测试TPLS测试过程登录状态
Table 10. Pass-Through Link Services
表10。直通链路服务
The extended and FC-4 link services of Table 11 are processed by an iFCP implementation as described in the sections referenced in the table.
表11中的扩展和FC-4链路服务由iFCP实施进行处理，如表中引用的章节所述。
Name Description Section
---- ----------- -------
Name Description Section
---- ----------- -------
ABTX Abort Exchange 7.3.1.1 ADISC Discover Address 7.3.1.2 ADISC Discover Address Accept 7.3.1.3 ACC FARP- Fibre Channel Address 7.3.1.4 REPLY Resolution Protocol Reply FARP- Fibre Channel Address 7.3.1.5 REQ Resolution Protocol Request LOGO N_PORT Logout 7.3.1.6 PLOGI Port Login 7.3.1.7 REC Read Exchange Concise 7.3.1.8 REC ACC Read Exchange Concise 7.3.1.9 Accept FCP REC FCP Read Exchange 7.3.2.1.1 Concise (see [FCP-2]) FCP REC FCP Read Exchange 7.3.2.1.2 ACC Concise Accept (see [FCP-2]) RES Read Exchange Status 7.3.1.10 Block RES ACC Read Exchange Status 7.3.1.11 Block Accept RLS Read Link Error Status 7.3.1.12 Block RRQ Reinstate Recovery 7.3.1.14 Qualifier RSI Request Sequence 7.3.1.15 Initiative RSS Read Sequence Status 7.3.1.13 Block SRL Scan Remote Loop 7.3.1.16 TPRLO Third Party Process 7.3.1.17 Logout TPRLO Third Party Process 7.3.1.18 ACC Logout Accept
ABTX中止交换7.3.1.1 ADISC发现地址7.3.1.2 ADISC发现地址接受7.3.1.3 ACC FARP-光纤通道地址7.3.1.4应答解析协议应答FARP-光纤通道地址7.3.1.5 REQ解析协议请求徽标N_端口注销7.3.1.6 PLOGI端口登录7.3.1.7 REC Read Exchange简明7.3.1.8 REC ACC Read Exchange简明7.3.1.9接受FCP REC FCP Read Exchange 7.3.2.1.1简明（见[FCP-2]）FCP REC FCP Read Exchange 7.3.2.1.2 ACC简明接受（见[FCP-2]）RES读取交换状态7.3.1.10块RES ACC读取交换状态7.3.1.11块接受RLS读取链路错误状态7.3.1.12块RRQ恢复7.3.1.14限定符RSI请求序列7.3.1.15主动RSS读取序列状态7.3.1.13块SRL扫描远程循环7.3.1.16 TPRLO第三方进程7.3.1.17注销TPRLO第三方过程7.3.1.18 ACC注销接受
Table 11. Special Link Services
表11。特别链接服务
A loop topology may be optionally supported by a gateway implementation in one of the following ways:
网关实现可以通过以下方式之一可选地支持循环拓扑：
a) By implementing the FL_PORT public loop interface specified in [FC-FLA].
a) 通过实现[FC-FLA]中规定的FL_端口公共环路接口。
b) By emulating the private loop environment specified in [FC-AL2].
b) 通过模拟[FC-AL2]中指定的专用循环环境。
Private loop emulation allows the attachment of fibre channel devices that do not support fabrics or public loops. The gateway presents such devices to the fabric as though they were fabric-attached. Conversely, the gateway presents devices on the fabric, whether they are locally or remotely attached, as though they were connected to the private loop.
专用环路仿真允许连接不支持结构或公共环路的光纤通道设备。网关将这些设备呈现给结构，就好像它们是连接到结构的一样。相反，网关在结构上呈现设备，无论它们是本地连接的还是远程连接的，就像它们连接到专用环路一样。
Private loop support requires gateway emulation of the loop primitives and control frames specified in [FC-AL2]. These frames and primitives MUST be locally emulated by the gateway. Loop control frames MUST NOT be sent over an iFCP session.
专用环路支持需要对[FC-AL2]中指定的环路原语和控制帧进行网关仿真。网关必须在本地模拟这些帧和基本体。循环控制帧不得通过iFCP会话发送。
A gateway MAY disclose that a remotely attached device is connected to a public loop. If it does, it MUST also provide aliases representing the corresponding Loop Fabric Address (LFA), DOMAIN_ID, and FL_PORT Address Identifier through which the public loop may be remotely controlled.
网关可以公开远程连接的设备连接到公共环路。如果需要，它还必须提供代表相应环路结构地址（LFA）、域ID和FL端口地址标识符的别名，通过这些别名可以远程控制公共环路。
The LFA and FL_PORT address identifier both represent an N_PORT that services remote loop management requests contained in the LINIT and SRL extended link service messages. To support these messages, the gateway MUST allocate an NL_PORT alias so that the corresponding alias for the LFA or FL_PORT address identifier can be derived by setting the Port ID component of the NL_PORT alias to zero.
LFA和FL_端口地址标识符都表示一个N_端口，该端口为包含在LINIT和SRL扩展链路服务消息中的远程环路管理请求提供服务。为了支持这些消息，网关必须分配NL_端口别名，以便通过将NL_端口别名的端口ID组件设置为零，可以导出LFA或FL_端口地址标识符的相应别名。
Acknowledgements
致谢
The authors are indebted to those who contributed material and who took the time to carefully review and critique this specification including David Black (EMC), Rory Bolt (Quantum/ATL), Victor Firoiu (Nortel), Robert Peglar (XIOtech), David Robinson (Sun), Elizabeth Rodriguez, Joshua Tseng (Nishan), Naoke Watanabe (HDS) and members of the IPS working group. For review of the iFCP security policy, the authors are further indebted to the authors of the IPS security document [SECIPS], which include Bernard Aboba (Microsoft), Ofer Biran (IBM), Uri Elzer (Broadcom), Charles Kunziger (IBM), Venkat Rangan (Rhapsody Networks), Julian Satran (IBM), Joseph Tardo (Broadcom), and Jesse Walker (Intel).
作者感谢那些提供材料并花时间仔细审查和评论本规范的人，包括大卫·布莱克（EMC）、罗里·博尔特（Quantum/ATL）、维克托·菲罗（Nortel）、罗伯特·佩格拉（XIOtech）、大卫·罗宾逊（Sun）、伊丽莎白·罗德里格斯（Elizabeth Rodriguez）、曾书亚（尼山）、渡边直树（HDS）以及IPS工作组成员。对于iFCP安全政策的审查，作者还要感谢IPS安全文档[SECIPS]的作者，其中包括Bernard Aboba（微软）、Ofer Biran（IBM）、Uri Elzer（博通）、Charles Kunziger（IBM）、Venkat Rangan（Rhapsody Networks）、Julian Satran（IBM）、Joseph Tardo（博通）和Jesse Walker（英特尔）。
Author's Addresses
作者地址
Comments should be sent to the ips mailing list (ips@ece.cmu.edu) or to the authors.
评论应发送至ips邮件列表(ips@ece.cmu.edu)或者给作者。
Charles Monia 7553 Morevern Circle San Jose, CA 95135
查尔斯·莫尼亚7553加利福尼亚州圣何塞莫尔文圈95135
EMail: charles_monia@yahoo.com
EMail: charles_monia@yahoo.com
Rod Mullendore McDATA 4555 Great America Pkwy Suite 301 Santa Clara, CA 95054
罗德·穆伦多尔·麦克达塔4555大美洲Pkwy套房301圣克拉拉，加利福尼亚州95054
Phone: 408-519-3986 EMail: Rod.Mullendore@MCDATA.com
电话：408-519-3986电子邮件：罗德。Mullendore@MCDATA.com
Franco Travostino Nortel 600 Technology Park Drive Billerica, MA 01821 USA
Franco Travostino Nortel 600科技园大道，美国马萨诸塞州比尔里卡，邮编01821
Phone: 978-288-7708 EMail: travos@nortel.com
电话：978-288-7708电子邮件：travos@nortel.com
Wayland Jeong TROIKA Networks, Inc. 2555 Townsgate Road, Suite 105 Westlake Village, CA 91361
Wayland Jeong TROIKA Networks，Inc.加利福尼亚州西湖村汤斯盖特路2555号105室，邮编：91361
Phone: 805-371-1377 EMail: wayland@TroikaNetworks.com
电话：805-371-1377电子邮件：wayland@TroikaNetworks.com
Mark Edwards Adaptec (UK) Ltd. 4th Floor, Howard House Queens Ave, UK. BS8 1SD
英国皇后大道霍华德大厦4楼Mark Edwards Adaptec（英国）有限公司。BS8 1SD
Phone: +44 (0)117 930 9600
EMail: mark_edwards@adaptec.com
Phone: +44 (0)117 930 9600
EMail: mark_edwards@adaptec.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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.
本文件受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编辑功能的资金目前由互联网协会提供。