[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
Internet Draft                                       Cisco Systems, Inc.
Expiration Date: August 2005                                 Claude Kawa
Andrew Malis                                           Oz Communications
Tellabs




                                                           February 2005


 Encapsulation Methods for Transport of Frame Relay Over MPLS Networks


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

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.


   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). Two
   mapping modes are defined. The first, one-to-one mapping mode, is
   characterized by a one to one relationship between a frame relay VC
   and a pair of MPLS LSPs. The second mode is known as port mode or



Martini, et al.                                                 [Page 1]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005


   many-to-one mapping mode.


Table of Contents

    1      Specification of Requirements  ..........................   3
    2      Co-authors  .............................................   3
    3      Acronyms and Abbreviations  .............................   4
    4      Introduction  ...........................................   4
    5      General encapsulation method  ...........................   6
    6      Frame Relay over MPLS PSN for the One-to-One Mode  ......   7
    6.1    MPLS PSN Tunnel and PW  .................................   7
    7      Details Specific to Particular Emulated Services  .......   7
    7.1    Frame Relay  ............................................   7
    7.2    Frame-Relay Specific Interface Parameters  ..............   7
    7.3    One-to-One Mapping and PW Packet Format over MPLS PSN  ..   8
    7.4    The Control Word  .......................................   9
    7.5    The Martini Legacy Mode Control Word  ...................  10
    7.6    PW packet processing  ...................................  11
    7.6.1  Generation of PW packets  ...............................  11
    7.6.2  Setting the sequence number  ............................  11
    7.7    Reception of PW packets  ................................  12
    7.7.1  Processing the sequence number  .........................  13
    7.7.2  Processing of the Length Field by the Receiver  .........  14
    8      Frame Relay Port Mode  ..................................  14
    8.1    General Description  ....................................  14
    8.2    PW packet format for MPLS frame relay port mode  ........  15
    8.3    PW packet processing for frame relay port mode  .........  17
    8.4    MPLS Shim EXP Bit Values  ...............................  17
    8.5    MPLS Shim S Bit Value  ..................................  17
    9      IANA Considerations  ....................................  17
   10      Security Considerations  ................................  17
   11      Full Copyright Statement  ...............................  18
   12      Intellectual Property Statement  ........................  18
   13      Normative References  ...................................  19
   14      Informative References  .................................  19
   15      Author Information  .....................................  20
   16      Contributing Author Information  ........................  21













Martini, et al.                                                 [Page 2]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005


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.

     - Backward direction.

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

     - Forward direction.

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


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-04.txt      February 2005


3. Acronyms and Abbreviations

      Bc      Committed burst size
      Be      Excess burst size
      BECN    Backward Explicit Congestion Notification
      CE      Customer Edge
      CIR     Committed Information Rate
      C/R     Command/Response
      DE      Discard Eligibility
      DLCI    Data Link Connection identifier
      FCS     Frame Check Sequence
      FECN    Forward Explicit Congestion Notification
      FR      Frame Relay
      L2TP    Layer 2 Tunneling Protocol
      FRS     Frame Relay Service
      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
      SLA     Service Level Agreement
      SPVC    Switched/Soft permanent virtual circuit
      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. This requires that the layer 2 PDUs be
   encapsulated. 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,






Martini, et al.                                                 [Page 4]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005


     - Transfer of a PW packet across a PSN 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 required to support frame relay
       service.

   This document specifies the encapsulation for the emulated frame
   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]

   This document also specifies the way in which the MPLS demultiplexer
   field is added to the emulated frame relay VC encapsulation when an
   MPLS label is used as the demultiplexer field.

   QoS related issues are not discussed in this draft.

   The following two figures describe 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





