tech-invite   World Map     

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

RFC 3821

 
 
 

Fibre Channel Over TCP/IP (FCIP)

Part 3 of 3, p. 47 to 74
Prev RFC Part

 


prevText      Top      Up      ToC       Page 47 
11.  References

11.1.  Normative References

   The references in this section were current as of the time this
   specification was approved.  This specification is intended to
   operate with newer versions of the referenced documents and looking
   for newer reference documents is recommended.

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Fibre Channel Backbone (FC-BB), ANSI INCITS.342:2001, December
        12, 2001.

   [3]  Fibre Channel Backbone -2 (FC-BB-2), ANSI INCITS.372:2003, July
        25, 2003.

   [4]  Fibre Channel Switch Fabric -2 (FC-SW-2), ANSI INCITS.355:2001,
        December 12, 2001.

   [5]  Fibre Channel Framing and Signaling (FC-FS), ANSI
        INCITS.373:2003, October 27, 2003.

   [6]  Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
        September 1981.

Top      Up      ToC       Page 48 
   [7]  Braden, R., "Requirements for Internet Hosts -- Communication
        Layers", STD 3, RFC 1122, October 1989.

   [8]  Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High
        Performance", RFC 1323, May 1992.

   [9]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
        Recommendations for Security", RFC 1750, December 1994.

   [10] Kent, S. and R. Atkinson, "Security Architecture for the
        Internet Protocol", RFC 2401, November 1998.

   [11] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- Hashing
        for Message Authentication", RFC 2104, February 1997.

   [12] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
        (ESP)", RFC 2406, November 1998.

   [13] Piper, D., "The Internet IP Security Domain of Interpretation of
        ISAKMP", RFC 2407, November 1998.

   [14] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
        RFC 2409, November 1998.

   [15] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its
        Use With IPsec", RFC 2410, November 1998.

   [16] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms",
        RFC 2451, November 1998.

   [17] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
        Location Protocol, version 2", RFC 2608, July 1999.

   [18] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "SACK
        Extension", RFC 2883, July 2000.

   [19] Weber, R., Rajagopal, M., Travostino, F., O'Donnell, M., Monia,
        C. and M. Merhar, "Fibre Channel (FC) Frame Encapsulation", RFC
        3643, December 2003.

   [20] Peterson, D., "Finding Fibre Channel over TCP/IP (FCIP) Entities
        Using Service Location Protocol version 2 (SLPv2)", RFC 3822,
        July 2004.

   [21] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F. Travostino,
        "Securing Block Storage Protocols over IP", RFC 3723, April
        2004.

Top      Up      ToC       Page 49 
   [22] Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher
        Algorithm and Its Use with IPsec", RFC 3602, September 2003.

   [23] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and
        Its Use With IPsec", RFC 3566, September 2003.

11.2.  Informative References

   [24] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High
        Performance", RFC 1323, May 1992.

   [25] Braden, R., Clark, D. and S. Shenker, "Integrated Services in
        the Internet Architecture: an Overview", RFC 1633, June 1994.

   [26] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
        IPv4, IPv6 and OSI", RFC 2030, October 1996.

   [27] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412,
        November 1998.

   [28] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
        the Differentiated Services Field (DS Field) in the IPv4 and
        Ipv6 Headers", RFC 2474, December 1998.

   [29] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
        Weiss, "An Architecture for Differentiated Services", RFC 2475,
        December 1998.

   [30] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,  "An
        Assured Forwarding PHB", RFC 2597, June 1999.

   [31] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited
        Forwarding PHB Group", RFC 2598, June 1999.

   [32] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label
        Switching Architecture", RFC 3031, January, 2001.

   [33] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic Host
        Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel
        Mode", RFC 3456, January 2003.

   [34] Kembel, R., "The Fibre Channel Consultant: A Comprehensive
        Introduction", Northwest Learning Associates, 1998.

Top      Up      ToC       Page 50 
12.  Acknowledgments

   The developers of this specification thank Mr. Jim Nelson for his
   assistance with FC-FS related issues.

   The developers of this specification express their appreciation to
   Mr. Mallikarjun Chadalapaka and Mr. David Black for their detailed
   and helpful reviews.

Top      Up      ToC       Page 51 
Appendix A. Fibre Channel Bit and Byte Numbering Guidance

   Both Fibre Channel and IETF standards use the same byte transmission
   order.  However, the bit and byte numbering is different.

   Fibre Channel bit and byte numbering can be observed if the data
   structure heading, shown in figure 11, is cut and pasted at the top
   of figure 7, figure 9, and figure 17.

   W|------------------------------Bit------------------------------|
   o|                                                               |
   r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1                    |
   d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0|

   Figure 11:  Fibre Channel Data Structure Bit and Byte Numbering

   Fibre Channel bit numbering for the pFlags field can be observed if
   the data structure heading, shown in figure 12, is cut and pasted at
   the top of figure 8.

       |----------------Bit--------------------|
       |                                       |
       | 31   30   29   28   27   26   25   24 |

   Figure 12:  Fibre Channel pFlags Bit Numbering

   Fibre Channel bit numbering for the Connection Usage Flags field can
   be observed if the data structure heading, shown in figure 13, is cut
   and pasted at the top of figure 10.

   |------------------------------Bit------------------------------|
   |                                                               |
   |   31      30      29      28      27      26      25      24  |

   Figure 13:  Fibre Channel Connection Usage Flags Bit Numbering

