GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3643

Network Working Group R. Weber Request for Comments: 3643 Brocade Category: Standards Track M. Rajagopal

                                                  Broadcom Corporation
                                                         F. Travostino
                                                       Nortel Networks
                                                          M. O'Donnell
                                                                McDATA
                                                              C. Monia
                                                        Nishan Systems
                                                             M. Merhar
                                                      Sun Microsystems
                                                         December 2003
               Fibre Channel (FC) Frame Encapsulation

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 (2003).  All Rights Reserved.

Abstract

 This document describes the common Fibre Channel (FC) frame
 encapsulation format and a procedure for the measurement and
 calculation of frame transit time through the IP network.  This
 specification is intended for use by any IETF protocol that
 encapsulates FC frames.

Weber, et al. Standards Track [Page 1] RFC 3643 FC Frame Encapsulation December 2003

Table Of Contents

 1.  Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
 2.  Encapsulation Concepts . . . . . . . . . . . . . . . . . . . .  3
 3.  The FC Encapsulation Header. . . . . . . . . . . . . . . . . .  4
     3.1.  FC Encapsulation Header Format . . . . . . . . . . . . .  4
     3.2.  FC Encapsulation Header Validation . . . . . . . . . . .  7
           3.2.1.  Redundancy Based FC Encapsulation
                   Header Validation. . . . . . . . . . . . . . . .  7
           3.2.2.  CRC Based FC Encapsulation Header Validation . .  7
 4.  Measuring Fibre Channel Frame Transit Time . . . . . . . . . .  8
 5.  The FC Frame . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  FC Frame Content . . . . . . . . . . . . . . . . . . . . 10
     5.2.  Bit and Byte Ordering. . . . . . . . . . . . . . . . . . 10
     5.3.  FC SOF and EOF . . . . . . . . . . . . . . . . . . . . . 11
 6.  Security Considerations. . . . . . . . . . . . . . . . . . . . 12
 7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Normative References . . . . . . . . . . . . . . . . . . 12
     7.2.  Informative References . . . . . . . . . . . . . . . . . 13
 8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
 Appendix
 A  Fibre Channel Bit and Byte Numbering Guidance . . . . . . . . . 15
 B  Encapsulating Protocol Requirements . . . . . . . . . . . . . . 15
 C  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16
 D  Intellectual Property Rights Statement. . . . . . . . . . . . . 17
 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 20

1. Scope

 This document describes common mechanisms for the transport of Fibre
 Channel frames over an IP network, including the encapsulation format
 and a mechanism for enforcing the Fibre Channel frame lifetime
 limits.
 Warning to Readers Familiar With Fibre Channel: Both Fibre Channel
 and IETF standards use the same byte transmission order. However, the
 bit and byte numbering is different.  See Appendix A for guidance.
 The organization responsible for the Fibre Channel standards (INCITS
 Technical Committee T11) has determined that some functions and modes
 of operation are not interoperable to the degree required by the IETF
 (see FC-MI [8]).  This document includes applicable T11
 interoperability determinations in the form of restrictions on the
 use of this encapsulation mechanism.

Weber, et al. Standards Track [Page 2] RFC 3643 FC Frame Encapsulation December 2003

 Use of these mechanisms in an encapsulating protocol requires an
 additional document to specify the encapsulating protocol specific
 functionality and appropriate security considerations.  Because
 security considerations for this encapsulation depend on how it is
 used by encapsulating protocols, they are taken up in encapsulating
 protocol specific documents.
 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 BCP 14, RFC
    2119 [2].

2. 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), and the contents of the Fibre Channel frame.  The Fibre
 Channel frame includes a Cyclic Redundancy Check (CRC) code that
 provides error detection for the contents of the frame.  FC frames
 are variable length.  To facilitate transporting FC frames over an IP
 based transport such as 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 |
    +--------------------+-----+
    Figure 1 -  FC frame Encapsulation
 The format and content of an FC frame are 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 a CRC for detection of transmission errors.

Weber, et al. Standards Track [Page 3] RFC 3643 FC Frame Encapsulation December 2003

