RFC 2625
IP and ARP over Fibre Channel
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 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. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved.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.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
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
1. Introduction
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.
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).
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.
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
(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.
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.
"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.
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.
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.
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].2. Problem Statement
This specification addresses two problems: - A format definition and encapsulation mechanism for IPv4 and ARP packets over FC - Mechanisms for Address Resolution 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. 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. An optional FARP mechanism resolves IP address directly to FC Port_IDs. This is useful in some upper layer applications. 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.3. IP and ARP Encapsulation
3.1 FC Frame Format
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.
+------+--------+-----------+----//-------+------+------+
| 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.
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.
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.
Current FC Standards allow up to 3 Optional Header fields [11]:
- Network_Header (16-bytes)
- Association_Header (32-bytes)
- Device_Header (up to 64-bytes).
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.
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.
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.
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.
ARP packets map to a single frame FC Sequence and SHALL always carry
the FC Network_Header.
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.
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 |
--+-----------+-------------//-----------------+--
Fig. 2 FC Network_Header in a Frame Sequence
The SOF, CRC, EOF control fields of the FC frame and other optional
headers have been omitted in the figure for clarity.
3.2 MTU
3.2.1 IP MTU
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.
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.
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.
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. 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. All implementations SHALL restrict the IP MTU size to 65,280 bytes and the corresponding FC Sequence Payload size to 65536-bytes.3.2.2 Maximally Minimum IPv4 Packet
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]. 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.3.2.3 ARP MTU
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. The InARP packet is identical in size to the ARP and the same MTU requirements apply.
3.2.4 FC Data Field containing FARP Packet
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.3.3 FC Port and Node Network Addresses
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). 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). 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]. 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.
+--------+---------------------------------------+
| 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.4 FC Sequence Payload Format
FC Payload with IP:
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.
+-----------------+-----------+------------+-------------//----------+
| 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
FC Sequence Payload with ARP:
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.
+-----------------+-------------------+
| LLC/SNAP Header | ARP Packet |
| (8 bytes) | (28 bytes) |
+-----------------+-------------------+
Fig. 5 Format of FC Sequence Payload carrying ARP
FC Sequence Payload with FARP: 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. 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. +----------+----------+----------+ | 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. 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 +------+------+-------+------+------+ | 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). The SNAP OUI value equal to 0x00-80-C2 indicates Bridged Protocols.
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).
The complete LLC/SNAP Header is shown in Fig. 8.
+-----------+----------+----------+-------+-------+-------+-------+------+
| DSAP | SSAP | CTRL | OUI | PID |
| (1 byte) | (1 byte) | (1 byte) | ( 3 bytes) | (2 bytes |
+-----------+----------+----------+-------+-------+-------+-------+------+
Fig. 8 LLC/SNAP Header
3.5 Bit and Byte Ordering
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.
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.
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.
4. ARP
4.1 Address Resolution
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:
- a non-volatile unique 64-bit address called World Wide Port_Name
(WW_PN)
- a volatile 24-bit address called a Port_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)
2. A mapping from the WW_PN to the Port_ID (see Appendix G for a
definition of Port_ID)
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.
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.
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.
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.
4.2 ARP Packet Format
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.
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.
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.
The LLC/SNAP encapsulated ARP Reply Packet is mapped to a FC Sequence. Compliant ARP Replys SHALL include Network_Headers. Note that in all discussions to follow, the WW_PN and the 48-bit MAC address conceptually mean the same thing. The 'HW Type' field SHALL be set to 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. The 'Protocol' field SHALL be set to 0x08-00 indicating IP protocol. The 'HW Addr Length' field SHALL be set to 0x06 indicating 6-bytes of HW address. The 'Protocol Addr Length' field SHALL be set to 0x04 indicating 4- bytes of IPv4 address. The 'Operation' Code field SHALL be set as follows: 0x00-01 for ARP Request 0x00-02 for ARP Reply 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. 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). 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. 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.
+-------------------------+
| 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
4.3 ARP Layer Mapping and Operation
Whenever a FC port wishes to send IP data to another FC port, then
the following steps are taken:
1. The source port should first consult its local mapping tables to
determine the <destination IP address, destination WW_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.
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.
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.
5. If no node has the matching IP address, the result is a silent
behavior.
4.4 ARP Broadcast in a Point-to-Point Topology
The ARP Request (Broadcast) and Reply mechanism described above still apply, although there is only one node that receives the ARP Request.4.5 ARP Broadcast in a Private Loop Topology
In a private loop, the ARP Request Broadcast frame is sent using the broadcast method specified in the FC-AL [7]standard. 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. 2. The source port then removes this OPN(fr) signal when it returns to it. 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: Destination ID <Word 0, bit 0:23>: D_ID = 0xFF-FF-FF Sequence Initiative <Word 2, bit23>: SI=0 Last Sequence <Word 2, bit 20>: LS=1 End Sequence <Word 2, bit 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' 5. The destination port recognizing its IP address in the ARP Request packet SHALL respond with an ARP Reply.4.6 ARP Broadcast in a Public Loop Topology
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.
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.
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.
4. A Broadcast Sequence is now sent on all ports (all FL_ports,
F_Ports) in Class 3 frame with:
Destination ID <Word 0, bit 23:0>: D_ID = 0xFF-FF-FF
Sequence Initiative <Word 2, bit23>: SI=0
Last Sequence <Word 2, bit 20>: LS=1
End Sequence <Word 2, bit 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'
6. The destination port recognizing its IP address in the ARP
Request packet SHALL respond with an ARP Reply.
4.7 ARP Operation in a Fabric Topology
1. Nodes directly attached to fabric do not require the OPN(fr)
primitive signal.
2. A Broadcast Sequence is now sent on all ports (all FL_ports,
F_Ports) in Class 3 frame with:
Destination ID <Word 0, bit 23:0>: D_ID = 0xFF-FF-FF
Sequence Initiative <Word 2, bit23>: SI=0
Last Sequence <Word 2, bit 20>: LS=1
End Sequence <Word 2, bit 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'
4. The destination port recognizing its IP address in
the ARP packet SHALL respond with an ARP Reply.
(next page on part 2)