Appendix B. IANA Considerations

   IANA has made the following port assignments to FCIP:

      - fcip-port 3225/tcp FCIP
      - fcip-port 3225/udp FCIP

   IANA has changed the authority for these port allocations to
   reference this RFC.

   Use of UDP with FCIP is prohibited even though IANA has allocated a
   port.

Top      Up      ToC       Page 52 
   The FC Frame encapsulation used by this specification employs
   Protocol# value 1, as described in the IANA Considerations appendix
   of the FC Frame Encapsulation [19] specification.

Appendix C. FCIP Usage of Addresses and Identifiers

   In support of network address translators, FCIP does not use IP
   Addresses to identify FCIP Entities or FCIP_LEPs.  The only use of IP
   Addresses for identification occurs when initiating new TCP connect
   requests (see section 8.1.2.3) where the IP Address destination of
   the TCP connect request is used to answer the question: "Have
   previous TCP connect requests been made to the same destination FCIP
   Entity?"  The correctness of this assumption is further checked by
   sending the Destination FC Fabric Entity World Wide Name in the FCIP
   Special Frame (FSF) and having the value checked by the FCIP Entity
   that receives the TCP connect request and FSF (see section 8.1.3).

   For the purposes of processing incoming TCP connect requests, the
   source FCIP Entity is identified by the Source FC Fabric Entity World
   Wide Name and Source FC/FCIP Entity Identifier fields in the FSF sent
   from the TCP connect requestor to the TCP connect recipient as the
   first bytes following the TCP connect request (see section 8.1.2.3
   and section 8.1.3).

   FC-BB-2 [3] provides the definitions for each of the following FSF
   fields:

      -  Source FC Fabric Entity World Wide Name,
      -  Source FC/FCIP Entity Identifier, and
      -  Destination FC Fabric Entity World Wide Name.

   As described in section 8.1.3, FCIP Entities segregate their
   FCIP_LEPs between:

   -  Connections resulting from TCP connect requests initiated by the
      FCIP Entity, and

   -  Connections resulting from TCP connect requests received by the
      FCIP Entity.

   Within each of these two groups, the following information is used to
   further identify each FCIP_LEP:

      -  Source FC Fabric Entity World Wide Name,
      -  Source FC/FCIP Entity Identifier, and
      -  Destination FC Fabric Entity World Wide Name.

Top      Up      ToC       Page 53 
Appendix D. Example of Synchronization Recovery Algorithm

   The contents of this annex are informative.

   Synchronization may be recovered as specified in section 5.6.2.3.  An
   example of an algorithm for searching the bytes delivered to the
   Encapsulated Frame Receiver Portal for a valid FCIP Frame header is
   provided in this annex.

   This resynchronization uses the principle that a valid FCIP data
   stream must contain at least one valid header every 2176 bytes (the
   maximum length of an encapsulated FC Frame).  Although other data
   patterns containing apparently valid headers may be contained in the
   stream, the FC CRC or FCIP Frame validity of the data patterns
   contained in the data stream will always be either interrupted by or
   resynchronized with the valid FCIP Frame headers.

   Consider the case shown in figure 14.  A series of short FCIP Frames,
   perhaps from a trace, are embedded in larger FCIP Frames, say as a
   result of a trace file being transferred from one disk to another.
   The headers for the short FCIP Frames are denoted SFH and the long
   FCIP Frame headers are marked as LFH.

      +-+--+-+----+-+----+-+----+-+-+-+---+-+---
      |L|  |S|    |S|    |S|    |S| |L|   |S|
      |F|  |F|    |F|    |F|    |F| |F|   |F|...
      |H|  |H|    |H|    |H|    |H| |H|   |H|
      +-+--+-+----+-+----+-+----+-+-+-+---+-+---
      |                             |
      |<---------2176 bytes-------->|

      Figure 14:  Example of resynchronization data stream

   A resynchronization attempt that starts just to the right of an LFH
   will find several SFH FCIP Frames before discovering that they do not
   represent the transmitted stream of FCIP Frames.  Within 2176 bytes
   plus or minus, however, the resynchronization attempt will encounter
   an SFH whose length does not match up with the next SFH because the
   LFH will fall in the middle of the short FCIP Frame pushing the next
   header farther out in the byte stream.

   Note that the resynchronization algorithm cannot forward any
   prospective FC Frames to the FC Frame Transmitter Portal because,
   until synchronization is completely established, there is no
   certainty that anything that looked like an FCIP Frame really was
   one.  For example, an SFH might fortuitously contain a length that

Top      Up      ToC       Page 54 
   points exactly to the beginning of an LFH.  The LFH would identify
   the correct beginning of a transmitted FCIP Frame, but that in no way
   guarantees that the SFH was also a correct FCIP Frame header.

   There exist some data streams that cannot be resynchronized by this
   algorithm.  If such a data stream is encountered, the algorithm
   causes the TCP Connection to be closed.

   The resynchronization assumes that security and authentication
   procedures outside the FCIP Entity are protecting the valid data
   stream from being replaced by an intruding data stream containing
   valid FCIP data.

   The following steps are one example of how an FCIP_DE might
   resynchronize with the data stream entering the Encapsulated Frame
   Receiver Portal.

   1) Search for candidate and strong headers:

      The data stream entering the Encapsulated Frame Receiver Portal is
      searched for 12 bytes in a row containing the required values for:

         a) Protocol field,
         b) Version field,
         c) ones complement of the Protocol field,
         d) ones complement of the Version field,
         e) replication of encapsulation word 0 in word 1, and
         f) pFlags field and its ones complement.

      If such a 12-byte grouping is found, the FCIP_DE assumes that it
      has identified bytes 0-2 of a candidate FCIP encapsulation header.

      All bytes up to and including the candidate header byte are
      discarded.

      If no candidate header has been found after searching a specified
      number of bytes greater than some multiple of 2176 (the maximum
      length of an FCIP Frame), resynchronization has failed and the
      TCP/IP connection is closed.

      Word 3 of the candidate header contains the Frame Length and Flags
      fields and their ones complements.  If the fields are consistent
      with their ones complements, the candidate header is considered a
      strong candidate header.  The Frame Length field is used to
      determine where in the byte stream the next strong candidate
      header should be and processing continues at step 2).

