diff options
Diffstat (limited to 'doc/rfc/rfc3890.txt')
| -rw-r--r-- | doc/rfc/rfc3890.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc3890.txt b/doc/rfc/rfc3890.txt new file mode 100644 index 0000000..ce05170 --- /dev/null +++ b/doc/rfc/rfc3890.txt @@ -0,0 +1,1235 @@ + + + + + + +Network Working Group M. Westerlund +Request for Comments: 3890 Ericsson +Category: Standards Track September 2004 + + + A Transport Independent Bandwidth Modifier + for the Session Description Protocol (SDP) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document defines a Session Description Protocol (SDP) Transport + Independent Application Specific Maximum (TIAS) bandwidth modifier + that does not include transport overhead; instead an additional + packet rate attribute is defined. The transport independent bit-rate + value together with the maximum packet rate can then be used to + calculate the real bit-rate over the transport actually used. + + The existing SDP bandwidth modifiers and their values include the + bandwidth needed for the transport and IP layers. When using SDP + with protocols like the Session Announcement Protocol (SAP), the + Session Initiation Protocol (SIP), and the Real-Time Streaming + Protocol (RTSP), and when the involved hosts has different transport + overhead, for example due to different IP versions, the + interpretation of what lower layer bandwidths are included is not + clear. + + + + + + + + + + + + + + +Westerlund Standards Track [Page 1] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. The Bandwidth Attribute. . . . . . . . . . . . . . . . . 3 + 1.1.1. Conference Total . . . . . . . . . . . . . . . . 3 + 1.1.2. Application Specific Maximum . . . . . . . . . . 3 + 1.1.3. RTCP Report Bandwidth. . . . . . . . . . . . . . 4 + 1.2. IPv6 and IPv4. . . . . . . . . . . . . . . . . . . . . . 4 + 1.3. Further Mechanisms that Change the Bandwidth + Utilization. . . . . . . . . . . . . . . . . . . . . . . 5 + 1.3.1. IPsec. . . . . . . . . . . . . . . . . . . . . . 5 + 1.3.2. Header Compression . . . . . . . . . . . . . . . 5 + 2. Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 6 + 3. The Bandwidth Signaling Problems . . . . . . . . . . . . . . . 6 + 3.1. What IP Version is Used. . . . . . . . . . . . . . . . . 6 + 3.2. Taking Other Mechanisms into Account . . . . . . . . . . 7 + 3.3. Converting Bandwidth Values. . . . . . . . . . . . . . . 8 + 3.4. RTCP Problems. . . . . . . . . . . . . . . . . . . . . . 8 + 3.5. Future Development . . . . . . . . . . . . . . . . . . . 9 + 3.6. Problem Conclusion . . . . . . . . . . . . . . . . . . . 9 + 4. Problem Scope. . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 6. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 11 + 6.2. The TIAS Bandwidth Modifier. . . . . . . . . . . . . . . 11 + 6.2.1. Usage. . . . . . . . . . . . . . . . . . . . . . 11 + 6.2.2. Definition . . . . . . . . . . . . . . . . . . . 12 + 6.2.3. Usage Rules. . . . . . . . . . . . . . . . . . . 13 + 6.3. Packet Rate Parameter. . . . . . . . . . . . . . . . . . 13 + 6.4. Converting to Transport-Dependent Values . . . . . . . . 14 + 6.5. Deriving RTCP bandwidth. . . . . . . . . . . . . . . . . 15 + 6.5.1. Motivation for this Solution. . . . . . . . . . . 15 + 6.6. ABNF Definitions . . . . . . . . . . . . . . . . . . . . 16 + 6.7. Example. . . . . . . . . . . . . . . . . . . . . . . . . 16 + 7. Protocol Interaction . . . . . . . . . . . . . . . . . . . . . 17 + 7.1. RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 7.2. SIP. . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 7.3. SAP. . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 18 + 9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 18 + 10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 19 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 + 11.2. Informative References . . . . . . . . . . . . . . . . . 19 + 12. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 + 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22 + + + +Westerlund Standards Track [Page 2] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + +1. Introduction + + This specification is structured in the following way: In this + section, some information regarding SDP bandwidth modifiers, and + different mechanisms that affect transport overhead are asserted. In + section 3, the problems found are described, including problems that + are not solved by this specification. In section 4 the scope of the + problems this specification solves is presented. Section 5 contains + the requirements applicable to the problem scope. Section 6 defines + the solution, which is a new bandwidth modifier, and a new maximum + packet rate attribute. Section 7 looks at the protocol interaction + for SIP, RTSP, and SAP. The security considerations are discussed in + section 8. The remaining sections are the necessary IANA + considerations, acknowledgements, reference list, author's address, + and copyright and IPR notices. + + Today the Session Description Protocol (SDP) [1] is used in several + types of applications. The original application is session + information and configuration for multicast sessions announced with + Session Announcement Protocol (SAP) [5]. SDP is also a vital + component in media negotiation for the Session Initiation Protocol + (SIP) [6] by using the offer answer model [7]. The Real-Time + Streaming Protocol (RTSP) [8] also makes use of SDP to declare to the + client what media and codec(s) comprise a multi-media presentation. + +1.1. The Bandwidth Attribute + + In SDP [1] there exists a bandwidth attribute, which has a modifier + used to specify what type of bit-rate the value refers to. The + attribute has the following form: + + b=<modifier>:<value> + + Today there are four defined modifiers used for different purposes. + +1.1.1. Conference Total + + The Conference Total is indicated by giving the modifier "CT". + Conference total gives a maximum bandwidth that a conference session + will use. Its purpose is to decide if this session can co-exist with + any other sessions, defined in RFC 2327 [1]. + +1.1.2. Application Specific Maximum + + The Application Specific maximum bandwidth is indicated by the + modifier "AS". The interpretation of this attribute is dependent on + the application's notion of maximum bandwidth. For an RTP + application, this attribute is the RTP session bandwidth as defined + + + +Westerlund Standards Track [Page 3] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + + in RFC 3550 [4]. The session bandwidth includes the bandwidth that + the RTP data traffic will consume, including the lower layers, down + to the IP layer. Therefore, the bandwidth is in most cases + calculated over RTP payload, RTP header, UDP, and IP, defined in RFC + 2327 [1]. + +1.1.3. RTCP Report Bandwidth + + In RFC 3556 [9], two bandwidth modifiers are defined. These + modifiers, "RS" and "RR", define the amount of bandwidth that is + assigned for RTCP reports by active data senders and RTCP reports by + other participants (receivers), respectively. + +1.2. IPv6 and IPv4 + + Today there are two IP versions, 4 [14] and 6 [13], used in parallel + on the Internet, creating problems. However, there exist a number of + possible transition mechanisms. + + - The nodes which wish to communicate must share the IP version; + typically this is done by deploying dual-stack nodes. For + example, an IPv4 only host cannot communicate with an IPv6 only + host. + + - If communication between nodes which do not share a protocol + version is required, use of a translation or proxying mechanism + would be required. Work is underway to specify such a mechanism + for this purpose. + + ------------------ ---------------------- + | IPv4 domain | | IPv6 Domain | + | | ------------- | | + | ---------- |-|Translator |-| ---------- | + | |Server A| | | or proxy | | |Client B| | + | ---------- | ------------- | ---------- | + ------------------ ---------------------- + + Figure 1. Translation or proxying between IPv6 and IPv4 addresses. + + - IPv6 nodes belonging to different domains running IPv6, but + lacking IPv6 connectivity between them, solve this by tunneling + over the IPv4 net, see Figure 2. Basically, the IPv6 packets are + sent as payload in IPv4 packets between the tunneling end-points + at the edge of each IPv6 domain. The bandwidth required over the + IPv4 domain will be different from IPv6 domains. However, as the + tunneling is normally not performed by the application end-point, + this scenario can not usually be taken into consideration. + + + + +Westerlund Standards Track [Page 4] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + + --------------- --------------- --------------- + | IPv6 domain | | IPv4 domain | | IPv6 Domain | + | | |-------------| | | + | ---------- |--||Tunnel ||--| ---------- | + | |Server A| | |-------------| | |Client B| | + | ---------- | | | | ---------- | + --------------- --------------- --------------| + + Figure 2. Tunneling through a IPv4 domain + + IPv4 has a minimum header size of 20 bytes, while the fixed part of + the IPv6 header is 40 bytes. + + The difference in header sizes means that the bit-rate required for + the two IP versions is different. The significance of the difference + depends on the packet rate and payload size of each packet. + +1.3. Further Mechanisms that Change the Bandwidth Utilization + + There exist a number of other mechanisms that also may change the + overhead at layers below media transport. We will briefly cover a + few of these here. + +1.3.1. IPsec + + IPsec [19] can be used between end points to provide confidentiality + through the application of the IP Encapsulating Security Payload + (ESP) [21] or integrity protection using the IP Authentication Header + (AH) [20] of the media stream. The addition of the ESP and AH + headers increases each packet's size. + + To provide virtual private networks, complete IP packets may be + encapsulated between an end node and the private networks security + gateway, thus providing a secure tunnel that ensures confidentiality, + integrity, and authentication of the packet stream. In this case, + the extra IP and ESP header will significantly increase the packet + size. + +1.3.2. Header Compression + + Another mechanism that alters the actual overhead over links is + header compression. Header compression uses the fact that most + network protocol headers have either static or predictable values in + their fields within a packet stream. Compression is normally only + done on a per hop basis, i.e., on a single link. The normal reason + for doing header compression is that the link has fairly limited + bandwidth and significant gain in throughput is achieved. + + + + +Westerlund Standards Track [Page 5] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + + There exist several different header compression standards. For + compressing IP headers only, there is RFC 2507 [10]. For compressing + packets with IP/UDP/RTP headers, CRTP [11] was created at the same + time. More recently, the Robust Header Compression (ROHC) working + group has been developing a framework and profiles [12] for + compressing certain combinations of protocols, like IP/UDP, and + IP/UDP/RTP. + +2. Definitions + +2.1. Glossary + + ALG - Application Level Gateway. + bps - bits per second. + RTSP - Real-Time Streaming Protocol, see [8]. + SDP - Session Description Protocol, see [1]. + SAP - Session Announcement Protocol, see [5]. + SIP - Session Initiation Protocol, see [6]. + TIAS - Transport Independent Application Specific maximum, a + bandwidth modifier. + +2.2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14, RFC 2119 [3]. + +3. The Bandwidth Signaling Problems + + When an application wants to use SDP to signal the bandwidth required + for this application, some problems become evident due to the + inclusion of the lower layers in the bandwidth values. + +3.1. What IP Version is Used + + If one signals the bandwidth in SDP, for example, using "b=AS:" as an + RTP based application, one cannot know if the overhead is calculated + for IPv4 or IPv6. An indication of which protocol has been used when + calculating the bandwidth values is given by the "c=" connection + address line. This line contains either a multicast group address or + a unicast address of the data source or sink. The "c=" line's + address type may be assumed to be of the same type as the one used in + the bandwidth calculation, although no document specifying this point + seems to exist. + + In cases of SDP transported by RTSP, this is even less clear. The + normal usage for a unicast on-demand streaming session is to set the + connection data address to a null address. This null address does + + + +Westerlund Standards Track [Page 6] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + + have an address type, which could be used as an indication. However, + this is also not clarified anywhere. + + Figure 1, illustrates a connection scenario between a streaming + server A and a client B over a translator. When B receives the SDP + from A over RTSP, it will be very difficult for B to know what the + bandwidth values in the SDP represent. The following possibilities + exist: + + 1. The SDP is unchanged and the "c=" null address is of type IPv4. + The bandwidth value represents the bandwidth needed in an IPv4 + network. + + 2. The SDP has been changed by an Application Level Gateway (ALG). + The "c=" address is changed to an IPv6 type. The bandwidth value + is unchanged. + + 3. The SDP is changed and both "c=" address type and bandwidth value + is converted. Unfortunately, this can seldom be done, see 3.3. + + In case 1, the client can understand that the server is located in an + IPv4 network and that it uses IPv4 overhead when calculating the + bandwidth value. The client can almost never convert the bandwidth + value, see section 3.3. + + In case 2, the client does not know that the server is in an IPv4 + network and that the bandwidth value is not calculated with IPv6 + overhead. In cases where a client uses this value to determine if + its end of the network has sufficient resources the client will + underestimate the required bit-rate, potentially resulting in bad + application performance. + + In case 3, everything works correctly. However, this case will be + very rare. If one tries to convert the bandwidth value without + further information about the packet rate, significant errors may be + introduced into the value. + +3.2. Taking Other Mechanisms into Account + + Section 1.2 and 1.3 lists a number of reasons, like header + compression and tunnels, that would change lower layer header sizes. + For these mechanisms there exist different possibilities to take them + into account. + + + + + + + + +Westerlund Standards Track [Page 7] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + + Using IPsec directly between end-points should definitely be known to + the application, thus enabling it to take the extra headers into + account. However the same problem also exists with the current SDP + bandwidth modifiers where a receiver is not able to convert these + values taking the IPsec headers into account. + + It is less likely that an application would be aware of the existence + of a virtual private network. Thus the generality of the mechanism + to tunnel all traffic may prevent the application from even + considering whether it would be possible to convert the values. + + When using header compression, the actual overhead will be less + deterministic, but in most cases an average overhead can be + determined for a certain application. If a network node knows that + some type of header compression is employed, this can be taken into + consideration. For RSVP [15], there exists an extension, RFC 3006 + [16], that allows the data sender to inform network nodes about the + compressibility of the data flow. To be able to do this with any + accuracy, the compression factor and packet rate or size is needed, + as RFC 3006 provides. + +3.3. Converting Bandwidth Values + + If one would like to convert a bandwidth value calculated using IPv4 + overhead to IPv6 overhead, the packet rate is required. The new + bandwidth value for IPv6 is normally "IPv4 bandwidth" + "packet rate" + * 20 bytes, where 20 bytes is the usual difference between IPv6 and + IPv4 headers. The overhead difference may be some other value in + cases when IPv4 options [14] or IPv6 extension headers [13] are used. + + As converting requires the packet rate of the stream, this is not + possible in the general case. Many codecs have either multiple + possible packet/frame rates or can perform payload format + aggregation, resulting in many possible rates. Therefore, some extra + information in the SDP will be required. The "a=ptime:" parameter + may be a possible candidate. However, this parameter is normally + only used for audio codecs. Its definition [1] is that it is only a + recommendation, which the sender may disregard. A better parameter + is needed. + +3.4. RTCP Problems + + When RTCP is used between hosts in IPv4 and IPv6 networks over + translator, similar problems exist. The RTCP traffic going from the + IPv4 domain will result in a higher RTCP bit-rate than intended in + the IPv6 domain due to the larger headers. This may result in up to + a 25% increase in required bandwidth for the RTCP traffic. The + largest increase will be for small RTCP packets when the number of + + + +Westerlund Standards Track [Page 8] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + + IPv4 hosts is much larger than the number of IPv6 hosts. + Fortunately, as RTCP has a limited bandwidth compared to RTP, it will + only result in a maximum of 1.75% increase of the total session + bandwidth when RTCP bandwidth is 5% of RTP bandwidth. The RTCP + randomization may easily result in short term effects of the same + magnitude, so this increase may be considered tolerable. The + increase in bandwidth will in most cases be less. + + At the same time, this results in unfairness in the reporting between + an IPv4 and IPv6 node. In the worst case scenario, the IPv6 node may + report with 25% longer intervals. + + These problems have been considered insignificant enough to not be + worth any complex solutions. Therefore, only a simple algorithm for + deriving RTCP bandwidth is defined in this specification. + +3.5. Future Development + + Today there is work in the IETF to design a new datagram transport + protocol suitable for real-time media. This protocol is called the + Datagram Congestion Control Protocol (DCCP). It will most probably + have a different header size than UDP, which is the protocol most + often used for real-time media today. This results in even more + possible transport combinations. This may become a problem if one + has the possibility of using different protocols, which will not be + determined prior to actual protocol SETUP. Thus, pre-calculating + this value will not be possible, which is one further motivation why + a transport independent bandwidth modifier is needed. + + DCCP's congestion control algorithms will control how much bandwidth + can really be utilized. This may require further work with + specifying SDP bandwidth modifiers to declare the dynamic + possibilities of an application's media stream. For example, min and + max media bandwidth the application is capable of producing at all, + or for media codecs only capable of producing certain bit-rates, + enumerating possible rates. However, this is for future study and + outside the scope of the present solution. + +3.6. Problem Conclusion + + A shortcoming of the current SDP bandwidth modifiers is that they + also include the bandwidth needed for lower layers. It is in many + cases difficult to determine which lower layers and their versions + were included in the calculation, especially in the presence of + translation or proxying between different domains. This prevents a + receiver from determining if given bandwidth needs to be converted + based on the actual lower layers being used. + + + + +Westerlund Standards Track [Page 9] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + + Secondly, an attribute to give the receiver an explicit determination + of the maximum packet rate that will be used does not exist. This + value is necessary for accurate conversion of any bandwidth values if + the difference in overhead is known. + +4. Problem Scope + + The problems described in section 3 are common and effect application + level signaling using SDP, other signaling protocols, and also + resource reservation protocols. However, this document targets the + specific problem of signaling the bit-rate in SDP. The problems need + to be considered in other affected protocols and in new protocols + being designed. In the MMUSIC WG there is work on a replacement of + SDP called SDP-NG. It is recommended that the problems outlined in + this document be considered when designing solutions for specifying + bandwidth in the SDP-NG [17]. + + As this specification only targets carrying the bit-rate information + within SDP, it will have a limited applicability. As SDP information + is normally transported end-to-end by an application protocol, nodes + between the end-points will not have access to the bit-rate + information. It will normally only be the end points that are able + to take this information into account. An interior node will need to + receive the information through a means other than SDP, and that is + outside the scope of this specification. + + Nevertheless, the bit-rate information provided in this specification + is sufficient for cases such as first-hop resource reservation and + admission control. It 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 + + The problems outlined in the preceding sections and with the above + applicability, should meet the following requirements: + + - The bandwidth value SHALL be given in a way such that it can be + calculated for all possible combinations of transport overhead. + + + + + + + + + + +Westerlund Standards Track [Page 10] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + +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 for 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 for use as + a resource reservation. Some characteristics can be derived from + the stream, codec type, etc. In cases where more information is + needed, 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 of 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 by adding all maximum bit-rates from the streams + in a session together, a receiver can determine if its + communication resources are sufficient to handle the stream. For + + + +Westerlund Standards Track [Page 11] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + + 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, equal to 5% of the RTP session bandwidth, + shall be used by RTCP. The RTCP bandwidth can be explicitly + allocated by using the RR and RS modifiers defined in [9]. + +6.2.2. Definition + + A new session and media level bandwidth modifier is defined: + + b=TIAS:<bandwidth-value> ; see section 6.6 for ABNF definition. + + The Transport Independent Application Specific Maximum (TIAS) + bandwidth modifier has an integer bit-rate value in bits per second. + A fractional bandwidth value SHALL always be rounded up to the next + integer. The bandwidth value is the maximum needed by the + application (SDP session level) or media stream (SDP media level) + without counting IP or other transport layers like TCP or UDP. + + At the SDP session level, the TIAS value is the maximal amount of + bandwidth needed when all declared media streams are used. This MAY + be less than the sum of all the individual media streams values. + This is 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. + + + + + + + + +Westerlund Standards Track [Page 12] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + + Note 1: The usage of bps is not in accordance with RFC 2327 [1]. + This change has no implications on the parser, only the interpreter + of the value must be aware. The change is done to allow for better + resolution, and has also been used for the RR and RS bandwidth + modifiers, see [9]. + + Note 2: RTCP bandwidth is not included in the bandwidth value. In + applications using RTCP, the bandwidth used by RTCP is either 5% of + the RTP session bandwidth including lower layers or as specified by + the RR and RS modifiers [9]. A specification of how to derive the + RTCP bit-rate when using TIAS is presented in chapter 6.5. + +6.2.3. Usage Rules + + "TIAS" is primarily intended to be used at the SDP media level. The + "TIAS" bandwidth attribute MAY be present at the session level in + SDP, if all media streams use the same transport. In cases where 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:<packet-rate> ; see section 6.6 for ABNF definition. + + + + + + +Westerlund Standards Track [Page 13] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + + The <packet-rate> is a floating-point value for the stream's maximum + packet rate in packets per second. If the number of packets is + variable, the given value SHALL be the maximum the application can + produce in case of a live stream, or for stored on-demand streams, + has produced. The packet rate is calculated by adding the number of + packets sent within a 1 second 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., a live stream, a + estimated value of the maximum packet rate the codec can produce for + the given configuration and content SHALL be used. + + Note: The sliding window calculation will always yield an integer + number. However the attributes field is a floating-point value + because the 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 stream's maximums. The "maxprate" + attribute MUST NOT be present at the 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. + + + +Westerlund Standards Track [Page 14] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + + 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. + +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 section provides 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 section 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. + The sending rate represents 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. + + + +Westerlund Standards Track [Page 15] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + + The larger the RTCP packets become, the more it will favor the IPv6 + host in its sending rate. + + The conclusions is that, within the normal useful combination of + transport-independent bit rates and packet rates, the difference in + fairness between hosts on different IP versions with different + overhead is acceptable. For the 20-byte difference in overhead + between IPv4 and IPv6 headers, the RTCP bandwidth actually used in a + unicast connection case will not be larger than approximately 1% of + the total session bandwidth. + +6.6. ABNF Definitions + + This chapter defines in ABNF from RFC 2234 [2] the bandwidth modifier + and the packet rate attribute. + + The bandwidth modifier: + + TIAS-bandwidth-def = "b" "=" "TIAS" ":" bandwidth-value CRLF + + bandwidth-value = 1*DIGIT + + 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 + + + +Westerlund Standards Track [Page 16] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + + 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 used here to produce a + constant rate media stream and uses 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 42,300 bits per second. The video stream also has a variable + packet rate, despite the fact that the video is 15 frames per second, + where at least one instance in a second long window contains 18 + packets. + +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 the + desired transport profile(s) to the client. + +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 be available in the transport field in the + "m=" line. The address class can be determined from the "c=" field + and the client's connectivity. + + + + + + + + + + +Westerlund Standards Track [Page 17] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + +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 be altered, if not integrity protected. By altering the + bandwidth value, one can fool a receiver into reserving either more + or less bandwidth than actually needed. Reserving too much may + result in unwanted expenses on behalf of the user, while also + blocking 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 tampering can not + be performed, and the source can be 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 expected values + for the application. For example, a single channel AMR-encoded voice + stream claiming to use 1000 kbps is not reasonable. + + Please note that some of the above security requirements are in + conflict with that required to make signaling protocols using SDP + work through a middlebox, as discussed in the security considerations + of RFC 3303 [18]. + +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. + + + + + + + + + +Westerlund Standards Track [Page 18] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + +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 fix the language, and + identifying some errors in the previous versions. Further thanks for + suggestion to improvements go 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. References + +11.1. Normative References + + [1] Handley, M. and V. Jacobson, "SDP: Session Description + Protocol", RFC 2327, April 1998. + + [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, + "RTP: A Transport Protocol for Real-Time Applications", STD 64, + RFC 3550, July 2003. + +11.2. Informative References + + [5] Handley, M., Perkins, C., and E. Whelan, "Session Announcement + Protocol", RFC 2974, October 2000. + + [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: + Session Initiation Protocol", RFC 3261, June 2002. + + [7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with + Session Description Protocol (SDP)", RFC 3264, June 2002. + + [8] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming + Protocol (RTSP)", RFC 2326, April 1998. + + [9] Casner, S., "Session Description Protocol (SDP) Bandwidth + Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, + July 2003. + + + + +Westerlund Standards Track [Page 19] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + + [10] Degermark, M., Nordgren, B., and S. Pink, "IP Header + Compression", RFC 2507, February 1999. + + [11] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for + Low-Speed Serial Links", RFC 2508, February 1999. + + [12] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., + Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, + Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., + Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): + Framework and four profiles: RTP, UDP, ESP, and uncompressed ", + RFC 3095, July 2001. + + [13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460, December 1998. + + [14] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. + + [15] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, + "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional + Specification", RFC 2205, September 1997. + + [16] Davie, B., Iturralde, C., Oran, D., Casner, S., and J. + Wroclawski, "Integrated Services in the Presence of Compressible + Flows", RFC 3006, November 2000. + + [17] Kutscher, Ott, Bormann, "Session Description and Capability + Negotiation," Work in Progress, March 2003. + + [18] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. + Rayhan, "Middlebox communication architecture and framework", + RFC 3303, August 2002. + + [19] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [20] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, + November 1998. + + [21] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload + (ESP)", RFC 2406, November 1998. + + + + + + + + + + +Westerlund Standards Track [Page 20] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + +12. Author's Address + + Magnus Westerlund + Ericsson Research + Ericsson AB + Torshamnsgatan 23 + SE-164 80 Stockholm, SWEDEN + + Phone: +46 8 7190000 + EMail: Magnus.Westerlund@ericsson.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Westerlund Standards Track [Page 21] + +RFC 3890 Bandwidth Modifier for SDP September 2004 + + +13. Full Copyright Statement + + Copyright (C) The Internet Society (2004). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights 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; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Westerlund Standards Track [Page 22] + |