Shahram Davari Internet Draft PMC-Sierra Inc. Document: draft-davari-pwe3-aal12-over-psn-00.txt Expires: February 2003 August 2002 Transport of ATM AAL1/2 frames over PSN Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Notice Copyright(C) The Internet Society (2001). All Rights Reserved. Abstract This document describes an efficient method for transporting AAL1/2 over IP/MPLS network, using effectively the ATM AAL5 PDU transport mode without introducing any new protocol. Sub-IP ID Summary WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK? Fits in the PE box WHY IS IT TARGETED AT THIS WG? It proposes ATM AAL1/2 emulation over PSN network such as IP/MPLS network. Davari Expires February 2003 Page 1 Transport of AAL1/2 frames over PSN August 2002 JUSTIFICATION? The WG charter calls for ATM and TDM emulation over PSN. [draft- martini], [draft-koleyni] and [draft-bocci] already cover the ATM cell transport and the AAL5 frame transport. This draft complements them by covering the AAL1/2 frame transport. Also a companion draft describes how to do TDM emulation over PSN, using the AAL1/2 frame transport. Table of contents 1. Conventions used in this document..............................2 2. Introduction...................................................2 3. Applicability..................................................3 4. Implementation and deployment consideration....................3 5. Limitations....................................................4 6. ATM VCC Services...............................................4 6.1 Transparent AAL1/2 PDU Frame Service..........................4 6.2 Length and sequence number....................................6 6.3 Administrative (OAM and RM) Cell Support......................6 6.4 Packing AAL1/2 PDUs...........................................7 6.4.1 Procedures in the ATM-to-MPLS direction.....................7 6.4.2 Procedures in the MPLS-to-ATM direction.....................8 6.5 Defect Handling...............................................8 6.5.1 L & R bits..................................................9 7. ILMI support...................................................9 8. QoS consideration.............................................10 9. ATM Pseudo-Wire over IP/MPLS specific requirements............10 10. Security.....................................................10 11. References...................................................10 12. Author's Address.............................................11 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. Introduction Currently a great portion of voice and TDM traffic is carried over ATM networks using AAL1 and AAL2 adaptation layers. As the service providers migrate to IP/MPLS networks there is a need to transport AAL1/2 traffic over IP/MPLS networks. Davari Expires February 2003 Page 2 Transport of AAL1/2 frames over PSN August 2002 This document describes an efficient method for transporting AAL1/2 over IP/MPLS network, using effectively the ATM AAL5 PDU transport mode [draft-bocci] without introducing any new protocol. A companion draft will describe how to do TDM (T1/E1)_emulation over PSN using the procedures described in this draft. Note: By AAL2 PDU, the draft refers to the 48-byte AAL2 CPS-PDU, not the variable length AAL2-CP packet. Note: Throughout this draft, ôfragmentationö means AAL5 PDU fragmentation procedures as described in [draft-bocci] not AAL1/2 PDU fragmentation. 3. Applicability The primary application supported by AAL1/2 PDU frame encapsulation over PSN is the transparent carriage of ATM layer services that use AAL1/2 to carry higher layer frames, such as voice and TDM services. The AAL1/2 transport mode takes advantage of the AAL5-PDU mode to provide increased bandwidth efficiency compared with the basic cell encapsulation mode of [draft-martini] or [draft-Koleyni]. The nature of the service, as defined by the [ATM service] or the [ATM transfer capability] should be preserved. To provide this, the basic requirement of the ATM-PSN interworking function is to map the AAL1/2 PDU frames belonging to a VCC, together with any related OAM, RM cells and protocol control information, into a PW. The benefits of this model to service providers and vendors are: i. Leveraging of the existing systems and services to provide increased capacity from a packet switched core. ii. Preserving existing network operational processes and procedures used to maintain the legacy services e.g. ATM OAM and ATM security. iii. Using the common packet switched network infrastructure to support both the core capacity requirements of existing services and the requirements of new services supported natively over the packet switched network. iv. Leveraging the same hardware and software used for transporting ATM AAL5-PDU over IP/MPLS networks to transport ATM AAL1/2 and TDM signals over those networks. v. Leveraging off the shelf hardware and software that emulate TDM over AAL1/2 to transport TDM signals over IP/MPLS network. 4. Implementation and deployment consideration The procedures mentioned in this draft, apply in most part to any ATM AAL type, but the scope of this draft is the AAL1 and AAL2 frame transport by transporting Nx48 byte cells over a PSN. It leverages Davari Expires February 2003 Page 3 Transport of AAL1/2 frames over PSN August 2002 the AAL5 PDU mode already defined in [draft-bocci]. It does not introduce any new protocol, and therefore is fully backward compatible with hardware and software developed for AAL5 PDU mode. 5. Limitations AAL1/2 frame transport only supports point-to-point LSPs. Multi point-to-point and point-to-multi-point are for further study (FFS). To have bi-directional connectivity, as required in ATM, two LSPs should be configured, one for each direction (ATM-to-MPLS and MPLS to-ATM) of the ATM connection. The AAL1/2 frame transport requires the usage of AAL5 PDU mode fragmentation procedure for bounding cell transfer delay as described in [draft-bocci]. Therefore the ingress PE MUST have the AAL5 PDU fragmentation capability turned on that will limit the payload size of the IP/MPLS packet to Nx48 bytes, in which N is a pre-configured value or a variable number that bounds the cell transfer delay. The AAL1/2 frame transport requires that the egress PE MUST NOT do reassembly of the AAL5 PDU fragments. For the purpose of AAL1/2 frame transport, the control wordÆs Sequence # SHOULD be used. This draft does not preserve the value of the CLP bit for every ATM cell. 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. This draft does not preserve the EFCI state for every ATM cell. Therefore, transparency of the EFCI state may be violated. 6. ATM VCC Services This section defines ATM AAL1/2 VCC service that may be supported over the PSN. It assumes that each PW carries only a single ATM VCC. 6.1 Transparent AAL1/2 PDU Frame Service In this service, the ingress PE encapsulates a number of AAL1 or AAL2 PDUs (Nx48 bytes) in a single packet. Transparent AAL1/2 PDU service makes use of transparent AAL5 PDU service defined in [draft-bocci]. From the ingress PEÆs point of view, the concatenated AAL1/2 PDUs (Nx48 bytes) looks like a very large AAL5 PDU. Therefore to support this service, ingress PE MUST support AAL5 PDU fragmentation for the purpose of bounding the cell delay in that limits the number of AAL1/2 PDUs, which is encapsulated in a single packet. Davari Expires February 2003 Page 4 Transport of AAL1/2 frames over PSN August 2002 The AAL1/2 transparent VCC service is intended to be more efficient than the VCC cell transport service. Note that the AAL1/2 PDUs are not processed, i.e. CRC is not checked. This service supports all OAM and RM cell flows by using the fragmentation procedure described in [draft-bocci] that ensures that OAM and RM cells are not repositioned in respect to AAL1/2 cells. The AAL1/2 transparent VCC service is OPTIONAL. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSN Transport Header (As Required) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pseudo Wire Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length and Sequence Number |M|V|Res|Frg|E|C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | " | | AAL1/2 PDUs | | (N * 48 bytes) | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: AAL1/2 transparent service encapsulation The first octet following the Pseudo Wire Header carries control information. The M, V, RES, Frg, E and C bits are as defined in [draft-bocci]: * M (Mode) bit This bit MUST be set to æ1Æ to indicate the frame mode encapsulation * V (VCI present) bit This bit MUST be set to æ0Æ to indicate that no VCI is present * Res (Reserved) bits These bits SHOULD be set to L & R values as described in section 6.4. They MAY optionally be set to æ00Æ. * Frg (Fragmentation/packing) bits This field is used to support the AAL1/2 PDU packing functionality (which is equivalent to AAL5 PDU fragmentation) described later in this section. [draft-bocci] defines the following values for Frg bits: Davari Expires February 2003 Page 5 Transport of AAL1/2 frames over PSN August 2002 - 10 Beginning of Message (BOM) - 01 End of Message (EOM) - 00 Continuation of Message (COM) - 11 Single Segment Message (SSM) The LSB of the Frg bits effectively represents the UU-bit of the last cell in the packet. Since the ATM headerÆs UU-bit is not currently defined for AAL1/2, the EOM (01) and SSM (11) are not currently used for AAL1/2 frame transport. * E (EFCI) bit This field is used to convey the EFCI state of the ATM cells. The EFCI state is indicated in the middle bit of each ATM cell's PTI field. ATM-to-PSN direction (ingress): The EFCI field of the control byte is set to the EFCI state of the last cell of the packet. PSN-to-ATM direction (egress): The EFCI state of all constituent cells of the packet are set to the value of the EFCI field in the control byte. * C (CLP) bit This field is used to convey the cell loss priority of the ATM cells. ATM-to-PSN direction (ingress): The CLP field of the control byte is set to æ1Æ if any of the constituent cells of the packet has its CLP bit set to æ1Æ; otherwise this field is set to æ0Æ. PSN-to-ATM direction (egress): The CLP bit of all constituent cells of a packet is set to the value of the CLP field in the control byte. 6.2 Length and sequence number The inclusion of Length field is optional and MAY be required for links that have a minimum frame size, such as Ethernet with a minimum frame size of 64 octets. For the purpose of transporting AAL1/2 PDUs, the sequence number SHOULD be used. The reason is that AAL1/2 are used mainly for multiplexed streaming real-time applications that require detection of lost/Misinserted cells. The procedure for generation and processing of Length and Sequence number are the same as those defined in [draft-bocci]. 6.3 Administrative (OAM and RM) Cell Support Davari Expires February 2003 Page 6 Transport of AAL1/2 frames over PSN August 2002 When configured for the AAL1/2 transparent VCC service, both PE's SHOULD act as a VC switch, in accordance with the OAM procedures defined in [ATM OAM]. The PEs SHOULD be able to pass the following administrative cells transparently: - F5 AIS (segment and end-to-end) - F5 RDI (segment and end-to-end) - F5 loopback (segment and end-to-end) - Resource Management - Performance Management - Continuity Check - Security The PEs SHALL use the single ATM VCC cell mode encapsulation Section 6.1, [draft-Koleyni] when passing an OAM or RM cell. The ingress PE SHOULD be able to generate an F5 AIS upon reception of a corresponding F4 AIS or lower layer defect (such as LOS). The egress PE SHOULD be able to generate an F5 AIS based on a PSN failure (such as a PSN tunnel failure or LOS on the PSN port). If the ingress PE cannot support the generation of OAM cells, it MAY notify the egress PE using a Pseudo Wire specific maintenance mechanism to be defined. For example, the ingress PE MAY withdraw the Pseudo Wire (VC label) associated with the service. Or it MAY set a flag (i.e., L-bit) in the control byte to indicate such failure to the egress PE (see section 6.5). Upon receiving such a notification, the egress PE SHOULD generate the appropriate F5 AIS. 6.4 Packing AAL1/2 PDUs As shown in figure 1, N AAL1/2 PDUs (Nx48 bytes) are packed in a single IP/MPLS packet to form the payload of the PW packet. The PDUs are formed by removing the ATM header of arriving cells. N MAY be fixed or variable, but has a maximum value that SHOULD be either configured or negotiated between PEs based on the maximum cell transfer delay tolerance and minimum and maximum MTU size. From a PEs perspective, the packing of N AAL1/2 PDUs is identical to fragmenting an AAL5 PDU to fragments containing Nx48 bytes data in AAL5 PDU mode. Therefore to reuse a device that has implemented AAL5 PDU mode for packing AAL1/2 PDUs, the ingress PE MUST use the AAL5 PDU fragmentation capability for the purpose of bounding cell delay as described in [draft-bocci]. The procedures described in the following subsections shall be followed by ingress and egress PEs. 6.4.1 Procedures in the ATM-to-MPLS direction Davari Expires February 2003 Page 7 Transport of AAL1/2 frames over PSN August 2002 The following procedures shall apply while packing the PDUs at the ingress PE: - Ingress PE receives ATM cells, and starts packing (reassembling) them. - Ingress PE stops packing, when either a cell with PTI='1xx' (OAM/RM cell) or PTI='01x' (UU-bit=1, which is N/A to AAL1/2) is received or if the number of packed cells exceeds a pre- configured value of N or if the packing delay exceeds a pre- configured value. - For the very first packet generated for a specific AAL1/2 stream, the FRG bits SHALL be set to æ10Æ (BOM, Beginning Of Message). - For all other future packets of the same stream, the FRG bits SHOULD be set to æ00Æ (COM, Continuation Of Message). - The E and C bits of the fragment shall be set as defined earlier in section 6.1. Note: The above procedures are defined so that they are fully backward compatible with AAL5 PDU mode hardware and software. 6.4.2 Procedures in the MPLS-to-ATM direction The following procedures shall apply at the egress PE: - The egresses PE SHOULD generate ATM cells upon reception of every packet. Note, in terms of AAL5 PDU mode devices, this requirement translates to requiring that the egress PE SHALL NOT do reassembly of AAL5 PDU fragments. - The 3-bit PTI field of each ATM cell header is constructed as follows: + The most significant bit (MSB)is set to æ0Æ, indicating a user data cell. + The middle bit is set to the E bit value of the packetÆs control byte. + The least significant bit (LSB) is set to the LSB of the Frg field. Since no UU-bit is defined for AAL1/2 this bit SHOULD be set to æ0Æ. - The C bit of each ATM cell header is set to the value of the C bit of the control byte in Figure 1. Note: The above procedures are defined so that they are fully backward compatible with AAL5 PDU mode hardware and software. 6.5 Defect Handling It is expected that for the purpose of detection and handling of defects that may happen in the PSN, the PSN SHOULD have its own OAM (operation and maintenance) and defect handling mechanism. These mechanisms are outside the scope of this draft. There are some defects that may happen outside of the PSN, such as defects at a lower layer (e.g. Physical layer LOS) between CE-PE in Davari Expires February 2003 Page 8 Transport of AAL1/2 frames over PSN August 2002 the ATM-MPLS direction. These defects are detected by other means than PSN OAM. When such defect happens, the PE SHOULD generate ATM F5 AIS on all affected VCs. As described in section 6.3, when an ingress PE cannot support the generation of OAM cells upon reception of a corresponding F4 AIS or lower layer defect (such as LOS), it MAY notify the egress PE by setting the L-bit (as defined below) in the control byte to indicate that a defect exist at a lower layer (i.e., Physical layer) in the ATM-to-PSN direction. In such defect conditions, for bandwidth saving purpose, the IP/MPLS packets MAY be send without any payload (i.e., AAL1/2 PDUs). For AAL1/2 services, loss of packets is an important defect that SHOULD be detected and reported. Egress PE SHOULD use the sequence number in the control word (figure 1) to detect packet loss. Upon detection of such a packet loss the egress PE SHOULD inform the ingress PE by setting the R-bit (as defined below) in the control byte to indicate a packet loss. Loss of packet MAY also be detected independently using PSN specific OAM mechanisms. 6.5.1 L & R bits Two bits are reserved (RESV bits) in [draft-bocci] for future use. [draft-bocci] requires that these bits be set to zero at ingress PE and ignored at reception. This draft proposes encoding the forward and backward defect identifiers in these reserved bits as following. L-bit: Forward defect identifier. L-bit is the left hand bit of the RESV field in the control byte. It SHOULD be set when a failure happens in a lower layer between CE-PE and the ingress PE cannot support the generation of OAM cells upon reception of a corresponding F4 AIS or lower layer defect (such as LOS). And it SHOULD be cleared when those failures are rectified. R-bit: Backward defect identifier. R-bit is the right hand bit of the RESV field in the control byte. It SHOULD be set 2.5 +/- 0.5 seconds after a PE detects loss of a pre-configured number of consecutive packets. And it should be cleared after 10 seconds free of loss of the pre-configured number of consecutive packets. The PEs that canÆt or donÆt want to encode L or R bit in the RESV field MUST set it to æ0Æ. The PEs that canÆt interpret the L or R bits MUST ignore the RESV field. These rules insure backward compatibility with equipments that have already been developed based on AAL5 PDU mode. 7. ILMI support Integrated Local Management Interface (ILMI) typically is used in ATM networks for neighbor resource availability detection, address registration, auto-configuration, and loss of connectivity Davari Expires February 2003 Page 9 Transport of AAL1/2 frames over PSN August 2002 detection. ILMI messages are sent as SNMP PDU's and are transported as ATM AAL5 messages per [draft-bocci]. A PE MAY provide an ATM ILMI to its attached CE. If the ingress PE receives an ILMI message indicating that the ATM service (VCC) is down, it MAY use a Pseudo Wire specific mechanism to notify the egress PE of the ATM service status. For example, a PE using an MPLS based Pseudo Wire may withdraw its advertised VC label. When receiving such a notification, the egress PE MAY use ILMI to signal the ATM service status to its attached CE. 8. QoS consideration Since AAL1 is predominantly used to transport real-time CBR data, such as TDM traffic, it is recommended to use EF PHB to transport the AAL1 PDUs over the PSN. Since AAL2 is predominantly used to transport variable rate real- time data such as voice, it is recommended to use either EF PHB or one of the AF PSCs to transport the AAL1 PDUs over the PSN. 9. ATM Pseudo-Wire over IP/MPLS specific requirements All the requirements of [draft-bocci] apply also to this draft. 10. Security No additional security issues are introduced in this document. As ATM encapsulation to MPLS packet is related to MPLS. AAL1/2 frame encapsulation shares the security concerns associated with MPLS. 11. References [draft-bocci] draft-bocci-pwe3-app-frame-over-PSN-00.txt (May 2002, work in progress), Applicability Statement for AAL5 Transparent Frame Encapsulation over PSN [draft-koleyni] draft-koleyni-app-cell-over-psn-01.txt (May 2002, Work in Progress), Applicability Statement for ATM Cell Encapsulation over PSN (the basic mode) [draft-martini] draft-martini-atm-encap-mpls-01.txt (June 2002, work in progress), Encapsulation Methods for Transport of ATM Cells/Frame Over IP and MPLS Networks [ATM service] ATM Forum Specification af-tm-0121.000 (1999), Traffic Management Specification Version 4.1. Davari Expires February 2003 Page 10 Transport of AAL1/2 frames over PSN August 2002 [ATM transfer capability] ITU-T Recommendation I.371 (2000), Traffic control and congestion control in B-ISDN. [ATM OAM] ITU-T Recommendation I.610, (1999), B-ISDN operation and maintenance principles and functions. 12. Author's Address Shahram Davari PMC-Sierra 411 Legget Drive Phone: 1-613-271-4018 Kanata, ON, Canada Email: Shahram_Davari@pmc-sierra.com Davari Expires February 2003 Page 11