Network Working Group G. Koleyni B.St-Denis Internet Draft Nortel Networks Expiration Date: November 2001 R. Park, M. Aissaoui J. Fisher, M. Bocci Alcatel A. Siddiqui Cable & Wireless Sohel Khan Sprint May 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. 1. Abstract This contribution specifies requirements for connecting ATM edge networks through a core packet network using MPLS. This basic application of ATM-MPLS interworking will allow ATM service providers to take advantage of new technologies in the core to provide ATM multiservices. Furthermore, this application requires only a basic interworking function of ATM and MPLS. The ATM Forum has adopted these requirements as a basis for further work defining ATM-MPLS network interworking. Koleyni, et al. Expires November 2001 [Page 1] Internet Draft draft-koleyni-pwe3-atm-over-mpls-00.txt May 2001 This draft is proposed for consideration in the Pseudo Wire Emulation Edge-to-Edge (PWE3) Working group. Table of contents 1. Abstract 1 2. Introduction 2 3. Terminology 3 4. Background of ATM-MPLS Network Interworking 3 5. ATM-MPLS user plane interworking requirements 4 6. ATM encapsulation format 5 7. Encapsulation modes 6 7.1 Cell mode encapsulation 7 7.1.1 Single cell encapsulation 7 7.1.2 Concatenated cells encapsulation 8 7.2 Frame mode encapsulation 10 8. Security Considerations 11 9. References 11 2. Introduction MPLS has 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 MPLS to this type of network operator is as a common core transport for multiple existing legacy networks, not as a unifying control plane architecture for all services. MPLS as a common transport infrastructure provides 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 an MPLS enabled core. - Existing network operational processes and procedures used to maintain the legacy services are preserved. - The common MPLS 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 MPLS, network. This draft describes a simple application of ATM-MPLS interworking intended to allow ATM service providers to carry their ATM multi- services transparently over a MPLS packet core. This draft specifies requirements and the frame work which were adopted by the ATM-IP Collaboration (AIC) working group of the ATM Forum as a basis for further work on ATM-MPLS network interworking. This draft is proposed for consideration in the Pseudo Wire Emulation Edge-to-Edge (PWE3) Working group. Koleyni, et al. Expires November 2001 [Page 2] Internet Draft draft-koleyni-pwe3-atm-over-mpls-00.txt May 2001 3. Terminology AAL ATM Adaptation Layer. OAM Operations, Administration, and Maintenance. PVC Permanent Virtual Connection. An ATM connection that is provisioning via a network management interface. The connection is not signalled. PNNI Private Network-Network Interface. An ATM signalling protocol. PVP Permanent Virtual Path connection. A PVC that is switched using the ATM VPI. RM Resource Management. A type of OAM cell. 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 signalled through the ATM network. 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. IWF The Interworking Function (IWF) is a functional entity that facilitates interworking between two dissimilar networks (e.g., ATM and MPLS). Network interworking: In network interworking, the Protocol Control Information of the protocol used in two similar networks and the payload information are transferred, transparently across an intermediate network by an IWF. 4. Background of ATM-MPLS Network Interworking 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 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 and LMDS access applications. An example of such a network is shown in Figure 1. ATM connections are carried transparently over MPLS LSPs from one edge of the packet core to another one. The LSPs are primarily used as transparent tunnels. The role of the ATM-MPLS interworking function at each edge of the core is to multiplex a number of ATM connections (VCCs, VPCs or both) into a LSP and originate the LSP. The pair of LSPs (bi-directional Koleyni, et al. Expires November 2001 [Page 3] Internet Draft draft-koleyni-pwe3-atm-over-mpls-00.txt May 2001 connectivity) between any two interworking devices at the edge of the core is either established using a network management system or is initiated through MPLS signalling. ATM ATM Multiservices MPLS Core Multiservices Network Network Network Edge LSR Edge LSR VCC ************************ VCC ------+-------+------+ +--------+------+---- !!=======+=======+=====>* !!<======+=======+======* ------+-------+------+ Pair of LSPs +--------+------+---- VPC * * VPC ************************ IWF IWF Figure 1: Example of a Network Using ATM/MPLS Network Interworking Transparency in this context means that ATM multi-services should be carried over the packet core unaffected. In other words, the ATM/MPLS interworking function is characterized by: a. ATM layer protocols are not terminated at the interworking function. b. ATM and MPLS user data planes are interworked. c. ATM control plane information (signaling channels, routing control channels) and layer management plane information (OAM cells) are tunnelled through the LSP from one ATM/MPLS edge to the other edge. The pair of associated unidirectional LSPs between the IWFs is seen as a bi-directional link by the ATM edge networks. 5. ATM-MPLS user plane interworking requirements The following is a summary of the requirements for the ATM-MPLS network interworking. a. The ability to multiplex multiple ATM connections, VPC and/or VCC, into a pair of associated MPLS LSP. Koleyni, et al. Expires November 2001 [Page 4] Internet Draft draft-koleyni-pwe3-atm-over-mpls-00.txt May 2001 b. Support for the traffic contracts and the QoS commitments made to the ATM connections (i.e., 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 MPLS frame with a reasonable overhead. h. The option to concatenate multiple ATM cells into the same MPLS frame i. The option to reassemble an AAL5 PDU into one or more MPLS frames for bandwidth efficiency. 6. ATM encapsulation format Figure 2 provides a general format for interworking between ATM and MPLS. The interworking Function (IWF) uses a unique MPLS label, i.e., the interworking label, to identify each direction of an ATM connection. This label 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 MPLS- to-ATM direction. 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | MPLS Transport Label (4 octets) | | | +------+------+------+------+------+------+------+------+ | Interworking Label (4 octets) | | | +------+------+------+------+------+------+------+------+ | ATM-MPLS interworking specific header (up to 3 octets)| | | +------+------+------+------+------+------+------+------+ | Payload | | | +------+------+------+------+------+------+------+------+ Figure 2: General encapsulation format Koleyni, et al. Expires November 2001 [Page 5] Internet Draft draft-koleyni-pwe3-atm-over-mpls-00.txt May 2001 MPLS transport label -------------------- The 4-octet MPLS transport label identifies a LSP (TLSP) used to transport traffic between two ATM-MPLS interworking functions. This label is used to switch the transport LSP between core LSRs. Interworking label ------------------ The 4-octet interworking label uniquely identifies one interworking LSP (ILSP), carried inside a MPLS transport LSP. The interworking label has the structure of a standard MPLS shim header. More than one interworking LSP may be supported by one MPLS transport LSP. The interworking function provides the association between the ATM connection and MPLS LSP by means of the 20-bit field of the interworking LSP. In this association, in the ATM-to-MPLS direction a translation of VCI/VPI to the 20-bit label is performed, while in the MPLS-to-ATM direction the 20-bit label is translated to VCI/VPI of the ATM connection. This association is signalled or provisioned between the two interworking functions. Since MPLS LSP is unidirectional, for the case of bi-directional ATM VCCs, there will be two different interworking LSPs, one for each direction of the connection. These may have different label values. Setting of the EXP and TTL is for further study. The S bit is set to 1 since this is the last label in the bottom of the MPLS stack. The interworking label is not visible to the LSRs within the MPLS core network. ATM-MPLS interworking specific header ------------------------------------- The ATM-MPLS interworking specific header (ISH) is inserted before the payload and identifies whether encapsulation is to be performed for ATM cells or AAL5 frames. In addition, other elements of the protocol control information constitute parts of this header. The cell mode and frame mode encapsulation formats and procedures are shown and explained in the following sections. Payload ------- The payload octet group is the payload of the service that is being encapsulated. 7. Encapsulation modes Two modes of encapsulation are considered, cell mode and frame mode. Koleyni, et al. Expires November 2001 [Page 6] Internet Draft draft-koleyni-pwe3-atm-over-mpls-00.txt May 2001 7.1 Cell mode encapsulation In this mode, a single ATM cell or many concatenated ATM cells are encapsulated in a single MPLS frame. 7.1.1 Single cell encapsulation Figure 3 shows structure of the ATM-MPLS interworking specific header for single cell encapsulation. Description of ATM-MPLS interworking specific header fields for single cell encapsulation is given below: 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | MODE | VCIP | RES | PTI | CLP | +------+------+------+------+------+------+------+------+ | VCI (2 octets) | +------+------+------+------+------+------+------+------+ / Payload (48 octets) / / / +------+------+------+------+------+------+------+------+ Note: bit 0 is the most significant bit Figure 3:Structure of ATM-MPLS interworking specific header for transport of a single ATM cell 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 VPC, the VCIP field in the interworking header of the first cell of a MPLS frame must always be set to 1. 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) -------------- Payload Type Identifier, Incorporates ATM Layer PTI coding of the cell. These bits are set to the value of the PTI of the ATM cell. Koleyni, et al. Expires November 2001 [Page 7] Internet Draft draft-koleyni-pwe3-atm-over-mpls-00.txt May 2001 CLP (bit 7) ----------- Cell Loss Priority indicates CLP value of the cell. For ATM-to-MPLS direction, the CLP state of the cell may optionally be mapped into the EXP field of the MPLS transport label. 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). 7.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 MPLS frame 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-MPLS network need to be configured via the NMS or via signalling in order to be able to transmit and receive concatenated cells in a MPLS frame. 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 ATM-MPLS interworking specific header for concatenated cells encapsulation. Description of ATM-MPLS interworking specific header fields for concatenated cells encapsulation is given below: 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | MODE | VCIP | RES | PTI | CLP | +------+------+------+------+------+------+------+------+ | VCI (2 octets) | +------+------+------+------+------+------+------+------+ / Payload (48 octets) / / / +------+------+------+------+------+------+------+------+ / / / / +------+------+------+------+------+------+------+------+ | MODE | VCIP | RES | PTI | CLP | +------+------+------+------+------+------+------+------+ | VCI (2 octets) | +------+------+------+------+------+------+------+------+ / Payload (48 octets) / / / +------+------+------+------+------+------+------+------+ Koleyni, et al. Expires November 2001 [Page 8] Internet Draft draft-koleyni-pwe3-atm-over-mpls-00.txt May 2001 Figure 4 Structure of ATM-MPLS interworking specific header for transport of concatenated cells 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 VPC, the VCIP field in the interworking header of the first cell of a MPLS frame must always be set to 1, which means that the VCI field is present. When cell concatenation is enabled, the value of the VCIP field must not change (default) within the same MPLS frame. Optionally, the ATM- MPLS interworking functions can be configured via NMS or signaling to transmit and receive a MPLS frame with a variable VCIP field value in the same MPLS frame. Note that the value of the VCIP field is allowed to vary from MPLS frame to MPLS frame. 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) -------------- Payload Type Identifier, Incorporates ATM Layer PTI coding of each cell. These bits are set to the value of the PTI of the ATM cell. CLP (bit 7) ----------- Cell Loss Priority indicates CLP value of each cell. For ATM-to- MPLS direction, the CLP state of the concatenated cells may optionally be mapped into the EXP field of the MPLS transport label. 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 signalling. The payload does not include the cell header. The value of N is limited by the smallest link MTU (Maximum Transport Unit) in the LSP tunnel. Koleyni, et al. Expires November 2001 [Page 9] Internet Draft draft-koleyni-pwe3-atm-over-mpls-00.txt May 2001 7.2 Frame mode encapsulation This mode is used for carrying a whole AAL5 PDU in the LSP. 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 Indicator). ATM cells of an AAL5 PDU are re-assembled and the resulting AAL5 PDU is encapsulated in a MPLS frame. Figure 5 shows structure of ATM-MPLS interworking specific header for frame mode encapsulation. Description of ATM-MPLS interworking specific header fields for AAL5 frame encapsulation is given below: 0 1 2 3 4 5 6 7 +------+------+------+------+------+------+------+------+ | MODE | VCIP | RES | FRAG | EFCI | CLP | +------+------+------+------+------+------+------+------+ | VCI (2 octets) | +------+------+------+------+------+------+------+------+ / Payload / / / +------+------+------+------+------+------+------+------+ Note: bit 0 is the most significant bit Figure 5:Structure of ATM-MPLS interworking specific header for frame transport MODE (bit 0) ------------ This field is set to 1 to indicate frame 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. 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. FRAGmentation (bits 4-5) ------------------------ This field provides information about frame fragmentation. It is set to (10 for BOM, Beginning Of Message), (00 for COM, Continuation Of Koleyni, et al. Expires November 2001 [Page 10] Internet Draft draft-koleyni-pwe3-atm-over-mpls-00.txt May 2001 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 signalling. 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-MPLS direction: The EFCI state of the reassembled AAL5 PDU is conveyed in the EFCI field of the ATM-MPLS interworking specific header. The EFCI state of a PDU is set to 1 if the last cell of the PDU has its EFCI bit set to 1, it is set to 0 otherwise. MPLS-to-ATM direction: The EFCI bit of all constituent cells of a segmented AAL5 PDU is set to the value of the EFCI field in the ATM- MPLS interworking specific header. CLP (bit 7) ----------- ATM-to-MPLS direction: The CLP state of the reassembled AAL5 PDU is conveyed in the CLP field of the ATM-MPLS interworking specific header. The CLP state of the PDU is set to 1 if any of the PDU constituent cells has its CLP bit set to 1. Optionally, the CLP state may be mapped into the EXP field of the MPLS transport label. MPLS-to-ATM direction: The CLP bit of all constituent cells of a segmented AAL5 PDU is set to the value of the CLP field in the interworking label. PAYLOAD: The payload consists of the re-assembled AAL5 CPCS-PDU, including the AAL5 padding and trailer. 8. Security Considerations This draft does not introduce any new security considerations to MPLS. 9. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] IETF RFC 3032 (January 2000): MPLS Label Stack Encoding [3] ATM Forum, str-aic-mpls-niwf-01.01, ATM-MPLS Interworking: Network Interworking Koleyni, et al. Expires November 2001 [Page 11] Internet Draft draft-koleyni-pwe3-atm-over-mpls-00.txt May 2001 10. Acknowledgement The authors like to acknowledge the contribution to this work by Khalid Ahmad. 11. 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 Fisher Alcatel Networks Corporation 600 March Road Kanata, Ontario, K2K 2E6 Canada Email: john.fisher@alcatel.com Sohel Khan Sprint 7171 W 95th Street Overland Park, KS 66212 Email: sohel.khan@mail.sprint.com Koleyni, et al. Expires November 2001 [Page 12] Internet Draft draft-koleyni-pwe3-atm-over-mpls-00.txt May 2001 Adeel A. Siddiqui Cable & Wireless 11700 Plaza America Drive Reston, Virginia 20190, USA Email: adeel.siddiqui@cwusa.com Koleyni, et al. Expires November 2001 [Page 13] Internet Draft draft-koleyni-pwe3-atm-over-mpls-00.txt May 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 November 2001 [Page 14]