diff options
Diffstat (limited to 'doc/rfc/rfc6659.txt')
| -rw-r--r-- | doc/rfc/rfc6659.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc6659.txt b/doc/rfc/rfc6659.txt new file mode 100644 index 0000000..5a33f53 --- /dev/null +++ b/doc/rfc/rfc6659.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Begen +Request for Comments: 6659 Cisco +Category: Informational July 2012 +ISSN: 2070-1721 + + + Considerations for Deploying the Rapid Acquisition of + Multicast RTP Sessions (RAMS) Method + +Abstract + + The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a + method based on RTP and the RTP Control Protocol (RTCP) that enables + an RTP receiver to rapidly acquire and start consuming the RTP + multicast data. Upon a request from the RTP receiver, an auxiliary + unicast RTP retransmission session is set up between a retransmission + server and the RTP receiver, over which the reference information + about the new multicast stream the RTP receiver is about to join is + transmitted at an accelerated rate. This often precedes, but may + also accompany, the multicast stream itself. When there is only one + multicast stream to be acquired, the RAMS solution works in a + straightforward manner. However, when there are two or more + multicast streams to be acquired from the same or different multicast + RTP sessions, care should be taken to configure each RAMS session + appropriately. This document provides example scenarios and + discusses how the RAMS solution could be used in such scenarios. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6659. + + + + + + + + + +Begen Informational [Page 1] + +RFC 6659 RAMS Considerations July 2012 + + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................2 + 2. Background ......................................................3 + 3. Example Scenarios ...............................................4 + 3.1. Scenario #1: Two Multicast Groups ..........................4 + 3.2. Scenario #2: One Multicast Group ...........................5 + 3.3. Scenario #3: SSRC Multiplexing .............................6 + 3.4. Scenario #4: Payload-Type Multiplexing .....................6 + 4. Feedback Target and SSRC Signaling Issues .......................7 + 5. FEC during RAMS and Bandwidth Issues ............................7 + 5.1. Scenario #1 ................................................7 + 5.2. Scenario #2 ................................................9 + 5.3. Scenario #3 ...............................................10 + 6. Security Considerations ........................................10 + 7. Acknowledgments ................................................10 + 8. References .....................................................11 + 8.1. Normative References ......................................11 + 8.2. Informative References ....................................11 + +1. Introduction + + The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a + method based on RTP and the RTP Control Protocol (RTCP) that enables + an RTP receiver to rapidly acquire and start consuming the RTP + multicast data. Through an auxiliary unicast RTP retransmission + session [RFC4588], the RTP receiver receives reference information + about the new multicast stream it is about to join. This often + precedes, but may also accompany, the multicast stream itself. The + RAMS solution is documented in detail in [RFC6285]. + + + + + + +Begen Informational [Page 2] + +RFC 6659 RAMS Considerations July 2012 + + + The RAMS specification [RFC6285] has provisions for concurrently + acquiring multiple streams inside a multicast RTP session. However, + the RAMS specification does not discuss scenarios where an RTP + receiver makes use of the RAMS method to rapidly acquire multiple and + associated multicast streams in parallel, or where different RTP + sessions are part of the same Source-Specific Multicast (SSM) + session. The example presented in Section 8.3 of [RFC6285] addresses + only the simple case of an RTP receiver rapidly acquiring only one + multicast stream to explain the protocol details. + + There are certain deployment models where a multicast RTP session + might have two or more multicast streams associated with it. There + are also cases where an RTP receiver might be interested in acquiring + one or more multicast streams from several multicast RTP sessions. + Close coordination is required for multiple RAMS sessions + simultaneously started by an RTP server, where each session is + initiated with an individual RAMS Request message to a different + feedback target. In this document, we present scenarios from real- + life deployments and discuss how the RAMS solution could be used in + such scenarios. + +2. Background + + In the following discussion, we assume that there are two RTP streams + (1 and 2) that are in some manner associated with each other. These + could be audio and video elementary streams for the same TV channel, + or they could be an MPEG2 Transport Stream (that has audio and video + multiplexed together) and its Forward Error Correction (FEC) stream. + + An SSM session is defined by its (distribution) source address and + (destination) multicast group, and there can be only one feedback + target per SSM session [RFC5760]. So, if the RTP streams are + distributed by different sources or over different multicast groups, + they are considered different SSM sessions. While different SSM + sessions can normally share the same feedback target address and/or + port, RAMS requires each unique feedback target (i.e., the + combination of address and port) to be associated with at most one + RTP session (See Section 6.2 of [RFC6285]). + + Two or more multicast RTP streams can be transmitted in the same RTP + session (e.g., in a single UDP flow). This is called Synchronization + Source (SSRC) multiplexing. In this case, (de)multiplexing is done + at the SSRC level. Alternatively, the multicast RTP streams can be + transmitted in different RTP sessions (e.g., in different UDP flows), + which is called session multiplexing. In practice, there are + different deployment models for each multiplexing scheme. + + + + + +Begen Informational [Page 3] + +RFC 6659 RAMS Considerations July 2012 + + + Generally, to avoid complications in RTCP reports, it is suggested + that two different media streams with different clock rates use + different SSRCs or be carried in different RTP sessions. Some of the + fields in RAMS messages might depend on the clock rate. Thus, in a + single RTP session, RTP streams carrying payloads with different + clock rates need to have different SSRCs. Since RTP streams with + different SSRCs do not share the sequence numbering, each stream + needs to be acquired individually. + + In the remaining sections, only the relevant portions of the Session + Description Protocol (SDP) descriptions [RFC4566] will be provided. + For an example of a full SDP description, refer to Section 8.3 of + [RFC6285]. + +3. Example Scenarios + +3.1. Scenario #1: Two Multicast Groups + + This is the scenario for session multiplexing where RTP streams 1 and + 2 are transmitted over different multicast groups. A practical use + case is where the first and second SSM sessions carry the primary + video stream and its associated FEC stream, respectively. + + An individual RAMS session is run for each of the RTP streams that + require rapid acquisition. Each requires a separate RAMS Request + message to be sent. These RAMS sessions can be run in parallel. If + they are, the RTP receiver needs to pay attention to using the shared + bandwidth appropriately among the two unicast bursts. As explained + earlier, there has to be a different feedback target for these two + SSM sessions. + + v=0 + o=ali 1122334455 1122334466 IN IP4 rams.example.com + s=RAMS Scenarios + t=0 0 + a=group:FEC-FR Channel1_Video Channel1_FEC + m=video 40000 RTP/AVPF 96 + c=IN IP4 233.252.0.1/127 + a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 + a=rtcp:41000 IN IP4 192.0.2.1 + a=ssrc:1 cname:ch1_video@example.com + a=mid:Channel1_Video + m=application 40000 RTP/AVPF 97 + c=IN IP4 233.252.0.2/127 + a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 + a=rtcp:42000 IN IP4 192.0.2.1 + a=ssrc:2 cname:ch1_fec@example.com + a=mid:Channel1_FEC + + + +Begen Informational [Page 4] + +RFC 6659 RAMS Considerations July 2012 + + + Note that the multicast destination ports in the above SDP do not + matter, and they could be the same or different. The "FEC-FR" + grouping semantics are defined in [RFC5956]. + +3.2. Scenario #2: One Multicast Group + + Here, RTP streams 1 and 2 are transmitted over the same multicast + group with different destination ports. A practical use case is + where the SSM session carries the primary video and audio streams, + each destined to a different port. + + The RAMS Request message sent by an RTP receiver to the feedback + target could indicate the desire to acquire all or a subset or one of + the available RTP streams. Thus, both the primary video and audio + streams can be acquired rapidly in parallel. Or, the RTP receiver + can acquire only the primary video or audio stream, if desired, by + indicating the specific SSRC in the request. Compared to the + previous scenario, the only difference is that in this case the join + times for both streams need to be coordinated as they are delivered + in the same multicast session. + + v=0 + o=ali 1122334455 1122334466 IN IP4 rams.example.com + s=RAMS Scenarios + t=0 0 + m=video 40000 RTP/AVPF 96 + c=IN IP4 233.252.0.1/127 + a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 + a=rtcp:41000 IN IP4 192.0.2.1 + a=ssrc:1 cname:ch1_video@example.com + a=mid:Channel1_Video + m=audio 40001 RTP/AVPF 97 + c=IN IP4 233.252.0.1/127 + a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 + a=rtcp:41000 IN IP4 192.0.2.1 + a=ssrc:2 cname:ch1_audio@example.com + a=mid:Channel1_Audio + + Note that the destination ports in "m" lines need to be distinct per + [RFC5888]. + + If RTP streams 1 and 2 share the same distribution source, then there + is only one SSM session, which means that there can be only one + feedback target (as shown in the SDP description above). This + requires RTP streams 1 and 2 to have their own unique SSRC values + (also as shown in the SDP description above). If RTP streams 1 and 2 + do not share the same distribution source, meaning that their + + + + +Begen Informational [Page 5] + +RFC 6659 RAMS Considerations July 2012 + + + respective SSM sessions can use different feedback target transport + addresses, then their SSRC values do not have to be different from + each other. + +3.3. Scenario #3: SSRC Multiplexing + + This is the scenario for SSRC multiplexing where both RTP streams are + transmitted over the same multicast group to the same destination + port. This is a less practical scenario, but it could be used where + the SSM session carries both the primary video and audio stream, + destined to the same port. + + Similar to scenario #2, both the primary video and audio streams can + be acquired rapidly in parallel. Or, the RTP receiver can acquire + only the primary video or audio stream, if desired, by indicating the + specific SSRC in the request. In this case, there is only one + distribution source and the destination multicast address is shared. + Thus, there is always one SSM session and one feedback target. + + v=0 + o=ali 1122334455 1122334466 IN IP4 rams.example.com + s=RAMS Scenarios + t=0 0 + m=video 40000 RTP/AVPF 96 97 + c=IN IP4 233.252.0.1/127 + a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 + a=rtcp:41000 IN IP4 192.0.2.1 + a=ssrc:1 cname:ch1_video@example.com + a=ssrc:2 cname:ch1_audio@example.com + a=mid:Channel1 + +3.4. Scenario #4: Payload-Type Multiplexing + + This is the scenario for payload-type multiplexing. + + In this case, instead of two, there is only one RTP stream (and one + RTP session) carrying both payload types (e.g., media payload and its + FEC data). While this scheme is permissible per [RFC3550], it has + several drawbacks. For example, RTP packets carrying different + payload formats will share the same sequence numbering space, and the + RAMS operations will not be able to be applied based on the payload + type. For other drawbacks and details, see Section 5.2 of [RFC3550]. + + + + + + + + + +Begen Informational [Page 6] + +RFC 6659 RAMS Considerations July 2012 + + +4. Feedback Target and SSRC Signaling Issues + + The RAMS protocol uses the common packet format from [RFC4585], which + has a field to signal the media sender SSRC. The SSRCs for the RTP + streams can be signaled out-of-band in the SDP or could be learned + from the RTP packets once the transmission starts. In RAMS, the + latter cannot be used. + + Signaling the media sender SSRC value helps the feedback target + correctly identify the RTP stream to be acquired. If a feedback + target is serving multiple SSM sessions on a particular port, all the + RTP streams in these SSM sessions are supposed to have a unique SSRC + value. However, this is not an easy requirement to satisfy. Thus, + the RAMS specification forbids having more than one RTP session + associated with a specific feedback target on a specific port. + +5. FEC during RAMS and Bandwidth Issues + + Suppose that RTP stream 1 denotes the primary video stream that has a + bitrate of 10 Mbps and RTP stream 2 denotes the associated FEC stream + that has a bitrate of 1 Mbps. Also assume that the RTP receiver + knows that it can receive data at a maximum bitrate of 22 Mbps. SDP + can specify the bitrate ("b=" line in kbps) of each media session + (per "m" line). + + Note that RAMS can potentially congest the network temporarily. + Refer to [RFC6285] for a detailed discussion. + +5.1. Scenario #1 + + This is the scenario for session multiplexing where RTP streams 1 and + 2 are transmitted over different multicast groups. + + This is the preferred deployment model for FEC [RFC6363]. Having FEC + in a different multicast group provides two flexibility points: RTP + receivers that are not FEC capable can receive the primary video + stream without FEC, and RTP receivers that are FEC capable can decide + to not receive FEC during the rapid acquisition (but still start + receiving the FEC stream after the acquisition of the primary video + stream has been completed). + + + + + + + + + + + +Begen Informational [Page 7] + +RFC 6659 RAMS Considerations July 2012 + + + v=0 + o=ali 1122334455 1122334466 IN IP4 rams.example.com + s=RAMS Scenarios + t=0 0 + a=group:FEC-FR Channel1_Video Channel1_FEC + m=video 40000 RTP/AVPF 96 + c=IN IP4 233.252.0.1/127 + a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 + a=rtcp:41000 IN IP4 192.0.2.1 + a=rtpmap:96 MP2T/90000 + b=TIAS:10000 + a=ssrc:1 cname:ch1_video@example.com + a=mid:Channel1_Video + m=application 40000 RTP/AVPF 97 + c=IN IP4 233.252.0.2/127 + a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 + a=rtcp:42000 IN IP4 192.0.2.1 + a=rtpmap:97 1d-interleaved-parityfec/90000 + b=TIAS:1000 + a=ssrc:2 cname:ch1_fec@example.com + a=mid:Channel1_FEC + + If the RTP receiver does not want to receive FEC until the + acquisition of the primary video stream is completed, the total + available bandwidth can be used for faster acquisition of the primary + video stream. In this case, the RTP receiver can request a Max + Receive Bitrate of 22 Mbps in the RAMS Request message for the + primary video stream. Once RAMS has been completed, the RTP receiver + can join the FEC multicast session, if desired. + + If the RTP receiver wants to rapidly acquire both primary and FEC + streams, it needs to allocate the total bandwidth among the two RAMS + sessions and indicate individual Max Receive Bitrate values in each + respective RAMS Request message. Since less bandwidth will be used + to acquire the primary video stream, the acquisition of the primary + video session will take a longer time on the average. + + While the RTP receiver can update the Max Receive Bitrate values + during the course of the RAMS session, this approach is more error- + prone, due to the possibility of losing the update messages. + + + + + + + + + + + +Begen Informational [Page 8] + +RFC 6659 RAMS Considerations July 2012 + + +5.2. Scenario #2 + + Here, RTP streams 1 (primary video) and 2 (FEC) are transmitted over + the same multicast group with different destination ports. This is + not a preferred deployment model. + + v=0 + o=ali 1122334455 1122334466 IN IP4 rams.example.com + s=RAMS Scenarios + t=0 0 + a=group:FEC-FR Channel1_Video Channel1_FEC + m=video 40000 RTP/AVPF 96 + c=IN IP4 233.252.0.1/127 + a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 + a=rtcp:41000 IN IP4 192.0.2.1 + a=rtpmap:96 MP2T/90000 + b=TIAS:10000 + a=ssrc:1 cname:ch1_video@example.com + a=mid:Channel1_Video + m=application 40001 RTP/AVPF 97 + c=IN IP4 233.252.0.1/127 + a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 + a=rtcp:41000 IN IP4 192.0.2.1 + a=rtpmap:97 1d-interleaved-parityfec/90000 + b=TIAS:1000 + a=ssrc:2 cname:ch1_fec@example.com + a=mid:Channel1_FEC + + The RAMS Request message sent by an RTP receiver to the feedback + target could indicate the desire to acquire all or a subset or one of + the available RTP streams. Thus, both the primary video and FEC + streams can be acquired rapidly in parallel sharing the same + available bandwidth. Or, the RTP receiver can acquire only the + primary video stream by indicating its specific SSRC in the request. + In this case, the RTP receiver can first acquire the primary video + stream at the full receive bitrate. But, upon the multicast join, + the available bandwidth for the burst drops to 11 Mbps instead of + 12 Mbps. Regardless of whether FEC is desired or not by the RTP + receiver, its bitrate needs to be taken into account once the RTP + receiver joins the SSM session. + + + + + + + + + + + +Begen Informational [Page 9] + +RFC 6659 RAMS Considerations July 2012 + + +5.3. Scenario #3 + + This is the scenario for SSRC multiplexing where both RTP streams are + transmitted over the same multicast group to the same destination + port. + + v=0 + o=ali 1122334455 1122334466 IN IP4 rams.example.com + s=RAMS Scenarios + t=0 0 + m=video 40000 RTP/AVPF 96 97 + c=IN IP4 233.252.0.1/127 + a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1 + a=rtcp:41000 IN IP4 192.0.2.1 + a=rtpmap:96 MP2T/90000 + a=rtpmap:97 1d-interleaved-parityfec/90000 + a=fmtp:97 L=10; D=10; repair-window=200000 + a=ssrc:1 cname:ch1_video@example.com + a=ssrc:2 cname:ch1_fec@example.com + b=TIAS:11000 + a=mid:Channel1 + + Similar to scenario #2, both the primary video and audio streams can + be acquired rapidly in parallel. Or, the RTP receiver can acquire + only the primary video stream, if desired, by indicating its specific + SSRC in the request. + + Note that based on the "a=fmtp" line for the FEC stream, it could be + possible to infer the bitrate of this FEC stream and set the Max + Receive Bitrate value accordingly. + +6. Security Considerations + + Because this document describes deployment scenarios for RAMS, all + security considerations are specified in the RAMS specification + [RFC6285]. + +7. Acknowledgments + + I would like to thank various individuals in the AVTEXT and MMUSIC + WGs, and my friends at Cisco for their comments and feedback. + + + + + + + + + + +Begen Informational [Page 10] + +RFC 6659 RAMS Considerations July 2012 + + +8. References + +8.1. Normative References + + [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, + "Unicast-Based Rapid Acquisition of Multicast RTP + Sessions", RFC 6285, June 2011. + +8.2. Informative References + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, July 2006. + + [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, + "Extended RTP Profile for Real-time Transport Control + Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, + July 2006. + + [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. + Hakenberg, "RTP Retransmission Payload Format", RFC 4588, + July 2006. + + [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control + Protocol (RTCP) Extensions for Single-Source Multicast + Sessions with Unicast Feedback", RFC 5760, February 2010. + + [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description + Protocol (SDP) Grouping Framework", RFC 5888, June 2010. + + [RFC5956] Begen, A., "Forward Error Correction Grouping Semantics in + the Session Description Protocol", RFC 5956, + September 2010. + + [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error + Correction (FEC) Framework", RFC 6363, October 2011. + + + + + + + + + + + + +Begen Informational [Page 11] + +RFC 6659 RAMS Considerations July 2012 + + +Author's Address + + Ali Begen + Cisco + 181 Bay Street + Toronto, ON M5J 2T3 + Canada + + EMail: abegen@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Begen Informational [Page 12] + |