idnits 2.17.1 draft-begen-avt-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 15, 2011) is 4811 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 (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT A. Begen 3 Internet-Draft Cisco 4 Intended status: Informational February 15, 2011 5 Expires: August 19, 2011 7 Considerations and Guidelines for Deploying the Rapid Acquisition of 8 Multicast RTP Sessions (RAMS) Method 9 draft-begen-avt-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 August 19, 2011. 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. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 64 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Example Scenarios . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. Scenario #1: Two Multicast Groups . . . . . . . . . . . . 4 67 4.2. Scenario #2: One Multicast Group . . . . . . . . . . . . . 5 68 4.3. Scenario #3: SSRC Multiplexing . . . . . . . . . . . . . . 6 69 4.4. Scenario #4: Payload-Type Multiplexing . . . . . . . . . . 7 70 5. Feedback Target and SSRC Signaling Issues . . . . . . . . . . 7 71 6. FEC during RAMS and Bandwidth Issues . . . . . . . . . . . . . 7 72 6.1. Scenario #1 . . . . . . . . . . . . . . . . . . . . . . . 8 73 6.2. Scenario #2 . . . . . . . . . . . . . . . . . . . . . . . 9 74 6.3. Scenario #3 . . . . . . . . . . . . . . . . . . . . . . . 9 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 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 93 [I-D.ietf-avt-rapid-acquisition-for-rtp]. 95 The RAMS specification [I-D.ietf-avt-rapid-acquisition-for-rtp] has 96 provisions for concurrently acquiring multiple streams inside a 97 multicast RTP session. However, the specification has mostly focused 98 on the simplest case, which is when the RTP receiver acquires only 99 one multicast stream at a time, to explain the protocol details. 101 There are certain deployment models where a multicast RTP session may 102 have two or more multicast streams associated with it. There are 103 also cases, where an RTP receiver may be interested in acquiring one 104 or more multicast streams from several multicast RTP sessions. In 105 scenarios where multiple RAMS sessions will be simultaneously run by 106 an RTP receiver, they need to be coordinated. In this document, we 107 present scenarios from real-life deployments and provide guidelines. 109 2. Requirements Notation 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in 114 [RFC2119]. 116 Editor's note: I am inclined not use any 2119 keyword in this 117 document and remove this section altogether. 119 3. Background 121 In the following discussion, we assume that there are two RTP streams 122 (1 and 2) that are somehow associated with each other. These could 123 be audio and video elementary streams for the same TV channel, or 124 they could be an MPEG2-TS stream (that has audio and video 125 multiplexed together) and its Forward Error Correction (FEC) stream. 127 It is important to note that a source-specific multicast (SSM) 128 session is defined by its (distribution) source address and 129 (destination) multicast group and there can be only one feedback 130 target per SSM session [RFC5760]. So, if the RTP streams are 131 distributed by different sources or over different multicast groups, 132 they are considered different SSM sessions. While different SSM 133 sessions can normally share the same feedback target address and/or 134 port, RAMS requires each unique feedback target (i.e., the 135 combination of address and port) to be associated with at most one 136 RTP session (See Section 6.2 of 137 [I-D.ietf-avt-rapid-acquisition-for-rtp]). 139 Two or more multicast RTP streams can be transmitted in the same RTP 140 session (i.e., in a single UDP flow). This is called Synchronization 141 Source (SSRC) multiplexing. In this case, (de)multiplexing is done 142 at the SSRC level. Alternatively, the multicast RTP streams can be 143 transmitted in different RTP sessions (i.e., in different UDP flows), 144 which is called session multiplexing. In practice, there are 145 different deployment models for each multiplexing scheme. 147 Generally, two different media streams with different clock rates are 148 suggested to use different SSRCs or to be carried in different RTP 149 sessions to avoid complications in RTCP reports. Some of the fields 150 in RAMS messages might depend on the clock rate. Thus, in a single 151 RTP session, RTP streams carrying payloads with different clock rates 152 need to have different SSRCs. Since RTP streams in the same RTP 153 session but with different SSRCs do not share the sequence numbering, 154 each stream needs to be acquired individually. 156 In the remaining sections, only the relevant portions of the SDP 157 descriptions [RFC4566] will be provided. For an example of a full 158 SDP description, refer to Section 8.3 of 159 [I-D.ietf-avt-rapid-acquisition-for-rtp]. 161 4. Example Scenarios 163 4.1. Scenario #1: Two Multicast Groups 165 This is the scenario for session multiplexing where RTP streams 1 and 166 2 are transmitted over different multicast groups. A practical use 167 case is where the first and second SSM sessions carry the primary 168 video stream and its associated FEC stream, respectively. 170 We run an individual RAMS session for each of these RTP streams that 171 we want to rapidly acquire. These RAMS sessions can be run in 172 parallel. If they are, the RTP receiver needs to pay attention to 173 using the shared bandwidth appropriately among the two unicast 174 bursts. As explained earlier, there has to be a different feedback 175 target for these two SSM sessions. 177 a=group:FEC-FR Channel1_Video Channel1_FEC 178 m=video 40000 RTP/AVPF 96 179 c=IN IP4 233.252.0.1/127 180 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 181 a=rtcp:41000 IN IP4 192.0.2.1 182 a=ssrc:1 cname:ch1_video@example.com 183 a=mid:Channel1_Video 184 m=application 40000 RTP/AVPF 97 185 c=IN IP4 233.252.0.2/127 186 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 187 a=rtcp:42000 IN IP4 192.0.2.1 188 a=ssrc:2 cname:ch1_fec@example.com 189 a=mid:Channel1_FEC 191 Note that the multicast destination ports in the above SDP do not 192 matter, and they could be the same or different. The "FEC-FR" 193 grouping semantics are defined in [RFC5956]. 195 4.2. Scenario #2: One Multicast Group 197 This is the scenario for session multiplexing where RTP streams 1 and 198 2 are transmitted over the same multicast group with different 199 destination ports. A practical use case is where the SSM session 200 carries the primary video and audio streams, each destined to a 201 different port. 203 Similar to scenario #1, we run individual RAMS sessions for each RTP 204 stream that we want to rapidly acquire (Note that the RAMS request 205 sent by an RTP receiver could indicate the desire to acquire all or a 206 subset or one of the available RTP streams in an SSM session). 207 Compared to the previous scenario, the only difference is that in 208 this case the join times for both streams need to be coordinated as 209 they are on the same multicast session. 211 m=video 40000 RTP/AVPF 96 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:1 cname:ch1_video@example.com 216 a=mid:Channel1_Video 217 m=audio 40001 RTP/AVPF 97 218 c=IN IP4 233.252.0.1/127 219 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 220 a=rtcp:41000 IN IP4 192.0.2.1 221 a=ssrc:2 cname:ch1_audio@example.com 222 a=mid:Channel1_Audio 224 Note that the destination ports in the above SDP need to be distinct 225 per [RFC5888]. 227 If RTP streams 1 and 2 share the same distribution source, then there 228 is only one SSM session, which means that there can be only one 229 feedback target (as shown in the SDP description above). This 230 requires RTP streams 1 and 2 to have their own unique SSRC values 231 (also as shown in the SDP description above). If RTP streams 1 and 2 232 do not share the same distribution source, meaning that their 233 respective SSM sessions can use different feedback target transport 234 addresses, then their SSRC values do not have to be different from 235 each other. 237 4.3. Scenario #3: SSRC Multiplexing 239 This is the scenario for SSRC multiplexing where both RTP streams are 240 transmitted over the same multicast group to the same destination 241 port. This is a less practical scenario but it could be used where 242 the SSM session carries both the primary video and audio stream, 243 destined to the same port. 245 Similar to scenario #2, we run individual RAMS sessions and the join 246 time needs to be coordinated. In this case, there is only one 247 distribution source and the destination multicast address is shared. 248 Thus, there is always one SSM session and one feedback target. 250 m=video 40000 RTP/AVPF 96 97 251 c=IN IP4 233.252.0.1/127 252 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 253 a=rtcp:41000 IN IP4 192.0.2.1 254 a=ssrc:1 cname:ch1_video@example.com 255 a=ssrc:2 cname:ch1_audio@example.com 256 a=mid:Channel1 258 4.4. Scenario #4: Payload-Type Multiplexing 260 This is the scenario for payload-type multiplexing. 262 In this case, instead of two, we have only one RTP stream (and one 263 RTP session) carrying both payload types (e.g., media payload and its 264 FEC data). While this scheme is permissible per [RFC3550], it has 265 several drawbacks. For example, RTP packets carrying different 266 payload formats will share the same sequence numbering space, and the 267 retransmission and RAMS operations will not be able to be applied 268 based on the payload type. For other drawbacks and details, see 269 Section 5.2 of [RFC3550]. 271 5. Feedback Target and SSRC Signaling Issues 273 The RAMS protocol uses the common packet format from [RFC4585], which 274 has a field to signal the media sender SSRC. The SSRCs for the RTP 275 streams can be signaled out-of-band in the SDP, or could be learned 276 from the RTP packets once the transmission starts. In RAMS, the 277 latter cannot be used. 279 Signaling the media sender SSRC value helps the feedback target 280 correctly identify the RTP stream to be acquired. If a feedback 281 target is serving multiple SSM sessions on a particular port, all the 282 RTP streams in these SSM sessions are supposed to have a unique SSRC 283 value. However, since this is not an easy requirement to satisfy, 284 RAMS specification forbids to have more than one RTP session to be 285 associated with a specific feedback target. 287 6. FEC during RAMS and Bandwidth Issues 289 Suppose that RTP stream 1 denotes the primary video stream that has a 290 bitrate of 10 Mbps and RTP stream 2 denotes the FEC stream that has a 291 bitrate of 1 Mbps. Also assume that the RTP receiver knows that it 292 can receive data at a maximum bitrate of 22 Mbps. SDP can specify 293 the bitrate ("b=" line in Kbps) of each media session (per "m" line). 295 6.1. Scenario #1 297 This is the scenario for session multiplexing where RTP streams 1 and 298 2 are transmitted over different multicast groups. 300 This is the preferred deployment model for FEC. Having FEC in a 301 different multicast group provides flexibility for not only the RTP 302 receivers that are not FEC capable but also the ones that are FEC 303 capable but are not willing to receive FEC during the rapid 304 acquisition. 306 a=group:FEC-FR Channel1_Video Channel1_FEC 307 m=video 40000 RTP/AVPF 96 308 c=IN IP4 233.252.0.1/127 309 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 310 a=rtcp:41000 IN IP4 192.0.2.1 311 a=rtpmap:96 MP2T/90000 312 b=TIAS:10000 313 a=ssrc:1 cname:ch1_video@example.com 314 a=mid:Channel1_Video 315 m=application 40000 RTP/AVPF 97 316 c=IN IP4 233.252.0.2/127 317 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 318 a=rtcp:42000 IN IP4 192.0.2.1 319 a=rtpmap:97 1d-interleaved-parityfec/90000 320 b=TIAS:1000 321 a=ssrc:2 cname:ch1_fec@example.com 322 a=mid:Channel1_FEC 324 If the RTP receiver does not want to receive FEC until the 325 acquisition of the primary video stream is completed, the total 326 available bandwidth can be used for faster acquisition of the primary 327 video stream. In this case, the RTP receiver can request a Max 328 Receive Bitrate of 22 Mbps in the RAMS Request message. Once RAMS 329 has been completed, the RTP receiver can join the FEC multicast 330 session, if desired. 332 If the RTP receiver wants to rapidly acquire both primary and FEC 333 streams, it needs to allocate the total bandwidth among the two RAMS 334 sessions and indicate individual Max Receive Bitrate values in each 335 respective RAMS Request message. Since less bandwidth will be used 336 to acquire the primary video stream, the acquisition of the primary 337 video session will take a longer time on the average. 339 While the RTP receiver can update the Max Receive Bitrate values 340 during the course of the RAMS session, this approach is more error- 341 prone due to the possibility of losing the update messages. 343 6.2. Scenario #2 345 This is the scenario for session multiplexing where RTP streams 1 and 346 2 are transmitted over the same multicast group with different 347 destination ports. 349 a=group:FEC-FR Channel1_Video Channel1_FEC 350 m=video 40000 RTP/AVPF 96 351 c=IN IP4 233.252.0.1/127 352 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 353 a=rtcp:41000 IN IP4 192.0.2.1 354 a=rtpmap:96 MP2T/90000 355 b=TIAS:10000 356 a=ssrc:1 cname:ch1_video@example.com 357 a=mid:Channel1_Video 358 m=application 40001 RTP/AVPF 97 359 c=IN IP4 233.252.0.1/127 360 a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 361 a=rtcp:41000 IN IP4 192.0.2.1 362 a=rtpmap:97 1d-interleaved-parityfec/90000 363 b=TIAS:1000 364 a=ssrc:2 cname:ch1_fec@example.com 365 a=mid:Channel1_FEC 367 Similar to scenario #1, the RTP receiver can first ask for RAMS for 368 the primary video stream at the full receive bitrate. But, upon the 369 multicast join, the available bandwidth for the burst drops to 11 370 Mbps instead of 12 Mbps. Regardless of whether FEC is desired or not 371 by the RTP receiver, its bitrate needs to be taken into account once 372 the RTP receiver joins the SSM session. 374 If the RTP receiver wants to rapidly acquire both primary and FEC 375 streams, the same conditions explained for scenario #1 apply. The 376 only difference from scenario #1 is that here the join time is the 377 same for both the primary video and FEC streams. 379 6.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 a=mid:Channel1 395 b=TIAS:11000 396 a=mid:Channel1 398 This is similar to scenario #2. However, since we cannot explicitly 399 specify the bitrates for the primary and FEC streams, the RTP 400 receiver can request to rapidly acquire both streams in parallel. In 401 this case, two separate RAMS Request messages have to be sent by the 402 RTP receiver to the feedback target. 404 Note that based on the "a=fmtp" line for the FEC stream, it could be 405 possible to infer the bitrate of this FEC stream and set the Max 406 Receive Bitrate value accordingly. 408 7. Security Considerations 410 There are no security considerations in this document. 412 8. IANA Considerations 414 There are no IANA considerations in this document. 416 9. Acknowledgments 418 I would like to thank various individuals in the AVT and MMUSIC WGs, 419 and my friends at Cisco for their comments and feedback. 421 10. References 423 10.1. Normative References 425 [I-D.ietf-avt-rapid-acquisition-for-rtp] 426 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 427 Based Rapid Acquisition of Multicast RTP Sessions", 428 draft-ietf-avt-rapid-acquisition-for-rtp-17 (work in 429 progress), November 2010. 431 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 432 Jacobson, "RTP: A Transport Protocol for Real-Time 433 Applications", STD 64, RFC 3550, July 2003. 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, March 1997. 438 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 439 Description Protocol", RFC 4566, July 2006. 441 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 442 "Extended RTP Profile for Real-time Transport Control 443 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 444 July 2006. 446 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 447 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 448 July 2006. 450 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 451 Protocol (RTCP) Extensions for Single-Source Multicast 452 Sessions with Unicast Feedback", RFC 5760, February 2010. 454 10.2. Informative References 456 [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description 457 Protocol (SDP) Grouping Framework", RFC 5888, June 2010. 459 [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in 460 the Session Description Protocol", RFC 5956, 461 September 2010. 463 Author's Address 465 Ali Begen 466 Cisco 467 181 Bay Street 468 Toronto, ON M5J 2T3 469 Canada 471 Email: abegen@cisco.com