Internet DRAFT - draft-fischer-pwe3-atm-service

draft-fischer-pwe3-atm-service





   PWE3 Working Group                                       John Fischer
   Internet Draft                                          Matthew Bocci
   Expiration Date: August 2002                        Mustapha Aissaoui
                                                                 Alcatel
   A. Siddiqui
   Cable & Wireless                                            Mina Azad
                                                         Ghassem Koleyni
   Anna Cui                                              Nortel Networks
   Advanced Fibre Communications
                                                             Jim Harford
   Dave Paw                                           AdvanceNet Systems
   MCI WorldCom
                                                           Cheng C. Chen
   Sat Sahota                                          NEC America, Inc.
   Telus Communications
                                                           Sushil Shelly
   Eric Letourneau                                         Avici Systems
   Bell Canada
                                                              Phong Khuu
   Dave King                                              Turin Networks

   Jeffery See
   General Dynamics                                        Aditya Sehgal
                                                                     SBC

                                                           Sohel Q. Khan
                                                                  Sprint

                                                              March 2002


                      PWE3: ATM service description
                  draft-fischer-pwe3-atm-service-03.txt


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of section 10 of RFC 2026 [1].

   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.



Fischer, et al.           Expires August 2002                  [Page 1]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002

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


Abstract

   Generic requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3)
   have been described in [6].  This draft lists ATM specific
   requirements and provides encapsulation formats and semantics for
   connecting ATM edge networks through a core packet network using IP,
   L2TP or MPLS.  This basic application of ATM interworking will allow
   ATM service providers to take advantage of new technologies in the
   core in order to provide ATM multi-services.

Table of Contents

   1 Conventions used in this document................................3

   2 Introduction.....................................................3
   3 Terminology......................................................4
   4 General Requirements.............................................5
   5 ATM Service Encapsulation........................................5
   5.1 Length and Sequence Number ....................................6
      5.1.1 Setting the length field .................................7
      5.1.2 Processing the length field ..............................7
      5.1.3 Setting the sequence number ..............................8

      5.1.4 Processing the sequence number ...........................8
   6 ATM VCC Services.................................................9
   6.1 ATM VCC Cell Transport Service ................................9
      6.1.1 ATM OAM Cell Support ....................................11
   6.2 ATM VCC Frame Transport Service ..............................11
      6.2.1 Transparent AAL5 PDU Frame Service ......................12
        6.2.1.1 OAM Cell Support ....................................13

        6.2.1.2 Fragmentation .......................................14
           6.2.1.2.1 Procedures in the ATM-to-MPLS Direction ........14
           6.2.1.2.2 Procedures in the MPLS-to-ATM Direction ........15
      6.2.2 AAL5 SDU Frame Service ..................................15
        6.2.2.1 OAM Cell Support ....................................16
   7 ATM VPC Services................................................17
   7.1 ATM VPC Cell Transport Services ..............................17
      7.1.1 OAM Cell Support ........................................19

   8 ILMI support....................................................20
   9 QoS considerations..............................................20
   10 ATM Pseudo-Wire over MPLS specific requirements................22
   10.1 MPLS Transport Label ........................................23
   10.2 MPLS Pseudo Wire Label ......................................23
   11 ATM Pseudo-Wire over L2TP specific requirements................24
   11.1 L2TP Session ID .............................................25

   11.2 Cookie ......................................................25



Fischer, et al.            Expires August 2002                   [Page 2]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002

   12 ATM Pseudo-Wire over IP specific requirements..................25

   12.1 C, K, and S bits ............................................26
   12.2 Protocol Type field .........................................26
   12.3 Key Field ...................................................26
   12.4 GRE Sequence Number Field ...................................27
   13 Security Considerations........................................27
   14 Intellectual Property Disclaimer...............................27
   15 References.....................................................27
   16 Acknowledgments................................................28

   17 Authors' Addresses.............................................28


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


2 Introduction

   Many service providers have multiple service networks and the
   Operational Support System capabilities needed to support these
   existing service offerings.  Packet Switched Networks (PSNs) have
   the potential to reduce the complexity of a service provider's
   infrastructure by allowing virtually any existing digital service to
   be supported over a single networking infrastructure.

   The benefits of this model to a service provider are threefold:

     1. Leveraging of the existing systems and services to provide
     increased capacity from a packet switched core.

     2. Preserving existing network operational processes and
     procedures used to maintain the legacy services.

     3. Using the common packet switched network infrastructure to
     support both the core capacity requirements of existing services
     and the requirements of new services supported natively over the
     packet switched network.

   This draft describes a method to carry ATM services over IP, L2TP
   and MPLS.  It lists ATM specific requirements and provides
   encapsulation formats and semantics for connecting ATM edge networks
   through a core packet network using IP, L2TP or MPLS.  The
   techniques described in this draft will allow ATM service providers
   to take advantage of new technologies in the core in order to
   provide ATM multi-services.

   Figure 1, below displays the ATM services reference model.  This
   model is adapted from [6].


Fischer, et al.            Expires August 2002                   [Page 3]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002



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

     Customer                                                Customer
      Edge 1                                                  Edge 2

                   Figure 1: ATM Service Reference Model


3 Terminology

   Packet Switched Network - A Packet Switched Network (PSN) is a
   network using IP, MPLS or L2TP as the unit of switching.

   Pseudo Wire Emulation Edge to Edge - Pseudo Wire Emulation Edge to
   Edge (PWE3) is a mechanism that emulates the essential attributes of
   a service (such as a T1 leased line or Frame Relay) over a PSN.

   Customer Edge - A Customer Edge (CE) is a device where one end of an
   emulated service originates and terminates.  The CE is not aware
   that it is using an emulated service rather than a "real" service.

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

   Pseudo Wire - A Pseudo Wire (PW) is a connection between two PEs
   carried over a PSN.  The PE provides the adaptation between the CE
   and the PW.

   Pseudo Wire PDU - A Pseudo Wire PDU is a PDU sent on the PW that
   contains all of the data and control information necessary to
   provide the desired service.

   PSN Tunnel - A PSN Tunnel is a tunnel inside which multiple PWs can
   be nested so that they are transparent to core network devices.


Fischer, et al.            Expires August 2002                   [Page 4]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002

   Ingress _ The point where the ATM service is encapsulated into a
   Pseudo Wire PDU (ATM to PSN direction.)

   Egress - The point where the ATM service is decapsulated from a
   Pseudo Wire PDU (PSN to ATM direction.)

