G. Koleyni B.St-Denis Internet Draft Nortel Networks Expiration Date: February 2002 R. Park, M. Aissaoui J. Fischer, M. Bocci Alcatel A. Siddiqui Cable & Wireless Sohel Khan Sprint Cheng C. Chen NEC America, Inc. John Rutemiller Marconi Networks Enrique Cuevas AT&T Labs August 2001 Requirements and framework for ATM network interworking over MPLS 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 Koleyni, et al. Expires February 2002 [Page 1] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 ATM service providers to take advantage of new technologies in the core to provide ATM multi-services. Table of contents 1. Introduction 2 2. Terminology 3 3. Background of ATM encapsulation over PSN 4 4. ATM-PSN user plane interworking requirements 6 5. Encapsulation format 6 6. IP Packet Switched Networks User Plane Interworking Aspects 7 7. L2TP Packet Switched Networks User Plane Interworking Aspects 7 8. MPLS Packet Switched Networks User Plane Interworking Aspects 7 8.1. ATM encapsulation format 7 8.2. Encapsulation modes 9 8.2.1 Single cell encapsulation 9 8.2.2 Concatenated cells encapsulation 11 8.2.3 Frame mode encapsulation 13 8.3 Configurable parameters 15 8.4 Fragmentation 15 8.4.1 Procedures in the ATM-to-MPLS direction 16 7.4.2 Procedures in the MPLS-to-ATM direction 16 8.5 ATM OAM and RM Cells 16 8.5.1 ATM-to-MPLS Direction 16 8.5.2 MPLS-to-ATM Direction 17 8.6 Interworking transparency 18 8.6.1 General 18 8.6.2 Specific to Frame Mode Encapsulation 18 9. IP Packet Switched Networks Control Plane interworking Aspects 18 10. L2TP Packet Switched Networks Control Plane interworking Aspects 18 11. MPLS Packet Switched Networks Control Plane interworking Aspects 19 12. IP Packet Switched Networks Management Plane interworking Aspects 19 13. L2TP Packet Switched Networks Management Plane interworking Aspects 19 14. MPLS Packet Switched Networks Management Plane interworking Aspects 19 15. Security Considerations 19 16. References 19 17. Acknowledgement 20 18. Author's Addresses 20 1. Introduction Koleyni, et al. Expires February 2002 [Page 2] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 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. - 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). It 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. Encapsulation of various protocols such as ATM, Frame Relay, Circuit Emulation and Ethernet over MPLS has been discussed in [11], [12] and [13]. This basic application of ATM interworking described in this draft will allow ATM service providers to take advantage of new technologies in the core to provide ATM multi- services. 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 Koleyni, et al. Expires February 2002 [Page 3] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 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. 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 Koleyni, et al. Expires February 2002 [Page 4] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 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. 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. Koleyni, et al. Expires February 2002 [Page 5] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 4. ATM-PSN user plane interworking 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. 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. 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 sections 6, 7 and 8. Figure 2 provides a general format for encapsulation of ATM cells (or frames) into packets. 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | PSN Transport Header | | | +------+------+------+------+------+------+------+------+ | Pseudo-Wire Header | | | +------+------+------+------+------+------+------+------+ | ATM Specific Header | | | +------+------+------+------+------+------+------+------+ | ATM Payload | | | +------+------+------+------+------+------+------+------+ Figure 2: General format for ATM encapsulation over PSNs Koleyni, et al. Expires February 2002 [Page 6] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 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. Pseudo Wire Header ------------------ The pseudo-wire header depends on the packet technology: IP, L2TP or MPLS. It maintains context information associating ATM connection with the packet technology used. 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. ATM Payload ----------- The ATM payload octet group is the payload of the service that is being encapsulated. 6. IP Packet Switched Networks User Plane Interworking Aspects This section is for further study. 7. L2TP Packet Switched Networks User Plane Interworking Aspects This section is for further study. 8. MPLS Packet Switched Networks User Plane Interworking Aspects 8.1. ATM encapsulation format Figure 3 provides the format for encapsulation of ATM cells (or frames) into MPLS 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. Koleyni, et al. Expires February 2002 [Page 7] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 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 3: General format for ATM encapsulation over MPLS PSN Transport Header -------------------- This header is used to transport the encapsulated ATM information through the MPLS core. This header identifies an LSP used to transport traffic between two ATM-MPLS interworking devices. This header is visible to the core LSRs, which use it to switch the transport LSP between core LSRs. The setting of the EXP and TTL fields of the transport label is outside the scope of this specification. The S bit is set to 0 for this label, indicating that this is not the bottom of the label stack. Pseudo Wire Header ------------------ The 4-octet Pseudo Wire Header uniquely identifies one interworking LSP, carried inside a MPLS transport LSP. The Pseudo Wire Header has the structure of a standard MPLS shim header. More than one Pseudo- wire LSP may be supported by one Transport LSP. Since a MPLS LSP is unidirectional, for the case of bi-directional ATM VCCs, there will be two different Pseudo-wire LSPs, one for each direction of the connection. These may have different label values. The IWF maintains the context information that associates the ATM connection to the MPLS LSP. This information is referenced by means of the 20-bit label field of the interworking label. The context of the interworking label field implies: -Connection type: VCC or VPC. -VPI value to be inserted in the ATM cells in the MPLS to ATM direction. Koleyni, et al. Expires February 2002 [Page 8] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 -For VCC connection types, the VCI value to be inserted in the ATM cells in the MPLS to ATM direction. This does not preclude the inclusion of other context information. Setting of the 20-bit label field is done in the following ways: ATM-to-MPLS direction In the case of a VPC, translation of the VPI to the 20 bit label field is performed. In the case of a VCC, the VPI and VCI are translated to the 20-bit label field. This association is signaled or provisioned between a pair of peer IWFs. The S bit is set to 1 to indicate the bottom of the label stack. The settings of the EXP and TTL bits are for further study. MPLS-to-ATM direction In the case of a VPC, translation of the 20-bit label field to the VPI is performed. In the case of a VCC, the 20-bit label field is translated to the VPI and VCI. This association is signaled or provisioned between a pair of peer IWFs. MPLS frames received with an invalid or unassigned Pseudo-Wire Header are discarded. 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. 8.2. Encapsulation modes Three modes of encapsulation are considered, Single cell mode, concatenated cell mode and frame mode. 8.2.1 Single cell encapsulation In this mode, a single ATM cell is encapsulated in a single packet. Figure 4 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: Koleyni, et al. Expires February 2002 [Page 9] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | 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) / / / +------+------+------+------+------+------+------+------+ Figure 4-b (for a VCC) Note: bit 0 is the most significant bit Figure 4: 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. Koleyni, et al. Expires February 2002 [Page 10] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 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). 8.2.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 5 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 | Koleyni, et al. Expires February 2002 [Page 11] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 +------+------+------+------+------+------+------+------+ | VCI (2 octets) | +------+------+------+------+------+------+------+------+ / Payload (48 octets) / / / +------+------+------+------+------+------+------+------+ Figure 5-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 | +------+------+------+------+------+------+------+------+ / Payload (48 octets) / / / +------+------+------+------+------+------+------+------+ Figure 5-b (for a VCC) Note: bit 0 is the most significant bit Figure 5 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. If cell concatenation optimization is disabled (default), then the VCI field is present for every cell in the MPLS frame. If cell concatenation optimization is enabled, then the VCI field must be present in the following cases: -The cell is the first cell in a MPLS frame -The previous cell within the MPLS frame belongs to a different VCC Koleyni, et al. Expires February 2002 [Page 12] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 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. 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. 8.2.3 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 6 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 6-a (for a VPC) 0 1 2 3 4 5 6 7 Koleyni, et al. Expires February 2002 [Page 13] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 +------+------+------+------+------+------+------+------+ | MODE |VCIP=0| RES | FRAG | EFCI | CLP | +------+------+------+------+------+------+------+------+ / Payload / / / +------+------+------+------+------+------+------+------+ Figure 6-b (for a VCC) Note: bit 0 is the most significant bit Figure 6: 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. 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). The fragmentation procedures are used to subdivide the AAL5 PDU into a series of fragments and later reassemble the sequence of such fragments to reconstitute the original AAL5 PDU. EFCI (bit 6) ------------ 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: The EFCI field of the ISH is set to the EFCI state of the last cell of the AAL5 PDU or AAL5 fragment. Koleyni, et al. Expires February 2002 [Page 14] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 -PSN-to-ATM direction: 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 ISH. CLP (bit 7) ----------- This field is used to convey the cell loss priority of the ATM cells. -ATM-to-PSN direction: The CLP field of the ISH 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: 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 ISH. PAYLOAD: The payload consists of the re-assembled AAL5 CPCS-PDU, including the AAL5 padding and trailer or the AAL5 fragment. 8.3 Configurable parameters For each ATM connection, the following parameters may be configured: - Interworking labels (one for each direction) - Connection type (VCC or VPC) - Encapsulation mode - MTU for the transport LSP - Maximum number of concatenated cells in concatenated cell mode. This value is limited by the smallest link MTU in the transport LSP. - VCIP optimization capability for VPCs in concatenated cell mode Some of these parameters need to be agreed by the INEs at either end of the LSP. 8.4 Fragmentation This section only applies to frame mode encapsulation. It may not always be possible to reassemble a full AAL5 frame at an INE. This may be due to the AAL5 PDU exceeding the MPLS MTU or if OAM cells arrive during reassembly of an AAL5 PDU. In these cases, the AAL5 PDU shall be fragmented. In addition, fragmentation may be desirable to bound ATM cell delay. If no fragmentation occurs, then the FRAG bits are set to 11 (SSM, Single Segment Message). When fragmentation occurs, the procedures described in the following subsections shall be followed. Koleyni, et al. Expires February 2002 [Page 15] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 8.4.1 Procedures in the ATM-to-MPLS direction The following procedures shall apply while fragmenting AAL5 PDUs: -Fragmentation shall always occur at cell boundaries within the AAL5 PDU. -For the first fragment, the FRAG bits shall be set to 10 (BOM, Beginning Of Message). -For the last fragment, the FRAG bits shall be set to 01 (EOM, End Of Message). -For all other fragments, the FRAG bits shall be set to 00 (COM, Continuation Of Message). -Setting of the EFCI and CLP fields in the ISH of the fragment shall be as per Section 8.2.3. 8.4.2 Procedures in the MPLS-to-ATM direction The following procedures shall apply: -The 3-bit PTI field of each ATM cell header is constructed as follows: + The most significant bit is set to 0, indicating a user data cell. + The middle bit is set to the EFCI value of the ISH of the fragment. + The least significant bit is set to 1 for the last ATM cell of a fragment where the FRAG bits are 01 (EOM) or 11(SSM); otherwise this bit is set to 0. -The CLP bit of each ATM cell header is set to the value of CLP field in the ISH. 8.5 ATM OAM and RM Cells 8.5.1 ATM-to-MPLS Direction 8.5.1.1 OAM Cells Several types of OAM cells are defined in [6]. Applications, such as those identified in [9], utilize these OAM cells. These cells are categorized as: -fault management cells -performance monitoring and reporting, both in forward and backward directions -user OAM cells (e.g. security OAM cells) 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). F4 and F5 OAM cells are either segment flows for communicating OAM related information within the boundary of the VPC or VCC, or end-to-end for information regarding end-to-end VPC or VCC operations. From an OAM perspective, the INE behaves as an ATM switch. OAM cells are always encapsulated with the cell mode encapsulation, regardless of the encapsulation format for user data. For cell mode encapsulation of user data, OAM cells are encapsulated in the same manner as user data cells. Koleyni, et al. Expires February 2002 [Page 16] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 For frame mode encapsulation of user data, OAM cells that arrive during the reassembly of an AAL5 frame cause fragmentation procedures to be invoked. The partially reassembled AAL5 frame is sent as a fragment, immediately followed by the OAM cell. Reassembly of the AAL5 frame is then resumed. If an OAM cell arrives between AAL5 frames, then it is sent in cell mode encapsulation. This procedure ensures cell sequence integrity for user cells and OAM cells. The general functional architecture of an ATM network element is provided in Figure 4-2/I.732 of ITU-T Recommendation I.732 [7]. This functional model is used below to describe the treatment of F4 and F5 OAM cells at the IWF. The IWF performs switching at either the VP or the VC level. In the following sections, _frame mode encapsulation_ refers to the encapsulation method for user data. VP Switching - Cell Mode Encapsulation F4 OAM cells are inserted or extracted by the INE. These cells are then sent across the LSP according to procedures specified in [6]. F5 OAM are not inserted or extracted here and are therefore simply encapsulated and sent across the LSP. VP Switching - Frame Mode Encapsulation This case is not supported by this specification. VC Switching - Cell Mode Encapsulation F4 OAM cells are inserted or extracted at the VP link termination; such OAM cells are not seen at the VC link termination and are therefore not sent across the LSP. F5 OAM cells are inserted or extracted at the VC link termination or VC termination. These cells are then sent across the LSP according to procedures specified in [6]. VC Switching - Frame Mode Encapsulation This case is the same as _VC switching _ Cell Mode Encapsulation_. 8.5.1.2 RM cells RM cells use a PTI value of 110 [6] and are treated the same way as OAM cells in order to maintain cell ordering. 8.5.2 MPLS-to-ATM Direction Koleyni, et al. Expires February 2002 [Page 17] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 OAM and RM cells are received as single encapsulated cells. They are treated at the INE in accordance with procedures described in [6], [7] and [9]. 8.6 Interworking transparency 8.6.1 General An objective of this specification is to provide complete transparency for ATM services across the interworking function. Due to the nature of interworking across frame-based networks, several limitations are unavoidable. The MPLS network is assumed to maintain frame sequence ordering between the sending IWF and the receiving IWF in steady state operation. Some applications are sensitive to the mis-ordering of user and OAM cells. (e.g. those described in [9]). Mechanisms for the detection of frames that are mis-ordered by the MPLS network are for further study. The cell loss ratio may be adversely affected by transport across the MPLS network. An MPLS frame may be discarded due to a single bit error within the entire MPLS frame. By contrast, a separate HEC field protects ATM cell headers. Thus, ATM cells can be switched even if errors occur in the cell payload. An IWF has an implementation-specific contribution to the end-to-end maximum CTD and peak-to-peak CDV, when these parameters are specified for an ATM connection. The INE applies its contribution to the accumulated end-to-end values as specified in TM4.1 [10]. Once the connection is established, the IWF's contribution to the maximum CTD and peak-to-peak CDV shall not exceed the values previously advertised. Note that the INE contribution includes the time required for cell concatenation (cell encapsulation mode) or AAL5 PDU reassembly (frame encapsulation mode). 8.6.2 Specific to Frame Mode Encapsulation 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 [10]. This mode does not preserve the EFCI state for every ATM cell within an AAL5 PDU. Therefore, transparency of the EFCI state may be violated. 9. IP Packet Switched Networks Control Plane interworking Aspects This section is for further study. 10. L2TP Packet Switched Networks Control Plane interworking Aspects Koleyni, et al. Expires February 2002 [Page 18] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 This section is for further study. 11. MPLS Packet Switched Networks Control Plane interworking Aspects Transport of ILMI, control signaling and control routing requires configuration of the interworking labels to be used for each of these virtual connections. This is for further study. 12. IP Packet Switched Networks Management Plane interworking Aspects This section is for further study. 13. L2TP Packet Switched Networks Management Plane interworking Aspects This section is for further study. 14. MPLS Packet Switched Networks Management Plane interworking Aspects ATM OAM cells carry performance, fault, security and protection switching information for VCCs and VPCs on an end-to-end and segment basis [6] to support ATM layer management functions. The interworking function shall be capable of transferring ATM OAM information through the MPLS network by encapsulating ATM OAM cells in MPLS frames. In addition, the interworking function may correlate MPLS OAM information with ATM OAM information in the management plane through internal or external management interfaces. Correlation of MPLS OAM information and ATM OAM cells is for further study. This is for further study. 15. Security Considerations This draft does not introduce any new security considerations to IP, L2TP or MPLS. 16. References [1] IETF RFC 2026 (October 1996): The Internet Standards Process- Revision 3, BCP 9 [2] IETF draft-ietf-pwe3-requirements-01.txt, work in progress, (July 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 Koleyni, et al. Expires February 2002 [Page 19] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 [8] ATM Forum, FB-AIC-0178.000 (August 2001), ATM-MPLS Network Interworking [9] ATM Forum specification af-sec-0100.002 (March 2001): ATM Security Specification Version 1.1 [10] ATM Forum specification af-tm-0121.000 (March 1999): Traffic Management Specification Version 4.1 [11] IETF draft draft-martini-12circuit-encap-mpls-02.txt, work in progress, (May 2001): Encapsulation methods for transport of layer 2 frames over MPLS [12] IETF draft draft-martini-12circuit-trans-mpls-06.txt, work in progress, (May 2001): Transport of layer 2 frames over MPLS [13] IETF draft draft-stdenis-ms-over-mpls-00.txt, work in progress, (Nov 2000): Multi-service over MPLS [14] IETF draft-pate-pwe3-framework-01.txt, work in progress, (July 2001): Framework for pseudo Wire Emulation Edge-to-Edge (PWE3) 17. Acknowledgement The authors like to acknowledge the contribution to this work by Dr. Khalid Ahmad. 18. 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. Koleyni, et al. Expires February 2002 [Page 20] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 2001 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 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 John Rutemiller Marconi Networks 1000 Marconi Drive Warrendale, PA 15086 Email: John.Rutemiller@marconi.com Enrique Cuevas AT&T Labs Room D3-2B25 200 S. Laurel Ave. Middletown, NJ 07748 ecuevas@att.com Koleyni, et al. Expires February 2002 [Page 21] Internet Draft draft-koleyni-pwe3-atm-over-mpls-02.txt August 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 February 2002 [Page 22]