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

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

PWE3 Working Group                                         Claude Kawa
Internet Draft                                     Ðcole Polytechnique
Expires: January 2005                                    Rao Cherukuri
                                                    Cisco Systems, Inc.
                                                              (Editors)


                                                       Andrew G. Malis
                                                               Tellabs

                                                          Luca Martini
                                                    Cisco Systems, Inc.

                                                       David Sinicrope
                                                              Ericsson


                                                           August 2004


                      Frame Relay over Pseudo-Wires

                   draft-ietf-pwe3-frame-relay-03.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 (2004). All Rights Reserved.





Kawa, et al.                                                   [Page 1]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt       August 2004

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. 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, and  is defined for MPLS PSN only. The second mode
   is known as port mode or many-to-one mapping mode and is defined for both
   MPLS PSNs and IP PSNs with L2TPv3.


Co-authors

 The following are co-authors of this document:

       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
       Nasser El-Aawar           Level 3 Communications, LLC







Table of Contents

1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . . .  4
4. Requirements for Frame Relay Over Pseudo-wires. . . .  . . . .  5
5. Reference model and PWE3 protocol layering . . . . . . . . . .  5
6. General encapsulation for the two mapping modes   . . . . . .   7
7. Frame Relay over MPLS PSN for the one-to-one mapping mode. .  . 8
8. FR PVC provisioning. . . . . . . . . . . . . . . . . . . . . . 16
9. Traffic management aspects                                     16
10. Frame relay port mode . . . . . . . .. . . . . . . . . . . .  17
11. Frame relay service over pseudo-wires. . . . . . . . . . . . .22
12. IANA considerations. . . . . . . . . . . . . . . . . . . . . .24
13. Security Considerations. . . . . . . . . . . . . . . . . . .  24
14. Supplement on frame relay frame formats. . . . . . . . . . . .24
15. References . . . . . . . . . . . . . . . . . . . . . . . . .  25
16. Author's Addresses  . . . . . . . . . . . . . . . . . . . . . 27

Kawa, et al.                                                   [Page 2]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt       August 2004

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

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

   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 is an overview of PWE3 reference model and PWE3
   protocol layers described in [PWE3ARC]. 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 addresses FR PVC provisioning. Section 9 covers the traffic
   management aspects. Section 10 describes FR port mode for MPLS PSN and
   IP PSN with L2TPv3. 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. A supplement on frame relay frame formats
   appears in Section 14.



Kawa, et al.                                                  [Page 3]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt     August 2004

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.
   PWE3 definitions can be found in [PWE3REQ, PWE3ARC]. 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:    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.


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

Kawa, et al.                                                   [Page 4]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt      August 2004

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: MUST be able to transport variable length FR
   frames and SHOULD be able to transport FR frames without being
   limited by the PSN MTU through the use of PW fragmentation [FRAG].

        2. Bidirectional traffic: MUST support bidirectional traffic.

        3. Frame ordering: MUST deliver frame relay frames in the order.
           as they were transmitted.

        4. 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 [X36, X76].

        5. PVC Status Maintenance: MUST support the mapping and transport
           of frame relay PVC status indications defined in ITU-T
           Recommendation X.36 [X36].  Note PVC status signaling will be
           addressed in another IETF draft.

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

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

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


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




Kawa, et al.                                                   [Page 5]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt      August 2004


            |<-------------- Emulated Service ---------------->|
            |                                                  |
            |          |<------- Pseudo Wire ------>|          |
            |          |                            |          |
            |          |    |<-- PSN Tunnel -->|    |          |
            |          V    V                  V    V          |
            V    AC    +----+                  +----+     AC   V
      +-----+    |     | PE1|==================| PE2|     |    +-----+
      |     |----------|............PW1.............|----------|     |
      | CE1 |    |     |    |                  |    |     |    | CE2 |
      |     |----------|............PW2.............|----------|     |
      +-----+  ^ |     |    |==================|    |     | ^  +-----+
            ^  |       +----+                  +----+     | |  ^
            |  |   Provider Edge 1         Provider Edge 2  |  |
            |  |                                            |  |
      Customer |                                            | Customer
      Edge 1   |                                            | Edge 2
               |                                            |
               |                                            |
         native service                               native service

                     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, 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.
    One-to-one mapping mode is defined for MPLS PSNs only and port mode is
    defined for both MPLS PSN and IP PSN with L2TPv3.

    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 PSNs and IP PSNs. With IP PSNs, 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 PSNs and IP PSNs
         with L2TPv3. In terms of PWE3 protocol layering defined in [PWE3ARC],
         this specification utilizes the protocol stack shown in Figure 2.






