idnits 2.17.1 draft-ietf-avt-rapid-acquisition-for-rtp-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 594 has weird spacing: '...| Burst and |...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 29, 2010) is 5078 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) == Missing Reference: 'RFCXXXX' is mentioned on line 2111, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) == Outdated reference: A later version (-13) exists of draft-ietf-avt-rapid-rtp-sync-10 -- Possible downref: Normative reference to a draft: ref. 'I-D.begen-avt-rtcp-port-for-ssm' == Outdated reference: A later version (-11) exists of draft-ietf-avt-ports-for-ucast-mcast-rtp-02 ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-01) exists of draft-begen-avt-rams-scenarios-00 == Outdated reference: A later version (-03) exists of draft-ietf-avt-ecn-for-rtp-01 == Outdated reference: A later version (-03) exists of draft-ietf-avt-srtp-ekt-00 Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT B. VerSteeg 3 Internet-Draft A. Begen 4 Intended status: Standards Track Cisco 5 Expires: November 30, 2010 T. VanCaenegem 6 Alcatel-Lucent 7 Z. Vax 8 Microsoft Corporation 9 May 29, 2010 11 Unicast-Based Rapid Acquisition of Multicast RTP Sessions 12 draft-ietf-avt-rapid-acquisition-for-rtp-10 14 Abstract 16 When an RTP receiver joins a multicast session, it may need to 17 acquire and parse certain Reference Information before it can process 18 any data sent in the multicast session. Depending on the join time, 19 length of the Reference Information repetition (or appearance) 20 interval, size of the Reference Information as well as the 21 application and transport properties, the time lag before an RTP 22 receiver can usefully consume the multicast data, which we refer to 23 as the Acquisition Delay, varies and can be large. This is an 24 undesirable phenomenon for receivers that frequently switch among 25 different multicast sessions, such as video broadcasts. 27 In this document, we describe a method using the existing RTP and 28 RTCP protocol machinery that reduces the acquisition delay. In this 29 method, an auxiliary unicast RTP session carrying the Reference 30 Information to the receiver precedes/accompanies the multicast 31 stream. This unicast RTP flow can be transmitted at a faster than 32 natural bitrate to further accelerate the acquisition. The 33 motivating use case for this capability is multicast applications 34 that carry real-time compressed audio and video. However, the 35 proposed method can also be used in other types of multicast 36 applications where the acquisition delay is long enough to be a 37 problem. 39 Status of this Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on November 30, 2010. 56 Copyright Notice 58 Copyright (c) 2010 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 This document may contain material from IETF Documents or IETF 72 Contributions published or made publicly available before November 73 10, 2008. The person(s) controlling the copyright in some of this 74 material may not have granted the IETF Trust the right to allow 75 modifications of such material outside the IETF Standards Process. 76 Without obtaining an adequate license from the person(s) controlling 77 the copyright in such materials, this document may not be modified 78 outside the IETF Standards Process, and derivative works of it may 79 not be created outside the IETF Standards Process, except to format 80 it for publication as an RFC or to translate it into languages other 81 than English. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 86 1.1. Acquisition of RTP Streams vs. RTP Sessions . . . . . . . 6 87 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 7 88 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7 89 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 90 4. Elements of Delay in Multicast Applications . . . . . . . . . 9 91 5. Protocol Design Considerations and Their Effect on 92 Resource Management for Rapid Acquisition . . . . . . . . . . 10 93 6. Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . 12 94 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13 96 6.3. Synchronization of Primary Multicast Streams . . . . . . . 23 97 6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 23 98 6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 26 99 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 27 100 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 28 101 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 29 102 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 29 103 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 30 104 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 32 105 7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 35 106 8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 36 107 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 36 108 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 36 109 8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 37 110 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 40 111 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 112 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 113 11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 43 114 11.2. Registration of SDP Attribute Values . . . . . . . . . . . 43 115 11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 44 116 11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 44 117 11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 45 118 11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 46 119 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48 120 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 121 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 122 14.1. Normative References . . . . . . . . . . . . . . . . . . . 48 123 14.2. Informative References . . . . . . . . . . . . . . . . . . 50 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 126 1. Introduction 128 Most multicast flows carry a stream of inter-related data. Certain 129 information must first be acquired by the receivers to start 130 processing any data sent in the multicast session. This document 131 refers to this information as Reference Information. The Reference 132 Information is conventionally sent periodically in the multicast 133 session (although its content can change over time) and usually 134 consists of items such as a description of the schema for the rest of 135 the data, references to which data to process, encryption information 136 including keys, as well as any other information required to process 137 the data in the multicast stream [IC2009]. 139 Real-time multicast applications require the receivers to buffer 140 data. The receiver may have to buffer data to smooth out the network 141 jitter, to allow loss-repair methods such as Forward Error Correction 142 and retransmission to recover the missing packets, and to satisfy the 143 data processing requirements of the application layer. 145 When a receiver joins a multicast session, it has no control over 146 what point in the flow is currently being transmitted. Sometimes the 147 receiver might join the session right before the Reference 148 Information is sent in the session. In this case, the required 149 waiting time is usually minimal. Other times, the receiver might 150 join the session right after the Reference Information has been 151 transmitted. In this case, the receiver has to wait for the 152 Reference Information to appear again in the flow before it can start 153 processing any multicast data. In some other cases, the Reference 154 Information is not contiguous in the flow but dispersed over a large 155 period, which forces the receiver to wait for all of the Reference 156 Information to arrive before starting to process the rest of the 157 data. 159 The net effect of waiting for the Reference Information and waiting 160 for various buffers to fill up is that the receivers can experience 161 significantly large delays in data processing. In this document, we 162 refer to the difference between the time an RTP receiver joins the 163 multicast session and the time the RTP receiver acquires all the 164 necessary Reference Information as the Acquisition Delay. The 165 acquisition delay might not be the same for different receivers; it 166 usually varies depending on the join time, length of the Reference 167 Information repetition (or appearance) interval, size of the 168 Reference Information as well as the application and transport 169 properties. 171 The varying nature of the acquisition delay adversely affects the 172 receivers that frequently switch among multicast sessions. In this 173 specification, we address this problem for RTP-based multicast 174 applications and describe a method that uses the fundamental tools 175 offered by the existing RTP and RTCP protocols [RFC3550]. In this 176 method, either the multicast source (or the distribution source in a 177 source-specific multicast (SSM) session) retains the Reference 178 Information for a period after its transmission, or an intermediary 179 network element (that we refer to as Retransmission Server) joins the 180 multicast session and continuously caches the Reference Information 181 as it is sent in the session and acts as a feedback target (See 182 [RFC5760]) for the session. When an RTP receiver wishes to join the 183 same multicast session, instead of simply issuing a Source Filtering 184 Group Management Protocol (SFGMP) Join message, it sends a request to 185 the feedback target for the session and asks for the Reference 186 Information. The retransmission server starts a new unicast RTP 187 (retransmission) session and sends the Reference Information to the 188 RTP receiver over that session. If there is spare bandwidth, the 189 retransmission server might burst the Reference Information faster 190 than its natural rate. As soon as the receiver acquires the 191 Reference Information, it can join the multicast session and start 192 processing the multicast data. A simplified network diagram showing 193 this method through an intermediary network element is depicted in 194 Figure 1. 196 This method potentially reduces the acquisition delay. We refer to 197 this method as Unicast-based Rapid Acquisition of Multicast RTP 198 Sessions. A primary use case for this method is to reduce the 199 channel-change times in IPTV networks where compressed video streams 200 are multicast in different SSM sessions and viewers randomly join 201 these sessions. 203 ----------------------- 204 +--->| Intermediary | 205 | | Network Element | 206 | ...|(Retransmission Server)| 207 | : ----------------------- 208 | : 209 | v 210 ----------- ---------- ---------- 211 | Multicast | | |---------->| Joining | 212 | Source |------->| Router |..........>| RTP | 213 | | | | | Receiver | 214 ----------- ---------- ---------- 215 | 216 | ---------- 217 +---------------->| Existing | 218 | RTP | 219 | Receiver | 220 ---------- 222 -------> Multicast RTP Flow 223 .......> Unicast RTP Flow 225 Figure 1: Rapid acquisition through an intermediary network element 227 A principle design goal in this solution is to use the existing tools 228 in the RTP/RTCP protocol family. This improves the versatility of 229 the existing implementations, and promotes faster deployment and 230 better interoperability. To this effect, we use the unicast 231 retransmission support of RTP [RFC4588] and the capabilities of RTCP 232 to handle the signaling needed to accomplish the acquisition. 234 1.1. Acquisition of RTP Streams vs. RTP Sessions 236 In this memo we describe a protocol that handles the rapid 237 acquisition of a single multicast RTP session (called primary 238 multicast RTP session) carrying one or more RTP streams (called 239 primary multicast streams). If desired, multiple instances of this 240 protocol may be run in parallel to acquire multiple RTP sessions 241 simultaneously. 243 When an RTP receiver requests the Reference Information from the 244 retransmission server, it can opt to rapidly acquire a specific 245 subset of the available RTP streams in the primary multicast RTP 246 session. Alternatively, it can request the rapid acquisition of all 247 of the RTP streams in that RTP session. Regardless of how many RTP 248 streams are requested by the RTP receiver or how many will be 249 actually sent by the retransmission server, only one unicast RTP 250 session will be established by the retransmission server. This 251 unicast RTP session is separate from the associated primary multicast 252 RTP session. As a result, there are always two different RTP 253 sessions in a single instance of the rapid acquisition protocol: (i) 254 the primary multicast RTP session with its associated unicast 255 feedback and (ii) the unicast RTP session. 257 If the RTP receiver wants to rapidly acquire multiple RTP sessions 258 simultaneously, separate unicast RTP sessions will be established for 259 each of them. 261 1.2. Outline 263 In the rest of this specification, we have the following outline: In 264 Section 4, we describe the delay components in generic multicast 265 applications. Section 5 presents an overview of the protocol design 266 considerations for rapid acquisition. We provide the protocol 267 details of the rapid acquisition method in Section 6 and Section 7. 268 Section 8 and Section 9 discuss the SDP signaling issues with 269 examples and NAT-related issues, respectively. Finally, Section 10 270 discusses the security considerations. 272 Section 3 provides a list of the definitions frequently used in this 273 document. 275 2. Requirements Notation 277 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 278 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 279 document are to be interpreted as described in [RFC2119]. 281 3. Definitions 283 This document uses the following acronyms and definitions frequently: 285 (Primary) SSM (or Multicast) Session: The multicast session to which 286 RTP receivers can join at a random point in time. A primary SSM 287 session can carry multiple RTP streams. 289 Primary Multicast RTP Session: The multicast RTP session an RTP 290 receiver is interested in acquiring rapidly. From the RTP receiver's 291 viewpoint, the primary multicast RTP session has one associated 292 unicast RTCP feedback stream to a Feedback Target, in addition to the 293 primary multicast RTP stream(s). 295 Primary Multicast (RTP) Streams: The RTP stream(s) carried in the 296 primary multicast RTP session. 298 Source Filtering Group Management Protocol (SFGMP): Following the 299 definition in [RFC4604], SFGMP refers to the Internet Group 300 Management Protocol (IGMP) version 3 [RFC3376] and the Multicast 301 Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and 302 IPv6 networks, respectively. However, the rapid acquisition method 303 introduced in this document does not depend on a specific version of 304 either of these group management protocols. In the remainder of this 305 document, SFGMP will refer to any group management protocol that has 306 Join and Leave functionalities. 308 Feedback Target (FT): Unicast RTCP feedback target as defined in 309 [RFC5760]. FT_Ap denotes a specific feedback target running on a 310 particular address and port. 312 Retransmission (or Burst) Packet: An RTP packet that is formatted as 313 defined in Section 4 of [RFC4588]. The payload of a retransmission 314 or burst packet comprises the retransmission payload header followed 315 by the payload of the original RTP packet. 317 Reference Information: The set of certain media content and metadata 318 information that is sufficient for an RTP receiver to start usefully 319 consuming a media stream. The meaning, format and size of this 320 information are specific to the application and are out of scope of 321 this document. 323 Preamble Information: A more compact form of the whole or a subset 324 of the Reference Information transmitted out-of-band. 326 (Unicast) Burst (or Retransmission) RTP Session: The unicast RTP 327 session used to send one or more unicast burst RTP streams and their 328 associated RTCP messages. The terms "burst RTP session" and 329 "retransmission RTP session" can be used interchangeably. 331 (Unicast) Burst (Stream): A unicast stream of RTP retransmission 332 packets that enable an RTP receiver to rapidly acquire the Reference 333 Information associated with a primary multicast stream. Each burst 334 stream is identified by its Synchronization Source (SSRC) identifier 335 that is unique in the primary multicast RTP session. Following the 336 session-multiplexing guidelines in [RFC4588], each unicast burst 337 stream must use the same SSRC and CNAME as its primary multicast RTP 338 stream. 340 Retransmission Server (RS): The RTP/RTCP endpoint that can generate 341 the retransmission packets and the burst streams. RS may also 342 generate other non-retransmission packets to aid rapid acquisition. 344 4. Elements of Delay in Multicast Applications 346 In a source-specific (SSM) multicast delivery system, there are three 347 major elements that contribute to the overall acquisition delay when 348 an RTP receiver switches from one multicast session to another one. 349 These are: 351 o Multicast switching delay 353 o Reference Information latency 355 o Buffering delays 357 Multicast switching delay is the delay that is experienced to leave 358 the current multicast session (if any) and join the new multicast 359 session. In typical systems, the multicast join and leave operations 360 are handled by a group management protocol. For example, the 361 receivers and routers participating in a multicast session can use 362 the Internet Group Management Protocol (IGMP) version 3 [RFC3376] or 363 the Multicast Listener Discovery Protocol (MLD) version 2 [RFC3810]. 364 In either of these protocols, when a receiver wants to join a 365 multicast session, it sends a message to its upstream router and the 366 routing infrastructure sets up the multicast forwarding state to 367 deliver the packets of the multicast session to the new receiver. 368 Depending on the proximity of the upstream router, the current state 369 of the multicast tree, the load on the system and the protocol 370 implementation, the join times vary. Current systems provide join 371 latencies usually less than 200 milliseconds (ms). If the receiver 372 had been participating in another multicast session before joining 373 the new session, it needs to send a Leave message to its upstream 374 router to leave the session. In common multicast routing protocols, 375 the leave times are usually smaller than the join times, however, it 376 is possible that the Leave and Join messages might get lost, in which 377 case the multicast switching delay inevitably increases. 379 Reference Information latency is the time it takes the receiver to 380 acquire the Reference Information. It is highly dependent on the 381 proximity of the actual time the receiver joined the session to the 382 next time the Reference Information will be sent to the receivers in 383 the session, whether the Reference Information is sent contiguously 384 or not, and the size of the Reference Information. For some 385 multicast flows, there is a little or no interdependency in the data, 386 in which case the Reference Information latency will be nil or 387 negligible. For other multicast flows, there is a high degree of 388 interdependency. One example of interest is the multicast flows that 389 carry compressed audio/video. For these flows, the Reference 390 Information latency can become quite large and be a major contributor 391 to the overall delay. 393 The buffering component of the overall acquisition delay is driven by 394 the way the application layer processes the payload. In many 395 multicast applications, an unreliable transport protocol such as UDP 396 [RFC0768] is often used to transmit the data packets, and the 397 reliability, if needed, is usually addressed through other means such 398 as Forward Error Correction (e.g., 399 [I-D.ietf-fecframe-interleaved-fec-scheme]) and retransmission. 400 These loss-repair methods require buffering at the receiver side to 401 function properly. In many applications, it is also often necessary 402 to de-jitter the incoming data packets before feeding them to the 403 application. The de-jittering process also increases the buffering 404 delays. Besides these network-related buffering delays, there are 405 also specific buffering needs that are required by the individual 406 applications. For example, standard video decoders typically require 407 an amount, sometimes a significant amount, of coded video data to be 408 available in the pre-decoding buffers prior to starting to decode the 409 video bitstream. 411 5. Protocol Design Considerations and Their Effect on Resource 412 Management for Rapid Acquisition 414 This section is for informational purposes and does not contain 415 requirements for implementations. 417 Rapid acquisition is an optimization of a system that is expected to 418 continue to work correctly and properly whether or not the 419 optimization is effective, or even fails due to lost control and 420 feedback messages, congestion, or other problems. This is 421 fundamental to the overall design requirements surrounding the 422 protocol definition and to the resource management schemes to be 423 employed together with the protocol (e.g., QoS machinery, server load 424 management, etc). In particular, the system needs to operate within 425 a number of constraints: 427 o First, a rapid acquisition operation must fail gracefully. The 428 user experience must, except perhaps in pathological 429 circumstances, be not significantly worse for trying and failing 430 to complete rapid acquisition compared to simply joining the 431 multicast session. 433 o Second, providing the rapid acquisition optimizations must not 434 cause collateral damage to either the multicast session being 435 joined, or other multicast sessions sharing resources with the 436 rapid acquisition operation. In particular, the rapid acquisition 437 operation must avoid interference with the multicast session that 438 might be simultaneously being received by other hosts. In 439 addition, it must also avoid interference with other multicast 440 sessions sharing the same network resources. These properties are 441 possible, but are usually difficult to achieve. 443 One challenge is the existence of multiple bandwidth bottlenecks 444 between the receiver and the server(s) in the network providing the 445 rapid acquisition service. In commercial IPTV deployments, for 446 example, bottlenecks are often present in the aggregation network 447 connecting the IPTV servers to the network edge, the access links 448 (e.g., DSL, DOCSIS) and in the home network of the subscribers. Some 449 of these links might serve only a single subscriber, limiting 450 congestion impact to the traffic of only that subscriber, but others 451 can be shared links carrying multicast sessions of many subscribers. 452 Also note that the state of these links can vary over time. The 453 receiver might have knowledge of a portion of this network, or might 454 have partial knowledge of the entire network. The methods employed 455 by the devices to acquire this network state information is out of 456 scope for this document. The receiver should be able to signal the 457 server with the bandwidth that it believes it can handle. The server 458 also needs to be able to rate limit the flow in order to stay within 459 the performance envelope that it knows about. Both the server and 460 receiver need to be able to inform the other of changes in the 461 requested and delivered rates. However, the protocol must be robust 462 in the presence of packet loss, so this signaling must include the 463 appropriate default behaviors. 465 A second challenge is that for some uses (e.g., high-bitrate video) 466 the unicast burst bitrate is high while the flow duration of the 467 unicast burst is short. This is because the purpose of the unicast 468 burst is to allow the RTP receiver to join the multicast quickly and 469 thereby limit the overall resources consumed by the burst. Such 470 high-bitrate, short-duration flows are not amenable to conventional 471 admission control techniques. For example, end-to-end per-flow 472 signaled admission control techniques such as RSVP have too much 473 latency and control channel overhead to be a good fit for rapid 474 acquisition. Similarly, using a TCP (or TCP-like) approach with a 475 3-way handshake and slow-start to avoid inducing congestion would 476 defeat the purpose of attempting rapid acquisition in the first place 477 by introducing many round-trip times (RTT) of delay. 479 These observations lead to certain unavoidable requirements and goals 480 for a rapid acquisition protocol. These are: 482 o The protocol must be designed to allow a deterministic upper bound 483 on the extra bandwidth used (compared to just joining the 484 multicast session). A reasonable size bound is e*B, where B is 485 the nominal bandwidth of the primary multicast streams, and e is 486 an excess-bandwidth coefficient. The total duration of the 487 unicast burst must have a reasonable bound; long unicast bursts 488 devolve to the bandwidth profile of multi-unicast for the whole 489 system. 491 o The scheme should minimize (or better eliminate) the overlap of 492 the unicast burst and the primary multicast stream. This 493 minimizes the window during which congestion could be induced on a 494 bottleneck link compared to just carrying the multicast or unicast 495 packets alone. 497 o The scheme must minimize (or better eliminate) any gap between the 498 unicast burst and the primary multicast stream, which has to be 499 repaired later, or in the absence of repair, will result in loss 500 being experienced by the application. 502 In addition to the above, there are some other protocol design issues 503 to be considered. First, there is at least one RTT of "slop" in the 504 control loop. In starting a rapid acquisition burst, this manifests 505 as the time between the client requesting the unicast burst and the 506 burst description and/or the first unicast burst packets arriving at 507 the receiver. For managing and terminating the unicast burst, there 508 are two possible approaches for the control loop: The receiver can 509 adapt to the unicast burst as received, converge based on observation 510 and explicitly terminate the unicast burst with a second control loop 511 exchange (which takes a minimum of one RTT, just as starting the 512 unicast burst does). Alternatively, the server generating the 513 unicast burst can pre-compute the burst parameters based on the 514 information in the initial request and tell the receiver the burst 515 duration. 517 The protocol described in the next section allows either method of 518 controlling the rapid acquisition unicast burst. 520 6. Rapid Acquisition of Multicast RTP Sessions (RAMS) 522 We start this section with an overview of the rapid acquisition of 523 multicast sessions (RAMS) method. 525 6.1. Overview 527 [RFC5760] specifies an extension to the RTP Control Protocol (RTCP) 528 to use unicast feedback in an SSM session. It defines an 529 architecture that introduces the concept of Distribution Source, 530 which - in an SSM context - distributes the RTP data and 531 redistributes RTCP information to all RTP receivers. This RTCP 532 information is retrieved from the Feedback Target, to which RTCP 533 unicast feedback traffic is sent. One or more entities different 534 from the Distribution Source MAY implement the feedback target 535 functionality, and different RTP receivers MAY use different feedback 536 targets. 538 This document builds further on these concepts to reduce the 539 acquisition delay when an RTP receiver joins a multicast session at a 540 random point in time by introducing the concept of the Burst Source 541 and new RTCP feedback messages. The Burst Source has a cache where 542 the most recent packets from the primary multicast RTP session are 543 continuously stored. When an RTP receiver wants to receive a primary 544 multicast stream, it can first request a unicast burst from the Burst 545 Source before it joins the SSM session. In this burst, the packets 546 are formatted as RTP retransmission packets [RFC4588] and carry 547 Reference Information. This information allows the RTP receiver to 548 start usefully consuming the RTP packets sent in the primary 549 multicast RTP session. 551 Using an accelerated bitrate (as compared to the nominal bitrate of 552 the primary multicast stream) for the unicast burst implies that at a 553 certain point in time, the payload transmitted in the unicast burst 554 is going to be the same as the payload in the associated multicast 555 stream, i.e., the unicast burst will catch up with the primary 556 multicast stream. At this point, the RTP receiver no longer needs to 557 receive the unicast burst and can join the SSM session. This method 558 is referred to as the Rapid Acquisition of Multicast Sessions (RAMS). 560 This document proposes extensions to [RFC4585] for an RTP receiver to 561 request a unicast burst as well as for additional control messaging 562 that can be leveraged during the acquisition process. 564 6.2. Message Flows 566 Figure 2 shows the main entities involved in rapid acquisition and 567 the message flows. They are 569 o Multicast Source 571 o Feedback Target (FT) 573 o Burst/Retransmission Source (BRS) 575 o RTP Receiver (RTP_Rx) 576 ----------- -------------- 577 | |------------------------------------>| | 578 | |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| | 579 | | | | 580 | Multicast | ---------------- | | 581 | Source | | Retransmission | | | 582 | |-------->| Server (RS) | | | 583 | |.-.-.-.->| | | | 584 | | | ------------ | | | 585 ----------- | | Feedback | |<.=.=.=.=.| | 586 | | Target (FT)| |<~~~~~~~~~| RTP Receiver | 587 PRIMARY MULTICAST | ------------ | | (RTP_Rx) | 588 RTP SESSION with | | | | 589 UNICAST FEEDBACK | | | | 590 | | | | 591 - - - - - - - - - - - |- - - - - - - - |- - - - - |- - - - - - - |- - 592 | | | | 593 UNICAST BURST | ------------ | | | 594 (or RETRANSMISSION) | | Burst and | |<~~~~~~~~>| | 595 RTP SESSION | | Retrans. | |.........>| | 596 | |Source (BRS)| |<.=.=.=.=>| | 597 | ------------ | | | 598 | | | | 599 ---------------- -------------- 601 -------> Multicast RTP Flow 602 .-.-.-.> Multicast RTCP Flow 603 .=.=.=.> Unicast RTCP Reports 604 ~~~~~~~> Unicast RTCP Feedback Messages 605 .......> Unicast RTP Flow 607 Figure 2: Flow diagram for unicast-based rapid acquisition 609 The feedback target (FT) is the entity as defined in [RFC5760], to 610 which RTP_Rx sends its RTCP feedback messages indicating packet loss 611 by means of an RTCP NACK message or indicating RTP_Rx's desire to 612 rapidly acquire the primary multicast RTP session by means of an RTCP 613 feedback message defined in this document. While the Burst/ 614 Retransmission Source (BRS) is responsible for responding to these 615 messages and for further RTCP interaction with RTP_Rx in the case of 616 a rapid acquisition process, it is assumed in the remainder of the 617 document that these two logical entities (FT and BRS) are combined in 618 a single physical entity and they share state. In the remainder of 619 the text, the term Retransmission Server (RS) is used whenever 620 appropriate, to refer to this single physical entity. 622 FT is involved in the primary multicast RTP session and receives 623 unicast feedback for that session as in [RFC5760]. BRS is involved 624 in the unicast burst (or retransmission) RTP session and transmits 625 the unicast burst and retransmission packets formatted as RTP 626 retransmission packets [RFC4588] in a single separate unicast RTP 627 session to each RTP_Rx. In the unicast burst RTP session, as in any 628 other RTP session, the BRS and RTP_Rx regularly send the periodic 629 sender and receiver reports, respectively. 631 The unicast burst is started by an RTCP feedback message that is 632 defined in this document based on the common packet format provided 633 in [RFC4585]. An RTP retransmission is triggered by an RTCP NACK 634 message defined in [RFC4585]. Both of these messages are sent to FT 635 of the primary multicast RTP session, and can start the unicast 636 burst/retransmission RTP session. 638 In the RTP/AVPF profile, there are certain rules that apply to 639 scheduling of both of these messages sent to FT in the primary 640 multicast RTP session, and these are detailed in Section 3.5 of 641 [RFC4585]. One of the rules states that in a multi-party session 642 such as the SSM sessions we are considering in this specification, an 643 RTP_Rx cannot send an RTCP feedback message for a minimum of one 644 second period after joining the session (i.e., Tmin=1.0 second). 645 While this rule has the goal of avoiding problems associated with 646 flash crowds in typical multi-party sessions, it defeats the purpose 647 of rapid acquisition. Furthermore, when RTP receivers delay their 648 messages requesting a burst by a deterministic or even a random 649 amount, it still does not make a difference since such messages are 650 not related and their timings are independent from each other. Thus, 651 in this specification we initialize Tmin to zero and allow the RTP 652 receivers to send a burst request message right at the beginning. It 653 should, however, be emphasized that for the subsequent messages 654 during rapid acquisition, the timing rules of [RFC4585] still apply. 656 Figure 3 depicts an example of messaging flow for rapid acquisition. 657 The RTCP feedback messages are explained below. The optional 658 messages are indicated in parentheses and they might or might not be 659 present during rapid acquisition. In a scenario where rapid 660 acquisition is performed by a feedback target co-located with the 661 media sender, the same method (with the identical message flows) 662 still applies. 664 ------------------------- 665 | Retransmission Server | 666 ----------- | ------ ------------ | -------- ------------ 667 | Multicast | | | FT | | Burst/Ret. | | | | | RTP | 668 | Source | | | | | Source | | | Router | | Receiver | 669 | | | ------ ------------ | | | | (RTP_Rx) | 670 ----------- | | | | -------- ------------ 671 | ------------------------- | | 672 | | | | | 673 |-- RTP Multicast ---------->--------------->| | 674 |-. RTCP Multicast -.-.-.-.->-.-.-.-.-.-.-.->| | 675 | | | | | 676 | | |********************************| 677 | | |* PORT MAPPING SETUP *| 678 | | |********************************| 679 | | | | | 680 | |<~~~~~~~~~~~~~~~~~~~~~~~~~ RTCP RAMS-R ~~~| 681 | | | | | 682 | | |********************************| 683 | | |* UNICAST SESSION ESTABLISHED *| 684 | | |********************************| 685 | | | | | 686 | | |~~~ RTCP RAMS-I ~~~~~~~~~~~~~~~>| 687 | | | | | 688 | | |... Unicast RTP Burst .........>| 689 | | | | | 690 | |<~~~~~~~~~~~~~~~~~~~~~~~~ (RTCP RAMS-R) ~~| 691 | | | | | 692 | | |~~ (RTCP RAMS-I) ~~~~~~~~~~~~~~>| 693 | | | | | 694 | | | | | 695 | | | |<= SFGMP Join ==| 696 | | | | | 697 |-- RTP Multicast ------------------------------------------->| 698 |-. RTCP Multicast -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.>| 699 | | | | | 700 | | | | | 701 | | |<~~~~~~~~~~~~~~~ RTCP RAMS-T ~~~| 702 | | | | | 703 | | | | | 704 | | | | | 705 : : : : : 706 : : : : : 707 | | |<.=.= Unicast RTCP Reports .=.=>| 708 : : : (for the unicast session) : 709 : : : : : 710 | | | | | 712 -------> Multicast RTP Flow 713 .-.-.-.> Multicast RTCP Flow 714 .=.=.=.> Unicast RTCP Reports 715 ~~~~~~~> Unicast RTCP Feedback Messages 716 =======> SFGMP Messages 717 .......> Unicast RTP Flow 719 Figure 3: Message flows for unicast-based rapid acquisition 721 This document defines the expected behaviors of RS and RTP_Rx. It is 722 instructive to have independently operating implementations on RS and 723 RTP_Rx that request the burst, describe the burst, start the burst, 724 join the multicast session and stop the burst. These implementations 725 send messages to each other, but there must be provisions for the 726 cases where the control messages get lost, or re-ordered, or are not 727 being delivered to their destinations. 729 The following steps describe rapid acquisition in detail: 731 1. Port Mapping Setup: For the primary multicast RTP session, the 732 RTP and RTCP destination ports are declaratively specified 733 (Refer to Section 8 for examples in SDP). However, RTP_Rx needs 734 to choose its RTP and RTCP receive ports in the unicast burst 735 RTP session. Since this unicast session is established after 736 RTP_Rx has sent a RAMS-Request (RAMS-R) message as unicast 737 feedback in the primary multicast RTP session, RTP_Rx MUST first 738 setup the port mappings between the unicast and multicast 739 sessions and send this mapping information to FT along with the 740 RAMS-R message so that BRS knows how to communicate with RTP_Rx. 742 The details of this setup procedure are explained in 743 [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. Other NAT-related 744 issues are left to Section 9 to keep the present discussion 745 focused on the RAMS message flows. 747 2. Request: RTP_Rx sends a rapid acquisition request (RAMS-R) for 748 the primary multicast RTP session to the unicast feedback target 749 of that session. The request contains the SSRC identifier of 750 RTP_Rx (aka SSRC of packet sender) and can contain the media 751 sender SSRC identifier(s) of the primary multicast stream(s) of 752 interest (aka SSRC of media source). The RAMS-R message can 753 contain parameters that constrain the burst, such as the buffer 754 and bandwidth limits. 756 Before joining the SSM session, RTP_Rx learns the addresses for 757 the multicast source, group and RS by out-of-band means. If 758 RTP_Rx desires to rapidly acquire only a subset of the primary 759 multicast streams available in the primary multicast RTP 760 session, it MUST also acquire the SSRC identifiers for the 761 desired RTP streams out-of-band. Based on this information, 762 RTP_Rx populates the desired SSRC(s) in the RAMS-R message. 764 When FT successfully receives the RAMS-R message, BRS responds 765 to it by accepting or rejecting the request. Immediately before 766 BRS sends any RTP or RTCP packet(s) described below, it 767 establishes the unicast burst RTP session. 769 3. Response: BRS sends RAMS-Information (RAMS-I) message(s) to 770 RTP_Rx to convey the status for the burst(s) requested by 771 RTP_Rx. 773 If the primary multicast RTP session associated with FT_Ap on 774 which the RAMS-R message was received contains only a single 775 primary multicast stream, BRS SHALL always use the SSRC of the 776 RTP stream associated with FT_Ap in the RAMS-I message(s) 777 regardless of the media sender SSRC requested in the RAMS-R 778 message. In such cases the 'ssrc' attribute MAY be omitted from 779 the media description. If the requested SSRC and the actual 780 media sender SSRC do not match, BRS MUST explicitly populate the 781 correct media sender SSRC in the initial RAMS-I message (See 782 Section 7.3). 784 FT_Ap could also be associated with an RTP session that carries 785 two or more primary multicast streams. If RTP_Rx will issue a 786 collective request to receive the whole primary multicast RTP 787 session, it does not need the 'ssrc' attributes to be described 788 in the media description. 790 If FT_Ap is associated with two or more RTP sessions, RTP_Rx's 791 request will be ambiguous. To avoid any ambiguity, each FT_Ap 792 MUST be associated with a single RTP session. 794 If RTP_Rx is willing to rapidly acquire only a subset of the 795 primary multicast streams, the RAMS-R message MUST explicitly 796 list the media sender SSRCs denoting the stream(s) it wishes to 797 acquire. Upon receiving such a message, BRS MAY accept the 798 request for all or a subset of the media sender SSRC(s) that 799 matched the RTP stream(s) it serves. BRS MUST reject all other 800 requests with the appropriate response code. 802 * Reject Responses: BRS MUST take into account any limitations 803 that may have been specified by RTP_Rx in the RAMS-R message 804 when making a decision regarding the request. If RTP_Rx has 805 requested to acquire the whole primary multicast RTP session 806 but BRS cannot provide a rapid acquisition service for any of 807 the primary multicast streams, BRS MUST reject the request 808 via a single RAMS-I message with a collective reject response 809 code and whose media sender SSRC field is set to one of SSRCs 810 served by this FT_Ap. Upon receiving this RAMS-I message, 811 RTP_Rx abandons the rapid acquisition attempt and can 812 immediately join the multicast session by sending an SFGMP 813 Join message towards its upstream multicast router. 815 In all other cases, BRS MUST send a separate RAMS-I message 816 with the appropriate response code for each primary multicast 817 stream that has been requested by RTP_Rx but cannot be served 818 by BRS. 820 * Accept Responses: BRS MUST send a separate RAMS-I message 821 with the appropriate response code for each primary multicast 822 stream that has been requested by RTP_Rx and will be served 823 by BRS. Such RAMS-I messages comprise fields that can be 824 used to describe the individual unicast burst streams. 826 A particularly important field in the RAMS-I message carries 827 the RTP sequence number of the first packet transmitted in 828 the respective RTP stream to allow RTP_Rx to detect any 829 missing initial packet(s). When BRS accepts the request, 830 this field MUST be populated in the RAMS-I message and the 831 initial RAMS-I message SHOULD precede the unicast burst or be 832 sent at the start of the burst so that RTP_Rx can quickly 833 detect any missing initial packet(s). 835 Where possible, it is RECOMMENDED to include all RAMS-I messages 836 in the same compound RTCP packet. However, it is possible that 837 the RAMS-I message for a primary multicast stream can get 838 delayed or lost, and RTP_Rx can start receiving RTP packets 839 before receiving a RAMS-I message. RTP_Rx MUST NOT make 840 protocol dependencies on quickly receiving the initial RAMS-I 841 message. For redundancy purposes, it is RECOMMENDED that BRS 842 repeats the RAMS-I messages multiple times as long as it follows 843 the RTCP timer rules defined in [RFC4585]. 845 4. Unicast Burst: For the primary multicast stream(s) for which 846 the request is accepted, BRS starts sending the unicast burst(s) 847 that comprises one or more RTP retransmission packets sent in 848 the unicast burst RTP session. In addition, BRS MAY send 849 preamble information data to RTP_Rx in addition to the requested 850 burst, to prime the media decoder(s). The format of this 851 preamble data is RTP-payload specific and not specified here. 853 5. Updated Request: RTP_Rx MAY send an updated RAMS-R message (as 854 unicast feedback in the primary multicast RTP session) with a 855 different value for one or more fields of an earlier RAMS-R 856 message. If there is already a burst planned for or being 857 transmitted to a particular RTP_Rx for a particular stream, the 858 newly arriving RAMS-R is an updated request; otherwise, it is a 859 new request. BRS determines the identity of the requesting 860 RTP_Rx by looking at its canonical name identifier (CNAME item 861 in the SDES source description). To choose a globally unique 862 CNAME identifier, RTP_Rx SHOULD follow the guidelines given in 863 [I-D.begen-avt-rtp-cnames]. In addition to one or more fields 864 with updated values, an updated RAMS-R message may also include 865 the fields whose values did not change. 867 Upon receiving an updated request, BRS can use the updated 868 values for sending/shaping the burst, or refine the values and 869 use the refined values for sending/shaping the burst. 870 Subsequently, BRS MAY send an updated RAMS-I message in the 871 unicast burst RTP session to indicate the changes it made. 873 However, the updated RAMS-I message can get lost. It is also 874 possible that the updated RAMS-R message could have been lost. 875 RTP_Rx MUST NOT make protocol dependencies on quickly (or ever) 876 receiving an updated RAMS-I message, or assume that BRS will 877 honor the requested changes. 879 RTP_Rx may be in an environment where the available resources 880 are time-varying, which may or may not deserve sending a new 881 updated request. Determining the circumstances where RTP_Rx 882 should or should not send an updated request and the methods 883 that RTP_Rx can use to detect and evaluate the time-varying 884 available resources are not specified in this document. 886 6. Updated Response: BRS can send more than one RAMS-I messages in 887 the unicast burst RTP session, e.g., to update the value of one 888 or more fields in an earlier RAMS-I message. The updated RAMS-I 889 messages might or might not be a direct response to a RAMS-R 890 message. BRS can also send updated RAMS-I messages to signal 891 RTP_Rx in real time to join the SSM session. RTP_Rx depends on 892 BRS to learn the join time, which can be conveyed by the first 893 RAMS-I message, or can be sent/revised in a later RAMS-I 894 message. If BRS is not capable of determining the join time in 895 the initial RAMS-I message, BRS MUST send another RAMS-I message 896 (with the join time information) later. 898 7. Multicast Join Signaling: The RAMS-I message allows BRS to 899 signal explicitly when RTP_Rx SHOULD send the SFGMP Join 900 message. If the request is accepted, this information MUST be 901 conveyed in at least one RAMS-I message and its value MAY be 902 updated by subsequent RAMS-I messages. If RTP_Rx has received 903 multiple RAMS-I messages, RTP_Rx SHOULD use the information from 904 the most recent RAMS-I message. 906 There can be missing packets if RTP_Rx joins the multicast 907 session too early or too late. For example, if RTP_Rx starts 908 receiving the primary multicast stream while it is still 909 receiving the unicast burst at a high excess bitrate, this can 910 result in an increased risk of packet loss. Or, if RTP_Rx joins 911 the multicast session some time after the unicast burst is 912 finished, there can be a gap between the burst and multicast 913 data (a number of RTP packets might be missing). In both cases, 914 RTP_Rx can issue retransmission requests (via RTCP NACK messages 915 sent as unicast feedback in the primary multicast RTP session) 916 [RFC4585] to the FT entity of RS to fill the gap. BRS might or 917 might not respond to such requests. When it responds and the 918 response causes significant changes in one or more values 919 reported earlier to RTP_Rx, an updated RAMS-I should be sent to 920 RTP_Rx. 922 8. Multicast Receive: After the join, RTP_Rx starts receiving the 923 primary multicast stream(s). 925 9. Terminate: BRS can know when it needs to ultimately stop the 926 unicast burst based on its parameters. However, RTP_Rx may need 927 to ask BRS to terminate the burst prematurely or at a specific 928 sequence number. For this purpose, it uses the RAMS-Termination 929 (RAMS-T) message sent as RTCP feedback in the unicast burst RTP 930 session. A separate RAMS-T message is sent for each primary 931 multicast stream served by BRS unless an RTCP BYE message has 932 been sent in the unicast burst RTP session as described in Step 933 10. For the burst requests that were rejected by BRS, there is 934 no need to send a RAMS-T message. 936 If RTP_Rx wants to terminate a burst prematurely, it SHALL send 937 a plain RAMS-T message for the SSRC of the primary multicast 938 stream it wishes to terminate. This message is sent in the 939 unicast burst RTP session. Upon receiving this message BRS MUST 940 terminate the unicast burst. If RTP_Rx requested to acquire the 941 entire primary multicast RTP session but wants to terminate this 942 request before it learns the individual media sender SSRC(s) via 943 RAMS-I message(s) or RTP packets, RTP_Rx cannot use RAMS-T 944 message(s) and thus MUST send an RTCP BYE message in the unicast 945 burst RTP session to terminate the request. 947 Otherwise, the default behavior for RTP_Rx is to send a RAMS-T 948 message in the unicast burst RTP session immediately after it 949 joins the multicast session and started receiving multicast 950 packets. In that case, RTP_Rx SHALL send a RAMS-T message with 951 the sequence number of the first RTP packet received in the 952 primary multicast stream. Then, BRS SHOULD terminate the 953 respective burst after it sends the unicast burst packet whose 954 Original Sequence Number (OSN) field in the RTP retransmission 955 payload header matches this number minus one. 957 If an RTCP BYE message has not been issued yet as described in 958 Step 10, RTP_Rx MUST send at least one RAMS-T message for each 959 primary multicast stream served by BRS. The RAMS-T message(s) 960 MUST be addressed to BRS and sent in the unicast burst RTP 961 session. Against the possibility of a message loss, it is 962 RECOMMENDED that RTP_Rx repeats the RAMS-T messages multiple 963 times as long as it follows the RTCP timer rules defined in 964 [RFC4585]. 966 The binding between RAMS-T and ongoing bursts is achieved 967 through RTP_Rx's CNAME identifier, and packet sender and media 968 sender SSRCs. Choosing a globally unique CNAME makes sure that 969 the RAMS-T messages are processed correctly. 971 10. Terminate with RTCP BYE: When RTP_Rx is receiving one or more 972 burst streams, if RTP_Rx becomes no longer interested in 973 acquiring any of the primary multicast streams, RTP_Rx SHALL 974 issue an RTCP BYE message for the unicast burst RTP session and 975 another RTCP BYE message for the primary multicast RTP session. 976 These RTCP BYE messages are sent to BRS and FT logical entities, 977 respectively. 979 Upon receiving an RTCP BYE message, BRS MUST terminate the rapid 980 acquisition operation, and cease transmitting any further burst 981 packets and retransmission packets. If support for [RFC5506] 982 has been signaled, the RTCP BYE message MAY be sent in a 983 reduced-size RTCP packet. Otherwise, Section 6.1 of [RFC3550] 984 mandates the RTCP BYE message always to be sent with a sender or 985 receiver report in a compound RTCP packet. If no data has been 986 received, an empty receiver report MUST be still included. With 987 the information contained in the receiver report, RS can figure 988 out how many duplicate RTP packets have been delivered to RTP_Rx 989 (Note that this will be an upper-bound estimate as one or more 990 packets might have been lost during the burst transmission). 991 The impact of duplicate packets and measures that can be taken 992 to minimize the impact of receiving duplicate packets will be 993 addressed in Section 6.4. 995 Since an RTCP BYE message issued for the unicast burst RTP 996 session terminates that session and ceases transmitting any 997 further packets in that session, there is no need for sending 998 explicit RAMS-T messages, which would only terminate their 999 respective bursts. 1001 For the purpose of gathering detailed information about RTP_Rx's 1002 rapid acquisition experience, [I-D.ietf-avt-multicast-acq-rtcp-xr] 1003 defines an RTCP Extended Report (XR) Block. This report is designed 1004 to be payload-independent, thus, it can be used by any multicast 1005 application that supports rapid acquisition. Support for this XR 1006 report is, however, OPTIONAL. 1008 6.3. Synchronization of Primary Multicast Streams 1010 When RTP_Rx acquires multiple primary multicast streams, RTP_Rx can 1011 need to synchronize them for the playout. This synchronization is 1012 traditionally achieved by the help of the RTCP sender reports 1013 [RFC3550]. If the playout will start before RTP_Rx has joined the 1014 multicast session, RTP_Rx needs to receive the information reflecting 1015 the synchronization among the primary multicast streams early enough 1016 so that it can play out the media in a synchronized fashion. 1018 The suggested approach is to use the RTP header extension mechanism 1019 [RFC5285] and convey the synchronization information in a header 1020 extension as defined in [I-D.ietf-avt-rapid-rtp-sync]. [RFC4588] 1021 says that retransmission packets should carry the same header 1022 extension carried in the header of the original RTP packets. Thus, 1023 as long as the multicast source emits a header extension with the 1024 synchronization information frequently enough, there is no additional 1025 task that needs to be carried out by BRS. The synchronization 1026 information will be sent to RTP_Rx along with the burst packets. The 1027 frequent header extensions sent in the primary multicast RTP sessions 1028 also allow rapid synchronization of the RTP streams for the RTP 1029 receivers that do not support RAMS or that directly join the 1030 multicast session without running RAMS. Thus, in RAMS applications, 1031 it is RECOMMENDED that the multicast sources frequently send 1032 synchronization information by using header extensions following the 1033 rules presented in [I-D.ietf-avt-rapid-rtp-sync]. The regular sender 1034 reports are still sent in the unicast session by following the rules 1035 of [RFC3550]. 1037 6.4. Burst Shaping and Congestion Control in RAMS 1039 This section provides informative guidelines about how BRS can shape 1040 the transmission of the unicast burst and how congestion can be dealt 1041 within the RAMS process. When RTP_Rx detects that the unicast burst 1042 is causing severe congestion, it can prefer to send a RAMS-T message 1043 immediately to stop the unicast burst. 1045 A higher bitrate for the unicast burst naturally conveys the 1046 Reference Information and media content to RTP_Rx faster. This way, 1047 RTP_Rx can start consuming the data sooner, which results in a faster 1048 acquisition. A higher bitrate also represents a better utilization 1049 of BRS resources. As the burst may continue until it catches up with 1050 the primary multicast stream, the higher the bursting bitrate, the 1051 less data BRS needs to transmit. However, a higher bitrate for the 1052 burst also increases the chances for congestion-caused packet loss. 1053 Thus, as discussed in Section 5, there has to be an upper bound on 1054 the bandwidth used by the burst. 1056 When BRS transmits the unicast burst, it should take into account all 1057 available information to prevent any packet loss that might take 1058 place during the bursting as a result of buffer overflow on the path 1059 between RS and RTP_Rx and at RTP_Rx itself. The bursting bitrate can 1060 be determined by taking into account the following information, when 1061 available: 1063 a. Information obtained via the RAMS-R message, such as Max RAMS 1064 Buffer Fill Requirement and/or Max Receive Bitrate (See 1065 Section 7.2). 1067 b. Information obtained via RTCP receiver reports provided by RTP_Rx 1068 in the retransmission session, allowing in-session bitrate 1069 adaptations for the burst. When these receiver reports indicate 1070 packet loss, this can indicate a certain congestion state in the 1071 path from RS to RTP_Rx. 1073 c. Information obtained via RTCP NACKs provided by RTP_Rx in the 1074 primary multicast RTP session, allowing in-session bitrate 1075 adaptations for the burst. Such RTCP NACKs are transmitted by 1076 RTP_Rx in response to packet loss detection in the burst. NACKs 1077 can indicate a certain congestion state on the path from RS to 1078 RTP_Rx. 1080 d. There can be other feedback received from RTP_Rx, e.g., in the 1081 form of ECN-CE markings [I-D.ietf-avt-ecn-for-rtp] that can 1082 influence in-session bitrate adaptation. 1084 e. Information obtained via updated RAMS-R messages, allowing in- 1085 session bitrate adaptations, if supported by BRS. 1087 f. Transport protocol-specific information. For example, when DCCP 1088 is used to transport the RTP burst, the ACKs from the DCCP client 1089 can be leveraged by the BRS / DCCP server for burst shaping and 1090 congestion control. 1092 g. Pre-configured settings for each RTP_Rx or a set of RTP_Rxs that 1093 indicate the upper-bound bursting bitrates for which no packet 1094 loss will occur as a result of congestion along the path of RS to 1095 RTP_Rx. For example, in managed IPTV networks, where the 1096 bottleneck bandwidth along the end-to-end path is known and where 1097 the network between RS and this link is provisioned and 1098 dimensioned to carry the burst streams, the bursting bitrate does 1099 not exceed the provisioned value. These settings can also be 1100 dynamically adapted using application-aware knowledge. 1102 BRS chooses the initial burst bitrate as follows: 1104 o When using RAMS in environments as described in (g), BRS MUST 1105 transmit the burst packets at an initial bitrate higher than the 1106 nominal bitrate, but within the engineered or reserved bandwidth 1107 limit. 1109 o When BRS cannot determine a reliable bitrate value for the unicast 1110 burst (through a or g), BRS should choose an appropriate initial 1111 bitrate not above the nominal bitrate and increase it gradually 1112 unless a congestion is detected. 1114 In both cases, during the burst transmission BRS MUST continuously 1115 monitor for packet losses as a result of congestion by means of one 1116 or more of the mechanisms described in (b,c,d,e,f). When BRS relies 1117 on RTCP receiver reports, sufficient bandwidth needs to be provided 1118 to RTP Rx for RTCP transmission in the unicast burst RTP session. To 1119 achieve a reasonable fast adaptation against congestion, it is 1120 recommended that RTP_Rx sends a receiver report at least once every 1121 two RTTs between RS and RTP_Rx. Although the specific heuristics and 1122 algorithms that deduce a congestion state and how subsequently BRS 1123 should act are outside the scope of this specification, the following 1124 two practices are recommended: 1126 o Upon detection of a significant amount of packet loss, which BRS 1127 attributes to congestion, BRS should decrease the burst bitrate. 1128 The rate by which BRS increases and decreases the bitrate for the 1129 burst can be determined by a TCP-friendly bitrate adaptation 1130 algorithm for RTP over UDP , or in the case of (f) by the 1131 congestion control algorithms defined in DCCP [RFC5762]. 1133 o If the congestion is persistent and BRS has to reduce the burst 1134 bitrate to a point where the RTP Rx buffer might underrun or the 1135 burst will consume too many resources, BRS should terminate the 1136 burst and transmit a RAMS-I message to RTP Rx with the appropriate 1137 response code. It is then up to RTP Rx to decide when to join the 1138 multicast session. 1140 Even though there is no congestion experienced during the burst, 1141 congestion may anyway arise near the end of the burst as RTP_Rx 1142 eventually needs to join the multicast session. During this brief 1143 period both the burst packets and the multicast packets can be 1144 simultaneously received by RTP_Rx, thus enhancing the risk of 1145 congestion. 1147 Since BRS signals RTP_Rx when BRS expects RTP_Rx to send the SFGMP 1148 Join message, BRS can have a rough estimate of when RTP_Rx will start 1149 receiving multicast packets in the SSM session. BRS can keep on 1150 sending burst packets but should reduce the bitrate accordingly at 1151 the appropriate instant by taking the bitrate of the whole SSM 1152 session into account. If BRS ceases transmitting the burst packets 1153 before the burst catches up, any gap resulting from this imperfect 1154 switch-over by RTP_Rx can be later repaired by requesting 1155 retransmissions for the missing packets from RS. The retransmissions 1156 can be shaped by BRS to make sure that they do not cause collateral 1157 loss in the primary multicast RTP session and the unicast burst RTP 1158 session. 1160 6.5. Failure Cases 1162 In the following, we examine the implications of losing the RAMS-R, 1163 RAMS-I or RAMS-T messages and other failure cases. 1165 When RTP_Rx sends a RAMS-R message to initiate a rapid acquisition 1166 but the message gets lost and FT does not receive it, RTP_Rx will get 1167 neither a RAMS-I message, nor a unicast burst. In this case, RTP_Rx 1168 MAY resend the request when it is eligible to do so based on the RTCP 1169 timer rules defined in [RFC4585]. Or, after a reasonable amount of 1170 time, RTP_Rx can time out (based on the previous observed response 1171 times) and immediately join the SSM session. 1173 In the case RTP_Rx starts receiving a unicast burst but it does not 1174 receive a corresponding RAMS-I message within a reasonable amount of 1175 time, RTP_Rx can either discard the burst data or decide not to 1176 interrupt the unicast burst, and be prepared to join the SSM session 1177 at an appropriate time it determines or as indicated in a subsequent 1178 RAMS-I message (if available). To minimize the chances of losing the 1179 RAMS-I messages, it is RECOMMENDED that BRS repeats the RAMS-I 1180 messages multiple times based on the RTCP timer rules defined in 1181 [RFC4585]. 1183 In the failure cases where the RAMS-R message is lost and RTP_Rx 1184 gives up, or the RAMS-I message is lost, RTP_Rx MUST still terminate 1185 the burst(s) it requested by following the rules described in 1186 Section 6.2. 1188 In the case a RAMS-T message sent by RTP_Rx does not reach its 1189 destination, BRS can continue sending burst packets even though 1190 RTP_Rx no longer needs them. In such cases, it is RECOMMENDED that 1191 RTP_Rx repeats the RAMS-T message multiple times based on the RTCP 1192 timer rules defined in [RFC4585]. BRS MUST be provisioned to 1193 deterministically terminate the burst when it can no longer send the 1194 burst packets faster than it receives the primary multicast stream 1195 packets. 1197 Section 6.3.5 of [RFC3550] explains the rules pertaining to timing 1198 out an SSRC. When BRS accepts to serve the requested burst(s) and 1199 establishes the retransmission session, it should check the liveness 1200 of RTP_Rx via the RTCP messages and reports RTP_Rx sends. The 1201 default rules explained in [RFC3550] apply in RAMS as well. 1203 7. Encoding of the Signaling Protocol in RTCP 1205 This section defines the formats of the RTCP transport-layer feedback 1206 messages that are exchanged between the retransmission server (RS) 1207 and RTP receiver (RTP_Rx) during rapid acquisition. These messages 1208 are referred to as the RAMS Messages. They are payload-independent 1209 and MUST be used by all RTP-based multicast applications that support 1210 rapid acquisition regardless of the payload they carry. 1212 Payload-specific feedback messages are not defined in this document. 1213 However, further optional payload-independent and payload-specific 1214 information can be included in the exchange. 1216 The common packet format for the RTCP feedback messages is defined in 1217 Section 6.1 of [RFC4585] and is also sketched in Figure 4. 1219 0 1 2 3 1220 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 |V=2|P| FMT | PT | length | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | SSRC of packet sender | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | SSRC of media source | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 : Feedback Control Information (FCI) : 1229 : : 1231 Figure 4: The common packet format for the RTCP feedback messages 1233 Each feedback message has a fixed-length field for version, padding, 1234 feedback message type (FMT), payload type (PT), length, SSRC of 1235 packet sender, SSRC of media sender as well as a variable-length 1236 field for feedback control information (FCI). 1238 In the RAMS messages, the PT field is set to RTPFB (205) and the FMT 1239 field is set to RAMS (6). Individual RAMS messages are identified by 1240 a sub-field called Sub Feedback Message Type (SFMT). Any Reserved 1241 field SHALL be set to zero and ignored. 1243 Depending on the specific scenario and timeliness/importance of a 1244 RAMS message, it can be desirable to send it in a reduced-size RTCP 1245 packet [RFC5506]. However, unless support for [RFC5506] has been 1246 signaled, compound RTCP packets MUST be used by following [RFC3550] 1247 rules. 1249 Following the rules specified in [RFC3550], all integer fields in the 1250 messages defined below are carried in network-byte order, that is, 1251 most significant byte (octet) first, also known as big-endian. 1252 Unless otherwise stated, numeric constants are in decimal (base 10). 1254 7.1. Extensions 1256 To improve the functionality of the RAMS method in certain 1257 applications, it can be desirable to define new fields in the RAMS 1258 Request, Information and Termination messages. Such fields MUST be 1259 encoded as Type-Length-Value (TLV) elements as described below and 1260 sketched in Figure 5: 1262 o Type: A single-octet identifier that defines the type of the 1263 parameter represented in this TLV element. 1265 o Length: A two-octet field that indicates the length (in octets) 1266 of the TLV element excluding the Type and Length fields, and the 1267 8-bit Reserved field between them. This length does not include 1268 any padding that is required for alignment. 1270 o Value: Variable-size set of octets that contains the specific 1271 value for the parameter. 1273 In the extensions, the Reserved field SHALL be set to zero and 1274 ignored. If a TLV element does not fall on a 32-bit boundary, the 1275 last word MUST be padded to the boundary using further bits set to 1276 zero. 1278 In a RAMS message, any vendor-neutral or private extension MUST be 1279 placed after the mandatory fields and mandatory TLV elements (if 1280 any). The extensions MAY be placed in any order. The support for 1281 extensions (unless specified otherwise) is OPTIONAL. 1283 0 1 2 3 1284 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 | Type | Reserved | Length | 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 : Value : 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 Figure 5: Structure of a TLV element 1293 7.1.1. Vendor-Neutral Extensions 1295 If the goal in defining new TLV elements is to extend the 1296 functionality in a vendor-neutral manner, they MUST be registered 1297 with IANA through the guidelines provided in Section 11.5. 1299 The current document defines several vendor-neutral extensions in the 1300 subsequent sections. 1302 7.1.2. Private Extensions 1304 It is desirable to allow vendors to use private extensions in a TLV 1305 format. For interoperability, such extensions must not collide with 1306 each other. 1308 A certain range of TLV Types (between - and including - 128 and 254 ) 1309 is reserved for private extensions (Refer to Section 11.5). IANA 1310 management for these extensions is unnecessary and they are the 1311 responsibility of individual vendors. 1313 The structure that MUST be used for the private extensions is 1314 depicted in Figure 6. Here, the enterprise numbers are used from 1315 http://www.iana.org/assignments/enterprise-numbers. This will ensure 1316 the uniqueness of the private extensions and avoid any collision. 1318 0 1 2 3 1319 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 | Type | Reserved | Length | 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 | Enterprise Number | 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 : Value : 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 Figure 6: Structure of a private extension 1330 7.2. RAMS Request 1332 The RAMS Request message is identified by SFMT=1. This message is 1333 sent as unicast feedback in the primary multicast RTP session by 1334 RTP_Rx to request rapid acquisition of a primary multicast RTP 1335 session, or one or more primary multicast streams belonging to the 1336 same primary multicast RTP session. In the RAMS-R message, RTP_Rx 1337 MUST set both the packet sender SSRC and media sender SSRC fields to 1338 its own SSRC since the media sender SSRC may not be known. RTP_Rx 1339 MUST provide explicit signaling as described below to request 1340 stream(s). This minimizes the chances of accidentally requesting a 1341 wrong primary multicast stream. 1343 The FCI field MUST contain only one RAMS Request. The FCI field has 1344 the structure depicted in Figure 7. 1346 0 1 2 3 1347 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 | SFMT=1 | Reserved | 1350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 : Optional TLV-encoded Fields (and Padding, if needed) : 1352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 Figure 7: FCI field syntax for the RAMS Request message 1356 o Requested Media Sender SSRC(s): Mandatory TLV element that lists 1357 the media sender SSRC(s) requested by RTP_Rx. BRS MUST ignore the 1358 media sender SSRC specified in the header of the RAMS-R message. 1360 If the Length field is set to zero (i.e., no media sender SSRC is 1361 listed), it means that RTP_Rx is requesting to rapidly acquire the 1362 entire primary multicast RTP session. Otherwise, RTP_Rx lists the 1363 individual media sender SSRCs in this TLV element and sets the 1364 Length field of the TLV element to 4*n, where n is the number of 1365 SSRC entries. 1367 Type: 1 1369 o Min RAMS Buffer Fill Requirement (32 bits): Optional TLV element 1370 that denotes the minimum milliseconds of data that RTP_Rx desires 1371 to have in its buffer before allowing the data to be consumed by 1372 the application. 1374 RTP_Rx can have knowledge of its buffering requirements. These 1375 requirements can be application and/or device specific. For 1376 instance, RTP_Rx might need to have a certain amount of data in 1377 its application buffer to handle transmission jitter and/or to be 1378 able to support error-control methods. If BRS is told the minimum 1379 buffering requirement of the receiver, BRS can tailor the burst(s) 1380 more precisely, e.g., by choosing an appropriate starting point. 1381 The methods used by RTP_Rx to determine this value are application 1382 specific, and thus, out of the scope of this document. 1384 If specified, the amount of backfill that will be provided by the 1385 unicast bursts and any payload-specific information MUST NOT be 1386 smaller than the specified value. Otherwise, the backfill will 1387 not be able to build up the desired level of buffer at RTP_Rx and 1388 can cause buffer underruns. 1390 Type: 2 1392 o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element 1393 that denotes the maximum milliseconds of data that RTP_Rx can 1394 buffer without losing the data due to buffer overflow. 1396 RTP_Rx can have knowledge of its buffering requirements. These 1397 requirements can be application or device specific. For instance, 1398 one particular RTP_Rx might have more physical memory than another 1399 RTP_Rx, and thus, can buffer more data. If BRS knows the 1400 buffering ability of the receiver, BRS can tailor the burst(s) 1401 more precisely. The methods used by the receiver to determine 1402 this value are application specific, and thus, out of scope. 1404 If specified, the amount of backfill that will be provided by the 1405 unicast bursts and any payload-specific information MUST NOT be 1406 larger than this value. Otherwise, the backfill may cause buffer 1407 overflows at RTP_Rx. 1409 Type: 3 1411 o Max Receive Bitrate (64 bits): Optional TLV element that denotes 1412 the maximum bitrate (in bits per second) at which the RTP_Rx can 1413 process the aggregation of the unicast burst(s) and any payload- 1414 specific information that will be provided by BRS. The limits can 1415 include local receiver limits as well as network limits that are 1416 known to the receiver. 1418 If specified, the total bitrate of the unicast burst(s) plus any 1419 payload-specific information MUST NOT be larger than this value. 1420 Otherwise, congestion and packet loss may occur. 1422 Type: 4 1424 o Request for Preamble Only (0 bits): Optional TLV element that 1425 indicates that RTP_Rx is only requesting the preamble information 1426 for the desired primary multicast stream(s). If this TLV element 1427 exists in the RAMS-R message, BRS MUST NOT send any burst packets 1428 other than the preamble packets. Since this TLV element does not 1429 carry a Value field, the Length field MUST be set to zero. 1431 Type: 5 1433 The semantics of the RAMS-R feedback message is independent of the 1434 payload type. 1436 7.3. RAMS Information 1438 The RAMS Information message is identified by SFMT=2. This message 1439 is used to describe the unicast burst that will be sent for rapid 1440 acquisition. It also includes other useful information for RTP_Rx as 1441 described below. 1443 A separate RAMS-I message with the appropriate response code is sent 1444 in the unicast burst RTP session by BRS for each primary multicast 1445 stream that has been requested by RTP_Rx. In each of these RAMS-I 1446 messages, the media sender SSRC and packet sender SSRC fields are 1447 both set to the SSRC of BRS, which equals the SSRC of the respective 1448 primary multicast stream. 1450 The FCI field MUST contain only one RAMS Information. The FCI field 1451 has the structure depicted in Figure 8. 1453 0 1 2 3 1454 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 | SFMT=2 | MSN | Response | 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 : Optional TLV-encoded Fields (and Padding, if needed) : 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1461 Figure 8: FCI field syntax for the RAMS Information message 1463 A RAMS-I message has the following fields: 1465 o Message Sequence Number (8 bits) : Mandatory field that denotes 1466 the sequence number of the RAMS-I message for the particular media 1467 sender SSRC specified in the message header. The MSN value SHALL 1468 be set to zero only when a new RAMS request is received. During 1469 rapid acquisition, the same RAMS-I message MAY be repeated for 1470 redundancy purposes without incrementing the MSN value. If an 1471 updated RAMS-I message will be sent (either with a new information 1472 or an updated information), the MSN value SHALL be incremented by 1473 one. In the MSN field, the regular wrapping rules apply. 1475 o Response (16 bits): Mandatory field that denotes the response 1476 code for this RAMS-I message. This document defines several 1477 initial response codes and registers them with IANA. If a new 1478 vendor-neutral response code will be defined, it MUST be 1479 registered with IANA through the guidelines specified in 1480 Section 11.6. If the new response code is intended to be used 1481 privately by a vendor, there is no need for IANA management. 1482 Instead, the vendor MUST use the private extension mechanism 1483 (Section 7.1.2) to convey its message and MUST indicate this by 1484 putting zero in the Response field. 1486 The following TLV elements have been defined for the RAMS-I messages: 1488 o Media Sender SSRC (32 bits): Optional TLV element that specifies 1489 the media sender SSRC of the unicast burst stream. While this 1490 information is already available in the message header, it can be 1491 useful to repeat it in an explicit field. If FT_Ap that received 1492 the RAMS-R message is associated with a single primary multicast 1493 stream but the requested media sender SSRC does not match the SSRC 1494 of the RTP stream associated with this FT_Ap, BRS MUST include 1495 this TLV element in the initial RAMS-I message to let RTP_Rx know 1496 that the media sender SSRC has changed. If the two SSRCs match, 1497 there is no need to include this TLV element. 1499 Type: 31 1501 o RTP Seqnum of the First Packet (16 bits): TLV element that 1502 specifies the RTP sequence number of the first packet that will be 1503 sent in the respective RTP stream. This allows RTP_Rx to know 1504 whether one or more packets sent by BRS have been dropped at the 1505 beginning of the stream. If BRS accepts the RAMS request, this 1506 element MUST exist. If BRS rejects the RAMS request, this element 1507 SHALL NOT exist. 1509 Type: 32 1511 o Earliest Multicast Join Time (32 bits): TLV element that 1512 specifies the delta time (in ms) between the arrival of the first 1513 RTP packet in the RTP stream (which could be a burst packet or a 1514 payload-specific packet) and the earliest time instant when RTP_Rx 1515 SHOULD send an SFGMP Join message to join the multicast session. 1516 A zero value in this field means that RTP_Rx can send the SFGMP 1517 Join message right away. 1519 If the RAMS request has been accepted, BRS MUST send this field at 1520 least once, so that RTP_Rx knows when to join the multicast 1521 session. If the burst request has been rejected as indicated in 1522 the Response field, this field MUST be set to zero. In that case, 1523 it is up to RTP_Rx when or whether to join the multicast session. 1525 When BRS serves two or more bursts and sends a separate RAMS-I 1526 message for each burst, the join times specified in these RAMS-I 1527 messages should correspond to more or less the same time instant, 1528 and RTP_Rx sends the SFGMP Join message based on the earliest join 1529 time. 1531 Type: 33 1533 o Burst Duration (32 bits): Optional TLV element that denotes the 1534 duration of the burst, i.e., the delta difference between the 1535 first and the last burst packet, that BRS is planning to send (in 1536 ms) in the respective RTP stream. In the absence of additional 1537 stimulus, BRS will send a burst of this duration. However, the 1538 burst duration can be modified by subsequent events, including 1539 changes in the primary multicast stream and reception of RAMS-T 1540 messages. 1542 BRS MUST terminate the flow in a deterministic timeframe, even if 1543 it does not get a RAMS-T or a BYE from RTP_Rx. It is OPTIONAL to 1544 send this field in a RAMS-I message when the burst request is 1545 accepted. If the burst request has been rejected as indicated in 1546 the Response field, this field MAY be omitted or set to zero. 1548 Type: 34 1550 o Max Transmit Bitrate (64 bits): Optional TLV element that denotes 1551 the maximum bitrate (in bits per second) that will be used by BRS 1552 for the RTP stream associated with this RAMS-I message. 1554 Type: 35 1556 The semantics of the RAMS-I feedback message is independent of the 1557 payload type. 1559 The initial RAMS-I message SHOULD precede the unicast burst or be 1560 sent at the start of the burst. Subsequent RAMS-I message(s) MAY be 1561 sent during the unicast burst and convey changes in any of the 1562 fields. 1564 7.4. RAMS Termination 1566 The RAMS Termination message is identified by SFMT=3. 1568 The RAMS Termination is used to assist BRS in determining when to 1569 stop the burst. A separate RAMS-T message is sent in the unicast 1570 burst RTP session by RTP_Rx for each primary multicast stream that 1571 has been served by BRS. Each of these RAMS-T messages has the 1572 appropriate media sender SSRC populated in its message header. 1574 If RTP_Rx wants BRS to stop a burst prematurely, it sends a plain 1575 RAMS-T message as described below. Upon receiving this message, BRS 1576 stops the respective burst immediately. If RTP_Rx wants BRS to 1577 terminate all of the bursts, it needs to send all of the respective 1578 RAMS-T messages in a single compound RTCP packet. 1580 The default behavior for RTP_Rx is to send a RAMS-T message 1581 immediately after it joined the multicast session and started 1582 receiving multicast packets. In that case, RTP_Rx includes the 1583 sequence number of the first RTP packet received in the primary 1584 multicast stream in the RAMS-T message. With this information, BRS 1585 can decide when to terminate the unicast burst. 1587 The FCI field MUST contain only one RAMS Termination. The FCI field 1588 has the structure depicted in Figure 9. 1590 0 1 2 3 1591 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 | SFMT=3 | Reserved | 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 : Optional TLV-encoded Fields (and Padding, if needed) : 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 Figure 9: FCI field syntax for the RAMS Termination message 1600 o Extended RTP Seqnum of First Multicast Packet (32 bits): Optional 1601 TLV element that specifies the extended RTP sequence number of the 1602 first packet received from the SSM session for a particular 1603 primary multicast stream. The low 16 bits contain the sequence 1604 number of the first packet received from the SSM session, and the 1605 most significant 16 bits extend that sequence number with the 1606 corresponding count of sequence number cycles, which can be 1607 maintained according to the algorithm in Appendix A.1 of 1608 [RFC3550]. 1610 Type: 61 1612 The semantics of the RAMS-T feedback message is independent of the 1613 payload type. 1615 8. SDP Signaling 1617 8.1. Definitions 1619 The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585]. 1620 Here we add the following syntax to the 'rtcp-fb' attribute (the 1621 feedback type and optional parameters are all case sensitive): 1623 (In the following ABNF [RFC5234], fmt, SP and CRLF are used as 1624 defined in [RFC4566].) 1626 rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF 1628 rtcp-fb-pt = "*" ; wildcard: applies to all formats 1629 / fmt ; as defined in SDP spec 1631 rtcp-fb-val = "nack" SP "rai" 1633 The following parameter is defined in this document for use with 1634 'nack': 1636 o 'rai' stands for Rapid Acquisition Indication and indicates the 1637 use of RAMS messages as defined in Section 7. 1639 This document also defines a new media-level SDP attribute ('rams- 1640 updates') that indicates whether BRS supports updated request 1641 messages or not. This attribute is used in a declarative manner and 1642 no Offer/Answer Model behavior is specified. If BRS supports updated 1643 request messages and this attribute is included in the SDP 1644 description, RTP_Rx can send updated requests. BRS might or might 1645 not be able to accept value changes in every field in an updated 1646 RAMS-R message. However, if the 'rams-updates' attribute is not 1647 included in the SDP description, RTP_Rx SHALL NOT send updated 1648 requests. RTP_Rx MAY still repeat its initial request without 1649 changes, though. 1651 8.2. Requirements 1653 The use of SDP to describe the RAMS entities normatively requires the 1654 support for: 1656 o The SDP grouping framework and flow identification (FID) semantics 1657 [I-D.ietf-mmusic-rfc3388bis] 1659 o The RTP/AVPF profile [RFC4585] 1661 o The RTP retransmission payload format [RFC4588] 1663 o The RTCP extensions for SSM sessions with unicast feedback 1664 [RFC5760] 1666 o The multicast RTCP port attribute 1667 [I-D.begen-avt-rtcp-port-for-ssm] 1669 o Multiplexing RTP and RTCP on a single port on both endpoints in 1670 the unicast session[RFC5761] 1672 The support for the source-specific media attributes [RFC5576] can 1673 also be needed. 1675 8.3. Example and Discussion 1677 This section provides a declarative SDP [RFC4566] example for 1678 enabling rapid acquisition of multicast RTP sessions. 1680 v=0 1681 o=ali 1122334455 1122334466 IN IP4 rams.example.com 1682 s=Rapid Acquisition Example 1683 t=0 0 1684 a=group:FID 1 2 1685 a=rtcp-unicast:rsi 1686 m=video 41000 RTP/AVPF 98 1687 i=Primary Multicast Stream 1688 c=IN IP4 233.252.0.2/255 1689 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 1690 a=rtpmap:98 MP2T/90000 1691 a=multicast-rtcp:42000 1692 a=rtcp:43000 IN IP4 192.0.2.1 1693 a=rtcp-fb:98 nack 1694 a=rtcp-fb:98 nack rai 1695 a=ssrc:123321 cname:iptv-ch32@rams.example.com 1696 a=rams-updates 1697 a=mid:1 1698 m=video 51000 RTP/AVPF 99 1699 i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support) 1700 c=IN IP4 192.0.2.1 1701 a=sendonly 1702 a=rtpmap:99 rtx/90000 1703 a=rtcp-mux 1704 a=fmtp:99 apt=98;rtx-time=5000 1705 a=mid:2 1707 Figure 10: Example SDP for a single-channel RAMS scenario 1709 In this example SDP description, we have a primary multicast (source) 1710 stream and a unicast retransmission stream. The source stream is 1711 multicast from a distribution source (with a source IP address of 1712 198.51.100.1) to the multicast destination address of 233.252.0.2 and 1713 port 41000. The corresponding RTCP traffic is multicast to the same 1714 multicast destination address at port 42000. Here, we are assuming 1715 that the multicast RTP and RTCP ports are carefully chosen so that 1716 different RTP and RTCP streams do not collide with each other. 1718 The feedback target (FT_Ap) residing on RS (with an address of 1719 192.0.2.1) at port 43000 is declared with the "a=rtcp" line 1720 [RFC3605]. The support for the conventional retransmission is 1721 indicated through the "a=rtcp-fb:98 nack" line. The RTP receiver(s) 1722 can report missing packets on the source stream to the feedback 1723 target and request retransmissions. The SDP above includes the 1724 "a=sendonly" line for the media description of the retransmission 1725 stream since the retransmissions are sent in only one direction. 1727 The support for rapid acquisition is indicated through the "a=rtcp- 1728 fb:98 nack rai" line. The parameter 'rtx-time' applies to both the 1729 conventional retransmissions and rapid acquisition. However, when 1730 rapid acquisition is enabled, the standard definition for the 1731 parameter 'rtx-time' given in [RFC4588] is not followed. Instead, 1732 when rapid acquisition support is enabled, 'rtx-time' specifies the 1733 time in milliseconds that BRS keeps an RTP packet in its cache 1734 available for retransmission (measured from the time the packet was 1735 received by BRS, not from the time indicated in the packet 1736 timestamp). 1738 Once an RTP_Rx has acquired an SDP description, it can ask for rapid 1739 acquisition before it joins a primary multicast RTP session. To do 1740 so, it sends a RAMS-R message to the feedback target of that primary 1741 multicast RTP session. If FT_Ap is associated with only one RTP 1742 stream, RTP_Rx does not need to learn the SSRC of that stream via an 1743 out-of-band method. If BRS accepts the rapid acquisition request, it 1744 will send an RAMS-I message with the correct SSRC identifier. If 1745 FT_Ap is associated with a multi-stream RTP session and RTP_Rx is 1746 willing to request rapid acquisition for the entire session, RTP_Rx 1747 again does not need to learn the SSRCs via an out-of-band method. 1748 However, if RTP_Rx intends to request a particular subset of the 1749 primary multicast streams, it must learn their SSRC identifiers and 1750 list them in the RAMS-R message. Since this RTP_Rx has not yet 1751 received any RTP packets for the primary multicast stream(s), RTP_Rx 1752 must in this case learn the SSRC value(s) from the 'ssrc' attribute 1753 of the media description [RFC5576]. In addition to the SSRC value, 1754 the 'cname' source attribute must also be present in the SDP 1755 description [RFC5576]. 1757 Listing the SSRC values for the primary multicast streams in the SDP 1758 file does not create a problem in SSM sessions when an SSRC collision 1759 occurs. This is because in SSM sessions, an RTP_Rx that observed an 1760 SSRC collision with a media sender must change its own SSRC [RFC5760] 1761 by following the rules defined in [RFC3550]. 1763 A feedback target that receives a RAMS-R feedback message becomes 1764 aware that the prediction chain at RTP_Rx side has been broken or 1765 does not exist anymore. If the necessary conditions are satisfied 1766 (as outlined in Section 7 of [RFC4585]) and available resources 1767 exist, BRS can react to the RAMS-R message by sending any transport- 1768 layer (and optional payload-specific, when allowed) feedback 1769 message(s) and starting the unicast burst. 1771 In this section, we considered the simplest scenario where the 1772 primary multicast RTP session carried only one stream and RTP_Rx 1773 wanted to rapidly acquire this stream only. Best practices for 1774 scenarios where the primary multicast RTP session carries two or more 1775 streams or RTP_Rx wants to acquire one or more streams from multiple 1776 primary multicast RTP sessions at the same time are presented in 1777 [I-D.begen-avt-rams-scenarios]. 1779 9. NAT Considerations 1781 For a variety of reasons, one or more NAPT devices (hereafter simply 1782 called NAT) can exist between RTP_Rx and RS. NATs have a variety of 1783 operating characteristics for UDP traffic [RFC4787]. For a NAT to 1784 permit traffic from BRS to arrive at RTP_Rx, the NAT(s) must first 1785 either: 1787 a. See UDP traffic sent from RTP_Rx (which is on the 'inside' of the 1788 NAT) to BRS (which is on the 'outside' of the NAT). This traffic 1789 has the same transport address as the subsequent response 1790 traffic, or; 1792 b. Be configured to forward certain ports (e.g., using HTML 1793 configuration, UPnP IGD [UPnP-IGD], DLNA [DLNA]). Details of 1794 this are out of scope of this document. 1796 For both (a) and (b), RTP_Rx is responsible for maintaining the NAT's 1797 state if it wants to receive traffic from the BRS on that port. For 1798 (a), RTP_Rx MUST send UDP traffic to keep the NAT binding alive, at 1799 least every 30 seconds [RFC4787]. While (a) is more like an 1800 automatic/dynamic configuration, (b) is more like a manual/static 1801 configuration. 1803 When RTP_Rx sends a request (RAMS-R) message to FT as unicast 1804 feedback in the primary multicast RTP session, and the request is 1805 received by FT, a new unicast burst RTP session will be established 1806 between BRS and RTP_Rx. 1808 While the FT and BRS ports on RS are already signaled via out-of-band 1809 means (e.g., SDP), RTP_Rx needs to convey the RTP and RTCP ports it 1810 wants to use on its side for the new session. Since there are two 1811 RTP sessions (one multicast and one unicast) involved during this 1812 process and one of them is established upon a feedback message sent 1813 in the other one, this requires an explicit port mapping method. 1814 This problem equally applies to scenarios where the RTP media is 1815 multicast in an SSM session, and an RTP_Rx requests retransmission 1816 from a local repair server by using the RTCP NACK messages for the 1817 missing packets and the repair server retransmits the requested 1818 packets over a unicast session. Thus, instead of laying out a 1819 specific solution for the RAMS applications, a general solution is 1820 introduced in [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. This generic 1821 solution implies the exchange of port mapping RTCP messages between 1822 RTP_Rx and BRS. 1824 Applications using RAMS MUST support the solution presented in 1825 [I-D.ietf-avt-ports-for-ucast-mcast-rtp] both on the RS and RTP_Rx 1826 side to allow RTP receivers to use their desired ports and to support 1827 RAMS behind NAT devices. The port mapping message exchange needs to 1828 take place whenever RTP_Rx intends to make use of the RAMS protocol 1829 for rapidly acquiring a specific multicast RTP session, prior to 1830 joining the associated SSM session. 1832 10. Security Considerations 1834 Applications that are using RAMS make heavy use of the unicast 1835 feedback mechanism described in [RFC5760], the payload format defined 1836 in [RFC4588] and the port mapping solution specified in 1837 [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. Thus, these applications 1838 are subject to the general security considerations discussed in 1839 [RFC5760], [RFC4588] and [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. 1840 In this section, we give an overview of the guidelines and 1841 suggestions described in these specifications from a RAMS 1842 perspective. We also discuss the security considerations that 1843 explicitly apply to applications using RAMS. 1845 First of all, much of the session description information is 1846 available in the SDP descriptions that are distributed to the media 1847 senders, retransmission servers and RTP receivers. Adequate security 1848 measures are RECOMMENDED to ensure the integrity and authenticity of 1849 the SDP descriptions so that transport addresses of the media 1850 senders, distribution sources, feedback targets as well as other 1851 session-specific information can be protected. 1853 Compared to an RTCP NACK message that triggers one or more 1854 retransmissions, a RAMS Request (RAMS-R) message can trigger a new 1855 burst stream to be sent by the retransmission server. Depending on 1856 the application-specific requirements and conditions existing at the 1857 time of the RAMS-R reception by the retransmission server, the 1858 resulting burst stream can potentially contain a large number of 1859 retransmission packets. Since these packets are sent at a faster 1860 than the nominal rate, RAMS consumes more resources on the 1861 retransmission servers, RTP receivers and the network. In 1862 particular, this can make denial-of-service attacks more intense, and 1863 hence, more harmful than attacks that target ordinary retransmission 1864 sessions. 1866 Following the suggestions given in [RFC4588], counter-measures SHOULD 1867 be taken to prevent tampered or spoofed RTCP packets. Tampered 1868 RAMS-R messages can trigger inappropriate burst streams or alter the 1869 existing burst streams in an inappropriate way. For example, if the 1870 Max Receive Bitrate field is altered by a tampered RAMS-R message, 1871 the updated burst can overflow the buffer at the receiver side, or 1872 oppositely, can slow down the burst to the point that it becomes 1873 useless. Tampered RAMS Termination (RAMS-T) messages can terminate 1874 valid burst streams prematurely resulting in gaps in the received RTP 1875 packets. RAMS Information (RAMS-I) messages contain fields that are 1876 critical for a successful rapid acquisition. Any tampered 1877 information in the RAMS-I message can easily cause an RTP receiver to 1878 make wrong decisions. Consequently, the RAMS operation can fail. 1880 While most of the denial-of-service attacks can be prevented by the 1881 integrity and authenticity checks enabled by Secure RTP (SRTP) 1882 [RFC3711], an attack can still be started by legitimate endpoints 1883 that send several valid RAMS-R messages to a particular feedback 1884 target in a synchronized fashion and very short amount of time. 1885 Since a RAMS operation can temporarily consume a large amount of 1886 resources, a series of the RAMS-R messages can temporarily overload 1887 the retransmission server. In these circumstances, the 1888 retransmission server can, for example, reject incoming RAMS requests 1889 until its resources become available again. One means to ameliorate 1890 this threat is to apply a per-endpoint policing mechanism on the 1891 incoming RAMS requests. A reasonable policing mechanism should 1892 consider application-specific requirements and minimize false 1893 negatives. 1895 In addition to the denial-of-service attacks, man-in-the-middle and 1896 replay attacks can also be harmful. However, RAMS itself does not 1897 bring any new risks or threats other than the ones discussed in 1898 [RFC5760]. 1900 [RFC4588] RECOMMENDS that the cryptography mechanisms are used for 1901 the retransmission payload format to provide protection against known 1902 plain-text attacks. As discussed in [RFC4588], the retransmission 1903 payload format sets the timestamp field in the RTP header to the 1904 media timestamp of the original packet and this does not compromise 1905 the confidentiality. Furthermore, if cryptography is used to provide 1906 security services on the original stream, then the same services, 1907 with equivalent cryptographic strength, MUST be provided on the 1908 retransmission stream per [RFC4588]. 1910 To protect the RTCP messages from man-in-the-middle and replay 1911 attacks, the RTP receivers and retransmission server SHOULD perform a 1912 DTLS-SRTP handshake [RFC5764] over the RTCP channel. Because there 1913 is no integrity-protected signaling channel between an RTP receiver 1914 and the retransmission server, the retransmission server MUST 1915 maintain a list of certificates owned by legitimate RTP receivers, or 1916 their certificates MUST be signed by a trusted Certificate Authority. 1918 Once the DTLS-SRTP security is established, non-SRTCP-protected 1919 messages received from a particular RTP receiver are ignored by the 1920 retransmission server. To reduce the impact of DTLS-SRTP overhead 1921 when communicating with different feedback targets on the same 1922 retransmission server, it is RECOMMENDED that RTP receivers and the 1923 retransmission server both support TLS Session Resumption without 1924 Server-side State [RFC5077]. To help scale SRTP to handle many RTP 1925 receivers asking for retransmissions of identical data, implementors 1926 may consider using the same SRTP key for SRTP data sent to the 1927 receivers [I-D.ietf-avt-srtp-ekt] and consider the security of such 1928 SRTP key sharing. 1930 11. IANA Considerations 1932 The following contact information shall be used for all registrations 1933 in this document: 1935 Ali Begen 1936 abegen@cisco.com 1938 Note to the RFC Editor: In the following, please replace "XXXX" with 1939 the number of this document prior to publication as an RFC. 1941 11.1. Registration of SDP Attributes 1943 This document registers a new attribute name in SDP. 1945 SDP Attribute ("att-field"): 1946 Attribute name: rams-updates 1947 Long form: Support for Updated RAMS Request Messages 1948 Type of name: att-field 1949 Type of attribute: Media level 1950 Subject to charset: No 1951 Purpose: See this document 1952 Reference: [RFCXXXX] 1953 Values: None 1955 11.2. Registration of SDP Attribute Values 1957 This document registers a new value for the 'nack' attribute to be 1958 used with the 'rtcp-fb' attribute in SDP. For more information about 1959 the 'rtcp-fb' attribute, refer to Sections 4.2 and 6.2 of [RFC4585]. 1961 Value name: rai 1962 Long name: Rapid Acquisition Indication 1963 Usable with: nack 1964 Reference: [RFCXXXX] 1966 11.3. Registration of FMT Values 1968 Within the RTPFB range, the following format (FMT) value is 1969 registered: 1971 Name: RAMS 1972 Long name: Rapid Acquisition of Multicast Sessions 1973 Value: 6 1974 Reference: [RFCXXXX] 1976 11.4. SFMT Values for RAMS Messages Registry 1978 This document creates a new sub-registry for the sub-feedback message 1979 type (SFMT) values to be used with the FMT value registered for RAMS 1980 messages. The registry is called the SFMT Values for RAMS Messages 1981 Registry. This registry is to be managed by the IANA according to 1982 the Specification Required policy of [RFC5226]. 1984 The length of the SFMT field in the RAMS messages is a single octet, 1985 allowing 256 values. The registry is initialized with the following 1986 entries: 1988 Value Name Reference 1989 ----- -------------------------------------------------- ------------- 1990 0 Reserved [RFCXXXX] 1991 1 RAMS Request [RFCXXXX] 1992 2 RAMS Information [RFCXXXX] 1993 3 RAMS Termination [RFCXXXX] 1994 4-254 Assignable - Specification Required 1995 255 Reserved [RFCXXXX] 1997 The SFMT values 0 and 255 are reserved for future use. 1999 Any registration for an unassigned SFMT value MUST contain the 2000 following information: 2002 o Contact information of the one doing the registration, including 2003 at least name, address, and email. 2005 o A detailed description of what the new SFMT represents and how it 2006 shall be interpreted. 2008 New RAMS functionality is intended to be introduced by using the 2009 extension mechanism within the existing RAMS message types not by 2010 introducing new message types unless it is absolutely necessary. 2012 11.5. RAMS TLV Space Registry 2014 This document creates a new IANA TLV space registry for the RAMS 2015 extensions. The registry is called the RAMS TLV Space Registry. 2016 This registry is to be managed by the IANA according to the 2017 Specification Required policy of [RFC5226]. 2019 The length of the Type field in the TLV elements is a single octet, 2020 allowing 256 values. The Type values 0 and 255 are reserved for 2021 future use. The Type values between (and including) 128 and 254 are 2022 reserved for private extensions. 2024 The registry is initialized with the following entries: 2026 Type Description Reference 2027 ---- -------------------------------------------------- ------------- 2028 0 Reserved [RFCXXXX] 2029 1 Requested Media Sender SSRC(s) [RFCXXXX] 2030 2 Min RAMS Buffer Fill Requirement [RFCXXXX] 2031 3 Max RAMS Buffer Fill Requirement [RFCXXXX] 2032 4 Max Receive Bitrate [RFCXXXX] 2033 5 Request for Preamble Only [RFCXXXX] 2034 6-30 Assignable - Specification Required 2035 31 Media Sender SSRC [RFCXXXX] 2036 32 RTP Seqnum of the First Packet [RFCXXXX] 2037 33 Earliest Multicast Join Time [RFCXXXX] 2038 34 Burst Duration [RFCXXXX] 2039 35 Max Transmit Bitrate [RFCXXXX] 2040 36-60 Assignable - Specification Required 2041 61 Extended RTP Seqnum of First Multicast Packet [RFCXXXX] 2042 62-127 Assignable - Specification Required 2043 128-254 No IANA Maintenance 2044 255 Reserved [RFCXXXX] 2046 Any registration for an unassigned Type value MUST contain the 2047 following information: 2049 o Contact information of the one doing the registration, including 2050 at least name, address, and email. 2052 o A detailed description of what the new TLV element represents and 2053 how it shall be interpreted. 2055 11.6. RAMS Response Code Space Registry 2057 This document creates a new IANA TLV space registry for the RAMS 2058 response codes. The registry is called the RAMS Response Code Space 2059 Registry. This registry is to be managed by the IANA according to 2060 the Specification Required policy of [RFC5226]. 2062 The length of the Response field is two octets, allowing 65536 codes. 2063 However, the response codes have been classified and registered 2064 following an HTTP-style code numbering in this document. New 2065 response codes should be classified following the guidelines below: 2067 Code Level Purpose 2068 ---------- --------------- 2069 1xx Informational 2070 2xx Success 2071 3xx Redirection 2072 4xx RTP Receiver Error 2073 5xx Retransmission Server Error 2075 The Response code 65536 is reserved for future use. 2077 The registry is initialized with the following entries: 2079 Code Description Reference 2080 ----- -------------------------------------------------- ------------- 2081 0 A private response code is included in the message [RFCXXXX] 2083 100 Parameter update for RAMS session [RFCXXXX] 2085 200 RAMS request has been accepted [RFCXXXX] 2086 201 Unicast burst has been completed [RFCXXXX] 2088 400 Invalid RAMS-R message syntax 2089 401 Invalid min buffer requirement in RAMS-R message [RFCXXXX] 2090 402 Invalid max buffer requirement in RAMS-R message [RFCXXXX] 2091 403 Invalid max bitrate requirement in RAMS-R message [RFCXXXX] 2093 500 An unspecified BRS internal error has occurred [RFCXXXX] 2094 501 BRS has insufficient bandwidth to start RAMS 2095 session [RFCXXXX] 2096 502 Burst is terminated due to network congestion [RFCXXXX] 2097 503 BRS has insufficient CPU cycles to start RAMS 2098 session [RFCXXXX] 2099 504 RAMS functionality is not available on BRS [RFCXXXX] 2100 505 RAMS functionality is not available for RTP_Rx [RFCXXXX] 2101 506 RAMS functionality is not available for 2102 the requested multicast stream [RFCXXXX] 2103 507 BRS has no valid starting point available for 2104 the requested multicast stream [RFCXXXX] 2105 508 BRS has no reference information available for 2106 the requested multicast stream [RFCXXXX] 2107 509 BRS has no RTP stream matching the requested SSRC [RFCXXXX] 2108 510 RAMS request to acquire the entire session 2109 has been denied [RFCXXXX] 2110 511 Only the preamble information is sent [RFCXXXX] 2111 512 RAMS request has been denied due to a policy [RFCXXXX] 2113 Any registration for an unassigned Response code MUST contain the 2114 following information: 2116 o Contact information of the one doing the registration, including 2117 at least name, address, and email. 2119 o A detailed description of what the new Response code describes and 2120 how it shall be interpreted. 2122 12. Contributors 2124 Dave Oran, Magnus Westerlund and Colin Perkins have contributed 2125 significantly to this specification by providing text and solutions 2126 to some of the issues raised during the development of this 2127 specification. 2129 13. Acknowledgments 2131 The following individuals have reviewed the earlier versions of this 2132 specification and provided helpful comments: Colin Perkins, Joerg 2133 Ott, Roni Even, Dan Wing, Tony Faustini, Peilin Yang, Jeff Goldberg, 2134 Muriel Deschanel, Orit Levin, Guy Hirson, Tom Taylor, Xavier Marjou, 2135 Ye-Kui Wang, Zixuan Zou, Ingemar Johansson, Haibin Song, Ning Zong, 2136 Jonathan Lennox, Jose Rey, Sean Sheedy and Keith Drage. 2138 14. References 2140 14.1. Normative References 2142 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2143 Jacobson, "RTP: A Transport Protocol for Real-Time 2144 Applications", STD 64, RFC 3550, July 2003. 2146 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2147 Requirement Levels", BCP 14, RFC 2119, March 1997. 2149 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2150 Thyagarajan, "Internet Group Management Protocol, Version 2151 3", RFC 3376, October 2002. 2153 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 2154 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 2156 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 2157 Group Management Protocol Version 3 (IGMPv3) and Multicast 2158 Listener Discovery Protocol Version 2 (MLDv2) for Source- 2159 Specific Multicast", RFC 4604, August 2006. 2161 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2162 Description Protocol", RFC 4566, July 2006. 2164 [I-D.ietf-mmusic-rfc3388bis] 2165 Camarillo, G. and H. Schulzrinne, "The SDP (Session 2166 Description Protocol) Grouping Framework", 2167 draft-ietf-mmusic-rfc3388bis-04 (work in progress), 2168 November 2009. 2170 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2171 "Extended RTP Profile for Real-time Transport Control 2172 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2173 July 2006. 2175 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 2176 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 2177 July 2006. 2179 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 2180 Protocol (RTCP) Extensions for Single-Source Multicast 2181 Sessions with Unicast Feedback", RFC 5760, February 2010. 2183 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2184 Media Attributes in the Session Description Protocol 2185 (SDP)", RFC 5576, June 2009. 2187 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2188 in Session Description Protocol (SDP)", RFC 3605, 2189 October 2003. 2191 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2192 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2194 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 2195 Real-Time Transport Control Protocol (RTCP): Opportunities 2196 and Consequences", RFC 5506, April 2009. 2198 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 2199 Header Extensions", RFC 5285, July 2008. 2201 [I-D.begen-avt-rtp-cnames] 2202 Begen, A., Perkins, C., and D. Wing, "Guidelines for 2203 Choosing RTP Control Protocol (RTCP) Canonical Names 2204 (CNAMEs)", draft-begen-avt-rtp-cnames-02 (work in 2205 progress), May 2010. 2207 [I-D.ietf-avt-rapid-rtp-sync] 2208 Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 2209 Flows", draft-ietf-avt-rapid-rtp-sync-10 (work in 2210 progress), May 2010. 2212 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2213 Control Packets on a Single Port", RFC 5761, April 2010. 2215 [I-D.begen-avt-rtcp-port-for-ssm] 2216 Begen, A., "RTP Control Protocol (RTCP) Port for Multicast 2217 Sessions", draft-begen-avt-rtcp-port-for-ssm-01 (work in 2218 progress), April 2010. 2220 [I-D.ietf-avt-ports-for-ucast-mcast-rtp] 2221 Begen, A. and B. Steeg, "Port Mapping Between Unicast and 2222 Multicast RTP Sessions", 2223 draft-ietf-avt-ports-for-ucast-mcast-rtp-02 (work in 2224 progress), May 2010. 2226 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2227 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2228 RFC 3711, March 2004. 2230 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2231 Security (DTLS) Extension to Establish Keys for the Secure 2232 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 2234 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 2235 "Transport Layer Security (TLS) Session Resumption without 2236 Server-Side State", RFC 5077, January 2008. 2238 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2239 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2240 May 2008. 2242 14.2. Informative References 2244 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2245 August 1980. 2247 [I-D.begen-avt-rams-scenarios] 2248 Begen, A., "Considerations for RAMS Scenarios", 2249 draft-begen-avt-rams-scenarios-00 (work in progress), 2250 October 2009. 2252 [I-D.ietf-avt-multicast-acq-rtcp-xr] 2253 Begen, A. and E. Friedrich, "Multicast Acquisition Report 2254 Block Type for RTP Control Protocol (RTCP) Extended 2255 Reports (XRs)", draft-ietf-avt-multicast-acq-rtcp-xr-01 2256 (work in progress), May 2010. 2258 [I-D.ietf-avt-ecn-for-rtp] 2259 Westerlund, M., Johansson, I., Perkins, C., and K. 2260 Carlberg, "Explicit Congestion Notification (ECN) for RTP 2261 over UDP", draft-ietf-avt-ecn-for-rtp-01 (work in 2262 progress), March 2010. 2264 [I-D.ietf-fecframe-interleaved-fec-scheme] 2265 Begen, A., "RTP Payload Format for 1-D Interleaved Parity 2266 FEC", draft-ietf-fecframe-interleaved-fec-scheme-09 (work 2267 in progress), January 2010. 2269 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 2270 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 2271 RFC 4787, January 2007. 2273 [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control 2274 Protocol (DCCP)", RFC 5762, April 2010. 2276 [I-D.ietf-avt-srtp-ekt] 2277 McGrew, D., Andreasen, F., Wing, D., and L. Dondeti, 2278 "Encrypted Key Transport for Secure RTP", 2279 draft-ietf-avt-srtp-ekt-00 (work in progress), March 2010. 2281 [UPnP-IGD] 2282 Forum, UPnP., "Universal Plug and Play (UPnP) Internet 2283 Gateway Device (IGD)", November 2001. 2285 [DLNA] , DLNA., "http://www.dlna.org/home". 2287 [IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing 2288 Channel Change Times in IPTV with Real-Time Transport 2289 Protocol (IEEE Internet Computing)", May 2009. 2291 Authors' Addresses 2293 Bill VerSteeg 2294 Cisco 2295 5030 Sugarloaf Parkway 2296 Lawrenceville, GA 30044 2297 USA 2299 Email: billvs@cisco.com 2301 Ali Begen 2302 Cisco 2303 181 Bay Street 2304 Toronto, ON M5J 2T3 2305 CANADA 2307 Email: abegen@cisco.com 2308 Tom VanCaenegem 2309 Alcatel-Lucent 2310 Copernicuslaan 50 2311 Antwerpen, 2018 2312 Belgium 2314 Email: Tom.Van_Caenegem@alcatel-lucent.be 2316 Zeev Vax 2317 Microsoft Corporation 2318 1065 La Avenida 2319 Mountain View, CA 94043 2320 USA 2322 Email: zeevvax@microsoft.com