Network Working Group                                     G. Koleyni
                                                          B.St-Denis
Internet Draft                                       Nortel Networks
Expiration Date: January 2002                   R. Park, M. Aissaoui
                                                J. Fischer, M. Bocci
                                                             Alcatel
                                                         A. Siddiqui
                                                    Cable & Wireless
                                                          Sohel Khan
                                                              Sprint
                                                       Cheng C. Chen 
						   NEC America, Inc. 

 
                                                           July 2001
 
 
   Requirements and framework for ATM network interworking over MPLS 
     
        <draft-koleyni-pwe3-atm-over-mpls-01.txt> 
 
Status of this Memo 
    
   This document is  an Internet-Draft and  is in full conformance  with 
   all provisions of Section 10 of RFC2026 [1].  
    
   Internet-Drafts are  working documents  of the  Internet  Engineering 
   Task Force  (IETF), its  areas,  and its  working groups.  Note  that 
   other groups  may  also  distribute working  documents  as  Internet-
   Drafts.  
    
   Internet-Drafts are  draft  documents  valid  for a  maximum  of  six 
   months and may be updated, replaced, or obsoleted by other  documents 
   at  any  time.  It  is  inappropriate  to  use  Internet-  Drafts  as 
   reference material or to cite them other than as "work in progress."  
    
   The  list   of   current   Internet-Drafts   can   be   accessed   at 
   http://www.ietf.org/ietf/1id-abstracts.txt  
    
   The list  of Internet-Draft  Shadow Directories  can  be accessed  at 
   http://www.ietf.org/shadow.html. 
    
    
   Abstract 
    
   Generic requirements  for Pseudo-Wire  Emulation Edge-to-Edge  (PWE3) 
   have  been  described   in  [2].  This   draft  lists  ATM   specific 
   requirements and  provides  encapsulation  format and  semantics  for 
   connecting ATM edge networks through a core packet network using  IP, 
   L2TP or MPLS. This  basic application of ATM interworking will  allow 
   ATM service providers  to take advantage  of new technologies in  the 
   core to provide ATM multi-services. 
    
    
    
    
  
Koleyni, et al.          Expires January 2002                 [Page 1] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
   Table of contents 
    
   1. Introduction      2 
   2. Terminology       3 
   3. Background of ATM encapsulation over PSN  4 
   4. ATM-PSN user plane encapsulation requirements     5 
   5. ATM encapsulation format  6 
   6. Encapsulation modes       7 
   6.1 Cell mode encapsulation  7 
   6.1.1 Single cell encapsulation      7 
   6.1.2 Concatenated cells encapsulation       9 
   6.2  Frame mode encapsulation        11 
   7. IP Packet Switched Networks       13 
   8. L2TP Packet Switched Networks     13 
   9. MPLS Packet Switched Networks     13 
   10. Security Considerations  14 
   11. Signaling and Routing Considerations     14 
   11.1 Signaling       15 
   11.1.1 IP Packet Switched Networks   15 
   11.1.2 L2TP Packet Switched Networks 15 
   11.1.3 MPLS Packet Switched Networks 15 
   11.2 Routing 15 
   12. AAL5 Frame Fragmentation While ATM and MPLS Interwork    15 
   12.1 Procedures at the ATM-PSN direction     16 
   12.2 Procedures at the PSN-ATM direction     16 
   13. Handling of OAM & RM cells at the ATM-PSN INE    17 
   13.1 OAM Cells       17 
   13.2 RM cells        18 
   13.3 Handling of OAM & RM cells at the PSN-ATM PWE   18 
   14. References       18 
   15. Acknowledgement  18 
   16. Author's Addresses       19 
    
1. Introduction 
    
   Packet Switched  Networks (PSNs)  have the  potential  to reduce  the 
   complexity of service provider infrastructures by allowing  virtually 
   any  existing  digital  service   to  be  supported  over  a   single 
   networking  infrastructure.  However,  many  service  providers  have 
   legacy network and Operational  Support System (OSS) capabilities  to 
   support these  existing service  offerings. The  benefit  of PSNs  to 
   this type  of network  operator is  as  a common  core transport  for 
   multiple existing  legacy  networks, not  as unifying  control  plane 
   architecture for all services. 
    
   IP, L2TP and MPLS  as a common transport infrastructures provide  the 
   ability to transparently  carry existing  networking systems and  the 
   evolution to a single networking  core. The benefit of this model  to 
   the service provider is threefold: 
     - Leverage  of the  existing systems  and  services with  increased 
       capacity from a packet switched core. 
     - Existing  network operational  processes and  procedures used  to 
       maintain the legacy services are preserved. 
 Koleyni, et al.         Expires January 2002                 [Page 2] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
     - The  common packet  switched network  infrastructure  is used  to 
       support both  the core capacity  requirements of legacy  networks 
       and  the  requirements  of  new  services,  which  are  supported 
       natively over the packet switched network. 
 
   This draft describes a  simple application of ATM encapsulation  over 
   IP, L2TP  and  MPLS  (ATM-PSN  interworking) intended  to  allow  ATM 
   service providers  to carry  their ATM  multi-services  transparently 
   over a packet switched core.   
    