3. The FC Encapsulation Header

3.1. FC Encapsulation Header Format

 Figure 2 shows the format of the required FC Encapsulation Header.
 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    |
  +---------------+---------------+---------------+---------------+
 1|                                                               |
  +-----           Encapsulating Protocol Specific            ----+
 2|                                                               |
  +-----------+-------------------+-----------+-------------------+
 3|   Flags   |   Frame Length    |   -Flags  |   -Frame Length   |
  +-----------+-------------------+-----------+-------------------+
 4|                      Time Stamp [Seconds]                     |
  +---------------------------------------------------------------+
 5|                  Time Stamp [Seconds Fraction]                |
  +---------------------------------------------------------------+
 6|                              CRC                              |
  +---------------------------------------------------------------+
  Figure 2 -  FC Encapsulation Header Format
 The fields in the FC Encapsulation Header are defined as follows.
 Protocol#: The Protocol# field SHALL contain a number that indicates
    which encapsulating protocol is employing the FC Encapsulation.
    The values in the Protocol# field are assigned by IANA (see
    Appendix C).
 Version: The Version field SHALL contain 0x01 to indicate that this
    version of the FC Encapsulation is being used.  All other values
    are reserved for future versions of the FC Encapsulation.
  1. Protocol#: The -Protocol# field SHALL contain the one's complement

of the contents of the Protocol# field. FC Encapsulation

    receivers SHOULD either validate the CRC or compare the Protocol#
    and - Protocol# fields to verify that an FC Encapsulation Header
    is being processed according to a policy defined by the
    encapsulating protocol.

Weber, et al. Standards Track [Page 4] RFC 3643 FC Frame Encapsulation December 2003

  1. Version: The -Version field SHALL contain the one's complement of

the contents of the Version field. FC Encapsulation receivers

    SHOULD either validate the CRC or compare the Version and -Version
    fields to verify that an FC Encapsulation Header is being
    processed according to a policy defined by the encapsulating
    protocol.
 Encapsulating Protocol Specific: The usage of these words differs
    based on the contents of the Protocol# field, i.e., the usage of
    these words is defined by the encapsulating protocol that is
    employing this encapsulation.
 Flags: The Flags bits provide information about the usage of the
    FC Encapsulation Header as shown in Figure 3.
    |------------------------Bit--------------------------|
    |                                                     |
    |    0        1        2        3        4        5   |
    +--------------------------------------------+--------+
    |                  Reserved                  |  CRCV  |
    +--------------------------------------------+--------+
    Figure 3 -  Flags Field Format
 Reserved Flags bits: These bits are reserved for use by future
    versions of the FC Encapsulation and SHALL be set to zero on send.
    Encapsulating protocols employing the encapsulation described in
    this specification MAY require checking for zero on receive,
    however doing so has the potential to create incompatibilities
    with future versions of this encapsulation.  Changes in the usage
    of the Reserved Flags bits MUST be identified by changes in the
    contents of the Version field.  Encapsulating protocols employing
    the encapsulation described in this specification MUST NOT make
    use of the Reserved Flags bits in any fashion other than that
    described in this specification.
 CRCV (CRC Valid Flag): A CRCV bit value of one indicates that
    the contents of the CRC field are valid.  A CRCV bit value of zero
    indicates that the contents of the CRC field are invalid.  The
    value of the CRCV bit SHALL be constant for all FC Encapsulation
    Headers sent on a given connection.
 Frame Length: 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 is always word-aligned;
    therefore a32-bit word length is acceptable.

Weber, et al. Standards Track [Page 5] RFC 3643 FC Frame Encapsulation December 2003

  1. Flags: The -Flags field SHALL contain the one's complement of the

contents of the Flags field. FC Encapsulation receivers SHOULD

    either validate the CRC or compare the Flags and -Flags fields to
    verify that an FC Encapsulation Header is being processed
    according to a policy defined by the encapsulating protocol.
  1. Frame Length: The -Frame Length field SHALL contain the one's

