Network Working Group Magnus Westerlund
INTERNET-DRAFT Ericsson
Expires: April 2003
A transport independent bandwidth modifier for the Session
Description Protocol.
<draft-westerlund-mmusic-sdp-bwparam-00.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
The existing Session Description Protocol (SDP) bandwidth modifiers
and their values include the bandwidth needed also for the transport
and IP layers. When using SDP in protocols like SAP, SIP and RTSP and
the involved hosts reside in networks running different IP versions,
the interpretation of what type of lower layers that is included is
not clear. A possible solution to this problem is proposed.
Westerlund [Page 1]
INTERNET-DRAFT Bandwidth modifier for SDP okt 07, 2002
TABLE OF CONTENTS
1. Definitions.........................................................2
1.1. Glossary..........................................................2
1.2. Terminology.......................................................2
2. Introduction........................................................3
2.1. The Bandwidth Attribute...........................................3
2.1.1. Conference Total................................................3
2.1.2. Application Specific............................................3
2.1.3. RTCP Report bandwidth...........................................3
2.2. IPv6 and IPv4.....................................................4
3. The Bandwidth Signaling Problems....................................5
3.1.1. What IP version is used.........................................5
3.1.2. Converting bandwidth values.....................................5
3.2. Header Compression................................................6
3.3. Future development................................................6
4. Problem Scope.......................................................7
5. Requirements........................................................7
6. A Solution..........................................................7
6.1. The bandwidth modifier............................................7
6.2. Packet Rate parameter.............................................8
6.3. Converting to Transport Dependent values..........................8
6.4. ABNF definitions..................................................8
7. Security Consideration..............................................9
8. IANA Consideration..................................................9
9. Acknowledgments.....................................................9
10. Author's Addresses.................................................9
11. References........................................................10
11.1. Normative references............................................10
11.2. Informative References..........................................10
1. Definitions
1.1. Glossary
SDP - Session Description Protocol
SAP - Session Announcement Protocol
SIP - Session Initiation Protocol
RTSP - Real-Time Streaming Protocol
1.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 RFC 2119 [7].
Westerlund [Page 2]
INTERNET-DRAFT Bandwidth modifier for SDP okt 07, 2002
2. Introduction
Today the Session Description Protocol (SDP) [1] is used in several
types of applications. The original application is session
configuration for multicast sessions announced with Session
Announcement Protocol (SAP) [2]. SDP is also a vital component in
media negotiation for the Session Initiation Protocol (SIP) [3] by
using the offer answer model [4]. The Real-Time Streaming Protocol
(RTSP) [5] also makes use of SDP to declare what media and codec(s) a
multi-media presentation consist of to the client.
2.1. The Bandwidth Attribute
In SDP there exist a bandwidth attribute, which has a modifier used
to specify what type of bandwidth the value refers to. The attribute
has the following form:
b=<modifier>:<value>
Today there are four modifiers defined which are used for different
purposes.
2.1.1. Conference Total
The Conference Total is indicated by giving the modifier "CT". The
meaning of Conference total is to give a maximum bandwidth that a
conference session will use. Its purpose is so that it is possible to
decide if this session can co-exist with any other sessions. Defined
in the RFC 2327 [1].
2.1.2. Application Specific
The Application Specific bandwidth is indicated by the modifier "AS".
The interpretation of this attribute is depending on the
applications notion of maximum bandwidth. For an RTP application
this attribute is the RTP session bandwidth as defined in RFC 1889
[6]. The session bandwidth includes the bandwidth that the RTP data
traffic will result in, including the lower layers down to IP layer.
So the bandwidth is in most cases calculated over RTP payload, RTP
header, UDP and IP. Defined in the RFC 2327 [1].
2.1.3. RTCP Report bandwidth
Today there is a draft [9], currently in the RFC editors queue to
become a Proposed Standard, which defines two new bandwidth
modifiers. These modifiers "RS" and "RR" define the amount of
bandwidth that is assigned for RTCP reports by active data senders
respectively RTCP reports by receivers only.
Westerlund [Page 3]
INTERNET-DRAFT Bandwidth modifier for SDP okt 07, 2002
2.2. IPv6 and IPv4
Today there are two IP versions used in parallel on the Internet.
This creates problems and there exist a number of possible transition
mechanisms.
------------------ ----------------------
| IPv4 domain | | IPv6 Domain |
| | ---------| | |
| ---------- |-| NAT-PT |-| ---------- |
| |Server A| | ---------| | |Client B| |
| ---------- | | ---------- |
------------------ ----------------------
Figure 1. Translation between IPv6 and IPv4 addresses.
- To achieve connectivity between IPv4 and IPv6 only hosts one most
do translation. This translator can be for example a NAT-PT, see
Figure 1. However to get connectivity for large number of
protocols, Application Level Gateway (ALG) functionality is also
required at the node. To be able to locate hosts through the
translation node DNS ALG must be supported.
- IPv6 nodes belonging to different domains running IPv6, but
lacking IPv6 connectivity between them solves this by tunneling
over the IPv4 net, see Figure 2. Basically the IPv6 packets are
put as payload in IPv4 packets between the tunneling end-points at
the edge of each IPv6 domain.
--------------- --------------- ---------------
| IPv6 domain | | IPv4 domain | | IPv6 Domain |
| | |-------------| | |
| ---------- |--||Tunnel ||--| ---------- |
| |Server A| | |-------------| | |Client B| |
| ---------- | | | | ---------- |
--------------- --------------- --------------|
Figure 2. Tunneling through a IPv4 domain
IPv4 has minimal header size of 20 bytes. While the fixed part of the
IPv6 header is 40 bytes.
The difference in header size results in that the bandwidth used for
the IP layer is different. How big the difference is, depends on the
packet rate.
Westerlund [Page 4]
INTERNET-DRAFT Bandwidth modifier for SDP okt 07, 2002
3. The Bandwidth Signaling Problems
When an application wants to use SDP to signal the bandwidth required
for this application some problems becomes evident depending on the
transport layers.
3.1.1. What IP version is used
If one signals the bandwidth in SDP, with for example "b=AS:" for an
RTP based application, one cannot know if the overhead is calculated
for IPv4 or IPv6. An indication to which protocol has been used when
calculating the bandwidth values is given by the "c=" connection data
line. This line contains either a multicast group address or a
unicast address of the data source or sink. The c= lines address type
may be assumed to be of the same type as the one used in the
bandwidth calculation. There seems to exist no specification pointing
this out.
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 not clarified anywhere.
Figure 1, illustrates a connection scenario between a streaming
server A and a client B over a translator here designated as a NAT-
PT. 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 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 the ALG. The c= address is changed to
IPv6 type. The bandwidth value is unchanged.
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 cannot convert the bandwidth value, see
section 3.1.2.
In case 2 the client does not know that the server is in an IPv4
network and the bandwidth value is for not calculated with IPv6
overhead. In cases where a client reserve bandwidth for this flow,
too little will be reserved, resulting in bad Quality of Service
(QoS).
3.1.2. 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
Westerlund [Page 5]
INTERNET-DRAFT Bandwidth modifier for SDP okt 07, 2002
bandwidth value for IPv6 is "IPv4 bandwidth" + "packet rate" * 20
bytes. Where 20 bytes is the difference between IPv6 and IPv4
headers.
As converting requires the packet rate for the stream this is not
possible in the general case. Many codecs has many possible packet
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. Also its definition
[1] is that it is only a recommendation, which the sender may
disregard from. A better parameter is needed.
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. This is normally only done on 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 a couple of different header compression standard. For
compressing IP headers only, there exist 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,
IP/UDP/RTP.
When using header compression the actual used overhead will be less
certain but in most cases one can determine an average overhead for
an application. If a network node knows that some type of header
compression is employed this can taken into consideration. To be able
to do this with any accuracy the application and packet rate is
needed.
3.3. Future development
Today there is work in IETF to design a new datagram transport
protocol, which will be suitable to use for real-time media. This
protocol is called the Datagram Congestion Control Protocol (DCCP).
This protocol will most probably have another header size than UDP,
which is mostly used today. This results in even further numbers of
possible transport combinations to calculate overhead for.
Westerlund [Page 6]
INTERNET-DRAFT Bandwidth modifier for SDP okt 07, 2002
4. Problem Scope
The problems described in chapter 3 does effect all the protocols
that uses SDP to signal bandwidth parameters.
In the MMUSIC WG there is work on a replacement of SDP called SDP-NG.
That work SHOULD consider the problems outlined in this draft when
designing solutions for specifying bandwidth in SDP-NG.
5. Requirements
A solution to the problems outlined in this draft should meet the
following requirements:
- The bandwidth value SHALL be given in a way so that it can be
calculated for all possible combination of transport overhead.
6. A Solution
This chapter describes a solution for the problems outlined in this
document for the Application Specific (AS) bandwidth modifier.
The CT is a session level modifier and cannot easily be dealt with.
To address the problems with different overhead the CT value is
RECOMMENDED to be calculated using reasonable worst case overhead.
The RR and RS modifiers will hopefully be possible to clarify before
the publishing of their specification.
6.1. The bandwidth modifier
A new media level bandwidth modifier is defined:
b=TIAS:<bandwidth-value>
The Transport Independent Application Specific Maximum bandwidth
modifier (TIAS) has an integer bandwidth value in kbits per second. A
fractional bandwidth value SHALL always be rounded up to the next
integer. The bandwidth value is the maximum needed by the application
without counting IP or transport layer. For RTP based applications,
TIAS gives the RTP "session bandwidth" as defined in section 6.2 of
[6] with the following exception:
- Only RTP header and payload SHALL be used in the calculation, i.e.
the lower layers (IP/UDP) are excluded. The reason for not also
excluding RTP from the value is that RTP will always be present
for media transport using RTP. In the cases the RTP header is
compressed it can be easily taken into account as long as the
packet rate is known.
Note: RTCP bandwidth is not included in the bandwidth value. In
applications using RTCP the bandwidth used by RTCP is either 5% of
Westerlund [Page 7]
INTERNET-DRAFT Bandwidth modifier for SDP okt 07, 2002
the RTP session bandwidth including lower layers or as specified by
the RR and RS modifiers.
6.2. Packet Rate parameter
To be able to calculate the bandwidth value including the actually
used lower layers a packet rate parameter is also defined.
The packet rate parameter is defined as:
a=prate:<packet-rate>
The packet rate is a floating-point value for the streams packet
rate. If the number of packets is variable the given value SHALL be
the maximum the application can produce. The value is calculated by
taking the maximum number of packets that are present within a 1
second window placed anywhere in the media stream during its life
time.
The "prate" attribute is a media level attribute.
6.3. Converting to Transport Dependent values
When one want to convert the transport independent bandwidth value
into one including the lower layers the following MUST be done.
1. Determine which lower layers that will be used and calculate the
size of these headers (h-size).
2. Retrieve the packet rate from the SDP (prate).
3. Calculate the transport overhead by multiplying the header size
with the packet rate (t-over = h-size * prate).
4. Round the transport overhead up to nearest integer (t-over =
CEIL(t-over)).
5. Add the transport overhead to the TIAS bandwidth value (bandwidth
= TIAS-value + t-over)
6.4. ABNF definitions
This chapter defines in ABNF from RFC 2234 [8] the bandwidth modifier
and the packet rate attribute.
The bandwidth modifier:
TIAS-bandwidth = "b" "=" "TIAS" ":" bandwidth-value
bandwidth-value = 1*DIGIT
The packet rate attribute:
p-rate-def = "a" "=" "prate" ":" packet-rate CRLF
Westerlund [Page 8]
INTERNET-DRAFT Bandwidth modifier for SDP okt 07, 2002
packet-rate = 1*DIGIT ["." 1*DIGIT]
7. Security Consideration
The bandwidth value that is supplied by the parameters defined here
can if not protected be altered. By altering the bandwidth value one
can fool a receiver to reserve either more or less bandwidth than
actually needed. Reserving too much may result in unwanted expenses
on behalf of user and also blocking of resources that other parties
could have used. If to little bandwidth is reserved the receiving
users quality MAY be effected.
Due to these security risks it is RECOMMENDED that the SDP is
authenticated so no tampering can be performed. It is also
RECOMMENDED that any receiver of the SDP performs an analysis of the
received bandwidth values so that they are reasonable and is what can
be expected for the application. For example an AMR encoded voice
stream claiming to use 1000 kbps is not reasonable.
8. IANA Consideration
This document register one new SDP media level attribute "prate", see
section 6.2.
A new bandwidth modifier "TIAS" is also registered in accordance with
the rules requiring a standard tracks RFC. The modifier is defined in
section 6.1.
9. Acknowledgments
The author would like to thank Gonzalo Camarillo and Hesham Soliman
for their work reviewing this document.
10. Author's Addresses
Magnus Westerlund Tel: +46 8 4048287
Ericsson Research Email: Magnus.Westerlund@ericsson.com
Ericsson AB
Torshamnsgatan 23
SE-164 80 Stockholm, SWEDEN
Westerlund [Page 9]
INTERNET-DRAFT Bandwidth modifier for SDP okt 07, 2002
11. References
11.1. Normative references
[1] M. Handley, V. Jacobson, "Session Description Protocol (SDP)",
IETF RFC 2327, April 1998.
[2] M. Handley et al., "Session Announcement Protocol", IETF RFC
2974, October 2000.
[3] J. Rosenberg, et. al., "SIP: Session Initiation Protocol", IETF
RFC 3261, June 2002.
[4] J. Rosenberg, H. Schulzrine, "An Offer/Answer Model with Session
Description Protocol (SDP)", IETF RFC 3164, June 2002.
[5] H. Schulzrinne, et. al., "Real Time Streaming Protocol (RTSP)",
IETF RFC 2326, April 1998.
[6] H. Schulzrinne, et. al., "RTP: A Transport Protocol for Real-
Time Applications", IETF RFC 1889, January 1996.
[7] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[8] D. Crocker and P. Overell, "Augmented BNF for syntax specifica-
tions: ABNF," RFC 2234, Internet Engineering Task Force, Nov.
1997.
11.2. Informative References
[9] S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", IETF WG
draft, draft-ietf-avt-rtcp-bw-05.txt, November 2001, Work in
progress
[10] M. Degermark, B. Nordgren, S. Pink, "IP Header Compression",
IETF RFC 2507, February 1999.
[11] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-
Speed Serial Links", IETF RFC 2508, February 1999.
[12] C. Bormann, et. al., "RObust Header Compression (ROHC):
Framework and four profiles", IETF RFC 3095, July 2001.
This Internet-Draft expires in April 2003.
Westerlund [Page 10]