GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6285

Internet Engineering Task Force (IETF) B. Ver Steeg Request for Comments: 6285 A. Begen Category: Standards Track Cisco ISSN: 2070-1721 T. Van Caenegem

                                                        Alcatel-Lucent
                                                                Z. Vax
                                                  Magnum Semiconductor
                                                             June 2011
     Unicast-Based Rapid Acquisition of Multicast RTP Sessions

Abstract

 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.

Ver Steeg, et al. Standards Track [Page 1] RFC 6285 RAMS June 2011

 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/rfc6285.

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
 (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.
 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

Ver Steeg, et al. Standards Track [Page 2] RFC 6285 RAMS June 2011

   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

Ver Steeg, et al. Standards Track [Page 3] RFC 6285 RAMS June 2011

 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
 data.
 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
 properties.
 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.

Ver Steeg, et al. Standards Track [Page 4] RFC 6285 RAMS June 2011

 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.
  1. ———————-

+—>| Intermediary |

                                |    |    Network Element    |
                                | ...|(Retransmission Server)|
                                | :   -----------------------
                                | :
                                | v
         -----------          ----------             ----------
        | Multicast |        |          |---------->| Joining  |
        |  Source   |------->|  Router  |..........>|   RTP    |
        |           |        |          |           | Receiver |
         -----------          ----------             ----------
                                  |
                                  |                  ----------
                                  +---------------->| Existing |
                                                    |    RTP   |
                                                    | Receiver |
                                                     ----------
  1. ——> 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

Ver Steeg, et al. Standards Track [Page 5] RFC 6285 RAMS June 2011

 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.

Ver Steeg, et al. Standards Track [Page 6] RFC 6285 RAMS June 2011

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.

Ver Steeg, et al. Standards Track [Page 7] RFC 6285 RAMS June 2011

 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

Ver Steeg, et al. Standards Track [Page 8] RFC 6285 RAMS June 2011

 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
 increases.
 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.

Ver Steeg, et al. Standards Track [Page 9] RFC 6285 RAMS June 2011

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

Ver Steeg, et al. Standards Track [Page 10] RFC 6285 RAMS June 2011

 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

Ver Steeg, et al. Standards Track [Page 11] RFC 6285 RAMS June 2011

 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.

6. Rapid Acquisition of Multicast RTP Sessions (RAMS)

 We start this section with an overview of the Rapid Acquisition of
 Multicast RTP Sessions (RAMS) method.

6.1. Overview

 [RFC5760] specifies an extension to the RTP Control Protocol (RTCP)
 to use unicast feedback in an SSM session.  It defines an
 architecture that introduces the concept of Distribution Source,
 which, in an SSM context, distributes the RTP data and redistributes
 RTCP information to all RTP receivers.  This RTCP information is
 retrieved from the Feedback Target, to which RTCP unicast feedback
 traffic is sent.  One or more entities different from the
 Distribution Source MAY implement the feedback target functionality,
 and different RTP receivers MAY use different feedback targets.
 This document builds further on these concepts to reduce the
 acquisition delay when an RTP receiver joins a multicast session at a
 random point in time by introducing the concept of the Burst Source
 and new RTCP feedback messages.  The Burst Source has a cache where
 the most recent packets from the primary multicast RTP session are
 continuously stored.  When an RTP receiver wants to receive a primary
 multicast stream, it can first request a unicast burst from the Burst
 Source before it joins the SSM session.  In this burst, the packets
 are formatted as RTP retransmission packets [RFC4588] and carry
 Reference Information.  This information allows the RTP receiver to
 start usefully consuming the RTP packets sent in the primary
 multicast RTP session.
 Using an accelerated bitrate (as compared to the nominal bitrate of
 the primary multicast stream) for the unicast burst implies that at a
 certain point in time, the payload transmitted in the unicast burst
 is going to be the same as the payload in the associated multicast
 stream, i.e., the unicast burst will catch up with the primary

Ver Steeg, et al. Standards Track [Page 12] RFC 6285 RAMS June 2011

 multicast stream.  At this point, the RTP receiver no longer needs to
 receive the unicast burst and can join the SSM session.  This method
 is referred to as the Rapid Acquisition of Multicast RTP Sessions
 (RAMS).
 This document defines extensions to [RFC4585] for an RTP receiver to
 request a unicast burst as well as for additional control messaging
 that can be leveraged during the acquisition process.

6.2. Message Flows

 As shown in Figure 2, the main entities involved in rapid acquisition
 and the message flows are:
 o  Multicast Source
 o  Feedback Target (FT)
 o  Burst/Retransmission Source (BRS)
 o  RTP Receiver (RTP_Rx)

Ver Steeg, et al. Standards Track [Page 13] RFC 6285 RAMS June 2011

  1. ———- ————–

| |————————————>| |

 |           |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->|              |
 |           |                                     |              |
 | Multicast |          ----------------           |              |
 |  Source   |         | Retransmission |          |              |
 |           |-------->|  Server  (RS)  |          |              |
 |           |.-.-.-.->|                |          |              |
 |           |         |  ------------  |          |              |
  -----------          | |  Feedback  | |<.=.=.=.=.|              |
                       | | Target (FT)| |<~~~~~~~~~| RTP Receiver |
 PRIMARY MULTICAST     |  ------------  |          |   (RTP_Rx)   |
 RTP SESSION with      |                |          |              |
 UNICAST FEEDBACK      |                |          |              |
                       |                |          |              |
 - - - - - - - - - - - |- - - - - - - - |- - - - - |- - - - - - - |- -
                       |                |          |              |
 UNICAST BURST         |  ------------  |          |              |
 (or RETRANSMISSION)   | |   Burst/   | |<~~~~~~~~>|              |
 RTP SESSION           | |  Retrans.  | |.........>|              |
                       | |Source (BRS)| |<.=.=.=.=>|              |
                       |  ------------  |          |              |
                       |                |          |              |
                        ----------------            --------------
  1. ——> Multicast RTP Flow

.-.-.-.> Multicast RTCP Flow

 .=.=.=.> Unicast RTCP Reports
 ~~~~~~~> Unicast RTCP Feedback Messages
 .......> Unicast RTP Flow
      Figure 2: Flow Diagram for Unicast-Based Rapid Acquisition
 As defined in [RFC5760], the feedback target (FT) is the entity to
 which the RTP_Rx sends its RTCP feedback messages indicating packet
 loss by means of an RTCP NACK message or indicating RTP_Rx's desire
 to rapidly acquire the primary multicast RTP session by means of an
 RTCP feedback message defined in this document.  While the Burst/
 Retransmission Source (BRS) is responsible for responding to these
 messages and for further RTCP interaction with the RTP_Rx in the case
 of a rapid acquisition process, it is assumed in the remainder of
 this document that these two logical entities (FT and BRS) are
 combined in a single physical entity and they share state.  In the
 remainder of the text, the term Retransmission Server (RS) is used
 whenever appropriate, to refer to this single physical entity.

Ver Steeg, et al. Standards Track [Page 14] RFC 6285 RAMS June 2011

 The FT is involved in the primary multicast RTP session and receives
 unicast feedback for that session as in [RFC5760].  The BRS is
 involved in the unicast burst (or retransmission) RTP session and
 transmits the unicast burst and retransmission packets formatted as
 RTP retransmission packets [RFC4588] in a single separate unicast RTP
 session to each RTP_Rx.  In the unicast burst RTP session, as in any
 other RTP session, the BRS and RTP_Rx regularly send the periodic
 sender and receiver reports, respectively.
 The unicast burst is started by an RTCP feedback message that is
 defined in this document based on the common packet format provided
 in [RFC4585].  An RTP retransmission is triggered by an RTCP NACK
 message defined in [RFC4585].  Both of these messages are sent to the
 FT of the primary multicast RTP session and can start the unicast
 burst/retransmission RTP session.
 In the extended RTP profile for RTCP-based feedback (RTP/Audio-Visual
 Profile with Feedback (AVPF)), there are certain rules that apply to
 scheduling of both of these messages sent to the FT in the primary
 multicast RTP session; these are detailed in Section 3.5 of
 [RFC4585].  One of the rules states that in a multi-party session
 such as the SSM sessions we are considering in this specification, an
 RTP_Rx cannot send an RTCP feedback message for a minimum of one
 second after joining the session (i.e., Tmin=1.0 second).  While this
 rule has the goal of avoiding problems associated with flash crowds
 in typical multi-party sessions, it defeats the purpose of rapid
 acquisition.  Furthermore, when RTP receivers delay their messages
 requesting a burst by a deterministic or even a random amount, it
 still does not make a difference since such messages are not related
 and their timings are independent from each other.  Thus, in this
 specification, we initialize Tmin to zero and allow the RTP receivers
 to send a burst request message right at the beginning.  For the
 subsequent messages (e.g., updated requests) during rapid
 acquisition, the timing rules of [RFC4585] still apply.
 Figure 3 depicts an example of messaging flow for rapid acquisition.
 The RTCP feedback messages are explained below.  The optional
 messages are indicated in parentheses, and they might or might not be
 present during rapid acquisition.  In a scenario where rapid
 acquisition is performed by a feedback target co-located with the
 media sender, the same method (with the identical message flows)
 still applies.

Ver Steeg, et al. Standards Track [Page 15] RFC 6285 RAMS June 2011

  1. ————————

| Retransmission Server |

  1. ———- | —— ———— | ——– ————

| Multicast | | | FT | | Burst/Ret. | | | | | RTP |

 |  Source   | | |      | |   Source   | |  | Router |  |  Receiver  |
 |           | |  ------   ------------  |  |        |  |  (RTP_Rx)  |
  -----------  |      |         |        |   --------    ------------
   |            -------------------------       |                |
   |                  |         |               |                |
   |-- RTP Multicast ---------->--------------->|                |
   |-. RTCP Multicast -.-.-.-.->-.-.-.-.-.-.-.->|                |
   |                  |         |               |                |
   |                  |         |********************************|
   |                  |         |*      PORT MAPPING SETUP      *|
   |                  |         |********************************|
   |                  |         |               |                |
   |                  |<~~~~~~~~~~~~~~~~~~~~~~~~~ RTCP RAMS-R ~~~|
   |                  |         |               |                |
   |                  |         |********************************|
   |                  |         |* UNICAST SESSION ESTABLISHED  *|
   |                  |         |********************************|
   |                  |         |               |                |
   |                  |         |~~~ RTCP RAMS-I ~~~~~~~~~~~~~~~>|
   |                  |         |               |                |
   |                  |         |... Unicast RTP Burst .........>|
   |                  |         |               |                |
   |                  |<~~~~~~~~~~~~~~~~~~~~~~~~ (RTCP RAMS-R) ~~|
   |                  |         |               |                |
   |                  |         |~~ (RTCP RAMS-I) ~~~~~~~~~~~~~~>|
   |                  |         |               |                |
   |                  |         |               |                |
   |                  |         |               |<= SFGMP Join ==|
   |                  |         |               |                |
   |-- RTP Multicast ------------------------------------------->|
   |-. RTCP Multicast -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.>|
   |                  |         |               |                |
   |                  |         |               |                |
   |                  |         |<~~~~~~~~~~~~~~~ RTCP RAMS-T ~~~|
   |                  |         |               |                |
   :                  :         :               :                :
   |                  |         |<.=.= Unicast RTCP Reports .=.=>|
   :                  :         :     for the unicast session    :
   |                  |         |               |                |

Ver Steeg, et al. Standards Track [Page 16] RFC 6285 RAMS June 2011

  1. ——> Multicast RTP Flow

.-.-.-.> Multicast RTCP Flow

 .=.=.=.> Unicast RTCP Reports
 ~~~~~~~> Unicast RTCP Feedback Messages
 =======> SFGMP Messages
 .......> Unicast RTP Flow
      Figure 3: Message Flows for Unicast-Based Rapid Acquisition
 This document defines the expected behaviors of the RS and RTP_Rx.
 It is instructive to consider independently operating implementations
 on the RS and RTP_Rx that request the burst, describe the burst,
 start the burst, join the multicast session, and stop the burst.
 These implementations send messages to each other, but provisions are
 needed for the cases where the control messages get lost, or
 reordered, or are not being delivered to their destinations.
 The following steps describe rapid acquisition in detail:
 1.   Port Mapping Setup:  For the primary multicast RTP session, the
      RTP and RTCP destination ports are declaratively specified
      (refer to Section 8 for examples in SDP).  However, the RTP_Rx
      needs to choose its RTP and RTCP receive ports for the unicast
      burst RTP session.  Since this unicast session is established
      after the RTP_Rx has sent a RAMS Request (RAMS-R) message as
      unicast feedback in the primary multicast RTP session, the
      RTP_Rx MUST first set up the port mappings between the unicast
      and multicast sessions and send this mapping information to the
      FT along with the RAMS-R message so that the BRS knows how to
      communicate with the RTP_Rx.
      The details of this setup procedure are explained in [RFC6284].
      Other NAT-related issues are left to Section 9 to keep the
      present discussion focused on the RAMS message flows.
 2.   Request:  The RTP_Rx sends a rapid acquisition request (RAMS-R)
      for the primary multicast RTP session to the unicast feedback
      target of that session.  The request contains the SSRC
      identifier of the RTP_Rx (aka SSRC of packet sender) and can
      contain the media sender SSRC identifier(s) of the primary
      multicast stream(s) of interest (aka SSRC of media source).  The
      RAMS-R message can contain parameters that constrain the burst,
      such as the buffer and bandwidth limits.
      Before joining the SSM session, the RTP_Rx learns the addresses
      for the multicast source, group, and RS by out-of-band means.
      If the RTP_Rx desires to rapidly acquire only a subset of the
      primary multicast streams available in the primary multicast RTP

Ver Steeg, et al. Standards Track [Page 17] RFC 6285 RAMS June 2011

      session, the RTP_Rx MUST also acquire the SSRC identifiers for
      the desired RTP streams out-of-band.  Based on this information,
      the RTP_Rx populates the desired SSRC(s) in the RAMS-R message.
      When the FT successfully receives the RAMS-R message, the BRS
      responds to it by accepting or rejecting the request.
      Immediately before the BRS sends any RTP or RTCP packet(s)
      described below, it establishes the unicast burst RTP session.
 3.   Response:  The BRS sends RAMS Information (RAMS-I) message(s) to
      the RTP_Rx to convey the status for the burst(s) requested by
      the RTP_Rx.
      If the primary multicast RTP session associated with the FT_Ap
      (a specific feedback target running on a particular address and
      port) on which the RAMS-R message was received contains only a
      single primary multicast stream, the BRS SHALL always use the
      SSRC of the RTP stream associated with the FT_Ap in the RAMS-I
      message(s) regardless of the media sender SSRC requested in the
      RAMS-R message.  In such cases the 'ssrc' attribute MAY be
      omitted from the media description.  If the requested SSRC and
      the actual media sender SSRC do not match, the BRS MUST
      explicitly populate the correct media sender SSRC in the initial
      RAMS-I message (see Section 7.3).
      The FT_Ap could also be associated with an RTP session that
      carries two or more primary multicast streams.  If the RTP_Rx
      wants to issue a collective request to receive the whole primary
      multicast RTP session, it does not need the 'ssrc' attributes to
      be described in the media description.
      If the FT_Ap is associated with two or more RTP sessions,
      RTP_Rx's request will be ambiguous.  To avoid any ambiguity,
      each FT_Ap MUST be only associated with a single RTP session.
      If the RTP_Rx is willing to rapidly acquire only a subset of the
      primary multicast streams, the RTP_Rx MUST list all the media
      sender SSRC(s) denoting the stream(s) it wishes to acquire in
      the RAMS-R message.  Upon receiving such a message, the BRS MAY
      accept the request for all or a subset of the media sender
      SSRC(s) that match the RTP stream(s) it serves.  The BRS MUST
      reject all other requests with an appropriate response code.
  • Reject Responses: The BRS MUST take into account any

limitations that may have been specified by the RTP_Rx in the

         RAMS-R message when making a decision regarding the request.
         If the RTP_Rx has requested to acquire the whole primary
         multicast RTP session but the BRS cannot provide a rapid

Ver Steeg, et al. Standards Track [Page 18] RFC 6285 RAMS June 2011

         acquisition service for any of the primary multicast streams,
         the BRS MUST reject the request via a single RAMS-I message
         with a collective reject response code, which is defined as
         510 in Section 11.6 and whose media sender SSRC field is set
         to one of SSRCs served by this FT_Ap.  Upon receiving this
         RAMS-I message, the RTP_Rx abandons the rapid acquisition
         attempt and can immediately join the multicast session by
         sending an SFGMP Join message towards its upstream multicast
         router.
         In all other cases, the BRS MUST send a separate RAMS-I
         message with the appropriate 5xx-level response code (as
         defined in Section 11.6) for each primary multicast stream
         that has been requested by the RTP_Rx but cannot be served by
         the BRS.  There could be multiple reasons why the BRS has
         rejected the request; however, the BRS chooses the most
         appropriate response code to inform the RTP_Rx.
         Upon receiving a reject response indicating a transient
         problem such as insufficient BRS or network resources, if the
         RTP_Rx wants to retry sending the same request, the RTP_Rx
         MUST follow the RTCP timer rules of [RFC4585] to allow the
         transient problems to go away.  However, if the reject
         response indicates a non-transient problem (such as the ones
         reported by response codes 504, 505, and 506), the RTP_Rx
         MUST NOT attempt a retry.  Different response codes have
         different scopes.  Refer to Section 7.3.1 for details.
         The BRS can employ a policing mechanism against the broken
         RTP_Rx implementations that are not following these rules.
         See Section 10 for details.
  • Accept Responses: The BRS MUST send at least one separate

RAMS-I message with the appropriate response code (either

         zero indicating a private response or response code 200
         indicating success as listed in Section 11.6) for each
         primary multicast stream that has been requested by the
         RTP_Rx and will be served by the BRS.  Such RAMS-I messages
         comprise fields that can be used to describe the individual
         unicast burst streams.  When there is a RAMS-R request for
         multiple primary multicast streams, the BRS MUST include all
         the individual RAMS-I messages corresponding to that RAMS-R
         request in the same compound RTCP packet if these messages
         fit in the same packet.  Note that if the BRS is sending only
         the preamble information but not the whole unicast burst
         stream, it will not accept the request but will send a
         response code 511 instead, as defined in Section 11.6.

Ver Steeg, et al. Standards Track [Page 19] RFC 6285 RAMS June 2011

         The RAMS-I message carries the RTP sequence number of the
         first packet transmitted in the respective RTP stream to
         allow the RTP_Rx to detect any missing initial packet(s).
         When the BRS accepts a request for a primary multicast
         stream, this field MUST always be populated in the RAMS-I
         message(s) sent for this particular primary multicast stream.
         It is RECOMMENDED that the BRS sends a RAMS-I message at the
         start of the burst so that the RTP_Rx can quickly detect any
         missing initial packet(s).
      It is possible that the RAMS-I message for a primary multicast
      stream can get delayed or lost, and the RTP_Rx can start
      receiving RTP packets before receiving a RAMS-I message.  An
      RTP_Rx implementation MUST NOT assume it will quickly receive
      the initial RAMS-I message.  For redundancy purposes, it is
      RECOMMENDED that the BRS repeats the RAMS-I messages multiple
      times as long as it follows the RTCP timer rules defined in
      [RFC4585].
 4.   Unicast Burst:  For the primary multicast stream(s) for which
      the request is accepted, the BRS starts sending the unicast
      burst(s) that comprises one or more RTP retransmission packets
      sent in the unicast burst RTP session.  In some applications,
      the BRS can send preamble information data to the RTP_Rx in
      addition to the requested burst to prime the media decoder(s).
      However, for the BRS to send the preamble information in a
      particular format, explicit signaling from the RTP_Rx is
      required.  In other words, the BRS MUST NOT send preamble
      information in a particular format unless the RTP_Rx has
      signaled support for that format in the RAMS-R message through a
      public or private extension as defined in Section 7.1.
      The format of this preamble data is RTP-payload specific and not
      specified here.
 5.   Updated Request:  The RTP_Rx MAY send an updated RAMS-R message
      (as unicast feedback in the primary multicast RTP session) with
      a different value for one or more fields of an earlier RAMS-R
      message.  The BRS MUST be able to detect whether a burst is
      already planned for or being transmitted to this particular
      RTP_Rx for this particular media sender SSRC.  If there is an
      existing burst planned for or being transmitted, the newly
      arriving RAMS-R is an updated request; otherwise, it is a new
      request.  It is also possible that the RTP_Rx has sent an
      improperly formatted RAMS-R message or used an invalid value in
      the RAMS-R message.  If notified by the BRS using a 4xx-level

Ver Steeg, et al. Standards Track [Page 20] RFC 6285 RAMS June 2011

      response code (as defined in Section 11.6) and only after
      following the timing rules of [RFC4585], the RTP_Rx MAY resend
      its corrected request.
      The BRS determines the identity of the requesting RTP_Rx by
      looking at its canonical name identifier (CNAME item in the
      source description (SDES)).  Thus, the RTP_Rx MUST choose a
      method that ensures it uses a unique CNAME identifier.  Such
      methods are provided in [RFC6222].  In addition to one or more
      fields with updated values, an updated RAMS-R message may also
      include the fields whose values did not change.
      Upon receiving an updated request, the BRS can use the updated
      values for sending/shaping the burst or refine the values and
      use the refined values for sending/shaping the burst.
      Subsequently, the BRS MAY send an updated RAMS-I message in the
      unicast burst RTP session to indicate the changes it made.
      It is an implementation-dependent decision for an RTP_RX whether
      and when to send an updated request.  However, note that the
      updated request messages can get delayed and arrive at the BRS
      after the initial unicast burst was completed.  In this case,
      the updated request message can trigger a new unicast burst, and
      by then if the RTP_Rx has already started receiving multicast
      data, a congestion is likely to occur.  In this case, the RTP_Rx
      can detect this only after a delay, and then it can try to
      terminate the new burst.  However, in the meantime, the RTP_Rx
      can experience packet loss or other problems.  This and other
      similar corner cases SHOULD be carefully examined if updated
      requests are to be used.
 6.   Updated Response:  The BRS can send more than one RAMS-I message
      in the unicast burst RTP session, e.g., to update the value of
      one or more fields in an earlier RAMS-I message.  The updated
      RAMS-I messages might or might not be a direct response to a
      RAMS-R message.  The BRS can also send updated RAMS-I messages
      to signal the RTP_Rx in real time to join the SSM session when
      the BRS had already sent an initial RAMS-I message, e.g., at the
      start of the burst.  The RTP_Rx depends on the BRS to learn the
      join time, which can be conveyed by the first RAMS-I message or
      can be sent/revised in a later RAMS-I message.  If the BRS is
      not capable of determining the join time in the initial RAMS-I
      message, the BRS MUST send another RAMS-I message (with the join
      time information) later.
 7.   Multicast Join Signaling:  The RAMS-I message allows the BRS to
      signal explicitly when the RTP_Rx needs to send the SFGMP Join
      message.  The RTP_Rx SHOULD use this information from the most

Ver Steeg, et al. Standards Track [Page 21] RFC 6285 RAMS June 2011

      recent RAMS-I message unless it has more accurate information.
      If the request is accepted, this information MUST be conveyed in
      at least one RAMS-I message, and its value MAY be updated by
      subsequent RAMS-I messages.
      There can be missing packets if the RTP_Rx joins the multicast
      session too early or too late.  For example, if the RTP_Rx
      starts receiving the primary multicast stream while it is still
      receiving the unicast burst at a high excess bitrate, this can
      result in an increased risk of packet loss.  Or, if the RTP_Rx
      joins the multicast session some time after the unicast burst is
      finished, there can be a gap between the burst and multicast
      data (a number of RTP packets might be missing).  In both cases,
      the RTP_Rx can issue retransmission requests (via RTCP NACK
      messages sent as unicast feedback in the primary multicast RTP
      session) [RFC4585] to the FT entity of the RS to fill the gap.
      The BRS might or might not respond to such requests.  When it
      responds and the response causes significant changes in one or
      more values reported earlier to the RTP_Rx, an updated RAMS-I
      SHOULD be sent to the RTP_Rx.
 8.   Multicast Receive:  After the join, the RTP_Rx starts receiving
      the primary multicast stream(s).
 9.   Terminate:  The BRS can know when it needs to ultimately stop
      the unicast burst based on its parameters.  However, the RTP_Rx
      may need to ask the BRS to terminate the burst prematurely or at
      a specific sequence number.  For this purpose, the RTP_Rx uses
      the RAMS Termination (RAMS-T) message sent as RTCP feedback in
      the unicast burst RTP session.  A separate RAMS-T message is
      sent for each primary multicast stream served by the BRS unless
      an RTCP BYE message has been sent in the unicast burst RTP
      session as described in Step 10.  For the burst requests that
      were rejected by the BRS, there is no need to send a RAMS-T
      message.
      If the RTP_Rx wants to terminate a burst prematurely, it MUST
      send a RAMS-T message for the SSRC of the primary multicast
      stream it wishes to terminate.  This message is sent in the
      unicast burst RTP session.  Upon receiving this message, the BRS
      MUST terminate the unicast burst.  If the RTP_Rx requested to
      acquire the entire primary multicast RTP session but wants to
      terminate this request before it learns the individual media
      sender SSRC(s) via RAMS-I message(s) or RTP packets, the RTP_Rx
      cannot use RAMS-T message(s) and thus MUST send an RTCP BYE
      message in the unicast burst RTP session to terminate the
      request.

Ver Steeg, et al. Standards Track [Page 22] RFC 6285 RAMS June 2011

      Otherwise, the default behavior for the RTP_Rx is to send a
      RAMS-T message in the unicast burst RTP session immediately
      after it joins the multicast session and has started receiving
      multicast packets.  In that case, the RTP_Rx MUST send a RAMS-T
      message with the sequence number of the first RTP packet
      received in the primary multicast stream.  Then, the BRS MUST
      terminate the respective burst after it sends the unicast burst
      packet whose Original Sequence Number (OSN) field in the RTP
      retransmission payload header matches this number minus one.  If
      the BRS has already sent that unicast burst packet when the
      RAMS-T message arrives, the BRS MUST terminate the respective
      burst immediately.
      If an RTCP BYE message has not been issued yet as described in
      Step 10, the RTP_Rx MUST send at least one RAMS-T message for
      each primary multicast stream served by the BRS.  The RAMS-T
      message(s) MUST be sent to the BRS in the unicast burst RTP
      session.  Against the possibility of a message loss, it is
      RECOMMENDED that the RTP_Rx repeats the RAMS-T messages multiple
      times as long as it follows the RTCP timer rules defined in
      [RFC4585].
      The binding between RAMS-T and ongoing bursts is achieved
      through RTP_Rx's CNAME identifier and packet sender and media
      sender SSRCs.  Choosing a globally unique CNAME makes sure that
      the RAMS-T messages are processed correctly.
 10.  Terminate with RTCP BYE:  When the RTP_Rx is receiving one or
      more burst streams, if the RTP_Rx becomes no longer interested
      in acquiring any of the primary multicast streams, the RTP_Rx
      SHALL issue an RTCP BYE message for the unicast burst RTP
      session and another RTCP BYE message for the primary multicast
      RTP session.  These RTCP BYE messages are sent to the BRS and FT
      logical entities, respectively.
      Upon receiving an RTCP BYE message, the BRS MUST terminate the
      rapid acquisition operation and cease transmitting any further
      burst packets and retransmission packets.  If support for
      [RFC5506] has been signaled, the RTCP BYE message MAY be sent in
      a reduced-size RTCP packet.  Otherwise, Section 6.1 of [RFC3550]
      mandates the RTCP BYE message always be sent with a sender or
      receiver report in a compound RTCP packet.  If no data has been
      received, an empty receiver report MUST be still included.  With
      the information contained in the receiver report, the RS can
      figure out how many duplicate RTP packets have been delivered to
      the RTP_Rx (note that this will be an upper-bound estimate as
      one or more packets might have been lost during the burst

Ver Steeg, et al. Standards Track [Page 23] RFC 6285 RAMS June 2011

      transmission).  The impact of duplicate packets and measures
      that can be taken to minimize the impact of receiving duplicate
      packets will be addressed in Section 6.4.
      Since an RTCP BYE message issued for the unicast burst RTP
      session terminates that session and ceases transmitting any
      further packets in that session, there is no need for sending
      explicit RAMS-T messages, which would only terminate their
      respective bursts.
 For the purpose of gathering detailed information about RTP_Rx's
 rapid acquisition experience, [MULTICAST-ACQ] defines an RTCP
 Extended Report (XR) Block.  This report is designed to be payload-
 independent; thus, it can be used by any multicast application that
 supports rapid acquisition.

6.3. Synchronization of Primary Multicast Streams

 When an RTP_RX acquires multiple primary multicast streams, it might
 need to synchronize them for playout.  This synchronization is
 achieved by the help of the RTCP sender reports [RFC3550].  If the
 playout will start before the RTP_Rx has joined the multicast
 session, the RTP_Rx needs to receive the information reflecting the
 synchronization among the primary multicast streams early enough so
 that it can play out the media in a synchronized fashion.
 The suggested approach is to use the RTP header extension mechanism
 [RFC5285] and convey the synchronization information in a header
 extension as defined in [RFC6051].  Per [RFC4588], "if the original
 RTP header carried an RTP header extension, the retransmission packet
 SHOULD carry the same header extension".  Thus, as long as the
 multicast source emits a header extension with the synchronization
 information frequently enough, there is no additional task that needs
 to be carried out by the BRS.  The synchronization information will
 be sent to the RTP_Rx along with the burst packets.  The frequent
 header extensions sent in the primary multicast RTP sessions also
 allow rapid synchronization of the RTP streams for the RTP receivers
 that do not support RAMS or that directly join the multicast session
 without running RAMS.  Thus, in RAMS applications, it is RECOMMENDED
 that the multicast sources frequently send synchronization
 information by using header extensions following the rules presented
 in [RFC6051].  The regular sender reports are still sent in the
 unicast session by following the rules of [RFC3550].

Ver Steeg, et al. Standards Track [Page 24] RFC 6285 RAMS June 2011

6.4. Burst Shaping and Congestion Control in RAMS

 This section provides informative guidelines about how the BRS can
 shape the transmission of the unicast burst and how congestion can be
 dealt with in the RAMS process.  When the RTP_Rx detects that the
 unicast burst is causing severe congestion, it can prefer to send a
 RAMS-T message immediately to stop the unicast burst.
 A higher bitrate for the unicast burst naturally conveys the
 Reference Information and media content to the RTP_Rx faster.  This
 way, the RTP_Rx can start consuming the data sooner, which results in
 a faster acquisition.  A higher bitrate also represents a better
 utilization of the BRS resources.  As the burst may continue until it
 catches up with the primary multicast stream, the higher the bursting
 bitrate, the less data the BRS needs to transmit.  However, a higher
 bitrate for the burst also increases the chances for congestion-
 caused packet loss.  Thus, as discussed in Section 5, there has to be
 an upper bound on the bandwidth used by the burst.
 When the BRS transmits the unicast burst, it is expected to take into
 account all available information to prevent any packet loss that
 might take place during the bursting as a result of buffer overflow
 on the path between the RS and RTP_Rx and at the RTP_Rx itself.  The
 bursting bitrate can be determined by taking into account the
 following information, when available:
 (a)  Information obtained via the RAMS-R message, such as Max RAMS
      Buffer Fill Requirement and/or Max Receive Bitrate (see
      Section 7.2).
 (b)  Information obtained via RTCP receiver reports provided by the
      RTP_Rx in the retransmission session, allowing in-session
      bitrate adaptations for the burst.  When these receiver reports
      indicate packet loss, this can indicate a certain congestion
      state in the path from the RS to the RTP_Rx.
 (c)  Information obtained via RTCP NACKs provided by the RTP_Rx in
      the primary multicast RTP session, allowing in-session bitrate
      adaptations for the burst.  Such RTCP NACKs are transmitted by
      the RTP_Rx in response to packet loss detection in the burst.
      NACKs can indicate a certain congestion state on the path from
      the RS to RTP_Rx.
 (d)  There can be other feedback received from the RTP_Rx, e.g., in
      the form of Explicit Congestion Notification - Congestion
      Experienced (ECN-CE) markings [ECN-FOR-RTP] that can influence
      in-session bitrate adaptation.

Ver Steeg, et al. Standards Track [Page 25] RFC 6285 RAMS June 2011

 (e)  Information obtained via updated RAMS-R messages, allowing in-
      session bitrate adaptations, if supported by the BRS.
 (f)  Transport protocol-specific information.  For example, when
      Datagram Congestion Control Protocol (DCCP) is used to transport
      the RTP burst, the ACKs from the DCCP client can be leveraged by
      the BRS / DCCP server for burst shaping and congestion control.
 (g)  Preconfigured settings for each RTP_Rx or a set of RTP_Rxs that
      indicate the upper-bound bursting bitrates for which no packet
      loss will occur as a result of congestion along the path of the
      RS to RTP_Rx.  For example, in managed IPTV networks, where the
      bottleneck bandwidth along the end-to-end path is known and
      where the network between the RS and this link is provisioned
      and dimensioned to carry the burst streams, the bursting bitrate
      does not exceed the provisioned value.  These settings can also
      be dynamically adapted using application-aware knowledge.
 The BRS chooses the initial burst bitrate as follows:
 o  When using RAMS in environments as described in (g), the BRS MUST
    transmit the burst packets at an initial bitrate higher than the
    nominal bitrate but within the engineered or reserved bandwidth
    limit.
 o  When the BRS cannot determine a reliable bitrate value for the
    unicast burst (using (a) through (g)), it is desirable for the BRS
    to choose an appropriate initial bitrate not above the nominal
    bitrate and increase it gradually unless a congestion is detected.
 In both cases, during the burst transmission, the BRS MUST
 continuously monitor for packet losses as a result of congestion by
 means of one or more of the mechanisms described in (b) through (f).
 When the BRS relies on RTCP receiver reports, sufficient bandwidth
 needs to be provided to RTP_Rx for RTCP transmission in the unicast
 burst RTP session.  To achieve a reasonable fast adaptation against
 congestion, it is recommended that the RTP_Rx sends a receiver report
 at least once every two RTTs between the RS and RTP_Rx.  Although the
 specific heuristics and algorithms that deduce a congestion state and
 how the BRS acts subsequently are outside the scope of this
 specification, the following two methods are the best practices:
 o  Upon detection of a significant amount of packet loss, which the
    BRS attributes to congestion, the BRS decreases the burst bitrate.
    The rate by which the BRS increases and decreases the bitrate for
    the burst can be determined by a TCP-friendly bitrate adaptation
    algorithm for RTP over UDP or, in the case of (f), by the
    congestion control algorithms defined in DCCP [RFC5762].

Ver Steeg, et al. Standards Track [Page 26] RFC 6285 RAMS June 2011

 o  If the congestion is persistent and the BRS has to reduce the
    burst bitrate to a point where the RTP_Rx buffer might underrun or
    the burst will consume too many resources, the BRS terminates the
    burst and transmits a RAMS-I message to RTP_Rx with the
    appropriate response code.  It is then up to RTP_Rx to decide when
    to join the multicast session.
 Even though there is no congestion experienced during the burst,
 congestion may anyway arise near the end of the burst as the RTP_Rx
 eventually needs to join the multicast session.  During this brief
 period, both the burst packets and the multicast packets can be
 simultaneously received by the RTP_Rx, thus enhancing the risk of
 congestion.
 Since the BRS signals the RTP_Rx when the BRS expects the RTP_Rx to
 send the SFGMP Join message, the BRS can have a rough estimate of
 when the RTP_Rx will start receiving multicast packets in the SSM
 session.  The BRS can keep on sending burst packets but reduces the
 bitrate accordingly at the appropriate instant by taking the bitrate
 of the whole SSM session into account.  If the BRS ceases
 transmitting the burst packets before the burst catches up, any gap
 resulting from this imperfect switch-over by the RTP_Rx can be later
 repaired by requesting retransmissions for the missing packets from
 the RS.  The retransmissions can be shaped by the BRS to make sure
 that they do not cause collateral loss in the primary multicast RTP
 session and the unicast burst RTP session.

6.5. Failure Cases

 In this section, we examine the implications of losing the RAMS-R,
 RAMS-I, or RAMS-T messages and other failure cases.
 When the RTP_Rx sends a RAMS-R message to initiate a rapid
 acquisition but the message gets lost and the FT does not receive it,
 the RTP_Rx will get neither a RAMS-I message nor a unicast burst.  In
 this case, the RTP_Rx MAY resend the request when it is eligible to
 do so based on the RTCP timer rules defined in [RFC4585].  Or, after
 a reasonable amount of time, the RTP_Rx can time out (based on the
 previous observed response times) and immediately join the SSM
 session.
 In the case where RTP_Rx starts receiving a unicast burst but does
 not receive a corresponding RAMS-I message within a reasonable amount
 of time, the RTP_Rx can either discard the burst data or decide not
 to interrupt the unicast burst and be prepared to join the SSM
 session at an appropriate time it determines or as indicated in a
 subsequent RAMS-I message (if available).  If the network is subject

Ver Steeg, et al. Standards Track [Page 27] RFC 6285 RAMS June 2011

 to packet loss, it is RECOMMENDED that the BRS repeats the RAMS-I
 messages multiple times based on the RTCP timer rules defined in
 [RFC4585].
 In the failure cases where the RAMS-I message is lost or the RAMS-R
 message is lost and the RTP_Rx gives up, the RTP_Rx MUST still
 terminate the burst(s) it requested by following the rules described
 in Section 6.2.
 In the case where a RAMS-T message sent by the RTP_Rx does not reach
 its destination, the BRS can continue sending burst packets even
 though the RTP_Rx no longer needs them.  If an RTP_Rx is receiving
 burst packets it no longer needs after sending a RAMS-T message, it
 is RECOMMENDED that the RTP_Rx repeats the RAMS-T message multiple
 times based on the RTCP timer rules defined in [RFC4585].  The BRS
 MUST be provisioned to terminate the burst when it can no longer send
 the burst packets faster than it receives the primary multicast
 stream packets.
 Section 6.3.5 of [RFC3550] explains the rules pertaining to timing
 out an SSRC.  When the BRS accepts to serve the requested burst(s)
 and establishes the retransmission session, the BRS needs to check
 the liveness of the RTP_Rx via the RTCP messages and reports the
 RTP_Rx sends.  The default rules explained in [RFC3550] apply in RAMS
 as well.

7. Encoding of the Signaling Protocol in RTCP

 This section defines the formats of the RTCP transport-layer feedback
 messages that are exchanged between the retransmission server (RS)
 and RTP receiver (RTP_Rx) during rapid acquisition.  These messages
 are referred to as the RAMS Messages.  They are payload-independent
 and MUST be used by all RTP-based multicast applications that support
 rapid acquisition regardless of the payload they carry.
 Payload-specific feedback messages are not defined in this document.
 However, further optional payload-independent and payload-specific
 information can be included in the exchange.
 The common packet format for the RTCP feedback messages is defined in
 Section 6.1 of [RFC4585] and is also sketched in Figure 4.

Ver Steeg, et al. Standards Track [Page 28] RFC 6285 RAMS June 2011

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|   FMT   |       PT      |          length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of packet sender                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of media source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :            Feedback Control Information (FCI)                 :
   :                                                               :
   Figure 4: The Common Packet Format for the RTCP Feedback Messages
 Each feedback message has a fixed-length field for version, padding,
 feedback message type (FMT), packet type (PT), length, SSRC of packet
 sender, SSRC of media source, and a variable-length field for
 feedback control information (FCI).
 In the RAMS messages, the PT field is set to RTPFB (205) and the FMT
 field is set to RAMS (6).  Individual RAMS messages are identified by
 a sub-field called sub-feedback message type (SFMT).  Any Reserved
 field SHALL be set to zero and ignored.
 Depending on the specific scenario and timeliness/importance of a
 RAMS message, it can be desirable to send it in a reduced-size RTCP
 packet [RFC5506].  However, unless support for [RFC5506] has been
 signaled, compound RTCP packets MUST be used by following [RFC3550]
 rules.
 Following the rules specified in [RFC3550], all integer fields in the
 messages defined below are carried in network-byte order, that is,
 most significant byte (octet) first, also known as big-endian.
 Unless otherwise stated, numeric constants are in decimal (base 10).

7.1. Extensions

 To improve the functionality of the RAMS method in certain
 applications, it can be desirable to define new fields in the RAMS
 Request, Information, and Termination messages.  Such fields MUST be
 encoded as Type-Length-Value (TLV) elements as described below and
 sketched in Figure 5:
 o  Type:  A single-octet identifier that defines the type of the
    parameter represented in this TLV element.

Ver Steeg, et al. Standards Track [Page 29] RFC 6285 RAMS June 2011

 o  Length:  A two-octet field that indicates the length (in octets)
    of the TLV element excluding the Type and Length fields and the
    8-bit Reserved field between them.  This length does not include
    any padding that is required for alignment.
 o  Value:  Variable-size set of octets that contains the specific
    value for the parameter.
 In the extensions, the Reserved field SHALL be set to zero and
 ignored.  If a TLV element does not fall on a 32-bit boundary, the
 last word MUST be padded to the boundary using further bits set to
 zero.
 An RTP_Rx or BRS MAY include vendor-neutral and private extensions in
 any RAMS message.  The RTP_Rx or BRS MUST place such extensions after
 the mandatory fields and mandatory TLV elements (if any) and MAY
 place such extensions in any order.  The RTP_Rx or BRS MUST NOT
 include multiple TLV elements with the same Type value in a RAMS
 message.
 The support for extensions (unless specified otherwise) is OPTIONAL.
 An RTP_Rx or BRS receiving a vendor-neutral or private extension that
 it does not understand MUST ignore that extension.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Reserved    |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                             Value                             :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Figure 5: Structure of a TLV Element

7.1.1. Vendor-Neutral Extensions

 If the goal in defining new TLV elements is to extend the
 functionality in a vendor-neutral manner, they MUST be registered
 with IANA through the guidelines provided in Section 11.5.
 The current document defines several vendor-neutral extensions in the
 subsequent sections.

7.1.2. Private Extensions

 It is desirable to allow vendors to use private extensions in a TLV
 format.  For interoperability, such extensions must not collide with
 each other.

Ver Steeg, et al. Standards Track [Page 30] RFC 6285 RAMS June 2011

 A certain range of TLV Types (between and including 128 and 254 ) is
 reserved for private extensions (refer to Section 11.5).  IANA
 management for these extensions is unnecessary, and they are the
 responsibility of individual vendors.
 The structure that MUST be used for the private extensions is
 depicted in Figure 6.  Here, the enterprise numbers are as listed on
 http://www.iana.org.  This will ensure the uniqueness of the private
 extensions and avoid any collision.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |   Reserved    |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Enterprise Number                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                             Value                             :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Figure 6: Structure of a Private Extension

7.2. RAMS Request

 The RAMS Request (RAMS-R) message is identified by SFMT=1.  This
 message is sent as unicast feedback in the primary multicast RTP
 session by the RTP_Rx to request rapid acquisition of a primary
 multicast RTP session or one or more primary multicast streams
 belonging to the same primary multicast RTP session.  In the RAMS-R
 message, the RTP_Rx MUST set both the packet sender SSRC and media
 sender SSRC fields to its own SSRC since the media sender SSRC may
 not be known.  The RTP_Rx MUST provide explicit signaling as
 described below to request stream(s).  This minimizes the chances of
 accidentally requesting a wrong primary multicast stream.
 The FCI field MUST contain only one RAMS Request.  The FCI field has
 the structure depicted in Figure 7.
 The semantics of the RAMS-R message is independent of the payload
 type carried in the primary multicast RTP session.

Ver Steeg, et al. Standards Track [Page 31] RFC 6285 RAMS June 2011

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    SFMT=1     |                    Reserved                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :                  Requested Media Sender SSRC(s)               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :      Optional TLV-encoded Fields (and Padding, if needed)     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Figure 7: FCI Field Syntax for the RAMS Request Message
 o  Requested Media Sender SSRC(s):  Mandatory TLV element that lists
    the media sender SSRC(s) requested by the RTP_Rx.  The BRS MUST
    ignore the media sender SSRC specified in the header of the RAMS-R
    message.
    If the Length field is set to zero (i.e., no media sender SSRC is
    listed), it means that the RTP_Rx is requesting to rapidly acquire
    the entire primary multicast RTP session.  Otherwise, the RTP_Rx
    lists the individual media sender SSRCs in this TLV element and
    sets the Length field of the TLV element to 4*n, where n is the
    number of SSRC entries.
    Type:  1
 o  Min RAMS Buffer Fill Requirement (32 bits):  Optional TLV element
    that denotes the minimum milliseconds of data that the RTP_Rx
    desires to have in its buffer before allowing the data to be
    consumed by the application.
    The RTP_Rx can have knowledge of its buffering requirements.
    These requirements can be application and/or device specific.  For
    instance, the RTP_Rx might need to have a certain amount of data
    in its application buffer to handle transmission jitter and/or to
    be able to support error-control methods.  If the BRS is told the
    minimum buffering requirement of the receiver, the BRS can tailor
    the burst(s) more precisely, e.g., by choosing an appropriate
    starting point.  The methods used by the RTP_Rx to determine this
    value are application specific and thus out of the scope of this
    document.

Ver Steeg, et al. Standards Track [Page 32] RFC 6285 RAMS June 2011

    If specified, the amount of backfill that will be provided by the
    unicast bursts and any payload-specific information MUST NOT be
    smaller than the specified value.  Otherwise, the backfill will
    not be able to build up the desired level of buffer at the RTP_Rx
    and can cause buffer underruns.
    Type:  2
 o  Max RAMS Buffer Fill Requirement (32 bits):  Optional TLV element
    that denotes the maximum milliseconds of data that the RTP_Rx can
    buffer without losing the data due to buffer overflow.
    The RTP_Rx can have knowledge of its buffering requirements.
    These requirements can be application or device specific.  For
    instance, one particular RTP_Rx might have more physical memory
    than another RTP_Rx and thus can buffer more data.  If the BRS
    knows the buffering ability of the receiver, the BRS can tailor
    the burst(s) more precisely.  The methods used by the receiver to
    determine this value are application specific and thus out of the
    scope of this document.
    If specified, the amount of backfill that will be provided by the
    unicast bursts and any payload-specific information MUST NOT be
    larger than this value.  Otherwise, the backfill may cause buffer
    overflows at the RTP_Rx.
    Type:  3
 o  Max Receive Bitrate (64 bits):  Optional TLV element that denotes
    the maximum bitrate (in bits per second) at which the RTP_Rx can
    process the aggregation of the unicast burst(s) and any payload-
    specific information that will be provided by the BRS.  The limits
    can include local receiver limits as well as network limits that
    are known to the receiver.
    If specified, the total bitrate of the unicast burst(s) plus any
    payload-specific information MUST NOT be larger than this value.
    Otherwise, congestion and packet loss are more likely to occur.
    Type:  4
 o  Preamble-only Allowed (0 bits):  Optional TLV element that
    indicates that the RTP_Rx is willing to receive only the preamble
    information for the desired primary multicast stream(s) in case
    the BRS cannot send the unicast burst stream(s).  (In such cases,
    the BRS will not accept the request, but will send a response code
    511 in the RAMS-I message as defined in Section 11.6.)  Note that

Ver Steeg, et al. Standards Track [Page 33] RFC 6285 RAMS June 2011

    the RTP_Rx signals the particular preamble format(s) it supports
    through a public or a private extension in the same RAMS-R
    message.
    If this TLV element does not exist in the RAMS-R message, the BRS
    MUST NOT respond to the RAMS-R message by sending the preamble
    information only.  Since this TLV element does not carry a Value
    field, the Length field MUST be set to zero.
    Type:  5
 o  Supported Enterprise Number(s):  Optional TLV element that
    indicates the enterprise number(s) that the RTP_Rx implementation
    supports.  Similar to the private extensions, the enterprise
    numbers here are as listed on http://www.iana.org.  This TLV
    element, if exists, provides a hint to the BRS about which private
    extensions the RTP_Rx can potentially support.  Note that an
    RTP_Rx does not necessarily support all the private extensions
    under a particular enterprise number.  Unless the BRS explicitly
    knows which private extensions an RTP_Rx supports (through this or
    some out-of-band means), the BRS SHOULD NOT use private extensions
    in the RAMS-I messages.  The BRS SHOULD rather use only vendor-
    neutral extensions.  The Length field of this TLV element is set
    to 4*n, where n is the number of enterprise number entries.
    Type:  6

7.3. RAMS Information

 The RAMS Information (RAMS-I) message is identified by SFMT=2.  This
 message is used to describe the unicast burst that will be sent for
 rapid acquisition.  It also includes other useful information for the
 RTP_Rx as described below.
 A separate RAMS-I message with the appropriate response code is sent
 in the unicast burst RTP session by the BRS for each primary
 multicast stream that has been requested by the RTP_Rx.  In each of
 these RAMS-I messages, the media sender SSRC and packet sender SSRC
 fields are both set to the SSRC of the BRS, which equals the SSRC of
 the respective primary multicast stream.
 The FCI field MUST contain only one RAMS Information message.  The
 FCI field has the structure depicted in Figure 8.
 The semantics of the RAMS-I message is independent of the payload
 type carried in the primary multicast RTP session.

Ver Steeg, et al. Standards Track [Page 34] RFC 6285 RAMS June 2011

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    SFMT=2     |      MSN      |          Response             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :      Optional TLV-encoded Fields (and Padding, if needed)     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Figure 8: FCI Field Syntax for the RAMS Information Message
 A RAMS-I message has the following fields:
 o  Message Sequence Number (MSN) (8 bits) :  Mandatory field that
    denotes the sequence number of the RAMS-I message for the
    particular media sender SSRC specified in the message header.  The
    MSN value SHALL be set to zero when a new RAMS request is
    received.  During rapid acquisition, the same RAMS-I message MAY
    be repeated for redundancy purposes without incrementing the MSN
    value.  If an updated RAMS-I message will be sent (either with new
    information or updated information), the MSN value SHALL be
    incremented by one.  In the MSN field, the regular wrapping rules
    apply.  Note that if the RTP_Rx has sent an updated request, it
    MUST check every RAMS-I message entirely, regardless of whether or
    not the MSN value has changed.
 o  Response (16 bits):  Mandatory field that denotes the response
    code for this RAMS-I message.  This document defines several
    initial response codes in Section 7.3.1 and registers them with
    IANA in Section 11.6.  If a new vendor-neutral response code will
    be defined, it MUST be registered with IANA through the guidelines
    specified in Section 11.6.  If the new response code is intended
    to be used privately by a vendor, there is no need for IANA
    management.  Instead, the vendor MUST use the private extension
    mechanism (Section 7.1.2) to convey its message and MUST indicate
    this by putting zero in the Response field.
    When the RTP_Rx receives a RAMS-I message with a response code
    that it does not understand, the RTP_Rx MUST send a RAMS-T message
    immediately to the BRS.
 The following TLV elements have been defined for the RAMS-I messages:
 o  Media Sender SSRC (32 bits):  Optional TLV element that specifies
    the media sender SSRC of the unicast burst stream.  If the FT_Ap
    that received the RAMS-R message is associated with a single
    primary multicast stream but the requested media sender SSRC does
    not match the SSRC of the RTP stream associated with this FT_Ap,

Ver Steeg, et al. Standards Track [Page 35] RFC 6285 RAMS June 2011

    the BRS includes this TLV element in the initial RAMS-I message to
    let the RTP_Rx know that the media sender SSRC has changed.  If
    the two SSRCs match, there is no need to include this TLV element.
    Type:  31
 o  RTP Seqnum of the First Packet (16 bits):  TLV element that
    specifies the RTP sequence number of the first packet that will be
    sent in the respective unicast RTP stream.  This allows the RTP_Rx
    to know whether one or more packets sent by the BRS have been
    dropped at the beginning of the stream.  If the BRS accepts the
    RAMS request, this element exists.  If the BRS rejects the RAMS
    request, this element SHALL NOT exist.
    Type:  32
 o  Earliest Multicast Join Time (32 bits):  TLV element that
    specifies the delta time (in ms) between the arrival of the first
    RTP packet in the unicast RTP stream (which could be a burst
    packet or a payload-specific packet) and the earliest time instant
    when an RTP_Rx MAY send an SFGMP Join message to join the
    multicast session.  A zero value indicated in this element means
    that the RTP_Rx MAY send the SFGMP Join message right away.  If
    the RTP_Rx does not want to wait until the earliest multicast join
    time, it MAY send a RAMS-T message, and after a reasonable amount
    of time, it MAY join the SSM session.
    If the RAMS request has been accepted, the BRS sends this element
    at least once so that the RTP_Rx knows when to join the multicast
    session.  If the burst request has been rejected as indicated in
    the Response field, this element MUST indicate a zero value.  In
    that case, it is up to the RTP_Rx when or whether to join the
    multicast session.
    When the BRS serves two or more bursts and sends a separate RAMS-I
    message for each burst, the join times specified in these RAMS-I
    messages SHOULD correspond to more or less the same time instant,
    and the RTP_Rx sends the SFGMP Join message based on the earliest
    join time.
    Type:  33
 o  Burst Duration (32 bits):  Optional TLV element that denotes the
    time the burst will last (in ms), i.e., the difference between the
    expected transmission times of the first and the last burst
    packets that the BRS is planning to send in the respective unicast
    RTP stream.  In the absence of additional stimulus, the BRS will

Ver Steeg, et al. Standards Track [Page 36] RFC 6285 RAMS June 2011

    send a burst of this duration.  However, the burst duration can be
    modified by subsequent events, including changes in the primary
    multicast stream and reception of RAMS-T messages.
    The BRS MUST terminate the flow in the timeframe indicated by this
    burst duration or the duration established by those subsequent
    events even if it does not get a RAMS-T or a BYE message from the
    RTP_Rx.  It is OPTIONAL to send this element in a RAMS-I message
    when the burst request is accepted.  If the burst request has been
    rejected as indicated in the Response field, this element MAY be
    omitted or indicate a zero value.
    Type:  34
 o  Max Transmit Bitrate (64 bits):  Optional TLV element that denotes
    the maximum bitrate (in bits per second) that will be used by the
    BRS for the RTP stream associated with this RAMS-I message.
    Type:  35

7.3.1. Response Code Definitions

 1xx-Level Response Codes:  These response codes are sent for
 informational purposes.
 o  100:  This is used when the BRS wants to update a value that was
    sent earlier to the RTP_Rx.
 2xx-Level Response Codes:  These response codes are sent to indicate
 success.
 o  200:  This is used when the server accepts the RAMS request.
 o  201:  This is used when the unicast burst has been completed and
    the BRS wants to notify the RTP_Rx.
 4xx-Level Response Codes:  These response codes are sent to indicate
 that the message sent by the RTP_Rx is either improperly formatted or
 contains an invalid value.  The rules the RTP_Rx needs to follow upon
 receiving one of these response codes are outlined in Step 5 in
 Section 6.2.  The 4xx-level response codes are also used as status
 codes in the Multicast Acquisition Report Block [MULTICAST-ACQ] in
 order to collect RTP_Rx-based error conditions.
 o  400:  This is used when the RAMS-R message is improperly
    formatted.

Ver Steeg, et al. Standards Track [Page 37] RFC 6285 RAMS June 2011

 o  401:  This is used when the minimum RAMS buffer fill requirement
    value indicated in the RAMS-R message is invalid.
 o  402:  This is used when the maximum RAMS buffer fill requirement
    value indicated in the RAMS-R message is invalid.
 o  403:  This is used when the maximum receive bitrate value
    indicated in the RAMS-R message is insufficient.
 o  404:  This is used when the RAMS-T message is improperly
    formatted.
 5xx-Level Response Codes:  These response codes are sent to indicate
 an error on the BRS side.  The rules the RTP_Rx needs to follow upon
 receiving one of these response codes are outlined in Step 3 in
 Section 6.2.  The 5xx-level response codes are also used as status
 codes in the Multicast Acquisition Report Block [MULTICAST-ACQ] in
 order to collect BRS-based error conditions.
 o  500:  This is used when the BRS has experienced an internal error
    and cannot accept the RAMS request.
 o  501:  This is used when the BRS does not have enough bandwidth to
    send the unicast burst stream.
 o  502:  This is used when the BRS terminates the unicast burst
    stream due to network congestion.
 o  503:  This is used when the BRS does not have enough CPU resources
    to send the unicast burst stream.
 o  504:  This is used when the BRS does not support sending a unicast
    burst stream.
 o  505:  This is used when the requesting RTP_Rx is not eligible to
    receive a unicast burst stream.
 o  506:  This is used when RAMS functionality is not enabled for the
    requested multicast stream.
 o  507:  This is used when the BRS cannot find a valid starting point
    for the unicast burst stream that satisfies the RTP_Rx's
    requirements.
 o  508:  This is used when the BRS cannot find the essential
    reference information for the requested multicast stream.

Ver Steeg, et al. Standards Track [Page 38] RFC 6285 RAMS June 2011

 o  509:  This is used when the BRS cannot match the requested SSRC to
    any of the streams it is serving.
 o  510:  This is used when the BRS cannot serve the requested entire
    session.
 o  511:  This is used when the BRS sends only the preamble
    information but not the whole unicast burst stream.
 o  512:  This is used when the RAMS request is denied due to a policy
    for the requested multicast stream, the RTP_Rx, or this particular
    BRS.

7.4. RAMS Termination

 The RAMS Termination (RAMS-T) message is identified by SFMT=3.
 The RAMS Termination is used to assist the BRS in determining when to
 stop the burst.  A separate RAMS-T message is sent in the unicast
 burst RTP session by the RTP_Rx for each primary multicast stream
 that has been served by the BRS.  Each of these RAMS-T message's
 media sender SSRC field SHALL BE populated with the SSRC of the media
 stream to be terminated.  If the media sender SSRC populated in the
 RAMS-T message does not match the SSRC of the burst served by the
 BRS, BRS SHALL ignore the RAMS-T message.
 If the RTP_Rx wants the BRS to stop a burst prematurely, it sends a
 RAMS-T message as described below.  Upon receiving this message, the
 BRS stops the respective burst immediately.  If the RTP_Rx wants the
 BRS to terminate all of the bursts, it needs to send all of the
 respective RAMS-T messages in a single compound RTCP packet.
 The default behavior for the RTP_Rx is to send a RAMS-T message
 immediately after it joined the multicast session and started
 receiving multicast packets.  In that case, the RTP_Rx includes the
 sequence number of the first RTP packet received in the primary
 multicast stream in the RAMS-T message.  With this information, the
 BRS can decide when to terminate the unicast burst.
 The FCI field MUST contain only one RAMS Termination.  The FCI field
 has the structure depicted in Figure 9.
 The semantics of the RAMS-T message is independent of the payload
 type carried in the primary multicast RTP session.

Ver Steeg, et al. Standards Track [Page 39] RFC 6285 RAMS June 2011

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    SFMT=3     |                    Reserved                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :      Optional TLV-encoded Fields (and Padding, if needed)     :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Figure 9: FCI field syntax for the RAMS Termination message
 o  Extended RTP Seqnum of First Multicast Packet (32 bits):  Optional
    TLV element that specifies the extended RTP sequence number of the
    first packet received from the SSM session for a particular
    primary multicast stream.  The low 16 bits contain the sequence
    number of the first packet received from the SSM session, and the
    most significant 16 bits extend that sequence number with the
    corresponding count of sequence number cycles, which can be
    maintained according to the algorithm in Appendix A.1 of
    [RFC3550].
    Type:  61

8. SDP Signaling

8.1. Definitions

 The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585].
 Here we add the following syntax to the 'rtcp-fb' attribute (the
 feedback type and optional parameters are all case sensitive):
 (In the following ABNF [RFC5234], rtcp-fb-nack-param is used as
 defined in [RFC4585].)
       rtcp-fb-nack-param =/ SP "rai"
 The following parameter is defined in this document for use with
 'nack':
 o  'rai' stands for Rapid Acquisition Indication and indicates the
    use of RAMS messages as defined in Section 7.
 This document also defines a new media-level SDP attribute
 ('rams-updates') that indicates whether or not the BRS supports
 updated request messages.  This attribute is used in a declarative
 manner and no Offer/Answer Model behavior is specified.  If the BRS
 supports updated request messages and this attribute is included in
 the SDP description, the RTP_Rx can send updated requests.  The BRS
 might or might not be able to accept value changes in every field in