Top      Up      ToC       Page 55 
   2) Use multiple strong candidate headers to locate a verified
      candidate header:

      The Frame Length in one strong candidate header is used to skip
      incoming bytes until the expected location of the next strong
      candidate header is reached.  Then the tests described in step 1)
      are applied to see if another strong candidate header has
      successfully been located.

      All bytes skipped and all bytes in all strong candidate headers
      processed are discarded.

      Strong candidate headers continue to be verified in this way for
      at least 4352 bytes (twice the maximum length of an FCIP Frame).
      If at any time a verification test fails, processing restarts at
      step 1 and a retry counter is incremented.  If the retry counter
      exceeds 3 retries, resynchronization has failed and the TCP
      Connection is closed, and the FC entity is notified with the
      reason for the closure.

      After strong candidate headers have been verified for at least
      4352 bytes, the next header identified is a verified candidate
      header, and processing continues at step 3).

      Note: If a strong candidate header was part of the data content of
      an FCIP Frame, the FCIP Frame defined by that or a subsequent
      strong candidate header will eventually cross an actual header in
      the byte stream.  As a result it will either identify the actual
      header as a strong candidate header or it will lose
      synchronization again because of the extra 28 bytes in the length,
      returning to step 1 as described above.

   3) Use multiple strong candidate headers to locate a verified
      candidate header:

      Incoming bytes are inspected and discarded until the next verified
      candidate header is reached.  Inspection of the incoming bytes
      includes testing for other candidate headers using the criteria
      described in step 1.  Each verified candidate header is tested
      against the tests listed in section 5.6.2.2 as would normally be
      the case.

      Verified candidate headers continue to be located and tested in
      this way for a minimum of 4352 bytes (twice the maximum length of
      an FCIP Frame).  If all verified candidate headers encountered are
      valid, the last verified candidate header is a valid header.  At
      this point the FCIP_DE stops discarding bytes and begins normal

Top      Up      ToC       Page 56 
      FCIP de-encapsulation, including for the first time since
      synchronization was lost, delivery of FC Frames through the FC
      Frame Transmitter Portal according to normal FCIP rules.

      If any verified candidate headers are invalid but meet all the
      requirements of a strong candidate header, increment the retry
      counter and return to step 2).  If any verified candidate headers
      are invalid and fail to meet the tests for a strong candidate
      header, or if inspection of the bytes between verified candidate
      headers discovers any candidate headers, increment the retry
      counter and return to step 1.  If the retry counter exceeds 4
      retries, resynchronization has failed and the TCP/IP connection is
      closed.

Top      Up      ToC       Page 57 
      A flowchart for this algorithm can be found in figure 15.

                        Synchronization is lost
                                 |
                    _____________v_______________
                   |                             |
                   | Search for candidate header |
      +----------->|                             |
      |            |   Found           Not Found |
      |            | (Strong candidate)          |
      |            |_____________________________|
      |                    |              |
      |                    |              + --------->close TCP
      |             _______v_____________________     Connection
      |            |                             |    and notify
      |            |   Enough strong candidate   |    the FC Entity
      |      +---->|     headers identified?     |    with the reason
      |      |     |                             |    for closure
      |      |     |     No               Yes    |
      |      |     |        (Verified candidate) |
      |      |     |_____________________________|
      |___________________|                |
      ^      |                             |
      |      |                             |
      |      |      _______________________v_____
      |      |     |                             |
      |      |     | Enough verified candidate   |
      |      |     |   headers validated?        |
      |      |     |                             |
      |      |     |     No               Yes    |
      |      |     |            (Resynchronized) |
      |      |     |_____________________________|
      |      |            |                |
      |      |      ______v__________      |      Resume
      |      |     |                 |     + ---> Normal
      |      |     | Synchronization |            De-encapsulation
      |      |     |      Lost?      |
      |      |     |                 |
      |      |     | No          Yes |
      |      |     |_________________|
      |      |        |           |
      |      |________|           |
      |___________________________|

      Figure 15:  Flow diagram of simple synchronization example

Top      Up      ToC       Page 58 
Appendix E. Relationship between FCIP and IP over FC (IPFC)

   The contents of this annex are informative.

   IPFC (RFC 2625) describes the encapsulation of IP packets in FC
   Frames.  It is intended to facilitate IP communication over an FC
   network.

   FCIP describes the encapsulation of FC Frames in TCP segments, which
   in turn are encapsulated inside IP packets for transporting over an
   IP network.  It gives no consideration to the type of FC Frame that
   is being encapsulated.  Therefore, the FC Frame may actually contain
   an IP packet as described in the IP over FC specification (RFC
   2625).  In such a case, the data packet would have:

      -  Data Link Header
      -  IP Header
      -  TCP Header
      -  FCIP Header
      -  FC Header
      -  IP Header

   Note: The two IP headers would not be identical to each other.  One
   would have information pertaining to the final destination, while the
   other would have information pertaining to the FCIP Entity.

   The two documents focus on different objectives.  As mentioned above,
   implementation of FCIP will lead to IP encapsulation within IP.
   While perhaps inefficient, this should not lead to issues with IP
   communication.  One caveat: if a Fibre Channel device is
   encapsulating IP packets in an FC Frame (e.g., an IPFC device), and
   that device is communicating with a device running IP over a non-FC
   medium, a second IPFC device may need to act as a gateway between the
   two networks.  This scenario is not specifically addressed by FCIP.

   There is nothing in either of the specifications to prevent a single
   device from implementing both FCIP and IP-over-FC (IPFC), but this is
   implementation specific, and is beyond the scope of this document.