2. Terminology 
    
   AAL       ATM Adaptation Layer 
   ATMH      ATM specific Header 
   BOM       Beginning Of Message 
   CCM       Continuation Of Message 
   CCM       Continuation Of Message 
   DSL       Digital Subscriber Line 
   EOM       End Of Message 
   L2TP      Layer Two Tunneling Protocol 
   LMDS      Local multipoint Distribution System 
   LSR       Label Switching Router 
   MTU       Maximum Transport Unit 
   NMS       Network Management System 
   OAM       Operations, Administration, and Maintenance. 
   OSS       Operational Support System 
   PCI       Protocol Control Information 
   PNNI      Private Network-Network Interface, An ATM signaling 
             protocol. 
   PSN       Packet Switched Network 
   PTI       Payload Type Identifier 
   PVC       Permanent Virtual Connection, An ATM connection that is 
             provisioning via a network management interface.  The 
             connection is not signaled. 
   PVP       Permanent Virtual Path connection, A PVC that is switched 
             using the ATM VPI. 
   PWE       Pseudo-Wire Endpoint 
   RM        Resource Management, A type of OAM cells. 
   SE        Service Endpoint 
   SPVC      Soft Permanent Virtual Connection, A Soft PVC is 
             provisioned by the network management system specifying 
             only the two endpoints of the connection, and having the 
             connection signaled through the ATM network 
   SSM       Single Segment Message 
   SVC       Switched Virtual Connection 
   SVP       Switched Virtual Path 
   TLSP      Transport LSP 
   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. 
    

 Koleyni, et al.         Expires January 2002                 [Page 3] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
   Cell  Concatenation:  The  process  of  bundling  a  group  of  cells 
   belonging to an ATM VCC or a VPC into a packet. 
    
   Interworking: Interworking is  used to  express interactions  between 
   networks, between  end systems, or  between parts  thereof, with  the 
   aim of providing  a functional entity  capable of supporting an  end-
   to-end  communication.    The  interactions  required  to  provide  a 
   functional entity rely on functions and on the means to select  these 
   functions. [3] 
    
   Interworking  Function   (IWF):  An   Interworking  Function   is   a 
   functional  entity   that   facilitates  interworking   between   two 
   dissimilar networks (e.g.,  ATM &  MPLS, ATM &  L2TP, etc.).   A  PWE 
   performs the IWF function. 
    
   Network Interworking:  In  Network  Interworking, the  PCI  (Protocol 
   Control Information)  of  the protocol  and the  payload  information 
   used in two similar networks are transferred transparently by an  IWF 
   of the PWE across the PSN.  Typically the 
 
3. Background of ATM encapsulation over PSN  
    
   Advances in  networking  technology  in recent  years  allow  service 
   providers more choice and flexibility in building their networks  and 
   deploying their  services.  Service  providers envision  the  use  of 
   multiple technologies in  their networks,  and ATM is  often not  the 
   sole technology  used  in  the  network  core.  There  exist  network 
   topologies that rely  on packet  transport in the  core based on  IP, 
   L2TP and MPLS.  
    
   In these kinds of network topologies,  ATM is present on the edge  as 
   a protocol  that brings multi-services  into the  packet core.  Frame 
   relay services, voice  services, and  circuit emulation services  are 
   all currently carried  over ATM. ATM  is also the current  underlying 
   technology  for  DSL  (Digital  Subscriber  Line)  and  LMDS   (Local 
   Multipoint Distribution System)  access applications.  An example  of 
   such a  network is  shown in Figure  1. ATM  connections are  carried 
   transparently over pseudo-wires from  one edge of the packet core  to 
   another  one  (PWE1  to  PWE2).  The  PSNs  are  primarily  used   as 
   transparent  tunnels   for  the   pseudo-wires.  The   role  of   the 
   interworking function  at each  edge of the  core is  to multiplex  a 
   number of ATM  connections (VCCs,  VPCs or both)  into a  pseudo-wire 
   and  originate  the  pseudo-wire.  The  pair  of  pseudo-wires   (bi-
   directional connectivity)  between any  two interworking  devices  at 
   the  edge  of  the  core  is  either  established  using  a   network 
   management system or is initiated through signaling. 
    
    
    
    
    
    
    
 Koleyni, et al.         Expires January 2002                 [Page 4] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
    
      ATM                                            ATM 
      Multi-services         Packet Switched Core    Multi-services 
      Network                Network (MPLS)          Network 
    
                        Edge LSR               Edge LSR 
           VCC             ************************        VCC 
      SE ---+-------+------+       Forward LSPs   +--------+------+- SE 
                           *=======+=======+=====>* 
                           *<======+=======+======* 
      SE ---+-------+------+      Backward LSPs   +--------+------+- SE 
           VPC             *                      *        VPC 
                           ************************ 
                          PWE1                   PWE2 
    
   Figure 1: Example of ATM encapsulation using MPLS as Pseudo-wire 
    
    
   Transparency in this context means that ATM multi-services should  be 
   carried over the packet core unaffected. In other words, the  ATM-PSN 
   interworking function is characterized by: 
    
   a. ATM  layer  protocols  are  not  terminated  at  the   pseudo-wire 
      endpoints. 
   b. ATM and PSN user data planes are interworked. 
   c. ATM  control  plane   information  (signaling  channels,   routing 
      control  channels) and  layer  management plane  information  (OAM 
      cells) are tunneled through the PSN from one pseudo-wire  endpoint 
      to the other pseudo-wire endpoint. 
    
   The pair of associated  unidirectional paths or pseudo-wires  between 
   the PWEs is seen as a bi-directional link by the ATM edge networks. 
    
