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

Versions: (draft-roth-pwe3-fc-encap) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 RFC 6307

INTERNET-DRAFT                                     David L. Black (ed.)
PWE3 WG                                                 EMC Corporation
Intended Status: Standard Track                       Linda Dunbar(ed.)
Expires: December 2010                              Huawei Technologies
                                                          June 29, 2010

   Encapsulation Methods for Transport of Fibre Channel frames Over MPLS
                                 Networks

                      draft-ietf-pwe3-fc-encap-11.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   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 December 29, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document. Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.




Black and Dunbar      Expires December 29, 2010                [Page 1]

Internet-Draft             FC Encapsulation                   June 2010


   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Abstract

   A Fibre Channel pseudowire (PW) is used to carry Fibre Channel frames
   over an MPLS network. This enables service providers to take full
   advantage of the reliable transport of MPLS-TE/MPLS-TP to offer
   "emulated" Fibre Channel services. This document specifies the
   encapsulation of Fibre Channel PDUs within a pseudowire. It also
   specifies the common procedures for using a PW to provide a Fibre
   Channel service. The mechanisms controlling the reliable transport of
   Fibre Channel PW over MPLS networks can be provided by MPLS-TP.

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

Table of Contents


   1. Introduction...................................................3
      1.1. Transparency..............................................3
      1.2. Bandwidth Efficiency......................................4
   2. Reference Model................................................4
   3. Encapsulation..................................................7
      3.1. The Control Word..........................................8
      3.2. MTU Requirements..........................................9
      3.3. Mapping of FC traffic to PW PDU...........................9
      3.4. PW failure mapping.......................................12
   4. Signaling of FC Pseudowires...................................13
   5. Timing Considerations.........................................13
   6. Security Considerations.......................................14
   7. Applicability Statement.......................................14
   8. IANA Considerations...........................................16
   9. Acknowledgments...............................................16


Black and Dunbar      Expires December 29, 2010                [Page 2]

Internet-Draft             FC Encapsulation                   June 2010


   10. Normative References.........................................16
   11. Informative references.......................................17
   Authors' Addresses...............................................17
   Contributors' Addresses..........................................18

1. Introduction

   Fibre Channel Storage Area Networks (SAN) extension for disaster
   recovery has become an important source of network traffic. In order
   to meet Fibre Channel's network service requirements, such as
   transparency and low latency, multiple methods for encapsulating and
   transporting FC frames over backbone networks have been developed
   [FC-BB-6].

   FC/IP, as described in [RFC3821] and [FC-BB-6], interconnects
   otherwise isolated FC SANs over IP Networks. FC/IP uses FC Frame
   Encapsulation, [RFC3643] to encapsulate FC frames and addresses
   concerns specific to tunneling FC over an IP-based network. Since
   such networks may not reliably deliver packets, FC/IP relies on the
   TCP protocol to retransmit dropped frames. Due to possible delay
   variation and TCP re-transmission timeouts, special timing mechanisms
   are required to ensure correct Fibre Channel operation over FC/IP
   [FC-BB-6].

   MPLS-TP and MPLS-TE provide mechanisms for reliable transport over
   MPLS networks, making it possible for Fibre Channel ports to be
   interconnected directly over MPLS networks. A Fibre Channel
   pseudowire (FC PW) is a method to transparently transport FC frames
   over an MPLS network resulting in behavior similar to a pair of FC
   ports that are directly connected by a physical FC link. The result
   is simpler control processing by comparison to FC/IP.

   This document defines the encapsulation of FC Protocol Data Units
   (PDUs) into an MPLS pseudowire and related procedures for using PW
   encapsulation.  The following sections describe some of the key
   requirements for transporting FC frames over an MPLS PSN.

1.1. Transparency

   Transparent emulation of an FC link is a key requirement for
   transporting FC frames over a carrier's network. This requires the FC
   PW to emulate an FC Link between two FC ports, similar to the
   approach defined for FC over GFPT in [FC-BB-6]. This results in
   transparent forwarding of FC frames over the MPLS PSN from both the
   FC Fabric and the operator's points of view.




Black and Dunbar      Expires December 29, 2010                [Page 3]