Kawa, et al.                                                   [Page 6]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt      August 2004



      +-------------+                                +-------------+
      |  Emulated   |                                |  Emulated   |
      | Frame Relay |         Emulated Service       | Frame Relay |
      |  Services   |<==============================>|  Services   |
      |             |                                |             |
      +-------------+           Pseudo Wire          +-------------+
      |Demultiplexer|<==============================>|Demultiplexer|
      +-------------+                                +-------------+
      |    PSN      |            PSN Tunnel          |    PSN      |
      | MPLS or IP  |<==============================>| MPLS or IP  |
      +-------------+                                +-------------+
      |  Physical   |                                |  Physical   |
      +-----+-------+                                +-----+-------+

            PE1                                            PE2

         Figure 2: Frame Relay PWE3 Protocol Stack Reference Model


      For the purpose of this document, PE1 is defined as the ingress
      router, and PE2 as the egress router. A layer 2 PDU received
      at PE1, will be encapsulated at PE1, transported, decapsulated at PE2,
      and transmitted out of PE2.



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


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

     Figure 3 - General format of FR encapsulation over PSN


Kawa, et al.                                                   [Page 7]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt      August 2004

The FRoPW 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:

      1. PSN Transport header is specific to the PSN and the tunneling
         technology used (L2TP or MPLS) This header is used to switch
         the FRoPW packet through the packet switched core. It is described
         in the following sub-sections addressing each type of PSN and
         tunneling technology.

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

      3. Control Word 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 FR service payload field depends on the mapping
         mode.  The details are provided in the following sections addressing
         each mapping mode.

         The Pad is used for the following reason: When a pseudo-wire
         traverses a link that requires a minimum Layer 2 frame length
         (for example, Ethernet), padding octets are added at the
         end of the FRoPW packet (i.e. after the payload field) to
         produce the required minimum length.


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 the MPLS PSN core network for forwarding purposes
      of FRoPW packets. A tunnel LSP corresponds to "PSN transport" 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, and frame relay VCs are
      bidirectional, a pair of VC LSPs and corresponding tunnel LSPs carrying
      traffic in opposite directions will be required.







Kawa, et al.                                                   [Page 8]
Internet Draft      draft-ietf-pwe3-frame-relay-03.txt      August 2004



      In the PE1 to PE2 direction a tunnel LSP is used for forwarding FRoPW
      packets from PE1 to PE2, and the tunnel LSP label is not related
      to any particular 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
      pushes on a tunnel LSP label. The VC label is at the bottom of
      the label stack. As with the other PWE3 encapsulations, 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 signaling establishes the two directions
      simultaneously with a single set of control messages 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 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 single direction.

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








Kawa, et al.                                                  [Page  9]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt       August 2004



       +-------------------------------+
       |      Tunnel LSP label(s)      | n*4 octets (four octets per label)
       +-------------------------------+
       |      VC LSP label             |  4 octets
       +-------------------------------+
       |       Control Word            |
       |      (See Figure 5)           | 4 octets
       +-------------------------------+
       |             Payload           |
       |       (Frame relay frame      |
       |        information field)     | n octets
       |                               |
       +-------------------------------+
       |        Pad (if required)      |
       +-------------------------------+

    Figure 4 - FR Over MPLS Packet Format for the One-to-One Mapping

The encapsulation consists of the following fields: Control Word,
Payload and Pad (if required), preceded by the Tunnel LSP label(s) and
VC LSP label.