Ver Steeg, et al. Standards Track [Page 40] RFC 6285 RAMS June 2011

 an updated RAMS-R message.  However, if the 'rams-updates' attribute
 is not included in the SDP description, the RTP_Rx SHALL NOT send
 updated requests.  The RTP_Rx MAY still repeat its initial request
 without changes, though.

8.2. Requirements

 The use of SDP to describe the RAMS entities normatively requires
 support for:
 o  The SDP grouping framework and flow identification (FID) semantics
    [RFC5888]
 o  The RTP/AVPF profile [RFC4585]
 o  The RTP retransmission payload format [RFC4588]
 o  The RTCP extensions for SSM sessions with unicast feedback
    [RFC5760]
 o  The 'multicast-rtcp' attribute [RFC6128]
 o  Multiplexing RTP and RTCP on a single port on both endpoints in
    the unicast session [RFC5761]
 o  The 'portmapping-req' attribute [RFC6284]
 Support for the source-specific media attributes [RFC5576] can also
 be needed when the 'ssrc' attribute is to be used for the media
 descriptions.

8.3. Example and Discussion

 This section provides a declarative SDP [RFC4566] example (for the
 RTP_Rx side) for enabling rapid acquisition of multicast RTP
 sessions.
      v=0
      o=ali 1122334455 1122334466 IN IP4 rams.example.com
      s=Rapid Acquisition Example
      t=0 0
      a=group:FID 1 2
      a=rtcp-unicast:rsi
      m=video 41000 RTP/AVPF 98
      i=Primary Multicast Stream
      c=IN IP4 233.252.0.2/255
      a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
      a=rtpmap:98 MP2T/90000

