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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 4717

Network Working Group                                       Luca Martini
Internet Draft                              Level 3 Communications, LLC.
Expiration Date: April 2003

Jeremy Brayley                                             Matthew Bocci
Laurel Networks, Inc.                                            Alcatel

Eric C. Rosen                                            Ghassem Koleyni
Cisco Systems, Inc.                                     Nortel Networks.

                                                            October 2002


Encapsulation Methods for Transport of ATM Cells/Frame Over IP and MPLS Networks


                    draft-ietf-pwe3-atm-encap-00.txt

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

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

Abstract

   A framework for providing various Layer 1 and Layer 2 services over a
   Packet Switched Network has been described in [3]. This draft
   provides encapsulation formats and guidelines for transporting a
   variety of ATM services over a PSN. This draft merges three internet
   drafts previously submitted to the PWE3 working group. These are:
   draft-martini-atm-encap-mpls-01.txt; draft-koleyni-pwe3-app-cell-
   over-psn-01.txt; and draft-bocci-pwe3-app-frame-over-psn-00.txt. This
   draft describes two methods of ATM cell encapsulation, one-to-one



Martini, et al.                                                 [Page 1]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


   mode based on draft-koleyni-pwe3-app-cell-over-psn-01.txt and n-to-
   one mode (n=>1) based on draft-martini-atm-encap-mpls-01.txt. This
   draft describes two methods of AAL5 encapsulation, PDU mode based on
   draft-bocci-pwe3-app-frame-over-psn-00.txt and SDU mode based on
   draft-martini-atm-encap-mpls-01.txt. It includes an applicability
   statement for each service along with ATM OAM handling and QoS
   guidelines. Please note that this section will change in the next
   revisions.











































Martini, et al.                                                 [Page 2]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002




Table of Contents

    1      Specification of Requirements  ..........................   4
    2      Introduction  ...........................................   4
    3      Terminology  ............................................   5
    4      General encapsulation method  ...........................   6
    4.1    The Control Word  .......................................   6
    4.1.1  Setting the sequence number  ............................   8
    4.1.2  Processing the sequence number  .........................   8
    4.2    MTU Requirements  .......................................   9
    5      ATM  ....................................................   9
    6      ATM one-to-one Cell Mode  ...............................  10
    6.1    Applicability  ..........................................  10
    6.2    Implementation and deployment considerations  ...........  11
    6.3    Limitations  ............................................  11
    6.4    ATM one-to-one Service Encapsulation  ...................  11
    6.5    Length and Sequence Number  .............................  12
    6.5.1  Setting the length field  ...............................  13
    6.5.2  Processing the length field  ............................  13
    6.6    ATM VCC Services  .......................................  13
    6.7    ATM VCC Cell Transport Service  .........................  14
    6.7.1  ATM OAM Cell Support  ...................................  15
    6.8    ATM VPC Services  .......................................  16
    6.8.1  ATM VPC Cell Transport Services  ........................  16
    6.8.2  OAM Cell Support  .......................................  18
    7      ATM n-to-one Cell Mode  .................................  19
    7.1    ATM n-to-one Service Encapsulation  .....................  19
    7.2    ATM OAM Cell Support  ...................................  22
    7.3    CLP bit to Quality of Service mapping  ..................  22
    7.4    Applicability Statement for n-to-one mode  ..............  22
    7.5    Review of header information  ...........................  23
    7.6    MPLS Shim S Bit Value  ..................................  24
    7.7    MPLS Shim TTL Values  ...................................  24
    8      ATM AAL5 CPCS-SDU Mode  .................................  24
    8.1    Applicability Statement  ................................  24
    8.2    Transparent AAL5 SDU Frame Encapsulation  ...............  25
    8.3    ATM OAM Cell Support  ...................................  26
    9      AAL5 PDU frame mode  ....................................  27
    9.1    Applicability  ..........................................  27
    9.1.1  Implementation and deployment considerations  ...........  29
    9.1.2  Limitations  ............................................  29
    9.2    Transparent AAL5 PDU Frame encapsulation  ...............  29
    9.3    ATM OAM Cell Support  ...................................  31
    9.4    Fragmentation  ..........................................  32
    9.4.1  Procedures in the ATM-to-MPLS Direction  ................  32
    9.4.2  Procedures in the MPLS-to-ATM Direction  ................  32



Martini, et al.                                                 [Page 3]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


   10      Security Considerations  ................................  33
   11      Intellectual Property Disclaimer  .......................  33
   12      References  .............................................  33
   13      Author Information  .....................................  34





1. Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119


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 providers
   infrastructure by allowing virtually any existing digital service to
   be supported over a single networking infrastructure.  The benefit of
   this model to a service provider is threefold:
     - Leveraging of the existing systems and services to provide
       increased capacity from a packet switched core.
     - Preserving existing network operational processes and procedures
       used to maintain the legacy services.
     - 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 [3].







Martini, et al.                                                 [Page 4]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


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

                      Figure 1: ATM Service Reference Model

       QoS related issues are not discussed in this draft.  This draft
       describes two methods of ATM cell encapsulation, one-to-one mode
       and n-to-one mode.  This draft describes two methods of AAL5
       encapsulation, PDU mode and SDU mode.


3. Terminology

   One-to-one mode: The One-to-one mode specifies an encapsulation
   method which maps one ATM VCC (or one ATM VPC) to one PSN Tunnel.

   N-to-one mode (N >= 1): The N-to-one mode specifies an encapsulation
   method which maps one or more ATM VCCs (or one or more ATM VPCs) to
   one  PSN tunnel.

   Packet Switched Network - A Packet Switched Network (PSN) is an IP or
   MPLS network.

   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.




Martini, et al.                                                 [Page 5]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


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

   PSN Bound - The traffic direction where information from a CE is
   adapted to a PW, and PW-PDUs are sent into the PSN. CE Bound - The
   traffic direction where PW-PDUs are received on a PW from the PSN,
   re-converted back in the emulated service, and sent out to a CE.

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

   CTD    Cell Transfer Delay MTU    Maximum Transfer Unit OAM
   Operations, Administration, and Maintenance.  PVC    Permanent
   Virtual Connection. An ATM connection that is
          provisioned via a network management interface.  The
          connection is not signalled.  VCC    Virtual Circuit
   Connection.  An ATM connection that is
          switched based on the cell header's VCI.  VPC    Virtual Path
   Connection.  An ATM connection that is switched
          based on the cell header's VPI.


4. General encapsulation method

4.1. The Control Word

   There are three requirements that may need to be satisfied when
   transporting layer 2 protocols over an IP or MPLS backbone:

        -i. Sequentiality may need to be preserved.
       -ii. 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.
      -iii. Control bits carried in the header of the layer 2 frame may
            need to be transported.

   The control word defined here addresses all three of these



Martini, et al.                                                 [Page 6]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


   requirements. For some protocols this word is REQUIRED, and for
   others OPTIONAL.  For protocols where the control word is OPTIONAL
   implementations MUST support sending no control word, and MAY support
   sending a control word.

   In all cases the egress router must be aware of whether the ingress
   router will send a control word over a specific virtual circuit.
   This may be achieved by configuration of the routers, or by
   signaling, for example as defined in [1].

   The control word is defined as follows:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Rsvd  | Flags |Res|   Length  |     Sequence Number           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In the above diagram the first 4 bits are reserved for future use.
   They MUST be set to 0 when transmitting, and MUST be ignored upon
   receipt.

   The next 4 bits provide space for carrying protocol specific flags.
   These are defined in the protocol-specific details below.

   These bits are reserved and MUST be set to 0 upon transmission and
   ignored upon reception.

   The next 6 bits provide a length field, which is used as follows: If
   the packet's length (defined as the length of the layer 2 payload
   plus the length of the control word) is less than 64 bytes, the
   length field MUST be set to the packet's length. Otherwise the length
   field MUST be set to zero. The value of the length field, if non-
   zero, can be used to remove any padding. When the packet reaches the
   service provider's egress router, it may be desirable to remove the
   padding before forwarding the packet.

   The next 16 bits provide a sequence number that can be used to
   guarantee ordered packet delivery. The processing of the sequence
   number field is OPTIONAL.

   The sequence number space is a 16 bit, unsigned circular space. The
   sequence number value 0 is used to indicate an unsequenced packet.









Martini, et al.                                                 [Page 7]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


4.1.1. Setting the sequence number

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

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

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


4.1.2. Processing the sequence number

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

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

   When a packet is received on that emulated VC, the sequence number
   should be processed as follows:

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

     - 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 a packet passes the sequence number check, or is in order then, it
   can be delivered immediately. If the packet is in order, then the
   expected sequence number should be set using the algorithm:

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



Martini, et al.                                                 [Page 8]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


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

   If a router PE2 does not support receive sequence number processing,
   then the sequence number field MAY be ignored.