4 General Requirements

   For transport of an ATM service across a PSN, the PSN SHOULD be able
   to:

   1.   Carry all AAL types transparently.
   2.   Carry multiple ATM connections (VPCs and/or VCCs).
   3.   Support ATM OAM applications.
   4.   Transport Cell Loss Priority (CLP) and Payload Type Indicator
        (PTI) information from the ATM cell header.
   5.   Provide a mechanism to detect mis-ordering of ATM cells over
        the PSN.
   6.   Support traffic contracts and the QoS commitments made to the
        ATM connections (through the use of existing IETF defined Diff-
        Serv techniques).


5 ATM Service Encapsulation

   This section describes the general encapsulation format for ATM over
   PSN pseudo wires, such as IP, L2TP, or MPLS. The specifics
   pertaining to each packet technology are covered in later sections.

   Figure 2 provides a general format for encapsulation of ATM cells
   (or frames) into packets.


     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               PSN Transport Header (As Required)              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     Pseudo Wire Header                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Optional Length and Sequence Number       | ATM Specific  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ATM Service Payload                       |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 2: General format for ATM encapsulation over PSNs

   The PSN Transport Header depends on the packet technology: IP, L2TP
   or MPLS.  This header is used to transport the encapsulated ATM
   information through the packet switched core.  This header is always
   present if the Pseudo Wire is MPLS.


Fischer, et al.            Expires August 2002                   [Page 5]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002


   The Pseudo Wire Header depends on the packet technology: IP, L2TP or
   MPLS. It identifies a particular ATM service within the PSN tunnel.

   The Length and Sequence Number is inserted after the Pseudo Wire
   Header.  This field is optional.

   The ATM Specific Header is inserted before the ATM service payload.
   The ATM Specific Header contains control bits needed to carry the
   service.  These are defined in the ATM service descriptions below.
   The length of ATM specific header may not always be one octet.  It
   depends on the service type.

   The ATM payload octet group is the payload of the service that is
   being encapsulated.




5.1 Length and Sequence Number

   The length and sequence number are not required for all services.
   The control word is designed to satisfy these requirements.

       - Sequentiality may need to be preserved.
       - Small packets may need to be padded in order to be transmitted
         on a medium where the minimum transport unit is larger than
         the actual packet size.

   The one-octet Length indicates length of the packet payload that
   includes Sequence number length, the ATM specific header length and
   the payload length (i.e., Pseudo Wire PDU). The Length field is set
   to 0 by the ingress PE if not used and is ignored by the egress PE.

   If the Pseudo Wire traverses a network link that requires a minimum
   frame size such as Ethernet as a practical example, with a minimum
   frame size of 64 octets, then such links will apply padding to the
   Pseudo Wire PDU to reach its minimum frame size. In this case the
   length field MUST be set to the PDU length. A mechanism is required
   for the egress PE to detect and remove such padding.

   The Sequence Number is a 2-octet field that may be used to track
   packet order delivery. This field is set to 0 by the ingress PE if
   not used and is ignored by the egress PE. The sequence number space
   is a 16-bit, unsigned circular space. Processing of the sequence
   number field is OPTIONAL.

   In all cases the egress PE MUST be aware of whether the ingress PE
   will send the length and sequence number over a specific Pseudo
   Wire.
   This may be achieved using static configuration or using Pseudo Wire
   specific signaling.


Fischer, et al.            Expires August 2002                   [Page 6]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002




5.1.1 Setting the length field

   The length field is required to enable the egress PE to remove any
   padding that may have resulted if the pseudo-wire traversed a
   network link that enforces a minimum frame size (e.g. Ethernet).
   Ethernet applies padding to frames that are smaller than 64 bytes,
   where this includes a minimum of 18 bytes for the Ethernet header
   and trailer.

   The length field represents the size of the packet in bytes
   including the length, sequence number, ATM specific header and ATM
   service payload.  If the size of the packet is larger than can be
   represented by the length field, the field MUST be set to 0.  In
   addition, the length field MAY be set to 0 if the size of the packet
   prevents any padding from being applied.

   The AAL5 SDU Frame service is the only service that can generate
   packets smaller than the Ethernet minimum and MUST set the length
   field accordingly.  The length field MUST either be set to the size
   of the packet if the size is less than 46 bytes or to 0.

   All other cell or frame transport services MUST either follow the
   same procedure as the SDU frame service or always set the length
   field to 0 to indicate to the remote PE that no padding was applied.



5.1.2 Processing the length field

   When the length field is present the egress PE MUST follow these
   procedures:

     - If the length field of the packet is 0, then the packet does not
      require padding to be stripped.

     - Otherwise, the length field MUST be verified against the size of
      the packet as follows.

      - if the packet size is smaller than indicated by the length
        field, the packet MUST be discarded

      - otherwise, if the packet size is as indicated by the length
        field then the packet does not require padding to be stripped

        - otherwise, the packet is altered by removing the padding
          bytes from the end of the packet to match the size indicated
          by the length field.


Fischer, et al.            Expires August 2002                   [Page 7]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002


5.1.3 Setting the sequence number

   The following procedures SHOULD be used by the ingress PE if
   sequencing is desired for a given ATM service:

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

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



5.1.4 Processing the sequence number

   If the egress PE supports receive sequence number processing, then
   the following procedures SHOULD be used:

     When an ATM service is initially created, the "expected sequence
     number" associated with it MUST be initialized to 1.

     When a PDU is received on the Pseudo Wire associated with the ATM
     service, the sequence number SHOULD be processed as follows:

       - if the sequence number on the packet is 0, then the PDU passes
         the sequence number check

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

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

       - otherwise the PDU is out of order.

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

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

     Pseudo Wire PDUs that are received out of order MAY be dropped or
     reordered at the discretion of the egress PE.


Fischer, et al.            Expires August 2002                   [Page 8]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002

   If the egress PE does not support receive sequence number
   processing, then the sequence number field MAY be ignored.


6 ATM VCC Services

   This section defines three types of ATM VCC services that may be
   supported over the PSN: ATM cell, ATM AAL5 PDU, and ATM AAL5 SDU.