Martini, et al.                                                 [Page 5]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005


      Figure 1: PWE3 frame relay PVC Interface Reference Configuration


   Two mapping modes are defined between FR VCs and pseudo-wires: The
   first one is called "one-to-one" mapping, because there is a one-to-
   one correspondence between a FR VC and one Pseudo Wire. The second
   mapping is called "many-to-one" mapping or "port mode" Because
   multiple FR VCs assigned to a port are mapped to one Pseudo Wire. As
   specified later in this document, the encapsulation of frame relay
   information is slightly different between the two mapping modes.



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

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


   Figure 2 - General format of FR encapsulation over PSN

   The PW packet consists of the following fields: Control word, Payload
   and Pad (if required) preceded by PSN Transport and pseudo-wire
   header.  The meaning of the different fields is as follows:
        -i. PSN Transport header is specific to the PSN, in this case
            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
            a PSN tunnel.
      -iii. Control Word contains protocol control information for
            providing a frame relay service. Its structure is provided
            in the following sections addressing each mapping mode.





Martini, et al.                                                 [Page 6]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005


       -iv. The contents of the FR service payload field depends on the
            mapping mode.  The details are provided in the following
            sections addressing each mapping mode.


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

6.1. MPLS PSN Tunnel and PW

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

   Several "Pseudo-Wires" may be nested inside one PSN tunnel. Each PW
   carries the traffic of a single frame relay VC.



7. Details Specific to Particular Emulated Services

7.1. Frame Relay

   When emulating a frame relay service, the Frame Relay PDUs are
   encapsulated according to the procedures defined herein. 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 [ITUQ] 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 [ITUQ] 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.2. Frame-Relay Specific Interface Parameters

   This field specifies interface specific parameters. When applicable,
   it 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 types is defined in [IANA], but the frame relay specific



Martini, et al.                                                 [Page 7]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005


   interface parameters are specified as follows:

     - 0x08 Frame-Relay DLCI Length.

       An optional 16 bit value indicating the length of the frame relay
       DLCI field. This OPTIONAL interface parameter can have value of 2
       , or 4, with the default being equal to 2. If this interface
       parameter is not present the default value of 2 is assumed.


7.3. One-to-One Mapping and PW Packet Format over MPLS PSN

   For the one-to-one mapping mode for frame relay over MPLS PSN, 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 5)           | 4 octets
    +-------------------------------+
    |            Payload            |
    |      (Frame relay frame       |
    |       information field)      | n octets
    |                               |
    +-------------------------------+


   Figure 3 - FR 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 PSN transport header
       of Figure 3.  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 FR VC
       in one direction. It corresponds to the PW header of Figure 3.
       Together the MPLS Tunnel label(s) and PW label form an MPLS label
       stack [RFC3032].





Martini, et al.                                                 [Page 8]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005


     - 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
       size of at least 1600 bytes. The maximum length of the payload
       field MUST be agreed by the two PEs when the PW is established.


7.4. The Control Word

   When carrying frame relay over an MPLS network, sequentiality may
   need to be preserved. The REQUIRED control word defined here
   addresses this requirement.

   The Control Word contains protocol control information. 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 5) 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.







Martini, et al.                                                 [Page 9]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005


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

     - 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.5. 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               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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












Martini, et al.                                                [Page 10]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005


7.6. PW packet processing

7.6.1. Generation of PW packets

   The generation process of a PW packet 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 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 FR PW uses sequence
       numbers.
     - 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.6.2. Setting the sequence number

   For a given PW, and a pair of routers PE1 and PE2, if PE1 supports
   frame sequencing then the following procedures should be used:







Martini, et al.                                                [Page 11]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005


     - the initial frame transmitted on the PW MUST use sequence number
       1
     - subsequent frames MUST increment the sequence number by one for
       each frame
     - when the transmit sequence number reaches the maximum 16 bit
       value (65535) the sequence number MUST wrap to 1

   If the transmitting router PE1 does not support sequence number
   processing, then the sequence number field in the control word MUST
   be set to 0.


7.7. Reception of PW packets

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

     - It generates the following FR frame header fields from the
       corresponding fields of the PW packet.
     - The C/R bit is copied in the frame relay header.
     - The D bit is copied into the frame relay header DE bit.
     - The F bit is 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 is 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 subsequent sub-sections.
     - It generates 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 generated, the FCS
       has to be computed, HDLC flags have to be added and any bit or
       byte stuffing has been performed (these final actions typically
       take place in a hardware framer).  The FR frame is queued for
       transmission on the selected frame relay UNI or NNI interface.










Martini, et al.                                                [Page 12]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005