Top      Up      ToC       Page 59 
Appendix F. FC Frame Format

   Note: All users of the words "character" or "characters" in this
   section refer to 8bit/10bit link encoding wherein each 8 bit
   "character" within a link frame is encoded as a 10 bit "character"
   for link transmission.  These words do not refer to ASCII, Unicode,
   or any other form of text characters, although octets from such
   characters will occur as 8 bit "characters" for this encoding.  This
   usage is employed here for consistency with the ANSI T11 standards
   that specify Fibre Channel.

   The contents of this annex are informative.

   All FC Frames have a standard format (see FC-FS [5]) much like LAN's
   802.x protocols.  However, the exact size of each FC 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 figure 16, resulting in the minimum size FC Frame of 36
   bytes and the maximum size FC Frame of 2148 bytes.  Valid FC Frame
   lengths are always a multiple of four bytes.

   +------+--------+-----------+----//-------+------+------+
   | SOF  |Frame   |Optional   |  Frame      | CRC  |  EOF |
   | (4B) |Header  |Header     | Payload     | (4B) | (4B) |
   |      |(24B)   |<----------------------->|      |      |
   |      |        | Data Field = (0-2112B)  |      |      |
   +------+--------+-----------+----//-------+------+------+

   Figure 16:  FC Frame Format

   SOF and EOF Delimiters

      On an FC link, Start-of-Frame (SOF) and End-Of-Frame (EOF) are
      called Ordered Sets and are sent as special words constructed from
      the 8B/10B comma character (K28.5) followed by three additional
      8B/10B data characters making them uniquely identifiable in the
      data stream.

      On an FC link, the SOF delimiter serves to identify the beginning
      of an FC Frame and prepares the receiver for FC Frame reception.
      The SOF contains information about the FC Frame's Class of
      Service, position within a sequence, and in some cases, connection
      status.

      The EOF delimiter identifies the end of the FC Frame and the final
      FC Frame of a sequence.  In addition, it serves to force the
      running disparity to negative.  The EOF is used to end the
      connection in connection-oriented classes of service.

Top      Up      ToC       Page 60 
      A special EOF delimiter called EOFa (End Of Frame - Abort) is used
      to terminate a partial FC Frame resulting from a malfunction in a
      link facility during transmission.  Since an FCIP Entity functions
      like a transmission link with respect to the rest of the FC
      Fabric, FCIP_DEs may use EOFa in their error recovery procedures.

      It is therefore important to preserve the information conveyed by
      the delimiters across the IP-based network, so that the receiving
      FCIP Entity can correctly reconstruct the FC Frame in its original
      SOF and EOF format before forwarding it to its ultimate FC
      destination on the FC link.

      When an FC Frame is encapsulated and sent over a byte-oriented
      interface, the SOF and EOF delimiters are represented as sequences
      of four consecutive bytes, which carry the equivalent Class of
      Service and FC Frame termination information as the FC ordered
      sets.

      The representation of SOF and EOF in an encapsulation FC Frame is
      described in FC Frame Encapsulation [19].

   Frame Header

      The FC Frame Header is transparent to the FCIP Entity.  The FC
      Frame Header is 24 bytes long and has several fields that are
      associated with the identification and control of the payload.
      Current FC Standards allow up to 3 Optional Header fields [5]:

      - Network_Header (16-bytes)
      - Association_Header (32-bytes)
      - Device_Header (up to 64-bytes).

   Frame Payload

      The FC Frame Payload is transparent to the FCIP Entity.  An FC
      application level payload is called an Information Unit at the
      FC-4 Level.  This is mapped into the FC Frame Payload of the FC
      Frame.  A large Information Unit is segmented using a structure
      consisting of FC Sequences.  Typically, a Sequence consists of
      more than one FC Frame.  FCIP does not maintain any state
      information regarding the relationship of FC Frames within an FC
      Sequence.

   CRC

      The FC 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.  This CRC value is calculated over the entire FC

Top      Up      ToC       Page 61 
      header and the FC payload; it does not include the SOF and EOF
      delimiters.

      Note: When FC Frames are encapsulated into FCIP Frames, the FC
      Frame CRC is untouched by the FCIP Entity.

Appendix G. FC Encapsulation Format

   This annex contains a reproduction of the FC Encapsulation Format
   [19] as it applies to FCIP Frames that encapsulate FC Frames.  The
   information in this annex is not intended to represent the FCIP
   Special Frame (FSF) that is described in section 7.

   The information in this annex was correct as of the time this
   specification was approved.  The information in this annex is
   informative only.

   If there are any differences between the information here and the FC
   Encapsulation Format specification [19], the FC Encapsulation Format
   specification takes precedence.

   If there are any differences between the information here and the
   contents of section 5.6.1, then the contents of section 5.6.1 take
   precedence.

   Figure 17 applies the requirements stated in section 5.6.1 and in the
   FC Encapsulation Frame format resulting in a summary of the FC Frame
   format.  Where FCIP requires specific values, those values are shown
   in hexadecimal in parentheses.  Detailed requirements for the FCIP
   usage of the FC Encapsulation Format are in section 5.6.1.