6.1 ATM VCC Cell Transport Service

   The VCC cell transport service is characterized by the mapping of a
   single ATM VCC (VPI/VCI) to a Pseudo Wire.  This service is fully
   transparent to the ATM Adaptation Layer.  The VCC cell transport
   service is MANDATORY.

   This service MUST use the following cell mode encapsulation:

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               PSN Transport Header (As Required)              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Pseudo Wire Header                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Optional Length and Sequence Number        |M|V|Res| PTI |C|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  |                   ATM Cell Payload ( 48 bytes )               |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 3: Single ATM VCC Cell Encapsulation

        * M (transport mode) bit

        Bit (M) of the control byte indicates whether the packet
        contains an ATM cell or a frame payload. If set to 0, the
        packet contains an ATM cell.  If set to 1, the PDU contains an
        AAL5 payload.  The ability to transport an ATM cell in the AAL5
        mode is intended to provide a means of enabling OAM
        functionality over the AAL5 VCC.

        * V (VCI present) bit

        Bit (V) of the control byte indicates whether the VCI field is
        present in the packet. If set to 1, the VCI field is present
        for the cell.  If set to 0, no VCI field is present. In the
        case of a VCC, the VCI field is not required.  For VPC, the VCI
        field is required and is transmitted with each cell.


Fischer, et al.            Expires August 2002                   [Page 9]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002


        * Reserved bits

        The reserved bits should be set to 0 at the transmitter and
        ignored upon reception.

        * PTI Bits

        The 3-bit Payload Type Identifier (PTI) incorporates ATM Layer
        PTI coding of the cell.  These bits are set to the value of the
        PTI of the encapsulated ATM cell.

        * C (CLP) Bit

        The Cell Loss Priority (CLP) field indicates CLP value of the
        encapsulated cell.


   For increased transport efficiency, the ingress PE SHOULD be able to
   encapsulate multiple ATM cells into a Pseudo Wire PDU.  The ingress
   and egress PE SHOULD agree to a maximum number of cells in a single
   Pseudo Wire PDU.  This agreement may be accomplished via a Pseudo
   Wire specific signaling mechanism or via static configuration.

   When multiple cells are encapsulated in the same PSN packet, the ATM
   control byte MUST be repeated for each cell.  This means that 49
   bytes are used to encapsulate each 53 byte ATM cell.

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               PSN Transport Header (As Required)              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Pseudo Wire Header                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Optional Length and Sequence Number         |M|V|Res| PTI |C|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  |                   ATM Cell Payload ( 48 bytes )               |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |M|V|Res| PTI |C|                                               |
  +-+-+-+-+-+-+-+-+                                               |
  |                   ATM Cell Payload ( 48 bytes )               |
  |                                                               |
  |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               |
  +-+-+-+-+-+-+-+-+

              Figure 4: Multiple ATM VCC Cell Encapsulation


Fischer, et al.            Expires August 2002                   [Page 10]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002


6.1.1 ATM OAM Cell Support

   When configured for a VCC cell relay service, both PE's SHOULD act
   as a VC switch in accordance with the OAM procedures defined in [5].

   The PEs MUST be able to pass the following OAM cells transparently:
       - F5 AIS (segment and end-to-end)
       - F5 RDI (segment and end-to-end)
       - F5 loopback (segment and end-to-end)
       - Resource Management
       - Performance Management
       - Continuity Check
       - Security

   The PEs SHALL use the ATM VCC cell mode encapsulation (Section 6.1)
   when passing an OAM cell.  The OAM cell MAY be encapsulated together
   with other user data cells if multiple cell encapsulation is used.

   The ingress PE SHOULD be able to generate an F5 AIS upon reception
   of a corresponding F4 AIS or lower layer defect (such as LOS).

   The egress PE SHOULD be able to generate an F5 AIS based on a PSN
   failure (such as a PSN tunnel failure or LOS on the PSN port).

   If the ingress PE cannot support the generation of OAM cells, it MAY
   notify the egress PE using a Pseudo Wire specific maintenance
   mechanism (to be defined).  For example, the ingress PE MAY withdraw
   the Pseudo Wire (VC label) associated with the service.  Upon
   receiving such a notification, the egress PE SHOULD generate the
   appropriate F5 AIS.



6.2 ATM VCC Frame Transport Service

   The frame mode services were designed specifically for better
   transport efficiency than the cell mode.  Two modes of AAL5 frame
   transport are available.  The transparent AAL5 PDU mode is intended
   to be more efficient than cell mode, yet still provide full ATM
   transparency including the correct sequencing of OAM cells on an
   AAL5 flow.  The payload AAL5 SDU mode is intended to provide more
   transport efficiency than the PDU mode while foregoing some ATM
   transparency.

   It is important that the PEs be able to efficiently switch between
   the frame and cell modes in order to support ATM OAM functions.

   The agreement to transport transparent AAL5 PDUs or payload AAL5
   SDUs may be accomplished via a Pseudo Wire specific signaling
   mechanism or via static configuration.


Fischer, et al.            Expires August 2002                   [Page 11]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002




6.2.1 Transparent AAL5 PDU Frame Service

   In this mode, the ingress PE encapsulates the entire CPCS-PDU
   including the PAD and trailer.

   This mode MAY support fragmentation in order to maintain OAM cell
   sequencing.

   Like the ATM AAL5 payload VCC service, the AAL5 transparent VCC
   service is intended to be more efficient than the VCC cell transport
   service.  However, the AAL5 transparent VCC service carries the
   entire AAL5 CPCS-PDU, including the PAD and trailer.  Note that the
   AAL5 CPCS-PDU is not processed _ i.e. an AAL5 frame with an invalid
   CRC or length field will be transported.  One reason for this is
   that there may be a security agent that has scrambled the ATM cell
   payloads that form the AAL5 CPCS-PDU.

   This service supports all OAM cell flows by using a fragmentation
   procedure that ensures that OAM cells are not repositioned in
   respect to AAL5 composite cells.

   The AAL5 transparent VCC service is OPTIONAL.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               PSN Transport Header (As Required)              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Pseudo Wire Header                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Optional Length and Sequence Number        |M|V|Res|Frg|E|C|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    +                             "                                 |
    |                        AAL5 CPCS-PDU                          |
    |                      (n * 48 bytes)                           |
    |                             "                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 5: AAL5 transparent service encapsulation

        The first octet following the Pseudo Wire Header carries
        control information.  The M, V, Res, and C bits are as defined
        earlier for VCC cell mode.

        * Frg (Fragmentation) Bits

        This field is used to support the fragmentation functionality
        described later in this section.

         - 11 Single Segment Message (Beginning and End of Message)