The meaning of the different fields is as follows:

      Tunnel LSP label(s):
         The Tunnel LSP label(s) corresponds to the PSN transport header
         of Figure 3. 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
         header of Figure 3. Together the Tunnel LSP label(s) and VC
         LSP label form an MPLS label stack [RFC3032].

      Control Word:
         Control Word contains protocol control information. Its
         structure is shown in Figure 5.


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

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


Kawa, et al.                                                  [Page  10]


Internet Draft      draft-ietf-pwe3-frame-relay-03.txt       August 2004

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

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

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

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

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

         I, L (bits 8 and 9):
            I and L are the Initial and Last fragmentation bits and their
            functionality is specified in [FRAG].

         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 total length of FRoPW payload, which is the sum of the
            lengths of the control word and Payload fields is less than 64 octets,
            then padding has to be performed. In this case length field MUST be
            set to the FRoPW 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 ingress PE.

         Sequence number (Bit 16 to 31):
             Sequence numbers provide one possible mechanism to ensure the
             ordered delivery of FRoPW packets. A circular list
             of sequence numbers is used, skipping the value zero. The value of
           zero indicates that the sequence number field is not used. See
           section 7.4 for the sequence number generation and checking
           algorithms.

Kawa, et al.                                                   [Page 11]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt        August 2004
            Note: The use of sequence numbers may not be required if the network
          itself ensures ordered delivery of FRoPW packets.

         Payload:
            The payload field corresponds to X.36/X.76 frame relay frame
            information field with bit/byte stuffing and frame relay header
           (DLCI)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 VC LSP is established.

         Pad:
            The Pad consists of a number of octets (including zero
            octet) required to guarantee that the FRoPW packet size
            is not less than 64 packets.  Any octet with a decimal
            value from 0 to 255 may be used as a padding character.

         Note: The limit of 64 octets for the packet length below which
               padding is required, aligns with the minimum Ethernet
               frame size.

   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 interfaces. The PE takes the following actions (not necessarily
         in the order shown):

            - It 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 FRoPW Control Word.

               - Discard eligibility indicator (DE or D): The D bit is
                 set as follows in the Control Word: 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. This bit is often set as a result of
                 ingress frame policing.

                 Setting of this bit by a PE is OPTIONAL. However, no PE
                 SHALL ever 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.

               - 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 Control Word carrying the FECN.


Kawa, et al.                                                  [Page 12]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt       August 2004

                 While setting this bit by a PE is OPTIONAL, PE MUST not
                 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 backward direction.

               - Length: If the FRoPW 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
                 and padding has to be performed. Otherwise the length field
                 MUST be set to zero.

               - Sequence number: The sequence number field is set if the FR PW
                 uses sequence numbers.

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

                    - The initial FRoPW packet transmitted MUST use sequence
                      number 1,
                    - For a subsequent frame, the sequence number corresponds
                      to the sequence number of the preceding frame incremented
                      by 1 up to the maximum value of 65535,
                    - When the sequence number reaches the maximum 16 bit value
                      (65535) the next sequence number wraps to 1 (the value of
                      0 is skipped).

                 If the FR PW uses sequence numbers do not support sequence
                 number processing, then the sequence number field must be set
                 to 0.

               - Payload and Pad: The payload of the FRoPW 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. Padding characters may follow the payload field.

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



Kawa, et al.                                                  [Page 13]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt       August 2004



      7.4.2. Reception of FRoPW packets

               When a PE receives a FRoPW packet, it processes the different
               fields of the control word 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 unchanged into the frame relay
                         header DE bit.

                       - The F bit is processed as follows: If it was set
                         to one in the incoming FRoPW packet, it must be
                         copied unchanged into the FECN bit in the frame relay
                         header.
                         Otherwise if it was set to zero, the FECN bit may be
                         set to one, depending on the congestion state of the PE
                         device in the forward direction. Setting this bit by a
                         PE is OPTIONAL.

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

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


        7.4.2.1. Checking the Sequence Number by the Receiving PE

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

              When a FRoPW packet is received the sequence number is processed
              as follows:


