Network Working Group M. Rajagopal
Request for Comments: 2625 R. Bhagwat
Category: Standards Track W. Rickard
Gadzoox Networks
June 1999
Network Working Group M. Rajagopal
Request for Comments: 2625 R. Bhagwat
Category: Standards Track W. Rickard
Gadzoox Networks
June 1999
IP and ARP over Fibre Channel
光纤通道上的IP和ARP
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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
Fibre Channel (FC) is a high speed serial interface technology that supports several higher layer protocols including Small Computer System Interface (SCSI) and Internet Protocol(IP). Until now, SCSI has been the only widely used protocol over FC. Existing FC standards [3] do not adequately specify how IP packets may be transported over FC and how IP addresses are resolved to FC addresses. The purpose of this document is to specify a way of encapsulating IP and Address Resolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution.
光纤通道（FC）是一种高速串行接口技术，支持多种更高层协议，包括小型计算机系统接口（SCSI）和互联网协议（IP）。到目前为止，SCSI是FC上唯一广泛使用的协议。现有的FC标准[3]没有充分规定如何通过FC传输IP数据包，以及如何将IP地址解析为FC地址。本文档旨在指定通过光纤通道封装IP和地址解析协议（ARP）的方法，并描述IP地址解析机制。
Table of Contents
目录
1. Introduction ............................................... 3
2. Problem Statement .......................................... 5
3. IP and ARP Encapsulation ................................... 5
3.1 FC Frame Format ........................................ 5
3.2 MTU .................................................... 7
3.2.1 IP MTU ........................................... 7
3.2.2 Maximally Minimum IPv4 packet .................... 8
3.2.3 ARP MTU .......................................... 8
3.2.4 FC Data Field containing FARP Packet ............. 9
3.3 FC Port and Node Network Addresses ..................... 9
3.4 FC Sequence Payload Format ............................. 10
3.5 Bit and Byte Ordering .................................. 12
4. ARP ........................................................ 12
1. Introduction ............................................... 3
2. Problem Statement .......................................... 5
3. IP and ARP Encapsulation ................................... 5
3.1 FC Frame Format ........................................ 5
3.2 MTU .................................................... 7
3.2.1 IP MTU ........................................... 7
3.2.2 Maximally Minimum IPv4 packet .................... 8
3.2.3 ARP MTU .......................................... 8
3.2.4 FC Data Field containing FARP Packet ............. 9
3.3 FC Port and Node Network Addresses ..................... 9
3.4 FC Sequence Payload Format ............................. 10
3.5 Bit and Byte Ordering .................................. 12
4. ARP ........................................................ 12
4.1 Address Resolution .................................... 12
4.2 ARP Packet Format ...................................... 13
4.3 ARP Layer Mapping and Operation ........................ 15
4.4 ARP Broadcast in a Point-to-Point Topology ............. 16
4.5 ARP Broadcast in a Private Loop Topology ............... 16
4.6 ARP Broadcast in a Public Loop Topology ................ 16
4.7 ARP Operation in a Fabric Topology ..................... 17
5. FARP ....................................................... 18
5.1 Scope .................................................. 18
5.2 FARP Overview .......................................... 18
5.3 FARP Command Format .................................... 20
5.4 Match Address Code Points .............................. 22
5.5 Responder Flags ........................................ 23
5.6 FARP Support Requirements .............................. 24
6. Exchange Management ........................................ 25
6.1 Exchange Origination ................................... 25
6.2 Exchange Termination ................................... 25
7. Summary of Supported Features .............................. 25
7.1 FC-4 Header ............................................ 25
7.2 R_CTL .................................................. 26
7.3 F_CTL .................................................. 27
7.4 Sequences .............................................. 28
7.5 Exchanges .............................................. 29
7.6 ARP and InARP ......................................... 30
7.7 Extended Link Services (ELS) ........................... 31
7.8 Login Parameters ....................................... 31
7.8.1 Common Service Parameters - FLOGI ............... 32
7.8.2 Common Services Parameters - PLOGI ............... 32
7.8.3 Class Service Parameters - PLOGI ................. 32
8. Security Considerations .................................... 32
8.1 IP and ARP Related ..................................... 32
8.2 FC Related ............................................. 32
9. Acknowledgements ........................................... 33
10. References ................................................ 33
11. Authors' Addresses ........................................ 35
Appendix A: Additional Matching Mechanisms in FARP ............ 36
Appendix B: InARP ............................................. 40
B.1 General Discussion ..................................... 40
B.2 InARP Protocol Operation ............................... 40
B.3 InARP Packet Format .................................... 40
B.4 InARP Support Requirements ............................. 41
Appendix C: Some Informal Mechanisms for FC Layer Mappings .... 42
C.1 Login on cached Mapping Information .................... 42
C.2 Login on ARP parsing ................................... 42
C.3 Login to Everyone ...................................... 43
C.4 Static Table ........................................... 43
Appendix D: FC Layer Address Validation........................ 44
D.1 General Discussion ..................................... 44
4.1 Address Resolution .................................... 12
4.2 ARP Packet Format ...................................... 13
4.3 ARP Layer Mapping and Operation ........................ 15
4.4 ARP Broadcast in a Point-to-Point Topology ............. 16
4.5 ARP Broadcast in a Private Loop Topology ............... 16
4.6 ARP Broadcast in a Public Loop Topology ................ 16
4.7 ARP Operation in a Fabric Topology ..................... 17
5. FARP ....................................................... 18
5.1 Scope .................................................. 18
5.2 FARP Overview .......................................... 18
5.3 FARP Command Format .................................... 20
5.4 Match Address Code Points .............................. 22
5.5 Responder Flags ........................................ 23
5.6 FARP Support Requirements .............................. 24
6. Exchange Management ........................................ 25
6.1 Exchange Origination ................................... 25
6.2 Exchange Termination ................................... 25
7. Summary of Supported Features .............................. 25
7.1 FC-4 Header ............................................ 25
7.2 R_CTL .................................................. 26
7.3 F_CTL .................................................. 27
7.4 Sequences .............................................. 28
7.5 Exchanges .............................................. 29
7.6 ARP and InARP ......................................... 30
7.7 Extended Link Services (ELS) ........................... 31
7.8 Login Parameters ....................................... 31
7.8.1 Common Service Parameters - FLOGI ............... 32
7.8.2 Common Services Parameters - PLOGI ............... 32
7.8.3 Class Service Parameters - PLOGI ................. 32
8. Security Considerations .................................... 32
8.1 IP and ARP Related ..................................... 32
8.2 FC Related ............................................. 32
9. Acknowledgements ........................................... 33
10. References ................................................ 33
11. Authors' Addresses ........................................ 35
Appendix A: Additional Matching Mechanisms in FARP ............ 36
Appendix B: InARP ............................................. 40
B.1 General Discussion ..................................... 40
B.2 InARP Protocol Operation ............................... 40
B.3 InARP Packet Format .................................... 40
B.4 InARP Support Requirements ............................. 41
Appendix C: Some Informal Mechanisms for FC Layer Mappings .... 42
C.1 Login on cached Mapping Information .................... 42
C.2 Login on ARP parsing ................................... 42
C.3 Login to Everyone ...................................... 43
C.4 Static Table ........................................... 43
Appendix D: FC Layer Address Validation........................ 44
D.1 General Discussion ..................................... 44
D.2 FC Layer Address Validation in a Point-to-Point Topology 45
D.3 FC Layer Address Validation in a Private Loop Topology . 45
D.4 FC Layer Address Validation in a Public Loop Topology .. 45
D.5 FC layer Address Validation in a Fabric Topology ....... 46
Appendix E: Fibre channel Overview ............................ 47
E.1 Brief Tutorial ......................................... 47
E.2 Exchange, Information Unit, Sequence, and Frame ........ 48
E.3 Fibre Channel Header Fields ............................ 49
E.4 Code Points for FC Frame ............................... 52
E.4.1 Code Points with IP and ARP Packet .............. 52
E.4.2 Code Points with FARP Command ................... 54
Appendix F: Fibre Channel Protocol Considerations.............. 58
F.1 Reliability in Class 3 ................................. 58
F.2 Continuously Increasing SEQ_CNT ........................ 58
Appendix G: Acronyms and Glossary of FC Terms ................. 60
Full Copyright Statement ...................................... 63
D.2 FC Layer Address Validation in a Point-to-Point Topology 45
D.3 FC Layer Address Validation in a Private Loop Topology . 45
D.4 FC Layer Address Validation in a Public Loop Topology .. 45
D.5 FC layer Address Validation in a Fabric Topology ....... 46
Appendix E: Fibre channel Overview ............................ 47
E.1 Brief Tutorial ......................................... 47
E.2 Exchange, Information Unit, Sequence, and Frame ........ 48
E.3 Fibre Channel Header Fields ............................ 49
E.4 Code Points for FC Frame ............................... 52
E.4.1 Code Points with IP and ARP Packet .............. 52
E.4.2 Code Points with FARP Command ................... 54
Appendix F: Fibre Channel Protocol Considerations.............. 58
F.1 Reliability in Class 3 ................................. 58
F.2 Continuously Increasing SEQ_CNT ........................ 58
Appendix G: Acronyms and Glossary of FC Terms ................. 60
Full Copyright Statement ...................................... 63
Fibre Channel (FC) is a gigabit speed networking technology primarily used for Storage Area Networking (SAN). FC is standardized under American National Standard for Information Systems of the National Committee for Information Technology Standards (NCITS) and has specified a number of documents describing its protocols, operations, and services.
光纤通道（FC）是一种主要用于存储区域网络（SAN）的千兆速度网络技术。FC根据国家信息技术标准委员会（NCITS）的美国信息系统国家标准进行标准化，并规定了描述其协议、操作和服务的大量文件。
Need:
需要：
Currently, Fibre Channel is predominantly used for communication between storage devices and servers using the SCSI protocol, with most of the servers still communicating with each other over LANs. Although, there exists a Fibre Channel Standard [3] that has architecturally defined support for IP encapsulation and address resolution, it is inadequately specified. ([3] prohibits broadcasts, thus loops are not covered; [10] has no support for Class 3).
目前，光纤通道主要用于使用SCSI协议的存储设备和服务器之间的通信，大多数服务器仍然通过LAN相互通信。尽管存在一个光纤通道标准[3]，该标准在体系结构上定义了对IP封装和地址解析的支持，但它的规定并不充分。（[3]禁止广播，因此不包括循环；[10]不支持类3）。
This has lead to a nonstandard way of using IP over FC in the past. Once such a standard method is completely specified, servers can directly communicate with each other using IP over FC, possibly boosting performance in Server host-to-host communications. This technique will be especially useful in a Clustering Application.
这导致了过去使用IP over FC的非标准方式。一旦完全指定了这种标准方法，服务器就可以使用IP over FC直接彼此通信，这可能会提高服务器主机间通信的性能。这种技术在集群应用程序中特别有用。
Objective and Scope:
目标和范围：
The major objective of this specification is to promote interoperable implementations of IPv4 over FC. This specification describes a method for encapsulating IPv4 and Address Resolution Protocol (ARP) packets over FC. This specification accommodates any FC topology
本规范的主要目标是促进IPv4在FC上的互操作实现。本规范描述了通过FC封装IPv4和地址解析协议（ARP）数据包的方法。本规范适用于任何FC拓扑
(loop, fabric, or point-to-point) and any FC class of service (1, 2 or 3). This specification also describes a FC Address Resolution Protocol(FARP) for associating World Wide Port Names (MAC addresses) and FC Port identifiers.
（环路、结构或点对点）和任何FC服务类别（1、2或3）。本规范还描述了用于关联全球通用端口名称（MAC地址）和FC端口标识符的FC地址解析协议（FARP）。
A secondary objective of this specification is to describe other optional address resolution mechanisms:
本规范的第二个目标是描述其他可选地址解析机制：
- Other FARP mechanisms that directly build IPv4 address and FC Port Identifier (Port_ID) associations. - Inverse ARP (InARP) that allows learning the IP address of a remote node given its World Wide Port Name (WW_PN) and Port_ID.
- 直接构建IPv4地址和FC端口标识符（端口ID）关联的其他FARP机制。-反向ARP（InARP），允许根据远程节点的全球通用端口名（WW_PN）和端口ID学习其IP地址。
"Multicasting" in Fibre Channel is defined as an optional service [11] for FC Classes 3 and 6 only, with no definition for Classes 1 and 2. Currently, there are no vendor implementations of this service for either Class of service. Broadcast service available within Fibre Channel can be used to do multicasting, although less efficiently. Presently, there appears to be no IP applications over Fibre Channel that require support for IP multicasting. This specification therefore does not support IP Multicasting.
光纤通道中的“多播”定义为仅适用于FC类别3和6的可选服务[11]，而不适用于类别1和类别2。目前，这两种服务都没有供应商实现。光纤通道中可用的广播服务可用于多播，但效率较低。目前，光纤通道上似乎没有需要支持IP多播的IP应用程序。因此，本规范不支持IP多播。
Organization:
组织：
Section 2 states the problem that is solved in this specification. Section 3 describes the techniques used for encapsulating IP and ARP packets in a FC sequence. Section 4 discusses the ARP protocol(IP address to WW_PN). Section 5 discusses the FARP protocol used in FC Layer mappings (WW_PN to Port_ID). Section 6 describes the "Exchange" Management in FC. Section 7 is a summary section and provides a quick reference to FC header settings, FC Link Service Commands, supported features in ARP, FARP, InARP, FC Sequences, FC Exchanges, and FC Login Parameters. Section 8 discusses security. Section 9 acknowledges the technical contributors of this document. Section 10 provides a list of references, and Section 11 provides the authors' addresses.
第2节说明了本规范中解决的问题。第3节描述了用于在FC序列中封装IP和ARP数据包的技术。第4节讨论ARP协议（WW_PN的IP地址）。第5节讨论FC层映射（WW_PN到端口ID）中使用的FARP协议。第6节介绍了FC中的“交换”管理。第7节是一个摘要部分，提供了FC头设置、FC链路服务命令、ARP、FARP、InARP、FC序列、FC交换和FC登录参数中支持的功能的快速参考。第8节讨论安全性。第9节确认本文件的技术贡献者。第10节提供了参考文献列表，第11节提供了作者的地址。
Appendix A discusses other optional FARP mechanisms. Appendix B discusses the Inverse ARP protocol(WW_PN to IP address) as an alternate and optional way of building MAC and IP address associations. Appendix C lists some informal mechanisms for FC Layer Mappings. Appendix D provides a discussion on validation of the FC-layer mappings for the different FC topologies. Appendix E provides a brief overview of the FC Protocols and Networks. Appendix F addresses reliability in Class 3 and Sequence Count FC Protocol issues. Appendix G provides a list of acronyms and a glossary of FC Terms used in this specification.
附录A讨论了其他可选的FARP机制。附录B讨论了反向ARP协议（WW_PN到IP地址），作为建立MAC和IP地址关联的替代和可选方法。附录C列出了FC层映射的一些非正式机制。附录D提供了关于验证不同FC拓扑的FC层映射的讨论。附录E简要概述了FC协议和网络。附录F解决了3级和序列计数FC协议的可靠性问题。附录G提供了本规范中使用的首字母缩略词列表和FC术语表。
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 RFC 2119 [19].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[19]中所述进行解释。
This specification addresses two problems:
本规范解决了两个问题：
- A format definition and encapsulation mechanism for IPv4 and ARP packets over FC - Mechanisms for Address Resolution
- FC上IPv4和ARP数据包的格式定义和封装机制-地址解析机制
As noted earlier, the existing FC Standard [3] ([10]) is inadequate to solve the above problems. A solution to both problems was first proposed by the Fibre Channel Association (FCA)[1]. FCA is an industry consortium of FC vendor companies and not a Standards Body. This specification is based on the proposed solution in [1] and builds on it.
如前所述，现有的FC标准[3]（[10]）不足以解决上述问题。光纤通道协会（FCA）[1]首次提出了这两个问题的解决方案。FCA是FC供应商公司的行业联盟，而不是标准机构。本规范基于[1]中提出的解决方案，并以此为基础。
Address Resolution is concerned with resolving IP addresses to WW_PN (MAC address) and WW_PN to FC Port Identifiers (Port_ID). ARP provides a solution to the first resolution problem and FARP the second.
地址解析涉及将IP地址解析为WW_PN（MAC地址），将WW_PN解析为FC端口标识符（端口ID）。ARP为第一个分辨率问题提供解决方案，FARP为第二个分辨率问题提供解决方案。
An optional FARP mechanism resolves IP address directly to FC Port_IDs. This is useful in some upper layer applications.
可选的FARP机制将IP地址直接解析为FC端口ID。这在某些上层应用程序中很有用。
InARP is another optional mechanism that resolves WW_PN and Port_ID to an IP address. InARP is useful when a node after performing a PLOGI with another node, knows its WW_PN and Port_ID, but not its IP address.
INAP是另一种可选机制，它将WW_PN和端口ID解析为IP地址。当一个节点在与另一个节点执行PLOGI后知道其WW_PN和端口ID，但不知道其IP地址时，INRAP非常有用。
All FC frames have a standard format much like LAN 802.x protocols. (See Appendix E and F). However, the exact size of each frame varies depending on the size of the variable fields. The size of the variable field ranges from 0 to 2112-bytes as shown in the FC Frame Format in Fig. 1.
所有FC帧都有一个标准格式，很像LAN 802.x协议。（见附录E和F）。但是，每个帧的确切大小取决于变量字段的大小。变量字段的大小范围为0到2112字节，如图1中的FC帧格式所示。
+------+--------+-----------+----//-------+------+------+
| SOF |Frame |Optional | Frame | CRC | EOF |
| (4B) |Header |Header | Payload | (4B) | (4B) |
| |(24B) |<----------------------->| | |
| | | Data Field = (0-2112B) | | |
+------+--------+-----------+----//-------+------+------+
Fig. 1 FC Frame Format
+------+--------+-----------+----//-------+------+------+
| SOF |Frame |Optional | Frame | CRC | EOF |
| (4B) |Header |Header | Payload | (4B) | (4B) |
| |(24B) |<----------------------->| | |
| | | Data Field = (0-2112B) | | |
+------+--------+-----------+----//-------+------+------+
Fig. 1 FC Frame Format
The Start of Frame (SOF) and End of Frame (EOF) are both 4-bytes long and act as frame delimiters.
帧开始（SOF）和帧结束（EOF）都是4字节长，用作帧分隔符。
The CRC is 4-bytes long and uses the same 32-bit polynomial used in FDDI and is specified in ANSI X3.139 Fiber Distributed Data Interface.
CRC长度为4字节，使用FDDI中使用的相同32位多项式，并在ANSI X3.139光纤分布式数据接口中指定。
The Frame Header is 24-bytes long and has several fields that are associated with the identification and control of the payload. Some of the values and options for this field that are relevant to the IP and ARP payloads are discussed in Section 7.
帧头的长度为24字节，有几个字段与有效负载的标识和控制相关。第7节讨论了与IP和ARP有效载荷相关的该字段的一些值和选项。
Current FC Standards allow up to 3 Optional Header fields [11]:
当前FC标准最多允许3个可选的标题字段[11]：
- Network_Header (16-bytes) - Association_Header (32-bytes) - Device_Header (up to 64-bytes).
- 网络_头（16字节）-关联_头（32字节）-设备_头（最多64字节）。
The IP and ARP FC Sequences SHALL carry only the Network_Header field which is 16-bytes long. Other types of optional headers SHALL NOT be used. The Network_Header is REQUIRED in all ARP packets and in the first frame of a logical sequence carrying an IP payload as described below.
IP和ARP FC序列应仅携带16字节长的网络头字段。不得使用其他类型的可选集管。在所有ARP数据包中以及在承载IP有效载荷的逻辑序列的第一帧中都需要网络头，如下所述。
An application level payload such as IP is called an Information Unit at the FC-4 Level. Lower FC levels map this to a FC Sequence. (See Appendix E.2 for a description of Sequences and Information Units.) Typically, a Sequence consists of more than one frame. Larger user data is segmented and reassembled using two methods: Sequence Count and Relative Offset [18]. With the use of Sequence Count, data blocks are sent using frames with increasing sequence counts (modulo 65536) and it is quite straightforward to detect the first frame that contains the Network_Header. When Relative Offset is used, as frames arrive, some computation is required to detect the first frame that contains the Network_Header. Sequence Count and Relative Offset field control information, is carried in the FC Header.
应用级有效负载（如IP）称为FC-4级的信息单元。较低的FC级别将其映射到FC序列。（序列和信息单元的描述见附录E.2。）通常，序列由多个帧组成。使用两种方法对较大的用户数据进行分段和重组：序列计数和相对偏移量[18]。通过使用序列计数，使用序列计数增加的帧（模65536）发送数据块，并且检测包含网络头的第一帧非常简单。当使用相对偏移量时，当帧到达时，需要进行一些计算来检测包含网络头的第一帧。序列计数和相对偏移量字段控制信息携带在FC报头中。
In FC, the physical temporal ordering of the frames as it arrives at a destination can be different from that of the order sent because of traversing through a FC Network.
在FC中，帧到达目的地时的物理时间顺序可能与发送的顺序不同，因为通过FC网络进行遍历。
When IP forms the FC Payload then only the first frame of the logical Sequence SHALL include the FC Network_Header. Fig. 2 shows the logical First Frame and logical subsequent frames. Since frames may arrive out of order, detection of the first frame of the logical FC Sequence is necessary.
当IP形成FC有效载荷时，只有逻辑序列的第一帧应包括FC网络头。图2示出了逻辑第一帧和逻辑后续帧。由于帧可能无序到达，因此需要检测逻辑FC序列的第一帧。
ARP packets map to a single frame FC Sequence and SHALL always carry the FC Network_Header.
ARP数据包映射到单帧FC序列，并应始终携带FC网络_头。
Note the definition of FC Data Field and FC Frame Payload in Fig. 1. FC Data Field includes the FC Frame Payload and the FC Optional Header, that is, Frame Payload definition does not include the FC Optional Header. One or more Frame Payloads together make the FC Sequence Payload as shown in Fig 2 and discussed further in Sections 3.2 and 3.4. FC Sequence Payload includes the mapped IP or ARP packet along with the LLC/SNAP headers.
注意图1中FC数据字段和FC帧有效载荷的定义。FC数据字段包括FC帧有效负载和FC可选报头，即，帧有效负载定义不包括FC可选报头。一个或多个帧有效载荷共同构成FC序列有效载荷，如图2所示，并在第3.2和3.4节中进一步讨论。FC序列有效负载包括映射的IP或ARP数据包以及LLC/SNAP报头。
First Frame of a Logical FC Sequence
---+------------+---------------------------+----------//----------+---
| FC Header | FC Network_Header | FC Sequence Payload |
---+------------+---------------------------+---------//-----------+---
First Frame of a Logical FC Sequence
---+------------+---------------------------+----------//----------+---
| FC Header | FC Network_Header | FC Sequence Payload |
---+------------+---------------------------+---------//-----------+---
Subsequent Frames of a Logical FC Sequence
--+-----------+--------------//----------------+--
| FC Header | Additional FC Sequence Payload |
--+-----------+-------------//-----------------+--
Subsequent Frames of a Logical FC Sequence
--+-----------+--------------//----------------+--
| FC Header | Additional FC Sequence Payload |
--+-----------+-------------//-----------------+--
Fig. 2 FC Network_Header in a Frame Sequence
图2帧序列中的FC网络_报头
The SOF, CRC, EOF control fields of the FC frame and other optional headers have been omitted in the figure for clarity.
为了清楚起见，图中省略了FC帧的SOF、CRC、EOF控制字段和其他可选报头。
An FC Information Unit specific to each protocol such as IP is defined in FC-4. This defines the upper bound on the size of the information that can be transported.
FC-4中定义了特定于每个协议（如IP）的FC信息单元。这定义了可以传输的信息大小的上限。
Each IP or ARP Packet is mapped to a single FC Information Unit, which in turn is mapped to a single FC Sequence. There is a one-to-one mapping between an IP or ARP packet and a FC Sequence.
每个IP或ARP数据包被映射到单个FC信息单元，该信息单元又被映射到单个FC序列。IP或ARP数据包与FC序列之间存在一对一映射。
Fibre Channel limits the size of a single Information Unit to 2^32-1, which is very large [2]. However, since the Maximum Transmission Unit (MTU) size of an IPv4 packet does not exceed 65,536-bytes, the mapped IPv4 size is far below the 2^32-1 limit.
光纤通道将单个信息单元的大小限制为2^32-1，这是非常大的[2]。但是，由于IPv4数据包的最大传输单元（MTU）大小不超过65536字节，因此映射的IPv4大小远低于2^32-1限制。
IPv4 Packet definition includes the IP Payload and IP Headers - both fixed and optional. The corresponding FC Sequence Payload includes the LLC/SNAP Header and the IPv4 packet.
IPv4数据包定义包括IP有效负载和IP报头（固定和可选）。相应的FC序列有效负载包括LLC/SNAP报头和IPv4数据包。
As noted above, the greatest length allowed for an IPv4 Packet including any optional headers and independent of this standard is 65,536-bytes. However, limiting the IP MTU size to 65,280-bytes helps in buffer resource allocation at N_Ports and also allows for up to 256-bytes of overhead. Since the FC Network_Header requires 16-bytes and the IEEE 802.2 LLC/SNAP header requires 8 bytes, it leaves 232 bytes for future use.
如上所述，IPv4数据包（包括任何可选标头）允许的最大长度为65536字节，与本标准无关。但是，将IP MTU大小限制为65280字节有助于在N_端口分配缓冲区资源，并允许高达256字节的开销。由于FC Network_标头需要16个字节，而IEEE 802.2 LLC/SNAP标头需要8个字节，因此它会留下232个字节供将来使用。
All implementations SHALL restrict the IP MTU size to 65,280 bytes and the corresponding FC Sequence Payload size to 65536-bytes.
所有实现应将IP MTU大小限制为65280字节，并将相应的FC序列有效负载大小限制为65536字节。
In order for IP fragmentation and reassembly to work properly it is necessary that every implementation of IP be capable of transporting a maximally minimum size IP packet without fragmentation. A maximally minimum size IP Packet is defined as an IP Packet with an 8-byte payload (the smallest possible non-zero payload size for a fragment) and a 60-byte header (the largest possible header consisting of a 20-byte fixed part and a maximum size option field of 40-bytes) [17].
为了使IP分段和重新组装能够正常工作，每个IP实现都必须能够在不分段的情况下传输最大最小大小的IP数据包。最大最小大小的IP数据包定义为具有8字节有效负载（片段的最小可能非零有效负载大小）和60字节报头（最大可能报头由20字节固定部分和40字节的最大大小选项字段组成）[17]的IP数据包。
All implementations SHALL support a FC Data Field of 92-bytes, which is required to support 68-bytes of the maximally minimum sized IP Packet, 16-bytes of the FC Network_Header, and 8-bytes of the LLC/SNAP Header.
所有实现应支持92字节的FC数据字段，这需要支持68字节的最大最小大小IP数据包、16字节的FC网络_报头和8字节的LLC/SNAP报头。
The ARP packet has a fixed size of 28-bytes. All implementations SHALL support a FC Data Field size of 52-bytes, which is required to support 28-bytes of an ARP Packet, 16-bytes of the FC Network_Header, and 8-bytes of the LLC/SNAP Header. Note that the minimum MTU requirement for ARP is already covered by the minimum MTU requirement for IP but it is mentioned here for completeness.
ARP数据包的固定大小为28字节。所有实现应支持52字节的FC数据字段大小，这是支持28字节的ARP数据包、16字节的FC网络_报头和8字节的LLC/SNAP报头所必需的。请注意，ARP的最低MTU要求已经包含在IP的最低MTU要求中，但为了完整性，这里提到了它。
The InARP packet is identical in size to the ARP and the same MTU requirements apply.
InARP数据包的大小与ARP相同，并且适用相同的MTU要求。
The FARP Command is a FC Extended Link Service (ELS) command and maps directly to the FC Data Field without the LLC/SNAP or the FC Network_Header. The FARP Command has a fixed size of 76-bytes. Because FARP operates purely in the FC space, it places no special MTU requirements in this specification.
FARP命令是FC扩展链路服务（ELS）命令，直接映射到FC数据字段，无需LLC/SNAP或FC网络_头。FARP命令的固定大小为76字节。由于FARP仅在FC空间中运行，因此在本规范中没有特殊的MTU要求。
FC devices are identified by Nodes and their Ports. A Node is a collection of one or more Ports identified by a unique nonvolatile 64-bit World Wide Node name (WW_NN). Each Port in a node, is identified with a unique nonvolatile 64-bit World Wide Port name (WW_PN), and a volatile Port Identifier (Port_ID).
FC设备由节点及其端口标识。节点是由唯一的非易失性64位全球通用节点名（WW_NN）标识的一个或多个端口的集合。节点中的每个端口都由唯一的非易失性64位全球通用端口名（WW_PN）和易失性端口标识符（Port_ID）标识。
Port_IDs are 24-bits long. A FC frame header carries a Source Port_ID (S_ID) and a Destination Port_ID (D_ID). The Port_ID of a given port is volatile. (The mechanism(s) by which a Port_ID may change in a FC topology is outside the scope of this document. See Appendix D).
端口ID为24位长。FC帧头携带源端口ID（S_ID）和目标端口ID（D_ID）。给定端口的端口ID不稳定。（FC拓扑中端口ID可能发生变化的机制不在本文档范围内。请参阅附录D）。
The FC Network_Header is normally optional in FC Standards, but REQUIRED in this specification. A FC Network_Header carries source and destination WW_PNs. A WW_PN consists of a 60-bit Network Address and a upper 4-bit Network Address Authority (NAA) field as shown in Fig. 3. The 4-bit NAA field is used to distinguish between the various name registration authorities used to define the Network Address [2].
FC网络头在FC标准中通常是可选的，但在本规范中是必需的。FC网络_头承载源和目标WW_PN。WW_PN由一个60位网络地址和一个上层4位网络地址授权（NAA）字段组成，如图3所示。4位NAA字段用于区分用于定义网络地址的各种名称注册机构[2]。
In this specification, both the Source and Destination 4-bit NAA identifiers SHALL be set to binary '0001' indicating that an IEEE 48-bit MAC address is contained in the lower 48 bits of the network address fields. The high order 12 bits in the network address fields SHALL be set to 0x0000. The NAA field value equal to binary '0001' allows FC networks to be bridged with other FC networks or traditional LANs.
在本规范中，源和目标4位NAA标识符均应设置为二进制“0001”，表示IEEE 48位MAC地址包含在网络地址字段的较低48位中。网络地址字段中的高阶12位应设置为0x0000。等于二进制“0001”的NAA字段值允许FC网络与其他FC网络或传统LAN桥接。
+--------+---------------------------------------+
| D_NAA |Network_Dest_Address (High-order bits) |
|(4 bits)| (28 bits) |
+--------+---------------------------------------+
| Network_Dest_Address (Low-order bits) |
| (32 bits) |
+--------+---------------------------------------+
| S_NAA |Network_Source_Address(High-order bits)|
|(4 bits)| (28 bits) |
+--------+---------------------------------------+
| Network_Source_Address (Low-order bit) |
| (32 bits) |
+--------+---------------------------------------+
+--------+---------------------------------------+
| D_NAA |Network_Dest_Address (High-order bits) |
|(4 bits)| (28 bits) |
+--------+---------------------------------------+
| Network_Dest_Address (Low-order bits) |
| (32 bits) |
+--------+---------------------------------------+
| S_NAA |Network_Source_Address(High-order bits)|
|(4 bits)| (28 bits) |
+--------+---------------------------------------+
| Network_Source_Address (Low-order bit) |
| (32 bits) |
+--------+---------------------------------------+
Fig. 3 Format of the Network_Header Field
图3网络头字段的格式
FC Payload with IP:
具有IP的FC有效负载：
An FC Sequence Payload carrying an IP and ARP packet SHALL use the formats shown in Figs. 4 and 5 respectively. Both formats use the 8-byte LLC/SNAP header.
承载IP和ARP数据包的FC序列有效载荷应使用图中所示的格式。分别为4和5。这两种格式都使用8字节LLC/SNAP标头。
+-----------------+-----------+------------+-------------//----------+
| LLC/SNAP Header | IP Header | Opt.IP Hdr.| IP Data |
| (8 bytes) | (20 bytes)| (40 bytes | (65280 -IP Header |
| | | Max) | - Opt. IP Hdr.) bytes |
+-----------------+-----------+------------+-------------//----------+
+-----------------+-----------+------------+-------------//----------+
| LLC/SNAP Header | IP Header | Opt.IP Hdr.| IP Data |
| (8 bytes) | (20 bytes)| (40 bytes | (65280 -IP Header |
| | | Max) | - Opt. IP Hdr.) bytes |
+-----------------+-----------+------------+-------------//----------+
Fig. 4 Format of FC Sequence Payload carrying IP
图4承载IP的FC序列有效载荷格式
FC Sequence Payload with ARP:
具有ARP的FC序列有效负载：
As noted earlier, FC frames belonging to the same Sequence may be delivered out of order over a Fabric. If the Relative Offset method is used to identify FC Sequence Payload fragments, then the IP Header MUST appear in the frame that has a relative offset of 0.
如前所述，属于相同序列的FC帧可能在结构上无序交付。如果使用相对偏移量方法识别FC序列有效负载片段，则IP头必须出现在相对偏移量为0的帧中。
+-----------------+-------------------+
| LLC/SNAP Header | ARP Packet |
| (8 bytes) | (28 bytes) |
+-----------------+-------------------+
+-----------------+-------------------+
| LLC/SNAP Header | ARP Packet |
| (8 bytes) | (28 bytes) |
+-----------------+-------------------+
Fig. 5 Format of FC Sequence Payload carrying ARP
图5承载ARP的FC序列有效载荷格式
FC Sequence Payload with FARP:
具有FARP的FC序列有效负载：
FARP Protocol commands are directly mapped to the Frame Sequence Payload and are 76-bytes long. No LLC/SNAP Header or FC Network_Header is used and therefore the FC Data Field size simply consists of the FC Sequence Payload.
FARP协议命令直接映射到帧序列有效负载，长度为76字节。未使用LLC/SNAP报头或FC网络_报头，因此FC数据字段大小仅由FC序列有效负载组成。
LLC:
有限责任公司：
A Logical Link Control (LLC) field along with a Sub Network Access Protocol (SNAP) field is a method used to identify routed and bridged non-OSI protocol PDUs and is defined by IEEE 802.2 and applied to IP in [8]. In LLC Type 1 operation (i.e., unacknowledged connectionless mode), the LLC header is 3-bytes long and consists of a 1-byte Destination Service Access Point (DSAP)field, a 1-byte Source Service Access Point (SSAP)field, and a 1-byte Control field as shown in Fig. 6.
逻辑链路控制（LLC）字段和子网访问协议（SNAP）字段是一种用于识别路由和桥接非OSI协议PDU的方法，由IEEE 802.2定义，并应用于[8]中的IP。在LLC类型1操作（即，未确认无连接模式）中，LLC报头的长度为3字节，由1字节目标服务接入点（DSAP）字段、1字节源服务接入点（SSAP）字段和1字节控制字段组成，如图6所示。
+----------+----------+----------+
| DSAP | SSAP | CTRL |
| (1 byte) | (1 byte) | (1 byte) |
+----------+----------+----------+
Fig. 6 LLC Format
+----------+----------+----------+
| DSAP | SSAP | CTRL |
| (1 byte) | (1 byte) | (1 byte) |
+----------+----------+----------+
Fig. 6 LLC Format
The LLC's DSAP and SSAP values of 0xAA indicate that an IEEE 802.2 SNAP header follows. The LLC's CTRL value equal to 0x03 specifies an Unnumbered Information Command PDU. In this specification the LLC Header value SHALL be set to 0xAA-AA-03. Other values of DSAP/SSAP indicate support for other protocols and SHALL NOT be used in this specification.
LLC的DSAP和SSAP值为0xAA，表示随后出现IEEE 802.2 SNAP头。LLC的CTRL值等于0x03，指定一个未编号的信息命令PDU。在本规范中，LLC标题值应设置为0xAA-AA-03。DSAP/SSAP的其他值表示对其他协议的支持，不应在本规范中使用。
SNAP:
捕捉：
The SNAP Header is 5-bytes long and consists of a 3-byte Organizationally Unique Identifier (OUI) field and a 2-byte Protocol Identifier (PID) as shown in Fig. 7
SNAP标头的长度为5字节，由3字节的组织唯一标识符（OUI）字段和2字节的协议标识符（PID）组成，如图7所示
+------+------+-------+------+------+
| OUI | PID |
| ( 3 bytes) | (2 bytes) |
+------+------+-------+------+------+
Fig. 7 SNAP Format
+------+------+-------+------+------+
| OUI | PID |
| ( 3 bytes) | (2 bytes) |
+------+------+-------+------+------+
Fig. 7 SNAP Format
SNAP was invented to "encapsulate" LAN frames within the payload. The SNAP OUI value equal to 0x00-00-00 specifies that the PID is an EtherType (i.e., routed non-OSI protocol).
SNAP被发明来“封装”有效载荷中的LAN帧。等于0x00-00-00的SNAP OUI值指定PID为以太类型（即路由非OSI协议）。
The SNAP OUI value equal to 0x00-80-C2 indicates Bridged Protocols.
等于0x00-80-C2的SNAP OUI值表示桥接协议。
With the OUI value set to 0x00-00-00, the SNAP PID value equal to 0x08-00 indicates IP and a PID value equal to 0x08-06 indicates ARP (or InARP).
当OUI值设置为0x00-00-00时，等于0x08-00的捕捉PID值表示IP，等于0x08-06的PID值表示ARP（或INAP）。
The complete LLC/SNAP Header is shown in Fig. 8.
图8显示了完整的LLC/SNAP头。
+-----------+----------+----------+-------+-------+-------+-------+------+
| DSAP | SSAP | CTRL | OUI | PID |
| (1 byte) | (1 byte) | (1 byte) | ( 3 bytes) | (2 bytes |
+-----------+----------+----------+-------+-------+-------+-------+------+
+-----------+----------+----------+-------+-------+-------+-------+------+
| DSAP | SSAP | CTRL | OUI | PID |
| (1 byte) | (1 byte) | (1 byte) | ( 3 bytes) | (2 bytes |
+-----------+----------+----------+-------+-------+-------+-------+------+
Fig. 8 LLC/SNAP Header
图8 LLC/SNAP收割台
IP or ARP Packets are mapped to FC-4 Level using the big endian byte ordering, which corresponds to the standard network byte order or canonical form [20]. FC-4 Payload maps with no change in order to the FC-2 Level.
IP或ARP数据包使用大端字节顺序映射到FC-4级别，大端字节顺序对应于标准网络字节顺序或规范格式[20]。FC-4有效负载无需更改即可映射到FC-2级别。
FC-1 Level defines the method used to encode data prior to transmission and subsequently decode the data upon reception. The method encodes 8-bit bytes into 10-bit transmission characters to improve the transmission characteristics of the serial data stream. In Fibre Channel, data fields are aligned on word boundaries. See Appendix E. A word in FC is defined as 4 bytes or 32 bits. The resulting transmission word after the 8-bit to 10-bit encoding consists of 40 bits.
FC-1级别定义了用于在传输前对数据进行编码，然后在接收时对数据进行解码的方法。该方法将8位字节编码为10位传输字符，以改善串行数据流的传输特性。在光纤通道中，数据字段在字边界上对齐。参见附录E。FC中的字定义为4字节或32位。8位到10位编码后产生的传输字由40位组成。
Data words or Ordered Sets (special FC-2 Level control words) from the FC-2 Level map to the FC-1 Level with no change in order and the bytes in the word are transmitted in the Most Significant Byte first to Least Significant Byte order. The transmission order of bits within each byte is the Least Significant Bit to the Most Significant Bit.
从FC-2级映射到FC-1级的数据字或有序集（特殊FC-2级控制字），顺序不变，字中的字节以最高有效字节的第一位到最低有效字节的顺序传输。每个字节内位的传输顺序为最低有效位到最高有效位。
Address Resolution in this specification is primarily concerned with associating IP addresses with FC Port addresses. As described earlier, FC device ports have two types of addresses:
本规范中的地址解析主要涉及将IP地址与FC端口地址关联。如前所述，FC设备端口有两种类型的地址：
- a non-volatile unique 64-bit address called World Wide Port_Name (WW_PN) - a volatile 24-bit address called a Port_ID
- 一个非易失性的唯一64位地址，称为全球端口名称（WW_PN）——一个易失性的24位地址，称为端口ID
The Address Resolution mechanism therefore will need two levels of mapping:
因此，地址解析机制需要两个级别的映射：
1. A mapping from the IP address to the WW_PN (i.e., IEEE 48-bit MAC address)
1. 从IP地址到WW_PN的映射（即IEEE 48位MAC地址）
2. A mapping from the WW_PN to the Port_ID (see Appendix G for a definition of Port_ID)
2. 从WW_PN到Port_ID的映射（Port_ID的定义见附录G）
The address resolution problem is compounded by the fact that the Port_ID is volatile and the second mapping MUST be valid before use. Moreover, this validation process can be different depending on the network topology used. Appendix D provides a discussion on validation for the different FC topologies.
地址解析问题由于端口ID不稳定以及第二个映射必须在使用前有效而变得更加复杂。此外，根据所使用的网络拓扑，此验证过程可能会有所不同。附录D对不同FC拓扑的验证进行了讨论。
Architecturally, the first level of mapping and control operation is handled by the Address Resolution Protocol (ARP), and the second level by the FC Address Resolution Protocol (FARP). FARP is described in Section 5.
架构上，第一级映射和控制操作由地址解析协议（ARP）处理，第二级由FC地址解析协议（FARP）处理。FARP在第5节中描述。
Other optional mechanisms in FARP that directly map an IP address to a Port_ID, or WW_NN to a Port_ID are described in Appendix A.
FARP中直接将IP地址映射到Port_ID或WW_NN映射到Port_ID的其他可选机制如附录a所述。
The Inverse Address Resolution Protocol (InARP) is yet another optional mechanism that resolves WW_PN and Port_IDs to IP addresses. InARP is described in Appendix B.
反向地址解析协议（InARP）是将WW_PN和端口ID解析为IP地址的另一种可选机制。附录B中描述了InARP。
The Address Resolution Protocol (ARP) given in [9] was designed to be a general purpose protocol, and to work with many network technologies, and with many upper layer protocols. Fig 9 shows the ARP packet format based on [9], where the upper layer protocol uses a 4 octet protocol (IP) address and the network technology uses six-octet hardware (MAC) address.
[9]中给出的地址解析协议（ARP）设计为通用协议，可与许多网络技术和许多上层协议一起使用。图9显示了基于[9]的ARP数据包格式，其中上层协议使用4个八位字节的协议（IP）地址，网络技术使用6个八位字节的硬件（MAC）地址。
The ARP uses two packet types - Request and Reply - and each type of packet is 28 -bytes long in this specification. The ARP Packet fields are common to both ARP Requests and ARP Replys.
ARP使用两种数据包类型——请求和应答，在本规范中，每种数据包的长度为28字节。ARP数据包字段对于ARP请求和ARP应答都是通用的。
The LLC/SNAP encapsulated ARP Request Packet is mapped to a FC Broadcast Sequence and the exact mechanism used to broadcast a FC Sequence depends on the FC topology. This is discussed later in this section. Compliant ARP Request Broadcasts SHALL include Network_Headers.
LLC/SNAP封装的ARP请求包映射到FC广播序列，用于广播FC序列的确切机制取决于FC拓扑。这将在本节后面讨论。符合要求的ARP请求广播应包括网络头。
The LLC/SNAP encapsulated ARP Reply Packet is mapped to a FC Sequence. Compliant ARP Replys SHALL include Network_Headers.
LLC/SNAP封装的ARP应答包映射到FC序列。符合要求的ARP应答应包括网络头。
Note that in all discussions to follow, the WW_PN and the 48-bit MAC address conceptually mean the same thing.
请注意，在接下来的所有讨论中，WW_PN和48位MAC地址在概念上的含义是相同的。
The 'HW Type' field SHALL be set to 0x00-01.
“HW类型”字段应设置为0x00-01。
Technically, the correct HW Type value should be set to 0x00-06 according to RFC 1700 indicating IEEE 802 networks. However, as a practical matter a HW Type value of 0x00-06 is known to cause rejections from some Ethernet end stations when FC is bridged to Ethernet. Translational bridges are normally expected to change this field from Type 6 to 1 and vice versa under these configurations, but many do not. It is because of this reason that the Type Code is set to 1 rather than 6. However, both HW Type values of 0x00-01 and 0x00-06 SHALL be accepted.
从技术上讲，根据指示IEEE 802网络的RFC 1700，正确的HW类型值应设置为0x00-06。然而，实际上，当FC桥接到以太网时，已知HW类型值0x00-06会导致来自某些以太网终端站的拒绝。在这些配置下，平移桥通常会将该字段从类型6更改为类型1，反之亦然，但许多平移桥不会。正是由于这个原因，类型代码被设置为1而不是6。但是，应接受0x00-01和0x00-06的HW类型值。
The 'Protocol' field SHALL be set to 0x08-00 indicating IP protocol.
“协议”字段应设置为0x08-00，表示IP协议。
The 'HW Addr Length' field SHALL be set to 0x06 indicating 6-bytes of HW address.
“硬件地址长度”字段应设置为0x06，表示6字节的硬件地址。
The 'Protocol Addr Length' field SHALL be set to 0x04 indicating 4- bytes of IPv4 address.
“协议地址长度”字段应设置为0x04，表示IPv4地址的4字节。
The 'Operation' Code field SHALL be set as follows:
“操作”代码字段应设置如下：
0x00-01 for ARP Request 0x00-02 for ARP Reply
0x00-01用于ARP请求0x00-02用于ARP回复
The 'HW Addr of Sender' field SHALL be the 6-byte IEEE MAC address of the sender. It is either the Requester (ARP Request) or the Responder (ARP Reply) address.
“发送方的HW地址”字段应为发送方的6字节IEEE MAC地址。它是请求者（ARP请求）或响应者（ARP回复）地址。
The 'Protocol Addr of Sender' field SHALL be the 4-byte IP address of the Requester (ARP Request) or that of the Responder (ARP Reply).
“发送方的协议地址”字段应为请求方（ARP请求）或响应方（ARP回复）的4字节IP地址。
The 'HW Addr of Target' field SHALL be set to zero during an ARP Request and to the 6-byte MAC address of the Requester (ARP Request) in an ARP Reply.
在ARP请求期间，“HW Addr of Target”字段应设置为零，并在ARP应答中设置为请求者的6字节MAC地址（ARP请求）。
The 'Protocol Addr of Target' field SHALL be set to the 4-byte IP address of the Responder (ARP Reply) in a ARP Request, and to the 4-byte IP address of the Requester (ARP Request) in an ARP Reply.
“目标协议地址”字段应设置为ARP请求中响应者的4字节IP地址（ARP应答），以及ARP应答中请求者的4字节IP地址（ARP请求）。
+-------------------------+
| HW Type | 2 bytes
+-------------------------+
| Protocol | 2 bytes
+-------------------------+
| HW Addr Length | 1 byte
+-------------------------+
| Protocol Addr Length | 1 byte
+-------------------------+
| Op Code | 2 bytes
+-------------------------+
| HW Addr of Sender | 6 bytes
+-------------------------+
| Protocol Addr of Sender | 4 bytes
+-------------------------+
| HW Addr of Target | 6 bytes
+-------------------------+
| Protocol Addr of Target | 4 bytes
+-------------------------+
Total 28 bytes
Fig. 9 ARP Packet Format
+-------------------------+
| HW Type | 2 bytes
+-------------------------+
| Protocol | 2 bytes
+-------------------------+
| HW Addr Length | 1 byte
+-------------------------+
| Protocol Addr Length | 1 byte
+-------------------------+
| Op Code | 2 bytes
+-------------------------+
| HW Addr of Sender | 6 bytes
+-------------------------+
| Protocol Addr of Sender | 4 bytes
+-------------------------+
| HW Addr of Target | 6 bytes
+-------------------------+
| Protocol Addr of Target | 4 bytes
+-------------------------+
Total 28 bytes
Fig. 9 ARP Packet Format
Whenever a FC port wishes to send IP data to another FC port, then the following steps are taken:
每当一个FC端口希望向另一个FC端口发送IP数据时，将采取以下步骤：
1. The source port should first consult its local mapping tables to determine the <destination IP address, destination WW_PN>.
1. 源端口应首先查阅其本地映射表，以确定<destination IP address，destination WW\u PN>。
2. If such a mapping is found, then the source sends the IP data to the port whose WW_PN address was found in the table.
2. 如果找到这样的映射，则源将IP数据发送到表中找到其WW_PN地址的端口。
3. If such a mapping is not found, then the source sends an ARP Request broadcast to its connected FC network in anticipation of getting a reply from the correct destination along with its WW_PN.
3. 如果没有找到这样的映射，则源向其连接的FC网络发送ARP请求广播，以期望从正确的目的地及其WW_PN获得回复。
4. When an ARP Request Broadcast frame is received by a node with the matching IP address, it generates an ARP Reply. Since the ARP Reply must be addressed to a specific destination Port_ID, the FC layer mapping between the WW_PN and Port_ID (of the ARP Request orginator) MUST be valid before the reply is sent.
4. 当具有匹配IP地址的节点接收到ARP请求广播帧时，它生成ARP应答。由于ARP回复必须发送到特定的目标端口号，因此在发送回复之前，WW_PN和端口号（ARP请求发起人的）之间的FC层映射必须有效。
5. If no node has the matching IP address, the result is a silent behavior.
5. 如果没有节点具有匹配的IP地址，则结果是静默行为。
The ARP Request (Broadcast) and Reply mechanism described above still apply, although there is only one node that receives the ARP Request.
尽管只有一个节点接收ARP请求，但上述ARP请求（广播）和应答机制仍然适用。
In a private loop, the ARP Request Broadcast frame is sent using the broadcast method specified in the FC-AL [7]standard.
在专用环路中，使用FC-AL[7]标准中规定的广播方法发送ARP请求广播帧。
1. The source port first sends an Open Broadcast Replicate primitive (OPN(fr))Signal forcing all the ports in the loop (except itself), to replicate the frames that they receive while examining the frame header's Destination_ID field.
1. 源端口首先发送一个开放广播复制原语（OPN（fr））信号，强制循环中的所有端口（自身除外）复制它们在检查帧头的Destination_ID字段时接收的帧。
2. The source port then removes this OPN(fr) signal when it returns to it.
2. 然后，源端口在返回时删除此OPN（fr）信号。
3. The loop is now ready to receive the ARP broadcast. The source now sends the ARP Request as a single-frame Broadcast Sequence in a Class 3 frame with the following FC Header D_ID field and F_CTL bits setting:
3. 环路现在已准备好接收ARP广播。现在，源以3类帧中的单帧广播序列发送ARP请求，具有以下FC头D_ID字段和F_CTL位设置：
Destination ID <Word 0, bit 0:23>: D_ID = 0xFF-FF-FF
Destination ID <Word 0, bit 0:23>: D_ID = 0xFF-FF-FF
Sequence Initiative <Word 2, bit23>: SI=0
Sequence Initiative <Word 2, bit23>: SI=0
Last Sequence <Word 2, bit 20>: LS=1
Last Sequence <Word 2, bit 20>: LS=1
End Sequence <Word 2, bit 19>: ES=1.
结束序列<字2，位19>：ES=1。
4. A compliant ARP Broadcast Sequence frame SHALL include the Network_Header with destination MAC address set to 0xFF-FF-FF-FF-FF-FF and with NAA = b'0001'
4. 符合要求的ARP广播序列帧应包括网络头，目标MAC地址设置为0xFF，NAA=b'0001'
5. The destination port recognizing its IP address in the ARP Request packet SHALL respond with an ARP Reply.
5. 在ARP请求包中识别其IP地址的目标端口应以ARP应答进行响应。
The following steps will be followed when a port is configured in a public loop:
在公共环路中配置端口时，将遵循以下步骤：
1. A public loop device attached to a fabric through a FL_Port MUST NOT use the OPN(fr) signal primitive. Rather, it sends the broadcast sequence to the FL_Port at AL_PA = 0x00.
1. 通过FL_端口连接到结构的公共环路设备不得使用OPN（fr）信号原语。相反，它将广播序列发送到AL_PA=0x00处的FL_端口。
2. A FC Fabric propagates the broadcast to all other ports including the FL_Port which the broadcast arrived on. This includes all F_Ports, and other FL_Ports.
2. FC结构将广播传播到所有其他端口，包括广播到达的FL_端口。这包括所有F_端口和其他F_端口。
3. On each FL_Port, the fabric propagates the broadcast by first using the primitive signal OPNfr, in order to prepare the loop to receive the broadcast sequence.
3. 在每个FL_端口上，结构首先使用基本信号OPNfr传播广播，以便准备环路以接收广播序列。
4. A Broadcast Sequence is now sent on all ports (all FL_ports, F_Ports) in Class 3 frame with:
4. 广播序列现在在3级帧中的所有端口（所有FL_端口、F_端口）上发送，具有：
Destination ID <Word 0, bit 23:0>: D_ID = 0xFF-FF-FF
Destination ID <Word 0, bit 23:0>: D_ID = 0xFF-FF-FF
Sequence Initiative <Word 2, bit23>: SI=0
Sequence Initiative <Word 2, bit23>: SI=0
Last Sequence <Word 2, bit 20>: LS=1
Last Sequence <Word 2, bit 20>: LS=1
End Sequence <Word 2, bit 19>: ES=1.
结束序列<字2，位19>：ES=1。
5. A compliant ARP Broadcast Sequence frame SHALL include the Network_Header with destination MAC address set to 0xFF-FF-FF-FF-FF-FF and with NAA = b'0001'
5. 符合要求的ARP广播序列帧应包括网络头，目标MAC地址设置为0xFF，NAA=b'0001'
6. The destination port recognizing its IP address in the ARP Request packet SHALL respond with an ARP Reply.
6. 在ARP请求包中识别其IP地址的目标端口应以ARP应答进行响应。
1. Nodes directly attached to fabric do not require the OPN(fr) primitive signal.
1. 直接连接到结构的节点不需要OPN（fr）原语信号。
2. A Broadcast Sequence is now sent on all ports (all FL_ports, F_Ports) in Class 3 frame with:
2. 广播序列现在在3级帧中的所有端口（所有FL_端口、F_端口）上发送，具有：
Destination ID <Word 0, bit 23:0>: D_ID = 0xFF-FF-FF
Destination ID <Word 0, bit 23:0>: D_ID = 0xFF-FF-FF
Sequence Initiative <Word 2, bit23>: SI=0
Sequence Initiative <Word 2, bit23>: SI=0
Last Sequence <Word 2, bit 20>: LS=1
Last Sequence <Word 2, bit 20>: LS=1
End Sequence <Word 2, bit 19>: ES=1.
结束序列<字2，位19>：ES=1。
3. A compliant ARP Broadcast Sequence frame SHALL include the Network_Header with destination MAC address set to 0xFF-FF-FF-FF-FF-FF and with NAA = b'0001'
3. 符合要求的ARP广播序列帧应包括网络头，目标MAC地址设置为0xFF，NAA=b'0001'
4. The destination port recognizing its IP address in the ARP packet SHALL respond with an ARP Reply.
4. 在ARP数据包中识别其IP地址的目标端口应以ARP应答进行响应。
FC Layer Mapping between the WW_PN and the Port_ID is independent of the ARP mechanism and is more closely associated with the details of the FC protocols. Name Server and FC Address Resolution Protocol (FARP) are two formal mechanisms that can be used to create and maintain WW_PN to Port_ID tables.
WW_PN和端口ID之间的FC层映射独立于ARP机制，并且与FC协议的细节更密切相关。名称服务器和FC地址解析协议（FARP）是两种正式的机制，可用于创建和维护WW_PN到Port_ID表。
FARP is a method using Extended Link Service (ELS) commands that resolves <WW_PN, Port_ID> mappings. The WW_PN to Port_ID address resolution using FARP is especially useful in instances where the Login table entries at a node expire and a Name Server is not available. It is outside the scope of this document to describe Name Server. (See [14].)
FARP是一种使用扩展链路服务（ELS）命令解析<WW_PN，Port_ID>映射的方法。使用FARP的WW_PN到Port_ID地址解析在节点上的登录表条目过期且名称服务器不可用的情况下特别有用。描述名称服务器超出了本文档的范围。（见[14]。）
Additional address matching mechanisms that resolve <WW_NN, Port_ID> and <IP addr., Port_ID> mapping have been added to FARP. These additional mechanisms are optional and described in Appendix A. Direct IP address to Port_ID mapping is useful in applications where there is no visibility of the MAC address.
FARP中添加了解析<WW_NN，Port_ID>和<IP addr.，Port_ID>映射的其他地址匹配机制。这些附加机制是可选的，如附录A所述。在MAC地址不可见的应用程序中，直接IP地址到端口ID的映射非常有用。
Other less formal FC Layer Mapping mechanisms are described in Appendix C.
附录C中描述了其他不太正式的FC层映射机制。
Since Port_IDs are volatile, all mapped Port_IDs at all times MUST be valid before use. There are many events that can invalidate this mapping. Appendix D discusses conditions when such a validation is required.
由于端口ID是易失性的，所以所有映射的端口ID在使用前必须始终有效。有许多事件会使此映射无效。附录D讨论了需要进行此类验证的条件。
The FARP protocol uses two ELS commands - FARP-REQ and FARP-REPLY.
FARP协议使用两个ELS命令-FARP-REQ和FARP-REPLY。
Note: In the following discussion 'Requester' means the node issuing the FARP-REQ ELS message; 'Responder' means the node replying to the request by sending the FARP-REPLY command.
注：在以下讨论中，“请求者”指发出FARP-REQ ELS消息的节点；'响应者”指通过发送FARP-REPLY命令来响应请求的节点。
The FARP-REQ ELS Broadcast Request command is used to retrieve a specific node's current Port_ID given its unique WW_PN. This Port_ID is sent in a FARP-REPLY unicast command.
FARP-REQ ELS广播请求命令用于检索给定其唯一WW_PN的特定节点的当前端口ID。此端口号通过FARP-REPLY单播命令发送。
The FARP-REQ may indicate that the Responder:
FARP-REQ可指示响应者：
- Perform only a Login with it (Requester) or, - Send only a FARP-REPLY or, - Perform a Login and send a FARP-REPLY.
- 使用它（请求者）只执行登录，或者，-只发送FARP-REPLY，或者，-执行登录并发送FARP-REPLY。
No sequence initiative is transferred with the FARP-REQ and therefore no Reply (ACCEPT or REJECT) follows this command.
FARP-REQ不传输序列主动权，因此该命令后没有应答（接受或拒绝）。
Since a Sequence Initiative is transferred with the FARP-REPLY, either a ACCEPT or REJECT follows this command as a response.
由于序列主动权是通过FARP-REPLY传输的，所以接受或拒绝作为响应跟随该命令。
Reception of a FARP-REQ requires a higher level entity at the responding node to send a FARP-REPLY or perform a Port Login.
接收FARP-REQ需要响应节点上的更高级别实体发送FARP-REPLY或执行端口登录。
You do not have to be logged in to issue a FARP Request. Also, you do not have to be logged in to the FARP Requester to issue a FARP-REPLY.
您无需登录即可发出FARP请求。此外，您无需登录FARP请求者即可发布FARP-REPLY。
The FARP Protocol Steps:
FARP协议包括以下步骤：
FARP-REQ (ELS broadcast) Request Sequence
FARP-REQ（ELS广播）请求序列
(No Reply Sequence)
（无应答序列）
FARP-REPLY (ELS command) Sequence
FARP-REPLY（ELS命令）序列
Accept/Reject Reply Sequence
接受/拒绝回复序列
The FARP Protocol Format [2] and Size:
FARP协议格式[2]和大小：
FT_1, 76-bytes fixed size
FT_1，76字节固定大小
The FARP Protocol Addressing:
FARP协议涉及：
- In a FARP-REQ, the S_ID in the FC Header designates the Requester's Port ID. The D_ID in the FC Header is the broadcast identifier 0xFF-FF-FF.
- 在FARP-REQ中，FC报头中的S_ID指定请求者的端口ID。FC报头中的D_ID是广播标识符0xFF。
- In a FARP-REPLY, the S_ID in the FC Header designates the Responder's Port_ID. The D_ID in the FC Header is the Requester's Port_ID.
- 在FARP应答中，FC头中的S_ID指定响应者的端口ID。FC头中的D_ID是请求者的端口ID。
FARP-REQ and FARP-REPLY commands have identical formats (76-bytes fixed size) and fields but use different command codes. See tables below.
FARP-REQ和FARP-REPLY命令具有相同的格式（76字节固定大小）和字段，但使用不同的命令代码。见下表。
+---------------------------------------------------------------------+
| FARP-REQ Command |
+-------------------------------------+---------+---------------------+
| Field | Size | Remarks |
| | (Bytes) | |
+-------------------------------------+---------+---------------------+
| 0x54-00-00-00 | 4 | Request Command Code|
+-------------------------------------+---------+---------------------+
| Match Address Code Points | 1 | Indicates Address |
| | | Matching Mechanism |
+-------------------------------------+---------+---------------------+
| Port_ID of Requester | 3 | Supplied by |
| | | Requester = |
| | | S_ID in FC Header |
+-------------------------------------+---------+---------------------+
| Responder Flags | 1 | Response Action to |
| | | be taken |
+-------------------------------------+---------+---------------------+
| Port_ID of Responder | 3 | Set to 0x00-00-00 |
+-------------------------------------+---------+---------------------+
| WW_PN of Requester | 8 |Supplied by Requester|
+-------------------------------------+---------+---------------------+
+ WW_NN of Requester | 8 |OPTIONAL; |
| | |See Appendix A |
+-------------------------------------+---------+---------------------+
| WW_PN of Responder | 8 |Supplied by Requester|
+-------------------------------------+---------+---------------------+
| WW_NN of Responder | 8 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
| IP Address of Requester | 16 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
| IP Address of Responder | 16 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
+---------------------------------------------------------------------+
| FARP-REQ Command |
+-------------------------------------+---------+---------------------+
| Field | Size | Remarks |
| | (Bytes) | |
+-------------------------------------+---------+---------------------+
| 0x54-00-00-00 | 4 | Request Command Code|
+-------------------------------------+---------+---------------------+
| Match Address Code Points | 1 | Indicates Address |
| | | Matching Mechanism |
+-------------------------------------+---------+---------------------+
| Port_ID of Requester | 3 | Supplied by |
| | | Requester = |
| | | S_ID in FC Header |
+-------------------------------------+---------+---------------------+
| Responder Flags | 1 | Response Action to |
| | | be taken |
+-------------------------------------+---------+---------------------+
| Port_ID of Responder | 3 | Set to 0x00-00-00 |
+-------------------------------------+---------+---------------------+
| WW_PN of Requester | 8 |Supplied by Requester|
+-------------------------------------+---------+---------------------+
+ WW_NN of Requester | 8 |OPTIONAL; |
| | |See Appendix A |
+-------------------------------------+---------+---------------------+
| WW_PN of Responder | 8 |Supplied by Requester|
+-------------------------------------+---------+---------------------+
| WW_NN of Responder | 8 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
| IP Address of Requester | 16 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
| IP Address of Responder | 16 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
+---------------------------------------------------------------------+
| FARP-REPLY Command |
+-------------------------------------+---------+---------------------+
| Field | Size | Remarks |
| | (Bytes) | |
+-------------------------------------+---------+---------------------+
| 0x55-00-00-00 | 4 | Reply Command Code |
+-------------------------------------+---------+---------------------+
| Match Address Code Points | 1 | Not Used and |
| | | Unchanged from the |
| | | FARP-REQ |
+-------------------------------------+---------+---------------------+
| Port_ID of Requester | 3 | Extracted from |
| | | FARP-REQ |
+-------------------------------------+---------+---------------------+
| Responder Flags | 1 | Not Used and |
| | | Unchanged from the |
| | | FARP-REQ |
+-------------------------------------+---------+---------------------+
| Port_ID of Responder | 3 | Supplied by |
| | | Responder = |
| | | S_ID in FC Header |
+-------------------------------------+---------+---------------------+
|WW_PN of Requester | 8 |Supplied by Requester|
+-------------------------------------+---------+---------------------+
|WW_NN of Requester | 8 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
|WW_PN of Responder | 8 |Supplied by Requester|
+-------------------------------------+---------+---------------------+
|WW_NN of Responder | 8 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
|IP Add. of Requester | 16 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
|IP Address of Responder | 16 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
+---------------------------------------------------------------------+
| FARP-REPLY Command |
+-------------------------------------+---------+---------------------+
| Field | Size | Remarks |
| | (Bytes) | |
+-------------------------------------+---------+---------------------+
| 0x55-00-00-00 | 4 | Reply Command Code |
+-------------------------------------+---------+---------------------+
| Match Address Code Points | 1 | Not Used and |
| | | Unchanged from the |
| | | FARP-REQ |
+-------------------------------------+---------+---------------------+
| Port_ID of Requester | 3 | Extracted from |
| | | FARP-REQ |
+-------------------------------------+---------+---------------------+
| Responder Flags | 1 | Not Used and |
| | | Unchanged from the |
| | | FARP-REQ |
+-------------------------------------+---------+---------------------+
| Port_ID of Responder | 3 | Supplied by |
| | | Responder = |
| | | S_ID in FC Header |
+-------------------------------------+---------+---------------------+
|WW_PN of Requester | 8 |Supplied by Requester|
+-------------------------------------+---------+---------------------+
|WW_NN of Requester | 8 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
|WW_PN of Responder | 8 |Supplied by Requester|
+-------------------------------------+---------+---------------------+
|WW_NN of Responder | 8 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
|IP Add. of Requester | 16 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
|IP Address of Responder | 16 |OPTIONAL; see App. A |
+-------------------------------------+---------+---------------------+
Following is a description of the address fields in the FARP Commands.
以下是FARP命令中地址字段的说明。
Port_ID of Requester:
请求者的端口ID：
It is the 24-bit Port_ID used in the S_ID field of the FC Header of a FARP-REQ. It is supplied by the Requester in a FARP-REQ and retained in a FARP-REPLY.
它是FARP-REQ的FC报头的S_ID字段中使用的24位端口ID。它由请求者在FARP-REQ中提供，并保留在FARP-REPLY中。
Port_ID of Responder:
响应程序的端口号：
It is the 24-bit Port_ID used in the S_ID field of the FC Header of a FARP-REPLY. It SHALL be set to 0x00-00-00 in a FARP-REQ. It is supplied by the Responder in a FARP-REPLY.
它是FARP-REPLY的FC头的S_ID字段中使用的24位端口ID。在FARP-REQ中，应将其设置为0x00-00-00。由响应者在FARP-REPLY中提供。
WW_PN:
WW_PN:
This address field is used with the b'001', b'011', b'101, b'111', Match Address Code Points. See Match Address Code Point Table below. The Requester supplies the unique 8-byte WW_PN of the Requester and the Responder. It is retained in a FARP-REPLY.
此地址字段用于b'001'，b'011'，b'101，b'111'，匹配地址代码点。请参阅下面的匹配地址代码点表。请求者提供请求者和响应者的唯一8字节WW_PN。它保留在FARP-REPLY中。
WW_NN:
WW_NN：
The WW_NN address field is used with Match Address Code Points b'010', b'011', b'110', and b'111', which are all optional. Its usage is fully described in Appendix A. When the WW_NN field is not used it SHALL be either set to '0' or a valid non-zero address.
WW_NN地址字段与匹配地址代码点b'010'，b'011'，b'110'，和b'111'一起使用，这些都是可选的。其用法在附录A中有详细说明。如果未使用WW_NN字段，则应将其设置为“0”或有效的非零地址。
IPv4:
IPv4:
The IPv4 address field is used with the Match Address Code Points b'100', b'101', b'110', and b'111', which are all optional. Its usage is fully described in Appendix A. When the IP Address field is not used it SHALL be either set to '0' or a valid IP address. A valid IP address consists of the 32-bit IPv4 Address with the upper 96 bits set to '0'.
IPv4地址字段与匹配地址代码点b'100'，b'101'，b'110'，和b'111'一起使用，这些都是可选的。其用法在附录A中有详细说明。如果未使用IP地址字段，则应将其设置为“0”或有效的IP地址。有效的IP地址由32位IPv4地址组成，其上限96位设置为“0”。
For each receipt of the FARP-REQ Broadcast ELS, the recipients match one or more addresses based on the encoded bits of the "FARP Match Address Code Points" field shown in the table below. FARP operation with the Match Address Code Point equal to b'001' is described in this section. Other code points are OPTIONAL and are discussed in Appendix A. The upper 5 bits of the Match Address Code Point byte are unused and their use is not currently defined.
对于FARP-REQ广播ELS的每次接收，接收方根据下表所示“FARP匹配地址代码点”字段的编码位匹配一个或多个地址。本节描述了匹配地址代码点等于b'001'的FARP操作。其他代码点是可选的，在附录A中讨论。匹配地址代码点字节的上5位未使用，其用途目前未定义。
+------------------------------------------------------------------+
| Match Address Code Points |
+------------------------------------------------------------------+
| LSBits | Bit name | Action |
+-----------+--------------------+---------------------------------+
| 000 | Reserved | |
+-----------+--------------------+---------------------------------+
| 001 | MATCH_WW_PN | If 'WW_PN of Responder' = |
| | | Node's WW_PN then respond |
+-----------+--------------------+---------------------------------+
| 010 | MATCH_WW_NN | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 011 | MATCH_WW_PN_NN | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 100 | MATCH_IPv4 | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 101 | MATCH_WW_PN_IPv4 | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 110 | MATCH_WW_NN_IPv4 | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 111 | MATCH_WW_PN_NN_IPv4| OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
+------------------------------------------------------------------+
| Match Address Code Points |
+------------------------------------------------------------------+
| LSBits | Bit name | Action |
+-----------+--------------------+---------------------------------+
| 000 | Reserved | |
+-----------+--------------------+---------------------------------+
| 001 | MATCH_WW_PN | If 'WW_PN of Responder' = |
| | | Node's WW_PN then respond |
+-----------+--------------------+---------------------------------+
| 010 | MATCH_WW_NN | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 011 | MATCH_WW_PN_NN | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 100 | MATCH_IPv4 | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 101 | MATCH_WW_PN_IPv4 | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 110 | MATCH_WW_NN_IPv4 | OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
| 111 | MATCH_WW_PN_NN_IPv4| OPTIONAL; see Appendix A |
+-----------+--------------------+---------------------------------+
When a node receives a FARP-REQ with Code Point b'001', it checks its WW_PN against the one set in 'WW_PN of Responder' field of the FARP-REQ command. If there is a match, then the node issues a response according to the action indicated by the FARP Responder Flag. See table below.
当节点接收到代码点为b'001'的FARP-REQ时，它将对照FARP-REQ命令的“应答器的WW_PN”字段中设置的WW_PN检查其WW_PN。如果存在匹配，则节点根据FARP响应者标志指示的操作发出响应。见下表。
WW_NN and IPv4 address fields are not used with the b'001' Code Point operation. They SHALL be set to '0' or a valid address either by the Requester or the Requester and the Responder.
WW_NN和IPv4地址字段不用于b'001'代码点操作。请求者或请求者与响应者应将其设置为“0”或有效地址。
Note that there can be utmost one FARP-REPLY per FARP-REQ.
请注意，每个FARP-REQ最多只能有一个FARP-REPLY。
The Responder Flags define what Responder action to take if the result of the Match Address Code Points is successful. 'Responder Flags' is an 8-bit field (bits 0-7) and is defined in the table below. This field is used only in a FARP-REQ. This field is retained unchanged in a FARP-REPLY. If no bits are set, the Responder will take no action.
响应程序标志定义了如果匹配地址代码点的结果成功，响应程序将采取的操作。”响应器标志”是一个8位字段（位0-7），定义见下表。此字段仅在FARP-REQ中使用。该字段在FARP-REPLY中保持不变。如果未设置任何位，响应程序将不采取任何操作。
+----------+-------------------------------------------------------+
| | FARP Responder Flag |
+----------+----------------+--------------------------------------+
| Bit | Bit Name | Action |
| Position | | |
+----------+----------------+--------------------------------------+
| 0 | INIT_P_LOGI | Initiate a P_LOGI to the Requester |
+----------+----------------+--------------------------------------+
| 1 | INIT_REPLY | Send FARP_REPLY to Requester |
+----------+----------------+--------------------------------------+
| 2 to 7 | Reserved | |
+----------+----------------+--------------------------------------+
+----------+-------------------------------------------------------+
| | FARP Responder Flag |
+----------+----------------+--------------------------------------+
| Bit | Bit Name | Action |
| Position | | |
+----------+----------------+--------------------------------------+
| 0 | INIT_P_LOGI | Initiate a P_LOGI to the Requester |
+----------+----------------+--------------------------------------+
| 1 | INIT_REPLY | Send FARP_REPLY to Requester |
+----------+----------------+--------------------------------------+
| 2 to 7 | Reserved | |
+----------+----------------+--------------------------------------+
If INIT_P_LOGI bit is set then, a Login is performed with the port identified by "Port_ID of Requester" field.
如果设置了INIT_P_LOGI位，则使用“请求者的端口ID”字段标识的端口执行登录。
If INIT_REPLY is set then, a FARP-REPLY is sent to the Port Identified by "Port_ID of Requester" field.
如果设置了INIT_REPLY，则FARP-REPLY将发送到由“请求者的端口ID”字段标识的端口。
If both bits are set at the same time, then both Actions are performed.
如果同时设置两个位，则执行两个操作。
All other bit patterns are undefined at this time and are reserved for possible future use.
所有其他位模式此时未定义，保留供将来可能使用。
Responder action - FARP-REPLY and/or Port Login - for a successful MATCH_WW_PN is always REQUIRED. If there is no address match then a silent behavior is specified.
响应程序操作-FARP-REPLY和/或端口登录-始终需要成功匹配WW PN。如果没有地址匹配，则指定静默行为。
Support for all other Match Address Code Points is OPTIONAL and a silent behavior from the Responder is valid when it is not supported. Recipients of the FARP-REQ ELS SHALL NOT issue a Service Reject (LS_RJT) if FARP OPTIONAL mechanisms are not supported.
对所有其他匹配地址代码点的支持是可选的，响应程序的静默行为在不受支持时有效。如果FARP可选机制不受支持，FARP-REQ ELS的接收者不得发出服务拒绝（LS_RJT）。
In all cases, if there are no matches, then a silent behavior is specified.
在所有情况下，如果没有匹配项，则指定静默行为。
If an implementation issues a FARP-REQ with a Match Address Code Point that is OPTIONAL, and fails to receive a response, and the implementation has not obtained the Port_ID of the Responder's port by other means (e.g., prior FARP-REQ with other Code Points), then the implementation SHALL reattempt the FARP-REQ with the MATCH_WW_PN Code Point.
如果实现发出具有可选匹配地址代码点的FARP-REQ，并且未能接收响应，并且该实现未通过其他方式（例如，先前的FARP-REQ具有其他代码点）获得响应者端口的端口ID，则该实现应使用匹配地址代码点重新尝试FARP-REQ。
Getting multiple FARP Replies corresponding to a single FARP-REQ should normally never occur. It is beyond the scope of this document to specify conditions under which this error may occur or what the corrective action ought to be.
通常情况下，不会获得与单个FARP-REQ对应的多个FARP回复。指定可能发生此错误的条件或应采取的纠正措施超出了本文件的范围。
FC Exchanges shall be established to transfer data between ports. Frames on IP exchanges shall not transfer Sequence Initiative. See Appendix E for a discussion on FC Exchanges.
应建立FC交换，以在端口之间传输数据。IP交换机上的帧不应传输序列主动权。有关FC交换的讨论，请参见附录E。
With the exception of the recommendations in Appendix F, Section F.1, "Reliability in Class 3", the mechanism for aging or expiring exchanges based on activity, timeout, or other method is outside the scope of this document.
除附录F第F.1节“第3类可靠性”中的建议外，基于活动、超时或其他方法的老化或到期交换机制不在本文件范围内。
Exchanges may be terminated by either port. The Exchange Originator may terminate Exchanges by setting the LS bit, following normal FC standard FC-PH [2] rules. This specification prohibits the use of the NOP ELS with LS set for Exchange termination.
交换可以由任一端口终止。交换发起人可以通过设置LS位来终止交换，遵循正常的FC标准FC-PH[2]规则。本规范禁止使用设置了LS的NOP ELS进行交换终止。
Exchanges may be torn down by the Exchange Originator or Exchange Responder by using the ABTS_LS protocol. The use of ABTS_LS for terminating aged Exchanges or error recovery is outside the scope of this document.
交换发起者或交换响应者可使用ABTS_LS协议终止交换。使用ABTS_LS终止过时的交换或错误恢复不在本文档的范围内。
The termination of IP Exchanges by Logout is discouraged, since this may terminate active Exchanges on other FC-4s.
不鼓励通过注销终止IP交换，因为这可能会终止其他FC-4上的活动交换。
Note: 'Settable' means support is as specified in the relevant standard; all other key words are as defined earlier in this document.
注：“可设置”指相关标准中规定的支撑；所有其他关键词如本文件前面所述。
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| Type Code ( = 5) ISO8802-2 LLC/SNAP | REQUIRED | 2 |
| Network_Headers | REQUIRED | 3 |
| Other Optional Headers | MUST NOT | |
+--------------------------------------------------------------------+
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| Type Code ( = 5) ISO8802-2 LLC/SNAP | REQUIRED | 2 |
| Network_Headers | REQUIRED | 3 |
| Other Optional Headers | MUST NOT | |
+--------------------------------------------------------------------+
Notes:
笔记：
1. This table applies only to FC-4 related data, such as IP and ARP packets. This table does not apply to link services and other non-FC-4 sequences (PLOGI, for example) that must occur for normal operation.
1. 此表仅适用于FC-4相关数据，如IP和ARP数据包。此表不适用于正常运行必须出现的链路服务和其他非FC-4序列（例如PLOGI）。
2. The TYPE field in the FC Header (Word 2 bits 31-24) MUST indicate ISO 8802-2 LLC/SNAP Encapsulation (Type 5). This revision of the document focuses solely on the issues related to running IP and ARP over FC. All other issues are outside the scope of this document, including full support for IEEE 802.2 LLC.
2. FC头中的类型字段（字2位31-24）必须指示ISO 8802-2 LLC/SNAP封装（类型5）。本文件修订版仅关注与通过FC运行IP和ARP相关的问题。所有其他问题不在本文件范围内，包括对IEEE 802.2 LLC的全面支持。
3. DF_CTL field (Word 3, bits 23-16 of FC-Header) MUST indicate the presence of a Network_Header (0010 0000) on the First logical Frame of FC-4 Sequences. It should not indicate the presence of a Network_Header on any subsequent frames of the Sequence.
3. DF_CTL字段（字3，FC头的位23-16）必须指示FC-4序列的第一个逻辑帧上存在网络_头（0010 0000）。它不应指示序列的任何后续帧上存在网络_报头。
R_CTL in FC-Header: Word 0, bits 31-24
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| Information Category (R_CTL Routing): | | |
| | | |
| FC-4 Device Data | REQUIRED | 1 |
| Extended Link Data | REQUIRED | |
| FC-4 Link Data | MUST NOT | |
| Video Data | MUST NOT | |
| Basic Link Data | REQUIRED | |
| Link Control | REQUIRED | |
| | | |
| R_CTL information : | | |
| | | |
| Uncategorized | MUST NOT | |
| Solicited Data | MUST NOT | |
| Unsolicited Control | REQUIRED | |
| Solicited Control | REQUIRED | |
| Unsolicited Data | REQUIRED | 1 |
| Data Descriptor | MUST NOT | |
| Unsolicited Command | MUST NOT | |
| Command Status | MUST NOT | |
+--------------------------------------------------------------------+
R_CTL in FC-Header: Word 0, bits 31-24
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| Information Category (R_CTL Routing): | | |
| | | |
| FC-4 Device Data | REQUIRED | 1 |
| Extended Link Data | REQUIRED | |
| FC-4 Link Data | MUST NOT | |
| Video Data | MUST NOT | |
| Basic Link Data | REQUIRED | |
| Link Control | REQUIRED | |
| | | |
| R_CTL information : | | |
| | | |
| Uncategorized | MUST NOT | |
| Solicited Data | MUST NOT | |
| Unsolicited Control | REQUIRED | |
| Solicited Control | REQUIRED | |
| Unsolicited Data | REQUIRED | 1 |
| Data Descriptor | MUST NOT | |
| Unsolicited Command | MUST NOT | |
| Command Status | MUST NOT | |
+--------------------------------------------------------------------+
Notes:
笔记：
1. This is REQUIRED for FC-4 (IP and ARP) packets
1. 这是FC-4（IP和ARP）数据包所必需的
- Routing bits of R_CTL field MUST indicate Device Data frames (0000) - Information Category of R_CTL field MUST indicate Unsolicited Data (0100)
- R_CTL字段的路由位必须指示设备数据帧（0000）-R_CTL字段的信息类别必须指示未经请求的数据（0100）
F_CTL in FC-Header: Word 2, bits 23-0
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| Exchange Context | Settable | |
| Sequence Context | Settable | |
| First / Last / End Sequence (FS/LS/ES) | Settable | |
| Chained Sequence | MUST NOT | |
| Sequence Initiative (SI) | Settable | 1 |
| X_ID Reassigned / Invalidate | MUST NOT | |
| Unidirectional Transmit | Settable | |
| Continue Sequence Condition | REQUIRED | 2 |
| Abort Seq. Condition -continue and single Seq.| REQUIRED | 3 |
| Relative Offset - Unsolicited Data | Settable | 4 |
| Fill Bytes | Settable | |
+--------------------------------------------------------------------+
F_CTL in FC-Header: Word 2, bits 23-0
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| Exchange Context | Settable | |
| Sequence Context | Settable | |
| First / Last / End Sequence (FS/LS/ES) | Settable | |
| Chained Sequence | MUST NOT | |
| Sequence Initiative (SI) | Settable | 1 |
| X_ID Reassigned / Invalidate | MUST NOT | |
| Unidirectional Transmit | Settable | |
| Continue Sequence Condition | REQUIRED | 2 |
| Abort Seq. Condition -continue and single Seq.| REQUIRED | 3 |
| Relative Offset - Unsolicited Data | Settable | 4 |
| Fill Bytes | Settable | |
+--------------------------------------------------------------------+
Notes
笔记
1. For FC-4 frames, each N_Port shall have a dedicated OX_ID for sending data to each N_Port in the network and a dedicated RX_ID for receiving data from each N_Port as well. Exchanges are used in a unidirectional mode, thus setting Sequence Initiative is not valid for FC-4 frames. Sequence Initiative is valid when using Extended Link Services.
1. 对于FC-4帧，每个N_端口应具有专用的OX_ID，用于向网络中的每个N_端口发送数据，以及专用的RX_ID，用于从每个N_端口接收数据。交换在单向模式下使用，因此设置序列主动性对FC-4帧无效。使用扩展链接服务时，序列主动性有效。
2. This field is required to be 00, no information.
2. 此字段要求为00，无信息。
3. Sequence error policy is requested by an exchange originator in the F_CTL Abort Sequence Condition bits in the first data frame of the exchange. For Classes 1 and 2, ACK frame is required to be "continuous sequence".
3. 序列错误策略由交换发起者在交换的第一个数据帧中的F_CTL Abort序列条件位中请求。对于1类和2类，ACK帧要求为“连续序列”。
4. Relative offset prohibited on all other types (Information Category) of frames.
4. 禁止在所有其他类型（信息类别）的帧上使用相对偏移。
+---------------------------------------------------------------------+
| Feature | Support |Notes |
+---------------------------------------------------------------------+
| Class 2 open Sequences / Exchange | 1 | 1 |
| Length of Seq. not limited by end-to-end credit | REQUIRED | 2 |
| IP and ARP Packet and FC Data Field sizes | REQUIRED | 3 |
| Capability to receive Sequence of maximum size | OPTIONAL | 4 |
| Sequence Streaming | MUST NOT | 5 |
| Stop Sequence Protocol | MUST NOT | |
| ACK_0 support | OPTIONAL | 6 |
| ACK_1 support | REQUIRED | 6 |
| ACK_N support | MUST NOT | |
| Class of Service for transmitted Sequences | Class | 7 |
| | 1, 2, or 3 | |
| Continuously Increasing Sequence Count | OPTIONAL | 8, 9 |
+---------------------------------------------------------------------+
+---------------------------------------------------------------------+
| Feature | Support |Notes |
+---------------------------------------------------------------------+
| Class 2 open Sequences / Exchange | 1 | 1 |
| Length of Seq. not limited by end-to-end credit | REQUIRED | 2 |
| IP and ARP Packet and FC Data Field sizes | REQUIRED | 3 |
| Capability to receive Sequence of maximum size | OPTIONAL | 4 |
| Sequence Streaming | MUST NOT | 5 |
| Stop Sequence Protocol | MUST NOT | |
| ACK_0 support | OPTIONAL | 6 |
| ACK_1 support | REQUIRED | 6 |
| ACK_N support | MUST NOT | |
| Class of Service for transmitted Sequences | Class | 7 |
| | 1, 2, or 3 | |
| Continuously Increasing Sequence Count | OPTIONAL | 8, 9 |
+---------------------------------------------------------------------+
Notes:
笔记：
1. Only one active sequence per exchange is optional.
1. 每个交换只有一个活动序列是可选的。
2. A Sequence Initiator shall be capable of transmitting Sequences containing more frames than the available credit indicated by a Sequence recipient at Login. FC-PH [2] end-to-end flow control rules will be followed when transmitting such Sequences.
2. 序列发起者应能够传输包含比序列接收者在登录时指示的可用信用更多帧的序列。传输此类序列时，将遵循FC-PH[2]端到端流量控制规则。
3. a) IP MTU size is 65280-bytes and resulting FC Sequence Payload size is 65536-bytes. b) Maximally Minimum IP Packet size is 68-bytes and resulting FC Data Field size is 92-bytes. c) ARP (and InARP) Packet size is 28-bytes and resulting FC Data Field size is 52-bytes.
3. a） IP MTU大小为65280字节，产生的FC序列有效负载大小为65536字节。b） 最大最小IP数据包大小为68字节，生成的FC数据字段大小为92字节。c） ARP（和InARP）数据包大小为28字节，生成的FC数据字段大小为52字节。
4. Some OS environments may not handle the max Sequence Payload size of 65536. It is up to the administrator to configure the Max size for all systems.
4. 某些操作系统环境可能无法处理最大序列有效负载大小65536。由管理员为所有系统配置最大大小。
5. All class 3 sequences are assumed to be non-streamed.
5. 假设所有3级序列均为非流式序列。
6. Only applies for Class 1 and 2. Use of ACK_1 is default, ACK_0 used if indicated by Sequence recipient at Login.
6. 仅适用于1级和2级。默认使用ACK_1，如果序列收件人在登录时指示，则使用ACK_0。
7. The administrator configured class of service is used, except where otherwise specified (e.g. Broadcasts are always sent in Class 3).
7. 使用管理员配置的服务类别，除非另有规定（例如，广播始终在类别3中发送）。
8. Review Appendix F, "Reliability in Class 3".
8. 审查附录F“3级可靠性”。
9. The first frame of the first sequence of a new Exchange must have SEQ_CNT = 0 [2].
9. 新交换的第一个序列的第一帧必须具有SEQ_CNT=0[2]。
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| X_ID interlock support | OPTIONAL | 1 |
| OX_ID=FFFF | MUST NOT | |
| RX_ID=FFFF | OPTIONAL | 2 |
| Action if no exchange resources available | P_RJT | 3 |
| Long Lived Exchanges | OPTIONAL | 4 |
| Reallocation of Idle Exchanges | OPTIONAL | |
+--------------------------------------------------------------------+
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| X_ID interlock support | OPTIONAL | 1 |
| OX_ID=FFFF | MUST NOT | |
| RX_ID=FFFF | OPTIONAL | 2 |
| Action if no exchange resources available | P_RJT | 3 |
| Long Lived Exchanges | OPTIONAL | 4 |
| Reallocation of Idle Exchanges | OPTIONAL | |
+--------------------------------------------------------------------+
Notes:
笔记：
1. Only applies to Classes 1 and 2, supported by the Exchange Originator. A Port SHALL be capable of interoperating with another Port that requires X_ID interlock. The Exchange Originator facility within the Port shall use the X_ID Interlock protocol in such cases.
1. 仅适用于由交易所发起人支持的类别1和类别2。一个端口应能够与另一个需要X_ID联锁的端口进行互操作。在这种情况下，港口内的交换发起人设施应使用X_ID联锁协议。
2. An Exchange Responder is not required to assign RX_IDs. If a RX_ID of FFFF is assigned, it is identifying Exchanges based on S_ID / D_ID / OX_ID only.
2. 交换应答器不需要分配RX_ID。如果分配了FFFF的RX_ID，则仅基于S_ID/D_ID/OX_ID识别交换。
3. In Classes 1 and 2, a Port shall reject a frame that would create a new Exchange with a P_RJT containing reason code "Unable to establish Exchange". In Class 3, the frame would be dropped.
3. 在第1类和第2类中，端口应拒绝使用包含原因码“无法建立交换”的P_RJT创建新交换的帧。在第3类中，框架将被丢弃。
4. When an Exchange is created between 2 Ports for IP/ARP data, it remains active while the ports are logged in with each other. An Exchange SHALL NOT transfer Sequence Initiative (SI). Broadcasts and ELS commands may use short lived Exchanges.
4. 当在两个端口之间为IP/ARP数据创建交换时，当端口彼此登录时，交换将保持活动状态。交易所不得转让序列倡议（SI）。广播和ELS命令可能使用短期交换。
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| ARP Server Support | MUST NOT | 1 |
| Response to ARP requests | REQUIRED | 2 |
| Class of Service for ARP requests | Class 3 | 3 |
| Class of Service for ARP replies | Class | 4 |
| | 1, 2, or 3 | |
| Response to InARP requests | OPTIONAL | |
| Class of Service for InARP requests/replies | Class | |
| | 1, 2 or 3 | 5 |
+--------------------------------------------------------------------+
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| ARP Server Support | MUST NOT | 1 |
| Response to ARP requests | REQUIRED | 2 |
| Class of Service for ARP requests | Class 3 | 3 |
| Class of Service for ARP replies | Class | 4 |
| | 1, 2, or 3 | |
| Response to InARP requests | OPTIONAL | |
| Class of Service for InARP requests/replies | Class | |
| | 1, 2 or 3 | 5 |
+--------------------------------------------------------------------+
Notes:
笔记：
1. Well-known Address FFFFFC is not used for ARP requests. Frames from Well-known address FFFFFC are not considered to be ARP frames. Broadcast support is REQUIRED for ARP.
1. 众所周知的地址FFF C不用于ARP请求。来自已知地址FFF C的帧不被视为ARP帧。ARP需要广播支持。
2. The IP Address is mapped to a specific MAC address with ARP.
2. IP地址通过ARP映射到特定的MAC地址。
3. An ARP request is a Broadcast Sequence, therefore Class 3 is always used.
3. ARP请求是一个广播序列，因此总是使用类别3。
4. An ARP reply is a normal Sequence, thus the administrator configured class of service is used.
4. ARP应答是正常的序列，因此使用管理员配置的服务类。
5. An InARP Request or Reply is a normal Sequence, thus an administrator configured class of service is used.
5. INAP请求或应答是正常的序列，因此使用管理员配置的服务类。
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| Class of service for ELS commands / responses | Class | |
| | 1,2 or 3 | 1 |
| Explicit N-Port Login | REQUIRED | |
| Explicit F-Port Login | REQUIRED | |
| FLOGI ELS command | REQUIRED | |
| PLOGI ELS command | REQUIRED | |
| ADISC ELS command | REQUIRED | |
| PDISC ELS command | OPTIONAL | 2 |
| FAN ELS command | REQUIRED | 5 |
| LOGO ELS command | REQUIRED | |
| FARP-REQ/FARP-REPLY ELS commands | REQUIRED | 3 |
| Other ELS command support | OPTIONAL | 4 |
+-----------------------------------------------+------------+-------+
+--------------------------------------------------------------------+
| Feature | Support | Notes |
+--------------------------------------------------------------------+
| Class of service for ELS commands / responses | Class | |
| | 1,2 or 3 | 1 |
| Explicit N-Port Login | REQUIRED | |
| Explicit F-Port Login | REQUIRED | |
| FLOGI ELS command | REQUIRED | |
| PLOGI ELS command | REQUIRED | |
| ADISC ELS command | REQUIRED | |
| PDISC ELS command | OPTIONAL | 2 |
| FAN ELS command | REQUIRED | 5 |
| LOGO ELS command | REQUIRED | |
| FARP-REQ/FARP-REPLY ELS commands | REQUIRED | 3 |
| Other ELS command support | OPTIONAL | 4 |
+-----------------------------------------------+------------+-------+
Notes:
笔记：
1. The administrator configured class of service is used.
1. 使用管理员配置的服务类。
2. PDISC shall not be used as a Requester; ADISC shall be used instead. As a Responder, an implementation may need to respond to both ADISC and PDISC for compatibility with other specifications.
2. PDISC不得用作请求者；应改用ADISC。作为响应者，实现可能需要同时响应ADISC和PDISC以与其他规范兼容。
3. Responder Action - FARP-REPLY and/or Port Login - for a successful MATCH_WW_PN is always REQUIRED. Support for all other match Address Codes Points is a silent behavior from the Responder is valid when it is not supported. Recipients of the FARP-REQ ELS shall not issue a Service Reject (LS_RJT) if FARP is not supported.
3. 响应程序操作-FARP-REPLY和/或端口登录-始终需要成功匹配WW PN。对所有其他匹配地址代码点的支持是一种静默行为，响应程序在不支持时有效。如果FARP不受支持，FARP-REQ ELS的接收者不得发出服务拒绝（LS_RJT）。
4. If other ELS commands are received an LS_RJT may be sent. NOP is not required by this specification, and shall not be used as a mechanism to terminate exchanges.
4. 如果收到其他ELS命令，则可能会发送LS_RJT。本规范不要求NOP，且不得将其用作终止交换的机制。
5. Required for FL_Ports
5. FL_端口需要
Unless explicitly noted here, a compliant implementation shall use the login parameters as described in [4].
除非此处明确说明，否则符合要求的实现应使用[4]中所述的登录参数。
- FC-PH Version, lowest version may be 0x09 to indicate 'minimum 4.3'. - Can't use BB_Credit=0 for N_Port on a switched Fabric (F_Port).
- FC-PH版本，最低版本可能为0x09，表示“最低4.3”。-无法将BB_Credit=0用于交换结构（F_端口）上的N_端口。
- FC-PH Version, lowest version may be 0x09 to indicate 'minimum 4.3'. - Can't use BB_Credit=0 for N_Port in a Point-to-Point configuration
- FC-PH版本，最低版本可能为0x09，表示“最低4.3”。-在点到点配置中，无法将BB_Credit=0用于N_端口
- Random Relative Offset is optional.
- 随机相对偏移是可选的。
- Note that the 'Receive Data Field Size' fields specified in the PLOGI represent both optional headers and payload.
- 请注意，PLOGI中指定的“接收数据字段大小”字段表示可选标头和有效负载。
- The MAC Address can therefore be extracted from the 6 lower bytes of the WW_PN field (when the IEEE 48-bit Identifier format is chosen as the NAA) during PLOGI or ACC payload exchanged during Fibre Channel Login [2].
- 因此，在光纤通道登录期间交换PLOGI或ACC有效负载期间，可以从WW_PN字段的6个较低字节中提取MAC地址（当IEEE 48位标识符格式被选择为NAA时）[2]。
- The MAC Address can also be extracted from the WW_PN field in the Network_Header during ADISC (and ADISC ACC), or PDISC (and PDISC ACC).
- 在ADISC（和ADISC ACC）或PDISC（和PDISC ACC）期间，还可以从网络_报头中的WW_PN字段提取MAC地址。
- Discard error policy only.
- 仅放弃错误策略。
IP and ARP do not introduce any new security concerns beyond what already exists within the Fibre Channel Protocols and Technology. Therefore IP and ARP related Security does not require special consideration in this document.
除了光纤通道协议和技术中已经存在的安全问题外，IP和ARP不会引入任何新的安全问题。因此，本文件不需要特别考虑IP和ARP相关的安全性。
FC Standards [11] specify a Security Key Server (independent of IP and ARP) as an optional service. However, there are no known implementations of this server yet. Also, the previously defined [2] use of a Security Header has been discontinued [11].
FC标准[11]将安全密钥服务器（独立于IP和ARP）指定为可选服务。但是，目前还没有该服务器的已知实现。此外，先前定义的[2]安全标头的使用已经停止[11]。
This specification is based on FCA IP Profile, Version 3.3. The FCA IP Profile was a joint work of the Fibre Channel Association (FCA) vendor community. The following organizations or individuals have contributed to the creation of the FCA IP Profile: Adaptec, Ancor, Brocade, Clariion, Crossroads, emf Associates, Emulex, Finisar, Gadzoox, Hewlett Packard, Interphase, Jaycor, McData, Migration Associates, Orca Systems, Prisa, Q-Logic, Symbios, Systran, Tektronix, Univ. of Minnesota, Univ. of New Hamshire. Jon Infante from Emulex deserves special mention for his contributions to the FARP Protocol. The authors extend their thanks to all who provided comments and especially to Lansing Sloan from LLNL for his detailed comments.
本规范基于FCA IP配置文件3.3版。FCA IP配置文件是光纤通道协会（FCA）供应商团体的联合工作。以下组织或个人为FCA IP配置文件的创建做出了贡献：Adaptec、Ancor、Brocade、Clariion、Crossroads、emf Associates、Emulex、Finisar、Gadzoox、Hewlett-Packard、Interphase、Jaycor、McData、Migration Associates、Orca Systems、Prisa、Q-Logic、Symbios、Systran、Tektronix、明尼苏达大学、，新罕布什尔大学。Emulex公司的Jon Infante对FARP协议的贡献值得特别提及。作者感谢所有提供评论的人，特别是LLNL的兰辛·斯隆，感谢他详细的评论。
[1] FCA IP Profile, Revision 3.3, May 15, 1997
[1] FCA IP概要，第3.3版，1997年5月15日
[2] Fibre Channel Physical and Signaling Interface (FC-PH) , ANSI X3.230-1994
[2] 光纤通道物理和信令接口（FC-PH），ANSI X3.230-1994
[3] Fibre Channel Link Encapsulation (FC-LE), Revision 1.1, June 26, 1996
[3] 光纤通道链路封装（FC-LE），版本1.11996年6月26日
[4] Fibre Channel Fabric Loop Attachment (FC-FLA), Rev. 2.7, August 12, 1997
[4] 光纤通道结构环路连接（FC-FLA），修订版。一九九七年八月十二日（星期二）
[5] Fibre Channel Private Loop SCSI Direct Attach (FC-PLDA), Rev. 2.1, September 22, 1997
[5] 光纤通道专用环路SCSI直接连接（FC-PLDA），修订版。1997年9月22日，星期二
[6] Fibre Channel Physical and Signaling Interface-2 (FC-PH-2), Rev. 7.4, ANSI X3.297-1996
[6] 光纤通道物理和信令接口-2（FC-PH-2），修订版。7.4，ANSI X3.297-1996
[7] Fibre Channel Arbitrated Loop (FC-AL), ANSI X3.272-1996
[7] 光纤通道仲裁环路（FC-AL），ANSI X3.272-1996
[8] Postel, J. and J. Reynolds, "A standard for the Transmission of IP Datagrams over IEEE 802 Networks", STD 43, RFC 1042, February 1988.
[8] Postel，J.和J.Reynolds，“通过IEEE 802网络传输IP数据报的标准”，STD 43，RFC 1042，1988年2月。
[9] Plummer, D. "An Ethernet Address Resolution Protocol -or-Converting Network Addresses to 48-bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[9] Plummer，D.“以太网地址解析协议-或将网络地址转换为48位以太网地址以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[10] FCSI IP Profile, FCSI-202, Revision 2.1, September 8, 1995
[10] FCSI IP概要，FCSI-202，第2.1版，1995年9月8日
[11] Fibre Channel Physical and Signaling Interface -3 (FC-PH-3), Rev. 9.3, ANSI X3.303-199x
[11] 光纤通道物理和信令接口-3（FC-PH-3），修订版。9.3，ANSI X3.303-199x
[12] Fibre Channel-The Basics, "Gary R. Stephens and Jan V. Dedek", Ancot Corporation
[12] 光纤通道基础，“Gary R.Stephens和Jan V.Dedek”，安科公司
[13] Fibre Channel -Gigabit Communications and I/O for Computers Networks "Alan Benner", McGraw-Hill, 1996, ISBN 0-07-005669-2
[13] 光纤通道-计算机网络的千兆位通信和I/O“Alan Benner”，麦格劳·希尔，1996年，ISBN 0-07-005669-2
[14] Fibre Channel Generic Services -2 (FC-GS-2), Rev. 5.2 X3.288-199x
[14] 光纤通道通用服务-2（FC-GS-2），修订版。5.2 X3.288-199x
[15] Bradley, T. and C. Brown, "Inverse Address Resolution Protocol", RFC 1293, January 1992.
[15] Bradley，T.和C.Brown，“反向地址解析协议”，RFC 1293，1992年1月。
[16] Bradley, T., Brown, C. and A. Malis, "Inverse Address Resolution Protocol", RFC 2390, August 1992.
[16] Bradley，T.，Brown，C.和A.Malis，“反向地址解析协议”，RFC 23901992年8月。
[17] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[17] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[18] The Fibre Channel Consultant: A Comprehensive Introduction, "Robert W. Kembel", Northwest Learning Associates, 1998
[18] 光纤通道顾问：全面介绍，“Robert W.Kembel”，西北学习协会，1998年
[19] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[19] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[20] Narten, T. and C. Burton, "A Caution on The Canonical Ordering of Link-Layer Addresses", RFC 2469, December 1998.
[20] Narten，T.和C.Burton，“链路层地址规范排序的注意事项”，RFC 2469，1998年12月。
Murali Rajagopal Gadzoox Networks, Inc. 711 Kimberly Avenue, Suite 100 Placentia, CA 92870
Murali Rajagopal Gadzoox Networks，Inc.加利福尼亚州金伯利大道711号Placentia 100号套房，邮编92870
Phone: +1 714 577 6805
Fax: +1 714 524 8508
EMail: murali@gadzoox.com
Phone: +1 714 577 6805
Fax: +1 714 524 8508
EMail: murali@gadzoox.com
Raj Bhagwat Gadzoox Networks, Inc. 711 Kimberly Avenue, Suite 100 Placentia, CA 92870
Raj Bhagwat Gadzoox Networks，Inc.加利福尼亚州金伯利大道711号Placentia 100号套房，邮编92870
Phone: +1 714 577 6806
Fax: +1 714 524 8508
EMail: raj@gadzoox.com
Phone: +1 714 577 6806
Fax: +1 714 524 8508
EMail: raj@gadzoox.com
Wayne Rickard Gadzoox Networks, Inc. 711 Kimberly Avenue, Suite 100 Placentia, CA 92870
Wayne Rickard Gadzoox Networks，Inc.加利福尼亚州普莱森蒂亚金伯利大道711号100室，邮编92870
Phone: +1 714 577 6803
Fax: +1 714 524 8508
EMail: wayne@gadzoox.com
Phone: +1 714 577 6803
Fax: +1 714 524 8508
EMail: wayne@gadzoox.com
Appendix A: Additional Matching Mechanisms in FARP
附录A：FARP中的其他匹配机制
Section 5 described the FC Layer mapping between the WW_PN and the Port_ID using the FARP Protocol. This appendix describes other optional criteria for address matching and includes:
第5节描述了使用FARP协议在WW_PN和端口ID之间的FC层映射。本附录描述了地址匹配的其他可选标准，包括：
- WW_NN
- 韦恩
- WW_PN & WW_NN at the same time
- WW_PN和WW_NN同时出现
- IPv4
- IPv4
- IPv4 & WW_PN at the same time
- IPv4和WWU PN同时存在
- IPv4 & WW_NN at the same time
- IPv4和WW_NN同时使用
- IPv4 & WW_PN & WW_NN at the same time
- IPv4和WW_PN和WW_NN同时使用
Depending on the Match Address Code Points, the FARP protocol fundamentally resolves three main types of addresses to Port_IDs and is described in table below.
根据匹配地址代码点，FARP协议从根本上将三种主要类型的地址解析为端口ID，如下表所述。
- For Match Address Code Point b'001': WW_PN Names fields are used to resolve the WW_PN names to Port_IDs. WW_NN and IP address fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder.
- 对于匹配地址代码点b'001'：WW_PN名称字段用于将WW_PN名称解析为端口ID。WW_NN和IP地址字段不与这些代码点一起使用，请求者或请求者和响应者应将其设置为“0”或有效地址。
- For Match Address Code Point b'010': WW_NN Names fields are used to resolve the WW_NN names to Port_IDs. WW_PN and IP address fields are not used with these Code Points and SHALL be set to either '0' or valid addresses by Requester or Requester and Responder.
- 对于匹配地址代码点b'010'：WW_NN名称字段用于将WW_NN名称解析为端口ID。WW_PN和IP地址字段不与这些代码点一起使用，请求者或请求者和响应者应将其设置为“0”或有效地址。
- For Match Address Code Point b'100': IPv4 fields are used to resolve the IPv4 addresses to Port_IDs. WW_PN and WW_NN fields are not used with these Code Points and SHALL be set to either ' 0' or valid addresses by Requester or Requester and Responder.
- 对于匹配地址代码点b'100'：IPv4字段用于将IPv4地址解析为端口ID。WW_PN和WW_NN字段不与这些代码点一起使用，请求者或请求者和响应者应将其设置为“0”或有效地址。
- For all other Match Address Code Points b'011', b'101',b'110', b'111', depending on set bits one or more addresses are jointly resolved to a Port_ID. See table below. If fields are not used, then they are set either to '0' or valid addresses.
- 对于所有其他匹配地址代码点b'011'，b'101'，b'110'，b'111'，根据设置位，一个或多个地址共同解析为端口ID。见下表。如果未使用字段，则将其设置为“0”或有效地址。
The Responder Flags remain the same as before. Note that there can be utmost one FARP-REPLY per FARP-REQ.
响应程序标志与以前相同。请注意，每个FARP-REQ最多只能有一个FARP-REPLY。
Tables showing FARP-REQ and FARP-REPLY and address fields setting are given below:
下面给出了显示FARP-REQ和FARP-REPLY以及地址字段设置的表格：
+--------------------------------------------------------------------+
| Match Address Code Points |
+--------------------------------------------------------------------+
| LSBits| Bit name | Action |
+-------+--------------------+---------------------------------------+
| 000 | Reserved | |
+-------+--------------------+---------------------------------------+
| 001 | MATCH_WW_PN | If 'WW_PN of Responder' = |
| | | Node's WW_PN then respond |
+-------+--------------------+---------------------------------------+
| 010 | MATCH_WW_NN | If 'WW_NN of Responder' = |
| | | Node's WW_NN then respond |
+-------+--------------------+---------------------------------------+
| 011 | MATCH_WW_PN_NN | If both 'WW_PN of Responder' & |
| | | 'WW_NN of Responder' = |
| | | Node's WW_PN & WW_NN then respond |
+-------+--------------------+---------------------------------------+
| 100 | MATCH_IPv4 | If 'IPv4 Address of Responder' = |
| | | Node's IPv4 Address then respond |
+-------+--------------------+---------------------------------------+
| 101 | MATCH_WW_PN_IPv4 | If 'WW_PN & IPv4 of Responder' = |
| | | Node's WW_PN and IPv4 then respond |
+-------+--------------------+---------------------------------------+
| 110 | MATCH_WW_NN_IPv4 | If both 'WW_NN of Responder' & |
| | | 'IPv4 Address of Responder' = |
| | | Node's WW_NN & IPv4 then respond |
+-------+--------------------+---------------------------------------+
| 111 |MATCH_WW_PN_NN_IPv4 | If 'WW_PN of Responder' & |
| | | 'WW_NN of Responder' & |
| | | 'IPv4 Address of Responder' = |
| | | Nodes' WW_PN & WW_NN & IPv4 |
| | | then respond |
+-------+--------------------+---------------------------------------+
+--------------------------------------------------------------------+
| Match Address Code Points |
+--------------------------------------------------------------------+
| LSBits| Bit name | Action |
+-------+--------------------+---------------------------------------+
| 000 | Reserved | |
+-------+--------------------+---------------------------------------+
| 001 | MATCH_WW_PN | If 'WW_PN of Responder' = |
| | | Node's WW_PN then respond |
+-------+--------------------+---------------------------------------+
| 010 | MATCH_WW_NN | If 'WW_NN of Responder' = |
| | | Node's WW_NN then respond |
+-------+--------------------+---------------------------------------+
| 011 | MATCH_WW_PN_NN | If both 'WW_PN of Responder' & |
| | | 'WW_NN of Responder' = |
| | | Node's WW_PN & WW_NN then respond |
+-------+--------------------+---------------------------------------+
| 100 | MATCH_IPv4 | If 'IPv4 Address of Responder' = |
| | | Node's IPv4 Address then respond |
+-------+--------------------+---------------------------------------+
| 101 | MATCH_WW_PN_IPv4 | If 'WW_PN & IPv4 of Responder' = |
| | | Node's WW_PN and IPv4 then respond |
+-------+--------------------+---------------------------------------+
| 110 | MATCH_WW_NN_IPv4 | If both 'WW_NN of Responder' & |
| | | 'IPv4 Address of Responder' = |
| | | Node's WW_NN & IPv4 then respond |
+-------+--------------------+---------------------------------------+
| 111 |MATCH_WW_PN_NN_IPv4 | If 'WW_PN of Responder' & |
| | | 'WW_NN of Responder' & |
| | | 'IPv4 Address of Responder' = |
| | | Nodes' WW_PN & WW_NN & IPv4 |
| | | then respond |
+-------+--------------------+---------------------------------------+
+---------------------------------------------------------------------+
| FARP-REQ Command |
+-------------------------------+---------+---------------------------+
| Field | Size | Remarks |
| | (Bytes) | |
+-------------------------------+---------+---------------------------+
| 0x54-00-00-00 | 4 | Request Command Code |
+-------------------------------+---------+---------------------------+
| Match Address Code Points | 1 | Indicates Address |
| | | Matching Mechanism |
+-------------------------------+---------+---------------------------+
| Port_ID of Requester | 3 |Supplied by Requester |
+-------------------------------+---------+---------------------------+
| Responder Flags | 1 |Response Action to be taken|
+-------------------------------+---------+---------------------------+
| Port_ID of Responder | 3 | Set to 0x00-00-00 |
+-------------------------------+---------+---------------------------+
|WW_PN of Requester | 8 | Supplied by Requester |
+-------------------------------+---------+---------------------------+
|WW_NN of Requester | 8 |OPTIONAL; |
| | |Supplied by Requester |
+-------------------------------+---------+---------------------------+
|WW_PN of Responder | 8 |Supplied by Requester |
+-------------------------------+---------+---------------------------+
|WW_NN of Responder | 8 |OPTIONAL ;Supplied by |
| | |Requester or Responder |
+-------------------------------+---------+---------------------------+
|IP Add. of Requester | 16 |OPTIONAL; Supplied by |
| | |Requester |
| | |IPv4 Add.=low 32 bits |
+-------------------------------+---------+---------------------------+
|IP Address of Responder | 16 |OPTIONAL; Supplied by |
| | |Requester or Responder |
| | |IPv4 Add.=low 32 bits |
+-------------------------------+---------+---------------------------+
+---------------------------------------------------------------------+
| FARP-REQ Command |
+-------------------------------+---------+---------------------------+
| Field | Size | Remarks |
| | (Bytes) | |
+-------------------------------+---------+---------------------------+
| 0x54-00-00-00 | 4 | Request Command Code |
+-------------------------------+---------+---------------------------+
| Match Address Code Points | 1 | Indicates Address |
| | | Matching Mechanism |
+-------------------------------+---------+---------------------------+
| Port_ID of Requester | 3 |Supplied by Requester |
+-------------------------------+---------+---------------------------+
| Responder Flags | 1 |Response Action to be taken|
+-------------------------------+---------+---------------------------+
| Port_ID of Responder | 3 | Set to 0x00-00-00 |
+-------------------------------+---------+---------------------------+
|WW_PN of Requester | 8 | Supplied by Requester |
+-------------------------------+---------+---------------------------+
|WW_NN of Requester | 8 |OPTIONAL; |
| | |Supplied by Requester |
+-------------------------------+---------+---------------------------+
|WW_PN of Responder | 8 |Supplied by Requester |
+-------------------------------+---------+---------------------------+
|WW_NN of Responder | 8 |OPTIONAL ;Supplied by |
| | |Requester or Responder |
+-------------------------------+---------+---------------------------+
|IP Add. of Requester | 16 |OPTIONAL; Supplied by |
| | |Requester |
| | |IPv4 Add.=low 32 bits |
+-------------------------------+---------+---------------------------+
|IP Address of Responder | 16 |OPTIONAL; Supplied by |
| | |Requester or Responder |
| | |IPv4 Add.=low 32 bits |
+-------------------------------+---------+---------------------------+
+---------------------------------------------------------------------+
| FARP-REPLY Command |
+-------------------------------+---------+---------------------------+
| Field | Size | Remarks |
| | (Bytes) | |
+-------------------------------+---------+---------------------------+
| 0x55-00-00-00 | 4 |Reply Command Code |
+-------------------------------+---------+---------------------------+
| Match Address Code Points | 1 | Not Used and unchanged |
| | |from the FARP-REQ |
+-------------------------------+---------+---------------------------+
| Port_ID of Requester | 3 |Supplied by Requester |
+-------------------------------+---------+---------------------------+
| Responder Flags | 1 | Not Used and unchanged |
| | |from the FARP-REQ |
+-------------------------------+---------+---------------------------+
| Port_ID of Responder | 3 |Supplied by Responder |
+-------------------------------+---------+---------------------------+
|WW_PN of Requester | 8 |Supplied by Requester |
+-------------------------------+---------+---------------------------+
|WW_NN of Requester | 8 |OPTIONAL; Supplied by |
| | |Requester |
+-------------------------------+---------+---------------------------+
|WW_PN of Responder | 8 |Supplied by Requester |
+-------------------------------+---------+---------------------------+
|WW_NN of Responder | 8 |OPTIONAL; Supplied by |
| | |Requester or Responder |
+-------------------------------+---------+---------------------------+
|IP Add. of Requester | 16 |OPTIONAL; Supplied by |
| | |Requester |
| | |IPv4 Add.=low 32 bits |
+-------------------------------+---------+---------------------------+
|IP Address of Responder | 16 |OPTIONAL; Supplied by |
| | |Requester or Responder |
| | |IPv4 Add.=low 32 bits |
+-------------------------------+---------+---------------------------+
+---------------------------------------------------------------------+
| FARP-REPLY Command |
+-------------------------------+---------+---------------------------+
| Field | Size | Remarks |
| | (Bytes) | |
+-------------------------------+---------+---------------------------+
| 0x55-00-00-00 | 4 |Reply Command Code |
+-------------------------------+---------+---------------------------+
| Match Address Code Points | 1 | Not Used and unchanged |
| | |from the FARP-REQ |
+-------------------------------+---------+---------------------------+
| Port_ID of Requester | 3 |Supplied by Requester |
+-------------------------------+---------+---------------------------+
| Responder Flags | 1 | Not Used and unchanged |
| | |from the FARP-REQ |
+-------------------------------+---------+---------------------------+
| Port_ID of Responder | 3 |Supplied by Responder |
+-------------------------------+---------+---------------------------+
|WW_PN of Requester | 8 |Supplied by Requester |
+-------------------------------+---------+---------------------------+
|WW_NN of Requester | 8 |OPTIONAL; Supplied by |
| | |Requester |
+-------------------------------+---------+---------------------------+
|WW_PN of Responder | 8 |Supplied by Requester |
+-------------------------------+---------+---------------------------+
|WW_NN of Responder | 8 |OPTIONAL; Supplied by |
| | |Requester or Responder |
+-------------------------------+---------+---------------------------+
|IP Add. of Requester | 16 |OPTIONAL; Supplied by |
| | |Requester |
| | |IPv4 Add.=low 32 bits |
+-------------------------------+---------+---------------------------+
|IP Address of Responder | 16 |OPTIONAL; Supplied by |
| | |Requester or Responder |
| | |IPv4 Add.=low 32 bits |
+-------------------------------+---------+---------------------------+
Appendix B: InARP
附录B：InARP
Inverse ARP (InARP) is a mechanism described in RFC 1293/2390 [15, 16], which is useful when a node desires to know the protocol address of a target node whose hardware address is known. Situations where this could occur are described in [15, 16]. The motivation for using InARP in FC is to allow a node to learn the IP address of another node with which it has performed a Port Login (PLOGI). PLOGI is a normal FC process that happens between nodes, independent of this standard. PLOGI makes it possible for a node to discover the WW_PN and the Port_ID of the other node but not its IP address. A node in this way may potentially obtain the IP address of all nodes with which it can PLOGI.
反向ARP（InARP）是RFC 1293/2390[15,16]中描述的一种机制，当节点希望知道其硬件地址已知的目标节点的协议地址时，该机制非常有用。[15,16]中描述了可能发生这种情况的情况。在FC中使用InARP的动机是允许一个节点了解另一个节点的IP地址，该节点已使用该地址执行端口登录（PLOGI）。PLOGI是在节点之间发生的正常FC进程，与此标准无关。PLOGI使一个节点能够发现另一个节点的WW_PN和端口ID，但不能发现其IP地址。通过这种方式，一个节点可能获得它可以使用的所有节点的IP地址。
Note that the use of the InARP mechanism can result in resolving all WW_PN to IP addresses and ARP may no longer be required. This can be beneficially applied in cases where a particular FC topology makes it inefficient to send out an ARP broadcast.
请注意，使用INAP机制可能导致将所有WW_PN解析为IP地址，并且可能不再需要ARP。这可以有益地应用于特定FC拓扑使得发送ARP广播效率低下的情况。
InARP uses the same ARP Packet format but with different 'Op Codes', one for InARP Request and another for InARP Reply.
INRAP使用相同的ARP数据包格式，但具有不同的“操作码”，一个用于INRAP请求，另一个用于INRAP应答。
The InARP protocol operation is very simple. The requesting node fills the hardware address (WW_PN) of the target device and sets the protocol address to 0x00-00-00-00. Because, the request is sent to a node whose WW_PN and Port_ID are known, there is no need for a broadcast. The target node fills in its Protocol address (IP address in this case) and sends an InARP Reply back to the sender. A node may collect, all such WW_PN and IP addresses pairs in a similar way.
InARP协议操作非常简单。请求节点填写目标设备的硬件地址（WW_PN），并将协议地址设置为0x00-00-00-00。因为请求被发送到WW_PN和端口ID已知的节点，所以不需要广播。目标节点填写其协议地址（本例中为IP地址），并向发送方发送INAP回复。节点可以以类似的方式收集所有此类WW_PN和IP地址对。
Since the InARP protocol uses the same packet format as the ARP protocol, much of the discussion on ARP formats given in Section 4 applies here.
由于InARP协议使用与ARP协议相同的数据包格式，因此第4节中对ARP格式的大部分讨论适用于此。
The InARP is 28-bytes long in this application and uses two packet types: Request and Reply. Like ARP, the InARP Packet fields are common to both InARP Requests and InARP Replies.
在这个应用程序中，INRAP的长度为28字节，使用两种数据包类型：请求和应答。与ARP一样，INRAP数据包字段对于INRAP请求和INRAP回复都是通用的。
InARP Request and Reply Packets are encapsulated in a single frame FC Sequence much like ARP. Compliant InARP Request and Reply FC Sequences SHALL include Network_Headers.
InARP请求和应答数据包被封装在单帧FC序列中，与ARP非常相似。符合要求的InARP请求和应答FC序列应包括网络头。
The 'HW Type' field SHALL be set to 0x00-01.
“HW类型”字段应设置为0x00-01。
The 'Protocol' field SHALL be set to 0x08-00 indicating IP protocol.
“协议”字段应设置为0x08-00，表示IP协议。
The 'HW Addr Length' field SHALL be set to 0x06 indicating 6-bytes of HW address.
“硬件地址长度”字段应设置为0x06，表示6字节的硬件地址。
The 'Protocol Addr Length' field SHALL be set to 0x04 indicating 4-bytes of IP address.
“协议地址长度”字段应设置为0x04，表示4字节的IP地址。
The 'Operation' Code field SHALL be set as follows:
“操作”代码字段应设置如下：
0x00-08 for InARP Request 0x00-09 for InARP Reply
0x00-08用于INAP请求0x00-09用于INAP回复
The 'HW Addr of Sender' field SHALL be the 6-byte IEEE MAC address of the Requester (InARP Request) or Responder (InARP Reply).
“发送方的HW地址”字段应为请求方（InARP请求）或响应方（InARP回复）的6字节IEEE MAC地址。
The 'Protocol Addr of Sender' field SHALL be the 4-byte IP address of the Requester (InARP Request) or Responder (InARP Reply).
“发送方的协议地址”字段应为请求方（InARP请求）或响应方（InARP回复）的4字节IP地址。
The 'HW Addr of Target' field SHALL be set to the 6-byte MAC address of the Responder in an InARP Request and to the 6-byte MAC address of the Requester in an InARP Reply.
“HW Addr of Target”字段应设置为InARP请求中响应者的6字节MAC地址，以及InARP应答中请求者的6字节MAC地址。
The 'Protocol Addr of Target' field SHALL be set to 0x00-00-00-00 in an InARP Request and to the 4-byte IP address of the Requester in an InARP Reply.
在InARP请求中，“目标的协议地址”字段应设置为0x00-00-00-00，在InARP回复中应设置为请求者的4字节IP地址。
Support for InARP is OPTIONAL. If a node does not support InARP and it receives an InARP Request message then a silent behavior is specified.
对InARP的支持是可选的。如果节点不支持InARP，并且收到InARP请求消息，则指定静默行为。
APPENDIX C: Some Informal Mechanisms for FC Layer Mappings
附录C：FC层映射的一些非正式机制
Each method SHALL have some check to ensure PLOGI has completed successfully before data is sent. A related concern in large networks is limiting concurrent logins to only those ports with active IP traffic.
每种方法都应进行一些检查，以确保在发送数据之前PLOGI已成功完成。大型网络中的一个相关问题是，仅将并发登录限制在具有活动IP流量的端口。
This method insulates the level performing Login from the level interpreting ARP. It is more accommodating of non-ARP mechanisms for building the FC-layer mapping table.
此方法将执行登录的级别与解释ARP的级别隔离开来。在构建FC层映射表时，它更适合非ARP机制。
1. Broadcast messages that carry a Network_Header contain the S_ID on the FC-header and WW_PN in the Network-Header. Caching this information provides a correlation of Port_ID to WW_PN. If the received Broadcast message is compliant with this specification, the WW_PN will contain the MAC Address.
1. 带有网络头的广播消息包含FC头上的S\U ID和网络头中的WW\U PN。缓存此信息可提供端口ID与WW\U PN的关联。如果接收到的广播消息符合此规范，WW_PN将包含MAC地址。
2. The WW_PN is "available" if Login has been performed to the Port_ID and flagged. If Login has not been performed, the WW_PN is "unavailable".
2. 如果对端口ID进行了登录并进行了标记，则WWU PN“可用”。如果未执行登录，则WW_PN“不可用”。
3. If an outbound packet is destined for a port that is "unavailable", the cached information (from broadcast) is used to look up the Port_ID.
3. 如果出站数据包的目的地是“不可用”的端口，则缓存的信息（来自广播）用于查找端口ID。
4. After sending an ELS PLOGI command (Port Login) to the Port (from a higher level entity at the host), waiting for an outbound packet before sending this Port Login conserves resources for only those ports which wish to establish communication.
4. 在向端口发送ELS PLOGI命令（端口登录）后（从主机上的更高级别实体），在发送此端口登录之前等待出站数据包只会为希望建立通信的端口节省资源。
5. After Port Login completes (ACC received), the outbound packet can be forwarded. At this point in time, both ends have the necessary information to complete their <IP address, MAC Address, Port_ID> association.
5. 端口登录完成（ACC接收）后，可以转发出站数据包。此时，两端都有必要的信息来完成其<IP地址、MAC地址、端口ID>关联。
This method performs Login sooner by parsing ARP before passing it up to higher levels for IP/MAC Address correlation. It requires a low-level awareness of the IP address, and is therefore protocol-specific.
此方法通过解析ARP，然后将其传递到更高级别以进行IP/MAC地址关联，从而更快地执行登录。它需要对IP地址的低级别感知，因此是特定于协议的。
1. When an ARP Broadcast Message is received, the S_ID is extracted from the FC-header and the corresponding Network_Source_Address from the Network_Header.
1. 当接收到ARP广播消息时，将从FC报头提取S_ID，并从网络_报头提取相应的网络_源_地址。
2. The ARP payload is parsed to determine if (a) this host is the target of the ARP request (Target IP Address match), and (b) if this host is currently logged in with the port (Port_ID = S_ID) originating the ARP broadcast.
2. 解析ARP有效负载以确定（a）此主机是否为ARP请求的目标（目标IP地址匹配），以及（b）此主机当前是否使用发起ARP广播的端口（端口ID=S_ID）登录。
3. The ARP is passed to a higher level for ARP Response generation.
3. ARP被传递到更高级别以生成ARP响应。
4. If a Port Login is required, an ELS PLOGI command (Port Login) is sent immediately to the Port originating the ARP Broadcast.
4. 如果需要端口登录，将立即向发起ARP广播的端口发送ELS PLOGI命令（端口登录）。
5. After Port Login completes, an ARP response can be forwarded. Note that there are two possible scenarios:
5. 端口登录完成后，可以转发ARP响应。请注意，有两种可能的情况：
- The ACC to PLOGI returns before the ARP reply is processed and the ARP Reply is immediately forwarded. - The ARP reply is delayed, waiting for ACC (successful Login).
- ACC to PLOGI在处理ARP回复之前返回，ARP回复立即转发。-ARP回复延迟，等待ACC（成功登录）。
6. At this point in time, both ends have the necessary information to complete their <IP address, MAC Address, Port_ID> association.
6. 此时，两端都有必要的信息来完成其<IP地址、MAC地址、端口ID>关联。
In Fibre Channel topologies with a limited number of ports, it may be efficient to unconditionally Login to each port. This method is discouraged in fabric and public loop environments.
在端口数量有限的光纤通道拓扑中，无条件登录到每个端口可能是有效的。在结构和公共循环环境中不鼓励使用此方法。
After Port Login completes, the MAC Address to Port_ID Address tables can be constructed.
端口登录完成后，可以构建MAC地址到端口ID地址表。
In some loop environments with a limited number of ports, a static mapping from a MAC Address to Port_ID (D_ID or AL_PA) may be maintained. The FC layer will always know the destination Port_ID based on the table. The table is typically downloaded into the driver at configuration time. This method scales poorly, and is therefore not recommended.
在一些端口数量有限的环路环境中，可以保持从MAC地址到端口ID（D_ID或AL_PA）的静态映射。FC层将始终根据表知道目标端口的ID。该表通常在配置时下载到驱动程序中。这种方法伸缩性差，因此不推荐使用。
Appendix D: FC Layer Address Validation
附录D：FC层地址验证
At all times, the <WW_PN, Port_ID> mapping MUST be valid before use. There are many events that can invalidate this mapping. The following discussion addresses conditions when such a validation is required.
在任何时候，<WW\u PN，Port\u ID>映射必须在使用前有效。有许多事件会使此映射无效。以下讨论讨论了需要此类验证时的条件。
After a FC link interruption occurs, the Port_ID of a port may change. After the interruption, the Port_IDs of all other ports that have previously performed PLOGI (N_Port Login) with this port may have changed, and its own Port_ID may have changed.
FC链路中断发生后，端口的端口ID可能会更改。中断后，以前使用此端口执行PLOGI（N_Port Login）的所有其他端口的端口号可能已更改，其自身的端口号也可能已更改。
Because of this, address validation is required after a LIP in a loop topology [7] or after NOS/OLS in a point-to-point topology [6].
因此，在循环拓扑[7]中的LIP之后或在点到点拓扑[6]中的NOS/OLS之后需要进行地址验证。
Port_IDs will not change as a result of Link Reset (LR),thus address validation is not required.
端口ID不会因链路重置（LR）而改变，因此不需要地址验证。
In addition to actively validating devices after a link interruption, if a port receives any FC-4 data frames (other than broadcast frames), from a port that is not currently logged in, then it shall send an explicit Extended Link Service (ELS) Request logout (LOGO) command to that port.
除了在链路中断后主动验证设备外，如果端口从当前未登录的端口接收到任何FC-4数据帧（广播帧除外），则应向该端口发送显式扩展链路服务（ELS）请求注销（LOGO）命令。
ELS commands (Requests and Replies) are used by an N_Port to solicit a destination port (F_Port or N_Port) to perform some link-level function or service.) The LOGO Request is used to request invalidation of the service parameters and Port_ID of the recipient N_Port.
ELS命令（请求和回复）由N_端口用于请求目标端口（F_端口或N_端口）以执行某些链路级功能或服务。）徽标请求用于请求服务参数和收件人N_端口的端口ID无效。
The level of initialization and subsequent validation and recovery reported to the upper (FC-4) layers is implementation-specific.
向上层（FC-4）报告的初始化、后续验证和恢复级别是特定于实现的。
In general, an explicit Logout (LOGO) SHALL be sent whenever the FC-Layer mapping between the Port_ID and WW_PN of a remote port is removed.
通常，只要移除远程端口的端口ID和WW_PN之间的FC层映射，就应发送明确的注销（LOGO）。
The effect of power-up or re-boot on the mapping tables is outside the scope of this specification.
通电或重新引导对映射表的影响不在本规范的范围内。
No validation is required after LR. In a point-to-point topology, NOS/OLS causes implicit Logout of each port and after a NOS/OLS, each port must perform a PLOGI [2].
LR后无需验证。在点到点拓扑中，NOS/OLS导致每个端口隐式注销，在NOS/OLS之后，每个端口必须执行PLOGI[2]。
After a LIP, a port SHALL not transmit any link data to another port until the address of the other port has been validated. The validation consists of completing either ADISC or PDISC. (See Appendix G.)
在LIP之后，一个端口不得将任何链路数据传输到另一个端口，直到验证另一个端口的地址。验证包括完成ADISC或PDISC。（见附录G）
ADISC (Address Discovery) is an ELS command for discovering the hard addresses - the 24-bit identifier- of NL_Ports [5], [6].
ADISC（地址发现）是一个ELS命令，用于发现NLU端口的硬地址（24位标识符）[5]，[6]。
PDISC (Discover Port) is an ELS command for exchanging service parameters without affecting Login state [5], [6].
PDISC（Discover Port）是一个ELS命令，用于在不影响登录状态的情况下交换服务参数[5]，[6]。
As a requester, this specification prohibits PDISC and requires ADISC.
作为请求者，本规范禁止PDISC，并要求ADISC。
As a responder, an implementation may need to respond to both ADISC and PDISC for compatibility with other FC specifications.
作为响应者，实现可能需要同时响应ADISC和PDISC，以便与其他FC规范兼容。
If the three addresses, Port_ID, WW_PN, WW_NN, exactly match the values prior to the LIP, then any active exchanges may continue.
如果端口ID、WW_PN、WW_NN这三个地址与LIP之前的值完全匹配，则任何活动交换都可以继续。
If any of the three addresses have changed, then the node must be explicitly Logged out [4], [5].
如果三个地址中的任何一个已更改，则必须显式注销节点[4]、[5]。
If a port's N_Port ID changes after a LIP, then all active Port-ID to WW_PN mappings at this port must be explicitly Logged out.
如果某个端口的N_端口ID在LIP之后发生更改，则必须显式注销此端口上所有活动端口ID到WW_PN的映射。
A FAN (Fabric Address Notification) ELS command is sent by the fabric to all known previously logged in ports following an initialization event. Therefore, after a LIP, hosts may wait for this notification to arrive or they may perform a FLOGI.
在初始化事件之后，FAN（结构地址通知）ELS命令由结构发送到所有已知的以前登录的端口。因此，在LIP之后，主机可能会等待此通知到达，或者执行FLOGI。
If the WW_PN and WW_NN of the fabric FL_Port contained in the FAN ELS or FLOGI response exactly match the values before the LIP, and if the AL_PA obtained by the port is the same as the one before the LIP, then the port may resume all exchanges. If not, then FLOGI (Fabric Login) must be performed with the fabric and all nodes must be explicitly Logged out.
如果FAN ELS或FLOGI响应中包含的结构FL_端口的WW_PN和WW_NN与LIP之前的值完全匹配，并且如果端口获得的AL_PA与LIP之前的值相同，则端口可以恢复所有交换。否则，必须使用结构执行FLOGI（结构登录），并且必须显式注销所有节点。
A public loop device will have to perform the private loop authentication to any nodes on the local loop which have an Area + Domain Address == 0x00-00-XX
公共环路设备必须对本地环路上具有Area+Domain Address==0x00-00-XX的任何节点执行私有环路身份验证
No validation is required after LR (link reset).
LR（链路重置）后无需验证。
After NOS/OLS, a port must perform FLOGI. If, after FLOGI, the S_ID of the port, the WW_PN of the fabric, and the WW_NN of the fabric are the same as before the NOS/OLS, then the port may resume all exchanges. If not, all nodes must be explicitly, Logged out [2].
NOS/OLS之后，端口必须执行FLOGI。如果在FLOGI之后，端口的S_ID、结构的WW_PN和结构的WW_NN与NOS/OLS之前相同，则端口可以恢复所有交换。如果不是，则必须显式注销所有节点[2]。
APPENDIX E: Fibre Channel Overview
附录E：光纤通道概述
The FC Standard [2] defines 5 "levels" (not layers) for its protocol description: FC-0, FC-1, FC-2, FC-3, and FC-4. The first three levels (FC-0, FC-1, FC-2) are largely concerned with the physical formatting and control aspects of the protocol. FC-3 has been architected to provide a place holder for functions that might need to be performed after the upper layer protocol has requested the transmission of an information unit, but before FC-2 is asked to deliver that piece of information by using a sequence of frames [18]. At this time, no FC-3 functions have been defined. FC-4 is meant for supporting profiles of Upper Layer Protocols (ULP) such as IP and Small Computer System Interface (SCSI), and supports a relatively small set compared to LAN protocols such as IEEE 802.3.
FC标准[2]为其协议描述定义了5个“级别”（非层）：FC-0、FC-1、FC-2、FC-3和FC-4。前三个级别（FC-0、FC-1、FC-2）主要涉及协议的物理格式化和控制方面。FC-3被设计为在上层协议请求传输信息单元之后，但在FC-2被要求使用帧序列交付该信息之前，为可能需要执行的功能提供占位符[18]。目前，尚未定义FC-3功能。FC-4用于支持上层协议（ULP）的配置文件，如IP和小型计算机系统接口（SCSI），与局域网协议（如IEEE 802.3）相比，FC-4支持的配置文件集相对较小。
FC devices are called "Nodes", each of which has at least one "Port" to connect to other ports. A Node may be a workstation, a disk drive or disk array, a camera, a display unit, etc. A "Link" is two unidirectional paths flowing in opposite directions and connecting two Ports within adjacent Nodes.
FC设备称为“节点”，每个节点至少有一个“端口”连接到其他端口。节点可以是工作站、磁盘驱动器或磁盘阵列、摄像头、显示单元等。“链路”是两条单向路径，沿相反方向流动，并连接相邻节点内的两个端口。
FC Nodes communicate using higher layer protocols such as SCSI and IP and are configured to operate using Point-to-Point, Private Loop, Public Loop (attachment to a Fabric), or Fabric network topologies.
FC节点使用更高层协议（如SCSI和IP）进行通信，并配置为使用点对点、专用环路、公共环路（连接到结构）或结构网络拓扑进行操作。
The point-to-point is the simplest of the four topologies, where only two nodes communicate with each other. The private loop may connect a number of devices (max 126) in a logical ring much like Token Ring, and is distinguished from a public loop by the absence of a Fabric Node participating in the loop. The Fabric topology is a switched network where any attached node can communicate with any other. For a detail description of FC topologies refer to [18].
点到点是四种拓扑中最简单的一种，其中只有两个节点相互通信。专用环路可以像令牌环一样连接逻辑环中的多个设备（最大126个），并且与公共环路的区别在于没有参与环路的结构节点。结构拓扑是一个交换网络，其中任何连接的节点都可以与任何其他节点通信。有关FC拓扑的详细说明，请参阅[18]。
Table below summarizes the usage of port types depending on its location [12]. Note that E-Port is not relevant to any discussion in this specification but is included below for completeness.
下表总结了端口类型的使用情况，具体取决于其位置[12]。请注意，E-Port与本规范中的任何讨论无关，但出于完整性考虑，包含在下文中。
+-----------+-------------+-----------------------------------------+
| Port Type | Location | Topology Associated with |
+-----------+-------------+-----------------------------------------+
| N_Port | Node | Point-to-Point or Fabric |
+-----------+-------------+-----------------------------------------+
| NL_Port | Node |In N_Port mode -Point-to-Point or Fabric |
| | |In NL_Port mode - Arbitrated Loop |
+-----------+-------------+-----------------------------------------+
| F_Port | Fabric | Fabric |
+-----------+-------------+-----------------------------------------+
| FL_Port | Fabric | In F_Port mode - Fabric |
| | | In FL_Port mode - Arbitrated Loop |
+-----------+-------------+-----------------------------------------+
| E_Port | Fabric | Internal Fabric Expansion |
+-----------+-------------+-----------------------------------------+
+-----------+-------------+-----------------------------------------+
| Port Type | Location | Topology Associated with |
+-----------+-------------+-----------------------------------------+
| N_Port | Node | Point-to-Point or Fabric |
+-----------+-------------+-----------------------------------------+
| NL_Port | Node |In N_Port mode -Point-to-Point or Fabric |
| | |In NL_Port mode - Arbitrated Loop |
+-----------+-------------+-----------------------------------------+
| F_Port | Fabric | Fabric |
+-----------+-------------+-----------------------------------------+
| FL_Port | Fabric | In F_Port mode - Fabric |
| | | In FL_Port mode - Arbitrated Loop |
+-----------+-------------+-----------------------------------------+
| E_Port | Fabric | Internal Fabric Expansion |
+-----------+-------------+-----------------------------------------+
The FC 'Exchange' is a mechanism used by two FC ports to identify and manage an operation between them [18]. An Exchange is opened whenever an operation is started between two ports. The Exchange is closed when this operation ends.
FC“交换”是两个FC端口用来识别和管理它们之间的操作的机制[18]。每当在两个端口之间启动操作时，就会打开一个交换机。此操作结束时，交易所关闭。
The FC-4 Level specifies data units for each type of application level payload called 'Information Unit' (IU). Each protocol carried by FC has a defined size for the IU. Every operation must have at least one IU. Lower FC levels map this to a FC Sequence.
FC-4级别为称为“信息单元”（IU）的每种类型的应用级有效负载指定数据单元。FC携带的每个协议都有一个定义的IU大小。每个操作必须至少有一个IU。较低的FC级别将其映射到FC序列。
Typically, a Sequence consists of more than one frame. Larger user data is segmented and reassembled using two methods: Sequence Count and Relative Offset [18]. With the use of Sequence Count, data blocks are sent using frames with increasing sequence counts (modulo 65536) and it is quite straightforward to detect the first frame that contains the Network_Header. When Relative Offset is used, as frames arrive, some computation is required to detect the first frame that contains the Network_Header. Sequence Count and Relative Offset field control information, is carried in the FC Header.
通常，一个序列由多个帧组成。使用两种方法对较大的用户数据进行分段和重组：序列计数和相对偏移量[18]。通过使用序列计数，使用序列计数增加的帧（模65536）发送数据块，并且检测包含网络头的第一帧非常简单。当使用相对偏移量时，当帧到达时，需要进行一些计算来检测包含网络头的第一帧。序列计数和相对偏移量字段控制信息携带在FC报头中。
The FC-4 Level makes a request to FC-3 Level when it wishes it to be delivered. Currently, there are no FC-3 level defined functions, and this level simply converts the Information Unit delivery request into a 'Sequence' delivery request and passes it on to the FC-2 Level. Therefore, each FC-4 Information Unit corresponds to a FC-2 Level Sequence.
FC-4级在希望交付时向FC-3级发出请求。目前，没有FC-3级别定义的功能，该级别仅将信息单元交付请求转换为“顺序”交付请求，并将其传递到FC-2级别。因此，每个FC-4信息单元对应一个FC-2级序列。
The maximum data carried by a FC frame cannot exceed 2112-bytes [2]. Whenever, the Information Unit exceeds this value, the FC-2 breaks it into multiple frames and sends it in a sequence.
FC帧承载的最大数据不能超过2112字节[2]。每当信息单元超过此值时，FC-2将其分为多个帧并按顺序发送。
There can be multiple Sequences within an Exchange. Sequences within an Exchange are processed sequentially. Only one Sequence is active at a time. Within an Exchange information may flow in one direction only or both. If bi-directional then one of the ports has the initiative to send the next Sequence for that Exchange. Sequence Initiative can be passed between the ports on the last frame of Sequence when control is transferred. This amounts to half-duplex behavior.
一个交换中可以有多个序列。交换中的序列是按顺序处理的。一次只有一个序列处于活动状态。在交换中，信息可能只朝一个方向流动，也可能同时朝两个方向流动。如果是双向的，则其中一个端口有权为该交换发送下一个序列。在传输控制时，序列的最后一帧上的端口之间可以传递序列主动性。这相当于半双工行为。
Ports may have more than one Exchange open at a time. Ports can multiplex between Exchanges. Exchanges are uniquely identified by Exchange IDs (X_ID). An Originator OX_ID and a Responder RX_ID uniquely identify an Exchange.
端口一次可以打开多个Exchange。端口可以在交换机之间多路传输。交换由交换ID（X_ID）唯一标识。发起者OX_ID和响应者RX_ID唯一标识交换。
The FC header as shown in the diagrams below contains routing and other control information to manage Frames, Sequences, and Exchanges. The Frame-header is sent as 6 transmission words immediately following an SOF delimiter and before the Data Field.
下图所示的FC报头包含用于管理帧、序列和交换的路由和其他控制信息。帧头作为6个传输字发送，紧跟在SOF定界符之后和数据字段之前。
D_ID and S_ID:
D_ID和S_ID：
FC uses destination address routing [12], [13]. Frame routing in a point-to-point topology is trivial.
FC使用目标地址路由[12]，[13]。点到点拓扑中的帧路由非常简单。
For the Arbitrated Loop topology, with the destination NL_Port on the same AL, the source port must pick the destination port, determine its AL Physical Address, and "Open" the destination port. The frames must pass through other NL_Ports or the FL_Port on the loop between the source and destination, but these ports do not capture the frames. They simply repeat and transmit the frame. Either communicating port may "Close" the circuit.
对于仲裁环路拓扑，当目标NL_端口位于同一AL上时，源端口必须选择目标端口，确定其AL物理地址，并“打开”目标端口。帧必须通过源和目标之间环路上的其他NL_端口或FL_端口，但这些端口不捕获帧。它们只是重复并传输帧。任一通信端口均可“关闭”电路。
When the destination port is not on the same AL, the source NL_Port must open the FL_Port attached to a Fabric. Once in the Fabric, the Fabric routes the frames again to the destination.
当目标端口不在同一AL上时，源NL_端口必须打开连接到结构的FL_端口。一旦进入结构，结构会将帧再次路由到目标。
In a Fabric topology, the Fabric looks into the Frame-header, extracts the destination address (D_ID), searches its own routing tables, and sends the frame to the destination port along the path chosen. The process of choosing a path may be performed at each fabric element or switch until the F_Port attached to the destination N_Port is reached.
在结构拓扑中，结构查看帧头，提取目标地址（D_ID），搜索自己的路由表，并沿所选路径将帧发送到目标端口。选择路径的过程可以在每个结构元素或交换机上执行，直到到达连接到目标N_端口的F_端口。
Fibre Channel Frame Header, Network_Header, and Payload carrying IP Packet
光纤通道帧标头、网络标头和承载IP数据包的有效负载
+---+----------------+----------------+----------------+--------------+
|Wrd| <31:24> | <23:16> | <15:08> | <07:00> |
+---+----------------+----------------+----------------+--------------+
|0 | R_CTL | D_ID |
+---+----------------+----------------+----------------+--------------+
|1 | CS_CTL | S_ID |
+---+----------------+----------------+----------------+--------------+
|2 | TYPE | F_CTL |
+---+----------------+----------------+----------------+--------------+
|3 | SEQ_ID | DF_CTL | SEQ_CNT |
+---+----------------+----------------+----------------+--------------+
|4 | OX_ID | RX_ID |
+---+--------+-------+----------------+----------------+--------------+
|5 | Parameter (Control or Relative Offset for Data ) |
+---+-----------------------------------------------------------------+
|6 | NAA | Network_Dest_Address (Hi order bits) |
+---+--------+-------+----------------+----------------+--------------+
|7 | Network_Dest_Address (Lo order bits) |
+---+--------+-------+----------------+----------------+--------------+
|8 | NAA | Network_Src_Address (Hi order bits) |
+---+--------+-------+----------------+----------------+--------------+
|9 | Network_Src_Address (Lo order bits) |
+---+----------------+----------------+----------------+--------------+
|10 | DSAP | SSAP | CTRL | OUI |
+---+----------------+----------------+----------------+--------------+
|11 | OUI | PID |
+---+----------------+----------------+----------------+--------------+
|12 | IP Packet Data ... |
+---+----------------+----------------+----------------+--------------+
+---+----------------+----------------+----------------+--------------+
|Wrd| <31:24> | <23:16> | <15:08> | <07:00> |
+---+----------------+----------------+----------------+--------------+
|0 | R_CTL | D_ID |
+---+----------------+----------------+----------------+--------------+
|1 | CS_CTL | S_ID |
+---+----------------+----------------+----------------+--------------+
|2 | TYPE | F_CTL |
+---+----------------+----------------+----------------+--------------+
|3 | SEQ_ID | DF_CTL | SEQ_CNT |
+---+----------------+----------------+----------------+--------------+
|4 | OX_ID | RX_ID |
+---+--------+-------+----------------+----------------+--------------+
|5 | Parameter (Control or Relative Offset for Data ) |
+---+-----------------------------------------------------------------+
|6 | NAA | Network_Dest_Address (Hi order bits) |
+---+--------+-------+----------------+----------------+--------------+
|7 | Network_Dest_Address (Lo order bits) |
+---+--------+-------+----------------+----------------+--------------+
|8 | NAA | Network_Src_Address (Hi order bits) |
+---+--------+-------+----------------+----------------+--------------+
|9 | Network_Src_Address (Lo order bits) |
+---+----------------+----------------+----------------+--------------+
|10 | DSAP | SSAP | CTRL | OUI |
+---+----------------+----------------+----------------+--------------+
|11 | OUI | PID |
+---+----------------+----------------+----------------+--------------+
|12 | IP Packet Data ... |
+---+----------------+----------------+----------------+--------------+
R_CTL (Routing Control) and TYPE(data structure):
R_CTL（路由控制）和类型（数据结构）：
Frames for each FC-4 can be easily distinguished from the others at the receiving port using the R_CTL (Routing Control) and TYPE (data structure) fields in the Frame-header.
使用帧头中的R_CTL（路由控制）和TYPE（数据结构）字段，可以在接收端口轻松地将每个FC-4的帧与其他帧区分开来。
The R_CTL has two sub-fields: Routing bits and Information category. The Routing bits sub-field has specific values that mean FC-4 data follows and the Information Category tells the receiver the "Type" of data contained in the frame. The R_CTL and TYPE code points are shown in the diagrams.
R_CTL有两个子字段：路由位和信息类别。路由比特子字段具有特定值，表示FC-4数据随后出现，信息类别告知接收器帧中包含的数据的“类型”。R_CTL和类型代码点如图所示。
Other Header fields:
其他标题字段：
F_CTL (Frame Control) and SEQ_ID (Sequence Identification), SEQ_CNT (Sequence Count), OX_ID (Originator exchange Identifier), RX_ID (Responder exchange Identifier), and Parameter fields are used to manage the contents of a frame, and mark information exchange boundaries for the destination port.
F_CTL（帧控制）和SEQ_ID（序列标识）、SEQ_CNT（序列计数）、OX_ID（发起者交换标识符）、RX_ID（响应者交换标识符）和参数字段用于管理帧的内容，并标记目标端口的信息交换边界。
F_CTL(Frame Control):
F_控制（帧控制）：
The FC_CTL field is a 3-byte field that contains information relating to the frame content. Most of the other Frame-header fields are used for frame identification. Among other things, bits in this field indicate the First Sequence, Last Sequence, or End Sequence. Sequence Initiative bit is used to pass control of the next Sequence in the Exchange to the recipient.
FC_CTL字段是一个3字节字段，包含与帧内容相关的信息。大多数其他帧头字段用于帧标识。除其他外，该字段中的位表示第一个序列、最后一个序列或结束序列。序列起始位用于将交换中下一个序列的控制权传递给接收方。
SEQ_ID (Sequence Identifier) and SEQ_CNT (Sequence Count):
序列ID（序列标识符）和序列CNT（序列计数）：
This is used to uniquely identify sequences within an Exchange. The <S_ID, D_ID, SEQ_ID> uniquely identifies any active Sequence. SEQ_CNT is used to uniquely identify frames within a Sequence to assure sequentiality of frame reception, and to allow unique correlation of link control frames with their related data frames.
这用于唯一标识交换中的序列。<S_ID，D_ID，SEQ_ID>唯一地标识任何活动序列。SEQ_CNT用于唯一地标识序列中的帧，以确保帧接收的顺序性，并允许链路控制帧与其相关数据帧的唯一相关性。
Originator Exchange Identifier (OX_ID) and Responder Exchange Identifier (RX_ID):
发起者交换标识符（OX_ID）和响应者交换标识符（RX_ID）：
The OX_ID value provides association of frames with specific Exchanges originating at a particular N_Port. The RX_ID field provides the same function that the OX_ID provides for the Exchange Originator. The OX_ID is meaningful on the Exchange Originator, and the RX_ID is meaningful on the Responder.
OX_ID值提供帧与源自特定N_端口的特定交换的关联。RX_ID字段提供的功能与OX_ID为Exchange发起人提供的功能相同。OX_ID对Exchange发起人有意义，RX_ID对响应者有意义。
DF_CTL (Data Field Control):
DF_CTL（数据字段控制）：
The DF_CTL field specifies the presence or absence of optional headers between the Frame-header and Frame Payload
DF_CTL字段指定帧标头和帧有效负载之间是否存在可选标头
PARAMETER:
参数：
The Parameter field has two meanings, depending on Frame type. For Link Control Frames, the Parameter field indicates the specific type of Link Control frame. For Data frames, this field contains the Relative Offset value. This specifies an offset from an Upper Layer Protocol buffer from a base address.
参数字段有两种含义，具体取决于帧类型。对于链接控制帧，参数字段指示链接控制帧的特定类型。对于数据帧，此字段包含相对偏移值。这指定从上层协议缓冲区到基址的偏移量。
The Code Points for FC Frames with IP and ARP Packets are very similar with the exception of PID value in Word 11 which is set to 0x08-00 for IP and 0x08-06 for ARP. Also, the Network_Header appears only in the first logical frame of a FC Sequence carrying IP. In the case, where FC frames carry ARP packets it is always present because these are single frame Sequences.
具有IP和ARP数据包的FC帧的代码点非常相似，但字11中的PID值除外，该值对于IP设置为0x08-00，对于ARP设置为0x08-06。此外，网络头仅出现在承载IP的FC序列的第一个逻辑帧中。在这种情况下，当FC帧携带ARP数据包时，它总是存在，因为这些数据包是单帧序列。
Code Points for FC Frame with IP packet Data
+---+----------------+----------------+----------------+------------+
|Wrd| <31:24> | <23:16> | <15:08> | <07:00> |
+---+----------------+----------------+----------------+------------+
| 0 | 0x04 | D_ID |
+---+----------------+----------------+----------------+------------+
| 1 | 0x00 | S_ID |
+---+----------------+----------------+----------------+------------+
| 2 | 0x05 | F_CTL |
+---+----------------+----------------+----------------+------------+
| 3 | SEQ_ID | 0x20 | SEQ_CNT |
+---+----------------+----------------+----------------+------------+
| 4 | OX_ID | RX_ID |
+---+----------------+----------------+----------------+------------+
| 5 | 0xXX-XX-XX-XX Parameter Relative Offset |
+---+------+--------------------------------------------------------+
| 6 | 0001 | 0x000 | Dest. MAC (Hi order bits) |
+---+------+---------+----------------+----------------+------------+
| 7 | Dest. MAC (Lo order bits) |
+---+------+----------+----------------+----------------------------+
| 8 | 0001 | 0x000 | Src. MAC (Hi order bits) |
+---+------+---------+----------------+----------------+------------+
| 9 | Src. MAC (Lo order bits) |
+---+----------------+----------------+----------------+------------+
|10 | 0xAA | 0xAA | 0x03 | 0x00 |
+---+----------------+----------------+----------------+------------+
|11 | 0x00-00 | 0x08-00 |
+---+----------------+----------------+----------------+------------+
|12 | IP Packet Data |
+---+----------------+----------------+----------------+------------+
|13 | ... |
+---+----------------+----------------+----------------+------------+
Code Points for FC Frame with IP packet Data
+---+----------------+----------------+----------------+------------+
|Wrd| <31:24> | <23:16> | <15:08> | <07:00> |
+---+----------------+----------------+----------------+------------+
| 0 | 0x04 | D_ID |
+---+----------------+----------------+----------------+------------+
| 1 | 0x00 | S_ID |
+---+----------------+----------------+----------------+------------+
| 2 | 0x05 | F_CTL |
+---+----------------+----------------+----------------+------------+
| 3 | SEQ_ID | 0x20 | SEQ_CNT |
+---+----------------+----------------+----------------+------------+
| 4 | OX_ID | RX_ID |
+---+----------------+----------------+----------------+------------+
| 5 | 0xXX-XX-XX-XX Parameter Relative Offset |
+---+------+--------------------------------------------------------+
| 6 | 0001 | 0x000 | Dest. MAC (Hi order bits) |
+---+------+---------+----------------+----------------+------------+
| 7 | Dest. MAC (Lo order bits) |
+---+------+----------+----------------+----------------------------+
| 8 | 0001 | 0x000 | Src. MAC (Hi order bits) |
+---+------+---------+----------------+----------------+------------+
| 9 | Src. MAC (Lo order bits) |
+---+----------------+----------------+----------------+------------+
|10 | 0xAA | 0xAA | 0x03 | 0x00 |
+---+----------------+----------------+----------------+------------+
|11 | 0x00-00 | 0x08-00 |
+---+----------------+----------------+----------------+------------+
|12 | IP Packet Data |
+---+----------------+----------------+----------------+------------+
|13 | ... |
+---+----------------+----------------+----------------+------------+
Code Points for FC Frame with ARP packet Data
+---+----------------+----------------+----------------+------------+
|Wrd| <31:24> | <23:16> | <15:08> | <07:00> |
+---+----------------+----------------+----------------+------------+
| 0 | 0x04 | D_ID |
+---+----------------+----------------+----------------+------------+
| 1 | 0x00 | S_ID |
+---+----------------+----------------+----------------+------------+
| 2 | 0x05 | F_CTL |
+---+----------------+----------------+----------------+------------+
| 3 | SEQ_ID | 0x20 | SEQ_CNT |
+---+----------------+----------------+----------------+------------+
| 4 | OX_ID | RX_ID |
+---+----------------+----------------+----------------+------------+
| 5 | 0xXX-XX-XX-XX Parameter Relative Offset |
+---+------+--------------------------------------------------------+
| 6 | 0001 | 0x000 | Dest. MAC (Hi order bits) |
+---+------+---------+----------------+----------------+------------+
| 7 | Dest. MAC (Lo order bits) |
+---+------+----------+----------------+----------------------------+
| 8 | 0001 | 0x000 | Src. MAC (Hi order bits) |
+---+------+---------+----------------+----------------+------------+
| 9 | Src. MAC (Lo order bits) |
+---+----------------+----------------+----------------+------------+
|10 | 0xAA | 0xAA | 0x03 | 0x00 |
+---+----------------+----------------+----------------+------------+
|11 | 0x00-00 | 0x08-06 |
+---+----------------+----------------+----------------+------------+
|12 | ARP Packet Data |
+---+----------------+----------------+----------------+------------+
|13| ... |
+---+----------------+----------------+----------------+------------+
Code Points for FC Frame with ARP packet Data
+---+----------------+----------------+----------------+------------+
|Wrd| <31:24> | <23:16> | <15:08> | <07:00> |
+---+----------------+----------------+----------------+------------+
| 0 | 0x04 | D_ID |
+---+----------------+----------------+----------------+------------+
| 1 | 0x00 | S_ID |
+---+----------------+----------------+----------------+------------+
| 2 | 0x05 | F_CTL |
+---+----------------+----------------+----------------+------------+
| 3 | SEQ_ID | 0x20 | SEQ_CNT |
+---+----------------+----------------+----------------+------------+
| 4 | OX_ID | RX_ID |
+---+----------------+----------------+----------------+------------+
| 5 | 0xXX-XX-XX-XX Parameter Relative Offset |
+---+------+--------------------------------------------------------+
| 6 | 0001 | 0x000 | Dest. MAC (Hi order bits) |
+---+------+---------+----------------+----------------+------------+
| 7 | Dest. MAC (Lo order bits) |
+---+------+----------+----------------+----------------------------+
| 8 | 0001 | 0x000 | Src. MAC (Hi order bits) |
+---+------+---------+----------------+----------------+------------+
| 9 | Src. MAC (Lo order bits) |
+---+----------------+----------------+----------------+------------+
|10 | 0xAA | 0xAA | 0x03 | 0x00 |
+---+----------------+----------------+----------------+------------+
|11 | 0x00-00 | 0x08-06 |
+---+----------------+----------------+----------------+------------+
|12 | ARP Packet Data |
+---+----------------+----------------+----------------+------------+
|13| ... |
+---+----------------+----------------+----------------+------------+
The Code Points for a FARP-REQ for a specific Match Address Code Point MATCH_WW_PN_NN ( b'011') is shown below. In particular, note the IP addresses field of the Requester set to a valid address and that of the responder set to '0'. Note also the setting of the D_ID address and the Port_ID of the Responder.
特定匹配地址码点匹配码点匹配码点匹配码点（b'011'）的FARP-REQ码点如下所示。请特别注意，请求者的IP地址字段设置为有效地址，响应者的IP地址字段设置为“0”。还要注意响应程序的D_ID地址和端口ID的设置。
The corresponding code point for a FARP-REPLY is also shown below. In particular, note the setting of the Port_ID of Responder and the IP address setting of the Responder.
FARP-REPLY的相应代码点也如下所示。特别是，请注意响应程序的端口ID设置和响应程序的IP地址设置。
Code Points for FC Frame with FARP-REQ Command for MATCH_WW_PN_NN
+---+----------------+----------------+----------------+------------+
|Wrd| <31:24> | <23:16> | <15:08> | <07:00> |
+---+----------------+----------------+----------------+------------+
| 0 | 0x04 | D_ID = |
| | | 0xFF 0xFF 0xFF |
+---+----------------+----------------+----------------+------------+
| 1 | 0x00 | S_ID |
+---+----------------+----------------+----------------+------------+
| 2 | 0x05 | F_CTL |
+---+----------------+----------------+----------------+------------+
| 3 | SEQ_ID | 0x20 | SEQ_CNT |
+---+----------------+----------------+----------------+------------+
| 4 | OX_ID | RX_ID |
+---+----------------+----------------+----------------+------------+
| 5 | 0xXX-XX-XX-XX Parameter Relative Offset |
+---+----------------+----------------+----------------+------------+
| 6 | 0x54 | 0x00 | 0x00 | 0x00 |
+---+----------------+----------------+----------------+------------+
| 7 | Port_ID of Requester = S_ID |Match Addr. |
| | |Code Points |
| | | xxxxx011 |
+---+----------------+----------------+----------------+------------+
| 8 | Port_ID of Responder = |Responder |
| | 0x00 0x00 0x00 |Flags |
+---+----------------+----------------+----------------+------------+
| 9 | 0001 | 0x000 |WW_PN Src. MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|10 | WW_PN Src. MAC (Lo order bits) |
+---+------+----------+---------------+-----------------------------+
|11 | 0001 | 0x000 |WW_NN Src. MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|12 | WW_NN Src. MAC (Lo order bits) |
+---+----------------+----------------+----------------+------------+
|13 | 0001 | 0x000 |WW_PN Src. MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|14 | WW_PN Dest. MAC (Lo order bits) |
+---+------+----------+---------------+-----------------------------+
|15 | 0001 | 0x000 |WW_NN Dest.MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|16 | WW_NN Dest. MAC (Lo order bits) |
+---+----------------+----------------+----------------+------------+
|17 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|18 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
Code Points for FC Frame with FARP-REQ Command for MATCH_WW_PN_NN
+---+----------------+----------------+----------------+------------+
|Wrd| <31:24> | <23:16> | <15:08> | <07:00> |
+---+----------------+----------------+----------------+------------+
| 0 | 0x04 | D_ID = |
| | | 0xFF 0xFF 0xFF |
+---+----------------+----------------+----------------+------------+
| 1 | 0x00 | S_ID |
+---+----------------+----------------+----------------+------------+
| 2 | 0x05 | F_CTL |
+---+----------------+----------------+----------------+------------+
| 3 | SEQ_ID | 0x20 | SEQ_CNT |
+---+----------------+----------------+----------------+------------+
| 4 | OX_ID | RX_ID |
+---+----------------+----------------+----------------+------------+
| 5 | 0xXX-XX-XX-XX Parameter Relative Offset |
+---+----------------+----------------+----------------+------------+
| 6 | 0x54 | 0x00 | 0x00 | 0x00 |
+---+----------------+----------------+----------------+------------+
| 7 | Port_ID of Requester = S_ID |Match Addr. |
| | |Code Points |
| | | xxxxx011 |
+---+----------------+----------------+----------------+------------+
| 8 | Port_ID of Responder = |Responder |
| | 0x00 0x00 0x00 |Flags |
+---+----------------+----------------+----------------+------------+
| 9 | 0001 | 0x000 |WW_PN Src. MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|10 | WW_PN Src. MAC (Lo order bits) |
+---+------+----------+---------------+-----------------------------+
|11 | 0001 | 0x000 |WW_NN Src. MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|12 | WW_NN Src. MAC (Lo order bits) |
+---+----------------+----------------+----------------+------------+
|13 | 0001 | 0x000 |WW_PN Src. MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|14 | WW_PN Dest. MAC (Lo order bits) |
+---+------+----------+---------------+-----------------------------+
|15 | 0001 | 0x000 |WW_NN Dest.MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|16 | WW_NN Dest. MAC (Lo order bits) |
+---+----------------+----------------+----------------+------------+
|17 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|18 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|19 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|20 | set to a valid IPv4 Address by Requester if Available |
+--------------------+----------------+---------+-------------------+
|21 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|22 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|23 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
| | 0x00-00-00-00 |
|24 | set to a valid IPv4 Address of Responder if available |
+--------------------+----------------+---------+-------------------+
|19 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|20 | set to a valid IPv4 Address by Requester if Available |
+--------------------+----------------+---------+-------------------+
|21 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|22 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|23 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
| | 0x00-00-00-00 |
|24 | set to a valid IPv4 Address of Responder if available |
+--------------------+----------------+---------+-------------------+
Code Points for FC Frame with FARP-REPLY Command
+---+----------------+----------------+----------------+------------+
|Wrd| <31:24> | <23:16> | <15:08> | <07:00> |
+---+----------------+----------------+----------------+------------+
| 0 | 0x04 | D_ID |
+---+----------------+----------------+----------------+------------+
| 1 | 0x00 | S_ID |
+---+----------------+----------------+----------------+------------+
| 2 | 0x05 | F_CTL |
+---+----------------+----------------+----------------+------------+
| 3 | SEQ_ID | 0x20 | SEQ_CNT |
+---+----------------+----------------+----------------+------------+
| 4 | OX_ID | RX_ID |
+---+----------------+----------------+----------------+------------+
| 5 | 0xXX-XX-XX-XX Parameter Relative Offset |
+---+----------------+----------------+----------------+------------+
| 6 | 0x55 | 0x00 | 0x00 | 0x00 |
+---+----------------+----------------+----------------+------------+
| 7 | Port_ID of Requester = D_ID | xxxxx011 |
+---+----------------+----------------+----------------+------------+
| 8 | Port_ID of Responder = S_ID |Resp. Flag |
+---+----------------+----------------+----------------+------------+
| 9 | 0001 | 0x000 |WW_PN Src. MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|10 | WW_PN Src. MAC (Lo order bits) |
+---+------+----------+---------------+-----------------------------+
|11 | 0001 | 0x000 |WW_NN Src. MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|12 | WW_NN Src. MAC (Lo order bits) |
+---+----------------+----------------+----------------+------------+
|13 | 0001 | 0x000 |WW_PN Src. MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|14 | WW_PN Dest. MAC (Lo order bits) |
+---+------+----------+---------------+-----------------------------+
|15 | 0001 | 0x000 |WW_NN Dest.MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|16 | WW_NN Dest. MAC (Lo order bits) |
+---+----------------+----------------+----------------+------------+
|17 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|18 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|19 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|20 | set to a valid IPv4 Address by Requester |
+--------------------+----------------+---------+-------------------+
|21 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
Code Points for FC Frame with FARP-REPLY Command
+---+----------------+----------------+----------------+------------+
|Wrd| <31:24> | <23:16> | <15:08> | <07:00> |
+---+----------------+----------------+----------------+------------+
| 0 | 0x04 | D_ID |
+---+----------------+----------------+----------------+------------+
| 1 | 0x00 | S_ID |
+---+----------------+----------------+----------------+------------+
| 2 | 0x05 | F_CTL |
+---+----------------+----------------+----------------+------------+
| 3 | SEQ_ID | 0x20 | SEQ_CNT |
+---+----------------+----------------+----------------+------------+
| 4 | OX_ID | RX_ID |
+---+----------------+----------------+----------------+------------+
| 5 | 0xXX-XX-XX-XX Parameter Relative Offset |
+---+----------------+----------------+----------------+------------+
| 6 | 0x55 | 0x00 | 0x00 | 0x00 |
+---+----------------+----------------+----------------+------------+
| 7 | Port_ID of Requester = D_ID | xxxxx011 |
+---+----------------+----------------+----------------+------------+
| 8 | Port_ID of Responder = S_ID |Resp. Flag |
+---+----------------+----------------+----------------+------------+
| 9 | 0001 | 0x000 |WW_PN Src. MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|10 | WW_PN Src. MAC (Lo order bits) |
+---+------+----------+---------------+-----------------------------+
|11 | 0001 | 0x000 |WW_NN Src. MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|12 | WW_NN Src. MAC (Lo order bits) |
+---+----------------+----------------+----------------+------------+
|13 | 0001 | 0x000 |WW_PN Src. MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|14 | WW_PN Dest. MAC (Lo order bits) |
+---+------+----------+---------------+-----------------------------+
|15 | 0001 | 0x000 |WW_NN Dest.MAC(Hi order bits)|
+---+------+---------+----------------+----------------+------------+
|16 | WW_NN Dest. MAC (Lo order bits) |
+---+----------------+----------------+----------------+------------+
|17 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|18 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|19 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|20 | set to a valid IPv4 Address by Requester |
+--------------------+----------------+---------+-------------------+
|21 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|22 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|23 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|24 | set to a valid IPv4 Address by Responder |
+--------------------+----------------+---------+-------------------+
|22 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|23 | 0x00-00-00-00 |
+--------------------+----------------+---------+-------------------+
|24 | set to a valid IPv4 Address by Responder |
+--------------------+----------------+---------+-------------------+
APPENDIX F: Fibre Channel Protocol Considerations
附录F：光纤通道协议注意事项
Problem: Sequence ID reuse in Class 3 can conceivably result in missing frame aliasing, which could result in delivery of corrupted (incorrectly-assembled) data, with no corresponding detection at the FC level.
问题：类3中的序列ID重用可能会导致丢失帧别名，这可能导致交付损坏（错误组装）的数据，而在FC级别没有相应的检测。
Prevention: This specification requires one of the following methods if Class 3 is used.
预防：如果使用3级，本规范要求以下方法之一。
- Continuously increasing Sequence Count (new Login Bit) - both sides must set When an N_Port sets the PLOGI login bit for continuously increasing SEQ_CNT, it is guaranteeing that it will transmit all frames within an Exchange using a continuously increasing SEQ_CNT (see description in Section B.1 below). - After using all SEQ_IDs (0-255) once, must start a new Exchange. It is recommended that a minimum of 4 Exchanges be used before an OX_ID can be reused. - Note: If an implementation is not checking the OX_ID when reassembling Sequences, the problem can still occur. Cycling through some number of SEQ_IDs, then jumping to a new Exchange does not solve the problem. SEQ_IDs must still be unique between two N_Ports, even across Exchanges. - Use only single-frame Sequences.
- 连续递增序列计数（新登录位）-当N_端口为连续递增序列设置PLOGI登录位时，双方必须进行设置，这保证了它将使用连续递增序列传输交换机内的所有帧（见下面第B.1节中的说明）。-在使用所有序列ID（0-255）一次后，必须启动新的交换。建议在重新使用OX_ID之前至少使用4次交换。-注意：如果一个实现在重新组装序列时没有检查OX_ID，那么问题仍然会发生。循环使用一些SEQ_id，然后跳转到新的交换并不能解决问题。SEQ_ID在两个N_端口之间必须仍然是唯一的，即使在交换机之间也是如此。-仅使用单帧序列。
This method allows the recipient to check incoming frames, knowing exactly what SEQ_CNT value to expect next. Since the SEQ_CNT will not repeat for 65,536 frames, the aliasing problem is significantly reduced.
这种方法允许接收者检查传入的帧，准确地知道下一步的SEQ_CNT值。由于SEQ_CNT不会对65536帧重复，因此混叠问题显著减少。
A Login bit (PLOGI) is used to indicate that a device always uses a continuously increasing SEQ_CNT, even across transfers of Sequence Initiative. This bit is necessary for interoperability with some devices, and it provides other benefits as well.
登录位（PLOGI）用于指示设备始终使用不断增加的序列，即使在序列传输中也是如此。此位对于与某些设备的互操作性是必需的，并且它还提供其他好处。
In the FC-PH-3 [11], the following is supported:
在FC-PH-3[11]中，支持以下内容：
Word 1, bit 17 - SEQ_CNT (S) 0 = Normal FC-PH rules apply 1 = Continuously increasing SEQ_CNT
字1，第17位-序号0=正常FC-PH规则适用1=连续增加序号
Any N_Port that sets Word 1, Bit 17 = 1, is guaranteeing that it will transmit all frames within an Exchange using a continuously increasing SEQ_CNT. Each Exchange SHALL start with SEQ_CNT = 0 in the first frame, and every frame transmitted after that SHALL increment the previous SEQ_CNT by one, even across transfers of Sequence Initiative. Any frames received from the other N_Port in the Exchange shall have no effect on the transmitted SEQ_CNT.
任何设置字1，位17=1的N_端口都保证它将使用连续递增的序列发送交换中的所有帧。每个交换应在第一帧中以SEQ_CNT=0开始，并且在该帧之后传输的每个帧应将先前的SEQ_CNT增加1，即使在序列主动性的传输中也是如此。从交换机中的另一个N_端口接收的任何帧对传输的序列没有影响。
Appendix G: Acronyms and Glossary of FC Terms
附录G：FC术语的首字母缩略词和词汇表
It is assumed that the reader is familiar with the terms and acronyms used in the FC protocol specification [2]. The following is provided for easy reference.
假设读者熟悉FC协议规范[2]中使用的术语和首字母缩略词。以下内容仅供参考。
First Frame: The frame that contains the SOFi field. This means a logical first and may not necessarily be the first frame temporally received in a sequence.
第一帧：包含SOFi字段的帧。这意味着逻辑第一帧，并且不一定是在序列中临时接收的第一帧。
Code Point: The coded bit pattern associated with control fields in frames or packets.
编码点：与帧或数据包中的控制字段相关的编码位模式。
PDU: Protocol Data Unit
协议数据单元
ABTS_LS: Abort Sequence Protocol - Last Sequence. A protocol for aborting an exchange based on the ABTS recipient setting the Last_Sequence bit in the BA_ACC ELS to the ABTS
ABTS_LS：中止序列协议-最后一个序列。一种基于ABTS接收方将BA_ACC ELS中的最后一个_序列位设置为ABTS而中止交换的协议
ADISC: Discover Address. An ELS for discovering the Hard Addresses (the 24 bit NL_Port Identifier) of N_Ports
发现地址。用于发现N_端口的硬地址（24位NL_端口标识符）的ELS
D_ID: Destination ID
D_ID：目的地ID
ES: End sequence. This FCTL bit in the FC header indicates this frame is the last frame of the sequence.
结束序列。FC头中的FCTL位表示该帧是序列的最后一帧。
FAN: Fabric Address Notification. An ELS sent by the fabric to all known previously Logged in ports following an initialization event.
FAN：结构地址通知。在初始化事件之后，结构向所有已知的以前登录的端口发送的ELS。
FLOGI: Fabric Login.
FLOGI:Fabric登录。
LIP: Loop Initialization. A primitive Sequence used by a port to detect if it is part of a loop or to recover from certain loop errors.
LIP：循环初始化。端口用来检测它是否是循环的一部分或从某些循环错误中恢复的基本序列。
Link: Two unidirectional paths flowing in opposite directions and connecting two Ports within adjacent Nodes.
链路：两条单向路径，流向相反，连接相邻节点内的两个端口。
LOGO: Logout.
LOGO：注销。
LR: Link reset. A primitive sequence transmitted by a port to initiate the link reset protocol or to recover from a link timeout.
链接重置。由端口发送的一种原始序列，用于启动链路重置协议或从链路超时中恢复。
LS: Last Sequence of Exchange. This FCTL bit in the FC header indicates the Sequence is the Last Sequence of the Exchange.
LS：交换的最后一个序列。FC头中的FCTL位表示该序列是交换的最后一个序列。
Network Address Authority: A 4-bit field specified in Network_Headers that distinguishes between various name registration authorities that may be used to identify the WW_PN and the WW_NN. NAA=b'0001' indicates IEEE-48-bit MAC addresses
网络地址授权：在网络头中指定的一个4位字段，用于区分可用于标识WW_PN和WW_NN的各种名称注册授权。NAA=b'0001'表示IEEE-48位MAC地址
Node: A collection of one or more Ports identified by a unique World Wide Node Name (WW_NN).
节点：由唯一的全球通用节点名称（WW_NN）标识的一个或多个端口的集合。
NOS: Not Operational. A primitive Sequence transmitted to indicate that the port transmitting this Sequence has detected a link failure or is offline, waiting for OLS to be received.
否：不可操作。发送的一种基本序列，表示发送该序列的端口已检测到链路故障或处于脱机状态，等待接收OLS。
OLS: Off line. A primitive Sequence transmitted to indicate that the port transmitting this Sequence is either initiating the link initialization protocol, receiving and recognizing NOS, or entering the offline state.
OLS：离线。一种发送的原始序列，用于指示发送该序列的端口正在启动链路初始化协议、接收并识别NOS或进入脱机状态。
PDISC: Discover Port. An ELS for exchanging Service Parameters without affecting Login state.
发现端口。用于在不影响登录状态的情况下交换服务参数的ELS。
Primitive Sequence: A primitive Sequence is an Ordered Set that is transmitted repeatedly and continuously.
基元序列：基元序列是一个有序的集合，可以重复和连续地传输。
Private Loop Device: A device that does not attempt Fabric Login (FLOGI) and usually adheres to PLDA. The Area and Domain components of the NL_Port ID must be 0x0000. These devices cannot communicate with any port not in the local loop.
专用循环设备：不尝试结构登录（FLOGI）且通常遵守PLDA的设备。NL_端口ID的区域和域组件必须为0x0000。这些设备无法与本地环路以外的任何端口通信。
Public Loop Device: A device whose Area and Domain components of the NL_Port ID cannot be 0x0000. Additionally, to be FLA compliant, the device must attempt to open AL_PA 0x00 and attempt FLOGI. These devices communicate with devices on the local loop as well as devices on the other side of a Fabric.
公用环路设备：NL_端口ID的区域和域组件不能为0x0000的设备。此外，为了符合FLA，设备必须尝试打开AL_PA 0x00并尝试FLOGI。这些设备与本地环路上的设备以及结构另一侧的设备通信。
Port: The transmitter, receiver and associated logic at either end of a link within a Node. There may be multiple Ports per Node. Each Port is identified by a unique Port_ID, which is volatile, and a unique World Wide Port Name (WW_PN), which is unchangeable. In this document, the term "port" may be used interchangeably with NL_Port or N_Port.
端口：节点内链路两端的发射机、接收机和相关逻辑。每个节点可能有多个端口。每个端口都由一个唯一的端口号（volatile）和一个唯一的全球通用端口名（WW\U PN）标识，后者是不可更改的。在本文件中，术语“端口”可与NL_端口或N_端口互换使用。
Port_ID: Fibre Channel ports are addressed by unique 24-bit Port_IDs. In a Fibre Channel frame header, the Port_ID is referred to as S_ID (Source ID) to identify the port originating a frame, and D_ID to identify the destination port. The Port_ID of a given port is volatile (changeable).
端口ID：光纤通道端口由唯一的24位端口ID寻址。在光纤通道帧头中，端口_ID称为S_ID（源ID），用于标识发起帧的端口，而D_ID用于标识目标端口。给定端口的端口ID是可变的（可变的）。
PLOGI: Port Login.
PLOGI：端口登录。
SI: Sequence Initiative
SI：序列倡议
World Wide Port_Name (WW_PN): Fibre Channel requires each Port to have an unchangeable WW_PN. Fibre Channel specifies a Network Address Authority (NAA) to distinguish between the various name registration authorities that may be used to identify the WW_PN. A 4-bit NAA identifier, 12-bit field set to 0x0 and an IEEE 48-bit MAC address together make this a 64-bit field.
全球通用端口名称（WW\U PN）：光纤通道要求每个端口都有一个不可更改的WW\U PN。光纤通道指定网络地址授权（NAA），以区分可用于标识WWU PN的各种名称注册授权。4位NAA标识符、设置为0x0的12位字段和IEEE 48位MAC地址共同构成64位字段。
World Wide Node_Name (WW_NN): Fibre Channel identifies each Node with a unchangeable WW_NN. In a single port Node, the WW_NN and the WW_PN may be identical.
全球范围节点名称（WW\U NN）：光纤通道使用不可更改的WW\U NN标识每个节点。在单端口节点中，WW_NN和WW_PN可能相同。
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。