complement of the contents of the Frame Length field. FC

    Encapsulation receivers SHOULD either validate the CRC or compare
    the Frame Length and -Frame Length fields to verify that an FC
    Encapsulation Header is being processed according to a policy
    defined by the encapsulating protocol.
 Time Stamp [Seconds]: The Time Stamp [Seconds] field contains zero
    or the number of seconds since 0 hour on 1 January 1900 at the
    time the FC Encapsulated frame is place in the outgoing data
    stream.
 Time Stamp [Seconds Fraction]: The Time Stamp [Second Fraction]
    field contains the fraction of the second at the time the FC
    Encapsulated frame is place in the outgoing data stream.  Non-
    significant low order bits may be set to zero.  Table 1 shows some
    example Time Stamp [Seconds Fraction] values.
    +------------+--------------------+
    |            |     Time Stamp     |
    |   Second   | [Seconds Fraction] |
    +------------+--------------------+
    | n.50000... |     0x80000000     |
    | n.25000... |     0x40000000     |
    | n.12500... |     0x20000000     |
    +------------+--------------------+
    Table 1  Example Time Stamp [Seconds Fraction] values
 Note that, since some time in 1968 (second 2,147,483,648) the most
 significant bit (bit 0 of Time Stamp [Seconds]) has been set and that
 the field will overflow some time in 2036 (second 4,294,967,296).
 Should FCIP be in use in 2036, some external means will be necessary
 to qualify time relative to 1900 and time relative to 2036 (and other
 multiples of 136 years).  There will exist a 200-picosecond interval,
 henceforth ignored, every 136 years when the 64-bit field will be 0,
 which by convention is interpreted as an invalid or unavailable
 timestamp.

Weber, et al. Standards Track [Page 6] RFC 3643 FC Frame Encapsulation December 2003

 The Time Stamp [Seconds] and Time Stamp [Seconds Fraction] words
 follow the in time format described in Simple Network Time Protocol
 (SNTP) Version 4 [9].  The contents of the Time Stamp [Seconds] and
 Time Stamp [Seconds Fraction] words SHALL be set as described in
 section 4.
 CRC: 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 equations, polynomial, initial value, and bit order defined for
 Fibre Channel in FC-FS [3].  Using this algorithm, the bit order of
 the resulting CRC corresponds to that of FC-1 layer.  The CRC
 transmitted over the IP network shall correspond to the equivalent
 value converted to FC-2 format as specified in FC-FS.

3.2. FC Encapsulation Header Validation

 Two mechanisms are provided for validating an FC Encapsulation
 Header:
  1. Redundancy based
  2. CRC based
 The two mechanisms address the needs of two different design and
 operating environments.

3.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.
 Encapsulating protocols that use redundancy based validation SHOULD
 define how receiving devices use one's complement fields to verify
 header validity.
 Header validation based on redundancy is a stepwise 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.

3.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.
 Header validation based on the CRC defined in section 3.1 requires
 computing the CRC for all bytes preceding the CRC word, and comparing
 the results to the CRC word's contents.

Weber, et al. Standards Track [Page 7] RFC 3643 FC Frame Encapsulation December 2003

