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