4.2. MTU Requirements

   The network MUST be configured with an MTU that is sufficient to
   transport the largest encapsulation frames.  If MPLS is used as the
   tunneling protocol, for example, this is likely to be 12 or more
   bytes greater than the largest frame size.  Other tunneling protocols
   may have longer headers and require larger MTUs.  If the ingress
   router determines that an encapsulated layer 2 PDU exceeds the MTU of
   the tunnel through which it must be sent, the PDU MUST be dropped. If
   an egress router receives an encapsulated layer 2 PDU whose payload
   length (i.e., the length of the PDU itself without any of the
   encapsulation headers), exceeds the MTU of the destination layer 2
   interface, the PDU MUST be dropped.


5. ATM

   This Draft defines two methods for encapsulation of ATM cells,
   namely, One-to-one mode and N-to-one mode.

   The One-to-one mode specifies an encapsulation method that maps one
   ATM VCC or one ATM VPC to one Pseudo-Wire. Two formats are specified:
   one for transporting a VCC on a tunnel and another for transporting a
   VPC on a tunnel. In the VCC format, the VPI/VCI is not included. In
   the VPC format, the VPI is not included. Cells from one VCC or one
   VPC may be concatenated.

   The N-to-one mode (N >= 1) specifies an encapsulation method that
   maps one or more ATM VCCs (or one or more ATM VPCs) to one  Pseudo-
   Wire. One format is used for both the VCC or VPC mapping to the
   tunnel. The 4-octet ATM header is unaltered in the encapsulation,
   thus the VPI/VCI is always present. Cells from one or more VCCs (or
   one or more VPCs) may be concatenated.

   Furthermore different encapsulations are supported for ATM AAL5
   transport:  one for ATM AAL5 SDUs, and and another for ATM AAL5 PDUs.








Martini, et al.                                                 [Page 9]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


6. ATM one-to-one Cell Mode

   The One-to-one mode described in this Draft allows a service provider
   to offer an ATM PVC or SVC based service across a network. The
   encapsulation allows one ATM VCC or VPC to be carried within a single
   Pseudo-Wire.


6.1. Applicability

   The primary application of one-to-one ATM cell encapsulation over PSN
   is the transparent carriage of ATM layer services over a PSN. An ATM
   layer service is the transfer of ATM cells over a VCC or a VPC
   between communicating upper layer entities. The nature of the
   service, as defined by the ATM service category [5] or ATM transfer
   capability [6], should be preserved. To provide this, the basic
   requirement of the ATM-PSN interworking function is to map the ATM
   cells belonging to either VCC or VPC, together with any related OAM
   and protocol control information into a PW.

   Two network applications that utilize the cell mode encapsulation
   are:

     a. The transport of multiservice ATM over a packet core network.
        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:
             -i. Leveraging of the existing systems and services to
                 provide increased capacity from a packet switched core.
            -ii. Preserving existing network operational processes and
                 procedures used to maintain the legacy services.
           -iii. 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.

     b. L2 VPN service over a PSN infrastructure. In this case, VPN
        sites are connected through ATM VCCs or VPCs, as in today's L2
        VPNs. The basic cell encapsulation allows the VPN service
        provider to transparently extend this L2 connectivity over its
        PSN while still providing the contracted SLA with the VPN
        customer. The advantage is for the service provider to combine
        L2 and L3 services over the same PSN.



Martini, et al.                                                [Page 10]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


   Figure 1 shows the reference model for carrying ATM services over a
   PSN.  An ATM VCC or VPC is carried over a PW. The PW corresponding to
   any VCC or VPC may be further tunneled in a transport PSN tunnel to
   achieve multiplexing gain and bandwidth efficiency.

   ATM over PSN service provides end users with the same quality of
   service on any given VPC or VCC as per the QoS commitments in the ATM
   service traffic contract.

   Concatenation of ATM cells belonging to a VCC or a VPC provides added
   bandwidth efficiency while preserving the specific information
   (CLP/PTI) of each cell.


6.2. Implementation and deployment considerations

   Although the Single ATM cell encapsulation provides the simplest way
   for encapsulating ATM cells within a single MPLS packet, it lacks
   bandwidth efficiency. This can be improved substantially by the use
   of the procedures enabling cells from any given VCC or VPC to be
   concatenated within the corresponding ATM PW.


6.3. Limitations

   Cell encapsulation only supports point-to-point LSPs. Multi-point-
   to-point and point-to-multi-point are for further study (FFS).

   When PSN is MPLS network, to have bi-directional connectivity, as
   required in ATM, two LSPs should be configured, one for each
   direction (ATM-to-MPLS and MPLS-to-ATM) of the ATM connection.

   The number of concatenated ATM cells is limited by the MTU (Maximum
   Transfer Unit) size and the cell transfer delay (CTD) and cell delay
   variation (CDV) objectives.