Top      Up      ToC       Page 62 
   W|------------------------------Bit------------------------------|
   o|                                                               |
   r|                    1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
   d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
    +---------------+---------------+---------------+---------------+
   0|   Protocol#   |    Version    |  -Protocol#   |   -Version    |
    |    (0x01)     |    (0x01)     |     (0xFE)    |    (0xFE)     |
    +---------------+---------------+---------------+---------------+
   1|   Protocol#   |    Version    |  -Protocol#   |   -Version    |
    |    (0x01)     |    (0x01)     |     (0xFE)    |    (0xFE)     |
    +---------------+---------------+---------------+---------------+
   2|    pFlags     |    Reserved   |    -pFlags    |  -Reserved    |
    |     (0x00)    |     (0x00)    |     (0xFF)    |    (0xFF)     |
    +-----------+---+---------------+-----------+---+---------------+
   3|   Flags   |   Frame Length    |   -Flags  |   -Frame Length   |
    |   (0x00)  |                   |   (0x3F)  |                   |
    +-----------+-------------------+-----------+-------------------+
   4|                      Time Stamp [integer]                     |
    +---------------------------------------------------------------+
   5|                      Time Stamp [fraction]                    |
    +---------------------------------------------------------------+
   6|                     CRC (Reserved in FCIP)                    |
    |                        (0x00-00-00-00)                        |
    +---------------+---------------+---------------+---------------+
   7|      SOF      |      SOF      |     -SOF      |     -SOF      |
    +---------------+---------------+---------------+---------------+
   8|                                                               |
    +-----            FC Frame content (see appendix F)        -----+
    |                                                               |
    +---------------+---------------+---------------+---------------+
   n|      EOF      |      EOF      |     -EOF      |     -EOF      |
    +---------------+---------------+---------------+---------------+

   Figure 17:  FCIP Frame Format

   The names of fields are generally descriptive on their contents and
   the FC Encapsulation Format specification [19] is referenced for
   details.  Field names preceded by a minus sign are ones complement
   values of the named field.

   Note: Figure 17 does not represent the FSF that is described in
   section 7.

Top      Up      ToC       Page 63 
Appendix H. FCIP Requirements on an FC Entity

   The contents of this annex are informative for FCIP but might be
   considered normative on FC-BB-2.

   The capabilities that FCIP requires of an FC Entity include:

   1) The FC Entity must deliver FC Frames to the correct FCIP Data
      Engine (in the correct FCIP Link Endpoint).

   2) Each FC Frame delivered to an FCIP_DE must be accompanied by a
      time value synchronized with the clock maintained by the FC Entity
      at the other end of the FCIP Link (see section 6).  If a
      synchronized time value is not available, a value of zero must
      accompany the FC Frame.

   3) When FC Frames exit FCIP Data Engine(s) via the FC Frame
      Transmitter Portal(s), the FC Entity should forward them to the FC
      Fabric.  However, before forwarding an FC Frame, the FC Entity
      must compute the end-to-end transit time for the FC Frame using
      the time value supplied by the FCIP_DE (taken from the FCIP
      header) and a synchronized time value (see section 6).  If the
      end-to-end transit time exceeds the requirements of the FC Fabric,
      the FC Entity is responsible for discarding the FC Frame.

   4) The only delivery ordering guarantee provided by FCIP is correctly
      ordered delivery of FC Frames between a pair of FCIP Data Engines.
      FCIP expects the FC Entity to implement all other FC Frame
      delivery ordering requirements.

   5) When a TCP connect request is received and that request would add
      a new TCP Connection to an existing FCIP_LEP, the FC Entity must
      authenticate the source of the TCP connect request before use of
      the new TCP connection is allowed.

   6) The FC Entity may participate in determining allowed TCP
      Connections, TCP Connection parameters, quality of service usage,
      and security usage by modifying interactions with the FCIP Entity
      that are modelled as a "shared" database in section 8.1.1.

   7) The FC Entity may require the FCIP Entity to perform TCP close
      requests.

   8) The FC Entity may recover from connection failures.

   9) The FC Entity must recover from events that the FCIP Entity cannot
      handle, such as:

Top      Up      ToC       Page 64 
      a) loss of synchronization with FCIP Frame headers from the
         Encapsulated Frame Receiver Portal requiring resetting the TCP
         Connection; and

      b) recovering from FCIP Frames that are discarded as a result of
         synchronization problems (see section 5.6.2.2 and section
         5.6.2.3).

   10) The FC Entity must work cooperatively with the FCIP Entity to
       manage flow control problems in either the IP Network or FC
       Fabric.

   11) The FC Entity may test for failed TCP Connections.

       Note that the Fibre Channel standards must be consulted for a
       complete understanding of the requirements placed on an FC
       Entity.

       Table 2 shows the explicit interactions between the FCIP Entity
       and the FC Entity.

   +-------------+-----------------+-----------------------------------+
   |             |                 | Information/Parameter Passed and  |
   |             |                 |             Direction             |
   | Reference   |                 +-----------------+-----------------+
   |  Section    |    Condition    | FCIP Entity---> | <---FC Entity   |
   +-------------+-----------------+-----------------+-----------------+
   | 5.6         | FC Frame ready  |                 | Provide FC      |
   | FCIP Data   | for IP transfer |                 | Frame and       |
   | Engine      |                 |                 | time stamp at   |
   |             |                 |                 | FC Frame        |
   |             |                 |                 | Receiver Portal |
   +-------------+-----------------+-----------------+-----------------+
   | WWN = World Wide Name                                             |
   +-------------------------------------------------------------------+
   |                           continued                               |
   +-------------------------------------------------------------------+

   Table 2:  FC/FCIP Entity pair interactions (part 1 of 5)