Ver Steeg, et al. Standards Track [Page 41] RFC 6285 RAMS June 2011

      a=multicast-rtcp:42000
      a=rtcp:43000 IN IP4 192.0.2.1
      a=rtcp-fb:98 nack
      a=rtcp-fb:98 nack rai
      a=ssrc:123321 cname:iptv-ch32@rams.example.com
      a=rams-updates
      a=portmapping-req:54000 IN IP4 192.0.2.1
      a=mid:1
      m=video 51000 RTP/AVPF 99
      i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support)
      c=IN IP4 192.0.2.1
      a=sendonly
      a=rtpmap:99 rtx/90000
      a=rtcp-mux
      a=rtcp:51500
      a=fmtp:99 apt=98;rtx-time=5000
      a=portmapping-req:55000
      a=mid:2
       Figure 10: Example SDP for a Single-Channel RAMS Scenario
 In this example SDP description, we have a primary multicast (source)
 stream and a unicast retransmission stream.  The source stream is
 multicast from a distribution source (with a source IP address of
 198.51.100.1) to the multicast destination address of 233.252.0.2 and
 port 41000.  The corresponding RTCP traffic is multicast to the same
 multicast destination address at port 42000.  Here, we are assuming
 that the multicast RTP and RTCP ports are carefully chosen so that
 different RTP and RTCP streams do not collide with each other.
 The feedback target (FT_Ap) residing on the RS (with an address of
 192.0.2.1) at port 43000 is declared with the "a=rtcp" line
 [RFC3605].  The support for the conventional retransmission is
 indicated through the "a=rtcp-fb:98 nack" line.  The RTP receiver(s)
 can report missing packets on the source stream to the feedback
 target and request retransmissions.  The SDP above includes the
 "a=sendonly" line for the media description of the retransmission
 stream since the retransmissions are sent in only one direction.
 The support for rapid acquisition is indicated through the "a=rtcp-
 fb:98 nack rai" line.  The parameter 'rtx-time' applies to both the
 conventional retransmissions and rapid acquisition.  However, when
 rapid acquisition is enabled, the standard definition for the
 parameter 'rtx-time' given in [RFC4588] is not followed.  Instead,
 when rapid acquisition support is enabled, 'rtx-time' specifies the
 time in milliseconds that the BRS keeps an RTP packet in its cache

