idnits 2.17.1 draft-ietf-avt-rapid-acquisition-for-rtp-17.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 609 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 (November 18, 2010) is 4901 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 2348, 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 (-04) exists of draft-ietf-avt-rtcp-port-for-ssm-03 == 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) == Outdated reference: A later version (-01) exists of draft-begen-avt-rams-scenarios-00 == Outdated reference: A later version (-05) exists of draft-ietf-avt-rtp-cnames-02 == Outdated reference: A later version (-03) exists of draft-ietf-avt-srtp-ekt-01 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 3 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: May 22, 2011 T. VanCaenegem 6 Alcatel-Lucent 7 Z. Vax 8 Microsoft Corporation 9 November 18, 2010 11 Unicast-Based Rapid Acquisition of Multicast RTP Sessions 12 draft-ietf-avt-rapid-acquisition-for-rtp-17 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 RTP 28 Control Protocol (RTCP) machinery that reduces the acquisition delay. 29 In this method, an auxiliary unicast RTP session carrying the 30 Reference Information to the receiver precedes/accompanies the 31 multicast stream. This unicast RTP flow can be transmitted at a 32 faster than natural bitrate to further accelerate the acquisition. 33 The motivating use case for this capability is multicast applications 34 that carry real-time compressed audio and video. However, this 35 method can also be used in other types of multicast applications 36 where the acquisition delay is long enough to be a problem. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on May 22, 2011. 55 Copyright Notice 57 Copyright (c) 2010 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 This document may contain material from IETF Documents or IETF 71 Contributions published or made publicly available before November 72 10, 2008. The person(s) controlling the copyright in some of this 73 material may not have granted the IETF Trust the right to allow 74 modifications of such material outside the IETF Standards Process. 75 Without obtaining an adequate license from the person(s) controlling 76 the copyright in such materials, this document may not be modified 77 outside the IETF Standards Process, and derivative works of it may 78 not be created outside the IETF Standards Process, except to format 79 it for publication as an RFC or to translate it into languages other 80 than English. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 85 1.1. Acquisition of RTP Streams vs. RTP Sessions . . . . . . . 7 86 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 7 87 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7 88 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 89 4. Elements of Delay in Multicast Applications . . . . . . . . . 9 90 5. Protocol Design Considerations and Their Effect on 91 Resource Management for Rapid Acquisition . . . . . . . . . . 10 92 6. Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . 13 93 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13 94 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13 95 6.3. Synchronization of Primary Multicast Streams . . . . . . . 24 96 6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 24 97 6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27 98 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 28 99 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 29 100 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 30 101 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 30 102 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 31 103 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 34 104 7.3.1. Response Code Definitions . . . . . . . . . . . . . . 37 105 7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 38 106 8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 40 107 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 40 108 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 40 109 8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 41 110 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 44 111 10. Security Considerations . . . . . . . . . . . . . . . . . . . 45 112 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 113 11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 48 114 11.2. Registration of SDP Attribute Values . . . . . . . . . . . 48 115 11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 48 116 11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 49 117 11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 49 118 11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 50 119 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53 120 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 121 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 122 14.1. Normative References . . . . . . . . . . . . . . . . . . . 53 123 14.2. Informative References . . . . . . . . . . . . . . . . . . 55 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 126 1. Introduction 128 Most multicast flows carry a stream of inter-related data. Receivers 129 need to acquire certain information to start processing any data sent 130 in the multicast session. This document refers to this information 131 as Reference Information. The Reference Information is 132 conventionally sent periodically in the multicast session (although 133 its content can change over time) and usually consists of items such 134 as a description of the schema for the rest of the data, references 135 to which data to process, encryption information including keys, as 136 well as any other information required to process the data in the 137 multicast stream [IC2009]. 139 Real-time multicast applications require receivers to buffer data. 140 Receivers may have to buffer data to smooth out the network jitter, 141 to allow loss-repair methods such as Forward Error Correction and 142 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 the whole 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 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 wants to 163 join the multicast session and the time the RTP receiver acquires all 164 the 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. While 173 this problem equally applies to both any-source (ASM) and source- 174 specific (SSM) multicast applications, in this specification we 175 address it for the SSM-based multicast applications by describing a 176 method that uses the fundamental tools offered by the existing RTP 177 and RTCP protocols [RFC3550]. In this method, either the multicast 178 source (or the distribution source in an SSM session) retains the 179 Reference Information for a period after its transmission, or an 180 intermediary network element (that we refer to as Retransmission 181 Server) joins the multicast session and continuously caches the 182 Reference Information as it is sent in the session and acts as a 183 feedback target (See [RFC5760]) for the session. When an RTP 184 receiver wishes to join the same multicast session, instead of simply 185 issuing a Source Filtering Group Management Protocol (SFGMP) Join 186 message, it sends a request to the feedback target for the session 187 and asks for the Reference Information. The retransmission server 188 starts a new unicast RTP (retransmission) session and sends the 189 Reference Information to the RTP receiver over that session. If 190 there is residual bandwidth, the retransmission server might burst 191 the Reference Information faster than its natural rate. As soon as 192 the receiver acquires the Reference Information, it can join the 193 multicast session and start processing the multicast data. A 194 simplified network diagram showing this method through an 195 intermediary network element is depicted in Figure 1. 197 This method potentially reduces the acquisition delay. We refer to 198 this method as Unicast-based Rapid Acquisition of Multicast RTP 199 Sessions. A primary use case for this method is to reduce the 200 channel-change times in IPTV networks where compressed video streams 201 are multicast in different SSM sessions and viewers randomly join 202 these sessions. 204 ----------------------- 205 +--->| Intermediary | 206 | | Network Element | 207 | ...|(Retransmission Server)| 208 | : ----------------------- 209 | : 210 | v 211 ----------- ---------- ---------- 212 | Multicast | | |---------->| Joining | 213 | Source |------->| Router |..........>| RTP | 214 | | | | | Receiver | 215 ----------- ---------- ---------- 216 | 217 | ---------- 218 +---------------->| Existing | 219 | RTP | 220 | Receiver | 221 ---------- 223 -------> Multicast RTP Flow 224 .......> Unicast RTP Flow 226 Figure 1: Rapid acquisition through an intermediary network element 228 A principle design goal in this solution is to use the existing tools 229 in the RTP/RTCP protocol family. This improves the versatility of 230 the existing implementations, and promotes faster deployment and 231 better interoperability. To this effect, we use the unicast 232 retransmission support of RTP [RFC4588] and the capabilities of RTCP 233 to handle the signaling needed to accomplish the acquisition. 235 A reasonable effort has been made in this specification to design a 236 solution that reliably works in both engineered and best-effort 237 networks. However, a proper congestion control combined with the 238 desired behavior of this solution is difficult to achieve. Rather, 239 this solution has been designed based on an assumption that the 240 retransmission server and the RTP receivers have some knowledge about 241 where the bottleneck between them is. This assumption does not 242 generally hold unless both the retransmission server and the RTP 243 receivers are in the same edge network. Thus, this solution should 244 not be used across any best-effort path of the Internet. 245 Furthermore, this solution should only be used in networks that are 246 already carrying non-congestion-responsive multicast traffic and have 247 throttling mechanisms in the retransmission servers to ensure the 248 (unicast) burst traffic is a known constant upper-bound multiplier on 249 the multicast load. 251 1.1. Acquisition of RTP Streams vs. RTP Sessions 253 In this memo we describe a protocol that handles the rapid 254 acquisition of a single multicast RTP session (called primary 255 multicast RTP session) carrying one or more RTP streams (called 256 primary multicast streams). If desired, multiple instances of this 257 protocol may be run in parallel to acquire multiple RTP sessions 258 simultaneously. 260 When an RTP receiver requests the Reference Information from the 261 retransmission server, it can opt to rapidly acquire a specific 262 subset of the available RTP streams in the primary multicast RTP 263 session. Alternatively, the RTP receiver can request the rapid 264 acquisition of all of the RTP streams in that RTP session. 265 Regardless of how many RTP streams are requested by the RTP receiver 266 or how many will be actually sent by the retransmission server, only 267 one unicast RTP session will be established by the retransmission 268 server. This unicast RTP session is separate from the associated 269 primary multicast RTP session. As a result, there are always two 270 different RTP sessions in a single instance of the rapid acquisition 271 protocol: (i) the primary multicast RTP session with its associated 272 unicast feedback and (ii) the unicast RTP session. 274 If the RTP receiver wants to rapidly acquire multiple RTP sessions 275 simultaneously, separate unicast RTP sessions will be established for 276 each of them. 278 1.2. Outline 280 In the rest of this specification, we have the following outline: In 281 Section 4, we describe the delay components in generic multicast 282 applications. Section 5 presents an overview of the protocol design 283 considerations for rapid acquisition. We provide the protocol 284 details of the rapid acquisition method in Section 6 and Section 7. 285 Section 8 and Section 9 discuss the SDP signaling issues with 286 examples and NAT-related issues, respectively. Finally, Section 10 287 discusses the security considerations. 289 Section 3 provides a list of the definitions frequently used in this 290 document. 292 2. Requirements Notation 294 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 295 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 296 document are to be interpreted as described in [RFC2119]. 298 3. Definitions 300 This document uses the following acronyms and definitions frequently: 302 (Primary) SSM (or Multicast) Session: The multicast session to which 303 RTP receivers can join at a random point in time. A primary SSM 304 session can carry multiple RTP streams. 306 Primary Multicast RTP Session: The multicast RTP session an RTP 307 receiver is interested in acquiring rapidly. From the RTP receiver's 308 viewpoint, the primary multicast RTP session has one associated 309 unicast RTCP feedback stream to a Feedback Target, in addition to the 310 primary multicast RTP stream(s). 312 Primary Multicast (RTP) Streams: The RTP stream(s) carried in the 313 primary multicast RTP session. 315 Source Filtering Group Management Protocol (SFGMP): Following the 316 definition in [RFC4604], SFGMP refers to the Internet Group 317 Management Protocol (IGMP) version 3 [RFC3376] and the Multicast 318 Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and 319 IPv6 networks, respectively. However, the rapid acquisition method 320 introduced in this document does not depend on a specific version of 321 either of these group management protocols. In the remainder of this 322 document, SFGMP will refer to any group management protocol that has 323 Join and Leave functionalities. 325 Feedback Target (FT): Unicast RTCP feedback target as defined in 326 [RFC5760]. FT_Ap denotes a specific feedback target running on a 327 particular address and port. 329 Retransmission (or Burst) Packet: An RTP packet that is formatted as 330 defined in Section 4 of [RFC4588]. The payload of a retransmission 331 or burst packet comprises the retransmission payload header followed 332 by the payload of the original RTP packet. 334 Reference Information: The set of certain media content and metadata 335 information that is sufficient for an RTP receiver to start usefully 336 consuming a media stream. The meaning, format and size of this 337 information are specific to the application and are out of scope of 338 this document. 340 Preamble Information: A more compact form of the whole or a subset 341 of the Reference Information transmitted out-of-band. 343 (Unicast) Burst (or Retransmission) RTP Session: The unicast RTP 344 session used to send one or more unicast burst RTP streams and their 345 associated RTCP messages. The terms "burst RTP session" and 346 "retransmission RTP session" can be used interchangeably. 348 (Unicast) Burst (Stream): A unicast stream of RTP retransmission 349 packets that enable an RTP receiver to rapidly acquire the Reference 350 Information associated with a primary multicast stream. Each burst 351 stream is identified by its Synchronization Source (SSRC) identifier 352 that is unique in the primary multicast RTP session. Following the 353 session-multiplexing guidelines in [RFC4588], each unicast burst 354 stream will use the same SSRC and Canonical Name (CNAME) as its 355 primary multicast RTP stream. 357 Retransmission Server (RS): The RTP/RTCP endpoint that can generate 358 the retransmission packets and the burst streams. The RS may also 359 generate other non-retransmission packets to aid rapid acquisition. 361 4. Elements of Delay in Multicast Applications 363 In a source-specific (SSM) multicast delivery system, there are three 364 major elements that contribute to the acquisition delay when an RTP 365 receiver switches from one multicast session to another one. These 366 are: 368 o Multicast switching delay 370 o Reference Information latency 372 o Buffering delays 374 Multicast switching delay is the delay that is experienced to leave 375 the current multicast session (if any) and join the new multicast 376 session. In typical systems, the multicast join and leave operations 377 are handled by a group management protocol. For example, the 378 receivers and routers participating in a multicast session can use 379 the Internet Group Management Protocol (IGMP) version 3 [RFC3376] or 380 the Multicast Listener Discovery Protocol (MLD) version 2 [RFC3810]. 381 In either of these protocols, when a receiver wants to join a 382 multicast session, it sends a message to its upstream router and the 383 routing infrastructure sets up the multicast forwarding state to 384 deliver the packets of the multicast session to the new receiver. 385 Depending on the proximity of the upstream router, the current state 386 of the multicast tree, the load on the system and the protocol 387 implementation, the join times vary. Current systems provide join 388 latencies usually less than 200 milliseconds (ms). If the receiver 389 had been participating in another multicast session before joining 390 the new session, it needs to send a Leave message to its upstream 391 router to leave the session. In common multicast routing protocols, 392 the leave times are usually smaller than the join times, however, it 393 is possible that the Leave and Join messages might get lost, in which 394 case the multicast switching delay inevitably increases. 396 Reference Information latency is the time it takes the receiver to 397 acquire the Reference Information. It is highly dependent on the 398 proximity of the actual time the receiver joined the session to the 399 next time the Reference Information will be sent to the receivers in 400 the session, whether the Reference Information is sent contiguously 401 or not, and the size of the Reference Information. For some 402 multicast flows, there is a little or no interdependency in the data, 403 in which case the Reference Information latency will be nil or 404 negligible. For other multicast flows, there is a high degree of 405 interdependency. One example of interest is the multicast flows that 406 carry compressed audio/video. For these flows, the Reference 407 Information latency can become quite large and be a major contributor 408 to the overall delay. 410 The buffering component of the overall acquisition delay is driven by 411 the way the application layer processes the payload. In many 412 multicast applications, an unreliable transport protocol such as UDP 413 [RFC0768] is often used to transmit the data packets, and the 414 reliability, if needed, is usually addressed through other means such 415 as Forward Error Correction (e.g., [RFC6015]) and retransmission. 416 These loss-repair methods require buffering at the receiver side to 417 function properly. In many applications, it is also often necessary 418 to de-jitter the incoming data packets before feeding them to the 419 application. The de-jittering process also increases the buffering 420 delays. Besides these network-related buffering delays, there are 421 also specific buffering needs that are required by the individual 422 applications. For example, standard video decoders typically require 423 an amount, sometimes up to a few seconds, of coded video data to be 424 available in the pre-decoding buffers prior to starting to decode the 425 video bitstream. 427 5. Protocol Design Considerations and Their Effect on Resource 428 Management for Rapid Acquisition 430 This section is for informational purposes and does not contain 431 requirements for implementations. 433 Rapid acquisition is an optimization of a system that is expected to 434 continue to work correctly and properly whether or not the 435 optimization is effective, or even fails due to lost control and 436 feedback messages, congestion, or other problems. This is 437 fundamental to the overall design requirements surrounding the 438 protocol definition and to the resource management schemes to be 439 employed together with the protocol (e.g., QoS machinery, server load 440 management, etc). In particular, the system needs to operate within 441 a number of constraints: 443 o First, a rapid acquisition operation must fail gracefully. The 444 user experience must be not significantly worse for trying and 445 failing to complete rapid acquisition compared to simply joining 446 the multicast session. 448 o Second, providing the rapid acquisition optimizations must not 449 cause collateral damage to either the multicast session being 450 joined, or other multicast sessions sharing resources with the 451 rapid acquisition operation. In particular, the rapid acquisition 452 operation must avoid interference with the multicast session that 453 might be simultaneously being received by other hosts. In 454 addition, it must also avoid interference with other multicast and 455 non-multicast sessions sharing the same network resources. These 456 properties are possible, but are usually difficult to achieve. 458 One challenge is the existence of multiple bandwidth bottlenecks 459 between the receiver and the server(s) in the network providing the 460 rapid acquisition service. In commercial IPTV deployments, for 461 example, bottlenecks are often present in the aggregation network 462 connecting the IPTV servers to the network edge, the access links 463 (e.g., DSL, DOCSIS) and in the home network of the subscribers. Some 464 of these links might serve only a single subscriber, limiting 465 congestion impact to the traffic of only that subscriber, but others 466 can be shared links carrying multicast sessions of many subscribers. 467 Also note that the state of these links can vary over time. The 468 receiver might have knowledge of a portion of this network, or might 469 have partial knowledge of the entire network. The methods employed 470 by the devices to acquire this network state information is out of 471 scope for this document. The receiver should be able to signal the 472 server with the bandwidth that it believes it can handle. The server 473 also needs to be able to rate limit the flow in order to stay within 474 the performance envelope that it knows about. Both the server and 475 receiver need to be able to inform the other of changes in the 476 requested and delivered rates. However, the protocol must be robust 477 in the presence of packet loss, so this signaling must include the 478 appropriate default behaviors. 480 A second challenge is that for some uses (e.g., high-bitrate video) 481 the unicast burst bitrate is high while the flow duration of the 482 unicast burst is short. This is because the purpose of the unicast 483 burst is to allow the RTP receiver to join the multicast quickly and 484 thereby limit the overall resources consumed by the burst. Such 485 high-bitrate, short-duration flows are not amenable to conventional 486 admission control techniques. For example, end-to-end per-flow 487 signaled admission control techniques such as RSVP have too much 488 latency and control channel overhead to be a good fit for rapid 489 acquisition. Similarly, using a TCP (or TCP-like) approach with a 490 3-way handshake and slow-start to avoid inducing congestion would 491 defeat the purpose of attempting rapid acquisition in the first place 492 by introducing many round-trip times (RTT) of delay. 494 These observations lead to certain unavoidable requirements and goals 495 for a rapid acquisition protocol. These are: 497 o The protocol must be designed to allow a deterministic upper bound 498 on the extra bandwidth used (compared to just joining the 499 multicast session). A reasonable size bound is e*B, where B is 500 the nominal bandwidth of the primary multicast streams, and e is 501 an excess-bandwidth coefficient. The total duration of the 502 unicast burst must have a reasonable bound; long unicast bursts 503 devolve to the bandwidth profile of multi-unicast for the whole 504 system. 506 o The scheme should minimize (or better eliminate) the overlap of 507 the unicast burst and the primary multicast stream. This 508 minimizes the window during which congestion could be induced on a 509 bottleneck link compared to just carrying the multicast or unicast 510 packets alone. 512 o The scheme must minimize (or better eliminate) any gap between the 513 unicast burst and the primary multicast stream, which has to be 514 repaired later, or in the absence of repair, will result in loss 515 being experienced by the application. 517 In addition to the above, there are some other protocol design issues 518 to be considered. First, there is at least one RTT of "slop" in the 519 control loop. In starting a rapid acquisition burst, this manifests 520 as the time between the client requesting the unicast burst and the 521 burst description and/or the first unicast burst packets arriving at 522 the receiver. For managing and terminating the unicast burst, there 523 are two possible approaches for the control loop: The receiver can 524 adapt to the unicast burst as received, converge based on observation 525 and explicitly terminate the unicast burst with a second control loop 526 exchange (which takes a minimum of one RTT, just as starting the 527 unicast burst does). Alternatively, the server generating the 528 unicast burst can pre-compute the burst parameters based on the 529 information in the initial request and tell the receiver the burst 530 duration. 532 The protocol described in the next section allows either method of 533 controlling the rapid acquisition unicast burst. 535 6. Rapid Acquisition of Multicast RTP Sessions (RAMS) 537 We start this section with an overview of the rapid acquisition of 538 multicast sessions (RAMS) method. 540 6.1. Overview 542 [RFC5760] specifies an extension to the RTP Control Protocol (RTCP) 543 to use unicast feedback in an SSM session. It defines an 544 architecture that introduces the concept of Distribution Source, 545 which - in an SSM context - distributes the RTP data and 546 redistributes RTCP information to all RTP receivers. This RTCP 547 information is retrieved from the Feedback Target, to which RTCP 548 unicast feedback traffic is sent. One or more entities different 549 from the Distribution Source MAY implement the feedback target 550 functionality, and different RTP receivers MAY use different feedback 551 targets. 553 This document builds further on these concepts to reduce the 554 acquisition delay when an RTP receiver joins a multicast session at a 555 random point in time by introducing the concept of the Burst Source 556 and new RTCP feedback messages. The Burst Source has a cache where 557 the most recent packets from the primary multicast RTP session are 558 continuously stored. When an RTP receiver wants to receive a primary 559 multicast stream, it can first request a unicast burst from the Burst 560 Source before it joins the SSM session. In this burst, the packets 561 are formatted as RTP retransmission packets [RFC4588] and carry 562 Reference Information. This information allows the RTP receiver to 563 start usefully consuming the RTP packets sent in the primary 564 multicast RTP session. 566 Using an accelerated bitrate (as compared to the nominal bitrate of 567 the primary multicast stream) for the unicast burst implies that at a 568 certain point in time, the payload transmitted in the unicast burst 569 is going to be the same as the payload in the associated multicast 570 stream, i.e., the unicast burst will catch up with the primary 571 multicast stream. At this point, the RTP receiver no longer needs to 572 receive the unicast burst and can join the SSM session. This method 573 is referred to as the Rapid Acquisition of Multicast Sessions (RAMS). 575 This document defines extensions to [RFC4585] for an RTP receiver to 576 request a unicast burst as well as for additional control messaging 577 that can be leveraged during the acquisition process. 579 6.2. Message Flows 581 Figure 2 shows the main entities involved in rapid acquisition and 582 the message flows. They are 583 o Multicast Source 585 o Feedback Target (FT) 587 o Burst/Retransmission Source (BRS) 589 o RTP Receiver (RTP_Rx) 591 ----------- -------------- 592 | |------------------------------------>| | 593 | |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| | 594 | | | | 595 | Multicast | ---------------- | | 596 | Source | | Retransmission | | | 597 | |-------->| Server (RS) | | | 598 | |.-.-.-.->| | | | 599 | | | ------------ | | | 600 ----------- | | Feedback | |<.=.=.=.=.| | 601 | | Target (FT)| |<~~~~~~~~~| RTP Receiver | 602 PRIMARY MULTICAST | ------------ | | (RTP_Rx) | 603 RTP SESSION with | | | | 604 UNICAST FEEDBACK | | | | 605 | | | | 606 - - - - - - - - - - - |- - - - - - - - |- - - - - |- - - - - - - |- - 607 | | | | 608 UNICAST BURST | ------------ | | | 609 (or RETRANSMISSION) | | Burst and | |<~~~~~~~~>| | 610 RTP SESSION | | Retrans. | |.........>| | 611 | |Source (BRS)| |<.=.=.=.=>| | 612 | ------------ | | | 613 | | | | 614 ---------------- -------------- 616 -------> Multicast RTP Flow 617 .-.-.-.> Multicast RTCP Flow 618 .=.=.=.> Unicast RTCP Reports 619 ~~~~~~~> Unicast RTCP Feedback Messages 620 .......> Unicast RTP Flow 622 Figure 2: Flow diagram for unicast-based rapid acquisition 624 The feedback target (FT) is the entity as defined in [RFC5760], to 625 which the RTP_Rx sends its RTCP feedback messages indicating packet 626 loss by means of an RTCP NACK message or indicating RTP_Rx's desire 627 to rapidly acquire the primary multicast RTP session by means of an 628 RTCP feedback message defined in this document. While the Burst/ 629 Retransmission Source (BRS) is responsible for responding to these 630 messages and for further RTCP interaction with the RTP_Rx in the case 631 of a rapid acquisition process, it is assumed in the remainder of the 632 document that these two logical entities (FT and BRS) are combined in 633 a single physical entity and they share state. In the remainder of 634 the text, the term Retransmission Server (RS) is used whenever 635 appropriate, to refer to this single physical entity. 637 The FT is involved in the primary multicast RTP session and receives 638 unicast feedback for that session as in [RFC5760]. The BRS is 639 involved in the unicast burst (or retransmission) RTP session and 640 transmits the unicast burst and retransmission packets formatted as 641 RTP retransmission packets [RFC4588] in a single separate unicast RTP 642 session to each RTP_Rx. In the unicast burst RTP session, as in any 643 other RTP session, the BRS and RTP_Rx regularly send the periodic 644 sender and receiver reports, respectively. 646 The unicast burst is started by an RTCP feedback message that is 647 defined in this document based on the common packet format provided 648 in [RFC4585]. An RTP retransmission is triggered by an RTCP NACK 649 message defined in [RFC4585]. Both of these messages are sent to the 650 FT of the primary multicast RTP session, and can start the unicast 651 burst/retransmission RTP session. 653 In the extended RTP profile for RTCP-based feedback (RTP/AVPF), there 654 are certain rules that apply to scheduling of both of these messages 655 sent to the FT in the primary multicast RTP session, and these are 656 detailed in Section 3.5 of [RFC4585]. One of the rules states that 657 in a multi-party session such as the SSM sessions we are considering 658 in this specification, an RTP_Rx cannot send an RTCP feedback message 659 for a minimum of one second period after joining the session (i.e., 660 Tmin=1.0 second). While this rule has the goal of avoiding problems 661 associated with flash crowds in typical multi-party sessions, it 662 defeats the purpose of rapid acquisition. Furthermore, when RTP 663 receivers delay their messages requesting a burst by a deterministic 664 or even a random amount, it still does not make a difference since 665 such messages are not related and their timings are independent from 666 each other. Thus, in this specification we initialize Tmin to zero 667 and allow the RTP receivers to send a burst request message right at 668 the beginning. For the subsequent messages (e.g., updated requests) 669 during rapid acquisition, the timing rules of [RFC4585] still apply. 671 Figure 3 depicts an example of messaging flow for rapid acquisition. 672 The RTCP feedback messages are explained below. The optional 673 messages are indicated in parentheses and they might or might not be 674 present during rapid acquisition. In a scenario where rapid 675 acquisition is performed by a feedback target co-located with the 676 media sender, the same method (with the identical message flows) 677 still applies. 679 ------------------------- 680 | Retransmission Server | 681 ----------- | ------ ------------ | -------- ------------ 682 | Multicast | | | FT | | Burst/Ret. | | | | | RTP | 683 | Source | | | | | Source | | | Router | | Receiver | 684 | | | ------ ------------ | | | | (RTP_Rx) | 685 ----------- | | | | -------- ------------ 686 | ------------------------- | | 687 | | | | | 688 |-- RTP Multicast ---------->--------------->| | 689 |-. RTCP Multicast -.-.-.-.->-.-.-.-.-.-.-.->| | 690 | | | | | 691 | | |********************************| 692 | | |* PORT MAPPING SETUP *| 693 | | |********************************| 694 | | | | | 695 | |<~~~~~~~~~~~~~~~~~~~~~~~~~ RTCP RAMS-R ~~~| 696 | | | | | 697 | | |********************************| 698 | | |* UNICAST SESSION ESTABLISHED *| 699 | | |********************************| 700 | | | | | 701 | | |~~~ RTCP RAMS-I ~~~~~~~~~~~~~~~>| 702 | | | | | 703 | | |... Unicast RTP Burst .........>| 704 | | | | | 705 | |<~~~~~~~~~~~~~~~~~~~~~~~~ (RTCP RAMS-R) ~~| 706 | | | | | 707 | | |~~ (RTCP RAMS-I) ~~~~~~~~~~~~~~>| 708 | | | | | 709 | | | | | 710 | | | |<= SFGMP Join ==| 711 | | | | | 712 |-- RTP Multicast ------------------------------------------->| 713 |-. RTCP Multicast -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.>| 714 | | | | | 715 | | | | | 716 | | |<~~~~~~~~~~~~~~~ RTCP RAMS-T ~~~| 717 | | | | | 718 : : : : : 719 | | |<.=.= Unicast RTCP Reports .=.=>| 720 : : : (for the unicast session) : 721 | | | | | 723 -------> Multicast RTP Flow 724 .-.-.-.> Multicast RTCP Flow 725 .=.=.=.> Unicast RTCP Reports 726 ~~~~~~~> Unicast RTCP Feedback Messages 727 =======> SFGMP Messages 728 .......> Unicast RTP Flow 730 Figure 3: Message flows for unicast-based rapid acquisition 732 This document defines the expected behaviors of the RS and RTP_Rx. 733 It is instructive to consider independently operating implementations 734 on the RS and RTP_Rx that request the burst, describe the burst, 735 start the burst, join the multicast session and stop the burst. 736 These implementations send messages to each other, but provisions are 737 needed for the cases where the control messages get lost, or re- 738 ordered, or are not being delivered to their destinations. 740 The following steps describe rapid acquisition in detail: 742 1. Port Mapping Setup: For the primary multicast RTP session, the 743 RTP and RTCP destination ports are declaratively specified 744 (Refer to Section 8 for examples in SDP). However, the RTP_Rx 745 needs to choose its RTP and RTCP receive ports for the unicast 746 burst RTP session. Since this unicast session is established 747 after the RTP_Rx has sent a RAMS-Request (RAMS-R) message as 748 unicast feedback in the primary multicast RTP session, the 749 RTP_Rx MUST first setup the port mappings between the unicast 750 and multicast sessions and send this mapping information to the 751 FT along with the RAMS-R message so that the BRS knows how to 752 communicate with the RTP_Rx. 754 The details of this setup procedure are explained in 755 [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. Other NAT-related 756 issues are left to Section 9 to keep the present discussion 757 focused on the RAMS message flows. 759 2. Request: the RTP_Rx sends a rapid acquisition request (RAMS-R) 760 for the primary multicast RTP session to the unicast feedback 761 target of that session. The request contains the SSRC 762 identifier of the RTP_Rx (aka SSRC of packet sender) and can 763 contain the media sender SSRC identifier(s) of the primary 764 multicast stream(s) of interest (aka SSRC of media source). The 765 RAMS-R message can contain parameters that constrain the burst, 766 such as the buffer and bandwidth limits. 768 Before joining the SSM session, the RTP_Rx learns the addresses 769 for the multicast source, group and RS by out-of-band means. If 770 the RTP_Rx desires to rapidly acquire only a subset of the 771 primary multicast streams available in the primary multicast RTP 772 session, the RTP_Rx MUST also acquire the SSRC identifiers for 773 the desired RTP streams out-of-band. Based on this information, 774 the RTP_Rx populates the desired SSRC(s) in the RAMS-R message. 776 When the FT successfully receives the RAMS-R message, the BRS 777 responds to it by accepting or rejecting the request. 778 Immediately before the BRS sends any RTP or RTCP packet(s) 779 described below, it establishes the unicast burst RTP session. 781 3. Response: The BRS sends RAMS-Information (RAMS-I) message(s) to 782 the RTP_Rx to convey the status for the burst(s) requested by 783 the RTP_Rx. 785 If the primary multicast RTP session associated with the FT_Ap 786 (a specific feedback target running on a particular address and 787 port) on which the RAMS-R message was received contains only a 788 single primary multicast stream, the BRS SHALL always use the 789 SSRC of the RTP stream associated with the FT_Ap in the RAMS-I 790 message(s) regardless of the media sender SSRC requested in the 791 RAMS-R message. In such cases the 'ssrc' attribute MAY be 792 omitted from the media description. If the requested SSRC and 793 the actual media sender SSRC do not match, the BRS MUST 794 explicitly populate the correct media sender SSRC in the initial 795 RAMS-I message (See Section 7.3). 797 The FT_Ap could also be associated with an RTP session that 798 carries two or more primary multicast streams. If the RTP_Rx 799 wants to issue a collective request to receive the whole primary 800 multicast RTP session, it does not need the 'ssrc' attributes to 801 be described in the media description. 803 If the FT_Ap is associated with two or more RTP sessions, 804 RTP_Rx's request will be ambiguous. To avoid any ambiguity, 805 each FT_Ap MUST be only associated with a single RTP session. 807 If the RTP_Rx is willing to rapidly acquire only a subset of the 808 primary multicast streams, the RTP_Rx MUST list all the media 809 sender SSRC(s) denoting the stream(s) it wishes to acquire in 810 the RAMS-R message. Upon receiving such a message, the BRS MAY 811 accept the request for all or a subset of the media sender 812 SSRC(s) that matched the RTP stream(s) it serves. The BRS MUST 813 reject all other requests with an appropriate response code. 815 * Reject Responses: The BRS MUST take into account any 816 limitations that may have been specified by the RTP_Rx in the 817 RAMS-R message when making a decision regarding the request. 818 If the RTP_Rx has requested to acquire the whole primary 819 multicast RTP session but the BRS cannot provide a rapid 820 acquisition service for any of the primary multicast streams, 821 the BRS MUST reject the request via a single RAMS-I message 822 with a collective reject response code, which is defined as 823 510 in Section 11.6, and whose media sender SSRC field is set 824 to one of SSRCs served by this FT_Ap. Upon receiving this 825 RAMS-I message, the RTP_Rx abandons the rapid acquisition 826 attempt and can immediately join the multicast session by 827 sending an SFGMP Join message towards its upstream multicast 828 router. 830 In all other cases, the BRS MUST send a separate RAMS-I 831 message with the appropriate 5xx-level response code (as 832 defined in Section 11.6) for each primary multicast stream 833 that has been requested by the RTP_Rx but cannot be served by 834 the BRS. There could be multiple reasons why the BRS has 835 rejected the request, however, the BRS chooses the most 836 appropriate response code to inform the RTP_Rx. 838 Upon receiving a reject response indicating a transient 839 problem such as insufficient BRS or network resources, if the 840 RTP_Rx wants to retry sending the same request, the RTP_Rx 841 MUST follow the RTCP timer rules of [RFC4585] to allow the 842 transient problems go away. However, if the reject response 843 indicates a non-transient problem (such as the ones reported 844 by response codes 504, 505 and 506), the RTP_Rx MUST NOT 845 attempt a retry. Different response codes have different 846 scopes. Refer to Section 7.3.1 for details. 848 The BRS can employ a policing mechanism against the broken 849 RTP_Rx implementations that are not following these rules. 850 See Section 10 for details. 852 * Accept Responses: The BRS MUST send at least one separate 853 RAMS-I message with the appropriate response code (either 854 zero indicating a private response or response code 200 855 indicating success as listed in Section 11.6) for each 856 primary multicast stream that has been requested by the 857 RTP_Rx and will be served by the BRS. Such RAMS-I messages 858 comprise fields that can be used to describe the individual 859 unicast burst streams. When there is a RAMS-R request for 860 multiple primary multicast streams, the BRS MUST include all 861 the individual RAMS-I messages corresponding to that RAMS-R 862 request in the same compound RTCP packet if these messages 863 fit in the same packet. Note that if the BRS is sending only 864 the preamble information but not the whole unicast burst 865 stream, it will not accept the request, but will send a 866 response code 511 instead as defined in Section 11.6. 868 The RAMS-I message carries the RTP sequence number of the 869 first packet transmitted in the respective RTP stream to 870 allow the RTP_Rx to detect any missing initial packet(s). 871 When the BRS accepts a request for a primary multicast 872 stream, this field MUST always be populated in the RAMS-I 873 message(s) sent for this particular primary multicast stream. 874 It is RECOMMENDED that the BRS sends a RAMS-I message at the 875 start of the burst so that the RTP_Rx can quickly detect any 876 missing initial packet(s). 878 It is possible that the RAMS-I message for a primary multicast 879 stream can get delayed or lost, and the RTP_Rx can start 880 receiving RTP packets before receiving a RAMS-I message. An 881 RTP_Rx implementation MUST NOT assume it will quickly receive 882 the initial RAMS-I message. For redundancy purposes, it is 883 RECOMMENDED that the BRS repeats the RAMS-I messages multiple 884 times as long as it follows the RTCP timer rules defined in 885 [RFC4585]. 887 4. Unicast Burst: For the primary multicast stream(s) for which 888 the request is accepted, the BRS starts sending the unicast 889 burst(s) that comprises one or more RTP retransmission packets 890 sent in the unicast burst RTP session. In addition, in some 891 applications the BRS can send preamble information data to the 892 RTP_Rx in addition to the requested burst to prime the media 893 decoder(s). However, for the BRS to send the preamble 894 information in a particular format, explicit signaling from the 895 RTP_Rx is required. In other words, the BRS MUST NOT send 896 preamble information in a particular format unless the RTP_Rx 897 has signaled support for that format in the RAMS-R message 898 through a public or private extension as defined in Section 7.1. 900 The format of this preamble data is RTP-payload specific and not 901 specified here. 903 5. Updated Request: The RTP_Rx MAY send an updated RAMS-R message 904 (as unicast feedback in the primary multicast RTP session) with 905 a different value for one or more fields of an earlier RAMS-R 906 message. The BRS MUST be able to detect whether a burst is 907 already planned for or being transmitted to this particular 908 RTP_Rx for this particular media sender SSRC. If there is an 909 existing burst planned for or being transmitted, the newly 910 arriving RAMS-R is an updated request; otherwise it is a new 911 request. It is also possible that the RTP_Rx has sent an 912 improperly formatted RAMS-R message or used an invalid value in 913 the RAMS-R message. If notified by the BRS using a 4xx-level 914 response code (as defined in Section 11.6) and only after 915 following the timing rules of [RFC4585], the RTP_Rx MAY re-send 916 its corrected request. 918 The BRS determines the identity of the requesting RTP_Rx by 919 looking at its canonical name identifier (CNAME item in the SDES 920 source description). Thus, the RTP_Rx MUST choose a method that 921 ensures it uses a unique CNAME identifier. Different such ways 922 are provided in [I-D.ietf-avt-rtp-cnames]. In addition to one 923 or more fields with updated values, an updated RAMS-R message 924 may also include the fields whose values did not change. 926 Upon receiving an updated request, the BRS can use the updated 927 values for sending/shaping the burst, or refine the values and 928 use the refined values for sending/shaping the burst. 929 Subsequently, the BRS MAY send an updated RAMS-I message in the 930 unicast burst RTP session to indicate the changes it made. 932 It is an implementation-dependent decision for an RTP_RX whether 933 and when to send an updated request. However, note that the 934 updated request messages can get delayed and arrive at the BRS 935 after the initial unicast burst was completed. In this case, 936 the updated request message can trigger a new unicast burst and 937 by then if the RTP_Rx has already started receiving multicast 938 data, a congestion is likely to occur. In this case, the RTP_Rx 939 can detect this only after a delay and then it can try to 940 terminate the new burst. However, in the mean time, the RTP_Rx 941 can experience packet loss or other problems. This and other 942 similar corner cases SHOULD be carefully examined if updated 943 requests are to be used. 945 6. Updated Response: The BRS can send more than one RAMS-I 946 messages in the unicast burst RTP session, e.g., to update the 947 value of one or more fields in an earlier RAMS-I message. The 948 updated RAMS-I messages might or might not be a direct response 949 to a RAMS-R message. The BRS can also send updated RAMS-I 950 messages to signal the RTP_Rx in real time to join the SSM 951 session, when the BRS had already sent an initial RAMS-I 952 message, e.g., at the start of the burst. The RTP_Rx depends on 953 the BRS to learn the join time, which can be conveyed by the 954 first RAMS-I message, or can be sent/revised in a later RAMS-I 955 message. If the BRS is not capable of determining the join time 956 in the initial RAMS-I message, the BRS MUST send another RAMS-I 957 message (with the join time information) later. 959 7. Multicast Join Signaling: The RAMS-I message allows the BRS to 960 signal explicitly when the RTP_Rx needs to send the SFGMP Join 961 message. The RTP_Rx SHOULD use this information from the most 962 recent RAMS-I message unless it has more accurate information. 964 If the request is accepted, this information MUST be conveyed in 965 at least one RAMS-I message and its value MAY be updated by 966 subsequent RAMS-I messages. 968 There can be missing packets if the RTP_Rx joins the multicast 969 session too early or too late. For example, if the RTP_Rx 970 starts receiving the primary multicast stream while it is still 971 receiving the unicast burst at a high excess bitrate, this can 972 result in an increased risk of packet loss. Or, if the RTP_Rx 973 joins the multicast session some time after the unicast burst is 974 finished, there can be a gap between the burst and multicast 975 data (a number of RTP packets might be missing). In both cases, 976 the RTP_Rx can issue retransmission requests (via RTCP NACK 977 messages sent as unicast feedback in the primary multicast RTP 978 session) [RFC4585] to the FT entity of the RS to fill the gap. 979 The BRS might or might not respond to such requests. When it 980 responds and the response causes significant changes in one or 981 more values reported earlier to the RTP_Rx, an updated RAMS-I 982 SHOULD be sent to the RTP_Rx. 984 8. Multicast Receive: After the join, the RTP_Rx starts receiving 985 the primary multicast stream(s). 987 9. Terminate: The BRS can know when it needs to ultimately stop 988 the unicast burst based on its parameters. However, the RTP_Rx 989 may need to ask the BRS to terminate the burst prematurely or at 990 a specific sequence number. For this purpose, the RTP_Rx uses 991 the RAMS-Termination (RAMS-T) message sent as RTCP feedback in 992 the unicast burst RTP session. A separate RAMS-T message is 993 sent for each primary multicast stream served by the BRS unless 994 an RTCP BYE message has been sent in the unicast burst RTP 995 session as described in Step 10. For the burst requests that 996 were rejected by the BRS, there is no need to send a RAMS-T 997 message. 999 If the RTP_Rx wants to terminate a burst prematurely, it MUST 1000 send a RAMS-T message for the SSRC of the primary multicast 1001 stream it wishes to terminate. This message is sent in the 1002 unicast burst RTP session. Upon receiving this message, the BRS 1003 MUST terminate the unicast burst. If the RTP_Rx requested to 1004 acquire the entire primary multicast RTP session but wants to 1005 terminate this request before it learns the individual media 1006 sender SSRC(s) via RAMS-I message(s) or RTP packets, the RTP_Rx 1007 cannot use RAMS-T message(s) and thus MUST send an RTCP BYE 1008 message in the unicast burst RTP session to terminate the 1009 request. 1011 Otherwise, the default behavior for the RTP_Rx is to send a 1012 RAMS-T message in the unicast burst RTP session immediately 1013 after it joins the multicast session and has started receiving 1014 multicast packets. In that case, the RTP_Rx MUST send a RAMS-T 1015 message with the sequence number of the first RTP packet 1016 received in the primary multicast stream. Then, the BRS MUST 1017 terminate the respective burst after it sends the unicast burst 1018 packet whose Original Sequence Number (OSN) field in the RTP 1019 retransmission payload header matches this number minus one. If 1020 the BRS has already sent that unicast burst packet when the 1021 RAMS-T message arrives, the BRS MUST terminate the respective 1022 burst immediately. 1024 If an RTCP BYE message has not been issued yet as described in 1025 Step 10, the RTP_Rx MUST send at least one RAMS-T message for 1026 each primary multicast stream served by the BRS. The RAMS-T 1027 message(s) MUST be sent to the BRS in the unicast burst RTP 1028 session. Against the possibility of a message loss, it is 1029 RECOMMENDED that the RTP_Rx repeats the RAMS-T messages multiple 1030 times as long as it follows the RTCP timer rules defined in 1031 [RFC4585]. 1033 The binding between RAMS-T and ongoing bursts is achieved 1034 through RTP_Rx's CNAME identifier, and packet sender and media 1035 sender SSRCs. Choosing a globally unique CNAME makes sure that 1036 the RAMS-T messages are processed correctly. 1038 10. Terminate with RTCP BYE: When the RTP_Rx is receiving one or 1039 more burst streams, if the RTP_Rx becomes no longer interested 1040 in acquiring any of the primary multicast streams, the RTP_Rx 1041 SHALL issue an RTCP BYE message for the unicast burst RTP 1042 session and another RTCP BYE message for the primary multicast 1043 RTP session. These RTCP BYE messages are sent to the BRS and FT 1044 logical entities, respectively. 1046 Upon receiving an RTCP BYE message, the BRS MUST terminate the 1047 rapid acquisition operation, and cease transmitting any further 1048 burst packets and retransmission packets. If support for 1049 [RFC5506] has been signaled, the RTCP BYE message MAY be sent in 1050 a reduced-size RTCP packet. Otherwise, Section 6.1 of [RFC3550] 1051 mandates the RTCP BYE message always to be sent with a sender or 1052 receiver report in a compound RTCP packet. If no data has been 1053 received, an empty receiver report MUST be still included. With 1054 the information contained in the receiver report, the RS can 1055 figure out how many duplicate RTP packets have been delivered to 1056 the RTP_Rx (Note that this will be an upper-bound estimate as 1057 one or more packets might have been lost during the burst 1058 transmission). The impact of duplicate packets and measures 1059 that can be taken to minimize the impact of receiving duplicate 1060 packets will be addressed in Section 6.4. 1062 Since an RTCP BYE message issued for the unicast burst RTP 1063 session terminates that session and ceases transmitting any 1064 further packets in that session, there is no need for sending 1065 explicit RAMS-T messages, which would only terminate their 1066 respective bursts. 1068 For the purpose of gathering detailed information about RTP_Rx's 1069 rapid acquisition experience, [I-D.ietf-avt-multicast-acq-rtcp-xr] 1070 defines an RTCP Extended Report (XR) Block. This report is designed 1071 to be payload-independent, thus, it can be used by any multicast 1072 application that supports rapid acquisition. 1074 6.3. Synchronization of Primary Multicast Streams 1076 When an RTP_RX acquires multiple primary multicast streams, it might 1077 need to synchronize them for playout. This synchronization is 1078 achieved by the help of the RTCP sender reports [RFC3550]. If the 1079 playout will start before the RTP_Rx has joined the multicast 1080 session, the RTP_Rx needs to receive the information reflecting the 1081 synchronization among the primary multicast streams early enough so 1082 that it can play out the media in a synchronized fashion. 1084 The suggested approach is to use the RTP header extension mechanism 1085 [RFC5285] and convey the synchronization information in a header 1086 extension as defined in [RFC6051]. Per [RFC4588] "if the original 1087 RTP header carried an RTP header extension, the retransmission packet 1088 SHOULD carry the same header extension." Thus, as long as the 1089 multicast source emits a header extension with the synchronization 1090 information frequently enough, there is no additional task that needs 1091 to be carried out by the BRS. The synchronization information will 1092 be sent to the RTP_Rx along with the burst packets. The frequent 1093 header extensions sent in the primary multicast RTP sessions also 1094 allow rapid synchronization of the RTP streams for the RTP receivers 1095 that do not support RAMS or that directly join the multicast session 1096 without running RAMS. Thus, in RAMS applications, it is RECOMMENDED 1097 that the multicast sources frequently send synchronization 1098 information by using header extensions following the rules presented 1099 in [RFC6051]. The regular sender reports are still sent in the 1100 unicast session by following the rules of [RFC3550]. 1102 6.4. Burst Shaping and Congestion Control in RAMS 1104 This section provides informative guidelines about how the BRS can 1105 shape the transmission of the unicast burst and how congestion can be 1106 dealt within the RAMS process. When the RTP_Rx detects that the 1107 unicast burst is causing severe congestion, it can prefer to send a 1108 RAMS-T message immediately to stop the unicast burst. 1110 A higher bitrate for the unicast burst naturally conveys the 1111 Reference Information and media content to the RTP_Rx faster. This 1112 way, the RTP_Rx can start consuming the data sooner, which results in 1113 a faster acquisition. A higher bitrate also represents a better 1114 utilization of the BRS resources. As the burst may continue until it 1115 catches up with the primary multicast stream, the higher the bursting 1116 bitrate, the less data the BRS needs to transmit. However, a higher 1117 bitrate for the burst also increases the chances for congestion- 1118 caused packet loss. Thus, as discussed in Section 5, there has to be 1119 an upper bound on the bandwidth used by the burst. 1121 When the BRS transmits the unicast burst, it is expected to take into 1122 account all available information to prevent any packet loss that 1123 might take place during the bursting as a result of buffer overflow 1124 on the path between the RS and RTP_Rx and at the RTP_Rx itself. The 1125 bursting bitrate can be determined by taking into account the 1126 following information, when available: 1128 a. Information obtained via the RAMS-R message, such as Max RAMS 1129 Buffer Fill Requirement and/or Max Receive Bitrate (See 1130 Section 7.2). 1132 b. Information obtained via RTCP receiver reports provided by the 1133 RTP_Rx in the retransmission session, allowing in-session bitrate 1134 adaptations for the burst. When these receiver reports indicate 1135 packet loss, this can indicate a certain congestion state in the 1136 path from the RS to the RTP_Rx. 1138 c. Information obtained via RTCP NACKs provided by the RTP_Rx in the 1139 primary multicast RTP session, allowing in-session bitrate 1140 adaptations for the burst. Such RTCP NACKs are transmitted by 1141 the RTP_Rx in response to packet loss detection in the burst. 1142 NACKs can indicate a certain congestion state on the path from 1143 the RS to RTP_Rx. 1145 d. There can be other feedback received from the RTP_Rx, e.g., in 1146 the form of ECN-CE markings [I-D.ietf-avt-ecn-for-rtp] that can 1147 influence in-session bitrate adaptation. 1149 e. Information obtained via updated RAMS-R messages, allowing in- 1150 session bitrate adaptations, if supported by the BRS. 1152 f. Transport protocol-specific information. For example, when DCCP 1153 is used to transport the RTP burst, the ACKs from the DCCP client 1154 can be leveraged by the BRS / DCCP server for burst shaping and 1155 congestion control. 1157 g. Pre-configured settings for each RTP_Rx or a set of RTP_Rxs that 1158 indicate the upper-bound bursting bitrates for which no packet 1159 loss will occur as a result of congestion along the path of the 1160 RS to RTP_Rx. For example, in managed IPTV networks, where the 1161 bottleneck bandwidth along the end-to-end path is known and where 1162 the network between the RS and this link is provisioned and 1163 dimensioned to carry the burst streams, the bursting bitrate does 1164 not exceed the provisioned value. These settings can also be 1165 dynamically adapted using application-aware knowledge. 1167 The BRS chooses the initial burst bitrate as follows: 1169 o When using RAMS in environments as described in (g), the BRS MUST 1170 transmit the burst packets at an initial bitrate higher than the 1171 nominal bitrate, but within the engineered or reserved bandwidth 1172 limit. 1174 o When the BRS cannot determine a reliable bitrate value for the 1175 unicast burst (using a through g), it is desirable that the BRS 1176 chooses an appropriate initial bitrate not above the nominal 1177 bitrate and increases it gradually unless a congestion is 1178 detected. 1180 In both cases, during the burst transmission the BRS MUST 1181 continuously monitor for packet losses as a result of congestion by 1182 means of one or more of the mechanisms described in (b,c,d,e,f). 1183 When the BRS relies on RTCP receiver reports, sufficient bandwidth 1184 needs to be provided to RTP Rx for RTCP transmission in the unicast 1185 burst RTP session. To achieve a reasonable fast adaptation against 1186 congestion, it is recommended that the RTP_Rx sends a receiver report 1187 at least once every two RTTs between the RS and RTP_Rx. Although the 1188 specific heuristics and algorithms that deduce a congestion state and 1189 how subsequently the BRS acts are outside the scope of this 1190 specification, the following two methods are the best practices: 1192 o Upon detection of a significant amount of packet loss, which the 1193 BRS attributes to congestion, the BRS decreases the burst bitrate. 1194 The rate by which the BRS increases and decreases the bitrate for 1195 the burst can be determined by a TCP-friendly bitrate adaptation 1196 algorithm for RTP over UDP , or in the case of (f) by the 1197 congestion control algorithms defined in DCCP [RFC5762]. 1199 o If the congestion is persistent and the BRS has to reduce the 1200 burst bitrate to a point where the RTP Rx buffer might underrun or 1201 the burst will consume too many resources, the BRS terminates the 1202 burst and transmits a RAMS-I message to RTP Rx with the 1203 appropriate response code. It is then up to RTP Rx to decide when 1204 to join the multicast session. 1206 Even though there is no congestion experienced during the burst, 1207 congestion may anyway arise near the end of the burst as the RTP_Rx 1208 eventually needs to join the multicast session. During this brief 1209 period both the burst packets and the multicast packets can be 1210 simultaneously received by the RTP_Rx, thus enhancing the risk of 1211 congestion. 1213 Since the BRS signals the RTP_Rx when the BRS expects the RTP_Rx to 1214 send the SFGMP Join message, the BRS can have a rough estimate of 1215 when the RTP_Rx will start receiving multicast packets in the SSM 1216 session. The BRS can keep on sending burst packets but reduces the 1217 bitrate accordingly at the appropriate instant by taking the bitrate 1218 of the whole SSM session into account. If the BRS ceases 1219 transmitting the burst packets before the burst catches up, any gap 1220 resulting from this imperfect switch-over by the RTP_Rx can be later 1221 repaired by requesting retransmissions for the missing packets from 1222 the RS. The retransmissions can be shaped by the BRS to make sure 1223 that they do not cause collateral loss in the primary multicast RTP 1224 session and the unicast burst RTP session. 1226 6.5. Failure Cases 1228 In the following, we examine the implications of losing the RAMS-R, 1229 RAMS-I or RAMS-T messages and other failure cases. 1231 When the RTP_Rx sends a RAMS-R message to initiate a rapid 1232 acquisition but the message gets lost and the FT does not receive it, 1233 the RTP_Rx will get neither a RAMS-I message, nor a unicast burst. 1234 In this case, the RTP_Rx MAY resend the request when it is eligible 1235 to do so based on the RTCP timer rules defined in [RFC4585]. Or, 1236 after a reasonable amount of time, the RTP_Rx can time out (based on 1237 the previous observed response times) and immediately join the SSM 1238 session. 1240 In the case the RTP_Rx starts receiving a unicast burst but it does 1241 not receive a corresponding RAMS-I message within a reasonable amount 1242 of time, the RTP_Rx can either discard the burst data or decide not 1243 to interrupt the unicast burst, and be prepared to join the SSM 1244 session at an appropriate time it determines or as indicated in a 1245 subsequent RAMS-I message (if available). If the network is subject 1246 to packet loss, it is RECOMMENDED that the BRS repeats the RAMS-I 1247 messages multiple times based on the RTCP timer rules defined in 1248 [RFC4585]. 1250 In the failure cases where the RAMS-R message is lost and the RTP_Rx 1251 gives up, or the RAMS-I message is lost, the RTP_Rx MUST still 1252 terminate the burst(s) it requested by following the rules described 1253 in Section 6.2. 1255 In the case a RAMS-T message sent by the RTP_Rx does not reach its 1256 destination, the BRS can continue sending burst packets even though 1257 the RTP_Rx no longer needs them. If an RTP_Rx is receiving burst 1258 packets it no longer needs after sending a RAMS-T message, it is 1259 RECOMMENDED that the RTP_Rx repeats the RAMS-T message multiple times 1260 based on the RTCP timer rules defined in [RFC4585]. The BRS MUST be 1261 provisioned to terminate the burst when it can no longer send the 1262 burst packets faster than it receives the primary multicast stream 1263 packets. 1265 Section 6.3.5 of [RFC3550] explains the rules pertaining to timing 1266 out an SSRC. When the BRS accepts to serve the requested burst(s) 1267 and establishes the retransmission session, the BRS needs to check 1268 the liveness of the RTP_Rx via the RTCP messages and reports the 1269 RTP_Rx sends. The default rules explained in [RFC3550] apply in RAMS 1270 as well. 1272 7. Encoding of the Signaling Protocol in RTCP 1274 This section defines the formats of the RTCP transport-layer feedback 1275 messages that are exchanged between the retransmission server (RS) 1276 and RTP receiver (RTP_Rx) during rapid acquisition. These messages 1277 are referred to as the RAMS Messages. They are payload-independent 1278 and MUST be used by all RTP-based multicast applications that support 1279 rapid acquisition regardless of the payload they carry. 1281 Payload-specific feedback messages are not defined in this document. 1282 However, further optional payload-independent and payload-specific 1283 information can be included in the exchange. 1285 The common packet format for the RTCP feedback messages is defined in 1286 Section 6.1 of [RFC4585] and is also sketched in Figure 4. 1288 0 1 2 3 1289 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 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 |V=2|P| FMT | PT | length | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | SSRC of packet sender | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | SSRC of media source | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 : Feedback Control Information (FCI) : 1298 : : 1300 Figure 4: The common packet format for the RTCP feedback messages 1302 Each feedback message has a fixed-length field for version, padding, 1303 feedback message type (FMT), packet type (PT), length, SSRC of packet 1304 sender, SSRC of media source as well as a variable-length field for 1305 feedback control information (FCI). 1307 In the RAMS messages, the PT field is set to RTPFB (205) and the FMT 1308 field is set to RAMS (6). Individual RAMS messages are identified by 1309 a sub-field called Sub Feedback Message Type (SFMT). Any Reserved 1310 field SHALL be set to zero and ignored. 1312 Depending on the specific scenario and timeliness/importance of a 1313 RAMS message, it can be desirable to send it in a reduced-size RTCP 1314 packet [RFC5506]. However, unless support for [RFC5506] has been 1315 signaled, compound RTCP packets MUST be used by following [RFC3550] 1316 rules. 1318 Following the rules specified in [RFC3550], all integer fields in the 1319 messages defined below are carried in network-byte order, that is, 1320 most significant byte (octet) first, also known as big-endian. 1321 Unless otherwise stated, numeric constants are in decimal (base 10). 1323 7.1. Extensions 1325 To improve the functionality of the RAMS method in certain 1326 applications, it can be desirable to define new fields in the RAMS 1327 Request, Information and Termination messages. Such fields MUST be 1328 encoded as Type-Length-Value (TLV) elements as described below and 1329 sketched in Figure 5: 1331 o Type: A single-octet identifier that defines the type of the 1332 parameter represented in this TLV element. 1334 o Length: A two-octet field that indicates the length (in octets) 1335 of the TLV element excluding the Type and Length fields, and the 1336 8-bit Reserved field between them. This length does not include 1337 any padding that is required for alignment. 1339 o Value: Variable-size set of octets that contains the specific 1340 value for the parameter. 1342 In the extensions, the Reserved field SHALL be set to zero and 1343 ignored. If a TLV element does not fall on a 32-bit boundary, the 1344 last word MUST be padded to the boundary using further bits set to 1345 zero. 1347 An RTP_Rx or BRS MAY include vendor-neutral and private extensions in 1348 any RAMS message. The RTP_Rx or BRS MUST place such extensions after 1349 the mandatory fields and mandatory TLV elements (if any), and MAY 1350 place such extensions in any order. The RTP_Rx or BRS MUST NOT 1351 include multiple TLV elements with the same Type value in a RAMS 1352 message. 1354 The support for extensions (unless specified otherwise) is OPTIONAL. 1355 An RTP_Rx or BRS receiving a vendor-neutral or private extension that 1356 it does not understand MUST ignore that extension. 1358 0 1 2 3 1359 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 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 | Type | Reserved | Length | 1362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1363 : Value : 1364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 Figure 5: Structure of a TLV element 1368 7.1.1. Vendor-Neutral Extensions 1370 If the goal in defining new TLV elements is to extend the 1371 functionality in a vendor-neutral manner, they MUST be registered 1372 with IANA through the guidelines provided in Section 11.5. 1374 The current document defines several vendor-neutral extensions in the 1375 subsequent sections. 1377 7.1.2. Private Extensions 1379 It is desirable to allow vendors to use private extensions in a TLV 1380 format. For interoperability, such extensions must not collide with 1381 each other. 1383 A certain range of TLV Types (between - and including - 128 and 254 ) 1384 is reserved for private extensions (Refer to Section 11.5). IANA 1385 management for these extensions is unnecessary and they are the 1386 responsibility of individual vendors. 1388 The structure that MUST be used for the private extensions is 1389 depicted in Figure 6. Here, the enterprise numbers are used from 1390 http://www.iana.org/assignments/enterprise-numbers. This will ensure 1391 the uniqueness of the private extensions and avoid any collision. 1393 0 1 2 3 1394 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 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 | Type | Reserved | Length | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | Enterprise Number | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 : Value : 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 Figure 6: Structure of a private extension 1405 7.2. RAMS Request 1407 The RAMS Request (RAMS-R) message is identified by SFMT=1. This 1408 message is sent as unicast feedback in the primary multicast RTP 1409 session by the RTP_Rx to request rapid acquisition of a primary 1410 multicast RTP session, or one or more primary multicast streams 1411 belonging to the same primary multicast RTP session. In the RAMS-R 1412 message, the RTP_Rx MUST set both the packet sender SSRC and media 1413 sender SSRC fields to its own SSRC since the media sender SSRC may 1414 not be known. The RTP_Rx MUST provide explicit signaling as 1415 described below to request stream(s). This minimizes the chances of 1416 accidentally requesting a wrong primary multicast stream. 1418 The FCI field MUST contain only one RAMS Request. The FCI field has 1419 the structure depicted in Figure 7. 1421 The semantics of the RAMS-R message is independent of the payload 1422 type carried in the primary multicast RTP session. 1424 0 1 2 3 1425 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 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | SFMT=1 | Reserved | 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 : Requested Media Sender SSRC(s) : 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 : Optional TLV-encoded Fields (and Padding, if needed) : 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 Figure 7: FCI field syntax for the RAMS Request message 1436 o Requested Media Sender SSRC(s): Mandatory TLV element that lists 1437 the media sender SSRC(s) requested by the RTP_Rx. The BRS MUST 1438 ignore the media sender SSRC specified in the header of the RAMS-R 1439 message. 1441 If the Length field is set to zero (i.e., no media sender SSRC is 1442 listed), it means that the RTP_Rx is requesting to rapidly acquire 1443 the entire primary multicast RTP session. Otherwise, the RTP_Rx 1444 lists the individual media sender SSRCs in this TLV element and 1445 sets the Length field of the TLV element to 4*n, where n is the 1446 number of SSRC entries. 1448 Type: 1 1450 o Min RAMS Buffer Fill Requirement (32 bits): Optional TLV element 1451 that denotes the minimum milliseconds of data that the RTP_Rx 1452 desires to have in its buffer before allowing the data to be 1453 consumed by the application. 1455 The RTP_Rx can have knowledge of its buffering requirements. 1456 These requirements can be application and/or device specific. For 1457 instance, the RTP_Rx might need to have a certain amount of data 1458 in its application buffer to handle transmission jitter and/or to 1459 be able to support error-control methods. If the BRS is told the 1460 minimum buffering requirement of the receiver, the BRS can tailor 1461 the burst(s) more precisely, e.g., by choosing an appropriate 1462 starting point. The methods used by the RTP_Rx to determine this 1463 value are application specific, and thus, out of the scope of this 1464 document. 1466 If specified, the amount of backfill that will be provided by the 1467 unicast bursts and any payload-specific information MUST NOT be 1468 smaller than the specified value. Otherwise, the backfill will 1469 not be able to build up the desired level of buffer at the RTP_Rx 1470 and can cause buffer underruns. 1472 Type: 2 1474 o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element 1475 that denotes the maximum milliseconds of data that the RTP_Rx can 1476 buffer without losing the data due to buffer overflow. 1478 The RTP_Rx can have knowledge of its buffering requirements. 1479 These requirements can be application or device specific. For 1480 instance, one particular RTP_Rx might have more physical memory 1481 than another RTP_Rx, and thus, can buffer more data. If the BRS 1482 knows the buffering ability of the receiver, the BRS can tailor 1483 the burst(s) more precisely. The methods used by the receiver to 1484 determine this value are application specific, and thus, out of 1485 scope. 1487 If specified, the amount of backfill that will be provided by the 1488 unicast bursts and any payload-specific information MUST NOT be 1489 larger than this value. Otherwise, the backfill may cause buffer 1490 overflows at the RTP_Rx. 1492 Type: 3 1494 o Max Receive Bitrate (64 bits): Optional TLV element that denotes 1495 the maximum bitrate (in bits per second) at which the RTP_Rx can 1496 process the aggregation of the unicast burst(s) and any payload- 1497 specific information that will be provided by the BRS. The limits 1498 can include local receiver limits as well as network limits that 1499 are known to the receiver. 1501 If specified, the total bitrate of the unicast burst(s) plus any 1502 payload-specific information MUST NOT be larger than this value. 1503 Otherwise, congestion and packet loss are more likely to occur. 1505 Type: 4 1507 o Preamble-only Allowed (0 bits): Optional TLV element that 1508 indicates that the RTP_Rx is willing to receive only the preamble 1509 information for the desired primary multicast stream(s) in case 1510 the BRS cannot send the unicast burst stream(s) (In such cases, 1511 the BRS will not accept the request, but will send a response code 1512 511 in the RAMS-I message as defined in Section 11.6). Note that 1513 the RTP_Rx signals the particular preamble format(s) it supports 1514 through a public or a private extension in the same RAMS-R 1515 message. 1517 If this TLV element does not exist in the RAMS-R message, the BRS 1518 MUST NOT respond to the RAMS-R message by sending the preamble 1519 information only. Since this TLV element does not carry a Value 1520 field, the Length field MUST be set to zero. 1522 Type: 5 1524 o Supported Enterprise Number(s): Optional TLV element that 1525 indicates the enterprise number(s) that the RTP_Rx implementation 1526 supports. Similar to the private extensions, the enterprise 1527 numbers here are used from 1528 http://www.iana.org/assignments/enterprise-numbers. This TLV 1529 element, if exists, provides a hint information to the BRS about 1530 which private extensions the RTP_Rx can potentially support. Note 1531 that an RTP_Rx does not necessarily support all the private 1532 extensions under a particular enterprise number. Unless the BRS 1533 explicitly knows which private extensions an RTP_Rx supports 1534 (through this or some out-of-band means), the BRS SHOULD NOT use 1535 private extensions in the RAMS-I messages. The BRS SHOULD rather 1536 use only vendor-neutral extensions. The Length field of this TLV 1537 element is set to 4*n, where n is the number of enterprise number 1538 entries. 1540 Type: 6 1542 7.3. RAMS Information 1544 The RAMS Information (RAMS-I) message is identified by SFMT=2. This 1545 message is used to describe the unicast burst that will be sent for 1546 rapid acquisition. It also includes other useful information for the 1547 RTP_Rx as described below. 1549 A separate RAMS-I message with the appropriate response code is sent 1550 in the unicast burst RTP session by the BRS for each primary 1551 multicast stream that has been requested by the RTP_Rx. In each of 1552 these RAMS-I messages, the media sender SSRC and packet sender SSRC 1553 fields are both set to the SSRC of the BRS, which equals the SSRC of 1554 the respective primary multicast stream. 1556 The FCI field MUST contain only one RAMS Information message. The 1557 FCI field has the structure depicted in Figure 8. 1559 The semantics of the RAMS-I message is independent of the payload 1560 type carried in the primary multicast RTP session. 1562 0 1 2 3 1563 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 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 | SFMT=2 | MSN | Response | 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1567 : Optional TLV-encoded Fields (and Padding, if needed) : 1568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 Figure 8: FCI field syntax for the RAMS Information message 1572 A RAMS-I message has the following fields: 1574 o Message Sequence Number (MSN) (8 bits) : Mandatory field that 1575 denotes the sequence number of the RAMS-I message for the 1576 particular media sender SSRC specified in the message header. The 1577 MSN value SHALL be set to zero when a new RAMS request is 1578 received. During rapid acquisition, the same RAMS-I message MAY 1579 be repeated for redundancy purposes without incrementing the MSN 1580 value. If an updated RAMS-I message will be sent (either with a 1581 new information or an updated information), the MSN value SHALL be 1582 incremented by one. In the MSN field, the regular wrapping rules 1583 apply. Note that if the RTP_Rx has sent an updated request, it 1584 MUST check every RAMS-I message entirely regardless of whether the 1585 MSN value has changed or not. 1587 o Response (16 bits): Mandatory field that denotes the response 1588 code for this RAMS-I message. This document defines several 1589 initial response codes in Section 7.3.1 and registers them with 1590 IANA in Section 11.6. If a new vendor-neutral response code will 1591 be defined, it MUST be registered with IANA through the guidelines 1592 specified in Section 11.6. If the new response code is intended 1593 to be used privately by a vendor, there is no need for IANA 1594 management. Instead, the vendor MUST use the private extension 1595 mechanism (Section 7.1.2) to convey its message and MUST indicate 1596 this by putting zero in the Response field. 1598 When the RTP_Rx receives a RAMS-I message with a response code 1599 that it does not understand, the RTP_Rx MUST send a RAMS-T message 1600 immediately to the BRS. 1602 The following TLV elements have been defined for the RAMS-I messages: 1604 o Media Sender SSRC (32 bits): Optional TLV element that specifies 1605 the media sender SSRC of the unicast burst stream. If the FT_Ap 1606 that received the RAMS-R message is associated with a single 1607 primary multicast stream but the requested media sender SSRC does 1608 not match the SSRC of the RTP stream associated with this FT_Ap, 1609 the BRS includes this TLV element in the initial RAMS-I message to 1610 let the RTP_Rx know that the media sender SSRC has changed. If 1611 the two SSRCs match, there is no need to include this TLV element. 1613 Type: 31 1615 o RTP Seqnum of the First Packet (16 bits): TLV element that 1616 specifies the RTP sequence number of the first packet that will be 1617 sent in the respective unicast RTP stream. This allows the RTP_Rx 1618 to know whether one or more packets sent by the BRS have been 1619 dropped at the beginning of the stream. If the BRS accepts the 1620 RAMS request, this element exists. If the BRS rejects the RAMS 1621 request, this element SHALL NOT exist. 1623 Type: 32 1625 o Earliest Multicast Join Time (32 bits): TLV element that 1626 specifies the delta time (in ms) between the arrival of the first 1627 RTP packet in the unicast RTP stream (which could be a burst 1628 packet or a payload-specific packet) and the earliest time instant 1629 when an RTP_Rx MAY send an SFGMP Join message to join the 1630 multicast session. A zero value in this field means that the 1631 RTP_Rx MAY send the SFGMP Join message right away. If the RTP_Rx 1632 does not want to wait until the earliest multicast join time, it 1633 MAY send a RAMS-T message and only after a reasonable amount of 1634 time, it MAY join the SSM session. 1636 If the RAMS request has been accepted, the BRS sends this field at 1637 least once, so that the RTP_Rx knows when to join the multicast 1638 session. If the burst request has been rejected as indicated in 1639 the Response field, this field MUST be set to zero. In that case, 1640 it is up to the RTP_Rx when or whether to join the multicast 1641 session. 1643 When the BRS serves two or more bursts and sends a separate RAMS-I 1644 message for each burst, the join times specified in these RAMS-I 1645 messages SHOULD correspond to more or less the same time instant, 1646 and the RTP_Rx sends the SFGMP Join message based on the earliest 1647 join time. 1649 Type: 33 1651 o Burst Duration (32 bits): Optional TLV element that denotes the 1652 time the burst will last (in ms), i.e., the difference between the 1653 expected transmission times of the first and the last burst 1654 packets that the BRS is planning to send in the respective unicast 1655 RTP stream. In the absence of additional stimulus, the BRS will 1656 send a burst of this duration. However, the burst duration can be 1657 modified by subsequent events, including changes in the primary 1658 multicast stream and reception of RAMS-T messages. 1660 The BRS MUST terminate the flow in the timeframe indicated by this 1661 burst duration or the duration established by those subsequent 1662 events, even if it does not get a RAMS-T or a BYE message from the 1663 RTP_Rx. It is OPTIONAL to send this field in a RAMS-I message 1664 when the burst request is accepted. If the burst request has been 1665 rejected as indicated in the Response field, this field MAY be 1666 omitted or set to zero. 1668 Type: 34 1670 o Max Transmit Bitrate (64 bits): Optional TLV element that denotes 1671 the maximum bitrate (in bits per second) that will be used by the 1672 BRS for the RTP stream associated with this RAMS-I message. 1674 Type: 35 1676 7.3.1. Response Code Definitions 1678 1xx-Level Response Codes: These response codes are sent for 1679 informational purposes. 1681 o 100: This is used when the BRS wants to update a value that was 1682 sent earlier to the RTP_Rx. 1684 2xx-Level Response Codes: These response codes are sent to indicate 1685 success. 1687 o 200: This is used when the server accepts the RAMS request. 1689 o 201: This is used when the unicast burst has been completed and 1690 the BRS wants to notify the RTP_Rx. 1692 4xx-Level Response Codes: These response codes are sent to indicate 1693 that the message sent by the RTP_Rx is either improperly formatted or 1694 contains an invalid value. The rules the RTP_Rx needs to follow upon 1695 receiving one of these response codes are outlined in Step 5 in 1696 Section 6.2. The 4xx-level response codes are also used as status 1697 codes in the Multicast Acquisition Report Block 1698 [I-D.ietf-avt-multicast-acq-rtcp-xr] in order to collect RTP_Rx-based 1699 error conditions. 1701 o 400: This is used when the RAMS-R message is improperly 1702 formatted. 1704 o 401: This is used when the minimum RAMS buffer fill requirement 1705 value indicated in the RAMS-R message is invalid. 1707 o 402: This is used when the maximum RAMS buffer fill requirement 1708 value indicated in the RAMS-R message is invalid. 1710 o 403: This is used when the maximum receive bitrate value 1711 indicated in the RAMS-R message is insufficient. 1713 o 404: This is used when the RAMS-T message is improperly 1714 formatted. 1716 5xx-Level Response Codes: These response codes are sent to indicate 1717 an error on the BRS side. The rules the RTP_Rx needs to follow upon 1718 receiving one of these response codes are outlined in Step 3 in 1719 Section 6.2 and Section 7.2. The 5xx-level response codes are also 1720 used as status codes in the Multicast Acquisition Report Block 1721 [I-D.ietf-avt-multicast-acq-rtcp-xr] in order to collect BRS-based 1722 error conditions. 1724 o 500: This is used when the BRS has experienced an internal error 1725 and cannot accept the RAMS request. 1727 o 501: This is used when the BRS does not have enough bandwidth to 1728 send the unicast burst stream. 1730 o 502: This is used when the BRS terminates the unicast burst 1731 stream due to network congestion. 1733 o 503: This is used when the BRS does not have enough CPU resources 1734 to send the unicast burst stream. 1736 o 504: This is used when the BRS does not support sending a unicast 1737 burst stream. 1739 o 505: This is used when the requesting RTP_Rx is not eligible to 1740 receive a unicast burst stream. 1742 o 506: This is used when RAMS functionality is not enabled for the 1743 requested multicast stream. 1745 o 507: This is used when the BRS cannot find a valid starting point 1746 for the unicast burst stream satisfying the RTP_Rx's requirements. 1748 o 508: This is used when the BRS cannot find the essential 1749 reference information for the requested multicast stream. 1751 o 509: This is used when the BRS cannot match the requested SSRC to 1752 any of the streams it is serving. 1754 o 510: This is used when the BRS cannot serve the requested entire 1755 session. 1757 o 511: This is used when the BRS sends only the preamble 1758 information but not the whole unicast burst stream. 1760 o 512: This is used when the RAMS request is denied due to a policy 1761 specified for the requested multicast stream, requesting RTP_Rx or 1762 this particular BRS. 1764 7.4. RAMS Termination 1766 The RAMS Termination (RAMS-T) message is identified by SFMT=3. 1768 The RAMS Termination is used to assist the BRS in determining when to 1769 stop the burst. A separate RAMS-T message is sent in the unicast 1770 burst RTP session by the RTP_Rx for each primary multicast stream 1771 that has been served by the BRS. Each of these RAMS-T message's 1772 media sender SSRC field SHALL BE populated with the SSRC of the media 1773 stream to be terminated. If the media sender SSRC populated in the 1774 RAMS-T message does not match the SSRC of the burst served by the 1775 BRS, BRS SHALL ignore the RAMS-T message. 1777 If the RTP_Rx wants the BRS to stop a burst prematurely, it sends a 1778 RAMS-T message as described below. Upon receiving this message, the 1779 BRS stops the respective burst immediately. If the RTP_Rx wants the 1780 BRS to terminate all of the bursts, it needs to send all of the 1781 respective RAMS-T messages in a single compound RTCP packet. 1783 The default behavior for the RTP_Rx is to send a RAMS-T message 1784 immediately after it joined the multicast session and started 1785 receiving multicast packets. In that case, the RTP_Rx includes the 1786 sequence number of the first RTP packet received in the primary 1787 multicast stream in the RAMS-T message. With this information, the 1788 BRS can decide when to terminate the unicast burst. 1790 The FCI field MUST contain only one RAMS Termination. The FCI field 1791 has the structure depicted in Figure 9. 1793 The semantics of the RAMS-T message is independent of the payload 1794 type carried in the primary multicast RTP session. 1796 0 1 2 3 1797 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 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 | SFMT=3 | Reserved | 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 : Optional TLV-encoded Fields (and Padding, if needed) : 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 Figure 9: FCI field syntax for the RAMS Termination message 1806 o Extended RTP Seqnum of First Multicast Packet (32 bits): Optional 1807 TLV element that specifies the extended RTP sequence number of the 1808 first packet received from the SSM session for a particular 1809 primary multicast stream. The low 16 bits contain the sequence 1810 number of the first packet received from the SSM session, and the 1811 most significant 16 bits extend that sequence number with the 1812 corresponding count of sequence number cycles, which can be 1813 maintained according to the algorithm in Appendix A.1 of 1814 [RFC3550]. 1816 Type: 61 1818 8. SDP Signaling 1820 8.1. Definitions 1822 The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585]. 1823 Here we add the following syntax to the 'rtcp-fb' attribute (the 1824 feedback type and optional parameters are all case sensitive): 1826 (In the following ABNF [RFC5234], rtcp-fb-nack-param is used as 1827 defined in [RFC4566].) 1829 rtcp-fb-nack-param =/ SP "rai" 1831 The following parameter is defined in this document for use with 1832 'nack': 1834 o 'rai' stands for Rapid Acquisition Indication and indicates the 1835 use of RAMS messages as defined in Section 7. 1837 This document also defines a new media-level SDP attribute ('rams- 1838 updates') that indicates whether the BRS supports updated request 1839 messages or not. This attribute is used in a declarative manner and 1840 no Offer/Answer Model behavior is specified. If the BRS supports 1841 updated request messages and this attribute is included in the SDP 1842 description, the RTP_Rx can send updated requests. The BRS might or 1843 might not be able to accept value changes in every field in an 1844 updated RAMS-R message. However, if the 'rams-updates' attribute is 1845 not included in the SDP description, the RTP_Rx SHALL NOT send 1846 updated requests. The RTP_Rx MAY still repeat its initial request 1847 without changes, though. 1849 8.2. Requirements 1851 The use of SDP to describe the RAMS entities normatively requires the 1852 support for: 1854 o The SDP grouping framework and flow identification (FID) semantics 1855 [RFC5888] 1857 o The RTP/AVPF profile [RFC4585] 1859 o The RTP retransmission payload format [RFC4588] 1861 o The RTCP extensions for SSM sessions with unicast feedback 1862 [RFC5760] 1864 o The 'multicast-rtcp' attribute [I-D.ietf-avt-rtcp-port-for-ssm] 1866 o Multiplexing RTP and RTCP on a single port on both endpoints in 1867 the unicast session [RFC5761] 1869 o The 'portmapping-req' attribute 1870 [I-D.ietf-avt-ports-for-ucast-mcast-rtp] 1872 The support for the source-specific media attributes [RFC5576] can 1873 also be needed when the 'ssrc' attribute is to be used for the media 1874 descriptions. 1876 8.3. Example and Discussion 1878 This section provides a declarative SDP [RFC4566] example (for the 1879 RTP_Rx side) for enabling rapid acquisition of multicast RTP 1880 sessions. 1882 v=0 1883 o=ali 1122334455 1122334466 IN IP4 rams.example.com 1884 s=Rapid Acquisition Example 1885 t=0 0 1886 a=group:FID 1 2 1887 a=rtcp-unicast:rsi 1888 m=video 41000 RTP/AVPF 98 1889 i=Primary Multicast Stream 1890 c=IN IP4 233.252.0.2/255 1891 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 1892 a=rtpmap:98 MP2T/90000 1893 a=multicast-rtcp:42000 1894 a=rtcp:43000 IN IP4 192.0.2.1 1895 a=rtcp-fb:98 nack 1896 a=rtcp-fb:98 nack rai 1897 a=ssrc:123321 cname:iptv-ch32@rams.example.com 1898 a=rams-updates 1899 a=mid:1 1900 m=video 51000 RTP/AVPF 99 1901 i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support) 1902 c=IN IP4 192.0.2.1 1903 a=sendonly 1904 a=rtpmap:99 rtx/90000 1905 a=rtcp-mux 1906 a=rtcp:51500 1907 a=fmtp:99 apt=98;rtx-time=5000 1908 a=portmapping-req:55000 1909 a=mid:2 1911 Figure 10: Example SDP for a single-channel RAMS scenario 1913 In this example SDP description, we have a primary multicast (source) 1914 stream and a unicast retransmission stream. The source stream is 1915 multicast from a distribution source (with a source IP address of 1916 198.51.100.1) to the multicast destination address of 233.252.0.2 and 1917 port 41000. The corresponding RTCP traffic is multicast to the same 1918 multicast destination address at port 42000. Here, we are assuming 1919 that the multicast RTP and RTCP ports are carefully chosen so that 1920 different RTP and RTCP streams do not collide with each other. 1922 The feedback target (FT_Ap) residing on the RS (with an address of 1923 192.0.2.1) at port 43000 is declared with the "a=rtcp" line 1924 [RFC3605]. The support for the conventional retransmission is 1925 indicated through the "a=rtcp-fb:98 nack" line. The RTP receiver(s) 1926 can report missing packets on the source stream to the feedback 1927 target and request retransmissions. The SDP above includes the 1928 "a=sendonly" line for the media description of the retransmission 1929 stream since the retransmissions are sent in only one direction. 1931 The support for rapid acquisition is indicated through the "a=rtcp- 1932 fb:98 nack rai" line. The parameter 'rtx-time' applies to both the 1933 conventional retransmissions and rapid acquisition. However, when 1934 rapid acquisition is enabled, the standard definition for the 1935 parameter 'rtx-time' given in [RFC4588] is not followed. Instead, 1936 when rapid acquisition support is enabled, 'rtx-time' specifies the 1937 time in milliseconds that the BRS keeps an RTP packet in its cache 1938 available for retransmission (measured from the time the packet was 1939 received by the BRS, not from the time indicated in the packet 1940 timestamp). 1942 Once an RTP_Rx has acquired an SDP description, it can ask for rapid 1943 acquisition before it joins a primary multicast RTP session. To do 1944 so, it sends a RAMS-R message to the feedback target of that primary 1945 multicast RTP session. If the FT_Ap is associated with only one RTP 1946 stream, the RTP_Rx does not need to learn the SSRC of that stream via 1947 an out-of-band method. If the BRS accepts the rapid acquisition 1948 request, it will send a RAMS-I message with the correct SSRC 1949 identifier. If the FT_Ap is associated with a multi-stream RTP 1950 session and the RTP_Rx is willing to request rapid acquisition for 1951 the entire session, the RTP_Rx again does not need to learn the SSRCs 1952 via an out-of-band method. However, if the RTP_Rx intends to request 1953 a particular subset of the primary multicast streams, it must learn 1954 their SSRC identifiers and list them in the RAMS-R message. Since 1955 this RTP_Rx has not yet received any RTP packets for the primary 1956 multicast stream(s), the RTP_Rx must in this case learn the SSRC 1957 value(s) from the 'ssrc' attribute of the media description 1958 [RFC5576]. In addition to the SSRC value, the 'cname' source 1959 attribute must also be present in the SDP description [RFC5576]. 1961 Listing the SSRC values for the primary multicast streams in the SDP 1962 file does not create a problem in SSM sessions when an SSRC collision 1963 occurs. This is because in SSM sessions, an RTP_Rx that observed an 1964 SSRC collision with a media sender must change its own SSRC [RFC5760] 1965 by following the rules defined in [RFC3550]. 1967 A feedback target that receives a RAMS-R message becomes aware that 1968 the RTP_Rx wants to rapidly catch up with a primary multicast RTP 1969 session. If the necessary conditions are satisfied (as outlined in 1970 Section 7 of [RFC4585]) and available resources exist, the BRS can 1971 react to the RAMS-R message by sending any transport-layer (and 1972 optional payload-specific, when allowed) feedback message(s) and 1973 starting the unicast burst. 1975 In this section, we considered the simplest scenario where the 1976 primary multicast RTP session carried only one stream and the RTP_Rx 1977 wanted to rapidly acquire this stream only. Best practices for 1978 scenarios where the primary multicast RTP session carries two or more 1979 streams or the RTP_Rx wants to acquire one or more streams from 1980 multiple primary multicast RTP sessions at the same time are 1981 presented in [I-D.begen-avt-rams-scenarios]. 1983 9. NAT Considerations 1985 For a variety of reasons, one or more Network Address Port 1986 Translators (NAPT - hereafter simply called NAT) can exist between 1987 the RTP_Rx and RS. NATs have a variety of operating characteristics 1988 for UDP traffic [RFC4787]. For a NAT to permit traffic from the BRS 1989 to arrive at the RTP_Rx, the NAT(s) must first either: 1991 a. See UDP (or DCCP) traffic sent from the RTP_Rx (which is on the 1992 'inside' of the NAT) to the BRS (which is on the 'outside' of the 1993 NAT). This traffic has the same transport address as the 1994 subsequent response traffic, or; 1996 b. Be configured to forward certain ports (e.g., using HTML 1997 configuration or UPnP IGD [UPnP-IGD]). Details of this are out 1998 of scope of this document. 2000 For both (a) and (b), the RTP_Rx is responsible for maintaining the 2001 NAT's state if it wants to receive traffic from the BRS on that port. 2002 For (a), the RTP_Rx MUST send UDP traffic to keep the NAT binding 2003 alive, at least every 30 seconds [RFC4787]. While (a) is more like 2004 an automatic/dynamic configuration, (b) is more like a manual/static 2005 configuration. 2007 When the RTP_Rx sends a request (RAMS-R) message to the FT as unicast 2008 feedback in the primary multicast RTP session, and the request is 2009 received by the FT, a new unicast burst RTP session will be 2010 established between the BRS and RTP_Rx. 2012 While the FT and BRS ports on the RS are already signaled via out-of- 2013 band means (e.g., SDP), the RTP_Rx needs to convey the RTP and RTCP 2014 ports it wants to use on its side for the new session. Since there 2015 are two RTP sessions (one multicast and one unicast) involved during 2016 this process and one of them is established upon a feedback message 2017 sent in the other one, this requires an explicit port mapping method. 2019 Applications using RAMS MUST support the method presented in 2020 [I-D.ietf-avt-ports-for-ucast-mcast-rtp] both on the RS and RTP_Rx 2021 side to allow RTP receivers to use their desired ports and to support 2022 RAMS behind NAT devices. The port mapping message exchange needs to 2023 take place whenever the RTP_Rx intends to make use of the RAMS 2024 protocol for rapidly acquiring a specific multicast RTP session, 2025 prior to joining the associated SSM session. 2027 10. Security Considerations 2029 Applications that are using RAMS make heavy use of the unicast 2030 feedback mechanism described in [RFC5760], the payload format defined 2031 in [RFC4588] and the port mapping solution specified in 2032 [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. Thus, these applications 2033 are subject to the general security considerations discussed in those 2034 documents. In particular, the threats and risks discussed in 2035 [RFC5760] need to be considered carefully. In this section, we give 2036 an overview of the guidelines and suggestions described in these 2037 specifications from a RAMS perspective. We also discuss the security 2038 considerations that explicitly apply to applications using RAMS. 2040 First of all, much of the session description information is 2041 available in the SDP descriptions that are distributed to the media 2042 senders, retransmission servers and RTP receivers. Adequate security 2043 measures are RECOMMENDED to ensure the integrity and authenticity of 2044 the SDP descriptions so that transport addresses of the media 2045 senders, distribution sources, feedback targets as well as other 2046 session-specific information can be protected. See [RFC4566] for 2047 details. 2049 Compared to an RTCP NACK message that triggers one or more 2050 retransmissions, a RAMS Request (RAMS-R) message can trigger a new 2051 burst stream to be sent by the retransmission server. Depending on 2052 the application-specific requirements and conditions existing at the 2053 time of the RAMS-R reception by the retransmission server, the 2054 resulting burst stream can potentially contain a large number of 2055 retransmission packets. Since these packets are sent faster than the 2056 nominal rate, RAMS consumes more resources on the retransmission 2057 servers, RTP receivers and the network. In particular, this can make 2058 denial-of-service (DoS) attacks more intense, and hence, more harmful 2059 than attacks that target ordinary retransmission sessions. 2061 As RAMS messages are sent as RTCP messages, following the suggestions 2062 given in [RFC4588], counter-measures SHOULD be taken to prevent 2063 tampered or spoofed RTCP packets. Tampered RAMS-R messages can 2064 trigger inappropriate burst streams or alter the existing burst 2065 streams in an inappropriate way. For example, if the Max Receive 2066 Bitrate field is altered by a tampered RAMS-R message, the updated 2067 burst can overflow the buffer at the receiver side, or oppositely, 2068 can slow down the burst to the point that it becomes useless. 2069 Tampered RAMS Termination (RAMS-T) messages can terminate valid burst 2070 streams prematurely resulting in gaps in the received RTP packets. 2072 RAMS Information (RAMS-I) messages contain fields that are critical 2073 for a successful rapid acquisition. Any tampered information in the 2074 RAMS-I message can easily cause an RTP receiver to make wrong 2075 decisions. Consequently, the RAMS operation can fail. 2077 RTCP BYE messages are similar to RAMS-T messages in the sense that 2078 they can be used to stop an existing burst. The CNAME of an RTP 2079 receiver is used to bind the RTCP BYE message to an existing burst. 2080 Thus, one should be careful if the CNAMEs are reasonably easy to 2081 guess and off-path attacks can be performed. Also note that the 2082 CNAMEs might be redistributed to all participants in the multicast 2083 group (as in ASM or the simple feedback model of [RFC5760]). 2085 The retransmission server has to consider if values indicated in a 2086 RAMS-R message are reasonable. For example, a request demanding a 2087 large value of many seconds in the Min RAMS Buffer Fill Requirement 2088 element should, unless special uses cases exist, likely be rejected 2089 since it is likely to be an attempt to prolong a DoS attack on the 2090 retransmission server, RTP receiver and/or the network. The Max 2091 Receive Bitrate could also be set to a very large value to try to get 2092 the retransmission server to cause massive congestion by bursting at 2093 a bitrate that will not be supported by the network. An RTP_Rx 2094 should also consider if the values for the Earliest Multicast Join 2095 Time and Burst Duration indicated by the retransmission server in a 2096 RAMS-I message are reasonable. For example, if the burst packets 2097 stop arriving and the join time is still significantly far into the 2098 future, this could be a sign of a man-in-the-middle attack where the 2099 RAMS-I message has been manipulated by an attacker. 2101 A basic mitigation against DoS attacks introduced by an attacker 2102 injecting tampered RAMS messages is source address validation 2103 [RFC2827]. Also, most of the DoS attacks can be prevented by the 2104 integrity and authenticity checks enabled by Secure RTP (SRTP) 2105 [RFC3711]. However, an attack can still be started by legitimate 2106 endpoints that send several valid RAMS-R messages to a particular 2107 feedback target in a synchronized fashion and in a very short amount 2108 of time. Since a RAMS operation can temporarily consume a large 2109 amount of resources, a series of the RAMS-R messages can temporarily 2110 overload the retransmission server. In these circumstances, the 2111 retransmission server can, for example, reject incoming RAMS requests 2112 until its resources become available again. One means to ameliorate 2113 this threat is to apply a per-endpoint policing mechanism on the 2114 incoming RAMS requests. A reasonable policing mechanism should 2115 consider application-specific requirements and minimize false 2116 negatives. 2118 In addition to the DoS attacks, man-in-the-middle and replay attacks 2119 will also be harmful. RAMS-R messages do not carry any information 2120 that allows the retransmission server to detect duplication or replay 2121 attacks. Thus, the possibility of a replay attack using a captured 2122 valid RAMS-R message exists unless a mitigation method such as Secure 2123 RTCP (SRTCP) is used. Similarly, RAMS-T messages can be replayed. 2124 The RAMS-I has sequence number that makes replay attacks less likely 2125 but not impossible. Man-in-the-middle attacks that are capable of 2126 capturing, injecting or modifying the RAMS messages can easily 2127 accomplish the attacks described above. Thus, cryptographic 2128 integrity and authentication is the only reliable protection. To 2129 protect the RTCP messages from man-in-the-middle and replay attacks, 2130 the RTP receivers and retransmission server SHOULD perform a DTLS- 2131 SRTP handshake [RFC5764] over the RTCP channel. Because there is no 2132 integrity-protected signaling channel between an RTP receiver and the 2133 retransmission server, the retransmission server MUST maintain a list 2134 of certificates owned by legitimate RTP receivers, or their 2135 certificates MUST be signed by a trusted Certificate Authority. Once 2136 the DTLS-SRTP security is established, non-SRTCP-protected messages 2137 received from a particular RTP receiver are ignored by the 2138 retransmission server. To reduce the impact of DTLS-SRTP overhead 2139 when communicating with different feedback targets on the same 2140 retransmission server, it is RECOMMENDED that RTP receivers and the 2141 retransmission server both support TLS Session Resumption without 2142 Server-side State [RFC5077]. To help scale SRTP to handle many RTP 2143 receivers asking for retransmissions of identical data, implementors 2144 may consider using the same SRTP key for SRTP data sent to the 2145 receivers [I-D.ietf-avt-srtp-ekt] and be aware that such key sharing 2146 allows those receivers to impersonate the sender, so source address 2147 validation remains important. 2149 [RFC4588] RECOMMENDS that the cryptography mechanisms are used for 2150 the retransmission payload format to provide protection against known 2151 plain-text attacks. As discussed in [RFC4588], the retransmission 2152 payload format sets the timestamp field in the RTP header to the 2153 media timestamp of the original packet and this does not compromise 2154 the confidentiality. Furthermore, if cryptography is used to provide 2155 security services on the original stream, then the same services, 2156 with equivalent cryptographic strength, MUST be provided on the 2157 retransmission stream per [RFC4588]. 2159 Finally, a retransmission server that has become subverted by an 2160 attacker is almost impossible to protect against as such a server can 2161 perform a large number of different actions to deny service to 2162 receivers. 2164 11. IANA Considerations 2166 The following contact information shall be used for all registrations 2167 in this document: 2169 Ali Begen 2170 abegen@cisco.com 2172 Note to the RFC Editor: In the following, please replace "XXXX" with 2173 the number of this document prior to publication as an RFC. 2175 11.1. Registration of SDP Attributes 2177 This document registers a new attribute name in SDP. 2179 SDP Attribute ("att-field"): 2180 Attribute name: rams-updates 2181 Long form: Support for Updated RAMS Request Messages 2182 Type of name: att-field 2183 Type of attribute: Media level 2184 Subject to charset: No 2185 Purpose: See this document 2186 Reference: [RFCXXXX] 2187 Values: None 2189 11.2. Registration of SDP Attribute Values 2191 This document registers a new value for the 'nack' attribute to be 2192 used with the 'rtcp-fb' attribute in SDP. For more information about 2193 the 'rtcp-fb' attribute, refer to Sections 4.2 and 6.2 of [RFC4585]. 2195 Value name: rai 2196 Long name: Rapid Acquisition Indication 2197 Usable with: nack 2198 Reference: [RFCXXXX] 2200 11.3. Registration of FMT Values 2202 Within the RTPFB range, the following format (FMT) value is 2203 registered: 2205 Name: RAMS 2206 Long name: Rapid Acquisition of Multicast Sessions 2207 Value: 6 2208 Reference: [RFCXXXX] 2210 11.4. SFMT Values for RAMS Messages Registry 2212 This document creates a new sub-registry for the sub-feedback message 2213 type (SFMT) values to be used with the FMT value registered for RAMS 2214 messages. The registry is called the SFMT Values for RAMS Messages 2215 Registry. This registry is to be managed by the IANA according to 2216 the Specification Required policy of [RFC5226]. 2218 The length of the SFMT field in the RAMS messages is a single octet, 2219 allowing 256 values. The registry is initialized with the following 2220 entries: 2222 Value Name Reference 2223 ----- -------------------------------------------------- ------------- 2224 0 Reserved [RFCXXXX] 2225 1 RAMS Request [RFCXXXX] 2226 2 RAMS Information [RFCXXXX] 2227 3 RAMS Termination [RFCXXXX] 2228 4-254 Assignable - Specification Required 2229 255 Reserved [RFCXXXX] 2231 The SFMT values 0 and 255 are reserved for future use. 2233 Any registration for an unassigned SFMT value needs to contain the 2234 following information: 2236 o Contact information of the one doing the registration, including 2237 at least name, address, and email. 2239 o A detailed description of what the new SFMT represents and how it 2240 shall be interpreted. 2242 New RAMS functionality is intended to be introduced by using the 2243 extension mechanism within the existing RAMS message types not by 2244 introducing new message types unless it is absolutely necessary. 2246 11.5. RAMS TLV Space Registry 2248 This document creates a new IANA TLV space registry for the RAMS 2249 extensions. The registry is called the RAMS TLV Space Registry. 2250 This registry is to be managed by the IANA according to the 2251 Specification Required policy of [RFC5226]. 2253 The length of the Type field in the TLV elements is a single octet, 2254 allowing 256 values. The Type values 0 and 255 are reserved for 2255 future use. The Type values between (and including) 128 and 254 are 2256 reserved for private extensions. 2258 The registry is initialized with the following entries: 2260 Type Description Reference 2261 ---- -------------------------------------------------- ------------- 2262 0 Reserved [RFCXXXX] 2263 1 Requested Media Sender SSRC(s) [RFCXXXX] 2264 2 Min RAMS Buffer Fill Requirement [RFCXXXX] 2265 3 Max RAMS Buffer Fill Requirement [RFCXXXX] 2266 4 Max Receive Bitrate [RFCXXXX] 2267 5 Request for Preamble Only [RFCXXXX] 2268 6 Supported Enterprise Number(s) [RFCXXXX] 2269 7-30 Assignable - Specification Required 2270 31 Media Sender SSRC [RFCXXXX] 2271 32 RTP Seqnum of the First Packet [RFCXXXX] 2272 33 Earliest Multicast Join Time [RFCXXXX] 2273 34 Burst Duration [RFCXXXX] 2274 35 Max Transmit Bitrate [RFCXXXX] 2275 36-60 Assignable - Specification Required 2276 61 Extended RTP Seqnum of First Multicast Packet [RFCXXXX] 2277 62-127 Assignable - Specification Required 2278 128-254 No IANA Maintenance 2279 255 Reserved [RFCXXXX] 2281 Any registration for an unassigned Type value needs to contain the 2282 following information: 2284 o Contact information of the one doing the registration, including 2285 at least name, address, and email. 2287 o A detailed description of what the new TLV element represents and 2288 how it shall be interpreted. 2290 11.6. RAMS Response Code Space Registry 2292 This document creates a new IANA TLV space registry for the RAMS 2293 response codes. The registry is called the RAMS Response Code Space 2294 Registry. This registry is to be managed by the IANA according to 2295 the Specification Required policy of [RFC5226]. 2297 The length of the Response field is two octets, allowing 65536 codes. 2298 However, the response codes have been classified and registered 2299 following an HTTP-style code numbering in this document. New 2300 response codes should be classified following the guidelines below: 2302 Code Level Purpose 2303 ---------- --------------- 2304 1xx Informational 2305 2xx Success 2306 3xx Redirection 2307 4xx RTP Receiver (RTP_Rx) Error 2308 5xx Burst/Retransmission Source (BRS) Error 2310 The Response code 65535 is reserved for future use. 2312 The registry is initialized with the following entries: 2314 Code Description Reference 2315 ----- -------------------------------------------------- ------------- 2316 0 A private response code is included in the message [RFCXXXX] 2318 100 Parameter update for RAMS session [RFCXXXX] 2320 200 RAMS request has been accepted [RFCXXXX] 2321 201 Unicast burst has been completed [RFCXXXX] 2323 400 Invalid RAMS-R message syntax [RFCXXXX] 2324 401 Invalid min buffer requirement in RAMS-R message [RFCXXXX] 2325 402 Invalid max buffer requirement in RAMS-R message [RFCXXXX] 2326 403 Insufficient max bitrate requirement in RAMS-R 2327 message [RFCXXXX] 2328 404 Invalid RAMS-T message syntax [RFCXXXX] 2330 500 An unspecified BRS internal error has occurred [RFCXXXX] 2331 501 BRS has insufficient bandwidth to start RAMS 2332 session [RFCXXXX] 2333 502 Burst is terminated due to network congestion [RFCXXXX] 2334 503 BRS has insufficient CPU cycles to start RAMS 2335 session [RFCXXXX] 2336 504 RAMS functionality is not available on BRS [RFCXXXX] 2337 505 RAMS functionality is not available for RTP_Rx [RFCXXXX] 2338 506 RAMS functionality is not available for 2339 the requested multicast stream [RFCXXXX] 2340 507 BRS has no valid starting point available for 2341 the requested multicast stream [RFCXXXX] 2342 508 BRS has no reference information available for 2343 the requested multicast stream [RFCXXXX] 2344 509 BRS has no RTP stream matching the requested SSRC [RFCXXXX] 2345 510 RAMS request to acquire the entire session 2346 has been denied [RFCXXXX] 2347 511 Only the preamble information is sent [RFCXXXX] 2348 512 RAMS request has been denied due to a policy [RFCXXXX] 2350 Any registration for an unassigned Response code needs to contain the 2351 following information: 2353 o Contact information of the one doing the registration, including 2354 at least name, address, and email. 2356 o A detailed description of what the new Response code describes and 2357 how it shall be interpreted. 2359 12. Contributors 2361 Dave Oran, Magnus Westerlund and Colin Perkins have contributed 2362 significantly to this specification by providing text and solutions 2363 to some of the issues raised during the development of this 2364 specification. 2366 13. Acknowledgments 2368 The following individuals have reviewed the earlier versions of this 2369 specification and provided helpful comments: Joerg Ott, Roni Even, 2370 Dan Wing, Tony Faustini, Peilin Yang, Jeff Goldberg, Muriel 2371 Deschanel, Orit Levin, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui 2372 Wang, Zixuan Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan 2373 Lennox, Jose Rey, Sean Sheedy and Keith Drage. 2375 14. References 2377 14.1. Normative References 2379 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2380 Jacobson, "RTP: A Transport Protocol for Real-Time 2381 Applications", STD 64, RFC 3550, July 2003. 2383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2384 Requirement Levels", BCP 14, RFC 2119, March 1997. 2386 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2387 Thyagarajan, "Internet Group Management Protocol, Version 2388 3", RFC 3376, October 2002. 2390 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 2391 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 2393 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 2394 Group Management Protocol Version 3 (IGMPv3) and Multicast 2395 Listener Discovery Protocol Version 2 (MLDv2) for Source- 2396 Specific Multicast", RFC 4604, August 2006. 2398 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2399 Description Protocol", RFC 4566, July 2006. 2401 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 2402 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 2404 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2405 "Extended RTP Profile for Real-time Transport Control 2406 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2407 July 2006. 2409 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 2410 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 2411 July 2006. 2413 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 2414 Protocol (RTCP) Extensions for Single-Source Multicast 2415 Sessions with Unicast Feedback", RFC 5760, February 2010. 2417 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2418 Media Attributes in the Session Description Protocol 2419 (SDP)", RFC 5576, June 2009. 2421 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2422 in Session Description Protocol (SDP)", RFC 3605, 2423 October 2003. 2425 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2426 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2428 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 2429 Real-Time Transport Control Protocol (RTCP): Opportunities 2430 and Consequences", RFC 5506, April 2009. 2432 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 2433 Header Extensions", RFC 5285, July 2008. 2435 [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 2436 Flows", RFC 6051, November 2010. 2438 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2439 Control Packets on a Single Port", RFC 5761, April 2010. 2441 [I-D.ietf-avt-rtcp-port-for-ssm] 2442 Begen, A., "RTP Control Protocol (RTCP) Port for Source- 2443 Specific Multicast (SSM) Sessions", 2444 draft-ietf-avt-rtcp-port-for-ssm-03 (work in progress), 2445 October 2010. 2447 [I-D.ietf-avt-ports-for-ucast-mcast-rtp] 2448 Begen, A. and B. Steeg, "Port Mapping Between Unicast and 2449 Multicast RTP Sessions", 2450 draft-ietf-avt-ports-for-ucast-mcast-rtp-02 (work in 2451 progress), May 2010. 2453 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 2454 Defeating Denial of Service Attacks which employ IP Source 2455 Address Spoofing", BCP 38, RFC 2827, May 2000. 2457 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2458 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2459 RFC 3711, March 2004. 2461 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 2462 Security (DTLS) Extension to Establish Keys for the Secure 2463 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 2465 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 2466 "Transport Layer Security (TLS) Session Resumption without 2467 Server-Side State", RFC 5077, January 2008. 2469 14.2. Informative References 2471 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2472 August 1980. 2474 [I-D.begen-avt-rams-scenarios] 2475 Begen, A., "Considerations for RAMS Scenarios", 2476 draft-begen-avt-rams-scenarios-00 (work in progress), 2477 October 2009. 2479 [I-D.ietf-avt-rtp-cnames] 2480 Begen, A., Perkins, C., and D. Wing, "Guidelines for 2481 Choosing RTP Control Protocol (RTCP) Canonical Names 2482 (CNAMEs)", draft-ietf-avt-rtp-cnames-02 (work in 2483 progress), November 2010. 2485 [I-D.ietf-avt-multicast-acq-rtcp-xr] 2486 Begen, A. and E. Friedrich, "Multicast Acquisition Report 2487 Block Type for RTP Control Protocol (RTCP) Extended 2488 Reports (XRs)", draft-ietf-avt-multicast-acq-rtcp-xr-01 2489 (work in progress), May 2010. 2491 [I-D.ietf-avt-ecn-for-rtp] 2492 Westerlund, M., Johansson, I., Perkins, C., and K. 2493 Carlberg, "Explicit Congestion Notification (ECN) for RTP 2494 over UDP", draft-ietf-avt-ecn-for-rtp-03 (work in 2495 progress), October 2010. 2497 [RFC6015] Begen, A., "RTP Payload Format for 1-D Interleaved Parity 2498 Forward Error Correction (FEC)", RFC 6015, October 2010. 2500 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 2501 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 2502 RFC 4787, January 2007. 2504 [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control 2505 Protocol (DCCP)", RFC 5762, April 2010. 2507 [I-D.ietf-avt-srtp-ekt] 2508 McGrew, D., Andreasen, F., Wing, D., and K. Fischer, 2509 "Encrypted Key Transport for Secure RTP", 2510 draft-ietf-avt-srtp-ekt-01 (work in progress), July 2010. 2512 [UPnP-IGD] 2513 Forum, UPnP., "Universal Plug and Play (UPnP) Internet 2514 Gateway Device (IGD)", November 2001. 2516 [IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing 2517 Channel Change Times in IPTV with Real-Time Transport 2518 Protocol (IEEE Internet Computing)", May 2009. 2520 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2521 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2522 May 2008. 2524 Authors' Addresses 2526 Bill VerSteeg 2527 Cisco 2528 5030 Sugarloaf Parkway 2529 Lawrenceville, GA 30044 2530 USA 2532 Email: billvs@cisco.com 2534 Ali Begen 2535 Cisco 2536 181 Bay Street 2537 Toronto, ON M5J 2T3 2538 Canada 2540 Email: abegen@cisco.com 2541 Tom VanCaenegem 2542 Alcatel-Lucent 2543 Copernicuslaan 50 2544 Antwerpen, 2018 2545 Belgium 2547 Email: Tom.Van_Caenegem@alcatel-lucent.be 2549 Zeev Vax 2550 Microsoft Corporation 2551 1065 La Avenida 2552 Mountain View, CA 94043 2553 USA 2555 Email: zeevvax@microsoft.com