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