PWE3 Working Group                                 Claude Kawa (Editor)
Internet Draft                                          Nortel Networks

Expires: December 2002                                  Andrew G. Malis
                                                  Vivace Networks, Inc.

                                                           Luca Martini
                                                        Nasser El-Aawar
                                           Level 3 Communications, LLC.

Vinai Sirkay                                               Prayson Pate
Vivace Networks, Inc.                           Overture Networks, Inc.

Giles Heron                                             Steve Vogelsang
PacketExchange Ltd.                               Laurel Networks, Inc.

Chris Liljenstolpe                             Dimitri Stratton Vlachos
Cable & Wireless                                    Mazu Networks, Inc.

Daniel Tappan                                           Kireeti Kompella
Eric C. Rosen                                           Juniper Networks
Cisco Systems, Inc.
                                                               Ravi Bhat
                                                         Nishit Vasavada
                                                                   Nokia


                                                              June 2002


               Frame Relay Encapsulation over Pseudo-Wires
                   draft-martini-frame-encap-mpls-01.txt



Status of this Memo

This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.

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.


Copyright Notice

Copyright(C) The Internet Society (2002). All Rights Reserved.




Kawa, et al.                                                   [Page 1]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002


Abstract

   This document defines frame relay pseudo-wire emulation edge-to-edge.
   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 IP and MPLS packet switched network (PSN).
   Two mapping modes are defined: One-to-one mapping mode characterized
   by a one to one relationship between a frame relay VC and a pair
   of MPLS LSPs is defined for MPLS PSN. The other mode is known as port
   mode or many-to-one mapping mode and is defined for MPLS PSN and IP
   PSN with L2TPv3.


Table of Contents

1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . . .  4
4. Requirements for Frame Relay Over Pseudo-wires. . . .  . . . .  5
5. Reference model and PWE3 protocol layering . . . . . . . . . .  6
6. General encapsulation for the two mapping modes   . . . . . .   8
7. Frame Relay over MPLS PSN for the one-to-one mapping mode. .  .10
8. FR SVC and SPVC Signalling between PEs. . . . . . . . . . . .  19
9. FR PVC provisioning. . . . . . . . . . . . . . . . . . . . . . 19
10. Frame relay port mode . . . . . . . .. . . . . . . . . . . .  19
11. Frame relay service over pseudo-wires. . . . . . . . . . . . .24
12. IANA considerations. . . . . . . . . . . . . . . . . . . . . .26
13. Security Considerations. . . . . . . . . . . . . . . . . . .  26
14. References . . . . . . . . . . . . . . . . . . . . . . . . .  26
15. Author's Addresses  . . . . . . . . . . . . . . . . . . . . . 28

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.


1. Introduction

   This draft combines draft-martini-frame-encap-mpls-00.txt and draft-
   kamapabhava-fr-pwe3-01.txt previously submitted to the PWE3 working
   group and replaces both of these drafts.

   This document defines frame relay pseudo-wire emulation edge-to-edge.
   A frame relay pseudo-wire (PW) is a mechanism that exists between
   provider's edge network nodes (PEs) and supports as faithfully as
   possible frame relay services over IP and MPLS packet switched
   network (PSN) using MPLS LSP [RFC3031, RFC3032] and L2TPv3 [L2TPv3]
   tunnels for multiplexing purposes. L2TPv3 is used only with IP PSN in
   this document.

   The main functions required to support frame relay PW by a PE
   include:

      - Encapsulation of frame relay specific information in a suitable
        frame relay over pseudo wire (FRoPW) packet,

Kawa, et al.                                                   [Page 2]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002


      - Transfer of a FRoPW packet across a PSN for delivery to a peer
        PE,

      - Extraction of frame relay specific information from a FRoPW
        packet by the remote edge node,

      - Generation of native frame relay frames for forwarding across an
        egress port of the remote edge node,

      - Execution of any other operations required to support frame
        relay service.

   Two mapping modes are defined between FR VCs and FR PWs: The first
   one is called "one-to-one" mapping. because there is a one-to-one
   correspondence between a FR VC and a pair of unidirectional PWs. The
   second mapping is called "many-to-one" mapping or "port mode" because
   multiple FR VCs assigned to a port are mapped to one pair of PWs.
   One-to-one mapping mode is defined for MPLS PSN only and port mode is
   defined for MPLS LSP and IP PSN with L2TPv3.

   The main structure of this document is as follows: Section 4 lists
   some important frame relay requirements to be met in a PWE3
   environment. Section 5 described PWE3 reference model and PWE3
   protocol layers described in [LYR]. Section 6 describes the generic
   frame relay over pseudo-wire (FRoPW) packet format. Section 7
   specifies frame relay over MPLS PSN for the one-to-one mapping
   Section 8 just indicates that FR SVC and SPVC are not supported in
   this document. Section 9 is about FR PVC provisioning. Section 10
   describes FR port mode for MPLS PSN and IP PSN with L2TPv3. Finally,
   Section 11 discusses the meaning of providing frame relay services in
   the native and PWE3 environments and how faithfully/perfectly FR
   service should be provided.


2. Terminology

   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.


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

   Customer Edge:        A Customer Edge (CE) is a device attached to a
                         provider's PSN and where the emulated (frame
                         relay) service originates and terminates.

   Forward direction:    In frame relay the reference used to
                         determine whether the direction of the traffic
                         is the forward or backward direction is the
                         frame being forwarded. The forward direction is
                         the direction taken by the frame being
                         forwarded.


