rfc2625.txt

RFC 的详细文档！

   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).