Internet Engineering Task Force AVT Working Group Internet Draft R. Pazhyannur, I. Ali Document: Motorola Expires: December 22, 1999 June 22, 1999 Multiplexing Compressed RTP/UDP Packets in a PPP Frame 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. 1. Abstract This draft proposes a scheme to increase the capacity of low-speed transmission links, T-1/E-1 or smaller, to transport low-bit rate voice applications over PPP. Given the relatively small payload size of the voice packets (average of 8 bytes for certain cellular networks) protocol overheads due to PPP, IP, UDP, and RTP are significant in determining the link capacity. The scheme proposed here is to multiplex compressed RTP/UDP packets into a single PPP frame. As a result, the PPP overhead (5-7 bytes) is distributed over multiple compressed RTP/UDP packets. 2. Introduction A typical application of the PPP multiplexing scheme is the CDMA cellular infrastructure. The architecture relevant to this draft is shown in Figure 1. Voice packets are transported between the Base Station Transceiver (BTS) and the Selector/Distributor Unit (SDU) through a router/switch node. The link between the BTS and the router is a low-speed link, typically a T-1/E-1 link or smaller depending on the load of the BTS. The link between the router/switch and the SDU is typically a high-speed link. Voice packets formatted according to the Code Division Multiple Access (CDMA) standard IS- 634, are exchanged between the SDU and the BTS. IS-634 expects the transport layer to provide context information for the voice packets, i.e., mapping a voice call reference number to a voice R. Pazhyannur, I. Ali [Page 1] PPP Mux June, 1999 packet. Hence, the IS-634 packets need to be encapsulated in UDP. However, the use of RTP over UDP is not critical, since two key features of RTP (sequence number and time stamp) are already provided in the IS-634 packet. ------- -------- | | PPP -------- | | | BTS |--------| |--------| SDU-1 | | 1 | | | -------- ------- | | -------- ------- | Router/ |--------| | | | PPP | Switch | | SDU-2 | | BTS |--------| | -------- | 2 | | | -------- ------- | |--------| | | | | SDU-3 | --------- -------- Figure 1: A section of the CDMA cellular network architecture The IP/UDP headers (and the RTP header if used) are compressed prior to the PPP encapsulation. The details of an additional PPP multiplexing of the compressed packets are provided below. 3. Description The key idea is to multiplex multiple compressed UDP packets into a single PPP frame by appending a length field to the beginning of packets. During the setup phase of PPP, the two end-points negotiate to support the multiplexed compressed UDP type of payload or the multiplexed compressed RTP/UDP type of payload, using negotiation procedures specified in IPCP [RFC1332]. During the data transfer phase a PPP frame containing multiplexed compressed UDP packets has a pre-assigned value in the PPP Protocol Field. On receiving a PPP frame with the appropriate Protocol Field value, the PPP software passes the PPP frame to the UDP mux/demux software. Suggested PPP Data Link Layer Protocol Field values in the PPP header MUXED_COMPRESSED_UDP_8 The frame contains multiple compressed header UDP datagrams with the format as specified in [CRTP] Section 3.3.3, using 8-bit CIDs. Suggested Value: 3067 (hex) MUXED_COMPRESSED_RTP_8 The frame contains multiple compressed header RTP datagrams with the format as specified in [CRTP] Section 3.3.2, using 8-bit CIDs. Suggested Value: 3069 (hex) R. Pazhyannur, I. Ali [Page 2] PPP Mux June, 1999 Payload Format: The format of the complete PPP frame along with multiple compressed UDP packets is shown in Figure 2. The Protocol Field value in the PPP header corresponds to MUXED_COMPRESSED_UDP_8. The format for a PPP frame containing header-compressed RTP packets is similar to that shown in Figure 2 with the Protocol Field value in the PPP header corresponding to MUXED_COMPRESSED_RTP_8. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ | + + + + + + + + | | PPP + + H.C. + + H.C.+ + + H.C + PPP | |Header + Len1 + UDP1 + Len2+ UDP2+ ~ + LenN+UDPN + CRC | | + + + + + + + + | | (3-5) + (1) + + (1) + + + (1) + + (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+ *H.C. Header Compressed Figure 2. Multiplexing header-compressed UDP packets in a PPP frame PPP Header: In the default mode, PPP appends a 5 byte header and 2 byte trailer to each IP packet; thus the default PPP overhead is 7 bytes. When the two ends of the link negotiate to reduce the header of PPP through address-and-control-field-compression (ACFC) [RFC1661], the PPP overhead can be reduced to 5 bytes by eliminating the two bytes corresponding to the Address Field and the Control Field. Length Field: Each header-compressed UDP or header-compressed RTP/UDP packet has a one byte length field appended to the beginning of the packet, which is the length of the packet (not including the length field) in bytes. An alternative PPP multiplexing scheme would be to append to the beginning of each packet a one-byte length field and a two byte PPP Data Link Layer Protocol Field. With this scheme one Protocol Field value in the outer PPP header of the multiplexed frame would be required and packets of different protocols, such as header- compressed UDP and header-compressed TCP, can be multiplexed into the same PPP frame. However, this scheme increases the fixed overhead per multiplexed packet from 1 byte to 3 bytes and hence is not considered further. 4. Comparison with RTP multiplexing schemes The objective of the PPP multiplexing scheme proposed here is the same as that for proposed RTP multiplexing schemes [GeRM], [RTPMux] and [UserMux], namely to reduce the protocol overhead in transporting low bit-rate voice. However, there are significant differences between the two. PPP multiplexing scheme is a link-layer scheme whereas RTP multiplexing schemes are application layer schemes in which different RTP flows are multiplexed/demultiplexed at the RTP source/destination. R. Pazhyannur, I. Ali [Page 3] PPP Mux June, 1999 This difference is evident in the way multiplexing schemes may be utilized in the cellular infrastructure. PPP multiplexing occurs between the end-points of the low-speed link (the router and the BTS in Figure 1). Consequently, all RTP/UDP packets destined to the same BTS from different SDUs can be multiplexed into a PPP frame. By contrast, RTP multiplexing schemes would only multiplex packets with identical source and destination points (in this case the BTS and SDU). This limitation is highlighted in cases of large fan-out of BTSs from a single SDU, reducing the potential multiplexing gains for RTP multiplexing schemes. Another difference between PPP multiplexing and RTP multiplexing is that the length field in PPP multiplexing is more like a separator than the channel identification (CID) field used in RTP multiplexing schemes [UserMux] and [RTPMux]. Specifically, the multiplexed packets do not have to be separated by a unique identifier, since the information provided by the CID is already available in the compressed header of the multiplexed packets. This makes the PPP multiplexing scheme simpler than RTP multiplexing schemes. 5. Performance consideration Significant capacity improvements arise with the use of PPP multiplexing for low-bit rate applications like cellular voice. For a typical CDMA 8 Kbps coder, the average voice packet size is 8 bytes along with 6-8 bytes of control information. For CRTP, the protocol overhead per voice packet would be 7 bytes (5 bytes of PPP, and 2 bytes of compressed RTP/UDP/IP). Note that even with compressed RTP, the combined PPP and RTP overhead is significant. In the PPP multiplexing scheme each packet has a fixed overhead of 3 bytes (2 bytes of compressed RTP/UDP/IP and one byte for the Length Field) and the 5 bytes of PPP overhead is distributed over multiple RTP/UDP packets. The total number of voice-packets that are multiplexed is obtained by considering trade-offs between multiplexing delays (incurred due to waiting for multiple voice-packets) and improvements in link capacity. (However, in CDMA applications, voice packets are ęsynchronizedĘ in the sense that they arrive almost simultaneously. Consequently, there are no multiplexing delays.) A related issue is the size of the PPP frame used for multiplexing. Clearly, the larger the size the more the multiplexing gain. However, so is the corresponding loss of the voice packets due to transmission error of a PPP frame. Detailed analysis and simulation for the CDMA application shows that on a T-1 link, the call carrying capacity can be improved by 25-30 percent when using PPP multiplexing as compared to using CRTP only. 6. IANA Considerations The values suggested for the PPP Data Link Layer Protocol Field will need to be registered with IANA. Though the suggested values R. Pazhyannur, I. Ali [Page 4] PPP Mux June, 1999 specified here conforms to the rules stipulated in [RFC1700] and do not conflict with any currently assigned value, the request for the new Protocol Field values should be reviewed by a designated expert in the PPP arena and possibly also by the mailing list of the PPP Extensions Working Group. 7. Security Considerations This draft does not impose additional security considerations beyond those that apply to PPP and header-compression schemes over PPP. 8. References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP9, RFC 2026, October 1996. [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2509] Engan, M., Casner, S., and Bromann C., "IP Header Compression over PPP", RFC 2509, February 1999. [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992. [RFC1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC1700, USC/Information Sciences Institute, October 1994. [UserMux] Subbiah, B., and Sengodan, S., "User multiplexing in RTP payload between IP telephony gateways", Internet Draft, Internet Engineering Task Force, Aug. 1998. Work in Progress. [RTPMux] Rosenberg, J., and Schulzrinne, H., "An RTP payload format for user multiplexing", Internet Draft, Internet Engineering Task Force, May 1998. Work in progress. [GeRM] Handley, M., "GeRM: Generic RTP Multiplexing," Internet Draft, Internet Engineering Task Force, November 1998. Work in progress. 11. Author's Addresses Rajesh Pazhyannur Motorola, Network Solutions Sector 1501, W. Shure Drive Arlington Heights, IL 60004 Phone: (847) 632-4524 Email: pazhynnr@cig.mot.com Irfan Ali R. Pazhyannur, I. Ali [Page 5] PPP Mux June, 1999 Motorola, Network Solutions Sector 2A8, 1421 Shure Drive Arlington Heights, IL 60004 Phone: (847) 632-3281 Email: fia225@email.mot.com R. Pazhyannur, I. Ali [Page 6] PPP Mux June, 1999 Full Copyright Statement "Copyright (C) The Internet Society (date). 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 R. Pazhyannur, I. Ali [Page 7]