6.4. ATM one-to-one 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 into
   packets.







Martini, et al.                                                [Page 11]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 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       | ATM Specific  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ATM Service Payload                       |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2: General format for one-to-one mode 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.

   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.


6.5. Length and Sequence Number

   The length and sequence number are not required for all services.
   Length and sequence number are 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, length of the length field, 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



Martini, et al.                                                [Page 12]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


   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.

   Treatment of the sequence number is according to previous sections
   "Setting the sequence number", and "Processing the sequence number".

   Length field is not required for the cell mode.


6.5.1. Setting the length field

   All cell transport services MUST always set the length field to 0 to
   indicate to the remote PE that no padding was applied.

6.5.2. Processing the length field

   Since length field is not used for cell mode, no processing is
   required.


6.6. ATM VCC Services

   This section defines ATM cell VCC services that may be supported over
   the PSN.










Martini, et al.                                                [Page 13]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


6.7. 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 single cell
   transport service is OPTIONAL.  This service MUST use the following
   encapsulation format:
    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.

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





Martini, et al.                                                [Page 14]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


     * 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


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

   The PEs MUST be able to pass the following OAM cells transparently:






Martini, et al.                                                [Page 15]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


     - 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 one-to-one cell mode encapsulation 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.8. 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.


6.8.1. ATM VPC Cell Transport Services

   The ATM VPC cell transport service is OPTIONAL.

   This service MUST use the following cell mode encapsulation:







Martini, et al.                                                [Page 16]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 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 5: 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.













Martini, et al.                                                [Page 17]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 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 6: Multiple Cell VPC Encapsulation


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

   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 one-to-one cell encapsulation when
   passing an OAM cell.  The OAM cell MAY be encapsulated together with



Martini, et al.                                                [Page 18]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


   other user data cells if multiple cell encapsulation is used.

   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.


7. ATM n-to-one Cell Mode

   The N-to-one mode (N >= 1) described in this Draft allows a service
   provider to offer an ATM PVC or SVC based service across a network.
   The encapsulation allows multiple ATM VCCs or VPCs to be carried
   within a single PSN tunnel. A service provider may also use N-to-one
   mode to provision either one VCC or one VPC on a tunnel. This section
   defines the VCC and VPC cell relay services over a PSN and their
   applicability.


7.1. ATM n-to-one Service Encapsulation

   This section describes the general encapsulation format for ATM over
   PSN pseudo wires.

    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                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ATM Control Word                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ATM Service Payload                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 7: General format for ATM encapsulation over PSNs

   The PSN Transport Header depends on the particular tunneling
   technology in use (L2TP or MPLS). This header is used to transport



Martini, et al.                                                [Page 19]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


   the encapsulated ATM information through the packet switched core.

   The Pseudo Wire Header identifies a particular ATM service on a
   tunnel.  Non-ATM services may also be carried on the PSN tunnel.

   The ATM Control Word is inserted before the ATM service payload. It
   may contain a length and sequence number in addition to certain
   control bits needed to carry the service.

   The ATM Service Payload is specific to the service being offered via
   the Pseudo Wire. It is defined in the following sections.

   In this encapsulation mode ATM cells are transported individually
   without a SAR process. This is the only REQUIRED encapsulation for
   ATM.  The ATM cell encapsulation consists of an OPTIONAL control
   word, and one or more ATM cells - each consisting of a 4 byte ATM
   cell header and the 48 byte ATM cell payload. This ATM cell header is
   defined as in the FAST encapsulation [4] section 3.1.1, but without
   the trailer byte. The length of each frame, without the encapsulation
   headers, is a multiple of 52 bytes long. The maximum number of ATM
   cells that can be fitted in a frame, in this fashion, is limited only
   by the network MTU and by the ability of the egress router to process
   them. The ingress router MUST NOT send more cells than the egress
   router is willing to receive. The number of cells that the egress
   router is willing to receive may either be configured in the ingress
   router or may be signaled, for example using the methods described in
   [1]. The number of cells encapsulated in a particular frame can be
   inferred by the frame length. The control word is OPTIONAL. If the
   control word is used then the flag bits in the control word are not
   used, and MUST be set to 0 when transmitting, and MUST be ignored
   upon receipt.

   The EFCI and CLP bits are carried across the network in the ATM cell
   header.  The edge routers that implement this document MAY, when
   either adding or removing the encapsulation described herein, change
   the EFCI bit from zero to one in order to reflect congestion in the
   network that is known to the edge router, and the CLP bit from zero
   to one to reflect marking from edge policing of the ATM Sustained
   Cell Rate. The EFCI and CLP bits SHOULD NOT be changed from one to
   zero.

   This diagram illustrates an encapsulation of two ATM cells:









Martini, et al.                                                [Page 20]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Control word ( Optional )                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          VPI          |              VCI              | PTI |C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  ATM Payload ( 48 bytes )                     |
   |                          "                                    |
   |                          "                                    |
   |                          "                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          VPI          |              VCI              | PTI |C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  ATM Payload ( 48 bytes )                     |
   |                          "                                    |
   |                          "                                    |
   |                          "                                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 8: Multiple Cell ATM Encapsulation

     * VPI

       The ingress router MUST copy the VPI field from the incoming cell
       into this field.  For particular emulated VCs, the egress router
       MAY generate a new VPI and ignore the VPI contained in this
       field.

     * VCI

       The ingress router MUST copy the VCI field from the incoming ATM
       cell header into this field.  For particular emulated VCs, the
       egress router MAY generate a new VCI.

     * PTI & CLP ( C bit )

       The PTI and CLP fields are the PTI and CLP fields of the incoming
       ATM cells.  The cell headers of the cells within the packet are
       the ATM headers (without HEC) of the incoming cell.











Martini, et al.                                                [Page 21]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


7.2. ATM OAM Cell Support

   OAM cells MAY be transported on the VC LSP. An egress router that
   does not support transport of OAM cells MUST discard frames that
   contain an ATM cell with the high-order bit of the PTI field set to
   1. A router that supports transport of OAM cells MUST follow the
   procedures outlined in [4] section 8 for mode 0 only, in addition to
   the applicable procedures specified in [1].


7.3. CLP bit to Quality of Service mapping

   The ingress router MAY consider the CLP bit when determining the
   value to be placed in the Quality of Service fields (e.g. the EXP
   fields of the MPLS label stack) of the encapsulating protocol. This
   gives the network visibility of the CLP bit.  Note however that cells
   from the same VC MUST NOT be reordered.


7.4. Applicability Statement for n-to-one mode

   The N-to-one cell relay encapsulation described in this document
   allows a service provider to offer a PVC/PVP or SVC/SVP based VCC/VPC
   cell relay service across an IP or MPLS PSN.

   The encapsulation allows multiple VCCs/VPCs to be carried within a
   single PSN tunnel. This does not preclude the possibility that a
   service provider may wish to provision a single VCC to a PSN tunnel
   in order to satisfy QoS or restoration requirements.

   The encapsulation also supports the binding of multiple VCCs/VPCs to
   a single Pseudo Wire.  This capability is useful in order to make
   more efficient use of the PW demultiplexing header space as well as
   to ease provisioning of the VCC/VPC services.

   The VCC/VPC cell relay service has the following attributes:
        -i. Supports all ATM Adaptation Layers Types.
       -ii. Non-terminating OAM/Admin cells are transported among the
            user cells in the same order as they are received. This
            requirement enables the use of various performance
            management and security applications.
      -iii. In order to gain transport efficiency on the PSN, multiple
            cells may be encapsulated in a single PW PDU. This process
            is called cell concatenation .  How many cells to insert or
            how long to wait for cell arrival before sending a PW PDU is
            an implementation decision. Like any SAR scheme, cell
            concatenation introduces latency to a cell relay service.




Martini, et al.                                                [Page 22]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


       -iv. The CLP bit from each cell may be mapped to a corresponding
            marking on the PW PDU. This allows the drop precedence to be
            preserved across the PSN.

   The VCC cell relay service encapsulation has the following drawbacks:
        -i. There is no currently defined method to translate the
            forward congestion indication (EFCI) to a corresponding
            function in the PSN. Nor is there a way to translate PSN
            congestion to the EFCI upon transmission by the egress PE.
       -ii. The ATM cell header checksum can correct a single bit error
            in the cell header. Analogous functionality does not exist
            in most PSNs. A single bit error in a PW PDU will most
            likely cause the packet to be dropped due to a L2 FCS
            failure.
      -iii. There is no currently defined method to support EPD/PPD on
            the PSN.
       -iv. There are currently no OAM mechanisms defined for the PSN
            like those defined for ATM. Therefore the methods for the
            detection/consequent-actions of failures in the PSN are not
            specified. This also means that QoS/availability metrics
            cannot be specified for the PSN.