Fischer, et al.            Expires August 2002                   [Page 12]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002

         - 10 Beginning of Message
         - 00 Continuation of Message
         - 01 End of Message

        * E (EFCI) bit

        This field is used to convey the EFCI state of the ATM cells.
        The EFCI state is indicated in the middle bit of each ATM
        cell's PTI field.

           ATM-to-PSN direction (ingress): The EFCI field of the
           control byte is set to the EFCI state of the last cell of
           the AAL5 PDU or AAL5 fragment.

           PSN-to-ATM direction (egress): The EFCI state of all
           constituent cells of the AAL5 PDU or AAL5 fragment is set to
           the value of the EFCI field in the control byte.

        * C (CLP) bit

        This field is used to convey the cell loss priority of the ATM
        cells.

           ATM-to-PSN direction (ingress):  The CLP field of the
           control byte is set to 1 if any of the constituent cells of
           the AAL5 PDU or AAL5 fragment has its CLP bit set to 1;
           otherwise this field is set to 0.

           PSN-to-ATM direction (egress):  The CLP bit of all
           constituent cells for an AAL5 PDU or AAL5 fragment is set to
           the value of the CLP field in the control byte.

        The payload consists of the re-assembled AAL5 CPCS-PDU,
        including the AAL5 padding and trailer or the AAL5 fragment.




6.2.1.1 OAM Cell Support

   When configured for the AAL5 transparent VCC service, both PE's
   SHOULD act as a VC switch, in accordance with the OAM procedures
   defined in [5].

   The PEs SHOULD be able to pass the following OAM cells
   transparently:
       - F5 AIS (segment and end-to-end)
       - F5 RDI (segment and end-to-end)
       - F5 loopback (segment and end-to-end)
       - Resource Management
       - Performance Management
       - Continuity Check
       - Security


Fischer, et al.            Expires August 2002                   [Page 13]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002


   The PEs SHALL use the single ATM VCC cell mode encapsulation
   (Section 6.1) when passing an OAM cell.

   The ingress PE SHOULD be able to generate an F5 AIS upon reception
   of a corresponding F4 AIS or lower layer defect (such as LOS).

   The egress PE SHOULD be able to generate an F5 AIS based on a PSN
   failure (such as a PSN tunnel failure or LOS on the PSN port).

   If the ingress PE cannot support the generation of OAM cells, it MAY
   notify the egress PE using a Pseudo Wire specific maintenance
   mechanism to be defined.  For example, the ingress PE MAY withdraw
   the Pseudo Wire (VC label) associated with the service.  Upon
   receiving such a notification, the egress PE SHOULD generate the
   appropriate F5 AIS.




6.2.1.2 Fragmentation

   The ingress PE may not always be able to reassemble a full AAL5
   frame. This may be due to the AAL5 PDU exceeding the Pseudo Wire MTU
   or when OAM cells arrive during reassembly of the AAL5 PDU. In these
   cases, the AAL5 PDU shall be fragmented. In addition, fragmentation
   may be desirable to bound ATM cell delay.

   If no fragmentation occurs, then the fragmentation bits are set to
   11 (SSM, Single Segment Message).

   When fragmentation occurs, the procedures described in the following
   subsections shall be followed.


6.2.1.2.1 Procedures in the ATM-to-MPLS Direction

   The following procedures shall apply while fragmenting AAL5 PDUs:
       - Fragmentation shall always occur at cell boundaries within the
         AAL5 PDU.
       - For the first fragment, the FRG bits shall be set to 10 (BOM,
         Beginning Of Message).
       - For the last fragment, the FRG bits shall be set to 01 (EOM,
         End Of Message).
       - For all other fragments, the FRG bits shall be set to 00 (COM,
         Continuation Of Message).
       - The E and C bits of the fragment shall be set as defined
         earlier in section 6.


Fischer, et al.            Expires August 2002                   [Page 14]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002


6.2.1.2.2 Procedures in the MPLS-to-ATM Direction

   The following procedures shall apply:
       - The 3-bit PTI field of each ATM cell header is constructed as
         follows:
             + The most significant bit is set to 0, indicating a user
               data cell.
             + The middle bit is set to the E bit value of the
               fragment.
             + The least significant bit is set to 1 for the last ATM
               cell of a fragment where the FRG bits are 01 (EOM) or
               11(SSM); otherwise this bit is set to 0.
       - The C bit of each ATM cell header is set to the value of the C
         bit of the control byte in Figure 5.


6.2.2 AAL5 SDU Frame Service

   The AAL5 payload VCC service defines a mapping between the payload
   of an AAL5 VCC and a single Pseudo Wire.  This service is OPTIONAL.

   The AAL5 payload VCC service requires ATM segmentation and
   reassembly support on the PE.  Once the ingress PE reassembles the
   AAL5 CPCS-PDU, the PE discards the PAD and CPCS-PDU trailer and then
   inserts the resulting payload into a Pseudo Wire PDU.  Although any
   AAL5 PDU may be transported using the VCC cell relay service and
   cell mode encapsulation, the AAL5 payload VCC service is designed
   for better transport efficiency.

   The egress PE MUST regenerate the PAD and trailer before
   transmitting the AAL5 frame on the egress ATM port.

   This service does allow the transport of OAM and RM cells, but does
   not attempt to maintain the relative order of these cells with
   respect to the cells that comprise the AAL5 CPCS-PDU.  OAM cells
   that arrive during the reassembly of a single AAL5 CPCS-PDU are sent
   immediately on the Pseudo Wire, followed by the AAL5 payload.
   Therefore, the AAL5 payload VCC service may not be suitable for some
   ATM applications that require strict ordering of OAM cells (such as
   performance monitoring and security applications).

   The AAL5 payload service encapsulation is shown below.


Fischer, et al.            Expires August 2002                   [Page 15]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               PSN Transport Header (As Required)              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Pseudo Wire Header                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Optional Length and Sequence Number        |M|V|R|U|Frg|E|C|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             "                                 |
    |                        AAL5 SDU payload                       |
    |                             "                                 |
    |                             "                                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 6: AAL5 payload service encapsulation

        The first octet following the Pseudo Wire Header carries
        control information.  The M, V, R (reserved), E and C bits are
        as defined earlier for VCC cell mode.  Since fragmentation is
        not required, the fragmentation bits are set to 11 to indicate
        a complete frame.


       * U (UU Octet Command/Response) Bit

        When FRF.8.1 Frame Relay / ATM PVC Service Interworking traffic
        is being transported, the CPCS-UU Least Significant Bit (LSB)
        of the AAL5 CPCS-PDU may contain the Frame Relay C/R bit.
        The ingress PE device SHOULD copy this bit to the C bit of the
        control byte. The egress PE device SHOULD copy the C bit to the
        CPCS-UU Least Significant Bit (LSB) of the AAL5 payload.