4. ATM-PSN user plane encapsulation requirements 
    
   The following requirements  are to  complement requirements  provided 
   in [2]  to  cover ATM  encapsulation  over PSNs.  The ATM  Forum  has 
   adopted these  requirements as  a basis  for the  development of  the 
   ATM-MPLS network interworking specification [8]: 
    
  a.    The  ability to multiplex  multiple ATM connections (i.e.,  VPCs 
        and/or VCCS) into a pseudo-wire. 
  b.    Support for  the traffic contracts and the QoS commitments  made 
        to  the ATM connections  (e.g., relationship to underlying  MPLS 
        Diffserv capabilities). 
  c.    The ability to transparently carry all AAL types. 
  d.    The ability to  transparently carry all OAM cells, including the 
        support  for proper operation of  OAM PM cells and OAM  security 
        cells. 
  e.    Transport of Resource Management (RM) cells. 
  f.    Transport  of   Cell  Loss  priority  (CLP)  and  Payload   Type 
        Indicator (PTI) information from the ATM cell header. 

 Koleyni, et al.         Expires January 2002                 [Page 5] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
  g.    The  ability to encapsulate  a single ATM  cell within a  single 
        packet with a reasonable overhead. 
  h.    The  option to  concatenate  multiple ATM  cells into  the  same 
        packet 
  i.   The option  to reassemble an  AAL5 PDU into  one or more  packets 
       for bandwidth efficiency. 
   
5. ATM encapsulation format 
 
   This section describes the general encapsulation format for ATM  over 
   PSN pseudo-wires,  IP, L2TP,  or MPLS.  The  specifics pertaining  to 
   each specific packet technology are covered in Section 7, 8, and 9.    
    
   Figure 2 provides  a general  format for encapsulation  of ATM  cells 
   (or frames) into  packets. The interworking  Function (IWF) uses  the 
   PSN Transport header (PSN-TH),  to identify each direction of an  ATM 
   connection. This header allows the IWF to access context  information 
   for the  connection.  As  an example,  the  context may  contain  the 
   information regarding connection type  such as VCC or VPC or  VPI/VCI 
   value that need to be inserted  into the ATM cell header in the  PSN-
   to-ATM direction. 
    
    
    
       0      1      2      3      4      5      6      7 
   +------+------+------+------+------+------+------+------+ 
   |           PSN Transport Header (4 octets)             | 
   |                                                       | 
   +------+------+------+------+------+------+------+------+ 
   |              Pseudo-Wire Header (4 octets)            | 
   |                                                       | 
   +------+------+------+------+------+------+------+------+ 
   |         ATM Specific Header (1 or 3 octets)           | 
   |                                                       | 
   +------+------+------+------+------+------+------+------+ 
   |                    ATM Payload                        | 
   |                                                       | 
   +------+------+------+------+------+------+------+------+ 
            
   Figure 2: General format for ATM encapsulation over PSNs 
 
    
   PSN Transport Header  
   -------------------- 
    
   The PSN transport header  depends on the packet technology: IP,  L2TP 
   or MPLS.   This  header is  used  to transport  the encapsulated  ATM 
   information through  the  packet  switched  core.    It  may  contain 

 Koleyni, et al.         Expires January 2002                 [Page 6] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
   information to  transport  the  packet  to  the  remote  Pseudo  Wire 
   Endpoint as  well  as  information to  identify  the payload  of  the 
   packet. 
    
   Pseudo Wire Header  
   ------------------ 
    
   For some PSNs it may be useful to address specific issues such as packet
   reordering or minimum length limitations. In such cases additional 
   information may need to be conveyed in the Pseudo-Wire Header.
    
   ATM Specific Header (ATMH) 
   -------------------------- 
    
   The ATM Specific  Header (ATMH)  is inserted before  the ATM  payload 
   and identifies whether encapsulation  was performed for ATM cells  or 
   AAL5 frames.  In  addition, some  elements  of the  protocol  control 
   information (PCI) constitute parts of this header.  
    
   ATM Payload 
   ----------- 
    
   The ATM payload octet group is the payload of the service that is 
   being encapsulated. 
    
6. Encapsulation modes 
 
   Two modes of encapsulation are considered, cell mode and frame mode.  
    
6.1 Cell mode encapsulation  
    
   In this mode, a single ATM cell or many concatenated ATM cells are 
   encapsulated in a single packet.  
 
6.1.1 Single cell encapsulation 
    
   Figure 3 shows  structure of the ATM  specific header for single  ATM 
   cell encapsulation.   Description of ATM  specific header fields  for 
   single cell encapsulation is given below: 
    
 
         0      1      2      3      4      5      6      7 
      +------+------+------+------+------+------+------+------+ 
      | MODE |VCIP=1|    RES      |        PTI         | CLP  |  
      +------+------+------+------+------+------+------+------+ 
      |                     VCI (2 octets)                    | 
      +------+------+------+------+------+------+------+------+ 
      /               Payload (48 octets)                     / 
      /                                                       / 
      +------+------+------+------+------+------+------+------+ 
                        Figure 3-a (for a VPC) 
    

 Koleyni, et al.         Expires January 2002                 [Page 7] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
    
         0      1      2      3      4      5      6      7 
      +------+------+------+------+------+------+------+------+ 
      | MODE |VCIP=0|    RES      |        PTI         | CLP  |  
      +------+------+------+------+------+------+------+------+ 
      /               Payload (48 octets)                     / 
      /                                                       / 
      +------+------+------+------+------+------+------+------+ 
                        Figure 3-b (for a VCC) 
    
   Note: bit 0 is the most significant bit 
     
   Figure 3: ATM specific header and payload for transport of a single 
   ATM cell for a VPC and a VCC  
     
   MODE (bit 0) 
   ------------ 
    
   This field is set to 0 to indicate cell mode.   
    
   VCI Present (bit 1) 
   ------------------- 
    
   This bit is set to 1 when VCI field is present, set  to 0 when 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 2 & 3) 
   --------------------- 
    
   These bits are reserved for future use. They must be set to 0 when 
   transmitted and must be ignored upon receipt. 
    
   PTI (bits 4-6) 
   -------------- 
    
   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. 
    
   CLP (bit 7) 
   ----------- 
     
   Cell Loss  Priority (CLP)  field, which  indicates CLP  value of  the 
   encapsulated cell is  set to the  value of the  CLP field of the  ATM 
   cell. 
     
   VCI: The VCI value, if present, is the same as that of the cell.  
    
   Payload: The payload consists of one ATM cell, excluding the header 
   (i.e., 48 octets).  
    
 Koleyni, et al.         Expires January 2002                 [Page 8] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