7.5. Review of header information

   The review of the ATM header at PE devices is OPTIONAL. While
   information carried in the cell encapsulation is carried
   transparently through the PSN, and does not require a SAR function,
   inspection of the header information provides a mechanism to map
   characteristics of the transported information to the PSN. Each cell
   is inspected at the PE device and service requirements are mapped
   accordingly in the packet based network.

   It is through this examination that control mechanisms such as
   congestion management can be translated for transport in the PSN.
   This capability could also be used to support the mapping of ATM QoS
   to CoS.

   Similar mechanisms can be used to map ATM header information to other
   type of PSN tunnel PDU headers.











Martini, et al.                                                [Page 23]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


7.6. MPLS Shim S Bit Value

   The ingress LSR, PE1, MUST set the S bit of the VC label to a value
   of 1 to denote that the VC label is at the bottom of the stack.


7.7. MPLS Shim TTL Values

   The ingress LSR, PE1, SHOULD set the TTL field of the VC label to a
   value of 2.


8. ATM AAL5 CPCS-SDU Mode

   The AAL5 payload VCC service defines a mapping between the payload of
   an AAL5 VCC and a single Pseudo Wire.  The AAL5 payload VCC service
   requires ATM segmentation and reassembly support on the PE.

   The AAL5 payload CPCS-SDU service is OPTIONAL.

   Even the smallest TCP packet requires two ATM cells when sent over
   AAL5 on a native ATM device. It is desirable to avoid this padding on
   the Pseudo Wire.  Therefore, once the ingress PE reassembles the AAL5
   CPCS-PDU, the PE discards the PAD and CPCS-PDU trailer then inserts
   the resulting payload into a Pseudo Wire PDU.

   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 will not be suitable for ATM
   applications that require strict ordering of OAM cells (such as
   performance monitoring and security applications).



8.1. Applicability Statement

   It is possible to carry any ATM service using the VCC and VPC cell
   relay encapsulations defined in the previous section. After all, ATM
   is inherently a cell-based technology. However, a vast majority of
   the data carried on ATM networks is frame based and therefore uses
   AAL5. For example, most Frame Relay services are provided on an ATM
   backbone using AAL5 and of course AAL5 is used to carry IP PDUs



Martini, et al.                                                [Page 24]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


   between ATM attached routers.

   The AAL5-SDU service is designed with this reality in mind. The
   encapsulation defined below is more efficient for small AAL5 SDUs
   than the VCC cell relay service. In turn it presents a more efficient
   alternative to the cell relay service when carrying RFC 2684
   encapsulated IP PDUs across a PSN.

   The AAL5-SDU encapsulation requires Segmentation and Reassembly on
   the PE-CE ATM interface. This SAR function is provided by common
   off-the-shelf hardware components. Once reassembled, the AAL5-SDU is
   carried via a Pseudo Wire to the egress PE. Herein lies another
   advantage of the AAL5-SDU encapsulation. Using the AAL5-SDU mode the
   egress PE does not have to perform reassembly itself on the PSN
   facing interface when converting to a frame based medium. For
   example, the AAL5-SDU mode allows easier extraction of an IP PDU for
   processing, or conversion to a different frame technology such as
   Frame Relay or Ethernet. When using the cell relay service to provide
   this same functionality, the egress PE must reassemble cells arriving
   over a PSN tunnel.


8.2. Transparent AAL5 SDU Frame Encapsulation

   The AAL5 CPCS-SDU is prepended by the following 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Res  |T|E|C|U|Res|  Length   |   Sequence Number (Optional)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              "                                |
   |                     ATM cell or AAL5 CPCS-SDU                 |
   |                              "                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 9: AAL5 CPCS-SDU Encapsulation

   The AAL5 payload service encapsulation requires the ATM control word.
   The Flag bits are described below.
     * Res (Reserved) These bits are reserved and MUST be set to 0 upon
       transmission and ignored upon reception.

     * T (transport type) bit

       Bit (T) of the control word indicates whether the packet contains
       an ATM admin cell or an AAL5 payload. If T = 1, the packet
       contains an ATM admin cell, encapsulated according to the VCC