4. Measuring Fibre Channel Frame Transit Time

 To comply with FC-FS [3], an FC Fabric must specify and limit the
 lifetime of a frame.  In an FC Fabric comprised of IP-connected
 elements, one component of the frame's lifetime is the time required
 to traverse the connection.  To ensure that the total frame lifetime
 remains within the limits required by the FC Fabric, the
 encapsulation described in this specification contains provisions for
 recording the departure time of an encapsulated frame injected into a
 connection.  If the encapsulated frame originator and recipient have
 access to aligned and synchronized time bases, the transit time
 through the IP network can then be computed.
 When originating an encapsulated frame, an entity that does not
 support transit time calculation SHALL always set the Time Stamp
 [Seconds] and Time Stamp [Seconds Fraction] fields to zero.  When
 receiving an encapsulated frame, an entity that does not support
 transit time calculation SHALL ignore the contents of the Time Stamp
 words.
 The encapsulating protocol SHALL specify whether or not
 implementation support is required.  The encapsulating protocol SHALL
 specify those conditions under which a received encapsulated frame
 MUST have its transit time checked before forwarding.
 Encapsulating and de-encapsulating entities that support this feature
 MUST have access to:
 a) An internal time base having the stability and resolution
    necessary to comply with the requirements of the encapsulating
    protocol specification; and
 b) A time base that is synchronized and aligned with the time base of
    other entities to which encapsulated frames may be sent or
    received.  The encapsulating protocol specification MUST describe
    the synchronization and alignment procedure.
 With respect to its ability to measure and set transit time for
 encapsulated frames exchanged with another device, an entity is
 either in the Synchronized or Unsynchronized state.  An entity is in
 the Unsynchronized state upon power-up and transitions to the
 Synchronized state once it has aligned its time base in accordance
 with the applicable encapsulating protocol specification.
 An entity MUST return to the Unsynchronized state if it is unable to
 maintain synchronization of its time base as required by the
 encapsulating protocol specification.

Weber, et al. Standards Track [Page 8] RFC 3643 FC Frame Encapsulation December 2003

 The policy for forwarding frames while in the Unsynchronized state
 SHALL be defined by the encapsulating protocol specification.
 If processing frames in the Unsynchronized state is permitted by the
 encapsulating protocol specification, the entity SHALL:
 a) When de-encapsulating a frame, ignore the Time Stamp words. For
    example, if a calculated transit time exceeds a value that could
    cause the frame to violate FC maximum time in transit limits, the
    encapsulating protocol may specify that the frame is to be
    discarded; and
 b) When encapsulating a frame set the Time Stamp [Seconds] and Time
    Stamp [Seconds Fraction] words to zero.  For example, an
    encapsulating protocol may specify that frames for which transit
    time cannot be determined are never to be forwarded over FC.
 When encapsulating a frame, an entity in the Synchronized state SHALL
 record the value of the time base in the Time Stamp [Seconds] and
 Time Stamp [Seconds Fraction] words in the encapsulation header.
 When de-encapsulating a frame, an entity in the Synchronized state
 SHALL:
 a) Test the Time Stamp words to determine if they contain a time as
    specified in [9].  If the time stamp is valid, the receiving
    entity SHALL compute the transit time by calculating the
    difference between its time base and the departure time recorded
    in the frame header.  The receiving entity SHALL process the
    calculated transit time and the de-encapsulated frame in
    accordance with the applicable encapsulating protocol
    specification; or
 b) If both Time Stamp words have a value of zero, the receiving
    entity SHALL de-encapsulate the frame without computing the
    transit time.  The disposition of the frame and any other actions
    by the recipient SHALL be defined by the encapsulating protocol
    specification.
 Note: For most purposes, communication between entities is possible
 only while in the Synchronized state.

Weber, et al. Standards Track [Page 9] RFC 3643 FC Frame Encapsulation December 2003

5. The FC Frame

5.1. FC Frame Content

 NOTE: All uses 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.
 Figure 4 shows the structure of a general FC-2 frame format.
    +------------------+
    |        SOF       |
    +------------------+
    | FC frame content |
    +------------------+
    |        EOF       |
    +------------------+
    Figure 4 -  General FC-2 Frame Format
 As shown in Figure 4, the FC frame content is defined as the data
 between the EOF and SOF delimiters (including the FC CRC) after
 conversion from FC-1 to FC-2 format as specified by FC-FS [3].
 When Fibre Channel devices convert the FC frame content to the FC-0
 physical transport, an encoding is applied to the FC frame content
 (e.g., 8b/10b encoding like that used in Gigbit Ethernet) for reasons
 that include redundancy and low level timing synchronization between
 sender and receiver.  With the exceptions of SOF and EOF [3] all
 discussion of FC frame content in this document is at the 8-bit byte
 level, prior to the application of any such encoding.
 The 8-bit bytes in the FC frame content can be translated directly
 for transmission over an IP Network.  However, the FC SOF and EOF
 employ special 10b characters that have no 8b equivalents. Therefore,
 special byte placement and 8-bit character encodings are required to
 represent SOF and EOF.

