Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2625

IP and ARP over Fibre Channel

Pages: 63
Obsoleted by:  4338
Part 1 of 3 – Pages 1 to 17
None   None   Next

ToP   noToC   RFC2625 - Page 1
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
ToP   noToC   RFC2625 - Page 2
      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
ToP   noToC   RFC2625 - Page 3
      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
ToP   noToC   RFC2625 - Page 4
   (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.
ToP   noToC   RFC2625 - Page 5
   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.
ToP   noToC   RFC2625 - Page 6
         +------+--------+-----------+----//-------+------+------+
         | 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.
ToP   noToC   RFC2625 - Page 7
   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.
ToP   noToC   RFC2625 - Page 8
   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.
ToP   noToC   RFC2625 - Page 9

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.
ToP   noToC   RFC2625 - Page 10
         +--------+---------------------------------------+
         | 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
ToP   noToC   RFC2625 - Page 11
   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.
ToP   noToC   RFC2625 - Page 12
   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
ToP   noToC   RFC2625 - Page 13
   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.
ToP   noToC   RFC2625 - Page 14
   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.
ToP   noToC   RFC2625 - Page 15
                     +-------------------------+
                     | 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.
ToP   noToC   RFC2625 - Page 16

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.
ToP   noToC   RFC2625 - Page 17
      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)

Next Section