idnits 2.17.1 draft-ietf-avtext-rams-scenarios-01.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 (October 11, 2011) is 4580 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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 October 11, 2011 5 Expires: April 13, 2012 7 Considerations for Deploying the Rapid Acquisition of Multicast RTP 8 Sessions (RAMS) Method 9 draft-ietf-avtext-rams-scenarios-01 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 offers guidelines. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 13, 2012. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Scenario #1: Two Multicast Groups . . . . . . . . . . . . 4 66 3.2. Scenario #2: One Multicast Group . . . . . . . . . . . . . 5 67 3.3. Scenario #3: SSRC Multiplexing . . . . . . . . . . . . . . 6 68 3.4. Scenario #4: Payload-Type Multiplexing . . . . . . . . . . 7 69 4. Feedback Target and SSRC Signaling Issues . . . . . . . . . . 7 70 5. FEC during RAMS and Bandwidth Issues . . . . . . . . . . . . . 7 71 5.1. Scenario #1 . . . . . . . . . . . . . . . . . . . . . . . 8 72 5.2. Scenario #2 . . . . . . . . . . . . . . . . . . . . . . . 9 73 5.3. Scenario #3 . . . . . . . . . . . . . . . . . . . . . . . 9 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a 85 method based on RTP and RTP Control Protocol (RTCP) that enables an 86 RTP receiver to rapidly acquire and start consuming the RTP multicast 87 data. Through an auxiliary unicast RTP retransmission session 88 [RFC4588], the RTP receiver receives a reference information about 89 the new multicast stream it is about to join. This often precedes, 90 but may also accompany, the multicast stream itself. The RAMS 91 solution is documented in detail in [RFC6285]. 93 The RAMS specification [RFC6285] has provisions for concurrently 94 acquiring multiple streams inside a multicast RTP session. However, 95 the specification does not discuss scenarios where an RTP receiver 96 makes use of the RAMS method to rapidly acquire multiple and 97 associated multicast streams in parallel, or where different RTP 98 sessions are part of the same source-specific multicast (SSM) 99 session. The example presented in Section 8.3 of [RFC6285] addresses 100 only the simple case of an RTP receiver rapidly acquiring only one 101 multicast stream to explain the protocol details. 103 There are certain deployment models where a multicast RTP session may 104 have two or more multicast streams associated with it. There are 105 also cases, where an RTP receiver may be interested in acquiring one 106 or more multicast streams from several multicast RTP sessions. In 107 scenarios where multiple RAMS sessions, each initiated with an 108 individual RAMS Request message to a different feedback target, will 109 be simultaneously run by an RTP receiver, they need to be 110 coordinated. In this document, we present scenarios from real-life 111 deployments and provide guidelines. 113 2. Background 115 In the following discussion, we assume that there are two RTP streams 116 (1 and 2) that are somehow associated with each other. These could 117 be audio and video elementary streams for the same TV channel, or 118 they could be an MPEG2-TS stream (that has audio and video 119 multiplexed together) and its Forward Error Correction (FEC) stream. 121 It is important to note that an SSM session is defined by its 122 (distribution) source address and (destination) multicast group and 123 there can be only one feedback target per SSM session [RFC5760]. So, 124 if the RTP streams are distributed by different sources or over 125 different multicast groups, they are considered different SSM 126 sessions. While different SSM sessions can normally share the same 127 feedback target address and/or port, RAMS requires each unique 128 feedback target (i.e., the combination of address and port) to be 129 associated with at most one RTP session (See Section 6.2 of 130 [RFC6285]). 132 Two or more multicast RTP streams can be transmitted in the same RTP 133 session (e.g., in a single UDP flow). This is called Synchronization 134 Source (SSRC) multiplexing. In this case, (de)multiplexing is done 135 at the SSRC level. Alternatively, the multicast RTP streams can be 136 transmitted in different RTP sessions (e.g., in different UDP flows), 137 which is called session multiplexing. In practice, there are 138 different deployment models for each multiplexing scheme. 140 Generally, two different media streams with different clock rates are 141 suggested to use different SSRCs or to be carried in different RTP 142 sessions to avoid complications in RTCP reports. Some of the fields 143 in RAMS messages might depend on the clock rate. Thus, in a single 144 RTP session, RTP streams carrying payloads with different clock rates 145 need to have different SSRCs. Since RTP streams with different SSRCs 146 do not share the sequence numbering, each stream needs to be acquired 147 individually. 149 In the remaining sections, only the relevant portions of the SDP 150 descriptions [RFC4566] will be provided. For an example of a full 151 SDP description, refer to Section 8.3 of [RFC6285]. 153 3. Example Scenarios 155 3.1. Scenario #1: Two Multicast Groups 157 This is the scenario for session multiplexing where RTP streams 1 and 158 2 are transmitted over different multicast groups. A practical use 159 case is where the first and second SSM sessions carry the primary 160 video stream and its associated FEC stream, respectively. 162 We run an individual RAMS session for each of these RTP streams that 163 we want to rapidly acquire. Each requires a separate RAMS Request 164 message to be sent. These RAMS sessions can be run in parallel. If 165 they are, the RTP receiver needs to pay attention to using the shared 166 bandwidth appropriately among the two unicast bursts. As explained 167 earlier, there has to be a different feedback target for these two 168 SSM sessions. 170 a=group:FEC-FR Channel1_Video Channel1_FEC 171 m=video 40000 RTP/AVPF 96 172 c=IN IP4 233.252.0.1/127 173 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 174 a=rtcp:41000 IN IP4 192.0.2.1 175 a=ssrc:1 cname:ch1_video@example.com 176 a=mid:Channel1_Video 177 m=application 40000 RTP/AVPF 97 178 c=IN IP4 233.252.0.2/127 179 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 180 a=rtcp:42000 IN IP4 192.0.2.1 181 a=ssrc:2 cname:ch1_fec@example.com 182 a=mid:Channel1_FEC 184 Note that the multicast destination ports in the above SDP do not 185 matter, and they could be the same or different. The "FEC-FR" 186 grouping semantics are defined in [RFC5956]. 188 3.2. Scenario #2: One Multicast Group 190 Here RTP streams 1 and 2 are transmitted over the same multicast 191 group with different destination ports. A practical use case is 192 where the SSM session carries the primary video and audio streams, 193 each destined to a different port. 195 The RAMS Request message sent by an RTP receiver to the feedback 196 target could indicate the desire to acquire all or a subset or one of 197 the available RTP streams. Thus, both the primary video and audio 198 streams can be acquired rapidly in parallel. Or, the RTP receiver 199 can acquire only the primary video or audio stream, if desired, by 200 indicating the specific SSRC in the request. Compared to the 201 previous scenario, the only difference is that in this case the join 202 times for both streams need to be coordinated as they are delivered 203 in the same multicast session. 205 m=video 40000 RTP/AVPF 96 206 c=IN IP4 233.252.0.1/127 207 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 208 a=rtcp:41000 IN IP4 192.0.2.1 209 a=ssrc:1 cname:ch1_video@example.com 210 a=mid:Channel1_Video 211 m=audio 40001 RTP/AVPF 97 212 c=IN IP4 233.252.0.1/127 213 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 214 a=rtcp:41000 IN IP4 192.0.2.1 215 a=ssrc:2 cname:ch1_audio@example.com 216 a=mid:Channel1_Audio 218 Note that the destination ports in "m" lines need to be distinct per 219 [RFC5888]. 221 If RTP streams 1 and 2 share the same distribution source, then there 222 is only one SSM session, which means that there can be only one 223 feedback target (as shown in the SDP description above). This 224 requires RTP streams 1 and 2 to have their own unique SSRC values 225 (also as shown in the SDP description above). If RTP streams 1 and 2 226 do not share the same distribution source, meaning that their 227 respective SSM sessions can use different feedback target transport 228 addresses, then their SSRC values do not have to be different from 229 each other. 231 3.3. Scenario #3: SSRC Multiplexing 233 This is the scenario for SSRC multiplexing where both RTP streams are 234 transmitted over the same multicast group to the same destination 235 port. This is a less practical scenario but it could be used where 236 the SSM session carries both the primary video and audio stream, 237 destined to the same port. 239 Similar to scenario #2, both the primary video and audio streams can 240 be acquired rapidly in parallel. Or, the RTP receiver can acquire 241 only the primary video or audio stream, if desired, by indicating the 242 specific SSRC in the request. In this case, there is only one 243 distribution source and the destination multicast address is shared. 244 Thus, there is always one SSM session and one feedback target. 246 m=video 40000 RTP/AVPF 96 97 247 c=IN IP4 233.252.0.1/127 248 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 249 a=rtcp:41000 IN IP4 192.0.2.1 250 a=ssrc:1 cname:ch1_video@example.com 251 a=ssrc:2 cname:ch1_audio@example.com 252 a=mid:Channel1 254 3.4. Scenario #4: Payload-Type Multiplexing 256 This is the scenario for payload-type multiplexing. 258 In this case, instead of two, we have only one RTP stream (and one 259 RTP session) carrying both payload types (e.g., media payload and its 260 FEC data). While this scheme is permissible per [RFC3550], it has 261 several drawbacks. For example, RTP packets carrying different 262 payload formats will share the same sequence numbering space, and the 263 RAMS operations will not be able to be applied based on the payload 264 type. For other drawbacks and details, see Section 5.2 of [RFC3550]. 266 4. Feedback Target and SSRC Signaling Issues 268 The RAMS protocol uses the common packet format from [RFC4585], which 269 has a field to signal the media sender SSRC. The SSRCs for the RTP 270 streams can be signaled out-of-band in the SDP, or could be learned 271 from the RTP packets once the transmission starts. In RAMS, the 272 latter cannot be used. 274 Signaling the media sender SSRC value helps the feedback target 275 correctly identify the RTP stream to be acquired. If a feedback 276 target is serving multiple SSM sessions on a particular port, all the 277 RTP streams in these SSM sessions are supposed to have a unique SSRC 278 value. However, since this is not an easy requirement to satisfy, 279 RAMS specification forbids to have more than one RTP session to be 280 associated with a specific feedback target on a specific port. 282 5. FEC during RAMS and Bandwidth Issues 284 Suppose that RTP stream 1 denotes the primary video stream that has a 285 bitrate of 10 Mbps and RTP stream 2 denotes the associated FEC stream 286 that has a bitrate of 1 Mbps. Also assume that the RTP receiver 287 knows that it can receive data at a maximum bitrate of 22 Mbps. SDP 288 can specify the bitrate ("b=" line in Kbps) of each media session 289 (per "m" line). 291 5.1. Scenario #1 293 This is the scenario for session multiplexing where RTP streams 1 and 294 2 are transmitted over different multicast groups. 296 This is the preferred deployment model for FEC 297 [I-D.ietf-fecframe-framework]. Having FEC in a different multicast 298 group provides two flexibility points: RTP receivers that are not 299 FEC capable can receive the primary video stream without FEC, and RTP 300 receivers that are FEC capable can decide to not receive FEC during 301 the rapid acquisition (but still start receiving the FEC stream after 302 the acquisition of the primary video stream has been completed). 304 a=group:FEC-FR Channel1_Video Channel1_FEC 305 m=video 40000 RTP/AVPF 96 306 c=IN IP4 233.252.0.1/127 307 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 308 a=rtcp:41000 IN IP4 192.0.2.1 309 a=rtpmap:96 MP2T/90000 310 b=TIAS:10000 311 a=ssrc:1 cname:ch1_video@example.com 312 a=mid:Channel1_Video 313 m=application 40000 RTP/AVPF 97 314 c=IN IP4 233.252.0.2/127 315 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 316 a=rtcp:42000 IN IP4 192.0.2.1 317 a=rtpmap:97 1d-interleaved-parityfec/90000 318 b=TIAS:1000 319 a=ssrc:2 cname:ch1_fec@example.com 320 a=mid:Channel1_FEC 322 If the RTP receiver does not want to receive FEC until the 323 acquisition of the primary video stream is completed, the total 324 available bandwidth can be used for faster acquisition of the primary 325 video stream. In this case, the RTP receiver can request a Max 326 Receive Bitrate of 22 Mbps in the RAMS Request message for the 327 primary video stream. Once RAMS has been completed, the RTP receiver 328 can join the FEC multicast session, if desired. 330 If the RTP receiver wants to rapidly acquire both primary and FEC 331 streams, it needs to allocate the total bandwidth among the two RAMS 332 sessions and indicate individual Max Receive Bitrate values in each 333 respective RAMS Request message. Since less bandwidth will be used 334 to acquire the primary video stream, the acquisition of the primary 335 video session will take a longer time on the average. 337 While the RTP receiver can update the Max Receive Bitrate values 338 during the course of the RAMS session, this approach is more error- 339 prone due to the possibility of losing the update messages. 341 5.2. Scenario #2 343 Here RTP streams 1 (primary video) and 2 (FEC) are transmitted over 344 the same multicast group with different destination ports. This is 345 not a preferred deployment model. 347 a=group:FEC-FR Channel1_Video Channel1_FEC 348 m=video 40000 RTP/AVPF 96 349 c=IN IP4 233.252.0.1/127 350 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 351 a=rtcp:41000 IN IP4 192.0.2.1 352 a=rtpmap:96 MP2T/90000 353 b=TIAS:10000 354 a=ssrc:1 cname:ch1_video@example.com 355 a=mid:Channel1_Video 356 m=application 40001 RTP/AVPF 97 357 c=IN IP4 233.252.0.1/127 358 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 359 a=rtcp:41000 IN IP4 192.0.2.1 360 a=rtpmap:97 1d-interleaved-parityfec/90000 361 b=TIAS:1000 362 a=ssrc:2 cname:ch1_fec@example.com 363 a=mid:Channel1_FEC 365 The RAMS Request message sent by an RTP receiver to the feedback 366 target could indicate the desire to acquire all or a subset or one of 367 the available RTP streams. Thus, both the primary video and FEC 368 streams can be acquired rapidly in parallel sharing the same 369 available bandwidth. Or, the RTP receiver can acquire only the 370 primary video stream by indicating its specific SSRC in the request 371 (Acquiring only the FEC stream without the primary video stream is 372 not practical). In this case, the RTP receiver can first acquire the 373 primary video stream at the full receive bitrate. But, upon the 374 multicast join, the available bandwidth for the burst drops to 11 375 Mbps instead of 12 Mbps. Regardless of whether FEC is desired or not 376 by the RTP receiver, its bitrate needs to be taken into account once 377 the RTP receiver joins the SSM session. 379 5.3. Scenario #3 381 This is the scenario for SSRC multiplexing where both RTP streams are 382 transmitted over the same multicast group to the same destination 383 port. 385 m=video 40000 RTP/AVPF 96 97 386 c=IN IP4 233.252.0.1/127 387 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 388 a=rtcp:41000 IN IP4 192.0.2.1 389 a=rtpmap:96 MP2T/90000 390 a=rtpmap:97 1d-interleaved-parityfec/90000 391 a=fmtp:97 L=10; D=10; repair-window=200000 392 a=ssrc:1 cname:ch1_video@example.com 393 a=ssrc:2 cname:ch1_fec@example.com 394 b=TIAS:11000 395 a=mid:Channel1 397 Similar to scenario #2, both the primary video and audio streams can 398 be acquired rapidly in parallel. Or, the RTP receiver can acquire 399 only the primary video stream, if desired, by indicating its specific 400 SSRC in the request. 402 Note that based on the "a=fmtp" line for the FEC stream, it could be 403 possible to infer the bitrate of this FEC stream and set the Max 404 Receive Bitrate value accordingly. 406 6. Security Considerations 408 There are no security considerations in this document. 410 7. IANA Considerations 412 There are no IANA considerations in this document. 414 8. Acknowledgments 416 I would like to thank various individuals in the AVTEXT and MMUSIC 417 WGs, and my friends at Cisco for their comments and feedback. 419 9. References 421 9.1. Normative References 423 [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, 424 "Unicast-Based Rapid Acquisition of Multicast RTP 425 Sessions", RFC 6285, June 2011. 427 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 428 Jacobson, "RTP: A Transport Protocol for Real-Time 429 Applications", STD 64, RFC 3550, July 2003. 431 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 432 Description Protocol", RFC 4566, July 2006. 434 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 435 "Extended RTP Profile for Real-time Transport Control 436 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 437 July 2006. 439 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 440 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 441 July 2006. 443 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 444 Protocol (RTCP) Extensions for Single-Source Multicast 445 Sessions with Unicast Feedback", RFC 5760, February 2010. 447 9.2. Informative References 449 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 450 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 452 [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in 453 the Session Description Protocol", RFC 5956, 454 September 2010. 456 [I-D.ietf-fecframe-framework] 457 Watson, M., Begen, A., and V. Roca, "Forward Error 458 Correction (FEC) Framework", 459 draft-ietf-fecframe-framework-15 (work in progress), 460 June 2011. 462 Author's Address 464 Ali Begen 465 Cisco 466 181 Bay Street 467 Toronto, ON M5J 2T3 468 Canada 470 Email: abegen@cisco.com