<pre>Network Working Group                                         L. Martini
Request for Comments: 4717                                  J. Jayakumar
Category: Standards Track                            Cisco Systems, Inc.
                                                                M. Bocci
                                                                 Alcatel
                                                             N. El-Aawar
                                             Level 3 Communications, LLC
                                                              J. Brayley
                                                        ECI Telecom Inc.
                                                              G. Koleyni
                                                         Nortel Networks
                                                           December 2006


                <span class="h1">Encapsulation Methods for Transport of</span>
          <span class="h1">Asynchronous Transfer Mode (ATM) over MPLS Networks</span>

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2006).

Abstract

   An Asynchronous Transfer Mode (ATM) Pseudowire (PW) is used to carry
   ATM cells over an MPLS network.  This enables service providers to
   offer "emulated" ATM services over existing MPLS networks.  This
   document specifies methods for the encapsulation of ATM cells within
   a pseudowire.  It also specifies the procedures for using a PW to
   provide an ATM service.














<span class="grey">Martini, et al.             Standards Track                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
   <a href="#section-2">2</a>. Specification of Requirements ...................................<a href="#page-4">4</a>
   <a href="#section-3">3</a>. Applicability Statement .........................................<a href="#page-4">4</a>
   <a href="#section-4">4</a>. Terminology .....................................................<a href="#page-4">4</a>
   <a href="#section-5">5</a>. General Encapsulation Method ....................................<a href="#page-6">6</a>
      <a href="#section-5.1">5.1</a>. The Control Word ...........................................<a href="#page-6">6</a>
           <a href="#section-5.1.1">5.1.1</a>. The Generic Control Word ............................<a href="#page-7">7</a>
           <a href="#section-5.1.2">5.1.2</a>. The Preferred Control Word ..........................<a href="#page-8">8</a>
           5.1.3. Setting the Sequence Number Field in the
                  Control Word ........................................<a href="#page-9">9</a>
      <a href="#section-5.2">5.2</a>. MTU Requirements ...........................................<a href="#page-9">9</a>
      <a href="#section-5.3">5.3</a>. MPLS Shim S Bit Value .....................................<a href="#page-10">10</a>
      <a href="#section-5.4">5.4</a>. MPLS Shim TTL Values ......................................<a href="#page-10">10</a>
   <a href="#section-6">6</a>. Encapsulation Mode Applicability ...............................<a href="#page-10">10</a>
      <a href="#section-6.1">6.1</a>. ATM N-to-One Cell Mode ....................................<a href="#page-11">11</a>
      <a href="#section-6.2">6.2</a>. ATM One-to-One Cell Encapsulation .........................<a href="#page-13">13</a>
      <a href="#section-6.3">6.3</a>. AAL5 SDU Frame Encapsulation ..............................<a href="#page-13">13</a>
      <a href="#section-6.4">6.4</a>. AAL5 PDU Frame Encapsulation ..............................<a href="#page-14">14</a>
   <a href="#section-7">7</a>. ATM OAM Cell Support ...........................................<a href="#page-15">15</a>
      <a href="#section-7.1">7.1</a>. VCC Case ..................................................<a href="#page-15">15</a>
      <a href="#section-7.2">7.2</a>. VPC Case ..................................................<a href="#page-16">16</a>
      <a href="#section-7.3">7.3</a>. SDU/PDU OAM Cell Emulation Mode ...........................<a href="#page-16">16</a>
      <a href="#section-7.4">7.4</a>. Defect Handling ...........................................<a href="#page-17">17</a>
   <a href="#section-8">8</a>. ATM N-to-One Cell Mode .........................................<a href="#page-18">18</a>
      <a href="#section-8.1">8.1</a>. ATM N-to-One Service Encapsulation ........................<a href="#page-19">19</a>
   <a href="#section-9">9</a>. ATM One-to-One Cell Mode .......................................<a href="#page-21">21</a>
      <a href="#section-9.1">9.1</a>. ATM One-to-One Service Encapsulation ......................<a href="#page-21">21</a>
      <a href="#section-9.2">9.2</a>. Sequence Number ...........................................<a href="#page-22">22</a>
      <a href="#section-9.3">9.3</a>. ATM VCC Cell Transport Service ............................<a href="#page-22">22</a>
      <a href="#section-9.4">9.4</a>. ATM VPC Services ..........................................<a href="#page-24">24</a>
           <a href="#section-9.4.1">9.4.1</a>. ATM VPC Cell Transport Services ....................<a href="#page-25">25</a>
   <a href="#section-10">10</a>. ATM AAL5 CPCS-SDU Mode ........................................<a href="#page-26">26</a>
      <a href="#section-10.1">10.1</a>. Transparent AAL5 SDU Frame Encapsulation .................<a href="#page-27">27</a>
   <a href="#section-11">11</a>. AAL5 PDU Frame Mode ...........................................<a href="#page-28">28</a>
      <a href="#section-11.1">11.1</a>. Transparent AAL5 PDU Frame Encapsulation .................<a href="#page-28">28</a>
      <a href="#section-11.2">11.2</a>. Fragmentation ............................................<a href="#page-30">30</a>
           <a href="#section-11.2.1">11.2.1</a>. Procedures in the ATM-to-PSN Direction ............<a href="#page-30">30</a>
           <a href="#section-11.2.2">11.2.2</a>. Procedures in the PSN-to-ATM Direction ............<a href="#page-31">31</a>
   <a href="#section-12">12</a>. Mapping of ATM and PSN Classes of Service .....................<a href="#page-31">31</a>
   <a href="#section-13">13</a>. ILMI Support ..................................................<a href="#page-32">32</a>
   <a href="#section-14">14</a>. ATM-Specific Interface Parameter Sub-TLVs .....................<a href="#page-32">32</a>
   <a href="#section-15">15</a>. Congestion Control ............................................<a href="#page-32">32</a>
   <a href="#section-16">16</a>. Security Considerations .......................................<a href="#page-33">33</a>
   <a href="#section-17">17</a>. Normative References ..........................................<a href="#page-34">34</a>
   <a href="#section-18">18</a>. Informative References ........................................<a href="#page-34">34</a>
   <a href="#section-19">19</a>. Significant Contributors ......................................<a href="#page-36">36</a>