Internet-Draft             FC Encapsulation                   June 2010


   Transparency distinguishes the FC PW approach from FC/IP. An FC PW
   logically connects the FC port on one end of PW directly with the FC
   port on the other end of PW, whereas FC/IP introduces FC B_Ports at
   both ends of the extended FC link; each FC B_Port is logically
   connected to the FC port on the same side of the link extension.

1.2. Bandwidth Efficiency

   The bandwidth allocated to a PW can be less than the rate of the
   attached FC port. When there is no data exchange between the two
   directly connected FC ports, Idle Primitive signals are continuously
   exchanged between the two FC ports to keep the FC link up. In order
   to improve the bandwidth efficiency across the MPLS network, it is
   necessary for PW PE to suppress (or drop) the Idle Primitive signals
   generated by its adjacent FC ports. The far end PW PE regenerates
   Idle Primitive signals to send to its adjacent FC port as necessary,
   see [FC-BB-6].

   FC link protocols may send the same FC Primitive Sequence [FC-FS-2]
   between two directly connected FC ports until a reply is received. To
   improve bandwidth efficiency, the PW PE only encapsulates a subset of
   the received repetitive FC Primitive Sequences to send across the PW
   tunnel [FC-BB-6]. For example, one out of each set of four identical
   received primitives may be sent across the MPLS network. The far end
   PW PE has to send the Primitive Sequences received from the WAN side,
   i.e. from PW tunnel, to its attached FC port continuously until a new
   primitive sequence or data frame is received from the WAN.

   Another requirement for transporting FC over an MPLS PSN is to
   minimize the protocol overhead to optimize the bandwidth consumed by
   the FC traffic. FC PW has an overhead of 16 bytes, consisting of the
   FC Encapsulation Header (4 bytes), the Control Word (4 bytes), the PW
   label (4 bytes) and the MPLS label (4 bytes).

  2. Reference Model

   FC PW allows FC Protocol Data Units (PDUs) to be carried over an MPLS
   network. In addressing the issues associated with carrying a FC PDU
   over an MPLS network, this document assumes that a pseudowire can be
   provisioned statically or through signaling protocol as defined in
   [RFC4447].

   FC PW emulates a single FC link between exactly two endpoints. This
   document specifies the emulated PW encapsulation for FC. Figure 1
   describes the reference models which are derived from [RFC3985] to
   support the FC PW emulated services. FC PDUs are received by PE1's FC
   attachment channel, encapsulated at PE1, transported across MPLS


Black and Dunbar      Expires December 29, 2010                [Page 4]

Internet-Draft             FC Encapsulation                   June 2010


   network, decapsulated at PE2, and transmitted onward via the PE2's FC
   attachment channel.



         |<-------------- Emulated Service ----------------->|
         |                                                   |
         |          |<------- Pseudowire -------->|          |
         |          |                             |          |
         |          |    |<-- MPLS Tunnel -->|    |          |
         |          V    V                   V    V          |
         V   AC     +----+                   +----+    AC    V
   +-----+    |     | PE1|===================| PE2|     |    +-----+
   |     |----------|............PW1..............|----------|     |
   | CE1 |    |     |    |                   |    |     |    | CE2 |
   |     |----------|............PW2..............|----------|     |
   +-----+  ^ |     |    |===================|    |     | ^  +-----+
         ^  |       +----+                   +----+     | |  ^
         |  |   Provider Edge 1          Provider Edge 2  |  |
         |  |                                             |  |
   Customer |                                             | Customer
   Edge 1   |                                             | Edge 2
            |                                             |
            |                                             |
     Native FC service                             Native FC service

            Figure 1: PWE3 FC Interface Reference Configuration






















Black and Dunbar      Expires December 29, 2010                [Page 5]