5.2. Bit and Byte Ordering

 The Encapsulation Header, SOF, FC frame content (see section 5.1),
 and EOF are mapped to TCP using the big endian byte ordering, which
 corresponds to the standard network byte order or canonical form [7].

Weber, et al. Standards Track [Page 10] RFC 3643 FC Frame Encapsulation December 2003

5.3. FC SOF and EOF

 As described in section 5.1, representation of FC SOF and EOF in an
 IP Network byte stream requires special formatting and 8-bit code
 definitions.  Therefore, 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|                    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|      SOF      |      SOF      |     -SOF      |     -SOF      |
  +---------------+---------------+-------------------------------+
 1|                                                               |
  +-----                   FC frame content                  -----+
  |                                                               |
  +---------------+---------------+-------------------------------+
 n|      EOF      |      EOF      |     -EOF      |     -EOF      |
  +---------------+---------------+-------------------------------+
  Figure 5 -  FC Frame Encapsulation Format
 Note: The number of 8-bit bytes in the FC frame content is always a
 multiple of four.
 SOF: The SOF fields contain the encoded SOF value selected from table
 2.
 +-------+------+-------+    +-------+------+-------+
 |  FC   | SOF  |       |    |  FC   | SOF  |       |
 |  SOF  | Code | Class |    |  SOF  | Code | Class |
 +-------+------+-------+    +-------+------+-------+
 | SOFf  | 0x28 |   F   |    | SOFi4 | 0x29 |   4   |
 | SOFi2 | 0x2D |   2   |    | SOFn4 | 0x31 |   4   |
 | SOFn2 | 0x35 |   2   |    | SOFc4 | 0x39 |   4   |
 | SOFi3 | 0x2E |   3   |    +-------+------+-------+
 | SOFn3 | 0x36 |   3   |
 +-------+------+-------+
 Table 2  Translation of FC SOF values to SOF field contents
  1. SOF: The -SOF fields contain the one's complement of the value in

the SOF fields. Encapsulation receivers SHOULD validate the SOF

    field according to a policy defined by the encapsulating protocol.

Weber, et al. Standards Track [Page 11] RFC 3643 FC Frame Encapsulation December 2003

 EOF: The EOF fields contain the encoded EOF value selected from
    table 3.
 +-------+------+---------+   +--------+------+-------+
 |  FC   | EOF  |         |   |  FC    | EOF  |       |
 |  EOF  | Code |  Class  |   |  EOF   | Code | Class |
 +-------+------+---------+   +--------+------+-------+
 | EOFn  | 0x41 | 2,3,4,F |   | EOFdt  | 0x46 |   4   |
 | EOFt  | 0x42 | 2,3,4,F |   | EOFdti | 0x4E |   4   |
 | EOFni | 0x49 | 2,3,4,F |   | EOFrt  | 0x44 |   4   |
 | EOFa  | 0x50 | 2,3,4,F |   | EOFrti | 0x4F |   4   |
 +-------+------+---------+   +--------+------+-------+
 Table 3  Translation of FC EOF values to EOF field contents
  1. EOF: The -EOF fields contain the one's complement of the value in

the EOF fields. Encapsulation receivers SHOULD validate the EOF

    field according to a policy defined by the encapsulating protocol.
 Note: FC-BB-2 [6] lists SOF and EOF codes not shown in table 2 and
 table 3 (e.g., SOFi1 and SOFn1).  However, FC-MI [8] identifies these
 codes as not interoperable, so they are not listed in this
 specification.

6. Security Considerations

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

7. References

7.1. Normative 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.