Ver Steeg, et al. Standards Track [Page 42] RFC 6285 RAMS June 2011

 available for retransmission (measured from the time the packet was
 received by the BRS, not from the time indicated in the packet
 timestamp).
 Once an RTP_Rx has acquired an SDP description, it can ask for rapid
 acquisition before it joins a primary multicast RTP session.  To do
 so, it sends a RAMS-R message to the feedback target of that primary
 multicast RTP session.  If the FT_Ap is associated with only one RTP
 stream, the RTP_Rx does not need to learn the SSRC of that stream via
 an out-of-band method.  If the BRS accepts the rapid acquisition
 request, it will send a RAMS-I message with the correct SSRC
 identifier.  If the FT_Ap is associated with a multi-stream RTP
 session and the RTP_Rx is willing to request rapid acquisition for
 the entire session, the RTP_Rx again does not need to learn the SSRCs
 via an out-of-band method.  However, if the RTP_Rx intends to request
 a particular subset of the primary multicast streams, it must learn
 their SSRC identifiers and list them in the RAMS-R message.  Since
 this RTP_Rx has not yet received any RTP packets for the primary
 multicast stream(s), the RTP_Rx must in this case learn the SSRC
 value(s) from the 'ssrc' attribute of the media description
 [RFC5576].  In addition to the SSRC value, the 'cname' source
 attribute must also be present in the SDP description [RFC5576].
 Listing the SSRC values for the primary multicast streams in the SDP
 file does not create a problem in SSM sessions when an SSRC collision
 occurs.  This is because in SSM sessions, an RTP_Rx that observed an
 SSRC collision with a media sender must change its own SSRC [RFC5760]
 by following the rules defined in [RFC3550].
 A feedback target that receives a RAMS-R message becomes aware that
 the RTP_Rx wants to rapidly catch up with a primary multicast RTP
 session.  If the necessary conditions are satisfied (as outlined in
 Section 7 of [RFC4585]) and available resources exist, the BRS can
 react to the RAMS-R message by sending any transport-layer (and
 optional payload-specific, when allowed) feedback message(s) and
 starting the unicast burst.
 In this section, we considered the simplest scenario where the
 primary multicast RTP session carried only one stream and the RTP_Rx
 wanted to rapidly acquire this stream only.  Best practices for
 scenarios where the primary multicast RTP session carries two or more
 streams or the RTP_Rx wants to acquire one or more streams from
 multiple primary multicast RTP sessions at the same time are
 presented in [RAMS-SCENARIOS].

