Network Working Group Magnus Westerlund INTERNET-DRAFT Ericsson Category: Standards Track October 20, 2003 Expires: April 2004 A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP). 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 an SDP bandwidth modifier (TIAS) that Westerlund [Page 1] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 2003 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. 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..........................................4 2.1.2. Application Specific Maximum..............................4 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.............................................7 3.4. RTCP problems..................................................7 3.5. Future development.............................................8 4. Problem Scope.......................................................8 5. Requirements........................................................8 6. Solution............................................................9 6.1. Introduction...................................................9 6.2. The TIAS bandwidth modifier....................................9 6.2.1. Usage.....................................................9 6.2.2. Definition...............................................10 6.2.3. Usage Rules..............................................11 6.3. Packet Rate parameter.........................................11 6.4. Converting to Transport-Dependent values......................12 6.5. Deriving RTCP bandwidth.......................................13 6.5.1. Motivation for this solution.............................13 6.6. ABNF definitions..............................................13 6.7. Example.......................................................14 7. Protocol Interaction...............................................15 7.1. RTSP..........................................................15 7.2. SIP...........................................................15 7.3. SAP...........................................................15 8. Security Consideration.............................................15 9. IANA Considerations................................................16 10. Acknowledgments...................................................16 11. Author's Addresses................................................16 12. References........................................................17 12.1. Normative references.........................................17 12.2. Informative References.......................................17 13. IPR Notice........................................................19 14. Copyright Notice..................................................19 Westerlund Standards Track [Page 2] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 2003 1. Definitions 1.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. 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 This specification is structured in the following way: In this section (2) some information regarding SDP bandwidth modifiers and IP versions 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 consideration, acknowledgements, author's address, reference list, 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. 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=: Westerlund Standards Track [Page 3] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 2003 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 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 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 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. 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 Westerlund Standards Track [Page 4] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 2003 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. --------------- --------------- --------------- | 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 Westerlund Standards Track [Page 5] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 2003 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: 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 an Application Level Gateway (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 converted. 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 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. 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 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 Westerlund Standards Track [Page 6] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 2003 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. 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. Westerlund Standards Track [Page 7] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 2003 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. This may become a problem if one has the possibility to use different protocols, which will not be determined prior to actual protocol SETUP. Thus pre-calculating this value will not be possible. 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. This specification does NOT try to solve the problem of detecting NATs or other middleboxes. 5. Requirements A solution to the problems outlined in the preceding chapters and with the above applicability, should meet the following requirements: Westerlund Standards Track [Page 8] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 2003 - 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. Thus enabling the derivation of the required bit-rate for an application, or RTP session's data and RTCP traffic. The solution is based upon the definition of a new Transport Independent Application Specific (TIAS) bandwidth modifier and a new SDP attribute for the maximum packet rate (maxprate). 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. An example of how to calculate a reasonable worst case overhead is: Take the overhead of the largest transport protocol (using average size if variable), add that to the largest IP overhead that is expected to use plus the data traffic rate. Do this for every individual media stream used in the conference and add them together. 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 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. Using session level values or through adding all maximum bit-rates from the streams in a session together, a receiver can determine if its Westerlund Standards Track [Page 9] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 2003 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: ; 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 the maximal amount of bandwidth need when all declared media streams are used. This MAY be less than the sum of all the individual media streams values. This can be due to the possibility that not all streams have their maximum at the same point in time. This can normally only be verified for stored media streams. For RTP transported media streams, TIAS at the SDP media level can be used to derive the RTP "session bandwidth", defined in section 6.2 of [4]. In the context of RTP transport the TIAS value is defined as: 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]. Westerlund Standards Track [Page 10] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 2003 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, if all media streams uses the same transport. In cases when the sum of the media level values for all media streams is larger than the actual maximum bandwidth need for all streams, it SHOULD be included at session level. 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 protocols is used for all media streams. The same transport is used as long as the same combination of protocols is used, like IPv6/UDP/RTP. 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 if possible to calculate, 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: ; see section 6.6 for ABNF definition. The 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. Westerlund Standards Track [Page 11] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 2003 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 is the maximum packet rate calculated over all the declared media streams. If this can't be measured (stored media) or estimated (live) the sum of all media level values provides a ceiling value. Note: the value at session level can be less then the sum of the individual media streams due to temporal distribution of media streams maximums. The "maxprate" attribute MUST NOT be present at session level if the media streams use different transport. The attribute MAY be present if the media streams use the same transport. If the attribute is present at the session level it SHOULD also be present at the media level for all media streams. "maxprate" SHALL be included for all transports where a packet rate can be derived and TIAS is included. For example, if you use TIAS and a transport like IP/UDP/RTP, for which the max packet rate (actual or estimated) can be derived, then "maxprate" SHALL be included. However if either (a) the packet rate for the transport cannot be derived, or (b) TIAS is not included, then, "maxprate" is not required to be 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 12] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 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. With sending rate it is meant the number of RTCP packets sent during a given time interval. The sending of RTCP is limited according to rules defined in the RTP specification [4]. For a 100-byte RTCP packet (including UDP/IPv4), the IPv4 sender has an approximately 20% higher sending rate. This rate falls with larger RTCP packets. For example, 300-byte packets will only give the IPv4 host a 7% higher sending 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: Westerlund Standards Track [Page 13] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 2003 TIAS-bandwidth-def = "b" "=" "TIAS" ":" bandwidth-value CRLF bandwidth-value = 1*DIGIT The maximum packet rate attribute: max-p-rate-def = "a" "=" "maxprate" ":" packet-rate CRLF packet-rate = 1*DIGIT ["." 1*DIGIT] 6.7. Example v=0 o=Example_SERVER 3413526809 0 IN IP4 server.example.com s=Example of TIAS and maxprate in use c=IN IP4 0.0.0.0 b=AS:60 b=TIAS:50780 t=0 0 a=control:rtsp://server.example.com/media.3gp a=range:npt=0-150.0 a=maxprate:28.0 m=audio 0 RTP/AVP 97 b=AS:12 b=TIAS:8480 a=maxprate:10.0 a=rtpmap:97 AMR/8000 a=fmtp:97 octet-align; a=control:rtsp://server.example.com/media.3gp/trackID=1 m=video 0 RTP/AVP 99 b=AS:48 b=TIAS:42300 a=maxprate:18.0 a=rtpmap:99 MP4V-ES/90000 a=fmtp:99 profile-level-id=8; config=000001B008000001B509000001010000012000884006682C2090A21F a=control:rtsp://server.example.com/media.3gp/trackID=3 In this SDP example of a streaming session's SDP, there are two media streams, one audio stream encoded with AMR and one video stream encoded with the MPEG-4 Video encoder. AMR is here used to produce a constant rate media stream and does use a packetization resulting in 10 packets per second. This results in a TIAS bandwidth rate of 8480 bits per second, and the claimed 10 packets per second. The video stream is more variable. However it has a measured maximum payload rate of 42300 bits per second. The video also has variable packet rate, despite the fact that the video is 15 frames per second there where at least one instance when a second long window contained 18 packets. Westerlund Standards Track [Page 14] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 2003 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 integrity 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. Due to these security risks it is strongly RECOMMENDED that the SDP be integrity protected and source authenticated so no tampering can be performed and the source trusted. 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. Westerlund Standards Track [Page 15] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 2003 Please note that some of the above security requirements are in conflict with what is required to make signaling protocols using SDP to work through a middlebox as discussed in the security considerations of RFC 3303 [19]. 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. Further thanks for suggestion to improvements goes to Colin Perkins, Geetha Srikantan, and Emre Aksu. 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 16] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 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", RFC 3550, Internet Engineering Task Force, July 2003. 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 3556, Internet Engineering Task Force, July 2003. [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 17] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 2003 [19] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan, " Middlebox communication architecture and framework," RFC 3303, Internet Engineering Task Force, August 2002. Westerlund Standards Track [Page 18] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 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 19] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 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]. The following changes have been done to this version compared to draft-ietf-mmusic-sdp-bwparam-03.txt - Changed the definition of TIAS and maxprate at SDP session level. It is now allowed to have a session rate less than the sum of the individual rates. - Added an example of the usage of the attributes. - Reformulated some sentences for clarity. The following changes have been done to this version compared to draft-ietf-mmusic-sdp-bwparam-04.txt - Clarified the scope by explicitly noting that detecting NATs was out of scope. - Added a paragraph in the introduction presenting the structure of the document. - Clarified that the bandwidth parameter and intended use is not end to end, but rather near end usage. - Clarified for readability in the solution section directly what TIAS stands for. - Added an example of how to derive reasonable worst case overhead for the CT bandwidth modifier. - Clarified what is meant with "RTCP sending rate". - Added a reference to the security considerations of RFC 3303. Westerlund Standards Track [Page 20] INTERNET-DRAFT Bandwidth modifier for SDP October 20, 2003 - Replaced the preliminary RFC XXXX and RFC YYYY references with the real RFC 3550 and 3556 information. This Internet-Draft expires in April 2004. Westerlund Standards Track [Page 21]