6.1.2 Concatenated cells encapsulation  
 
   Concatenation is the  act of  encapsulating, one after  the other,  a 
   group of cells  belonging to the  same VCC or  VPC into a packet  for 
   more bandwidth efficiency.  In the  case of a  VPC, the  concatenated 
   cells may belong to different VCCs. 
    
   The interworking functions at the edge of the ATM-PSN network  (i.e., 
   PWEs) need to be  configured via the NMS (Network Management  system) 
   or via  signaling  in  order  to  be able  to  transmit  and  receive 
   concatenated cells in  a packet. In  the case of misconfiguration,  a 
   receiver that  is not configured  to support  cell concatenation  may 
   discard a received  payload with a size  larger than 48 bytes  (i.e., 
   payload of a single cell).   
    
   Figure 4 shows structure of the ATM specific header for  concatenated 
   cells encapsulation. Description  of ATM  specific header fields  for 
   concatenated cells encapsulation is given below:  
    
      0      1      2      3      4      5      6      7 
   +------+------+------+------+------+------+------+------+ 
   | MODE |VCIP=1|     RES     |        PTI         | CLP  | 
   +------+------+------+------+------+------+------+------+ 
   |                     VCI (2 octets)                    | 
   +------+------+------+------+------+------+------+------+ 
   /               Payload (48 octets)                     / 
   /                                                       / 
   +------+------+------+------+------+------+------+------+ 
   /                                                       / 
   /                                                       / 
   +------+------+------+------+------+------+------+------+ 
   | MODE |VCIP=1|     RES     |        PTI         | CLP  | 
   +------+------+------+------+------+------+------+------+ 
   |                     VCI (2 octets)                    | 
   +------+------+------+------+------+------+------+------+ 
   /               Payload (48 octets)                     / 
   /                                                       / 
   +------+------+------+------+------+------+------+------+ 
                 Figure 4-a (for a VPC) 
    
      0      1      2      3      4      5      6      7 
   +------+------+------+------+------+------+------+------+ 
   | MODE |VCIP=0|     RES     |        PTI         | CLP  | 
   +------+------+------+------+------+------+------+------+ 
   /               Payload (48 octets)                     / 
   /                                                       / 
   +------+------+------+------+------+------+------+------+ 
   /                                                       / 
   /                                                       / 
   +------+------+------+------+------+------+------+------+ 
   | MODE |VCIP=0|     RES     |        PTI         | CLP  | 
   +------+------+------+------+------+------+------+------+ 

 Koleyni, et al.         Expires January 2002                 [Page 9] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
   /               Payload (48 octets)                     / 
   /                                                       / 
   +------+------+------+------+------+------+------+------+ 
    
               Figure 4-a (for a VCC) 
    
    
   Note: bit 0 is the most significant bit 
     
   Figure 4 ATM specific header and the payload for transport of 
   concatenated ATM cells of a VPC and a VCC 
 
   MODE (bit 0) 
   ------------ 
    
   This field is set to 0 to indicate cell mode.   
    
   VCI Present (bit 1) 
   ------------------- 
    
   This bit is set to 1 when VCI field is present, set  to 0 when no VCI 
   field is present. In the case  of a VCC, the VCI is not required  and 
   this field is set to 0.   
    
   When cell concatenation is enabled, by default the value of the  VCIP 
   field should not change within the same packet. Optionally, if  cells 
   subsequent to the  first cell in  the packet are  of the same VCC  as 
   the first cell,  then VCIP for  these cells may be  set to 0 and  the 
   VCI not  transmitted. If  the  VCI of  subsequent cell  differs  from 
   either the VCI of the first cell or the previous cell in  the packet, 
   or it is the first cell in the packet, then the VCIP  shall be set to 
   1 and the VCI transmitted. 
    
   REServed (bits 2 & 3) 
   --------------------- 
    
   These bits are reserved  for future use. They  must be set to 0  when 
   transmitting and must be ignored upon receipt. 
 
   PTI (bits 4-6) 
   -------------- 
   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. 
    
   CLP (bit 7) 
   ----------- 
     
   Cell Loss  Priority (CLP)  field, which  indicates CLP  value of  the 
   encapsulated cell is  set to the  value of the  CLP field of the  ATM 
   cell. 
    
   VCI: The VCI value, if present, is the same as that of the cell.  
 Koleyni, et al.         Expires January 2002                [Page 10] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
    
   Payload: The total payload consists of up to N (>1) contiguous  cells 
   payloads (i.e., Nx48 octets). The  value of N needs to be  configured 
   via the NMS or via signaling.  The payload does not include the  cell 
   header. The value of N is  limited by the smallest link MTU  (Maximum 
   Transport Unit) in the PSN. 
 
 6.2  Frame mode encapsulation  

   This mode is used  for carrying a whole  AAL5 PDU in the packet.  The 
   whole AAL5  PDU  is  comprised of  its  payload, padding,  and  whole 
   trailer, which include  CPCS-UU (CPCS  User-to-User indication),  CPI 
   (Common Part Indicator),  Length and  CRC (Cyclic Redundancy  Check). 
   ATM cells of an AAL5 PDU are re-assembled and the resulting AAL5  PDU 
   is encapsulated in a packet. 
    
   Figure 5  shows  structure  of ATM  specific  header for  frame  mode 
   encapsulation. Description  of ATM  specific header  fields for  AAL5 
   frame encapsulation is given below: 
    
       0      1      2      3      4      5      6      7 
   +------+------+------+------+------+------+------+------+ 
   | MODE |VCIP=1|     RES     |   FRAG      | EFCI | CLP  | 
   +------+------+------+------+------+------+------+------+ 
   |                     VCI (2 octets)                    | 
   +------+------+------+------+------+------+------+------+ 
   /                          Payload                      / 
   /                                                       / 
   +------+------+------+------+------+------+------+------+ 
                   Figure 5-a (for a VPC) 
    
       0      1      2      3      4      5      6      7 
   +------+------+------+------+------+------+------+------+ 
   | MODE |VCIP=0|     RES     |   FRAG      | EFCI | CLP  | 
   +------+------+------+------+------+------+------+------+ 
   /                          Payload                      / 
   /                                                       / 
   +------+------+------+------+------+------+------+------+ 
                    Figure 5-b (for a VCC) 
    
   Note: bit 0 is the most significant bit 
     
   Figure 5: ATM specific header and the payload for AAL5 frame 
   transport of VPCs and VCCs  
    
   MODE (bit 0) 
   ------------ 
    
   This field is set to 1 to indicate frame mode.   
    
    
    
    
 Koleyni, et al.         Expires January 2002                [Page 11] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
   VCI Present (bit 1) 
   ------------------- 
    
   The VCIP bit is set to 1 when VCI field is present, set to 0 when no 
   VCI field is present. 
    
   REServed (bits 2 & 3) 
   --------------------- 
    
   These bits are reserved for future use. They must be set to 0 when 
   transmitted and must be ignored upon receipt. 
    
   FRAGmentation (bits 4-5) 
   ------------------------ 
    
   The FRAG field provides information about frame fragmentation. It  is 
   set to (10 for BOM, Beginning Of Message), (00 for COM,  Continuation 
   Of Message), (11  for SSM, Single Segment  Message) and (01 for  EOM, 
   End Of  Message). Fragmentation  is a function  that may  be used  to 
   subdivide the payload into a series of fragments and to reassemble  a 
   sequence of  such  fragments to  reconstitute the  original  payload. 
   Fragmentation may be  enabled by network  management system (NMS)  or 
   via signaling.  If fragmentation  is disabled,  frames received  with 
   the FRAG bit set to any  value other than 11 (SSM) are not valid  and 
   may be discarded.  
    
   EFCI (bit 6) 
   ------------  
    
   ATM-to-PSN direction: The EFCI state  of a AAL5 PDU or AAL5  fragment 
   is set to  1 if the last  cell of the AAL5  PDU or AAL5 fragment  has 
   its EFCI bit set to 1, it is set to 0 otherwise. 
    
   PSN-to-ATM direction: The EFCI bit of all constituent cells of the 
   AAL5 PDU or AAL5 fragment is set to the value of the EFCI field in 
   the ATM specific header.  
    
   CLP (bit 7) 
   ----------- 
    
   ATM-to-PSN direction: The CLP state of the AAL5 PDU or AAL5  fragment 
   is set to  1 if  any of the  AAL5 PDU   or AAL5 fragment  constituent 
   cells has its CLP bit set to 1.  
    
   PSN-to-ATM direction: The CLP bit  of all constituent cells of a  the 
   AAL5 PDU or  AAL5 fragment is  set to the value  of the CLP field  in 
   the ATM-MPLS tunneling specific header. 
    
   PAYLOAD:   The payload consists  of the  re-assembled AAL5  CPCS-PDU, 
   including the AAL5 padding and trailer or the AAL5 fragment. 
    
    
    
 Koleyni, et al.         Expires January 2002                [Page 12] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
  7. IP Packet Switched Networks 

   This section is for further study. 
 

  8. L2TP Packet Switched Networks 

   This section is for further study. 
 

  9. MPLS Packet Switched Networks 
 

          0      1      2      3      4      5      6      7  
      +------+------+------+------+------+------+------+------+  
      |           MPLS Transport Header (4 octets)            |  
      |                                                       |  
      +------+------+------+------+------+------+------+------+  
      |           MPLS Pseudo-Wire Header (4 octets)          |  
      |                                                       |  
      +------+------+------+------+------+------+------+------+  
      |        ATM Specific Header (1 or 3 octets)            |  
      |                                                       |  
      +------+------+------+------+------+------+------+------+  
      |                    ATM Payload                        |  
      |                                                       |  
      +------+------+------+------+------+------+------+------+  
         Figure 6: Encapsulation format for ATM over MPLS 
    
    
   MPLS Transport Header (MPLS-TH)  
   -------------------------------   
        
   The 4-octet MPLS Transport  Header identifies a LSP (i.e.,  transport 
   LSP, TLSP)  used to transport  traffic between  two ATM-MPLS  Pseudo-
   Wire endpoints (PWEs).  This  header is used to switch the  transport 
   LSP between core  LSRs. Setting of the  fields in the MPLS  Transport 
   Header is beyond the scope of this draft.  
        
   Note that structure of the shim header is described in IETF RFC  3032  
   [4].   
        
   MPLS Pseudo-Wire Header (MPLS-PWH)  
   ---------------------------------  
        
   The  4-octet  MPLS-PWH   uniquely  identifies  one  Pseudo-Wire   LSP 
   (PWLSP), carried inside  a MPLS transport  LSP  (TLSP). The  MPLS-PWH 
   has the structure of a standard MPLS shim header.  More than  one PWH 
   may be supported by one TLSP.  
        
   The interworking function  provides the  association between the  ATM 
   connection and MPLS  LSP by means  of the 20-bit  label field of  the 

 Koleyni, et al.         Expires January 2002                [Page 13] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
   MPLS-PWH.  In  this  association,  in  the  ATM-to-MPLS  direction  a 
   translation of VCI/VPI to the 20-bit label field is performed,  while 
   in the MPLS-to-ATM direction the 20-bit label field is translated  to 
   VCI/VPI of  the ATM  connection.   This  association is  signaled  or 
   provisioned between  the two  interworking functions  at  Pseudo-Wire 
   Endpoints (PWEs).   
        
   Since PW LSP is unidirectional, for the case of bi-directional ATM  
   VCCs, there will be two  different PWLSPs, one for each direction  of 
   the connection.  The MPLS-PWH  for these  PWLSPs  may have  different 
   label field values.  
     
   The Label Field: The  IWF includes the context information  providing 
   the association between the ATM  connection and MPLS LSP by means  of 
   the 20-bit label field of the MPLS Pseudo-Wire Header.    
        
   The context of  the label field implies  connection type  (i.e.,  VCC 
   or VPC), VPI value  to be inserted in  the ATM cells in the  MPLS-to-
   ATM direction.    For  VCC connection  types,  the  VCI value  to  be 
   inserted in the ATM cells in the MPLS to ATM direction.  
               
     ATM-to-MPLS  direction:   In  the   ATM-to-MPLS  direction        a 
     translation of  VCI/VPI to  the 20-bit  label  field is  performed. 
     This association  is  signaled or  provisioned  between a  pair  of 
     PWEs.   
             
     MPLS-to-ATM direction:  In  the  MPLS-to-ATM direction  the  20-bit 
     label field is  translated to VCI/VPI  of the ATM connection.  This 
     association is  signaled  or provisioned  between  a pair  of  peer 
     PWEs.   
        
   Setting of The EXP and TTL fields are for further study.  
        
   The S bit is set to 1 to indicate the bottom of the label stack.  
     
   The MPLS-PWLSP  is  not visible  to  the LSRs  within the  MPLS  core 
   network.    
    
    