Internet-Draft             FC Encapsulation                   June 2010


   The following reference model describes the termination point of each
   end of the PW within the PE:

              +-----------------------------------+
              |                PE                 |
      +---+   +-+  +-----+  +------+  +------+  +-+
      |   |   |P|  |     |  |PW ter|  | MPLS |  |P|
      |   |<==|h|<=| NSP |<=|minati|<=|Tunnel|<=|h|<== From PSN
      |   |   |y|  |     |  |on    |  |      |  |y|
      | C |   +-+  +-----+  +------+  +------+  +-+
      | E |   |                                   |
      |   |   +-+  +-----+  +------+  +------+  +-+
      |   |   |P|  |     |  |PW ter|  | MPLS |  |P|
      |   |==>|h|=>| NSP |=>|minati|=>|Tunnel|=>|h|==> To PSN
      |   |   |y|  |     |  |on    |  |      |  |y|
      +---+   +-+  +-----+  +------+  +------+  +-+
              |                                   |
              +-----------------------------------+
                 Figure 2: PW reference diagram

   The Native Service Processing (NSP) function includes

      - suppressing any FC Idle frames received from the PE's attached
        FC port,

      - re-generating FC Idle frames to send to the attached FC port
        when there are no FC data frames are received from PW WAN side,

      - selecting a subset of repetitive FC Primitive Sequences
        received from the attached FC port and passing them to the PW
        Termination Entity for both encapsulation and forwarding to the
        PW tunnel,

      - re-sending the last received FC primitive sequence to the
        attached FC port repetitively until a new frame is received
        from the PW WAN side, and

      - using the Alternate Simple Flow Control (ASFC) protocol for
        buffer management in concert with the peer PW PE's NSP
        function.

   The NSP function is specified in detail by [FC-BB-6].







Black and Dunbar      Expires December 29, 2010                [Page 6]

Internet-Draft             FC Encapsulation                   June 2010


  3. Encapsulation

   This specification provides port to port transport of FC encapsulated
   traffic. There are several port types defined by Fibre Channel,
   including:

     . An N_port is a port on the node (e.g. host or storage device)
        used with both FC-P2P or FC-SW topologies. Also known as a Node
        port.

     . An NL_port is a port on the node used with an FC-AL topology.
        Also known as a Node Loop port.

     . An F_port is a port on the switch that connects to a node point-
        to-point (i.e. connects to an N_port). Also known as a Fabric
        port. An F_port is not loop capable.

     . An FL_port is a port on the switch that connects to a FC-AL loop
        (i.e. to NL_ports). Also known as Fabric Loop port.

     . An E_port is a port used to connect two Fibre Channel switches.
        Also known as an Expansion port. When E_ports between two
        switches are connected to form a link, that link is referred to
        as an inter-switch link (ISL).

   Among the port types listed above, only the following FC connections
   (as specified in [FC-BB-6]) are supported by an FC PW over MPLS:

          - N-Port to N-Port

          - N-Port to F-Port

          - E-Port to E-Port

   FC Primitive Signals and FC-Port Login handling by the NSP function
   within the PE is defined in [FC-BB-6].

   This FC PW specification is limited to use with FC service classes 2,
   3 and F (see [FC-FS-2]).  Other FC service classes (e.g., 1, 4 and 6)
   MUST NOT be used with an FC PW.  This FC PW specification is limited
   to native FC attachment links that employ the 8b/10b transmission
   code used by FC (see [FC-FS-2]).  The protocol specified in this
   document is not sufficient to support attached FC links that use a
   64b/66b transmission code (e.g., 10GFC, 16GFC); such links MUST NOT
   be attached to an FC PW PE.




Black and Dunbar      Expires December 29, 2010                [Page 7]

Internet-Draft             FC Encapsulation                   June 2010


3.1. The Control Word

   The Generic PW Control Word, as defined in "PWE3 Control Word"
   [RFC4385] MUST be used for FC PW to facilitate the transport of short
   packets (by setting the Length field as detailed below), and convey
   the flag bit defined below. The structure of the Control Word is as
   follows:

                           1                   2                   3
       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 0 0 0| PT  |X|0 0|  Length   |     Sequence Number           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 3 - Control Word Structure

   The first four bits of the PW Control Word MUST be set to 0 by the
   ingress PE to indicate PW data.

   The Flags bits are in use to convey the PT - Payload Type indication.
   This field identifies the payload type carried within the PW PDU. The
   following types are defined:

           PT = 0: FC data frame.

           PT = 1: FC login frame.

           PT = 2: FC Primitive Sequence.

           PT = 6: FC Control Frame (refer to [FC-BB-6] for usage).

   X - This bit is not used by this version of the protocol. It SHOULD
   be set to zero by the sender and MUST be ignored by the receiver.

   The fragmentation bits (bits 8-9) are not used by the FC PW protocol.
   These bits may be used in the future for FC specific indications as
   defined in [RFC4385].

   The length field MUST be used for packets shorter than 64 bytes, and
   MUST be processed according to the rules specified in [RFC4385].

   The sequence number is not used for FC PW and MUST be set to 0 by the
   ingress PE, and MUST be ignored by the egress PE.





