idnits 2.17.1 draft-ietf-mmusic-sdp-bwparam-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 924. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 5) being 72 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 14, 2004) is 7289 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2327 (ref. '1') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 3164 (ref. '7') (Obsoleted by RFC 5424) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '8') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '13') (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '19') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. '20') (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2406 (ref. '21') (Obsoleted by RFC 4303, RFC 4305) Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Magnus Westerlund 2 INTERNET-DRAFT Ericsson 3 Expires: October 2004 April 14, 2004 5 A Transport Independent Bandwidth Modifier for the Session 6 Description Protocol (SDP). 7 9 Status of this memo 11 By submitting this Internet-Draft, I (we) certify that any applicable 12 patent or other IPR claims of which I am (we are) aware have been 13 disclosed, and any of which I (we) become aware will be disclosed, in 14 accordance with RFC 3668 (BCP 79). 16 By submitting this Internet-Draft, I (we) accept the provisions of 17 Section 3 of RFC 3667 (BCP 78). 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/lid-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This document is a submission of the IETF MMUSIC WG. Comments should 35 be directed to the MMUSIC WG mailing list, mmusic@ietf.org. 37 Abstract 39 The existing Session Description Protocol (SDP) bandwidth modifiers 40 and their values include the bandwidth needed also for the transport 41 and IP layers. When using SDP with protocols like the Session 42 Announcement Protocol (SAP), the Session Initiation Protocol (SIP) 43 and the Real-Time Streaming Protocol (RTSP) and when the involved 44 hosts has different transport overhead, for example due to different 45 IP versions, the interpretation of what lower layer bandwidths are 46 included is not clear. This document defines an SDP bandwidth 47 modifier (TIAS) that does not include transport overhead; instead an 48 additional packet rate attribute is defined. The transport 49 independent bit-rate value together with the maximum packet rate can 50 then be used to calculate the real bit-rate over the transport 51 actually used. 53 TABLE OF CONTENTS 55 1. Definitions.........................................................4 56 1.1. Glossary.......................................................4 57 1.2. Terminology....................................................4 58 2. Introduction........................................................4 59 2.1. The Bandwidth Attribute........................................4 60 2.1.1. Conference Total..........................................5 61 2.1.2. Application Specific Maximum..............................5 62 2.1.3. RTCP Report bandwidth.....................................5 63 2.2. IPv6 and IPv4..................................................5 64 2.3. Further Mechanisms that change the bandwidth utilization.......6 65 2.3.1. IPSec.....................................................6 66 2.3.2. Header Compression........................................7 67 3. The Bandwidth Signaling Problems....................................7 68 3.1. What IP version is used........................................7 69 3.2. Taking other mechanisms into account...........................8 70 3.3. Converting bandwidth values....................................9 71 3.4. RTCP problems..................................................9 72 3.5. Future development............................................10 73 3.6. Problem Conclusion............................................10 74 4. Problem Scope......................................................11 75 5. Requirements.......................................................11 76 6. Solution...........................................................11 77 6.1. Introduction..................................................11 78 6.2. The TIAS bandwidth modifier...................................12 79 6.2.1. Usage....................................................12 80 6.2.2. Definition...............................................13 81 6.2.3. Usage Rules..............................................13 82 6.3. Packet Rate parameter.........................................14 83 6.4. Converting to Transport-Dependent values......................15 84 6.5. Deriving RTCP bandwidth.......................................15 85 6.5.1. Motivation for this solution.............................16 86 6.6. ABNF definitions..............................................16 87 6.7. Example.......................................................17 88 7. Protocol Interaction...............................................17 89 7.1. RTSP..........................................................17 90 7.2. SIP...........................................................18 91 7.3. SAP...........................................................18 92 8. Security Consideration.............................................18 93 9. IANA Considerations................................................19 94 10. Acknowledgments...................................................19 95 11. Author's Addresses................................................19 96 12. References........................................................19 97 12.1. Normative references.........................................19 98 12.2. Informative References.......................................19 100 1. Definitions 102 1.1. Glossary 104 ALG - Application Level Gateway. 105 bps - bits per second. 106 RTSP - Real-Time Streaming Protocol, see [8]. 107 SDP - Session Description Protocol, see [1]. 108 SAP - Session Announcement Protocol, see [5]. 109 SIP - Session Initiation Protocol, see [6]. 110 TIAS - Transport Independent Application Specific maximum, a 111 bandwidth modifier. 113 1.2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [3]. 119 2. Introduction 121 This specification is structured in the following way: In this 122 section (2) some information regarding SDP bandwidth modifiers, and 123 different mechanisms that affect transport overhead are asserted. In 124 section 3 the problems found are described, including problems that 125 are not solved by this specification. In section 4 the scope of the 126 problems this specification solves is presented. Section 5 contains 127 the requirements applicable to the problem scope. Section 6 defines 128 the solution, which is a new bandwidth modifier, and a new maximum 129 packet rate attribute. Section 7 looks at the protocol interaction 130 for SIP, RTSP, and SAP. The security considerations are discussed in 131 section 8. The remaining sections are the necessary IANA 132 consideration, acknowledgements, author's address, reference list, 133 and copyright and IPR notices. 135 Today the Session Description Protocol (SDP) [1] is used in several 136 types of applications. The original application is session 137 information and configuration for multicast sessions announced with 138 Session Announcement Protocol (SAP) [5]. SDP is also a vital 139 component in media negotiation for the Session Initiation Protocol 140 (SIP) [6] by using the offer answer model [7]. The Real-Time 141 Streaming Protocol (RTSP) [8] also makes use of SDP to declare to the 142 client what media and codec(s) comprise a multi-media presentation. 144 2.1. The Bandwidth Attribute 145 In SDP [1] there exists a bandwidth attribute, which has a modifier 146 used to specify what type of bit-rate the value refers to. The 147 attribute has the following form: 149 b=: 151 Today there are four modifiers defined which are used for different 152 purposes. 154 2.1.1. Conference Total 156 The Conference Total is indicated by giving the modifier "CT". The 157 meaning of Conference total is to give a maximum bandwidth that a 158 conference session will use. Its purpose is to decide if this session 159 can co-exist with any other sessions. Defined in RFC 2327 [1]. 161 2.1.2. Application Specific Maximum 163 The Application Specific maximum bandwidth is indicated by the 164 modifier "AS". The interpretation of this attribute is dependent on 165 the application's notion of maximum bandwidth. For an RTP application 166 this attribute is the RTP session bandwidth as defined in RFC 3550 167 [4]. The session bandwidth includes the bandwidth that the RTP data 168 traffic will consume, including the lower layers down to IP layer. 169 Therefore, the bandwidth is in most cases calculated over RTP 170 payload, RTP header, UDP and IP. Defined in RFC 2327 [1]. 172 2.1.3. RTCP Report bandwidth 174 In RFC 3556 [9], two bandwidth modifiers are defined. These 175 modifiers, "RS" and "RR", define the amount of bandwidth that is 176 assigned for RTCP reports by active data senders and RTCP reports by 177 other participants (receivers), respectively. 179 2.2. IPv6 and IPv4 181 Today there are two IP versions 4 [14] and 6 [13] used in parallel on 182 the Internet. This creates problems and there exist a number of 183 possible transition mechanisms. 185 - The nodes which wish to communicate must share the IP version; 186 typically this is done by deploying dual-stack nodes. For 187 example, an IPv4 only host cannot communicate with an IPv6 only 188 host. 190 - If communication between nodes which do not share a protocol 191 version is required, using a translation or proxying mechanism 192 would be required. Work is underway to specify one for this 193 purpose. 195 ------------------ ---------------------- 196 | IPv4 domain | | IPv6 Domain | 197 | | ------------- | | 198 | ---------- |-|Translator |-| ---------- | 199 | |Server A| | | or proxy | | |Client B| | 200 | ---------- | ------------- | ---------- | 201 ------------------ ---------------------- 203 Figure 1. Translation or proxying between IPv6 and IPv4 addresses. 205 - IPv6 nodes belonging to different domains running IPv6, but 206 lacking IPv6 connectivity between them, solve this by tunneling 207 over the IPv4 net, see Figure 2. Basically the IPv6 packets are 208 put as payload in IPv4 packets between the tunneling end-points at 209 the edge of each IPv6 domain. The bandwidth required over the IPv4 210 domain will be different from IPv6 domains. However as the 211 tunneling is normally not performed by the application end-point 212 this scenario can not usually be taken into consideration. 214 --------------- --------------- --------------- 215 | IPv6 domain | | IPv4 domain | | IPv6 Domain | 216 | | |-------------| | | 217 | ---------- |--||Tunnel ||--| ---------- | 218 | |Server A| | |-------------| | |Client B| | 219 | ---------- | | | | ---------- | 220 --------------- --------------- --------------| 222 Figure 2. Tunneling through a IPv4 domain 224 IPv4 has a minimum header size of 20 bytes, while the fixed part of 225 the IPv6 header is 40 bytes. 227 The difference in header sizes means that the bit-rate required for 228 the two IP versions is different. The significance of the difference 229 depends on the packet rate and payload size of each packet. 231 2.3. Further Mechanisms that change the bandwidth utilization 233 There exist a number of other mechanisms that also may change the 234 overhead at layers below media transport. We will here shortly cover 235 a few of these. 237 2.3.1. IPSec 238 IPSec [19] can be used between end points to provide confidentiality 239 through the application of the IP Encapsulating Security Payload 240 (ESP) [21] or integrity protection using IP Authentication Header 241 (AH) [20] of the media stream. The addition of the ESP and AH headers 242 increases each packet's size. 244 To provide virtual private networks, complete IP packets may be 245 encapsulated between an end node and the private networks security 246 gateway. Thus providing a secure tunnel that ensures confidentiality, 247 integrity, and authentication of the packet stream. The extra IP and 248 ESP header will in this case significantly increase the packet size. 250 2.3.2. Header Compression 252 Another mechanism that alters the actual overhead over links is 253 header compression. Header compression uses the fact that most 254 network protocol headers have either static or predictable values in 255 their fields within a packet stream. Compression is normally only 256 done on per hop basis, i.e. on a single link. The normal reason for 257 doing header compression is that the link has fairly limited 258 bandwidth and significant gain in throughput is achieved. 260 There exist several different header compression standards. For 261 compressing IP headers only, there is RFC 2507 [10]. For compressing 262 packets with IP/UDP/RTP headers, CRTP [11] was created at the same 263 time. More recently the Robust Header Compression (ROHC) working 264 group has been developing a framework and profiles [12] for 265 compressing certain combinations of protocols, like IP/UDP, and 266 IP/UDP/RTP. 268 3. The Bandwidth Signaling Problems 270 When an application wants to use SDP to signal the bandwidth required 271 for this application, some problems become evident due to the 272 inclusion of the lower layers in the bandwidth values. 274 3.1. What IP version is used 276 If one signals the bandwidth in SDP, with for example "b=AS:" for an 277 RTP based application, one cannot know if the overhead is calculated 278 for IPv4 or IPv6. An indication of which protocol has been used when 279 calculating the bandwidth values is given by the "c=" connection 280 address line. This line contains either a multicast group address or 281 a unicast address of the data source or sink. The "c=" line's address 282 type may be assumed to be of the same type as the one used in the 283 bandwidth calculation, although there seems to exist no specification 284 pointing this out. 286 In cases of SDP transported by RTSP this is even less clear. The 287 normal usage for a unicast on-demand streaming session is to set the 288 connection data address to a null address. This null address does 289 have an address type, which could be used as an indication. However, 290 this is also not clarified anywhere. 292 Figure 1, illustrates a connection scenario between a streaming 293 server A and a client B over a translator. When B receives the SDP 294 from A over RTSP it will be very difficult for B to know what the 295 bandwidth values in the SDP represent. The following possibilities 296 exist: 298 1. The SDP is unchanged and "c=" null address is of type IPv4. The 299 bandwidth value represents the bandwidth needed in an IPv4 300 network. 301 2. The SDP has been changed by an Application Level Gateway (ALG). 302 The "c=" address is changed to IPv6 type. The bandwidth value is 303 unchanged. 304 3. The SDP is changed and both "c=" address type and bandwidth value 305 is converted. Unfortunately, this can seldom be done, see 3.2. 307 In case 1 the client can understand that the server is located in an 308 IPv4 network and that it uses IPv4 overhead when calculating the 309 bandwidth value. The client can almost never convert the bandwidth 310 value, see section 3.2. 312 In case 2 the client does not know that the server is in an IPv4 313 network and that the bandwidth value is not calculated with IPv6 314 overhead. In cases where a client uses this value to determine if its 315 end of the network has sufficient resources the client will 316 underestimate the required bit-rate, potentially resulting in bad 317 application performance. 319 In case 3 everything works correctly. However, this case will be very 320 rare. If one tries to convert the bandwidth value without further 321 information about the packet rate, significant errors may be 322 introduced into the value. 324 3.2. Taking other mechanisms into account 326 Section 2.2 and 2.3 lists a number of reasons, like header 327 compression and tunnels that would change lower layer header sizes. 328 For these mechanisms there exist different possibilities to take them 329 into account. 331 Using IPSec directly between end-points should definitely been known 332 to the application, thus enabling it to take the extra headers into 333 account. However the same problem exist with the current SDP 334 bandwidth modifiers that a receiver is not able to convert these 335 values taking the IPSec headers into account. 337 It is less likely that an application would be aware of the existence 338 of a virtual private network. Thus the generality of the mechanism to 339 tunnel all traffic, may prevent the application to even consider this 340 even if it would be possible to convert the values. 342 When using header compression the actual overhead will be less 343 deterministic, but in most cases an average overhead can be 344 determined for a certain application. If a network node knows that 345 some type of header compression is employed this can taken into 346 consideration. For RSVP [15] there exists an extension, RFC 3006 347 [16], that allows the data sender to inform network nodes about the 348 compressibility of the data flow. To be able to do this with any 349 accuracy the compression factor and packet rate or size is needed, as 350 RFC 3006 provides. 352 3.3. Converting bandwidth values 354 If one would like to convert a bandwidth value calculated using IPv4 355 overhead to IPv6 overhead, the packet rate is required. The new 356 bandwidth value for IPv6 is normally "IPv4 bandwidth" + "packet rate" 357 * 20 bytes, where 20 bytes is the usual difference between IPv6 and 358 IPv4 headers. The overhead difference may be some other value in 359 cases when IPv4 options [14] or IPv6 extension headers [13] are used. 361 As converting requires the packet rate of the stream, this is not 362 possible in the general case. Many codecs have either multiple 363 possible packet/frame rates or can perform payload format 364 aggregation, resulting in many possible rates. Therefore some extra 365 information in the SDP will be required. The "a=ptime:" parameter may 366 be a possible candidate. However this parameter is normally only used 367 for audio codecs. Also its definition [1] is that it is only a 368 recommendation which the sender may disregard. A better parameter is 369 needed. 371 3.4. RTCP problems 373 When RTCP is used between hosts in IPv4 and IPv6 networks over an 374 translator, similar problems exist. The RTCP traffic going from the 375 IPv4 domain will result in a higher RTCP bit-rate than intended in 376 the IPv6 domain due to the larger headers. This may result in up to 377 25% increase in required bandwidth for the RTCP traffic. The largest 378 increase will be for small RTCP packets when the number of IPv4 hosts 379 is much larger than the number of IPv6 hosts. Fortunately, as RTCP 380 has a limited bandwidth compared to RTP it will only result in a 381 maximum of 1.75% increase of the total session bandwidth when RTCP 382 bandwidth is 5% of RTP bandwidth. The RTCP randomization may easily 383 result in short term effects of the same magnitude, so this increase 384 may be considered tolerable. The increase in bandwidth will in most 385 cases be less. 387 At the same time, this results in unfairness in the reporting between 388 an IPv4 and IPv6 node. The IPv6 node may report with 25% longer 389 intervals, in the worst case. 391 These problems have been considered insignificant enough to not be 392 worth any complex solutions. Therefore only a simple algorithm for 393 deriving RTCP bandwidth is defined in this specification. 395 3.5. Future development 397 Today there is work in IETF to design a new datagram transport 398 protocol suitable for real-time media. This protocol is called the 399 Datagram Congestion Control Protocol (DCCP). It will most probably 400 have a different header size than UDP, which is the protocol most 401 often used for real-time media today. This results in even more 402 possible transport combinations. This may become a problem if one has 403 the possibility to use different protocols, which will not be 404 determined prior to actual protocol SETUP. Thus pre-calculating this 405 value will not be possible. Which is one further motivation why a 406 transport independent bandwidth modifier is needed. 408 DCCP's congestion control algorithms will control how much bandwidth 409 that really can be utilized. This may require further work with 410 specifying SDP bandwidth modifiers to declare the dynamic 411 possibilities of an application's media stream, for example min and 412 max media bandwidth the application is capable of producing at all, 413 or for media codecs only capable of producing certain bit-rates, 414 enumerating possible rates. However this is for future study and 415 outside the scope of the present solution. 417 3.6. Problem Conclusion 419 A shortcoming of the current SDP bandwidth modifiers is that they 420 include also the bandwidth needed for lower layers. It is in many 421 cases difficult to determine which lower layers and their versions 422 that were included in the calculation, especially in the presence of 423 translation or proxying between different domains. This prevents a 424 receiver from determining if given bandwidth needs to be converted 425 based on the actual lower layers being used. 427 Secondly there exist no attribute to give the receiver an explicit 428 determination of the maximum packet rate that will be used. This 429 value is necessary for accurate conversion of any bandwidth values if 430 the difference in overhead is known. 432 4. Problem Scope 434 The problems described in chapter 3 are common and effect application 435 level signaling using SDP, other signaling protocols, and also 436 resource reservation protocols. However this document targets the 437 specific problem of signaling the bit-rate in SDP. The problems need 438 to be considered in other affected protocols and in new protocols 439 being designed. In the MMUSIC WG there is work on a replacement of 440 SDP called SDP-NG. It is recommended that the problems outlined in 441 this document be considered when designing solutions for specifying 442 bandwidth in SDP-NG [17]. 444 As this specification only targets carrying the bit-rate information 445 within SDP it will have a limited applicability. As SDP information 446 normally is transported end-to-end by an application protocol, nodes 447 between the end-points will not have access to the bit-rate 448 information. It will normally only be the end points that are able to 449 take this information into account. An interior node will need to 450 receive the information through other means than SDP, and that is 451 outside the scope of this specification. 453 Nevertheless, the bit-rate information provided in this specification 454 is sufficient for cases such as first-hop resource reservation and 455 admission control. It does also provide information about the maximum 456 codec rate, which is independent of lower-level protocols. 458 This specification does NOT try to solve the problem of detecting 459 NATs or other middleboxes. 461 5. Requirements 463 A solution to the problems outlined in the preceding chapters and 464 with the above applicability, should meet the following requirements: 466 - The bandwidth value SHALL be given in a way such that it can be 467 calculated for all possible combinations of transport overhead. 469 6. Solution 471 6.1. Introduction 473 This chapter describes a solution for the problems outlined in this 474 document for the Application Specific (AS) bandwidth modifier. Thus 475 enabling the derivation of the required bit-rate for an application, 476 or RTP session's data and RTCP traffic. The solution is based upon 477 the definition of a new Transport Independent Application Specific 478 (TIAS) bandwidth modifier and a new SDP attribute for the maximum 479 packet rate (maxprate). 481 The CT is a session level modifier and cannot easily be dealt with. 482 To address the problems with different overhead, it is RECOMMENDED 483 that the CT value be calculated using reasonable worst case overhead. 484 An example of how to calculate a reasonable worst case overhead is: 485 Take the overhead of the largest transport protocol (using average 486 size if variable), add that to the largest IP overhead that is 487 expected to use plus the data traffic rate. Do this for every 488 individual media stream used in the conference and add them together. 490 The RR and RS modifiers [9] will be used as defined and include 491 transport overhead. The small unfairness between hosts is deemed 492 acceptable. 494 6.2. The TIAS bandwidth modifier 496 6.2.1. Usage 498 A new bandwidth modifier is defined to be used for the following 499 purposes: 501 - Resource reservation. A single bit-rate can be enough to use for 502 resource reservation. Some characteristics can be derived from the 503 stream, codec type, etc. In cases where more information is 504 needed, then another SDP parameter will be required. 506 - Maximum media codec rate. With the definition below of "TIAS" the 507 given bit-rate will mostly be from the media codec. Therefore it 508 gives a good indication on the maximum codec bit-rate required to 509 be supported by the decoder. 511 - Communication bit-rate required for the stream. The "TIAS" value 512 together with "maxprate" can be used to determine the maximum 513 communication bit-rate the stream will require. Using session 514 level values or through adding all maximum bit-rates from the 515 streams in a session together, a receiver can determine if its 516 communication resources are sufficient to handle the stream. For 517 example a modem user can determine if the session fits his modem's 518 capabilities and the established connection. 520 - Determine the RTP session bandwidth and derive the RTCP 521 bandwidth. The derived transport dependent attribute will be the 522 RTP session bandwidth in case of RTP based transport. The TIAS 523 value can also be used to determine the RTCP bandwidth to use when 524 using implicit allocation. RTP [4] specifies that if not 525 explicitly stated, additional bandwidth shall be used by RTCP 526 equal to 5% of the RTP session bandwidth. The RTCP bandwidth can 527 be explicitly allocated by using the RR and RS modifiers defined 528 in [9]. 530 6.2.2. Definition 532 A new session and media level bandwidth modifier is defined: 534 b=TIAS: ; see section 6.6 for ABNF definition. 536 The Transport Independent Application Specific Maximum (TIAS) 537 bandwidth modifier has an integer bit-rate value in bits per second. 538 A fractional bandwidth value SHALL always be rounded up to the next 539 integer. The bandwidth value is the maximum needed by the application 540 (SDP session level) or media stream (SDP media level) without 541 counting IP and other transport layers like TCP or UDP. 543 At the SDP session level, the TIAS value is the maximal amount of 544 bandwidth need when all declared media streams are used. This MAY be 545 less than the sum of all the individual media streams values. This 546 can be due to the possibility that not all streams have their maximum 547 at the same point in time. This can normally only be verified for 548 stored media streams. 550 For RTP transported media streams, TIAS at the SDP media level can be 551 used to derive the RTP "session bandwidth", defined in section 6.2 of 552 [4]. In the context of RTP transport the TIAS value is defined as: 554 Only the RTP payload as defined in [4] SHALL be used in the 555 calculation of the bit-rate, i.e., excluding the lower layers 556 (IP/UDP) and RTP headers including RTP header, RTP header 557 extensions, CSRC list and other RTP profile specific fields. Note 558 that the RTP payload includes both the payload format header and 559 the data. This may allow one to use the same value for RTP-based 560 media transport, non-RTP transport and stored media. 562 Note 1: The usage of bps is not in accordance with RFC 2327 [1]. This 563 change has no implications on the parser, only the interpreter of the 564 value must be aware. The change is done to allow for better 565 resolution, and has also been used for the RR and RS bandwidth 566 modifiers, see [9]. 568 Note 2: RTCP bandwidth is not included in the bandwidth value. In 569 applications using RTCP, the bandwidth used by RTCP is either 5% of 570 the RTP session bandwidth including lower layers or as specified by 571 the RR and RS modifiers [9]. A specification of how to derive the 572 RTCP bit-rate when using TIAS is presented in chapter 6.5. 574 6.2.3. Usage Rules 576 "TIAS" is primarily intended to be used at the SDP media level. The 577 "TIAS" bandwidth attribute MAY be present at the session level in 578 SDP, if all media streams uses the same transport. In cases when the 579 sum of the media level values for all media streams is larger than 580 the actual maximum bandwidth need for all streams, it SHOULD be 581 included at session level. However, if present at the session level 582 it SHOULD be present also at the media level. "TIAS" SHALL NOT be 583 present at the session level unless the same transport protocols is 584 used for all media streams. The same transport is used as long as the 585 same combination of protocols is used, like IPv6/UDP/RTP. 587 To allow for backwards compatibility with applications of SDP that do 588 not implement "TIAS", it is RECOMMENDED to also include the "AS" 589 modifier when using "TIAS". The presence of a value including lower- 590 layer overhead, even with its problems, is better than none. However, 591 an SDP application implementing TIAS SHOULD ignore the "AS" value and 592 use "TIAS" instead when both are present. 594 When using TIAS for an RTP-transported stream, the "maxprate" 595 attribute if possible to calculate, defined next, SHALL be included 596 at the corresponding SDP level. 598 6.3. Packet Rate parameter 600 To be able to calculate the bandwidth value including the lower 601 layers actually used, a packet rate attribute is also defined. 603 The SDP session and media level maximum packet rate attribute is 604 defined as: 606 a=maxprate: ; see section 6.6 for ABNF definition. 608 The is a floating-point value for the stream's maximum 609 packet rate in packets per second. If the number of packets is 610 variable, the given value SHALL be the maximum the application can 611 produce in case of live stream, or for stored on-demand streams, has 612 produced. The packet rate is calculated by adding together the number 613 of packets sent within a 1 second long window. The maxprate is the 614 largest value produced when the window slides over the entire media 615 stream. In cases that this can't be calculated, i.e. for example a 616 live stream, a estimated value of the maximum packet rate the codec 617 can produce for the given configuration and content SHALL be used. 619 Note: The sliding window calculation will always yield an integer 620 number, however the attributes field is a floating-point value. The 621 reason is that estimated or known maximum packet rate per second may 622 be fractional. 624 At the SDP session level, the "maxprate" value is the maximum packet 625 rate calculated over all the declared media streams. If this can't be 626 measured (stored media) or estimated (live) the sum of all media 627 level values provides a ceiling value. Note: the value at session 628 level can be less then the sum of the individual media streams due to 629 temporal distribution of media streams maximums. The "maxprate" 630 attribute MUST NOT be present at session level if the media streams 631 use different transport. The attribute MAY be present if the media 632 streams use the same transport. If the attribute is present at the 633 session level it SHOULD also be present at the media level for all 634 media streams. 636 "maxprate" SHALL be included for all transports where a packet rate 637 can be derived and TIAS is included. For example, if you use TIAS and 638 a transport like IP/UDP/RTP, for which the max packet rate (actual or 639 estimated) can be derived, then "maxprate" SHALL be included. However 640 if either (a) the packet rate for the transport cannot be derived, or 641 (b) TIAS is not included, then, "maxprate" is not required to be 642 included. 644 6.4. Converting to Transport-Dependent values 646 When converting the transport-independent bandwidth value (bw-value) 647 into a transport-dependent value including the lower layers, the 648 following MUST be done: 650 1. Determine which lower layers will be used and calculate the sum of 651 the sizes of the headers in bits (h-size). In cases of variable 652 header sizes, the average size SHALL be used. For RTP-transported 653 media, the lower layers SHALL include the RTP header with header 654 extensions, if used, the CSRC list, and any profile-specific 655 extensions. 656 2. Retrieve the maximum packet rate from the SDP (prate = maxprate). 657 3. Calculate the transport overhead by multiplying the header sizes 658 by the packet rate (t-over = h-size * prate). 659 4. Round the transport overhead up to nearest integer in bits (t-over 660 = CEIL(t-over)). 661 5. Add the transport overhead to the transport independent bandwidth 662 value (total bit-rate = bw-value + t-over) 664 When the above calculation is performed using the "maxprate", the 665 bit-rate value will be the absolute maximum the media stream may use 666 over the transport assumed in the calculations. 668 6.5. Deriving RTCP bandwidth 670 This chapter does not solve the fairness and possible bit-rate change 671 introduced by IPv4 to IPv6 translation. These differences are 672 considered small enough and known solutions introduce code changes to 673 the RTP/RTCP implementation. This chapter gives only a consistent way 674 of calculating the bit-rate to assign to RTCP if not explicitly 675 given. 677 First the transport-dependent RTP session bit-rate is calculated, in 678 accordance with chapter 6.4, using the actual transport layers used 679 at the end point where the calculation is done. The RTCP bit-rate is 680 then derived as usual based on the RTP session bandwidth, i.e., 681 normally equal to 5% of the calculated value. 683 6.5.1. Motivation for this solution 685 Giving the exact same RTCP bit-rate value to both the IPv4 and IPv6 686 hosts will result in the IPv4 host having a higher RTCP sending rate. 687 With sending rate it is meant the number of RTCP packets sent during 688 a given time interval. The sending of RTCP is limited according to 689 rules defined in the RTP specification [4]. For a 100-byte RTCP 690 packet (including UDP/IPv4), the IPv4 sender has an approximately 20% 691 higher sending rate. This rate falls with larger RTCP packets. For 692 example, 300-byte packets will only give the IPv4 host a 7% higher 693 sending rate. 695 The above rule for deriving RTCP bandwidth gives the same behavior as 696 fixed assignment when the RTP session has traffic parameters giving a 697 large TIAS/maxprate ratio. The two hosts will be fair when the 698 TIAS/maxprate ratio is approximately 40 bytes/packet given 100-byte 699 RTCP packets. For a TIAS/maxprate ratio of 5 bytes/packet, the IPv6 700 host will be allowed to send approximately 15-20% more RTCP packets. 701 The larger the RTCP packets become, the more it will favor the IPv6 702 host in sending rate. 704 The conclusions is that, within the normal useful combination of 705 transport-independent bit rates and packet rates, the difference in 706 fairness between hosts on different IP versions with different 707 overhead is acceptable. For the 20-byte difference in overhead 708 between IPv4 and IPv6 headers, the RTCP bandwidth actually used in a 709 unicast connection case will not be larger than approximately 1% of 710 the total session bandwidth. 712 6.6. ABNF definitions 714 This chapter defines in ABNF from RFC 2234 [2] the bandwidth modifier 715 and the packet rate attribute. 717 The bandwidth modifier: 719 TIAS-bandwidth-def = "b" "=" "TIAS" ":" bandwidth-value CRLF 721 bandwidth-value = 1*DIGIT 723 The maximum packet rate attribute: 725 max-p-rate-def = "a" "=" "maxprate" ":" packet-rate CRLF 727 packet-rate = 1*DIGIT ["." 1*DIGIT] 729 6.7. Example 731 v=0 732 o=Example_SERVER 3413526809 0 IN IP4 server.example.com 733 s=Example of TIAS and maxprate in use 734 c=IN IP4 0.0.0.0 735 b=AS:60 736 b=TIAS:50780 737 t=0 0 738 a=control:rtsp://server.example.com/media.3gp 739 a=range:npt=0-150.0 740 a=maxprate:28.0 741 m=audio 0 RTP/AVP 97 742 b=AS:12 743 b=TIAS:8480 744 a=maxprate:10.0 745 a=rtpmap:97 AMR/8000 746 a=fmtp:97 octet-align; 747 a=control:rtsp://server.example.com/media.3gp/trackID=1 748 m=video 0 RTP/AVP 99 749 b=AS:48 750 b=TIAS:42300 751 a=maxprate:18.0 752 a=rtpmap:99 MP4V-ES/90000 753 a=fmtp:99 profile-level-id=8; 754 config=000001B008000001B509000001010000012000884006682C2090A21F 755 a=control:rtsp://server.example.com/media.3gp/trackID=3 757 In this SDP example of a streaming session's SDP, there are two media 758 streams, one audio stream encoded with AMR and one video stream 759 encoded with the MPEG-4 Video encoder. AMR is here used to produce a 760 constant rate media stream and does use a packetization resulting in 761 10 packets per second. This results in a TIAS bandwidth rate of 8480 762 bits per second, and the claimed 10 packets per second. The video 763 stream is more variable. However it has a measured maximum payload 764 rate of 42300 bits per second. The video also has variable packet 765 rate, despite the fact that the video is 15 frames per second there 766 where at least one instance when a second long window contained 18 767 packets. 769 7. Protocol Interaction 771 7.1. RTSP 773 The "TIAS" and "maxprate" parameters can be used with RTSP as 774 currently specified. To be able to calculate the transport dependent 775 bandwidth, some of the transport header parameters will be required. 776 There should be no problem for a client to calculate the required 777 bandwidth(s) prior to an RTSP SETUP. The reason is that a client 778 supports a limited number of transport setups. The one actually 779 offered to a server in a SETUP request will be dependent on the 780 contents of the SDP description. The "m=" line(s) will signal to the 781 client the desired transport profile(s). 783 7.2. SIP 785 The usage of "TIAS" together with "maxprate" should not be different 786 from the handling of the "AS" modifier currently in use. The needed 787 transport parameters will available in the transport field in the 788 "m=" line. The address class can be determined from the "c=" field 789 and the client's connectivity. 791 7.3. SAP 793 In the case of SAP all available information to calculate the 794 transport dependent bit-rate should be present in the SDP. The "c=" 795 information gives the address family used for the multicast. The 796 transport layer, e.g. RTP/UDP, for each media is evident in the media 797 line ("m=") and its transport field. 799 8. Security Consideration 801 The bandwidth value that is supplied by the parameters defined here 802 can, if not integrity protected, be altered. By altering the 803 bandwidth value one can fool a receiver to reserve either more or 804 less bandwidth than actually needed. Reserving too much may result in 805 unwanted expenses on behalf of the user and also blocking of 806 resources that other parties could have used. If too little bandwidth 807 is reserved the receiving user's quality may be effected. Trusting a 808 too-large TIAS value may also result in the receiver rejecting the 809 session due to insufficient communication and decoding resources. 811 Due to these security risks it is strongly RECOMMENDED that the SDP 812 be integrity protected and source authenticated so no tampering can 813 be performed and the source trusted. It is also RECOMMENDED that any 814 receiver of the SDP perform an analysis of the received bandwidth 815 values to verify that they are reasonable and are what can be 816 expected for the application. For example, a single channel AMR- 817 encoded voice stream claiming to use 1000 kbps is not reasonable. 819 Please note that some of the above security requirements are in 820 conflict with what is required to make signaling protocols using SDP 821 to work through a middlebox as discussed in the security 822 considerations of RFC 3303 [18]. 824 9. IANA Considerations 826 This document registers one new SDP session and media level attribute 827 "maxprate", see section 6.3. 829 A new SDP [1] bandwidth modifier (bwtype) "TIAS" is also registered 830 in accordance with the rules requiring a standards-track RFC. The 831 modifier is defined in section 6.2. 833 10. Acknowledgments 835 The author would like to thank Gonzalo Camarillo and Hesham Soliman 836 for their work reviewing this document. A very big thanks goes to 837 Stephen Casner for reviewing and helping fixing the language and 838 finding some errors in the draft. Further thanks for suggestion to 839 improvements goes to Colin Perkins, Geetha Srikantan, and Emre Aksu. 841 The author would also like to thank all persons on the MMUSIC working 842 group's mailing list that have commented on this specification. 844 11. Author's Addresses 846 Magnus Westerlund Tel: +46 8 4048287 847 Ericsson Research Email: Magnus.Westerlund@ericsson.com 848 Ericsson AB 849 Torshamnsgatan 23 850 SE-164 80 Stockholm, SWEDEN 852 12. References 854 12.1. Normative references 856 [1] M. Handley, V. Jacobson, "Session Description Protocol (SDP)", 857 IETF RFC 2327, April 1998. 858 [2] D. Crocker and P. Overell, "Augmented BNF for syntax specifica- 859 tions: ABNF," RFC 2234, Internet Engineering Task Force, Nov. 860 1997. 861 [3] S. Bradner, "Key words for use in RFCs to Indicate Requirement 862 Levels", RFC 2119, March 1997. 863 [4] H. Schulzrinne, et. al., "RTP: A Transport Protocol for Real- 864 Time Applications", RFC 3550, Internet Engineering Task Force, 865 July 2003. 867 12.2. Informative References 869 [5] M. Handley et al., "Session Announcement Protocol", IETF RFC 870 2974, October 2000. 871 [6] J. Rosenberg, et. al., "SIP: Session Initiation Protocol", IETF 872 RFC 3261, June 2002. 874 [7] J. Rosenberg, H. Schulzrine, "An Offer/Answer Model with Session 875 Description Protocol (SDP)", IETF RFC 3164, June 2002. 876 [8] H. Schulzrinne, et. al., "Real Time Streaming Protocol (RTSP)", 877 IETF RFC 2326, April 1998. 878 [9] S. Casner, "SDP Bandwidth Modifiers for RTCP Bandwidth", IETF 879 RFC 3556, Internet Engineering Task Force, July 2003. 880 [10] M. Degermark, B. Nordgren, S. Pink, "IP Header Compression", 881 IETF RFC 2507, February 1999. 882 [11] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for Low- 883 Speed Serial Links", IETF RFC 2508, February 1999. 884 [12] C. Bormann, et. al., "RObust Header Compression (ROHC): 885 Framework and four profiles", IETF RFC 3095, July 2001. 886 [13] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) 887 Specification", RFC 2460, Internet Engineering Task Force, 888 December 1998. 889 [14] J. Postel, "Internet Protocol", RFC 791, Internet Engineering 890 Task Force, September 1981. 891 [15] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 892 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 893 Specification", RFC 2205, September 1997. 894 [16] Davie, B., et. al., "Integrated Services in the Presence of 895 Compressible Flows," RFC 3006, Internet Engineering Task Force, 896 November 2000. 897 [17] Kutscher, Ott, Bormann, "Session Description and Capability 898 Negotiation," IETF draft, work in progress, march 2003. 899 [18] P. Srisuresh, J. Kuthan, J. Rosenberg, A. Molitor, A. Rayhan, " 900 Middlebox communication architecture and framework," RFC 3303, 901 Internet Engineering Task Force, August 2002. 902 [19] S. Kent, R. Atkinson, "Security Architecture for the Internet 903 Protocol.," RFC 2401, Internet Engineering Task Force, November 904 1998. 905 [20] S. Kent, R. Atkinson., "IP Authentication Header.," RFC 2402, 906 Internet Engineering Task Force, November 1998. 907 [21] S. Kent, R. Atkinson., "IP Encapsulating Security Payload 908 (ESP).," RFC 2406, November 1998. 910 Copyright Statement 912 Copyright (C) The Internet Society (2004). This document is subject 913 to the rights, licenses and restrictions contained in BCP 78, and 914 except as set forth therein, the authors retain all their rights. 916 Disclaimer of Validity 918 This document and the information contained herein are provided on an 919 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 920 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 921 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 922 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 923 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 924 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 926 Changes 928 [Note to RFC Editor: Remove this section when publishing] 930 The following changes have been done to this version compared to 931 draft-ietf-mmusic-sdp-bwparam-05.txt 933 - Removed any explicit naming of a translation mechanism. 934 - Updated the ID boilerplate in accordance with RFC 3367, and RFC 935 3668. 936 - Clarified that there exist further mechanisms that effect the 937 lower layers, like IPSec. 938 - Added a problem conclusion section. 940 This Internet-Draft expires in October 2004.