Kawa, et al.                                                   [Page 3]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002


   Packet Switched Network:
                         A Packet Switched Network (PSN) is a network
                         using packets as the unit of switching.

   Provider Edge:        A Provider Edge (PE) is a device that provides
                         PWE3 to a CE.

   Pseudo-Wire:          A Pseudo Wire (PW) is a mechanism between two
                         PEs that carries the essential elements of an
                         emulated service (e.g. frame relay service)
                         over a PSN to provide the service to the CEs.

   Pseudo-Wire Emulation Edge to Edge:
                         Pseudo-Wire Emulation Edge to Edge (PWE3) is
                         the technique that emulates the essential
                         characteristics of a service (e.g. frame relay)
                         over a PSN.

   Pseudo-Wire PDU:      A Pseudo Wire PDU is a PDU sent on the PW that
                         contains all of the data and control
                         information necessary to provide the desired
                         service. Frame relay pseudo-wire PDU is also
                         called Frame Relay over PW (FRoPW) packet.

   Tunnel:               A Tunnel is a mechanism to carry PW PDUs
                         between PEs in a transparent way to the PSN
                         core.


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
   FRoPW   Frame Relay over Pseudo Wire
   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



Kawa, et al.                                                   [Page 4]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002

   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. Requirements for Frame Relay Over Pseudo-Wires

   The section lists the main frame relay pseudo-wire requirements to
   be met by a PE:

      1. Frame Length: Should transport variable length FR frames
         without being limited by the PSN MTU.

      2. Bidirectional traffic: Must support bidirectional traffic.

      3. Frame ordering: Must preserve FR frames order.

      4. Transmission errors: Must detect (detectable) transmission
         errors,

      5. Control bits: Must support the transport of FR Discard
         Eligibility (DE), Forward Explicit Congestion Notification
         (FECN), Backward Explicit Congestion Notification (BECN) and
         Command/Response (C/R) bits [Q922].

      6. PVC Status Maintenance: Must support the mapping and transport
         of frame relay PVC status indications defined in Q.933 Annex A
         [Q933]. The support of PVC link integrity check should be
         provided. Note PVC status maintenance will be addressed in
         another IETF draft.

      7. Traffic Management: Should be able to map the following FR
         traffic management parameters to PWs and tunnel traffic
         parameters:

            a) CIR (Committed Information Rate) or throughput,
            b) Bc (Committed burst size),
            c) Be (Excess Burst Size),
            e) Maximum frame size.

      8. Frame Priority and QoS: Should support the ability to map FR
         transfer and discard priorities or QoS service classes defined
         in [X36, X76] to appropriately engineered PWs and PSN tunnels.

      9. Frame relay VC type: Must support PVC, support of SVC and SPVC
         is optional.










Kawa, et al.                                                   [Page 5]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002


5. Reference model and PWE3 protocol layering

   5.1. Reference model

      Figure 1 shows PWE3 reference model with additional frame relay
      concepts. More details on the reference model can be found in
      [PWE3REQ, PWE3FW].


                    |<------ Pseudo-wires ------>|
                    |                            |
                    |    |<-- PSN Tunnel -->|    |
                    V    V                  V    V
              FR    +----+                  +----+     FR
         UNI or NNI |    |       PW1        |    | UNI or NNI
   +-----+    |     |    |==================|    |     |    +-----+
   |     |----------| PE1|                  | PE2|----------|     |
   | CE1 |    |     |    |                  |    |     |    | CE2 |
   |     |----------|    |        PW2       |    |----------|     |
   +-----+    |     |    |==================|    |     |    +-----+
         ^          +----+                  +----+          ^
         |                                                  |
         |<------------- Emulated Service ----------------->|
                    (i.e. FR PVC, SVC or SPVC)

                     Figure 1 - PWE3 Reference Model

      Two  mapping modes are defined between FR VCs and pseudo-wires:

        - The first one is called "one-to-one" mapping. With one-to-one
          mapping, for each frame relay VC, a pair of pseudo-wires (one
          for each direction of the traffic) is established between a
          pair of PEs.

        - The second mapping is called "many-to-one" mapping or "port
          mode": With this mapping multiple frame relay VCs related to a
          port are assigned to one pair of pseudo-wires.

      As specified later in this document, the encapsulation of frame
      relay information is slightly different between the two mapping
      modes.


   5.2. Frame relay over PW and PWE3 protocol layering

      This document supports MPLS PSN and IP PSN. With IP PSN, L2TPV3
      [L2TPv3] is used for multiplexing purposes of a number of FR VCs
      into one L2TPv3 tunnel. In addition, the one- to-one mapping mode
      applies to frame relay over MPLS PSN only and the many-to-one
      mapping mode applies to both frame relay over MPLS PSN and IP PSN
      with L2TPv3. In terms of PWE3 protocol layering defined in [LYR],
      we have the following two protocol stacks:

      The first protocol stack is for the one-to-one mapping mode. It is
      adapted from [LYR Figure 11]:



Kawa, et al.                                                   [Page 6]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002



     +---------------------+
     |      Payload        |
     /=====================\
     H Payload Convergence H-----------------+
     H---------------------H                 |
     H  Timing (NIL)       H                 |
     H---------------------H                 |
     H     Sequencing      H------------------------------------+
     \=====================/                 |                  |
     |  PW Demultiplexer   |---+             |                  |
     +---------------------+   |             |                  |
     |  PSN Convergence    |-----------------------+----+----+  |
     +---------------------+   |             |     |    |    |  |
     |   MPLS PSN          |-+ |             v     v    v    v  v
     +---------------------+ | |  +--------------------------------+
     |    MAC/Data-link    | | |  |      Flags   |Frag| Len |Seq # |
     +---------------------+ | |  +--------------------------------+
     |       Physical      | | +->|      Inner MPLS LSP/PW Label   |
     +---------------------+ |    +--------------------------------+
                             +--->|       Outer MPLS LSP Label     |
                                  +--------------------------------+
                                           Control words

  Figure 2- FR PWE3 over MPLS PSN for the one-to-one mapping mode


     Notes: 1-For the one-to-one mapping mode only MPLS PSN is used in
              this document and MPLS LSP labels are used for PW
              demultiplexer.

            2-The payload is a FR frame information field only with
              bit/byte stuffing undone (byte stuffing is used only over
              Sonet/SDH transmission facilities [FRF14]).

            3-Control words carrying different protocol control
              information are used. They are described in subsequent
              sections.

      The second protocol stack is for the many-to-one mapping or port
      mode. It is adapted from [LYR Figure 10]:

