10. Security Considerations 
 
   This draft does not introduce any new security considerations to IP, 
   L2TP or MPLS.  
    
11. Signaling and Routing Considerations 
 
   Encapsulation methods for ATM cell and AAL5 frame at the ATM-MPLS 
   interworking points are discussed in previous sections.  The 
   following parameters are related to this interworking: 
   - Exchange of pseudo-wire information between PWEs 
   - VCC or VPC connection 
   - Mode of encapsulation 
   - Enabling of concatenation 
 Koleyni, et al.         Expires January 2002                [Page 14] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
   - Maximum number of concatenated cells 
   - Maximum MTU size per transport LSP 
   - Fragmentation choice (stating either fragmentation is performed or   
   not) 
   - Presence or absence of VCI in the ATM specific header 
   -      VCIP optimization capability for VPCs 
         
11.1 Signaling  
    
   Section  6   has   listed   parameters  involved   in   the   ATM-PSN 
   interworking, majority  of  them  are carried  in  the  encapsulation 
   format or derived from the context.  
    
11.1.1 IP Packet Switched Networks 
    
   This section is for further study. 
    
11.1.2 L2TP Packet Switched Networks 
    
   This section is for further study. 
    
11.1.3 MPLS Packet Switched Networks 
    
   The only parameter, which needs  to be signaled, is the 20-bit  field 
   in the MPLS pseudo-wire header. 
    
   In order to set up a ATM switched connection over the MPLS  transport 
   LSP, the PWE at  the edge of the  MPLS network need to negotiate  the 
   values of the  MPLS pseudo-wire  header for each  direction and  then 
   bind them to  the corresponding  VPI/VCI values on  the outgoing  ATM 
   interfaces 
    
