Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 6285

Unicast-Based Rapid Acquisition of Multicast RTP Sessions

Pages: 56
Proposed Standard
Part 1 of 3 – Pages 1 to 12
None   None   Next

Top   ToC   RFC6285 - Page 1
Internet Engineering Task Force (IETF)                      B. Ver Steeg
Request for Comments: 6285                                      A. Begen
Category: Standards Track                                          Cisco
ISSN: 2070-1721                                          T. Van Caenegem
                                                                  Z. Vax
                                                    Magnum Semiconductor
                                                               June 2011

       Unicast-Based Rapid Acquisition of Multicast RTP Sessions


When an RTP receiver joins a multicast session, it may need to acquire and parse certain Reference Information before it can process any data sent in the multicast session. Depending on the join time, length of the Reference Information repetition (or appearance) interval, size of the Reference Information, and the application and transport properties, the time lag before an RTP receiver can usefully consume the multicast data, which we refer to as the Acquisition Delay, varies and can be large. This is an undesirable phenomenon for receivers that frequently switch among different multicast sessions, such as video broadcasts. In this document, we describe a method using the existing RTP and RTP Control Protocol (RTCP) machinery that reduces the acquisition delay. In this method, an auxiliary unicast RTP session carrying the Reference Information to the receiver precedes or accompanies the multicast stream. This unicast RTP flow can be transmitted at a faster than natural bitrate to further accelerate the acquisition. The motivating use case for this capability is multicast applications that carry real-time compressed audio and video. However, this method can also be used in other types of multicast applications where the acquisition delay is long enough to be a problem. Status of This Memo This is an Internet Standards Track document. 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). Further information on Internet Standards is available in Section 2 of RFC 5741.
Top   ToC   RFC6285 - Page 2
   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Copyright Notice

   Copyright (c) 2011 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
   ( 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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Acquisition of RTP Streams vs. RTP Sessions . . . . . . . 6 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Elements of Delay in Multicast Applications . . . . . . . . . 8 5. Protocol Design Considerations and Their Effect on Resource Management for Rapid Acquisition . . . . . . . . . . 10 6. Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . 12 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13 6.3. Synchronization of Primary Multicast Streams . . . . . . . 24 6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 25 6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 28
Top   ToC   RFC6285 - Page 3
     7.1.  Extensions . . . . . . . . . . . . . . . . . . . . . . . . 29
       7.1.1.  Vendor-Neutral Extensions  . . . . . . . . . . . . . . 30
       7.1.2.  Private Extensions . . . . . . . . . . . . . . . . . . 30
     7.2.  RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 31
     7.3.  RAMS Information . . . . . . . . . . . . . . . . . . . . . 34
       7.3.1.  Response Code Definitions  . . . . . . . . . . . . . . 37
     7.4.  RAMS Termination . . . . . . . . . . . . . . . . . . . . . 39
   8.  SDP Signaling  . . . . . . . . . . . . . . . . . . . . . . . . 40
     8.1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . 40
     8.2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . 41
     8.3.  Example and Discussion . . . . . . . . . . . . . . . . . . 41
   9.  NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 44
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 45
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 47
     11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 48
     11.2. Registration of SDP Attribute Values . . . . . . . . . . . 48
     11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 48
     11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 48
     11.5. RAMS TLV Space Registry  . . . . . . . . . . . . . . . . . 49
     11.6. RAMS Response Code Space Registry  . . . . . . . . . . . . 50
   12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 52
   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 52
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 52
     14.2. Informative References . . . . . . . . . . . . . . . . . . 54

1. Introduction

Most multicast flows carry a stream of inter-related data. Receivers need to acquire certain information to start processing any data sent in the multicast session. This document refers to this information as Reference Information. The Reference Information is conventionally sent periodically in the multicast session (although its content can change over time) and usually consists of items such as a description of the schema for the rest of the data, references to which data to process, encryption information including keys, and any other information required to process the data in the multicast stream [IC2009]. Real-time multicast applications require receivers to buffer data. Receivers may have to buffer data to smooth out the network jitter, to allow loss-repair methods such as Forward Error Correction and retransmission to recover the missing packets, and to satisfy the data-processing requirements of the application layer. When a receiver joins a multicast session, it has no control over what point in the flow is currently being transmitted. Sometimes the receiver might join the session right before the Reference
Top   ToC   RFC6285 - Page 4
   Information is sent in the session.  In this case, the required
   waiting time is usually minimal.  Other times, the receiver might
   join the session right after the Reference Information has been
   transmitted.  In this case, the receiver has to wait for the
   Reference Information to appear again in the flow before it can start
   processing any multicast data.  In some other cases, the Reference
   Information is not contiguous in the flow but dispersed over a large
   period, which forces the receiver to wait for the whole Reference
   Information to arrive before starting to process the rest of the

   The net effect of waiting for the Reference Information and waiting
   for various buffers to fill up is that receivers can experience
   significantly large delays in data processing.  In this document, we
   refer to the difference between the time an RTP receiver wants to
   join the multicast session and the time the RTP receiver acquires all
   the necessary Reference Information as the Acquisition Delay.  The
   acquisition delay might not be the same for different receivers; it
   usually varies depending on the join time, length of the Reference
   Information repetition (or appearance) interval, and size of the
   Reference Information, as well as the application and transport

   The varying nature of the acquisition delay adversely affects the
   receivers that frequently switch among multicast sessions.  While
   this problem equally applies to both any-source multicast (ASM) and
   source-specific multicast (SSM) applications, in this specification
   we address it for the SSM-based applications by describing a method
   that uses the fundamental tools offered by the existing RTP and RTCP
   protocols [RFC3550].  In this method, either the multicast source (or
   the distribution source in an SSM session) retains the Reference
   Information for a period after its transmission, or an intermediary
   network element (that we refer to as Retransmission Server) joins the
   multicast session and continuously caches the Reference Information
   as it is sent in the session and acts as a feedback target (see
   [RFC5760]) for the session.  When an RTP receiver wishes to join the
   same multicast session, instead of simply issuing a Source Filtering
   Group Management Protocol (SFGMP) Join message, it sends a request to
   the feedback target for the session and asks for the Reference
   Information.  The retransmission server starts a new unicast RTP
   (retransmission) session and sends the Reference Information to the
   RTP receiver over that session.  If there is residual bandwidth, the
   retransmission server might burst the Reference Information faster
   than its natural rate.  As soon as the receiver acquires the
   Reference Information, it can join the multicast session and start
   processing the multicast data.  A simplified network diagram showing
   this method through an intermediary network element is depicted in
   Figure 1.
Top   ToC   RFC6285 - Page 5
   This method potentially reduces the acquisition delay.  We refer to
   this method as Unicast-Based Rapid Acquisition of Multicast RTP
   Sessions.  A primary use case for this method is to reduce the
   channel-change times in IPTV networks where compressed video streams
   are multicast in different SSM sessions and viewers randomly join
   these sessions.

                                  +--->|     Intermediary      |
                                  |    |    Network Element    |
                                  | ...|(Retransmission Server)|
                                  | :   -----------------------
                                  | :
                                  | v
           -----------          ----------             ----------
          | Multicast |        |          |---------->| Joining  |
          |  Source   |------->|  Router  |..........>|   RTP    |
          |           |        |          |           | Receiver |
           -----------          ----------             ----------
                                    |                  ----------
                                    +---------------->| Existing |
                                                      |    RTP   |
                                                      | Receiver |

          -------> Multicast RTP Flow
          .......> Unicast RTP Flow

    Figure 1: Rapid Acquisition through an Intermediary Network Element

   A principle design goal in this solution is to use the existing tools
   in the RTP/RTCP protocol family.  This improves the versatility of
   the existing implementations and promotes faster deployment and
   better interoperability.  To this effect, we use the unicast
   retransmission support of RTP [RFC4588] and the capabilities of RTCP
   to handle the signaling needed to accomplish the acquisition.

   A reasonable effort has been made in this specification to design a
   solution that reliably works in both engineered and best-effort
   networks.  However, a proper congestion control combined with the
   desired behavior of this solution is difficult to achieve.  Rather,
   this solution has been designed based on the assumption that the
   retransmission server and the RTP receivers have some knowledge about
   where the bottleneck between them is.  This assumption does not
   generally hold unless both the retransmission server and the RTP
   receivers are in the same edge network.  Thus, this solution should
Top   ToC   RFC6285 - Page 6
   not be used across any best-effort path of the Internet.
   Furthermore, this solution should only be used in networks that are
   already carrying non-congestion-responsive multicast traffic and have
   throttling mechanisms in the retransmission servers to ensure the
   (unicast) burst traffic is a known constant upper-bound multiplier on
   the multicast load.

1.1. Acquisition of RTP Streams vs. RTP Sessions

In this memo, we describe a protocol that handles the rapid acquisition of a single multicast RTP session (called a primary multicast RTP session) carrying one or more RTP streams (called primary multicast streams). If desired, multiple instances of this protocol may be run in parallel to acquire multiple RTP sessions simultaneously. When an RTP receiver requests the Reference Information from the retransmission server, it can opt to rapidly acquire a specific subset of the available RTP streams in the primary multicast RTP session. Alternatively, the RTP receiver can request the rapid acquisition of all of the RTP streams in that RTP session. Regardless of how many RTP streams are requested by the RTP receiver or how many will be actually sent by the retransmission server, only one unicast RTP session will be established by the retransmission server. This unicast RTP session is separate from the associated primary multicast RTP session. As a result, there are always two different RTP sessions in a single instance of the rapid acquisition protocol: (i) the primary multicast RTP session with its associated unicast feedback and (ii) the unicast RTP session. If the RTP receiver wants to rapidly acquire multiple RTP sessions simultaneously, separate unicast RTP sessions will be established for each of them.

1.2. Outline

The rest of this specification is as follows. Section 3 provides a list of the definitions frequently used in this document. In Section 4, we describe the delay components in generic multicast applications. Section 5 presents an overview of the protocol design considerations for rapid acquisition. We provide the protocol details of the rapid acquisition method in Sections 6 and 7. Sections 8 and 9 discuss the Session Description Protocol (SDP) signaling issues with examples and NAT-related issues, respectively. Finally, Section 10 discusses the security considerations, and Section 11 details the IANA considerations.
Top   ToC   RFC6285 - Page 7

2. Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Definitions

This document uses the following acronyms and definitions frequently: (Primary) SSM Session: The multicast session to which RTP receivers can join at a random point in time. A primary SSM session can carry multiple RTP streams. Primary Multicast RTP Session: The multicast RTP session an RTP receiver is interested in acquiring rapidly. From the RTP receiver's viewpoint, the primary multicast RTP session has one associated unicast RTCP feedback stream to a Feedback Target, in addition to the primary multicast RTP stream(s). Primary Multicast (RTP) Streams: The RTP stream(s) carried in the primary multicast RTP session. Source Filtering Group Management Protocol (SFGMP): Following the definition in [RFC4604], SFGMP refers to the Internet Group Management Protocol (IGMP) version 3 [RFC3376] and the Multicast Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and IPv6 networks, respectively. However, the rapid acquisition method introduced in this document does not depend on a specific version of either of these group management protocols. In the remainder of this document, SFGMP will refer to any group management protocol that has Join and Leave functionalities. Feedback Target (FT): Unicast RTCP feedback target as defined in [RFC5760]. FT_Ap denotes a specific feedback target running on a particular address and port. Retransmission (or Burst) Packet: An RTP packet that is formatted as defined in Section 4 of [RFC4588]. The payload of a retransmission or burst packet comprises the retransmission payload header followed by the payload of the original RTP packet. Reference Information: The set of certain media content and metadata information that is sufficient for an RTP receiver to start usefully consuming a media stream. The meaning, format, and size of this information are specific to the application and are out of the scope of this document.
Top   ToC   RFC6285 - Page 8
   Preamble Information:  A more compact form of the whole or a subset
   of the Reference Information transmitted out-of-band.

   (Unicast) Burst (or Retransmission) RTP Session:  The unicast RTP
   session used to send one or more unicast burst RTP streams and their
   associated RTCP messages.  The terms "burst RTP session" and
   "retransmission RTP session" can be used interchangeably.

   (Unicast) Burst (Stream):  A unicast stream of RTP retransmission
   packets that enable an RTP receiver to rapidly acquire the Reference
   Information associated with a primary multicast stream.  Each burst
   stream is identified by its Synchronization Source (SSRC) identifier
   that is unique in the primary multicast RTP session.  Following the
   session-multiplexing guidelines in [RFC4588], each unicast burst
   stream will use the same SSRC and Canonical Name (CNAME) as its
   primary multicast RTP stream.

   Retransmission Server (RS):  The RTP/RTCP endpoint that can generate
   the retransmission packets and the burst streams.  The RS may also
   generate other non-retransmission packets to aid rapid acquisition.

4. Elements of Delay in Multicast Applications

In a source-specific multicast (SSM) delivery system, there are three major elements that contribute to the acquisition delay when an RTP receiver switches from one multicast session to another one. These are: o Multicast-switching delay o Reference Information latency o Buffering delays Multicast-switching delay is the delay that is experienced when leaving the current multicast session (if any) and joining the new multicast session. In typical systems, the multicast join and leave operations are handled by a group management protocol. For example, the receivers and routers participating in a multicast session can use the Internet Group Management Protocol (IGMP) version 3 [RFC3376] or the Multicast Listener Discovery Protocol (MLD) version 2 [RFC3810]. In either of these protocols, when a receiver wants to join a multicast session, it sends a message to its upstream router and the routing infrastructure sets up the multicast forwarding state to deliver the packets of the multicast session to the new receiver. The join times vary depending on the proximity of the upstream router, the current state of the multicast tree, the load on the system, and the protocol implementation. Current systems provide
Top   ToC   RFC6285 - Page 9
   join latencies, usually less than 200 milliseconds (ms).  If the
   receiver had been participating in another multicast session before
   joining the new session, it needs to send a Leave message to its
   upstream router to leave the session.  In common multicast routing
   protocols, the leave times are usually smaller than the join times;
   however, it is possible that the Leave and Join messages might get
   lost, in which case the multicast-switching delay inevitably

   Reference Information latency is the time it takes the receiver to
   acquire the Reference Information.  It is highly dependent on the
   proximity of the actual time the receiver joined the session to the
   next time the Reference Information will be sent to the receivers in
   the session, whether or not the Reference Information is sent
   contiguously, and the size of the Reference Information.  For some
   multicast flows, there is a little or no interdependency in the data,
   in which case the Reference Information latency will be nil or
   negligible.  For other multicast flows, there is a high degree of
   interdependency.  One example of interest is the multicast flows that
   carry compressed audio/video.  For these flows, the Reference
   Information latency can become quite large and be a major contributor
   to the overall delay.

   The buffering component of the overall acquisition delay is driven by
   the way the application layer processes the payload.  In many
   multicast applications, an unreliable transport protocol such as UDP
   [RFC0768] is often used to transmit the data packets, and the
   reliability, if needed, is usually addressed through other means such
   as Forward Error Correction (e.g., [RFC6015]) and retransmission.
   These loss-repair methods require buffering at the receiver side to
   function properly.  In many applications, it is also often necessary
   to de-jitter the incoming data packets before feeding them to the
   application.  The de-jittering process also increases the buffering
   delays.  Besides these network-related buffering delays, there are
   also specific buffering needs that are required by the individual
   applications.  For example, standard video decoders typically require
   a certain amount, sometimes up to a few seconds, of coded video data
   to be available in the pre-decoding buffers prior to starting to
   decode the video bitstream.
Top   ToC   RFC6285 - Page 10

5. Protocol Design Considerations and Their Effect on Resource Management for Rapid Acquisition

This section is for informational purposes and does not contain requirements for implementations. Rapid acquisition is an optimization of a system that is expected to continue to work correctly and properly whether or not the optimization is effective or even fails due to lost control and feedback messages, congestion, or other problems. This is fundamental to the overall design requirements surrounding the protocol definition and to the resource management schemes to be employed together with the protocol (e.g., Quality of Service (QoS) machinery, server load management, etc). In particular, the system needs to operate within a number of constraints: o First, a rapid acquisition operation must fail gracefully. The user experience must not be significantly worse for trying and failing to complete rapid acquisition compared to simply joining the multicast session. o Second, providing the rapid acquisition optimizations must not cause collateral damage to either the multicast session being joined or other multicast sessions sharing resources with the rapid acquisition operation. In particular, the rapid acquisition operation must avoid interference with the multicast session that might be simultaneously being received by other hosts. In addition, it must also avoid interference with other multicast and non-multicast sessions sharing the same network resources. These properties are possible but are usually difficult to achieve. One challenge is the existence of multiple bandwidth bottlenecks between the receiver and the server(s) in the network providing the rapid acquisition service. In commercial IPTV deployments, for example, bottlenecks are often present in the aggregation network connecting the IPTV servers to the network edge, the access links (e.g., DSL, Data Over Cable Service Interface Specification (DOCSIS)), and the home network of the subscribers. Some of these links might serve only a single subscriber, limiting congestion impact to the traffic of only that subscriber, but others can be shared links carrying multicast sessions of many subscribers. Also note that the state of these links can vary over time. The receiver might have knowledge of a portion of this network or might have partial knowledge of the entire network. The methods employed by the devices to acquire this network state information is out of the scope of this document. The receiver should be able to signal the server with the bandwidth that it believes it can handle. The server also needs to be able to rate limit the flow in order to stay within the
Top   ToC   RFC6285 - Page 11
   performance envelope that it knows about.  Both the server and
   receiver need to be able to inform the other of changes in the
   requested and delivered rates.  However, the protocol must be robust
   in the presence of packet loss, so this signaling must include the
   appropriate default behaviors.

   A second challenge is that for some uses (e.g., high-bitrate video)
   the unicast burst bitrate is high while the flow duration of the
   unicast burst is short.  This is because the purpose of the unicast
   burst is to allow the RTP receiver to join the multicast quickly and
   thereby limit the overall resources consumed by the burst.  Such
   high-bitrate, short-duration flows are not amenable to conventional
   admission-control techniques.  For example, end-to-end per-flow
   signaled admission-control techniques such as Resource Reservation
   Protocol (RSVP) have too much latency and control channel overhead to
   be a good fit for rapid acquisition.  Similarly, using a TCP (or TCP-
   like) approach with a 3-way handshake and slow-start to avoid
   inducing congestion would defeat the purpose of attempting rapid
   acquisition in the first place by introducing many round-trip times
   (RTTs) of delay.

   These observations lead to certain unavoidable requirements and goals
   for a rapid acquisition protocol.  These are:

   o  The protocol must be designed to allow a deterministic upper bound
      on the extra bandwidth used (compared to just joining the
      multicast session).  A reasonable size bound is e*B, where B is
      the nominal bandwidth of the primary multicast streams and e is an
      excess-bandwidth coefficient.  The total duration of the unicast
      burst must have a reasonable bound; long unicast bursts devolve to
      the bandwidth profile of multi-unicast for the whole system.

   o  The scheme should minimize (or better eliminate) the overlap of
      the unicast burst and the primary multicast stream.  This
      minimizes the window during which congestion could be induced on a
      bottleneck link compared to just carrying the multicast or unicast
      packets alone.

   o  The scheme must minimize (or better eliminate) any gap between the
      unicast burst and the primary multicast stream, which has to be
      repaired later or, in the absence of repair, will result in loss
      being experienced by the application.

   In addition to the above, there are some other protocol design issues
   to be considered.  First, there is at least one RTT of "slop" in the
   control loop.  In starting a rapid acquisition burst, this manifests
   as the time between the client requesting the unicast burst and the
   burst description and/or the first unicast burst packets arriving at
Top   ToC   RFC6285 - Page 12
   the receiver.  For managing and terminating the unicast burst, there
   are two possible approaches for the control loop.  First, the
   receiver can adapt to the unicast burst as received, converge based
   on observation, and explicitly terminate the unicast burst with a
   second control loop exchange (which takes a minimum of one RTT, just
   as starting the unicast burst does).  Alternatively, the server
   generating the unicast burst can precompute the burst parameters
   based on the information in the initial request and tell the receiver
   the burst duration.

   The protocol described in the next section allows either method of
   controlling the rapid acquisition unicast burst.

(page 12 continued on part 2)

Next Section