Kawa, et al.                                                   [Page 7]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002


     +---------------------+             +-------------------------+
     |      Payload        |------------>|FR frame less flags & FCS|
     /=====================\             +-------------------------+
     H Payload Convergence H------------>|             Nil         |
     H---------------------H             +-------------------------+
     H    Timing           H------------>|            Nil          |
     H---------------------H             +------------+------------+
     H     Sequencing      H------------>| Pseudo-wire protocol    |
     \=====================/             +------------+------------+
     |  PW Demultiplexer   |------------>|    L2TPv3  |   MPLS     |
     +---------------------+             +------------+------------+
     |  PSN Convergence    |------------>|     Nil    |     Nil    |
     +---------------------+             +------------+------------+
     |        PSN          |------------>|     IP     |    MPLS    |
     +---------------------+             +------------+------------+
     |    MAC/Data-link    |------------>|       MAC/Data-link     |
     +---------------------+             +-------------------------+
     |       Physical      |------------>|          Physical       |
     +---------------------+             +-------------------------+

  Figure 3 - FR PWE3 protocol layers for port mode with IP and MPLS PSNS


     Notes: 1-There are actually two instances of the protocol stack:
              One for IP PSN and the other for MPLS PSN.

            2-With IP PSN, L2TPv3 is used as PW demultiplexer.

            3-With MPLS PSN, MPLS is used as PW demultiplexer.

            4-The others PW demultiplexers listed in [LYR]: GRE, IPsec
               and MPLS are not supported. It has to be decided whether
               we need to support them or not.

            5-The payload is a complete FR frame with the exception of
              HDLC opening and closing flags and the Frame check
              sequence (FCS) and with bit/byte stuffing undone.

            6-Sequencing is provided by the PW protocol defined in this
              document.


6. General encapsulation for the two mapping modes

   The general frame relay over pseudo-wires (FRoPW) packet format
   for carrying frame relay information (user's payload and frame
   relay control information) between two PEs is shown in Figure 4.











Kawa, et al.                                                   [Page 8]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002


       +-------------------------------+
       |                               |
       |     PSN Delivery Header       |
       +-------------------------------+
       |                               |
       |     PW Identifier header      |
       +-------------------------------+
       |       FRoPW Header            |
       |                               |
       +-------------------------------+
       |                               |
       |           Payload             |
       |     and a Pad (if needed)     |
       +-------------------------------+

     Figure 4 - General format of FRoPW packet


      1. PSN delivery header is a header specific to the PSN, it is
         discussed in the following sub-sections addressing each type of
         PSN.

      2. PW identifier header contains an identifier for multiplexing
         PWs within a PSN tunnel.

      3. FRoPW header contains protocol control information for
         providing a frame relay service. Its structure is provided in
         the following sections addressing each mapping mode.

      4. The contents of the payload field depends on the mapping mode.
         The details are provided in the following sections addressing
         each mapping mode.

         The Pad is used to bring the size of a FRoPW
         packet to the minimum size required by the link layer when IEEE
         802.3/Ethernet [P8023, DIX] segment is used.

   Motivation for padding a FRoPW packet:

      A FRoPW packet is encapsulated in the payload field of the
      underlying link layer protocol frame. When IEEE 802.3 [P8023] or
      DIX Ethernet [DIX] is used as the link layer between a PE and the
      PSN core, there is a minimum frame size to meet and
      correspondingly a the link layer frame must have a minimum data
      field (payload) size to be valid. If the client data encapsulated
      in the data field of an Ethernet/802.3 frame has a smaller size
      than the minimum frame size, it has to be padded.

      In the case of DIX Ethernet it is up to the client (e.g. the
      protocol specified in this document) to pad its data to ensure
      that the minimum length is met.







Kawa, et al.                                                   [Page 9]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002


      In the case of IEEE 802.3 [P8023] padding will be always performed
      according to 802.3 specification regardless of the interpretation
      of the Length/Type field. So if an IEEE 802.3 implementation pads
      a data field, the receiver will not be able to determine whether
      the frame contains padding characters or only client data when the
      Type/Length field is used with the Type interpretation. With the
      length interpretation there is no problem because the Length/Type
      field will contain the length of the client data.

      The protocol defined in this document has a padding capability for
      two main reasons: When DIX Ethernet is used, to meet its
      requirements and overcome its lack of padding capabilities. When
      IEEE 802.3 is used to avoid that padding be done by 802.3
      implementation when the Type/Length Field is used with the Type
      interpretation.

      A FR over PW implementation must ensure that FRoPW packets meet
      IEEE 802.3/Ethernet minimum data field size. The various minimum
      sizes in bytes are as follows:


      IEEE 802.3/Ethernet minimum frame and data field sizes:

                            IEEE 802.3               DIX Ethernet

         Min. frame size         64                       64

         Min. data field size    46 (untagged frame)      46
                                 42 (VLAN tagged frame)    -

      In the case of IEEE 802.3 there are two minimum data field sizes:
      One minimum size when the frame does not have a VLAN QTag prefix
      [P8021Q] and when when it has one.