11.2 Routing             

   ATM SVC and  SVP calls may  be set up using  PNNI.  The PNNI RCC  and 
   signaling channels  are provisioned  across the  PSN.  The  transport 
   LSP between the  2 ATM-PSN IWF  is seen as a  single hop link by  the 
   PNNI routing  protocol.  The  ATM-PSN interworking  network  element, 
   (i.e., PWE)  is  able  to  advertise link  state  changes,  including 
   bandwidth changes, as  done in  a regular PNNI  link. It is  expected 
   that the PWE  flood information about  the changes to  administrative 
   state of the tunnel, the bandwidth available, etc., to both sides  of 
   the ATM network.  
    
12. AAL5 Frame Fragmentation While ATM and MPLS Interwork 
 
   It may not always be possible  to reassemble a full AAL5 frame at  an 
   IWF. This  may  be  due to  the  AAL5  frame being  too  long  (i.e., 
   exceeding  the  MTU  size)  or  if  OAM  PM  or  security  cells  are 
   interleaved within cells  of an  AAL5 frame and  there is  a need  to 
   maintain their relative  order. In  these cases, the  AAL5 frame  can 
   optionally be fragmented and  sent. Fragmentation shall always  occur 
   at the cell boundaries. 
 Koleyni, et al.         Expires January 2002                [Page 15] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
    
   By default, fragmentation  is disabled. In  this case, the FRAG  bits 
   of the  interworking specific  header are  always set  to 11  (Single 
   Segment Message). Thus,  frames received  with the FRAG  bits set  to 
   any value other than 11 (SSM) are not valid and may be discarded. 
    
   If fragmentation  is enabled, then  the procedures  described in  the 
   following subsections shall be followed. 
 