Black and Dunbar      Expires December 29, 2010                [Page 8]

Internet-Draft             FC Encapsulation                   June 2010


3.2. MTU Requirements

   The MPLS PSN MUST be able to transport the largest Fibre Channel
   encapsulation frame, including the overhead associated with the
   tunneling protocol. The maximum FC frame size without PW and MPLS
   labels (refer to Figure 4) is 2164 bytes. The MPLS PSN SHOULD
   accommodate frames of up to 2500 bytes to support future expansion of
   FC frames.

   Fragmentation, described in [RFC4623], SHALL NOT be used for an FC
   PW, therefore the network MUST be configured with a minimum MTU that
   is sufficient to transport the largest encapsulation frame.

3.3. Mapping of FC traffic to PW PDU

   FC frames and Primitive Sequences are transported over the PW. All
   packet types are carried over a single PW. In addition to the PW
   Control Word, an FC Encapsulation Header is included in the frame.
   This FC Encapsulation Header is not used in this version of the
   protocol. This field SHOULD be set to zero by the sender and MUST be
   ignored by the receiver.




























Black and Dunbar      Expires December 29, 2010                [Page 9]

Internet-Draft             FC Encapsulation                   June 2010


   Each FC frame is mapped to a PW PDU, including the Start Of Frame
   (SOF) delimiter, frame header, CRC field and the End Of Frame (EOF)
   delimiter, as shown in figure 4. The SOF and EOF frame delimiters are
   each encoded into a single byte as specified in [RFC3643], except
   that the codes for delimiters that apply only to FC service class 4
   (SOFi4, SOFc4, SOFn4, EOFdt, EOFdti, EOFrt, EOFrti) MUST NOT be used.
   The CRC in the frame is obtained directly from FC attachment channel,
   so that the PW PE is not required to re-calculate the CRC or to check
   the CRC in the received frame.

                           1                   2                   3
       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
      +---------------------------------------------------------------+
      |                    FC PW Control Word                         |
      +---------------------------------------------------------------+
      |                  FC Encapsulation Header                      |
      +---------------+-----------------------------------------------+
      |     SOF Code  |             Reserved                          |
      +---------------+-----------------------------------------------+
      |                                                               |
      +-----                      FC Data Frame                   ----+
      |                                                               |
      +---------------------------------------------------------------+
      |                              CRC                              |
      +---------------+-----------------------------------------------+
      |     EOF Code  |                Reserved                       |
      +---------------+-----------------------------------------------+

      Figure 4 - FC frame (SOF/EOF/CRC/Data) encapsulation within PW PDU

   FC Primitive Sequences and Primitive Signals are encapsulated in a PW
   PDU containing the encoded K28.5 character [FC-BB-6], followed by the
   encoded 3 data characters, as shown in Figure 5. Each K28.5 - Dxx.y -
   Dxx.y - Dxx.y set of 4 octets represents an FC ordered set, which is
   either a primitive signal or a primitive sequence for the FC PW.  All
   FC ordered sets start with a K28.5 control character, but the three
   following Dxx.y data characters differ depending on the ordered set.











Black and Dunbar      Expires December 29, 2010               [Page 10]

Internet-Draft             FC Encapsulation                   June 2010



                           1                   2                   3
       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
      +---------------------------------------------------------------+
      |                    FC PW Control Word                         |
      +---------------------------------------------------------------+
      |                  FC Encapsulation Header                      |
      +---------------+---------------+---------------+---------------+
      |     K28.5     |     Dxx.y     |     Dxx.y     |     Dxx.y     |
      +---------------+---------------+---------------+---------------+
      |                                                               |
      +----                                                       ----+
      |                                                               |
      +---------------+---------------+---------------+---------------+
      |     K28.5     |     Dxx.y     |     Dxx.y     |     Dxx.y     |
      +---------------+---------------+---------------+---------------+

             Figure 5 - FC Ordered Sets encapsulation within PW PDU

   Here are a couple of ordered set examples:

   o  Idle(Idle) is K28.5 - D21.4 - D21.5 - D21.5 (this FC primitive
      signal is sent when the FC link is idle).

   o  Link Reset Response(LRR) is K28.5 - D21.1 - D31.5 - D9.2 (this FC
      primitive sequence is used by FC link initialization and recovery
      protocols).

   The K28.5 10b control character received from the attached FC link is
   encoded for the FC PW as its 8b counterpart (0xBC).  The same 8b
   encoding is also used to encode a D28.5 data word; the receiving PW
   PE

   o  MUST check for presence of an 8b K28.5 value (0xBC) at the start
      of each ordered set (see Figure 5), MUST send that value as a 10b
      K28.5 character on the attached FC link,

   o  MUST send the following 3 Dxx.y 8b values as Dxx.y 10b characters
      on the attached FC link and MUST NOT send the 3 Dxx.y 8b values as
      10b Kxx.y characters on the attached FC link).

   A PW PDU may contain one or more encoded FC Ordered sets [FC-BB-6].
   The length field in the FC PW Control Word is used to indicate the
   packet length when the PW PDU contains multiple Ordered Sets.