Kawa, et al.                                                  [Page 14]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt      August 2004

                - 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 sequence
                       numbers are not used. Through management or signaling,
                       the two PEs determine whether sequence numbers are used
                       or not.

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

              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, up to a
               maximum of 65535 after which it skips zero and wraps from 6553 to
               1.

              If (expected_sequence_number = 0) then expected_sequence_number
                := 1.

              FRoPW  packets that are received out of order should be dropped
              unless they can be re-ordered without introducing significant
              delays.

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


              Note: Excessive out-of-sequence FRoPW packets has an effect
               similar to excessive packet loss on a frame relay VC.


               7.4.2.2. Processing of the Length Field by the Receiver

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

Kawa, et al.                                                  [Page 15]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt      August 2004


                The procedure described here is used to remove padding
                characters.

                If the Length field is set to zero then there are no padding
                Characters following the payload field.

                Else padding characters are removed based on the Length field.


           7.5. Handling of error conditions

            If a PE receives a FRoPW packet with a header containing invalid
            contents, it shall be discarded. For example:

            - An invalid or unassigned tunnel or VC label,
            - A value different than zero for the first four bits of the
              Control Word,
            - A length field with a content greater or equal to 64,
            - Inconsistencies between the content of the length field and the
              actual size of the FRoPW packet.
            - If fragmentation is not used a value different than zero for the
              two fragmentation bits(bits 8 and 9 of the FRoPW header).