<span class="grey">Martini, et al.             Standards Track                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   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 benefit of this model to a service
   provider is 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.

   This document describes a method to carry ATM services over MPLS.  It
   lists ATM-specific requirements and provides encapsulation formats
   and semantics for connecting ATM edge networks through a packet-
   switched network using MPLS.

   Figure 1, below, displays the ATM services reference model.  This
   model is adapted from [<a href="./rfc3985" title="&quot;Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture&quot;">RFC3985</a>].

                     |&lt;----- Pseudowire -----&gt;|
                     |                        |
                     |  |&lt;-- PSN Tunnel --&gt;|  |
        ATM Service  V  V                  V  V  ATM Service
             |     +----+                  +----+     |
   +----+    |     | PE1|==================| PE2|     |    +----+
   |    |----------|............PW1.............|----------|    |
   | CE1|    |     |    |                  |    |     |    |CE2 |
   |    |----------|............PW2.............|----------|    |
   +----+    |     |    |==================|    |     |    +----+
        ^          +----+                  +----+     |    ^
        |      Provider Edge 1         Provider Edge 2     |
        |                                                  |
        |&lt;-------------- Emulated Service ----------------&gt;|
   Customer                                                Customer
   Edge 1                                                  Edge 2

                   Figure 1: ATM Service Reference Model