Black and Dunbar      Expires December 29, 2010               [Page 11]

Internet-Draft             FC Encapsulation                   June 2010


   Idle Primitive Signals could be carried over the PW in the same
   manner as Primitive Sequences. However, [FC-BB-6] requires that Idle
   Primitive Signals be dropped by the Ingress PE and re-generated by
   the egress PE to save bandwidth consumed by FC (refer to [FC-BB-6]
   for further details).

   The egress PE extracts the Primitive Sequence or Primitive Signal
   from the received PW PDU. For a Primitive Sequence, the PE continues
   transmitting the same FC Ordered Set to its attached FC port until an
   FC frame or another ordered set is received over the PW.  A Primitive
   Signal is sent once, except that Idle Primitive Signals are sent
   continuously when there is nothing else to send.

   FC Control frames are transported over the PW, by encapsulating each
   frame in a PW PDU with PT=6 in the Control Word. FC Control Frame
   payloads are generated and terminated by the corresponding FC entity.
   FC Control frames are currently used for FC PW flow control (ASFC),
   ping and transmission of error indications. [FC-BB-6] specifies the
   generation and processing of FC Control Frames.



                           1                   2                   3
       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
      +---------------------------------------------------------------+
      |                    FC PW Control Word                         |
      +---------------------------------------------------------------+
      |                  FC Encapsulation Header                      |
      +---------------------------------------------------------------+
      |                                                               |
      +-----                FC Control Frame                      ----+
      |                                                               |
      +---------------------------------------------------------------+

             Figure 6 - FC Control frame encapsulation within PW PDU


3.4. PW failure mapping

   PW failure mapping, which are detected through PW signaling failure,
   PW status notifications as defined in [RFC4447], or through PW OAM
   mechanisms MUST be mapped to emulated signal failure indications.
   Sending the FC link failure indication to its attached FC link is
   performed by the NSP, as defined by [FC-BB-6], and is out of the
   scope of this document.



Black and Dunbar      Expires December 29, 2010               [Page 12]

Internet-Draft             FC Encapsulation                   June 2010


4. Signaling of FC Pseudowires

   RFC4447 specifies the use of the MPLS Label Distribution Protocol,
   LDP, as a protocol for setting up and maintaining pseudowires. This
   section describes the use of specific fields and error codes used to
   control FC PW.

   The PW Type field in the PWid FEC element and PW generalized ID FEC
   elements MUST be set to the "FC Port Mode" value in section 7 below.

   The Control Word is REQUIRED for FC pseudowires.  Therefore the C-Bit
   in the PWid FEC element and PW generalized ID FEC elements MUST be
   set. If the C-Bit is not set, the pseudowire MUST NOT be established
   and a Label Release MUST be sent with an "Illegal C-Bit" status code
   [RFC4447].

   The Fragmentation Indicator (Parameter ID = 0x09) is specified in
   [RFC4446] and its usage is defined in [RFC4623]. Since fragmentation
   is not used in FC PW, the fragmentation indicator parameter MUST be
   omitted from the Interface Parameter Sub-TLV.

