idnits 2.17.1 draft-ietf-avtext-rams-scenarios-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 10, 2012) is 4369 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVTEXT A. Begen 3 Internet-Draft Cisco 4 Intended status: Informational May 10, 2012 5 Expires: November 11, 2012 7 Considerations for Deploying the Rapid Acquisition of Multicast RTP 8 Sessions (RAMS) Method 9 draft-ietf-avtext-rams-scenarios-05 11 Abstract 13 The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a 14 method based on RTP and RTP Control Protocol (RTCP) that enables an 15 RTP receiver to rapidly acquire and start consuming the RTP multicast 16 data. Upon a request from the RTP receiver, an auxiliary unicast RTP 17 retransmission session is set up between a retransmission server and 18 the RTP receiver, over which the reference information about the new 19 multicast stream the RTP receiver is about to join is transmitted at 20 an accelerated rate. This often precedes, but may also accompany, 21 the multicast stream itself. When there is only one multicast stream 22 to be acquired, the RAMS solution works in a straightforward manner. 23 However, when there are two or more multicast streams to be acquired 24 from the same or different multicast RTP sessions, care should be 25 taken to configure each RAMS session appropriately. This document 26 provides example scenarios and discusses how the RAMS solution could 27 be used in such scenarios. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 11, 2012. 46 Copyright Notice 48 Copyright (c) 2012 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 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Scenario #1: Two Multicast Groups . . . . . . . . . . . . 4 67 3.2. Scenario #2: One Multicast Group . . . . . . . . . . . . . 5 68 3.3. Scenario #3: SSRC Multiplexing . . . . . . . . . . . . . . 6 69 3.4. Scenario #4: Payload-Type Multiplexing . . . . . . . . . . 7 70 4. Feedback Target and SSRC Signaling Issues . . . . . . . . . . 7 71 5. FEC during RAMS and Bandwidth Issues . . . . . . . . . . . . . 7 72 5.1. Scenario #1 . . . . . . . . . . . . . . . . . . . . . . . 8 73 5.2. Scenario #2 . . . . . . . . . . . . . . . . . . . . . . . 9 74 5.3. Scenario #3 . . . . . . . . . . . . . . . . . . . . . . . 10 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a 86 method based on RTP and RTP Control Protocol (RTCP) that enables an 87 RTP receiver to rapidly acquire and start consuming the RTP multicast 88 data. Through an auxiliary unicast RTP retransmission session 89 [RFC4588], the RTP receiver receives a reference information about 90 the new multicast stream it is about to join. This often precedes, 91 but may also accompany, the multicast stream itself. The RAMS 92 solution is documented in detail in [RFC6285]. 94 The RAMS specification [RFC6285] has provisions for concurrently 95 acquiring multiple streams inside a multicast RTP session. However, 96 the RAMS specification does not discuss scenarios where an RTP 97 receiver makes use of the RAMS method to rapidly acquire multiple and 98 associated multicast streams in parallel, or where different RTP 99 sessions are part of the same source-specific multicast (SSM) 100 session. The example presented in Section 8.3 of [RFC6285] addresses 101 only the simple case of an RTP receiver rapidly acquiring only one 102 multicast stream to explain the protocol details. 104 There are certain deployment models where a multicast RTP session 105 might have two or more multicast streams associated with it. There 106 are also cases, where an RTP receiver might be interested in 107 acquiring one or more multicast streams from several multicast RTP 108 sessions. Close coordination is required for multiple RAMS sessions 109 simultaneously started by an RTP server, where each session is 110 initiated with an individual RAMS Request message to a different 111 feedback target. In this document, we present scenarios from real- 112 life deployments and discuss how the RAMS solution could be used in 113 such scenarios. 115 2. Background 117 In the following discussion, we assume that there are two RTP streams 118 (1 and 2) that are in some manner associated with each other. These 119 could be audio and video elementary streams for the same TV channel, 120 or they could be an MPEG2-TS stream (that has audio and video 121 multiplexed together) and its Forward Error Correction (FEC) stream. 123 An SSM session is defined by its (distribution) source address and 124 (destination) multicast group and there can be only one feedback 125 target per SSM session [RFC5760]. So, if the RTP streams are 126 distributed by different sources or over different multicast groups, 127 they are considered different SSM sessions. While different SSM 128 sessions can normally share the same feedback target address and/or 129 port, RAMS requires each unique feedback target (i.e., the 130 combination of address and port) to be associated with at most one 131 RTP session (See Section 6.2 of [RFC6285]). 133 Two or more multicast RTP streams can be transmitted in the same RTP 134 session (e.g., in a single UDP flow). This is called Synchronization 135 Source (SSRC) multiplexing. In this case, (de)multiplexing is done 136 at the SSRC level. Alternatively, the multicast RTP streams can be 137 transmitted in different RTP sessions (e.g., in different UDP flows), 138 which is called session multiplexing. In practice, there are 139 different deployment models for each multiplexing scheme. 141 Generally, two different media streams with different clock rates are 142 suggested to use different SSRCs or to be carried in different RTP 143 sessions to avoid complications in RTCP reports. Some of the fields 144 in RAMS messages might depend on the clock rate. Thus, in a single 145 RTP session, RTP streams carrying payloads with different clock rates 146 need to have different SSRCs. Since RTP streams with different SSRCs 147 do not share the sequence numbering, each stream needs to be acquired 148 individually. 150 In the remaining sections, only the relevant portions of the SDP 151 descriptions [RFC4566] will be provided. For an example of a full 152 SDP description, refer to Section 8.3 of [RFC6285]. 154 3. Example Scenarios 156 3.1. Scenario #1: Two Multicast Groups 158 This is the scenario for session multiplexing where RTP streams 1 and 159 2 are transmitted over different multicast groups. A practical use 160 case is where the first and second SSM sessions carry the primary 161 video stream and its associated FEC stream, respectively. 163 An individual RAMS sesson is run for each of the RTP streams that 164 requires rapid acquisition. Each requires a separate RAMS Request 165 message to be sent. These RAMS sessions can be run in parallel. If 166 they are, the RTP receiver needs to pay attention to using the shared 167 bandwidth appropriately among the two unicast bursts. As explained 168 earlier, there has to be a different feedback target for these two 169 SSM sessions. 171 v=0 172 o=ali 1122334455 1122334466 IN IP4 rams.example.com 173 s=RAMS Scenarios 174 t=0 0 175 a=group:FEC-FR Channel1_Video Channel1_FEC 176 m=video 40000 RTP/AVPF 96 177 c=IN IP4 233.252.0.1/127 178 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 179 a=rtcp:41000 IN IP4 192.0.2.1 180 a=ssrc:1 cname:ch1_video@example.com 181 a=mid:Channel1_Video 182 m=application 40000 RTP/AVPF 97 183 c=IN IP4 233.252.0.2/127 184 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 185 a=rtcp:42000 IN IP4 192.0.2.1 186 a=ssrc:2 cname:ch1_fec@example.com 187 a=mid:Channel1_FEC 189 Note that the multicast destination ports in the above SDP do not 190 matter, and they could be the same or different. The "FEC-FR" 191 grouping semantics are defined in [RFC5956]. 193 3.2. Scenario #2: One Multicast Group 195 Here RTP streams 1 and 2 are transmitted over the same multicast 196 group with different destination ports. A practical use case is 197 where the SSM session carries the primary video and audio streams, 198 each destined to a different port. 200 The RAMS Request message sent by an RTP receiver to the feedback 201 target could indicate the desire to acquire all or a subset or one of 202 the available RTP streams. Thus, both the primary video and audio 203 streams can be acquired rapidly in parallel. Or, the RTP receiver 204 can acquire only the primary video or audio stream, if desired, by 205 indicating the specific SSRC in the request. Compared to the 206 previous scenario, the only difference is that in this case the join 207 times for both streams need to be coordinated as they are delivered 208 in the same multicast session. 210 v=0 211 o=ali 1122334455 1122334466 IN IP4 rams.example.com 212 s=RAMS Scenarios 213 t=0 0 214 m=video 40000 RTP/AVPF 96 215 c=IN IP4 233.252.0.1/127 216 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 217 a=rtcp:41000 IN IP4 192.0.2.1 218 a=ssrc:1 cname:ch1_video@example.com 219 a=mid:Channel1_Video 220 m=audio 40001 RTP/AVPF 97 221 c=IN IP4 233.252.0.1/127 222 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 223 a=rtcp:41000 IN IP4 192.0.2.1 224 a=ssrc:2 cname:ch1_audio@example.com 225 a=mid:Channel1_Audio 227 Note that the destination ports in "m" lines need to be distinct per 228 [RFC5888]. 230 If RTP streams 1 and 2 share the same distribution source, then there 231 is only one SSM session, which means that there can be only one 232 feedback target (as shown in the SDP description above). This 233 requires RTP streams 1 and 2 to have their own unique SSRC values 234 (also as shown in the SDP description above). If RTP streams 1 and 2 235 do not share the same distribution source, meaning that their 236 respective SSM sessions can use different feedback target transport 237 addresses, then their SSRC values do not have to be different from 238 each other. 240 3.3. Scenario #3: SSRC Multiplexing 242 This is the scenario for SSRC multiplexing where both RTP streams are 243 transmitted over the same multicast group to the same destination 244 port. This is a less practical scenario but it could be used where 245 the SSM session carries both the primary video and audio stream, 246 destined to the same port. 248 Similar to scenario #2, both the primary video and audio streams can 249 be acquired rapidly in parallel. Or, the RTP receiver can acquire 250 only the primary video or audio stream, if desired, by indicating the 251 specific SSRC in the request. In this case, there is only one 252 distribution source and the destination multicast address is shared. 253 Thus, there is always one SSM session and one feedback target. 255 v=0 256 o=ali 1122334455 1122334466 IN IP4 rams.example.com 257 s=RAMS Scenarios 258 t=0 0 259 m=video 40000 RTP/AVPF 96 97 260 c=IN IP4 233.252.0.1/127 261 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 262 a=rtcp:41000 IN IP4 192.0.2.1 263 a=ssrc:1 cname:ch1_video@example.com 264 a=ssrc:2 cname:ch1_audio@example.com 265 a=mid:Channel1 267 3.4. Scenario #4: Payload-Type Multiplexing 269 This is the scenario for payload-type multiplexing. 271 In this case, instead of two, there is only one RTP stream (and one 272 RTP session) carrying both payload types (e.g., media payload and its 273 FEC data). While this scheme is permissible per [RFC3550], it has 274 several drawbacks. For example, RTP packets carrying different 275 payload formats will share the same sequence numbering space, and the 276 RAMS operations will not be able to be applied based on the payload 277 type. For other drawbacks and details, see Section 5.2 of [RFC3550]. 279 4. Feedback Target and SSRC Signaling Issues 281 The RAMS protocol uses the common packet format from [RFC4585], which 282 has a field to signal the media sender SSRC. The SSRCs for the RTP 283 streams can be signaled out-of-band in the SDP, or could be learned 284 from the RTP packets once the transmission starts. In RAMS, the 285 latter cannot be used. 287 Signaling the media sender SSRC value helps the feedback target 288 correctly identify the RTP stream to be acquired. If a feedback 289 target is serving multiple SSM sessions on a particular port, all the 290 RTP streams in these SSM sessions are supposed to have a unique SSRC 291 value. However, this is not an easy requirement to satisfy. Thus, 292 RAMS specification forbids to have more than one RTP session to be 293 associated with a specific feedback target on a specific port. 295 5. FEC during RAMS and Bandwidth Issues 297 Suppose that RTP stream 1 denotes the primary video stream that has a 298 bitrate of 10 Mbps and RTP stream 2 denotes the associated FEC stream 299 that has a bitrate of 1 Mbps. Also assume that the RTP receiver 300 knows that it can receive data at a maximum bitrate of 22 Mbps. SDP 301 can specify the bitrate ("b=" line in Kbps) of each media session 302 (per "m" line). 304 Note that RAMS can potentially congest the network temporarily. 305 Refer to [RFC6285] for detailed discussion. 307 5.1. Scenario #1 309 This is the scenario for session multiplexing where RTP streams 1 and 310 2 are transmitted over different multicast groups. 312 This is the preferred deployment model for FEC [RFC6363]. Having FEC 313 in a different multicast group provides two flexibility points: RTP 314 receivers that are not FEC capable can receive the primary video 315 stream without FEC, and RTP receivers that are FEC capable can decide 316 to not receive FEC during the rapid acquisition (but still start 317 receiving the FEC stream after the acquisition of the primary video 318 stream has been completed). 320 v=0 321 o=ali 1122334455 1122334466 IN IP4 rams.example.com 322 s=RAMS Scenarios 323 t=0 0 324 a=group:FEC-FR Channel1_Video Channel1_FEC 325 m=video 40000 RTP/AVPF 96 326 c=IN IP4 233.252.0.1/127 327 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 328 a=rtcp:41000 IN IP4 192.0.2.1 329 a=rtpmap:96 MP2T/90000 330 b=TIAS:10000 331 a=ssrc:1 cname:ch1_video@example.com 332 a=mid:Channel1_Video 333 m=application 40000 RTP/AVPF 97 334 c=IN IP4 233.252.0.2/127 335 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 336 a=rtcp:42000 IN IP4 192.0.2.1 337 a=rtpmap:97 1d-interleaved-parityfec/90000 338 b=TIAS:1000 339 a=ssrc:2 cname:ch1_fec@example.com 340 a=mid:Channel1_FEC 342 If the RTP receiver does not want to receive FEC until the 343 acquisition of the primary video stream is completed, the total 344 available bandwidth can be used for faster acquisition of the primary 345 video stream. In this case, the RTP receiver can request a Max 346 Receive Bitrate of 22 Mbps in the RAMS Request message for the 347 primary video stream. Once RAMS has been completed, the RTP receiver 348 can join the FEC multicast session, if desired. 350 If the RTP receiver wants to rapidly acquire both primary and FEC 351 streams, it needs to allocate the total bandwidth among the two RAMS 352 sessions and indicate individual Max Receive Bitrate values in each 353 respective RAMS Request message. Since less bandwidth will be used 354 to acquire the primary video stream, the acquisition of the primary 355 video session will take a longer time on the average. 357 While the RTP receiver can update the Max Receive Bitrate values 358 during the course of the RAMS session, this approach is more error- 359 prone due to the possibility of losing the update messages. 361 5.2. Scenario #2 363 Here RTP streams 1 (primary video) and 2 (FEC) are transmitted over 364 the same multicast group with different destination ports. This is 365 not a preferred deployment model. 367 v=0 368 o=ali 1122334455 1122334466 IN IP4 rams.example.com 369 s=RAMS Scenarios 370 t=0 0 371 a=group:FEC-FR Channel1_Video Channel1_FEC 372 m=video 40000 RTP/AVPF 96 373 c=IN IP4 233.252.0.1/127 374 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 375 a=rtcp:41000 IN IP4 192.0.2.1 376 a=rtpmap:96 MP2T/90000 377 b=TIAS:10000 378 a=ssrc:1 cname:ch1_video@example.com 379 a=mid:Channel1_Video 380 m=application 40001 RTP/AVPF 97 381 c=IN IP4 233.252.0.1/127 382 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 383 a=rtcp:41000 IN IP4 192.0.2.1 384 a=rtpmap:97 1d-interleaved-parityfec/90000 385 b=TIAS:1000 386 a=ssrc:2 cname:ch1_fec@example.com 387 a=mid:Channel1_FEC 389 The RAMS Request message sent by an RTP receiver to the feedback 390 target could indicate the desire to acquire all or a subset or one of 391 the available RTP streams. Thus, both the primary video and FEC 392 streams can be acquired rapidly in parallel sharing the same 393 available bandwidth. Or, the RTP receiver can acquire only the 394 primary video stream by indicating its specific SSRC in the request. 396 In this case, the RTP receiver can first acquire the primary video 397 stream at the full receive bitrate. But, upon the multicast join, 398 the available bandwidth for the burst drops to 11 Mbps instead of 12 399 Mbps. Regardless of whether FEC is desired or not by the RTP 400 receiver, its bitrate needs to be taken into account once the RTP 401 receiver joins the SSM session. 403 5.3. Scenario #3 405 This is the scenario for SSRC multiplexing where both RTP streams are 406 transmitted over the same multicast group to the same destination 407 port. 409 v=0 410 o=ali 1122334455 1122334466 IN IP4 rams.example.com 411 s=RAMS Scenarios 412 t=0 0 413 m=video 40000 RTP/AVPF 96 97 414 c=IN IP4 233.252.0.1/127 415 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 416 a=rtcp:41000 IN IP4 192.0.2.1 417 a=rtpmap:96 MP2T/90000 418 a=rtpmap:97 1d-interleaved-parityfec/90000 419 a=fmtp:97 L=10; D=10; repair-window=200000 420 a=ssrc:1 cname:ch1_video@example.com 421 a=ssrc:2 cname:ch1_fec@example.com 422 b=TIAS:11000 423 a=mid:Channel1 425 Similar to scenario #2, both the primary video and audio streams can 426 be acquired rapidly in parallel. Or, the RTP receiver can acquire 427 only the primary video stream, if desired, by indicating its specific 428 SSRC in the request. 430 Note that based on the "a=fmtp" line for the FEC stream, it could be 431 possible to infer the bitrate of this FEC stream and set the Max 432 Receive Bitrate value accordingly. 434 6. Security Considerations 436 Because this document describes deployment scenarios for RAMS, all 437 security considerations are specified in the RAMS specifiction 438 [RFC6285]. 440 7. IANA Considerations 442 There are no IANA considerations in this document. 444 Note to RFC Editor: You can remove this section (7) upon 445 publication. 447 8. Acknowledgments 449 I would like to thank various individuals in the AVTEXT and MMUSIC 450 WGs, and my friends at Cisco for their comments and feedback. 452 9. References 454 9.1. Normative References 456 [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, 457 "Unicast-Based Rapid Acquisition of Multicast RTP 458 Sessions", RFC 6285, June 2011. 460 9.2. Informative References 462 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 463 Jacobson, "RTP: A Transport Protocol for Real-Time 464 Applications", STD 64, RFC 3550, July 2003. 466 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 467 Description Protocol", RFC 4566, July 2006. 469 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 470 "Extended RTP Profile for Real-time Transport Control 471 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 472 July 2006. 474 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 475 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 476 July 2006. 478 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 479 Protocol (RTCP) Extensions for Single-Source Multicast 480 Sessions with Unicast Feedback", RFC 5760, February 2010. 482 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 483 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 485 [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in 486 the Session Description Protocol", RFC 5956, 487 September 2010. 489 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 490 Correction (FEC) Framework", RFC 6363, October 2011. 492 Author's Address 494 Ali Begen 495 Cisco 496 181 Bay Street 497 Toronto, ON M5J 2T3 498 Canada 500 Email: abegen@cisco.com