<span class="grey">Martini, et al.             Standards Track                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Specification of Requirements</span>

   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 [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Applicability Statement</span>

   The ATM over PW service is not intended to perfectly emulate a
   traditional ATM service, but it can be used for applications that
   need an ATM transport service.

   The following are notable differences between traditional ATM service
   and the protocol described in this document:

     - ATM cell ordering can be preserved using the OPTIONAL sequence
       field in the control word; however, implementations are not
       required to support this feature.  The use of this feature may
       impact other ATM quality of service (QoS) commitments.

     - The QoS model for traditional ATM can be emulated.  However, the
       detailed specification of ATM QoS emulation is outside the scope
       of this document.  The emulation must be able to provide the
       required ATM QoS commitments for the end-user application.

     - The ATM flow control mechanisms are transparent to the MPLS
       network and cannot reflect the status of the MPLS network.

     - Control plane support for ATM SVCs, SVPs, SPVCs, and SPVPs is
       outside the scope of this document.

   Note that the encapsulations described in this specification are
   identical to those described in [<a href="#ref-Y.1411">Y.1411</a>] and [<a href="#ref-Y.1412">Y.1412</a>].

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Terminology</span>

   One-to-one mode: specifies an encapsulation method that maps one ATM
   Virtual Channel Connection (VCC) (or one ATM Virtual Path Connection
   (VPC)) to one pseudowire.

   N-to-one mode (N &gt;= 1): specifies an encapsulation method that maps
   one or more ATM VCCs (or one or more ATM VPCs) to one pseudowire.

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

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



<span class="grey">Martini, et al.             Standards Track                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


   Customer Edge (CE): a device where one end of a service originates
   and/or terminates.  The CE is not aware that it is using an emulated
   service rather than a native service.

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

   Pseudowire (PW): a connection between two PEs carried over a PSN.
   The PE provides the adaptation between the CE and the PW.

   Pseudowire PDU: a PDU sent on the PW that contains all of the data
   and control information necessary to provide the desired service.

   PSN Tunnel: 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
   pseudowire PDU (ATM to PSN direction).

   Egress: the point where the ATM service is decapsulated from a
   pseudowire PDU (PSN to ATM direction).

   CTD: Cell Transfer Delay.

   MTU: Maximum Transmission Unit.

   SDU: Service Data Unit.

   OAM: Operations And Maintenance.

   PVC: Permanent Virtual Connection.  An ATM connection that is
   provisioned via a network management interface.  The connection is
   not signaled.

   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.

   Additional terminology relevant to pseudowires and Layer 2 Virtual
   Private Networking (L2VPN) in general may be found in [<a href="./rfc4026" title="&quot;Provider Provisioned Virtual Private Network (VPN) Terminology&quot;">RFC4026</a>].



<span class="grey">Martini, et al.             Standards Track                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  General Encapsulation Method</span>

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

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

         Figure 2: General format for ATM encapsulation over PSNs

   The PSN Transport Header depends on the particular tunneling
   technology in use.  This header is used to transport the encapsulated
   ATM information through the packet-switched core.

   The Pseudowire Header identifies a particular ATM service on a
   tunnel.  In case of MPLS, the pseudowire header is one or more MPLS
   labels at the bottom of the MPLS label stack.

   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.

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  The Control Word</span>

   The Control Words defined in this section are based on the Generic PW
   MPLS Control Word as defined in [<a href="./rfc4385" title="&quot;Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN&quot;">RFC4385</a>].  They provide the ability
   to sequence individual frames on the PW, avoidance of equal-cost
   multiple-path load-balancing (ECMP) [<a href="./rfc2992" title="&quot;Analysis of an Equal-Cost Multi-Path Algorithm&quot;">RFC2992</a>], and OAM mechanisms
   including VCCV [<a href="#ref-VCCV" title="&quot;Pseudowire Virtual Circuit Connectivity Verification (VCCV)&quot;">VCCV</a>].

   [<a id="ref-RFC4385">RFC4385</a>] states, "If a PW is sensitive to packet misordering and is
   being carried over an MPLS PSN that uses the contents of the MPLS
   payload to select the ECMP path, it MUST employ a mechanism which
   prevents packet misordering."  This is necessary because ECMP
   implementations may examine the first nibble after the MPLS label
   stack to determine whether or not the labelled packet is IP.  Thus,
   if the VPI of an ATM connection carried over the PW using N-to-one
   cell mode encapsulation, without a control word present, begins with
   0x4 or 0x6, it could be mistaken for an IPv4 or IPv6 packet.  This



<span class="grey">Martini, et al.             Standards Track                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


   could, depending on the configuration and topology of the MPLS
   network, lead to a situation where all packets for a given PW do not
   follow the same path.  This may increase out-of-order frames on a
   given PW, or cause OAM packets to follow a different path than actual
   traffic (see <a href="#section-4.4.3">section 4.4.3</a> on Frame Ordering).

   The features that the control word provides may not be needed for a
   given ATM PW.  For example, ECMP may not be present or active on a
   given MPLS network, strict frame sequencing may not be required, etc.
   If this is the case, and the control word is not REQUIRED by the
   encapsulation mode for other functions (such as length or the
   transport of ATM protocol specific information), the control word
   provides little value and is therefore OPTIONAL.  Early ATM PW
   implementations have been deployed that do not include a control word
   or the ability to process one if present.  To aid in backwards
   compatibility, future implementations MUST be able to send and
   receive frames without a control word present.

   In all cases, the egress PE MUST be aware of whether the ingress PE
   will send a control word over a specific PW.  This may be achieved by
   configuration of the PEs, or by signaling, as defined in [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>].

   If the pseudowire traverses a network link that requires a minimum
   frame size (Ethernet is a practical example), with a minimum frame
   size of 64 octets, then such links will apply padding to the
   pseudowire PDU to reach its minimum frame size.  In this case, the
   control word must include a length field set to the PDU length.  A
   mechanism is required for the egress PE to detect and remove such
   padding.

<span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>.  The Generic Control Word</span>

   This control word is used in the following encapsulation modes:

     - ATM One-to-one Cell Mode
     - AAL5 PDU Frame Mode

   The PWE3 control word document [<a href="./rfc4385" title="&quot;Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN&quot;">RFC4385</a>] provides the following
   structure for the generic control word:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0|          Specified by PW Encapsulation                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






<span class="grey">Martini, et al.             Standards Track                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


   The detailed structure for the ATM One-to-one Cell Mode and for the
   AAL5 PDU Frame Mode is 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0| Resvd |        Sequence Number        | ATM Specific  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In the above diagram, the first 4 bits MUST be set to 0 to indicate
   PW data.  They MUST be ignored by the receiving PE.

   The next four bits are reserved and MUST be set to 0 upon
   transmission and ignored upon reception.

   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 that the sequence number
   check algorithm is not used.

   The last 8 bits provide space for carrying ATM-specific flags.  These
   are defined in the protocol-specific details below.

   There is no requirement for a length field for the One-to-one Cell
   and PDU Frame modes because the PSN PDU is always greater than 64
   bytes; therefore, no padding is applied in Ethernet links in the PSN.

<span class="h4"><a class="selflink" id="section-5.1.2" href="#section-5.1.2">5.1.2</a>.  The Preferred Control Word</span>

   This control word is used in the following encapsulation modes:

     - ATM N-to-one Cell Mode
     - AAL5 SDU Frame Mode

   It 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0| Flags |Res|   Length  |     Sequence Number           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In the above diagram, the first 4 bits MUST be set to 0 to indicate
   PW data.  They MUST be ignored by the receiving PE.




<span class="grey">Martini, et al.             Standards Track                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


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

   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.  Note that the length field
   is not used in the N-to-one mode and MUST be set to 0.

   The last 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 that the sequence number
   check algorithm is not used.

<span class="h4"><a class="selflink" id="section-5.1.3" href="#section-5.1.3">5.1.3</a>.  Setting the Sequence Number Field in the Control Word</span>

   This section applies to the sequence number field of both the Generic
   and Preferred Control Words.

   For a given emulated VC and a pair of routers PE1 and PE2, if PE1
   supports packet sequencing, then the sequencing procedures defined in
   [<a href="./rfc4385" title="&quot;Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN&quot;">RFC4385</a>] MUST be used.

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

   A simple extension of the processing algorithm in [<a href="./rfc4385" title="&quot;Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN&quot;">RFC4385</a>] MAY be
   used to detect lost packets.

   If a PE router negotiated not to use receive sequence number
   processing, and it received a non-zero sequence number, then it
   SHOULD send a PW status message indicating a receive fault and
   disable the PW.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  MTU Requirements</span>

   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



<span class="grey">Martini, et al.             Standards Track                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


   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.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  MPLS Shim S Bit Value</span>

   The ingress label switching router (LSR), PE1, MUST set the S bit of
   the PW label to a value of 1 to denote that the VC label is at the
   bottom of the stack.  For more information on setting the S Bit, see
   [<a href="./rfc3032" title="&quot;MPLS Label Stack Encoding&quot;">RFC3032</a>].

<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>.  MPLS Shim TTL Values</span>

   The setting of the TTL value in the PW label is application
   dependent.  In any case, [<a href="./rfc3032" title="&quot;MPLS Label Stack Encoding&quot;">RFC3032</a>] TTL processing procedure,
   including handling of expired TTLs, MUST be followed.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Encapsulation Mode Applicability</span>

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

   The N-to-one mode (N &gt;= 1) specifies an encapsulation method that
   maps one or more ATM VCCs (or one or more ATM VPCs) to one
   pseudowire.  This is the only REQUIRED mode.  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.

   The One-to-one mode specifies an encapsulation method that maps one
   ATM VCC or one ATM VPC to one pseudowire.  For VCCs, the VPI/VCI is
   not included.  For VPCs, the VPI is not included.  Cells from one VCC
   or one VPC may be concatenated.  This mode is OPTIONAL.

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

   Three deployment models are supported by the encapsulations described
   in this document:

        -i. Single ATM Connection: A PW carries the cells of only one
            ATM VCC or VPC.  This supports both the transport of
            multiservice ATM and L2VPN service over a PSN for all AAL
            types.



<span class="grey">Martini, et al.             Standards Track                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


       -ii. Multiple ATM Connections: A PW carries the cells of multiple
            ATM VCCs and/or VPCs.  This also supports both the transport
            of multiservice ATM and L2VPN service over a PSN for all AAL
            types.

      -iii. AAL5: A PW carries the AAL5 frames of only one ATM VCC.  A
            large proportion of the data carried on ATM networks is
            frame based and therefore uses AAL5.  The AAL5 mapping takes
            advantage of the delineation of higher-layer frames in the
            ATM layer to provide increased bandwidth efficiency compared
            with the basic cell mapping.  The nature of the service, as
            defined by the ATM service category [<a href="#ref-TM4.0">TM4.0</a>] or the ATM
            transfer capability [<a href="#ref-I.371" title="&quot;Traffic control and congestion control in B-ISDN&quot;">I.371</a>], should be preserved.

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  ATM N-to-One Cell Mode</span>

   This encapsulation supports both the Single and Multiple ATM
   Connection deployment models.  This encapsulation is REQUIRED.

   The encapsulation allows multiple VCCs/VPCs to be carried within a
   single pseudowire.  However, a service provider may wish to provision
   a single VCC to a pseudowire in order to satisfy QoS or restoration
   requirements.

   The encapsulation also supports the binding of multiple VCCs/VPCs to
   a single pseudowire.  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.

   In the simplest case, this encapsulation can be used to transmit a
   single ATM cell per PSN PDU.  However, in order to provide better PSN
   bandwidth efficiency, several ATM cells may optionally be
   encapsulated in a single PSN PDU.  This process is called cell
   concatenation.

   The encapsulation has the following attributes:

        -i. Supports all ATM Adaptation Layer 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.








<span class="grey">Martini, et al.             Standards Track                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


      -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.  Cell concatenation adds latency
            and delay variation to a cell relay service.

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

        -v. If the Single ATM connection deployment model is used, then
            it is simpler to provide an ATM layer service.  The nature
            of the service, as defined by the ATM service category
            [<a href="#ref-TM4.0">TM4.0</a>] or ATM transfer capability [<a href="#ref-I.371" title="&quot;Traffic control and congestion control in B-ISDN&quot;">I.371</a>], should be
            preserved.

   The limitations of the ATM N-to-one cell encapsulation are:

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

      -vii. The ATM cell header checksum can detect a 2-bit error or
            detect and 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 an L2 Frame Check Sequence (FCS)
            failure.

     -viii. Cells can be concatenated from multiple VCCs or VPCs
            belonging to different service categories and QoS
            requirements.  In this case, the PSN packet must receive
            treatment by the PSN to support the highest QoS of the ATM
            VCCs/VPCs carried.

       -ix. Cell encapsulation only supports point-to-point Label
            Switched Paths (LSPs).  Multipoint-to-point and point-to-
            multi-point are for further study (FFS).

        -x. The number of concatenated ATM cells is limited by the MTU
            size and the cell transfer delay (CTD) and cell delay
            variation (CDV) objectives of multiple ATM connections that
            are multiplexed into a single PW.






<span class="grey">Martini, et al.             Standards Track                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  ATM One-to-One Cell Encapsulation</span>

   This OPTIONAL encapsulation supports the Single ATM Connection
   deployment model.

   Like the N-to-one cell encapsulation mode, the One-to-one mode
   supports cell concatenation.  The advantage of this encapsulation is
   that it utilizes less bandwidth that the N-to-one encapsulation, for
   a given number of concatenated cells.  Since only one ATM VCC or VPC
   is carried on a PW, the VCI and/or VPI of the ATM VCC or VPC can be
   derived from the context of the PW using the PW label.  These fields
   therefore do not need to be encapsulated for a VCC, and only the VCI
   needs to be encapsulated for a VPC.  This encapsulation thus allows
   service providers to achieve a higher bandwidth efficiency on PSN
   links than the N-to-one encapsulation for a given number of
   concatenated cells.

   The limitations vi, vii, ix, and x of N-to-one mode apply.

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  AAL5 SDU Frame Encapsulation</span>

   This OPTIONAL encapsulation supports the AAL5 model.  This mode
   allows the transport of ATM AAL5 CSPS-SDUs traveling on a particular
   ATM PVC across the network to another ATM PVC.  This encapsulation is
   used by a PW of type 0x0002 "ATM AAL5 SDU VCC transport" as allocated
   in [<a href="./rfc4446" title="&quot;IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)&quot;">RFC4446</a>].

   The AAL5 SDU encapsulation is more efficient for small AAL5 SDUs than
   the VCC cell encapsulations.  In turn, it presents a more efficient
   alternative to the cell relay service when carrying [<a href="./rfc2684" title="&quot;Multiprotocol Encapsulation over ATM Adaptation Layer 5&quot;">RFC2684</a>]-
   encapsulated IP PDUs across a PSN.

   The AAL5-SDU encapsulation requires Segmentation and Reassembly (SAR)
   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 pseudowire to the egress PE.  Herein lies another
   advantage of the AAL5-SDU encapsulation.

   The limitations of the AAL5 SDU encapsulation are:

        -i. If an ATM OAM cell is received at the ingress PE, it is sent
            before the cells of the surrounding AAL5 frame.  Therefore,
            OAM cell reordering may occur, which may cause certain ATM
            OAM performance monitoring and ATM security applications to
            operate incorrectly.






<span class="grey">Martini, et al.             Standards Track                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


       -ii. If the ALL5 PDU is scrambled using ATM security standards, a
            PE will not be able to extract the ALL5 SDU, and therefore
            the whole PDU will be dropped.

      -iii. The AAL5 PDU CRC is not transported across the PSN.  The CRC
            must therefore be regenerated at the egress PE since the CRC
            has end-to-end significance in ATM security.  This means
            that the AAL5 CRC may not be used to accurately check for
            errors on the end-to-end ATM VCC.

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

        -v. 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 [<a href="#ref-TM4.0">TM4.0</a>].

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

<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>.  AAL5 PDU Frame Encapsulation</span>

   This OPTIONAL encapsulation supports the AAL5 model.

   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 main advantage of this AAL5
   mode is that it is transparent to ATM OAM and ATM security
   applications.

   One important consideration is to allow OAM information to be treated
   as in the original network.  This encapsulation mode allows this
   transparency while performing AAL5 frame encapsulation.  This mode
   supports fragmentation, which 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.
   Fragmentation provides a means for the PE to set the size of the PW
   packet to a different value than that of the original AAL5 PDU.  This
   means that the PE has control on the delay and jitter provided to the
   ATM cells.





<span class="grey">Martini, et al.             Standards Track                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


   The whole AAL5-PDU is encapsulated.  In this case, all necessary
   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 PDU.

   Reassembly is not required at the egress PE for the PSN-to-ATM
   direction.

   The limitations v and vi of the AAL5 SDU mode apply to this mode as
   well.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  ATM OAM Cell Support</span>

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  VCC Case</span>

   In general, when configured for ATM VCC service, both PEs SHOULD act
   as a VC switch, in accordance with the OAM procedures defined in
   [<a href="#ref-I.610" title="&quot;B-ISDN operation and maintenance principles and functions&quot;">I.610</a>].

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

     - F5 Alarm Indication Signal (AIS) (segment and end-to-end)
     - F5 Remote Defect Indicator (RDI) (segment and end-to-end)
     - F5 loopback (segment and end-to-end)
     - Resource Management
     - Performance Management
     - Continuity Check
     - Security

   However, if configured to be an administrative segment boundary, the
   PE SHOULD terminate and process F5 segment OAM cells.

   F4 OAM cells are inserted or extracted at the VP link termination.
   These OAM cells are not seen at the VC link termination and are
   therefore not sent across the PSN.

   When the PE is operating in AAL5 CPCS-SDU transport mode if it does
   not support transport of ATM cells, the PE MUST discard incoming MPLS
   frames on an ATM PW that contain a PW label with the T bit set.








<span class="grey">Martini, et al.             Standards Track                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  VPC Case</span>

   When configured for a VPC cell relay service, both PEs SHOULD act as
   a VP cross-connect in accordance with the OAM procedures defined in
   [<a href="#ref-I.610" title="&quot;B-ISDN operation and maintenance principles and functions&quot;">I.610</a>].

   The PEs SHOULD be able to process and pass the following OAM cells
   transparently according to [<a href="#ref-I.610" title="&quot;B-ISDN operation and maintenance principles and functions&quot;">I.610</a>]:

     - F4 AIS (segment and end-to-end)
     - F4 RDI (segment and end-to-end)
     - F4 loopback (segment and end-to-end)

   However, if configured to be an administrative segment boundary, the
   PE SHOULD terminate and process F4 segment OAM cells.

   F5 OAM are not inserted or extracted here.  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 OAM cell MAY be encapsulated together with other user data cells
   if multiple cell encapsulation is used.

<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>.  SDU/PDU OAM Cell Emulation Mode</span>

   A PE operating in ATM SDU or PDU transport mode that does not support
   transport of OAM cells across a PW MAY provide OAM support on ATM
   PVCs using the following procedures:

     - Loopback cells response

       If an F5 end-to-end OAM cell is received from an ATM VC, by
       either PE that is transporting this ATM VC, with a loopback
       indication value of 1, and the PE has a label mapping for the ATM
       VC, then the PE MUST decrement the loopback indication value and
       loop back the cell on the ATM VC.  Otherwise, the loopback cell
       MUST be discarded by the PE.







<span class="grey">Martini, et al.             Standards Track                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


     - AIS alarm

       If an ingress PE, PE1, receives an AIS F4/F5 OAM cell, it MUST
       notify the remote PE of the failure.  The remote PE, PE2, MUST in
       turn send F5 OAM AIS cells on the respective PVCs.  Note that if
       the PE supports forwarding of OAM cells, then the received OAM
       AIS alarm cells MUST be forwarded along the PW as well.

     - Interface failure

       If the PE detects a physical interface failure, or the interface
       is administratively disabled, the PE MUST notify the remote PE
       for all VCs associated with the failure.

     - PSN/PW failure detection

       If the PE detects a failure in the PW, by receiving a label
       withdraw for a specific PW ID, or the targeted Label Distribution
       Protocol (LDP) session fails, or a PW status TLV notification is
       received, then a proper AIS F5 OAM cell MUST be generated for all
       the affected ATM PVCs.  The AIS OAM alarm will be generated on
       the ATM output port of the PE that detected the failure.

<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>.  Defect Handling</span>

   Figure 3 illustrates four possible locations for defects on the PWE3
   service:

     - (a) On the ATM connection from CE to PE
     - (b) On the ATM side of the PW
     - (c) On the PSN side of the PE
     - (d) In the PSN

                   +----+                  +----+
   +----+          | PE1|==================| PE2|          +----+
   |    |---a------|b..c........PW1...d.........|----------|    |
   | CE1|          |    |                  |    |          |CE2 |
   |    |----------|............PW2.............|----------|    |
   +----+          |    |==================|    |          +----+
        ^          +----+                  +----+          ^
        |      Provider Edge 1         Provider Edge 2     |
        |                                                  |
        |&lt;-------------- Emulated Service ----------------&gt;|
   Customer                                                Customer
   Edge 1                                                  Edge 2

                        Figure 3: Defect Locations




<span class="grey">Martini, et al.             Standards Track                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


   For failures at (a) or (b), in the VPC case, the ingress PE MUST be
   able to generate an F4 AIS upon reception of a lower-layer defect
   (such as LOS).  In the VCC case, 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).  These messages are sent across the
   PSN.

   For failures at (c) or (d), in the VCC case, 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).  In the VPC case, 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 pseudowire-specific maintenance
   mechanism such as the PW status message defined in [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>].
   Alternatively, for example, the ingress PE MAY withdraw the
   pseudowire (PW label) label associated with the service.  Upon
   receiving such a notification, the egress PE SHOULD generate the
   appropriate F4 AIS (for VPC) or F5 AIS (for VCC).

   If the PW in one direction fails, then the complete bidirectional
   service is considered to have failed.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  ATM N-to-One Cell Mode</span>

   The N-to-one mode (N &gt;= 1) described in this document 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.


















