idnits 2.17.1 draft-ietf-avt-rapid-acquisition-for-rtp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 == 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 (October 8, 2009) is 5313 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 1814, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-04) exists of draft-ietf-mmusic-rfc3388bis-03 == Outdated reference: A later version (-19) exists of draft-ietf-avt-rtcpssm-18 == Outdated reference: A later version (-02) exists of draft-begen-avt-ports-for-ucast-mcast-rtp-00 ** 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-02 == Outdated reference: A later version (-03) exists of draft-begen-avt-rapid-sync-rtcp-xr-02 == Outdated reference: A later version (-13) exists of draft-ietf-avt-rapid-rtp-sync-05 == Outdated reference: A later version (-02) exists of draft-westerlund-avt-ecn-for-rtp-01 -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT B. VerSteeg 3 Internet-Draft A. Begen 4 Intended status: Standards Track Cisco Systems 5 Expires: April 11, 2010 T. VanCaenegem 6 Alcatel-Lucent 7 Z. Vax 8 Microsoft Corporation 9 October 8, 2009 11 Unicast-Based Rapid Acquisition of Multicast RTP Sessions 12 draft-ietf-avt-rapid-acquisition-for-rtp-04 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on April 11, 2010. 47 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 When an RTP receiver joins a primary multicast session, it may need 60 to acquire and parse certain Reference Information before it can 61 process any data sent in the multicast session. Depending on the 62 join time, length of the Reference Information repetition interval, 63 size of the Reference Information as well as the application and 64 transport properties, the time lag before an RTP receiver can 65 usefully consume the multicast data, which we refer to as the 66 Acquisition Delay, varies and may be large. This is an undesirable 67 phenomenon for receivers that frequently switch among different 68 multicast sessions, such as video broadcasts. 70 In this document, we describe a method using the existing RTP and 71 RTCP protocol machinery that reduces the acquisition delay. In this 72 method, an auxiliary unicast RTP session carrying the Reference 73 Information to the receiver precedes/accompanies the primary 74 multicast stream. This unicast RTP flow may be transmitted at a 75 faster than natural rate to further accelerate the acquisition. The 76 motivating use case for this capability is multicast applications 77 that carry real-time compressed audio and video. However, the 78 proposed method can also be used in other types of multicast 79 applications where the acquisition delay is long enough to be a 80 problem. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 85 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7 86 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 4. Elements of Delay in Multicast Applications . . . . . . . . . 8 88 5. Protocol Design Considerations and Their Effect on 89 Resource Management for Rapid Acquisition . . . . . . . . . . 10 90 6. Rapid Acquisition of Multicast RTP Sessions . . . . . . . . . 12 91 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13 93 6.3. Shaping the Unicast Burst . . . . . . . . . . . . . . . . 21 94 6.4. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 23 95 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 24 96 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 24 97 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 25 98 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 25 99 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 26 100 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 28 101 7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 30 102 8. SDP Definitions and Examples . . . . . . . . . . . . . . . . . 31 103 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 31 104 8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 31 105 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 34 106 10. Known Implementations . . . . . . . . . . . . . . . . . . . . 35 107 10.1. Open Source RTP Receiver Implementation by Cisco . . . . . 35 108 10.2. IPTV Commercial Implementation by Microsoft . . . . . . . 36 109 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 36 110 12. Security Considerations . . . . . . . . . . . . . . . . . . . 36 111 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 112 13.1. Registration of SDP Attributes . . . . . . . . . . . . . . 38 113 13.2. Registration of SDP Attribute Values . . . . . . . . . . . 38 114 13.3. Registration of FMT Values . . . . . . . . . . . . . . . . 39 115 13.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 39 116 13.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 40 117 13.6. RAMS Response Code Space Registry . . . . . . . . . . . . 40 118 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 119 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 42 120 15.1. draft-ietf-avt-rapid-acquisition-for-rtp-04 . . . . . . . 42 121 15.2. draft-ietf-avt-rapid-acquisition-for-rtp-03 . . . . . . . 42 122 15.3. draft-ietf-avt-rapid-acquisition-for-rtp-02 . . . . . . . 42 123 15.4. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 43 124 15.5. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 43 125 15.6. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 43 126 15.7. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 43 127 15.8. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 44 128 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 129 16.1. Normative References . . . . . . . . . . . . . . . . . . . 44 130 16.2. Informative References . . . . . . . . . . . . . . . . . . 46 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 133 1. Introduction 135 Most multicast flows carry a stream of inter-related data. Certain 136 information must first be acquired by the receivers to start 137 processing any data sent in the multicast session. This document 138 refers to this information as Reference Information. The Reference 139 Information is conventionally sent periodically in the multicast 140 session and usually consists of items such as a description of the 141 schema for the rest of the data, references to which data to process, 142 encryption information including keys, as well as any other 143 information required to process the data in the primary multicast 144 stream. 146 Real-time multicast applications require the receivers to buffer 147 data. The receiver may have to buffer data to smooth out the network 148 jitter, to allow loss-repair methods such as Forward Error Correction 149 and retransmission to recover the missing packets, and to satisfy the 150 data processing requirements of the application layer. 152 When a receiver joins a multicast session, it has no control over 153 what point in the flow is currently being transmitted. Sometimes the 154 receiver may join the session right before the Reference Information 155 is sent in the session. In this case, the required waiting time is 156 usually minimal. Other times, the receiver may join the session 157 right after the Reference Information has been transmitted. In this 158 case, the receiver has to wait for the Reference Information to 159 appear again in the flow before it can start processing any multicast 160 data. In some other cases, the Reference Information is not 161 contiguous in the flow but dispersed over a large period, which 162 forces the receiver to wait for all of the Reference Information to 163 arrive before starting to process the rest of the data. 165 The net effect of waiting for the Reference Information and waiting 166 for various buffers to fill up is that the receivers may experience 167 significantly large delays in data processing. In this document, we 168 refer to the difference between the time an RTP receiver joins the 169 multicast session and the time the RTP receiver acquires all the 170 necessary Reference Information as the Acquisition Delay. The 171 acquisition delay may not be the same for different receivers; it 172 usually varies depending on the join time, length of the Reference 173 Information repetition interval, size of the Reference Information as 174 well as the application and transport properties. 176 The varying nature of the acquisition delay adversely affects the 177 receivers that frequently switch among multicast sessions. In this 178 specification, we address this problem for RTP-based multicast 179 applications and describe a method that uses the fundamental tools 180 offered by the existing RTP and RTCP protocols [RFC3550]. In this 181 method, either the multicast source (or the distribution source in a 182 single-source multicast (SSM) session) retains the Reference 183 Information for a period after its transmission, or an intermediary 184 network element (that we refer to as Retransmission Server) joins the 185 multicast session and continuously caches the Reference Information 186 as it is sent in the session and acts as a feedback target (See 187 [I-D.ietf-avt-rtcpssm]) for the session. When an RTP receiver wishes 188 to join the same multicast session, instead of simply issuing a 189 Source Filtering Group Management Protocol (SFGMP) Join message, it 190 sends a request to the feedback target for the session asking for the 191 Reference Information. The Retransmission Server starts a unicast 192 retransmission RTP session and sends the Reference Information to the 193 RTP receiver over that session. If there is spare bandwidth, the 194 Retransmission Server may also burst the Reference Information at a 195 faster than its natural rate. As soon as the receiver acquires the 196 Reference Information, it can join the multicast session and start 197 processing the multicast data. This method potentially reduces the 198 acquisition delay. We refer to this method as Unicast-based Rapid 199 Acquisition of Multicast RTP Sessions. A simplified network diagram 200 showing this method through an intermediary network element is 201 depicted in Figure 1. 203 +-----------------------+ 204 +--->| Intermediary | 205 | ...| Network Element | 206 | : |(Retransmission Server)| 207 | : +-----------------------+ 208 | : 209 | v 210 +-----------+ +----------+ +----------+ 211 | Multicast | | Router |---------->| Joining | 212 | Source |------->| |..........>| RTP | 213 +-----------+ +----------+ | Receiver | 214 | +----------+ 215 | 216 | +----------+ 217 +---------------->| Existing | 218 | RTP | 219 | Receiver | 220 +----------+ 222 ...> Unicast RTP Flow 223 ---> Multicast RTP Flow 225 Figure 1: Rapid acquisition through an intermediary network element 227 A primary design goal in this solution is to use the existing tools 228 in the RTP/RTCP protocol family. This improves the versatility of 229 the existing implementations, and promotes faster deployment and 230 better interoperability. To this effect, we use the unicast 231 retransmission support of RTP [RFC4588] and the capabilities of RTCP 232 to handle the signaling needed to accomplish the acquisition. The 233 packet(s) carrying the Reference Information are sent by the 234 Retransmission Server in the auxiliary unicast RTP session for rapid 235 acquisition. These are constructed as retransmission packets that 236 would have been sent in a unicast RTP session to recover the missing 237 packets at an RTP receiver that has never received any packet. In 238 fact, a single RTP session SHOULD be used for both rapid acquisition 239 and retransmission-based loss repair. This session can be used to 240 simultaneously provide the unicast burst for the rapid acquisition 241 and the repair packets requested by the RTP receivers when they 242 detect lost burst packets or lost RTP packets in the primary 243 multicast stream. The conventional RTCP feedback (NACK) message that 244 requests the retransmission of the missing packets [RFC4585] 245 indicates their sequence numbers. However, upon joining a new 246 session the RTP receiver has never received a packet, and thus, does 247 not know the sequence numbers. Instead, the RTP receiver sends a 248 newly defined RTCP feedback message to request the Reference 249 Information needed to rapidly get on the track with the primary 250 multicast session. It is also worth noting that in order to issue 251 the initial RTCP message to the feedback target, the SSRC of the 252 session to be joined must be known prior to any packet reception, and 253 hence, needs to be signaled out-of-band (or otherwise communicated to 254 the RTP receiver in advance of the initiation of the rapid 255 acquisition operation). In a Session Description Protocol (SDP) 256 description, the SSRC MUST be signaled through the 'ssrc' attribute 257 [I-D.ietf-avt-rtcpssm]. 259 In the rest of this specification, we have the following outline: In 260 Section 4, we describe the delay components in generic multicast 261 applications. Section 5 presents an overview of the protocol design 262 considerations for rapid acquisition. We provide the protocol 263 details of the rapid acquisition method in Section 6 and Section 7. 264 Section 8 and Section 9 discuss the SDP signaling issues with 265 examples and NAT-related issues, respectively. 267 Note that Section 3 provides a list of the definitions frequently 268 used in this document. 270 2. Requirements Notation 272 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 273 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 274 document are to be interpreted as described in [RFC2119]. 276 3. Definitions 278 This document uses the following acronyms and definitions frequently: 280 Primary Multicast Session: The multicast RTP session to which RTP 281 receivers can join at a random point in time. 283 Primary Multicast Stream: The RTP stream carried in the primary 284 multicast session. 286 Source Filtering Group Management Protocol (SFGMP): Following the 287 definition in [RFC4604], SFGMP refers to the Internet Group 288 Management Protocol (IGMP) version 3 [RFC3376] and the Multicast 289 Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and 290 IPv6 networks, respectively. However, the rapid acquisition method 291 introduced in this document does not depend on a specific version of 292 either of these group management protocols. In the remainder of this 293 document, SFGMP will refer to any group management protocol that has 294 Join and Leave functionalities. 296 Feedback Target: (Unicast RTCP) Feedback target as defined in 297 [I-D.ietf-avt-rtcpssm]. 299 Retransmission Packet: An RTP packet that is formatted as defined in 300 [RFC4588]. 302 Reference Information: The set of certain media content and metadata 303 information that is sufficient for an RTP receiver to start usefully 304 consuming a media stream. The meaning, format and size of this 305 information are specific to the application and are out of scope of 306 this document. 308 (Unicast) Burst (Stream): A unicast stream of RTP retransmission 309 packets that enable an RTP receiver to rapidly acquire the Reference 310 Information. The burst stream is typically transmitted at an 311 accelerated rate. 313 Retransmission Server (RS): The RTP/RTCP endpoint that can generate 314 the retransmission packets and the burst stream. RS may also 315 generate other non-retransmission packets to aid the RAMS process. 317 4. Elements of Delay in Multicast Applications 319 In an any-source (ASM) or a single-source (SSM) multicast delivery 320 system, there are three major elements that contribute to the overall 321 acquisition delay when an RTP receiver switches from one multicast 322 session to another one. These are: 324 o Multicast switching delay 326 o Reference Information latency 328 o Buffering delays 330 Multicast switching delay is the delay that is experienced to leave 331 the current multicast session (if any) and join the new multicast 332 session. In typical systems, the multicast join and leave operations 333 are handled by a group management protocol. For example, the 334 receivers and routers participating in a multicast session may use 335 the Internet Group Management Protocol (IGMP) version 3 [RFC3376] or 336 the Multicast Listener Discovery Protocol (MLD) version 2 [RFC3810]. 337 In either of these protocols, when a receiver wants to join a 338 multicast session, it sends a message to its upstream router and the 339 routing infrastructure sets up the multicast forwarding state to 340 deliver the packets of the multicast session to the new receiver. 341 Depending on the proximity of the upstream router, the current state 342 of the multicast tree, the load on the system and the protocol 343 implementation, the join times vary. Current systems provide join 344 latencies usually less than 200 milliseconds (ms). If the receiver 345 had been participating in another multicast session before joining 346 the new session, it needs to send a Leave message to its upstream 347 router to leave the session. In common multicast routing protocols, 348 the leave times are usually smaller than the join times, however, it 349 is possible that the Leave and Join messages may get lost, in which 350 case the multicast switching delay inevitably increases. 352 Reference Information latency is the time it takes the receiver to 353 acquire the Reference Information. It is highly dependent on the 354 proximity of the actual time the receiver joined the session to the 355 next time the Reference Information will be sent to the receivers in 356 the session, whether the Reference Information is sent contiguously 357 or not, and the size of the Reference Information. For some 358 multicast flows, there is a little or no interdependency in the data, 359 in which case the Reference Information latency will be nil or 360 negligible. For other multicast flows, there is a high degree of 361 interdependency. One example of interest is the multicast flows that 362 carry compressed audio/video. For these flows, the Reference 363 Information latency may become quite large and be a major contributor 364 to the overall delay. Refer to [I-D.begen-avt-rtp-mpeg2ts-preamble] 365 for details. 367 The buffering component of the overall acquisition delay is driven by 368 the way the application layer processes the payload. In many 369 multicast applications, an unreliable transport protocol such as UDP 370 [RFC0768] is often used to transmit the data packets, and the 371 reliability, if needed, is usually addressed through other means such 372 as Forward Error Correction and retransmission 373 [I-D.ietf-rmt-pi-norm-revised]. These loss-repair methods require 374 buffering at the receiver side to function properly. In many 375 applications, it is also often necessary to de-jitter the incoming 376 data packets before feeding them to the application. The de- 377 jittering process also increases the buffering delays. Besides these 378 network-related buffering delays, there are also specific buffering 379 needs that are required by the individual applications. For example, 380 standard video decoders typically require an amount, sometimes a 381 significant amount, of coded video data to be available in the pre- 382 decoding buffers prior to starting to decode the video bitstream. 384 5. Protocol Design Considerations and Their Effect on Resource 385 Management for Rapid Acquisition 387 Rapid acquisition is an optimization of a system that must continue 388 to work correctly whether or not the optimization is effective, or 389 even fails due to lost control messages, congestion, or other 390 problems. This is fundamental to the overall design requirements 391 surrounding the protocol definition and to the resource management 392 schemes to be employed together with the protocol (e.g., QoS 393 machinery, server load management, etc). In particular, the system 394 needs to operate within a number of constraints: 396 o First, a rapid acquisition operation must fail gracefully. The 397 user experience must, except perhaps in pathological 398 circumstances, be not significantly worse for trying and failing 399 to complete rapid acquisition compared to simply joining the 400 multicast session. 402 o Second, providing the rapid acquisition optimizations must not 403 cause collateral damage to either the multicast session being 404 joined, or other multicast sessions sharing resources with the 405 rapid acquisition operation. In particular, the rapid acquisition 406 operation must avoid self-interference with the multicast session 407 that may be simultaneously being received by other hosts. In 408 addition, it must also avoid interference with other multicast 409 sessions sharing the same network resources. These properties are 410 possible, but are usually difficult to achieve. 412 One challenge is the existence of multiple bandwidth bottlenecks 413 between the receiver and the server(s) in the network providing the 414 rapid acquisition service. In commercial IPTV deployments, for 415 example, bottlenecks are often present in the aggregation network 416 connecting the IPTV servers to the network edge, the access links 417 (e.g., DSL, DOCSIS) and in the home network of the subscribers. Some 418 of these links may serve only a single subscriber, limiting 419 congestion impact to the traffic of only that subscriber, but others 420 can be shared links carrying multicast sessions of many subscribers. 421 Also note that the state of these links may be varying over time. 422 The receiver may have knowledge of a portion of this network, or may 423 have partial knowledge of the entire network. The methods employed 424 by the devices to acquire this network state information is out of 425 scope for this document. The receiver should be able to signal the 426 server with the bandwidth that it believes it can handle. The server 427 also needs to be able to rate limit the flow in order to stay within 428 the performance envelope that it knows about. Both the server and 429 receiver need to be able to inform the other of changes in the 430 requested and delivered rates. However, the protocol must be robust 431 in the presence of packet loss, so this signaling must include the 432 appropriate default behaviors. 434 A second challenge is that for some uses (e.g., high-bitrate video) 435 the unicast burst bitrate is high while the flow duration of the 436 unicast burst is short. This is because the purpose of the unicast 437 burst is to allow the RTP receiver to join the multicast quickly and 438 thereby limit the overall resources consumed by the burst. Such 439 high-bitrate, short-duration flows are not amenable to conventional 440 admission control techniques. For example, end-to-end per-flow 441 signaled admission control techniques such as RSVP have too much 442 latency and control channel overhead to be a good fit for rapid 443 acquisition. Similarly, using a TCP (or TCP-like) approach with a 444 3-way handshake and slow-start to avoid inducing congestion would 445 defeat the purpose of attempting rapid acquisition in the first place 446 by introducing many RTTs of delay. 448 These observations lead to certain unavoidable requirements and goals 449 for a rapid acquisition protocol. These are: 451 o The protocol must be designed to allow a deterministic upper bound 452 on the extra bandwidth used (compared to just joining the 453 multicast session). A reasonable size bound is e*B, where B is 454 the "nominal" bandwidth of the primary multicast stream, and e is 455 an "excess-bandwidth" coefficient The total duration of the 456 unicast burst must have a reasonable bound; long unicast bursts 457 devolve to the bandwidth profile of multi-unicast for the whole 458 system. 460 o The scheme should minimize (or better eliminate) the overlap of 461 the unicast burst and the primary multicast stream. This 462 minimizes the window during which congestion could be induced on a 463 bottleneck link compared to just carrying the multicast or unicast 464 packets alone. 466 o The scheme must minimize (or better eliminate) any gap between the 467 unicast burst and the primary multicast stream, which has to be 468 repaired later, or in the absence of repair, will result in loss 469 being experienced by the application. 471 In addition to the above, there are some other protocol design issues 472 to be considered. First, there is at least one RTT of "slop" in the 473 control loop. In starting a rapid acquisition burst, this manifests 474 as the time between the client requesting the unicast burst and the 475 burst description and/or the first unicast burst packets arriving at 476 the receiver. For managing and terminating the unicast burst, there 477 are two possible approaches for the control loop: The receiver can 478 adapt to the unicast burst as received, converge based on observation 479 and explicitly terminate the unicast burst with a second control loop 480 exchange (which takes a minimum of one RTT, just as starting the 481 unicast burst does). Alternatively, the server generating the 482 unicast burst can pre-compute the burst parameters based on the 483 information in the initial request and tell the receiver the burst 484 duration. 486 The protocol described in the next section allows either method of 487 controlling the rapid acquisition unicast burst. 489 6. Rapid Acquisition of Multicast RTP Sessions 491 We start this section with an overview of the rapid acquisition of 492 multicast sessions (RAMS) method. 494 6.1. Overview 496 [I-D.ietf-avt-rtcpssm] specifies an extension to the RTP Control 497 Protocol (RTCP) to use unicast feedback in an SSM session. It 498 defines an architecture that introduces the concept of Distribution 499 Source, which - in an SSM context - distributes the RTP data and 500 redistributes RTCP information to all RTP receivers. This RTCP 501 information is retrieved from the Feedback Target, to which RTCP 502 unicast feedback traffic is sent. The Feedback Target MAY be 503 implemented in one or more entities different from the Distribution 504 Source, and different RTP receivers MAY use different Feedback 505 Targets. 507 This document builds further on these concepts to reduce the 508 acquisition time when an RTP receiver joins a multicast session at a 509 random point in time by introducing the concept of the Burst Source 510 and new RTCP feedback messages. The Burst Source has a cache where 511 the most recent packets from the primary multicast session are 512 continuously stored. When an RTP receiver wants to receive the 513 primary multicast stream, prior to joining the SSM session, it may 514 first request a unicast burst from the Burst Source. In this burst, 515 the packets are formatted as RTP retransmission packets [RFC4588] and 516 carry the Reference Information. This information allows the RTP 517 receiver to start usefully consuming the RTP packets sent in the 518 primary multicast session. 520 Using an accelerated rate (as compared to the rate of the primary 521 multicast stream) for the unicast burst implies that at a certain 522 point in time, the payload transmitted in the unicast burst is going 523 to be the same as the payload multicast in the SSM session, i.e., the 524 unicast burst will catch up with the primary multicast stream. At 525 this point, the RTP receiver no longer needs to receive the unicast 526 burst and can join the primary multicast session. This method is 527 referred to as the Rapid Acquisition of Multicast Sessions (RAMS). 529 This document proposes extensions to [RFC4585] for an RTP receiver to 530 request a unicast burst as well as for additional control messaging 531 that can be leveraged during the acquisition process. 533 6.2. Message Flows 535 Figure 2 shows the main entities involved in rapid acquisition: 537 o Multicast Source 539 o Feedback Target (FT) 541 o Burst/Retransmission Source 543 o RTP Receiver (RR) 544 +----------------------------------------------+ 545 | Retransmission Server | 546 | (RS) | 547 | +----------+ +---------------------------+ | 548 | | Feedback | | Burst/Retransmission | | 549 | | Target | | Source | | 550 | +----------+ +---------------------------+ | 551 +----------------------------------------------+ 552 ^ ^ : 553 | ' : 554 | ' : 555 | ' v 556 +-----------+ +----------+ +----------+ 557 | | | |'''''''''''>| | 558 | Multicast |------->| Router |...........>| RTP | 559 | Source | | |<~~~~~~~~~~~| Receiver | 560 | | | |----------->| (RR) | 561 +-----------+ +----------+ +----------+ 563 '''> Unicast RTCP Messages 564 ~~~> SFGMP Messages 565 ...> Unicast RTP Flow 566 ---> Multicast RTP Flow 568 Figure 2: Flow diagram for unicast-based rapid acquisition 570 The feedback target (FT) is the entity as defined in 571 [I-D.ietf-avt-rtcpssm], to which RR sends its RTCP feedback messages 572 indicating packet loss in the primary multicast stream by means of an 573 RTCP NACK message or indicating RR's desire to rapidly acquire the 574 primary multicast stream by means of an RTCP feedback message defined 575 in this document. While the Burst/Retransmission Source is 576 responsible for responding to these messages and for further RTCP 577 interaction with RR in the case of a rapid acquisition process, it is 578 assumed in the remainder of the document that these two logical 579 entities (FT and Burst/Retransmission Source) are combined in a 580 single physical entity and they share state. In the remainder of the 581 text, the term Retransmission Server will be used whenever 582 appropriate, to refer to the combined functionality of the FT and 583 Burst/Retransmission Source. 585 However, it must be noted that only FT is involved in the primary 586 multicast session, whereas the Burst/Retransmission Source transmits 587 the unicast burst and retransmission packets both formatted as RTP 588 retransmission packets [RFC4588] in a single separate unicast RTP 589 retransmission session to each RR. In the retransmission session, as 590 in any other RTP session, RS and RR regularly send the periodic 591 sender and receiver reports, respectively. 593 Note also that the same method (with the identical message flows) 594 would also apply in a scenario where rapid acquisition is performed 595 by a feedback target co-located with the media source. 597 The unicast burst is triggered by an RTCP feedback message that is 598 defined in this document, whereas an RTP retransmission is triggered 599 by an RTCP NACK message defined in [RFC4585]. Based on its design, 600 in an RAMS implementation, there may be a gap between the end of the 601 burst and the reception of the primary multicast stream because of 602 the imperfections in the switch-over. If needed, RR may make use of 603 the RTCP NACK message to request a retransmission for the missing 604 packets in the gap. 606 Figure 3 depicts an example of messaging flow for rapid acquisition. 607 The RTCP feedback messages are explained below. Note that the 608 messages indicated in parentheses may or may not be present during 609 rapid acquisition. 611 +-----------+ +----------------+ +----------+ +------------+ 612 | Multicast | | Retransmission | | | | RTP | 613 | Source | | Server | | Router | | Receiver | 614 | | | (RS) | | | | (RR) | 615 +-----------+ +----------------+ +----------+ +------------+ 616 | | | | 617 |-- RTP Multicast ------------------->| | 618 | | | | 619 |-- RTP Multicast ->| | | 620 | | | | 621 | |<'''''''''''''''''' RTCP RAMS-R ''| 622 | | | | 623 | | | | 624 | |'' (RTCP RAMS-I) ''''''''''''''''>| 625 | | | | 626 | | | | 627 | |.. Unicast RTP Burst ............>| 628 | | | | 629 | |<''''''''''''''''''(RTCP RAMS-R)''| 630 | | | | 631 | | | | 632 | |'' (RTCP RAMS-I) ''''''''''''''''>| 633 | | | | 634 | | | | 635 | | |<~ SFGMP Join ~~| 636 | | | | 637 | | | | 638 |-- RTP Multicast ------------------------------------>| 639 | | | | 640 | | | | 641 | |<'''''''''''''''''' RTCP RAMS-T ''| 642 | | | | 643 | | | | 644 | |<''''''''''''''''''' (RTCP NACK)''| 645 | | | | 646 | | | | 647 | |.. (Unicast Retransmissions) ....>| 648 | | | | 649 | | | | 650 | |<''''''''''''''''''' (RTCP BYE) ''| 651 | | | | 652 | | | | 654 '''> Unicast RTCP Messages 655 ~~~> SFGMP Messages 656 ...> Unicast RTP Flow 657 ---> Multicast RTP Flow 658 Figure 3: Message flows for unicast-based rapid acquisition 660 This document defines the expected behaviors of RS and RR. It is 661 instructive to have independently operating implementations on RS and 662 RR that request the burst, describe the burst, start the burst, join 663 the multicast session and stop the burst. These implementations send 664 messages to each other, but there MUST be provisions for the cases 665 where the control messages get lost, or re-ordered, or are not being 666 delivered to their destinations. 668 The following steps describe rapid acquisition in detail: 670 1. Request: RR sends a rapid acquisition request for the new 671 multicast RTP session to the feedback target address of that 672 session. The request contains the SSRC of RR and the SSRC of the 673 media source. This RTCP feedback message is defined as the RAMS- 674 Request (RAMS-R) message and MAY contain parameters, which may 675 constrain the burst, such as the bandwidth limit. Other 676 parameters may be related to the amount of buffering capacity 677 available at RR, which may be used by RS to prepare a burst that 678 conforms with RR's requirements. 680 Before joining the primary multicast session, a new joining RR 681 learns the addresses associated with the new multicast session 682 (addresses for the multicast source, group and retransmission 683 server) by out-of-band means. Also note that since no RTP 684 packets have been received yet for this session, the SSRC must be 685 obtained out-of-band. See Section 8 for details. 687 2. Response: RS receives the RAMS-R message and decides whether to 688 accept it or not. RS MUST send an (at least one) RAMS- 689 Information (RAMS-I) message to RR. The first RAMS-I message MAY 690 precede the unicast burst or it MAY be sent during the burst. 691 Additional RAMS-I messages MAY be sent during the burst and these 692 RAMS-I messages may or may not be a direct response to an RAMS-R 693 message. The RAMS-I message is sent by the Burst/Retransmission 694 Source logical entity that is part of RS. 696 Note that RS learns the IP address information for RR from the 697 RAMS-R message it received. (This description glosses over the 698 NAT details. Refer to Section 9 for a discussion of NAT-related 699 issues.) 701 If RS cannot provide a rapid acquisition service, RS rejects the 702 request and informs RR immediately via an RAMS-I message. If RR 703 receives a message indicating that its rapid acquisition request 704 has been denied, it abandons the rapid acquisition attempt and 705 MAY immediately join the multicast session by sending an SFGMP 706 Join message towards its upstream multicast router for the new 707 primary multicast session. 709 If RS accepts the request, it sends an RAMS-I message to RR 710 (before commencing the unicast burst or during the unicast burst) 711 that comprises fields that can be used to describe the unicast 712 burst (e.g., the maximum bitrate and the duration of the unicast 713 burst). A particularly important field in the RAMS-I message 714 carries the RTP sequence number of the first packet transmitted 715 in the retransmission session to allow RR to detect any missing 716 initial packet(s). Note that the first RTP packet transmitted in 717 the retransmission session is not necessarily a burst packet. It 718 could be a payload-specific RTP packet (See 719 [I-D.begen-avt-rtp-mpeg2ts-preamble] for an example). When RS 720 accepts the request, this field MUST be populated in the RAMS-I 721 message and it is RECOMMENDED that the RAMS-I message is sent 722 early enough in the session to be useful. If RS rejects the 723 request, this field SHALL NOT exist in the RAMS-I message. 725 It is RECOMMENDED to include a sender report with the RAMS-I 726 message in the same compound RTCP packet. This allows rapid 727 synchronization among multiple RTP flows 728 [I-D.ietf-avt-rapid-rtp-sync]. 730 The unicast burst duration MAY be calculated by RS, and its value 731 MAY be updated by messages received from RR. If RS accepts the 732 request, the join time information (for the new multicast 733 session) MUST be populated in at least one of the RAMS-I 734 messages. If RS rejects the request, including the join time 735 information in a RAMS-I message is OPTIONAL. 737 RS MAY send the RAMS-I message after a significant delay, so RR 738 SHOULD NOT make protocol dependencies on quickly receiving an 739 RAMS-I message. 741 3. Unicast Burst: If the request is accepted, RS starts sending the 742 unicast burst that comprises one or more RTP retransmission 743 packets (The burst packet(s) are sent by the Burst/Retransmission 744 Source logical entity). In addition, there MAY be optional 745 payload-specific information that RS chooses to send to RR. Such 746 an example is discussed in [I-D.begen-avt-rtp-mpeg2ts-preamble] 747 for transmitting the payload-specific information for MPEG2 748 Transport Streams. 750 4. Updated Request: RR MAY send a new RAMS-R message (to the FT 751 entity of RS) with a different value for one or more fields of an 752 earlier RAMS-R message. Upon receiving an updated request, RS 753 MAY use the updated values for sending/shaping the burst, or 754 refine the values and use the refined values for sending/shaping 755 the burst. 757 RS MAY send a new RAMS-I message to indicate the changes it made. 758 However, note that RS does not have to send a new RAMS-I, or the 759 new RAMS-I message may get lost. It is also possible that the 760 updated RAMS-R message could have been lost. Thus, RR SHOULD NOT 761 make protocol dependencies on quickly (or ever) receiving a new 762 RAMS-I message, or assume that RS will honor the requested 763 changes. 765 RR may be in an environment where the available resources are 766 time-varying, which may or may not deserve sending a new updated 767 request. Determining the circumstances where RR should or should 768 not send an updated request and the methods that RR can use to 769 detect and evaluate the time-varying available resources are not 770 specified in this document. 772 5. Updated Response: RS may send more than one RAMS-I messages, 773 e.g., to update the value of one or more fields in an earlier 774 RAMS-I message and/or to signal RR in real time to join the 775 primary multicast session. RR usually depends on RS to learn the 776 join time, which can be conveyed by the first RAMS-I message, or 777 can be sent/revised in a later RAMS-I message. If RS is not 778 capable of determining the join time in the first RAMS-I message, 779 it MUST send another RAMS-I message (with the join time 780 information) later. 782 6. Multicast Join Signaling: In principal, RR can join the primary 783 multicast session any time during or after the end of the unicast 784 burst via an SFGMP Join message. However, there may be missing 785 packets if RR joins the primary multicast session too early or 786 too late. For example, if RR starts receiving the primary 787 multicast stream while it is still receiving the unicast burst at 788 a high excess bitrate, this may result in an increased risk of 789 packet loss. Or, if RR joins the primary multicast session some 790 time after the unicast burst is finished, there may be a gap 791 between the burst and multicast data (a number of RTP packets may 792 be missing). In both cases, RR MAY issue retransmissions 793 requests (via RTCP NACK messages) [RFC4585] to fill the gap. 795 Yet, there are cases where the remaining available bandwidth may 796 limit the number of retransmissions that can be provided within a 797 certain time period, causing the retransmission data to arrive 798 too late at RR (from an application-layer point of view). To 799 cope with such cases, the RAMS-I message allows RS to signal 800 explicitly when RR should send the SFGMP Join message. 801 Alternatively, RS may pre-compute the burst duration and the time 802 RR should send the SFGMP Join message. This information may be 803 conveyed in the RAMS-I message and can be updated in a subsequent 804 RAMS-I message. While RR MAY use a locally calculated join time, 805 it SHOULD use the information from the most recent RAMS-I 806 message. 808 7. Multicast Receive: After the join, RR starts receiving the 809 primary multicast stream. 811 8. Terminate: RS may know when it needs to stop the unicast burst 812 based on the burst parameters, or RR MAY explicitly let RS know 813 the sequence number of the first RTP packet it received from the 814 multicast session, or RR MAY request RS to terminate the burst 815 immediately. 817 Regardless of whether or not RS knows when it needs to stop the 818 burst, RR SHALL use the RAMS-Termination (RAMS-T) message at an 819 appropriate time. RR can choose to send the RAMS-T message 820 before or after it starts receiving the multicast data. In the 821 latter case, RR SHALL include the sequence number of the first 822 RTP packet received in the primary multicast session in the 823 RAMS-T message, and RS SHOULD terminate the burst after it sends 824 the unicast burst packet whose Original Sequence Number (OSN) 825 field in the RTP retransmission payload header matches this 826 number minus one. 828 If RR wants to stop the burst prior to receiving the multicast 829 data, it sends an RAMS-T message without an RTP sequence number. 831 RR MUST send at least one RAMS-T message (if an RTCP BYE message 832 has not been issued yet as described in Step 9), and the RAMS-T 833 message MUST be addressed to the RTCP port of the retransmission 834 session. Against the possibility of a message loss, RR MAY 835 repeat the RAMS-T message multiple times as long as it follows 836 the RTCP timer rules defined in [RFC4585]. 838 9. Terminate with RTCP BYE: When RR is receiving the burst, if RR 839 becomes no longer interested in the primary multicast stream, RR 840 SHALL issue an RTCP BYE message for the RTP retransmission 841 session and another RTCP BYE message for the primary multicast 842 session. 844 Upon receiving an RTCP BYE message, RS MUST terminate the rapid 845 acquisition operation, and cease transmitting any further regular 846 retransmission packets as well as retransmission packets 847 associated with the unicast burst. If support for [RFC5506] has 848 been signaled, the RTCP BYE message MAY be sent in a reduced-size 849 RTCP packet. Otherwise, Section 6.1 of [RFC3550] mandates the 850 RTCP BYE message always to be sent with a sender or receiver 851 report in a compound RTCP packet (If no data has been received, 852 an empty receiver report MUST be included). With the information 853 contained in the receiver report, RS can also figure out how many 854 duplicate RTP packets have been delivered to RR (Note that this 855 will be an upper-bound estimate as one or more packets might have 856 been lost during the burst transmission). The impact of 857 duplicate packets and measures that can be taken to minimize the 858 impact of receiving duplicate packets will be addressed in 859 Section 6.3. 861 Note that an RTCP BYE message issued for the RTP retransmission 862 session terminates the whole session and ceases transmitting any 863 further packets in that RTP session. Thus, in this case there is 864 no need for sending an (explicit) RAMS-T message, which would 865 only terminate the burst. 867 Note that for the purpose of gathering detailed information about 868 RR's rapid acquisition experience, [I-D.begen-avt-rapid-sync-rtcp-xr] 869 defines an RTCP Extended Report (XR) Block. This report is designed 870 to be payload-independent, thus, it can be used by any multicast 871 application that supports rapid acquisition. Support for this XR 872 report is, however, optional. 874 6.3. Shaping the Unicast Burst 876 This section provides informative guidelines about how RS can shape 877 the transmission of the unicast burst. 879 A higher bitrate for the unicast burst naturally conveys the 880 Reference Information and media content to RR faster. This way, RR 881 can start consuming the data sooner, which results in a faster 882 acquisition. 884 A higher rate also represents a better utilization of RS resources. 885 As the burst may continue until it catches up with the primary 886 multicast stream, the higher the bursting rate, the less data RS 887 needs to transmit. However, a higher rate for the burst also 888 increases the chances for congestion-caused packet loss. Thus, as 889 discussed in Section 5, there must be an upper bound on the extra 890 bandwidth used by the burst. 892 When RS transmits the burst, it SHOULD take into account all 893 available information to prevent any packet loss that may take place 894 during the bursting as a result of buffer overflow on the path 895 between RS and RR and at RR itself. The bursting rate may be 896 determined by taking into account the following data, when available: 898 a. Information obtained via the RAMS-R message, such as Max RAMS 899 Buffer Fill Requirement and/or Max Receive Bitrate (See 900 Section 7.2). 902 b. Information obtained via RTCP receiver reports provided by RR in 903 the retransmission session, allowing in-session rate adaptations 904 for the burst. When these receiver reports indicate packet loss, 905 this may indicate a certain congestion state in the path from RS 906 to RR. Heuristics or algorithms that deduce such congestion 907 state and how subsequently the RS should act, are outside the 908 scope of this document. 910 c. Information obtained via RTCP NACKs provided by RR in the primary 911 multicast session, allowing in-session rate adaptations for the 912 burst. Such RTCP NACKs are transmitted by RR in response to 913 packet loss detection by RR in the burst. NACKs may indicate a 914 certain congestion state on the path from RS to RR. Heuristics 915 or algorithms that deduce such congestion state and how 916 subsequently the RS should act, are outside the scope of this 917 document. 919 d. There may be other feedback received from RR, e.g., in the form 920 of ECN-CE RTCP feedback messages [I-D.westerlund-avt-ecn-for-rtp] 921 that may influence in-session rate adaptations. 923 e. Information obtained via updated RAMS-R messages, allowing in- 924 session rate adaptations, if supported by RS. 926 f. Pre-configured settings for each RR or a set of RRs that indicate 927 the upper-bound bursting rates for which no packet loss will 928 occur as a result of congestion along the path of RS to RR. For 929 example, in managed IPTV networks, where the bottleneck bandwidth 930 along the end-to-end path is known (which is generally the access 931 network link) and where the network between RS and this link is 932 provisioned and dimensioned to carry the burst streams, the 933 bursting rate does not exceed the provisioned value. These 934 settings may also be dynamically adapted using application-aware 935 knowledge. 937 The initial bursting rate of the unicast burst to RR is determined by 938 parameters directly obtained from RR (a) or by pre-configured 939 settings (f). If such information is not available, RS may choose an 940 appropriate initial bursting rate, and could increase or decrease the 941 rate based on the feedback information (b, c, d or e). However, this 942 may not be an easy task as by the time packet loss is reported back 943 to RS triggering a rate reduction, packet loss may have occurred. 945 A specific situation occurs near the end of the unicast burst, when 946 RS has almost no more additional data to sustain the relatively 947 higher bursting rate, thus, the upper-bound bursting rate 948 automatically gets limited by the nominal rate of the primary 949 multicast stream. During this time frame, RR will join the primary 950 multicast session because it was instructed to do so via an RAMS-I 951 message or based on some heuristics. This means that both the burst 952 packets and the primary multicast stream packets will be 953 simultaneously received by RR for a period of time. 955 In this case, when the unicast burst is close to catch up with the 956 primary multicast stream, RS may, for example, keep on sending burst 957 packets but should reduce the rate accordingly by taking the nominal 958 rate of the primary multicast stream into account. Alternatively, RS 959 may immediately cease transmitting the burst packets, when being 960 close to catch-up. Any gap resulting from an imperfect switch by RR 961 in receiving first the burst packets and then only primary multicast 962 stream packets, can be later repaired by requesting retransmissions 963 of the missing packets from RS. The retransmissions may also be 964 shaped by RS to make sure that they do not cause collateral loss in 965 the primary multicast and retransmission sessions. 967 6.4. Failure Cases 969 All RAMS messages MAY be sent several times against the possibility 970 of message loss as long as RS/RR follows the RTCP timer rules defined 971 in [RFC4585]. In the following, we examine the implications of 972 losing the RAMS-R, RAMS-I or RAMS-T messages. 974 When RR sends an RAMS-R message to initiate a rapid acquisition but 975 the message gets lost and RS does not receive it, RR will not get an 976 RAMS-I message, nor a unicast burst. In this case, RR MAY resend the 977 request when it is eligible to do so. Or, after a reasonable amount 978 of time, RR MAY time out (based on the previous observed response 979 times) and immediately join the primary multicast session. In this 980 case, RR MUST still send an RAMS-T message. 982 In the case RR starts receiving a unicast burst but it does not 983 receive a corresponding RAMS-I message within a reasonable amount of 984 time, RR MAY either discard the burst data and stop the burst by 985 sending an RAMS-T message to RS, or decide not to interrupt the 986 unicast burst and be prepared to join the primary multicast session 987 at an appropriate time it determines or indicated in a subsequent 988 RAMS-I message (if available). In either case, RR SHALL send an 989 RAMS-T message to RS at an appropriate time. 991 In the case the RAMS-T message sent by RR does not reach its 992 destination, RS may continue sending the unicast burst even though RR 993 no longer needs it. In some cases, RS has not pre-computed the burst 994 duration and does not know when to stop the burst. To cover that 995 case, RR MAY repeat the RAMS-T message multiple times as long as it 996 follows the RTCP timer rules defined in [RFC4585]. RS MUST be 997 provisioned to deterministically terminate the burst at some point, 998 even if it never receives an RAMS-T message for an ongoing burst. 1000 If RR becomes no longer interested in receiving the primary multicast 1001 stream and the associated unicast burst, RR SHALL issue an RTCP BYE 1002 message to RS to terminate the RTP retransmission session. Only 1003 after that, RR MAY send a new rapid acquisition request for another 1004 primary multicast session. 1006 7. Encoding of the Signaling Protocol in RTCP 1008 This section defines the formats of the RTCP transport-layer feedback 1009 messages that are exchanged between the Retransmission Server (RS) 1010 and RTP Receiver (RR) during rapid acquisition. These messages are 1011 referred to as the RAMS Messages. They are payload-independent and 1012 MUST be used by all RTP-based multicast applications that support 1013 rapid acquisition regardless of the payload they carry. 1015 Payload-specific feedback messages are not defined in this document, 1016 but an extension mechanism is provided where further optional 1017 payload-independent and payload-specific information can be included 1018 in the exchange. 1020 The common packet format for the RTCP feedback messages is defined in 1021 Section 6.1 of [RFC4585]. Each feedback message has a fixed-length 1022 field for version, padding, feedback message type (FMT), payload type 1023 (PT), length, SSRC of packet sender, SSRC of media source as well as 1024 a variable-length field for feedback control information (FCI). 1026 In the RAMS messages, the PT field is set to RTPFB (205) and the FMT 1027 field is set to RAMS (6). Individual RAMS messages are identified by 1028 a sub-field called Sub Feedback Message Type (SFMT). 1030 Depending on the specific scenario and timeliness/importance of a 1031 RAMS message, it may be desirable to send it in a reduced-size RTCP 1032 packet [RFC5506]. However, unless support for [RFC5506] has been 1033 signaled, compound RTCP packets MUST be used by following [RFC3550] 1034 rules. 1036 7.1. Extensions 1038 To improve the functionality of the RAMS method in certain 1039 applications, it may be desirable to define new fields in the RAMS 1040 Request, Information and Termination messages. Such fields MUST be 1041 encoded as TLV elements as described below and sketched in Figure 4: 1043 o Type: A single-octet identifier that defines the type of the 1044 parameter represented in this TLV element. 1046 o Length: A two-octet field that indicates the length of the TLV 1047 element excluding the Type and Length fields in octets. Note that 1048 this length does not include any padding that is required for 1049 alignment. 1051 o Value: Variable-size set of octets that contains the specific 1052 value for the parameter. 1054 If a TLV element does not fall on a 32-bit boundary, the last word 1055 must be padded to the boundary using further bits set to 0. 1057 In an RAMS message any vendor-neutral or private extension MUST be 1058 placed after the mandatory fields (if any). The support for 1059 extensions is OPTIONAL. 1061 0 1 2 3 1062 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 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | Type | Length | Value | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | Value contd. / 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 Figure 4: Structure of a TLV element 1071 7.1.1. Vendor-Neutral Extensions 1073 If the goal in defining new TLV elements is to extend the 1074 functionality in a vendor-neutral manner, they MUST be registered 1075 with IANA through the guidelines provided in Section 13.5. 1077 The current document defines several vendor-neutral extensions in the 1078 following sections. 1080 7.1.2. Private Extensions 1082 It is desirable to allow vendors to use private extensions in TLV 1083 format. For interoperability, such extensions MUST NOT collide with 1084 each other. 1086 A certain range of TLV Types is reserved for private extensions 1087 (Refer to Section 13.5). IANA management for these extensions is 1088 unnecessary and they are the responsibility of individual vendors. 1090 The structure that MUST be used for the private extensions is 1091 depicted in Figure 5. Here, the enterprise numbers are used from 1092 http://www.iana.org/assignments/enterprise-numbers. This will ensure 1093 the uniqueness of the private extensions and avoid any collision. 1095 0 1 2 3 1096 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 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | Type | Length | Ent. Number | 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | Ent. Number contd. | Value | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 | Value contd. / 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 Figure 5: Structure of a private extension 1107 7.2. RAMS Request 1109 The RAMS Request message is identified by SFMT=1. 1111 The FCI field MUST contain only one RAMS Request. 1113 The RAMS Request is used by RR to request rapid acquisition for a new 1114 multicast RTP session. 1116 The FCI field has the structure depicted in Figure 6. 1118 Editor's note: We have not finalized whether RAMS-R messages need a 1119 sequence number or not. 1121 0 1 2 3 1122 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 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | SFMT=1 | Optional TLV-encoded Fields | 1125 +-+-+-+-+-+-+-+-+ | 1126 : Optional TLV-encoded Fields (and Padding, if needed) : 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 Figure 6: FCI field syntax for the RAMS Request message 1131 o Min RAMS Buffer Fill Requirement (32 bits): Optional TLV element 1132 that denotes the minimum milliseconds of data that RR desires to 1133 have in its buffer before allowing the data to be consumed by the 1134 application. 1136 RR may have knowledge of its buffering requirements. These 1137 requirements may be application and/or device specific. For 1138 instance, RR may need to have a certain amount of data in its 1139 application buffer to handle transmission jitter and/or to be able 1140 to support error-control methods. If RS is told the minimum 1141 buffering requirement of the receiver, it may tailor the burst 1142 more precisely, e.g., by choosing an appropriate starting point. 1143 The methods used by RR to determine this value are application 1144 specific, and thus, out of the scope of this document. 1146 If specified, the amount of backfill that will be provided by the 1147 unicast burst SHOULD NOT be smaller than the specified value since 1148 it will not be able to build up the desired level of buffer at RR 1149 and may cause buffer underruns. 1151 Type: 1 1153 o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element 1154 that denotes the maximum milliseconds of data that RR can buffer 1155 without losing the burst data due to buffer overflow. 1157 RR may have knowledge of its buffering requirements. These 1158 requirements may be application or device specific. For instance, 1159 one particular RR may have more physical memory than another RR, 1160 and thus, can buffer more data. If RS knows the buffering ability 1161 of the receiver, it may tailor the burst more precisely. The 1162 methods used by the receiver to determine this value are 1163 application specific, and thus, out of scope. 1165 If specified, the amount of backfill that will be provided by the 1166 unicast burst SHOULD NOT be larger than this value since it may 1167 cause buffer overflows at RR. 1169 Type: 2 1171 o Max Receive Bitrate (32 bits): Optional TLV element that denotes 1172 the maximum bitrate (in bits per second) that the RTP receiver can 1173 process the unicast burst. This rate should include whatever 1174 knowledge the receiver has that would provide an upper bound on 1175 the unicast burst bitrate. The limits may include local receiver 1176 limits as well as network limits that are known to the receiver. 1178 If specified, the unicast burst bitrate SHOULD NOT be larger than 1179 this value since it may cause congestion and packet loss. 1181 Type: 3 1183 The semantics of the RAMS-R feedback message is independent of the 1184 payload type. 1186 7.3. RAMS Information 1188 The RAMS Information message is identified by SFMT=2. 1190 The FCI field MUST contain only one RAMS Information. 1192 The RAMS Information is used to describe the unicast burst that will 1193 be sent for rapid acquisition. It also includes other useful 1194 information for RR as described below. Optional payload-specific 1195 information MAY follow RAMS Information. 1197 The FCI field has the structure depicted in Figure 7. 1199 0 1 2 3 1200 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 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | SFMT=2 | MSN | Response | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 : Optional TLV-encoded Fields (and Padding, if needed) : 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 Figure 7: FCI field syntax for the RAMS Information message 1209 o Message Sequence Number (8 bits) : Mandatory field that denotes 1210 the sequence number of this RAMS-I message. During rapid 1211 acquisition, multiple RAMS-I messages MAY be sent and/or the same 1212 RAMS-I message MAY be repeated. The first RAMS-I message SHALL 1213 have an MSN value of 0. This value SHALL NOT be changed if the 1214 same RAMS-I message is sent to the same RR multiple times for 1215 redundancy purposes. If a new information is conveyed in a new 1216 RAMS-I message, the MSN value SHALL be incremented by one. 1218 o Response (16 bits): Mandatory field that denotes the RS response 1219 code for this RAMS-I message. This document defines several 1220 initial response codes and registers them with IANA. If a new 1221 vendor-neutral response code will be defined, it MUST be 1222 registered with IANA through the guidelines specified in 1223 Section 13.6. If the new response code is intended to be used 1224 privately by a vendor, there is no need for IANA management. 1225 Instead, the vendor MUST use the private extension mechanism 1226 (Section 7.1.2) to convey its message and MUST indicate this by 1227 putting zero in the Response field. 1229 o RTP Seqnum of the First Packet (16 bits): TLV element that 1230 specifies the RTP sequence number of the first packet that will be 1231 sent in the retransmission session. This allows RR to know 1232 whether one or more packets sent by RS have been dropped at the 1233 beginning of the retransmission session. If RS accepts the RAMS 1234 request, this element MUST exist. If RS rejects the RAMS request, 1235 this element SHALL NOT exist. 1237 Type: 31 1239 o Earliest Multicast Join Time (32 bits): Optional TLV element that 1240 specifies the time difference (i.e., delta time) between the 1241 arrival of this RAMS-I message and the earliest time instant when 1242 RR could join the primary multicast session in RTP ticks. A zero 1243 value in this field means that RR can join the primary multicast 1244 session right away. 1246 Note that if the RAMS request has been accepted, RS MUST send this 1247 field at least once, so that RR knows when to join the primary 1248 multicast session. If the burst request has been rejected as 1249 indicated in the Response field, this field MAY be omitted or set 1250 to 0. In that case, it is up to RR when or whether to join the 1251 primary multicast session. 1253 Type: 32 1255 o Burst Duration (32 bits): Optional TLV element that denotes the 1256 duration of the burst that RS is planning to send (in RTP ticks). 1257 In the absence of additional stimulus, RS will send a burst of 1258 this duration. However, the burst duration may be modified by 1259 subsequent events, including changes in the primary multicast 1260 stream and reception of RAMS-T messages. 1262 Note that RS MUST terminate the flow in a deterministic timeframe, 1263 even if it does not get an RAMS-T or a BYE from RR. It is 1264 optional to send this field in an RAMS-I message when the burst 1265 request is accepted. If the burst request has been rejected as 1266 indicated in the Response field, this field MAY be omitted or set 1267 to 0. 1269 Type: 33 1271 o Max Transmit Bitrate (32 bits): Optional TLV element that denotes 1272 the maximum bitrate (in bits per second) that will be used by RS. 1274 Type: 34 1276 The semantics of the RAMS-I feedback message is independent of the 1277 payload type. 1279 The RAMS-I message MAY be sent multiple times at the start of, prior 1280 to, or during the unicast burst. The subsequent RAMS-I messages MAY 1281 signal changes in any of the fields. 1283 7.4. RAMS Termination 1285 The RAMS Termination message is identified by SFMT=3. 1287 The FCI field MUST contain only one RAMS Termination. 1289 The RAMS Termination may be used to assist RS in determining when to 1290 stop the burst. 1292 If prior to sending the RAMS-T message RR has already joined the 1293 primary multicast session and received at least one RTP packet from 1294 the multicast session, RR includes the sequence number of the first 1295 RTP packet in the RAMS-T message. With this information, RS can 1296 decide when to terminate the unicast burst. 1298 If RR issues the RAMS-T message before it has joined and/or begun 1299 receiving RTP packets from the primary multicast session, RR does not 1300 specify any sequence number in the RAMS-T message, which indicates RS 1301 to stop the burst immediately. However, the RAMS-T message may get 1302 lost and RS may not receive this message. 1304 The FCI field has the structure depicted in Figure 8. 1306 0 1 2 3 1307 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 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 | SFMT=3 | Optional TLV-encoded Fields | 1310 +-+-+-+-+-+-+-+-+ | 1311 : Optional TLV-encoded Fields (and Padding, if needed) : 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 Figure 8: FCI field syntax for the RAMS Termination message 1316 o Extended RTP Seqnum of First Multicast Packet (32 bits): Optional 1317 TLV element that specifies the extended RTP sequence number of the 1318 of the first multicast packet received by RR. If no RTP packet 1319 has been received from the primary multicast session, this field 1320 does not exist and tells RS to stop the burst immediately. 1322 Type: 61 1324 The semantics of the RAMS-T feedback message is independent of the 1325 payload type. 1327 8. SDP Definitions and Examples 1329 8.1. Definitions 1331 The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585]. 1332 Here we add the following syntax to the 'rtcp-fb' attribute (the 1333 feedback type and optional parameters are all case sensitive): 1335 (In the following ABNF [RFC5234], fmt, SP and CRLF are used as 1336 defined in [RFC4566].) 1338 rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF 1340 rtcp-fb-pt = "*" ; wildcard: applies to all formats 1341 / fmt ; as defined in SDP spec 1343 rtcp-fb-val = "nack" SP "ssli" 1345 The following parameter is defined in this document for use with 1346 'nack': 1348 o 'ssli' stands for Stream Synchronization Loss Indication and 1349 indicates the use of RAMS messages as defined in Section 7. 1351 This document also defines a new SDP attribute ('rams-updates') that 1352 indicates whether RS supports updated request messages or not. This 1353 attribute is used in a declarative manner. If RS supports updated 1354 request messages and this attribute is included in the SDP 1355 description, RR MAY send updated requests. RS may or may not be able 1356 to accept value changes in every field in an RAMS-R message. 1357 However, if the 'rams-updates' attribute is not included in the SDP 1358 description, RR SHALL NOT send updated requests (RR MAY repeat its 1359 initial request without changes, though). 1361 8.2. Examples 1363 This section provides a declarative SDP [RFC4566] example for 1364 enabling rapid acquisition of multicast RTP sessions. The following 1365 example uses the SDP grouping semantics [I-D.ietf-mmusic-rfc3388bis], 1366 the RTP/AVPF profile [RFC4585], the RTP retransmissions [RFC4588], 1367 the RTCP extensions for SSM sessions with unicast feedback 1368 [I-D.ietf-avt-rtcpssm] and the source-specific media attributes 1369 [RFC5576]. 1371 In the example shown Figure 9, we have a primary multicast stream and 1372 a unicast retransmission stream. The source stream is multicast from 1373 a distribution source (with a source IP address of 192.0.2.2) to the 1374 multicast destination address of 233.252.0.2 and port 41000. A 1375 Retransmission Server including feedback target functionality (with 1376 an address of 192.0.2.1 and port of 41001) is specified with the 1377 'rtcp' attribute. The RTP receiver(s) can report missing packets on 1378 the source stream to the feedback target and request retransmissions. 1379 In the RAMS context, the parameter 'rtx-time' specifies the time in 1380 milliseconds that the Retransmission Server keeps an RTP packet in 1381 its buffer available for retransmission (measured from the time the 1382 packet was received by the Retransmission Server). 1384 The RTP retransmissions are sent on a unicast session with a 1385 destination port of 41002. 1387 Editor's note: This text will be updated in a later version to 1388 reflect the capability for RRs to use their desired ports to receive 1389 the burst and retransmission packets. 1391 The RTCP port for the unicast session (41003) is specified with the 1392 'rtcp' attribute. In this example, both the conventional 1393 retransmission and rapid acquisition support are enabled. This is 1394 achieved by the additional "a=rtcp-fb:98 nack ssli" line. Note that 1395 this SDP includes the "a=sendonly" line for the media description of 1396 the retransmission stream and is for the Retransmission Server (RS). 1397 Its counterpart for the RTP Receiver (RR) includes the "a=recvonly" 1398 line as shown in Figure 10. 1400 When an RTP receiver requires rapid acquisition for a new multicast 1401 session it wants to join, it sends an RAMS-R message to the feedback 1402 target of that primary multicast session. This feedback message has 1403 to have the SSRC of the primary multicast stream for which rapid 1404 acquisition is requested for. However, since this RTP receiver has 1405 not received any RTP packets from the primary multicast session yet, 1406 the RTP receiver MUST learn the SSRC value from the 'ssrc' attribute 1407 of the media description [I-D.ietf-avt-rtcpssm]. In addition to the 1408 SSRC value, the 'cname' source attribute MUST also be present in the 1409 SDP description [RFC5576]. 1411 Note that listing the SSRC values for the primary multicast sessions 1412 in the SDP file does not create a problem in SSM sessions when an 1413 SSRC collision occurs. This is because in SSM sessions, an RTP 1414 receiver that observed an SSRC collision with a media source MUST 1415 change its own SSRC [I-D.ietf-avt-rtcpssm] by following the rules 1416 defined in [RFC3550]. 1418 A feedback target that receives an RAMS-R feedback message becomes 1419 aware that the prediction chain at the RTP receiver side has been 1420 broken or does not exist any more. If the necessary conditions are 1421 satisfied (as outlined in Section 7 of [RFC4585]) and available 1422 resources exist, RS MAY react to the RAMS-R message by sending any 1423 transport-layer and payload-specific feedback message(s) and starting 1424 the unicast burst. 1426 v=0 1427 o=ali 1122334455 1122334466 IN IP4 rams.example.com 1428 s=Rapid Acquisition Example 1429 t=0 0 1430 a=group:FID 3 4 1431 a=rtcp-unicast:rsi 1432 m=video 41000 RTP/AVPF 98 1433 i=Primary Multicast Stream #2 1434 c=IN IP4 233.252.0.2/255 1435 a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2 1436 a=recvonly 1437 a=rtpmap:98 MP2T/90000 1438 a=rtcp:41001 IN IP4 192.0.2.1 1439 a=rtcp-fb:98 nack 1440 a=rtcp-fb:98 nack ssli 1441 a=ssrc:123321 cname:iptv-ch32@rams.example.com 1442 a=rams-updates 1443 a=mid:3 1444 m=video 41002 RTP/AVPF 99 1445 i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support) 1446 c=IN IP4 192.0.2.1 1447 a=sendonly 1448 a=rtpmap:99 rtx/90000 1449 a=rtcp:41003 1450 a=fmtp:99 apt=98; rtx-time=5000 1451 a=mid:4 1453 Figure 9: Example SDP for RS when RAMS support is enabled 1455 v=0 1456 o=ali 1122334455 1122334466 IN IP4 rams.example.com 1457 s=Rapid Acquisition Example 1458 t=0 0 1459 a=group:FID 3 4 1460 a=rtcp-unicast:rsi 1461 m=video 41000 RTP/AVPF 98 1462 i=Primary Multicast Stream #2 1463 c=IN IP4 233.252.0.2/255 1464 a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2 1465 a=recvonly 1466 a=rtpmap:98 MP2T/90000 1467 a=rtcp:41001 IN IP4 192.0.2.1 1468 a=rtcp-fb:98 nack 1469 a=rtcp-fb:98 nack ssli 1470 a=ssrc:123321 cname:iptv-ch32@rams.example.com 1471 a=rams-updates 1472 a=mid:3 1473 m=video 41002 RTP/AVPF 99 1474 i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support) 1475 c=IN IP4 192.0.2.1 1476 a=recvonly 1477 a=rtpmap:99 rtx/90000 1478 a=rtcp:41003 1479 a=fmtp:99 apt=98; rtx-time=5000 1480 a=mid:4 1482 Figure 10: Example SDP for RR when RAMS support is enabled 1484 The offer/answer model considerations [RFC3264] for the 'rtcp-fb' 1485 attribute are provided in Section 4.2 of [RFC4585]. 1487 In this section, we considered the simplest scenario where the 1488 primary multicast session carried only one multicast stream and the 1489 RTP receiver wanted to rapidly acquire this stream only. Discussions 1490 on scenarios and associated SDP examples where the primary multicast 1491 session carries two or more multicast streams or the RTP receiver 1492 wants to acquire one or more multicast streams from multiple 1493 multicast RTP sessions at the same time are presented in 1494 [I-D.begen-avt-rams-scenarios]. 1496 9. NAT Considerations 1498 For a variety of reasons, one or more NAPT devices (hereafter simply 1499 called NAT) are expected to exist between RR and RS. NATs have a 1500 variety of operating characteristics for UDP traffic [RFC4787]. For 1501 a NAT to permit traffic from RS to arrive at RR, the NAT(s) must 1502 first either: 1504 a. See UDP traffic sent from RR (which is on the 'inside' of the 1505 NAT) to RS (which is on the 'outside' of the NAT). This traffic 1506 is sent to the same transport address as the subsequent response 1507 traffic, OR; 1509 b. Be configured to forward certain ports (e.g., using HTML 1510 configuration, UPnP IGD [UPnP-IGD], DLNA [DLNA]). Details of 1511 this are out of scope of this document. 1513 For both (a) and (b), RR is responsible for maintaining the NAT's 1514 state if it wants to receive traffic from the RS on that port. For 1515 (a), RR MUST send UDP traffic to keep the NAT binding alive, at least 1516 every 30 seconds [RFC4787]. Note that while (a) is more like an 1517 automatic/dynamic configuration, (b) is more like a manual/static 1518 configuration. 1520 When using (a), RR will need to first learn the UDP port(s) of the 1521 NAT's binding(s) from the perspective of RS. This is done by sending 1522 a STUN [RFC5389] message from RR to the RTP port of RS which will be 1523 used for incoming RTP traffic. If RTP/RTCP multiplexing on a single 1524 port [I-D.ietf-avt-rtp-and-rtcp-mux] is not supported by RR, it will 1525 need to send a second STUN message to the RTCP port of RS which will 1526 be used for incoming RTCP traffic. If RTP/RTCP multiplexing is 1527 supported by RR, it only needs to learn one port. RS receives the 1528 STUN message(s) and responds to them. RR now knows the UDP ports 1529 from the perspective of RS. 1531 Editor's note: The issues related to using ports across multicast 1532 and unicast RTP sessions are discussed in 1533 [I-D.begen-avt-ports-for-ucast-mcast-rtp]. The updated text for this 1534 section will be provided in a later version. 1536 10. Known Implementations 1538 10.1. Open Source RTP Receiver Implementation by Cisco 1540 An open source RTP Receiver code that implements the functionalities 1541 introduced in this document is available. For documentation, visit 1542 the following URL: 1544 http://www.cisco.com/en/US/docs/video/cds/cda/vqe/3_4/user/guide/ 1545 vqe_guide3_4.html 1547 The code is also available at: 1549 ftp://ftpeng.cisco.com/ftp/vqec/ 1551 Note that this code is under development and may be based on an 1552 earlier version of this document. As we make progress in the draft, 1553 the source code will also be updated to reflect the changes. 1555 Some preliminary results based on this code are available in [CCNC09] 1556 and [IC2009]. 1558 10.2. IPTV Commercial Implementation by Microsoft 1560 Rapid Acquisition of Multicast RTP Sessions is supported as part of 1561 the Microsoft Mediaroom Internet Protocol Television (IPTV) and 1562 multimedia software platform. This system is in wide commercial 1563 deployment. More information can be found at: 1565 http://www.microsoft.com/mediaroom 1567 http://informitv.com/articles/2008/10/13/channelchangetimes/ 1569 11. Open Issues 1571 o Updating the NAT section and SDP examples. 1573 12. Security Considerations 1575 Applications that are using RAMS make heavy use of the unicast 1576 feedback mechanism described in [I-D.ietf-avt-rtcpssm] and the 1577 payload format defined in [RFC4588]. Thus, these applications are 1578 subject to the general security considerations discussed in 1579 [I-D.ietf-avt-rtcpssm] and [RFC4588]. In this section, we give an 1580 overview of the guidelines and suggestions described in these 1581 specifications from a RAMS perspective. We also discuss the security 1582 considerations that explicitly apply to RAMS applications. 1584 First of all, much of the session description information is 1585 available in the SDP descriptions that are distributed to the media 1586 sources, Retransmission Servers and RTP Receivers. Adequate security 1587 measures are RECOMMENDED to ensure the integrity and authenticity of 1588 the SDP descriptions so that transport addresses of the media 1589 sources, Feedback Targets as well as other session-specific 1590 information can be authenticated. 1592 Compared to an RTCP NACK message that triggers one or more 1593 retransmissions, an RAMS Request (RAMS-R) message may trigger a new 1594 burst stream to be sent by the Retransmission Server. Depending on 1595 the application-specific requirements and conditions existing at the 1596 time of the RAMS-R reception by the Retransmission Server, the 1597 resulting burst stream may contain potentially a large number of 1598 retransmission packets. Since these packets are sent at a faster 1599 than the nominal rate of the multicast session, RAMS consumes more 1600 resources on the Retransmission Server, the RTP Receiver and the 1601 network. This particularly makes denial-of-service attacks more 1602 intense, and hence, more harmful than attacks that target ordinary 1603 retransmission sessions. 1605 Following the suggestions given in [RFC4588], counter-measures SHOULD 1606 be taken to prevent tampered or spoofed RTCP packets. Tampered 1607 RAMS-R messages may trigger inappropriate burst streams or alter the 1608 existing burst streams in an inappropriate way. For example, if the 1609 Max Receive Bitrate field is altered by a tampered RAMS-R message, 1610 the updated burst may overflow the buffer on the receiver side, or 1611 oppositely, may slow down the burst to the point that it is useless. 1612 Tampered RAMS Termination (RAMS-T) messages may terminate valid burst 1613 streams pre-maturely resulting in gaps in the received RTP packets. 1614 RAMS Information (RAMS-I) messages contain fields that are critical 1615 for the success of the RAMS operation. Any tampered information in 1616 the RAMS-I message may easily cause the RTP Receiver to make wrong 1617 decisions. Consequently, the RAMS operation may fail. 1619 While most of the denial-of-service attacks can be prevented by the 1620 integrity and authenticity checks enabled by SRTP, an attack can 1621 still be started by legitimate endpoints that send several valid 1622 RAMS-R messages to a particular Feedback Target in a synchronized 1623 fashion and very short amount of time. Since a RAMS operation may 1624 temporarily consume a large amount of resources, a series of the 1625 RAMS-R messages may temporarily overload the Retransmission Server. 1626 In these circumstances, the Retransmission Server may, for example, 1627 reject incoming RAMS requests until its resources become available 1628 again. One means to ameliorate this threat is to apply a per- 1629 endpoint policing mechanism on the incoming RAMS requests. A 1630 reasonable policing mechanism should consider application-specific 1631 requirements and minimize false negatives. 1633 In addition to the denial-of-service attacks, man-in-the-middle and 1634 replay attacks can also be harmful. However, RAMS itself does not 1635 bring any new risks or threats other than the ones discussed in 1636 [I-D.ietf-avt-rtcpssm]. 1638 [RFC4588] RECOMMENDS that the cryptography mechanisms are used for 1639 the retransmission payload format to provide protection against known 1640 plaintext attacks. As discussed in [RFC4588], the retransmission 1641 payload format sets the timestamp field in the RTP header to the 1642 media timestamp of the original packet and this does not compromise 1643 the confidentiality. Furthermore, if cryptography is used to provide 1644 security services on the original stream, then the same services, 1645 with equivalent cryptographic strength, MUST be provided on the 1646 retransmission stream per [RFC4588]. 1648 13. IANA Considerations 1650 The following contact information shall be used for all registrations 1651 in this document: 1653 Ali Begen 1654 abegen@cisco.com 1656 170 West Tasman Drive 1657 San Jose, CA 95134 USA 1659 Note to the RFC Editor: In the following, please replace "XXXX" with 1660 the number of this document prior to publication as an RFC. 1662 13.1. Registration of SDP Attributes 1664 This document registers a new attribute name in SDP. 1666 SDP Attribute ("att-field"): 1667 Attribute name: rams-updates 1668 Long form: Support for Updated RAMS Request Messages 1669 Type of name: att-field 1670 Type of attribute: Media level 1671 Subject to charset: No 1672 Purpose: See this document 1673 Reference: [RFCXXXX] 1674 Values: None 1676 13.2. Registration of SDP Attribute Values 1678 This document registers a new value for the 'nack' attribute to be 1679 used with the 'rtcp-fb' attribute in SDP. For more information about 1680 'rtcp-fb', refer to [RFC4585]. 1682 Value name: ssli 1683 Long name: Stream Synchronization Loss Indication 1684 Usable with: nack 1685 Reference: [RFCXXXX] 1687 13.3. Registration of FMT Values 1689 Within the RTPFB range, the following format (FMT) value is 1690 registered: 1692 Name: RAMS 1693 Long name: Rapid Acquisition of Multicast Sessions 1694 Value: 6 1695 Reference: [RFCXXXX] 1697 13.4. SFMT Values for RAMS Messages Registry 1699 This document creates a new sub-registry for the sub-feedback message 1700 type (SFMT) values to be used with the FMT value registered for RAMS 1701 messages. The registry is called the SFMT Values for RAMS Messages 1702 Registry. This registry is to be managed by the IANA according to 1703 the Specification Required policy of [RFC5226]. 1705 The length of the SFMT field in the RAMS messages is a single octet, 1706 allowing 256 values. The registry is initialized with the following 1707 entries: 1709 Value Name Reference 1710 ----- -------------------------------------------------- ------------- 1711 1 RAMS Request [RFCXXXX] 1712 2 RAMS Information [RFCXXXX] 1713 3 RAMS Termination [RFCXXXX] 1715 The SFMT values 0 and 255 are reserved for future use. 1717 Any registration for an unassigned SFMT value MUST contain the 1718 following information: 1720 o Contact information of the one doing the registration, including 1721 at least name, address, and email. 1723 o A detailed description of what the new SFMT represents and how it 1724 shall be interpreted. 1726 Note that new RAMS functionality should be introduced by using the 1727 extension mechanism within the existing RAMS message types not by 1728 introducing new message types unless it is absolutely necessary. 1730 13.5. RAMS TLV Space Registry 1732 This document creates a new IANA TLV space registry for the RAMS 1733 extensions. The registry is called the RAMS TLV Space Registry. 1734 This registry is to be managed by the IANA according to the 1735 Specification Required policy of [RFC5226]. 1737 The length of the Type field in the TLV elements is a single octet, 1738 allowing 256 values. The Type values 0 and 255 are reserved for 1739 future use. The Type values between (and including) 128 and 254 are 1740 reserved for private extensions. 1742 The registry is initialized with the following entries: 1744 Type Description Reference 1745 ---- -------------------------------------------------- ------------- 1746 1 Min RAMS Buffer Fill Requirement [RFCXXXX] 1747 2 Max RAMS Buffer Fill Requirement [RFCXXXX] 1748 3 Max Receive Bitrate [RFCXXXX] 1749 31 RTP Seqnum of the First Packet [RFCXXXX] 1750 32 Earliest Multicast Join Time [RFCXXXX] 1751 33 Burst Duration [RFCXXXX] 1752 34 Max Transmit Bitrate [RFCXXXX] 1753 61 Extended RTP Seqnum of First Multicast Packet [RFCXXXX] 1755 Any registration for an unassigned Type value MUST contain the 1756 following information: 1758 o Contact information of the one doing the registration, including 1759 at least name, address, and email. 1761 o A detailed description of what the new TLV element represents and 1762 how it shall be interpreted. 1764 13.6. RAMS Response Code Space Registry 1766 This document creates a new IANA TLV space registry for the RAMS 1767 response codes. The registry is called the RAMS Response Code Space 1768 Registry. This registry is to be managed by the IANA according to 1769 the Specification Required policy of [RFC5226]. 1771 The length of the Response field is two octets, allowing 65536 codes. 1772 However, the response codes have been classified and registered 1773 following an HTTP-style code numbering in this document. New 1774 response codes SHALL follow the guidelines below: 1776 Code Level Purpose 1777 ---------- --------------- 1778 1xx Informational 1779 2xx Success 1780 3xx Redirection 1781 4xx RTP Receiver Error 1782 5xx Retransmission Server Error 1784 The Response code 65536 is reserved for future use. 1786 The registry is initialized with the following entries: 1788 Code Description Reference 1789 ----- -------------------------------------------------- ------------- 1790 0 A private response code is included in the message [RFCXXXX] 1792 100 Parameter update for RAMS session [RFCXXXX] 1793 101 RAMS session was terminated by RAMS-T [RFCXXXX] 1794 102 RAMS session was terminated by RS [RFCXXXX] 1796 200 RAMS request has been accepted [RFCXXXX] 1797 201 Unicast burst has been completed [RFCXXXX] 1799 400 Invalid RAMS-R message syntax 1800 401 Invalid min buffer requirement in RAMS-R message [RFCXXXX] 1801 402 Invalid max buffer requirement in RAMS-R message [RFCXXXX] 1802 403 Invalid max bw requirement in RAMS-R message [RFCXXXX] 1804 500 An unspecified RS internal error has occurred [RFCXXXX] 1805 501 RS has no bandwidth to start RAMS session [RFCXXXX] 1806 502 RS has no CPU available to start RAMS session [RFCXXXX] 1807 503 RAMS functionality is not available on RS [RFCXXXX] 1808 504 RAMS functionality is not available for RR [RFCXXXX] 1809 505 RAMS functionality is not available for 1810 the requested multicast stream [RFCXXXX] 1811 506 RS has no a valid starting point available for 1812 the requested multicast stream [RFCXXXX] 1813 507 RS has no reference information available for 1814 the requested multicast stream [RFCXXXX] 1816 Any registration for an unassigned Response code MUST contain the 1817 following information: 1819 o Contact information of the one doing the registration, including 1820 at least name, address, and email. 1822 o A detailed description of what the new Response code describes and 1823 how it shall be interpreted. 1825 14. Acknowledgments 1827 The authors would like to specially thank Peilin Yang for his 1828 contributions to this document and detailed reviews. 1830 The authors also thank the following individuals for their 1831 contributions, comments and suggestions to this document: Dave Oran, 1832 Dan Wing, Tony Faustini, Jeff Goldberg, Muriel Deschanel, Orit Levin, 1833 Roni Even, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui Wang, Zixuan 1834 Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan Lennox and 1835 Sean Sheedy. 1837 15. Change Log 1839 15.1. draft-ietf-avt-rapid-acquisition-for-rtp-04 1841 The following are the major changes compared to version 02: 1843 o Clarifications for the definition of RS. 1845 o Response codes have been defined. 1847 15.2. draft-ietf-avt-rapid-acquisition-for-rtp-03 1849 The following are the major changes compared to version 02: 1851 o Clarifications for the RAMS-I message. 1853 o Type values have been assigned. 1855 15.3. draft-ietf-avt-rapid-acquisition-for-rtp-02 1857 The following are the major changes compared to version 01: 1859 o Port mapping discussion has been removed since it will be 1860 discussed in a separate draft. 1862 o Security considerations section has been added. 1864 o Burst shaping section has been completed. 1866 o Most of the outstanding open issues have been addressed. 1868 15.4. draft-ietf-avt-rapid-acquisition-for-rtp-01 1870 The following are the major changes compared to version 00: 1872 o Formal definitions of vendor-neutral and private extensions and 1873 their IANA registries have been added. 1875 o SDP examples were explained in more detail. 1877 o The sub-FMT field has been introduced in the RAMS messages for 1878 message type identification. 1880 o Some terminology has been fixed. 1882 o NAT considerations section has been added. 1884 15.5. draft-ietf-avt-rapid-acquisition-for-rtp-00 1886 This is a resubmission of version 03 as a WG item. 1888 15.6. draft-versteeg-avt-rapid-synchronization-for-rtp-03 1890 The following are the major changes compared to version 02: 1892 o The title and message names have been changed. 1894 o RTCP message semantics have been added. RAMS protocol has been 1895 revised to handle updated requests and responses. 1897 o Definitions have been revised. 1899 o RTP/RTCP muxing reference has been added. 1901 15.7. draft-versteeg-avt-rapid-synchronization-for-rtp-02 1903 The following are the major changes compared to version 01: 1905 o The discussion around MPEG2-TS has been moved to another document. 1907 o The RAMS-R, RAMS-I and RAMS-T messages have been extensively 1908 modified and they have been made mandatory. 1910 o IANA Considerations section has been updated. 1912 o The discussion of RTCP XR report has been moved to another 1913 document. 1915 o A new section on protocol design considerations has been added. 1917 15.8. draft-versteeg-avt-rapid-synchronization-for-rtp-01 1919 The following are the major changes compared to version 00: 1921 o The core of the rapid synchronization method is now payload- 1922 independent. But, the draft still defines payload-specific 1923 messages that are required for enabling rapid synch for the RTP 1924 flows carrying MPEG2-TS. 1926 o RTCP APP packets have been removed, new RTCP transport-layer and 1927 payload-specific feedback messages have been defined. 1929 o The step for leaving the current multicast session has been 1930 removed from Section 6.2. 1932 o A new RTCP XR (Multicast Join) report has been defined. 1934 o IANA Considerations section have been updated. 1936 o Editorial changes to clarify several points. 1938 16. References 1940 16.1. Normative References 1942 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1943 Jacobson, "RTP: A Transport Protocol for Real-Time 1944 Applications", STD 64, RFC 3550, July 2003. 1946 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1947 Requirement Levels", BCP 14, RFC 2119, March 1997. 1949 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1950 Thyagarajan, "Internet Group Management Protocol, Version 1951 3", RFC 3376, October 2002. 1953 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1954 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1956 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1957 Group Management Protocol Version 3 (IGMPv3) and Multicast 1958 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1959 Specific Multicast", RFC 4604, August 2006. 1961 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1962 Description Protocol", RFC 4566, July 2006. 1964 [I-D.ietf-mmusic-rfc3388bis] 1965 Camarillo, G., "The SDP (Session Description Protocol) 1966 Grouping Framework", draft-ietf-mmusic-rfc3388bis-03 (work 1967 in progress), July 2009. 1969 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1970 "Extended RTP Profile for Real-time Transport Control 1971 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1972 July 2006. 1974 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1975 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1976 July 2006. 1978 [I-D.ietf-avt-rtcpssm] 1979 Schooler, E., Ott, J., and J. Chesterfield, "RTCP 1980 Extensions for Single-Source Multicast Sessions with 1981 Unicast Feedback", draft-ietf-avt-rtcpssm-18 (work in 1982 progress), March 2009. 1984 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1985 Media Attributes in the Session Description Protocol 1986 (SDP)", RFC 5576, June 2009. 1988 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1989 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1991 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1992 with Session Description Protocol (SDP)", RFC 3264, 1993 June 2002. 1995 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 1996 Real-Time Transport Control Protocol (RTCP): Opportunities 1997 and Consequences", RFC 5506, April 2009. 1999 [I-D.begen-avt-ports-for-ucast-mcast-rtp] 2000 Begen, A. and B. Steeg, "Port Mapping Between Unicast and 2001 Multicast RTP Sessions", 2002 draft-begen-avt-ports-for-ucast-mcast-rtp-00 (work in 2003 progress), September 2009. 2005 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2006 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2007 May 2008. 2009 16.2. Informative References 2011 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2012 August 1980. 2014 [I-D.ietf-rmt-pi-norm-revised] 2015 Adamson, B., Bormann, C., Handley, M., and J. Macker, 2016 "NACK-Oriented Reliable Multicast Transport Protocol", 2017 draft-ietf-rmt-pi-norm-revised-14 (work in progress), 2018 September 2009. 2020 [I-D.begen-avt-rams-scenarios] 2021 Begen, A., "Considerations for RAMS Scenarios", 2022 draft-begen-avt-rams-scenarios-00 (work in progress), 2023 October 2009. 2025 [I-D.begen-avt-rtp-mpeg2ts-preamble] 2026 Begen, A. and E. Friedrich, "RTP Payload Format for 2027 MPEG2-TS Preamble", 2028 draft-begen-avt-rtp-mpeg2ts-preamble-02 (work in 2029 progress), August 2009. 2031 [I-D.begen-avt-rapid-sync-rtcp-xr] 2032 Begen, A. and E. Friedrich, "Multicast Acquisition Report 2033 Block Type for RTCP XR", 2034 draft-begen-avt-rapid-sync-rtcp-xr-02 (work in progress), 2035 August 2009. 2037 [I-D.ietf-avt-rapid-rtp-sync] 2038 Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 2039 Flows", draft-ietf-avt-rapid-rtp-sync-05 (work in 2040 progress), July 2009. 2042 [I-D.westerlund-avt-ecn-for-rtp] 2043 Westerlund, M., Johansson, I., Perkins, C., and K. 2044 Carlberg, "Explicit Congestion Notification (ECN) for RTP 2045 over UDP", draft-westerlund-avt-ecn-for-rtp-01 (work in 2046 progress), October 2009. 2048 [I-D.ietf-avt-rtp-and-rtcp-mux] 2049 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 2050 Control Packets on a Single Port", 2051 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 2052 August 2007. 2054 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 2055 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 2056 RFC 4787, January 2007. 2058 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 2059 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 2060 October 2008. 2062 [UPnP-IGD] 2063 Forum, UPnP., "Universal Plug and Play (UPnP) Internet 2064 Gateway Device (IGD)", November 2001. 2066 [DLNA] , DLNA., "http://www.dlna.org/home". 2068 [CCNC09] Begen, A., Glazebrook, N., and W. VerSteeg, "A Unified 2069 Approach for Repairing Packet Loss and Accelerating 2070 Channel Changes in Multicast IPTV (IEEE CCNC)", 2071 January 2009. 2073 [IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing 2074 Channel Change Times in IPTV with Real-Time Transport 2075 Protocol (IEEE Internet Computing)", May 2009. 2077 Authors' Addresses 2079 Bill VerSteeg 2080 Cisco Systems 2081 5030 Sugarloaf Parkway 2082 Lawrenceville, GA 30044 2083 USA 2085 Email: billvs@cisco.com 2087 Ali Begen 2088 Cisco Systems 2089 170 West Tasman Drive 2090 San Jose, CA 95134 2091 USA 2093 Email: abegen@cisco.com 2094 Tom VanCaenegem 2095 Alcatel-Lucent 2096 Copernicuslaan 50 2097 Antwerpen, 2018 2098 Belgium 2100 Email: Tom.Van_Caenegem@alcatel-lucent.be 2102 Zeev Vax 2103 Microsoft Corporation 2104 1065 La Avenida 2105 Mountain View, CA 94043 2106 USA 2108 Email: zeevvax@microsoft.com