[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-westerlund-mmusic-sdp-bwparam) 00 01 02 03 04 05 06 RFC 3890

Network Working Group                                  Magnus Westerlund
INTERNET-DRAFT                                                  Ericsson
Category: Standards Track                                   May 27, 2003
Expires: November 2003




         A Transport Independent Bandwidth Modifier for the Session
                         Description Protocol (SDP).
                   <draft-ietf-mmusic-sdp-bwparam-03.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.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

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 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 reside in networks running different IP versions, the
   interpretation of what lower layer bandwidths are included is not
   clear. This document defines a bandwidth modifier that does not



Westerlund                                                      [Page 1]

INTERNET-DRAFT         Bandwidth modifier for SDP         MAY. 27, 2003


   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.

TABLE OF CONTENTS

1. Definitions.........................................................3
   1.1. Glossary.......................................................3
   1.2. Terminology....................................................3
2. Introduction........................................................3
   2.1. The Bandwidth Attribute........................................3
      2.1.1. Conference Total..........................................3
      2.1.2. Application Specific Maximum..............................3
      2.1.3. RTCP Report bandwidth.....................................4
   2.2. IPv6 and IPv4..................................................4
3. The Bandwidth Signaling Problems....................................5
   3.1. What IP version is used........................................5
   3.2. Converting bandwidth values....................................6
   3.3. Header Compression.............................................6
   3.4. RTCP problems..................................................7
   3.5. Future development.............................................7
4. Problem Scope.......................................................8
5. Requirements........................................................8
6. Solution............................................................8
   6.1. Introduction...................................................8
   6.2. The TIAS bandwidth modifier....................................8
      6.2.1. Usage.....................................................9
      6.2.2. Definition................................................9
      6.2.3. Usage Rules..............................................10
   6.3. Packet Rate parameters........................................10
   6.4. Converting to Transport-Dependent values......................11
   6.5. Deriving RTCP bandwidth.......................................12
      6.5.1. Motivation for this solution.............................12
   6.6. ABNF definitions..............................................12
7. Protocol Interaction...............................................13
   7.1. RTSP..........................................................13
   7.2. SIP...........................................................13
   7.3. SAP...........................................................13
8. Security Consideration.............................................13
9. IANA Considerations................................................14
10. Acknowledgments...................................................14
11. Author's Addresses................................................14
12. References........................................................15
   12.1. Normative references.........................................15
   12.2. Informative References.......................................15
13. IPR Notice........................................................16
14. Copyright Notice..................................................16






Westerlund                  Standards Track                    [Page 2]

INTERNET-DRAFT         Bandwidth modifier for SDP         MAY. 27, 2003


1. Definitions

1.1. Glossary

   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.

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 [3].

2. Introduction

   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.

2.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 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 to decide if this session
   can co-exist with any other sessions. Defined in RFC 2327 [1].

2.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



Westerlund                  Standards Track                    [Page 3]

INTERNET-DRAFT         Bandwidth modifier for SDP         MAY. 27, 2003


   this attribute is the RTP session bandwidth as defined in RFC XXXX
   [4]. The session bandwidth includes the bandwidth that the RTP data
   traffic will consume, including the lower layers down to IP layer.
   Therefore, the bandwidth is in most cases calculated over RTP
   payload, RTP header, UDP and IP. Defined in RFC 2327 [1].

2.1.3. RTCP Report bandwidth

   In RFC YYYY [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.

2.2. IPv6 and IPv4

   Today there are two IP versions 4 [15] and 6 [14] 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 an IPv4 only host and an IPv6
      only host, translation is necessary. This translator can be, for
      example, Network Address Translation - Protocol Translation (NAT-
      PT) [13], 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, solve 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. 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.









Westerlund                  Standards Track                    [Page 4]

INTERNET-DRAFT         Bandwidth modifier for SDP         MAY. 27, 2003



     ---------------  ---------------  ---------------
     | 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.

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
   dependency on the lower protocol layers.

3.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 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 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 also 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:





Westerlund                  Standards Track                    [Page 5]

INTERNET-DRAFT         Bandwidth modifier for SDP         MAY. 27, 2003


   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.
   3. The SDP is changed and both "c=" address type and bandwidth value
      is changed. Unfortunately, this can seldom be done, see 3.2.

   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.2.

   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 reserves bandwidth for this flow,
   too little will be reserved, potentially resulting in bad Quality of
   Service (QoS).

   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. 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 [15] or IPv6 extension headers [14] are used.

   As converting requires the packet rate of the stream, this is not
   possible in the general case. Many codecs have multiple 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. A better parameter is needed.

3.3. 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 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.




Westerlund                  Standards Track                    [Page 6]

INTERNET-DRAFT         Bandwidth modifier for SDP         MAY. 27, 2003


   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.

   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 taken into
   consideration.  For RSVP [16] there exists an extension, RFC 3006
   [17], 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.4. RTCP problems

   When RTCP is used between hosts in IPv4 and IPv6 networks over an
   NAT-PT, 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 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. The IPv6 node may report with 25% longer
   intervals, in the worst case.

   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 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 to calculate overhead for.




Westerlund                  Standards Track                    [Page 7]

INTERNET-DRAFT         Bandwidth modifier for SDP         MAY. 27, 2003


4. Problem Scope

   The problems described in chapter 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 SDP-NG [18].

   As this specification only targets carrying the bit-rate information
   within SDP it will have a limited applicability. As SDP information
   normally is 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 other means 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
   admission control. It does also provide information about the maximum
   codec rate, which is independent of lower-level protocols.

5. Requirements

   A solution to the problems outlined in the preceding chapters and
   with the above applicability, should meet the following requirements:

   - The bandwidth value SHALL be given in a way such that it can be
      calculated for all possible combinations of transport overhead.

6. Solution

6.1. Introduction

   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, it is RECOMMENDED
   that the CT value be calculated using reasonable worst case overhead.

   The RR and RS modifiers [9] will be used as defined and include
   transport overhead. The small unfairness between hosts is deemed
   acceptable.

6.2. The TIAS bandwidth modifier




Westerlund                  Standards Track                    [Page 8]

INTERNET-DRAFT         Bandwidth modifier for SDP         MAY. 27, 2003


6.2.1. Usage

   A new bandwidth modifier is defined to be used for the following
   purposes:

   -  Resource reservation. A single bit-rate can be enough to use for
      resource reservation. Some characteristics can be derived from the
      stream, codec type, etc. In cases where more information is
      needed, then another SDP parameter will be required.

   -  Maximum media codec rate. With the definition below of "TIAS" the
      given bit-rate will mostly be from the media codec. Therefore it
      gives a good indication on the maximum codec bit-rate required to
      be supported by the decoder.

   -  Communication bit-rate required for the stream. The "TIAS" value
      together with "maxprate" can be used to determine the maximum
      communication bit-rate the stream will require. By adding all
      maximum bit-rates from the streams in a session together, a
      receiver can determine if its communication resources are
      sufficient to handle the stream. For example a modem user can
      determine if the session fits his modem's capabilities and the
      established connection.

   -  Determine the RTP session bandwidth and derive the RTCP
      bandwidth. The derived transport dependent attribute will be the
      RTP session bandwidth in case of RTP based transport. The TIAS
      value can also be used to determine the RTCP bandwidth to use when
      using implicit allocation. RTP [4] specifies that if not
      explicitly stated, additional bandwidth shall be used by RTCP
      equal to 5% of the RTP session bandwidth. The RTCP bandwidth can
      be explicitly allocated by using the RR and RS modifiers defined
      in [9].

6.2.2. Definition

   A new session and media level bandwidth modifier is defined:

   b=TIAS:<bandwidth-value> ; see section 6.6 for ABNF definition.

   The Transport Independent Application Specific Maximum (TIAS)
   bandwidth modifier has an integer bit-rate value in bits 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
   (SDP session level) or media stream (SDP media level) without
   counting IP and other transport layers like TCP or UDP. At the SDP
   session level, the TIAS value is simply the sum of all media streams'
   TIAS values. For RTP based media streams, TIAS at the SDP media level
   can be used to derive the RTP "session bandwidth" as defined in
   section 6.2 of [4]. However in the context of RTP transport the TIAS
   value is defined as:



Westerlund                  Standards Track                    [Page 9]

INTERNET-DRAFT         Bandwidth modifier for SDP         MAY. 27, 2003



      Only the RTP payload as defined in [4] SHALL be used in the
      calculation of the bit-rate, i.e., excluding the lower layers
      (IP/UDP) and RTP headers including RTP header, RTP header
      extensions, CSRC list and other RTP profile specific fields. Note
      that the RTP payload includes both the payload format header and
      the data. This may allow one to use the same value for RTP-based
      media transport, non-RTP transport and stored media.

   Note 1: The usage of bps is not in accordance with RFC 2327 [1]. This
   change has no implications on the parser, only the interpreter of the
   value must be aware. The change is done to allow for better
   resolution, and has also been used for the RR and RS bandwidth
   modifiers, see [9].

   Note 2: RTCP bandwidth is not included in the bandwidth value. In
   applications using RTCP, the bandwidth used by RTCP is either 5% of
   the RTP session bandwidth including lower layers or as specified by
   the RR and RS modifiers [9]. A specification of how to derive the
   RTCP bit-rate when using TIAS is presented in chapter 6.5.

6.2.3. Usage Rules

   "TIAS" is primarily intended to be used at the SDP media level. The
   TIAS bandwidth attribute MAY be present at the session level in SDP.
   However, if present at the session level it SHOULD be present also at
   the media level. "TIAS" SHALL NOT be present at the session level
   unless the same transport is used for all media streams. The session
   level value, if present, MUST be the sum of all media level values.

   To allow for backwards compatibility with applications of SDP that do
   not implement "TIAS", it is RECOMMENDED to also include the "AS"
   modifier when using "TIAS". The presence of a value including lower-
   layer overhead, even with its problems, is better than none. However,
   an SDP application implementing TIAS SHOULD ignore the "AS" value and
   use "TIAS" instead when both are present.

   When using TIAS for an RTP-transported stream, the "maxprate"
   attribute, defined next, SHALL be included at the corresponding SDP
   level.

6.3. Packet Rate parameter

   To be able to calculate the bandwidth value including the lower
   layers actually used, a packet rate attribute is also defined.

   The SDP session and media level maximum packet rate attribute is
   defined as:

   a=maxprate:<packet-rate> ; see section 6.6 for ABNF definition.




Westerlund                  Standards Track                   [Page 10]

INTERNET-DRAFT         Bandwidth modifier for SDP         MAY. 27, 2003


   The <packet-rate> is a floating-point value for the stream's maximum
   packet rate in packets per second. If the number of packets is
   variable, the given value SHALL be the maximum the application can
   produce in case of live stream, or for stored on-demand streams, has
   produced. The packet rate is calculated by adding together the number
   of packets sent within a 1 second long window. The maxprate is the
   largest value produced when the window slides over the entire media
   stream. In cases that this can't be calculated, i.e. for example a
   live stream, a estimated value of the maximum packet rate the codec
   can produce for the given configuration and content SHALL be used.

   Note: The sliding window calculation will always yield an integer
   number, however the attributes field is a floating-point value. The
   reason is that estimated or known maximum packet rate per second may
   be fractional.

   At the SDP session level, the maxprate value MUST be the sum of all
   media-level packet rates. The session-level value MAY only be given
   if all media streams use the same transport. If that is not the case,
   the "maxprate" attribute MUST NOT be present at the session level. If
   given at the session level it SHOULD also be given at the media
   level.

   "maxprate" SHALL be included for all transports where a packet rate
   can be derived and TIAS is included.

6.4. Converting to Transport-Dependent values

   When converting the transport-independent bandwidth value (bw-value)
   into a transport-dependent value including the lower layers, the
   following MUST be done:

   1. Determine which lower layers will be used and calculate the sum of
      the sizes of the headers in bits (h-size). In cases of variable
      header sizes, the average size SHALL be used. For RTP-transported
      media, the lower layers SHALL include the RTP header with header
      extensions, if used, the CSRC list, and any profile-specific
      extensions.
   2. Retrieve the maximum packet rate from the SDP (prate = maxprate).
   3. Calculate the transport overhead by multiplying the header sizes
      by the packet rate (t-over = h-size * prate).
   4. Round the transport overhead up to nearest integer in bits (t-over
      = CEIL(t-over)).
   5. Add the transport overhead to the transport independent bandwidth
      value (total bit-rate = bw-value + t-over)

   When the above calculation is performed using the "maxprate", the
   bit-rate value will be the absolute maximum the media stream may use
   over the transport assumed in the calculations.





Westerlund                  Standards Track                   [Page 11]

INTERNET-DRAFT         Bandwidth modifier for SDP         MAY. 27, 2003


6.5. Deriving RTCP bandwidth

   This chapter does not solve the fairness and possible bit-rate change
   introduced by IPv4 to IPv6 translation. These differences are
   considered small enough and known solutions introduce code changes to
   the RTP/RTCP implementation. This chapter gives only a consistent way
   of calculating the bit-rate to assign to RTCP if not explicitly
   given.

   First the transport-dependent RTP session bit-rate is calculated, in
   accordance with chapter 6.4, using the actual transport layers used
   at the end point where the calculation is done. The RTCP bit-rate is
   then derived as usual based on the RTP session bandwidth, i.e.,
   normally equal to 5% of the calculated value.

6.5.1. Motivation for this solution

   Giving the exact same RTCP bit-rate value to both the IPv4 and IPv6
   hosts will result in the IPv4 host having a higher RTCP sending rate.
   For a 100-byte RTCP packet (including UDP/IPv4), the IPv4 sender has
   an approximately 20% higher rate. This rate falls with larger RTCP
   packets. For example, 300-byte packets will only give the IPv4 host a
   7% higher reporting rate.

   The above rule for deriving RTCP bandwidth gives the same behavior as
   fixed assignment when the RTP session has traffic parameters giving a
   large TIAS/maxprate ratio. The two hosts will be fair when the
   TIAS/maxprate ratio is approximately 40 bytes/packet given 100-byte
   RTCP packets. For a TIAS/maxprate ratio of 5 bytes/packet, the IPv6
   host will be allowed to send approximately 15-20% more RTCP packets.
   The larger the RTCP packets become, the more it will favor the IPv6
   host in sending rate.

   The conclusions is that, within the normal useful combination of
   transport-independent bit rates and packet rates, the difference in
   fairness between hosts on different IP versions with different
   overhead is acceptable. For the 20-byte difference in overhead
   between IPv4 and IPv6 headers, the RTCP bandwidth actually used in a
   unicast connection case will not be larger than approximately 1% of
   the total session bandwidth.

6.6. ABNF definitions

   This chapter defines in ABNF from RFC 2234 [2] the bandwidth modifier
   and the packet rate attribute.

   The bandwidth modifier:

   TIAS-bandwidth-def = "b" "=" "TIAS" ":" bandwidth-value CRLF

   bandwidth-value = 1*DIGIT



Westerlund                  Standards Track                   [Page 12]

INTERNET-DRAFT         Bandwidth modifier for SDP         MAY. 27, 2003



   The maximum packet rate attribute:

   max-p-rate-def = "a" "=" "maxprate" ":" packet-rate CRLF

   packet-rate = 1*DIGIT ["." 1*DIGIT]


7. Protocol Interaction

7.1. RTSP

   The "TIAS" and "maxprate" parameters can be used with RTSP as
   currently specified. To be able to calculate the transport dependent
   bandwidth, some of the transport header parameters will be required.
   There should be no problem for a client to calculate the required
   bandwidth(s) prior to an RTSP SETUP. The reason is that a client
   supports a limited number of transport setups. The one actually
   offered to a server in a SETUP request will be dependent on the
   contents of the SDP description. The "m=" line(s) will signal to the
   client the desired transport profile(s).

7.2. SIP

   The usage of "TIAS" together with "maxprate" should not be different
   from the handling of the "AS" modifier currently in use. The needed
   transport parameters will available in the transport field in the
   "m=" line. The address class can be determined from the "c=" field
   and the client's connectivity.


7.3. SAP

   In the case of SAP all available information to calculate the
   transport dependent bit-rate should be present in the SDP. The "c="
   information gives the address family used for the multicast. The
   transport layer, e.g. RTP/UDP, for each media is evident in the media
   line ("m=") and its transport field.

8. 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 the user and also blocking of resources that other
   parties could have used. If too little bandwidth is reserved the
   receiving user's quality MAY be effected. Trusting a too-large TIAS
   value may also result in the receiver rejecting the session due to
   insufficient communication and decoding resources.




Westerlund                  Standards Track                   [Page 13]

INTERNET-DRAFT         Bandwidth modifier for SDP         MAY. 27, 2003


   Due to these security risks it is strongly RECOMMENDED that the SDP
   be authenticated so no tampering can be performed. It is also
   RECOMMENDED that any receiver of the SDP perform an analysis of the
   received bandwidth values to verify that they are reasonable and are
   what can be expected for the application. For example, a single
   channel AMR-encoded voice stream claiming to use 1000 kbps is not
   reasonable.

9. IANA Considerations

   This document registers one new SDP session and media level attribute
   "maxprate", see section 6.3.

   A new SDP [1] bandwidth modifier (bwtype) "TIAS" is also registered
   in accordance with the rules requiring a standards-track RFC. The
   modifier is defined in section 6.2.

10. Acknowledgments

   The author would like to thank Gonzalo Camarillo and Hesham Soliman
   for their work reviewing this document. A very big thanks goes to
   Stephen Casner for reviewing and helping fixing the language and
   finding some errors in the draft.

   The author would also like to thank all persons on the MMUSIC working
   group's mailing list that have commented on this specification.

11. 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                  Standards Track                   [Page 14]

INTERNET-DRAFT         Bandwidth modifier for SDP         MAY. 27, 2003


12. References

12.1. Normative references

   [1]  M. Handley, V. Jacobson, "Session Description Protocol (SDP)",
        IETF RFC 2327, April 1998.
   [2]  D. Crocker and P. Overell, "Augmented BNF for syntax specifica-
        tions: ABNF," RFC 2234, Internet Engineering Task Force, Nov.
        1997.
   [3]  S. Bradner, "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.
   [4]  H. Schulzrinne, et. al., "RTP: A Transport Protocol for Real-
        Time Applications", IETF RFC XXXX, September 2003 (draft-ietf-
        avt-rtp-new-12.txt).

12.2. Informative References

   [5]  M. Handley et al., "Session Announcement Protocol", IETF RFC
        2974, October 2000.
   [6]  J. Rosenberg, et. al., "SIP: Session Initiation Protocol", IETF
        RFC 3261, June 2002.
   [7]  J. Rosenberg, H. Schulzrine, "An Offer/Answer Model with Session
        Description Protocol (SDP)", IETF RFC 3164, June 2002.
   [8]  H. Schulzrinne, et. al., "Real Time Streaming Protocol (RTSP)",
        IETF RFC 2326, April 1998.
   [9]  S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", IETF
        RFC YYYY, September 2003 (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.
   [13] Tsirtsis, G. and Srisuresh, P., "Network Address Translation -
        Protocol Translation (NAT-PT)", RFC 2766, Internet Engineering
        Task Force, February 2000.
   [14] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", RFC 2460, Internet Engineering Task Force,
        December 1998.
   [15] J. Postel, "Internet Protocol", RFC 791, Internet Engineering
        Task Force, September 1981.
   [16] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
        "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
        Specification", RFC 2205, September 1997.
   [17] Davie, B., et. al., "Integrated Services in the Presence of
        Compressible Flows," RFC 3006, Internet Engineering Task Force,
        November 2000.
   [18] Kutscher, Ott, Bormann, "Session Description and Capability
        Negotiation," IETF draft, work in progress, march 2003.




Westerlund                  Standards Track                   [Page 15]

INTERNET-DRAFT         Bandwidth modifier for SDP         MAY. 27, 2003


13. IPR Notice

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

14. Copyright Notice

   Copyright (C) The Internet Society (2003). 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 implementation 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 Society 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 followed, 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 MERCHANTABILITY OR FITNESS FOR A
   PARTICULAR PURPOSE.



Westerlund                  Standards Track                   [Page 16]

INTERNET-DRAFT         Bandwidth modifier for SDP         MAY. 27, 2003


Changes

   [Note to RFC Editor: Remove this section when publishing]

   The following changes have been done to this version compared to
   draft-ietf-mmusic-sdp-bwparam-01.txt:

   - Improved language in the whole draft
   - Updated the problem scope section (4) to clarify what part of the
      whole problem space that this specification provides solution to.
   - Clarified that the tunneling problem example may not be applicable
      for the TIAS parameters (Section 2.2).
   - Included text about RFC 3006, which provides hints in RSVP that
      header compression is possible.
   - Removed an inconsistency in the normative language regarding the
      usage of "maxprate" attribute. It shall always be present when
      TIAS is used.

   The following changes have been done to this version compared to
   draft-ietf-mmusic-sdp-bwparam-02.txt

   - Updated language in abstract.
   - Replaced a reference to RFC 1889 with RFC XXXX.
   - Added a SDP-NG informative reference.
   - Corrected two language errors in Section 4.
   - Fixed reference [15].

RFC-Editor Considerations

   Please remove this and the previous section before publishing.

   Please update reference [4] (draft-ietf-avt-rtp-new-12.txt) with the
   correct publication date and RFC number when they are available.
   Please remove the parenthesis pointing out the draft file. Please
   update all occurrences of XXXX with the RFC number that [4] receive.

   Please replace any occurrences of YYYY with the RFC number that is
   given to the draft in reference [9] when published. Please update
   reference [9] with the correct date of publication and remove the
   parenthesis pointing out the draft.

This Internet-Draft expires in November 2003.












Westerlund                  Standards Track                   [Page 17]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/