idnits 2.17.1 draft-rosenberg-rtpproto-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 6, 1998) is 9541 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 441 looks like a reference -- Missing reference section? '2' on line 445 looks like a reference -- Missing reference section? '3' on line 449 looks like a reference -- Missing reference section? '4' on line 453 looks like a reference -- Missing reference section? '5' on line 457 looks like a reference -- Missing reference section? '6' on line 461 looks like a reference -- Missing reference section? '7' on line 465 looks like a reference -- Missing reference section? '8' on line 469 looks like a reference -- Missing reference section? '9' on line 473 looks like a reference -- Missing reference section? '10' on line 476 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force AVT 2 Internet Draft J.Rosenberg,B.Aboba,H.Schulzrinne 3 draft-rosenberg-rtpproto-00.txt Bell Labs/Microsoft/Columbia 4 March 6, 1998 5 Expires: September 6, 1998 7 Elevating RTP to Protocol Status 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference mate- 19 rial or to cite them other than as ``work in progress''. 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Distribution of this document is unlimited. 29 1 Abstract 31 This document discusses the issues involved in elevating RTP to the 32 status of protocol, equivalent to TCP or UDP. This will result in all 33 RTP packets being explicitly labeled as such in the packet header. 34 This vastly simplifies the problem of classifying real time streams. 35 Such classification operations are essential for successful deploy- 36 ment of RTP header compression, differentiated services, and traffic 37 isolation. We define the format of the RTP protocol header, and dis- 38 cuss issues of backwards compatibility. 40 2 Introduction 42 Over the last few years, RTP [1] has gained widespread acceptance as 43 the transport protocol for real time services in the Internet. It has 44 been adopted by the ITU-T as part of the H.323 protocol suite [2], it 45 is used in many commercial and public software packages, and it is 46 used extensively on the mbone. Its success is due in large part to 47 the growing presence of real time traffic on the Internet, a trend 48 which is likely to continue. 50 At the same time, Internet routers and hosts are becoming more aware 51 of the traffic that they are carrying. Commerical routers can drop, 52 maintain logging records, and isolate in separate queues traffic 53 based on UDP and TCP port numbers. The integrated services architec- 54 ture [3,4,5], and the recently defined differentiated services , both 55 require routers to classify traffic based on fields and parameters 56 outside of the IP header. 58 Unfortunately, RTP has always been difficult to classify. Its packets 59 are encapsulated in UDP, and do not use a single, static port number. 60 This makes them very difficult to identify correctly. Hosts have 61 resorted to heuristics, such as looking for periodic packets with 62 certain byte values remaining static or incrementing predictably. 63 These heuristics are both stateful and complex, and do not scale well 64 at all. 66 Elevating RTP to protocol status, equivalent to TCP and UDP, would 67 imply that RTP packets are explicitly labeled as such in the IP 68 packet header. Such a change has a wide variety of useful implica- 69 tions, but also comes at a cost. This document discusses the motiva- 70 tions for such a change, discusses what the format of the new RTP 71 would look like, describes implementation approaches, and discusses 72 the important issue of backwards compatibility. 74 3 Motivations 76 We see a number of important applications where large scale classifi- 77 cation of RTP packets is neccesary. We discuss each in detail, and 78 weigh the usefulness of elevating RTP to protocol status as a solu- 79 tion. 81 3.1 Differentiated Services 83 Work has recently begun to define differentiated services on the 84 Internet. These services generally allow an ISP to mark packets at 85 the periphery of the network. Within the network, the packets receive 86 special treatment depending on the marking. For example, a premium 87 service class has been defined. This service emulates a completely 88 unloaded network, giving minimal delays and loss. Such a service is 89 ideal for real time applications, for example. An ISP could use the 90 premium service to offer improved quality for real time traffic only. 91 In order to implement this, packets must be classified at the periph- 92 ery so that they can be appropriately marked. 94 By having RTP packets clearly identified, the periphery routers of 95 the ISP will be able to mark them for premium service within the 96 ISP's network. Making RTP a protocol is an efficient way to accom- 97 plish this. 99 On the other hand, clients could mark their packets as being real 100 time by setting bits in other fields of the packet. In fact, the very 101 same TOS bits used by diffserv could be used by clients to express 102 how they would like the packets to be treated. These bits could then 103 be modified at the periphery of the network by the ISP to provide the 104 desired level of service. 106 3.2 Static Router Configuration 108 Most commercially available IP routers allow administrators to con- 109 figure the router to queue packets separately based on the value of 110 the source IP address, destination IP address, source port, destina- 111 tion port, protocol tuple. It would be very beneficial to an ISP to 112 be able to identify real-time traffic, isolate it from other flows, 113 and provide it with some amount of bandwidth. Currently, since RTP 114 cannot be classified by 5-tuple, it is placed in the default queue 115 with lots of other things that need much different handling compared 116 to real time. 118 Having RTP be an IP protocol would improve the situation in two ways. 119 First, RTP packets could be identified by the protocol field in the 120 IP header. Secondly, the payload type field in the RTP header could 121 be used to infer information about the codec used for the media com- 122 pression. This would allow a router to make a very educated guess 123 about the bandwidth and QoS requirements for the flow. 125 As with differentiated services, one could simply use a TOS value to 126 indicate that the traffic was real time (which may or may not be 127 RTP). However, having RTP packets explicitly labeled would allow 128 routers to look in RTP-specific header fields for additional informa- 129 tion. 131 3.3 Firewalls 133 Having RTP packets be labeled would provide additional information 134 that could be used by firewalls. Firewalls could be configured to 135 drop or accept all RTP traffic coming into or leaving a domain. Cur- 136 rently, RTP traffic cannot be distinguished from other applications 137 which use dynamic UDP ports. This would no longer be the case. 139 Firewall administrators would also be able to block RTCP traffic, 140 while admitting RTP. This is extremely useful for mbone sessions. 141 Typically, these will have one sender of data, with hundreds of lis- 142 teners, each of which sends only RTCP. These RTCP packets can cause a 143 lot of network state (in the form of (S,G) entries) to be created, 144 and can also cause significant network traffic (due to flooding in 145 DVMRP). Filtering incoming RTCP, but not RTP, would allow a network 146 administrator to offer mbone service without needing to worry about 147 these RTCP problems. 149 3.4 RTP Header Compression 151 RTP header compression [6] is typically used over dialup modem lines 152 where bandwidth is at a premium. Without it, the RTP/UDP/IP headers 153 require 10 kbps alone when used with the G.729 speech coder with a 154 30ms packetization delay. With it, this rate is reduced to less than 155 half a kilobit per second. This reduction can mean the difference 156 between transmitting video and having no video at all. The compres- 157 sion algorithm itself relies on the compressor classifying RTP pack- 158 ets, and maintaining state for the flow. Unfortunately, when the com- 159 pression is performed in the downstream direction (from the access 160 device to the host), the access device must decide which packets to 161 apply compression to. Having RTP packets be explicitly labeled makes 162 this process vastly simpler. The compressor could also look at the 163 SSRC field to decide to which compression context the packet belongs. 165 We observe that the access device could instead decide which packets 166 are RTP based on signaling from the host. An additional PPP packet 167 type could be created indicating the port number that the host is 168 expecting RTP packets on. Hosts would need to send these packets 169 after opening a socket for RTP. This would require explicit support 170 in the OS, but it is probably no more complicated than the OS support 171 required to elevate RTP to protocol status. 173 4 Alternate Solution: RTP Port Numbers 175 One approach to identifying RTP packets could be to assign it a 176 static pair of port numbers (one for RTP, one for RTCP). This is not 177 acceptable, however. In some cases, a host may run several real time 178 applications (such as a voice conferencing tool and a video confer- 179 encing tool), each of which may independently require its own ports. 180 An alternative would be to assign a block of port numbers to RTP. 181 This would allow for multiple simultaneous applications and still 182 allow RTP traffic to be identified. 184 The weakness of this approach is twofold: (1) it requires a choice of 185 an upper bound on the number of simultaneous RTP sessions in a 186 client, and (2) other UDP-based applications with dynamic port num- 187 bers may randomly choose an RTP-assigned port. The latter problem can 188 be made to eventually disappear if new applications are written to 189 avoid the UDP space. In the interim (which may be forever), some non 190 real time traffic could be mistakenly classified as real time. 192 5 Solution: RTP as Protocol 194 Our proposal would be to have the new RTP protocol have a header 195 which is identical to the concatenation of the UDP header and RTP 196 header. The new RTP protocol header would then look like: 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | RTP Source Port | RTP Destination Port | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Length | Checksum | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 |V=2|P|X| CC |M| PT | sequence number | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | timestamp | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | synchronization source (SSRC) identifier | 210 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 211 | contributing source (CSRC) identifiers | 212 | .... | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 The source port, destination port, length, and checksum have exactly 216 the same syntax and semantics as in UDP. Here, however, the port num- 217 bers refer to RTP ports. 219 6 Impact on Network Aware Devices 221 Elevation of RTP to protocol status would have an impact on almost 222 all network aware devices. This section discusses the implications 223 for each. 225 6.1 Hosts 227 When a packet arrives at a host, the operating system typically looks 228 at the IP protocol field, and processes the packet based on it. Since 229 RTP would become a new protocol, it is important to consider how to 230 handle it in operating systems. There seem to be three approaches: 232 1. Long Term. Significant extensions to the standard BSD sockets 233 API can be made to support RTP as another socket type. The 234 kernel would be upgraded to process RTP and RTCP packets. The 235 sockets extensions would provide functions for interacting 236 with RTCP, and setting the various fields and parameters in 237 the RTP header. Applications would need to be written to make 238 use of the new API. It is not clear that having RTP in kernel 239 space is the most efficient approach, but elevating RTP to 240 full protocol makes it a possibility at least. 242 2. Near Term. A small extension to the BSD sockets API can be 243 made to define a new protocol type ( IPPROTO_RTP) which can be 244 used when creating a socket of type SOCK_DGRAM. The resulting 245 socket is identical to all respects to the standard UDP 246 socket, except the value of the protocol field in the IP 247 header is set to that of RTP when sending. When receiving, 248 packets are sent to the socket only when the IP protocol field 249 indicates RTP. When sending data to the socket, the kernel 250 would add only the UDP portion of the RTP header. When receiv- 251 ing, it would strip only the UDP portion. This means that the 252 RTP part of the header would still need to be processed in 253 application space, but the UDP portion would be in the kernel. 254 This solution requires absolutely minimal changes to existing 255 application software, which perform RTP, but not UDP process- 256 ing. The kernel modifications are minor. 258 3. Short Term. Before operating systems are changed at all, the 259 new RTP protocol can be implemented purely in user space by 260 making use of the raw socket. This would require applications 261 to implement both the RTP and UDP portions of the protocol. 262 The UDP code can easily be lifted from current operating sys- 263 tems. Even if it cannot, its implementation is fairly 264 straightforward. 266 We anticipate that implementations would gradually migrate from the 267 short term solution to the near term. It is not clear whether the long 268 term solution is practical. 270 An unfortunate difficulty with the short term solution is that most 271 operating systems only allow users with root permissions to access the 272 raw socket. This may be problematic for many applications. 274 6.2 Routers 276 Routers do not need to understand the IP protocol field in order to 277 forward packets. However, most routers can be programmed with filters 278 that drop or classify packets based on this field. This operation is 279 only a problem if the routers cannot be configured to accept new val- 280 ues for this field. Routers which accept numeric values should oper- 281 ate correctly. 283 6.3 Firewalls 284 In all likelihood, most firewalls currently drop all traffic that is 285 not UDP or TCP. This would cause the new RTP packets to be discarded 286 ubiquitously by firewalls. To fix the problem, firewalls would need 287 to be upgraded to recognize the new protocol type, and accept filter 288 rules based on it. 290 6.4 Tools 292 A number of host tools rely on examination of the IP protocol header. 293 Most important among these is tcpdump, based on the Berkeley packet 294 filter. Tcpdump would not be able to recognize the new RTP, and would 295 need to be upgraded in order to do this. This issue is minor, but at 296 least worth a mention. 298 Other similar tools, such as packet sniffers and network analyzers, 299 would also need to eventually be upgraded to recognize the new proto- 300 col. In the long run, this would be very advantageous. Network tools 301 cannot recognize RTP packets at all. With this change, they would be 302 able to recognize and decode RTP packets. They could also recognize 303 and decode RTCP packets, which may provide valuable feedback when 304 doing network debugging. 306 6.5 Network Address Translators 308 Network Address Port Translation [7] allows for many hosts in a stub 309 domain to map their IP addresses (which may be routable or un- 310 routable) to a single IP address. NAPT does this by translating the 311 source IP address and port number. Many NAPT devices currently only 312 support UDP or TCP, and thus would be unable to handle a new protocol 313 without an upgrade. In any case, real-time applications present spe- 314 cial difficulties for NAT or NAPT implementations, since protocol 315 such as SDP require IP addresses to be carried in application packets 317 7 Backwards Compatibility 319 It is important to consider how to handle interoperability between 320 end systems using the new RTP protocol and those using the old. We 321 can classify RTP applications into two broad types - broadcast and 322 interactive. The interoperability issues are different in both cases. 324 7.1 Interactive 326 For interactive applications, there is usually some kind of signaling 327 protocol that establishes communications before the media is trans- 328 ported using RTP. These signaling protocols usually indicate the var- 329 ious codecs that the end systems are capable of decoding and encod- 330 ing. The use of the new RTP can be considered as just another capa- 331 bility. Both sides express their ability to receive the new RTP. 333 Applications implementing the new RTP should be prepared to also 334 transmit using the old RTP. As a result, a common RTP version can 335 always be found. 337 In the case of H.323, this would require the addition of a single new 338 ASN.1 element in H.245 [8], which expresses the ability to receive 339 the new RTP. 341 As an alternative, backwards compatibility can be achieved purely at 342 the RTP layer by making use of ICMP errors. Any host implementing the 343 new RTP would also be required to implement the old one. Whenever a 344 host listens to an RTP socket, the operating system accepts packets 345 which are either UDP or the new RTP with the given port number. This 346 will allow new RTP implementations to receive packets from both old 347 and new without explicit application signaling. This comes at the 348 expense of an effective sharing of port space between UDP and RTP. 350 When a host implementing the new RTP wishes to send a packet, it 351 sends it using the RTP protocol number. Hosts which do not understand 352 the new RTP protocol should generate an ICMP protocol unreachable 353 error message, and return it back to the source. The sender's operat- 354 ing system must then use the old RTP for sending packets on that 355 socket from that point forward. This will allow a new RTP implementa- 356 tion to talk to either a new or old one, thus achieving full back- 357 wards compatibility. The cost is additional smarts in the operating 358 system, and potential loss of the first few RTP packets until the 359 host switches back to RTP. This approach fails for multicast. 361 7.2 Broadcast 363 For broadcast applications, such as mbone conferences, there is no 364 capabilities exchange. However, there is usually some kind of session 365 advertisement (using SAP [9] and SDP [10], for example). These 366 announcements include the port numbers and multicast group used for 367 the media. They could be extended to also indicate whether the new 368 RTP protocol is being used. This would allow end systems to know 369 whether they can correctly receive the media or not. If a broadcast 370 is taking place using the new RTP, and there are old receivers trying 371 to listen, they will not be able to receive the media. However, this 372 is no different than the case where a broadcast is taking place using 373 a codec that some client applications cannot decode. The only solu- 374 tion is a software upgrade of the clients. 376 8 Conclusion 378 We have discussed the issues related to elevating RTP to protocol 379 status, which would give it its own unique IP protocol number like 380 TCP and UDP. The main motivation for this is to allow for 381 classification of RTP packets in end systems, routers, and other 382 devices. Classification is needed for services such as RTP header 383 compression, real time flow isolation, and differentiated services. 384 We have proposed that the new RTP protocol have a header which is the 385 concatenation of the current UDP and RTP header fields. This simpli- 386 fies implementation, and leaves open a smooth migration path for 387 deployment. We have also discussed backwards compatibility, and how 388 it can be handled for broadcast and interactive applications. 390 9 Full Copyright Statement 392 Copyright (C) The Internet Society (1998). All Rights Reserved. 394 This document and translations of it may be copied and furnished to 395 others, and derivative works that comment on or otherwise explain it 396 or assist in its implmentation may be prepared, copied, published and 397 distributed, in whole or in part, without restriction of any kind, 398 provided that the above copyright notice and this paragraph are 399 included on all such copies and derivative works. 401 However, this document itself may not be modified in any way, such as 402 by removing the copyright notice or references to the Internet Soci- 403 ety or other Internet organizations, except as needed for the purpose 404 of developing Internet standards in which case the procedures for 405 copyrights defined in the Internet Standards process must be fol- 406 lowed, or as required to translate it into languages other than 407 English. 409 The limited permissions granted above are perpetual and will not be 410 revoked by the Internet Society or its successors or assigns. 412 This document and the information contained herein is provided on an 413 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 414 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 415 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 416 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 417 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 419 10 Authors Addresses 421 Jonathan Rosenberg 422 Bell Laboratories, Lucent Technologies 423 101 Crawfords Corner Rd. 424 Holmdel, NJ 07733 425 email: jdrosen@bell-labs.com 426 Bernard Aboba 427 Microsoft Corporation 428 One Microsoft Way 429 Redmond, WA 98052 430 email: aboba@microsoft.com 432 Henning Schulzrinne 433 Columbia University 434 M/S 0401 435 1214 Amsterdam Ave. 436 New York, NY 10027-7003 437 email: schulzrinne@cs.columbia.edu 439 11 Bibliography 441 [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP: a 442 transport protocol for real-time applications, Request for Comments 443 (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996. 445 [2] ITU-T, Recommendation H.323 - Visual Telephone Systems and 446 Equipment for Local Area Networks which Provide Non-Guaranteed Qual- 447 ity of Service , February 1996. 449 [3] J. Wroclawski, The use of RSVP with IETF integrated services, 450 Request for Comments (Proposed Standard) 2210, Internet Engineering 451 Task Force, Oct. 1997. 453 [4] J. Wroclawski, Specification of the controlled-load network ele- 454 ment service, Request for Comments (Proposed Standard) 2211, Internet 455 Engineering Task Force, Oct. 1997. 457 [5] R. Guerin, C. Partridge, and S. Shenker, Specification of guaran- 458 teed quality of service, Request for Comments (Proposed Standard) 459 2212, Internet Engineering Task Force, Oct. 1997. 461 [6] S. Casner and V. Jacobson, Compressing IP/UDP/RTP headers for 462 low-speed serial links, Internet Draft, Internet Engineering Task 463 Force, Nov. 1996. Work in progress. 465 [7] P. Srisuresh and K. Egevang, The ip network address translator 466 (nat), (internet draft), Internet Engineering Task Force, Sept. 1997. 467 Work in Progress. 469 [8] International Telecommunication Union, Control protocol for mul- 470 timedia communication, Recommendation H.245, Telecommunication 471 Standardization Sector of ITU, Geneva, Switzerland, Mar. 1996. 473 [9] M. Handley, SAP: Session announcement protocol, Internet Draft, 474 Internet Engineering Task Force, Nov. 1996. Work in progress. 476 [10] M. Handley, SDP: Session description protocol, Internet Draft, 477 Internet Engineering Task Force, Nov. 1997. Work in progress.