Martini, et al.                                                [Page 25]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


       cell relay encapsulation, figure 8.  If not set, the PDU contains
       an AAL5 payload. The ability to transport an ATM cell in the AAL5
       SDU mode is intended to provide a means of enabling
       administrative functionality over the AAL5 VCC (though it does
       not endeavor to preserve user-cell and admin-cell
       arrival/transport ordering).

     * E ( EFCI ) Bit

       The ingress router, PE1, SHOULD set this bit to 1 if the EFCI bit
       of the final cell of those that transported the AAL5 CPCS-SDU is
       set to 1, or if the EFCI bit of the single ATM cell to be
       transported in the  packet is set to 1.  Otherwise this bit
       SHOULD be set to 0. The egress router, PE2, SHOULD set the EFCI
       bit of all cells that transport the AAL5 CPCS-SDU to the value
       contained in this field.

     * C ( CLP ) Bit

       The ingress router, PE1, SHOULD set this bit to 1 if the CLP bit
       of any of the ATM cells that transported the AAL5 CPCS-SDU is set
       to 1, or if the CLP bit of the single ATM cell to be transported
       in the packet is set to 1.  Otherwise this bit SHOULD be set to
       0. The egress router, PE2, SHOULD set the CLP bit of all cells
       that transport the AAL5 CPCS-SDU to the value contained in this
       field.

     * U ( Command / Response Field ) Bit

       When FRF.8.1 Frame Relay / ATM PVC Service Interworking [3]
       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 router, PE1, SHOULD copy this bit to the U bit of the
       control word. The egress router, PE2, SHOULD copy the U bit to
       the CPCS-UU Least Significant Bit (LSB) of the AAL5 CPCS PDU.


8.3. ATM 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 [7].

   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)






Martini, et al.                                                [Page 26]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


     - F5 loopback (segment and end-to-end)
     - Resource Management
     - Continuity Check (segment and end-to-end)

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

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

   The egress PE SHOULD be able to generate an F5 AIS for the VCC due to
   a PSN failure. A method to reliably detect a PSN tunnel failure is
   required but not specified in this draft.

   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.


9. AAL5 PDU frame mode

   The AAL5 payload PDU service is OPTIONAL.


9.1. Applicability

   The primary application supported by AAL5 PDU frame encapsulation
   over PSN is the transparent carriage of ATM layer services that use
   AAL5 to carry higher layer frames. The PDU frame mode takes advantage
   of the delineation of higher layer frames in the ATM layer to provide
   increased bandwidth efficiency compared with the basic cell
   encapsulation mode. The nature of the service, as defined by the ATM
   service category or the ATM transfer capability should be preserved.
   To provide this, the basic requirement of the ATM-PSN interworking
   function is to map the AAL5 PDU frames belonging to a VCC, together
   with any related OAM and protocol control information, into a PW.

   Two network applications that utilize the PDU frame mode
   encapsulation are:





Martini, et al.                                                [Page 27]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


     a The transport of multi-service ATM over a packet core network
       where AAL5 is used as the adaptation layer. 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:
            -i. Leveraging of the existing systems and services to
                provide increased capacity from a packet switched core.
           -ii. Preserving existing network operational processes and
                procedures used to maintain the legacy services e.g. ATM
                OAM and ATM security.
          -iii. 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.

         b L2 VPN service over a PSN infrastructure. In this case, VPN
           sites are connected through ATM VCCs, as in today's L2 VPNs.
           The transparent PDU frame mode encapsulation allows the VPN
           service provider to transparently extend this L2 connectivity
           over its PSN while achieving bandwidth efficiency gains over
           the basic cell mode and supporting ATM layer applications of
           the VPN customer, such as ATM security. The advantage is for
           the service provider to combine L2 and L3 services over the
           same PSN.

       One important consideration to make when interworking is to allow
       OAM information to be treated as in the original network. The
       interworking function allows this transparency while performing
       AAL5 frame encapsulation. Fragmentation may be performed in order
       to maintain the position of the OAM cells with respect to the
       user cells.

       Fragmentation may also be performed to maintain the size of the
       packet carrying the AAL5 PDU within the MTU of the link.

       Cell Loss priority (CLP) field conveys the priority of the cell
       in the connection. The Explicit Forward Congestion Indicator
       (EFCI) field conveys the congestion state of ATM network.
       Information on both of these fields is obtained from the ATM cell
       header. CLP and EFCI fields are both part of the ATM service
       specific information header.

       The whole AAL5-PDU is encapsulated. In this case all necessary



Martini, et al.                                                [Page 28]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


       parameters such as CPCS-UU (CPCS User-to-User indicator), CPI
       (Common Part Indicator), Length (Length of the CPCS-SDU) and CRC
       (Cyclic Redundancy Check) are transported as part of the payload.
       Note that carrying of the full PDU also allows the simplification
       of the fragmentation operation since it is performed at cell
       boundaries and the CRC in the trailer of the AAL5 PDU can be used
       to check the integrity of the reassembled fragments.


9.1.1. Implementation and deployment considerations

   AAL5 transparent mode is only applicable to services that use AAL5 to
   carry higher layer frames over ATM VCCs.


