Re: FCIP - Proposed changes in support of common FC encapsulation

[Ralph Weber <ralphoweber@compuserve.com>]

This is the complete list of changes need to be made in FCIP to make
correctly reference to the Common FC Encapsulation draft as updated
to reflect the correction proposed by Sudhir Srinivasan.

I am currently investigating whether an IANA Considerations annex
will be required. If one is necessary it will be proposed separately.

The changes are presented in the order that they are expected to appear
in draft-ietf-ips-fcovertcpip-03.txt.

In the section 3 objectives list (top of page 3 in draft-ietf-ips-
fcovertcpip-02.txt), replace:

          1) specify the encapsulation and mapping of FC frames using
             the FC encapsulation method specified in <TBD>.

with:

          1) specify the encapsulation and mapping of FC frames
             employing the common FC Frame Encapsulation[23].

In the 1st paragraph of section 4.2, replace:

      The FCIP protocol specifies the TCP/IP encapsulation, mapping and
      routing of FC frames and applies these mechanisms to an FC network
      utilizing IP for its backbone, or more generally, between any two
      FC devices.

with:

      The FCIP protocol specifies the TCP/IP encapsulation (employing
      the common FC Frame Encapsulation described in [23]), mapping and
      routing of FC frames and applies these mechanisms to an FC network
      utilizing IP for its backbone, or more generally, between any two
      FC devices.

In section 4.2 list item 6, replace:

        6. An FCIP device MAY send FC encapsulated TCP/IP packets to
           more than one FCIP device.  However, these encapsulated
           packets are treated as separate instances and are not
           correlated in any way by the FCIP protocol devices.

with:

        6. An FCIP device MAY send encapsulated FC frames to more than
           one FCIP device.  However, these encapsulated FC frames are
           treated as separate instances and are not correlated in any
           way by the FCIP protocol devices

Delete list item 11 in section 4.2 since it is covered in the intro-
ductory text at the beginning of the section.  For reference, list
item 11 currently reads:

        11. FCIP uses the common encapsulation method as specified by
        <TBD>.

In the 3rd paragraph of section 4.3, replace:

      Each FCIP data frame is built by adding an FCIP header to one FC
      frame delivered to the FCIP endpoint for transport. The FCIP data
      frames are handed in their entirety to TCP; TCP is responsible for
      delivering the same series of FCIP data frames to the receiving
      side in the same order as they are transmitted by the sending FCIP
      device.  The FCIP device MUST find the FCIP headers and deliver
      the FC frames wrapped inside the FCIP data frames to the correct
      FC ports connected to the FCIP device.

with:

      An FCIP data frame is built by encapsulating one FC frame delivered
      to the FCIP endpoint for transport using the encapsulation format
      described in the common FC Frame Encapsulation [23] and in section
      5.2 of this document.  The FCIP data frames are handed in their
      entirety to TCP; TCP is responsible for delivering the same series
      of FCIP data frames to the receiving side in the same order as
      they are transmitted by the sending FCIP device.  The FCIP receiving
      device MUST reverse the FC frame encapsulation process, verify the
      correctness of the header and deliver the FC frames to the correct
      FC ports connected to the FCIP device. When header errors are
      encountered in FCIP data frames, the FCIP device MUST take
      corrective  action in accordance with Section 8.1.

In section 5.1, the last paragraph of "SOF and EOF Delimiters:", replace:

      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 frame termination information as the FC ordered sets.
      This form of encoding can not provide unambiguous identification
      of frame beginning and end, however, and must rely on other
      mechanisms provided by the encapsulation protocol.

With:

      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 frame termination information as the FC ordered sets.
      The representation of SOF and EOF in an encapsulation FC frame
      is described in the common FC Frame Encapsulation [23].

Note: If the deleted sentence is considered important, then it should
be moved to section 3.3 of the common encapsulation draft.

Section 5.2 appears to have been omitted as a placeholder for the FCIP
encapsulation details.  Therefore, the following new text for section
5.2 is proposed.

   5.2 FCIP Encapsulation of FC Frames

      The FCIP encapsulation of FC frames employs the common FC Frame
      Encapsulation [23].

      The features from the common FC Frame Encapsulation that are
      unique to individual protocols SHALL be applied as follows for
      the FCIP encapsulation of FC frames.

      The Protocol# field SHALL contain 1 in accordance with the
      IANA Considerations annex of the common FC Frame Encapsulation
      [23].

      The Protocol Specific field SHALL have the format shown in
      figure xx.  Note: the word numbers in figure xx are relative to
      the complete FC frame encapsulation header, not to the Protocol
      Specific field.

     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|
      +---------------------------------------------------------------+
     1|               replication of encapsulation word 0             |
      +-------------------------------+-------------------------------+
     2|            reserved           |           -reserved           |
      +-------------------------------+-------------------------------+

             Fig. xx - FCIP Usage of common FC Frame Encapsulation
                       Protocol Specific field

      Word 1 of the Protocol Specific field SHALL contain an exact
      copy of word 0 in the common FC Frame Encapsulation [23].

      Word 2 of the Protocol Specific field is reserved for future
      enhancements to the FCIP protocol.

      The reserved field (bits 31-16 in word 2): SHALL contain 0.

      The -reserved field (bits 15-0 in word 2): SHALL contain 65535
      (or 0xFFFF).

      The CRCV (CRC Valid) Flag SHALL be set to 0.

      The CRC field SHALL be set to 0.

In section 5.3 list item 4, replace:

           After connection establishment, FCIP devices use the FCIP
           frame encapsulation as defined in [common encapsulation
           document].

with:

           After connection establishment, FCIP devices use the FCIP
           frame encapsulation defined in the common FC Frame
           Encapsulation [23] and in section 5.2 of this document.


In the 1st paragraph of 5.4.1, replace:

         These FCIP ELS messages use the same encapsulation mechanism
         as described in TBD.

with:

         These FCIP ELS messages use the same encapsulation mechanism
         as described in 5.2.

In the 3rd paragraph of 5.4.2, replace:

       FCIP Encapsulated frame

with

       FCIP frame


In the 1st paragraph of 8.5, replace:

       FCIP data  frame

with

       FCIP frame

In Section 11 (References) add the following:

     [23] Weber, Rajagopal, Travostino, Chau, McDonnell, Monia Merhar,
          "FC Frame Encapsulation", draft-ietf-ips-fcencapsulation-__.txt
          (RFC reference and date to be added during standards action).
          RFC1072, October 1988