[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 (Editor)
Internet Draft                                     Ðcole Polytechnique


Expires: January 2004                                     Luca Martini
                                                       Nasser El-Aawar
                                           Level 3 Communications, LLC.

                                                       Andrew G. Malis
                                                               Tellabs

                                                        Eric C. Rosen
                                                         Daniel Tappan
Prayson Pate
Overture Networks, Inc.                             Cisco Systems, Inc.

Chris Liljenstolpe
Cable & Wireless                                        Steve Vogelsang
                                                   Laurel Networks, Inc

Kireeti Kompella                                Dimitri Stratton Vlachos
Juniper Networks                                      Mazu Networks,Inc.

                                                             Giles Heron
                                                     PacketExchange Ltd.

Vinai Sirkay                                             Steve Vogelsang
Vivace Networks, Inc.                              Laurel Networks, Inc.


Ravi Bhat
Nishit Vasavada
Nokia

                                                               July 2003


                      Frame Relay over Pseudo-Wires

                   draft-ietf-pwe3-frame-relay-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."


Kawa, et al.                                                   [Page 1]

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003

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.

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. . . .  . . . .  4
5. Reference model and PWE3 protocol layering . . . . . . . . . .  5
6. General encapsulation for the two mapping modes   . . . . . .   8
7. Frame Relay over MPLS PSN for the one-to-one mapping mode. .  . 9
8. FR SVC and SPVC Signalling between PEs. . . . . . . . . . . .  17
9. FR PVC provisioning. . . . . . . . . . . . . . . . . . . . . . 17
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. . . . . . . . . . . .25
15. References . . . . . . . . . . . . . . . . . . . . . . . . .  26
16. Author's Addresses  . . . . . . . . . . . . . . . . . . . . . 27

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-01.txtand draft-
   kamapabhava-fr-pwe3-01.txt previously submitted to the PWE3 working
   group and replaces both of these drafts.



Kawa, et al.                                                   [Page 2]

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003

   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.

   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. A supplement on frame relay frame formats
   appears in Section 14.

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.




   Kawa, et al.                                              [Page 3]

   Internet Draft      draft-ietf-pwe3-frame-relay-01.txt      July 2003


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

4. Requirements for Frame Relay Over Pseudo-Wires

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

Kawa, et al.                                                   [Page 4]

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003


      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.


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







Kawa, et al.                                                   [Page 5]

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003



                    |<------ 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 10]:









Kawa, et al.                                                   [Page 6]

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003


     +---------------------+
     |      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]).Section 14
              contains aa supplement on frame relay frame formats and
              the description of the various fields.

            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 9]:














Kawa, et al.                                                   [Page 7]

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003


     +---------------------+             +-------------------------+
     |      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 (see Section 14) 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-ietf-pwe3-frame-relay-01.txt        July 2003


          +-------------------------------+
          |                               |
          |     PSN Delivery Header       |
          +-------------------------------+
          |                               |
          |     PW Identifier header      |
          +-------------------------------+
          |       FRoPW Header            |
          |                               |
          +-------------------------------+
          |                               |
          |           Payload             |
          +-------------------------------+
          |         Pad (if requided)     |
          +-------------------------------+

     Figure 4 - General format of FRoPW packet

The FRoPW packet format consits of the following fields: FRoPW Header, Payload and
Pad (if requided) preceded by the PSN delivery header and PW Identifier header.

The meaning of the different fields is as follows:

      1. PSN delivery header is a header 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 discussed in the following sub-sections addressing each type
         of PSN and tunneling technology.

      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 for the following reason: When a pseudo-wire
         traverses a link that requires a minimum layer 2 frame length
         (for example, Ethernet), padding characters 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 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.


Kawa, et al.                                                   [Page  9]
Internet Draft       draft-ietf-pwe3-frame-relay-01.txt        July 2003


      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

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

Internet Draft       draft-ietf-pwe3-frame-relay-01.txt        July 2003



       +-------------------------------+
       |      Tunnel LSP label(s)      | n words (1 word per label)
       +-------------------------------+
       |      VC LSP label             |  1 word
       +-------------------------------+
       |       FRoPW Header            |
       |      (See Figure 6)           | 1 word
       +-------------------------------+
       |             Payload           |
       |(from a frame relay frame      |
       |      information field)       | N bytes
       |                               |
       +-------------------------------+
       |        Pad (if required)      |
       +-------------------------------+

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

It consits of the following fields: FRoPW Header, Payload and
Pad (if requided) 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 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|B|E|  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.



Kawa, et al.                                                   [Page 11]