Weber, et al. Standards Track [Page 12] RFC 3643 FC Frame Encapsulation December 2003

 [3]  Fibre Channel Framing and Signaling (FC-FS), ANSI
      INCITS.373:2003, October 27, 2003. Note: Published T11 standards
      are available from the INCITS online store
      http://www.incits.org, or the ANSI online store,
      http://www.ansi.org.
 [4]  Fibre Channel Switch Fabric -2 (FC-SW-2), ANSI NCITS.355:2001,
      December 12, 2002.  Note: Published T11 standards are available
      from the INCITS online store http://www.incits.org, or the ANSI
      online store, http://www.ansi.org.
 [5]  Fibre Channel Physical Interfaces (FC-PI), ANSI NCITS.352:2002,
      December 1, 2002.  Note: Published T11 standards are available
      from the INCITS online store http://www.incits.org, or the ANSI
      online store, http://www.ansi.org.
 [6]  Fibre Channel Backbone -2 (FC-BB-2), ANSI INCITS.372:2003, July
      25, 2003.  Note: Published T11 standards are available from the
      INCITS online store http://www.incits.org, or the ANSI online
      store, http://www.ansi.org.
 [7]  Narten, T. and C. Burton, "A Caution on The Canonical Ordering
      of Link-Layer Addresses", RFC 2469, December 1998.

7.2. Informative References

 [8]  Fibre Channel Methodologies for Interconnects (FC-MI), ANSI
      INCITS/TR-30:2002, November 1, 2002.  Note: Published T11
      standards are available from the INCITS online store
      http://www.incits.org, or the ANSI online store,
      http://www.ansi.org.
 [9]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
      IPv4, IPv6 and OSI", RFC 2030, October 1996.
 [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
      Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
 [11] Rajagopal, M., Rodriguez, E., Weber, R., "Fibre Channel Over
      TCP/IP (FCIP)", Work in Progress.
 [12] Monia, C., et. al., "iFCP - A Protocol for Internet Fibre
      Channel Storage Networking", Work in Progress.

Weber, et al. Standards Track [Page 13] RFC 3643 FC Frame Encapsulation December 2003

8. Acknowledgements

 The authors express their appreciation to Mr. Vi Chau
 (vchau1@cox.net) for his contributions to the design team that
 developed this document.  Mr. Chau is no longer working in this
 technology.
 The authors are also grateful to Dr. David Black, Mr. Mallikarjun
 Chadalapaka, and Mr. Robert Elliott for their reviews of this
 specification.

Weber, et al. Standards Track [Page 14] RFC 3643 FC Frame Encapsulation December 2003

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 6, is cut and pasted at the top of
 Figure 2 and Figure 5.
 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 6 -  Fibre Channel Data Structure Bit and Byte Numbering
 Fibre Channel bit numbering for the Flags field can be observed if
 the data structure heading shown in Figure 7, is cut and pasted at
 the top of Figure 3.
 |------------------------Bit--------------------------|
 |                                                     |
 |   31       30       29       28       27       26   |
 Figure 7 -  Fibre Channel Flags Bit Numbering

Appendix B - Encapsulating Protocol Requirements

 This appendix lists the requirements placed on the encapsulating
 protocols that employ this encapsulation.  The requirements listed
 here are suggested or described elsewhere in this document, but their
 collection in this appendix serves to assist encapsulating protocol
 authors in meeting all obligations placed upon them.
 Encapsulating Protocol Specific Data
 Encapsulating protocols employing this encapsulation SHALL:
  1. specify the IANA assigned number used in the Protocol# field
  2. specify the contents of the Encapsulating Protocol Specific field
 Encapsulating protocols employing this encapsulation SHALL define the
 procedures and policies necessary for verifying that an FC
 Encapsulation Header is being processed.

Weber, et al. Standards Track [Page 15] RFC 3643 FC Frame Encapsulation December 2003

 Encapsulating protocols employing this encapsulation SHALL define the
 procedures and policies necessary for the detection of over age
 frames.  The items to be specified and the choices available to an
 encapsulating protocol specification are as follows:
 a) The encapsulating protocol requirements for measuring transit
    times.  The encapsulating protocol MAY allow implementation of
    transit time measurement to be optional.
 b) The requirements or guidelines for stability and resolution of the
    entity's time base.
 c) The procedure for synchronizing an entity's time base, including
    the criteria for entering the Synchronized and Unsynchronized
    states.
 d) The forwarding (or lack of forwarding) of frame traffic while in
    the Unsynchronized state.
    The specification MAY allow an entity in the Unsynchronized state
    to continue processing frame traffic.
 e) The procedure to be followed when frames are received that do not
    have a valid time stamp.
    The specification MAY allow such frames to be accepted by the
    entity.
 f) Requirements for setting and testing the transit time limit and
    the procedure to be followed when a received frame is discarded
    due to its transit time exceeding the limit.

