One document matched: draft-rosenberg-rtpproto-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:26:50 |