Top      Up      ToC       Page 65 
   +-------------+-----------------+-----------------------------------+
   |             |                 | Information/Parameter Passed and  |
   |             |                 |             Direction             |
   | Reference   |                 +-----------------+-----------------+
   |  Section    |    Condition    | FCIP Entity---> | <---FC Entity   |
   +-------------+-----------------+-----------------+-----------------+
   |                           continued                               |
   +-------------+-----------------+-----------------+-----------------+
   | 5.6         | FCIP Frame      | Provide FC      |                 |
   | FCIP Data   | received from   | Frame and       |                 |
   | Engine      | IP Network      | time stamp at   |                 |
   |             |                 | FC Frame Trans- |                 |
   |             |                 | mitter Portal   |                 |
   +-------------+-----------------+-----------------+-----------------+
   | 5.6.2.2     | FCIP_DE         | Inform FC       |                 |
   | Errors      | discards bytes  | Entity that     |                 |
   | in FCIP     | delivered       | bytes have been |                 |
   | Headers and | through         | discarded with  |                 |
   | Discarding  | Encapsulated    | reason          |                 |
   | FCIP Frames | Frame Receiver  |                 |                 |
   |             | Portal          |                 |                 |
   +-------------+-----------------+-----------------+-----------------+
   | 5.6.2.3     | FCIP Entity     | Inform FC       |                 |
   | Synchron-   | closes TCP      | Entity that TCP |                 |
   | ization     | Connection due  | Connection has  |                 |
   | Failures    | to synchron-    | been closed     |                 |
   |             | ization failure | with reason     |                 |
   |             |                 | for closure     |                 |
   +-------------+-----------------+-----------------+-----------------+
   | 8.1.2.3     | Receipt of the  | Inform FC       |                 |
   | Connection  | echoed FSF      | Entity that TCP |                 |
   | Setup       | takes too long  | Connection has  |                 |
   | Following a | or the FSF      | been closed     |                 |
   | Successful  | contents have   | with reason     |                 |
   | TCP Connect | changed         | for closure     |                 |
   | Request     |                 |                 |                 |
   +-------------+-----------------+-----------------+-----------------+
   | WWN = World Wide Name                                             |
   +-------------------------------------------------------------------+
   |                           continued                               |
   +-------------------------------------------------------------------+

   Table 2:  FC/FCIP Entity pair interactions (part 2 of 5)

Top      Up      ToC       Page 66 
   +-------------+-----------------+-----------------------------------+
   |             |                 | Information/Parameter Passed and  |
   |             |                 |             Direction             |
   | Reference   |                 +-----------------+-----------------+
   |  Section    |    Condition    | FCIP Entity---> | <---FC Entity   |
   +-------------+-----------------+-----------------+-----------------+
   |                           continued                               |
   +-------------+-----------------+-----------------+-----------------+
   | 8.1.2.1     | New TCP         | Inform FC       |                 |
   | Non-Dynamic | Connection      | Entity of       |                 |
   | Creation of | created based   | new or existing |                 |
   | a New TCP   | on "shared"     | FCIP_LEP and    |                 |
   | Connections | database        | new FCIP_DE     |                 |
   |             | information     | along with      |                 |
   |             |                 | Destination FC  |                 |
   |             |                 | Fabric Entity   |                 |
   |             |                 | WWN, Connection |                 |
   |             |                 | Usage Flags,    |                 |
   |             |                 | Connection      |                 |
   |             |                 | Usage Code and  |                 |
   |             |                 | Connection      |                 |
   |             |                 | Nonce           |                 |
   +-------------+-----------------+-----------------+-----------------+
   | 8.1.2.2     | New TCP         | Inform FC       |                 |
   | Dynamic     | Connection      | Entity of       |                 |
   | Creation of | created based   | new or existing |                 |
   | a New TCP   | on SLP service  | FCIP_LEP and    |                 |
   | Connections | advertisement   | new FCIP_DE     |                 |
   |             | and "shared"    | along with      |                 |
   |             | database        | Destination FC  |                 |
   |             | information     | Fabric Entity   |                 |
   |             |                 | WWN, Connection |                 |
   |             |                 | Usage Flags,    |                 |
   |             |                 | Connection      |                 |
   |             |                 | Usage Code and  |                 |
   |             |                 | Connection      |                 |
   |             |                 | Nonce           |                 |
   +-------------+-----------------+-----------------+-----------------+
   | WWN = World Wide Name                                             |
   +-------------------------------------------------------------------+
   |                           continued                               |
   +-------------------------------------------------------------------+

   Table 2:  FC/FCIP Entity pair interactions (part 3 of 5)