7. Frame Relay over MPLS PSN for the one-to-one mapping mode

   7.1. MPLS tunnel and VC LSPs

      MPLS label switched paths (LSPs) called "Tunnel LSPs" are used
      between PEs and within MPLS PSN core for forwarding purposes of
      FRoPW packets. A tunnel LSP corresponds to a "PSN tunnel" of
      Figure 1.

      Several  "Virtual Circuit LSPs" (VC LSPs) may be nested inside one
      Tunnel LSP. Each VC LSP carries the traffic of a frame relay VC in
      one direction. Since LSPs are unidirectional, a pair of VC LSPs
      and corresponding tunnel LSPs carrying traffic in opposite
      directions will be required.

      In PE1 to PE2 direction a tunnel LSP is used for forwarding FRoPW
      packets from PE1 to PE2,the corresponding LSP label is not related
      to any frame relay VC. When PE1 has to forward a FRoPW packet to
      PE2, it first pushes a VC label on its label stack, and then




Kawa, et al.                                                   [Page 10]


Internet Draft       draft-martini-frame-encap-mpls-01.txt     June 2002



      pushes on a tunnel LSP label. The VC label must be always at the
      bottom of the label stack. The VC label is not visible in the core
      PSN, only the tunnel LSP label and possibly other labels used in
      the core PSN for forwarding purposes until the FRoPW packet
      reaches PE2. While the FRoPW packet travels across the MPLS
      network, additional labels may be pushed on (and then popped off)
      as needed. When PE2 receives a FRoPW packet, it forwards the
      packet to the local CE based on the LSP VC label. The processing
      is similar in the opposite direction from PE2 to PE1 with the
      corresponding LSP used in the PE2 to PE1 forwarding direction.


   7.2. Relationship between FR VCs and MPLS VC LSPs

      Frame Relay VCs are considered to be bidirectional objects mainly
      because of the way they are created and identified. A single frame
      relay identifier (DLCI) refers to the two directions of a frame
      relay VC and frame relay signalling establishes the two directions
      simultaneously with the same message flows. In general each
      direction of a frame relay VC may have different traffic and QoS
      characteristics. The resource management of a frame relay
      implementation treats each direction separately and independently.
      MPLS LSPs, on the other hand LSPs are unidirectional and are
      established separately. Therefore for each FR VC there will be, in
      general, two VC LSPs such that each one will be assigned to carry
      the traffic in a different direction from the other.

      During the creation of a frame relay VC, a pair of VC LSPs will
      have to be established between two PEs. For one end-to-end frame
      relay VC two VC LSPs exist: One VC LSP to transport the traffic
      from PE1 to PE2 and the other to transport the traffic in the
      opposite direction. In the frame relay domain, a DLCI identifies a
      frame relay VC and in the MPLS domain, VC LSP labels with possible
      different values identify each VC LSP. This mapping between a FR
      VC and a pair of MPLS LSPs corresponds to the one-to-one mapping
      described in Section 5.


   7.3. One-to-one mapping and FRoPW packet format over MPLS PSN

      For the one-to-one mapping mode for frame relay over MPLS PSN, the
      FRoPW packet format is shown in Figure 5.















Kawa, et al.                                                   [Page 11]


Internet Draft       draft-martini-frame-encap-mpls-01.txt     June 2002



       +-------------------------------+
       |      Tunnel LSP label(s)      | n words (1 word per label)
       +-------------------------------+
       |      VC LSP label             |  1 word
       +-------------------------------+
       |       FRoPW Header            |
       |      (See Figure 6)           | 1 word
       +-------------------------------+
       |             Payload           |
       |(Q.922 frame information field)| N bytes
       |     and a Pad (if needed)     |
       +-------------------------------+

    Figure 5 - FR over MPLS packet format for the One-to-one mapping

      Tunnel LSP label(s):
         The Tunnel LSP label(s) corresponds to the PSN delivery header
         of Figure 4. The label(s) is/are used by MPLS PSN nodes to
         forward a FRoPW packet from one PE to the other.

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

      FRoPW header:
         FRoPW header contains protocol control information. Its
         structure is shown in Figure 6.

The above three headers were referred as "control words" in Figure 2.


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

     Figure 6 - FRoPW header structure for one-to-one mapping mode


      The meaning of the fields of FRoPW packet header (Figure 6) is as
      follows:

         Res (bits 0 to 3):
            Reserved bits. They are set to zero on transmission and
            ignored on reception.

         F (bit 4):
            FR FECN (Forward Explicit Congestion Notification) bit
            [Q922].





Kawa, et al.                                                   [Page 12]