<span class="grey">Martini, et al.             Standards Track                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  ATM N-to-One Service Encapsulation</span>

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

    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)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     pseudowire Header                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0| Flags |Res|   Length  |     Sequence Number           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ATM Service Payload                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 4: General format for ATM encapsulation over PSNs

   The PSN Transport Header depends on the particular tunneling
   technology in use.  This header is used to transport the encapsulated
   ATM information through the packet-switched core.

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

   As shown above, in Figure 4, the ATM Control Word is inserted before
   the ATM service payload.  It may contain a length field and a
   sequence number field in addition to certain control bits needed to
   carry the service.

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

   In this encapsulation mode, ATM cells are transported individually.
   The encapsulation of a single ATM cell is the only REQUIRED
   encapsulation for ATM.  The encapsulation of more than one ATM cell
   in a PSN frame is OPTIONAL.

   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 [<a href="#ref-FBATM">FBATM</a>] <a href="#section-3.1.1">section 3.1.1</a>, but without the
   trailer byte.  The length of each frame, without the encapsulation
   headers, is a multiple of 52 bytes.  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



<span class="grey">Martini, et al.             Standards Track                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


   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 be signaled, for example using the methods described later
   in this document and in [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>].  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
   and length bits in the control word are not used.  These bits 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 change the CLP bit from
   zero to one in order 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:

    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 5: Multiple Cell ATM Encapsulation

     * When multiple VCCs or VPCs are transported in one pseudowire,
       VPI/VCI values MUST be unique.  When the multiple VCCs or VPCs
       are from different a physical transmission path, it may be
       necessary to assign unique VPI/VCI values to the ATM connections.
       If they are from the same physical transmission path, the VPI/VCI
       values are unique.