Ver Steeg, et al. Standards Track [Page 43] RFC 6285 RAMS June 2011

9. NAT Considerations

 For a variety of reasons, one or more Network Address Port
 Translators (NAPT, hereafter simply called NAT) can exist between the
 RTP_Rx and RS.  NATs have a variety of operating characteristics for
 UDP traffic [RFC4787].  For a NAT to permit traffic from the BRS to
 arrive at the RTP_Rx, the NAT(s) must first either:
 a.  See UDP (or DCCP) traffic sent from the RTP_Rx (which is on the
     'inside' of the NAT) to the BRS (which is on the 'outside' of the
     NAT).  This traffic has the same transport address as the
     subsequent response traffic, or
 b.  Be configured to forward certain ports (e.g., using HTML
     configuration or Universal Plug and Play (UPnP) Internet Gateway
     Device (IGD) [UPnP-IGD]).  Details of this are out of the scope
     of this document.
 For both (a) and (b), the RTP_Rx is responsible for maintaining the
 NAT's state if it wants to receive traffic from the BRS on that port.
 For (a), the RTP_Rx MUST send UDP traffic to keep the NAT binding
 alive, at least every 30 seconds [RFC4787].  While (a) is more like
 an automatic/dynamic configuration, (b) is more like a manual/static
 configuration.
 When the RTP_Rx sends a request (RAMS-R) message to the FT as unicast
 feedback in the primary multicast RTP session and the request is
 received by the FT, a new unicast burst RTP session will be
 established between the BRS and RTP_Rx.
 While the FT and BRS ports on the RS are already signaled via out-of-
 band means (e.g., SDP), the RTP_Rx needs to convey the RTP and RTCP
 ports it wants to use on its side for the new session.  Since there
 are two RTP sessions (one multicast and one unicast) involved during
 this process and one of them is established upon a feedback message
 sent in the other one, this requires an explicit port mapping method.
 Applications using RAMS MUST support the method presented in
 [RFC6284] both on the RS and RTP_Rx side to allow RTP receivers to
 use their desired ports and to support RAMS behind NAT devices.  The
 port mapping message exchange needs to take place whenever the RTP_Rx
 intends to make use of the RAMS protocol for rapidly acquiring a
 specific multicast RTP session prior to joining the associated SSM
 session.

