Network Working Group Jerry Ash Internet Draft Bur Goode <draft-ash-avt-ecrtp-over-mpls-reqs-01.txt> Jim Hand Expiration Date: July 2004 AT&T Raymond Zhang Infonet Services Corporation January, 2004 Requirements for ECRTP over MPLS <draft-ash-avt-ecrtp-over-mpls-reqs-01.txt> 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. ABSTRACT: VoIP typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN, the packet header is at least 48 bytes, while the voice payload is often no more than 30 bytes, for example. VoIP header compression can significantly reduce the VoIP overhead through various compression mechanisms, such as enhanced compressed RTP (ECRTP). We consider using MPLS to route ECRTP compressed packets over an MPLS LSP without compression/decompression cycles at each router. Such an ECRTP over MPLS capability can increase the bandwidth efficiency as well as processing scalability of the maximum number of simultaneous VoIP flows that use header compression at each router. Table of Contents 1. Introduction 2. Problem Statement 3. Goals & Requirements 4. Example Scenario 5. Security Considerations 6. IANA Considerations 7. References 8. Intellectual Property Statement 9. Authors' Addresses 10. Full Copyright Statement Specification of Requirements 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]. 1. Introduction Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP. When MPLS labels [MPLS-ARCH] are added, this becomes voice/RTP/UDP/IP/MPLS-labels. For an MPLS VPN (e.g., [MPLS-VPN], the packet header is at least 48 bytes, while the voice payload is often no more than 30 bytes, for example. The interest in VoIP header compression is to exploit the possibility of significantly reducing the VoIP overhead through various compression mechanisms, such as with enhanced compressed RTP [ECRTP], and also to increase scalability of VoIP header compression. We consider using MPLS to route ECRTP compressed packets over an MPLS LSP (label switched path) without compression/decompression cycles at each router. Such an ECRTP over MPLS capability can increase bandwidth efficiency as well as the processing scalability of the maximum number of simultaneous VoIP flows which use header compression at each router. To implement ECRTP over MPLS, the ingress router/gateway would have to apply the ECRTP algorithm to the IP packet, the compressed packet routed on an MPLS LSP using MPLS labels, and the compressed header would be decompressed at the egress router/gateway where the ECRTP session terminates. Figure 1 illustrates an ECRTP over MPLS session established on an LSP that crosses several routers, from R1/HC --> R2 --> R3 --> R4/HD, where R1/HC is the ingress router where header compression (HC) is performed, and R4/HD is the egress router where header decompression (HD) is done. ECRTP compression of the RTP/UDP/IP header is performed at R1/HC, and the compressed packets are routed using MPLS labels from R1/HC to R2, to R3, and finally to R4/HD, without further decompression/recompression cycles. The RTP/UDP/IP header is decompressed at R4/HD and can be forwarded to other routers, as needed. _____ | | |R1/HC| ECRTP Header Compression (HC) Performed |_____| | | voice/ECRTP/MPLS-labels V _____ | | | R2 | |_____| | | voice/ECRTP/MPLS-labels V _____ | | | R3 | |_____| | | voice/ECRTP/MPLS-labels V _____ | | |R4/HD| ECRTP Header Decompression (HD) Performed |_____| Figure 1. Example of ECRTP over MPLS over Routers R1 --> R4 In the example scenario, ECRTP header compression therefore takes place between R1 and R4, and the MPLS path transports voice/ECRTP/MPLS-labels instead of voice/RTP/UDP/IP/MPLS-labels, saving 36 octets per packet. The MPLS label stack and link-layer headers are not compressed. A method is needed to set up a correspondence between the header compression tables at the ingress and egress routers of the ECRTP over MPLS session. Therefore additional signaling is needed to map the context for the compressed packets. In Section 2 we give a problem statement, in Section 3 we give goals and requirements, and in Section 4 we give an example scenario. 2. Problem Statement As described in the introduction, ECRTP over MPLS can significantly reduce the VoIP header overhead through compression mechanisms. The need for compression may be important on low-speed links where bandwidth is more scarce, but it could also be important on backbone facilities, especially where costs are high (e.g., some global cross-sections). VoIP typically will use voice compression mechanisms (e.g., G.729) on low-speed and international routes, in order to conserve bandwidth. With VoIP header compression, significantly more bandwidth could be saved. For example, carrying VoIP headers for the entire voice load of a large domestic network with 300 million or more calls per day could consume on the order of about 20-40 gigabits-per-second on the backbone network for headers alone. This overhead could translate into considerable bandwidth capacity. The claim is often made that once fiber is in place, increasing the bandwidth capacity is inexpensive, nearly 'free'. This may be true in some cases, however, on some international cross-sections, especially, facility/transport costs are very high and saving bandwidth on such backbone links is very worthwhile. Decreasing the backbone bandwidth is needed in some areas of the world where bandwidth is very expensive. It is also important in almost all locations to decrease the bandwidth consumption on low-speed links. So although bandwidth is getting cheaper, the value of compression does not go away. It should be further noted that IPv6 will increase the size of headers, and therefore increase the importance of header compression for VoIP flows. While hop-by-hop header compression could be applied to decrease bandwidth requirements, that implies a processing requirement for compression-decompression cycles at every router hop, which does not scale well for large voice traffic loads. The maximum number of cRTP flows is about 30-50 for a typical customer premise router, depending upon its uplink speed and processing power, while the need may exceed 300-500 for a high-end case. Therefore, ECRTP over MPLS seems to be a viable alternative to get the compression benefits without introducing costly processing demands on the intermediate nodes. By using ECRTP over MPLS, routers merely forward compressed packets without doing a decompression/recompression cycle, thereby increasing the maximum number of simultaneous VoIP compressed flows that routers can handle. Therefore the proposal is to use existing header compression techniques, such as those described in [ECRTP], together with MPLS labels, to make the transport of the RTP/UDP/IP headers more efficient over an MPLS network. However, at this time, there are no standards for ECRTP over MPLS, and vendors have not implemented such techniques. 3. Goals & Requirements The goals of ECRTP over MPLS are as follows: a. provide more efficient voice transport over MPLS networks, b. increase the scalability of VoIP header compression to a large number of flows, and c. not significantly increase packet delay, delay variation, or loss probability. Therefore the requirements for ECRTP over MPLS are that it must: a. Use existing protocols such as ECRTP and/or ROHC to compress RTP/UDP/IP headers, in order to provide for efficient voice transport, tolerance to packet loss, and resistance to loss of session context. b. Allow ECRTP over an MPLS LSP, and thereby avoid hop-by-hop compression/decompression cycles [e.g., VoMPLS]. c. Minimize incremental performance degradation due to increased delay, packet loss, and jitter. d. Use standard protocols to signal context identification and control information (e.g., [RSVP], [RSVP-TE], [LDP]). [ECRTP] should be used to make ECRTP over MPLS more tolerant of packet loss, to guard against frequent resynchronizations, and to minimize the need for error recovery. [ROHC] can also be considered, however [ROHC] does not accommodate packet reordering to protect against out-of-sequence packets, which can occur on MPLS LSPs. Protocol extensions may be required for [ECRTP] in that a packet type field is needed to identify FULL_HEADER, CONTEXT_STATE, and compressed packets. For example, [cRTP-ENCAP] specifies a separate link-layer packet type defined for header compression. Using a separate link-layer packet type for every packet type used in header compression avoids the need to add extra bits to the compression header to identify the packet type. However, this practice does not extend well to MPLS encapsulation conventions [MPLS-ENCAP], in which a separate link-layer packet type translates into a separate LSP for each packet type. In order to extend ECRTP to ECRTP over MPLS, each packet type defined in [ECRTP] would need to be identified in an appended packet type field in the ECRTP header. Extensions to MPLS signaling are needed to signal the session context IDs (SCIDs) between the ingress and egress routers on the MPLS LSP. For example, new objects need to be defined for [RSVP-TE] to signal the SCIDs between the ingress and egress routers, and [ECRTP] used to determine the FULL_HEADER packets for the context identification; these FULL HEADER packets then contain the SCID identified by using the RSVP-TE objects. It is also desirable to signal ECRTP over MPLS tunnels with the label distribution protocol [LDP], since many RFC2547 VPN [MPLS-VPN] implementations use LDP as the underlying LSP signaling mechanism, and LDP is very scalable. However, extensions to LDP would be needed to signal SCIDs between ingress and egress routers on ECRTP over MPLS LSPs. For example, 'targeted LDP sessions' might be established for signaling SCIDs, or perhaps methods described in [LDP-PWE3] and [GVPLS] to signal pseudo-wires and multipoint-to-point LSPs might be extended to support signaling of SCIDs for ECRTP over MPLS LSPs. These protocol extensions need coordination with other working groups (e.g., MPLS). Resynchronization and performance of ECRTP over MPLS needs to be considered. cRTP performs best with very low packet error rates on all hops of the path. Tunneling a cRTP session over an MPLS LSP with multiple routers in the path will increase the round trip delay and the chance of packet loss, and cRTP contexts are invalidated due to packet loss. The cRTP error recovery mechanism using CONTEXT_STATE packets can compound the problem when long round trip delays are involved. When the cRTP decompressor context state gets out of synch with the compressor, it will drop packets associated with the context until the two states are resynchronized. To resynchronize context state at the two ends, the decompressor transmits the CONTEXT_STATE packet to the compressor, and the compressor transmits a FULL_HEADER packet to the decompressor. [ECRTP] minimizes feedback based error recovery using CONTEXT_STATE packets to make cRTP more tolerant of packet loss, and minimize the need to use the cRTP error recovery mechanism. [ECRTP] should be used to make ECRTP over MPLS more tolerant of packet loss and to guard against frequent resynchronizations. Scalability of ECRTP over MPLS needs to be considered. This may require that LSPs be established with RSVP-TE between many router pairs, raising possible scalability issues. RSVP-TE has advantages in that it allows VoIP bandwidth assignment on LSPs and has QoS mechanisms. LDP is more scalable, but lacks QoS mechanisms. 4. Example Scenario As illustrated in Figure 2, many VoIP flows are originated from customer sites such as R1, R2, and R3 to several large customer call centers served by R4, which include R5, R6, and R7. It is essential that the R4-R5, R4-R6, and R4-R7 low-speed links all use header compression to allow a maximum number of simultaneous VoIP flows. To allow processing at R4 to handle the volume of simultaneous VoIP flows, it is desired to use ECRTP over MPLS for these flows. With ECRTP over MPLS, R4 does not need to do header compression/decompression for the flows to the call centers, enabling more scalability of the number of simultaneous VoIP flows with header compression at R4. voice/ECRTP/MPLS-labels ______ voice/ECRTP/MPLS-labels R1/HC---------------------->| |-----------------------> R5/HD | | voice/ECRTP/MPLS-labels| |voice/ECRTP/MPLS-labels R2/HC---------------------->| R4 |-----------------------> R6/HD | | voice/ECRTP/MPLS-labels| |voice/ECRTP/MPLS-labels R3/HC---------------------->|______|-----------------------> R7/HD [Note: HC 3D header compression; HD 3D header decompression] Figure 2. Example Scenario for Application of ECRTP over MPLS 5. Security Considerations The high processing load of header compression makes header compression a target for denial-of-service attacks. For example, an attacker could send a high bandwidth data stream through a network, with the headers in the data stream marked appropriately to cause header compression to be applied. This would use large amounts of processing resources on the routers performing compression and decompression, and these processing resources might then be unavailable for other important functions on the router. This threat is not a new threat for cRTP/ECRTP header compression, but is addressed and mitigated by ECRTP over MPLS. That is, by reducing the need for performing compression and decompression cycles, as proposed in this draft, the risk of this type of denial-of-service attack is reduced. 6. IANA Considerations No IANA actions are required. 7. References [cRTP] Casner, S., Jacobsen, V., "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [cRTP-ENCAP] Engan, M., Casner, S., Bormann, C., "IP Header Compression over PPP", RFC 2509, February 1999. [ECRTP] Koren, T., et. al., "Compressing IP/UDP/RTP Headers on Links with High Delay, Packet Loss, and Reordering," RFC 3545, July 2003. [GVPLS] Radoaca, V., et. al., "GVPLS/LPE - Generalized VPLS Solution based on LPE Framework," work in progress. [KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [LDP] Andersson, L., et. al., "LDP Specification", RFC 3036, January 2001. [LDP-PWE3] Martini, L., et. al., "Pseudowire Setup and Maintenance using LDP", work in progress. [MPLS-ARCH] Rosen, E., et. al., "Multiprotocol Label Switching Architecture," RFC 3031, January 2001. [MPLS-ENCAP] Rosen, E., et. al., "MPLS Label Stack Encoding", RFC 3032, January 2001. [MPLS-VPN] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March 1999. [ROHC] Bormann, C., et. al., "Robust Header Compression (ROHC)," RFC 3091, July 2001. [RSVP] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997. [RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [VoMPLS] Ash, G., Goode, B., Hand, J., "End-to-End VoIP over MPLS Header Compression", work in progress. 8. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in RFC 2028. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 9. Authors' Addresses Jerry Ash AT&T Room MT D5-2A01 200 Laurel Avenue Middletown, NJ 07748, USA Phone: +1 732-420-4578 Email: gash@att.com Bur Goode AT&T Phone: + 1 203-341-8705 E-mail: bgoode@att.com Jim Hand AT&T E-mail: hand17@earthlink.net Raymond Zhang Infonet Services Corporation 2160 E. Grand Ave. El Segundo, CA 90025 USA Email: raymond_zhangr@info.net 10. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.