5. Timing Considerations

   Correct Fibre Channel link operation requires that the FC link
   latency between CE1 and CE2 (refer to Figure 1) be:

   o  no more than one-half of the R_T_TOV (Receiver Transmitter Timeout
      Value, default value: 100 milliseconds) of the attached devices
      for Primitive Sequences;

   o  no more than one-half of the E_D_TOV (Error Detect Timeout Value,
      default value: 2 seconds) of the attached devices for frames; and

   o  within the R_A_TOV (Resource Allocation Timeout Value, default
      value: 10 seconds) of the attached fabric(s), if any.

   An FC PW MUST adhere to these three timing requirements and MUST NOT
   be used in environments where high or variable latency may cause
   these requirements to be violated.  See [FC-FS-2] for definitions of
   the three FC timeout values used above.

   Failure to adhere to the R_T_TOV requirement may result in FC link
   failures (e.g., caused by timeout of the FC link initialization
   protocol).  Failure to adhere to the other two requirements may cause
   incorrect Fibre Channel operation, including possible corruption of
   stored data when Fibre Channel is used to access storage systems.



Black and Dunbar      Expires December 29, 2010               [Page 13]

Internet-Draft             FC Encapsulation                   June 2010


   The PING and PING_ACK signals defined in Section 6.4.7 of [FC-BB-6]
   SHOULD be used to measure the current FC pseudowire latency between
   the CE devices.

   If the measured latency violates any of the above timing
   requirements, then the FC PW PE MUST generate a WAN Down event as
   specified in [FC-BB-6]. The WAN Down event causes the PE to
   continuously send NOS (an FC primitive sequence) on the native FC
   link to the attached FC Port (typically an E_Port on a switch in this
   case).  This immediately causes the FC link that is carried by the PW
   to be taken down, halting transmission of FC traffic.  However, it is
   not necessary to tear down the pseudowire itself in this situation
   (i.e., destroy the MPLS path set up by LDP).  The state machine in
   Section 6.4.2 of [FC-BB-6] specifies the protocol used to attempt to
   recover from the WAN Down event (i.e., bring the WAN back up).  If
   that protocol brings the WAN back up, FC traffic will resume and the
   standard FC link recovery protocol will bring the carried FC link
   back up. If the previous pseudowire was destroyed, attempts will be
   made to re-establish the path via LDP as part of recovering from the
   WAN Down event.

   If the PW round-trip latency remains above 100ms, the initialization
   protocol for the FC PW will repeatedly time out in attempting to
   recover from the WAN Down event, preventing FC recovery of the FC
   link carried by the PW.

6. Security Considerations

   FC PW does not change the security properties of the underlying MPLS
   PSN, rather it relies upon the PSN's mechanisms for encryption,
   integrity, and authentication as required.

   FC PW shares susceptibility to a number of pseudowire-layer attacks
   and implementations SHOULD use whatever mechanisms for
   confidentiality, integrity, and authentication are developed for PWs
   in general.  These methods are beyond the scope of this document.

   The protocols used to implement security in a Fibre Channel fabric
   are defined in [FC-SP]. These protocols operate at higher layers of
   the FC hierarchy and are transparent to the FC PW.

7. Applicability Statement

   FC PW allows the transparent transport of point-to-point Fibre
   Channel ports while saving network bandwidth by removing or reducing
   the FC Idle Signals and Primitive Sequences.



Black and Dunbar      Expires December 29, 2010               [Page 14]

Internet-Draft             FC Encapsulation                   June 2010


   o  The pair of CE devices operates as if they were directly connected
      by an FC link. In particular they react to Primitive Sequences on
      their local FC links in the standard way.

   o  The FC PW carries only FC data frames and a subset of the copies
      of an FC Primitive Sequence. Idle Primitive Signals encountered
      between FC data frames, and long streams of the same Primitive
      Sequence are suppressed over the PW thus saving bandwidth.

   o  The PW PE MUST generate Idle Primitive Signals to the attached FC
      link when there is no frame received from the MPLS network to
      transmit on the attached FC link.

   FC PW traffic should only traverse controlled MPLS or MPLS-TP
   networks. The network should enforce policing of incoming traffic and
   network resource/bandwidth allocation so that the FC PW delivery
   quality can be assured. To extend FC across an uncontrolled network,
   FC/IP SHOULD be used instead of an FC PW.

   This document does not provide any mechanisms for protecting FC PW
   against PSN outages. As a consequence, resilience of the emulated
   service to such outages is dependent upon MPLS-TE/MPLS-TP network.
   The NSP SHOULD use a WAN down event (as specified in [FC-BB-6]) to
   convey the PW status to the CE, to enable faster handling of the PSN
   outage.
























Black and Dunbar      Expires December 29, 2010               [Page 15]

Internet-Draft             FC Encapsulation                   June 2010


8. IANA Considerations

   IANA is requested to assign a new PW type as follows:

      PW type      Description           Reference
      --------     --------------        ----------
      0x001F       FC Port Mode          RFC XXXX

   The above value is suggested as the next available value.

   RFC Editor: Please replace RFC XXXX above with the RFC number of this
   document and remove this note.

   IANA should reserve the following Sub-TLV types which were
   tentatively allocated for FC PW. These Sub-TLV types were used for
   the FC PW Selective Retransmission protocol, which the working group
   has decided to eliminate. This reservation action prevents future use
   of these values for other purposes, just in case there are
   implementations of the Selective Retransmission protocol.

       Parameter  ID Length
      ---------  ---------
      0x12          4
      0x13          4
      0x14          4
      0x15          4

9. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.

10. Normative References

      [RFC3643]  Weber, R., et al, "Fibre Channel (FC) Frame
                 Encapsulation", RFC 3643, December 2003.

      [RFC3985]   Bryant, S., et al, "Pseudo Wire Emulation Edge-to-Edge
                 (PWE3) Architecture", RFC 3985, March 2005.

      [RFC4446]   Martini, L., "IANA Allocations for Pseudowire Edge to
                 Edge Emulation (PWE3)", RFC 4446, April 2006.

      [RFC4447]   Martini, L., et al, "Pseudowire Setup and Maintenance
                 using the Label Distribution Protocol (LDP)", RFC4447,
                 April 2006.




Black and Dunbar      Expires December 29, 2010               [Page 16]

Internet-Draft             FC Encapsulation                   June 2010


      [RFC4385]  Bryant, S., et al, "Pseudowire Emulation Edge-to-
                 Edge(PWE3) Control Word for use over an MPLS PSN",
                 RFC4385, February 2006.

      [RFC4623]   Malis, A., Townsley, M., "PWE3 Fragmentation and
                 Reassembly", RFC 4623, August 2006.

      [FC-BB-6]    "Fibre Channel Backbone-6" (FC-BB-6), T11 Project
                 2159-D, Rev 1.01, June 2010.

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

      [FC-FS-2]  "Fibre Channel - Framing and Signaling-2 (FC-FS-2)",
                 ANSI INCITS 424:2007, August 2007.

      [FC-SP]     "Fibre Channel - Security Protocols" (FC-SP), ANSI
                 INCITS 426:2007, February 2007.


11. Informative references

      [RFC3821]   M. Rajogopal, E. Rodriguez, "Fibre Channel over TCP/IP
                 (FCIP)", RFC 3821, July 2004.

Authors' Addresses

      David L. Black (ed.)
      EMC Corporation
      176 South Street
      Hopkinton, MA 01748
      Phone: +1 (508) 293-7953
      Email: black_david@emc.com

      Linda Dunbar (ed.)
      Huawei Technologies
      1700 Alma Drive, Suite 500
      Plano, TX 75075, USA
      Phone: +1 (972) 543-5849
      Email: ldunbar@huawei.com









Black and Dunbar      Expires December 29, 2010               [Page 17]

Internet-Draft             FC Encapsulation                   June 2010


Contributors' Addresses

      Moran Roth
      Corrigent Systems
      101, Metro Drive
      San Jose, CA 95110
      Phone: +1-408-392-9292
      Email: moranr@corrigent.com

      Ronen Solomon
      Corrigent Systems
      126, Yigal Alon st.
      Tel Aviv, ISRAEL
      Phone: +972-3-6945316
      Email: ronens@corrigent.com

      Munefumi Tsurusawa
      KDDI R&D Laboratories Inc.
      Ohara 2-1-15, Fujimino-shi,
      Saitama, Japan
      Phone: +81-49-278-7828

Intellectual Property Statement

   The IETF Trust 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 any IETF 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.

   Copies of Intellectual Property 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
   any standard or specification contained in an IETF Document. Please
   address the information to the IETF at ietf-ipr@ietf.org.





Black and Dunbar      Expires December 29, 2010               [Page 18]

Internet-Draft             FC Encapsulation                   June 2010


Disclaimer of Validity

   All IETF Documents and the information contained therein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST 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 THEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

Acknowledgment

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


































Black and Dunbar      Expires December 29, 2010               [Page 19]


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