7.7.1. Processing the sequence number

   If a router PE2 supports receive sequence number processing, then the
   following procedures should be used:

   When a PW is initially set up, the "expected sequence number"
   associated with it MUST be initialized to 1.

   When a frame is received on that PW, the sequence number should be
   processed as follows:

     - if the sequence number on the frame is 0, then the sequence
       number check is skipped. ( sequence check disabled )

     - otherwise if the frame sequence number >= the expected sequence
       number and the frame sequence number - the expected sequence
       number < 32768, then the frame is in order.

     - otherwise if the frame sequence number < the expected sequence
       number and the expected sequence number - the frame sequence
       number >= 32768, then the frame is in order.

     - otherwise the frame is out of order.

   If a frame passes the sequence number check, or is in order then, it
   can be delivered immediately. If the frame is in order, then the
   expected sequence number should be set using the algorithm:

   expected_sequence_number := frame_sequence_number + 1 mod 2**16
   if (expected_sequence_number = 0) then expected_sequence_number := 1;

   Packets which are received out of order MAY be dropped or reordered
   at the discretion of the receiver.

   If a PE router negotiated not to use receive sequence number
   processing, and it received a non zero sequence number, then it
   SHOULD send a PW status message indicating a receive fault, and
   disable the PW.

   If an egress PE receives an excessive number of out-of-sequence PW
   packets, it SHOULD inform the management plane responsible for PW
   setup/maintenance, and take the appropriate actions. The threshold
   for declaring that out-of-sequence PW packets are excessive is not
   defined in this document.







Martini, et al.                                                [Page 13]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005


7.7.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
       Characters 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.


8. Frame Relay Port Mode

8.1. General Description

   Editor's note: Frame relay port mode will be removed from this
   document in the next revision.

   Figure 5 illustrates the concept of frame relay port mode or many-
   to-one mapping which is an OPTIONAL capability.

   Figure 5 (a) shows two frame relay devices physically connected with
   a frame relay UNI or NNI. Between their two ports P1 and P2, n frame
   relay VCs are configured.

   Figure 5 (b) shows the replacement of the physical frame relay
   interface with a pair of PEs and a PW between them. The interface
   between a FR device and a PE is either a FR UNI or NNI. The set of n
   FR VCs between the two FR ports P1 and P2 which are controlled by the
   same signaling channel using DLCI=0, are mapped into one PW. Hence
   with port mode we have many-to-one mapping between FR VCs and a PW.




















Martini, et al.                                                [Page 14]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005


              +------+                          +-------+
              | FR   |                          |   FR  |
              |device|         FR UNI/NNI       | device|
              |    [P1]------------------------[P2]     |
              |      |      carrying n FR VCs   |       |
              +------+            |             +-------+
                                  |
                 [Pn]: A port     |
                                  | (a) FR interface between two
                                  |     FR devices
                                  |
                                  V
                    |<---------------------------->|
                    |                              |
                     +----+                  +----+
   +------+          |    |     One PW       |    |         +------+
   |      |          |    |==================|    |         |      |
   |  FR  |    FR    | PE1| carrying n FR VCs| PE2|    FR   |  FR  |
   |device|----------|    |                  |    |---------|device|
   | CE1  | UNI/NNI  |    |                  |    | UNI/NNI | CE2  |
   +------+          +----+                  +----+         +------+
          |                                                 |
          |<----------------------------------------------->|
                                  n FR VCs

              (b) Pseudo-wires replacing the FR interface

         Figure 5 - Concept of frame relay port-to-port mode

   FR VCs are not visible individually to a PE; there is no
   configuration of individual FR VC in a PE. A PE processes the set of
   FR VCs assigned to a port as an aggregate.

   FR port mode provides transport between two PEs of a complete FR
   frame excluding the opening and closing flags and the Frame Check The
   sequence (FCS) and with bit/byte stuffing are also removed. [X36,
   X76].


8.2. PW packet format for MPLS frame relay port mode

   When MPLS PW is used with port mode, the PW packet format is
            shown in Figure 7.








