tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2625


Pages: 63
Top     in Index     Prev     Next
 

IP and ARP over Fibre Channel

Part 1 of 3, p. 1 to 17
None       Next RFC Part

Obsoleted by:    4338


Top       ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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      ToC       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 RFC Part