6.2.2.1 OAM Cell Support

   Similar to the VCC cell relay service, both PEs SHOULD act as a VC
   switch in accordance with the OAM procedures defined in [5].

   The PEs SHOULD be able to pass the following OAM cells
   transparently:
       - F5 AIS (segment and end-to-end)
       - F5 RDI (segment and end-to-end)
       - F5 loopback (segment and end-to-end)
       - Resource Management
       - Continuity Check

   Because this service does not guarantee the original OAM cell
   position within the AAL5 composite cells, the following cell types
   are discarded by the ingress PE:
       - Performance Management


Fischer, et al.            Expires August 2002                   [Page 16]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002

       - Security

   The PEs SHALL use the single ATM VCC cell mode encapsulation
   (Section 6.1) when passing an OAM cell.

   The ingress PE SHOULD be able to generate an F5 AIS upon reception
   of a corresponding F4 AIS or lower layer defect (such as LOS).

   The egress PE SHOULD be able to generate an F5 AIS based on a PSN
   failure (such as a PSN tunnel failure or LOS on the PSN port).

   If the ingress PE cannot support the generation of OAM cells, it MAY
   notify the egress PE using a Pseudo Wire specific maintenance
   mechanism to be defined.  For example, the ingress PE MAY withdraw
   the Pseudo Wire (VC label) associated with the service.  Upon
   receiving such a notification, the egress PE SHOULD generate the
   appropriate F5 AIS.


7 ATM VPC Services

   The VPC service is defined by mapping a single VPC (VPI) to a Pseudo
   Wire.  As such it emulates as Virtual Path cross-connect across the
   PSN.  All VCCs belonging to the VPC are carried transparently by the
   VPC service.

   The egress PE may choose to apply a different VPI other than the one
   that arrived at the ingress PE.  The egress PE MUST choose the
   outgoing VPI based solely upon the Pseudo Wire header.  As a VPC
   service, the egress PE MUST NOT change the VCI field.




7.1 ATM VPC Cell Transport Services

   The ATM VPC cell transport service is OPTIONAL.

   This service MUST use the following cell mode encapsulation:


Fischer, et al.            Expires August 2002                   [Page 17]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               PSN Transport Header (As Required)              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Pseudo Wire Header                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Optional Length and Sequence Number        |M|V|Res| PTI |C|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |             VCI               |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
  |                                                               |
  |                   ATM Cell Payload ( 48 bytes )               |
  |                                                               |
  |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 7: Single Cell VPC Encapsulation

  The ATM control byte contains the same information as in the VCC
  encapsulation except for the VCI field.

        * VCI Bits

        The 16-bit Virtual Circuit Identifier (VCI) incorporates ATM
        Layer VCI value of the cell.


   For increased transport efficiency, the ingress PE SHOULD be able to
   encapsulate multiple ATM cells into a Pseudo Wire PDU.  The ingress
   and egress PE SHOULD agree to a maximum number of cells in a single
   Pseudo Wire PDU.  This agreement may be accomplished via a Pseudo
   Wire specific signaling mechanism or via static configuration.

   When multiple ATM cells are encapsulated in the same PSN packet, the
   ATM control byte MUST be repeated for each cell.  This means that 51
   bytes are used to encapsulate each 53 byte ATM cell.


Fischer, et al.            Expires August 2002                   [Page 18]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               PSN Transport Header (As Required)              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Pseudo Wire Header                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Optional Length and Sequence Number        |M|V|Res| PTI |C|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |             VCI               |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
  |                                                               |
  |                   ATM Cell Payload ( 48 bytes )               |
  |                                                               |
  |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                               |M|V|Res| PTI |C|        VCI    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   VCI         |                                               |
  +-+-+-+-+-+-+-+-+                                               |
  |                   ATM Cell Payload ( 48 bytes )               |
  |                                                               |
  |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               |
  +-+-+-+-+-+-+-+-+

                Figure 8: Multiple Cell VPC Encapsulation




7.1.1 OAM Cell Support

   When configured for a VPC cell relay service, both PE's SHOULD act
   as a VP cross-connect in accordance with the OAM procedures defined
   in [5].

   The PEs MUST be able to pass the following OAM cells transparently:
       - F4 AIS (segment and end-to-end)
       - F4 RDI (segment and end-to-end)
       - F4 loopback (segment and end-to-end)
       - F5 AIS (segment and end-to-end)
       - F5 RDI (segment and end-to-end)
       - F5 loopback (segment and end-to-end)
       - Resource Management
       - Performance Management
       - Continuity Check
       - Security

   The PEs SHALL use the ATM VPC cell encapsulation (Section 7.1) when
   passing an OAM cell.  The OAM cell MAY be encapsulated together with
   other user data cells if multiple cell encapsulation is used.


Fischer, et al.            Expires August 2002                   [Page 19]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002

   The ingress PE MUST be able to generate an F4 AIS upon reception of
   a lower layer defect (such as LOS).

   The egress PE SHOULD be able to generate an F4 AIS based on a PSN
   failure (such as a PSN tunnel failure or LOS on the PSN port).

   If the ingress PE cannot support the generation of OAM cells, it MAY
   notify the egress PE using a Pseudo Wire specific maintenance
   mechanism to be defined.  For example, the ingress PE MAY withdraw
   the Pseudo Wire (VC label) associated with the service.  Upon
   receiving such a notification, the egress PE SHOULD generate the
   appropriate F4 AIS.


8 ILMI support

   Integrated Local Management Interface (ILMI) typically is used in
   ATM networks for neighbor resource availability detection, address
   registration, auto-configuration, and loss of connectivity
   detection.  ILMI messages are sent as SNMP PDU's within ATM AAL5
   cells.

   A PE MAY provide an ATM ILMI to its attached CE. If the ingress PE
   receives an ILMI message indicating that the ATM service (VCC or
   VPC) is down, it MAY use a Pseudo Wire specific mechanism to notify
   the egress PE of the ATM service status.  For example, a PE using an
   MPLS based Pseudo Wire may withdraw its advertised VC label.

   When receiving such a notification, the egress PE MAY use ILMI to
   signal the ATM service status to its attached CE.