Internet Draft       draft-ietf-pwe3-frame-relay-01.txt        July 2003


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

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

         B, E (bits 8 and 9):
            B and E are fragmentation bits and their functionality is
            specified in [FRAG].

         Length (bits 10 to 15):
            The length field is used in conjunction with the padding of
            short FRoPW packets when the link layer protocol requires a minimum
            frame length.

            If the total length of the FRoPW packet header plus the Payload
            (see Figure 5) is less than 64 bytes, then the length field must be
            set to the length of the FRoPW packet header plus the Payload,
            otherwise the length field must be set to zero.

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




Kawa, et al.                                                  [Page 12]

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003


         Pad:
            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. Any 8-bit character
            with a decimal value from 0 to 255 may be used as a padding
            character.

   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.


Kawa, et al.                                                   [Page 12]

Internet Draft       draft-ietf-pwe3-frame-relay-01.txt        July 2003


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

               - Payload and Pad:
                 The payload of the FRoPW packet is the contents of ITU-
                 T Recommendation Q.922 [Q922] frame relay frame
                 information field (see Section 14) stripped from any
                 bit or byte stuffing. Padding characters may follow the
                 payload field; see 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 in bytes of the
                   FRoPW header and Payload of a FRoPW packet
                   shown in Figure 5,

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

                 - Min_length = 64 bytes

                 - Padding_length be the number (in bytes) of the
                   padding characters to be added.

               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_length then
                        padding is not required; set Length_field to
                        zero.


Kawa, et al.                                                  [Page 13]

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003


                       Else padding is required and the following
                       performed:

                         Padding_length = Min_length -
                              Length_FRoPW_packet;

                         Append Padding-length characters at the end of
                         the FRoPW packet (after the payload field).

                         Length_field = length_FRoPW_packet.

                End of the padding procedure.


         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.


Kawa, et al.                                                  [Page 14]

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003


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

                   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.

Kawa, et al.                                                  [Page 15]

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003


            - 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
               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 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 total length of the following
                  packet fields: FRoPW Header, Payload and Pad,

                - 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
            characters following the payload field

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


Kawa, et al.                                                  [Page 16]

Internet Draft     draft-ietf-pwe3-frame-relay-01.txt        July 2003


               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.


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







Kawa, et al.                                                  [Page 17]

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003



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

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003


      sequence (FCS) and with bit/byte stuffing undone.
      For more information, on FR frame formats the reader should
      consult Section 14 and the authoritative references [Q922, Q921].


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


       +-------------------------------+
       |      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 8- 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 19]

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003


         FRoPW header: FRoPW header contains protocol control
         information. Its structure is shown in Figure 9. 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 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|Res|  Length   | Sequence Number               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 9 - 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.  These are signaled during Pseudo-Wire setup using two
         interface parameters [CONTROL, PWE3IANA]:

         0x01         Interface MTU in octets
         0x08         Frame-Relay DLCI Length

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

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003


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

    Figure 10 - 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 11 (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 11 - L2TPv3 over IP and UDP Tunnel Header


Kawa, et al.                                                  [Page 21]

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003

         L2-Specific Sublayer:
            L2-Specific Sublayer header shown in Figure 10 is analogous
            to FRoPW header of Figure 4. With L2TPv3 the same FRoPW
            header defined in Figure 9 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 10 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 8is 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 22]

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003


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

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003


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



















Kawa, et al.                                                  [Page 24]

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003



14. Supplement on frame relay frame formats

    FR frame formats are defined in ITU-T Recommendation Q.922 [Q922].
    Two formats are used in this document. The first one uses 10 bits
    for the DLCI (Figure 12-a) and the second one uses 23 bits for the
    DLCI (Figure 12-b); see also Figure A-1/Q922.

    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 12. 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 [Q921] and the other a 32-bit
      sequence [FRF14].


 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 12 - Frame relay frame formats



Kawa, et al.                                                  [Page 25]

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003


15. References

[CONTROL]       Luca Martini, et al., Pseudowire Setup and Maintenance
                using LDP, draft-ietf-pwe3-control-protocol-02.txt,
                February 2003, 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.

[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-02.txt,
                June 2003, work in progress.

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

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

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

[PWE3FW]        Prayson Pate, et al., Internet draft, Framework for
                Pseudo Wire Emulation Edge-to-Edge (PWE3), draft-ietf-
                pwe3-framework-01.txt, 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.

Kawa, et al.                                                  [Page 26]

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003


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


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


16. Author's Addresses

   Claude Kawa
   Ðcole Polytechnique  Montr‰al
   email: claude.kawa@polymtl.ca

   Andrew G. Malis
   Tellabs
   e-mail: andy.malis@tellabs.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




Kawa, et al.                                                  [Page 27]

Internet Draft      draft-ietf-pwe3-frame-relay-01.txt        July 2003


   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

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


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