12.1 Procedures at the ATM-PSN direction 
 
   The following procedures shall apply at the transmitting side in the 
   PWE while reassembling the AAL5 frames: 
 
   Fragmentation disabled: 
 
   1. The FRAG bits  of the MPLS pseudo-wire  header shall be set to  11 
      (SSM, Single Segment Message). 
   2. Setting of the EFCI and  CLP bits of the fragment shall be as  per 
      section 6. 
 
   Fragmentation enabled: 
 
   1. The FRAG bits shall be set to 10 (BOM, Beginning Of Message), if 
      this is the first fragment (AUU is also =0). 
   2. For the following fragments and if the AUU is equal to 0, then 
      FRAG bits shall be to 00 (COM, Continuation Of Message).  
   3. If AUU is 1 (i.e., last SAR-PDU of AAL5 CPCS-PDU) the FRAG bits 
      shall be set to 01 (EOM, End Of Message).  
   4. Setting of the EFCI and CLP bits of the fragment shall be as per 
      section 6. 
    
   Note: AUU (ATM user to ATM user indication) is covered in section 
   2.2.4 of ITU-T Recommendation I.361 [5]. 
    
 
12.2 Procedures at the PSN-ATM direction 
 
   At the PSN-ATM PWE, ATM cells are constructed from an AAL5 frame or 
   an AAL5 fragment.  The following shall apply: 
 
   1. The 3-bits PTI field of each cell header is constructed as: 
       a. The left most bit is set to zero, indicating user data cell 
       b. The EFCI value of the ATM specific header of the fragment 
          should be put in the middle bit of the PTI 
       c. The right most bit of the PTI is set to 0 in the case that 
          FRAG bits are set to 10 (BOM) or 00 (COM).  
       d. The right most bit of the PTI is set to 1 in the case that 
          FRAG bits are set to 01 (EOM) or 11 (SSM). 
   2. The CLP bit of the cell header is set to the value of CLP in the 
      ATM specific header.    
 

 Koleyni, et al.         Expires January 2002                [Page 16] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
13. Handling of OAM & RM cells at the ATM-PSN INE 
 
13.1 OAM Cells 
 
   Several types  of  OAM cells  are  defined in  [6]. These  cells  are 
   categorized as fault  management cells (e.g.,  AIS, RDI, CC and  LB), 
   performance monitoring  and reporting  both in  forward and  backward 
   direction, security OAM cells  and APS cells for carrying  protection 
   switching information. 
    
   At the ATM layer two types of OAM cell flows are identified,  F4 (OAM 
   flow on  virtual path  level) and  F5  (OAM flow  on virtual  channel 
   level). So, all OAM cells discussed in this specification are  either 
   F4 or F5  OAM cells.   F4 and F5 OAM  cells are either segment  flows 
   for communicating OAM related information within the boundary of  the 
   VPC or  VCC or are  end-to-end for  information regarding  end-to-end 
   VPC or VCC operations. 
    
   OAM  and  RM  cells  are  always  encapsulated  with  the  cell  mode 
   encapsulation. In cell  mode, the  OAM and RM  cells are treated  and 
   encapsulated as any  other cell. In  frame mode, any  OAM or RM  cell 
   arriving between AAL5 frames is simply encapsulated in cell mode.  In 
   frame  mode  with  fragmentation  enabled,  OAM  or  RM  cells   that 
   interrupt the reassembly  of an AAL5  frame invoke the  fragmentation 
   procedures for the AAL5 frame.  The OAM or RM cell is sent  after the 
   AAL5 fragment it interrupted.  
    
   In frame  mode with  fragmentation  disabled, OAM  or RM  cells  that 
   interrupt the  reassembly of  an  AAL5 frame  are sent  upon  receipt 
   ahead of  the  AAL5  frame  without interruption  of  the  reassembly 
   process.  Note that in this case PM or security OAM processes may  be 
   invalidated.  
    
   General functional  architecture of an  ATM network  element (NE)  is 
   provided in Figure 4-2/I.732 of ITU-T Recommendation I.732 [7].  This 
   functional model  is used for  discussion regarding  treatment of  F4 
   and F5 OAM cell  while AAL5 frames are  being reassembled and an  OAM 
   cell needs to be inserted.  
      
   When reassembling AAL5 frames at the ATM-PSN interworking point,  the 
   interworking function  can  either  perform  switching at  VP  or  VC 
   level. If the PWE  does perform VP switching,  it may be the VP  link 
   termination or the  VPC termination point. In  this case only F4  OAM 
   cells can be processed.    If INE  does perform VC switching, it  may 
   be the  VC link  termination or the  VCC termination  point. In  this 
   case both F4 and  F5 OAM cells may  need to be processed. The F4  OAM 
   cells are processed at  the VP link termination  and are not seen  at 
   the VC link termination. 
    
   According to the  functional architecture of [7],  in the case of  VC 
   switching by  the PWE  and  when VCCs  are present,  the  termination 
   point before  service  access point  (SAP)  to AAL  layer is  the  VC 

 Koleyni, et al.         Expires January 2002                [Page 17] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
   termination point  at  which only  F5  OAM cell  can be  inserted  or 
   extracted.   For  this case to treat  F5 OAM cells, interworking  for 
   single ATM cell  is considered  (i.e., switching from  frame mode  to 
   cell mode) to  transmit this  cell. Following processing  of the  OAM 
   cell, fragmentation of AAL5 PDU shall be resumed. 
    
   In the case  of VP switching  by the INE  and when VCCs are  present, 
   the termination point before service access point (SAP) to AAL  layer 
   is the  VC  termination  point at  which  only  F5 OAM  cell  can  be 
   inserted or extracted.  Also, in  the case of  VP switching and  when 
   VCCs are present in the VPC  (i.e., both F4 and F5  OAM cells need to 
   be carried in the interworking LSP), frame mode encapsulation  should 
   not be used to carry such a VPC.  
    
   If there is no VC level functionality present in the PWE,  processing 
   of F4 OAM cells should be  done in the same way as would be done  for 
   F5 OAM cells as described above.   
    