Ver Steeg, et al. Standards Track [Page 44] RFC 6285 RAMS June 2011

10. Security Considerations

 Applications that are using RAMS make heavy use of the unicast
 feedback mechanism described in [RFC5760], the payload format defined
 in [RFC4588], and the port mapping solution specified in [RFC6284].
 Thus, these applications are subject to the general security
 considerations discussed in those documents.  In particular, the
 threats and risks discussed in [RFC5760] need to be considered
 carefully.  In this section, we give an overview of the guidelines
 and suggestions described in these specifications from a RAMS
 perspective.  We also discuss the security considerations that
 explicitly apply to applications using RAMS.
 First of all, much of the session description information is
 available in the SDP descriptions that are distributed to the media
 senders, retransmission servers, and RTP receivers.  Adequate
 security measures are RECOMMENDED to ensure the integrity and
 authenticity of the SDP descriptions so that transport addresses of
 the media senders, distribution sources, feedback targets, and other
 session-specific information can be protected.  See [RFC4566] for
 details.
 Compared to an RTCP NACK message that triggers one or more
 retransmissions, a RAMS Request (RAMS-R) message can trigger a new
 burst stream to be sent by the retransmission server.  Depending on
 the application-specific requirements and conditions existing at the
 time of the RAMS-R reception by the retransmission server, the
 resulting burst stream can potentially contain a large number of
 retransmission packets.  Since these packets are sent faster than the
 nominal rate, RAMS consumes more resources on the retransmission
 servers, RTP receivers, and the network.  In particular, this can
 make denial-of-service (DoS) attacks more intense and hence more
 harmful than attacks that target ordinary retransmission sessions.
 As RAMS messages are sent as RTCP messages, counter-measures SHOULD
 be taken to prevent tampered or spoofed RTCP packets, following the
 suggestions given in [RFC4588].  Tampered RAMS-R messages can trigger
 inappropriate burst streams or alter the existing burst streams in an
 inappropriate way.  For example, if the Max Receive Bitrate field is
 altered by a tampered RAMS-R message, the updated burst can overflow
 the buffer at the receiver side or, oppositely, can slow down the
 burst to the point that it becomes useless.  Tampered RAMS
 Termination (RAMS-T) messages can terminate valid burst streams
 prematurely resulting in gaps in the received RTP packets.  RAMS
 Information (RAMS-I) messages contain fields that are critical for a
 successful rapid acquisition.  Any tampered information in the RAMS-I
 message can easily cause an RTP receiver to make wrong decisions.
 Consequently, the RAMS operation can fail.

