tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6285

 
 
 

Unicast-Based Rapid Acquisition of Multicast RTP Sessions

Part 2 of 3, p. 12 to 40
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 12 
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

Top      Up      ToC       Page 13 
   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)

Top      Up      ToC       Page 14 
    -----------                                       --------------
   |           |------------------------------------>|              |
   |           |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->|              |
   |           |                                     |              |
   | 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)| |<.=.=.=.=>|              |
                         |  ------------  |          |              |
                         |                |          |              |
                          ----------------            --------------

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

Top      Up      ToC       Page 15 
   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.

Top      Up      ToC       Page 16 
                  -------------------------
                 | Retransmission  Server  |
    -----------  |  ------   ------------  |   --------    ------------
   | 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    :
     |                  |         |               |                |

Top      Up      ToC       Page 17 
   -------> 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

Top      Up      ToC       Page 18 
        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

Top      Up      ToC       Page 19 
           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.

Top      Up      ToC       Page 20 
           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

Top      Up      ToC       Page 21 
        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

Top      Up      ToC       Page 22 
        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.

Top      Up      ToC       Page 23 
        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

Top      Up      ToC       Page 24 
        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].

Top      Up      ToC       Page 25 
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.

Top      Up      ToC       Page 26 
   (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].

Top      Up      ToC       Page 27 
   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

Top      Up      ToC       Page 28 
   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.

Top      Up      ToC       Page 29 
      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.

Top      Up      ToC       Page 30 
   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.

Top      Up      ToC       Page 31 
   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.

Top      Up      ToC       Page 32 
      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.

Top      Up      ToC       Page 33 
      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

Top      Up      ToC       Page 34 
      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.

Top      Up      ToC       Page 35 
      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,

Top      Up      ToC       Page 36 
      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

Top      Up      ToC       Page 37 
      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.

Top      Up      ToC       Page 38 
   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.

Top      Up      ToC       Page 39 
   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.

Top      Up      ToC       Page 40 
      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



(page 40 continued on part 3)

Next RFC Part