Internet Draft Internet-Draft Thomas Theimer Expires December 2000 Siemens June 2000 Tunneling Multiplexed Compressed RTP in MPLS <draft-theimer-tcrtp-mpls-00.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 This document describes a method to improve the bandwidth efficiency of voice transmission over an IP/MPLS network by combining RTP compression, PPP multiplexing and MPLS tunneling. This proposal does not require any additions or modifications to existing protocols, and therefore should be fully interoperable with existing implementations of RTP compression and PPP multiplexing. It only requires specific use of some attributes of MPLS signalling protocols to setup a pair of unidirectional MPLS tunnels providing a bidirectional link for compressed RTP over PPP. 1. Introduction It is generally accepted that there is a need to improve the bandwidth efficiency of carrying voice traffic over an IP network. This issue has been addressed by various proposals in the past, mainly focussing on compressed RTP (CRTP) [7] carried by PPP links [8]. Recently, it was proposed to extend these mechanisms to also include MPLS in conjunction with CRTP [9]. In most previous proposals compression is applied on link level, aiming at maximum transmission efficieny to be achieved on links where bandwidth is limited and expensive. However, once header compression is involved, it may be [Page 1] Internet-Draft Tunneling Multiplexed CRTP in MPLS June 2000 beneficial in terms of end-end bandwidth efficiency to perform compression on LSP level whenever possible. For voice gateways supporting CRTP, this does not impose any additional complexity compared to link level header compression. In cases where MPLS is used anyway to provide QoS guarantees between voice gateways, a natural step would be to combine MPLS and header compression such that CRTP is applied on LSP level (end-end between voice gateways). This would extend the efficiency of CRTP to the entire communication path between two gateways without affecting intermediate nodes at all. Combined with PPP multiplexing [2], this leads to a very efficient end-end compression and multiplexing scheme between gateways that is fully transparent for routers within the IP backbone. Of course, there may be networks where bandwidth efficiency is not an issue, in which case the mechanisms described in this document are simply not required. An alternate end-end compression scheme for MPLS was recently proposed in [10], aiming at simplicity and robustness rather than efficiency and compatibility with existing header compression protocols. In parallel, the AVT working group has recently proposed to carry multiplexed compressed RTP using L2TP tunnels [1]. The advantage of this mechanism is that the overhead of the tunnel header (IP, UDP and L2TP) can be amortised over several RTP payloads carried by a single L2TP frame. While this concept fits nicely to general IP backbone networks, there is still room for improvement by applying MPLS as a tunneling mechanism instead of L2TP. Note that this document does not attempt to replace TCRTP as defined in [1]. It simply proposes an alternate tunneling mechanism that may be applied in an MPLS capable backbone network. A possible way forward would be to simply carry L2TP in an MPLS LSP in a similar manner as L2TP is carried in an ATM virtual circuit. However, L2TP itself imposes a significant overhead (both in terms of functionality and in terms of header bytes), without providing any significant additional benefit in this specific application. It is therefore proposed to carry PPP directly in MPLS rather than PPP over L2TP over MPLS. Using MPLS as a direct tunneling mechanism for multiplexed CRTP offers the following benefits: - improved bandwidth efficiency: instead of 36 bytes for the combined L2TP/UDP/IP header for TCRTP (or 21 bytes where L2TP header compression is used), only the MPLS shim header (4 bytes) and the PPP protocol field (typically 2 bytes) must be carried in addition to the multiplexed compressed RTP sub-frames. - guaranteed QoS: by constraining the setup of the MPLS tunnel, end- end quality of service guarantees (with respect to throughput and delay) could be provided to all RTP flows within the tunnel. This may be used to limit the expected CRTP packet loss rate within the Theimer Expires December 2000 [Page 2] Internet-Draft Tunneling Multiplexed CRTP in MPLS June 2000 network, and the round trip delay (variation). These issues are also discussed in [3] and [4]. - ordered packet delivery: in-order packet delivery can be guaranteed at the CRTP decompressor by carrying the multiplexed CRTP packets across an MPLS tunnel. There is no need for packet reordering as provided by L2TP. - fast rerouting: MPLS protection switching mechanisms can be applied to achieve fast restoration of voice trunks between gateways (see e.g. [11]). Both local and end-end protection could by used to achieve fast tunnel restoration which is an essential requirement for carrier grade public voice services. Backup tunnels may also be combined with load sharing to allow a more even traffic distribution. - explicit routing: MPLS tunnels can be constrained to a given set of nodes or links in the network, providing the network operator with better control over the flow of voice packets. This can be used e.g. to avoid slow or unreliable links, and to route tunnels in the most efficient way. The encapsulation proposed in this document may also be used as a general voice over MPLS encapsulation to be defined as part of the voice over MPLS work [3]. Note that using PPP as a container within the MPLS tunnel provides an end-end authentication mechanism that helps to significantly improve the security of voice over MPLS implementations. All existing authentication mechanisms supported by PPP can be reused. In addition, the full set of PPP features and extensions can be readily utilised if required in a specific application scenario (in particular when an application presumes a bi-directional communication path). Specific examples include connectivity testing via echo request and link quality monitoring. 2. Protocol Operation This document is related to the work on tunneling multiplexed compressed RTP using L2TP [1] and borrows heavily from this document. 2.1. Compressed RTP RTP compression as defined in RFC 2508 [7] is a method for compressing the headers of IP/UDP/RTP datagrams to reduce overhead on particular (low-speed) links. In many cases, all three headers can be compressed to 2-4 bytes. It was motivated primarily by the specific problem of sending audio and video over 14.4 and 28.8 dialup modems. The RTP compression scheme takes advantage of the fact that these links tend to provide full-duplex communication, and performs best on local links with low round trip delay. Theimer Expires December 2000 [Page 3] Internet-Draft Tunneling Multiplexed CRTP in MPLS June 2000 When CRTP sessions are transported through a network using an MPLS tunnel, some of the basic assumptions used for CRTP over a single physical link may no longer be valid. We assume that the main issue to consider is the effect of packet loss, which would trigger CRTP state synchronisation involving at least one round trip time. This could potentially lead to unacceptable delays when the round trip transmission time is significant. There are two ways to address this problem: - Packet loss can be virtually eliminated by chosing appropriate traffic parameter constraints for the MPLS tunnel so that packet loss and state synchronisation can simply be ignored. - If packet loss cannot be ignored, specific measures to improve CRTP error recovery will be necessary as discussed in [1] and as required in a similar way when operating over L2TP tunnels. 2.2. PPP Multiplexing Reference [2] describes a PPP extension that enables multiple PPP payloads to be transported between two PPP endpoints within a single multiplexed PPP frame. This capability may be useful in order to improve bandwidth efficiency in voice trunking and access applications where often multiple RTP streams are active between a pair of voice gateways. PPP multiplexing may also be combined with CRTP and L2TP tunneling as described in [1]. Using MPLS tunneling instead of L2TP tunnels has the advantage that fewer simultaneous RTP sessions are necessary to achieve bandwidth efficiencies similar to those of CRTP. On the other hand, combining multiple RTP payloads into a single packet will also introduce additional delay. This delay depends on the number of RTP payloads per PPP packet as well as the number of active RTP flows, and there is again a tradeoff between bandwidth efficiency and delay. Combining the use of RTP compression, PPP multiplexing and MPLS tunneling results in - a per CRTP payload overhead of 3-5 bytes (2-4 bytes of CRTP header, in addition to the single byte applied to each CRTP payload for PPP multiplexing). Note that this happens to be very similar to the overhead required for ATM AAL2 encapsulation. - a tunnel overhead, which is amortised over all CRTP payloads contained within the PPP multiplexed frame, of 6 bytes (2 byte PPP protocol field for PPP multiplexing, and a 4 byte MPLS header). Theimer Expires December 2000 [Page 4] Internet-Draft Tunneling Multiplexed CRTP in MPLS June 2000 Note: even when all sub-frames within the PPP multiplexed frame are of identical type, the first sub-frame MUST still have a preceding PPP protocol field (as described in [2]). Note: trunking gateways are expected to choose a 16-bit session context identifier in order to better cope with the larger number of active calls in progress. 2.3. Encapsulation Formats 2.3.1 Compressed RTP The typical packet format for an RTP packet compressed with RTP header compression as defined in RFC 2508 is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + MSTI + + + + Context + & + UDP + + + ID + Link + Checksum + RTP Data + + + Sequence+ (optional) + + + (1-2) + (1) + (0,2) + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The minimum CRTP header (without UDP checksum) is 2 bytes. For trunking applications, we recommend using a 2 byte context ID to allow for a sufficient number of simultaneous RTP sessions between a pair of trunking gateways. Note that additional header fields may be present as indicated by the MSTI flags. 2.3.2 PPP Multiplexing The packet format of a multiplexed PPP packet as defined in [2] is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ + Mux +P| 1. + 1. + + +P| n-th + n-th + + + PPP +F| Length+ PPP + 1. + +F| Length+ PPP + n-th+ + Prot. +F| + Prot. + Info+ ~ +F| + Prot. + Info+ + Field + |(7bits)+ Field + + + |(7bits)+ Field + + + (2) +(1 byte )+ (0-2) + + +(1 byte) + (0-2) + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+ Each PPP subframe has a 1 to 3 byte header. The first header byte contains a 7 bit length field plus a one bit flag that indicates the presence of the PPP protocol field. The PPP protocol field is only included when the protocol field of a subframe differs relative to the previous subframe. Thus, when all subframes contain compressed RTP payload packets of the same type, only the first subframe needs to actually contain a protocol field. Theimer Expires December 2000 [Page 5] Internet-Draft Tunneling Multiplexed CRTP in MPLS June 2000 2.3.3 PPP Encapsulation in MPLS Tunnel The packet format for carrying PPP in MPLS is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + MPLS Header + PPP + PPP + + + Prot. + Payload + + + Field + + + (4 bytes) + (1-2) + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The PPP protocol field directly follows the MPLS header. The address and control field that would normally precede the protocol field has been removed. Note that the MPLS header does not explicitly identify the protocol carried inside the MPLS payload. The protocol type must be bound to the label in the MPLS header when the tunnel is established (see following section). 2.4. MPLS Tunnel Establishment As noted in [4], TE-RSVP [5] and CR-LDP [6] can be used as the bearer control protocol to perform LSP setup and corresponding label binding for voice over MPLS. However, in the context of tunneling multiplexed and/or compressed RTP over an MPLS label switched path, RSVP is the preferred protocol due to its ability to identify the protocol type to be carried inside the MPLS tunnel. The label request object of TE- RSVP [5] MUST identify the protocol type using the standard Ethertype value for PPP (0x880B). CR-LDP does not have a similar capability, so that the MPLS tunnel endpoint must have another means to identify the protocol type carried by the tunnel. Note that MPLS tunnels are always uni-directional. A tunnel must exist in both directions before PPP link negotiation can start, and both forward and reverse tunnel must be combined to provide a bi- directional link to PPP. This can be achieved using TE-RSVP signalling as follows (use of CR-LDP is for further study): Step 1: the initiating endpoint (e.g. a trunking gateway) sets up a uni-directional MPLS tunnel to the peer. The label request object MUST identify the protocol type as PPP (0x880B). The session attribute object MUST contain a session name that MUST be unique for the (ingress node, egress node) pair as identified by their IP addresses. The LSP tunnel session object MUST contain the IP address of the ingress node in the extended tunnel ID field. This address is used as tunnel endpoint address in step 2. To uniquely identify a bidirectional session consisting of two tunnels, we use the combination of the destination IP address (an address of the node which is the egress of the tunnel), the session name, and the tunnel ingress node's IP address. This mechanism allows multiple bidirectional tunnels to exist between the same pair of nodes. Theimer Expires December 2000 [Page 6] Internet-Draft Tunneling Multiplexed CRTP in MPLS June 2000 Step 2: upon successful establishment of the tunnel in forward direction, the receiving node has to establish a tunnel in reverse direction. Note that both tunnels are independent from the prespective of the network. There is no requirement that both tunnels follow the same route or must be treated as a single instance by the network. Current MPLS signalling protocols lack an explicit indication that a reverse tunnel is requested when setting up a label switched path. Therefore we propose to infer from the presence of the PPP protocol type in the label request object received by the egress tunnel endpoint that a reverse tunnel is required. If an explicit flag or some other mechanism for reverse path establishment should be defined in MPLS signalling protocols, this could be used as well. The reverse tunnel MUST have the same protocol type and it MUST carry the same session name as the forward tunnel in its session attribute object. The unique session name allows forward and reverse tunnels to be associated, thus forming a bi-directional link for PPP. The tunnel endpoint address used to establish the reverse tunnel is derived from the extended tunnel ID signalled with the forward tunnel (specifying the IP address of the ingress node). Traffic parameter constraints SHOULD be identical in forward and reverse direction, assuming that bandwidth and QoS requirements of voice applications are symmetric. Step 3: PPP link negotiation may start as soon as both tunnels are operational and bound to PPP. At this point the MPLS tunnels appear as a point-point link for PPP messages used in link establishment and network layer protocol negotiation. This allows the procedures defined in [8] to be used for negotiating the use of - CRTP within a tunnel - compression/decompression parameters for the CRTP session - PPP multiplexed frame as supported by both tunnel endpoints. 2.5 Resource Reservation in the Presence of Header Compression MPLS supports quality of service either through explicit resource reservation or by requesting specific forwarding treatment of packets based on the DiffServ architecture. Both concepts can be applied to voice over MPLS. While it is not the intention of this document to define an overall architecture for QoS support in voice over MPLS (see [3] and [4]), some aspects specific to tunneling CRTP over MPLS are addressed in this section. We focus on MPLS tunnels with explicit resource reservation, assuming that the use of pure DiffServ mechanisms is not affected by the presence of compression. Resource reservation is a way to guarantee quality of service for all RTP flows carried by an MPLS tunnel, provided that the resources Theimer Expires December 2000 [Page 7] Internet-Draft Tunneling Multiplexed CRTP in MPLS June 2000 requested actually match the traffic injected into the tunnel. This must be ensured by applying admission control for each new CRTP flow, and it may even be necessary to police the traffic per MPLS tunnel. Applying compression obviously affects the traffic characteristics and must be adequately accounted for when admission control is performed. Detailed knowledge about the compression scheme and its implementation is required for an accurate estimation of the bandwidth reduction resulting from header compression. Since CRTP compressor/decompressor and MPLS tunnel endpoints coincide, the required knowledge is basically available in each tunnel endpoint. However, CRTP parameters are typically negotiated after call admission control is performed, making it impossible to precisely calculate the required bandwidth during the call setup phase. It may be possible to predict the compression gain based on the past history of CRTP flows established within the same MPLS tunnel. However, there is no guarantee that future RTP flows will experience the same compression ratio. On the contrary, it is likely that rising traffic volumes within a tunnel will increase packet loss and thus reduce compression efficiency. Hence, it is highly recommended to apply a safety margin to admission control in the presence of compression. In cases where the MPLS tunnel endpoint is located outside of the voice gateway, additional per-RTP-flow signalling is required to enable end-end resource reservation. Using RSVP signalling for VoIP in conjunction with aggregation based on MPLS is discussed in [4]. The same concepts can be applied when tunneling CRTP over MPLS. In addition, it may be beneficial to add a compression hint to RSVP as defined in [12] to notify the tunnel ingress that compression should be applied to this particular RTP flow. This would allow admission control to estimate the compression gain prior to performing the actual CRTP negotiation for that flow. An alternative would be to perform conservative admission control without considering compression for the new flow, and updating the actual resource allocation later when more details are available. 4. Security Considerations Using PPP in an MPLS tunnel actually improves the security of MPLS and voice over MPLS applications by enabling inband authentication of the tunnel endpoints through PPP. Existing PPP authentication mechansisms are reused, so that no new security issues are raised by this proposal. 5. Acknowledgements The author would like to thank Mike Chapman for his constructive comments and suggestions. Theimer Expires December 2000 [Page 8] Internet-Draft Tunneling Multiplexed CRTP in MPLS June 2000 6. References [1] B. Thompson, T. Koren, D. Wing: "Tunneling multiplexed Compressed RTP". Work in progress, March 2000. [2] R. Pazhyannur, I. Ali, C. Fox: "PPP Multiplexed Frame Option". Work in progress <draft-ietf-pppext-pppmux-00.txt>, January 2000. [3] A. Kankkunen, et al: "Voice over MPLS Framework". Work in progress <draft-kankkunen-vompls-fw-00.txt>, March 2000. [4] F. Le Faucheur, B. Thompson, A. Chiu: "Bearer Control for VoIP and VoMPLS Control Plane". Work in progress , March 2000. [5] D.O. Awduche, et al: "Extensions to RSVP for LSP Tunnels". Work in progress <draft-ietf-mpls-rsvp-lsp-tunnel-05.txt>, March 2000. [6] B. Jamoussi, et al: "Constraint-Based LSP Setup using LDP". Work in progress <draft-ietf-mpls-cr-ldp-03.txt>, October 1999. [7] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for Low- Speed Serial Links", RFC2508, February 1999. [8] M. Engan, S. Casner, C. Bormann, "IP Header Compression over PPP", RFC2509, February 1999. [9] L. Berger, J. Jeffords: "MPLS/IP Header Compression". Work in progress <draft-berger-mpls-hdr-comp-00.txt>, January 2000. [10] G. Swallow, L. Berger: "Simple Header Compression". Work in progress <draft-swallow-mpls-simple-hdr-compress-00.txt>, March 2000. [11] S. Makam et al: "Framework for MPLS Based Recovery". Work in progress <draft-makam-mpls-recovery-frmwrk-00.txt>, March 2000. [12] B. Davie et al: "Integrated Services in the Presence of Compressible Flows". Work in progress , February 2000. 6. Authors' Address Thomas Theimer Siemens AG Hofmannstr. 51 81359 Munich, Germany Email: Thomas.Theimer@icn.siemens.de Theimer Expires December 2000 [Page 9] Internet-Draft Tunneling Multiplexed CRTP in MPLS June 2000 Theimer Expires December 2000 [Page 10]