Request for Comments: 3890 Ericsson
Category: Standards Track September 2004
A Transport Independent Bandwidth Modifier
for the Session Description Protocol (SDP)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document defines a Session Description Protocol (SDP) Transport
Independent Application Specific Maximum (TIAS) bandwidth modifier
that does not include transport overhead; instead an additional
packet rate attribute is defined. The transport independent bit-rate
value together with the maximum packet rate can then be used to
calculate the real bit-rate over the transport actually used.
The existing SDP bandwidth modifiers and their values include the
bandwidth needed for the transport and IP layers. When using SDP
with protocols like the Session Announcement Protocol (SAP), the
Session Initiation Protocol (SIP), and the Real-Time Streaming
Protocol (RTSP), and when the involved hosts has different transport
overhead, for example due to different IP versions, the
interpretation of what lower layer bandwidths are included is not
clear.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Bandwidth Attribute. . . . . . . . . . . . . . . . . 3
1.1.1. Conference Total . . . . . . . . . . . . . . . . 3
1.1.2. Application Specific Maximum . . . . . . . . . . 3
1.1.3. RTCP Report Bandwidth. . . . . . . . . . . . . . 4
1.2. IPv6 and IPv4. . . . . . . . . . . . . . . . . . . . . . 4
1.3. Further Mechanisms that Change the Bandwidth
Utilization. . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1. IPsec. . . . . . . . . . . . . . . . . . . . . . 5
1.3.2. Header Compression . . . . . . . . . . . . . . . 5
2. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 6
3. The Bandwidth Signaling Problems . . . . . . . . . . . . . . . 6
3.1. What IP Version is Used. . . . . . . . . . . . . . . . . 6
3.2. Taking Other Mechanisms into Account . . . . . . . . . . 7
3.3. Converting Bandwidth Values. . . . . . . . . . . . . . . 8
3.4. RTCP Problems. . . . . . . . . . . . . . . . . . . . . . 8
3.5. Future Development . . . . . . . . . . . . . . . . . . . 9
3.6. Problem Conclusion . . . . . . . . . . . . . . . . . . . 9
4. Problem Scope. . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 11
6.2. The TIAS Bandwidth Modifier. . . . . . . . . . . . . . . 11
6.2.1. Usage. . . . . . . . . . . . . . . . . . . . . . 11
6.2.2. Definition . . . . . . . . . . . . . . . . . . . 12
6.2.3. Usage Rules. . . . . . . . . . . . . . . . . . . 13
6.3. Packet Rate Parameter. . . . . . . . . . . . . . . . . . 13
6.4. Converting to Transport-Dependent Values . . . . . . . . 14
6.5. Deriving RTCP bandwidth. . . . . . . . . . . . . . . . . 15
6.5.1. Motivation for this Solution. . . . . . . . . . . 15
6.6. ABNF Definitions . . . . . . . . . . . . . . . . . . . . 16
6.7. Example. . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Protocol Interaction . . . . . . . . . . . . . . . . . . . . . 17
7.1. RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.3. SAP. . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 19
12. Author’s Address . . . . . . . . . . . . . . . . . . . . . . . 21
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22
1. Introduction
This specification is structured in the following way: In this
section, some information regarding SDP bandwidth modifiers, and
different mechanisms that affect transport overhead are asserted. In
section 3, the problems found are described, including problems that
are not solved by this specification. In section 4 the scope of the
problems this specification solves is presented. Section 5 contains
the requirements applicable to the problem scope. Section 6 defines
the solution, which is a new bandwidth modifier, and a new maximum
packet rate attribute. Section 7 looks at the protocol interaction
for SIP, RTSP, and SAP. The security considerations are discussed in
section 8. The remaining sections are the necessary IANA
considerations, acknowledgements, reference list, author’s address,
and copyright and IPR notices.
Today the Session Description Protocol (SDP) [1] is used in several
types of applications. The original application is session
information and configuration for multicast sessions announced with
Session Announcement Protocol (SAP) [5]. SDP is also a vital
component in media negotiation for the Session Initiation Protocol
(SIP) [6] by using the offer answer model [7]. The Real-Time
Streaming Protocol (RTSP) [8] also makes use of SDP to declare to the
client what media and codec(s) comprise a multi-media presentation.
1.1. The Bandwidth Attribute
In SDP [1] there exists a bandwidth attribute, which has a modifier
used to specify what type of bit-rate the value refers to. The
attribute has the following form:
b=<modifier>:<value>
Today there are four defined modifiers used for different purposes.
1.1.1. Conference Total
The Conference Total is indicated by giving the modifier "CT".
Conference total gives a maximum bandwidth that a conference session
will use. Its purpose is to decide if this session can co-exist with
any other sessions, defined in RFC 2327 [1].
1.1.2. Application Specific Maximum
The Application Specific maximum bandwidth is indicated by the
modifier "AS". The interpretation of this attribute is dependent on
the application’s notion of maximum bandwidth. For an RTP
application, this attribute is the RTP session bandwidth as defined
in RFC 3550 [4]. The session bandwidth includes the bandwidth that
the RTP data traffic will consume, including the lower layers, down
to the IP layer. Therefore, the bandwidth is in most cases
calculated over RTP payload, RTP header, UDP, and IP, defined in RFC
2327 [1].
1.1.3. RTCP Report Bandwidth
In RFC 3556 [9], two bandwidth modifiers are defined. These
modifiers, "RS" and "RR", define the amount of bandwidth that is
assigned for RTCP reports by active data senders and RTCP reports by
other participants (receivers), respectively.
1.2. IPv6 and IPv4
Today there are two IP versions, 4 [14] and 6 [13], used in parallel
on the Internet, creating problems. However, there exist a number of
possible transition mechanisms.
- The nodes which wish to communicate must share the IP version;
typically this is done by deploying dual-stack nodes. For
example, an IPv4 only host cannot communicate with an IPv6 only
host.
- If communication between nodes which do not share a protocol
version is required, use of a translation or proxying mechanism
would be required. Work is underway to specify such a mechanism
for this purpose.
------------------ ----------------------
| IPv4 domain | | IPv6 Domain |
| | ------------- | |
| ---------- |-|Translator |-| ---------- |
| |Server A| | | or proxy | | |Client B| |
| ---------- | ------------- | ---------- |
------------------ ----------------------
Figure 1. Translation or proxying between IPv6 and IPv4 addresses.
- IPv6 nodes belonging to different domains running IPv6, but
lacking IPv6 connectivity between them, solve this by tunneling
over the IPv4 net, see Figure 2. Basically, the IPv6 packets are
sent as payload in IPv4 packets between the tunneling end-points
at the edge of each IPv6 domain. The bandwidth required over the
IPv4 domain will be different from IPv6 domains. However, as the
tunneling is normally not performed by the application end-point,
this scenario can not usually be taken into consideration.
--------------- --------------- ---------------
| IPv6 domain | | IPv4 domain | | IPv6 Domain |
| | |-------------| | |
| ---------- |--||Tunnel ||--| ---------- |
| |Server A| | |-------------| | |Client B| |
| ---------- | | | | ---------- |
--------------- --------------- --------------|
Figure 2. Tunneling through a IPv4 domain
IPv4 has a minimum header size of 20 bytes, while the fixed part of
the IPv6 header is 40 bytes.
The difference in header sizes means that the bit-rate required for
the two IP versions is different. The significance of the difference
depends on the packet rate and payload size of each packet.
1.3. Further Mechanisms that Change the Bandwidth Utilization
There exist a number of other mechanisms that also may change the
overhead at layers below media transport. We will briefly cover a
few of these here.
1.3.1. IPsec
IPsec [19] can be used between end points to provide confidentiality
through the application of the IP Encapsulating Security Payload
(ESP) [21] or integrity protection using the IP Authentication Header
(AH) [20] of the media stream. The addition of the ESP and AH
headers increases each packet’s size.
To provide virtual private networks, complete IP packets may be
encapsulated between an end node and the private networks security
gateway, thus providing a secure tunnel that ensures confidentiality,
integrity, and authentication of the packet stream. In this case,
the extra IP and ESP header will significantly increase the packet
size.
1.3.2. Header Compression
Another mechanism that alters the actual overhead over links is
header compression. Header compression uses the fact that most
network protocol headers have either static or predictable values in
their fields within a packet stream. Compression is normally only
done on a per hop basis, i.e., on a single link. The normal reason
for doing header compression is that the link has fairly limited
bandwidth and significant gain in throughput is achieved.
There exist several different header compression standards. For
compressing IP headers only, there is RFC 2507 [10]. For compressing
packets with IP/UDP/RTP headers, CRTP [11] was created at the same
time. More recently, the Robust Header Compression (ROHC) working
group has been developing a framework and profiles [12] for
compressing certain combinations of protocols, like IP/UDP, and
IP/UDP/RTP.
2. Definitions
2.1. Glossary
ALG - Application Level Gateway.
bps - bits per second.
RTSP - Real-Time Streaming Protocol, see [8].
SDP - Session Description Protocol, see [1].
SAP - Session Announcement Protocol, see [5].
SIP - Session Initiation Protocol, see [6].
TIAS - Transport Independent Application Specific maximum, a
bandwidth modifier.
2.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [3].
3. The Bandwidth Signaling Problems
When an application wants to use SDP to signal the bandwidth required
for this application, some problems become evident due to the
inclusion of the lower layers in the bandwidth values.
3.1. What IP Version is Used
If one signals the bandwidth in SDP, for example, using "b=AS:" as an
RTP based application, one cannot know if the overhead is calculated
for IPv4 or IPv6. An indication of which protocol has been used when
calculating the bandwidth values is given by the "c=" connection
address line. This line contains either a multicast group address or
a unicast address of the data source or sink. The "c=" line’s
address type may be assumed to be of the same type as the one used in
the bandwidth calculation, although no document specifying this point
seems to exist.
In cases of SDP transported by RTSP, this is even less clear. The
normal usage for a unicast on-demand streaming session is to set the
connection data address to a null address. This null address does
have an address type, which could be used as an indication. However,
this is also not clarified anywhere.
Figure 1, illustrates a connection scenario between a streaming
server A and a client B over a translator. When B receives the SDP
from A over RTSP, it will be very difficult for B to know what the
bandwidth values in the SDP represent. The following possibilities
exist:
1. The SDP is unchanged and the "c=" null address is of type IPv4.
The bandwidth value represents the bandwidth needed in an IPv4
network.
2. The SDP has been changed by an Application Level Gateway (ALG).
The "c=" address is changed to an IPv6 type. The bandwidth value
is unchanged.
3. The SDP is changed and both "c=" address type and bandwidth value
is converted. Unfortunately, this can seldom be done, see 3.3.
In case 1, the client can understand that the server is located in an
IPv4 network and that it uses IPv4 overhead when calculating the
bandwidth value. The client can almost never convert the bandwidth
value, see section 3.3.
In case 2, the client does not know that the server is in an IPv4
network and that the bandwidth value is not calculated with IPv6
overhead. In cases where a client uses this value to determine if
its end of the network has sufficient resources the client will
underestimate the required bit-rate, potentially resulting in bad
application performance.
In case 3, everything works correctly. However, this case will be
very rare. If one tries to convert the bandwidth value without
further information about the packet rate, significant errors may be
introduced into the value.
3.2. Taking Other Mechanisms into Account
Section 1.2 and 1.3 lists a number of reasons, like header
compression and tunnels, that would change lower layer header sizes.
For these mechanisms there exist different possibilities to take them
into account.
Using IPsec directly between end-points should definitely be known to
the application, thus enabling it to take the extra headers into
account. However the same problem also exists with the current SDP
bandwidth modifiers where a receiver is not able to convert these
values taking the IPsec headers into account.
It is less likely that an application would be aware of the existence
of a virtual private network. Thus the generality of the mechanism
to tunnel all traffic may prevent the application from even
considering whether it would be possible to convert the values.
When using header compression, the actual overhead will be less
deterministic, but in most cases an average overhead can be
determined for a certain application. If a network node knows that
some type of header compression is employed, this can be taken into
consideration. For RSVP [15], there exists an extension, RFC 3006
[16], that allows the data sender to inform network nodes about the
compressibility of the data flow. To be able to do this with any
accuracy, the compression factor and packet rate or size is needed,
as RFC 3006 provides.
3.3. Converting Bandwidth Values
If one would like to convert a bandwidth value calculated using IPv4
overhead to IPv6 overhead, the packet rate is required. The new
bandwidth value for IPv6 is normally "IPv4 bandwidth" + "packet rate"
* 20 bytes, where 20 bytes is the usual difference between IPv6 and
IPv4 headers. The overhead difference may be some other value in
cases when IPv4 options [14] or IPv6 extension headers [13] are used.
As converting requires the packet rate of the stream, this is not
possible in the general case. Many codecs have either multiple
possible packet/frame rates or can perform payload format
aggregation, resulting in many possible rates. Therefore, some extra
information in the SDP will be required. The "a=ptime:" parameter
may be a possible candidate. However, this parameter is normally
only used for audio codecs. Its definition [1] is that it is only a
recommendation, which the sender may disregard. A better parameter
is needed.
3.4. RTCP Problems
When RTCP is used between hosts in IPv4 and IPv6 networks over
translator, similar problems exist. The RTCP traffic going from the
IPv4 domain will result in a higher RTCP bit-rate than intended in
the IPv6 domain due to the larger headers. This may result in up to
a 25% increase in required bandwidth for the RTCP traffic. The
largest increase will be for small RTCP packets when the number of
IPv4 hosts is much larger than the number of IPv6 hosts.
Fortunately, as RTCP has a limited bandwidth compared to RTP, it will
only result in a maximum of 1.75% increase of the total session
bandwidth when RTCP bandwidth is 5% of RTP bandwidth. The RTCP
randomization may easily result in short term effects of the same
magnitude, so this increase may be considered tolerable. The
increase in bandwidth will in most cases be less.
At the same time, this results in unfairness in the reporting between
an IPv4 and IPv6 node. In the worst case scenario, the IPv6 node may
report with 25% longer intervals.
These problems have been considered insignificant enough to not be
worth any complex solutions. Therefore, only a simple algorithm for
deriving RTCP bandwidth is defined in this specification.
3.5. Future Development
Today there is work in the IETF to design a new datagram transport
protocol suitable for real-time media. This protocol is called the
Datagram Congestion Control Protocol (DCCP). It will most probably
have a different header size than UDP, which is the protocol most
often used for real-time media today. This results in even more
possible transport combinations. This may become a problem if one
has the possibility of using different protocols, which will not be
determined prior to actual protocol SETUP. Thus, pre-calculating
this value will not be possible, which is one further motivation why
a transport independent bandwidth modifier is needed.
DCCP’s congestion control algorithms will control how much bandwidth
can really be utilized. This may require further work with
specifying SDP bandwidth modifiers to declare the dynamic
possibilities of an application’s media stream. For example, min and
max media bandwidth the application is capable of producing at all,
or for media codecs only capable of producing certain bit-rates,
enumerating possible rates. However, this is for future study and
outside the scope of the present solution.
3.6. Problem Conclusion
A shortcoming of the current SDP bandwidth modifiers is that they
also include the bandwidth needed for lower layers. It is in many
cases difficult to determine which lower layers and their versions
were included in the calculation, especially in the presence of
translation or proxying between different domains. This prevents a
receiver from determining if given bandwidth needs to be converted
based on the actual lower layers being used.
Secondly, an attribute to give the receiver an explicit determination
of the maximum packet rate that will be used does not exist. This
value is necessary for accurate conversion of any bandwidth values if
the difference in overhead is known.
4. Problem Scope
The problems described in section 3 are common and effect application
level signaling using SDP, other signaling protocols, and also
resource reservation protocols. However, this document targets the
specific problem of signaling the bit-rate in SDP. The problems need
to be considered in other affected protocols and in new protocols
being designed. In the MMUSIC WG there is work on a replacement of
SDP called SDP-NG. It is recommended that the problems outlined in
this document be considered when designing solutions for specifying
bandwidth in the SDP-NG [17].
As this specification only targets carrying the bit-rate information
within SDP, it will have a limited applicability. As SDP information
is normally transported end-to-end by an application protocol, nodes
between the end-points will not have access to the bit-rate
information. It will normally only be the end points that are able
to take this information into account. An interior node will need to
receive the information through a means other than SDP, and that is
outside the scope of this specification.
Nevertheless, the bit-rate information provided in this specification
is sufficient for cases such as first-hop resource reservation and