<span class="grey">Martini, et al.             Standards Track                    [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


     * 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 &amp; 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 Header Error Check (HEC) field) of the
       incoming cell.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  ATM One-to-One Cell Mode</span>

   The One-to-one mode described in this document 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 pseudowire.

<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>.  ATM One-to-One Service Encapsulation</span>

   This section describes the general encapsulation format for ATM over
   pseudowires on an MPLS PSN.  Figure 6 provides a general format for
   encapsulation of ATM cells 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)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Pseudowire Header                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0| Resvd |    Optional Sequence Number   | ATM Specific  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     ATM Service Payload                       |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 6: General format for One-to-one mode encapsulation over PSNs




<span class="grey">Martini, et al.             Standards Track                    [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


   The MPLS PSN Transport Header depends on how the MPLS network is
   configured.  The Pseudowire Header identifies a particular ATM
   service within the PSN tunnel created by the PSN Transport Header.

   This header is used to transport the encapsulated ATM information
   through the packet-switched core.

   The generic control word is inserted after the Pseudowire Header.
   The presence of the control word is REQUIRED.

   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.

<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>.  Sequence Number</span>

   The sequence number is not required for all services.

   Treatment of the sequence number is according to <a href="#section-5.1.3">section 5.1.3</a>.

<span class="h3"><a class="selflink" id="section-9.3" href="#section-9.3">9.3</a>.  ATM VCC Cell Transport Service</span>

   The VCC cell transport service is characterized by the mapping of a
   single ATM VCC (VPI/VCI) to a pseudowire.  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)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Pseudowire Header                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 0 0 0| Resvd |  Optional Sequence Number     |M|V|Res| PTI |C|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                   ATM Cell Payload ( 48 bytes )               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 7: Single ATM VCC Cell Encapsulation