Ver Steeg, et al. Standards Track [Page 45] RFC 6285 RAMS June 2011

 RTCP BYE messages are similar to RAMS-T messages in the sense that
 they can be used to stop an existing burst.  The CNAME of an RTP
 receiver is used to bind the RTCP BYE message to an existing burst.
 Thus, one should be careful if the CNAMEs are reasonably easy to
 guess and off-path attacks can be performed.  Also note that the
 CNAMEs might be redistributed to all participants in the multicast
 group (as in ASM or the simple feedback model of [RFC5760]).
 The retransmission server has to consider if values indicated in a
 RAMS-R message are reasonable.  For example, a request demanding a
 large value of many seconds in the Min RAMS Buffer Fill Requirement
 element should, unless special use cases exist, likely be rejected
 since it is likely to be an attempt to prolong a DoS attack on the
 retransmission server, RTP receiver, and/or the network.  The Max
 Receive Bitrate could also be set to a very large value to try to get
 the retransmission server to cause massive congestion by bursting at
 a bitrate that will not be supported by the network.  An RTP_Rx
 should also consider if the values for the Earliest Multicast Join
 Time and Burst Duration indicated by the retransmission server in a
 RAMS-I message are reasonable.  For example, if the burst packets
 stop arriving and the join time is still significantly far into the
 future, this could be a sign of a man-in-the-middle attack where the
 RAMS-I message has been manipulated by an attacker.
 A basic mitigation against DoS attacks introduced by an attacker
 injecting tampered RAMS messages is source address validation
 [RFC2827].  Also, most of the DoS attacks can be prevented by the
 integrity and authenticity checks enabled by Secure RTP (SRTP)
 [RFC3711].  However, an attack can still be started by legitimate
 endpoints that send several valid RAMS-R messages to a particular
 feedback target in a synchronized fashion and in a very short amount
 of time.  Since a RAMS operation can temporarily consume a large
 amount of resources, a series of the RAMS-R messages can temporarily
 overload the retransmission server.  In these circumstances, the
 retransmission server can, for example, reject incoming RAMS requests
 until its resources become available again.  One means to ameliorate
 this threat is to apply a per-endpoint policing mechanism on the
 incoming RAMS requests.  A reasonable policing mechanism should
 consider application-specific requirements and minimize false
 negatives.
 In addition to the DoS attacks, man-in-the-middle and replay attacks
 will also be harmful.  RAMS-R messages do not carry any information
 that allows the retransmission server to detect duplication or replay
 attacks.  Thus, the possibility of a replay attack using a captured
 valid RAMS-R message exists unless a mitigation method such as Secure
 RTCP (SRTCP) is used.  Similarly, RAMS-T messages can be replayed.
 The RAMS-I has a sequence number that makes replay attacks less

Ver Steeg, et al. Standards Track [Page 46] RFC 6285 RAMS June 2011

 likely but not impossible.  Man-in-the-middle attacks that are
 capable of capturing, injecting, or modifying the RAMS messages can
 easily accomplish the attacks described above.  Thus, cryptographic
 integrity and authentication is the only reliable protection.  To
 protect the RTCP messages from man-in-the-middle and replay attacks,
 the RTP receivers and retransmission server SHOULD perform a Datagram
 Transport Layer Security (DTLS)-SRTP handshake [RFC5764] over the
 RTCP channel.  Because there is no integrity-protected signaling
 channel between an RTP receiver and the retransmission server, the
 retransmission server MUST maintain a list of certificates owned by
 legitimate RTP receivers, or their certificates MUST be signed by a
 trusted Certificate Authority.  Once the DTLS-SRTP security is
 established, non-SRTCP-protected messages received from a particular
 RTP receiver are ignored by the retransmission server.  To reduce the
 impact of DTLS-SRTP overhead when communicating with different
 feedback targets on the same retransmission server, it is RECOMMENDED
 that RTP receivers and the retransmission server both support TLS
 Session Resumption without Server-side State [RFC5077].  To help
 scale SRTP to handle many RTP receivers asking for retransmissions of
 identical data, implementors may consider using the same SRTP key for
 SRTP data sent to the receivers [SRTP-EKT] and be aware that such key
 sharing allows those receivers to impersonate the sender.  Thus,
 source address validation remains important.
 [RFC4588] RECOMMENDS that cryptography mechanisms be used for the
 retransmission payload format to provide protection against known
 plain-text attacks.  As discussed in [RFC4588], the retransmission
 payload format sets the timestamp field in the RTP header to the
 media timestamp of the original packet, and this does not compromise
 the confidentiality.  Furthermore, if cryptography is used to provide
 security services on the original stream, then the same services,
 with equivalent cryptographic strength, MUST be provided on the
 retransmission stream per [RFC4588].
 Finally, a retransmission server that has become subverted by an
 attacker is almost impossible to protect against as such a server can
 perform a large number of different actions to deny service to
 receivers.

11. IANA Considerations

 The following contact information is used for all registrations in
 this document:
 Ali Begen
 abegen@cisco.com

Ver Steeg, et al. Standards Track [Page 47] RFC 6285 RAMS June 2011

 Note that the "RAMS" (value 2) in the Multicast Acquisition Method
 Registry refers to the method described in Section 6 of this
 document.

11.1. Registration of SDP Attributes

 This document registers a new attribute name in SDP.
      SDP Attribute ("att-field"):
      Attribute name:     rams-updates
      Long form:          Support for Updated RAMS Request Messages
      Type of name:       att-field
      Type of attribute:  Media level
      Subject to charset: No
      Purpose:            See this document
      Reference:          [RFC6285]
      Values:             None

11.2. Registration of SDP Attribute Values

 This document registers a new value for the 'nack' attribute to be
 used with the 'rtcp-fb' attribute in SDP.  For more information about
 the 'rtcp-fb' attribute, refer to Section 4.2 of [RFC4585].
      Value name:     rai
      Long name:      Rapid Acquisition Indication
      Usable with:    nack
      Reference:      [RFC6285]

11.3. Registration of FMT Values

 Within the RTPFB range, the following format (FMT) value is
 registered:
      Name:           RAMS
      Long name:      Rapid Acquisition of Multicast Sessions
      Value:          6
      Reference:      [RFC6285]

11.4. SFMT Values for RAMS Messages Registry

 This document creates a new sub-registry for the sub-feedback message
 type (SFMT) values to be used with the FMT value registered for RAMS
 messages.  The registry is called the SFMT Values for RAMS Messages
 Registry.  This registry is managed by the IANA according to the
 Specification Required policy of [RFC5226].