9.1.2. Limitations

   AAL5 frame encapsulation only supports point-to-point LSPs.  Multi-
   point-to-point and point-to-multi-point are for further study (FFS).

   Length of AAL5 frame may exceed the MTU of the PSN. This requires
   fragmentation, which may not be available to all nodes at the PW
   endpoint.

   The maximum number of cells of an AAL5 PDU that may be reassembled
   before transport across the PSN may be limited by the cell transfers
   delay (CTD) and cell delay variation (CDV) objectives of the
   connection.

   This mode does not preserve the value of the CLP bit for every ATM
   cell within an AAL5 PDU. Therefore, transparency of the CLP setting
   may be violated. Additionally, tagging of some cells may occur when
   tagging is not allowed by the conformance definition.

   This mode does not preserve the EFCI state for every ATM cell within
   an AAL5 PDU. Therefore, transparency of the EFCI state may be
   violated.


9.2. Transparent AAL5 PDU Frame encapsulation

   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



Martini, et al.                                                [Page 29]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


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



Martini, et al.                                                [Page 30]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


       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.


9.3. ATM 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 [7].

   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

   The PEs SHALL use the single ATM VCC cell mode encapsulation 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).



Martini, et al.                                                [Page 31]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


   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.


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



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


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



Martini, et al.                                                [Page 32]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


                   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.


10. Security Considerations

   This document specifies only encapsulations, and not the protocols
   used to carry the encapsulated packets across the network.  Each such
   protocol may have its own set of security issues, but those issues
   are not affected by the encapsulations specified herein.


11. Intellectual Property Disclaimer

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


12. References

   [1] "Transport of Layer 2 Frames Over MPLS", draft-ietf-pwe3-
   control-protocol-00.txt. ( work in progress )

   [2] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter, D. Tappan, G.
        Fedorkow, D. Farinacci, T. Li, A. Conta. RFC3032

   [3] "Requirements for Peudo Wire Emulation Edge-to-Edge (PWE3",
   draft-ietf-pwe3-requirements-03.txt. ( work in Progress )

   [4] ATM Forum Specification fb-fbatm-0151.000 (2000) ,Frame Based ATM
   over SONET/SDH Transport (FAST)

   [5] ATM Forum Specification af-tm-0121.000 (1999), Traffic Management
   Specification Version 4.1.

   [6] ITU-T Recommendation I.371 (2000), Traffic control and congestion
   control in B-ISDN.

   [7] ITU-T Recommendation I.610, (1999), B-ISDN operation and
   maintenance principles and functions.






Martini, et al.                                                [Page 33]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002


13. Author Information


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


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


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


   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


   Jayakumar Jayakumar,
   Cisco Systems Inc.
   225, E.Tasman, MS-SJ3/3,
   San Jose , CA, 95134
   e-mail: jjayakum@cisco.com






Martini, et al.                                                [Page 34]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002



   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


   Jeremy Brayley
   Laurel Networks, Inc.
   Omega Corporate Center
   1300 Omega Drive
   Pittsburgh, PA 15205
   e-mail: jbrayley@laurelnetworks.com


   Gerald de Grace
   Laurel Networks, Inc.
   Omega Corporate Center
   1300 Omega Drive
   Pittsburgh, PA 15205
   e-mail: gdegrace@laurelnetworks.com


   John Shirron
   Laurel Networks, Inc.
   Omega Corporate Center
   1300 Omega Drive
   Pittsburgh, PA 15205
   e-mail: jshirron@laurelnetworks.com


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






Martini, et al.                                                [Page 35]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002



   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


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


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


   Matthew Bocci
   Alcatel
   Grove House, Waltham Road Rd
   White Waltham, Berks, UK. SL6 3TN
   e-mail: matthew.bocci@alcatel.co.uk


   Mustapha Aissaoui
   Alcatel
   600 March Rd
   Kanata, ON, Canada. K2K 2E6
   e-mail: mustapha.aissaoui@alcatel.com



Martini, et al.                                                [Page 36]

Internet Draft      draft-ietf-pwe3-atm-encap-00.txt        October 2002



   Tom Walsh
   Lucent Technologies
   1 Robbins Road
   Westford, MA 01886 USA
   e-mail: tdwalsh@lucent.com


   John Rutemiller
   Marconi Networks
   1000 Marconi Drive
   Warrendale, PA 15086
   e-mail: John.Rutemiller@marconi.com


   Rick Wilder
   Masergy Communications
   2901 Telestar Ct.
   Falls Church, VA 22042
   e-mail: rwilder@masergy.com


   Laura Dominik
   Qwest Communications, Inc.
   600 Stinson Blvd.
   Minneapolis, MN, 55413
   Email: ldomini@qwest.com
























Martini, et al.                                                [Page 37]


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