Internet Engineering Task Force AVT Internet Draft J.Rosenberg,B.Aboba,H.Schulzrinne draft-rosenberg-rtpproto-00.txt Bell Labs/Microsoft/Columbia March 6, 1998 Expires: September 6, 1998 Elevating RTP to Protocol Status STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing 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 mate- rial or to cite them other than as ``work in progress''. To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. 1 Abstract This document discusses the issues involved in elevating RTP to the status of protocol, equivalent to TCP or UDP. This will result in all RTP packets being explicitly labeled as such in the packet header. This vastly simplifies the problem of classifying real time streams. Such classification operations are essential for successful deploy- ment of RTP header compression, differentiated services, and traffic isolation. We define the format of the RTP protocol header, and dis- cuss issues of backwards compatibility. 2 Introduction Over the last few years, RTP [1] has gained widespread acceptance as the transport protocol for real time services in the Internet. It has been adopted by the ITU-T as part of the H.323 protocol suite [2], it J.Rosenberg,B.Aboba,H.Schulzrinne [Page 1]
Internet Draft RTP as Protocol March 6, 1998 is used in many commercial and public software packages, and it is used extensively on the mbone. Its success is due in large part to the growing presence of real time traffic on the Internet, a trend which is likely to continue. At the same time, Internet routers and hosts are becoming more aware of the traffic that they are carrying. Commerical routers can drop, maintain logging records, and isolate in separate queues traffic based on UDP and TCP port numbers. The integrated services architec- ture [3,4,5], and the recently defined differentiated services , both require routers to classify traffic based on fields and parameters outside of the IP header. Unfortunately, RTP has always been difficult to classify. Its packets are encapsulated in UDP, and do not use a single, static port number. This makes them very difficult to identify correctly. Hosts have resorted to heuristics, such as looking for periodic packets with certain byte values remaining static or incrementing predictably. These heuristics are both stateful and complex, and do not scale well at all. Elevating RTP to protocol status, equivalent to TCP and UDP, would imply that RTP packets are explicitly labeled as such in the IP packet header. Such a change has a wide variety of useful implica- tions, but also comes at a cost. This document discusses the motiva- tions for such a change, discusses what the format of the new RTP would look like, describes implementation approaches, and discusses the important issue of backwards compatibility. 3 Motivations We see a number of important applications where large scale classifi- cation of RTP packets is neccesary. We discuss each in detail, and weigh the usefulness of elevating RTP to protocol status as a solu- tion. 3.1 Differentiated Services Work has recently begun to define differentiated services on the Internet. These services generally allow an ISP to mark packets at the periphery of the network. Within the network, the packets receive special treatment depending on the marking. For example, a premium service class has been defined. This service emulates a completely unloaded network, giving minimal delays and loss. Such a service is ideal for real time applications, for example. An ISP could use the premium service to offer improved quality for real time traffic only. In order to implement this, packets must be classified at the periph- ery so that they can be appropriately marked. By having RTP packets clearly identified, the periphery routers of the ISP will be able to mark them for premium service within the J.Rosenberg,B.Aboba,H.Schulzrinne [Page 2]
Internet Draft RTP as Protocol March 6, 1998 ISP's network. Making RTP a protocol is an efficient way to accom- plish this. On the other hand, clients could mark their packets as being real time by setting bits in other fields of the packet. In fact, the very same TOS bits used by diffserv could be used by clients to express how they would like the packets to be treated. These bits could then be modified at the periphery of the network by the ISP to provide the desired level of service. 3.2 Static Router Configuration Most commercially available IP routers allow administrators to con- figure the router to queue packets separately based on the value of the source IP address, destination IP address, source port, destina- tion port, protocol tuple. It would be very beneficial to an ISP to be able to identify real-time traffic, isolate it from other flows, and provide it with some amount of bandwidth. Currently, since RTP cannot be classified by 5-tuple, it is placed in the default queue with lots of other things that need much different handling compared to real time. Having RTP be an IP protocol would improve the situation in two ways. First, RTP packets could be identified by the protocol field in the IP header. Secondly, the payload type field in the RTP header could be used to infer information about the codec used for the media com- pression. This would allow a router to make a very educated guess about the bandwidth and QoS requirements for the flow. As with differentiated services, one could simply use a TOS value to indicate that the traffic was real time (which may or may not be RTP). However, having RTP packets explicitly labeled would allow routers to look in RTP-specific header fields for additional informa- tion. 3.3 Firewalls Having RTP packets be labeled would provide additional information that could be used by firewalls. Firewalls could be configured to drop or accept all RTP traffic coming into or leaving a domain. Cur- rently, RTP traffic cannot be distinguished from other applications which use dynamic UDP ports. This would no longer be the case. Firewall administrators would also be able to block RTCP traffic, while admitting RTP. This is extremely useful for mbone sessions. Typically, these will have one sender of data, with hundreds of lis- teners, each of which sends only RTCP. These RTCP packets can cause a lot of network state (in the form of (S,G) entries) to be created, J.Rosenberg,B.Aboba,H.Schulzrinne [Page 3]
Internet Draft RTP as Protocol March 6, 1998 and can also cause significant network traffic (due to flooding in DVMRP). Filtering incoming RTCP, but not RTP, would allow a network administrator to offer mbone service without needing to worry about these RTCP problems. 3.4 RTP Header Compression RTP header compression [6] is typically used over dialup modem lines where bandwidth is at a premium. Without it, the RTP/UDP/IP headers require 10 kbps alone when used with the G.729 speech coder with a 30ms packetization delay. With it, this rate is reduced to less than half a kilobit per second. This reduction can mean the difference between transmitting video and having no video at all. The compres- sion algorithm itself relies on the compressor classifying RTP pack- ets, and maintaining state for the flow. Unfortunately, when the com- pression is performed in the downstream direction (from the access device to the host), the access device must decide which packets to apply compression to. Having RTP packets be explicitly labeled makes this process vastly simpler. The compressor could also look at the SSRC field to decide to which compression context the packet belongs. We observe that the access device could instead decide which packets are RTP based on signaling from the host. An additional PPP packet type could be created indicating the port number that the host is expecting RTP packets on. Hosts would need to send these packets after opening a socket for RTP. This would require explicit support in the OS, but it is probably no more complicated than the OS support required to elevate RTP to protocol status. 4 Alternate Solution: RTP Port Numbers One approach to identifying RTP packets could be to assign it a static pair of port numbers (one for RTP, one for RTCP). This is not acceptable, however. In some cases, a host may run several real time applications (such as a voice conferencing tool and a video confer- encing tool), each of which may independently require its own ports. An alternative would be to assign a block of port numbers to RTP. This would allow for multiple simultaneous applications and still allow RTP traffic to be identified. The weakness of this approach is twofold: (1) it requires a choice of an upper bound on the number of simultaneous RTP sessions in a client, and (2) other UDP-based applications with dynamic port num- bers may randomly choose an RTP-assigned port. The latter problem can be made to eventually disappear if new applications are written to avoid the UDP space. In the interim (which may be forever), some non real time traffic could be mistakenly classified as real time. J.Rosenberg,B.Aboba,H.Schulzrinne [Page 4]
Internet Draft RTP as Protocol March 6, 1998 5 Solution: RTP as Protocol Our proposal would be to have the new RTP protocol have a header which is identical to the concatenation of the UDP header and RTP header. The new RTP protocol header would then look like: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RTP Source Port | RTP Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The source port, destination port, length, and checksum have exactly the same syntax and semantics as in UDP. Here, however, the port num- bers refer to RTP ports. 6 Impact on Network Aware Devices Elevation of RTP to protocol status would have an impact on almost all network aware devices. This section discusses the implications for each. 6.1 Hosts When a packet arrives at a host, the operating system typically looks at the IP protocol field, and processes the packet based on it. Since RTP would become a new protocol, it is important to consider how to handle it in operating systems. There seem to be three approaches: 1. Long Term. Significant extensions to the standard BSD sockets API can be made to support RTP as another socket type. The kernel would be upgraded to process RTP and RTCP packets. The sockets extensions would provide functions for interacting J.Rosenberg,B.Aboba,H.Schulzrinne [Page 5]
Internet Draft RTP as Protocol March 6, 1998 with RTCP, and setting the various fields and parameters in the RTP header. Applications would need to be written to make use of the new API. It is not clear that having RTP in kernel space is the most efficient approach, but elevating RTP to full protocol makes it a possibility at least. 2. Near Term. A small extension to the BSD sockets API can be made to define a new protocol type ( IPPROTO_RTP) which can be used when creating a socket of type SOCK_DGRAM. The resulting socket is identical to all respects to the standard UDP socket, except the value of the protocol field in the IP header is set to that of RTP when sending. When receiving, packets are sent to the socket only when the IP protocol field indicates RTP. When sending data to the socket, the kernel would add only the UDP portion of the RTP header. When receiv- ing, it would strip only the UDP portion. This means that the RTP part of the header would still need to be processed in application space, but the UDP portion would be in the kernel. This solution requires absolutely minimal changes to existing application software, which perform RTP, but not UDP process- ing. The kernel modifications are minor. 3. Short Term. Before operating systems are changed at all, the new RTP protocol can be implemented purely in user space by making use of the raw socket. This would require applications to implement both the RTP and UDP portions of the protocol. The UDP code can easily be lifted from current operating sys- tems. Even if it cannot, its implementation is fairly straightforward. We anticipate that implementations would gradually migrate from the short term solution to the near term. It is not clear whether the long term solution is practical. An unfortunate difficulty with the short term solution is that most operating systems only allow users with root permissions to access the raw socket. This may be problematic for many applications. 6.2 Routers Routers do not need to understand the IP protocol field in order to forward packets. However, most routers can be programmed with filters that drop or classify packets based on this field. This operation is only a problem if the routers cannot be configured to accept new val- ues for this field. Routers which accept numeric values should oper- ate correctly. 6.3 Firewalls J.Rosenberg,B.Aboba,H.Schulzrinne [Page 6]
Internet Draft RTP as Protocol March 6, 1998 In all likelihood, most firewalls currently drop all traffic that is not UDP or TCP. This would cause the new RTP packets to be discarded ubiquitously by firewalls. To fix the problem, firewalls would need to be upgraded to recognize the new protocol type, and accept filter rules based on it. 6.4 Tools A number of host tools rely on examination of the IP protocol header. Most important among these is tcpdump, based on the Berkeley packet filter. Tcpdump would not be able to recognize the new RTP, and would need to be upgraded in order to do this. This issue is minor, but at least worth a mention. Other similar tools, such as packet sniffers and network analyzers, would also need to eventually be upgraded to recognize the new proto- col. In the long run, this would be very advantageous. Network tools cannot recognize RTP packets at all. With this change, they would be able to recognize and decode RTP packets. They could also recognize and decode RTCP packets, which may provide valuable feedback when doing network debugging. 6.5 Network Address Translators Network Address Port Translation [7] allows for many hosts in a stub domain to map their IP addresses (which may be routable or un- routable) to a single IP address. NAPT does this by translating the source IP address and port number. Many NAPT devices currently only support UDP or TCP, and thus would be unable to handle a new protocol without an upgrade. In any case, real-time applications present spe- cial difficulties for NAT or NAPT implementations, since protocol such as SDP require IP addresses to be carried in application packets 7 Backwards Compatibility It is important to consider how to handle interoperability between end systems using the new RTP protocol and those using the old. We can classify RTP applications into two broad types - broadcast and interactive. The interoperability issues are different in both cases. 7.1 Interactive For interactive applications, there is usually some kind of signaling protocol that establishes communications before the media is trans- ported using RTP. These signaling protocols usually indicate the var- ious codecs that the end systems are capable of decoding and encod- ing. The use of the new RTP can be considered as just another capa- bility. Both sides express their ability to receive the new RTP. J.Rosenberg,B.Aboba,H.Schulzrinne [Page 7]
Internet Draft RTP as Protocol March 6, 1998 Applications implementing the new RTP should be prepared to also transmit using the old RTP. As a result, a common RTP version can always be found. In the case of H.323, this would require the addition of a single new ASN.1 element in H.245 [8], which expresses the ability to receive the new RTP. As an alternative, backwards compatibility can be achieved purely at the RTP layer by making use of ICMP errors. Any host implementing the new RTP would also be required to implement the old one. Whenever a host listens to an RTP socket, the operating system accepts packets which are either UDP or the new RTP with the given port number. This will allow new RTP implementations to receive packets from both old and new without explicit application signaling. This comes at the expense of an effective sharing of port space between UDP and RTP. When a host implementing the new RTP wishes to send a packet, it sends it using the RTP protocol number. Hosts which do not understand the new RTP protocol should generate an ICMP protocol unreachable error message, and return it back to the source. The sender's operat- ing system must then use the old RTP for sending packets on that socket from that point forward. This will allow a new RTP implementa- tion to talk to either a new or old one, thus achieving full back- wards compatibility. The cost is additional smarts in the operating system, and potential loss of the first few RTP packets until the host switches back to RTP. This approach fails for multicast. 7.2 Broadcast For broadcast applications, such as mbone conferences, there is no capabilities exchange. However, there is usually some kind of session advertisement (using SAP [9] and SDP [10], for example). These announcements include the port numbers and multicast group used for the media. They could be extended to also indicate whether the new RTP protocol is being used. This would allow end systems to know whether they can correctly receive the media or not. If a broadcast is taking place using the new RTP, and there are old receivers trying to listen, they will not be able to receive the media. However, this is no different than the case where a broadcast is taking place using a codec that some client applications cannot decode. The only solu- tion is a software upgrade of the clients. 8 Conclusion We have discussed the issues related to elevating RTP to protocol status, which would give it its own unique IP protocol number like TCP and UDP. The main motivation for this is to allow for J.Rosenberg,B.Aboba,H.Schulzrinne [Page 8]
Internet Draft RTP as Protocol March 6, 1998 classification of RTP packets in end systems, routers, and other devices. Classification is needed for services such as RTP header compression, real time flow isolation, and differentiated services. We have proposed that the new RTP protocol have a header which is the concatenation of the current UDP and RTP header fields. This simpli- fies implementation, and leaves open a smooth migration path for deployment. We have also discussed backwards compatibility, and how it can be handled for broadcast and interactive applications. 9 Full Copyright Statement Copyright (C) The Internet Society (1998). 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 implmentation 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 Soci- ety 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 fol- lowed, 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 MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 10 Authors Addresses Jonathan Rosenberg Bell Laboratories, Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733 email: jdrosen@bell-labs.com J.Rosenberg,B.Aboba,H.Schulzrinne [Page 9]
Internet Draft RTP as Protocol March 6, 1998 Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 email: aboba@microsoft.com Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 email: schulzrinne@cs.columbia.edu 11 Bibliography [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP: a transport protocol for real-time applications, Request for Comments (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996. [2] ITU-T, Recommendation H.323 - Visual Telephone Systems and Equipment for Local Area Networks which Provide Non-Guaranteed Qual- ity of Service , February 1996. [3] J. Wroclawski, The use of RSVP with IETF integrated services, Request for Comments (Proposed Standard) 2210, Internet Engineering Task Force, Oct. 1997. [4] J. Wroclawski, Specification of the controlled-load network ele- ment service, Request for Comments (Proposed Standard) 2211, Internet Engineering Task Force, Oct. 1997. [5] R. Guerin, C. Partridge, and S. Shenker, Specification of guaran- teed quality of service, Request for Comments (Proposed Standard) 2212, Internet Engineering Task Force, Oct. 1997. [6] S. Casner and V. Jacobson, Compressing IP/UDP/RTP headers for low-speed serial links, Internet Draft, Internet Engineering Task Force, Nov. 1996. Work in progress. [7] P. Srisuresh and K. Egevang, The ip network address translator (nat), (internet draft), Internet Engineering Task Force, Sept. 1997. Work in Progress. [8] International Telecommunication Union, Control protocol for mul- timedia communication, Recommendation H.245, Telecommunication J.Rosenberg,B.Aboba,H.Schulzrinne [Page 10]
Internet Draft RTP as Protocol March 6, 1998 Standardization Sector of ITU, Geneva, Switzerland, Mar. 1996. [9] M. Handley, SAP: Session announcement protocol, Internet Draft, Internet Engineering Task Force, Nov. 1996. Work in progress. [10] M. Handley, SDP: Session description protocol, Internet Draft, Internet Engineering Task Force, Nov. 1997. Work in progress. J.Rosenberg,B.Aboba,H.Schulzrinne [Page 11]