8. 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 [X36, 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 the FR PW is addressed in [CONTROL].



9. Traffic management aspects

     In ITU-T Recommendations X.36 and X.146, a number of different traffic
     parameters and Quality of Service (QoS) classes are defined. When a
     tunnel LSP is used to carry either a single frame relay VC or
     multiple frame relay VCs with different combinations of traffic
     parameters and QoS classes, the tunnel LSP shall be capable of
     providing the required QoS for the encapsulated frame relay VCs.
     In an MPLS network that does only support QoS differentiation on a
     per LSP basis, the tunnel LSP shall meet the most stringent QoS
     requirements of the frame relay VCs carried by that tunnel LSP.


Kawa, et al.                                                  [Page 16]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt      August 2004

   9.1. Use of Differentiated Services for Frame relay over MPLS:

      If the MPLS network supports Differentiated Services (DiffServ)
      Behavior Aggregates defined in informational RFCs 2475 and 3260,
      MPLS packets can be treated with different priorities on a Per Hop
      Behavior (PHB). In this case, two different types of LSPs are defined
      in RFC 3270 which can both be used for the tunnel LSP:

        - Label-Only-Inferred-PSC LSPs (L-LSP);
        - EXP-Inferred-PSC LSPs (E-LSP).

      If a L-LSP is used as a tunnel LSP, the PHB scheduling class of each
      packet is inferred from the label without any other information
      (e.g., regardless of the EXP field value). In that case, the LSP shall
      meet the most stringent QoS requirements of the frame relay VCs tunneled
      by the LSP.

      If an E-LSP is used as a tunnel LSP, the EXP field of the tunnel label
      is used to determine the PHB to be applied to each packet, i.e.,
      different packets in one LSP may receive a different QoS. The 3-bit EXP
      field of the tunnel label can represent eight different combinations of
      Per Hop Behaviour (PHB) and drop precedence levels. The mapping of the
      PHB to EXP fields is either explicitly signaled at label set-up or
      relies on a pre-configured mapping.


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 6 illustrates the concept of frame relay port mode.

      Figure 6 (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 6 (b) shows the replacement of the physical frame relay interface
      with a pair of PEs and a PW between them. 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 which
      are controlled by the same signaling channel using DLCI=0 (cf. Figure
      7 (a)), are mapped into one PW. Hence with port mode we have many-to-one
      mapping between FR VCs and a PW.






Kawa, et al.                                                  [Page 17]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt       August 2004

              +------+                          +-------+
              | 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 pair    |    |         +------+
   |      |          |    |==================|    |         |      |
   |  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 6 - 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 traffic and QoS
      parameters listed in Section 8 may be assigned to the aggregate
      traffic flowing on an interface between a CE and a PE and not to
      individual FR VCs 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

      Sequence (FCS) and with bit/byte stuffing undone.
      For more information on FR frame formats the reader should
      consult Section 14 and [X36, X76].





Kawa, et al.                                                  [Page 18]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt      August 2004

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


       +-------------------------------+
       |      Tunnel LSP label(s)      | n*4 octets (four octets per label)
       +-------------------------------+
       |      VC LSP label             | 4 octets
       +-------------------------------+
       |       Control Word            |
       |        (see Figure 8)         | 4 octets
       +-------------------------------+
       |             Payload           |
       |    (FR Address plus           |
       |      information field)       | N octets
       |      and a Pad (if needed)    |
       +-------------------------------+

    Figure 7- 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 the PW assigned to the port for a set
         of FR VCs using that port. There is a pair of VC LSPs for the two
         traffic directions.


         Control Word: The Control Word contains protocol control
         information. Its structure is shown in Figure 8. Frame relay
         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. To compute the FRoPW packet
         size to determine whether padding is needed or not, the format of
         Figure 8 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|I|L|  Length   | Sequence Number               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 8 - Control Word structure for the port mode mapping


Kawa, et al.                                                  [Page 19]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt      August 2004

         The payload field contains a FR frame received from a CE consists of
         the address field (including the DLCI and the control bits) and
         information field, with the opening and closing flags, bit/byte
         stuffing and FCS 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.  These are signaled during Pseudo-Wire setup using two
         interface parameters [CONTROL, PWE3IANA]:



   10.3. FRoPW packet format for L2TPv3 port mode

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


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         PSN transport Header                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       L2TP Tunnel Header                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      L2-Specific Sublayer                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Tunneled L2 Frame                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

         PSN transport header:
            The PSN transport header is the PSN transport header of Figure 3.
            When the PSN is an IP network, this header is an IP v4 or v6
            datagram header.

         L2TP Tunnel header:
            L2TP Tunnel header corresponds to the PW header
            of Figure 3. 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 9 (a) and (b). The description of the
            various fields can be found in [L2TPv3].



Kawa, et al.                                                  [Page 20]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt      August 2004
    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 10 - L2TPv3 over IP and UDP Tunnel Header




         L2-Specific Sublayer:
            L2-Specific Sublayer header shown in Figure 9 is analogous
            to the Control Word of Figure 3. With L2TPv3 the same Control Word
            defined in Figure 8 for MPLS port mode is used also
            with L2TPv3.


         Tunneled L2 Frame:
            The Tunneled L2 Frame of Figure 9 corresponds to the
            payload of the general FRoPW format shown in Figure 3. 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.

Kawa, et al.                                                  [Page 21]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt      August 2004
   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 frame (excluding the flags and the FCS) is
         encapsulated in a FRoPW packet payload 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 FRoPW packet, the remote PE shall extract the
         FRoPW 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 ITU-T Recommendation [X36]. 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.


   Besides the above two service attributes, FRS is defined by a number
   of traffic and QoS attributes in ITU-T Recommendations
   [X36 and X76] 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.


Kawa, et al.                                                  [Page 22]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt      August 2004
   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 relay service.

   The other FRS attributes related to QoS and traffic are a matter of
   business decisions 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.

         2-Alternatively a service provider MAY elect to drop the
          requirement to deliver in-sequence FRoPW packets. In general,
          this practice is NOT RECOMMENDED, since it may adversely affect
          the applications in the CEs

      - Detection of transmission errors:

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

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

Kawa, et al.                                                  [Page 23]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt      August 2004

   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

   No IANA actions are required in 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 [PWE3ARC, PWE3REQ].


14. Supplement on frame relay frame formats

    FR frame formats are defined in ITU-T Recommendation X.36 [X36].
    Two formats are used in this document. The first one uses 10 bits
    for the DLCI (Figure 11-a) and the second one uses 23 bits for the
    DLCI (Figure 11-b).

    The first and last octets are HDLC opening and closing flags. The
    DLCI occupies the second and third octets or the second, third,
    fourth and fifth octets as shown in Figure 11. There are various
    control fields:

      C/R is HDLC command and response bit.
      F and B are respectively the forward and backward congestion
      notification bits.
      DE is the discard eligibility bit.
      FCS is the frame check sequence. Two generator polynomials are
      used. One produces a 16-bit sequence [X36] and the other a 32-bit
      sequence [FRF14].


















Kawa, et al.                                                  [Page 24]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt      August 2004

 bit 8  7   6   5   4   3   2   1    bit   8  7   6   5   4   3   2   1

   +-------------------------------+  +-------------------------------+
   |             Flag              |  |            Flag               |
   | 0  1   1   1    1   1   1   0 |  | 0  1   1   1    1   1   1   0 |
   +-------------------------------+  +-------------------------------+
   |   Upper DLCI          |C/R| 0 |  |   Upper DLCI          |C/R| 0 |
   +-------------------------------   +-------------------------------+
   |  Lower DLCI   | F | B | DE| 1 |  |   DLCI        | F | B | DE| 0 |
   +-------------------------------+  +-------------------------------+
   |                               |  |           DLCI            | 0 |
   :Frame relay information field  :  +-------------------------------+
   :       (i.e.payload)           :  |          Lower DLCI   | 0 | 1 |
   |                               |  +-------------------------------+
   +-------------------------------+  | Frame relay information field |
   |   FCS (2 or 4 octets)         |  :      (i.e. payload)           :
   |                               |  :                              :
   +-------------------------------+  |                               |
   |             Flag              |  +-------------------------------+
   | 0  1   1   1    1   1   1   0 |  |        FCS (2 or 4 octets)    |
   +-------------------------------+  :                               :
                                      +-------------------------------+
                                      |            Flag               |
                                      | 0  1   1   1    1   1   1   0 |
                                      +-------------------------------+


     a-With 10 bits for the DLCI      b-With 23 bits for the DLCI


                      Figure 11 - Frame relay frame formats


15. References

[CONTROL]       Luca Martini, et al., Pseudowire Setup and Maintenance
                using LDP, ddraft-ietf-pwe3-control-protocol-05.txt,
                June 2004, work in progress.

[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

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

Kawa, et al.                                                  [Page 25]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt      August 2004


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


[L2TPV3]        M. Townsley, et al., Layer Two Tunneling Protocol
                (Version 3) "L2TPv3", draft-ietf-l2tpext-l2tp-base-11.txt,
                October 2003, 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.

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

[PWE3ARC]       Stewart Bryant, et al.,Internet draft, PWE3 Architecture,
                draft-ietf-pwe3-arch-07.txt, work in progress.

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

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


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

Kawa, et al.                                                  [Page 26]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt      August 2004



16. Author's Addresses

   Claude Kawa
   Ecole Polytechnique  Montreal
   claude.kawa@sympatico.ca

   Andrew G. Malis
   Tellabs
   andy.malis@tellabs.com

   Rao Cherukuri
   Cisco Systems
   rcheruku@cisco.com


   David Sinicrope
   Ericsson IPI
   david.sinicrope@ericsson.com


   Prayson Pate
   Overture Networks
   prayson.pate@overturenetworks.com

   Ravi Bhat
   Nokia
   ravi.bhat@nokia.com

   Nishit Vasavada
   Nokia
   nishit.vasavada@nokia.com

   Luca Martini
   Cisco Systems Inc.
   lmartini@cisco.com

   Nasser El-Aawar
   Level 3 Communications, LLC.
   nna@level3.net

   Giles Heron
   Tellabs
   giles.heron@tellabs.com

    Dimitri Stratton Vlachos
    Mazu Networks, Inc.
    d@mazunetworks.com

    Dan Tappan
    Cisco Systems, Inc.
   tappan@cisco.com

 Kawa, et al.                                                  [Page 27]

Internet Draft      draft-ietf-pwe3-frame-relay-03.txt      August 2004


   Eric Rosen
   Cisco Systems, Inc.
   erosen@cisco.com

   Steve Vogelsang
   Laurel Networks, Inc.
   sjv@laurelnetworks.com

   Vinai Sirkay
   Reliance Infocomm
   vinai@sirkay.com


   Chris Liljenstolpe
   Cable & Wireless
   chris@cw.net

   Kireeti Kompella
   Juniper Networks
   kireeti@juniper.net































Kawa, et al.                                                  [Page 28]


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