PWE3 Working Group Internet Draft Tom Walsh Lucent Technologies Expires: December 2002 Rao Cherukuri Integral Access Andrew G. Malis Vivace Networks, Inc. Durai Chinnaiah Jayakumar Jayakumar Cisco Systems, Inc. June 2002 Comparison of ATM encapsulation formats in pwe3 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 Different encapsulation formats have been proposed to carry ATM services over IP, L2TP and MPLS [2], [3], [4]. The cell mode proposals are discussed in [2] and [3]. The frame mode proposals are discussed in [2] and [4]. This paper analyzes certain key issues in these proposals and makes some conclusions. Expires - December 2002 [Page 1] draft-walsh-pwe3-atm-compare-00.txt June 2002 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. Table of Contents 1. Introduction...................................................2 1.1 Cell Relay Service.........................................2 1.2 Frame Service (AAL5).......................................2 2. Terminology....................................................3 3. Issues related to cell relay service...........................3 3.1 Some basics on the proposed formats........................3 3.2 Principal of Minimal Intervention [].......................4 3.3 Mapping of VCCs and VPCs to Tunnels........................4 3.4 Bandwidth efficiency and simplicity........................5 4. Issues related to frame mode...................................6 4.1 Bandwidth efficiency.......................................6 4.2 OAM Support................................................7 4.3 AAL 5 SAR Function.........................................7 4.4 Comparison Table for SDU vs. PDU mode......................8 5. Conclusions....................................................9 5.1 Cell mode..................................................9 5.2 Frame mode.................................................9 6. Security Considerations.......................................10 7. IPR...........................................................10 8. References....................................................10 9. Author's Addresses............................................11 1. Introduction Different encapsulation formats have been proposed to carry ATM services over IP, L2TP and MPLS [2], [3], [4]. The cell relay service proposals are discussed in [2] and [3]. The frame service (AAL5) proposals are discussed in [2] and [4]. This paper analyzes certain key issues in these proposals and makes some conclusions. 1.1 Cell Relay Service The cell relay service proposals are discussed in [2] and [3]. There are two structures for cell relay service; single cell and concatenated cells. 1.2 Frame Service (AAL5) Walsh, et al Expires - December 2002 [Page 2] draft-walsh-pwe3-atm-compare-00.txt June 2002 The frame service (AAL5) proposals are discussed in [2] and [4]. There are two frame encapsulation services proposed: AAL 5 SDU mode [2] and AAL5 PDU mode [4]. The AAL5 PDU is comprised of an AAL5 SDU, padding and whole trailer. 2. Terminology Packet Switched Network - A Packet Switched Network (PSN) is an IP or MPLS network. Pseudo Wire Emulation Edge to Edge - Pseudo Wire Emulation Edge to Edge (PWE3) is a mechanism that emulates the essential attributes of a service (such as a T1 leased line or Frame Relay) over a PSN. Customer Edge - A Customer Edge (CE) is a device where one end of an emulated service originates and terminates. The CE is not aware that it is using an emulated service rather than a "real" service. Provider Edge - A Provider Edge (PE) is a device that provides PWE3 to a CE. Pseudo Wire - A Pseudo Wire (PW) is a connection between two PEs carried over a PSN. The PE provides the adaptation between the CE and the PW. PSN Tunnel - A PSN Tunnel is a tunnel inside which multiple PWs can be nested so that they are transparent to core PSN devices. Ingress - The point where the ATM service is encapsulated into a Pseudo Wire PDU (ATM to PSN direction.) Egress - The point where the ATM service is decapsulated from a Pseudo Wire PDU (PSN to ATM direction.) 3. Issues related to cell relay service Issues that need to be considered in choosing a cell relay service encapsulation format include the impact of the format on bandwidth efficiency, and whether a single encapsulation format or multiple encapsulation formats for each interworking structure are desirable. The choice of an encapsulation format should not introduce unnecessary complexity 3.1 Some basics on the proposed formats There are three proposed PWE3 cell relay services, VCC cell relay service, VPC cell relay service and Transparent port service. Martini Walsh, et al Expires - December 2002 [Page 3] draft-walsh-pwe3-atm-compare-00.txt June 2002 [2] supports all three services while Koleyni [3] can support only the first two services. In Martini cell encapsulation only one format is used for all services. The cell header length is always the same (i.e., it is the 4 octet ATM header) for VCC, VPC and the Transparent port mode. This format also has the advantage of being 4-byte aligned for easier processing because when multiple cells are encapsulated, e.g., each concatenated cell always begins on a 4-byte boundary. In Koleyni a different cell encapsulation format is used for each service. As a result, the cell header length is different for VCC and VPC services. VCC encapsulation uses one octet, whereas VPC encapsulation uses 3 octets, and Transparent port encapsulation can not be supported at all (because multiple VPs cannot be transported). When multiple cells are encapsulated, the boundary between cells varies depending on whether itÆs a VCC or VPC format. As a result, the boundary between encapsulated cells does not align on 4-byte boundaries but changes with each cell. 3.2 Principal of Minimal Intervention [5] The Martini encapsulation follows the principle of minimal intervention. The 4-octet ATM Header is used unaltered for the encapsulation formats. The Koleyni encapsulation format does not follow the principle of minimal intervention. The ATM header format is modified for transport over the MPLS network. Further complicating the Koleyni encapsulation is that different formats are used for each service. The Koleyni draft intervenes substantially which adds to the processing complexity. 3.3 Mapping of VCCs and VPCs to Tunnels Another significant difference exists in the mapping capabilities of the Martini and Koleyni encapsulations. In Martini, the ingress PE may map one or more VCCs to a single pseudo wire. The flexibility of the encapsulation format allows both a one-to-one mapping or multiple VCCs to be carried within a single PSN tunnel. The same is true also for VPC mapping. In Koleyni, the encapsulation format restricts the mapping to a single VCC per tunnel and a single VPC per tunnel. Multiple VCCs or multiple VPCs can not be transported on one tunnel because of the encapsulation format limitations. Each VCC or VPC requires its own tunnel. Walsh, et al Expires - December 2002 [Page 4] draft-walsh-pwe3-atm-compare-00.txt June 2002 A very significant advantage of the Martini encapsulation can now be seen. When encapsulating multiple cells in Martini, these cells can be concatenated from multiple VCCs. In Koleyni, only cells from a single VCC can used concatenated cell encapsulation. 3.4 Bandwidth efficiency and simplicity The overhead for transport of ATM over MPLS will be the combination of MPLS headers (MPLS transport label, Interworking label and control word) and cell header. For a single cell encapsulation the overhead is always high. Before calculating the efficiency, it is necessary to understand which cell relay services should use concatenated cell encapsulation. When concatenated cells are used the MPLS header overhead is divided among the number of cells. The next question is how many cells can be included in an MPLS frame. The number of cells in the frame will depend on the traffic and QoS associated with the connections. The quality of service provided to a connection across MPLS core, should be consistent with that indicated, implicitly or explicitly, by the QoS parameters associated with a connection. One common use of ATM is to carry AAL type 1 VCCs for voice service. For a 64 kbps G.711 voice call using AAL1, each cell is sent 5.875 ms apart (47 octets x .125 msec). The number of cells included in the concatenated cell mode must not increase delay and delay variation. As already noted in Koleyni, when using a VCC cell relay service only cells belonging to one VCC can be concatenated. If multiple cells belonging to the voice call are included in the frame, it introduces delay. If three cells are included it adds additional delay of 11.75 msec (2 x 5.875). Therefore, for the Koleyni VCC connection mode, it is not advisable to use concatenated cell encapsulation, unless the VCC is used for a very high bit rate or delay insensitive traffic. In the Martini format, cells can be concatenated from multiple VCCs. Therefore, in the AAL1 example, three cells can be concatenated from three different voice calls without waiting the additional 11.75 msec it would take to receive three cells from one VCC. Another issue with using VCC concatenated cells is the requirement to store the individual cells for assembly in the MPLS Frame. This means that each LSP must have a buffer pool available to accomplish this. Supporting cell concatenation for a very large number of VCCs will increase management processing and result in serious scalability issues. Walsh, et al Expires - December 2002 [Page 5] draft-walsh-pwe3-atm-compare-00.txt June 2002 For the VPC mode it is possible to use concatenated cell encapsulation with out affecting the QoS parameters. In Martini, cells from multiple VPs can be included. In Koleyni, cells may only be concatenated form a single VP. When using VPC mode concatenation, the bandwidth saving is only one octet in the Koleyni encapsulation when compared with the Martini encapsulation. This one byte saving is difficult to justify based on the increased complexity required to support the multiple Koleyni formats. The transparent port encapsulation header uses the four octets of ATM cell header and can not be supported with the existing Koleyni encapsulation format. In summary, the greatest efficiency from the existing Koleyni encapsulation is derived from concatenated VCC cell mode (3-bytes difference). However, as shown concatenated cell mode has limited usefulness for voice packets and requires a large pool of buffers per LSP to implement. Given a large number of LSPs, this can create scalability and management problems. The efficiency gain is more than off set by the complexity. The PE becomes more complex than the original ATM switch. The efficiency gain from the VPC mode with the Koleyni encapsulation is negligible (1-byte difference). To achieve this Koleyni sacrifices the flexibility to carry multiple VPCs. To gain efficiency in Koleyni, 2 different encapsulations are required and neither Koleyni encapsulation can support multiple VCCs per tunnel, multiple VPCs per tunnel or the transparent port service. The Martini encapsulation provides one encapsulation format that is the same for VCC, VPC and transparent port service. 4. Issues related to frame mode The frame service (AAL5) proposals are discussed in [2] and [4]. There are two frame encapsulation services proposed: Martini AAL 5 SDU mode [2] and Bocci AAL5 PDU mode [4]. The AAL5 PDU is comprised of an AAL5 SDU, padding and whole trailer. 4.1 Bandwidth efficiency The PDU mode includes the Pad and an 8-octet trailer. The trailer includes CPCS-UU, Length and CRC. The Pad field can be 0 to 47 octets. The PDU mode is less bandwidth efficient when compare to SDU mode. The percentage will depend on the Pad and length of SDU. Walsh, et al Expires - December 2002 [Page 6] draft-walsh-pwe3-atm-compare-00.txt June 2002 The average overhead for PDU mode: 24 (PAD) + 8 = 32 octets. The value of 24 is chosen for the PAD as its half the longest PAD length. On average, the PDU mode requires 32 octets more than SDU mode. There has been a lot of discussion about possible bandwidth efficiency in the cell mode. The efficiency argument does not favor the Bocci [4] encapsulation in the PDU frame mode, however. The Martini SDU mode does not have the overhead penalty for the PAD and trailer. The Martini SDU mode is the more efficient mode in frame mode. It also benefits from being much less complex as will be seen later. 4.2 OAM Support In discussing OAM support, a great deal of focus has been placed on cell sequence integrity when using the frame mode. In an ATM cell network, OAM cells can be inserted in the stream of cells. But if frames are being assembled from ATM cells for transport across an MPLS network, the issue of maintaining OAM cell sequence integrity has been raised. Is this difference in where the OAM cell positioning occurs important to applications using frame mode? The OAM position problem is only applicable for applications that support end-to-end performance monitoring and applications using security OAM cells. Most of the applications using AAL 5 (e.g., Frame Relay, IP and LAN) do not require this capability. SDU mode cannot preserve the position of the OAM cell relative to the user data cell. It may not support OAM-based applications (e.g., performance monitoring, security), which are sensitive to the position of the OAM cells. For applications, which require this capability, cell mode can be used. In PDU mode, to preserve positioning of OAM cells new fragmentation procedures are used. This is described in the next section. 4.3 AAL 5 SAR Function AAL Type 5 is defined in ITU-T Recommendation I.363.5 [6]. In AAL 5 there is no Service Access Point (SAP) between CPCS and SAR. Implementations based on ITU-T Recommendation I.363.5 do not provide access to the PDU. I.363.5 describes how the PDU is created within the CPCS by adding the PAD and Trailer. This CPCS-PDU is then passed to the SAR for segmentation into ATM cells. In the opposite direction, the ATM cells are reassembled into a PDU by the SAR and passed to the CPCS. Again, according to ITU-T Recommendation I.363.5 Walsh, et al Expires - December 2002 [Page 7] draft-walsh-pwe3-atm-compare-00.txt June 2002 there is no SAP defined between CPCS and SAR so the reassembled PDU is not externally available. The PDU Frame Mode is a new procedure proposed for PWE3 and is not part of existing ITU-T ATM Recommendations. Therefore, it is not possible to use an AAL 5 chip set to obtain the AAL 5 PDU. In order to support the PDU mode therefore, it is necessary to define new Fragmentation procedures which are not part of ITU-T AAL Type 5 Recommendations. Bocci defines these procedures. This imposes complex hardware requirements on both the ingress and egress PEs that are not supported today by existing ATM switches. For SDU mode, it is possible to use a standard AAL 5 chip set. The SDU is recoverable at an ITU-T Recommendation I.363.5 Service Access Point (SAP) in AAL Type 5, The AAL can be terminated at the user or at the PE. No fragmentation procedures are needed if the SDU size is less than MTU. This avoids the need for new hardware in the PE. Frame mode need not support all applications. SDU can support most common AAL 5 applications including Frame Relay, IP, and LAN transport. For applications that require a larger SDU size, cell mode procedures should be used. 4.4 Comparison Table for SDU vs. PDU mode The table below provides the comparison of two frame modes. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Function + SDU Mode + PDU Mode + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Bandwidth + Low + High + + overhead + + + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + OAM cell position + Not supported. + Requires new + + + Applications + fragmentation + + + needing this + hardware + + + capability can + + + + use cell mode + + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Segmentation and + Uses existing + Requires new + + Reassembly + AAL5 chipsets + fragmentation + + + + hardware + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Complexity + Low + High + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Walsh, et al Expires - December 2002 [Page 8] draft-walsh-pwe3-atm-compare-00.txt June 2002 5. Conclusions 5.1 Cell mode The encapsulation format in Koleyni has some deficiencies such as requiring different encapsulation formats for each cell relay service. In the Koleyni cell encapsulation: - Does not follow the principal of minimal intervention; - a different cell encapsulation format is used for each service; - the cell header length is different for VCC and VPC services - it does not support transparent port service as Koleyni would require yet another format; - restricted to a single VCC or a single VPC per tunnel as its format does not permit multiple VCCs or VPCs per tunnel; - in concatenated cell mode, must wait for cells from one VCC to arrive introducing delay; - the boundary between encapsulated cells, does not align on 4- byte boundaries but changes with each cell. Martini uses a common encapsulation format. In the Martini cell encapsulation: - Follows the principle of minimal intervention; - only one format is used for all services including VCC, VPC and the Transparent port mode; - the cell header length is always the same for VCC, VPC and the Transparent port mode; - each concatenated cell always begins on a 4-byte boundary; - in VCC cell relay service, both a one-to-one mapping or multiple VCCsÆ may be carried within a single PSN tunnel; - when encapsulating multiple cells in Martini, these cells can be concatenated from multiple VCCs; - in VPC cell relay service, both a one-to-one mapping or multiple VPCsÆ may be carried within a single PSN tunnel; - in concatenated cell mode, can encapsulate cells from multiple VCCs reducing delay. 5.2 Frame mode Walsh, et al Expires - December 2002 [Page 9] draft-walsh-pwe3-atm-compare-00.txt June 2002 ATM is inherently a cell-based technology. However, the vast majority of data carried on ATM networks is frame based and uses AAL Type 5. Frame mode is a set of new procedures intended to improve the efficiency of ATM over MPLS. Since efficiency is a driver for this mode, it is important to realize that the SDU mode defined in Martini is more efficient than the PDU mode define in Bocci. The table comparing SDU and PDU frame modes in section 4, shows that the Martini SDU mode is more efficient, less complex and may use existing hardware based on ITU-T Recommendations. The Bocci PDU mode requires new hardware in the PE, is not efficient, and requires new fragmentation procedures to be defined by PWE3. Not all ATM applications must be supported in frame mode. Security and Performance Monitoring have been identified as applications which could not use the SDU mode but could use the PDU mode. As these applications can be completely satisfied using cell mode, the PDU mode is not necessary. 6. Security Considerations This draft does not introduce any new security considerations to IP or MPLS. 7. IPR This document is being submitted for use in IETF standards discussions. 8. References 1 Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996. 2 Martini, L. et al, "Encapsulation Methods for Transport of ATM Cells/Frame over IP and MPLS Networks", draft-martini-atm-encap- mpls-01.txt, June 2002, work-in-progress 3 Koleyni, G. et al, "Applicability Statement for ATM Cell Encapsulation over PSN (the basic mode)", draft-koleyni-pwe3-app- cell-over-psn-01.txt, May 2002, work-in-progress 4 Bocci, M. et al, "Applicability Statement for AAL5 Transparent Frame Encapsulation over PSN", draft-bocci-pwe3-app-frame-over- psn-00.txt, May 2002, work-in-progress Walsh, et al Expires - December 2002 [Page 10] draft-walsh-pwe3-atm-compare-00.txt June 2002 5 Bryant, S. et al, "Protocol Layering in PWE3", draft-ietf-pwe3- protocol-layer-00.txt, work-in-progress 6 ITU-T Recommendation I.363.5, "B-ISDN ATM Adaptation Layer specification: Type 5 ALL", 08/96 9. Author's Addresses Tom Walsh Lucent Technologies 1 Robbins Road Westford, MA 01886 USA Email: tdwalsh@lucent.com Rao Cherukuri Integral Access 6 Omni Way Chelmsford, MA 01824 Email: rcherukuri@integralaccess.com Andrew G. Malis Vivace Networks, Inc. 2730 Orchard Parkway San Jose, CA 95134 Email: Andy.Malis@vivacenetworks.com Durai Chinnaiah Cisco Systems, Inc. 225, E. Tasman, MS-SJ3/3, San Jose, CA, 95134 Email: dchinnai@cisco.com Walsh, et al Expires - December 2002 [Page 11]