Internet Draft       draft-martini-frame-encap-mpls-01.txt     June 2002


         B (bit 5):
            FR BECN (Backward Explicit Congestion Notification) bit
            [Q.922].

         D (bit 6):
            FR DE bit indicates the discard eligibility [Q922].

         C (bit 7)
            FR frame C/R (command/response) bit [Q922].

         Res (bits 8 and 9):
            Reserved bits. They are set to zero on transmission and
            ignored on reception.

         Length (bits 10 to 15):
            The length field is used for padding the payload field of
            short FRoPW packets when IEEE 802.3/Ethernet [P8023, DIX]
            segment is used between a PE and the PSN. When padding of a
            short FRoPW packet is performed the length field must be set
            to the FRoPW packet size (Figure 5) specified in bytes.
            Otherwise the length field must be set to zero. The value of
            the length field, if non- zero, is used to remove any
            padding.

         Sequence number (Bit 16 to 31):
            If it is not used, it is set to zero by the sender and
            ignored by the receiver. Otherwise it specifies the sequence
            number of a FRoPW packet. A circular list of sequence
            numbers is used. A sequence number takes a value from 1 to
            65535 (2**16-1). Arithmetic modulo 2**16 is performed to
            generate a new sequence number. The value of zero indicates
            that the sequence number field is not used.

         Payload and Pad:
            The payload field corresponds to Q.922 frame relay frame
            information field with bit/byte stuffing removed. The
            default for the number of bytes in a Q.922 information field
            is 262 bytes. Recommendation Q.922 recommends to support a
            size of a least 1600 bytes [Q922 clause A.5.1]. The maximum
            length of the payload field should be agreed by the two PEs
            when the VC LSP is established.

            The Pad consists of a number of characters (including zero
            character) to bring the FRoPW packet size to the minimum
            size required by the link layer protocol, in particular IEEE
            802.3/Ethernet (cf.section 6 for the motivation for padding.
            Any 8-bit character with a decimal value from 0 to 255 may
            be used as a padding character.










Kawa, et al.                                                  [Page 13]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002



   7.4. FRoPW packet processing

      7.4.1. Generation of FRoPW packets

         The generation process of a FRoPW packet is initiated when a PE
         receives a frame relay frame from one of its frame relay UNI or
         NNI. The PE takes the following actions (not necessarily in the
         order shown):

            - It generates the following fields of FRoPW header 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 FRoPW header.

               - Discard eligibility indicator (DE or D): The D bit is
                 set as follows in the FRoPW header: This bit, if used,
                 is set to 1 to indicate a request that a frame should
                 be discarded in preference to other frames in a
                 congestion situation.

                 Setting of this bit by a PE is optional. However, no PE
                 shall clear this bit (set it to 0 if it was received
                 with the value of 1). A PE that does not provide
                 discard eligibility notification shall pass this bit
                 unchanged. Networks are not constrained to discard only
                 frames with D = 1 in the presence of congestion [Q922
                 Annex A].

               - Forward explicit congestion notification (FECN or F
                 bit): FECN may be set by a congested PE to notify the
                 user that congestion avoidance procedures should be
                 initiated where applicable for traffic in the direction
                 of the FRoPW packet carrying the FECN [Q922].

                 This bit is set to 1 to indicate to the destination
                 that the frames it receives have encountered congested
                 resources. This bit may be used by a destination to
                 adjust its transmission rate.

                 While setting this bit by a PE is optional, no PE shall
                 clear this bit (set it to 0 if it was received with the
                 value of 1). PEs that do not provide FECN shall pass
                 this bit unchanged.

               - Backward explicit congestion notification (BECN or B
                 bit): BECN follows the same processing rules as FECN,
                 except that it applies to the opposite direction
                 [Q922].

               - Length: See the following sub-section "Processing of
                 the Length field by the sender".

               - Sequence number: See the sub-section "Processing of the
                 Sequence number field by the sender".


Kawa, et al.                                                   [Page 14]


Internet Draft       draft-martini-frame-encap-mpls-01.txt     June 2002


               - Payload and pad:
                 The payload and pad field of the FRoPW packet is the
                 contents of ITU-T Recommendation Q.922 [Q922] frame
                 relay frame information field stripped from any bit or
                 byte stuffing. The payload field may also have padding
                 characters appended to its right as specified in the
                 following sub-section on "Processing of the length
                 field by the sender".

         Additional processing is performed by the lower protocol
         layers in order to transmit the FroPW packet to its next
         destination.

         7.4.1.1. Processing of the length field by the sender

            The procedure described here is used to determine whether
            padding is required or not.

               Let:
                 - Length_FRoPW_packet be the length of a FRoPW packet
                   shown in Figure 5,

                   length_field be the contents of the length field of
                   the FRoPW header,

                 - Min_data_field be the minimum size of the link layer
                   data field (46 or 42 bytes for 802.3/DIX Ethernet
                   depending on whether the frame is untagged or not
                   (See section 6 for the discussion),

                 - Padding_length be the length of the pad to be added
                   to the payload.

               The padding procedure is as follows:

                  If the link layer protocol does not have a minimum
                  length requirement then Length_field is set to zero
                  and no padding is required.

                  Else if Length_FRoPW_packet >= Min_data_field then
                        padding is not required; set Length_field to
                        zero.

                       Else padding is required and the following
                       performed:

                         Padding_length = Min_data_field -
                              Length_FRoPW_packet;

                         Append Padding-length characters at the end of
                         the FRoPW payload field;

                         Length_field = length_FRoPW_packet.

                End of the padding procedure.



Kawa, et al.                                                  [Page 15]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002


         7.4.1.2. Processing of the sequence number field by the sender

            The sequence number field is set according to whether the
            sequence number is used or not.

            If the PE supports the sequence number capability then the
            following procedure to number FRoPW packets is used:

               - The initial packet transmitted on the frame relay PW
               must use sequence number 1.

                - For a subsequent packet, the sequence number
                corresponds to the sequence number of the preceding
                packet incremented by 1 modulo 2**16.

                - When the sequence number reaches the maximum value
                (65535) the next sequence number wrap to 1 (the value of
                0 is skipped).

                If the PE does not support sequence number processing,
                then the sequence number field must be set to 0.



      7.4.2. Reception of FRoPW packets

         When a PE receives a FRoPW packet, it processes the different
         fields of the FRoPW header in order to synthesize 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 FRoPW packet as follows:

                 - C/R bit is copied unchanged in the frame relay
                   header.

                 - D bit is copied as follows into the frame relay
                   header DE bit: If it was set to one in the incoming
                   FRoPW packet, it must be copied unchanged in the FR
                   frame header or, depending on the traffic policing
                   performed by the PE and it state of congestion, the
                   FRoPW packet may be dropped.

                   Otherwise if the D bit was set to zero, it may be set
                   to zero or one, depending on the traffic policing
                   performed by the PE device. Setting of this bit by a
                   PE is optional.

                 - The F bit is copied as follows in the frame relay
                   header FECN bit: If it was set to one in the incoming
                   FRoPW packet, it must be copied unchanged in the
                   frame relay header. Otherwise if it was set to zero,




Kawa, et al.                                                  [Page 16]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002


                   it may be set to zero or one, depending on the
                   congestion state of the PE device in the forward
                   direction. Setting this bit by a PE is optional, if
                   the PE does not support FECN, it shall pass this bit
                   unchanged.

                 - BECN follows the same processing rules as FECN,
                   except that it applies to the opposite direction.

                 - It processes the length and sequence field, the
                   details are in the subsequent sub-sections.

                 - It generates the frame relay information field from
                   the contents of the FRoPW packet payload after
                   removing any padding character and retrieves the
                   appropriate DLCI.

        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. The FR frame is queued for
        transmission on the selected frame relay UNI or NNI.


        7.4.2.1. Checking the sequence number by the receiving PE

            If the receiving PE does not support sequence number
            processing, then it will skip the processing of the sequence
            number field.

            If the receiving PE supports packet sequencing capability,
            when a FRoPW packet is received the sequence number is
            processed as follows:

            - If the sequence number of the packet is 0, then the packet
              passes the sequence number check. Note a sequence number
              equal to 0 means that the sender does not support the use
              of sequence number.

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

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

            - Otherwise the packet is out of order.









Kawa, et al.                                                  [Page 17]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002



            If the packet is in order, then it passes the sequence
            number check and the expected sequence number is set as per
            the following assignment:

               expected_sequence_number := packet_sequence_number + 1
               mod 2**16. If (expected_sequence_number = 0) then
               expected_sequence_number := 1.

            FRoPW packets which are received out of order are silently
            discarded. As an option, a PE may buffer out of order FRoPW
            packets to re-order and deliver them in order.

            Re-ordering FRoPW packets is an implementation option but
            requires that the sender numbers FRoPW packets.


         7.4.2.2. Processing of the length field by the receiver

            Any padding character, if present, in the payload field of a
            FRoPW packet received must be removed before forwarding the
            data to the next destination.

            The procedure described here is used to remove padding
            characters.

               Let:
                 - Length_FRoPW_packet be the length of a FRoPW packet
                   received as shown in Figure 5,

                   length_field be the contents of the length field of
                   the FRoPW header of the packet received,

                 - Padding_length be the length of the pad to be removed
                   from the end of the payload field.

           Padding removal procedure:

            If Length_field is set to zero then
               there is no padding character in the payload field
               only user's data.

            Else padding characters are included and their length is
            computed as follows:

               Padding_length = Length_FRoPW_packet - Length_field;

               Remove Padding-length characters from the end of the
               FRoPW payload field.

           End of the padding removal procedure.







Kawa, et al.                                                  [Page 18]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002


   7.5. Handling of error conditions

      If a PE receives a FRoPW packet with errors, it shall discard it
      silently.


8. FR SVC and SPVC Signalling between PEs

   Not supported in this document.


9. FR PVC provisioning

   Provisioning of FR PVCs requires the following actions: The PEs and
   CEs are configured independently for each FR UNI or NNI PVC segments.
   Some of the configuration parameters may include:

      - Outgoing and incoming throughputs (CIR),
      - Outgoing and incoming committed burst sizes (Bc),
ΒΈ     - Outgoing and incoming excess burst sizes (Be),
      - Outgoing and incoming maximum frame lengths,
      - The DLCI assigned to the FR PVC locally,
      - If used, FR transfer and discard priority class or FR service
        class [X.36, X76] assigned to the FR VC.

   To complete the FR VC, a PW (i.e. a pair VC LSP) is established
   between the two PEs. Establishment of FR PW will be addressed in the
   future.

   To check the status of the FR PW at the remote PE, a PE
   execute a PVC maintenance protocol (analogous to Q.933 Annex A PVC
   management procedure [Q933, FRF2] to exchange PVC status information
   and for "keep-alive" purposes. The PVC maintenance protocol will be
   addressed in the future.


10. Frame relay port mode

   10.1. General

      Frame relay port mode or many-to-one mapping is an optional
      capability. It applies to both MPLS and L2TPv3 pseudo-wires.
      Figure 8 illustrates the concept of frame relay port mode.















Kawa, et al.                                                  [Page 19]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002



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


                        (b) Pseudo-wires replacing the FR interface

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


      Figure 7 (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 7 (b) shows the
      replacement of the physical frame relay interface with a pair of
      PEs and a pair of PWs (one PW for each traffic direction between
      PE1 and PE2). A PW may be an MPLS VC LSP or a L2TPv3 tunnel. 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 (cf. Figure
      7 (a)) are mapped now to one pair of PWs,  hence with port mode we
      have many-to-one mapping between FR VCs and a PW.

      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 traffic and QoS
      parameters listed in Section 9 may be assigned to the aggregate
      traffic flowing on an interface between a CE and a PE and not to
      individual FR VC and policing may be performed on the aggregate.

      FR port mode provides transport between two PEs of a complete FR
      frame excluding the opening and closing flags and the Frame check





Kawa, et al.                                                  [Page 20]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002


      sequence (FCS) and with bit/byte stuffing undone (see Figure 8)
      For more information, on FR frame format the reader should
      consult [Q922, Q921].


 bit 8  7   6   5   4   3   2   1    bit   8  7   6   5   4   3   2   1
   +-------------------------------+  +-------------------------------+
   |   Upper DLCI          |C/R| 0 |  |   Upper DLCI          |C/R| 0 |
   +-------------------------------   +-------------------------------+
   |  Lower DLCI   | F | B | DE| 1 |  |   DLCI        | F | B | DE| 0 |
   +-------------------------------+  +-------------------------------+
   |                               |  |           DLCI            | 0 |
   :  Q.922  Information field     :  +-------------------------------+
   :    (i.e. FR payload)          :  |          Lower DLCI   | 0 | 1 |
   |                               |  +-------------------------------+
   +-------------------------------+  |                               |
                                      :  Q.922  Information field     :
                                      :    (i.e. FR payload)          :
                                      |                               |
                                      +-------------------------------+

    (a) With 10 bits for the DLCI      (b) With 23 bits for the DLCI


        Figure 8 - Fields of the frame relay frame used with port mode


   10.2. FRoPW packet format for MPLS port mode

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


       +-------------------------------+
       |      Tunnel LSP label(s)      | n words (1 word per label)
       +-------------------------------+
       |      VC LSP label             |  1 word
       +-------------------------------+
       |       FRoPW Header            |
       |                               | 1 word
       +-------------------------------+
       |             Payload           |
       |        (See Figure 8)         | N bytes
       |      and a Pad (if needed)    |
       +-------------------------------+

    Figure 9 - FR over MPLS packet format for the port mode mapping

         Tunnel LSP label(s) role is as specified for the one-to-one
         mapping.

         The VC LSP label identifies one PW (i.e. one LSP) assigned to
         one port for a set of FR VCs using that port. There is a pair
         of VC LSPs for the two traffic directions.




Kawa, et al.                                                  [Page 21]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002


         FRoPW header: FRoPW header contains protocol control
         information. Its structure is shown in Figure 10. Frame relay
         control bits (F, B, D and C) are not used and are set to zero.
         Note it is possible to apply FECN, BECN and DE bits (bits 4, 5
         and 6) to the aggregate traffic but this use of the indicators
         requires further study.

         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. To compute the FRoPW packet
         size to determine whether padding is needed or not, the format
         of Figure 9 is used.


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

     Figure 10 - FRoPW header structure for the port mode mapping


         The payload field contains a FR frame as shown in Figure 8
         extracted from an incoming FR frame received from a CE and
         padding characters if needed (see section 6 for the need to
         pad).

         The two peer PEs must agree on the length of the DLCI field (2
         or 4 bytes) and the maximum length of FR frame information
         field.

         The default for the number of bytes in a Q.922 information
         field is 262 bytes. Recommendation Q.922 recommends to support
         a size of a least 1600 bytes [Q922 clause A.5.1].


   10.3. FRoPW packet format for L2TPv3 port mode

         When L2TPv3 PW is used with port mode, the FRoPW packet format
         is shown in Figure 11. This format is imported from [L2TPv3
         Figure 3.2.2] and is very similar to FRoPW general packet
         format of Figure 4.














Kawa, et al.                                                  [Page 22]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         PSN Delivery Header                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       L2TP Tunnel Header                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      L2-Specific Sublayer                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Tunneled L2 Frame  (See Figure 9)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 11 - FR over L2TPv3 packet format for the port mode mapping

         PSN delivery header:
            The PSN delivery header serves the same role as the PSN
            delivery header of  Figure 4. When the PSN is an IP network,
            the PSN delivery header is an IP v4 or v6 datagram header.

         L2TP Tunnel header:
            L2TP Tunnel header corresponds to the PW identifier header
            of Figure 4. There are two formats for L2TP Tunnel header
            defined in [L2TPv3]: One when L2TPv3 runs over IP directly
            and another one for L2TPv3 over UDP. The two formats are
            shown in Figure 12 (a) and (b). The description of the
            various fields can be found in [L2TPv3]

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Session ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   :              Cookie (optional, maximum 64 bits)               :
   :                                                               :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  (a) L2TPv3 over IP Tunnel Header


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |T|x|x|x|x|x|x|x|x|x|x|x|  Ver  |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Session ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                 Cookie (optional, maximum 64 bits)...         :
   :                                                               :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  (b) L2TPv3 over UDP Tunnel Header

             Figure 12 - L2TPv3 over IP and UDP Tunnel Header


Kawa, et al.                                                  [Page 23]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002

         L2-Specific Sublayer:
            L2-Specific Sublayer header shown in Figure 11 is analogous
            to FRoPW header of Figure 4. With L2TPv3 the same FRoPW
            header defined in Figure 10 for MPLS port mode is used also
            with L2TPv3. Although L2TPv3 draft defines a default L2-
            Specific Sublayer header, it is advantageous to use the same
            FRoPW header structure with the different types of pseudo-
            wires and the two mapping modes.

            It should be possible to add to the  FRoPW header of Figure
            10 in the next version of this draft the other fields (P, S
            and Offsz) defined in for L2-Specific Sublayer default
            header [L2TPv3].

         Tunneled L2 Frame:
            The Tunneled L2 Frame of Figure 11 corresponds to the
            payload of the general FRoPW format shown in Figure 4. This
            field is used to carry a FR frame as shown in Figure 8.
            Therefore for both MPLS and L2TPv3 used with FR port mode,
            the payload of the FRoPW packet is the same and consists of
            a frame relay frame, excluding the flags and the FCS, with
            bit/byte stuffing undone.


   10.4. FRoPW processing for 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 fields shown in Figure 8 are encapsulated in
         a FRoPW packet payload  to be forwarded to the remote PE. A PE
         shall not modify any of the fields shown in Figure 8, they
         shall be forwarded to the remote PE as received from the FR
         device.

         The processing of the length and sequence number fields is the
         same as for the one-to-one mapping, with the following
         exceptions mentionned earlier: There is one sequence number
         counter for the set of FR VCs and not one for each individual
         FR VC. To compute the FRoPW packet size to determine whether
         padding is needed or not, the format of Figure 9 is used.

         Upon receiving a FRoPW packet, the remote PE shall extract the
         payload field, encapsulate the result in a FR frame for
         transmission to the local FR device.

11. Frame relay service over pseudo-wires

   Frame relay service (FRS) is defined in terms of a number of
   attributes in the basic ITU-T Recommendation on frame relay service
   [I233]. The most two fundamental aspects of FRS are:

      1-The requirement to deliver in order the user's data between
        two frame relay service access point,

      2-The detection of transmission errors if they are detectable.


Kawa, et al.                                                  [Page 24]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002


   Besides the above two service attributes, FRS is defined by a number
   of traffic and QoS attributes in a number of ITU-T Recommendations
   [I.233, X.36 and X.76] and in the Frame Relay Forum Implementation
   Agreement FRF.13 [FRF13]. The following is a partial list
   illustrating some of frame relay service attributes:

      - Committed information rate
      - Excess information rate
      - Committed burst size
      - Excess burst size
      - transit delay
      - Frame delivery ratio
      - Service availability

   FR service providers use FRS attributes to define Service Level
   Agreements (SLA). A frame relay SLA are contractual and binding
   agreement describing the FRS service providers offer to their
   customers.

   An important question to ask is: What does it mean to offer a frame
   relay service? It means that the two fundamental attributes of FRS
   about in-sequence delivery and error detection must be satisfied by
   a network providing a frame relsy service.

   The other FRS attributes related to QoS and traffic are a matter of
   business decision because a multitude of possibilities are available
   to service providers. In one extreme, a service provider may offer a
   FRS with very stringent characteristics and in the opposite case, it
   will not provide any guarantee and provides just a best effort
   service.

   If we ask the previous question in the context of PWE3, we must first
   observe that PWE3 does not require that pseudo-wires emulate
   perfectly or faithfully the characteristics of the native service. In
   the case of FRS this means that the requirements to deliver in
   sequence the user's data and to detect transmission errors may be
   relaxed.

   For both the one-to-one mapping mode and many-to-one mapping/port
   mode, we have the following emulation possibilities with regard to
   the two main attributes of FRS:

      - In-sequence delivery of user's data:

         1-It is possible to emulate perfectly/faithfully this
           requirement. If the PSN does not guarantee in sequence
           delivery, the PEs should use the sequence number capability
           included in FRoPW packets to number the packets and check
           whether they are received in sequence or not.









Kawa, et al.                                                  [Page 25]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002


         2-Alternatively a service provider may elect to drop the
          requirement to deliver in-sequence FRoPW packets. This
          document does not recommend this practice unless for a
          good reason.

      - Detection of transmission errors:

          This requirement must be supported. PW layer does not have
          the capability to detect transmission errors but rely on the
          underlying link layer protocol for transmission error
          detection.

   About FRS traffic and QoS parameters, there is no strict requirements
   to meet. Frame relay traffic and QoS attributes defined in the
   relevant FR documents allow service providers to offer various
   combinations of traffic and QoS parameters without imposing any
   strict performance objective. The same thing should be possible in a
   PWE3 network environment and it is not relevant to refer to how
   faithful/perfect FRS traffic and QoS attributes are provided because
   of the wide spectrum of possibilities.

   There is one additional note to add about FR port mode. Since the
   individual FR VCs are not visible to the PEs individually but only as
   an aggregate, the frame relay service, and in particular, the traffic
   and QoS parameters, provided to the CEs does not apply to the
   individual FR VCs assigned to a port but to their aggregate.


12. IANA considerations

   Not applicable to this document.


13. Security considerations

   PWE3 provides no means of protecting the contents or delivery of the
   FRoPW 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 [LYR].


14. References

[DIX]           Digital, Intel and Xerox, The Ethernet, a local Area
                Network Data Link and Physical layer Specifications
                versions 1 and 2.

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



Kawa, et al.                                                  [Page 26]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 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.

[I233]          ITU-T Recommendation I.233, Frame Mode Bearer Services,
                ITU, Geneva, 1992.

[LYR]           Stewart Bryant, et al.,Protocol Layering in PWE3,draft-
                ietf-pwe3-protocol-layer-00.txt, May 2002, work in
                progress.

[L2TPV3]        M. Townsley, et al., Layer Two Tunneling Protocol
                (Version 3) "L2TPv3", draft-ietf-l2tpext-l2tp-
                base-02.txt, March 2002, work in progress..

[P8021Q]       IEEE Std 802.1Q, Virtual bridged local area networks.

[P8023]        IEEE Std 802.3, Part 3 Carrier sense multiple access with
               collision detection (CSMA/CD) access method and physical
               layer specifications.

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

[PWE3FW]        Prayson Pate, et al., Internet draft, Framework for
                Pseudo Wire Emulation Edge-to-Edge (PWE3), work in
                progress.

[Q921]          ITU-T Recommendation Q.921, ISDN Data Link Layer
                Specification, ITU,Geneva, 1997.

[Q922]          ITU-T Recommendation Q.922, ISDN Data Link Layer
                Specification for Frame Mode Bearer Services, ITU,
                Geneva, 1992.

[Q933]          ITU-T Recommendation Q.933, ISDN Signaling Specification
                for Frame Mode Bearer Services, Geneva, October 1995.

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

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






Kawa, et al.                                                  [Page 27]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002


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


15. Author's Addresses

   Claude Kawa
   Nortel Networks
   3500 Carling Ave.
   Ottawa, Ontario, Canada
   email: kawa@nortelnetworks.com

   Andrew G. Malis
   Vivace Networks, Inc.
   2730 Orchard Parkway
   San Jose, CA 95134
   e-mail: Andy.Malis@vivacenetworks.com

   Prayson Pate
   Overture Networks
   P. O. Box 14864
   RTP, NC, USA 27709
   email: prayson.pate@overturenetworks.com

   Ravi Bhat
   Nokia
   email: ravi.bhat@nokia.com

   Nishit Vasavada
   Nokia
   email: nishit.vasavada@nokia.com

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

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

   Giles Heron
   PacketExchange Ltd.
   The Truman Brewery
   91 Brick Lane
   LONDON E1 6QL
   United Kingdom
   e-mail: giles@packetexchange.net


Kawa, et al.                                                  [Page 28]


Internet Draft      draft-martini-frame-encap-mpls-01.txt     June 2002


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

   Dan Tappan
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824
   e-mail: tappan@cisco.com

   Eric Rosen
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA, 01824
   e-mail: erosen@cisco.com

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

   Vinai Sirkay
   Vivace Networks, Inc.
   2730 Orchard Parkway
   San Jose, CA 95134
   e-mail: sirkay@technologist.com

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

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















Kawa, et al.                                                  [Page 29]