Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) Method
RFC 6659

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]