9 QoS considerations

   This section provides guidelines for the provision of QoS for the
   individual ATM PWs over the PSN.  The objective is to provide the
   ability to support the traffic contracts and the QoS commitments
   made to the ATM connections [8].  This section is informational and
   the provided guidelines SHOULD be treated as good practices and the
   mappings as examples only.

   When ATM PW service is configured over a PSN, each ATM service
   category SHOULD be mapped to a compatible class of service in the
   PSN network.  A compatible class of service maintains the integrity
   of the service end to end.  For example, the CBR service category
   SHOULD be mapped to a class of service with stringent loss and delay
   objectives.  If the PSN implements the IP Diff-Serv framework to
   provide QoS classes, a class of service based on the EF PHB is a
   good candidate.

   Furthermore, ATM service categories have support for multiple
   conformance definitions.  A conformance definition specifies the


Fischer, et al.            Expires August 2002                   [Page 20]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002

   conformance of cells of a connection at an interface, e.g., public
   UNI, in relation to the conformance algorithm and corresponding
   parameters specified in the connection traffic descriptor [15].  For
   example, the conformance definition specifies if the requested QoS
   parameters, e.g., CLR, apply to the aggregate CLP0+1 conforming cell
   flow or to the CLP0 conforming flow only.  Thus, the conformance
   definition SHOULD be respected in the selected PSN class of service.
   For example, a connection CLP1 cell flow in a VBR.3 conformance
   definition is treated as excess traffic in the ATM network and thus
   has no QoS guarantees associated with it. This flow SHOULD be
   provided a treatment no better than the treatment of the CLP0 cell
   flow in the PSN. This does not mean however that the PSN network
   should mirror the various conformance definitions of the ATM service
   categories.

   In the remainder of this section, it is assumed that the PSN
   implements IP Diff-Serv framework to provide QoS.

   All ATM traffic management functions specified in [15] are
   applicable for the ATM part of the ATM PW in the ingress PE and
   egress PE. In the ATM-to-PSN direction, each ATM connection MAY be
   policed and/or shaped to conform to its traffic descriptor in the
   ATM endpoint of the ATM PW in the PE.  Whenever allowed by the
   conformance definition, a non-conforming CLP0 cell may be turned
   into a CLP1 cell and becomes conforming.  Connection admission
   SHOULD be applied to make sure sufficient resources are available to
   carry the ATM PW over the transport LSP.  The mapping of ATM service
   category and conformance definition to the Diff-Serv PHB determines
   the outgoing PHB.  This is the PHB to be applied to the cells or
   packets of the ATM PW in the ingress PE and egress PE and inside the
   PSN.  The PSN transport header of the outgoing PSN packet SHOULD be
   marked to identify the selected PHB.  This consists of marking the
   DS field in the IP header in the case of IP PSN, or the EXP field in
   the transport shim header in the case of a MPLS PSN.

   Figure 9 provides an example of mapping ATM service category and
   conformance definition to a Diff-Serv PHB.


      ATM Service    Conformance     CLP      Diff-Serv   DSCP
      Category       Definition      Setting  PHB         Marking
      ----------------------------------------------------------------
      CBR            CBR.1           0/1      EF          101110
      rt-VBR         VBR.1           0/1      EF          101110
                     VBR.2/VBR.3     0        AF11        001010
                                     1        AF12        001100
      nrt-VBR        VBR.1           0/1      AF21        010010
                     VBR.2/VBR.3     0        AF21        010010
                                     1        AF22        010100
      ABR            ABR             0        AF31        011010
      UBR+MDCR       UBR.1/UBR.2     0/1      AF31        011010
      GFR            GFR.1/GFR.2     0        AF31        011010


Fischer, et al.            Expires August 2002                   [Page 21]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002

                                     1        AF32        011100
      UBR            UBR.1/UBR.2     0/1      DF          000000

         Figure 9: Example of ATM Service Category to PHB Mapping


   Note that an alternative mapping may not distinguish between the
   conformance definitions in a given ATM service category. In this
   case, the CLP0 and CLP1 flows of a ATM connection are provided with
   the same QoS in the PSN. As an example, all conformance definitions
   of the nrt-VBR service category MAY be mapped to the AF21 PHB in
   Figure 9.

   When the PSN is MPLS based, the selected PHB for the ATM PW is
   conveyed in different ways depending if the transport LSP is an L-
   LSP or an E-LSP [16].  In the case of an L-LSP, the PHB Scheduling
   Class is signaled at the transport LSP establishment and is
   therefore inferred from the transport label value.  The Drop
   Precedence of the individual PW packets is conveyed in the EXP field
   of the transport LSP shim header.  In the case of an E-LSP, the PHB
   is conveyed in the EXP field of the transport LSP shim header.  The
   actual values to be marked in the EXP field to reflect the example
   in Figure 9 is outside the scope of this document.

   In the presence of congestion, the PE MAY mark the EFCI bit and MAY
   perform selective cell discard based on CLP setting, if allowed by
   the conformance definition, and in accordance with [15].  The method
   used to transfer the CLP and EFCI information of the individual
   cells into the ATM specific field of the PW packet is described in
   details in sections 6 and 7.

   In the PSN-to-ATM direction, the ATM service category and
   conformance definition is obtained from the context accessed via the
   pseudo wire label of the ATM PW.  The information needed to
   reconstruct the ATM header, including the setting of the CLP and
   EFCI fields, for the individual cells is contained in the ATM
   specific information field of the PW packet.  The method used to
   determine the CLP and EFCI information of the individual cells from
   the ATM specific information field of the PW packet is described in
   details in sections 6 and 7.


10 ATM Pseudo-Wire over MPLS specific requirements

   Figure 10 provides a general format for interworking between ATM and
   MPLS.  The ATM information is encapsulated inside two MPLS labels as
   defined in [9].

   The Pseudo Wire Endpoint uses a unique MPLS label, the pseudo wire
   label, to identify each direction of an ATM connection.  This label
   allows the PWE to access context information for the connection.  As
   an example, the context may contain the information regarding


Fischer, et al.            Expires August 2002                   [Page 22]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002

   connection type such as VCC or VPC or VPI/VCI value that need to be
   inserted into the ATM cell header in the MPLS-to-ATM direction.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    MPLS Transport Label                       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   MPLS Pseudo Wire Label                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Optional Length and Sequence Number       | ATM Specific  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                     ATM Service Payload                       |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 10: Format for ATM PW over a MPLS PSN



