idnits 2.17.1 draft-ietf-avt-rapid-acquisition-for-rtp-02.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 (August 25, 2009) is 5348 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) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 3388 (Obsoleted by RFC 5888) == Outdated reference: A later version (-19) exists of draft-ietf-avt-rtcpssm-18 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-14) exists of draft-ietf-rmt-pi-norm-revised-13 == 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-00 -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 4 errors (**), 0 flaws (~~), 8 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: February 26, 2010 T. VanCaenegem 6 Alcatel-Lucent 7 Z. Vax 8 Microsoft Corporation 9 August 25, 2009 11 Unicast-Based Rapid Acquisition of Multicast RTP Sessions 12 draft-ietf-avt-rapid-acquisition-for-rtp-02 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 February 26, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 85 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6 86 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 87 4. Elements of Delay in Multicast Applications . . . . . . . . . 7 88 5. Protocol Design Considerations and Their Effect on 89 Resource Management for Rapid Acquisition . . . . . . . . . . 9 90 6. Rapid Acquisition of Multicast RTP Sessions . . . . . . . . . 11 91 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11 92 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 12 93 6.3. Shaping the Unicast Burst . . . . . . . . . . . . . . . . 20 94 6.4. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 22 95 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 23 96 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 23 97 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 24 98 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 24 99 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 25 100 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 27 101 7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 29 102 8. SDP Definitions and Examples . . . . . . . . . . . . . . . . . 30 103 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 30 104 8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 30 105 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 33 106 10. Known Implementations . . . . . . . . . . . . . . . . . . . . 34 107 10.1. Open Source RTP Receiver Implementation by Cisco . . . . . 34 108 10.2. IPTV Commercial Implementation by Microsoft . . . . . . . 35 109 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35 110 12. Security Considerations . . . . . . . . . . . . . . . . . . . 35 111 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 112 13.1. Registration of SDP Attributes . . . . . . . . . . . . . . 37 113 13.2. Registration of SDP Attribute Values . . . . . . . . . . . 37 114 13.3. Registration of FMT Values . . . . . . . . . . . . . . . . 37 115 13.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 38 116 13.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 38 117 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39 118 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 39 119 15.1. draft-ietf-avt-rapid-acquisition-for-rtp-02 . . . . . . . 39 120 15.2. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 40 121 15.3. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 40 122 15.4. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 40 123 15.5. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 40 124 15.6. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 41 125 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 126 16.1. Normative References . . . . . . . . . . . . . . . . . . . 41 127 16.2. Informative References . . . . . . . . . . . . . . . . . . 43 128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 130 1. Introduction 132 Most multicast flows carry a stream of inter-related data. Certain 133 information must first be acquired by the receivers to start 134 processing any data sent in the multicast session. This document 135 refers to this information as Reference Information. The Reference 136 Information is conventionally sent periodically in the multicast 137 session and usually consists of items such as a description of the 138 schema for the rest of the data, references to which data to process, 139 encryption information including keys, as well as any other 140 information required to process the data in the primary multicast 141 stream. 143 Real-time multicast applications require the receivers to buffer 144 data. The receiver may have to buffer data to smooth out the network 145 jitter, to allow loss-repair methods such as Forward Error Correction 146 and retransmission to recover the missing packets, and to satisfy the 147 data processing requirements of the application layer. 149 When a receiver joins a multicast session, it has no control over 150 what point in the flow is currently being transmitted. Sometimes the 151 receiver may join the session right before the Reference Information 152 is sent in the session. In this case, the required waiting time is 153 usually minimal. Other times, the receiver may join the session 154 right after the Reference Information has been transmitted. In this 155 case, the receiver has to wait for the Reference Information to 156 appear again in the flow before it can start processing any multicast 157 data. In some other cases, the Reference Information is not 158 contiguous in the flow but dispersed over a large period, which 159 forces the receiver to wait for all of the Reference Information to 160 arrive before starting to process the rest of the data. 162 The net effect of waiting for the Reference Information and waiting 163 for various buffers to fill up is that the receivers may experience 164 significantly large delays in data processing. In this document, we 165 refer to the difference between the time an RTP receiver joins the 166 multicast session and the time the RTP receiver acquires all the 167 necessary Reference Information as the Acquisition Delay. The 168 acquisition delay may not be the same for different receivers; it 169 usually varies depending on the join time, length of the Reference 170 Information repetition interval, size of the Reference Information as 171 well as the application and transport properties. 173 The varying nature of the acquisition delay adversely affects the 174 receivers that frequently switch among multicast sessions. In this 175 specification, we address this problem for RTP-based multicast 176 applications and describe a method that uses the fundamental tools 177 offered by the existing RTP and RTCP protocols [RFC3550]. In this 178 method, either the multicast source (or the distribution source in a 179 single-source multicast (SSM) session) retains the Reference 180 Information for a period after its transmission, or an intermediary 181 network element (that we refer to as Retransmission Server) joins the 182 multicast session and continuously caches the Reference Information 183 as it is sent in the session and acts as a feedback target (See 184 [I-D.ietf-avt-rtcpssm]) for the session. When an RTP receiver wishes 185 to join the same multicast session, instead of simply issuing a 186 Source Filtering Group Management Protocol (SFGMP) Join message, it 187 sends a request to the feedback target for the session asking for the 188 Reference Information. The Retransmission Server starts a unicast 189 retransmission RTP session and sends the Reference Information to the 190 RTP receiver over that session. If there is spare bandwidth, the 191 Retransmission Server may also burst the Reference Information at a 192 faster than its natural rate. As soon as the receiver acquires the 193 Reference Information, it can join the multicast session and start 194 processing the multicast data. This method potentially reduces the 195 acquisition delay. We refer to this method as Unicast-based Rapid 196 Acquisition of Multicast RTP Sessions. A simplified network diagram 197 showing this method through an intermediary network element is 198 depicted in Figure 1. 200 +-----------------------+ 201 +--->| Intermediary | 202 | ...| Network Element | 203 | : |(Retransmission Server)| 204 | : +-----------------------+ 205 | : 206 | v 207 +-----------+ +----------+ +----------+ 208 | Multicast | | Router |---------->| Joining | 209 | Source |------->| |..........>| RTP | 210 +-----------+ +----------+ | Receiver | 211 | +----------+ 212 | 213 | +----------+ 214 +---------------->| Existing | 215 | RTP | 216 | Receiver | 217 +----------+ 219 ...> Unicast RTP Flow 220 ---> Multicast RTP Flow 222 Figure 1: Rapid acquisition through an intermediary network element 224 A primary design goal in this solution is to use the existing tools 225 in the RTP/RTCP protocol family. This improves the versatility of 226 the existing implementations, and promotes faster deployment and 227 better interoperability. To this effect, we use the unicast 228 retransmission support of RTP [RFC4588] and the capabilities of RTCP 229 to handle the signaling needed to accomplish the acquisition. The 230 packet(s) carrying the Reference Information are sent by the 231 Retransmission Server in the auxiliary unicast RTP session for rapid 232 acquisition. These are constructed as retransmission packets that 233 would have been sent in a unicast RTP session to recover the missing 234 packets at an RTP receiver that has never received any packet. In 235 fact, a single RTP session SHOULD be used for both rapid acquisition 236 and retransmission-based loss repair. This session can be used to 237 simultaneously provide the unicast burst for the rapid acquisition 238 and the repair packets requested by the RTP receivers when they 239 detect lost burst packets or lost RTP packets in the primary 240 multicast stream. The conventional RTCP feedback (NACK) message that 241 requests the retransmission of the missing packets [RFC4585] 242 indicates their sequence numbers. However, upon joining a new 243 session the RTP receiver has never received a packet, and thus, does 244 not know the sequence numbers. Instead, the RTP receiver sends a 245 newly defined RTCP feedback message to request the Reference 246 Information needed to rapidly get on the track with the primary 247 multicast session. It is also worth noting that in order to issue 248 the initial RTCP message to the feedback target, the SSRC of the 249 session to be joined must be known prior to any packet reception, and 250 hence, needs to be signaled out-of-band (or otherwise communicated to 251 the RTP receiver in advance of the initiation of the rapid 252 acquisition operation). In a Session Description Protocol (SDP) 253 description, the SSRC MUST be signaled through the 'ssrc' attribute 254 [I-D.ietf-avt-rtcpssm]. 256 In the rest of this specification, we have the following outline: In 257 Section 4, we describe the delay components in generic multicast 258 applications. Section 5 presents an overview of the protocol design 259 considerations for rapid acquisition. We provide the protocol 260 details of the rapid acquisition method in Section 6 and Section 7. 261 Section 8 and Section 9 discuss the SDP signaling issues with 262 examples and NAT-related issues, respectively. 264 Note that Section 3 provides a list of the definitions frequently 265 used in this document. 267 2. Requirements Notation 269 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 270 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 271 document are to be interpreted as described in [RFC2119]. 273 3. Definitions 275 This document uses the following acronyms and definitions frequently: 277 Primary Multicast Session: The multicast RTP session to which RTP 278 receivers can join at a random point in time. 280 Primary Multicast Stream: The RTP stream carried in the primary 281 multicast session. 283 Source Filtering Group Management Protocol (SFGMP): Following the 284 definition in [RFC4604], SFGMP refers to the Internet Group 285 Management Protocol (IGMP) version 3 [RFC3376] and the Multicast 286 Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and 287 IPv6 networks, respectively. However, the rapid acquisition method 288 introduced in this document does not depend on a specific version of 289 either of these group management protocols. In the remainder of this 290 document, SFGMP will refer to any group management protocol that has 291 Join and Leave functionalities. 293 Feedback Target: (Unicast RTCP) Feedback target as defined in 294 [I-D.ietf-avt-rtcpssm]. 296 Retransmission Packet: An RTP packet that is formatted as defined in 297 [RFC4588]. 299 Reference Information: The set of certain media content and metadata 300 information that is sufficient for an RTP receiver to start usefully 301 consuming a media stream. The meaning, format and size of this 302 information are specific to the application and are out of scope of 303 this document. 305 (Unicast) Burst (Stream): A unicast stream of RTP retransmission 306 packets that enable an RTP receiver to rapidly acquire the Reference 307 Information. The burst stream is typically transmitted at an 308 accelerated rate. 310 Retransmission Server (RS): The RTP/RTCP endpoint that can generate 311 the retransmission packets and the burst stream. 313 4. Elements of Delay in Multicast Applications 315 In an any-source (ASM) or a single-source (SSM) multicast delivery 316 system, there are three major elements that contribute to the overall 317 acquisition delay when an RTP receiver switches from one multicast 318 session to another one. These are: 320 o Multicast switching delay 322 o Reference Information latency 324 o Buffering delays 326 Multicast switching delay is the delay that is experienced to leave 327 the current multicast session (if any) and join the new multicast 328 session. In typical systems, the multicast join and leave operations 329 are handled by a group management protocol. For example, the 330 receivers and routers participating in a multicast session may use 331 the Internet Group Management Protocol (IGMP) version 3 [RFC3376] or 332 the Multicast Listener Discovery Protocol (MLD) version 2 [RFC3810]. 333 In either of these protocols, when a receiver wants to join a 334 multicast session, it sends a message to its upstream router and the 335 routing infrastructure sets up the multicast forwarding state to 336 deliver the packets of the multicast session to the new receiver. 337 Depending on the proximity of the upstream router, the current state 338 of the multicast tree, the load on the system and the protocol 339 implementation, the join times vary. Current systems provide join 340 latencies usually less than 200 milliseconds (ms). If the receiver 341 had been participating in another multicast session before joining 342 the new session, it needs to send a Leave message to its upstream 343 router to leave the session. In common multicast routing protocols, 344 the leave times are usually smaller than the join times, however, it 345 is possible that the Leave and Join messages may get lost, in which 346 case the multicast switching delay inevitably increases. 348 Reference Information latency is the time it takes the receiver to 349 acquire the Reference Information. It is highly dependent on the 350 proximity of the actual time the receiver joined the session to the 351 next time the Reference Information will be sent to the receivers in 352 the session, whether the Reference Information is sent contiguously 353 or not, and the size of the Reference Information. For some 354 multicast flows, there is a little or no interdependency in the data, 355 in which case the Reference Information latency will be nil or 356 negligible. For other multicast flows, there is a high degree of 357 interdependency. One example of interest is the multicast flows that 358 carry compressed audio/video. For these flows, the Reference 359 Information latency may become quite large and be a major contributor 360 to the overall delay. Refer to [I-D.begen-avt-rtp-mpeg2ts-preamble] 361 for details. 363 The buffering component of the overall acquisition delay is driven by 364 the way the application layer processes the payload. In many 365 multicast applications, an unreliable transport protocol such as UDP 366 [RFC0768] is often used to transmit the data packets, and the 367 reliability, if needed, is usually addressed through other means such 368 as Forward Error Correction and retransmission 369 [I-D.ietf-rmt-pi-norm-revised]. These loss-repair methods require 370 buffering at the receiver side to function properly. In many 371 applications, it is also often necessary to de-jitter the incoming 372 data packets before feeding them to the application. The de- 373 jittering process also increases the buffering delays. Besides these 374 network-related buffering delays, there are also specific buffering 375 needs that are required by the individual applications. For example, 376 standard video decoders typically require an amount, sometimes a 377 significant amount, of coded video data to be available in the pre- 378 decoding buffers prior to starting to decode the video bitstream. 380 5. Protocol Design Considerations and Their Effect on Resource 381 Management for Rapid Acquisition 383 Rapid acquisition is an optimization of a system that must continue 384 to work correctly whether or not the optimization is effective, or 385 even fails due to lost control messages, congestion, or other 386 problems. This is fundamental to the overall design requirements 387 surrounding the protocol definition and to the resource management 388 schemes to be employed together with the protocol (e.g., QoS 389 machinery, server load management, etc). In particular, the system 390 needs to operate within a number of constraints: 392 o First, a rapid acquisition operation must fail gracefully. The 393 user experience must, except perhaps in pathological 394 circumstances, be not significantly worse for trying and failing 395 to complete rapid acquisition compared to simply joining the 396 multicast session. 398 o Second, providing the rapid acquisition optimizations must not 399 cause collateral damage to either the multicast session being 400 joined, or other multicast sessions sharing resources with the 401 rapid acquisition operation. In particular, the rapid acquisition 402 operation must avoid self-interference with the multicast session 403 that may be simultaneously being received by other hosts. In 404 addition, it must also avoid interference with other multicast 405 sessions sharing the same network resources. These properties are 406 possible, but are usually difficult to achieve. 408 One challenge is the existence of multiple bandwidth bottlenecks 409 between the receiver and the server(s) in the network providing the 410 rapid acquisition service. In commercial IPTV deployments, for 411 example, bottlenecks are often present in the aggregation network 412 connecting the IPTV servers to the network edge, the access links 413 (e.g., DSL, DOCSIS) and in the home network of the subscribers. Some 414 of these links may serve only a single subscriber, limiting 415 congestion impact to the traffic of only that subscriber, but others 416 can be shared links carrying multicast sessions of many subscribers. 417 Also note that the state of these links may be varying over time. 418 The receiver may have knowledge of a portion of this network, or may 419 have partial knowledge of the entire network. The methods employed 420 by the devices to acquire this network state information is out of 421 scope for this document. The receiver should be able to signal the 422 server with the bandwidth that it believes it can handle. The server 423 also needs to be able to rate limit the flow in order to stay within 424 the performance envelope that it knows about. Both the server and 425 receiver need to be able to inform the other of changes in the 426 requested and delivered rates. However, the protocol must be robust 427 in the presence of packet loss, so this signaling must include the 428 appropriate default behaviors. 430 A second challenge is that for some uses (e.g., high-bitrate video) 431 the unicast burst bitrate is high while the flow duration of the 432 unicast burst is short. This is because the purpose of the unicast 433 burst is to allow the RTP receiver to join the multicast quickly and 434 thereby limit the overall resources consumed by the burst. Such 435 high-bitrate, short-duration flows are not amenable to conventional 436 admission control techniques. For example, end-to-end per-flow 437 signaled admission control techniques such as RSVP have too much 438 latency and control channel overhead to be a good fit for rapid 439 acquisition. Similarly, using a TCP (or TCP-like) approach with a 440 3-way handshake and slow-start to avoid inducing congestion would 441 defeat the purpose of attempting rapid acquisition in the first place 442 by introducing many RTTs of delay. 444 These observations lead to certain unavoidable requirements and goals 445 for a rapid acquisition protocol. These are: 447 o The protocol must be designed to allow a deterministic upper bound 448 on the extra bandwidth used (compared to just joining the 449 multicast session). A reasonable size bound is e*B, where B is 450 the "nominal" bandwidth of the primary multicast stream, and e is 451 an "excess-bandwidth" coefficient The total duration of the 452 unicast burst must have a reasonable bound; long unicast bursts 453 devolve to the bandwidth profile of multi-unicast for the whole 454 system. 456 o The scheme should minimize (or better eliminate) the overlap of 457 the unicast burst and the primary multicast stream. This 458 minimizes the window during which congestion could be induced on a 459 bottleneck link compared to just carrying the multicast or unicast 460 packets alone. 462 o The scheme must minimize (or better eliminate) any gap between the 463 unicast burst and the primary multicast stream, which has to be 464 repaired later, or in the absence of repair, will result in loss 465 being experienced by the application. 467 In addition to the above, there are some other protocol design issues 468 to be considered. First, there is at least one RTT of "slop" in the 469 control loop. In starting a rapid acquisition burst, this manifests 470 as the time between the client requesting the unicast burst and the 471 burst description and/or the first unicast burst packets arriving at 472 the receiver. For managing and terminating the unicast burst, there 473 are two possible approaches for the control loop: The receiver can 474 adapt to the unicast burst as received, converge based on observation 475 and explicitly terminate the unicast burst with a second control loop 476 exchange (which takes a minimum of one RTT, just as starting the 477 unicast burst does). Alternatively, the server generating the 478 unicast burst can pre-compute the burst parameters based on the 479 information in the initial request and tell the receiver the burst 480 duration. 482 The protocol described in the next section allows either method of 483 controlling the rapid acquisition unicast burst. 485 6. Rapid Acquisition of Multicast RTP Sessions 487 We start this section with an overview of the rapid acquisition of 488 multicast sessions (RAMS) method. 490 6.1. Overview 492 [I-D.ietf-avt-rtcpssm] specifies an extension to the RTP Control 493 Protocol (RTCP) to use unicast feedback in an SSM session. It 494 defines an architecture that introduces the concept of Distribution 495 Source, which - in an SSM context - distributes the RTP data and 496 redistributes RTCP information to all RTP receivers. This RTCP 497 information is retrieved from the Feedback Target, to which RTCP 498 unicast feedback traffic is sent. The Feedback Target MAY be 499 implemented in one or more entities different from the Distribution 500 Source, and different RTP receivers MAY use different Feedback 501 Targets. 503 This document builds further on these concepts to reduce the 504 acquisition time when an RTP receiver joins a multicast session at a 505 random point in time by introducing the concept of the Burst Source 506 and new RTCP feedback messages. The Burst Source has a cache where 507 the most recent packets from the primary multicast session are 508 continuously stored. When an RTP receiver wants to receive the 509 primary multicast stream, prior to joining the SSM session, it may 510 first request a unicast burst from the Burst Source. In this burst, 511 the packets are formatted as RTP retransmission packets [RFC4588] and 512 carry the Reference Information. This information allows the RTP 513 receiver to start usefully consuming the RTP packets sent in the 514 primary multicast session. 516 Using an accelerated rate (as compared to the rate of the primary 517 multicast stream) for the unicast burst implies that at a certain 518 point in time, the payload transmitted in the unicast burst is going 519 to be the same as the payload multicast in the SSM session, i.e., the 520 unicast burst will catch up with the primary multicast stream. At 521 this point, the RTP receiver no longer needs to receive the unicast 522 burst and can join the primary multicast session. This method is 523 referred to as the Rapid Acquisition of Multicast Sessions (RAMS). 525 This document proposes extensions to [RFC4585] for an RTP receiver to 526 request a unicast burst as well as for additional control messaging 527 that can be leveraged during the acquisition process. 529 6.2. Message Flows 531 Figure 2 shows the main entities involved in rapid acquisition: 533 o Multicast Source 535 o Feedback Target (FT) 537 o Burst/Retransmission Source 539 o RTP Receiver (RR) 540 +----------------------------------------------+ 541 | Retransmission Server | 542 | (RS) | 543 | +----------+ +---------------------------+ | 544 | | Feedback | | Burst/Retransmission | | 545 | | Target | | Source | | 546 | +----------+ +---------------------------+ | 547 +----------------------------------------------+ 548 ^ ^ : 549 | ' : 550 | ' : 551 | ' v 552 +-----------+ +----------+ +----------+ 553 | | | |'''''''''''>| | 554 | Multicast |------->| Router |...........>| RTP | 555 | Source | | |<~~~~~~~~~~~| Receiver | 556 | | | |----------->| (RR) | 557 +-----------+ +----------+ +----------+ 559 '''> Unicast RTCP Messages 560 ~~~> SFGMP Messages 561 ...> Unicast RTP Flow 562 ---> Multicast RTP Flow 564 Figure 2: Flow diagram for unicast-based rapid acquisition 566 The feedback target (FT) is the entity as defined in 567 [I-D.ietf-avt-rtcpssm], to which RR sends its RTCP feedback messages 568 indicating packet loss in the primary multicast stream by means of an 569 RTCP NACK message or indicating RR's desire to rapidly acquire the 570 primary multicast stream by means of an RTCP feedback message defined 571 in this document. While the Burst/Retransmission Source is 572 responsible for responding to these messages and for further RTCP 573 interaction with RR in the case of a rapid acquisition process, it is 574 assumed in the remainder of the document that these two logical 575 entities (FT and Burst/Retransmission Source) are combined in a 576 single physical entity and they share state. In the remainder of the 577 text, the term Retransmission Server will be used whenever 578 appropriate, to refer to the combined functionality of the FT and 579 Burst/Retransmission Source. 581 However, it must be noted that only FT is involved in the primary 582 multicast session, whereas the Burst/Retransmission Source transmits 583 the unicast burst and retransmission packets both formatted as RTP 584 retransmission packets [RFC4588] in a single separate unicast RTP 585 retransmission session to each RR. In the retransmission session, as 586 in any other RTP session, RS and RR regularly send the periodic 587 sender and receiver reports, respectively. 589 Note also that the same method (with the identical message flows) 590 would also apply in a scenario where rapid acquisition is performed 591 by a feedback target co-located with the media source. 593 The unicast burst is triggered by an RTCP feedback message that is 594 defined in this document, whereas an RTP retransmission is triggered 595 by an RTCP NACK message defined in [RFC4585]. Based on its design, 596 in an RAMS implementation, there may be a gap between the end of the 597 burst and the reception of the primary multicast stream because of 598 the imperfections in the switch-over. If needed, RR may make use of 599 the RTCP NACK message to request a retransmission for the missing 600 packets in the gap. 602 Figure 3 depicts an example of messaging flow for rapid acquisition. 603 The RTCP feedback messages are explained below. Note that the 604 messages indicated in parentheses may or may not be present during 605 rapid acquisition. 607 +-----------+ +----------------+ +----------+ +------------+ 608 | Multicast | | Retransmission | | | | RTP | 609 | Source | | Server | | Router | | Receiver | 610 | | | (RS) | | | | (RR) | 611 +-----------+ +----------------+ +----------+ +------------+ 612 | | | | 613 |-- RTP Multicast ------------------->| | 614 | | | | 615 |-- RTP Multicast ->| | | 616 | | | | 617 | |<'''''''''''''''''' RTCP RAMS-R ''| 618 | | | | 619 | | | | 620 | |'' (RTCP RAMS-I) ''''''''''''''''>| 621 | | | | 622 | | | | 623 | |.. Unicast RTP Burst ............>| 624 | | | | 625 | |<''''''''''''''''''(RTCP RAMS-R)''| 626 | | | | 627 | | | | 628 | |'' (RTCP RAMS-I) ''''''''''''''''>| 629 | | | | 630 | | | | 631 | | |<~ SFGMP Join ~~| 632 | | | | 633 | | | | 634 |-- RTP Multicast ------------------------------------>| 635 | | | | 636 | | | | 637 | |<'''''''''''''''''' RTCP RAMS-T ''| 638 | | | | 639 | | | | 640 | |<''''''''''''''''''' (RTCP NACK)''| 641 | | | | 642 | | | | 643 | |.. (Unicast Retransmissions) ....>| 644 | | | | 645 | | | | 646 | |<''''''''''''''''''' (RTCP BYE) ''| 647 | | | | 648 | | | | 650 '''> Unicast RTCP Messages 651 ~~~> SFGMP Messages 652 ...> Unicast RTP Flow 653 ---> Multicast RTP Flow 654 Figure 3: Message flows for unicast-based rapid acquisition 656 This document defines the expected behaviors of RS and RR. It is 657 instructive to have independently operating implementations on RS and 658 RR that request the burst, describe the burst, start the burst, join 659 the multicast session and stop the burst. These implementations send 660 messages to each other, but there MUST be provisions for the cases 661 where the control messages get lost, or re-ordered, or are not being 662 delivered to their destinations. 664 The following steps describe rapid acquisition in detail: 666 1. Request: RR sends a rapid acquisition request for the new 667 multicast RTP session to the feedback target address of that 668 session. The request contains the SSRC of RR and the SSRC of the 669 media source. This RTCP feedback message is defined as the RAMS- 670 Request (RAMS-R) message and MAY contain parameters, which may 671 constrain the burst, such as the bandwidth limit. Other 672 parameters may be related to the amount of buffering capacity 673 available at RR, which may be used by RS to prepare a burst that 674 conforms with RR's requirements. 676 Before joining the primary multicast session, a new joining RR 677 learns the addresses associated with the new multicast session 678 (addresses for the multicast source, group and retransmission 679 server) by out-of-band means. Also note that since no RTP 680 packets have been received yet for this session, the SSRC must be 681 obtained out-of-band. See Section 8 for details. 683 2. Response: RS receives the RAMS-R message and decides whether to 684 accept it or not. RS MUST send an (at least one) RAMS- 685 Information (RAMS-I) message to RR. The first RAMS-I message MAY 686 precede the unicast burst or it MAY be sent during the burst. 687 Additional RAMS-I messages MAY be sent during the burst and these 688 RAMS-I messages may or may not be a direct response to an RAMS-R 689 message. The RAMS-I message is sent by the Burst/Retransmission 690 Source logical entity that is part of RS. 692 Note that RS learns the IP address information for RR from the 693 RAMS-R message it received. (This description glosses over the 694 NAT details. Refer to Section 9 for a discussion of NAT-related 695 issues.) 697 If RS cannot provide a rapid acquisition service, RS rejects the 698 request and informs RR immediately via an RAMS-I message. If RR 699 receives a message indicating that its rapid acquisition request 700 has been denied, it abandons the rapid acquisition attempt and 701 MAY immediately join the multicast session by sending an SFGMP 702 Join message towards its upstream multicast router for the new 703 primary multicast session. 705 If RS accepts the request, it sends an RAMS-I message to RR 706 (before commencing the unicast burst or during the unicast burst) 707 that comprises fields that can be used to describe the unicast 708 burst (e.g., the maximum bitrate and the duration of the unicast 709 burst). A particularly important, thus mandatory, field in the 710 RAMS-I message carries the RTP sequence number of the first burst 711 packet. 713 It is RECOMMENDED to include a sender report with the RAMS-I 714 message in the same compound RTCP packet. This also allows rapid 715 synchronization among multiple RTP flows 716 [I-D.ietf-avt-rapid-rtp-sync]. 718 The unicast burst duration MAY be calculated by RS, and its value 719 MAY be updated by messages received from RR. The join time 720 information (for the new multicast session) SHOULD be populated 721 in at least one of the RAMS-I messages. Note that RS MAY send 722 the RAMS-I message after a significant delay, so RR SHOULD NOT 723 make protocol dependencies on quickly receiving an RAMS-I 724 message. 726 3. Unicast Burst: If the request is accepted, RS starts sending the 727 unicast burst that comprises one or more RTP retransmission 728 packets (The burst packet(s) are sent by the Burst/Retransmission 729 Source logical entity). In addition, there MAY be optional 730 payload-specific information that RS chooses to send to RR. Such 731 an example is discussed in [I-D.begen-avt-rtp-mpeg2ts-preamble] 732 for transmitting the payload-specific information for MPEG2 733 Transport Streams. 735 4. Updated Request: RR MAY send a new RAMS-R message (to the FT 736 entity of RS) with a different value for one or more fields of an 737 earlier RAMS-R message. Upon receiving an updated request, RS 738 MAY use the updated values for sending/shaping the burst, or 739 refine the values and use the refined values for sending/shaping 740 the burst. 742 RS MAY send a new RAMS-I message to indicate the changes it made. 743 However, note that RS does not have to send a new RAMS-I, or the 744 new RAMS-I message may get lost. It is also possible that the 745 updated RAMS-R message could have been lost. Thus, RR SHOULD NOT 746 make protocol dependencies on quickly (or ever) receiving a new 747 RAMS-I message, or assume that RS will honor the requested 748 changes. 750 RR may be in an environment where the available resources are 751 time-varying, which may or may not deserve sending a new updated 752 request. Determining the circumstances where RR should or should 753 not send an updated request and the methods that RR can use to 754 detect and evaluate the time-varying available resources are not 755 specified in this document. 757 5. Updated Response: RS may send more than one RAMS-I messages, 758 e.g., to update the value of one or more fields in an earlier 759 RAMS-I message and/or to signal RR in real time to join the 760 primary multicast session. RR usually depends on RS to learn the 761 join time, which can be conveyed by the first RAMS-I message, or 762 can be sent/revised in a later RAMS-I message. If RS is not 763 capable of determining the join time in the first RAMS-I message, 764 it MUST send another RAMS-I message (with the join time 765 information) later. 767 6. Multicast Join Signaling: In principal, RR can join the primary 768 multicast session any time during or after the end of the unicast 769 burst via an SFGMP Join message. However, there may be missing 770 packets if RR joins the primary multicast session too early or 771 too late. For example, if RR starts receiving the primary 772 multicast stream while it is still receiving the unicast burst at 773 a high excess bitrate, this may result in an increased risk of 774 packet loss. Or, if RR joins the primary multicast session some 775 time after the unicast burst is finished, there may be a gap 776 between the burst and multicast data (a number of RTP packets may 777 be missing). In both cases, RR MAY issue retransmissions 778 requests (via RTCP NACK messages) [RFC4585] to fill the gap. 780 Yet, there are cases where the remaining available bandwidth may 781 limit the number of retransmissions that can be provided within a 782 certain time period, causing the retransmission data to arrive 783 too late at RR (from an application-layer point of view). To 784 cope with such cases, the RAMS-I message allows RS to signal 785 explicitly when RR should send the SFGMP Join message. 786 Alternatively, RS may pre-compute the burst duration and the time 787 RR should send the SFGMP Join message. This information may be 788 conveyed in the RAMS-I message and can be updated in a subsequent 789 RAMS-I message. While RR MAY use a locally calculated join time, 790 it SHOULD use the information from the most recent RAMS-I 791 message. 793 7. Multicast Receive: After the join, RR starts receiving the 794 primary multicast stream. 796 8. Terminate: RS may know when it needs to stop the unicast burst 797 based on the burst parameters, or RR MAY explicitly let RS know 798 the sequence number of the first RTP packet it received from the 799 multicast session, or RR MAY request RS to terminate the burst 800 immediately. 802 Regardless of whether or not RS knows when it needs to stop the 803 burst, RR SHALL use the RAMS-Termination (RAMS-T) message at an 804 appropriate time. RR can choose to send the RAMS-T message 805 before or after it starts receiving the multicast data. In the 806 latter case, RR SHALL include the sequence number of the first 807 RTP packet received in the primary multicast session in the 808 RAMS-T message, and RS SHOULD terminate the burst after it sends 809 the unicast burst packet whose Original Sequence Number (OSN) 810 field in the RTP retransmission payload header matches this 811 number minus one. 813 If RR wants to stop the burst prior to receiving the multicast 814 data, it sends an RAMS-T message without an RTP sequence number. 816 RR MUST send at least one RAMS-T message (if an RTCP BYE message 817 has not been issued yet as described in Step 9), and the RAMS-T 818 message MUST be addressed to the RTCP port of the retransmission 819 session. Against the possibility of a message loss, RR MAY 820 repeat the RAMS-T message multiple times as long as it follows 821 the RTCP timer rules defined in [RFC4585]. 823 9. Terminate with RTCP BYE: When RR is receiving the burst, if RR 824 becomes no longer interested in the primary multicast stream, RR 825 SHALL issue an RTCP BYE message for the RTP retransmission 826 session and another RTCP BYE message for the primary multicast 827 session. 829 Upon receiving an RTCP BYE message, RS MUST terminate the rapid 830 acquisition operation, and cease transmitting any further regular 831 retransmission packets as well as retransmission packets 832 associated with the unicast burst. If support for [RFC5506] has 833 been signaled, the RTCP BYE message MAY be sent in a reduced-size 834 RTCP packet. Otherwise, Section 6.1 of [RFC3550] mandates the 835 RTCP BYE message always to be sent with a sender or receiver 836 report in a compound RTCP packet (If no data has been received, 837 an empty receiver report MUST be included). With the information 838 contained in the receiver report, RS can also figure out how many 839 duplicate RTP packets have been delivered to RR (Note that this 840 will be an upper-bound estimate as one or more packets might have 841 been lost during the burst transmission). The impact of 842 duplicate packets and measures that can be taken to minimize the 843 impact of receiving duplicate packets will be addressed in 844 Section 6.3. 846 Note that an RTCP BYE message issued for the RTP retransmission 847 session terminates the whole session and ceases transmitting any 848 further packets in that RTP session. Thus, in this case there is 849 no need for sending an (explicit) RAMS-T message, which would 850 only terminate the burst. 852 Note that for the purpose of gathering detailed information about 853 RR's rapid acquisition experience, [I-D.begen-avt-rapid-sync-rtcp-xr] 854 defines an RTCP Extended Report (XR) Block. This report is designed 855 to be payload-independent, thus, it can be used by any multicast 856 application that supports rapid acquisition. Support for this XR 857 report is, however, optional. 859 6.3. Shaping the Unicast Burst 861 This section provides informative guidelines about how RS can shape 862 the transmission of the unicast burst. 864 A higher bitrate for the unicast burst naturally conveys the 865 Reference Information and media content to RR faster. This way, RR 866 can start consuming the data sooner, which results in a faster 867 acquisition. 869 A higher rate also represents a better utilization of RS resources. 870 As the burst may continue until it catches up with the primary 871 multicast stream, the higher the bursting rate, the less data RS 872 needs to transmit. However, a higher rate for the burst also 873 increases the chances for congestion-caused packet loss. Thus, as 874 discussed in Section 5, there must be an upper bound on the extra 875 bandwidth used by the burst. 877 When RS transmits the burst, it SHOULD take into account all 878 available information to prevent any packet loss that may take place 879 during the bursting as a result of buffer overflow on the path 880 between RS and RR and at RR itself. The bursting rate may be 881 determined by taking into account the following data, when available: 883 a. Information obtained via the RAMS-R message, such as Max RAMS 884 Buffer Fill Requirement and/or Max Receive Bitrate (See 885 Section 7.2). 887 b. Information obtained via RTCP receiver reports provided by RR in 888 the retransmission session, allowing in-session rate adaptations 889 for the burst. When these receiver reports indicate packet loss, 890 this may indicate a certain congestion state in the path from RS 891 to RR. Heuristics or algorithms that deduce such congestion 892 state and how subsequently the RS should act, are outside the 893 scope of this document. 895 c. Information obtained via RTCP NACKs provided by RR in the primary 896 multicast session, allowing in-session rate adaptations for the 897 burst. Such RTCP NACKs are transmitted by RR in response to 898 packet loss detection by RR in the burst. NACKs may indicate a 899 certain congestion state on the path from RS to RR. Heuristics 900 or algorithms that deduce such congestion state and how 901 subsequently the RS should act, are outside the scope of this 902 document. 904 d. There may be other feedback received from RR, e.g., in the form 905 of ECN-CE RTCP feedback messages [I-D.westerlund-avt-ecn-for-rtp] 906 that may influence in-session rate adaptations. 908 e. Information obtained via updated RAMS-R messages, allowing in- 909 session rate adaptations, if supported by RS. 911 f. Pre-configured settings for each RR or a set of RRs that indicate 912 the upper-bound bursting rates for which no packet loss will 913 occur as a result of congestion along the path of RS to RR. For 914 example, in managed IPTV networks, where the bottleneck bandwidth 915 along the end-to-end path is known (which is generally the access 916 network link) and where the network between RS and this link is 917 provisioned and dimensioned to carry the burst streams, the 918 bursting rate does not exceed the provisioned value. These 919 settings may also be dynamically adapted using application-aware 920 knowledge. 922 The initial bursting rate of the unicast burst to RR is determined by 923 parameters directly obtained from RR (a) or by pre-configured 924 settings (f). If such information is not available, RS may choose an 925 appropriate initial bursting rate, and could increase or decrease the 926 rate based on the feedback information (b, c, d or e). However, this 927 may not be an easy task as by the time packet loss is reported back 928 to RS triggering a rate reduction, packet loss may have occurred. 930 A specific situation occurs near the end of the unicast burst, when 931 RS has almost no more additional data to sustain the relatively 932 higher bursting rate, thus, the upper-bound bursting rate 933 automatically gets limited by the nominal rate of the primary 934 multicast stream. During this time frame, RR will join the primary 935 multicast session because it was instructed to do so via an RAMS-I 936 message or based on some heuristics. This means that both the burst 937 packets and the primary multicast stream packets will be 938 simultaneously received by RR for a period of time. 940 In this case, when the unicast burst is close to catch up with the 941 primary multicast stream, RS may, for example, keep on sending burst 942 packets but should reduce the rate accordingly by taking the nominal 943 rate of the primary multicast stream into account. Alternatively, RS 944 may immediately cease transmitting the burst packets, when being 945 close to catch-up. Any gap resulting from an imperfect switch by RR 946 in receiving first the burst packets and then only primary multicast 947 stream packets, can be later repaired by requesting retransmissions 948 of the missing packets from RS. The retransmissions may also be 949 shaped by RS to make sure that they do not cause collateral loss in 950 the primary multicast and retransmission sessions. 952 6.4. Failure Cases 954 All RAMS messages MAY be sent several times against the possibility 955 of message loss as long as RS/RR follows the RTCP timer rules defined 956 in [RFC4585]. In the following, we examine the implications of 957 losing the RAMS-R, RAMS-I or RAMS-T messages. 959 When RR sends an RAMS-R message to initiate a rapid acquisition but 960 the message gets lost and RS does not receive it, RR will not get an 961 RAMS-I message, nor a unicast burst. In this case, RR MAY resend the 962 request when it is eligible to do so. Or, after a reasonable amount 963 of time, RR MAY time out (based on the previous observed response 964 times) and immediately join the primary multicast session. In this 965 case, RR MUST still send an RAMS-T message. 967 In the case RR starts receiving a unicast burst but it does not 968 receive a corresponding RAMS-I message within a reasonable amount of 969 time, RR MAY either discard the burst data and stop the burst by 970 sending an RAMS-T message to RS, or decide not to interrupt the 971 unicast burst and be prepared to join the primary multicast session 972 at an appropriate time it determines or indicated in a subsequent 973 RAMS-I message (if available). In either case, RR SHALL send an 974 RAMS-T message to RS at an appropriate time. 976 In the case the RAMS-T message sent by RR does not reach its 977 destination, RS may continue sending the unicast burst even though RR 978 no longer needs it. In some cases, RS has not pre-computed the burst 979 duration and does not know when to stop the burst. To cover that 980 case, RR MAY repeat the RAMS-T message multiple times as long as it 981 follows the RTCP timer rules defined in [RFC4585]. RS MUST be 982 provisioned to deterministically terminate the burst at some point, 983 even if it never receives an RAMS-T message for an ongoing burst. 985 If RR becomes no longer interested in receiving the primary multicast 986 stream and the associated unicast burst, RR SHALL issue an RTCP BYE 987 message to RS to terminate the RTP retransmission session. Only 988 after that, RR MAY send a new rapid acquisition request for another 989 primary multicast session. 991 7. Encoding of the Signaling Protocol in RTCP 993 This section defines the formats of the RTCP transport-layer feedback 994 messages that are exchanged between the Retransmission Server (RS) 995 and RTP Receiver (RR) during rapid acquisition. These messages are 996 referred to as the RAMS Messages. They are payload-independent and 997 MUST be used by all RTP-based multicast applications that support 998 rapid acquisition regardless of the payload they carry. 1000 Payload-specific feedback messages are not defined in this document, 1001 but an extension mechanism is provided where further optional 1002 payload-independent and payload-specific information can be included 1003 in the exchange. 1005 The common packet format for the RTCP feedback messages is defined in 1006 Section 6.1 of [RFC4585]. Each feedback message has a fixed-length 1007 field for version, padding, feedback message type (FMT), payload type 1008 (PT), length, SSRC of packet sender, SSRC of media source as well as 1009 a variable-length field for feedback control information (FCI). 1011 In the RAMS messages, the PT field is set to RTPFB (205) and the FMT 1012 field is set to RAMS (6). Individual RAMS messages are identified by 1013 a sub-field called Sub Feedback Message Type (SFMT). 1015 Depending on the specific scenario and timeliness/importance of a 1016 RAMS message, it may be desirable to send it in a reduced-size RTCP 1017 packet [RFC5506]. However, unless support for [RFC5506] has been 1018 signaled, compound RTCP packets MUST be used by following [RFC3550] 1019 rules. 1021 7.1. Extensions 1023 To improve the functionality of the RAMS method in certain 1024 applications, it may be desirable to define new fields in the RAMS 1025 Request, Information and Termination messages. Such fields MUST be 1026 encoded as TLV elements as described below and sketched in Figure 4: 1028 o Type: A single-octet identifier that defines the type of the 1029 parameter represented in this TLV element. 1031 o Length: A two-octet field that indicates the length of the TLV 1032 element excluding the Type and Length fields in octets. Note that 1033 this length does not include any padding that is required for 1034 alignment. 1036 o Value: Variable-size set of octets that contains the specific 1037 value for the parameter. 1039 If a TLV element does not fall on a 32-bit boundary, the last word 1040 must be padded to the boundary using further bits set to 0. 1042 In an RAMS message any vendor-neutral or private extension MUST be 1043 placed after the mandatory fields (if any). The support for 1044 extensions is OPTIONAL. 1046 0 1 2 3 1047 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 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Type | Length | Value | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Value contd. / 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 Figure 4: Structure of a TLV element 1056 7.1.1. Vendor-Neutral Extensions 1058 If the goal in defining new TLV elements is to extend the 1059 functionality in a vendor-neutral manner, they MUST be registered 1060 with IANA through the guidelines provided in Section 13.5. 1062 The current document defines several vendor-neutral extensions in the 1063 following sections. 1065 7.1.2. Private Extensions 1067 It is desirable to allow vendors to use private extensions in TLV 1068 format. For interoperability, such extensions MUST NOT collide with 1069 each other. 1071 A certain range of TLV Types is reserved for private extensions 1072 (Refer to Section 13.5). IANA management for these extensions is 1073 unnecessary and they are the responsibility of individual vendors. 1075 The structure that MUST be used for the private extensions is 1076 depicted in Figure 5. Here, the enterprise numbers are used from 1077 http://www.iana.org/assignments/enterprise-numbers. This will ensure 1078 the uniqueness of the private extensions and avoid any collision. 1080 0 1 2 3 1081 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 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | Type | Length | Ent. Number | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Ent. Number contd. | Value | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | Value contd. / 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 Figure 5: Structure of a private extension 1092 7.2. RAMS Request 1094 The RAMS Request message is identified by SFMT=1. 1096 The FCI field MUST contain only one RAMS Request. 1098 The RAMS Request is used by RR to request rapid acquisition for a new 1099 multicast RTP session. 1101 The FCI field has the structure depicted in Figure 6. 1103 Editor's note: We have not finalized whether RAMS-R messages need a 1104 sequence number or not. 1106 0 1 2 3 1107 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 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | SFMT=1 | Optional TLV-encoded Fields | 1110 +-+-+-+-+-+-+-+-+ | 1111 : Optional TLV-encoded Fields (and Padding, if needed) : 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 Figure 6: FCI field syntax for the RAMS Request message 1116 o Min RAMS Buffer Fill Requirement (32 bits): Optional TLV element 1117 that denotes the minimum milliseconds of data that RR desires to 1118 have in its buffer before allowing the data to be consumed by the 1119 application. 1121 RR may have knowledge of its buffering requirements. These 1122 requirements may be application and/or device specific. For 1123 instance, RR may need to have a certain amount of data in its 1124 application buffer to handle transmission jitter and/or to be able 1125 to support error-control methods. If RS is told the minimum 1126 buffering requirement of the receiver, it may tailor the burst 1127 more precisely, e.g., by choosing an appropriate starting point. 1128 The methods used by RR to determine this value are application 1129 specific, and thus, out of the scope of this document. 1131 If specified, the amount of backfill that will be provided by the 1132 unicast burst SHOULD NOT be smaller than the specified value since 1133 it will not be able to build up the desired level of buffer at RR 1134 and may cause buffer underruns. 1136 Type: TBD 1138 Length: TBD 1140 o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element 1141 that denotes the maximum milliseconds of data that RR can buffer 1142 without losing the burst data due to buffer overflow. 1144 RR may have knowledge of its buffering requirements. These 1145 requirements may be application or device specific. For instance, 1146 one particular RR may have more physical memory than another RR, 1147 and thus, can buffer more data. If RS knows the buffering ability 1148 of the receiver, it may tailor the burst more precisely. The 1149 methods used by the receiver to determine this value are 1150 application specific, and thus, out of scope. 1152 If specified, the amount of backfill that will be provided by the 1153 unicast burst SHOULD NOT be larger than this value since it may 1154 cause buffer overflows at RR. 1156 Type: TBD 1158 Length: TBD 1160 o Max Receive Bitrate (32 bits): Optional TLV element that denotes 1161 the maximum bitrate (in bits per second) that the RTP receiver can 1162 process the unicast burst. This rate should include whatever 1163 knowledge the receiver has that would provide an upper bound on 1164 the unicast burst bitrate. The limits may include local receiver 1165 limits as well as network limits that are known to the receiver. 1167 If specified, the unicast burst bitrate SHOULD NOT be larger than 1168 this value since it may cause congestion and packet loss. 1170 Type: TBD 1172 Length: TBD 1174 The semantics of the RAMS-R feedback message is independent of the 1175 payload type. 1177 7.3. RAMS Information 1179 The RAMS Information message is identified by SFMT=2. 1181 The FCI field MUST contain only one RAMS Information. 1183 The RAMS Information is used to describe the unicast burst that will 1184 be sent for rapid acquisition. It also includes other useful 1185 information for RR as described below. Optional payload-specific 1186 information MAY follow RAMS Information. 1188 The FCI field has the structure depicted in Figure 7. 1190 0 1 2 3 1191 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 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | SFMT=2 | MSN | Response | 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 |RTP SN of the First Burst Pkt. | Optional TLV-encoded Fields | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 : Optional TLV-encoded Fields (and Padding, if needed) : 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 Figure 7: FCI field syntax for the RAMS Information message 1202 o Message Sequence Number (8 bits) : Mandatory field that denotes 1203 the sequence number of this RAMS-I message. During rapid 1204 acquisition, multiple RAMS-I messages MAY be sent and/or the same 1205 RAMS-I message MAY be repeated. The first RAMS-I message SHALL 1206 have an MSN value of 0. This value SHALL NOT be changed if the 1207 same RAMS-I message is sent to the same RR multiple times for 1208 redundancy purposes. If a new information is conveyed in a new 1209 RAMS-I message, the MSN value SHALL be incremented by one. 1211 o Response (16 bits): Mandatory field that denotes the RS response 1212 code for this RAMS-I message. 1214 Editor's note: HTTP/SIP-like response codes will be defined and 1215 registered with IANA in a later version. 1217 o RTP SN of the First Burst Pkt. (16 bits): Mandatory field that 1218 specifies the RTP sequence number of the first packet that will be 1219 sent as part of the burst. This allows RR to know if one or more 1220 packets have been dropped at the beginning of the burst. 1222 o Earliest Multicast Join Time (32 bits): Optional TLV element that 1223 specifies the time difference (i.e., delta time) between the 1224 arrival of this RAMS-I message and the earliest time instant when 1225 RR could join the primary multicast session in RTP ticks. A zero 1226 value in this field means that RR can join the primary multicast 1227 session right away. 1229 Note that if the RAMS request has been accepted, RS SHOULD send 1230 this field at least once, so that RR knows when to join the 1231 primary multicast session. If the burst request has been rejected 1232 as indicated in the Response field, this field MAY be omitted or 1233 set to 0. In that case, it is up to RR when or whether to join 1234 the primary multicast session. 1236 Type: TBD 1238 Length: TBD 1240 o Burst Duration (32 bits): Optional TLV element that denotes the 1241 duration of the burst that RS is planning to send (in RTP ticks). 1242 In the absence of additional stimulus, RS will send a burst of 1243 this duration. However, the burst duration may be modified by 1244 subsequent events, including changes in the primary multicast 1245 stream and reception of RAMS-T messages. 1247 Note that RS MUST terminate the flow in a deterministic timeframe, 1248 even if it does not get an RAMS-T or a BYE from RR. It is 1249 optional to send this field in an RAMS-I message when the burst 1250 request is accepted. If the burst request has been rejected as 1251 indicated in the Response field, this field MAY be omitted or set 1252 to 0. 1254 Type: TBD 1256 Length: TBD 1258 o Max Burst Bitrate (32 bits): Optional TLV element that denotes 1259 the maximum bitrate (in bits per second) that will be used by RS 1260 for the unicast burst. 1262 Type: TBD 1264 Length: TBD 1266 The semantics of the RAMS-I feedback message is independent of the 1267 payload type. 1269 The RAMS-I message MAY be sent multiple times at the start of, prior 1270 to, or during the unicast burst. The subsequent RAMS-I messages MAY 1271 signal changes in any of the fields. 1273 7.4. RAMS Termination 1275 The RAMS Termination message is identified by SFMT=3. 1277 The FCI field MUST contain only one RAMS Termination. 1279 The RAMS Termination may be used to assist RS in determining when to 1280 stop the burst. 1282 If prior to sending the RAMS-T message RR has already joined the 1283 primary multicast session and received at least one RTP packet from 1284 the multicast session, RR includes the sequence number of the first 1285 RTP packet in the RAMS-T message. With this information, RS can 1286 decide when to terminate the unicast burst. 1288 If RR issues the RAMS-T message before it has joined and/or begun 1289 receiving RTP packets from the primary multicast session, RR does not 1290 specify any sequence number in the RAMS-T message, which indicates RS 1291 to stop the burst immediately. However, the RAMS-T message may get 1292 lost and RS may not receive this message. 1294 The FCI field has the structure depicted in Figure 8. 1296 0 1 2 3 1297 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 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 | SFMT=3 | Optional TLV-encoded Fields | 1300 +-+-+-+-+-+-+-+-+ | 1301 : Optional TLV-encoded Fields (and Padding, if needed) : 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 Figure 8: FCI field syntax for the RAMS Termination message 1306 o Extended RTP Seqnum of First Multicast Packet (32 bits): Optional 1307 TLV element that specifies the extended RTP sequence number of the 1308 of the first multicast packet received by RR. If no RTP packet 1309 has been received from the primary multicast session, this field 1310 does not exist and tells RS to stop the burst immediately. 1312 Type: TBD 1314 Length: TBD 1316 The semantics of the RAMS-T feedback message is independent of the 1317 payload type. 1319 8. SDP Definitions and Examples 1321 8.1. Definitions 1323 The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585]. 1324 Here we add the following syntax to the 'rtcp-fb' attribute (the 1325 feedback type and optional parameters are all case sensitive): 1327 (In the following ABNF [RFC5234], fmt, SP and CRLF are used as 1328 defined in [RFC4566].) 1330 rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF 1332 rtcp-fb-pt = "*" ; wildcard: applies to all formats 1333 / fmt ; as defined in SDP spec 1335 rtcp-fb-val = "nack" SP "ssli" 1337 The following parameter is defined in this document for use with 1338 'nack': 1340 o 'ssli' stands for Stream Synchronization Loss Indication and 1341 indicates the use of RAMS messages as defined in Section 7. 1343 This document also defines a new SDP attribute ('rams-updates') that 1344 indicates whether RS supports updated request messages or not. This 1345 attribute is used in a declarative manner. If RS supports updated 1346 request messages and this attribute is included in the SDP 1347 description, RR MAY send updated requests. RS may or may not be able 1348 to accept value changes in every field in an RAMS-R message. 1349 However, if the 'rams-updates' attribute is not included in the SDP 1350 description, RR SHALL NOT send updated requests (RR MAY repeat its 1351 initial request without changes, though). 1353 8.2. Examples 1355 This section provides a declarative SDP [RFC4566] example for 1356 enabling rapid acquisition of multicast RTP sessions. The following 1357 example uses the SDP grouping semantics [RFC3388], the RTP/AVPF 1358 profile [RFC4585], the RTP retransmissions [RFC4588], the RTCP 1359 extensions for SSM sessions with unicast feedback 1360 [I-D.ietf-avt-rtcpssm] and the source-specific media attributes 1361 [I-D.ietf-mmusic-sdp-source-attributes]. 1363 In the example shown Figure 9, we have a primary multicast stream and 1364 a unicast retransmission stream. The source stream is multicast from 1365 a distribution source (with a source IP address of 192.0.2.2) to the 1366 multicast destination address of 233.252.0.2 and port 41000. A 1367 Retransmission Server including feedback target functionality (with 1368 an address of 192.0.2.1 and port of 41001) is specified with the 1369 'rtcp' attribute. The RTP receiver(s) can report missing packets on 1370 the source stream to the feedback target and request retransmissions. 1371 In the RAMS context, the parameter 'rtx-time' specifies the time in 1372 milliseconds that the Retransmission Server keeps an RTP packet in 1373 its buffer available for retransmission (measured from the time the 1374 packet was received by the Retransmission Server). 1376 The RTP retransmissions are sent on a unicast session with a 1377 destination port of 41002. 1379 Editor's note: This text will be updated in a later version to 1380 reflect the capability for RRs to use their desired ports to receive 1381 the burst and retransmission packets. 1383 The RTCP port for the unicast session (41003) is specified with the 1384 'rtcp' attribute. In this example, both the conventional 1385 retransmission and rapid acquisition support are enabled. This is 1386 achieved by the additional "a=rtcp-fb:98 nack ssli" line. Note that 1387 this SDP includes the "a=sendonly" line for the media description of 1388 the retransmission stream and is for the Retransmission Server (RS). 1389 Its counterpart for the RTP Receiver (RR) includes the "a=recvonly" 1390 line as shown in Figure 10. 1392 When an RTP receiver requires rapid acquisition for a new multicast 1393 session it wants to join, it sends an RAMS-R message to the feedback 1394 target of that primary multicast session. This feedback message has 1395 to have the SSRC of the primary multicast stream for which rapid 1396 acquisition is requested for. However, since this RTP receiver has 1397 not received any RTP packets from the primary multicast session yet, 1398 the RTP receiver MUST learn the SSRC value from the 'ssrc' attribute 1399 of the media description [I-D.ietf-avt-rtcpssm]. In addition to the 1400 SSRC value, the 'cname' source attribute MUST also be present in the 1401 SDP description [I-D.ietf-mmusic-sdp-source-attributes]. 1403 Note that listing the SSRC values for the primary multicast sessions 1404 in the SDP file does not create a problem in SSM sessions when an 1405 SSRC collision occurs. This is because in SSM sessions, an RTP 1406 receiver that observed an SSRC collision with a media source MUST 1407 change its own SSRC [I-D.ietf-avt-rtcpssm] by following the rules 1408 defined in [RFC3550]. 1410 A feedback target that receives an RAMS-R feedback message becomes 1411 aware that the prediction chain at the RTP receiver side has been 1412 broken or does not exist any more. If the necessary conditions are 1413 satisfied (as outlined in Section 7 of [RFC4585]) and available 1414 resources exist, RS MAY react to the RAMS-R message by sending any 1415 transport-layer and payload-specific feedback message(s) and starting 1416 the unicast burst. 1418 v=0 1419 o=ali 1122334455 1122334466 IN IP4 rams.example.com 1420 s=Rapid Acquisition Example 1421 t=0 0 1422 a=group:FID 3 4 1423 a=rtcp-unicast:rsi 1424 m=video 41000 RTP/AVPF 98 1425 i=Primary Multicast Stream #2 1426 c=IN IP4 233.252.0.2/255 1427 a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2 1428 a=recvonly 1429 a=rtpmap:98 MP2T/90000 1430 a=rtcp:41001 IN IP4 192.0.2.1 1431 a=rtcp-fb:98 nack 1432 a=rtcp-fb:98 nack ssli 1433 a=ssrc:123321 cname:iptv-ch32@rams.example.com 1434 a=rams-updates 1435 a=mid:3 1436 m=video 41002 RTP/AVPF 99 1437 i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support) 1438 c=IN IP4 192.0.2.1 1439 a=sendonly 1440 a=rtpmap:99 rtx/90000 1441 a=rtcp:41003 1442 a=fmtp:99 apt=98; rtx-time=5000 1443 a=mid:4 1445 Figure 9: Example SDP for RS when RAMS support is enabled 1447 v=0 1448 o=ali 1122334455 1122334466 IN IP4 rams.example.com 1449 s=Rapid Acquisition Example 1450 t=0 0 1451 a=group:FID 3 4 1452 a=rtcp-unicast:rsi 1453 m=video 41000 RTP/AVPF 98 1454 i=Primary Multicast Stream #2 1455 c=IN IP4 233.252.0.2/255 1456 a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2 1457 a=recvonly 1458 a=rtpmap:98 MP2T/90000 1459 a=rtcp:41001 IN IP4 192.0.2.1 1460 a=rtcp-fb:98 nack 1461 a=rtcp-fb:98 nack ssli 1462 a=ssrc:123321 cname:iptv-ch32@rams.example.com 1463 a=rams-updates 1464 a=mid:3 1465 m=video 41002 RTP/AVPF 99 1466 i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support) 1467 c=IN IP4 192.0.2.1 1468 a=recvonly 1469 a=rtpmap:99 rtx/90000 1470 a=rtcp:41003 1471 a=fmtp:99 apt=98; rtx-time=5000 1472 a=mid:4 1474 Figure 10: Example SDP for RR when RAMS support is enabled 1476 The offer/answer model considerations [RFC3264] for the 'rtcp-fb' 1477 attribute are provided in Section 4.2 of [RFC4585]. 1479 9. NAT Considerations 1481 For a variety of reasons, one or more NAPT devices (hereafter simply 1482 called NAT) are expected to exist between RR and RS. NATs have a 1483 variety of operating characteristics for UDP traffic [RFC4787]. For 1484 a NAT to permit traffic from RS to arrive at RR, the NAT(s) must 1485 first either: 1487 a. See UDP traffic sent from RR (which is on the 'inside' of the 1488 NAT) to RS (which is on the 'outside' of the NAT). This traffic 1489 is sent to the same transport address as the subsequent response 1490 traffic, OR; 1492 b. Be configured to forward certain ports (e.g., using HTML 1493 configuration, UPnP IGD [UPnP-IGD], DLNA [DLNA]). Details of 1494 this are out of scope of this document. 1496 For both (a) and (b), RR is responsible for maintaining the NAT's 1497 state if it wants to receive traffic from the RS on that port. For 1498 (a), RR MUST send UDP traffic to keep the NAT binding alive, at least 1499 every 30 seconds [RFC4787]. Note that while (a) is more like an 1500 automatic/dynamic configuration, (b) is more like a manual/static 1501 configuration. 1503 When using (a), RR will need to first learn the UDP port(s) of the 1504 NAT's binding(s) from the perspective of RS. This is done by sending 1505 a STUN [RFC5389] message from RR to the RTP port of RS which will be 1506 used for incoming RTP traffic. If RTP/RTCP multiplexing on a single 1507 port [I-D.ietf-avt-rtp-and-rtcp-mux] is not supported by RR, it will 1508 need to send a second STUN message to the RTCP port of RS which will 1509 be used for incoming RTCP traffic. If RTP/RTCP multiplexing is 1510 supported by RR, it only needs to learn one port. RS receives the 1511 STUN message(s) and responds to them. RR now knows the UDP ports 1512 from the perspective of RS. 1514 Editor's note: The issues related to using ports across multicast 1515 and unicast RTP sessions will be discussed in a separate draft and 1516 the current document will normatively reference that document. The 1517 updated text for this section will be provided in a later version. 1519 10. Known Implementations 1521 10.1. Open Source RTP Receiver Implementation by Cisco 1523 An open source RTP Receiver code that implements the functionalities 1524 introduced in this document is available. For documentation, visit 1525 the following URL: 1527 http://www.cisco.com/en/US/docs/video/cds/cda/vqe/3_3/user/guide/ 1528 ch1_over.html 1530 The code is also available at: 1532 ftp://ftpeng.cisco.com/ftp/vqec/ 1534 Note that this code is under development and may be based on an 1535 earlier version of this document. As we make progress in the draft, 1536 the source code will also be updated to reflect the changes. 1538 Some preliminary results based on this code are available in [CCNC09] 1539 and [IC2009]. 1541 10.2. IPTV Commercial Implementation by Microsoft 1543 Rapid Acquisition of Multicast RTP Sessions is supported as part of 1544 the Microsoft Mediaroom Internet Protocol Television (IPTV) and 1545 multimedia software platform. This system is in wide commercial 1546 deployment. More information can be found at: 1548 http://www.microsoft.com/mediaroom 1550 http://informitv.com/articles/2008/10/13/channelchangetimes/ 1552 11. Open Issues 1554 o Discussion of acquisition for the individual RTP streams vs. the 1555 whole RTP session. 1557 o Updating the NAT section. 1559 o Completing the TLV types, lengths, etc. 1561 o Response/status codes for RAMS. 1563 12. Security Considerations 1565 Applications that are using RAMS make heavy use of the unicast 1566 feedback mechanism described in [I-D.ietf-avt-rtcpssm] and the 1567 payload format defined in [RFC4588]. Thus, these applications are 1568 subject to the general security considerations discussed in 1569 [I-D.ietf-avt-rtcpssm] and [RFC4588]. In this section, we give an 1570 overview of the guidelines and suggestions described in these 1571 specifications from a RAMS perspective. We also discuss the security 1572 considerations that explicitly apply to RAMS applications. 1574 First of all, much of the session description information is 1575 available in the SDP descriptions that are distributed to the media 1576 sources, Retransmission Servers and RTP Receivers. Adequate security 1577 measures are RECOMMENDED to ensure the integrity and authenticity of 1578 the SDP descriptions so that transport addresses of the media 1579 sources, Feedback Targets as well as other session-specific 1580 information can be authenticated. 1582 Compared to an RTCP NACK message that triggers one or more 1583 retransmissions, an RAMS Request (RAMS-R) message may trigger a new 1584 burst stream to be sent by the Retransmission Server. Depending on 1585 the application-specific requirements and conditions existing at the 1586 time of the RAMS-R reception by the Retransmission Server, the 1587 resulting burst stream may contain potentially a large number of 1588 retransmission packets. Since these packets are sent at a faster 1589 than the nominal rate of the multicast session, RAMS consumes more 1590 resources on the Retransmission Server, the RTP Receiver and the 1591 network. This particularly makes denial-of-service attacks more 1592 intense, and hence, more harmful than attacks that target ordinary 1593 retransmission sessions. 1595 Following the suggestions given in [RFC4588], counter-measures SHOULD 1596 be taken to prevent tampered or spoofed RTCP packets. Tampered 1597 RAMS-R messages may trigger inappropriate burst streams or alter the 1598 existing burst streams in an inappropriate way. For example, if the 1599 Max Receive Bitrate field is altered by a tampered RAMS-R message, 1600 the updated burst may overflow the buffer on the receiver side, or 1601 oppositely, may slow down the burst to the point that it is useless. 1602 Tampered RAMS Termination (RAMS-T) messages may terminate valid burst 1603 streams pre-maturely resulting in gaps in the received RTP packets. 1604 RAMS Information (RAMS-I) messages contain fields that are critical 1605 for the success of the RAMS operation. Any tampered information in 1606 the RAMS-I message may easily cause the RTP Receiver to make wrong 1607 decisions. Consequently, the RAMS operation may fail. 1609 While most of the denial-of-service attacks can be prevented by the 1610 integrity and authenticity checks enabled by SRTP, an attack can 1611 still be started by legitimate endpoints that send several valid 1612 RAMS-R messages to a particular Feedback Target in a synchronized 1613 fashion and very short amount of time. Since a RAMS operation may 1614 temporarily consume a large amount of resources, a series of the 1615 RAMS-R messages may temporarily overload the Retransmission Server. 1616 In these circumstances, the Retransmission Server may, for example, 1617 reject incoming RAMS requests until its resources become available 1618 again. One means to ameliorate this threat is to apply a per- 1619 endpoint policing mechanism on the incoming RAMS requests. A 1620 reasonable policing mechanism should consider application-specific 1621 requirements and minimize false negatives. 1623 In addition to the denial-of-service attacks, man-in-the-middle and 1624 replay attacks can also be harmful. However, RAMS itself does not 1625 bring any new risks or threats other than the ones discussed in 1626 [I-D.ietf-avt-rtcpssm]. 1628 [RFC4588] RECOMMENDS that the cryptography mechanisms are used for 1629 the retransmission payload format to provide protection against known 1630 plaintext attacks. As discussed in [RFC4588], the retransmission 1631 payload format sets the timestamp field in the RTP header to the 1632 media timestamp of the original packet and this does not compromise 1633 the confidentiality. Furthermore, if cryptography is used to provide 1634 security services on the original stream, then the same services, 1635 with equivalent cryptographic strength, MUST be provided on the 1636 retransmission stream per [RFC4588]. 1638 13. IANA Considerations 1640 The following contact information shall be used for all registrations 1641 in this document: 1643 Ali Begen 1644 abegen@cisco.com 1646 170 West Tasman Drive 1647 San Jose, CA 95134 USA 1649 13.1. Registration of SDP Attributes 1651 This document registers a new attribute name in SDP. 1653 SDP Attribute ("att-field"): 1654 Attribute name: rams-updates 1655 Long form: Support for Updated RAMS Request Messages 1656 Type of name: att-field 1657 Type of attribute: Media level 1658 Subject to charset: No 1659 Purpose: See this document 1660 Reference: This document 1661 Values: None 1663 13.2. Registration of SDP Attribute Values 1665 This document registers a new value for the 'nack' attribute to be 1666 used with the 'rtcp-fb' attribute in SDP. For more information about 1667 'rtcp-fb', refer to [RFC4585]. 1669 Value name: ssli 1670 Long name: Stream Synchronization Loss Indication 1671 Usable with: nack 1672 Reference: This document 1674 13.3. Registration of FMT Values 1676 Within the RTPFB range, the following format (FMT) value is 1677 registered: 1679 Name: RAMS 1680 Long name: Rapid Acquisition of Multicast Sessions 1681 Value: 6 1682 Reference: This document 1684 13.4. SFMT Values for RAMS Messages Registry 1686 This document creates a new sub-registry for the sub-feedback message 1687 type (SFMT) values to be used with the FMT value registered for RAMS 1688 messages. The registry is called the SFMT Values for RAMS Messages 1689 Registry. This registry is to be managed by the IANA according to 1690 the Specification Required policy of [RFC5226]. 1692 The length of the SFMT field in the RAMS messages is a single octet, 1693 allowing 256 values. The registry is initialized with the following 1694 entries: 1696 Value Name Reference 1697 ----- -------------------------------------------------- ------------- 1698 1 RAMS Request This document 1699 2 RAMS Information This document 1700 3 RAMS Termination This document 1702 The SFMT values 0 and 255 are reserved for future use. 1704 Any registration for an unassigned SFMT value MUST contain the 1705 following information: 1707 o Contact information of the one doing the registration, including 1708 at least name, address, and email. 1710 o A detailed description of what the new SFMT represents and how it 1711 shall be interpreted. 1713 Note that new RAMS functionality should be introduced by using the 1714 extension mechanism within the existing RAMS message types not by 1715 introducing new message types unless it is absolutely necessary. 1717 13.5. RAMS TLV Space Registry 1719 This document creates a new IANA TLV space registry for the RAMS 1720 extensions. The registry is called the RAMS TLV Space Registry. 1721 This registry is to be managed by the IANA according to the 1722 Specification Required policy of [RFC5226]. 1724 The length of the Type field in the TLV elements is a single octet, 1725 allowing 256 values. The registry is initialized with the following 1726 entries: 1728 Type Description Reference 1729 ---- -------------------------------------------------- ------------- 1730 TBD TBD This document 1731 ... ... 1733 The registry entries are TBC. 1735 The TYPE values 0 and 255 are reserved for future use. The TYPE 1736 values between (and including) 128 and 254 are reserved for private 1737 extensions. 1739 Any registration for an unassigned TYPE value MUST contain the 1740 following information: 1742 o Contact information of the one doing the registration, including 1743 at least name, address, and email. 1745 o A detailed description of what the new TLV element represents and 1746 how it shall be interpreted. 1748 14. Acknowledgments 1750 The authors would like to specially thank Peilin Yang for his 1751 contributions to this document and detailed reviews. 1753 The authors also thank the following individuals for their 1754 contributions, comments and suggestions to this document: Dave Oran, 1755 Dan Wing, Tony Faustini, Jeff Goldberg, Muriel Deschanel, Orit Levin, 1756 Roni Even, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui Wang, Zixuan 1757 Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan Lennox and 1758 Sean Sheedy. 1760 15. Change Log 1762 15.1. draft-ietf-avt-rapid-acquisition-for-rtp-02 1764 The following are the major changes compared to version 01: 1766 o Port mapping discussion has been removed since it will be 1767 discussed in a separate draft. 1769 o Security considerations section has been added. 1771 o Burst shaping section has been completed. 1773 o Most of the outstanding open issues have been addressed. 1775 15.2. draft-ietf-avt-rapid-acquisition-for-rtp-01 1777 The following are the major changes compared to version 00: 1779 o Formal definitions of vendor-neutral and private extensions and 1780 their IANA registries have been added. 1782 o SDP examples were explained in more detail. 1784 o The sub-FMT field has been introduced in the RAMS messages for 1785 message type identification. 1787 o Some terminology has been fixed. 1789 o NAT considerations section has been added. 1791 15.3. draft-ietf-avt-rapid-acquisition-for-rtp-00 1793 This is a resubmission of version 03 as a WG item. 1795 15.4. draft-versteeg-avt-rapid-synchronization-for-rtp-03 1797 The following are the major changes compared to version 02: 1799 o The title and message names have been changed. 1801 o RTCP message semantics have been added. RAMS protocol has been 1802 revised to handle updated requests and responses. 1804 o Definitions have been revised. 1806 o RTP/RTCP muxing reference has been added. 1808 15.5. draft-versteeg-avt-rapid-synchronization-for-rtp-02 1810 The following are the major changes compared to version 01: 1812 o The discussion around MPEG2-TS has been moved to another document. 1814 o The RAMS-R, RAMS-I and RAMS-T messages have been extensively 1815 modified and they have been made mandatory. 1817 o IANA Considerations section has been updated. 1819 o The discussion of RTCP XR report has been moved to another 1820 document. 1822 o A new section on protocol design considerations has been added. 1824 15.6. draft-versteeg-avt-rapid-synchronization-for-rtp-01 1826 The following are the major changes compared to version 00: 1828 o The core of the rapid synchronization method is now payload- 1829 independent. But, the draft still defines payload-specific 1830 messages that are required for enabling rapid synch for the RTP 1831 flows carrying MPEG2-TS. 1833 o RTCP APP packets have been removed, new RTCP transport-layer and 1834 payload-specific feedback messages have been defined. 1836 o The step for leaving the current multicast session has been 1837 removed from Section 6.2. 1839 o A new RTCP XR (Multicast Join) report has been defined. 1841 o IANA Considerations section have been updated. 1843 o Editorial changes to clarify several points. 1845 16. References 1847 16.1. Normative References 1849 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1850 Jacobson, "RTP: A Transport Protocol for Real-Time 1851 Applications", STD 64, RFC 3550, July 2003. 1853 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1854 Requirement Levels", BCP 14, RFC 2119, March 1997. 1856 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1857 Thyagarajan, "Internet Group Management Protocol, Version 1858 3", RFC 3376, October 2002. 1860 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1861 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1863 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1864 Group Management Protocol Version 3 (IGMPv3) and Multicast 1865 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1866 Specific Multicast", RFC 4604, August 2006. 1868 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 1869 Description Protocol", RFC 4566, July 2006. 1871 [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. 1872 Schulzrinne, "Grouping of Media Lines in the Session 1873 Description Protocol (SDP)", RFC 3388, December 2002. 1875 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1876 "Extended RTP Profile for Real-time Transport Control 1877 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1878 July 2006. 1880 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 1881 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 1882 July 2006. 1884 [I-D.ietf-avt-rtcpssm] 1885 Schooler, E., Ott, J., and J. Chesterfield, "RTCP 1886 Extensions for Single-Source Multicast Sessions with 1887 Unicast Feedback", draft-ietf-avt-rtcpssm-18 (work in 1888 progress), March 2009. 1890 [I-D.ietf-mmusic-sdp-source-attributes] 1891 Lennox, J., Ott, J., and T. Schierl, "Source-Specific 1892 Media Attributes in the Session Description Protocol 1893 (SDP)", draft-ietf-mmusic-sdp-source-attributes-02 (work 1894 in progress), October 2008. 1896 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1897 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1899 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 1900 with Session Description Protocol (SDP)", RFC 3264, 1901 June 2002. 1903 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 1904 Real-Time Transport Control Protocol (RTCP): Opportunities 1905 and Consequences", RFC 5506, April 2009. 1907 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1908 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1909 May 2008. 1911 16.2. Informative References 1913 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1914 August 1980. 1916 [I-D.ietf-rmt-pi-norm-revised] 1917 Adamson, B., Bormann, C., London, U., and J. Macker, 1918 "NACK-Oriented Reliable Multicast Transport Protocol", 1919 draft-ietf-rmt-pi-norm-revised-13 (work in progress), 1920 June 2009. 1922 [I-D.begen-avt-rtp-mpeg2ts-preamble] 1923 Begen, A. and E. Friedrich, "RTP Payload Format for 1924 MPEG2-TS Preamble", 1925 draft-begen-avt-rtp-mpeg2ts-preamble-02 (work in 1926 progress), August 2009. 1928 [I-D.begen-avt-rapid-sync-rtcp-xr] 1929 Begen, A. and E. Friedrich, "Multicast Acquisition Report 1930 Block Type for RTCP XR", 1931 draft-begen-avt-rapid-sync-rtcp-xr-02 (work in progress), 1932 August 2009. 1934 [I-D.ietf-avt-rapid-rtp-sync] 1935 Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP 1936 Flows", draft-ietf-avt-rapid-rtp-sync-05 (work in 1937 progress), July 2009. 1939 [I-D.westerlund-avt-ecn-for-rtp] 1940 Westerlund, M., Johansson, I., and C. Perkins, "Explicit 1941 Congestion Notification (ECN) for RTP over UDP", 1942 draft-westerlund-avt-ecn-for-rtp-00 (work in progress), 1943 July 2009. 1945 [I-D.ietf-avt-rtp-and-rtcp-mux] 1946 Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1947 Control Packets on a Single Port", 1948 draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), 1949 August 2007. 1951 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1952 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1953 RFC 4787, January 2007. 1955 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1956 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1957 October 2008. 1959 [UPnP-IGD] 1960 Forum, UPnP., "Universal Plug and Play (UPnP) Internet 1961 Gateway Device (IGD)", November 2001. 1963 [DLNA] , DLNA., "http://www.dlna.org/home". 1965 [CCNC09] Begen, A., Glazebrook, N., and W. VerSteeg, "A Unified 1966 Approach for Repairing Packet Loss and Accelerating 1967 Channel Changes in Multicast IPTV (IEEE CCNC)", 1968 January 2009. 1970 [IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing 1971 Channel Change Times in IPTV with Real-Time Transport 1972 Protocol (IEEE Internet Computing)", May 2009. 1974 Authors' Addresses 1976 Bill VerSteeg 1977 Cisco Systems 1978 5030 Sugarloaf Parkway 1979 Lawrenceville, GA 30044 1980 USA 1982 Email: billvs@cisco.com 1984 Ali Begen 1985 Cisco Systems 1986 170 West Tasman Drive 1987 San Jose, CA 95134 1988 USA 1990 Email: abegen@cisco.com 1992 Tom VanCaenegem 1993 Alcatel-Lucent 1994 Copernicuslaan 50 1995 Antwerpen, 2018 1996 Belgium 1998 Email: Tom.Van_Caenegem@alcatel-lucent.be 1999 Zeev Vax 2000 Microsoft Corporation 2001 1065 La Avenida 2002 Mountain View, CA 94043 2003 USA 2005 Email: zeevvax@microsoft.com