<span class="grey">Martini, et al.             Standards Track                    [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


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

     * 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 pseudowire PDU.  The ingress
   and egress PE MUST agree to a maximum number of cells in a single
   pseudowire PDU.  This agreement may be accomplished via a
   pseudowire-specific signaling mechanism or via static configuration.

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












<span class="grey">Martini, et al.             Standards Track                    [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


    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)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Pseudowire Header                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0| Resvd |  Optional Sequence Number     |M|V|Res| PTI |C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                   ATM Cell Payload ( 48 bytes )               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|V|Res| PTI |C|                                               |
   +-+-+-+-+-+-+-+-+                                               |
   |                   ATM Cell Payload ( 48 bytes )               |
   |                                                               |
   |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |
   +-+-+-+-+-+-+-+-+

               Figure 8: Multiple ATM VCC Cell Encapsulation

<span class="h3"><a class="selflink" id="section-9.4" href="#section-9.4">9.4</a>.  ATM VPC Services</span>

   The VPC service is defined by mapping a single VPC (VPI) to a
   pseudowire.  As such, it emulates a 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 pseudowire header.  As a VPC
   service, the egress PE MUST NOT change the VCI field.

















<span class="grey">Martini, et al.             Standards Track                    [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


<span class="h4"><a class="selflink" id="section-9.4.1" href="#section-9.4.1">9.4.1</a>.  ATM VPC Cell Transport Services</span>

   The ATM VPC cell transport service is OPTIONAL.

   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)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Pseudowire Header                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0| Resvd |  Optional Sequence Number     |M|V|Res| PTI |C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             VCI               |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   |                   ATM Cell Payload ( 48 bytes )               |
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 9: 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 pseudowire PDU.  The ingress
   and egress PE MUST agree to a maximum number of cells in a single
   pseudowire PDU.  This agreement may be accomplished via a
   pseudowire-specific signaling mechanism or via static configuration.

   If the Egress PE supports cell concatenation, the ingress PE MUST
   only concatenate cells up to the "Maximum Number of concatenated ATM
   cells in a frame" interface parameter sub-TLV as received as part of
   the control protocol [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>].

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



<span class="grey">Martini, et al.             Standards Track                    [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


    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)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Pseudowire Header                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0| Resvd |  Optional 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 10: Multiple Cell VPC Encapsulation

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  ATM AAL5 CPCS-SDU Mode</span>

   The AAL5 payload VCC service defines a mapping between the payload of
   an AAL5 VCC and a single pseudowire.  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 pseudowire.  Therefore, once the ingress PE reassembles the
   AAL5 CPCS-PDU, the PE discards the PAD and CPCS-PDU trailer, and then
   the ingress PE inserts the resulting payload into a pseudowire 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 it
   does not attempt to maintain the relative order of these cells with
   respect to the cells that comprise the AAL5 CPCS-PDU.  All OAM cells,
   regardless of their type, that arrive during the reassembly of a



<span class="grey">Martini, et al.             Standards Track                    [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


   single AAL5 CPCS-PDU are sent immediately on the pseudowire using
   N-to-one cell encapsulation, 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).

<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>.  Transparent AAL5 SDU Frame Encapsulation</span>

   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 11: 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 N-to-
       one cell relay encapsulation, Figure 4.  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



<span class="grey">Martini, et al.             Standards Track                    [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


       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 [<a href="./rfc3916" title="&quot;Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)&quot;">RFC3916</a>]
       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.

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  AAL5 PDU Frame Mode</span>

   The AAL5 payload PDU service is OPTIONAL.

<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>.  Transparent AAL5 PDU Frame Encapsulation</span>

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

   This mode MAY support fragmentation procedures described in the
   "Fragmentation" section below, 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.



<span class="grey">Martini, et al.             Standards Track                    [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


   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)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Pseudowire Header                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0| Resvd |   Optional Sequence Number    |M|V| Res |U|E|C|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             "                                 |
   |                        AAL5 CPCS-PDU                          |
   |                      (n * 48 bytes)                           |
   |                             "                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 12: AAL5 transparent service encapsulation

   The generic control word is inserted after the Pseudowire Header.
   The presence of the control word is MANDATORY.

   The M, V, Res, and C bits are as defined earlier for VCC One-to-one
   cell mode.

     * U Bit

       This field indicates whether this frame contains the last cell of
       an AAL5 PDU and represents the value of the ATM User-to-User bit
       for the last ATM cell of the PSN frame.  Note: The ATM User-to-
       User bit is the least significant bit of the PTI field in the ATM
       header.  This field is used to support the fragmentation
       functionality described later in this section.

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




<span class="grey">Martini, et al.             Standards Track                    [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


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

<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>.  Fragmentation</span>

   The ingress PE may not always be able to reassemble a full AAL5
   frame.  This may be because the AAL5 PDU exceeds the pseudowire MTU
   or because 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.

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

<span class="h4"><a class="selflink" id="section-11.2.1" href="#section-11.2.1">11.2.1</a>.  Procedures in the ATM-to-PSN Direction</span>

   The following procedures shall apply while fragmenting AAL5 PDUs:

     - Fragmentation shall always occur at cell boundaries within the
       AAL5 PDU.

     - Set the UU bit to the value of the ATM User-to-User bit in the
       cell header of the most recently received ATM cell.

     - The E and C bits of the fragment shall be set as defined in
       <a href="#section-9">section 9</a>.

     - If the arriving cell is an OAM or an RM cell, send the current
       PSN frame and then send the OAM or RM cell using One-to-one
       single cell encapsulation (VCC).








<span class="grey">Martini, et al.             Standards Track                    [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


<span class="h4"><a class="selflink" id="section-11.2.2" href="#section-11.2.2">11.2.2</a>.  Procedures in the PSN-to-ATM Direction</span>

   The following procedures shall apply:

     - The 3-bit PTI field of each ATM cell header is constructed as
       follows:

        -i. The most significant bit is set to 0, indicating a user data
            cell.

       -ii. The middle bit is set to the E bit value of the fragment.

      -iii. The least significant bit for the last ATM cell in the PSN
            frame is set to the value of the UU bit of Figure 12.

       -iv. The least significant PTI bit is set to 0 for all other
            cells in the PSN frame.

     - The CLP bit of each ATM cell header is set to the value of the C
       bit of the control byte in Figure 12.

     - When a fragment is received, each constituent ATM cell is sent in
       correct order.

<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>.  Mapping of ATM and PSN Classes of Service</span>

   This section is provided for informational purposes, and for guidance
   only.  This section should not be considered part of the standard
   proposed in this document.

   When ATM PW service is configured over a PSN, the ATM service
   category of a connection 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
   Diffserv framework, a class of service based on the EF PHB is a good
   candidate.

   Furthermore, ATM service categories have support for multiple
   conformance definitions [<a href="#ref-TM4.0">TM4.0</a>].  Some are CLP blind (e.g., CBR),
   meaning that the QoS objectives apply to the aggregate CLP0+1
   conforming cell flow.  Some are CLP significant (e.g., VBR.3),
   meaning that the QoS objectives apply to the CLP0 conforming cell
   flow only.

   When the PSN is MPLS based, a mapping between the CLP bit and the EXP
   field can be performed to provide visibility of the cell loss



<span class="grey">Martini, et al.             Standards Track                    [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


   priority in the MPLS network.  The actual value to be marked in the
   EXP field depends on the ATM service category, the ATM conformance
   definition, and the type of tunnel LSP used (E-LSP or L-LSP).  The
   details of this mapping are outside the scope of this document.
   Operators have the flexibility to design a specific mapping that
   satisfies their own requirements.

   In both the ATM-to-PSN and PSN-to-ATM directions, the method used to
   transfer the CLP and EFCI information of the individual cells into
   the ATM-specific field, or flags, of the PW packet is described in
   detail in sections <a href="#section-6">6</a> through <a href="#section-9">9</a> for each encapsulation mode.

<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>.  ILMI Support</span>

   An MPLS edge PE MAY provide an ATM Integrated Local Management
   Interface (ILMI) to the ATM edge switch.  If an ingress PE receives
   an ILMI message indicating that the ATM edge switch has deleted a VC,
   or if the physical interface goes down, it MUST send a PW status
   notification message for all PWs associated with the failure.  When a
   PW label mapping is withdrawn, or PW status notification message is
   received, the egress PE MUST notify its client of this failure by
   deleting the VC using ILMI.

<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>.  ATM-Specific Interface Parameter Sub-TLVs</span>

   The Interface parameter TLV is defined in [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>], and the IANA
   registry with initial values for interface parameter sub-TLV types is
   defined in [<a href="./rfc4446" title="&quot;IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)&quot;">RFC4446</a>], but the ATM PW-specific interface parameter is
   specified as follows:

     - 0x02 Maximum Number of concatenated ATM cells.

       A 2-octet value specifying the maximum number of concatenated ATM
       cells that can be processed as a single PDU by the egress PE.  An
       ingress PE transmitting concatenated cells on this PW can
       concatenate a number of cells up to the value of this parameter,
       but MUST NOT exceed it.  This parameter is applicable only to PW
       types 3, 9, 0x0a, 0xc, [<a href="./rfc4446" title="&quot;IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)&quot;">RFC4446</a>], and 0xd and is REQUIRED for
       these PWC types.  This parameter does not need to match in both
       directions of a specific PW.

<span class="h2"><a class="selflink" id="section-15" href="#section-15">15</a>.  Congestion Control</span>

   As explained in [<a href="./rfc3985" title="&quot;Pseudo Wire Emulation Edge-to- Edge (PWE3) Architecture&quot;">RFC3985</a>], the PSN carrying the PW may be subject to
   congestion, with congestion characteristics depending on PSN type,
   network architecture, configuration, and loading.  During congestion
   the PSN may exhibit packet loss that will impact the service carried
   by the ATM PW.  In addition, since ATM PWs carry a variety of



<span class="grey">Martini, et al.             Standards Track                    [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


   services across the PSN, including but not restricted to TCP/IP, they
   may or may not behave in a TCP-friendly manner prescribed by
   [<a href="./rfc2914" title="&quot;Congestion Control Principles&quot;">RFC2914</a>].  In the presence of services that reduce transmission
   rate, ATM PWs may thus consume more than their fair share and in that
   case SHOULD be halted.

   Whenever possible, ATM PWs should be run over traffic-engineered PSNs
   providing bandwidth allocation and admission control mechanisms.
   IntServ-enabled domains providing the Guaranteed Service (GS) or
   Diffserv-enabled domains using EF (expedited forwarding) are examples
   of traffic-engineered PSNs.  Such PSNs will minimize loss and delay
   while providing some degree of isolation of the ATM PW's effects from
   neighboring streams.

   It should be noted that when transporting ATM, Diffserv-enabled
   domains may use AF (Assured Forwarding) and/or DF (Default
   Forwarding) instead of EF, in order to place less burden on the
   network and gain additional statistical multiplexing advantage.  In
   particular, Table 1 of Appendix "V" in [<a href="#ref-ATM-MPLS" title="&quot;ATM-MPLS Network Interworking Version 2.0&quot;">ATM-MPLS</a>] contains a detailed
   mapping between ATM classes and Diffserv classes.

   The PEs SHOULD monitor for congestion (by using explicit congestion
   notification, [<a href="#ref-VCCV" title="&quot;Pseudowire Virtual Circuit Connectivity Verification (VCCV)&quot;">VCCV</a>], or by measuring packet loss) in order to ensure
   that the service using the ATM PW may be maintained.  When a PE
   detects significant congestion while receiving the PW PDUs, the PE
   MAY use RM cells for ABR connections to notify the remote PE.

   If the PW has been set up using the protocol defined in [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>],
   then procedures specified in [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>] for status notification can be
   used to disable packet transmission on the ingress PE from the egress
   PE.  The PW may be restarted by manual intervention, or by automatic
   means after an appropriate waiting time.

<span class="h2"><a class="selflink" id="section-16" href="#section-16">16</a>.  Security Considerations</span>

   This document specifies only encapsulations, not the protocols used
   to carry the encapsulated packets across the PSN.  Each such protocol
   may have its own set of security issues [<a href="./rfc4447" title="&quot;Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)&quot;">RFC4447</a>][RFC3985], but those
   issues are not affected by the encapsulations specified herein.  Note
   that the security of the transported ATM service will only be as good
   as the security of the PSN.  This level of security might be less
   rigorous than a native ATM service.









<span class="grey">Martini, et al.             Standards Track                    [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


<span class="h2"><a class="selflink" id="section-17" href="#section-17">17</a>.  Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC4447">RFC4447</a>]  Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
              Heron, "Pseudowire Setup and Maintenance Using the Label
              Distribution Protocol (LDP)", <a href="./rfc4447">RFC 4447</a>, April 2006.

   [<a id="ref-RFC3032">RFC3032</a>]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", <a href="./rfc3032">RFC 3032</a>, January 2001.

   [<a id="ref-RFC4446">RFC4446</a>]  Martini, L., "IANA Allocations for Pseudowire Edge to Edge
              Emulation (PWE3)", <a href="https://www.rfc-editor.org/bcp/bcp116">BCP 116</a>, <a href="./rfc4446">RFC 4446</a>, April 2006.

   [<a id="ref-RFC4385">RFC4385</a>]  Bryant, S., Swallow, G., Martini, L., and D. McPherson,
              "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
              Use over an MPLS PSN", <a href="./rfc4385">RFC 4385</a>, February 2006.

<span class="h2"><a class="selflink" id="section-18" href="#section-18">18</a>.  Informative References</span>

   [<a id="ref-FBATM">FBATM</a>]    ATM Forum Specification af-fbatm-0151.000 (2000), "Frame
              Based ATM over SONET/SDH Transport (FAST)"

   [<a id="ref-TM4.0">TM4.0</a>]    ATM Forum Specification af-tm-0121.000 (1999), "Traffic
              Management Specification Version 4.1"

   [<a id="ref-I.371">I.371</a>]    ITU-T Recommendation I.371 (2000), "Traffic control and
              congestion control in B-ISDN".

   [<a id="ref-I.610">I.610</a>]    ITU-T Recommendation I.610, (1999), "B-ISDN operation and
              maintenance principles and functions".

   [<a id="ref-Y.1411">Y.1411</a>]   ITU-T Recommendation Y.1411 (2003), ATM-MPLS Network
              Interworking - Cell Mode user Plane Interworking

   [<a id="ref-Y.1412">Y.1412</a>]   ITU-T Recommendation Y.1412 (2003), ATM-MPLS network
              interworking - Frame mode user plane interworking

   [<a id="ref-RFC3985">RFC3985</a>]  Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
              Edge (PWE3) Architecture", <a href="./rfc3985">RFC 3985</a>, March 2005.

   [<a id="ref-RFC3916">RFC3916</a>]  Xiao, X., McPherson, D., and P. Pate, "Requirements for
              Pseudo-Wire Emulation Edge-to-Edge (PWE3)", <a href="./rfc3916">RFC 3916</a>,
              September 2004.





<span class="grey">Martini, et al.             Standards Track                    [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


   [<a id="ref-RFC4026">RFC4026</a>]  Andersson, L. and T. Madsen, "Provider Provisioned Virtual
              Private Network (VPN) Terminology", <a href="./rfc4026">RFC 4026</a>, March 2005.

   [<a id="ref-VCCV">VCCV</a>]     Nadeau, T., Pignataro, C., and R. Aggarwal, "Pseudowire
              Virtual Circuit Connectivity Verification (VCCV)", Work in
              Progress, June 2006.

   [<a id="ref-RFC2992">RFC2992</a>]  Hopps, C., "Analysis of an Equal-Cost Multi-Path
              Algorithm", <a href="./rfc2992">RFC 2992</a>, November 2000.

   [<a id="ref-ATM-MPLS">ATM-MPLS</a>] ATM Forum Specification af-aic-0178.001, "ATM-MPLS Network
              Interworking Version 2.0", August 2003.

   [<a id="ref-RFC2914">RFC2914</a>]  Floyd, S., "Congestion Control Principles", <a href="https://www.rfc-editor.org/bcp/bcp41">BCP 41</a>, <a href="./rfc2914">RFC</a>
              <a href="./rfc2914">2914</a>, September 2000.

   [<a id="ref-RFC2684">RFC2684</a>]  Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation
              over ATM Adaptation Layer 5", <a href="./rfc2684">RFC 2684</a>, September 1999.

































<span class="grey">Martini, et al.             Standards Track                    [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


<span class="h2"><a class="selflink" id="section-19" href="#section-19">19</a>.  Significant Contributors</span>

   Giles Heron
   Tellabs
   Abbey Place
   24-28 Easton Street
   High Wycombe
   Bucks
   HP11 1NT
   UK
   EMail: giles.heron@tellabs.com


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


   Dan Tappan
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough, MA 01719
   EMail: tappan@cisco.com


   Eric C. Rosen
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough, MA 01719
   EMail: erosen@cisco.com


   Steve Vogelsang
   ECI Telecom
   Omega Corporate Center
   1300 Omega Drive
   Pittsburgh, PA 15205
   EMail: stephen.vogelsang@ecitele.com


   Gerald de Grace
   ECI Telecom
   Omega Corporate Center
   1300 Omega Drive
   Pittsburgh, PA 15205
   EMail: gerald.degrace@ecitele.com



<span class="grey">Martini, et al.             Standards Track                    [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


   John Shirron
   ECI Telecom
   Omega Corporate Center
   1300 Omega Drive
   Pittsburgh, PA 15205
   EMail: john.shirron@ecitele.com


   Andrew G. Malis
   Verizon Communications
   40 Sylvan Road
   Waltham, MA
   EMail: andrew.g.malis@verizon.com
   Phone: 781-466-2362


   Vinai Sirkay
   Redback Networks
   300 Holger Way
   San Jose, CA 95134
   EMail: vsirkay@redback.com


   Chris Liljenstolpe
   Alcatel
   11600 Sallie Mae Dr.
   9th Floor
   Reston, VA 20193
   EMail: chris.liljenstolpe@alcatel.com


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


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








<span class="grey">Martini, et al.             Standards Track                    [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


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


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


   John Rutemiller
   Marconi Networks
   1000 Marconi Drive
   Warrendale, PA 15086
   EMail: John.Rutemiller@marconi.com


   Rick Wilder
   Alcatel
   45195 Business Court
   Loudoun Gateway II Suite 300
   M/S STERV-SMAE
   Sterling, VA 20166
   EMail: Rick.Wilder@alcatel.com


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
















<span class="grey">Martini, et al.             Standards Track                    [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


Authors' Addresses

   Luca Martini
   Cisco Systems, Inc.
   9155 East Nichols Avenue, Suite 400
   Englewood, CO 80112
   EMail: lmartini@cisco.com


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


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


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


   Jeremy Brayley
   ECI Telecom Inc.
   Omega Corporate Center
   1300 Omega Drive
   Pittsburgh, PA 15205
   EMail: jeremy.brayley@ecitele.com


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








<span class="grey">Martini, et al.             Standards Track                    [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc4717">RFC 4717</a>            Encapsulation for ATM over MPLS        December 2006</span>


Full Copyright Statement

   Copyright (C) The IETF Trust (2006).

   This document is subject to the rights, licenses and restrictions
   contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
   AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
   IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
   PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.






Martini, et al.             Standards Track                    [Page 40]
</pre>