13.2 RM cells 
    
   RM cells use PTI value of 110 [6] and are treated the same way as 
   OAM cells in order to keep their priorities. 
    
13.3 Handling of OAM & RM cells at the PSN-ATM PWE 
 
   Since OAM or RM cells are sent as single encapsulated cells, they 
   will be treated at the PSN-ATM pseudo-wire endpoint (PWE) in the 
   same way as any other cell.  
    
14. References 
    
   [1]  IETF RFC 2026 (October 1996): The Internet Standards Process-
        Revision 3, BCP 9 
   [2]  IETF draft-ietf-pwe3-requirements-00.txt, work in progress, (17 
        May 2001): Requirements for pseudo Wire Emulation Edge-to-Edge 
        (PWE3) 
   [3]  ITU-T Recommendation I.510 (March 1993): Definitions and 
        general principles for ISDN interworking 
   [4]  IETF RFC 3032 (January 2000): MPLS Label Stack Encoding 
   [5]  ITU-T Recommendation I.361 (February 1999): B-ISDN ATM layer 
        specification 
   [6]  ITU-T Recommendation I.610 (February 1999): B-ISDN operation 
        and maintenance principles and functions 
   [7]  ITU-T Recommendation I.732 (March 1996): Functional 
        characteristics of ATM equipment 
   [8]  ATM Forum, str-aic-mpls-niwf-01.01 (July 2001), ATM-MPLS 
        Interworking: Network Interworking 
    
15. Acknowledgement 
 
The authors like to acknowledge the contribution to this work by Dr. 
Khalid Ahmad. 

 Koleyni, et al.         Expires January 2002                [Page 18] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
 
16. Author's Addresses 
    
   Ghassem Koleyni   
   Nortel Networks 
   P O Box 3511, Station C Ottawa, Ontario, 
   K1Y 4H7 Canada 
   Email: ghassem@nortelnetworks.com 
 
   Bernard St-Denis 
   Nortel Networks 
   P O Box 3511, Station C Ottawa, Ontario, 
   K1Y 4H7 Canada 
   Email: bernie@nortelnetworks.com 
    
   Robin Park 
   Alcatel Networks Corporation 
   600 March Road 
   Kanata, Ontario, 
   K2K 2E6 Canada 
   Email: robin.park@alcatel.com 
    
   Mustapha Aissaoui 
   Alcatel Networks Corporation 
   600 March Road 
   Kanata, Ontario, 
   K2K 2E6 Canada 
   Email: mustapha.aissaoui@alcatel.com 
    
   Matthew Bocci  
   Alcatel Telecom Ltd. 
   Voyager Place, Shoppenhangers Rd 
   Maidenhead, Berks,  
   UK  SL6 2PJ 
   Email: Matthew.bocci@alcatel.com 
    
   John Fischer 
   Alcatel Networks Corporation 
   600 March Road 
   Kanata, Ontario, 
   K2K 2E6 Canada 
   Email: john.fischer@alcatel.com 
    
   Sohel Khan 
   Sprint 
   7171 W 95th Street  
   Overland Park, KS 66212 
   Email: sohel.khan@mail.sprint.com 
    
    
    
    
    
 Koleyni, et al.         Expires January 2002                [Page 19] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
   Adeel A. Siddiqui 
   Cable & Wireless 
   11700 Plaza America Drive 
   Reston, Virginia 20190, USA 
   Email: adeel.siddiqui@cwusa.com 


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














































 Koleyni, et al.         Expires January 2002                [Page 20] 
 Internet Draft   draft-koleyni-pwe3-atm-over-mpls-01.txt    July 2001  
 
    
 Full Copyright Statement 

   "Copyright (C)  The  Internet Society  (date). All  Rights  Reserved. 
   This document and translations of  it may be copied and furnished  to 
   others, and derivative works that comment on or otherwise explain  it 
   or assist in  its implementation may  be prepared, copied,  published 
   and distributed,  in whole  or in  part, without  restriction of  any 
   kind, provided  that the above  copyright notice  and this  paragraph 
   are included on all  such copies and derivative works. However,  this 
   document itself may not be modified  in any way, such as by  removing 
   the copyright notice or  references to the Internet Society or  other 
   Internet  organizations,  except  as   needed  for  the  purpose   of 
   developing Internet  standards  in  which  case  the  procedures  for 
   copyrights  defined  in  the  Internet  Standards  process  must   be 
   followed, or as required to translate it into 
 
































 Koleyni, et al.         Expires January 2002                [Page 21]