Appendix C - IANA Considerations

 The Protocol# (Protocol Number) field is an identifier number used to
 distinguish between the encapsulating protocols that employ this FC
 frame encapsulation.  Values used in the Protocol# field are to be
 assigned from a new, separate registry that is maintained by IANA.
 All values in the Protocol# field are to be registered with and
 assigned by IANA with the following exceptions.
  1. Protocol# value 0 should not be assigned until after all other

values have been assigned.

  1. Protocol# values 240-255 inclusive must be set aside for private

use amongst cooperating systems.

Weber, et al. Standards Track [Page 16] RFC 3643 FC Frame Encapsulation December 2003

 Following the policies outlined in [10], Protocol# values not listed
 above are to be assigned only for Standards Track RFCs approved by
 the IESG.
 In addition to creating the FC Frame Encapsulation Protocol Number
 Registry, the standards action of this RFC allocates the following
 two values from the registry:
  1. Protocol# value 1 assigned to the FCIP (Fibre Channel Over TCP/

IP) encapsulating protocol [11].

  1. Protocol# value 2 assigned to the iFCP (A Protocol for Internet

Fibre Channel Storage Networking) encapsulating protocol [12].

Appendix D - Intellectual Property Rights Statement

 The IETF takes no position regarding the validity or scope of any
 intellectual property 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; neither does it represent that it
 has made any effort to identify any such rights.  Information on the
 IETF's procedures with respect to rights in standards-track and
 standards-related documentation can be found in BCP-11.  Copies of
 claims of rights made available for publication 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 implementors or users of this specification can
 be obtained from the IETF Secretariat.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights which may cover technology that may be required to practice
 this standard.  Please address the information to the IETF Executive
 Director.

Weber, et al. Standards Track [Page 17] RFC 3643 FC Frame Encapsulation December 2003

Authors' Addresses

 Ralph Weber
 ENDL Texas
 representing Brocade Comm.
 Suite 102 PMB 178
 18484 Preston Road
 Dallas, TX 75252
 USA
 Phone: +1 214 912 1373
 EMail: roweber@ieee.org
 Murali Rajagopal
 Broadcom
 16215 Alton Parkway
 PO Box 57013
 Irvine, CA 92619
 USA
 Phone: +1 949 450 8700
 EMail: muralir@broadcom.com
 Franco Travostino
 Technology Center
 Nortel Networks, Inc.
 600 Technology Park
 Billerica, MA 01821
 USA
 Phone: +1 978 288 7708
 EMail: travos@nortelnetworks.com
 Michael E. O'Donnell
 McDATA Corporation
 4 McDATA Parkway
 Broomfield, Co. 80021
 USA
 Phone +1 720 558 4142
 Fax +1 720 558 8999
 EMail: mike.o'donnell@mcdata.com

Weber, et al. Standards Track [Page 18] RFC 3643 FC Frame Encapsulation December 2003

 Charles Monia
 EMail: cmonia@pacbell.net
 Milan J. Merhar
 Sun Microsystems
 43 Nagog Park
 Acton, MA 01720
 USA
 Phone: +1 978 206 9124
 EMail: milan.merhar@sun.com

Weber, et al. Standards Track [Page 19] RFC 3643 FC Frame Encapsulation December 2003

Full Copyright Statement

 Copyright (C) The Internet Society (2003).  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.

Acknowledgement

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

Weber, et al. Standards Track [Page 20]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3643.txt · Last modified: 2003/12/09 16:36 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki