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

Versions: 00 01 02 03 04 05 06 07 RFC 4619

Network Working Group                              Luca Martini (Editor)
Internet Draft                                       Cisco Systems, Inc.
Expiration Date: August 2006                        Claude Kawa (Editor)
Andrew Malis (Editor)                                  Oz Communications
Tellabs




                                                           February 2006


 Encapsulation Methods for Transport of Frame Relay Over MPLS Networks


                   draft-ietf-pwe3-frame-relay-07.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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/1id-abstracts.html

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

Abstract

   A frame relay pseudo wire is a mechanism that exists between a
   provider's edge network nodes and support as faithfully as possible
   frame relay services over MPLS packet switched network (PSN). This
   document describes the detailed encapsulation necessary to transport
   frame relay packets over an MPLS network.




Martini, et al.                                                 [Page 1]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006




Table of Contents

    1      Specification of Requirements  ..........................   3
    2      Co-authors  .............................................   3
    3      Acronyms and Abbreviations  .............................   4
    4      Introduction  ...........................................   4
    5      Applicability Statement  ................................   6
    6      General encapsulation method  ...........................   6
    7      Frame Relay over MPLS PSN for the One-to-One Mode  ......   7
    7.1    MPLS PSN Tunnel and PW  .................................   7
    7.2    Packet Format over MPLS PSN  ............................   8
    7.3    The Control Word  .......................................   9
    7.4    The Martini Legacy Mode Control Word  ...................  10
    7.5    PW packet processing  ...................................  10
    7.5.1  Encapsulation of Frame relay frames  ....................  10
    7.5.2  Setting the sequence number  ............................  11
    7.6    Decapsulation of PW packets  ............................  11
    7.6.1  Processing the sequence number  .........................  12
    7.6.2  Processing of the Length Field by the Receiver  .........  12
    7.7    MPLS Shim EXP Bit Values  ...............................  13
    7.8    MPLS Shim S Bit Value  ..................................  13
    7.9    Control Plane Details for Frame Relay Service  ..........  13
    7.9.1  Frame Relay Specific Interface Parameter sub-TLV  .......  13
    8      Frame Relay Port Mode  ..................................  14
    9      Congestion Control  .....................................  14
   10      IANA Considerations  ....................................  15
   11      Security Considerations  ................................  15
   12      Full Copyright Statement  ...............................  15
   13      Intellectual Property Statement  ........................  16
   14      Normative References  ...................................  16
   15      Informative References  .................................  17
   16      Author Information  .....................................  18
   17      Contributing Author Information  ........................  19
















Martini, et al.                                                 [Page 2]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006


1. Specification of Requirements

   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.

   Below are the definitions for the terms used throughout the document.
   PWE3 definitions can be found in [PWE3REQ, RFC3985]. This section
   defines terms specific to frame relay.

     - Forward direction.

       The forward direction is the direction taken by the frame being
       forwarded.

     - Backward direction.

       In frame relay it is the direction opposite to the direction
       taken by a frame being forwarded (see also forward direction).


2. Co-authors

   The following are co-authors of this document:

   Nasser El-Aawar           Level 3 Communications, LLC
   Eric C. Rosen             Cisco Systems
   Daniel Tappan             Cisco Systems
   Thomas K. Johnson         Litchfield Communications
   Kireeti Kompella          Juniper Networks, Inc.
   Steve Vogelsang           Laurel Networks, Inc.
   Vinai Sirkay              Reliance Infocomm
   Ravi Bhat                 Nokia
   Nishit Vasavada           Nokia
   Giles Heron               Tellabs
   Dimitri Stratton Vlachos  Mazu Networks,Inc.
   Chris Liljenstolpe        Cable & Wireless
   Prayson Pate              Overture Networks, Inc













Martini, et al.                                                 [Page 3]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006


3. Acronyms and Abbreviations

      BECN    Backward Explicit Congestion Notification
      CE      Customer Edge
      C/R     Command/Response
      DE      Discard Eligibility
      DLCI    Data Link Connection identifier
      FCS     Frame Check Sequence
      FECN    Forward Explicit Congestion Notification
      FR      Frame Relay
      LSP     Label Switched Path
      LSR     Label Switching Router
      MPLS    Multiprotocol Label Switching
      MTU     Maximum Transfer Unit
      NNI     Network-Network Interface
      PE      Provider Edge
      PSN     Packet Switched Network
      PW      Pseudo Wire
      PWE3    Pseudo Wire Emulation Edge to Edge
      POS     Packet over SONET/SDH
      PVC     Permanent Virtual Circuit
      QoS     Quality of Service
      SVC     Switched Virtual Circuit
      UNI     User-Network Interface
      VC      Virtual Circuit


4. Introduction

   In an MPLS or IP network, it is possible to use control protocols
   such as those specified in [CONTROL] to set up "Pseudo Wires" that
   carry the the Protocol Data Units of layer 2 protocols across the
   network. A number of these emulated Pseudo Wires (PW) may be carried
   in a single tunnel. The main functions required to support frame
   relay PW by a PE include:

     - Encapsulation of frame relay specific information in a suitable
       pseudo wire (PW) packet,
     - Transfer of a PW packet across an MPLS network for delivery to a
       peer PE.
     - Extraction of frame relay specific information from a PW packet
       by the remote peer PE,
     - Regeneration of native frame relay frames for forwarding across
       an egress port of the remote peer PE,
     - Execution of any other operations as required to support frame
       relay service.

   This document specifies the encapsulation for the emulated frame



Martini, et al.                                                 [Page 4]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006


   relay VC over an MPLS PSN. Although different layer 2 protocols
   require different information to be carried in this encapsulation, an
   attempt has been made to make the encapsulation as common as possible
   for all layer 2 protocols.  Other layer 2 protocols are described in
   separate documents. [ATM] [ETH] [PPP]

   The following figure describes the reference models which are derived
   from [RFC3985] to support the frame relay PW emulated services.

         |<-------------- Emulated Service ---------------->|
         |                                                  |
         |          |<------- Pseudo Wire ------>|          |
         |          |                            |          |
         |          |    |<-- PSN Tunnel -->|    |          |
         | PW End   V    V                  V    V  PW End  |
         V Service  +----+                  +----+  Service V
   +-----+    |     | PE1|==================| PE2|     |    +-----+
   |     |----------|............PW1.............|----------|     |
   | CE1 |    |     |    |                  |    |     |    | CE2 |
   |     |----------|............PW2.............|----------|     |
   +-----+  ^ |     |    |==================|    |     | ^  +-----+
         ^  |       +----+                  +----+     | |  ^
         |  |   Provider Edge 1         Provider Edge 2  |  |
         |  |       (PE1)                    (PE2)       |  |
   Customer |                                            | Customer
   Edge 1   |                                            | Edge 2
            |                                            |
            |                                            |
    Attachment Circuit (AC)                    Attachment Circuit (AC)
   native frame relay service                 native frame relay service


      Figure 1: PWE3 frame relay PVC Interface Reference Configuration


   Two mapping modes can be defined between frame relay VCs and pseudo
   wires:  The first one is called "one-to-one" mapping, because there
   is a one-to-one correspondence between a frame relay VC and one
   Pseudo Wire. The second mapping is called "many-to-one" mapping or
   "port mode" because multiple frame relay VCs assigned to a port are
   mapped to one pseudo wire. The "port mode" encapsulation is identical
   to HDLC pseudo wire encapsulation which is described in [PPP].









Martini, et al.                                                 [Page 5]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006


5. Applicability Statement

   Frame Relay over PW service is not intended to perfectly emulate the
   traditional frame relay service, but it can be used for applications
   that need frame relay transport service.

   The following are notable differences between traditional frame relay
   service, and the protocol described in this document:

     - Frame ordering can be preserved using the OPTIONAL sequence field
       in the control word, however implementations are not required to
       support this feature.

     - The Quality of Service model for traditional frame relay can be
       emulated , however this is outside the scope of this document.

     - A Frame Relay Port mode PW, does not process any frame relay
       status messages or alarms as described in [Q922] [Q933]

     - The frame relay BECN, and FECN bit are transparent to the MPLS
       network , and cannot reflect the status of the MPLS network.

     - Support for frame relay SVC and SPVC is outside the scope of this
       document.

     - Frame relay LMI is terminated locally in the PE connected to the
       frame relay attachment circuit.

     - The support of PVC link integrity check is outside the scope of
       this document.


6. General encapsulation method

   The general frame relay pseudo wire packet format for carrying frame
   relay information (user's payload and frame relay control
   information) between two PEs is shown in Figure 2.














Martini, et al.                                                 [Page 6]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006


          +-------------------------------+
          |                               |
          |    MPLS Transport header      |
          |       (As required)           |
          +-------------------------------+
          |   Pseudo Wire (PW) Header     |
          +-------------------------------+
          |        Control Word           |
          +-------------------------------+
          |          FR Service           |
          |           Payload             |
          +-------------------------------+


   Figure 2 - General format of frame relay encapsulation over PSN

   The PW packet consists of the following fields: Control word, and
   Payload preceded by the MPLS Transport and pseudo wire header. The
   meaning of the different fields is as follows:

        -i. MPLS Transport header is specific to the MPLS network.  This
            header is used to switch the PW packet through the MPLS
            core.
       -ii. PW header contains an identifier for multiplexing PWs within
            an MPLS tunnel.
      -iii. Control Word contains protocol control information for
            providing a frame relay service. Its structure is provided
            in the following sections.
       -iv. The contents of the frame relay service payload field
            depends on the mapping mode. In general it contains the
            layer 2 frame relay frame.


7. Frame Relay over MPLS PSN for the One-to-One Mode

7.1. MPLS PSN Tunnel and PW

   MPLS label switched paths (LSPs) called "MPLS Tunnels" are used
   between PEs and within the MPLS core network for forwarding purposes
   of PW packets. An MPLS tunnel corresponds to "PSN Tunnel" of Figure
   1.

   Several "Pseudo Wires" may be nested inside one MPLS tunnel. Each PW
   carries the traffic of a single frame relay VC. In this case the PW
   header is an MPLS label called the PW label.






Martini, et al.                                                 [Page 7]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006


7.2. Packet Format over MPLS PSN

   For the one-to-one mapping mode for frame relay over an MPLS network,
   the PW packet format is shown in Figure 3.

    +-------------------------------+
    |      MPLS Tunnel label(s)     | n*4 octets (four octets per label)
    +-------------------------------+
    |      PW label                 |  4 octets
    +-------------------------------+
    |       Control Word            |
    |      (See Figure 4)           | 4 octets
    +-------------------------------+
    |            Payload            |
    |      (Frame relay frame       |
    |       information field)      | n octets
    |                               |
    +-------------------------------+


   Figure 3 - frame relay Over MPLS PSN Packet for the One-to-One
   Mapping

   The meaning of the different fields is as follows:

     - MPLS Tunnel label(s)

       The MPLS Tunnel label(s) corresponds to the MPLS transport header
       of Figure 2.  The label(s) is/are used by MPLS LSRs to forward a
       PW packet from one PE to the other.

     - PW Label

       The PW label identifies one PW (i.e. one LSP) assigned to a frame
       relay VC in one direction. It corresponds to the PW header of
       Figure 2. Together the MPLS Tunnel label(s) and PW label form an
       MPLS label stack [RFC3032].

     - Control Word

       The Control Word contains protocol control information. Its
       structure is shown in Figure 4.

     - Payload

       The payload field corresponds to X.36/X.76 frame relay frame
       information field with bit/byte stuffing, frame relay header
       removed, and FCS removed .  It is RECOMMENDED to support a frame



Martini, et al.                                                 [Page 8]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006


       size of at least 1600 bytes. The maximum length of the payload
       field MUST be agreed upon by the two PEs. This can be achieved by
       using the MTU interface parameter when the PW is established.
       [CONTROL]


7.3. The Control Word

   The control word defined below is REQUIRED for frame relay one-to-one
   mode.  The control word carries certain frame relay specific
   information that is necessary to regenerate the frame relay frame on
   the egress PE.  Additionally, the control word also carries a
   sequence number that can be used to preserve sequentiality when
   carrying frame relay over an MPLS network. Its structure is as
   follows:

    0                   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|F|B|D|C|Res|  Length   | Sequence Number               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Figure 4 - Control Word structure for the one-to-one mapping mode

   The meaning of the Control Word fields (Figure 4) is as follows (see
   also [X36 and X76] for frame relay bits):

     - bits 0 to 3

       In the above diagram the first 4 bits MUST be set to 0 to
       indicate PW data.

     - F (bit 4) FR FECN (Forward Explicit Congestion Notification) bit.

     - B (bit 5) FR BECN (Backward Explicit Congestion Notification)
       bit.

     - D (bit 6) FR DE bit (Discard Eligibility) bit.

     - C (bit 7) FR frame C/R (Command/Response) bit.

     - Res  (bits 8 and 9):  These bits are reserved and MUST be set to
       0 upon transmission and ignored upon reception.







Martini, et al.                                                 [Page 9]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006


     - Length (bits 10 to 15)

       If the Pseudo Wire traverses a network link that requires a
       minimum frame size (a notable example is Ethernet), padding is
       required to reach its minimum frame size.  If the frame's length
       (defined as the length of the layer 2 payload plus the length of
       the control word) is less than 64 octets, the length field MUST
       be set to the PW payload length. Otherwise the length field MUST
       be set to zero. The value of the length field, if non-zero, is
       used to remove the padding characters by the egress PE.

     - Sequence number (Bit 16 to 31)

       Sequence numbers provide one possible mechanism to ensure the
       ordered delivery of PW packets. The processing of the sequence
       number field is OPTIONAL. The sequence number space is a 16 bit,
       unsigned circular space.  The sequence number value 0 is used to
       indicate that the sequence number check algorithm is not used.


7.4. The Martini Legacy Mode Control Word

   For backward compatibility to existing implementations the following
   version of the control word is defined as the "martini mode CW" for
   frame relay.

    0                   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|B|F|D|C|Res|  Length   | Sequence Number               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 4 - Control Word structure for the frame relay martini mode

   Note that the "B" and "F" bits are reversed.

   This control word format is used for PW type "Frame Relay DLCI (
   Martini Mode )"


7.5. PW packet processing

7.5.1. Encapsulation of Frame relay frames

   The encapsulation process of a frame relay frame is initiated when a
   PE receives a frame relay frame from one of its frame relay UNI or
   NNI interfaces. The PE generates the following fields of the control
   word from the corresponding fields of the frame relay frame as



Martini, et al.                                                [Page 10]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006


   follows:

     - Command/Response (C/R or C) bit: The C bit is copied unchanged in
       the PW Control Word.
     - The DE bit of the frame relay frame is copied into the D bit
       field. However if the D bit is not already set, it MAY be set as
       a result of ingress frame policing. If not already set by the
       copy operation, setting of this bit by a PE is OPTIONAL. The PE
       MUST NOT clear this bit (set it to 0 if it was received with the
       value of 1).
     - The FECN bit of the frame relay frame is copied into the F bit
       field.  However if the F bit is not already set, it MAY be set to
       reflect a congestion situation detected by the PE. If not already
       set by the copy operation, setting of this bit by a PE is
       OPTIONAL. The PE MUST NOT clear this bit (set it to 0 if it was
       received with the value of 1).
     - The BECN bit of the frame relay frame is copied into the B bit
       field.  However if the B bit is not already set, it MAY be set to
       reflect a congestion situation detected by the PE. If not already
       set by the copy operation, setting of this bit by a PE is
       OPTIONAL. The PE MUST NOT clear this bit (set it to 0 if it was
       received with the value of 1).
     - If the PW packet length (defined as the length of the payload
       plus the length of the control word) is less than 64 octets, the
       length field MUST be set to the packet's length. Otherwise the
       length field MUST be set to zero.
     - The sequence number field is processed if the PW uses sequence
       numbers. [CW]
     - The payload of the PW packet is the contents of ITU-T
       Recommendations X.36/X.76 [X36] [X76] frame relay frame
       information field stripped from any bit or byte stuffing.


7.5.2. Setting the sequence number

   For a given PW, and a pair of routers PE1 and PE2, if PE1 supports
   packet sequencing then the procedures in [CW] section 4.1 MUST be
   followed.


7.6. Decapsulation of PW packets

   When a PE receives a PW packet, it processes the different fields of
   the control word in order to decapsulate the frame relay frame for
   transmission to a CE on a frame relay UNI or NNI. The PE performs the
   following actions (not necessarily in the order shown):





Martini, et al.                                                [Page 11]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006


     - It generates the following frame relay frame header fields from
       the corresponding fields of the PW packet.
     - The C/R bit MUST be copied in the frame relay header.
     - The D bit MUST be copied into the frame relay header DE bit.
     - The F bit MUST be copied into the frame relay header FECN bit. If
       the F bit is set to zero, the FECN bit may be set to one,
       depending on the congestion state of the PE device in the forward
       direction. Changing the state of this bit by a PE is OPTIONAL.
     - The B bit MUST be copied into the frame relay header BECN bit. If
       the B bit is set to zero, the BECN bit may be set to one,
       depending on the congestion state of the PE device in the
       backward direction. Changing the state of this bit by a PE is
       OPTIONAL.
     - It processes the length and sequence field, the details of which
       are in the following sub-sections.
     - It copies the frame relay information field from the contents of
       the PW packet payload after removing any padding.

   Once the above fields of a FR frame have been processed, the standard
   HDLC operations are performed on the frame relay frame: the HDLC
   header is added, any bit or byte stuffing is added as required, and
   the FCS is also appended to the frame. The FR frame is then queued
   for transmission on the selected frame relay UNI or NNI interface.


7.6.1. Processing the sequence number

   If a router PE2 supports receive sequence number processing, then the
   procedures in [CW] section 4.2 MUST be used.


7.6.2. Processing of the Length Field by the Receiver

   Any padding octet, if present, in the payload field of a PW packet
   received MUST be removed before forwarding the data.

     - If the Length field is set to zero then there are no padding
       octets following the payload field.
     - Else if the payload is longer then the length specified in the
       control word padding characters are removed based on the length
       field.










Martini, et al.                                                [Page 12]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006


7.7. MPLS Shim EXP Bit Values

   If it is desired to carry Quality of Service information, the Quality
   of Service information SHOULD be represented in the EXP field of the
   PW MPLS label. If more than one MPLS label is imposed by the ingress
   LSR, the EXP field of any labels higher in the stack SHOULD also
   carry the same value.


7.8. MPLS Shim S Bit Value

   The ingress LSR, PE1, MUST set the S bit of the PW label to a value
   of 1 to denote that the PW label is at the bottom of the stack.


7.9. Control Plane Details for Frame Relay Service

   The PE MUST provide frame relay PVC status signaling to the frame
   relay network. If the PE detects a service-affecting condition for a
   particular DLCI, as defined in [Q933] Q.933 Annex A.5 sited in IA
   FRF1.1, the PE MUST communicate to the remote PE the status of the PW
   that corresponds to the frame relay DLCI status. The Egress PE SHOULD
   generate the corresponding errors and alarms as defined in [Q922]
   [Q933] on the egress Frame relay PVC.

   There are two frame relay flags to control word bit mappings
   described below. The legacy bit ordering scheme will be used for a PW
   of type 0x0001 "Frame Relay DLCI (Martini Mode)", while the new bit
   ordering scheme will be used for a PW of type 0x0019 "Frame Relay
   DLCI". The IANA allocation registry of "Pseudowire Type" is defined
   in [IANA] along with initial allocated values.


7.9.1. Frame Relay Specific Interface Parameter sub-TLV

   A separate document [CONTROL], describes the PW control, and
   maintenance protocol in detail including generic interface parameter
   sub-TLVs. The interface parameter information, when applicable, MUST
   be used to validate that the PEs, and the ingress and egress ports at
   the edges of the circuit, have the necessary capabilities to
   interoperate with each other.  The Interface parameter TLV is defined
   in [CONTROL], the IANA registry with initial values for interface
   parameter sub-TLV types is defined in [IANA], but the frame relay
   specific interface parameter sub-TLV types are specified as follows:







Martini, et al.                                                [Page 13]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006


     - 0x08 Frame Relay Header Length Sub-TLV.

       An optional 16 bit value indicating the length of the FR Header
       expressed in octets. This OPTIONAL interface parameter Sub-TLV
       can have value of 2, 3, or 4, with the default being equal to 2.
       If this Sub-TLV is not present the default value of 2 is assumed.


8. Frame Relay Port Mode

   Frame relay port mode PW shares the same encapsulation as the HDLC
   PW, and is described in the respective document. [PPP]



9. Congestion Control

   As explained in [RFC3985], the PSN carrying the PW may be subject to
   congestion, with congestion characteristics depending on PSN type,
   network architecture, configuration, and loading. During congestion
   the PSN may exhibit packet loss that will impact the service carried
   by the frame relay PW. In addition, since frame relay PWs carry an
   variety of services across the PSN, including but not restricted to
   TCP/IP, they may or may not behave in a TCP-friendly manner
   prescribed by [RFC2914]. In the presence of services that reduce
   transmission rate, frame relay PWs may thus consume more than their
   fair share and in that case SHOULD be halted.

   Whenever possible, frame relay PWs should be run over traffic-
   engineered PSNs providing bandwidth allocation and admission control
   mechanisms.  IntServ-enabled domains providing the Guaranteed Service
   (GS) or DiffServ-enabled domains using EF (expedited forwarding) are
   examples of traffic-engineered PSNs. Such PSNs will minimize loss and
   delay while providing some degree of isolation of the frame relay
   PW's effects from neighboring streams.

   It should be noted that when transporting Frame Relay, DiffServ-
   enabled domains may use AF (Assured Forwarding) and/or DF (Default
   Forwarding) instead of EF, in order to place less burden on the
   network and gain additional statistical multiplexing advantage. In
   particular, if the CIR of a Frame Relay VC is zero, then it is
   equivalent to a best-effort UDP over IP stream regarding congestion -
   the network is free to drop frames as necessary. In this case, the
   "DF" PHB would be appropriate in a diff-serv-TE domain.
   Alternatively, if the CIR of a Frame Relay VC is nonzero and the DE
   bit is zero in the FR header, then "AF31" would be appropriate to
   use, and if the CIR of a Frame Relay VC is nonzero, but the DE bit is
   on, then "AF32" would be appropriate [RFC3270].



Martini, et al.                                                [Page 14]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006


   The PEs SHOULD monitor for congestion (by using explicit congestion
   notification, [VCCV], or by measuring packet loss) in order to ensure
   that the service using the frame relay PW may be maintained. When a
   PE detects significant congestion while receiving the PW PDUs, the
   BECN bits of the frame relay frame transmitted on the same PW SHOULD
   be set to notify the remote PE, and the remote frame relay switch of
   the congestion situation. In addition, the FECN bits SHOULD be set in
   the FR frames sent out the attachment circuit, to give the FR DTE a
   chance to adjust its transport layer advertised window if possible.

   If the PW has been set up using the protocol defined in [CONTROL],
   then procedures specified in [CONTROL] for status notification can be
   used to disable packet transmission on the ingress PE from the egress
   PE. The PW may be restarted by manual intervention, or by automatic
   means after an appropriate waiting time.


10. IANA Considerations

   This document has no IANA Actions.


11. Security Considerations

   PWE3 provides no means of protecting the contents or delivery of the
   PW packets on behalf of the native service. PWE3 may, however,
   leverage security mechanisms provided by the MPLS Tunnel Layer. A
   more detailed discussion of PW security is give in [RFC3985, CONTROL,
   PWE3REQ].


12. Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

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





Martini, et al.                                                [Page 15]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006


13. Intellectual Property Statement

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

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

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


14. Normative References

   [CONTROL] Luca Martini, et al., "Pseudowire Setup and Maintenance
        using LDP", draft-ietf-pwe3-control-protocol-16.txt,
        March 2005, work in progress.

   [CW] "PWE3 Control Word for use over an MPLS PSN", S. Bryant,
        G. Swallow, D. McPherson, draft-ietf-pwe3-cw-06.txt, ( work in
        progress ), October 2005.

   [ITUG] ITU Recommendation G.707, "Network Node Interface For The
        Synchronous Digital Hierarchy", 1996.

   [RFC3032] E. Rosen, et al., RFC 3032, MPLS Label Stack encoding,
        January 2001.

   [RFC3031] E. Rosen, et al., RFC 3031, MPLS Architecture, January
        2001.

   [IANA] "IANA Allocations for pseudo Wire Edge to Edge Emulation

   (PWE3)" Martini,Townsley, draft-ietf-pwe3-iana-allocation-09.txt
        (work in progress), April 2004



Martini, et al.                                                [Page 16]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006


   [PPP] "Encapsulation Methods for Transport of PPP/HDLC Over MPLS
         Networks", draft-ietf-pwe3-hdlc-ppp-encap-05.txt April 2005


15. Informative References

   [RFC3985] Stewart Bryant, et al., PWE3 Architecture,
        RFC3985

   [VCCV] Nadeau, T., et al."Pseudo Wire Virtual Circuit Connection
        Verification (VCCV)", Internet Draft
        draft-ietf-pwe3-vccv-08.txt, October 2005. (work in progress)

   [FRAG] Andrew G. Malis, et al., PWE3 Fragmentation and
        Reassembly, draft-ietf-pwe3-fragmentation-08.txt,
        February 2005, ( work in progress ).

   [ATM] "Encapsulation Methods for Transport of ATM Over MPLS
        Networks",  draft-ietf-pwe3-atm-encap-05.txt April 2005
        (work in progress)

   [ETH] "Encapsulation Methods for Transport of Ethernet Over
        MPLS Networks", draft-ietf-pwe3-ethernet-encap-06.txt.
        February 2005 (work in progress)

   [I233] ITU-T Recommendation I.233.1, ISDN frame relay bearer
        service, Geneva, October 1991.

   [FRF1] FRF.1.2, Frame relay PVC UNI Implementation Agreement,
        Frame Relay Forum, April 2000.

   [FRF2] FRF.2.2, Frame relay PVC UNI Implementation Agreement,
        Frame Relay Forum, April 2002

   [FRF4] FRF.4.1, Frame relay SVC UNI Implementation Agreement,
        Frame Relay Forum, January 2000.

   [FRF10] FRF.10.1, Frame relay SVC NNI Implementation Agreement,
        Frame Relay Forum, January 2000.

   [FRF13] FRF.13, Service Level Definition Implementation
         Agreement, Frame Relay Forum, August 1998.

   [FRF14] FRF.14, Physical layer Implementation Agreement, Frame
        Relay Forum, December 1998.

   [PWE3REQ] XiPeng Xiao, et al., RFC 3916.




Martini, et al.                                                [Page 17]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006


   [X36] ITU-T Recommendation X.36, Interface between a DTE and
        DCE for public data networks providing frame relay,
        Geneva, 2000.

   [X76] ITU-T Recommendation X.76, Network-to-network interface
        between public data networks providing frame relay
        services, Geneva,2000.

   [Q922] ITU-T Recommendation Q.922 Specification for Frame Mode
        Basic call control, ITU Geneva 1995

   [Q933] ITU-T Recommendation Q.933 Specification for Frame Mode
        Basic call control, ITU Geneva 2003

   [RFC2914] S Floyd, rfc2914, "Congestion Control Principles",
        September 2000

   [RFC3270] F. Le Faucheur, et al., rfc3270,"Multi-Protocol Label
        Switching (MPLS) Support of Differentiated Services",May 2002


16. Author Information


   Luca Martini
   Cisco Systems, Inc.
   9155 East Nichols Avenue, Suite 400
   Englewood, CO, 80112
   e-mail: lmartini@cisco.com


   Claude Kawa
   OZ Communications
   Windsor Station
   1100, de la Gauchetie`re St West
   Montreal QC Canada
   H3B 2S2
   e-mail: claude.kawa@oz.com


   Andrew G. Malis
   Tellabs
   90 Rio Robles Dr.
   San Jose, CA 95134
   e-mail: Andy.Malis@tellabs.com






Martini, et al.                                                [Page 18]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006


17. Contributing Author Information


   Kireeti Kompella
   Juniper Networks
   1194 N. Mathilda Ave
   Sunnyvale, CA 94089
   e-mail: kireeti@juniper.net


   Giles Heron
   Tellabs
   Abbey Place
   24-28 Easton Street
   High Wycombe
   Bucks
   HP11 1NT
   UK
   e-mail: giles.heron@tellabs.com


   Rao Cherukuri
   Juniper Networks
   1194 N. Mathilda Ave
   Sunnyvale, CA 94089


   Dimitri Stratton Vlachos
   Mazu Networks, Inc.
   125 Cambridgepark Drive
   Cambridge, MA 02140
   e-mail: d@mazunetworks.com


   Chris Liljenstolpe
   Cable & Wireless
   11700 Plaza America Drive
   Reston, VA 20190
   e-mail: chris@cw.net


   Nasser El-Aawar
   Level 3 Communications, LLC.
   1025 Eldorado Blvd.
   Broomfield, CO, 80021
   e-mail: nna@level3.net





Martini, et al.                                                [Page 19]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006



   Eric C. Rosen
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough, MA 01719
   e-mail: erosen@cisco.com


   Dan Tappan
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough, MA 01719
   e-mail: tappan@cisco.com


   Prayson Pate
   Overture Networks, Inc.
   507 Airport Boulevard
   Morrisville, NC, USA 27560
   e-mail: prayson.pate@overturenetworks.com


   David Sinicrope
   Ericsson IPI
   e-mail: david.sinicrope@ericsson.com


   Ravi Bhat
   Nokia
   e-mail: ravi.bhat@nokia.com


   Nishit Vasavada
   Nokia
   e-mail: nishit.vasavada@nokia.com


   Steve Vogelsang
   Laurel Networks, Inc.
   Omega Corporate Center
   1300 Omega Drive
   Pittsburgh, PA 15205
   e-mail: sjv@laurelnetworks.com








Martini, et al.                                                [Page 20]

Internet Draft     draft-ietf-pwe3-frame-relay-07.txt      February 2006



   Vinai Sirkay
   Redback Networks
   300 Holger Way,
   San Jose, CA 95134
   e-mail: sirkay@technologist.com













































Martini, et al.                                                [Page 21]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/