idnits 2.17.1 draft-begen-avt-rams-scenarios-00.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.ii 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 date (October 1, 2009) is 5314 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-avt-rapid-acquisition-for-rtp-03 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-19) exists of draft-ietf-avt-rtcpssm-18 == Outdated reference: A later version (-04) exists of draft-ietf-mmusic-rfc3388bis-03 Summary: 2 errors (**), 0 flaws (~~), 4 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 Systems 4 Intended status: Informational October 1, 2009 5 Expires: April 4, 2010 7 Considerations for RAMS Scenarios 8 draft-begen-avt-rams-scenarios-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 4, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a 47 method based on RTP and RTCP protocol family that enables an RTP 48 receiver to rapidly acquire and start usefully consuming the RTP 49 multicast data. Upon a request from the RTP receiver, an auxiliary 50 unicast RTP retransmission session is set up between a retransmission 51 server and the RTP receiver, over which the reference information 52 about the new multicast stream the RTP receiver is about to join is 53 transmitted at an accelerated pace. This often precedes, but may 54 also accompany, the multicast stream itself. When there is only one 55 multicast stream to be acquired, the RAMS solution works in a 56 straightforward manner. However, when there are two or more 57 multicast streams to be acquired from the same or different multicast 58 RTP sessions, care should be taken to configure each RAMS 59 appropriately. This document provides example scenarios and make 60 practical recommendations. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 66 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Illustrative Scenarios . . . . . . . . . . . . . . . . . . . . 4 68 4.1. Scenario #1 . . . . . . . . . . . . . . . . . . . . . . . 4 69 4.2. Scenario #2 . . . . . . . . . . . . . . . . . . . . . . . 5 70 4.3. Scenario #3 . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.4. Scenario #4 . . . . . . . . . . . . . . . . . . . . . . . 6 72 5. Feedback Target and SSRC Signaling Issues . . . . . . . . . . 6 73 6. FEC during RAMS and Bandwidth Issues . . . . . . . . . . . . . 7 74 6.1. Scenario #1 . . . . . . . . . . . . . . . . . . . . . . . 7 75 6.2. Scenario #2 . . . . . . . . . . . . . . . . . . . . . . . 8 76 6.3. Scenario #3 . . . . . . . . . . . . . . . . . . . . . . . 9 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a 87 method based on RTP and RTCP protocol family that enables an RTP 88 receiver to rapidly acquire and start usefully consuming the RTP 89 multicast data. Through an auxiliary unicast RTP retransmission 90 session [RFC4588], the RTP receiver receives a reference information 91 about the new multicast stream it is about to join. This often 92 precedes, but may also accompany, the multicast stream itself. The 93 RAMS solution is documented in detail in 94 [I-D.ietf-avt-rapid-acquisition-for-rtp]. 96 To focus on the protocol details, the RAMS specification 97 [I-D.ietf-avt-rapid-acquisition-for-rtp] has only considered the 98 simplest case, which is that the RTP receiver acquires only one 99 multicast stream at a time. However, there are many applications 100 where a multicast RTP session may have two or more multicast streams 101 associated with it. There are also cases, where an RTP receiver may 102 be interested in acquiring one or more multicast streams from 103 multiple multicast RTP sessions. In scenarios where multiple RAMS 104 sessions will be simultaneously run by the RTP receiver, care should 105 be taken to coordinate them. In this document, we provide scenarios 106 from real-life deployments and make recommendations. 108 2. Requirements Notation 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 3. Background 116 In the following, we assume that there are two RTP streams (1 and 2) 117 that are somehow associated with each other. These could be audio 118 and video elementary streams for the same TV channel, or they could 119 be an MPEG2-TS stream and its Forward Error Correction (FEC) stream. 121 It is important to note that a source-specific multicast (SSM) 122 session is defined by its (distribution) source address and 123 (destination) multicast group and there can be only one feedback 124 target per SSM session [I-D.ietf-avt-rtcpssm]. So, if the RTP 125 streams are distributed by different sources or over different 126 multicast groups, they have to be in different SSM sessions. 127 Different SSM sessions may share the same feedback target address 128 and/or port. 130 Different multicast RTP streams can be transmitted in the same RTP 131 session (i.e., in a single UDP flow). This is called SSRC 132 multiplexing. In this case, (de)multiplexing is done at the SSRC 133 level. Alternatively, different multicast RTP streams can be 134 transmitted in different RTP sessions (i.e., in different UDP flows), 135 which is called session multiplexing. In practice, there are 136 different deployment models for each multiplexing scheme. 138 It is also important to note that two different media streams with 139 different clock rates should use different SSRCs or RTP sessions to 140 avoid complications in RTCP reports. Some of the fields in RAMS 141 messages depend on the clock rate. Thus, in a single RTP session, 142 RTP streams carrying payloads with different clock rates should have 143 different SSRCs. Since RTP streams in the same RTP session but with 144 different SSRCs do not share the sequence numbering, each stream 145 needs to be acquired individually. 147 In the following, only the relevant portions of the SDP descriptions 148 [RFC4566] will be provided. 150 4. Illustrative Scenarios 152 4.1. Scenario #1 154 This is the scenario for session multiplexing where RTP streams 1 and 155 2 are transmitted over different multicast groups. A practical use 156 case is where the first and second SSM session carries the primary 157 video stream and its associated FEC stream, respectively. 159 We run an individual RAMS session for each RTP stream that we want to 160 rapidly acquire. These RAMS sessions MAY run in parallel. If they 161 are, the RTP receiver needs to pay attention to using the shared 162 bandwidth appropriately among different RAMS sessions. Note that 163 there may be different feedback targets for these two SSM sessions. 164 If that is the case, RTP streams 1 and 2 may have the same SSRC 165 value. However, if both SSM sessions use the same transport address 166 (IP address and port) for their feedback targets (as shown in the SDP 167 below), the SSRCs of the RTP streams 1 and 2 MUST be different from 168 each other to avoid any ambiguity in the RAMS requests. 170 a=group:FEC-XR RTP1 RTP2 171 m=video 40000 RTP/AVP 96 172 c=IN IP4 233.252.0.1/127 173 a=rtcp:41001 IN IP4 192.0.2.1 174 a=ssrc:1 cname:rtp1@example.com 175 a=mid:RTP1 176 m=application 40000 RTP/AVP 97 177 c=IN IP4 233.252.0.2/127 178 a=rtcp:41001 IN IP4 192.0.2.1 179 a=ssrc:2 cname:rtp2@example.com 180 a=mid:RTP2 182 Note that the destination ports in the above SDP do not matter, and 183 they could be the same or different. 185 4.2. Scenario #2 187 This is the scenario for session multiplexing where RTP streams 1 and 188 2 are transmitted over the same multicast group with different 189 destination ports. A practical use case is where the SSM session 190 carries the primary video and audio streams, each destined to a 191 different port. 193 Similar to scenario #1, we run individual RAMS sessions for each RTP 194 stream that we want to rapidly acquire. Compared to the previous 195 scenario, the only difference is that in this case the join times for 196 both streams need to be coordinated as they are on the same multicast 197 session. 199 m=video 40000 RTP/AVP 96 200 c=IN IP4 233.252.0.1/127 201 a=rtcp:41001 IN IP4 192.0.2.1 202 a=ssrc:1 cname:rtp1@example.com 203 a=mid:RTP1 204 m=audio 40001 RTP/AVP 97 205 c=IN IP4 233.252.0.1/127 206 a=rtcp:41001 IN IP4 192.0.2.1 207 a=ssrc:2 cname:rtp2@example.com 208 a=mid:RTP2 210 Note that the destination ports in the above SDP MUST be distinct per 211 [I-D.ietf-mmusic-rfc3388bis]. 213 If RTP streams 1 and 2 share the same distribution source, then there 214 is only one SSM session, which means that there can be only one 215 feedback target. This requires RTP streams 1 and 2 to have their own 216 unique SSRC values (as shown in the SDP above). If RTP streams 1 and 217 2 do not share the same distribution source, meaning that their 218 respective SSM sessions may use different feedback target transport 219 addresses, then their SSRC values do not have to be different from 220 each other. 222 4.3. Scenario #3 224 This is the scenario for SSRC multiplexing where both RTP streams are 225 transmitted over the same multicast group to the same destination 226 port. This is a less practical scenario but it could be used where 227 the SSM session carries the primary video and audio streams, destined 228 to the same port. 230 Similar to scenario #2, we run individual RAMS sessions and the join 231 time needs to be coordinated. In this case, there is only one 232 distribution source and the destination multicast address is shared. 233 Thus, there is only one SSM session and one feedback target. 235 m=video 40000 RTP/AVP 96 97 236 c=IN IP4 233.252.0.1/127 237 a=rtcp:41001 IN IP4 192.0.2.1 238 a=ssrc:1 cname:rtp1@example.com 239 a=ssrc:2 cname:rtp2@example.com 240 a=mid:Channel1 242 4.4. Scenario #4 244 This is the scenario for payload-type multiplexing. 246 In this case, instead of two, we have only one RTP stream (and one 247 RTP session) carrying both payload types (e.g., media payload and its 248 FEC data). While this scheme is permissible per [RFC3550], it has 249 several drawbacks. For example, RTP packets carrying different 250 payload formats will share the same sequence numbering space, and the 251 retransmission and RAMS operations will not be able to be applied 252 based on the payload type. For other drawbacks and details, see 253 Section 5.2 of [RFC3550]. 255 5. Feedback Target and SSRC Signaling Issues 257 The RAMS protocol uses the common packet format from [RFC4585], which 258 has a field to signal the media source SSRC. Thus, currently we 259 require the RAMS Request messages to have this field properly filled. 260 The SSRCs for the RTP streams can be signaled out-of-band in the SDP, 261 or could be learned from the RTP packets once the transmission 262 starts. In our scenario, the latter cannot be used. 264 Signaling the media source SSRC value will help the feedback target 265 correctly identify the RTP stream to be acquired. If a feedback 266 target is serving multiple SSM sessions on a particular port, all the 267 RTP streams in these SSM sessions MUST have a unique SSRC value. 268 Otherwise, the feedback target cannot discern the incoming RTCP 269 feedback messages. 271 If there are no provisions to assign unique SSRC values to the RTP 272 streams in a deployment, the feedback target transport addresses MUST 273 be assigned appropriately. Unique feedback target addresses can be 274 used without any issues if the deployment only covers scenario #1. 275 Using unique feedback target transport addresses may or may not be 276 sufficient in scenario #2. In scenario #3, there is one feedback 277 target. Thus, SSRCs must be unique among the RTP streams that a 278 particular feedback target (IP address and port) is responsible for. 280 6. FEC during RAMS and Bandwidth Issues 282 Suppose that RTP stream 1 denotes the primary video stream that has a 283 bitrate of 10 Mbps and RTP stream 2 denotes the FEC stream that has a 284 bitrate of 1 Mbps. Also assume that the RTP receiver knows that it 285 can receive data at a maximum bitrate of 22 Mbps. SDP can specify 286 the bitrate ("b=" line in Kbps) of each media session (per "m=" 287 line). 289 6.1. Scenario #1 291 This is the scenario for session multiplexing where RTP streams 1 and 292 2 are transmitted over different multicast groups. 294 This is the preferred deployment model for FEC. Having FEC in a 295 different multicast group provides flexibility for both RTP receivers 296 that are not FEC capable or the ones that are not willing to receive 297 FEC during the RAMS session. 299 a=group:FEC-XR RTP1 RTP2 300 m=video 40000 RTP/AVP 96 301 c=IN IP4 233.252.0.1/127 302 a=rtpmap:96 MP2T/90000 303 b=TIAS:10000 304 a=mid:RTP1 305 m=application 40000 RTP/AVP 97 306 c=IN IP4 233.252.0.2/127 307 a=rtpmap:97 1d-interleaved-parityfec/90000 308 b=TIAS:1000 309 a=mid:RTP2 311 If the RTP receiver does not want to receive FEC until the 312 acquisition of the primary video stream is completed, the total 313 available bandwidth can be used for faster acquisition of the primary 314 video stream. In this case, the RTP receiver may request a Max 315 Receive Bitrate of 22 Mbps in the RAMS Request message. Once RAMS 316 has been completed, the RTP receiver MAY join the FEC multicast 317 session, if desired. 319 If the RTP receiver wants to rapidly acquire both primary and FEC 320 streams, it needs to allocate the total bandwidth among the two RAMS 321 sessions and indicate individual Max Receive Bitrate values in each 322 respective RAMS Request message. Since less bandwidth will be used 323 to acquire the primary video stream, the acquisition of the primary 324 video session will take a longer time on the average. 326 While the RTP receiver can update the Max Receive Bitrate values 327 during the course of the RAMS session, this approach is more error- 328 prone due to the possibility of losing the update messages. 330 6.2. Scenario #2 332 This is the scenario for session multiplexing where RTP streams 1 and 333 2 are transmitted over the same multicast group with different 334 destination ports. 336 a=group:FEC-XR RTP1 RTP2 337 m=video 40000 RTP/AVP 96 338 c=IN IP4 233.252.0.1/127 339 a=rtpmap:96 MP2T/90000 340 b=TIAS:10000 341 a=mid:RTP1 342 m=application 40001 RTP/AVP 97 343 c=IN IP4 233.252.0.1/127 344 a=rtpmap:97 1d-interleaved-parityfec/90000 345 b=TIAS:1000 346 a=mid:RTP2 348 Similar to scenario #1, the RTP receiver can first ask for RAMS for 349 the primary video stream at the full receive bitrate. But, upon the 350 multicast join, the available bandwidth for the burst drops to 11 351 Mbps instead of 12 Mbps. Regardless of whether FEC is desired or not 352 by the RTP receiver, its bitrate needs to be taken into account once 353 the RTP receiver joins the multicast. 355 If the RTP receiver wants to rapidly acquire both primary and FEC 356 streams, the same conditions explained for scenario #1 apply. The 357 only difference from scenario #1 is that here the join time is the 358 same for both the primary video and FEC streams. 360 6.3. Scenario #3 362 This is the scenario for SSRC multiplexing where both RTP streams are 363 transmitted over the same multicast group to the same destination 364 port. 366 m=video 40000 RTP/AVP 96 97 367 c=IN IP4 233.252.0.1/127 368 a=rtpmap:96 MP2T/90000 369 a=rtpmap:97 1d-interleaved-parityfec/90000 370 b=TIAS:11000 371 a=mid:Channel1 373 This is similar to scenario #2. However, since we cannot explicitly 374 specify the bitrates for the primary and FEC streams, the RTP 375 receiver may request to rapidly acquire both streams in parallel. In 376 this case, two separate RAMS Request messages have to be sent by the 377 RTP receiver to the feedback target. 379 Note that based on the "a=fmtp" line for the FEC stream, it may be 380 possible to infer the bitrate of this FEC stream and set the Max 381 Receive Bitrate value accordingly. 383 7. Security Considerations 385 TBD. 387 8. IANA Considerations 389 There are no IANA considerations in this document. 391 9. References 392 9.1. Normative References 394 [I-D.ietf-avt-rapid-acquisition-for-rtp] 395 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 396 Based Rapid Acquisition of Multicast RTP Sessions", 397 draft-ietf-avt-rapid-acquisition-for-rtp-03 (work in 398 progress), September 2009. 400 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 401 Jacobson, "RTP: A Transport Protocol for Real-Time 402 Applications", STD 64, RFC 3550, July 2003. 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, March 1997. 407 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 408 Description Protocol", RFC 4566, July 2006. 410 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 411 "Extended RTP Profile for Real-time Transport Control 412 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 413 July 2006. 415 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 416 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 417 July 2006. 419 [I-D.ietf-avt-rtcpssm] 420 Schooler, E., Ott, J., and J. Chesterfield, "RTCP 421 Extensions for Single-Source Multicast Sessions with 422 Unicast Feedback", draft-ietf-avt-rtcpssm-18 (work in 423 progress), March 2009. 425 9.2. Informative References 427 [I-D.ietf-mmusic-rfc3388bis] 428 Camarillo, G., "The SDP (Session Description Protocol) 429 Grouping Framework", draft-ietf-mmusic-rfc3388bis-03 (work 430 in progress), July 2009. 432 Author's Address 434 Ali Begen 435 Cisco Systems 436 170 West Tasman Drive 437 San Jose, CA 95134 438 USA 440 Email: abegen@cisco.com