Martini, et al.                                                [Page 15]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005


   +-------------------------------+
   |      MPLS Tunnel label(s)     | n*4 octets (four octets per label)
   +-------------------------------+
   |          PW label             | 4 octets
   +-------------------------------+
   |   Optional Control Word       | 4 octets
   +-------------------------------+
   |             Payload           |
   |    (FR Address plus           |
   |      information field)       | N octets
   |      and a Pad (if needed)    |
   +-------------------------------+


   Figure 6- PW packet format for frame relay port mode.

   The OPTIONAL Control Word for frame relay port mode is show below.
   Control bits 4 to 7 (F, B, D and C) are not used and are set to zero.

   The use of the fragmentation bits (I and L) is the same as for the
   one-to-one mapping. The use of the length and sequence number fields
   is the same as for the one-to-one mapping, with the following
   exceptions: There is one sequence number counter for the set of FR
   VCs and not one for each individual FR VC.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Res  |0|0|0|0|Res|  Length   | Sequence Number               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The payload field of a frame relay port mode PW contains a FR frame
   which consists of the address field (including the DLCI and the
   control bits) and information field. The HDLC opening and closing
   flags, bit/byte stuffing and FCS are removed.

   The two peer PEs MUST agree on the length of the DLCI field (2 or 4
   octets) and the maximum length of FR frame information field. The
   DLCI  can be negotiated by a signaling protocol as in [CONTROL].











Martini, et al.                                                [Page 16]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005


8.3. PW packet processing for frame relay port mode

   When a PE receives a FR frame from a FR device (a CE), it shall
   remove the flags, undo bit/byte stuffing and check the FCS field to
   determine whether transmission errors occurred or not. If
   transmission errors occurred, the frame is discarded. Otherwise, the
   FR frame (excluding the flags and the FCS) is encapsulated in a PW
   packet to be forwarded to the remote PE.

   The processing of the length and sequence number fields is the same
   as for the one-to-one mapping, with the following exceptions
   mentioned earlier:  There is one sequence number counter for the set
   of FR VCs and not one for each individual FR VC.

   Upon receiving a PW packet, the remote PE shall extract the PW
   payload field, encapsulate the result in a HDLC frame for
   transmission to the local FR (CE) device.


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


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


9. IANA Considerations

   This document has no IANA Actions.


10. 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 PSN Tunnel Layer. A more
   detailed discussion of PW security is give in [RFC3985, PWE3REQ].






Martini, et al.                                                [Page 17]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005


11. Full Copyright Statement

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


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

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   or will be disclosed, and any of which I become aware will be
   disclosed, in accordance with RFC 3668.








Martini, et al.                                                [Page 18]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005


13. Normative References

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

   [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-08.txt
        (work in progress), April 2004


14. Informative References

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

   [FRAG] Andrew G. Malis, et al., PWE3 Fragmentation and
        Reassembly, draft-ietf-pwe3-fragmentation-04.txt,
        October 2003, work in progress.

   [ATM] "Encapsulation Methods for Transport of ATM Cells/Frame Over IP
        and MPLS Networks", draft-ietf-pwe3-atm-encap-05.txt (work in
        progress)

   [PPP] "Encapsulation Methods for Transport of PPP/HDLC Frames
        Over IP and MPLS Networks",
        draft-ietf-pwe3-hdlc-ppp-encap-05.txt (work in progress)

   [ETH] "Encapsulation Methods for Transport of Ethernet Frames Over
        IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-06.txt.
        (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



Martini, et al.                                                [Page 19]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005


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

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

   [IANA]  Luca Martini, et al., IANA Allocations for pseudo
        Wire Edge to Edge Emulation (PWE3),
        draft-ietf-pwe3-iana-allocation-02.txt, October 2003,
        work in progress.

   [PWE3REQ] XiPeng Xiao, et al., Internet draft, draft-ietf-pwe3-
        requirements-08.txt, work in progress.

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

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



15. Author Information


   Luca Martini
   Level 3 Communications, LLC.
   1025 Eldorado Blvd.
   Broomfield, CO, 80021
   e-mail: luca@level3.net






Martini, et al.                                                [Page 20]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005



   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



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








Martini, et al.                                                [Page 21]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005



   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


   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





Martini, et al.                                                [Page 22]

Internet Draft     draft-ietf-pwe3-frame-relay-04.txt      February 2005



   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


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



























Martini, et al.                                                [Page 23]


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