[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 3643

INTERNET-DRAFT                                                  R. Weber
<draft-ietf-ips-fcenapsulation-00.txt>                           Brocade
(Expires: October 19, 2001)
Category: standards-track                                   M. Rajagopal
                                                LightSand Communications

                                                           F. Travostino
                           FC Frame Encapsulation        Nortel Networks

                                                                 V. Chau
                                                        Gadzoox Networks

                                                            M. O'Donnell
                                                                  McDATA

                                                                C. Monia
                                                          Nishan Systems

                                                               M. Merhar
                                                          Pirus Networks




Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on October 18, 2001.





Weber, et.al.            Expires October 19, 2001               [Page 1]


Internet-Draft               FC Encapsulation                 April 2001


Abstract

   This is the ips (IP Storage) working group draft describing the
   common encapsulation format for use by any IETF protocol that
   encapsulates Fibre Channel (FC) frames. This draft describes a
   frame header containing information mandated for encapsulating,
   transmitting, and de-encapsulating FC frames.

Conventions used in this document

   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 [2].


   1.  Encapsulation Concepts  . . . . . . . . . . . . . . . . . . .   3
   2.  The FC Encapsulation Header . . . . . . . . . . . . . . . . .   4
   2.1 FC Encapsulation Header Format  . . . . . . . . . . . . . . .   4
   2.2 FC Encapsulation Header Validation  . . . . . . . . . . . . .   6
   2.2.1 Redundancy based FC Encapsulation Header validation . . . .   6
   2.2.2 CRC based FC Encapsulation Header validation  . . . . . . .   6
   3.  The FC frame  . . . . . . . . . . . . . . . . . . . . . . . .   7
   3.1 FC frame content  . . . . . . . . . . . . . . . . . . . . . .   7
   3.2 Bit and Byte Ordering . . . . . . . . . . . . . . . . . . . .   7
   3.3 FC SOF and EOF  . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Security  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Author's Addresses  . . . . . . . . . . . . . . . . . . . . .   9
   7.  Full Copyright Statement  . . . . . . . . . . . . . . . . . .  10

  Annex
   A   Protocol Requirements . . . . . . . . . . . . . . . . . . . .  11
   B   IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11

















Weber, et.al.            Expires October 19, 2001               [Page 2]


Internet-Draft               FC Encapsulation                 April 2001


1. Encapsulation Concepts

   The smallest unit of data transmission and routing in Fibre Channel
   (FC) is the frame.  FC frames include a Start Of Frame (SOF), End
   Of Frame (EOF), CRC coverage of the FC Payload for error detection.
   FC frames have several possible lengths.  To facilitate transporting
   FC frames over TCP the native FC frame needs to be contained in
   (encapsulated in) a slightly larger structure as shown in Figure 1.

                  +--------------------+
                  |       Header       |
                  +--------------------+-----+
                  |        SOF         |   f |
                  +--------------------+ F r |
                  |  FC frame content  | C a |
                  +--------------------+   m |
                  |        EOF         |   e |
                  +--------------------+-----+

                Fig. 1 - FC frame Encapsulation

   The format and content of an FC frame is described in the FC
   standards (e.g., FC-FS [3], FC-SW-2 [4], and FC-PI [5]).  Of
   importance to this encapsulation is the FC requirement that all
   frames SHALL contain an CRC for detection of transmission errors.

   This document describes the encapsulation format only.  Actual use of
   this format in a protocol requires an additional document to specify
   the protocol functionality and appropriate security considerations.
   Because security considerations for this encapsulation depend on how
   it is used by protocols, they are taken up in protocol-specific
   documents.


















Weber, et.al.            Expires October 19, 2001               [Page 3]


Internet-Draft               FC Encapsulation                 April 2001


2. The FC Encapsulation Header

2.1 FC Encapsulation Header Format

   Figure 2 shows the format of the required FC Encapsulation Header.

     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|
      +---------------+---------------+---------------+---------------+
     0|   Protocol#   |  -Protocol#   |    Version    |   -Version    |
      +---------------+---------------+---------------+---------------+
     1|                                                               |
      +-----                  Protocol Specific                   ----+
     2|                                                               |
      +-----------+-------------------+-----------+-------------------+
     3|   Flags   |   Frame Length    |   -Flags  |   -Frame Length   |
      +-----------+-------------------+-----------+-------------------+
     4|                      Time Stamp [integer]                     |
      +---------------------------------------------------------------+
     5|                      Time Stamp [fraction]                    |
      +---------------------------------------------------------------+
     6|                              CRC                              |
      +---------------------------------------------------------------+

                Fig. 2 - FC Encapsulation Header Format

   The fields in the FC Encapsulation Header are defined as follows.

   Protocol (bits 31-24 in word 0): The Protocol# field SHALL contain
   a number that indicates which protocol is employing the FC
   Encapsulation.  The values in the Protocol# field are assigned
   by IANA [6].  The following values are known to be in use:

       FCIP -- TO BE ASSIGNED by IANA
       iFCP -- TO BE ASSIGNED by IANA

   -Protocol# (bits 23-16 in word 0): The -Protocol# field contains
   the ones complement of the contents of the Protocol# field. FC
   Encapsulation receivers may compare the Protocol# and -Protocol#
   fields as an additional verification that an FC Encapsulation Header
   is being processed.

   Version (bits 15-8 in word 0): The Version field SHALL contain 0x1
   to indicate that this version of the FC Encapsulation is being used.
   All other values are reserved for future versions of the FC
   Encapsulation.


Weber, et.al.            Expires October 19, 2001               [Page 4]


Internet-Draft               FC Encapsulation                 April 2001


   -Version (bits 7-0 in word 0): The -Version field contains the ones
   complement of the contents of the Version field. FC Encapsulation
   receivers may compare the Version and -Version fields as an
   additional verification that an FC Encapsulation Header is being
   processed.

   Protocol Specific (words 1 and 2):  The usage of these words differs
   based on the contents of the Protocol# field, i.e., the usage of this
   word is defined by the protocol that is employing this encapsulation.

   Flags (bits 31-26 in word 3): The Flags bits provide information
   about the usage of the FC Encapsulation Header as shown in Figure 3.

      |------------------------Bit--------------------------|
      |                                                     |
      |   31       30       29       28       27       26   |
      +--------------------------------------------+--------+
      |                  Reserved                  |  CRCV  |
      +--------------------------------------------+--------+

                   Fig. 3 - Flags Field Format

      Reserved (Flag bits 31-27 in word 3):  These bits are reserved for
      use by future versions of the FC Encapsulation and SHALL be zero.

      CRCV (CRC Valid Flag, bit 26 in word 3):  A CRCV bit value of one
      indicates that the contents of the CRC field are valid. A CRCV bit
      value of zero indicates that CRC are invalid.  Some protocols may
      always check the CRC without regard for the state of this bit. The
      value of the CRCV bit SHALL be constant for all FC Encapsulation
      Headers sent on a given TCP connection.

   Frame Length (bits 25-16 in word 3): The Frame Length field contains
   the length of the entire FC Encapsulated frame including the FC
   Encapsulation Header and the FC frame (including SOF and EOF words).
   This length is based on a unit of 32-bit words.  All FC frames are
   32-bit-word-aligned and the FC Encapsulation Header SHALL always be
   word-aligned; therefore a 32-bit word length is acceptable.

   -Flags (bits 15-10 in word 3): The -Flags field contains the ones
   complement of the contents of the Flags field. FC Encapsulation
   receivers may compare the Flags and -Flags fields as an additional
   verification that an FC Encapsulation Header is being processed.

   -Frame Length (bits 9-0 in word 3): The -Frame Length field contains
   the ones complement of the contents of the Frame Length field. FC
   Encapsulation receivers may compare the Frame Length and -Frame
   Length fields as an additional verification that an FC Encapsulation
   Header is being processed.

Weber, et.al.            Expires October 19, 2001               [Page 5]


Internet-Draft               FC Encapsulation                 April 2001


   Time Stamp [integer] and Time Stamp [fraction] (words 4 and 5):  The
   two Time Stamp contain time at which the FC Encapsulated frame was
   sent as known to the sender.  The format of integer and fraction Time
   Stamp word values is specified in Simple Network Time Protocol (SNTP)
   Version 4 [7].  When the sending time is unknown, the Time Stamp
   [integer] and Time Stamp [fraction] words SHALL contain zero.

   CRC (word 6): When the CRCV Flag bit is zero, the CRC field SHALL
   contain zero. When the CRCV Flag bit is one, the CRC field SHALL
   contain a CRC for words 0 to 5 of the FC Encapsulation Header
   computed using the polynomial, initial value, and bit order defined
   for Fibre Channel[3].

2.2 FC Encapsulation Header Validation

   Two mechanisms are provided for validating an FC Encapsulation
   Header:

   o Redundancy based
   o CRC based

   The two mechanisms address the needs of two different design and
   operating environments.

2.2.1 Redundancy based FC Encapsulation Header validation

   Redundancy based validation of an FC Encapsulation Header relies on
   duplicated and one's complemented fields in the header.

   Validation of a header using redundancy may be accomplished using
   very simple logic (e.g., XORs and comparisons).  Header validation
   based on redundancy also is a step wise process in that the first
   word is validated, then the second, then the third and so on.  A
   decision that a candidate header is not valid may be reached before
   the complete header is available.

2.2.2 CRC based FC Encapsulation Header validation

   CRC based validation of an FC Encapsulation Header relies on a CRC
   located in the last word of the header.

   Validation of a header using the CRC may be accomplished using a very
   straight forward algorithm, compute the CRC for all bytes preceding
   the CRC word and compare the results to the CRC word's contents.  The
   number of comparisons required to perform CRC validation is exactly
   one and the method for computing the CRC is well known with proven
   implementations.



Weber, et.al.            Expires October 19, 2001               [Page 6]


Internet-Draft               FC Encapsulation                 April 2001


3. The FC frame

3.1 FC frame content

   Figure 4 shows the structure of a general FC-2 frame format.

                  +------------------+
                  |        SOF       |
                  +------------------+
                  | FC frame content |
                  +------------------+
                  |        EOF       |
                  +------------------+

              Fig. 4 - General FC-2 Frame Format

3.2 Bit and Byte Ordering

   FC frames are mapped to TCP using the big endian byte ordering, which
   corresponds to the standard network byte order or canonical form [8].

3.3 FC SOF and EOF

   The FC frame content is composed of 8-bit bytes that can be
   translated directly for transmission over TCP.  The SOF and EOF
   require 8b/10b special characters that cannot be translated directly
   to 8-bit bytes, encoded values are required.

   For this reason, the encapsulated FC frame SHALL have the format
   shown in figure 5.  The redundancy of the SOF/EOF representation in
   the encapsulation format results from concerns that the information
   be protected from transmission errors.

     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|
      +---------------+---------------+-------------------------------+
     0|      SOF      |     -SOF      |      SOF      |     -SOF      |
      +---------------+---------------+-------------------------------+
     1|                                                               |
      +-----                   FC frame content                  -----+
      |                                                               |
      +---------------+---------------+-------------------------------+
     n|      EOF      |     -EOF      |      EOF      |     -EOF      |
      +---------------+---------------+-------------------------------+

              Fig. 5 - FC Frame Encapsulation Format


Weber, et.al.            Expires October 19, 2001               [Page 2]


Internet-Draft               FC Encapsulation                 April 2001

   SOF (bits 31-24 and bits 15-8 in word 0):  The SOF fields contain the
   encoded SOF value selected from table 1.

         +-------+----------+
         |  FC   |          |
         |  SOF  | SOF Code |
         +-------+----------+
         | SOFf  |   0x28   |
         | SOFi2 |   0x2D   |
         | SOFn2 |   0x35   |
         | SOFi3 |   0x2E   |
         | SOFn3 |   0x36   |
         +-------+----------+

         Table 1 Translation of
         FC SOF values to SOF
         field contents

   -SOF (bits 23-16 and 7-0 in word 0): The -SOF fields contain the
   one's complement of the value in the SOF fields.

   EOF (bits 31-24 and 15-8 in word n):  The EOF fields contain the
   encoded EOF value selected from table 2.

         +-------+----------+
         |  FC   |          |
         |  EOF  | EOF Code |
         +-------+----------+
         | EOFn  |   0x41   |
         | EOFt  |   0x42   |
         | EOFni |   0x49   |
         | EOFa  |   0x50   |
         +-------+----------+

         Table 2 Translation of
         FC EOF values to EOF
         field contents

   -EOF (bits 23-16 and 7-0 in word n): The -EOF fields contain the
   one's complement of the value in the EOF fields.


4. Security

   This document describes the encapsulation format only.  Actual use of
   this format in a protocol requires an additional document to specify
   the protocol functionality and appropriate security considerations.
   Because security considerations for this encapsulation depend on how
   it is used by protocols, they SHALL be described in protocol-specific
   documents.

Weber, et.al.            Expires October 19, 2001               [Page 8]


Internet-Draft               FC Encapsulation                 April 2001


5. References

    [1] Bradner, S., "The Internet Standards Process -- Revision 3",
        BCP 9, RFC 2026, October 1996.

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

    [3] T11/Project 1331-D/Rev 1.20 "Fibre Channel Framing and
        Signaling", (FC-FS) February 16, 2001 (www.t11.org)

    [4] NCITS 321-200x (ANSI) T11/Project 1305-D/Rev 4.9 "Fibre Channel
        Switch-Fabric-2", (FC-SW-2) November 14, 2000 (www.t11.org)

    [5] NCITS 352-200x (ANSI) T11/Project 1306-D/Rev 9 "Fibre Channel
        Physical Interfaces", (FC-PI) August 18, 2000 (www.t11.org)

    [6] Reynolds, J. and Postel, J., "Assigned Numbers", RFC 1700,
        October, 1994.

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

    [8] Narten, T. and C. Burton, "A Caution on The Canonical Ordering
        of Link-Layer Addresses",  RFC 2469, December 1998.

6. Author's Addresses

   Ralph O. Weber                     Murali Rajagopal
   Representing Brocade Comm.         LightSand Communications, Inc.
   ENDL Texas                         375 Los Coches St.
   PMB 178                            Milpitas, CA 95035
   18484 Preston Road                 US
   Suite 102
   Dallas, TX 75252                   Phone: +1 408 404 3164
   US                                 Email: muralir@lightsand.com

   Phone: +1 214 912 1373
   Email: rweber@brocade.com

   Franco Travostino                  Vi Chau
   Technology Center                  Gadzoox Networks, Inc.
   Nortel Networks, Inc.              16241 Laguna Canyon Road
   600 Technology Park                Suite 100
   Billerica, MA 01821                Irvine, CA 92618
   US                                 US

   Phone: +1 978 288 7708             Phone: +1 949 789 4639
   Email: travos@nortelnetworks.com   Email: vchau@gadzoox.com

Weber, et.al.            Expires October 19, 2001               [Page 9]


Internet-Draft               FC Encapsulation                 April 2001


   Michael E. O'Donnell               Charles Monia
   McDATA Corporation                 Nishan Systems
   310 Interlocken Parkway            3850 North First Street
   Broomfield, Co. 80021              San Jose, CA 95134
   US                                 US

   Phone: +1 303 460 4142             Phone: +1 408 519 3986
   Email: modonnell@mcdata.com        Email: cmonia@nishansystems.com

   Milan Merhar
   Pirus Networks
   43 Nagog Park
   Acton MA 01720
   US

   Phone: +1 978 206 9124
   Email: milan@pirus.com


7. Full Copyright Statement

   Copyright (C) The Internet Society (2000). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.




Weber, et.al.            Expires October 19, 2001              [Page 10]


Internet-Draft               FC Encapsulation                 April 2001


Annex A - Protocol Requirements

   This annex lists the requirements placed on the protocols that employ
   this encapsulation.  The requirements listed here are suggested or
   described elsewhere in this document, but their collection in this
   annex serves to assist protocol authors in meeting all obligations
   placed upon them.

   Protocol Specific Data

   Protocols employing this encapsulation SHALL:

   o specify the IANA assigned number used in the Protocol# field
   o specify the contents of the Protocol Specific field

   CRC

   Protocols employing this encapsulation MAY:

   o require the CRC value to always be valid and the CRCV Flag
     to always be set to one
   o check the contents of the CRC field without regard for the
     contents of the CRCV Flag

Annex B - IANA Considerations

   The Protocol# (Protocol Number, bits 31-24 in word 0 of the
   Encapsulation Header) field is capable of conveying 256 distinct
   constant values.  Constant value 0 should be reserved for use in the
   event that the other 255 constant values are not sufficient.

   This document requests IANA assignment of two constant values, one to
   each of the two protocols known to employ this encapsulation (FCIP,
   and iFCP) both projects of the ips (IP Storage) working group.  Thus
   it is RECOMMENDED that FCIP be assigned constant value 1 and iFCP be
   assigned constant value 2.

   To verify that future protocols correctly employ this encapsulation,
   it is requested that the ips working group chairs or the Transport
   Services area directors be notified when additional constant value
   assignments are requested.









Weber, et.al.            Expires October 19, 2001              [Page 11]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/