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 Rajagopal, et al. Standards Track [Page 1] RFC 2625 IP and ARP over Fibre Channel June 1999 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 Rajagopal, et al. Standards Track [Page 2] RFC 2625 IP and ARP over Fibre Channel June 1999 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 Rajagopal, et al. Standards Track [Page 3] RFC 2625 IP and ARP over Fibre Channel June 1999 (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. Rajagopal, et al. Standards Track [Page 4] RFC 2625 IP and ARP over Fibre Channel June 1999 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. Rajagopal, et al. Standards Track [Page 5] RFC 2625 IP and ARP over Fibre Channel June 1999 +------+--------+-----------+----//-------+------+------+ | 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. Rajagopal, et al. Standards Track [Page 6] RFC 2625 IP and ARP over Fibre Channel June 1999 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. Rajagopal, et al. Standards Track [Page 7] RFC 2625 IP and ARP over Fibre Channel June 1999 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. Rajagopal, et al. Standards Track [Page 8] RFC 2625 IP and ARP over Fibre Channel June 1999 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. Rajagopal, et al. Standards Track [Page 9] RFC 2625 IP and ARP over Fibre Channel June 1999 +--------+---------------------------------------+ | 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 Rajagopal, et al. Standards Track [Page 10] RFC 2625 IP and ARP over Fibre Channel June 1999 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. Rajagopal, et al. Standards Track [Page 11] RFC 2625 IP and ARP over Fibre Channel June 1999 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 Rajagopal, et al. Standards Track [Page 12] RFC 2625 IP and ARP over Fibre Channel June 1999 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. Rajagopal, et al. Standards Track [Page 13] RFC 2625 IP and ARP over Fibre Channel June 1999 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. Rajagopal, et al. Standards Track [Page 14] RFC 2625 IP and ARP over Fibre Channel June 1999 +-------------------------+ | 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 . 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. Rajagopal, et al. Standards Track [Page 15] RFC 2625 IP and ARP over Fibre Channel June 1999 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 : D_ID = 0xFF-FF-FF Sequence Initiative : SI=0 Last Sequence : LS=1 End Sequence : 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. Rajagopal, et al. Standards Track [Page 16] RFC 2625 IP and ARP over Fibre Channel June 1999 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 : D_ID = 0xFF-FF-FF Sequence Initiative : SI=0 Last Sequence : LS=1 End Sequence : 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 : D_ID = 0xFF-FF-FF Sequence Initiative : SI=0 Last Sequence : LS=1 End Sequence : 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. Rajagopal, et al. Standards Track [Page 17] RFC 2625 IP and ARP over Fibre Channel June 1999 5. FARP 5.1 Scope 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. FARP is a method using Extended Link Service (ELS) commands that resolves 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].) Additional address matching mechanisms that resolve and 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. Other less formal FC Layer Mapping mechanisms are described in Appendix C. 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. 5.2 FARP Overview The FARP protocol uses two ELS commands - FARP-REQ and 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. 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. The FARP-REQ may indicate that the Responder: Rajagopal, et al. Standards Track [Page 18] RFC 2625 IP and ARP over Fibre Channel June 1999 - Perform only a Login with it (Requester) or, - Send only a FARP-REPLY or, - Perform a Login and send a FARP-REPLY. No sequence initiative is transferred with the FARP-REQ and therefore no Reply (ACCEPT or REJECT) follows this command. Since a Sequence Initiative is transferred with the FARP-REPLY, either a ACCEPT or REJECT follows this command as a response. Reception of a FARP-REQ requires a higher level entity at the responding node to send a FARP-REPLY or perform a Port Login. 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. The FARP Protocol Steps: FARP-REQ (ELS broadcast) Request Sequence (No Reply Sequence) FARP-REPLY (ELS command) Sequence Accept/Reject Reply Sequence The FARP Protocol Format [2] and Size: FT_1, 76-bytes fixed size The FARP Protocol Addressing: - 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. - 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. Rajagopal, et al. Standards Track [Page 19] RFC 2625 IP and ARP over Fibre Channel June 1999 5.3 FARP Command Format 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 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 | +-------------------------------------+---------+---------------------+ Rajagopal, et al. Standards Track [Page 20] RFC 2625 IP and ARP over Fibre Channel June 1999 +---------------------------------------------------------------------+ | 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. Port_ID of Requester: 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. Rajagopal, et al. Standards Track