10.1 MPLS Transport Label

   The 4-octet MPLS transport label identifies an LSP used to transport
   traffic between two ATM-MPLS pseudo wire endpoints.  This label is
   used to switch the transport LSP between core LSRs.

   Since an MPLS LSP is unidirectional, for the case of bi-directional
   traffic there will be two different pseudo wire LSPs, one for each
   direction of the connection.  These may have different label values.
   Setting of the EXP and TTL is for further study.  The S bit is set
   to 0 since this is not the last label in the MPLS label stack.




10.2 MPLS Pseudo Wire Label

   The 4-octet interworking label uniquely identifies one pseudo wire
   LSP, carried inside a MPLS transport LSP.  The pseudo wire label has
   the structure of a standard MPLS shim header.  More than one pseudo
   wire LSP may be supported by one MPLS transport LSP.  The pseudo
   wire endpoint provides the association between the ATM connection or
   the ATM port and MPLS LSP by means of the 20-bit label field of the
   pseudo wire LSP.  In this association, in the ATM-to-MPLS direction
   a mapping of the VCI/VPI of the ATM connection or the Port to the
   20-bit label is performed, while in the MPLS-to-ATM direction the
   20-bit label is mapped to a VPI/VCI of the ATM connection or to a
   Port. This association is signalled or provisioned between the two
   pseudo-wire endpoints.


   Since an MPLS LSP is unidirectional, for the case of bi-directional
   ATM VCCs there will be two different pseudo wire LSPs, one for each


Fischer, et al.            Expires August 2002                   [Page 23]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002

   direction of the connection.  These may have different label values.
   Setting of the EXP and TTL is for further study.  The S bit is set
   to 1 since this is the last label in the bottom of the MPLS stack.
   The pseudo wire label is not visible to the LSRs within the MPLS
   core network.



11 ATM Pseudo-Wire over L2TP specific requirements

   Figure 11 provides a general format for interworking between ATM and
   L2TP.  This draft refers to L2TPv3, or L2TP base, as described in
   [11].  L2TP base extends the original L2TP [12] to operate directly
   over a IP PSN and to further generalize the control procedures to
   carry any tunneled Layer 2 protocol other than PPP.  Any further
   reference to L2TP in this document assumes L2TPv3 or L2TP base as
   specified in [11].

   The ATM information is encapsulated inside a L2TP tunnel packet. The
   L2TP tunnel is setup over a IPv4 PSN. The IPv4 protocol in the IPv4
   header is set to 115 to indicate that the L2TP packet is
   encapsulated in a IPv4 packet [11]. Furthermore, L2TP can operate
   over IP or over UDP. The use of either mode is outside the scope of
   this document. The encapsulation format shown in Figure 11
   represents the common headers for carrying L2TP packet over UDP and
   IP. If UDP is used, additional header information is required and is
   defined in [11].

   The Pseudo Wire Endpoint uses a unique L2TP session ID to identify
   each direction of an ATM connection. This session ID is local to
   each PE and allows the PWE to identify each ATM PW in the L2TP
   tunnel in order to access context information for the ATM
   connection. As an example, the context may contain the information
   regarding connection type such as VCC or VPC or VPI/VCI value that
   need to be inserted into the ATM cell header in the L2TP-to-ATM
   direction. Multiple PWs with locally unique Session IDs at each PE
   can be multiplexed into a L2TP tunnel.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    L2TP Session ID                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                Cookie (optional, up to 64 bits)               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Optional Length and Sequence Number       | ATM Specific  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     ATM Service Payload                       |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 11: Format for ATM PW over a L2TP PSN


Fischer, et al.            Expires August 2002                   [Page 24]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002





11.1 L2TP Session ID

   This is 32-bit field containing a non-zero identifier for a session,
   or a PW in this case. L2TP sessions are named by identifiers that
   have local significance only at each PE [11].

   The same PW will be given different Session IDs by each PE for the
   life of the session. Multiple PWs with locally unique Session IDs at
   each PE can be multiplexed into a L2TP tunnel. When the L2TP control
   connection is used for session establishment, Session IDs are
   selected and exchanged as Local Session ID Attribute Value Pairs
   (AVPs) during the creation of a PW. A session ID of zero is reserved
   for the carriage of L2TP control messages [11].


11.2 Cookie

   The optional Cookie field contains a variable length (maximum 64
   bits), long word-aligned value used to check the association of a
   received packet with the PW identified by the Session ID. The Cookie
   MUST be configured with a random value utilizing all bits in the
   field [11].  The Cookie provides an additional level of guarantee,
   beyond the Session ID lookup, that a packet has been directed to the
   proper PW identified by the Session ID.

   When the L2TP control connection is used for PW session
   establishment, random Cookie values are selected and exchanged as
   Assigned Cookie AVPs during the creation of a PW.  The maximum size
   of the Cookie field is 64 bits.

12 ATM Pseudo-Wire over IP specific requirements

   Figure 12 provides a general format for carrying a ATM PW over a IP
   PSN. This is an alternative encapsulation to the one using L2TP, as
   described in Section 11. The GRE encapsulation is used as specified
   in [13] and [14]. The IPv4 protocol in the IPv4 header is set to 47
   to indicate that the GRE packet is encapsulated in a IPv4 packet
   [13].

   The ATM information is encapsulated inside a GRE/IP packet. The
   Pseudo Wire Endpoint uses a unique GRE Key to identify each
   direction of an ATM connection. As an example, the context may
   contain the information regarding connection type such as VCC or VPC
   or VPI/VCI value that need to be inserted into the ATM cell header
   in the IP-to-ATM direction. Multiple PWs with unique GRE Keys can be
   multiplexed into a GRE/IP tunnel.


Fischer, et al.            Expires August 2002                   [Page 25]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    IPv4 Header (N words)                      |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |C| |K|S| Reserved0       | Ver |         Protocol Type         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Key                                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 GRE Sequence Number (Optional)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Optional Length and Sequence Number       | ATM Specific  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     ATM Service Payload                       |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 12: Format for ATM PW over a IP PSN



12.1 C, K, and S bits

   The Checksum field in the GRE header is not required for carrying
   ATM PW over IP PSN. Therefore the C bit is set to zero.

   The Key field in the GRE header is always used (see Section 12.3).
   Therefore, the K bit is always set to 1.

   If the GRE Sequence Number field is used, then the value of the K
   bit is set to 1. Otherwise, its value is set to zero.



12.2 Protocol Type field

   The Protocol Type field is set to a number to be allocated by IEEE
   for the purpose of encapsulating ATM PW over GRE.