Top      Up      ToC       Page 67 
   +-------------+-----------------+-----------------------------------+
   |             |                 | Information/Parameter Passed and  |
   |             |                 |             Direction             |
   | Reference   |                 +-----------------+-----------------+
   |  Section    |    Condition    | FCIP Entity---> | <---FC Entity   |
   +-------------+-----------------+-----------------+-----------------+
   |                           continued                               |
   +-------------+-----------------+-----------------+-----------------+
   | 8.1.3       | New TCP         | Inform FC       |                 |
   | Processing  | Connection      | Entity of       |                 |
   | Incoming    | created based   | new or existing |                 |
   | TCP Connect | on incoming TCP | FCIP_LEP and    |                 |
   | Requests    | Connect request | new FCIP_DE     |                 |
   |             | and "shared"    | along with      |                 |
   |             | database        | Source FC       |                 |
   |             | information     | Fabric Entity   |                 |
   |             |                 | WWN, Source     |                 |
   |             |                 | FC/FCIP Entity  |                 |
   |             |                 | Identifier,     |                 |
   |             |                 | Connection      |                 |
   |             |                 | Usage Flags,    |                 |
   |             |                 | Connection      |                 |
   |             |                 | Usage Code and  |                 |
   |             |                 | Connection      |                 |
   |             |                 | Nonce           |                 |
   +-------------+-----------------+-----------------+-----------------+
   | 8.1.3       | TCP Connect     | Request FC      | Yes or No       |
   | Processing  | Request wants   | Entity to       | answer about    |
   | Incoming    | to add a new    | authenticate    | whether the     |
   | TCP Connect | TCP Connection  | the source of   | source of the   |
   | Requests    | to an existing  | the TCP Connect | TCP Connect     |
   |             | FCIP_LEP        | Request         | Request can be  |
   |             |                 |                 | authenticated   |
   +-------------+-----------------+-----------------+-----------------+
   | 8.1.3       | Receipt of the  | Inform FC       |                 |
   | Processing  | FSF takes too   | Entity that TCP |                 |
   | Incoming    | long or         | Connection has  |                 |
   | TCP Connect | duplicate       | been closed     |                 |
   | Requests    | Connection      | with reason     |                 |
   |             | Nonce value     | for closure     |                 |
   +-------------+-----------------+-----------------+-----------------+
   | WWN = World Wide Name                                             |
   +-------------------------------------------------------------------+
   |                           continued                               |
   +-------------------------------------------------------------------+

   Table 2:  FC/FCIP Entity pair interactions (part 4 of 5)

Top      Up      ToC       Page 68 
   +-------------+-----------------+-----------------------------------+
   |             |                 | Information/Parameter Passed and  |
   |             |                 |             Direction             |
   | Reference   |                 +-----------------+-----------------+
   |  Section    |    Condition    | FCIP Entity---> | <---FC Entity   |
   +-------------+-----------------+-----------------+-----------------+
   |                           concluded                               |
   +-------------+-----------------+-----------------+-----------------+
   | 8.2         | FC Entity       | Acknowledgement | Identification  |
   | Closing TCP | determines      | of TCP          | of the FCIP_DE  |
   | Connections | that a TCP      | Connection      | whose TCP       |
   |             | Connection      | closure         | Connection      |
   |             | needs to be     |                 | needs to be     |
   |             | closed          |                 | closed          |
   +-------------+-----------------+-----------------+-----------------+
   | 8.4         | Discovery that  | Inform FC       |                 |
   | TCP         | TCP connectiv-  | Entity that TCP |                 |
   | Connection  | ity has been    | Connection has  |                 |
   | Considera-  | lost            | been closed     |                 |
   | tions       |                 | with reason     |                 |
   |             |                 | for closure     |                 |
   +-------------+-----------------+-----------------+-----------------+
   | 9.4.1       | IKE phase 1     | Inform FC       |                 |
   | FCIP        | failed, result- | Entity that TCP |                 |
   | Link        | ing in termin-  | Connection can  |                 |
   | Initializ-  | ation of link   | not be opened   |                 |
   | ation Steps | initialization  | with reason for |                 |
   |             |                 | failure         |                 |
   +-------------+-----------------+-----------------+-----------------+
   | 9.4.3       | Excessive       | Inform FC       |                 |
   | Handling    | numbers of      | Entity that TCP |                 |
   | data        | dropped         | Connection has  |                 |
   | integrity   | datagrams       | been closed     |                 |
   | and confi-  | detected and    | with reason     |                 |
   | dentiality  | TCP Connection  | for closure     |                 |
   | violations  | closed          |                 |                 |
   +-------------+-----------------+-----------------+-----------------+
   | RFC 3723    | TCP Connection  | Inform FC       |                 |
   |             | closed due to   | Entity that TCP |                 |
   | Handling SA | SA parameter    | Connection has  |                 |
   | parameter   | mismatch        | been closed     |                 |
   | mismatches  | problems        | with reason     |                 |
   |             |                 | for closure     |                 |
   +-------------+-----------------+-----------------+-----------------+
   | WWN = World Wide Name                                             |
   +-------------------------------------------------------------------+

   Table 2:  FC/FCIP Entity pair interactions (part 5 of 5)

