Shahram Davari Internet Draft PMC-Sierra Inc. Document: draft-davari-pwe3-aal12-over-psn-01.txt Expires: September 2003 March 2003 Transport of AAL1 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 methods for transporting AAL1 over IP/MPLS network, using the existing ATM transport over IP/MPLS methods described in [ATM-encap]. 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 transport over PSN network such as IP/MPLS network. Davari Expires September 2003 Page 1 Transport of AAL1 frames over PSN March 2003 JUSTIFICATION? The PWE3 WG charter calls for ATM and TDM emulation over PSN. [ATM- encap] covers the ATM cell transport and the AAL5 frame transport over PSN. This draft complements [ATM-encap] and explains how to transport AAL1 traffic over PSN using the already defined methods and options in [ATM-encap] without introducing any new protocol. 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. AAL1 transport using N:1 cell mode............................4 7. AAL1 transport using 1:1 cell mode............................5 8. AAL1 transport using PDU mode.................................6 9. Length and sequence number....................................9 10. Administrative (OAM and RM) Cell Support.....................10 11. Defect Handling..............................................10 12. QoS consideration............................................11 13. AAL1 over IP/MPLS specific requirements......................12 14. Security.....................................................12 15. References...................................................12 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 adaptation layer. As the service providers migrate to IP/MPLS networks there is a need to transport AAL1 traffic over IP/MPLS networks. This document describes methods for transporting AAL1 over IP/MPLS networks, using the ATM transport modes described in [ATM-encap] without introducing any new protocol. This document extends the applicability of equipments that implement [ATM-encap], to transporting AAL1 traffic and potentially enables transport of TDM circuit emulation traffic over IP/MPLS networks as explained in [draft-anavi]. Davari Expires August 2003 Page 2 Transport of AAL1 frames over PSN March 2003 Note 1: Throughout this document, ôfragmentationö means PDU fragmentation procedures as described in [ATM-encap]. Note 2: Throughout this document, AAL1 PDU means the 48-byte AAL1 SAR-PDU as described in [ITU-AAL1]. Note 3: Since SDU mode is explicitly designed only for AAL5 transport; it cannot be used to transport AAL1. 3. Applicability The primary applications supported by AAL1 transport over PSN are CBR services such as voice and TDM services. The AAL1 transport takes advantage of the N:1 cell mode, described in [draft-martini,] to provide a default standard method for carrying AAL1 traffic. In addition it optionally also takes advantage of 1:1 cell mode and PDU mode, described in [ATM-encap], to increase bandwidth efficiency. 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 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 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. AAL1, 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 over IP/MPLS networks to transport AAL1 and TDM signals over those networks. v. Leveraging off the shelf hardware and software that emulate TDM over AAL1 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 frame transport over a PSN. It leverages the modes and options already defined in [ATM-encap] and does not introduce any new protocol, and therefore is backward compatible with hardware and software developed for Martini-compliant equipments. Davari Expires August 2003 Page 3 Transport of AAL1 frames over PSN March 2003 For bandwidth efficiency reasons the AAL1 frame transport may use PDU mode. To take advantage of the PDU mode, the fragmentation procedure for bounding cell transfer delay as described in [ATM- encap] MUST be used. This means that the ingress PE MUST have the PDU fragmentation capability that will limit the payload size of the IP/MPLS packet to Nx48 bytes, in which N is a pre-configured value that bounds the cell transfer delay. Since services that use AAL1, such as circuit emulation service, expect in-order delivery of data, for the purpose of AAL1 transport, it is advantageous to use the control wordÆs Sequence number. However, sequence number usage is optional as per [ATM-encap]. 5. Limitations AAL1 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. 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. AAL1 transport using N:1 cell mode N:1 cell mode is the only default and mandatory mode described in [ATM-encap]. To be fully compliant with [ATM-encap], this document also recommends the N: 1 cell mode as the default mode for transporting AAL1 traffic over IP/MPLS networks. Using N: 1 cell mode, one or more AAL1 stream could be transported over a single PW. Individual AAL1 streams are differentiated from each other by the VPI/VCI that is carried with each cell. The following figure shows how multiple CBR streams could be transported over a single PW using N:1 cell mode. +----+ +---+ +-------+ CBR stream 1 --->| |---->| | | | CBR stream 2 --->|AAL1|---->|ATM|--->| N:1 |---> PW1 CBR stream 3 --->| |---->| | | Mode | +----+ +---+ +-------+ Davari Expires August 2003 Page 4 Transport of AAL1 frames over PSN March 2003 Figure 1: AAL1 transport over PSN using Martini N: 1 cell mode In this figure CBR streams are attached to an AAL1 block. The AAL1 block performs the AAL1 adaptation function as specified in [ITU AAL1]. The outputs of the AAL1 block contain 48-byte AAL1-PDUs. The ATM block performs the ATM layer functions by adding 5-byte ATM headers to the 48-byte AAL1-PDUs with proper VPI/VCI. Each AAL1 stream is assigned a unique VPI/VCI based on the interface at which it arrives to the ATM block. The ATM block then generates an ATM stream toward a Martini (N:1) block, which then transports the ATM cells over a single PW (PW1), according to the N:1 cell mode of [ATM-encap]. Each IP/MPLS packet may carry one or more cells belonging to one or more AAL1 streams. The AAL1 and ATM blocks could be located in the CE or in the PE. If they are in CE, then the link between CE-PE is an ATM link, while if they are in PE, then the link between CE-PE is a TDM link. 7. AAL1 transport using 1:1 cell mode 1:1 cell mode is an optional mode described in [ATM-encap], and is more bandwidth efficient than N:1 cell mode. To be fully compliant with [ATM-encap], this document also permits the usage of 1:1 cell mode as an optional mode for transporting AAL1 traffic over IP/MPLS networks. Using 1:1 cell mode, only one AAL1 stream could be transported over a single PW. Individual AAL1 streams are differentiated from each other by the PW that they are carried in. The following figure shows how a single AAL1 stream could be transported over a single PW using 1:1 cell mode. +----+ +---+ +-------+ CBR stream 1 --->| |---->| | | |---> PW1 CBR stream 2 --->|AAL1|---->|ATM|--->| 1:1 |---> PW2 CBR stream 3 --->| |---->| | | Mode |---> PW3 +----+ +---+ +-------+ Figure 2: AAL1 transport over PSN using Martini 1: 1 cell mode In this figure CBR streams are attached to an AAL1 block. The AAL1 block performs the AAL1 adaptation function as specified in [ITU AAL1]. The outputs of the AAL1 block contain 48-byte AAL1-PDUs. The ATM block performs the ATM layer functions by adding 5-byte ATM headers to the 48-byte AAL1-PDUs with proper VPI/VCI. Each AAL1 stream is assigned a unique VPI/VCI based on the interface that it arrives to the ATM block. The ATM block then generates an ATM stream toward a Martini (1:1) block, which then transports the ATM cells over multiple PWs (PW1, PW2, PW3) bases on their VPI/VCI, according Davari Expires August 2003 Page 5 Transport of AAL1 frames over PSN March 2003 to the 1:1 cell mode of [ATM-encap]. Each IP/MPLS packet may carry one or more cells belonging to the same AAL1 stream. The AAL1 and ATM blocks could be located in the CE or in the PE. If they are in CE, then the link between CE-PE is an ATM link, while if they are in PE, then the link between CE-PE is a TDM link. 8. AAL1 transport using PDU mode PDU mode is an optional mode described in [ATM-encap], and is more bandwidth efficient than either 1:1 and N:1 cell modes. PDU mode was originally designed to carry AAL5 PDUs. However, it does not prohibit using it to carry other AAL types. The technique can easily be employed for other AAL types including AAL1. This is shown in section 8.1. To be fully compliant with [ATM-encap], this document also permits using the PDU mode as an optional mode for transporting AAL1 traffic over IP/MPLS networks. Using PDU mode, only one AAL1 stream could be transported over a single PW. Individual AAL1 streams are differentiated from each other by the PW that they are carried in. In this mode, the ingress PE encapsulates one or more AAL1-PDUs (Nx48 bytes) belonging to the same AAL1 stream in a single packet. The following figure shows how a single AAL1 stream could be transported over a single PW using PDU mode. +----+ +---+ +-------+ CBR stream 1 --->| |---->| | | |---> PW1 CBR stream 2 --->|AAL1|---->|ATM|--->| PDU |---> PW2 CBR stream 3 --->| |---->| | | Mode |---> PW3 +----+ +---+ +-------+ Figure 3: AAL1 transport over PSN using PDU mode In this figure CBR streams are attached to an AAL1 block. The AAL1 block performs the AAL1 adaptation function as specified in [ITU AAL1]. The outputs of the AAL1 block contain 48-byte AAL1-PDUs. The ATM block performs the ATM layer functions by adding 5-byte ATM headers to the 48-byte AAL1-PDUs with proper VPI/VCI. Each AAL1 stream is assigned a unique VPI/VCI based on the interface that it arrives to the ATM block. The ATM block then generates an ATM stream toward a Martini (PDU) block, which then transports the ATM cells over multiple PWs (PW1, PW2, PW3) bases on their VPI/VCI, according to the PDU mode of [ATM-encap]. Each IP/MPLS packet may carry one or more cells belonging to the same AAL1 stream. Davari Expires August 2003 Page 6 Transport of AAL1 frames over PSN March 2003 The AAL1 and ATM blocks could be located in the CE or in the PE. If they are in CE, then the link between CE-PE is an ATM link, while if they are in PE, then the link between CE-PE is a TDM link. It can be seen from Figure 3 that the ATM block adds the ATM header to each AAL1-PDU, while Martini (PDU) block removes the ATM headers and encapsulates Nx48 byte payloads (AAL1-PDUs) in to IP/MPLS packet. In case the the ATM block and the Martini block are implemented in a single PE device it is possible to combine them and therefore reduce the required processing by eliminating the add/remove ATM header operations. This concept is shown in the following figure. +----+ +----------+ CBR stream 1 --->| |---->|simplified|---> PW1 CBR stream 2 --->|AAL1|---->| PDU mode |---> PW2 CBR stream 3 --->| |---->| |---> PW3 +----+ +----------+ Figure 4: AAL1 transport over PSN using simplified PDU mode In this figure AAL1 streams are attached to a simplified PDU mode block. This block performs all the PDU mode operations except the ATM header removal. The AAL1 streams contain 48-byte AAL1-PDUs. The simplified Martini (PDU) block, transports the AAL1 PDUs over multiple PWs (PW1, PW2, PW3) bases on their input port, according to the PDU mode of [ATM-encap]. Each IP/MPLS packet may carry one or more cells belonging to the same AAL1 stream. 8.1 How to use PDU mode to transport AAL1 Although PDU mode is designed to transport AAL5 frames, it does not prohibit carrying other AAL type traffic. As it turns out, after a small change that was made to the PDU mode by the ATM Forum, the PDU mode could actually be used to carry other AAL types, including AAL1. ATM Forum noted that the current PDU mode is structured so that it requires reassembly of fragments at the egress PE. However, it was recognized that not only such a reassembly is not necessary, but also is harmful. For example reassembling the fragments may cause the OAM/RM cells to be misplaced in the stream. Also reassembly of fragments would increase the cost of buffering and the overall delay. These coupled with the fact that almost all implementations of PDU mode donÆt actually reassemble the fragments, triggered a minimal change to the PDU mode to rectify the situation. The ATM Forum decided to change the 2-bit FRAG field in the Interworking header to a Reserved bit followed by a UU-bit (Figure 5). The UU-bit would be copied from the MSB of the PTI of the last encapsulated cell to this field. This change simplifies the egress Davari Expires August 2003 Page 7 Transport of AAL1 frames over PSN March 2003 processing as well as opening new opportunities, such as using the PDU mode to transport other AAL types, including AAL1. Looking at the operation of PDU mode, we would see that what it actually does is to concatenate a number of 48-byte ATM payloads in a packet and send it across the PSN. The concatenation would terminate when either the UU bit=1 (used to indicate end of packet in AAL5), or when an RM/OAM cell arrives or when the packetization delay limit has exceeded. The same procedure when applied to AAL1 stream would concatenate a number of AAL1-PDUs (48-byte) in a packet and send it across the PSN. The concatenation would terminate when either RM/OAM cells arrive or when packetization delay limit is exceeded. Since AAL1 does not use the UU-bit, the UU-bit processing has no impact on it. The following figure shows the format of the packet generated by PDU mode (when the ATM Forum changes are reflected) for AAL1 transport. 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 |U|E|C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | " | | AAL1 PDUs | | (N * 48 bytes) | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: AAL1 transport over PDU encapsulation format The first octet following the Pseudo Wire Header carries control information. The M, V, RES, U, E and C bits are defined as following: * M (Mode) bit This bit is set to æ1Æ to indicate the frame mode encapsulation * V (VCI present) bit This bit is set to æ0Æ to indicate that no VCI is present * RES (Reserved) bits Davari Expires August 2003 Page 8 Transport of AAL1 frames over PSN March 2003 These bits are reserved in [ATM-encap] and by default are set to æ000Æ. However for the purpose of transporting AAL1 they MAY be used to encode L & R values as described in section 11.1. * UU bit This field is used to transparently carry the UU-bit of the last encapsulated cell in the packet. Since it is not used by AAL1 its value would be set to æ0Æ. * 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. As shown in figure 5, N x AAL1 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 SHOULD be either configured or negotiated between PEs based on the maximum delay tolerance and maximum MTU size. 9. Length and sequence number PDU mode [ATM-encap] requires the inclusion of Length field for links that have a minimum frame size, such as Ethernet with a minimum frame size of 64 octets. The same requirement exists for AAL1 transport over PDU mode. The use of sequence number is optional in [ATM-encap]. For the purpose of transporting AAL1 PDUs, here too the use of sequence number is optional. However, it should be noted that since the AAL1 Davari Expires August 2003 Page 9 Transport of AAL1 frames over PSN March 2003 is mainly used for CBR applications, such as circuit emulation that expect in-order delivery with no loss, it is advantageous to use sequence number. For example by using sequence number in the circuit emulation, the receiver could detect lost packets and insert dummy payload to keep the TDM frame synchronization. The procedure for generation and processing of Length and Sequence number are the same as those defined in [ATM-encap]. 10. Administrative (OAM and RM) Cell Support The treatment of OAM and RM cells is as per [ATM-encap], and depends on the transport mode selected. 11. Defect Handling For the purpose of detection and handling of defects that may occur in the PSN, the PSN should normally 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 occur outside of the PSN, such as defects at a lower layer (e.g. Physical layer LOS) between CE-PE. 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 according to [ATM-encap]. When an ingress PE cannot support the generation of F5 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, the packet payload is meaningless. For bandwidth saving purpose, the IP/MPLS packets MAY be send with minimum PSN payload set to all zeros. For AAL1 services, loss of packets is an important defect that MAY be detected and reported. Loss of packet could be due to connectivity failure of congestion. In either case Egress PE MAY use sequence number in the control word (figure 1) to detect packet loss. Upon detection of such a packet loss the egress PE MAY inform the ingress PE by setting the R-bit (as defined below) in the control byte to indicate a packet loss. The ingress PE could use that information to shut down or reroute the PW. Loss of connectivity MAY alternatively be detected independently using PSN specific OAM mechanisms. 11.1 L & R bits 3 bits are reserved (RESV bits) in [ATM-encap] (assuming ATM Forum change on PDU mode has been accepted) for future use. [ATM-encap] requires that these bits be set to zero at ingress PE and ignored at Davari Expires August 2003 Page 10 Transport of AAL1 frames over PSN March 2003 reception. This draft proposes encoding the forward and backward defect identifiers in two of 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 MAY 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). 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 MAY be set after a PE detects loss of a pre-configured number of packets in a certain interval. And it should be cleared after reception without loss of a pre- configured number of packets. The PEs that canÆt or donÆt want to encode L or R bits in the RESV field will set them to æ0Æ as per [ATM-encap]. The PEs that canÆt interpret the L or R bits will ignore the RESV field as per [ATM- encap]. These rules insure backward compatibility with equipments that have already been developed based on PDU mode. The following figure shows the encoding of L & R bits. 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|L|R| |U|E|C| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | " | | AAL1 PDUs | | (N * 48 bytes) | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: L & R bit encoding in PDU encapsulation format 12. QoS consideration Since AAL1 is predominantly used to transport real-time CBR data, such as TDM traffic, it is recommended to provision enough BW to carry the AAL1 traffic. In case Diffserv is used it is recommended to use a virtual wire kind of PDB to transport the AAL1 PDUs over the PSN. Davari Expires August 2003 Page 11 Transport of AAL1 frames over PSN March 2003 13. AAL1 over IP/MPLS specific requirements All the requirements of [ATM-encap] apply also to this draft. 14. Security No additional security risk apart from the security risks associated with IP/MPLS networks issues are introduced in this document. 15. References [ATM-encap] draft-ietf-pwe3-atm-encap.txt (Feb 2003, 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. [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. [ITU-AAL1] ITU-T Recommendation I.363.1, (1996), B-ISDN ATM Adaptation Layer specification: Type 1 AAL [draft-anavi] draft-anavi-tdmoip-05.txt (March 2003, work in progress), TDM over IP AuthorsÆ Address Shahram Davari PMC-Sierra 555 Legget Drive Phone: 1-613-271-4018 Kanata, ON, K2K 3C9, Email: Shahram_Davari@pmc-sierra.com Canada Davari Expires August 2003 Page 12