12.3 Key Field

   The Key field contains a four octet number which is inserted by the
   transmitting PE. The Key field is used by the receiving PE for
   identifying an individual ATM PW within a GRE/IP tunnel. Multiple
   PWs with unique GRE Keys can be multiplexed into a GRE/IP tunnel.
   The method by which the Key field value is negotiated between the
   transmitting PE and a receiving PE is further study.


Fischer, et al.            Expires August 2002                   [Page 26]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002


12.4 GRE Sequence Number Field

   If the Sequence Number Present bit is set to 1, then it indicates
   that the Sequence Number field is present in the GRE header.
   Otherwise, the Sequence Number field is not present in the GRE
   header. The use of the Sequence Number field MUST comply to [14].

   A specific ATM PWE network may choose to rely on the GRE protocol to
   track in-order delivery of ATM PW packets. Another way of tracking
   in-order delivery is to use the PW Sequence number field as
   explained in Section 5.1.


13 Security Considerations

   This draft does not introduce any new security considerations to IP,
   L2TP or MPLS.


14 Intellectual Property Disclaimer

   This document is being submitted for use in IETF standards
   discussions.


15 References

  [1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
       9, RFC 2026, October 1996.

  [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997

  [3]  "Frame Relay / ATM PVC Service Interworking Implementation
       Agreement (FRF.8.1)", Frame Relay Forum, 2000.

  [4]  "Frame Based ATM over SONET/SDH Transport (FAST)", af-fb-atm-
       0151.000, ATM Forum 2000.

  [5]  _B-ISDN operation and maintenance principles and functions_,
       ITU-T Recommendation I.610, February 1999.

  [6]  Xiao, X., et al., _Requirements for pseudo Wire Emulation Edge-
       to-Edge (PWE3)_, IETF draft-ietf-pwe3-requirements-02.txt, work
       in progress, November 2001.

  [7]  Martini, L., et al., "Encapsulation Methods for Transport of
       Layer 2 Frames Over IP and MPLS Networks", draft-martini-
       l2circuit-encap-mpls-04.txt, Work in Progress, November 2001.


Fischer, et al.            Expires August 2002                   [Page 27]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002

  [8]  Koleyni, G., et al., "Requirements and framework for ATM network
       interworking over MPLS", draft-koleyni-pwe3-atm-over-mpls-
       04.txt, Work in Progress, January 2002.

  [9]  Rosen, E., et al., "MPLS Label Stack Encoding", RFC 3032,
       January 2001.

  [10] _ATM-MPLS Network Interworking_, af-aic-0178.000, ATM Forum,
       2001.

  [11] Lau, J., et al., "Layer Two Tunneling Protocol "L2TP"", draft-
       ietf-l2tpext-l2tp-base-01.txt, Work in Progress, October 2001.

  [12] Townsley, W., et al., "Layer Two Tunneling Layer Two Tunneling
       Protocol (L2TP)", RFC 2661, August 1999.

  [13] Farinacci, D., et al., "Generic Routing Encapsulation (GRE)",
       RFC 2784, March 2000.

  [14] Dommety, G., et al., "Key and Sequence Number Extensions to
       GRE", RFC 2890, September 2000.

  [15] _Traffic Management Specification Version 4.1_, AF-TM-0121.000,
       ATM Forum, March 1999.

  [16] Le Faucheur, F., et al., "MPLS Support of Differentiated
       Services", draft-ietf-mpls-diff-ext-09.txt, Work in Progress,
       April 2001.


16 Acknowledgments

   The authors like to acknowledge the contribution to this work by
   Fred Kaudel and Dr. Khalid Ahmad.



17 Authors' Addresses

   John Fischer
   Alcatel
   600 March Rd
   Kanata, ON, Canada. K2K 2E6
   Email: john.fischer@alcatel.com

   Matthew Bocci
   Alcatel
   Voyager Place, Shoppenhangers Rd
   Maidenhead, Berks, UK SL6 2PJ
   Email: matthew.bocci@alcatel.co.uk

   Mustapha Aissaoui


Fischer, et al.            Expires August 2002                   [Page 28]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002

   Alcatel
   600 March Rd
   Kanata, ON, Canada. K2K 2E6
   Email: mustapha.aissaoui@alcatel.com

   Mina Azad
   Nortel Networks
   P O Box 3511, Station C
   Ottawa, ON, Canada K1Y 4H7
   Email:  mazad@nortelnetworks.com

   Ghassem Koleyni
   Nortel Networks
   P O Box 3511, Station C Ottawa, Ontario,
   K1Y 4H7 Canada
   Email: ghassem@nortelnetworks.com

   Adeel A. Siddiqui
   Cable & Wireless
   11700 Plaza America Drive
   Reston, Virginia 20190, USA
   Email: adeel.siddiqui@cwusa.com

   Anna Cui
   Advanced Fibre Communications
   3350 S.W. 148th Ave. Suite 300
   Miramar, FL 33027 USA
   Email: anna.cui@afc.com

   Jim Harford
   AdvanceNet Systems
   Research Triangle Park, NC
   E-mail: harford@atmware.com

   Dave Paw
   MCI WorldCom
   6929 N. Lakewood Ave.
   Tulsa, OK 74117
   Email: dave.paw@wcom.com

   Cheng C. Chen
   Network Systems Division,
   NEC America, Inc.
   6555 N. State Highway 161,
   Irving, TX 75039
   Email: cchen@necam.com

   Sat Sahota
   Telus Communications
   10020 100 Street
   Edmonton Alberta T5J 0N5
   Canada


Fischer, et al.            Expires August 2002                   [Page 29]



Internet Draft  draft-fischer-pwe3-atm-service-03.txt       March 2002

   Email: Sat.Sahota@telus.com

   Sushil Shelly
   Avici Systems
   Email: sshelly@avici.com

   Eric Letourneau
   Bell Canada
   700, De LaGauchetiere W.
   Montreal, Quebec H3B 4L1
   Email: eric.letourneau@bellnexxia.com

   Phong Khuu
   Turin Networks
   1415 N McDowell Blvd
   Petaluma, CA 94954 USA
   Email: pkhuu@turinnetworks.com

   Dave King
   General Dynamics
   Email: dave.king@gsc.gte.com

   Jeffery See
   General Dynamics
   Email: Jeffery.See@GD-CS.COM

   Aditya Sehgal
   SBC
   530 McCullough Rm 10 M 03
   San Antonio, TX 78215
   Email: sehgal@tri.sbc.com

   Sohel Q. Khan
   Sprint
   7171 W 95th Street
   Overland Park, KS 66212
   Email: sohel.khan@mail.sprint.com