Ver Steeg, et al. Standards Track [Page 48] RFC 6285 RAMS June 2011

 The length of the SFMT field in the RAMS messages is a single octet,
 allowing 256 values.  The registry is initialized with the following
 entries:
 Value Name                                               Reference
 ----- -------------------------------------------------- ------------
 0     Reserved                                           [RFC6285]
 1     RAMS Request                                       [RFC6285]
 2     RAMS Information                                   [RFC6285]
 3     RAMS Termination                                   [RFC6285]
 4-254 Unassigned - Specification Required
 255   Reserved                                           [RFC6285]
 The SFMT values 0 and 255 are reserved for future use.
 Any registration for an unassigned SFMT value needs to contain the
 following information:
 o  Contact information of the one doing the registration, including
    at least name, address, and email.
 o  A detailed description of what the new SFMT represents and how it
    shall be interpreted.
 New RAMS functionality is intended to be introduced by using the
 extension mechanism within the existing RAMS message types not by
 introducing new message types unless it is absolutely necessary.

11.5. RAMS TLV Space Registry

 This document creates a new IANA TLV space registry for the RAMS
 extensions.  The registry is called the RAMS TLV Space Registry.
 This registry is managed by the IANA according to the Specification
 Required policy of [RFC5226].
 The length of the Type field in the TLV elements is a single octet,
 allowing 256 values.  The Type values 0 and 255 are reserved for
 future use.  The Type values between (and including) 128 and 254 are
 reserved for private extensions.

Ver Steeg, et al. Standards Track [Page 49] RFC 6285 RAMS June 2011

 The registry is initialized with the following entries:
 Type    Description                                     Reference
 ----    ----------------------------------------------- -------------
 0       Reserved                                        [RFC6285]
 1       Requested Media Sender SSRC(s)                  [RFC6285]
 2       Min RAMS Buffer Fill Requirement                [RFC6285]
 3       Max RAMS Buffer Fill Requirement                [RFC6285]
 4       Max Receive Bitrate                             [RFC6285]
 5       Request for Preamble Only                       [RFC6285]
 6       Supported Enterprise Number(s)                  [RFC6285]
 7-30    Unassigned - Specification Required
 31      Media Sender SSRC                               [RFC6285]
 32      RTP Seqnum of the First Packet                  [RFC6285]
 33      Earliest Multicast Join Time                    [RFC6285]
 34      Burst Duration                                  [RFC6285]
 35      Max Transmit Bitrate                            [RFC6285]
 36-60   Unassigned - Specification Required
 61      Extended RTP Seqnum of First Multicast Packet   [RFC6285]
 62-127  Unassigned - Specification Required
 128-254 Reserved for Private Use
 255     Reserved                                        [RFC6285]
 Any registration for an unassigned Type value needs to contain the
 following information:
 o  Contact information of the one doing the registration, including
    at least name, address, and email.
 o  A detailed description of what the new TLV element represents and
    how it shall be interpreted.

11.6. RAMS Response Code Space Registry

 This document creates a new IANA TLV space registry for the RAMS
 response codes.  The registry is called the RAMS Response Code Space
 Registry.  This registry is managed by the IANA according to the
 Specification Required policy of [RFC5226].
 The length of the Response field is two octets, allowing 65536 codes.
 However, in this document, the response codes have been classified
 and registered following an HTTP-style code numbering.  New response
 codes should be classified following the guidelines below:

Ver Steeg, et al. Standards Track [Page 50] RFC 6285 RAMS June 2011

 Code Level Purpose
 ---------- ---------------
 1xx        Informational
 2xx        Success
 3xx        Redirection
 4xx        RTP Receiver (RTP_Rx) Error
 5xx        Burst/Retransmission Source (BRS) Error
 The Response code 65535 is reserved for future use.
 The registry is initialized with the following entries:
 Code  Description                                        Reference
 ----- -------------------------------------------------- ------------
 0     A private response code is included in the message [RFC6285]
 100   Parameter update for RAMS session                  [RFC6285]
 200   RAMS request has been accepted                     [RFC6285]
 201   Unicast burst has been completed                   [RFC6285]
 400   Invalid RAMS-R message syntax                      [RFC6285]
 401   Invalid min buffer requirement in RAMS-R message   [RFC6285]
 402   Invalid max buffer requirement in RAMS-R message   [RFC6285]
 403   Insufficient max bitrate requirement in RAMS-R
       message                                            [RFC6285]
 404   Invalid RAMS-T message syntax                      [RFC6285]
 500   An unspecified BRS internal error has occurred     [RFC6285]
 501   BRS has insufficient bandwidth to start RAMS
       session                                            [RFC6285]
 502   Burst is terminated due to network congestion      [RFC6285]
 503   BRS has insufficient CPU cycles to start RAMS
       session                                            [RFC6285]
 504   RAMS functionality is not available on BRS         [RFC6285]
 505   RAMS functionality is not available for RTP_Rx     [RFC6285]
 506   RAMS functionality is not available for
       the requested multicast stream                     [RFC6285]
 507   BRS has no valid starting point available for
       the requested multicast stream                     [RFC6285]
 508   BRS has no reference information available for
       the requested multicast stream                     [RFC6285]
 509   BRS has no RTP stream matching the requested SSRC  [RFC6285]
 510   RAMS request to acquire the entire session
       has been denied                                    [RFC6285]
 511   Only the preamble information is sent              [RFC6285]
 512   RAMS request has been denied due to a policy       [RFC6285]

Ver Steeg, et al. Standards Track [Page 51] RFC 6285 RAMS June 2011

 Any registration for an unassigned Response code needs to contain the
 following information:
 o  Contact information of the one doing the registration, including
    at least name, address, and email.
 o  A detailed description of what the new Response code describes and
    how it shall be interpreted.

12. Contributors

 Dave Oran, Magnus Westerlund, and Colin Perkins have contributed
 significantly to this specification by providing text and solutions
 to some of the issues raised during the development of this
 specification.

13. Acknowledgments

 The following individuals reviewed earlier versions of this
 specification and provided helpful comments:  Joerg Ott, Roni Even,
 Dan Wing, Tony Faustini, Peilin Yang, Jeff Goldberg, Muriel
 Deschanel, Orit Levin, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui
 Wang, Zixuan Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan
 Lennox, Jose Rey, Sean Sheedy, and Keith Drage.

14. References

14.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
            Defeating Denial of Service Attacks which employ IP Source
            Address Spoofing", BCP 38, RFC 2827, May 2000.
 [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
            Thyagarajan, "Internet Group Management Protocol, Version
            3", RFC 3376, October 2002.
 [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
            Jacobson, "RTP: A Transport Protocol for Real-Time
            Applications", STD 64, RFC 3550, July 2003.
 [RFC3605]  Huitema, C., "Real Time Control Protocol (RTCP) attribute
            in Session Description Protocol (SDP)", RFC 3605,
            October 2003.

Ver Steeg, et al. Standards Track [Page 52] RFC 6285 RAMS June 2011

 [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
            Norrman, "The Secure Real-time Transport Protocol (SRTP)",
            RFC 3711, March 2004.
 [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
            Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
 [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.
 [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet
            Group Management Protocol Version 3 (IGMPv3) and Multicast
            Listener Discovery Protocol Version 2 (MLDv2) for Source-
            Specific Multicast", RFC 4604, August 2006.
 [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
            "Transport Layer Security (TLS) Session Resumption without
            Server-Side State", RFC 5077, January 2008.
 [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
            Specifications: ABNF", STD 68, RFC 5234, January 2008.
 [RFC5285]  Singer, D. and H. Desineni, "A General Mechanism for RTP
            Header Extensions", RFC 5285, July 2008.
 [RFC5506]  Johansson, I. and M. Westerlund, "Support for Reduced-Size
            Real-Time Transport Control Protocol (RTCP): Opportunities
            and Consequences", RFC 5506, April 2009.
 [RFC5576]  Lennox, J., Ott, J., and T. Schierl, "Source-Specific
            Media Attributes in the Session Description Protocol
            (SDP)", RFC 5576, June 2009.
 [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.
 [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
            Control Packets on a Single Port", RFC 5761, April 2010.

Ver Steeg, et al. Standards Track [Page 53] RFC 6285 RAMS June 2011

 [RFC5764]  McGrew, D. and E. Rescorla, "Datagram Transport Layer
            Security (DTLS) Extension to Establish Keys for the Secure
            Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
 [RFC5888]  Camarillo, G. and H. Schulzrinne, "The Session Description
            Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
 [RFC6051]  Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
            Flows", RFC 6051, November 2010.
 [RFC6128]  Begen, A., "RTP Control Protocol (RTCP) Port for Source-
            Specific Multicast (SSM) Sessions", RFC 6128,
            February 2011.
 [RFC6284]  Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping
            Between Unicast and Multicast RTP Sessions", RFC 6284,
            June 2011.

14.2. Informative References

 [ECN-FOR-RTP]
            Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
            and K. Carlberg, "Explicit Congestion Notification (ECN)
            for RTP over UDP", Work in Progress, May 2011.
 [IC2009]   Begen, A., Glazebrook, N., and W. Ver Steeg, "Reducing
            Channel Change Times in IPTV with Real-Time Transport
            Protocol (IEEE Internet Computing)", May 2009.
 [MULTICAST-ACQ]
            Begen, A. and E. Friedrich, "Multicast Acquisition Report
            Block Type for RTP Control Protocol (RTCP) Extended
            Reports (XRs)", Work in Progress, May 2011.
 [RAMS-SCENARIOS]
            Begen, A., "Considerations and Guidelines for Deploying
            the Rapid Acquisition of Multicast Sessions (RAMS)
            Method", Work in Progress, June 2011.
 [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
            August 1980.
 [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
            (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
            RFC 4787, January 2007.

Ver Steeg, et al. Standards Track [Page 54] RFC 6285 RAMS June 2011

 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008.
 [RFC5762]  Perkins, C., "RTP and the Datagram Congestion Control
            Protocol (DCCP)", RFC 5762, April 2010.
 [RFC6015]  Begen, A., "RTP Payload Format for 1-D Interleaved Parity
            Forward Error Correction (FEC)", RFC 6015, October 2010.
 [RFC6222]  Begen, A., Perkins, C., and D. Wing, "Guidelines for
            Choosing RTP Control Protocol (RTCP) Canonical Names
            (CNAMEs)", RFC 6222, April 2011.
 [SRTP-EKT] McGrew, D., Andreasen, F., Wing, D., and K. Fischer,
            "Encrypted Key Transport for Secure RTP", Work
            in Progress, March 2011.
 [UPnP-IGD] UPnP Forum, "Universal Plug and Play (UPnP) Internet
            Gateway Device (IGD)", December 2010.

Ver Steeg, et al. Standards Track [Page 55] RFC 6285 RAMS June 2011

Authors' Addresses

 Bill Ver Steeg
 Cisco
 5030 Sugarloaf Parkway
 Lawrenceville, GA  30044
 USA
 EMail:  billvs@cisco.com
 Ali Begen
 Cisco
 181 Bay Street
 Toronto, ON  M5J 2T3
 Canada
 EMail:  abegen@cisco.com
 Tom Van Caenegem
 Alcatel-Lucent
 Copernicuslaan 50
 Antwerpen  2018
 Belgium
 EMail:  Tom.Van_Caenegem@alcatel-lucent.be
 Zeev Vax
 Magnum Semiconductor, Inc.
 591 Yosemite Drive
 Milpitas, CA  95035
 USA
 EMail:  zeev.vax@magnumsemi.com

Ver Steeg, et al. Standards Track [Page 56]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6285.txt · Last modified: 2011/06/28 22:03 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki