idnits 2.17.1 draft-ietf-avt-rapid-acquisition-for-rtp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 605 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 (March 8, 2010) is 5163 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 2083, 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-09 == Outdated reference: A later version (-11) exists of draft-ietf-avt-ports-for-ucast-mcast-rtp-00 ** 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 (-06) exists of draft-begen-avt-rtp-mpeg2ts-preamble-04 == Outdated reference: A later version (-01) exists of draft-ietf-avt-multicast-acq-rtcp-xr-00 == Outdated reference: A later version (-03) exists of draft-ietf-avt-ecn-for-rtp-00 Summary: 5 errors (**), 0 flaws (~~), 10 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: September 9, 2010 T. VanCaenegem 6 Alcatel-Lucent 7 Z. Vax 8 Microsoft Corporation 9 March 8, 2010 11 Unicast-Based Rapid Acquisition of Multicast RTP Sessions 12 draft-ietf-avt-rapid-acquisition-for-rtp-08 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 may 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 may 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 to IETF 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), its areas, and its working groups. Note that 46 other groups may also distribute working documents as Internet- 47 Drafts. 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 The list of current Internet-Drafts can be accessed at 55 http://www.ietf.org/ietf/1id-abstracts.txt. 57 The list of Internet-Draft Shadow Directories can be accessed at 58 http://www.ietf.org/shadow.html. 60 This Internet-Draft will expire on September 9, 2010. 62 Copyright Notice 64 Copyright (c) 2010 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (http://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the BSD License. 77 This document may contain material from IETF Documents or IETF 78 Contributions published or made publicly available before November 79 10, 2008. The person(s) controlling the copyright in some of this 80 material may not have granted the IETF Trust the right to allow 81 modifications of such material outside the IETF Standards Process. 82 Without obtaining an adequate license from the person(s) controlling 83 the copyright in such materials, this document may not be modified 84 outside the IETF Standards Process, and derivative works of it may 85 not be created outside the IETF Standards Process, except to format 86 it for publication as an RFC or to translate it into languages other 87 than English. 89 Table of Contents 91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 92 1.1. Acquisition of RTP Streams vs. RTP Sessions . . . . . . . 7 93 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 8 94 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 8 95 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 96 4. Elements of Delay in Multicast Applications . . . . . . . . . 10 97 5. Protocol Design Considerations and Their Effect on 98 Resource Management for Rapid Acquisition . . . . . . . . . . 11 99 6. Rapid Acquisition of Multicast RTP Sessions . . . . . . . . . 13 100 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 101 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 14 102 6.3. Synchronization of Primary Multicast Streams . . . . . . 23 103 6.4. Burst Shaping and Congestion Control in RAMS . . . . . . 24 104 6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27 105 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 27 106 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . 28 107 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 29 108 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 29 109 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . 30 110 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . 32 111 7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . 35 112 8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 36 113 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 36 114 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 37 115 8.3. Example and Discussion . . . . . . . . . . . . . . . . . 37 116 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 40 117 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 118 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 119 11.1. Registration of SDP Attributes . . . . . . . . . . . . . 43 120 11.2. Registration of SDP Attribute Values . . . . . . . . . . 43 121 11.3. Registration of FMT Values . . . . . . . . . . . . . . . 43 122 11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . 44 123 11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 44 124 11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 45 125 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 47 126 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 127 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 48 128 14.1. draft-ietf-avt-rapid-acquisition-for-rtp-08 . . . . . . . 48 129 14.2. draft-ietf-avt-rapid-acquisition-for-rtp-07 . . . . . . . 48 130 14.3. draft-ietf-avt-rapid-acquisition-for-rtp-06 . . . . . . . 48 131 14.4. draft-ietf-avt-rapid-acquisition-for-rtp-05 . . . . . . . 48 132 14.5. draft-ietf-avt-rapid-acquisition-for-rtp-04 . . . . . . . 49 133 14.6. draft-ietf-avt-rapid-acquisition-for-rtp-03 . . . . . . . 49 134 14.7. draft-ietf-avt-rapid-acquisition-for-rtp-02 . . . . . . . 49 135 14.8. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 49 136 14.9. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 50 137 14.10. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 50 138 14.11. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 50 139 14.12. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 50 140 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 141 15.1. Normative References . . . . . . . . . . . . . . . . . . 51 142 15.2. Informative References . . . . . . . . . . . . . . . . . 53 143 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 145 1. Introduction 147 Most multicast flows carry a stream of inter-related data. Certain 148 information must first be acquired by the receivers to start 149 processing any data sent in the multicast session. This document 150 refers to this information as Reference Information. The Reference 151 Information is conventionally sent periodically in the multicast 152 session (although its content may change over time) and usually 153 consists of items such as a description of the schema for the rest of 154 the data, references to which data to process, encryption information 155 including keys, as well as any other information required to process 156 the data in the multicast stream [IC2009]. 158 Real-time multicast applications require the receivers to buffer 159 data. The receiver may have to buffer data to smooth out the network 160 jitter, to allow loss-repair methods such as Forward Error Correction 161 and retransmission to recover the missing packets, and to satisfy the 162 data processing requirements of the application layer. 164 When a receiver joins a multicast session, it has no control over 165 what point in the flow is currently being transmitted. Sometimes the 166 receiver may join the session right before the Reference Information 167 is sent in the session. In this case, the required waiting time is 168 usually minimal. Other times, the receiver may join the session 169 right after the Reference Information has been transmitted. In this 170 case, the receiver has to wait for the Reference Information to 171 appear again in the flow before it can start processing any multicast 172 data. In some other cases, the Reference Information is not 173 contiguous in the flow but dispersed over a large period, which 174 forces the receiver to wait for all of the Reference Information to 175 arrive before starting to process the rest of the data. 177 The net effect of waiting for the Reference Information and waiting 178 for various buffers to fill up is that the receivers may experience 179 significantly large delays in data processing. In this document, we 180 refer to the difference between the time an RTP receiver joins the 181 multicast session and the time the RTP receiver acquires all the 182 necessary Reference Information as the Acquisition Delay. The 183 acquisition delay may not be the same for different receivers; it 184 usually varies depending on the join time, length of the Reference 185 Information repetition (or appearance) interval, size of the 186 Reference Information as well as the application and transport 187 properties. 189 The varying nature of the acquisition delay adversely affects the 190 receivers that frequently switch among multicast sessions. In this 191 specification, we address this problem for RTP-based multicast 192 applications and describe a method that uses the fundamental tools 193 offered by the existing RTP and RTCP protocols [RFC3550]. In this 194 method, either the multicast source (or the distribution source in a 195 source-specific multicast (SSM) session) retains the Reference 196 Information for a period after its transmission, or an intermediary 197 network element (that we refer to as Retransmission Server) joins the 198 multicast session and continuously caches the Reference Information 199 as it is sent in the session and acts as a feedback target (See 200 [RFC5760]) for the session. When an RTP receiver wishes to join the 201 same multicast session, instead of simply issuing a Source Filtering 202 Group Management Protocol (SFGMP) Join message, it sends a request to 203 the feedback target for the session and asks for the Reference 204 Information. The retransmission server starts a new unicast RTP 205 (retransmission) session and sends the Reference Information to the 206 RTP receiver over that session. If there is spare bandwidth, the 207 retransmission server may burst the Reference Information faster than 208 its natural rate. As soon as the receiver acquires the Reference 209 Information, it can join the multicast session and start processing 210 the multicast data. A simplified network diagram showing this method 211 through an intermediary network element is depicted in Figure 1. 213 This method potentially reduces the acquisition delay. We refer to 214 this method as Unicast-based Rapid Acquisition of Multicast RTP 215 Sessions. A primary use case for this method is to reduce the 216 channel-change times in IPTV networks where compressed video streams 217 are multicast in different SSM sessions and viewers randomly join 218 these sessions. 220 ----------------------- 221 +--->| Intermediary | 222 | | Network Element | 223 | ...|(Retransmission Server)| 224 | : ----------------------- 225 | : 226 | v 227 ----------- ---------- ---------- 228 | Multicast | | |---------->| Joining | 229 | Source |------->| Router |..........>| RTP | 230 | | | | | Receiver | 231 ----------- ---------- ---------- 232 | 233 | ---------- 234 +---------------->| Existing | 235 | RTP | 236 | Receiver | 237 ---------- 239 -------> Multicast RTP Flow 240 .......> Unicast RTP Flow 242 Figure 1: Rapid acquisition through an intermediary network element 244 A principle design goal in this solution is to use the existing tools 245 in the RTP/RTCP protocol family. This improves the versatility of 246 the existing implementations, and promotes faster deployment and 247 better interoperability. To this effect, we use the unicast 248 retransmission support of RTP [RFC4588] and the capabilities of RTCP 249 to handle the signaling needed to accomplish the acquisition. 251 1.1. Acquisition of RTP Streams vs. RTP Sessions 253 By the definition given in [RFC3550], an RTP session may involve one 254 or more RTP streams each identified with a unique SSRC. All RTP 255 streams within a single RTP session are sent towards the same 256 transport address, i.e., they share the same destination IP address 257 and port. In RTP jargon, these streams are said to be SSRC- 258 multiplexed. On the other hand, an SSM session is uniquely 259 identified by its source address and destination group address. 260 However, it may carry one or more RTP sessions, each associated with 261 a different destination port. Consequently, while it is not very 262 practical, it is still possible for an SSM session to carry multiple 263 RTP sessions each carrying multiple SSRC-multiplexed RTP streams. 265 Developing a protocol that can jointly handle the rapid acquisition 266 of all of the RTP sessions in an SSM session is neither practical nor 267 necessary. Rather, in this specification we focus on developing a 268 protocol that handles the rapid acquisition of a single RTP session 269 (called primary multicast RTP session) carrying one or more RTP 270 streams (called primary multicast streams). If desired, multiple 271 instances of this protocol may be run in parallel to acquire multiple 272 RTP sessions simultaneously. 274 When an RTP receiver requests the Reference Information from the 275 retransmission server, it may opt to rapidly acquire a specific 276 subset of the available RTP streams in the primary multicast RTP 277 session. Alternatively, it may request the rapid acquisition of all 278 of the RTP streams in that RTP session. Regardless of how many RTP 279 streams are requested by the RTP receiver or how many will be 280 actually sent by the retransmission server, only one unicast RTP 281 (retransmission) session will be established by the retransmission 282 server serving as the feedback target for that RTP session. The RTP 283 receiver multiplexes this unicast RTP session with the primary 284 multicast RTP session it receives as part of the SSM session. If the 285 RTP receiver wants to rapidly acquire multiple RTP sessions 286 simultaneously, separate unicast RTP (retransmission) sessions will 287 be established for each of them. 289 1.2. Outline 291 In the rest of this specification, we have the following outline: In 292 Section 4, we describe the delay components in generic multicast 293 applications. Section 5 presents an overview of the protocol design 294 considerations for rapid acquisition. We provide the protocol 295 details of the rapid acquisition method in Section 6 and Section 7. 296 Section 8 and Section 9 discuss the SDP signaling issues with 297 examples and NAT-related issues, respectively. Finally, Section 10 298 discusses the security considerations. 300 Section 3 provides a list of the definitions frequently used in this 301 document. 303 2. Requirements Notation 305 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 306 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 307 document are to be interpreted as described in [RFC2119]. 309 3. Definitions 311 This document uses the following acronyms and definitions frequently: 313 (Primary) SSM (or Multicast) Session: The multicast session to which 314 RTP receivers can join at a random point in time. 316 Primary Multicast RTP Session: The multicast RTP session an RTP 317 receiver is interested in acquiring rapidly. A primary SSM session 318 may carry multiple multicast RTP sessions, but only one of them can 319 be the primary from the viewpoint of rapid acquisition. 321 Primary Multicast (RTP) Streams: The RTP stream(s) carried in the 322 primary multicast RTP session. 324 Source Filtering Group Management Protocol (SFGMP): Following the 325 definition in [RFC4604], SFGMP refers to the Internet Group 326 Management Protocol (IGMP) version 3 [RFC3376] and the Multicast 327 Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and 328 IPv6 networks, respectively. However, the rapid acquisition method 329 introduced in this document does not depend on a specific version of 330 either of these group management protocols. In the remainder of this 331 document, SFGMP will refer to any group management protocol that has 332 Join and Leave functionalities. 334 Feedback Target (FT): Unicast RTCP feedback target as defined in 335 [RFC5760]. FT_Ap denotes a specific feedback target running on a 336 particular address and port. 338 Retransmission (Burst) Packet: An RTP packet that is formatted as 339 defined in [RFC4588]. 341 Reference Information: The set of certain media content and metadata 342 information that is sufficient for an RTP receiver to start usefully 343 consuming a media stream. The meaning, format and size of this 344 information are specific to the application and are out of scope of 345 this document. 347 Preamble Information: A more compact form of the whole or a subset 348 of the Reference Information transmitted out-of-band. 350 (Unicast) Burst (Stream): A unicast stream of RTP retransmission 351 packets that enable an RTP receiver to rapidly acquire the Reference 352 Information associated with a primary multicast stream. Each burst 353 stream is identified by its SSRC identifier that is unique in the 354 primary multicast RTP session. The burst streams are typically 355 transmitted at an accelerated rate. 357 Retransmission Server (RS): The RTP/RTCP endpoint that can generate 358 the retransmission packets and the burst streams. RS may also 359 generate other non-retransmission packets to aid the rapid 360 acquisition process. 362 4. Elements of Delay in Multicast Applications 364 In an any-source (ASM) or a source-specific (SSM) multicast delivery 365 system, there are three major elements that contribute to the overall 366 acquisition delay when an RTP receiver switches from one multicast 367 session to another one. These are: 369 o Multicast switching delay 371 o Reference Information latency 373 o Buffering delays 375 Multicast switching delay is the delay that is experienced to leave 376 the current multicast session (if any) and join the new multicast 377 session. In typical systems, the multicast join and leave operations 378 are handled by a group management protocol. For example, the 379 receivers and routers participating in a multicast session may use 380 the Internet Group Management Protocol (IGMP) version 3 [RFC3376] or 381 the Multicast Listener Discovery Protocol (MLD) version 2 [RFC3810]. 382 In either of these protocols, when a receiver wants to join a 383 multicast session, it sends a message to its upstream router and the 384 routing infrastructure sets up the multicast forwarding state to 385 deliver the packets of the multicast session to the new receiver. 386 Depending on the proximity of the upstream router, the current state 387 of the multicast tree, the load on the system and the protocol 388 implementation, the join times vary. Current systems provide join 389 latencies usually less than 200 milliseconds (ms). If the receiver 390 had been participating in another multicast session before joining 391 the new session, it needs to send a Leave message to its upstream 392 router to leave the session. In common multicast routing protocols, 393 the leave times are usually smaller than the join times, however, it 394 is possible that the Leave and Join messages may get lost, in which 395 case the multicast switching delay inevitably increases. 397 Reference Information latency is the time it takes the receiver to 398 acquire the Reference Information. It is highly dependent on the 399 proximity of the actual time the receiver joined the session to the 400 next time the Reference Information will be sent to the receivers in 401 the session, whether the Reference Information is sent contiguously 402 or not, and the size of the Reference Information. For some 403 multicast flows, there is a little or no interdependency in the data, 404 in which case the Reference Information latency will be nil or 405 negligible. For other multicast flows, there is a high degree of 406 interdependency. One example of interest is the multicast flows that 407 carry compressed audio/video. For these flows, the Reference 408 Information latency may become quite large and be a major contributor 409 to the overall delay. Refer to [I-D.begen-avt-rtp-mpeg2ts-preamble] 410 for details. 412 The buffering component of the overall acquisition delay is driven by 413 the way the application layer processes the payload. In many 414 multicast applications, an unreliable transport protocol such as UDP 415 [RFC0768] is often used to transmit the data packets, and the 416 reliability, if needed, is usually addressed through other means such 417 as Forward Error Correction (e.g., 418 [I-D.ietf-fecframe-interleaved-fec-scheme]) and retransmission. 419 These loss-repair methods require buffering at the receiver side to 420 function properly. In many applications, it is also often necessary 421 to de-jitter the incoming data packets before feeding them to the 422 application. The de-jittering process also increases the buffering 423 delays. Besides these network-related buffering delays, there are 424 also specific buffering needs that are required by the individual 425 applications. For example, standard video decoders typically require 426 an amount, sometimes a significant amount, of coded video data to be 427 available in the pre-decoding buffers prior to starting to decode the 428 video bitstream. 430 5. Protocol Design Considerations and Their Effect on Resource 431 Management for Rapid Acquisition 433 Rapid acquisition is an optimization of a system that must continue 434 to work correctly and properly whether or not the optimization is 435 effective, or even fails due to lost control and feedback messages, 436 congestion, or other problems. This is fundamental to the overall 437 design requirements surrounding the protocol definition and to the 438 resource management schemes to be employed together with the protocol 439 (e.g., QoS machinery, server load management, etc). In particular, 440 the system needs to operate within a number of constraints: 442 o First, a rapid acquisition operation must fail gracefully. The 443 user experience must, except perhaps in pathological 444 circumstances, be not significantly worse for trying and failing 445 to complete rapid acquisition compared to simply joining the 446 multicast session. 448 o Second, providing the rapid acquisition optimizations must not 449 cause collateral damage to either the multicast session being 450 joined, or other multicast sessions sharing resources with the 451 rapid acquisition operation. In particular, the rapid acquisition 452 operation must avoid interference with the multicast session that 453 may be simultaneously being received by other hosts. In addition, 454 it must also avoid interference with other multicast sessions 455 sharing the same network resources. These properties are 456 possible, but are usually difficult to achieve. 458 One challenge is the existence of multiple bandwidth bottlenecks 459 between the receiver and the server(s) in the network providing the 460 rapid acquisition service. In commercial IPTV deployments, for 461 example, bottlenecks are often present in the aggregation network 462 connecting the IPTV servers to the network edge, the access links 463 (e.g., DSL, DOCSIS) and in the home network of the subscribers. Some 464 of these links may serve only a single subscriber, limiting 465 congestion impact to the traffic of only that subscriber, but others 466 can be shared links carrying multicast sessions of many subscribers. 467 Also note that the state of these links may be varying over time. 468 The receiver may have knowledge of a portion of this network, or may 469 have partial knowledge of the entire network. The methods employed 470 by the devices to acquire this network state information is out of 471 scope for this document. The receiver should be able to signal the 472 server with the bandwidth that it believes it can handle. The server 473 also needs to be able to rate limit the flow in order to stay within 474 the performance envelope that it knows about. Both the server and 475 receiver need to be able to inform the other of changes in the 476 requested and delivered rates. However, the protocol must be robust 477 in the presence of packet loss, so this signaling must include the 478 appropriate default behaviors. 480 A second challenge is that for some uses (e.g., high-bitrate video) 481 the unicast burst bitrate is high while the flow duration of the 482 unicast burst is short. This is because the purpose of the unicast 483 burst is to allow the RTP receiver to join the multicast quickly and 484 thereby limit the overall resources consumed by the burst. Such 485 high-bitrate, short-duration flows are not amenable to conventional 486 admission control techniques. For example, end-to-end per-flow 487 signaled admission control techniques such as RSVP have too much 488 latency and control channel overhead to be a good fit for rapid 489 acquisition. Similarly, using a TCP (or TCP-like) approach with a 490 3-way handshake and slow-start to avoid inducing congestion would 491 defeat the purpose of attempting rapid acquisition in the first place 492 by introducing many round-trip times (RTT) of delay. 494 These observations lead to certain unavoidable requirements and goals 495 for a rapid acquisition protocol. These are: 497 o The protocol must be designed to allow a deterministic upper bound 498 on the extra bandwidth used (compared to just joining the 499 multicast session). A reasonable size bound is e*B, where B is 500 the nominal bandwidth of the primary multicast streams, and e is 501 an excess-bandwidth coefficient. The total duration of the 502 unicast burst must have a reasonable bound; long unicast bursts 503 devolve to the bandwidth profile of multi-unicast for the whole 504 system. 506 o The scheme should minimize (or better eliminate) the overlap of 507 the unicast burst and the primary multicast stream. This 508 minimizes the window during which congestion could be induced on a 509 bottleneck link compared to just carrying the multicast or unicast 510 packets alone. 512 o The scheme must minimize (or better eliminate) any gap between the 513 unicast burst and the primary multicast stream, which has to be 514 repaired later, or in the absence of repair, will result in loss 515 being experienced by the application. 517 In addition to the above, there are some other protocol design issues 518 to be considered. First, there is at least one RTT of "slop" in the 519 control loop. In starting a rapid acquisition burst, this manifests 520 as the time between the client requesting the unicast burst and the 521 burst description and/or the first unicast burst packets arriving at 522 the receiver. For managing and terminating the unicast burst, there 523 are two possible approaches for the control loop: The receiver can 524 adapt to the unicast burst as received, converge based on observation 525 and explicitly terminate the unicast burst with a second control loop 526 exchange (which takes a minimum of one RTT, just as starting the 527 unicast burst does). Alternatively, the server generating the 528 unicast burst can pre-compute the burst parameters based on the 529 information in the initial request and tell the receiver the burst 530 duration. 532 The protocol described in the next section allows either method of 533 controlling the rapid acquisition unicast burst. 535 6. Rapid Acquisition of Multicast RTP Sessions 537 We start this section with an overview of the rapid acquisition of 538 multicast sessions (RAMS) method. 540 6.1. Overview 542 [RFC5760] specifies an extension to the RTP Control Protocol (RTCP) 543 to use unicast feedback in an SSM session. It defines an 544 architecture that introduces the concept of Distribution Source, 545 which - in an SSM context - distributes the RTP data and 546 redistributes RTCP information to all RTP receivers. This RTCP 547 information is retrieved from the Feedback Target, to which RTCP 548 unicast feedback traffic is sent. The feedback target MAY be 549 implemented in one or more entities different from the Distribution 550 Source, and different RTP receivers MAY use different feedback 551 targets. 553 This document builds further on these concepts to reduce the 554 acquisition delay when an RTP receiver joins a multicast session at a 555 random point in time by introducing the concept of the Burst Source 556 and new RTCP feedback messages. The Burst Source has a cache where 557 the most recent packets from the primary multicast RTP session are 558 continuously stored. When an RTP receiver wants to receive a primary 559 multicast stream prior to joining the SSM session, it may first 560 request a unicast burst from the Burst Source. In this burst, the 561 packets are formatted as RTP retransmission packets [RFC4588] and 562 carry the Reference Information. This information allows the RTP 563 receiver to start usefully consuming the RTP packets sent in the 564 primary multicast RTP session. 566 Using an accelerated bitrate (as compared to the nominal bitrate of 567 the primary multicast stream) for the unicast burst implies that at a 568 certain point in time, the payload transmitted in the unicast burst 569 is going to be the same as the payload in the associated multicast 570 stream, i.e., the unicast burst will catch up with the primary 571 multicast stream. At this point, the RTP receiver no longer needs to 572 receive the unicast burst and can join the SSM session. This method 573 is referred to as the Rapid Acquisition of Multicast Sessions (RAMS). 575 This document proposes extensions to [RFC4585] for an RTP receiver to 576 request a unicast burst as well as for additional control messaging 577 that can be leveraged during the acquisition process. 579 6.2. Message Flows 581 Figure 2 shows the main entities involved in rapid acquisition and 582 the message flows. They are 584 o Multicast Source 586 o Feedback Target (FT) 588 o Burst/Retransmission Source 590 o RTP Receiver (RTP_Rx) 591 ----------- -------------- 592 | |----------------------------------->| | 593 | |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.>| | 594 | | | | 595 | Multicast | ---------------- | | 596 | Source | | Retransmission | | | 597 | |------->| Server (RS) |--------->| | 598 | |.-.-.-.>| |.-.-.-.-.>| | 599 | | | ------------ | | | 600 ----------- | | Feedback | |<.=.=.=.=.| | 601 | | Target | |<~~~~~~~~~| RTP Receiver | 602 | ------------ | | (RTP_Rx) | 603 | | | | 604 | ------------ | | | 605 | | Burst and | |<~~~~~~~~>| | 606 | | Retrans. | |.........>| | 607 | | Source | |<.=.=.=.=>| | 608 | ------------ | | | 609 | | | | 610 ---------------- -------------- 612 -------> Multicast RTP Flow 613 .-.-.-.> Multicast RTCP Flow 614 .=.=.=.> Unicast RTCP Reports 615 ~~~~~~~> Unicast RTCP Feedback Messages 616 .......> Unicast RTP Flow 618 Figure 2: Flow diagram for unicast-based rapid acquisition 620 The feedback target (FT) is the entity as defined in [RFC5760], to 621 which RTP_Rx sends its RTCP feedback messages indicating packet loss 622 by means of an RTCP NACK message or indicating RTP_Rx's desire to 623 rapidly acquire the primary multicast RTP session by means of an RTCP 624 feedback message defined in this document. While the Burst/ 625 Retransmission Source is responsible for responding to these messages 626 and for further RTCP interaction with RTP_Rx in the case of a rapid 627 acquisition process, it is assumed in the remainder of the document 628 that these two logical entities (FT and Burst/Retransmission Source) 629 are combined in a single physical entity and they share state. In 630 the remainder of the text, the term Retransmission Server (RS) will 631 be used whenever appropriate, to refer to the combined functionality 632 of the FT and Burst/Retransmission Source. 634 However, it must be noted that only FT is involved in the primary 635 multicast RTP session, whereas the Burst/Retransmission Source 636 transmits the unicast burst and retransmission packets both formatted 637 as RTP retransmission packets [RFC4588] in a single separate unicast 638 RTP retransmission session to each RTP_Rx. In the retransmission 639 session, as in any other RTP session, RS and RTP_Rx regularly send 640 the periodic sender and receiver reports, respectively. 642 The unicast burst is triggered by an RTCP feedback message that is 643 defined in this document based on the common packet format provided 644 in [RFC4585], whereas an RTP retransmission is triggered by an RTCP 645 NACK message defined in [RFC4585]. In the RTP/AVPF profile, there 646 are certain rules that apply to scheduling of both of these messages, 647 which are detailed in Section 3.5 of [RFC4585]. One of the rules 648 states that in a multi-party session such as the SSM sessions we are 649 considering in this specification, an RTP receiver cannot send an 650 RTCP feedback message for a minimum of one second period after 651 joining the session (i.e., Tmin=1.0 second). While this rule has the 652 goal of avoiding problems associated with flash crowds in typical 653 multi-party sessions, it defeats the purpose of rapid acquisition. 654 Furthermore, when RTP receivers delay their messages requesting a 655 burst by a deterministic or even a random amount, it still does not 656 make a difference since such messages are not related and their 657 timings are independent from each other. Thus, in this specification 658 we initialize Tmin to zero and allow the RTP receivers to send a 659 burst request message right at the beginning. It should, however, be 660 emphasized that for the subsequent messages during rapid acquisition, 661 the timing rules of [RFC4585] still apply. 663 Figure 3 depicts an example of messaging flow for rapid acquisition. 664 The RTCP feedback messages are explained below. The optional 665 messages are indicated in parentheses and they may or may not be 666 present during rapid acquisition. Note that in a scenario where 667 rapid acquisition is performed by a feedback target co-located with 668 the media sender, the same method (with the identical message flows) 669 still applies. 671 ------------------------- 672 | Retransmission Server | 673 ----------- | ------ ------------ | -------- ------------ 674 | Multicast | | | FT | | Burst/Ret. | | | | | RTP | 675 | Source | | | | | Source | | | Router | | Receiver | 676 | | | ------ ------------ | | | | (RTP_Rx) | 677 ----------- | | | | -------- ------------ 678 | ------------------------- | | 679 | | | | | 680 |-- RTP Multicast ---------->--------------->| | 681 |-. RTCP Multicast -.-.-.-.->-.-.-.-.-.-.-.->| | 682 | | | | | 683 | | |********************************| 684 | | |* PORT MAPPING SETUP *| 685 | | |********************************| 686 | | | | | 687 | |<~~~~~~~~~~~~~~~~~~~~~~~~~ RTCP RAMS-R ~~~| 688 | | | | | 689 | | |********************************| 690 | | |* UNICAST SESSION ESTABLISHED *| 691 | | |********************************| 692 | | | | | 693 | | |~~~ RTCP RAMS-I ~~~~~~~~~~~~~~~>| 694 | | | | | 695 | | |... Unicast RTP Burst .........>| 696 | | | | | 697 | |<~~~~~~~~~~~~~~~~~~~~~~~~ (RTCP RAMS-R) ~~| 698 | | | | | 699 | | |~~ (RTCP RAMS-I) ~~~~~~~~~~~~~~>| 700 | | | | | 701 | | | | | 702 | | | |<= SFGMP Join ==| 703 | | | | | 704 |-- RTP Multicast ------------------------------------------->| 705 |-. RTCP Multicast -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.>| 706 | | | | | 707 | | | | | 708 | | |<~~~~~~~~~~~~~~~ RTCP RAMS-T ~~~| 709 | | | | | 710 | | | | | 711 | |<~~~~~~~~~~~~~~~~~~~~~~~~~~ (RTCP NACK) ~~| 712 | | | | | 713 | | | | | 714 | | |...(Unicast Retransmissions)...>| 715 | | | | | 716 : : : : : 717 : : : : : 718 | | |<.=.= Unicast RTCP Reports .=.=>| 719 : : : : : 720 : : : : : 721 | | | | | 723 -------> Multicast RTP Flow 724 .-.-.-.> Multicast RTCP Flow 725 .=.=.=.> Unicast RTCP Reports 726 ~~~~~~~> Unicast RTCP Feedback Messages 727 =======> SFGMP Messages 728 .......> Unicast RTP Flow 730 Figure 3: Message flows for unicast-based rapid acquisition 732 This document defines the expected behaviors of RS and RTP_Rx. It is 733 instructive to have independently operating implementations on RS and 734 RTP_Rx that request the burst, describe the burst, start the burst, 735 join the multicast session and stop the burst. These implementations 736 send messages to each other, but there must be provisions for the 737 cases where the control messages get lost, or re-ordered, or are not 738 being delivered to their destinations. 740 The following steps describe rapid acquisition in detail: 742 1. Port Mapping Setup: For the primary multicast RTP session, the 743 RTP and RTCP destination ports are declaratively specified 744 (Refer to Section 8 for examples in SDP). However, in the 745 unicast RTP retransmission session, RTP_Rx needs to choose its 746 receive ports for RTP and RTCP. Since this unicast session is 747 established after RTP_Rx sends its rapid acquisition request and 748 it is received by RS in the primary multicast RTP session, 749 RTP_Rx MUST setup the port mappings between the unicast and 750 multicast sessions and send this mapping information to RS 751 before it sends its request so that RS knows how to communicate 752 with RTP_Rx. 754 The details of this setup procedure and other NAT-related issues 755 are left to Section 9 to keep the present discussion focused on 756 the RAMS message flows. 758 2. Request: RTP_Rx sends a rapid acquisition request for the 759 primary multicast RTP session to the feedback target address of 760 that session. The request contains the SSRC identifier of 761 RTP_Rx and may contain the media sender SSRC identifier(s) 762 associated with the desired primary multicast stream(s). This 763 RTCP feedback message is defined as the RAMS-Request (RAMS-R) 764 message and may contain parameters that constrain the burst, 765 such as the buffer and bandwidth limits. 767 Before joining the SSM session, RTP_Rx learns the addresses for 768 the multicast source, group and RS by out-of-band means. If 769 RTP_Rx desires to rapidly acquire only a subset of the primary 770 multicast streams available in the primary multicast RTP 771 session, the SSRC identifiers for the desired RTP streams MUST 772 also be obtained out-of-band, since no RTP packets have been 773 received yet for those streams. Based on this information, 774 RTP_Rx populates the desired SSRC(s) in its request message. 776 When RS successfully receives the RAMS-R message, it responds to 777 it by accepting or rejecting the request. Right before RS sends 778 any RTP or RTCP packet(s) described below, it establishes the 779 unicast RTP retransmission session. 781 3. Response: RS sends RAMS-Information (RAMS-I) message(s) to 782 RTP_Rx to convey the status for the burst(s) requested by 783 RTP_Rx. The RAMS-I message is sent by the Burst/Retransmission 784 Source logical entity that is part of RS. 786 In cases where the primary multicast RTP session associated with 787 FT_Ap on which the RAMS-R message was received contains only a 788 single primary multicast stream, RS SHALL always use the SSRC of 789 the RTP stream associated with FT_Ap in the RAMS-I message(s) 790 regardless of the media sender SSRC specified in the RAMS-R 791 message. In such cases the 'ssrc' attribute MAY be omitted from 792 the media description. If the requested SSRC and the actual 793 media sender SSRC do not match, RS SHOULD explicitly populate 794 the correct media sender SSRC in the initial RAMS-I message. 796 FT_Ap could also be associated with an RTP session that carries 797 two or more primary multicast streams. If RTP_Rx will issue a 798 collective request to receive the whole primary multicast RTP 799 session, it does not need the 'ssrc' attributes to be described 800 in the media description. Note that if FT_Ap is associated with 801 two or more RTP sessions, RTP_Rx's request will be ambiguous. 802 Thus, each FT_Ap MUST be associated with a single RTP session. 804 If RTP_Rx is willing to rapidly acquire only a subset of the 805 primary multicast streams, the RAMS-R message MUST explicitly 806 list the media sender SSRCs. Upon receiving such a message, RS 807 MAY accept the request for only the media sender SSRC(s) that 808 matched one of the RTP streams it serves. It MUST reject all 809 other requests with the appropriate response code. 811 * Reject Responses: RS MUST take into account any limitations 812 that MAY have been specified by RTP_Rx in the RAMS-R message 813 when making a decision regarding the request. If RTP_Rx has 814 requested to acquire the whole primary multicast RTP session 815 but RS cannot provide a rapid acquisition service for any of 816 the primary multicast streams, RS MUST reject the request via 817 a single RAMS-I message with a collective reject response 818 code and whose media sender SSRC field is set to one of SSRCs 819 served by this FT_Ap. Upon receiving this RAMS-I message, 820 RTP_Rx abandons the rapid acquisition attempt and may 821 immediately join the multicast session by sending an SFGMP 822 Join message towards its upstream multicast router. 824 In all other cases, RS MUST send a separate RAMS-I message 825 with the appropriate response code for each primary multicast 826 stream that has been requested by RTP_Rx but cannot be served 827 by RS. 829 * Accept Responses: RS MUST send a separate RAMS-I message 830 with the appropriate response code for each primary multicast 831 stream that has been requested by RTP_Rx and will be served 832 by RS. Such RAMS-I messages comprise fields that can be used 833 to describe the individual unicast burst streams. 835 A particularly important field carries the RTP sequence 836 number of the first packet transmitted in the respective RTP 837 stream to allow RTP_Rx to detect any missing initial 838 packet(s). Note that the first RTP packet transmitted in an 839 RTP stream is not necessarily a burst packet. It could be a 840 payload-specific RTP packet, which is payload-type- 841 multiplexed with the burst packets (See 842 [I-D.begen-avt-rtp-mpeg2ts-preamble] for an example). When 843 RS accepts the request, this field MUST be populated in the 844 RAMS-I message and the initial RAMS-I message SHOULD precede 845 the unicast burst or be sent at the start of the burst so 846 that RTP_Rx may quickly detect any missing initial packet(s). 848 Where possible, it is RECOMMENDED to include all RAMS-I messages 849 in the same compound RTCP packet. However, it is possible that 850 the RAMS-I message for a primary multicast stream may get 851 delayed or lost, and RTP_Rx may start receiving RTP packets 852 before receiving a RAMS-I message. Thus, RTP_Rx SHOULD NOT make 853 protocol dependencies on quickly receiving the initial RAMS-I 854 message. For redundancy purposes, it is RECOMMENDED that RS 855 repeats the RAMS-I messages multiple times as long as it follows 856 the RTCP timer rules defined in [RFC4585]. 858 4. Unicast Burst: For the primary multicast stream(s) for which 859 the request is accepted, RS starts sending the unicast burst(s) 860 that comprises one or more RTP retransmission packets. The 861 burst packet(s) are sent by the Burst/Retransmission Source 862 logical entity. In addition, there MAY be optional payload- 863 specific information that RS chooses to send to RTP_Rx. Such an 864 example is discussed in [I-D.begen-avt-rtp-mpeg2ts-preamble] for 865 transmitting the payload-specific information for MPEG2 866 Transport Streams. 868 5. Updated Request: RTP_Rx MAY send an updated RAMS-R message (to 869 the FT entity of RS) with a different value for one or more 870 fields of an earlier RAMS-R message. Upon receiving an updated 871 request, RS may use the updated values for sending/shaping the 872 burst, or refine the values and use the refined values for 873 sending/shaping the burst. Subsequently, RS MAY send an updated 874 RAMS-I message to indicate the changes it made. 876 However, the updated RAMS-I message may get lost. It is also 877 possible that the updated RAMS-R message could have been lost. 878 Thus, RTP_Rx SHOULD NOT make protocol dependencies on quickly 879 (or ever) receiving an updated RAMS-I message, or assume that RS 880 will honor the requested changes. 882 RTP_Rx may be in an environment where the available resources 883 are time-varying, which may or may not deserve sending a new 884 updated request. Determining the circumstances where RTP_Rx 885 should or should not send an updated request and the methods 886 that RTP_Rx can use to detect and evaluate the time-varying 887 available resources are not specified in this document. 889 6. Updated Response: RS may send more than one RAMS-I messages, 890 e.g., to update the value of one or more fields in an earlier 891 RAMS-I message. The updated RAMS-I messages may or may not be a 892 direct response to a RAMS-R message. RS may also send updated 893 RAMS-I messages to signal RTP_Rx in real time to join the 894 multicast session. RTP_Rx depends on RS to learn the join time, 895 which can be conveyed by the first RAMS-I message, or can be 896 sent/revised in a later RAMS-I message. If RS is not capable of 897 determining the join time in the initial RAMS-I message, it MUST 898 send another RAMS-I message (with the join time information) 899 later. 901 7. Multicast Join Signaling: The RAMS-I message allows RS to 902 signal explicitly when RTP_Rx SHOULD send the SFGMP Join 903 message. If the request is accepted, this information MUST be 904 conveyed in at least one RAMS-I message and its value MAY be 905 updated by subsequent RAMS-I messages. If RTP_Rx has received 906 multiple RAMS-I messages, it SHOULD use the information from the 907 most recent RAMS-I message. 909 There may be missing packets if RTP_Rx joins the multicast 910 session too early or too late. For example, if RTP_Rx starts 911 receiving the primary multicast stream while it is still 912 receiving the unicast burst at a high excess bitrate, this may 913 result in an increased risk of packet loss. Or, if RTP_Rx joins 914 the multicast session some time after the unicast burst is 915 finished, there may be a gap between the burst and multicast 916 data (a number of RTP packets may be missing). In both cases, 917 RTP_Rx may issue retransmissions requests (via RTCP NACK 918 messages) [RFC4585] to the FT entity of RS to fill the gap. RS 919 may or may not respond to such requests. When it responds and 920 the response causes significant changes in one or more values 921 reported earlier to RTP_Rx, an updated RAMS-I should be sent to 922 RTP_Rx. 924 8. Multicast Receive: After the join, RTP_Rx starts receiving the 925 primary multicast stream(s). 927 9. Terminate: RS may know when it needs to ultimately stop the 928 unicast burst based on its parameters. However, RTP_Rx may need 929 to ask RS to terminate the burst prematurely or at a specific 930 sequence number. For this purpose, it uses the RAMS-Termination 931 (RAMS-T) message. A separate RAMS-T message is sent for each 932 primary multicast stream served by RS unless an RTCP BYE message 933 has been sent as described in Step 10. For the burst requests 934 that were rejected by RS, there is no need to send a RAMS-T 935 message. 937 If RTP_Rx wants to terminate a burst prematurely, it SHALL send 938 a plain RAMS-T message for the particular primary multicast 939 stream, and upon receiving this message RS MUST terminate the 940 unicast burst. If RTP_Rx requested to acquire the entire 941 primary multicast RTP session but wants to terminate this 942 request before it learns the individual media sender SSRC(s) via 943 RAMS-I message(s), it cannot use RAMS-T message(s) and thus MUST 944 send an RTCP BYE message to terminate the request. 946 Otherwise, the default behavior for RTP_Rx is to send a RAMS-T 947 message right after it joined the multicast session and started 948 receiving multicast packets. In that case, RTP_Rx SHALL send a 949 RAMS-T message with the sequence number of the first RTP packet 950 received in the primary multicast stream, and RS SHOULD 951 terminate the respective burst after it sends the unicast burst 952 packet whose Original Sequence Number (OSN) field in the RTP 953 retransmission payload header matches this number minus one. 955 RTP_Rx MUST send at least one RAMS-T message for each primary 956 multicast stream served by RS (if an RTCP BYE message has not 957 been issued yet as described in Step 10). The RAMS-T message(s) 958 MUST be addressed to the Burst/Retransmission Source logical 959 entity. Against the possibility of a message loss, it is 960 RECOMMENDED that RTP_Rx repeats the RAMS-T messages multiple 961 times as long as it follows the RTCP timer rules defined in 962 [RFC4585]. 964 10. Terminate with RTCP BYE: When RTP_Rx is receiving one or more 965 burst streams, if RTP_Rx becomes no longer interested in 966 acquiring any of the primary multicast streams, RTP_Rx SHALL 967 issue an RTCP BYE message for the RTP retransmission session and 968 another RTCP BYE message for the primary multicast RTP session. 969 These RTCP BYE messages are sent to the Burst/Retransmission 970 Source and FT logical entities, respectively. 972 Upon receiving an RTCP BYE message, the Burst/Retransmission 973 Source logical entity MUST terminate the rapid acquisition 974 operation, and cease transmitting any further burst packets and 975 retransmission packets. If support for [RFC5506] has been 976 signaled, the RTCP BYE message MAY be sent in a reduced-size 977 RTCP packet. Otherwise, Section 6.1 of [RFC3550] mandates the 978 RTCP BYE message always to be sent with a sender or receiver 979 report in a compound RTCP packet (If no data has been received, 980 an empty receiver report MUST be still included). With the 981 information contained in the receiver report, RS can figure out 982 how many duplicate RTP packets have been delivered to RTP_Rx 983 (Note that this will be an upper-bound estimate as one or more 984 packets might have been lost during the burst transmission). 985 The impact of duplicate packets and measures that can be taken 986 to minimize the impact of receiving duplicate packets will be 987 addressed in Section 6.4. 989 Note that an RTCP BYE message issued for the RTP retransmission 990 session terminates the whole session and ceases transmitting any 991 further packets in that RTP session. Thus, in this case there 992 is no need for sending explicit RAMS-T messages, which would 993 only terminate their respective bursts. 995 For the purpose of gathering detailed information about RTP_Rx's 996 rapid acquisition experience, [I-D.ietf-avt-multicast-acq-rtcp-xr] 997 defines an RTCP Extended Report (XR) Block. This report is designed 998 to be payload-independent, thus, it can be used by any multicast 999 application that supports rapid acquisition. Support for this XR 1000 report is, however, OPTIONAL. 1002 6.3. Synchronization of Primary Multicast Streams 1004 When RTP_Rx acquires multiple primary multicast streams, it may need 1005 to synchronize them for the playout. This synchronization is 1006 traditionally achieved by the help of the RTCP sender reports 1007 [RFC3550]. If the playout will start before RTP_Rx has joined the 1008 multicast session, RTP_Rx must receive the information reflecting the 1009 synchronization among the primary multicast streams early enough so 1010 that it can play out the media in a synchronized fashion. However, 1011 this would require RS to cache the sender reports sent in the primary 1012 multicast RTP session(s), and piggyback the latest synchronization 1013 information on its own sender report and send an early sender report 1014 in the unicast RTP retransmission session. This issue and its 1015 implications are discussed in detail in 1016 [I-D.ietf-avt-rapid-rtp-sync]. 1018 An alternative approach is to use the RTP header extension mechanism 1019 [RFC5285] and convey the synchronization information in a header 1020 extension as defined in [I-D.ietf-avt-rapid-rtp-sync]. 1022 [RFC4588] says that retransmission packets SHOULD carry the same 1023 header extension carried in the header of the original RTP packets. 1024 Thus, as long as the multicast source emits a header extension with 1025 the synchronization information frequently enough, there is no 1026 additional task that needs to be carried out by RS. The 1027 synchronization information will be sent to RTP_Rx along with the 1028 burst packets. The frequent header extensions sent in the primary 1029 multicast RTP sessions also allow rapid synchronization of the RTP 1030 streams for the RTP receivers that do not support RAMS or that 1031 directly join the multicast session without running RAMS. Thus, in 1032 RAMS applications, it is RECOMMENDED that the multicast sources 1033 frequently send synchronization information by using header 1034 extensions following the rules presented in 1035 [I-D.ietf-avt-rapid-rtp-sync]. It should be noted that the regular 1036 sender reports are still sent in the unicast session by following the 1037 rules of [RFC3550]. 1039 6.4. Burst Shaping and Congestion Control in RAMS 1041 This section provides informative guidelines about how RS can shape 1042 the transmission of the unicast burst and how congestion can be dealt 1043 within the RAMS process. 1045 A higher bitrate for the unicast burst naturally conveys the 1046 Reference Information and media content to RTP_Rx faster. This way, 1047 RTP_Rx can start consuming the data sooner, which results in a faster 1048 acquisition. A higher bitrate also represents a better utilization 1049 of RS resources. As the burst may continue until it catches up with 1050 the primary multicast stream, the higher the bursting bitrate, the 1051 less data RS needs to transmit. However, a higher bitrate for the 1052 burst also increases the chances for congestion-caused packet loss. 1053 Thus, as discussed in Section 5, there must be an upper bound on the 1054 bandwidth used by the burst. 1056 When RS transmits the burst, it should take into account all 1057 available information to prevent any packet loss that may take place 1058 during the bursting as a result of buffer overflow on the path 1059 between RS and RTP_Rx and at RTP_Rx itself. The bursting bitrate may 1060 be determined by taking into account the following information, when 1061 available: 1063 a. Information obtained via the RAMS-R message, such as Max RAMS 1064 Buffer Fill Requirement and/or Max Receive Bitrate (See 1065 Section 7.2). 1067 b. Information obtained via RTCP receiver reports provided by RTP_Rx 1068 in the retransmission session, allowing in-session bitrate 1069 adaptations for the burst. When these receiver reports indicate 1070 packet loss, this may indicate a certain congestion state in the 1071 path from RS to RTP_Rx. 1073 c. Information obtained via RTCP NACKs provided by RTP_Rx in the 1074 primary multicast RTP session, allowing in-session bitrate 1075 adaptations for the burst. Such RTCP NACKs are transmitted by 1076 RTP_Rx in response to packet loss detection in the burst. NACKs 1077 may indicate a certain congestion state on the path from RS to 1078 RTP_Rx. 1080 d. There may be other feedback received from RTP_Rx, e.g., in the 1081 form of ECN-CE markings [I-D.ietf-avt-ecn-for-rtp] that may 1082 influence in-session bitrate adaptation. 1084 e. Information obtained via updated RAMS-R messages, allowing in- 1085 session bitrate adaptations, if supported by RS. 1087 f. Transport protocol-specific information. For example, when DCCP 1088 is used to transport the RTP burst, the ACKs from the DCCP client 1089 can be leveraged by the RS / DCCP server for burst shaping and 1090 congestion control. 1092 g. Pre-configured settings for each RTP_Rx or a set of RTP_Rxs that 1093 indicate the upper-bound bursting bitrates for which no packet 1094 loss will occur as a result of congestion along the path of RS to 1095 RTP_Rx. For example, in managed IPTV networks, where the 1096 bottleneck bandwidth along the end-to-end path is known and where 1097 the network between RS and this link is provisioned and 1098 dimensioned to carry the burst streams, the bursting bitrate does 1099 not exceed the provisioned value. These settings may also be 1100 dynamically adapted using application-aware knowledge. 1102 RS chooses the initial burst bitrate as follows: 1104 o When using RAMS in environments as described in (g), RS MUST 1105 transmit the burst packets at an initial bitrate higher than the 1106 nominal bitrate, but within the engineered or reserved bandwidth 1107 limit. 1109 o When RS cannot determine a reliable bitrate value for the unicast 1110 burst (through a or g), RS should choose an appropriate initial 1111 bitrate not above the nominal bitrate and increase it gradually 1112 unless a congestion is detected. 1114 In both cases, during the burst transmission RS MUST continuously 1115 monitor for packet losses as a result of congestion by means of one 1116 or more of the mechanisms described in (b,c,d,e,f). When RS relies 1117 on RTCP receiver reports, sufficient bandwidth must be provided to 1118 RTP Rx for RTCP transmission. To achieve a reasonable fast 1119 adaptation against congestion, it is recommended that RTP_Rx sends a 1120 receiver report at least once every two RTTs between RS and RTP_Rx. 1121 Although the specific heuristics and algorithms that deduce a 1122 congestion state and how subsequently RS should act are outside the 1123 scope of this specification, the following two practices are 1124 recommended: 1126 o Upon detection of a significant packet loss, which RS attributes 1127 to congestion, RS should decrease the burst bitrate. The rate by 1128 which RS increases and decreases the bitrate for the burst may be 1129 determined by a TCP-friendly bitrate adaptation algorithm for RTP 1130 over UDP , or in the case of (f) by the congestion control 1131 algorithms defined in DCCP [I-D.ietf-dccp-rtp]. 1133 o If the congestion is persistent and RS has to reduce the burst 1134 bitrate to a point where the RTP Rx buffer may underrun or the 1135 burst will consume too much RS resources, RS should terminate the 1136 burst and transmit a RAMS-I message to RTP Rx with the appropriate 1137 response code. It is then up to RTP Rx to decide when to join the 1138 multicast session. 1140 In case there is no congestion experienced during the burst, a 1141 specific situation occurs near the end of the unicast burst, when RS 1142 has almost no more additional data to sustain the relatively higher 1143 burst bitrate, thus, the upper-bound burst bitrate automatically gets 1144 limited by the nominal bitrate of the primary multicast stream. 1145 During this time frame, RTP_Rx eventually needs to join the multicast 1146 session. This means that both the burst packets and the multicast 1147 packets may be simultaneously received by RTP_Rx for a period of 1148 time, enhancing the risk of congestion again. 1150 Since RS signals RTP_Rx when it should send the SFGMP Join message, 1151 RS may have a rough estimate of when RTP_Rx will start receiving 1152 multicast packets in the SSM session. RS may keep on sending burst 1153 packets but should reduce the bitrate accordingly at the appropriate 1154 instant by taking the bitrate of the whole SSM session into account. 1155 If RS ceases transmitting the burst packets before the burst catches 1156 up, any gap resulting from this imperfect switch-over by RTP_Rx can 1157 be later repaired by requesting retransmissions for the missing 1158 packets from RS. The retransmissions may be shaped by RS to make 1159 sure that they do not cause collateral loss in the primary multicast 1160 RTP session and the RTP retransmission session. 1162 6.5. Failure Cases 1164 In the following, we examine the implications of losing the RAMS-R, 1165 RAMS-I or RAMS-T messages and other failure cases. 1167 When RTP_Rx sends a RAMS-R message to initiate a rapid acquisition 1168 but the message gets lost and RS does not receive it, RTP_Rx will get 1169 neither a RAMS-I message, nor a unicast burst. In this case, RTP_Rx 1170 MAY resend the request when it is eligible to do so based on the RTCP 1171 timer rules defined in [RFC4585]. Or, after a reasonable amount of 1172 time, RTP_Rx may time out (based on the previous observed response 1173 times) and immediately join the SSM session. 1175 In the case RTP_Rx starts receiving a unicast burst but it does not 1176 receive a corresponding RAMS-I message within a reasonable amount of 1177 time, RTP_Rx may either discard the burst data or decide not to 1178 interrupt the unicast burst, and be prepared to join the SSM session 1179 at an appropriate time it determines or as indicated in a subsequent 1180 RAMS-I message (if available). To minimize the chances of losing the 1181 RAMS-I messages, it is RECOMMENDED that RS repeats the RAMS-I 1182 messages multiple times based on the RTCP timer rules defined in 1183 [RFC4585]. 1185 In the failure cases where the RAMS-R message is lost and RTP_Rx 1186 gives up, or the RAMS-I message is lost, RTP_Rx MUST still terminate 1187 the burst(s) it requested by following the rules described in 1188 Section 6.2. 1190 In the case a RAMS-T message sent by RTP_Rx does not reach its 1191 destination, RS may continue sending burst packets even though RTP_Rx 1192 no longer needs them. In such cases, it is RECOMMENDED that RTP_Rx 1193 repeats the RAMS-T message multiple times based on the RTCP timer 1194 rules defined in [RFC4585]. In the worst case, RS MUST be 1195 provisioned to deterministically terminate the burst when it can no 1196 longer send the burst packets faster than it receives the primary 1197 multicast stream packets. 1199 Section 6.3.5 of [RFC3550] explains the rules pertaining to timing 1200 out an SSRC. When RS accepts to serve the requested burst(s) and 1201 establishes the retransmission session, it should check the liveness 1202 of RTP_Rx via the RTCP messages and reports RTP_Rx sends. The 1203 default rules explained in [RFC3550] apply in RAMS as well. 1205 7. Encoding of the Signaling Protocol in RTCP 1207 This section defines the formats of the RTCP transport-layer feedback 1208 messages that are exchanged between the retransmission server (RS) 1209 and RTP receiver (RTP_Rx) during rapid acquisition. These messages 1210 are referred to as the RAMS Messages. They are payload-independent 1211 and MUST be used by all RTP-based multicast applications that support 1212 rapid acquisition regardless of the payload they carry. 1214 Payload-specific feedback messages are not defined in this document. 1215 However, further optional payload-independent and payload-specific 1216 information can be included in the exchange. 1218 The common packet format for the RTCP feedback messages is defined in 1219 Section 6.1 of [RFC4585]. Each feedback message has a fixed-length 1220 field for version, padding, feedback message type (FMT), payload type 1221 (PT), length, SSRC of packet sender, SSRC of media sender as well as 1222 a variable-length field for feedback control information (FCI). 1224 In the RAMS messages, the PT field is set to RTPFB (205) and the FMT 1225 field is set to RAMS (6). Individual RAMS messages are identified by 1226 a sub-field called Sub Feedback Message Type (SFMT). Any Reserved 1227 field SHALL be set to zero and ignored. 1229 Depending on the specific scenario and timeliness/importance of a 1230 RAMS message, it may be desirable to send it in a reduced-size RTCP 1231 packet [RFC5506]. However, unless support for [RFC5506] has been 1232 signaled, compound RTCP packets MUST be used by following [RFC3550] 1233 rules. 1235 Following the rules specified in [RFC3550], all integer fields in the 1236 messages defined below are carried in network-byte order, that is, 1237 most significant byte (octet) first, also known as big-endian. 1238 Unless otherwise noted, numeric constants are in decimal (base 10). 1240 7.1. Extensions 1242 To improve the functionality of the RAMS method in certain 1243 applications, it may be desirable to define new fields in the RAMS 1244 Request, Information and Termination messages. Such fields MUST be 1245 encoded as TLV elements as described below and sketched in Figure 4: 1247 o Type: A single-octet identifier that defines the type of the 1248 parameter represented in this TLV element. 1250 o Length: A two-octet field that indicates the length (in octets) 1251 of the TLV element excluding the Type and Length fields, and the 1252 8-bit Reserved field between them. Note that this length does not 1253 include any padding that is required for alignment. 1255 o Value: Variable-size set of octets that contains the specific 1256 value for the parameter. 1258 In the extensions, the Reserved field SHALL be set to zero and 1259 ignored. If a TLV element does not fall on a 32-bit boundary, the 1260 last word MUST be padded to the boundary using further bits set to 1261 zero. 1263 In a RAMS message, any vendor-neutral or private extension MUST be 1264 placed after the mandatory fields (if any). The extensions MAY be 1265 placed in any order. The support for extensions is OPTIONAL. 1267 0 1 2 3 1268 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 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Type | Reserved | Length | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 : Value : 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 Figure 4: Structure of a TLV element 1277 7.1.1. Vendor-Neutral Extensions 1279 If the goal in defining new TLV elements is to extend the 1280 functionality in a vendor-neutral manner, they MUST be registered 1281 with IANA through the guidelines provided in Section 11.5. 1283 The current document defines several vendor-neutral extensions in the 1284 subsequent sections. 1286 7.1.2. Private Extensions 1288 It is desirable to allow vendors to use private extensions in a TLV 1289 format. For interoperability, such extensions MUST NOT collide with 1290 each other. 1292 A certain range of TLV Types (between - and including - 128 and 254 ) 1293 is reserved for private extensions (Refer to Section 11.5). IANA 1294 management for these extensions is unnecessary and they are the 1295 responsibility of individual vendors. 1297 The structure that MUST be used for the private extensions is 1298 depicted in Figure 5. Here, the enterprise numbers are used from 1299 http://www.iana.org/assignments/enterprise-numbers. This will ensure 1300 the uniqueness of the private extensions and avoid any collision. 1302 0 1 2 3 1303 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 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | Type | Reserved | Length | 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 | Enterprise Number | 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 : Value : 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 Figure 5: Structure of a private extension 1314 7.2. RAMS Request 1316 The RAMS Request message is identified by SFMT=1. This message is 1317 used by RTP_Rx to request rapid acquisition for a primary multicast 1318 RTP session, or one or more primary multicast streams belonging to 1319 the same primary multicast RTP session. 1321 Unless signaled otherwise, a RAMS-R message is used to request a 1322 single primary multicast stream whose SSRC is indicated in the media 1323 sender SSRC field of the message header. In cases where RTP_Rx does 1324 not know the media sender SSRC, it MUST set that field to its own 1325 SSRC. 1327 If RTP_Rx wants to request two or more primary multicast streams or 1328 all of the streams in the primary multicast RTP session, RTP_Rx MUST 1329 provide explicit signaling as described below and set the media 1330 sender SSRC field to its own SSRC to minimize the chances of 1331 accidentally requesting a wrong primary multicast stream. 1333 The FCI field MUST contain only one RAMS Request. The FCI field has 1334 the structure depicted in Figure 6. 1336 0 1 2 3 1337 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 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | SFMT=1 | Reserved | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 : Optional TLV-encoded Fields (and Padding, if needed) : 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 Figure 6: FCI field syntax for the RAMS Request message 1346 o Requested Media Sender SSRC(s): Optional TLV element that lists 1347 the media sender SSRC(s) requested by RTP_Rx. If this TLV element 1348 does not exist in the RAMS-R message, it means that RTP_Rx is only 1349 interested in a single primary multicast stream whose media sender 1350 SSRC is already specified in the header of the RAMS-R message. 1351 However, if this TLV element exists, RS MUST ignore the media 1352 sender SSRC specified in the header of the RAMS-R message. If 1353 this TLV element exists but the Length field is set to zero, 1354 meaning that no media sender SSRC is listed, it means that RTP_Rx 1355 is requesting to rapidly acquire the entire primary multicast RTP 1356 session. Otherwise, RTP_Rx lists the individual media sender 1357 SSRCs in this TLV element and sets the Length field of the TLV 1358 element to 4*n, where n is the number of SSRC entries. 1360 Type: 1 1362 o Min RAMS Buffer Fill Requirement (32 bits): Optional TLV element 1363 that denotes the minimum milliseconds of data that RTP_Rx desires 1364 to have in its buffer before allowing the data to be consumed by 1365 the application. 1367 RTP_Rx may have knowledge of its buffering requirements. These 1368 requirements may be application and/or device specific. For 1369 instance, RTP_Rx may need to have a certain amount of data in its 1370 application buffer to handle transmission jitter and/or to be able 1371 to support error-control methods. If RS is told the minimum 1372 buffering requirement of the receiver, it may tailor the burst(s) 1373 more precisely, e.g., by choosing an appropriate starting point. 1374 The methods used by RTP_Rx to determine this value are application 1375 specific, and thus, out of the scope of this document. 1377 If specified, the amount of backfill that will be provided by the 1378 unicast bursts and any payload-specific information MUST NOT be 1379 smaller than the specified value since it will not be able to 1380 build up the desired level of buffer at RTP_Rx and may cause 1381 buffer underruns. 1383 Type: 2 1385 o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element 1386 that denotes the maximum milliseconds of data that RTP_Rx can 1387 buffer without losing the data due to buffer overflow. 1389 RTP_Rx may have knowledge of its buffering requirements. These 1390 requirements may be application or device specific. For instance, 1391 one particular RTP_Rx may have more physical memory than another 1392 RTP_Rx, and thus, can buffer more data. If RS knows the buffering 1393 ability of the receiver, it may tailor the burst(s) more 1394 precisely. The methods used by the receiver to determine this 1395 value are application specific, and thus, out of scope. 1397 If specified, the amount of backfill that will be provided by the 1398 unicast bursts and any payload-specific information MUST NOT be 1399 larger than this value since it may cause buffer overflows at 1400 RTP_Rx. 1402 Type: 3 1404 o Max Receive Bitrate (64 bits): Optional TLV element that denotes 1405 the maximum bitrate (in bits per second) that the RTP receiver can 1406 process the aggregation of the unicast burst(s) and any payload- 1407 specific information that will be provided by RS. The limits may 1408 include local receiver limits as well as network limits that are 1409 known to the receiver. 1411 If specified, the total bitrate of the unicast burst(s) plus any 1412 payload-specific information MUST NOT be larger than this value 1413 since it may cause congestion and packet loss. 1415 Type: 4 1417 o Request for Preamble Only (0 bits): Optional TLV element that 1418 indicates that RTP_Rx is only requesting the preamble information 1419 for the desired primary multicast stream(s). If this TLV element 1420 exists in the RAMS-R message, RS SHOULD NOT send any burst packets 1421 other than the preamble packets. Note that this TLV element does 1422 not carry a Value field. Thus, the Length field MUST be set to 1423 zero. 1425 Type: 5 1427 The semantics of the RAMS-R feedback message is independent of the 1428 payload type. 1430 7.3. RAMS Information 1432 The RAMS Information message is identified by SFMT=2. This message 1433 is used to describe the unicast burst that will be sent for rapid 1434 acquisition. It also includes other useful information for RTP_Rx as 1435 described below. 1437 A separate RAMS-I message with the appropriate response code is sent 1438 by RS for each primary multicast stream that has been requested by 1439 RTP_Rx. In the RAMS-I messages, the media sender SSRC and packet 1440 sender SSRC fields are both set to the SSRC of the respective primary 1441 multicast stream. 1443 The FCI field MUST contain only one RAMS Information. The FCI field 1444 has the structure depicted in Figure 7. 1446 0 1 2 3 1447 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 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | SFMT=2 | MSN | Response | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 : Optional TLV-encoded Fields (and Padding, if needed) : 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 Figure 7: FCI field syntax for the RAMS Information message 1456 A RAMS-I message has the following fields: 1458 o Message Sequence Number (8 bits) : Mandatory field that denotes 1459 the sequence number of the RAMS-I message for the particular media 1460 sender SSRC specified in the message header. The MSN value SHALL 1461 be set to zero only when a new RAMS request is received. During 1462 rapid acquisition, the same RAMS-I message MAY be repeated for 1463 redundancy purposes without incrementing the MSN value. If an 1464 updated RAMS-I message will be sent (either with a new information 1465 or an updated information), the MSN value SHALL be incremented by 1466 one. In the MSN field, the regular wrapping rules apply. 1468 o Response (16 bits): Mandatory field that denotes the RS response 1469 code for this RAMS-I message. This document defines several 1470 initial response codes and registers them with IANA. If a new 1471 vendor-neutral response code will be defined, it MUST be 1472 registered with IANA through the guidelines specified in 1473 Section 11.6. If the new response code is intended to be used 1474 privately by a vendor, there is no need for IANA management. 1475 Instead, the vendor MUST use the private extension mechanism 1476 (Section 7.1.2) to convey its message and MUST indicate this by 1477 putting zero in the Response field. 1479 The following TLV elements have been defined for the RAMS-I messages: 1481 o Media Sender SSRC (32 bits): Optional TLV element that specifies 1482 the media sender SSRC of the unicast burst stream. While this 1483 information is already available in the message header, it may be 1484 useful to repeat it in an explicit field. For example, if FT_Ap 1485 that received the RAMS-R message is associated with a single 1486 primary multicast stream but the requested media sender SSRC does 1487 not match the SSRC of the RTP stream associated with this FT_Ap, 1488 RS SHOULD include this TLV element in the initial RAMS-I message 1489 to let RTP_Rx know that the media sender SSRC has changed. If the 1490 two SSRCs match, there is no need to include this TLV element. 1492 Type: 31 1494 o RTP Seqnum of the First Packet (16 bits): TLV element that 1495 specifies the RTP sequence number of the first packet that will be 1496 sent in the respective RTP stream. This allows RTP_Rx to know 1497 whether one or more packets sent by RS have been dropped at the 1498 beginning of the stream. If RS accepts the RAMS request, this 1499 element MUST exist. If RS rejects the RAMS request, this element 1500 SHALL NOT exist. 1502 Type: 32 1504 o Earliest Multicast Join Time (32 bits): TLV element that 1505 specifies the delta time (in ms) between the arrival of the first 1506 RTP packet in the RTP stream (which could be a burst packet or a 1507 payload-specific packet) and the earliest time instant when RTP_Rx 1508 SHOULD send an SFGMP Join message to join the multicast session. 1509 A zero value in this field means that RTP_Rx may send the SFGMP 1510 Join message right away. 1512 If the RAMS request has been accepted, RS MUST send this field at 1513 least once, so that RTP_Rx knows when to join the multicast 1514 session. If the burst request has been rejected as indicated in 1515 the Response field, this field MUST be set to zero. In that case, 1516 it is up to RTP_Rx when or whether to join the multicast session. 1518 It should be noted that when RS serves two or more bursts and 1519 sends a separate RAMS-I message for each burst, the join times 1520 specified in these RAMS-I messages should correspond to more or 1521 less the same time instant, and RTP_Rx sends the SFGMP Join 1522 message based on the earliest join time. 1524 Type: 33 1526 o Burst Duration (32 bits): Optional TLV element that denotes the 1527 duration of the burst, i.e., the delta difference between the 1528 first and the last burst packet, that RS is planning to send (in 1529 ms) in the respective RTP stream. In the absence of additional 1530 stimulus, RS will send a burst of this duration. However, the 1531 burst duration may be modified by subsequent events, including 1532 changes in the primary multicast stream and reception of RAMS-T 1533 messages. 1535 Note that RS MUST terminate the flow in a deterministic timeframe, 1536 even if it does not get a RAMS-T or a BYE from RTP_Rx. It is 1537 OPTIONAL to send this field in a RAMS-I message when the burst 1538 request is accepted. If the burst request has been rejected as 1539 indicated in the Response field, this field MAY be omitted or set 1540 to zero. 1542 Type: 34 1544 o Max Transmit Bitrate (64 bits): Optional TLV element that denotes 1545 the maximum bitrate (in bits per second) that will be used by RS 1546 for the RTP stream associated with this RAMS-I message. 1548 Type: 35 1550 The semantics of the RAMS-I feedback message is independent of the 1551 payload type. 1553 The initial RAMS-I message SHOULD precede the unicast burst or be 1554 sent at the start of the burst. Subsequent RAMS-I message(s) MAY be 1555 sent during the unicast burst and convey changes in any of the 1556 fields. 1558 7.4. RAMS Termination 1560 The RAMS Termination message is identified by SFMT=3. 1562 The RAMS Termination is used to assist RS in determining when to stop 1563 the burst. A separate RAMS-T message is sent by RTP_Rx for each 1564 primary multicast stream that has been served by RS. Each of these 1565 RAMS-T messages has the appropriate media sender SSRC populated in 1566 its message header. 1568 If RTP_Rx wants RS to stop a burst prematurely, it sends a plain 1569 RAMS-T message as described below. Upon receiving this message, RS 1570 stops the respective burst immediately. If RTP_Rx wants RS to 1571 terminate all of the bursts, it should send all of the respective 1572 RAMS-T messages in a single compound RTCP packet. 1574 The default behavior for RTP_Rx is to send a RAMS-T message right 1575 after it joined the multicast session and started receiving multicast 1576 packets. In that case, RTP_Rx includes the sequence number of the 1577 first RTP packet received in the primary multicast stream in the 1578 RAMS-T message. With this information, RS can decide when to 1579 terminate the unicast burst. 1581 The FCI field MUST contain only one RAMS Termination. The FCI field 1582 has the structure depicted in Figure 8. 1584 0 1 2 3 1585 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 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 | SFMT=3 | Reserved | 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 : Optional TLV-encoded Fields (and Padding, if needed) : 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 Figure 8: FCI field syntax for the RAMS Termination message 1594 o Extended RTP Seqnum of First Multicast Packet (32 bits): Optional 1595 TLV element that specifies the extended RTP sequence number of the 1596 first packet received from the SSM session for a particular 1597 primary multicast stream. The low 16 bits contain the sequence 1598 number of the first packet received from the SSM session, and the 1599 most significant 16 bits extend that sequence number with the 1600 corresponding count of sequence number cycles, which may be 1601 maintained according to the algorithm in Appendix A.1 of 1602 [RFC3550]. 1604 Type: 61 1606 The semantics of the RAMS-T feedback message is independent of the 1607 payload type. 1609 8. SDP Signaling 1611 8.1. Definitions 1613 The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585]. 1614 Here we add the following syntax to the 'rtcp-fb' attribute (the 1615 feedback type and optional parameters are all case sensitive): 1617 (In the following ABNF [RFC5234], fmt, SP and CRLF are used as 1618 defined in [RFC4566].) 1620 rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF 1622 rtcp-fb-pt = "*" ; wildcard: applies to all formats 1623 / fmt ; as defined in SDP spec 1625 rtcp-fb-val = "nack" SP "rai" 1627 The following parameter is defined in this document for use with 1628 'nack': 1630 o 'rai' stands for Rapid Acquisition Indication and indicates the 1631 use of RAMS messages as defined in Section 7. 1633 This document also defines a new media-level SDP attribute ('rams- 1634 updates') that indicates whether RS supports updated request messages 1635 or not. This attribute is used in a declarative manner. If RS 1636 supports updated request messages and this attribute is included in 1637 the SDP description, RTP_Rx may send updated requests. RS may or may 1638 not be able to accept value changes in every field in an updated 1639 RAMS-R message. However, if the 'rams-updates' attribute is not 1640 included in the SDP description, RTP_Rx SHALL NOT send updated 1641 requests (RTP_Rx MAY still repeat its initial request without 1642 changes, though). 1644 8.2. Requirements 1646 The use of SDP to describe the RAMS entities normatively requires the 1647 support for: 1649 o The SDP grouping framework and flow identification (FID) semantics 1650 [I-D.ietf-mmusic-rfc3388bis] 1652 o The RTP/AVPF profile [RFC4585] 1654 o The RTP retransmission payload format [RFC4588] 1656 o The RTCP extensions for SSM sessions with unicast feedback 1657 [RFC5760] 1659 The support for the source-specific media attributes [RFC5576] may be 1660 required in some deployments as described below. 1662 8.3. Example and Discussion 1664 This section provides a declarative SDP [RFC4566] example for 1665 enabling rapid acquisition of multicast RTP sessions. 1667 v=0 1668 o=ali 1122334455 1122334466 IN IP4 rams.example.com 1669 s=Rapid Acquisition Example 1670 t=0 0 1671 a=group:FID 1 2 1672 a=rtcp-unicast:rsi 1673 m=video 41000 RTP/AVPF 98 1674 i=Primary Multicast Stream 1675 c=IN IP4 233.252.0.2/255 1676 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 1677 a=rtpmap:98 MP2T/90000 1678 a=rtcp:41001 IN IP4 192.0.2.1 1679 a=rtcp-fb:98 nack 1680 a=rtcp-fb:98 nack rai 1681 a=ssrc:123321 cname:iptv-ch32@rams.example.com 1682 a=rams-updates 1683 a=mid:1 1684 m=video 41002 RTP/AVPF 99 1685 i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support) 1686 c=IN IP4 192.0.2.1 1687 a=sendonly 1688 a=rtpmap:99 rtx/90000 1689 a=rtcp:41003 1690 a=fmtp:99 apt=98; rtx-time=5000 1691 a=mid:2 1693 Figure 9: Example SDP for a single-channel RAMS scenario 1695 In this example SDP description, we have a primary multicast (source) 1696 stream and a unicast retransmission stream. The source stream is 1697 multicast from a distribution source (with a source IP address of 1698 198.51.100.1) to the multicast destination address of 233.252.0.2 and 1699 port 41000. Here, we are assuming that the multicast RTP and RTCP 1700 ports are carefully chosen so that different RTP and RTCP streams do 1701 not collide with each other. 1703 The feedback target (FT_Ap) residing on the retransmission server 1704 (with an address of 192.0.2.1) at port 41001 is declared with the 1705 "a=rtcp" line [RFC3605]. The RTP receiver(s) can report missing 1706 packets on the source stream to the feedback target and request 1707 retransmissions. In the RAMS context, the parameter 'rtx-time' 1708 specifies the time in milliseconds that the retransmission server 1709 keeps an RTP packet in its cache available for retransmission 1710 (measured from the time the packet was received by the retransmission 1711 server, not from the time indicated in the packet timestamp). 1713 In the example shown in Figure 9, support for both the conventional 1714 retransmission (through the "a=rtcp-fb:98 nack" line) and rapid 1715 acquisition (through the "a=rtcp-fb:98 nack rai" line) is enabled. 1716 Note that this SDP includes the "a=sendonly" line for the media 1717 description of the retransmission stream. 1719 Once an RTP receiver has acquired an SDP description, it may ask for 1720 rapid acquisition before it joins a primary multicast RTP session. 1721 To do so, it sends a RAMS-R message to the feedback target of that 1722 primary multicast RTP session. If FT_Ap is associated with only one 1723 RTP stream, the RTP receiver does not need to learn the SSRC of that 1724 stream via an out-of-band method. If RS accepts the rapid 1725 acquisition request, it will send an RAMS-I message with the correct 1726 SSRC identifier. If FT_Ap is associated with a multi-stream RTP 1727 session and the RTP receiver is willing to request rapid acquisition 1728 for the entire session, the RTP receiver again does not need to learn 1729 the SSRCs via an out-of-band method. However, if the RTP receiver 1730 intends to request a particular subset of the primary multicast 1731 streams, it must learn their SSRC identifiers and list them in the 1732 RAMS-R message. Since this RTP receiver has not yet received any RTP 1733 packets for the primary multicast stream(s), the RTP receiver must in 1734 this case learn the SSRC value(s) from the 'ssrc' attribute of the 1735 media description [RFC5576]. In addition to the SSRC value, the 1736 'cname' source attribute must also be present in the SDP description 1737 [RFC5576]. 1739 Note that listing the SSRC values for the primary multicast streams 1740 in the SDP file does not create a problem in SSM sessions when an 1741 SSRC collision occurs. This is because in SSM sessions, an RTP 1742 receiver that observed an SSRC collision with a media sender MUST 1743 change its own SSRC [RFC5760] by following the rules defined in 1744 [RFC3550]. 1746 A feedback target that receives a RAMS-R feedback message becomes 1747 aware that the prediction chain at the RTP receiver side has been 1748 broken or does not exist anymore. If the necessary conditions are 1749 satisfied (as outlined in Section 7 of [RFC4585]) and available 1750 resources exist, RS may react to the RAMS-R message by sending any 1751 transport-layer (and optional payload-specific, when allowed) 1752 feedback message(s) and starting the unicast burst. 1754 In this section, we considered the simplest scenario where the 1755 primary multicast RTP session carried only one stream and the RTP 1756 receiver wanted to rapidly acquire this stream only. Best practices 1757 for scenarios where the primary multicast RTP session carries two or 1758 more streams or the RTP receiver wants to acquire one or more streams 1759 from multiple primary multicast RTP sessions at the same time are 1760 presented in [I-D.begen-avt-rams-scenarios]. 1762 9. NAT Considerations 1764 For a variety of reasons, one or more NAPT devices (hereafter simply 1765 called NAT) may exist between RTP_Rx and RS. NATs have a variety of 1766 operating characteristics for UDP traffic [RFC4787]. For a NAT to 1767 permit traffic from RS to arrive at RTP_Rx, the NAT(s) must first 1768 either: 1770 a. See UDP traffic sent from RTP_Rx (which is on the 'inside' of the 1771 NAT) to RS (which is on the 'outside' of the NAT). This traffic 1772 is sent to the same transport address as the subsequent response 1773 traffic, or; 1775 b. Be configured to forward certain ports (e.g., using HTML 1776 configuration, UPnP IGD [UPnP-IGD], DLNA [DLNA]). Details of 1777 this are out of scope of this document. 1779 For both (a) and (b), RTP_Rx is responsible for maintaining the NAT's 1780 state if it wants to receive traffic from the RS on that port. For 1781 (a), RTP_Rx MUST send UDP traffic to keep the NAT binding alive, at 1782 least every 30 seconds [RFC4787]. Note that while (a) is more like 1783 an automatic/dynamic configuration, (b) is more like a manual/static 1784 configuration. 1786 When RTP_Rx sends a RAMS-R message in the primary multicast RTP 1787 session and the request is received by RS, a new unicast RTP 1788 retransmission session will be established between RS and RTP_Rx. 1790 While the ports on the RS side are already signaled via out-of-band 1791 means (e.g., SDP), RTP_Rx may need to convey to RS the RTP and RTCP 1792 ports it wants to use on its side for the new session. Since there 1793 are two RTP sessions involved during this process and one of them is 1794 established upon a feedback message sent in the other one, this 1795 requires an explicit port mapping method. This problem equally 1796 applies to scenarios where the RTP media is multicast in an SSM 1797 session, and an RTP receiver requests retransmission from a local 1798 repair server by using the RTCP NACK messages for the missing packets 1799 and the repair server retransmits the requested packets over a 1800 unicast session. Thus, instead of laying out a specific solution for 1801 the RAMS applications, a general solution is introduced in 1802 [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. 1804 Applications using RAMS MUST support this solution both on the RS and 1805 RTP_Rx side to allow RTP receivers to use their desired ports and to 1806 support RAMS behind NAT devices. 1808 10. Security Considerations 1810 Applications that are using RAMS make heavy use of the unicast 1811 feedback mechanism described in [RFC5760] and the payload format 1812 defined in [RFC4588]. Thus, these applications are subject to the 1813 general security considerations discussed in [RFC5760] and [RFC4588]. 1814 In this section, we give an overview of the guidelines and 1815 suggestions described in these specifications from a RAMS 1816 perspective. We also discuss the security considerations that 1817 explicitly apply to applications using RAMS. 1819 First of all, much of the session description information is 1820 available in the SDP descriptions that are distributed to the media 1821 senders, retransmission servers and RTP receivers. Adequate security 1822 measures are RECOMMENDED to ensure the integrity and authenticity of 1823 the SDP descriptions so that transport addresses of the media 1824 senders, distribution sources, feedback targets as well as other 1825 session-specific information can be authenticated. 1827 Compared to an RTCP NACK message that triggers one or more 1828 retransmissions, a RAMS Request (RAMS-R) message may trigger a new 1829 burst stream to be sent by the retransmission server. Depending on 1830 the application-specific requirements and conditions existing at the 1831 time of the RAMS-R reception by the retransmission server, the 1832 resulting burst stream may contain potentially a large number of 1833 retransmission packets. Since these packets are sent at a faster 1834 than the nominal rate, RAMS consumes more resources on the 1835 retransmission server, the RTP receiver and the network. This may 1836 particularly make denial-of-service attacks more intense, and hence, 1837 more harmful than attacks that target ordinary retransmission 1838 sessions. 1840 Following the suggestions given in [RFC4588], counter-measures SHOULD 1841 be taken to prevent tampered or spoofed RTCP packets. Tampered 1842 RAMS-R messages may trigger inappropriate burst streams or alter the 1843 existing burst streams in an inappropriate way. For example, if the 1844 Max Receive Bitrate field is altered by a tampered RAMS-R message, 1845 the updated burst may overflow the buffer at the receiver side, or 1846 oppositely, may slow down the burst to the point that it becomes 1847 useless. Tampered RAMS Termination (RAMS-T) messages may terminate 1848 valid burst streams prematurely resulting in gaps in the received RTP 1849 packets. RAMS Information (RAMS-I) messages contain fields that are 1850 critical for a successful rapid acquisition. Any tampered 1851 information in the RAMS-I message may easily cause the RTP receiver 1852 to make wrong decisions. Consequently, the RAMS operation may fail. 1854 While most of the denial-of-service attacks can be prevented by the 1855 integrity and authenticity checks enabled by Secure RTP (SRTP) 1857 [RFC3711], an attack can still be started by legitimate endpoints 1858 that send several valid RAMS-R messages to a particular feedback 1859 target in a synchronized fashion and very short amount of time. 1860 Since a RAMS operation may temporarily consume a large amount of 1861 resources, a series of the RAMS-R messages may temporarily overload 1862 the retransmission server. In these circumstances, the 1863 retransmission server may, for example, reject incoming RAMS requests 1864 until its resources become available again. One means to ameliorate 1865 this threat is to apply a per-endpoint policing mechanism on the 1866 incoming RAMS requests. A reasonable policing mechanism should 1867 consider application-specific requirements and minimize false 1868 negatives. 1870 In addition to the denial-of-service attacks, man-in-the-middle and 1871 replay attacks can also be harmful. However, RAMS itself does not 1872 bring any new risks or threats other than the ones discussed in 1873 [RFC5760]. 1875 [RFC4588] RECOMMENDS that the cryptography mechanisms are used for 1876 the retransmission payload format to provide protection against known 1877 plain-text attacks. As discussed in [RFC4588], the retransmission 1878 payload format sets the timestamp field in the RTP header to the 1879 media timestamp of the original packet and this does not compromise 1880 the confidentiality. Furthermore, if cryptography is used to provide 1881 security services on the original stream, then the same services, 1882 with equivalent cryptographic strength, MUST be provided on the 1883 retransmission stream per [RFC4588]. 1885 To protect the RTCP messages from man-in-the-middle and replay 1886 attacks, the RTP receivers and retransmission server SHOULD perform a 1887 DTLS-SRTP handshake [I-D.ietf-avt-dtls-srtp] over the RTCP channel. 1888 Because there is no integrity-protected signaling channel between an 1889 RTP receiver and the retransmission server, the retransmission server 1890 MUST maintain a list of certificates owned by legitimate RTP 1891 receivers, or their certificates MUST be signed by a trusted 1892 Certificate Authority. Once the DTLS-SRTP security is established, 1893 non-SRTCP-protected messages received from a particular RTP receiver 1894 are ignored by the retransmission server. To reduce the impact of 1895 DTLS-SRTP overhead when communicating with different feedback targets 1896 on the same retransmission server, it is RECOMMENDED that RTP 1897 receivers and the retransmission server both support TLS Session 1898 Resumption without Server-side State [RFC5077]. 1900 11. IANA Considerations 1902 The following contact information shall be used for all registrations 1903 in this document: 1905 Ali Begen 1906 abegen@cisco.com 1908 170 West Tasman Drive 1909 San Jose, CA 95134 USA 1911 Note to the RFC Editor: In the following, please replace "XXXX" with 1912 the number of this document prior to publication as an RFC. 1914 11.1. Registration of SDP Attributes 1916 This document registers a new attribute name in SDP. 1918 SDP Attribute ("att-field"): 1919 Attribute name: rams-updates 1920 Long form: Support for Updated RAMS Request Messages 1921 Type of name: att-field 1922 Type of attribute: Media level 1923 Subject to charset: No 1924 Purpose: See this document 1925 Reference: [RFCXXXX] 1926 Values: None 1928 11.2. Registration of SDP Attribute Values 1930 This document registers a new value for the 'nack' attribute to be 1931 used with the 'rtcp-fb' attribute in SDP. For more information about 1932 the 'rtcp-fb' attribute, refer to Sections 4.2 and 6.2 of [RFC4585]. 1934 Value name: rai 1935 Long name: Rapid Acquisition Indication 1936 Usable with: nack 1937 Reference: [RFCXXXX] 1939 11.3. Registration of FMT Values 1941 Within the RTPFB range, the following format (FMT) value is 1942 registered: 1944 Name: RAMS 1945 Long name: Rapid Acquisition of Multicast Sessions 1946 Value: 6 1947 Reference: [RFCXXXX] 1949 11.4. SFMT Values for RAMS Messages Registry 1951 This document creates a new sub-registry for the sub-feedback message 1952 type (SFMT) values to be used with the FMT value registered for RAMS 1953 messages. The registry is called the SFMT Values for RAMS Messages 1954 Registry. This registry is to be managed by the IANA according to 1955 the Specification Required policy of [RFC5226]. 1957 The length of the SFMT field in the RAMS messages is a single octet, 1958 allowing 256 values. The registry is initialized with the following 1959 entries: 1961 Value Name Reference 1962 ----- -------------------------------------------------- ------------- 1963 0 Reserved [RFCXXXX] 1964 1 RAMS Request [RFCXXXX] 1965 2 RAMS Information [RFCXXXX] 1966 3 RAMS Termination [RFCXXXX] 1967 4-254 Assignable - Specification Required 1968 255 Reserved [RFCXXXX] 1970 The SFMT values 0 and 255 are reserved for future use. 1972 Any registration for an unassigned SFMT value MUST contain the 1973 following information: 1975 o Contact information of the one doing the registration, including 1976 at least name, address, and email. 1978 o A detailed description of what the new SFMT represents and how it 1979 shall be interpreted. 1981 Note that new RAMS functionality should be introduced by using the 1982 extension mechanism within the existing RAMS message types not by 1983 introducing new message types unless it is absolutely necessary. 1985 11.5. RAMS TLV Space Registry 1987 This document creates a new IANA TLV space registry for the RAMS 1988 extensions. The registry is called the RAMS TLV Space Registry. 1989 This registry is to be managed by the IANA according to the 1990 Specification Required policy of [RFC5226]. 1992 The length of the Type field in the TLV elements is a single octet, 1993 allowing 256 values. The Type values 0 and 255 are reserved for 1994 future use. The Type values between (and including) 128 and 254 are 1995 reserved for private extensions. 1997 The registry is initialized with the following entries: 1999 Type Description Reference 2000 ---- -------------------------------------------------- ------------- 2001 0 Reserved [RFCXXXX] 2002 1 Requested Media Sender SSRC(s) [RFCXXXX] 2003 2 Min RAMS Buffer Fill Requirement [RFCXXXX] 2004 3 Max RAMS Buffer Fill Requirement [RFCXXXX] 2005 4 Max Receive Bitrate [RFCXXXX] 2006 5 Request for Preamble Only [RFCXXXX] 2007 6-30 Assignable - Specification Required 2008 31 Media Sender SSRC [RFCXXXX] 2009 32 RTP Seqnum of the First Packet [RFCXXXX] 2010 33 Earliest Multicast Join Time [RFCXXXX] 2011 34 Burst Duration [RFCXXXX] 2012 35 Max Transmit Bitrate [RFCXXXX] 2013 36-60 Assignable - Specification Required 2014 61 Extended RTP Seqnum of First Multicast Packet [RFCXXXX] 2015 62-127 Assignable - Specification Required 2016 128-254 No IANA Maintenance 2017 255 Reserved [RFCXXXX] 2019 Any registration for an unassigned Type value MUST contain the 2020 following information: 2022 o Contact information of the one doing the registration, including 2023 at least name, address, and email. 2025 o A detailed description of what the new TLV element represents and 2026 how it shall be interpreted. 2028 11.6. RAMS Response Code Space Registry 2030 This document creates a new IANA TLV space registry for the RAMS 2031 response codes. The registry is called the RAMS Response Code Space 2032 Registry. This registry is to be managed by the IANA according to 2033 the Specification Required policy of [RFC5226]. 2035 The length of the Response field is two octets, allowing 65536 codes. 2037 However, the response codes have been classified and registered 2038 following an HTTP-style code numbering in this document. New 2039 response codes SHALL follow the guidelines below: 2041 Code Level Purpose 2042 ---------- --------------- 2043 1xx Informational 2044 2xx Success 2045 3xx Redirection 2046 4xx RTP Receiver Error 2047 5xx Retransmission Server Error 2049 The Response code 65536 is reserved for future use. 2051 The registry is initialized with the following entries: 2053 Code Description Reference 2054 ----- -------------------------------------------------- ------------- 2055 0 A private response code is included in the message [RFCXXXX] 2057 100 Parameter update for RAMS session [RFCXXXX] 2059 200 RAMS request has been accepted [RFCXXXX] 2060 201 Unicast burst has been completed [RFCXXXX] 2062 400 Invalid RAMS-R message syntax 2063 401 Invalid min buffer requirement in RAMS-R message [RFCXXXX] 2064 402 Invalid max buffer requirement in RAMS-R message [RFCXXXX] 2065 403 Invalid max bitrate requirement in RAMS-R message [RFCXXXX] 2067 500 An unspecified RS internal error has occurred [RFCXXXX] 2068 501 RS has no bandwidth to start RAMS session [RFCXXXX] 2069 502 Burst is terminated due to network congestion [RFCXXXX] 2070 503 RS has no CPU available to start RAMS session [RFCXXXX] 2071 504 RAMS functionality is not available on RS [RFCXXXX] 2072 505 RAMS functionality is not available for RTP_Rx [RFCXXXX] 2073 506 RAMS functionality is not available for 2074 the requested multicast stream [RFCXXXX] 2075 507 RS has no valid starting point available for 2076 the requested multicast stream [RFCXXXX] 2077 508 RS has no reference information available for 2078 the requested multicast stream [RFCXXXX] 2079 509 RS has no RTP stream matching the requested SSRC [RFCXXXX] 2080 510 RAMS request to acquire the entire session 2081 has been denied [RFCXXXX] 2082 511 Only the preamble information is sent [RFCXXXX] 2083 512 RAMS request has been denied due to a policy [RFCXXXX] 2085 Any registration for an unassigned Response code MUST contain the 2086 following information: 2088 o Contact information of the one doing the registration, including 2089 at least name, address, and email. 2091 o A detailed description of what the new Response code describes and 2092 how it shall be interpreted. 2094 12. Contributors 2096 Dave Oran and Magnus Westerlund have contributed significantly to 2097 this specification by providing text and solutions to some of the 2098 issues raised during the development of this specification. 2100 13. Acknowledgments 2102 The following individuals have reviewed the earlier versions of this 2103 specification and provided helpful comments: Colin Perkins, Joerg 2104 Ott, Roni Even, Dan Wing, Tony Faustini, Peilin Yang, Jeff Goldberg, 2105 Muriel Deschanel, Orit Levin, Guy Hirson, Tom Taylor, Xavier Marjou, 2106 Ye-Kui Wang, Zixuan Zou, Ingemar Johansson, Haibin Song, Ning Zong, 2107 Jonathan Lennox, Jose Rey and Sean Sheedy. 2109 14. Change Log 2111 14.1. draft-ietf-avt-rapid-acquisition-for-rtp-08 2113 The following are the major changes compared to version 07: 2115 o Fixes and changes requested by Magnus W. and Jose R. have been 2116 addressed throuhout the document. 2118 o Some references have been updated. 2120 14.2. draft-ietf-avt-rapid-acquisition-for-rtp-07 2122 The following are the major changes compared to version 06: 2124 o Congestion control considerations text has been added to Section 2125 6.4. 2127 14.3. draft-ietf-avt-rapid-acquisition-for-rtp-06 2129 The following are the major changes compared to version 05: 2131 o Comments from WGLC have been addressed. See the mailing list for 2132 the list of changes. 2134 o Support for multi-stream RTP sessions has been added. 2136 o NAT section has been revised. 2138 14.4. draft-ietf-avt-rapid-acquisition-for-rtp-05 2140 The following are the major changes compared to version 04: 2142 o Editorial changes throughout the document. 2144 14.5. draft-ietf-avt-rapid-acquisition-for-rtp-04 2146 The following are the major changes compared to version 03: 2148 o Clarifications for the definition of RS. 2150 o Response codes have been defined. 2152 14.6. draft-ietf-avt-rapid-acquisition-for-rtp-03 2154 The following are the major changes compared to version 02: 2156 o Clarifications for the RAMS-I message. 2158 o Type values have been assigned. 2160 14.7. draft-ietf-avt-rapid-acquisition-for-rtp-02 2162 The following are the major changes compared to version 01: 2164 o Port mapping discussion has been removed since it will be 2165 discussed in a separate draft. 2167 o Security considerations section has been added. 2169 o Burst shaping section has been completed. 2171 o Most of the outstanding open issues have been addressed. 2173 14.8. draft-ietf-avt-rapid-acquisition-for-rtp-01 2175 The following are the major changes compared to version 00: 2177 o Formal definitions of vendor-neutral and private extensions and 2178 their IANA registries have been added. 2180 o SDP examples were explained in more detail. 2182 o The sub-FMT field has been introduced in the RAMS messages for 2183 message type identification. 2185 o Some terminology has been fixed. 2187 o NAT considerations section has been added. 2189 14.9. draft-ietf-avt-rapid-acquisition-for-rtp-00 2191 This is a resubmission of version 03 as a WG item. 2193 14.10. draft-versteeg-avt-rapid-synchronization-for-rtp-03 2195 The following are the major changes compared to version 02: 2197 o The title and message names have been changed. 2199 o RTCP message semantics have been added. RAMS protocol has been 2200 revised to handle updated requests and responses. 2202 o Definitions have been revised. 2204 o RTP/RTCP muxing reference has been added. 2206 14.11. draft-versteeg-avt-rapid-synchronization-for-rtp-02 2208 The following are the major changes compared to version 01: 2210 o The discussion around MPEG2-TS has been moved to another document. 2212 o The RAMS-R, RAMS-I and RAMS-T messages have been extensively 2213 modified and they have been made mandatory. 2215 o IANA Considerations section has been updated. 2217 o The discussion of RTCP XR report has been moved to another 2218 document. 2220 o A new section on protocol design considerations has been added. 2222 14.12. draft-versteeg-avt-rapid-synchronization-for-rtp-01 2224 The following are the major changes compared to version 00: 2226 o The core of the rapid synchronization method is now payload- 2227 independent. But, the draft still defines payload-specific 2228 messages that are required for enabling rapid synch for the RTP 2229 flows carrying MPEG2-TS. 2231 o RTCP APP packets have been removed, new RTCP transport-layer and 2232 payload-specific feedback messages have been defined. 2234 o The step for leaving the current multicast session has been 2235 removed from Section 6.2. 2237 o A new RTCP XR (Multicast Join) report has been defined. 2239 o IANA Considerations section have been updated. 2241 o Editorial changes to clarify several points. 2243 15. References 2245 15.1. Normative References 2247 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2248 Jacobson, "RTP: A Transport Protocol for Real-Time 2249 Applications", STD 64, RFC 3550, July 2003. 2251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2252 Requirement Levels", BCP 14, RFC 2119, March 1997. 2254 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2255 Thyagarajan, "Internet Group Management Protocol, Version 2256 3", RFC 3376, October 2002. 2258 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 2259 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 2261 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 2262 Group Management Protocol Version 3 (IGMPv3) and Multicast 2263 Listener Discovery Protocol Version 2 (MLDv2) for Source- 2264 Specific Multicast", RFC 4604, August 2006. 2266 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2267 Description Protocol", RFC 4566, July 2006. 2269 [I-D.ietf-mmusic-rfc3388bis] 2270 Camarillo, G. and H. Schulzrinne, "The SDP (Session 2271 Description Protocol) Grouping Framework", 2272 draft-ietf-mmusic-rfc3388bis-04 (work in progress), 2273 November 2009. 2275 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2276 "Extended RTP Profile for Real-time Transport Control 2277 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2278 July 2006. 2280 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 2281 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 2282 July 2006. 2284 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 2285 Protocol (RTCP) Extensions for Single-Source Multicast 2286 Sessions with Unicast Feedback", RFC 5760, February 2010. 2288 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 2289 Media Attributes in the Session Description Protocol 2290 (SDP)", RFC 5576, June 2009. 2292 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 2293 in Session Description Protocol (SDP)", RFC 3605, 2294 October 2003. 2296 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2297 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2299 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 2300 Real-Time Transport Control Protocol (RTCP): Opportunities 2301 and Consequences", RFC 5506, April 2009. 2303 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 2304 Header Extensions", RFC 5285, July 2008. 2306 [I-D.ietf-avt-rapid-rtp-sync] 2307 Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 2308 Flows", draft-ietf-avt-rapid-rtp-sync-09 (work in 2309 progress), January 2010. 2311 [I-D.ietf-avt-ports-for-ucast-mcast-rtp] 2312 Begen, A. and B. Steeg, "Port Mapping Between Unicast and 2313 Multicast RTP Sessions", 2314 draft-ietf-avt-ports-for-ucast-mcast-rtp-00 (work in 2315 progress), February 2010. 2317 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2318 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2319 RFC 3711, March 2004. 2321 [I-D.ietf-avt-dtls-srtp] 2322 McGrew, D. and E. Rescorla, "Datagram Transport Layer 2323 Security (DTLS) Extension to Establish Keys for Secure 2324 Real-time Transport Protocol (SRTP)", 2325 draft-ietf-avt-dtls-srtp-07 (work in progress), 2326 February 2009. 2328 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 2329 "Transport Layer Security (TLS) Session Resumption without 2330 Server-Side State", RFC 5077, January 2008. 2332 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2333 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2334 May 2008. 2336 15.2. Informative References 2338 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2339 August 1980. 2341 [I-D.begen-avt-rams-scenarios] 2342 Begen, A., "Considerations for RAMS Scenarios", 2343 draft-begen-avt-rams-scenarios-00 (work in progress), 2344 October 2009. 2346 [I-D.begen-avt-rtp-mpeg2ts-preamble] 2347 Begen, A. and E. Friedrich, "RTP Payload Format for 2348 MPEG2-TS Preamble", 2349 draft-begen-avt-rtp-mpeg2ts-preamble-04 (work in 2350 progress), December 2009. 2352 [I-D.ietf-avt-multicast-acq-rtcp-xr] 2353 Begen, A. and E. Friedrich, "Multicast Acquisition Report 2354 Block Type for RTP Control Protocol (RTCP) Extended 2355 Reports (XRs)", draft-ietf-avt-multicast-acq-rtcp-xr-00 2356 (work in progress), February 2010. 2358 [I-D.ietf-avt-ecn-for-rtp] 2359 Westerlund, M., Johansson, I., Perkins, C., and K. 2360 Carlberg, "Explicit Congestion Notification (ECN) for RTP 2361 over UDP", draft-ietf-avt-ecn-for-rtp-00 (work in 2362 progress), February 2010. 2364 [I-D.ietf-fecframe-interleaved-fec-scheme] 2365 Begen, A., "RTP Payload Format for 1-D Interleaved Parity 2366 FEC", draft-ietf-fecframe-interleaved-fec-scheme-09 (work 2367 in progress), January 2010. 2369 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 2370 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 2371 RFC 4787, January 2007. 2373 [I-D.ietf-dccp-rtp] 2374 Perkins, C., "RTP and the Datagram Congestion Control 2375 Protocol (DCCP)", draft-ietf-dccp-rtp-07 (work in 2376 progress), June 2007. 2378 [UPnP-IGD] 2379 Forum, UPnP., "Universal Plug and Play (UPnP) Internet 2380 Gateway Device (IGD)", November 2001. 2382 [DLNA] , DLNA., "http://www.dlna.org/home". 2384 [IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing 2385 Channel Change Times in IPTV with Real-Time Transport 2386 Protocol (IEEE Internet Computing)", May 2009. 2388 Authors' Addresses 2390 Bill VerSteeg 2391 Cisco 2392 5030 Sugarloaf Parkway 2393 Lawrenceville, GA 30044 2394 USA 2396 Email: billvs@cisco.com 2398 Ali Begen 2399 Cisco 2400 170 West Tasman Drive 2401 San Jose, CA 95134 2402 USA 2404 Email: abegen@cisco.com 2406 Tom VanCaenegem 2407 Alcatel-Lucent 2408 Copernicuslaan 50 2409 Antwerpen, 2018 2410 Belgium 2412 Email: Tom.Van_Caenegem@alcatel-lucent.be 2414 Zeev Vax 2415 Microsoft Corporation 2416 1065 La Avenida 2417 Mountain View, CA 94043 2418 USA 2420 Email: zeevvax@microsoft.com