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