Top      Up      ToC       Page 69 
Editors and Contributors Acknowledgements

   During the development of this specification, Murali Rajagopal,
   Elizabeth Rodriguez, Vi Chau, and Ralph Weber served consecutively as
   editors.  Raj Bhagwat contributed substantially to the initial basic
   FCIP concepts.

   Venkat Rangan contributed the Security section and continues to
   coordinate security issues with the ips Working Group and IETF.

   Andy Helland contributed a substantial revision of Performance
   section, aligning it with TCP/IP QoS concepts.

   Dave Peterson contributed the dynamic discovery section and edits to
   RFC 3822.

   Anil Rijhsinghani contributed material related to the FCIP MIB and
   edits the FCIP MIB document.

   Bob Snively contributed material related to error detection and
   recovery including the bulk of the synchronization recovery example
   annex.

   Lawrence J. Lamers contributed numerous ideas focused on keeping FCIP
   compatible with B_Port devices.

   Milan Merhar contributed several of the FCIP conceptual modifications
   necessary to support NATs.

   Don Fraser contributed material related to link failure detection and
   reporting.

   Bill Krieg contributed a restructuring of the TCP Connection setup
   sections that made them more linear with respect to time and more
   readable.

   Several T11 leaders supported this effort and advised the editors of
   this specification regarding coordination with T11 documents and
   projects.  These T11 leaders are: Jim Nelson (Framing and Signaling),
   Neil Wanamaker (Framing and Signaling), Craig Carlson (Generic
   Services), Ken Hirata (Switch Fabric), Murali Rajagopal (Backbone),
   Steve Wilson (Switch Fabric), and Michael O'Donnell (Security
   Protocols).

Top      Up      ToC       Page 70 
Editors and Contributors Addresses

   Neil Wanamaker
   Akara
   10624 Icarus Court
   Austin, TX 78726
   USA

   Phone: +1 512 257 7633
   Fax: +1 512 257 7877
   EMail: nwanamaker@akara.com

   Ralph Weber
   ENDL Texas, representing Brocade
   Suite 102 PMB 178
   18484 Preston Road
   Dallas, TX 75252
   USA

   Phone: +1 214 912 1373
   EMail: roweber@ieee.org

   Elizabeth G. Rodriguez
   Dot Hill Systems Corp.
   6305 El Camino Real
   Carlsbad, CA 92009
   USA

   Phone: +1 760 431 4435
   EMail: elizabeth.rodriguez@dothill.com

   Steve Wilson
   Brocade Comm. Systems, Inc.
   1745 Technology Drive
   San Jose, CA. 95110
   USA

   Phone: +1 408 333 8128
   EMail: swilson@brocade.com

Top      Up      ToC       Page 71 
   Bob Snively
   Brocade Comm. Systems, Inc.
   1745 Technology Drive
   San Jose, CA 95110
   USA

   Phone: +1 408 303 8135
   EMail: rsnively@brocade.com

   David Peterson
   Cisco Systems - SRBU
   6450 Wedgwood Road
   Maple Grove, MN 55311
   USA

   Phone: +1 763 398 1007
   Cell: +1 612 802 3299
   EMail: dap@cisco.com

   Donald R. Fraser
   Hewlett-Packard
   301 Rockrimmon Blvd., Bldg. 5
   Colorado Springs, CO 80919
   USA

   Phone: +1 719 548 3272
   EMail: Don.Fraser@HP.com

   R. Andy Helland
   LightSand Communications, Inc.
   375 Los Coches Street
   Milpitas, CA 95035
   USA

   Phone: +1 408 404 3119
   Fax: +1 408 941 2166
   EMail: andyh@lightsand.com

   Raj Bhagwat
   LightSand Communications, Inc.
   24411 Ridge Route Dr.
   Suite 135
   Laguna Hills, CA 92653
   USA

   Phone: +1 949 837 1733 x104
   EMail: rajb@lightsand.com

Top      Up      ToC       Page 72 
   Bill Krieg
   Lucent Technologies
   200 Lucent Lane
   Cary, NC 27511
   USA

   Phone: +1 919 463 4020
   Fax: +1 919 463 4041
   EMail: bkrieg@lucent.com

   Michael E. O'Donnell
   McDATA Corporation
   310 Interlocken Parkway
   Broomfield, CO 80021
   USA

   Phone: +1 303 460 4142
   Fax: +1 303 465 4996
   EMail: modonnell@mcdata.com

   Anil Rijhsinghani
   McDATA Corporation
   310 Interlocken Parkway
   Broomfield, CO 80021
   USA

   Phone: +1 508 870 6593
   EMail: anil.rijhsinghani@mcdata.com

   Milan J. Merhar
   43 Nagog Park
   Pirus Networks
   Acton, MA 01720
   USA

   Phone: +1 978 206 9124
   EMail: Milan@pirus.com

   Craig W. Carlson
   QLogic Corporation
   6321 Bury Drive
   Eden Prairie, MN 55346
   USA

   Phone: +1 952 932 4064
   EMail: craig.carlson@qlogic.com

Top      Up      ToC       Page 73 
   Venkat Rangan
   Rhapsody Networks Inc.
   3450 W. Warren Ave.
   Fremont, CA 94538
   USA

   Phone: +1 510 743 3018
   Fax: +1 510 687 0136
   EMail: venkat@rhapsodynetworks.com

   Lawrence J. Lamers
   SAN Valley Systems, Inc.
   6320 San Ignacio Ave.
   San Jose, CA 95119-1209
   USA

   Phone: +1 408 234 0071
   EMail: ljlamers@ieee.org

   Murali Rajagopal
   Broadcom Corporation
   16215 Alton Parkway
   Irvine,CA 92619
   USA

   Phone: +1 949 450 8700
   EMail: muralir@broadcom.com

   Ken Hirata
   Vixel Corporation
   15245 Alton Parkway, Suite 100
   Irvine, CA 92618
   USA

   Phone: +1 949 788 6368
   Fax: +1 949 753 9500
   EMail: ken.hirata@vixel.com

   Vi Chau
   USA
   Email: vchau1@cox.net

Top      Up      ToC       Page 74 
Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.