draft-ietf-avt-rapid-acquisition-for-rtp-11.txt   draft-ietf-avt-rapid-acquisition-for-rtp-12.txt 
AVT B. VerSteeg AVT B. VerSteeg
Internet-Draft A. Begen Internet-Draft A. Begen
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: January 10, 2011 T. VanCaenegem Expires: February 26, 2011 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Z. Vax Z. Vax
Microsoft Corporation Microsoft Corporation
July 9, 2010 August 25, 2010
Unicast-Based Rapid Acquisition of Multicast RTP Sessions Unicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-ietf-avt-rapid-acquisition-for-rtp-11 draft-ietf-avt-rapid-acquisition-for-rtp-12
Abstract Abstract
When an RTP receiver joins a multicast session, it may need to When an RTP receiver joins a multicast session, it may need to
acquire and parse certain Reference Information before it can process acquire and parse certain Reference Information before it can process
any data sent in the multicast session. Depending on the join time, any data sent in the multicast session. Depending on the join time,
length of the Reference Information repetition (or appearance) length of the Reference Information repetition (or appearance)
interval, size of the Reference Information as well as the interval, size of the Reference Information as well as the
application and transport properties, the time lag before an RTP application and transport properties, the time lag before an RTP
receiver can usefully consume the multicast data, which we refer to receiver can usefully consume the multicast data, which we refer to
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 10, 2011. This Internet-Draft will expire on February 26, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 25 skipping to change at page 3, line 25
6. Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . 12 6. Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . 12
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Synchronization of Primary Multicast Streams . . . . . . . 23 6.3. Synchronization of Primary Multicast Streams . . . . . . . 23
6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 23 6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 23
6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 26 6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 26
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 27 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 27
7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 28 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 29 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 29
7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 29 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 29
7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 29 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 30
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 32 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 32
7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 34 7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 35
8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 35 8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 36
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 35 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 36
8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 36 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 36
8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 37 8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 37
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 39 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 40
10. Security Considerations . . . . . . . . . . . . . . . . . . . 40 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 42 11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 43
11.2. Registration of SDP Attribute Values . . . . . . . . . . . 42 11.2. Registration of SDP Attribute Values . . . . . . . . . . . 43
11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 43 11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 43
11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 43 11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 44
11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 44 11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 44
11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 45 11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 45
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 47 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
14.1. Normative References . . . . . . . . . . . . . . . . . . . 47 14.1. Normative References . . . . . . . . . . . . . . . . . . . 48
14.2. Informative References . . . . . . . . . . . . . . . . . . 49 14.2. Informative References . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
1. Introduction 1. Introduction
Most multicast flows carry a stream of inter-related data. The Most multicast flows carry a stream of inter-related data. The
receivers need to acquire certain information to start processing any receivers need to acquire certain information to start processing any
data sent in the multicast session. This document refers to this data sent in the multicast session. This document refers to this
information as Reference Information. The Reference Information is information as Reference Information. The Reference Information is
conventionally sent periodically in the multicast session (although conventionally sent periodically in the multicast session (although
its content can change over time) and usually consists of items such 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 as a description of the schema for the rest of the data, references
skipping to change at page 4, line 51 skipping to change at page 4, line 51
refer to the difference between the time an RTP receiver joins the refer to the difference between the time an RTP receiver joins the
multicast session and the time the RTP receiver acquires all the multicast session and the time the RTP receiver acquires all the
necessary Reference Information as the Acquisition Delay. The necessary Reference Information as the Acquisition Delay. The
acquisition delay might not be the same for different receivers; it acquisition delay might not be the same for different receivers; it
usually varies depending on the join time, length of the Reference usually varies depending on the join time, length of the Reference
Information repetition (or appearance) interval, size of the Information repetition (or appearance) interval, size of the
Reference Information as well as the application and transport Reference Information as well as the application and transport
properties. properties.
The varying nature of the acquisition delay adversely affects the The varying nature of the acquisition delay adversely affects the
receivers that frequently switch among multicast sessions. In this receivers that frequently switch among multicast sessions. While
specification, we address this problem for RTP-based multicast this problem equally applies to both any-source (ASM) and source-
applications and describe a method that uses the fundamental tools specific (SSM) multicast applications, in this specification we
offered by the existing RTP and RTCP protocols [RFC3550]. In this address it for the SSM-based multicast applications by describing a
method, either the multicast source (or the distribution source in a method that uses the fundamental tools offered by the existing RTP
source-specific multicast (SSM) session) retains the Reference and RTCP protocols [RFC3550]. In this method, either the multicast
Information for a period after its transmission, or an intermediary source (or the distribution source in an SSM session) retains the
network element (that we refer to as Retransmission Server) joins the Reference Information for a period after its transmission, or an
multicast session and continuously caches the Reference Information intermediary network element (that we refer to as Retransmission
as it is sent in the session and acts as a feedback target (See Server) joins the multicast session and continuously caches the
[RFC5760]) for the session. When an RTP receiver wishes to join the Reference Information as it is sent in the session and acts as a
same multicast session, instead of simply issuing a Source Filtering feedback target (See [RFC5760]) for the session. When an RTP
Group Management Protocol (SFGMP) Join message, it sends a request to receiver wishes to join the same multicast session, instead of simply
the feedback target for the session and asks for the Reference issuing a Source Filtering Group Management Protocol (SFGMP) Join
Information. The retransmission server starts a new unicast RTP message, it sends a request to the feedback target for the session
(retransmission) session and sends the Reference Information to the and asks for the Reference Information. The retransmission server
RTP receiver over that session. If there is spare bandwidth, the starts a new unicast RTP (retransmission) session and sends the
retransmission server might burst the Reference Information faster Reference Information to the RTP receiver over that session. If
than its natural rate. As soon as the receiver acquires the there is spare bandwidth, the retransmission server might burst the
Reference Information, it can join the multicast session and start Reference Information faster than its natural rate. As soon as the
processing the multicast data. A simplified network diagram showing receiver acquires the Reference Information, it can join the
this method through an intermediary network element is depicted in multicast session and start processing the multicast data. A
Figure 1. simplified network diagram showing this method through an
intermediary network element is depicted in Figure 1.
This method potentially reduces the acquisition delay. We refer to This method potentially reduces the acquisition delay. We refer to
this method as Unicast-based Rapid Acquisition of Multicast RTP this method as Unicast-based Rapid Acquisition of Multicast RTP
Sessions. A primary use case for this method is to reduce the Sessions. A primary use case for this method is to reduce the
channel-change times in IPTV networks where compressed video streams channel-change times in IPTV networks where compressed video streams
are multicast in different SSM sessions and viewers randomly join are multicast in different SSM sessions and viewers randomly join
these sessions. these sessions.
----------------------- -----------------------
+--->| Intermediary | +--->| Intermediary |
skipping to change at page 6, line 48 skipping to change at page 6, line 48
In this memo we describe a protocol that handles the rapid In this memo we describe a protocol that handles the rapid
acquisition of a single multicast RTP session (called primary acquisition of a single multicast RTP session (called primary
multicast RTP session) carrying one or more RTP streams (called multicast RTP session) carrying one or more RTP streams (called
primary multicast streams). If desired, multiple instances of this primary multicast streams). If desired, multiple instances of this
protocol may be run in parallel to acquire multiple RTP sessions protocol may be run in parallel to acquire multiple RTP sessions
simultaneously. simultaneously.
When an RTP receiver requests the Reference Information from the When an RTP receiver requests the Reference Information from the
retransmission server, it can opt to rapidly acquire a specific retransmission server, it can opt to rapidly acquire a specific
subset of the available RTP streams in the primary multicast RTP subset of the available RTP streams in the primary multicast RTP
session. Alternatively, it can request the rapid acquisition of all session. Alternatively, the RTP receiver can request the rapid
of the RTP streams in that RTP session. Regardless of how many RTP acquisition of all of the RTP streams in that RTP session.
streams are requested by the RTP receiver or how many will be Regardless of how many RTP streams are requested by the RTP receiver
actually sent by the retransmission server, only one unicast RTP or how many will be actually sent by the retransmission server, only
session will be established by the retransmission server. This one unicast RTP session will be established by the retransmission
unicast RTP session is separate from the associated primary multicast server. This unicast RTP session is separate from the associated
RTP session. As a result, there are always two different RTP primary multicast RTP session. As a result, there are always two
sessions in a single instance of the rapid acquisition protocol: (i) different RTP sessions in a single instance of the rapid acquisition
the primary multicast RTP session with its associated unicast protocol: (i) the primary multicast RTP session with its associated
feedback and (ii) the unicast RTP session. unicast feedback and (ii) the unicast RTP session.
If the RTP receiver wants to rapidly acquire multiple RTP sessions If the RTP receiver wants to rapidly acquire multiple RTP sessions
simultaneously, separate unicast RTP sessions will be established for simultaneously, separate unicast RTP sessions will be established for
each of them. each of them.
1.2. Outline 1.2. Outline
In the rest of this specification, we have the following outline: In In the rest of this specification, we have the following outline: In
Section 4, we describe the delay components in generic multicast Section 4, we describe the delay components in generic multicast
applications. Section 5 presents an overview of the protocol design applications. Section 5 presents an overview of the protocol design
skipping to change at page 8, line 49 skipping to change at page 8, line 49
(Unicast) Burst (Stream): A unicast stream of RTP retransmission (Unicast) Burst (Stream): A unicast stream of RTP retransmission
packets that enable an RTP receiver to rapidly acquire the Reference packets that enable an RTP receiver to rapidly acquire the Reference
Information associated with a primary multicast stream. Each burst Information associated with a primary multicast stream. Each burst
stream is identified by its Synchronization Source (SSRC) identifier stream is identified by its Synchronization Source (SSRC) identifier
that is unique in the primary multicast RTP session. Following the that is unique in the primary multicast RTP session. Following the
session-multiplexing guidelines in [RFC4588], each unicast burst session-multiplexing guidelines in [RFC4588], each unicast burst
stream will use the same SSRC and CNAME as its primary multicast RTP stream will use the same SSRC and CNAME as its primary multicast RTP
stream. stream.
Retransmission Server (RS): The RTP/RTCP endpoint that can generate Retransmission Server (RS): The RTP/RTCP endpoint that can generate
the retransmission packets and the burst streams. RS may also the retransmission packets and the burst streams. The RS may also
generate other non-retransmission packets to aid rapid acquisition. generate other non-retransmission packets to aid rapid acquisition.
4. Elements of Delay in Multicast Applications 4. Elements of Delay in Multicast Applications
In a source-specific (SSM) multicast delivery system, there are three In a source-specific (SSM) multicast delivery system, there are three
major elements that contribute to the overall acquisition delay when major elements that contribute to the overall acquisition delay when
an RTP receiver switches from one multicast session to another one. an RTP receiver switches from one multicast session to another one.
These are: These are:
o Multicast switching delay o Multicast switching delay
skipping to change at page 10, line 19 skipping to change at page 10, line 19
reliability, if needed, is usually addressed through other means such reliability, if needed, is usually addressed through other means such
as Forward Error Correction (e.g., as Forward Error Correction (e.g.,
[I-D.ietf-fecframe-interleaved-fec-scheme]) and retransmission. [I-D.ietf-fecframe-interleaved-fec-scheme]) and retransmission.
These loss-repair methods require buffering at the receiver side to These loss-repair methods require buffering at the receiver side to
function properly. In many applications, it is also often necessary function properly. In many applications, it is also often necessary
to de-jitter the incoming data packets before feeding them to the to de-jitter the incoming data packets before feeding them to the
application. The de-jittering process also increases the buffering application. The de-jittering process also increases the buffering
delays. Besides these network-related buffering delays, there are delays. Besides these network-related buffering delays, there are
also specific buffering needs that are required by the individual also specific buffering needs that are required by the individual
applications. For example, standard video decoders typically require applications. For example, standard video decoders typically require
an amount, sometimes a significant amount, of coded video data to be an 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 available in the pre-decoding buffers prior to starting to decode the
video bitstream. video bitstream.
5. Protocol Design Considerations and Their Effect on Resource 5. Protocol Design Considerations and Their Effect on Resource
Management for Rapid Acquisition Management for Rapid Acquisition
This section is for informational purposes and does not contain This section is for informational purposes and does not contain
requirements for implementations. requirements for implementations.
Rapid acquisition is an optimization of a system that is expected to Rapid acquisition is an optimization of a system that is expected to
continue to work correctly and properly whether or not the continue to work correctly and properly whether or not the
optimization is effective, or even fails due to lost control and optimization is effective, or even fails due to lost control and
feedback messages, congestion, or other problems. This is feedback messages, congestion, or other problems. This is
fundamental to the overall design requirements surrounding the fundamental to the overall design requirements surrounding the
protocol definition and to the resource management schemes to be protocol definition and to the resource management schemes to be
employed together with the protocol (e.g., QoS machinery, server load employed together with the protocol (e.g., QoS machinery, server load
management, etc). In particular, the system needs to operate within management, etc). In particular, the system needs to operate within
a number of constraints: a number of constraints:
o First, a rapid acquisition operation must fail gracefully. The o First, a rapid acquisition operation must fail gracefully. The
user experience must, except perhaps in pathological user experience must be not significantly worse for trying and
circumstances, be not significantly worse for trying and failing failing to complete rapid acquisition compared to simply joining
to complete rapid acquisition compared to simply joining the the multicast session.
multicast session.
o Second, providing the rapid acquisition optimizations must not o Second, providing the rapid acquisition optimizations must not
cause collateral damage to either the multicast session being cause collateral damage to either the multicast session being
joined, or other multicast sessions sharing resources with the joined, or other multicast sessions sharing resources with the
rapid acquisition operation. In particular, the rapid acquisition rapid acquisition operation. In particular, the rapid acquisition
operation must avoid interference with the multicast session that operation must avoid interference with the multicast session that
might be simultaneously being received by other hosts. In might be simultaneously being received by other hosts. In
addition, it must also avoid interference with other multicast addition, it must also avoid interference with other multicast
sessions sharing the same network resources. These properties are sessions sharing the same network resources. These properties are
possible, but are usually difficult to achieve. possible, but are usually difficult to achieve.
skipping to change at page 13, line 29 skipping to change at page 13, line 28
Using an accelerated bitrate (as compared to the nominal bitrate of Using an accelerated bitrate (as compared to the nominal bitrate of
the primary multicast stream) for the unicast burst implies that at a the primary multicast stream) for the unicast burst implies that at a
certain point in time, the payload transmitted in the unicast burst certain point in time, the payload transmitted in the unicast burst
is going to be the same as the payload in the associated multicast 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 stream, i.e., the unicast burst will catch up with the primary
multicast stream. At this point, the RTP receiver no longer needs to multicast stream. At this point, the RTP receiver no longer needs to
receive the unicast burst and can join the SSM session. This method receive the unicast burst and can join the SSM session. This method
is referred to as the Rapid Acquisition of Multicast Sessions (RAMS). is referred to as the Rapid Acquisition of Multicast Sessions (RAMS).
This document proposes extensions to [RFC4585] for an RTP receiver to This document defines extensions to [RFC4585] for an RTP receiver to
request a unicast burst as well as for additional control messaging request a unicast burst as well as for additional control messaging
that can be leveraged during the acquisition process. that can be leveraged during the acquisition process.
6.2. Message Flows 6.2. Message Flows
Figure 2 shows the main entities involved in rapid acquisition and Figure 2 shows the main entities involved in rapid acquisition and
the message flows. They are the message flows. They are
o Multicast Source o Multicast Source
skipping to change at page 14, line 38 skipping to change at page 14, line 38
-------> Multicast RTP Flow -------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow .-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports .=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages ~~~~~~~> Unicast RTCP Feedback Messages
.......> Unicast RTP Flow .......> Unicast RTP Flow
Figure 2: Flow diagram for unicast-based rapid acquisition Figure 2: Flow diagram for unicast-based rapid acquisition
The feedback target (FT) is the entity as defined in [RFC5760], to The feedback target (FT) is the entity as defined in [RFC5760], to
which RTP_Rx sends its RTCP feedback messages indicating packet loss which the RTP_Rx sends its RTCP feedback messages indicating packet
by means of an RTCP NACK message or indicating RTP_Rx's desire to loss by means of an RTCP NACK message or indicating RTP_Rx's desire
rapidly acquire the primary multicast RTP session by means of an RTCP to rapidly acquire the primary multicast RTP session by means of an
feedback message defined in this document. While the Burst/ RTCP feedback message defined in this document. While the Burst/
Retransmission Source (BRS) is responsible for responding to these Retransmission Source (BRS) is responsible for responding to these
messages and for further RTCP interaction with RTP_Rx in the case of messages and for further RTCP interaction with the RTP_Rx in the case
a rapid acquisition process, it is assumed in the remainder of the of a rapid acquisition process, it is assumed in the remainder of the
document that these two logical entities (FT and BRS) are combined in document that these two logical entities (FT and BRS) are combined in
a single physical entity and they share state. In the remainder of a single physical entity and they share state. In the remainder of
the text, the term Retransmission Server (RS) is used whenever the text, the term Retransmission Server (RS) is used whenever
appropriate, to refer to this single physical entity. appropriate, to refer to this single physical entity.
FT is involved in the primary multicast RTP session and receives The FT is involved in the primary multicast RTP session and receives
unicast feedback for that session as in [RFC5760]. BRS is involved unicast feedback for that session as in [RFC5760]. The BRS is
in the unicast burst (or retransmission) RTP session and transmits involved in the unicast burst (or retransmission) RTP session and
the unicast burst and retransmission packets formatted as RTP transmits the unicast burst and retransmission packets formatted as
retransmission packets [RFC4588] in a single separate unicast RTP RTP retransmission packets [RFC4588] in a single separate unicast RTP
session to each RTP_Rx. In the unicast burst RTP session, as in any 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 other RTP session, the BRS and RTP_Rx regularly send the periodic
sender and receiver reports, respectively. sender and receiver reports, respectively.
The unicast burst is started by an RTCP feedback message that is The unicast burst is started by an RTCP feedback message that is
defined in this document based on the common packet format provided defined in this document based on the common packet format provided
in [RFC4585]. An RTP retransmission is triggered by an RTCP NACK in [RFC4585]. An RTP retransmission is triggered by an RTCP NACK
message defined in [RFC4585]. Both of these messages are sent to FT message defined in [RFC4585]. Both of these messages are sent to the
of the primary multicast RTP session, and can start the unicast FT of the primary multicast RTP session, and can start the unicast
burst/retransmission RTP session. burst/retransmission RTP session.
In the RTP/AVPF profile, there are certain rules that apply to In the RTP/AVPF profile, there are certain rules that apply to
scheduling of both of these messages sent to FT in the primary scheduling of both of these messages sent to the FT in the primary
multicast RTP session, and these are detailed in Section 3.5 of multicast RTP session, and these are detailed in Section 3.5 of
[RFC4585]. One of the rules states that in a multi-party session [RFC4585]. One of the rules states that in a multi-party session
such as the SSM sessions we are considering in this specification, an 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 RTP_Rx cannot send an RTCP feedback message for a minimum of one
second period after joining the session (i.e., Tmin=1.0 second). second period after joining the session (i.e., Tmin=1.0 second).
While this rule has the goal of avoiding problems associated with While this rule has the goal of avoiding problems associated with
flash crowds in typical multi-party sessions, it defeats the purpose flash crowds in typical multi-party sessions, it defeats the purpose
of rapid acquisition. Furthermore, when RTP receivers delay their of rapid acquisition. Furthermore, when RTP receivers delay their
messages requesting a burst by a deterministic or even a random messages requesting a burst by a deterministic or even a random
amount, it still does not make a difference since such messages are amount, it still does not make a difference since such messages are
skipping to change at page 16, line 37 skipping to change at page 16, line 36
| | | | | | | | | |
| | | | | | | | | |
| | | |<= SFGMP Join ==| | | | |<= SFGMP Join ==|
| | | | | | | | | |
|-- RTP Multicast ------------------------------------------->| |-- RTP Multicast ------------------------------------------->|
|-. RTCP Multicast -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.>| |-. RTCP Multicast -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.>|
| | | | | | | | | |
| | | | | | | | | |
| | |<~~~~~~~~~~~~~~~ RTCP RAMS-T ~~~| | | |<~~~~~~~~~~~~~~~ RTCP RAMS-T ~~~|
| | | | | | | | | |
| | | | |
| | | | |
: : : : :
: : : : : : : : : :
| | |<.=.= Unicast RTCP Reports .=.=>| | | |<.=.= Unicast RTCP Reports .=.=>|
: : : (for the unicast session) : : : : (for the unicast session) :
: : : : :
| | | | | | | | | |
-------> Multicast RTP Flow -------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow .-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports .=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages ~~~~~~~> Unicast RTCP Feedback Messages
=======> SFGMP Messages =======> SFGMP Messages
.......> Unicast RTP Flow .......> Unicast RTP Flow
Figure 3: Message flows for unicast-based rapid acquisition Figure 3: Message flows for unicast-based rapid acquisition
This document defines the expected behaviors of RS and RTP_Rx. It is This document defines the expected behaviors of the RS and RTP_Rx.
instructive to have independently operating implementations on RS and
RTP_Rx that request the burst, describe the burst, start the burst, It is instructive to consider independently operating implementations
join the multicast session and stop the burst. These implementations on the RS and RTP_Rx that request the burst, describe the burst,
send messages to each other, but provisions are needed for the cases start the burst, join the multicast session and stop the burst.
where the control messages get lost, or re-ordered, or are not being These implementations send messages to each other, but provisions are
delivered to their destinations. needed for the cases where the control messages get lost, or re-
ordered, or are not being delivered to their destinations.
The following steps describe rapid acquisition in detail: The following steps describe rapid acquisition in detail:
1. Port Mapping Setup: For the primary multicast RTP session, the 1. Port Mapping Setup: For the primary multicast RTP session, the
RTP and RTCP destination ports are declaratively specified RTP and RTCP destination ports are declaratively specified
(Refer to Section 8 for examples in SDP). However, RTP_Rx needs (Refer to Section 8 for examples in SDP). However, the RTP_Rx
to choose its RTP and RTCP receive ports in the unicast burst needs to choose its RTP and RTCP receive ports for the unicast
RTP session. Since this unicast session is established after burst RTP session. Since this unicast session is established
RTP_Rx has sent a RAMS-Request (RAMS-R) message as unicast after the RTP_Rx has sent a RAMS-Request (RAMS-R) message as
feedback in the primary multicast RTP session, RTP_Rx MUST first unicast feedback in the primary multicast RTP session, the
setup the port mappings between the unicast and multicast RTP_Rx MUST first setup the port mappings between the unicast
sessions and send this mapping information to FT along with the and multicast sessions and send this mapping information to the
RAMS-R message so that BRS knows how to communicate with RTP_Rx. 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 The details of this setup procedure are explained in
[I-D.ietf-avt-ports-for-ucast-mcast-rtp]. Other NAT-related [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. Other NAT-related
issues are left to Section 9 to keep the present discussion issues are left to Section 9 to keep the present discussion
focused on the RAMS message flows. focused on the RAMS message flows.
2. Request: RTP_Rx sends a rapid acquisition request (RAMS-R) for 2. Request: the RTP_Rx sends a rapid acquisition request (RAMS-R)
the primary multicast RTP session to the unicast feedback target for the primary multicast RTP session to the unicast feedback
of that session. The request contains the SSRC identifier of target of that session. The request contains the SSRC
RTP_Rx (aka SSRC of packet sender) and can contain the media identifier of the RTP_Rx (aka SSRC of packet sender) and can
sender SSRC identifier(s) of the primary multicast stream(s) of contain the media sender SSRC identifier(s) of the primary
interest (aka SSRC of media source). The RAMS-R message can multicast stream(s) of interest (aka SSRC of media source). The
contain parameters that constrain the burst, such as the buffer RAMS-R message can contain parameters that constrain the burst,
and bandwidth limits. such as the buffer and bandwidth limits.
Before joining the SSM session, RTP_Rx learns the addresses for
the multicast source, group and RS by out-of-band means. If
RTP_Rx desires to rapidly acquire only a subset of the primary
multicast streams available in the primary multicast RTP
session, RTP_Rx MUST also acquire the SSRC identifiers for the
desired RTP streams out-of-band. Based on this information,
RTP_Rx populates the desired SSRC(s) in the RAMS-R message.
When FT successfully receives the RAMS-R message, BRS responds Before joining the SSM session, the RTP_Rx learns the addresses
to it by accepting or rejecting the request. Immediately before for the multicast source, group and RS by out-of-band means. If
BRS sends any RTP or RTCP packet(s) described below, it the RTP_Rx desires to rapidly acquire only a subset of the
establishes the unicast burst RTP session. primary multicast streams available in the primary multicast RTP
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.
3. Response: BRS sends RAMS-Information (RAMS-I) message(s) to When the FT successfully receives the RAMS-R message, the BRS
RTP_Rx to convey the status for the burst(s) requested by responds to it by accepting or rejecting the request.
RTP_Rx. Immediately before the BRS sends any RTP or RTCP packet(s)
described below, it establishes the unicast burst RTP session.
If the primary multicast RTP session associated with FT_Ap on 3. Response: The BRS sends RAMS-Information (RAMS-I) message(s) to
which the RAMS-R message was received contains only a single the RTP_Rx to convey the status for the burst(s) requested by
primary multicast stream, BRS SHALL always use the SSRC of the the RTP_Rx.
RTP stream associated with 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, BRS MUST explicitly populate the
correct media sender SSRC in the initial RAMS-I message (See
Section 7.3).
FT_Ap could also be associated with an RTP session that carries If the primary multicast RTP session associated with the FT_Ap
two or more primary multicast streams. If RTP_Rx will issue a (a specific feedback target running on a particular address and
collective request to receive the whole primary multicast RTP port) on which the RAMS-R message was received contains only a
session, it does not need the 'ssrc' attributes to be described single primary multicast stream, the BRS SHALL always use the
in the media description. 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).
If FT_Ap is associated with two or more RTP sessions, RTP_Rx's The FT_Ap could also be associated with an RTP session that
request will be ambiguous. To avoid any ambiguity, each FT_Ap carries two or more primary multicast streams. If the RTP_Rx
MUST only associate itself with a single RTP session. will 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 RTP_Rx is willing to rapidly acquire only a subset of the If the FT_Ap is associated with two or more RTP sessions,
primary multicast streams, RTP_Rx MUST list all the media sender RTP_Rx's request will be ambiguous. To avoid any ambiguity,
SSRC(s) denoting the stream(s) it wishes to acquire in the each FT_Ap MUST be only associated with a single RTP session.
RAMS-R message. Upon receiving such a message, BRS MAY accept
the request for all or a subset of the media sender SSRC(s) that
matched the RTP stream(s) it serves. BRS MUST reject all other
requests with an appropriate response code.
* Reject Responses: BRS MUST take into account any limitations If the RTP_Rx is willing to rapidly acquire only a subset of the
that may have been specified by RTP_Rx in the RAMS-R message primary multicast streams, the RTP_Rx MUST list all the media
when making a decision regarding the request. If RTP_Rx has sender SSRC(s) denoting the stream(s) it wishes to acquire in
requested to acquire the whole primary multicast RTP session the RAMS-R message. Upon receiving such a message, the BRS MAY
but BRS cannot provide a rapid acquisition service for any of accept the request for all or a subset of the media sender
the primary multicast streams, BRS MUST reject the request SSRC(s) that matched the RTP stream(s) it serves. The BRS MUST
via a single RAMS-I message with a collective reject response reject all other requests with an appropriate response code.
code and whose media sender SSRC field is set to one of SSRCs
served by this FT_Ap. Upon receiving this RAMS-I message,
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, BRS MUST send a separate RAMS-I message * Reject Responses: The BRS MUST take into account any
with the appropriate response code for each primary multicast limitations that may have been specified by the RTP_Rx in the
stream that has been requested by RTP_Rx but cannot be served RAMS-R message when making a decision regarding the request.
by BRS. If the RTP_Rx has requested to acquire the whole primary
multicast RTP session but the BRS cannot provide a rapid
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 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.
* Accept Responses: BRS MUST send at least one separate RAMS-I In all other cases, the BRS MUST send a separate RAMS-I
message with the appropriate response code for each primary message with the appropriate response code for each primary
multicast stream that has been requested by RTP_Rx and will multicast stream that has been requested by the RTP_Rx but
be served by BRS. Such RAMS-I messages comprise fields that cannot be served by the BRS. There could be multiple reasons
can be used to describe the individual unicast burst streams. why the BRS has rejected the request, however, the BRS
When there is a RAMS-R request for multiple primary multicast chooses the most appropriate response code to inform the
streams, BRS MUST include all the individual RAMS-I messages RTP_Rx.
corresponding to that RAMS-R request in the same compound
RTCP packet if these messages fit in the same packet. * 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 a 2xx-level response
code 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.
The RAMS-I message carries the RTP sequence number of the The RAMS-I message carries the RTP sequence number of the
first packet transmitted in the respective RTP stream to first packet transmitted in the respective RTP stream to
allow RTP_Rx to detect any missing initial packet(s). When allow the RTP_Rx to detect any missing initial packet(s).
BRS accepts a request for a primary multicast stream, this When the BRS accepts a request for a primary multicast
field MUST always be populated in the RAMS-I message(s) sent stream, this field MUST always be populated in the RAMS-I
for this particular primary multicast stream. It is message(s) sent for this particular primary multicast stream.
RECOMMENDED that BRS sends a RAMS-I message at the start of It is RECOMMENDED that the BRS sends a RAMS-I message at the
the burst so that RTP_Rx can quickly detect any missing start of the burst so that the RTP_Rx can quickly detect any
initial packet(s). missing initial packet(s).
It is possible that the RAMS-I message for a primary multicast It is possible that the RAMS-I message for a primary multicast
stream can get delayed or lost, and RTP_Rx can start receiving stream can get delayed or lost, and the RTP_Rx can start
RTP packets before receiving a RAMS-I message. RTP_Rx MUST NOT receiving RTP packets before receiving a RAMS-I message. An
make protocol dependencies on quickly receiving the initial RTP-RX implementation MUST NOT assume it will quickly receive
RAMS-I message. For redundancy purposes, it is RECOMMENDED that the initial RAMS-I message. For redundancy purposes, it is
BRS repeats the RAMS-I messages multiple times as long as it RECOMMENDED that the BRS repeats the RAMS-I messages multiple
follows the RTCP timer rules defined in [RFC4585]. times as long as it follows the RTCP timer rules defined in
[RFC4585].
4. Unicast Burst: For the primary multicast stream(s) for which 4. Unicast Burst: For the primary multicast stream(s) for which
the request is accepted, BRS starts sending the unicast burst(s) the request is accepted, the BRS starts sending the unicast
that comprises one or more RTP retransmission packets sent in burst(s) that comprises one or more RTP retransmission packets
the unicast burst RTP session. In addition, BRS MAY send sent in the unicast burst RTP session. In addition, the BRS MAY
preamble information data to RTP_Rx in addition to the requested send preamble information data to the RTP_Rx in addition to the
burst, to prime the media decoder(s). The format of this requested burst, to prime the media decoder(s). The format of
preamble data is RTP-payload specific and not specified here. this preamble data is RTP-payload specific and not specified
here.
5. Updated Request: RTP_Rx MAY send an updated RAMS-R message (as 5. Updated Request: The RTP_Rx MAY send an updated RAMS-R message
unicast feedback in the primary multicast RTP session) with a (as unicast feedback in the primary multicast RTP session) with
different value for one or more fields of an earlier RAMS-R a different value for one or more fields of an earlier RAMS-R
message. If there is already a burst planned for or being message. If there is already a burst planned for or being
transmitted to a particular RTP_Rx for a particular stream, the transmitted to a particular RTP_Rx for a particular stream, the
newly arriving RAMS-R is an updated request; otherwise, it is a newly arriving RAMS-R is an updated request; otherwise, it is a
new request. BRS determines the identity of the requesting new request. The BRS determines the identity of the requesting
RTP_Rx by looking at its canonical name identifier (CNAME item RTP_Rx by looking at its canonical name identifier (CNAME item
in the SDES source description). Thus, RTP_Rx MUST choose a in the SDES source description). Thus, the RTP_Rx MUST choose a
globally unique CNAME identifier. Different such ways are globally unique CNAME identifier. Different such ways are
provided in [I-D.ietf-avt-rtp-cnames]. In addition to one or provided in [I-D.ietf-avt-rtp-cnames]. In addition to one or
more fields with updated values, an updated RAMS-R message may more fields with updated values, an updated RAMS-R message may
also include the fields whose values did not change. also include the fields whose values did not change.
Upon receiving an updated request, BRS can use the updated Upon receiving an updated request, the BRS can use the updated
values for sending/shaping the burst, or refine the values and values for sending/shaping the burst, or refine the values and
use the refined values for sending/shaping the burst. use the refined values for sending/shaping the burst.
Subsequently, BRS MAY send an updated RAMS-I message in the Subsequently, the BRS MAY send an updated RAMS-I message in the
unicast burst RTP session to indicate the changes it made. unicast burst RTP session to indicate the changes it made.
RTP_Rx may be in an environment where the available resources It is an implementation-dependent decision for an RTP_RX whether
are time-varying, which may or may not deserve sending a new and when to send an updated request.
updated request. Determining the circumstances where RTP_Rx
needs or does not need to send an updated request and the
methods that RTP_Rx can use to detect and evaluate the time-
varying available resources are not specified in this document.
6. Updated Response: BRS can send more than one RAMS-I messages in 6. Updated Response: The BRS can send more than one RAMS-I
the unicast burst RTP session, e.g., to update the value of one messages in the unicast burst RTP session, e.g., to update the
or more fields in an earlier RAMS-I message. The updated RAMS-I value of one or more fields in an earlier RAMS-I message. The
messages might or might not be a direct response to a RAMS-R updated RAMS-I messages might or might not be a direct response
message. BRS can also send updated RAMS-I messages to signal to a RAMS-R message. The BRS can also send updated RAMS-I
RTP_Rx in real time to join the SSM session, when BRS had messages to signal the RTP_Rx in real time to join the SSM
already sent an initial RAMS-I message, e.g., at the start of session, when the BRS had already sent an initial RAMS-I
the burst. RTP_Rx depends on BRS to learn the join time, which message, e.g., at the start of the burst. The RTP_Rx depends on
can be conveyed by the first RAMS-I message, or can be sent/ the BRS to learn the join time, which can be conveyed by the
revised in a later RAMS-I message. If BRS is not capable of first RAMS-I message, or can be sent/revised in a later RAMS-I
determining the join time in the initial RAMS-I message, BRS message. If the BRS is not capable of determining the join time
MUST send another RAMS-I message (with the join time in the initial RAMS-I message, the BRS MUST send another RAMS-I
information) later. message (with the join time information) later.
7. Multicast Join Signaling: The RAMS-I message allows BRS to 7. Multicast Join Signaling: The RAMS-I message allows the BRS to
signal explicitly when RTP_Rx needs to send the SFGMP Join signal explicitly when the RTP_Rx needs to send the SFGMP Join
message. RTP_Rx SHOULD use this information from the most message. The RTP_Rx SHOULD use this information from the most
recent RAMS-I message unless it has more accurate information. recent RAMS-I message unless it has more accurate information.
If the request is accepted, this information MUST be conveyed in If the request is accepted, this information MUST be conveyed in
at least one RAMS-I message and its value MAY be updated by at least one RAMS-I message and its value MAY be updated by
subsequent RAMS-I messages. subsequent RAMS-I messages.
There can be missing packets if RTP_Rx joins the multicast There can be missing packets if the RTP_Rx joins the multicast
session too early or too late. For example, if RTP_Rx starts session too early or too late. For example, if the RTP_Rx
receiving the primary multicast stream while it is still starts receiving the primary multicast stream while it is still
receiving the unicast burst at a high excess bitrate, this can receiving the unicast burst at a high excess bitrate, this can
result in an increased risk of packet loss. Or, if RTP_Rx joins result in an increased risk of packet loss. Or, if the RTP_Rx
the multicast session some time after the unicast burst is joins the multicast session some time after the unicast burst is
finished, there can be a gap between the burst and multicast finished, there can be a gap between the burst and multicast
data (a number of RTP packets might be missing). In both cases, data (a number of RTP packets might be missing). In both cases,
RTP_Rx can issue retransmission requests (via RTCP NACK messages the RTP_Rx can issue retransmission requests (via RTCP NACK
sent as unicast feedback in the primary multicast RTP session) messages sent as unicast feedback in the primary multicast RTP
[RFC4585] to the FT entity of RS to fill the gap. BRS might or session) [RFC4585] to the FT entity of the RS to fill the gap.
might not respond to such requests. When it responds and the The BRS might or might not respond to such requests. When it
response causes significant changes in one or more values responds and the response causes significant changes in one or
reported earlier to RTP_Rx, an updated RAMS-I SHOULD be sent to more values reported earlier to the RTP_Rx, an updated RAMS-I
RTP_Rx. SHOULD be sent to the RTP_Rx.
8. Multicast Receive: After the join, RTP_Rx starts receiving the 8. Multicast Receive: After the join, the RTP_Rx starts receiving
primary multicast stream(s). the primary multicast stream(s).
9. Terminate: BRS can know when it needs to ultimately stop the 9. Terminate: The BRS can know when it needs to ultimately stop
unicast burst based on its parameters. However, RTP_Rx may need the unicast burst based on its parameters. However, the RTP_Rx
to ask BRS to terminate the burst prematurely or at a specific may need to ask the BRS to terminate the burst prematurely or at
sequence number. For this purpose, it uses the RAMS-Termination a specific sequence number. For this purpose, the RTP_Rx uses
(RAMS-T) message sent as RTCP feedback in the unicast burst RTP the RAMS-Termination (RAMS-T) message sent as RTCP feedback in
session. A separate RAMS-T message is sent for each primary the unicast burst RTP session. A separate RAMS-T message is
multicast stream served by BRS unless an RTCP BYE message has sent for each primary multicast stream served by the BRS unless
been sent in the unicast burst RTP session as described in Step an RTCP BYE message has been sent in the unicast burst RTP
10. For the burst requests that were rejected by BRS, there is session as described in Step 10. For the burst requests that
no need to send a RAMS-T message. were rejected by the BRS, there is no need to send a RAMS-T
message.
If RTP_Rx wants to terminate a burst prematurely, it SHALL send If the RTP_Rx wants to terminate a burst prematurely, it SHALL
a plain RAMS-T message for the SSRC of the primary multicast send a RAMS-T message for the SSRC of the primary multicast
stream it wishes to terminate. This message is sent in the stream it wishes to terminate. This message is sent in the
unicast burst RTP session. Upon receiving this message BRS MUST unicast burst RTP session. Upon receiving this message, the BRS
terminate the unicast burst. If RTP_Rx requested to acquire the MUST terminate the unicast burst. If the RTP_Rx requested to
entire primary multicast RTP session but wants to terminate this acquire the entire primary multicast RTP session but wants to
request before it learns the individual media sender SSRC(s) via terminate this request before it learns the individual media
RAMS-I message(s) or RTP packets, RTP_Rx cannot use RAMS-T sender SSRC(s) via RAMS-I message(s) or RTP packets, the RTP_Rx
message(s) and thus MUST send an RTCP BYE message in the unicast cannot use RAMS-T message(s) and thus MUST send an RTCP BYE
burst RTP session to terminate the request. message in the unicast burst RTP session to terminate the
request.
Otherwise, the default behavior for RTP_Rx is to send a RAMS-T Otherwise, the default behavior for the RTP_Rx is to send a
message in the unicast burst RTP session immediately after it RAMS-T message in the unicast burst RTP session immediately
joins the multicast session and started receiving multicast after it joins the multicast session and started receiving
packets. In that case, RTP_Rx SHALL send a RAMS-T message with multicast packets. In that case, the RTP_Rx SHALL send a RAMS-T
the sequence number of the first RTP packet received in the message with the sequence number of the first RTP packet
primary multicast stream. Then, BRS MUST terminate the received in the primary multicast stream. Then, the BRS MUST
respective burst after it sends the unicast burst packet whose terminate the respective burst after it sends the unicast burst
Original Sequence Number (OSN) field in the RTP retransmission packet whose Original Sequence Number (OSN) field in the RTP
payload header matches this number minus one. retransmission payload header matches this number minus one.
If an RTCP BYE message has not been issued yet as described in If an RTCP BYE message has not been issued yet as described in
Step 10, RTP_Rx MUST send at least one RAMS-T message for each Step 10, the RTP_Rx MUST send at least one RAMS-T message for
primary multicast stream served by BRS. The RAMS-T message(s) each primary multicast stream served by the BRS. The RAMS-T
MUST be addressed to BRS and sent in the unicast burst RTP message(s) MUST be sent to the BRS in the unicast burst RTP
session. Against the possibility of a message loss, it is session. Against the possibility of a message loss, it is
RECOMMENDED that RTP_Rx repeats the RAMS-T messages multiple RECOMMENDED that the RTP_Rx repeats the RAMS-T messages multiple
times as long as it follows the RTCP timer rules defined in times as long as it follows the RTCP timer rules defined in
[RFC4585]. [RFC4585].
The binding between RAMS-T and ongoing bursts is achieved The binding between RAMS-T and ongoing bursts is achieved
through RTP_Rx's CNAME identifier, and packet sender and media through RTP_Rx's CNAME identifier, and packet sender and media
sender SSRCs. Choosing a globally unique CNAME makes sure that sender SSRCs. Choosing a globally unique CNAME makes sure that
the RAMS-T messages are processed correctly. the RAMS-T messages are processed correctly.
10. Terminate with RTCP BYE: When RTP_Rx is receiving one or more 10. Terminate with RTCP BYE: When the RTP_Rx is receiving one or
burst streams, if RTP_Rx becomes no longer interested in more burst streams, if the RTP_Rx becomes no longer interested
acquiring any of the primary multicast streams, RTP_Rx SHALL in acquiring any of the primary multicast streams, the RTP_Rx
issue an RTCP BYE message for the unicast burst RTP session and SHALL issue an RTCP BYE message for the unicast burst RTP
another RTCP BYE message for the primary multicast RTP session. session and another RTCP BYE message for the primary multicast
These RTCP BYE messages are sent to BRS and FT logical entities, RTP session. These RTCP BYE messages are sent to the BRS and FT
respectively. logical entities, respectively.
Upon receiving an RTCP BYE message, BRS MUST terminate the rapid Upon receiving an RTCP BYE message, the BRS MUST terminate the
acquisition operation, and cease transmitting any further burst rapid acquisition operation, and cease transmitting any further
packets and retransmission packets. If support for [RFC5506] burst packets and retransmission packets. If support for
has been signaled, the RTCP BYE message MAY be sent in a [RFC5506] has been signaled, the RTCP BYE message MAY be sent in
reduced-size RTCP packet. Otherwise, Section 6.1 of [RFC3550] a reduced-size RTCP packet. Otherwise, Section 6.1 of [RFC3550]
mandates the RTCP BYE message always to be sent with a sender or mandates the RTCP BYE message always to be sent with a sender or
receiver report in a compound RTCP packet. If no data has been receiver report in a compound RTCP packet. If no data has been
received, an empty receiver report MUST be still included. With received, an empty receiver report MUST be still included. With
the information contained in the receiver report, RS can figure the information contained in the receiver report, the RS can
out how many duplicate RTP packets have been delivered to RTP_Rx figure out how many duplicate RTP packets have been delivered to
(Note that this will be an upper-bound estimate as one or more the RTP_Rx (Note that this will be an upper-bound estimate as
packets might have been lost during the burst transmission). one or more packets might have been lost during the burst
The impact of duplicate packets and measures that can be taken transmission). The impact of duplicate packets and measures
to minimize the impact of receiving duplicate packets will be that can be taken to minimize the impact of receiving duplicate
addressed in Section 6.4. packets will be addressed in Section 6.4.
Since an RTCP BYE message issued for the unicast burst RTP Since an RTCP BYE message issued for the unicast burst RTP
session terminates that session and ceases transmitting any session terminates that session and ceases transmitting any
further packets in that session, there is no need for sending further packets in that session, there is no need for sending
explicit RAMS-T messages, which would only terminate their explicit RAMS-T messages, which would only terminate their
respective bursts. respective bursts.
For the purpose of gathering detailed information about RTP_Rx's For the purpose of gathering detailed information about RTP_Rx's
rapid acquisition experience, [I-D.ietf-avt-multicast-acq-rtcp-xr] rapid acquisition experience, [I-D.ietf-avt-multicast-acq-rtcp-xr]
defines an RTCP Extended Report (XR) Block. This report is designed defines an RTCP Extended Report (XR) Block. This report is designed
to be payload-independent, thus, it can be used by any multicast to be payload-independent, thus, it can be used by any multicast
application that supports rapid acquisition. Support for this XR application that supports rapid acquisition. Support for this XR
report is, however, OPTIONAL. report is, however, OPTIONAL.
6.3. Synchronization of Primary Multicast Streams 6.3. Synchronization of Primary Multicast Streams
When RTP_Rx acquires multiple primary multicast streams, RTP_Rx can When an RTP_RX acquires multiple primary multicast streams, it might
need to synchronize them for the playout. This synchronization is need to synchronize them for playout. This synchronization is
traditionally achieved by the help of the RTCP sender reports achieved by the help of the RTCP sender reports [RFC3550]. If the
[RFC3550]. If the playout will start before RTP_Rx has joined the playout will start before the RTP_Rx has joined the multicast
multicast session, RTP_Rx needs to receive the information reflecting session, the RTP_Rx needs to receive the information reflecting the
the synchronization among the primary multicast streams early enough synchronization among the primary multicast streams early enough so
so that it can play out the media in a synchronized fashion. that it can play out the media in a synchronized fashion.
The suggested approach is to use the RTP header extension mechanism The suggested approach is to use the RTP header extension mechanism
[RFC5285] and convey the synchronization information in a header [RFC5285] and convey the synchronization information in a header
extension as defined in [I-D.ietf-avt-rapid-rtp-sync]. Per [RFC4588] extension as defined in [I-D.ietf-avt-rapid-rtp-sync]. Per [RFC4588]
"if the original RTP header carried an RTP header extension, the "if the original RTP header carried an RTP header extension, the
retransmission packet SHOULD carry the same header extension." Thus, retransmission packet SHOULD carry the same header extension." Thus,
as long as the multicast source emits a header extension with the as long as the multicast source emits a header extension with the
synchronization information frequently enough, there is no additional synchronization information frequently enough, there is no additional
task that needs to be carried out by BRS. The synchronization task that needs to be carried out by the BRS. The synchronization
information will be sent to RTP_Rx along with the burst packets. The information will be sent to the RTP_Rx along with the burst packets.
frequent header extensions sent in the primary multicast RTP sessions The frequent header extensions sent in the primary multicast RTP
also allow rapid synchronization of the RTP streams for the RTP sessions also allow rapid synchronization of the RTP streams for the
receivers that do not support RAMS or that directly join the RTP receivers that do not support RAMS or that directly join the
multicast session without running RAMS. Thus, in RAMS applications, multicast session without running RAMS. Thus, in RAMS applications,
it is RECOMMENDED that the multicast sources frequently send it is RECOMMENDED that the multicast sources frequently send
synchronization information by using header extensions following the synchronization information by using header extensions following the
rules presented in [I-D.ietf-avt-rapid-rtp-sync]. The regular sender rules presented in [I-D.ietf-avt-rapid-rtp-sync]. The regular sender
reports are still sent in the unicast session by following the rules reports are still sent in the unicast session by following the rules
of [RFC3550]. of [RFC3550].
6.4. Burst Shaping and Congestion Control in RAMS 6.4. Burst Shaping and Congestion Control in RAMS
This section provides informative guidelines about how BRS can shape This section provides informative guidelines about how the BRS can
the transmission of the unicast burst and how congestion can be dealt shape the transmission of the unicast burst and how congestion can be
within the RAMS process. When RTP_Rx detects that the unicast burst dealt within the RAMS process. When the RTP_Rx detects that the
is causing severe congestion, it can prefer to send a RAMS-T message unicast burst is causing severe congestion, it can prefer to send a
immediately to stop the unicast burst. RAMS-T message immediately to stop the unicast burst.
A higher bitrate for the unicast burst naturally conveys the A higher bitrate for the unicast burst naturally conveys the
Reference Information and media content to RTP_Rx faster. This way, Reference Information and media content to the RTP_Rx faster. This
RTP_Rx can start consuming the data sooner, which results in a faster way, the RTP_Rx can start consuming the data sooner, which results in
acquisition. A higher bitrate also represents a better utilization a faster acquisition. A higher bitrate also represents a better
of BRS resources. As the burst may continue until it catches up with utilization of the BRS resources. As the burst may continue until it
the primary multicast stream, the higher the bursting bitrate, the catches up with the primary multicast stream, the higher the bursting
less data BRS needs to transmit. However, a higher bitrate for the bitrate, the less data the BRS needs to transmit. However, a higher
burst also increases the chances for congestion-caused packet loss. bitrate for the burst also increases the chances for congestion-
caused packet loss. Thus, as discussed in Section 5, there has to be
Thus, as discussed in Section 5, there has to be an upper bound on an upper bound on the bandwidth used by the burst.
the bandwidth used by the burst.
When BRS transmits the unicast burst, it is expected to take into When the BRS transmits the unicast burst, it is expected to take into
account all available information to prevent any packet loss that account all available information to prevent any packet loss that
might take place during the bursting as a result of buffer overflow might take place during the bursting as a result of buffer overflow
on the path between RS and RTP_Rx and at RTP_Rx itself. The bursting on the path between the RS and RTP_Rx and at the RTP_Rx itself. The
bitrate can be determined by taking into account the following bursting bitrate can be determined by taking into account the
information, when available: following information, when available:
a. Information obtained via the RAMS-R message, such as Max RAMS a. Information obtained via the RAMS-R message, such as Max RAMS
Buffer Fill Requirement and/or Max Receive Bitrate (See Buffer Fill Requirement and/or Max Receive Bitrate (See
Section 7.2). Section 7.2).
b. Information obtained via RTCP receiver reports provided by RTP_Rx b. Information obtained via RTCP receiver reports provided by the
in the retransmission session, allowing in-session bitrate RTP_Rx in the retransmission session, allowing in-session bitrate
adaptations for the burst. When these receiver reports indicate adaptations for the burst. When these receiver reports indicate
packet loss, this can indicate a certain congestion state in the packet loss, this can indicate a certain congestion state in the
path from RS to RTP_Rx. path from the RS to the RTP_Rx.
c. Information obtained via RTCP NACKs provided by RTP_Rx in the c. Information obtained via RTCP NACKs provided by the RTP_Rx in the
primary multicast RTP session, allowing in-session bitrate primary multicast RTP session, allowing in-session bitrate
adaptations for the burst. Such RTCP NACKs are transmitted by adaptations for the burst. Such RTCP NACKs are transmitted by
RTP_Rx in response to packet loss detection in the burst. NACKs the RTP_Rx in response to packet loss detection in the burst.
can indicate a certain congestion state on the path from RS to NACKs can indicate a certain congestion state on the path from
RTP_Rx. the RS to RTP_Rx.
d. There can be other feedback received from RTP_Rx, e.g., in the d. There can be other feedback received from the RTP_Rx, e.g., in
form of ECN-CE markings [I-D.ietf-avt-ecn-for-rtp] that can the form of ECN-CE markings [I-D.ietf-avt-ecn-for-rtp] that can
influence in-session bitrate adaptation. influence in-session bitrate adaptation.
e. Information obtained via updated RAMS-R messages, allowing in- e. Information obtained via updated RAMS-R messages, allowing in-
session bitrate adaptations, if supported by BRS. session bitrate adaptations, if supported by the BRS.
f. Transport protocol-specific information. For example, when DCCP f. Transport protocol-specific information. For example, when DCCP
is used to transport the RTP burst, the ACKs from the DCCP client 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 can be leveraged by the BRS / DCCP server for burst shaping and
congestion control. congestion control.
g. Pre-configured settings for each RTP_Rx or a set of RTP_Rxs that g. Pre-configured settings for each RTP_Rx or a set of RTP_Rxs that
indicate the upper-bound bursting bitrates for which no packet indicate the upper-bound bursting bitrates for which no packet
loss will occur as a result of congestion along the path of RS to loss will occur as a result of congestion along the path of the
RTP_Rx. For example, in managed IPTV networks, where 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 bottleneck bandwidth along the end-to-end path is known and where
the network between RS and this link is provisioned and the network between the RS and this link is provisioned and
dimensioned to carry the burst streams, the bursting bitrate does dimensioned to carry the burst streams, the bursting bitrate does
not exceed the provisioned value. These settings can also be not exceed the provisioned value. These settings can also be
dynamically adapted using application-aware knowledge. dynamically adapted using application-aware knowledge.
BRS chooses the initial burst bitrate as follows: The BRS chooses the initial burst bitrate as follows:
o When using RAMS in environments as described in (g), BRS MUST o When using RAMS in environments as described in (g), the BRS MUST
transmit the burst packets at an initial bitrate higher than the transmit the burst packets at an initial bitrate higher than the
nominal bitrate, but within the engineered or reserved bandwidth nominal bitrate, but within the engineered or reserved bandwidth
limit. limit.
o When BRS cannot determine a reliable bitrate value for the unicast o When the BRS cannot determine a reliable bitrate value for the
burst (using a through g), it is desirable that BRS chooses an unicast burst (using a through g), it is desirable that the BRS
appropriate initial bitrate not above the nominal bitrate and chooses an appropriate initial bitrate not above the nominal
increases it gradually unless a congestion is detected. bitrate and increases it gradually unless a congestion is
detected.
In both cases, during the burst transmission BRS MUST continuously In both cases, during the burst transmission the BRS MUST
monitor for packet losses as a result of congestion by means of one continuously monitor for packet losses as a result of congestion by
or more of the mechanisms described in (b,c,d,e,f). When BRS relies means of one or more of the mechanisms described in (b,c,d,e,f).
on RTCP receiver reports, sufficient bandwidth needs to be provided When the BRS relies on RTCP receiver reports, sufficient bandwidth
to RTP Rx for RTCP transmission in the unicast burst RTP session. To needs to be provided to RTP Rx for RTCP transmission in the unicast
achieve a reasonable fast adaptation against congestion, it is burst RTP session. To achieve a reasonable fast adaptation against
recommended that RTP_Rx sends a receiver report at least once every congestion, it is recommended that the RTP_Rx sends a receiver report
two RTTs between RS and RTP_Rx. Although the specific heuristics and at least once every two RTTs between the RS and RTP_Rx. Although the
algorithms that deduce a congestion state and how subsequently BRS specific heuristics and algorithms that deduce a congestion state and
acts are outside the scope of this specification, the following two how subsequently the BRS acts are outside the scope of this
methods are the best practices: specification, the following two methods are the best practices:
o Upon detection of a significant amount of packet loss, which BRS o Upon detection of a significant amount of packet loss, which the
attributes to congestion, BRS decreases the burst bitrate. The BRS attributes to congestion, the BRS decreases the burst bitrate.
rate by which BRS increases and decreases the bitrate for the The rate by which the BRS increases and decreases the bitrate for
burst can be determined by a TCP-friendly bitrate adaptation the burst can be determined by a TCP-friendly bitrate adaptation
algorithm for RTP over UDP , or in the case of (f) by the algorithm for RTP over UDP , or in the case of (f) by the
congestion control algorithms defined in DCCP [RFC5762]. congestion control algorithms defined in DCCP [RFC5762].
o If the congestion is persistent and BRS has to reduce the burst o If the congestion is persistent and the BRS has to reduce the
bitrate to a point where the RTP Rx buffer might underrun or the burst bitrate to a point where the RTP Rx buffer might underrun or
burst will consume too many resources, BRS terminates the burst the burst will consume too many resources, the BRS terminates the
and transmits a RAMS-I message to RTP Rx with the appropriate burst and transmits a RAMS-I message to RTP Rx with the
response code. It is then up to RTP Rx to decide when to join the appropriate response code. It is then up to RTP Rx to decide when
multicast session. to join the multicast session.
Even though there is no congestion experienced during the burst, Even though there is no congestion experienced during the burst,
congestion may anyway arise near the end of the burst as RTP_Rx congestion may anyway arise near the end of the burst as the RTP_Rx
eventually needs to join the multicast session. During this brief eventually needs to join the multicast session. During this brief
period both the burst packets and the multicast packets can be period both the burst packets and the multicast packets can be
simultaneously received by RTP_Rx, thus enhancing the risk of simultaneously received by the RTP_Rx, thus enhancing the risk of
congestion. congestion.
Since BRS signals RTP_Rx when BRS expects RTP_Rx to send the SFGMP Since the BRS signals the RTP_Rx when the BRS expects the RTP_Rx to
Join message, BRS can have a rough estimate of when RTP_Rx will start send the SFGMP Join message, the BRS can have a rough estimate of
receiving multicast packets in the SSM session. BRS can keep on when the RTP_Rx will start receiving multicast packets in the SSM
sending burst packets but reduces the bitrate accordingly at the session. The BRS can keep on sending burst packets but reduces the
appropriate instant by taking the bitrate of the whole SSM session bitrate accordingly at the appropriate instant by taking the bitrate
into account. If BRS ceases transmitting the burst packets before of the whole SSM session into account. If the BRS ceases
the burst catches up, any gap resulting from this imperfect switch- transmitting the burst packets before the burst catches up, any gap
over by RTP_Rx can be later repaired by requesting retransmissions resulting from this imperfect switch-over by the RTP_Rx can be later
for the missing packets from RS. The retransmissions can be shaped repaired by requesting retransmissions for the missing packets from
by BRS to make sure that they do not cause collateral loss in the the RS. The retransmissions can be shaped by the BRS to make sure
primary multicast RTP session and the unicast burst RTP session. that they do not cause collateral loss in the primary multicast RTP
session and the unicast burst RTP session.
6.5. Failure Cases 6.5. Failure Cases
In the following, we examine the implications of losing the RAMS-R, In the following, we examine the implications of losing the RAMS-R,
RAMS-I or RAMS-T messages and other failure cases. RAMS-I or RAMS-T messages and other failure cases.
When RTP_Rx sends a RAMS-R message to initiate a rapid acquisition When the RTP_Rx sends a RAMS-R message to initiate a rapid
but the message gets lost and FT does not receive it, RTP_Rx will get acquisition but the message gets lost and the FT does not receive it,
neither a RAMS-I message, nor a unicast burst. In this case, RTP_Rx the RTP_Rx will get neither a RAMS-I message, nor a unicast burst.
MAY resend the request when it is eligible to do so based on the RTCP In this case, the RTP_Rx MAY resend the request when it is eligible
timer rules defined in [RFC4585]. Or, after a reasonable amount of to do so based on the RTCP timer rules defined in [RFC4585]. Or,
time, RTP_Rx can time out (based on the previous observed response after a reasonable amount of time, the RTP_Rx can time out (based on
times) and immediately join the SSM session. the previous observed response times) and immediately join the SSM
session.
In the case RTP_Rx starts receiving a unicast burst but it does not In the case the RTP_Rx starts receiving a unicast burst but it does
receive a corresponding RAMS-I message within a reasonable amount of not receive a corresponding RAMS-I message within a reasonable amount
time, RTP_Rx can either discard the burst data or decide not to of time, the RTP_Rx can either discard the burst data or decide not
interrupt the unicast burst, and be prepared to join the SSM session to interrupt the unicast burst, and be prepared to join the SSM
at an appropriate time it determines or as indicated in a subsequent session at an appropriate time it determines or as indicated in a
RAMS-I message (if available). If the network is subject to packet subsequent RAMS-I message (if available). If the network is subject
loss, it is RECOMMENDED that BRS repeats the RAMS-I messages multiple to packet loss, it is RECOMMENDED that the BRS repeats the RAMS-I
times based on the RTCP timer rules defined in [RFC4585]. messages multiple times based on the RTCP timer rules defined in
[RFC4585].
In the failure cases where the RAMS-R message is lost and RTP_Rx In the failure cases where the RAMS-R message is lost and the RTP_Rx
gives up, or the RAMS-I message is lost, RTP_Rx MUST still terminate gives up, or the RAMS-I message is lost, the RTP_Rx MUST still
the burst(s) it requested by following the rules described in terminate the burst(s) it requested by following the rules described
Section 6.2. in Section 6.2.
In the case a RAMS-T message sent by RTP_Rx does not reach its In the case a RAMS-T message sent by the RTP_Rx does not reach its
destination, BRS can continue sending burst packets even though destination, the BRS can continue sending burst packets even though
RTP_Rx no longer needs them. In such cases, it is RECOMMENDED that the RTP_Rx no longer needs them. In such cases, it is RECOMMENDED
RTP_Rx repeats the RAMS-T message multiple times based on the RTCP that the RTP_Rx repeats the RAMS-T message multiple times based on
timer rules defined in [RFC4585]. BRS MUST be provisioned to the RTCP timer rules defined in [RFC4585]. The BRS MUST be
deterministically terminate the burst when it can no longer send the provisioned to terminate the burst when it can no longer send the
burst packets faster than it receives the primary multicast stream burst packets faster than it receives the primary multicast stream
packets. packets.
Section 6.3.5 of [RFC3550] explains the rules pertaining to timing Section 6.3.5 of [RFC3550] explains the rules pertaining to timing
out an SSRC. When BRS accepts to serve the requested burst(s) and out an SSRC. When the BRS accepts to serve the requested burst(s)
establishes the retransmission session, BRS needs to check the and establishes the retransmission session, the BRS needs to check
liveness of RTP_Rx via the RTCP messages and reports RTP_Rx sends. the liveness of the RTP_Rx via the RTCP messages and reports the
The default rules explained in [RFC3550] apply in RAMS as well. RTP_Rx sends. The default rules explained in [RFC3550] apply in RAMS
as well.
7. Encoding of the Signaling Protocol in RTCP 7. Encoding of the Signaling Protocol in RTCP
This section defines the formats of the RTCP transport-layer feedback This section defines the formats of the RTCP transport-layer feedback
messages that are exchanged between the retransmission server (RS) messages that are exchanged between the retransmission server (RS)
and RTP receiver (RTP_Rx) during rapid acquisition. These messages and RTP receiver (RTP_Rx) during rapid acquisition. These messages
are referred to as the RAMS Messages. They are payload-independent are referred to as the RAMS Messages. They are payload-independent
and MUST be used by all RTP-based multicast applications that support and MUST be used by all RTP-based multicast applications that support
rapid acquisition regardless of the payload they carry. rapid acquisition regardless of the payload they carry.
skipping to change at page 28, line 38 skipping to change at page 28, line 48
o Value: Variable-size set of octets that contains the specific o Value: Variable-size set of octets that contains the specific
value for the parameter. value for the parameter.
In the extensions, the Reserved field SHALL be set to zero and 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 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 last word MUST be padded to the boundary using further bits set to
zero. zero.
In a RAMS message, any vendor-neutral or private extension MUST be In a RAMS message, any vendor-neutral or private extension MUST be
placed after the mandatory fields and mandatory TLV elements (if placed after the mandatory fields and mandatory TLV elements (if
any). The extensions MAY be placed in any order. The support for any). The extensions MAY be placed in any order. In a RAMS message,
extensions (unless specified otherwise) is OPTIONAL. multiple TLV elements with the same Type value MUST NOT exist.
The support for extensions (unless specified otherwise) is OPTIONAL.
0 1 2 3 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 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 | | Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value : : Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Structure of a TLV element Figure 5: Structure of a TLV element
skipping to change at page 29, line 44 skipping to change at page 30, line 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number | | Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value : : Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Structure of a private extension Figure 6: Structure of a private extension
7.2. RAMS Request 7.2. RAMS Request
The RAMS Request message is identified by SFMT=1. This message is The RAMS Request (RAMS-R) message is identified by SFMT=1. This
sent as unicast feedback in the primary multicast RTP session by message is sent as unicast feedback in the primary multicast RTP
RTP_Rx to request rapid acquisition of a primary multicast RTP session by the RTP_Rx to request rapid acquisition of a primary
session, or one or more primary multicast streams belonging to the multicast RTP session, or one or more primary multicast streams
same primary multicast RTP session. In the RAMS-R message, RTP_Rx belonging to the same primary multicast RTP session. In the RAMS-R
MUST set both the packet sender SSRC and media sender SSRC fields to message, the RTP_Rx MUST set both the packet sender SSRC and media
its own SSRC since the media sender SSRC may not be known. RTP_Rx sender SSRC fields to its own SSRC since the media sender SSRC may
MUST provide explicit signaling as described below to request not be known. The RTP_Rx MUST provide explicit signaling as
stream(s). This minimizes the chances of accidentally requesting a described below to request stream(s). This minimizes the chances of
wrong primary multicast stream. accidentally requesting a wrong primary multicast stream.
The FCI field MUST contain only one RAMS Request. The FCI field has The FCI field MUST contain only one RAMS Request. The FCI field has
the structure depicted in Figure 7. 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.
0 1 2 3 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 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 | | SFMT=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Requested Media Sender SSRC(s) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) : : Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: FCI field syntax for the RAMS Request message Figure 7: FCI field syntax for the RAMS Request message
o Requested Media Sender SSRC(s): Mandatory TLV element that lists o Requested Media Sender SSRC(s): Mandatory TLV element that lists
the media sender SSRC(s) requested by RTP_Rx. BRS MUST ignore the the media sender SSRC(s) requested by the RTP_Rx. The BRS MUST
media sender SSRC specified in the header of the RAMS-R message. 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 If the Length field is set to zero (i.e., no media sender SSRC is
listed), it means that RTP_Rx is requesting to rapidly acquire the listed), it means that the RTP_Rx is requesting to rapidly acquire
entire primary multicast RTP session. Otherwise, RTP_Rx lists the the entire primary multicast RTP session. Otherwise, the RTP_Rx
individual media sender SSRCs in this TLV element and sets the lists the individual media sender SSRCs in this TLV element and
Length field of the TLV element to 4*n, where n is the number of sets the Length field of the TLV element to 4*n, where n is the
SSRC entries. number of SSRC entries.
Type: 1 Type: 1
o Min RAMS Buffer Fill Requirement (32 bits): Optional TLV element o Min RAMS Buffer Fill Requirement (32 bits): Optional TLV element
that denotes the minimum milliseconds of data that RTP_Rx desires that denotes the minimum milliseconds of data that the RTP_Rx
to have in its buffer before allowing the data to be consumed by desires to have in its buffer before allowing the data to be
the application. consumed by the application.
RTP_Rx can have knowledge of its buffering requirements. These The RTP_Rx can have knowledge of its buffering requirements.
requirements can be application and/or device specific. For These requirements can be application and/or device specific. For
instance, RTP_Rx might need to have a certain amount of data in instance, the RTP_Rx might need to have a certain amount of data
its application buffer to handle transmission jitter and/or to be in its application buffer to handle transmission jitter and/or to
able to support error-control methods. If BRS is told the minimum be able to support error-control methods. If the BRS is told the
buffering requirement of the receiver, BRS can tailor the burst(s) minimum buffering requirement of the receiver, the BRS can tailor
more precisely, e.g., by choosing an appropriate starting point. the burst(s) more precisely, e.g., by choosing an appropriate
The methods used by RTP_Rx to determine this value are application starting point. The methods used by the RTP_Rx to determine this
specific, and thus, out of the scope of this document. 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 If specified, the amount of backfill that will be provided by the
unicast bursts and any payload-specific information MUST NOT be unicast bursts and any payload-specific information MUST NOT be
smaller than the specified value. Otherwise, the backfill will smaller than the specified value. Otherwise, the backfill will
not be able to build up the desired level of buffer at RTP_Rx and not be able to build up the desired level of buffer at the RTP_Rx
can cause buffer underruns. and can cause buffer underruns.
Type: 2 Type: 2
o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element
that denotes the maximum milliseconds of data that RTP_Rx can that denotes the maximum milliseconds of data that the RTP_Rx can
buffer without losing the data due to buffer overflow. buffer without losing the data due to buffer overflow.
RTP_Rx can have knowledge of its buffering requirements. These The RTP_Rx can have knowledge of its buffering requirements.
requirements can be application or device specific. For instance, These requirements can be application or device specific. For
one particular RTP_Rx might have more physical memory than another instance, one particular RTP_Rx might have more physical memory
RTP_Rx, and thus, can buffer more data. If BRS knows the than another RTP_Rx, and thus, can buffer more data. If the BRS
buffering ability of the receiver, BRS can tailor the burst(s) knows the buffering ability of the receiver, the BRS can tailor
more precisely. The methods used by the receiver to determine the burst(s) more precisely. The methods used by the receiver to
this value are application specific, and thus, out of scope. determine this value are application specific, and thus, out of
scope.
If specified, the amount of backfill that will be provided by the If specified, the amount of backfill that will be provided by the
unicast bursts and any payload-specific information MUST NOT be unicast bursts and any payload-specific information MUST NOT be
larger than this value. Otherwise, the backfill may cause buffer larger than this value. Otherwise, the backfill may cause buffer
overflows at RTP_Rx. overflows at the RTP_Rx.
Type: 3 Type: 3
o Max Receive Bitrate (64 bits): Optional TLV element that denotes o Max Receive Bitrate (64 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) at which the RTP_Rx can the maximum bitrate (in bits per second) at which the RTP_Rx can
process the aggregation of the unicast burst(s) and any payload- process the aggregation of the unicast burst(s) and any payload-
specific information that will be provided by BRS. The limits can specific information that will be provided by the BRS. The limits
include local receiver limits as well as network limits that are can include local receiver limits as well as network limits that
known to the receiver. are known to the receiver.
If specified, the total bitrate of the unicast burst(s) plus any If specified, the total bitrate of the unicast burst(s) plus any
payload-specific information MUST NOT be larger than this value. payload-specific information MUST NOT be larger than this value.
Otherwise, congestion and packet loss may occur. Otherwise, congestion and packet loss may occur.
Type: 4 Type: 4
o Request for Preamble Only (0 bits): Optional TLV element that o Request for Preamble Only (0 bits): Optional TLV element that
indicates that RTP_Rx is only requesting the preamble information indicates that the RTP_Rx is only requesting the preamble
for the desired primary multicast stream(s). If this TLV element information for the desired primary multicast stream(s). If this
exists in the RAMS-R message, BRS MUST NOT send any burst packets TLV element exists in the RAMS-R message, the BRS MUST NOT send
other than the preamble packets. Since this TLV element does not any burst packets other than the preamble packets. Since this TLV
carry a Value field, the Length field MUST be set to zero. element does not carry a Value field, the Length field MUST be set
to zero.
Type: 5 Type: 5
The semantics of the RAMS-R feedback message is independent of the
payload type.
7.3. RAMS Information 7.3. RAMS Information
The RAMS Information message is identified by SFMT=2. This message The RAMS Information (RAMS-I) message is identified by SFMT=2. This
is used to describe the unicast burst that will be sent for rapid message is used to describe the unicast burst that will be sent for
acquisition. It also includes other useful information for RTP_Rx as rapid acquisition. It also includes other useful information for the
described below. RTP_Rx as described below.
A separate RAMS-I message with the appropriate response code is sent A separate RAMS-I message with the appropriate response code is sent
in the unicast burst RTP session by BRS for each primary multicast in the unicast burst RTP session by the BRS for each primary
stream that has been requested by RTP_Rx. In each of these RAMS-I multicast stream that has been requested by the RTP_Rx. In each of
messages, the media sender SSRC and packet sender SSRC fields are these RAMS-I messages, the media sender SSRC and packet sender SSRC
both set to the SSRC of BRS, which equals the SSRC of the respective fields are both set to the SSRC of the BRS, which equals the SSRC of
primary multicast stream. the respective primary multicast stream.
The FCI field MUST contain only one RAMS Information. The FCI field The FCI field MUST contain only one RAMS Information message. The
has the structure depicted in Figure 8. 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.
0 1 2 3 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 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 | | SFMT=2 | MSN | Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) : : Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: FCI field syntax for the RAMS Information message Figure 8: FCI field syntax for the RAMS Information message
skipping to change at page 32, line 46 skipping to change at page 33, line 17
sender SSRC specified in the message header. The MSN value SHALL sender SSRC specified in the message header. The MSN value SHALL
be set to zero only when a new RAMS request is received. During be set to zero only when a new RAMS request is received. During
rapid acquisition, the same RAMS-I message MAY be repeated for rapid acquisition, the same RAMS-I message MAY be repeated for
redundancy purposes without incrementing the MSN value. If an redundancy purposes without incrementing the MSN value. If an
updated RAMS-I message will be sent (either with a new information updated RAMS-I message will be sent (either with a new information
or an updated information), the MSN value SHALL be incremented by or an updated information), the MSN value SHALL be incremented by
one. In the MSN field, the regular wrapping rules apply. one. In the MSN field, the regular wrapping rules apply.
o Response (16 bits): Mandatory field that denotes the response o Response (16 bits): Mandatory field that denotes the response
code for this RAMS-I message. This document defines several code for this RAMS-I message. This document defines several
initial response codes and registers them with IANA. If a new initial response codes in Section 11.6 and registers them with
vendor-neutral response code will be defined, it MUST be IANA. If a new vendor-neutral response code will be defined, it
registered with IANA through the guidelines specified in MUST be registered with IANA through the guidelines specified in
Section 11.6. If the new response code is intended to be used Section 11.6. If the new response code is intended to be used
privately by a vendor, there is no need for IANA management. privately by a vendor, there is no need for IANA management.
Instead, the vendor MUST use the private extension mechanism Instead, the vendor MUST use the private extension mechanism
(Section 7.1.2) to convey its message and MUST indicate this by (Section 7.1.2) to convey its message and MUST indicate this by
putting zero in the Response field. putting zero in the Response field. When the RTP_Rx receives an
RAMS-I message with a private response code that it does not
understand, the RTP_Rx still needs to process the TLV elements it
understands.
The following TLV elements have been defined for the RAMS-I messages: The following TLV elements have been defined for the RAMS-I messages:
o Media Sender SSRC (32 bits): Optional TLV element that specifies o Media Sender SSRC (32 bits): Optional TLV element that specifies
the media sender SSRC of the unicast burst stream. While this the media sender SSRC of the unicast burst stream. While this
information is already available in the message header, it can be information is already available in the message header, it can be
useful to repeat it in an explicit field. If FT_Ap that received useful to repeat it in an explicit field. If the FT_Ap that
the RAMS-R message is associated with a single primary multicast received the RAMS-R message is associated with a single primary
stream but the requested media sender SSRC does not match the SSRC multicast stream but the requested media sender SSRC does not
of the RTP stream associated with this FT_Ap, BRS includes this match the SSRC of the RTP stream associated with this FT_Ap, the
TLV element in the initial RAMS-I message to let RTP_Rx know that BRS includes this TLV element in the initial RAMS-I message to let
the media sender SSRC has changed. If the two SSRCs match, there the RTP_Rx know that the media sender SSRC has changed. If the
is no need to include this TLV element. two SSRCs match, there is no need to include this TLV element.
Type: 31 Type: 31
o RTP Seqnum of the First Packet (16 bits): TLV element that o RTP Seqnum of the First Packet (16 bits): TLV element that
specifies the RTP sequence number of the first packet that will be specifies the RTP sequence number of the first packet that will be
sent in the respective RTP stream. This allows RTP_Rx to know sent in the respective unicast RTP stream. This allows the RTP_Rx
whether one or more packets sent by BRS have been dropped at the to know whether one or more packets sent by the BRS have been
beginning of the stream. If BRS accepts the RAMS request, this dropped at the beginning of the stream. If the BRS accepts the
element exists. If BRS rejects the RAMS request, this element RAMS request, this element exists. If the BRS rejects the RAMS
SHALL NOT exist. request, this element SHALL NOT exist.
Type: 32 Type: 32
o Earliest Multicast Join Time (32 bits): TLV element that o Earliest Multicast Join Time (32 bits): TLV element that
specifies the delta time (in ms) between the arrival of the first specifies the delta time (in ms) between the arrival of the first
RTP packet in the RTP stream (which could be a burst packet or a RTP packet in the unicast RTP stream (which could be a burst
payload-specific packet) and the earliest time instant when RTP_Rx packet or a payload-specific packet) and the earliest time instant
sends an SFGMP Join message to join the multicast session. A zero when an RTP_Rx MAY send an SFGMP Join message to join the
value in this field means that RTP_Rx can send the SFGMP Join multicast session. A zero value in this field means that the
message right away. RTP_Rx MAY send the SFGMP Join message right away.
If the RAMS request has been accepted, BRS sends this field at If the RAMS request has been accepted, the BRS sends this field at
least once, so that RTP_Rx knows when to join the multicast least once, so that the RTP_Rx knows when to join the multicast
session. If the burst request has been rejected as indicated in session. If the burst request has been rejected as indicated in
the Response field, this field MUST be set to zero. In that case, the Response field, this field MUST be set to zero. In that case,
it is up to RTP_Rx when or whether to join the multicast session. it is up to the RTP_Rx when or whether to join the multicast
session.
When BRS serves two or more bursts and sends a separate RAMS-I 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 message for each burst, the join times specified in these RAMS-I
messages should correspond to more or less the same time instant, messages should correspond to more or less the same time instant,
and RTP_Rx sends the SFGMP Join message based on the earliest join and the RTP_Rx sends the SFGMP Join message based on the earliest
time. join time.
Type: 33 Type: 33
o Burst Duration (32 bits): Optional TLV element that denotes the o Burst Duration (32 bits): Optional TLV element that denotes the
duration of the burst, i.e., the delta difference between the time the burst will last (in ms), i.e., the delta difference
first and the last burst packet, that BRS is planning to send (in between the expected transmission times of the first and the last
ms) in the respective RTP stream. In the absence of additional burst packets that the BRS is planning to send in the respective
stimulus, BRS will send a burst of this duration. However, the unicast RTP stream. In the absence of additional stimulus, the
burst duration can be modified by subsequent events, including BRS will send a burst of this duration. However, the burst
changes in the primary multicast stream and reception of RAMS-T duration can be modified by subsequent events, including changes
messages. in the primary multicast stream and reception of RAMS-T messages.
BRS MUST terminate the flow in a deterministic timeframe, even if The BRS MUST terminate the flow in the timeframe indicated by this
it does not get a RAMS-T or a BYE from RTP_Rx. It is OPTIONAL to burst duration or the duration established by those subsequent
send this field in a RAMS-I message when the burst request is events, even if it does not get a RAMS-T or a BYE message from the
accepted. If the burst request has been rejected as indicated in RTP_Rx. It is OPTIONAL to send this field in a RAMS-I message
the Response field, this field MAY be omitted or set to zero. when the burst request is accepted. If the burst request has been
rejected as indicated in the Response field, this field MAY be
omitted or set to zero.
Type: 34 Type: 34
o Max Transmit Bitrate (64 bits): Optional TLV element that denotes o Max Transmit Bitrate (64 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that will be used by BRS the maximum bitrate (in bits per second) that will be used by the
for the RTP stream associated with this RAMS-I message. BRS for the RTP stream associated with this RAMS-I message.
Type: 35 Type: 35
The semantics of the RAMS-I feedback message is independent of the
payload type.
7.4. RAMS Termination 7.4. RAMS Termination
The RAMS Termination message is identified by SFMT=3. The RAMS Termination (RAMS-T) message is identified by SFMT=3.
The RAMS Termination is used to assist BRS in determining when to 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 stop the burst. A separate RAMS-T message is sent in the unicast
burst RTP session by RTP_Rx for each primary multicast stream that burst RTP session by the RTP_Rx for each primary multicast stream
has been served by BRS. Each of these RAMS-T messages has the that has been served by the BRS. Each of these RAMS-T messages has
appropriate media sender SSRC populated in its message header. the appropriate media sender SSRC populated in its message header.
If RTP_Rx wants BRS to stop a burst prematurely, it sends a plain 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, BRS RAMS-T message as described below. Upon receiving this message, the
stops the respective burst immediately. If RTP_Rx wants BRS to BRS stops the respective burst immediately. If the RTP_Rx wants the
terminate all of the bursts, it needs to send all of the respective BRS to terminate all of the bursts, it needs to send all of the
RAMS-T messages in a single compound RTCP packet. respective RAMS-T messages in a single compound RTCP packet.
The default behavior for RTP_Rx is to send a RAMS-T message The default behavior for the RTP_Rx is to send a RAMS-T message
immediately after it joined the multicast session and started immediately after it joined the multicast session and started
receiving multicast packets. In that case, RTP_Rx includes the receiving multicast packets. In that case, the RTP_Rx includes the
sequence number of the first RTP packet received in the primary sequence number of the first RTP packet received in the primary
multicast stream in the RAMS-T message. With this information, BRS multicast stream in the RAMS-T message. With this information, the
can decide when to terminate the unicast burst. BRS can decide when to terminate the unicast burst.
The FCI field MUST contain only one RAMS Termination. The FCI field The FCI field MUST contain only one RAMS Termination. The FCI field
has the structure depicted in Figure 9. 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.
0 1 2 3 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 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 | | SFMT=3 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) : : Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: FCI field syntax for the RAMS Termination message Figure 9: FCI field syntax for the RAMS Termination message
skipping to change at page 35, line 28 skipping to change at page 36, line 4
Figure 9: FCI field syntax for the RAMS Termination message Figure 9: FCI field syntax for the RAMS Termination message
o Extended RTP Seqnum of First Multicast Packet (32 bits): Optional o Extended RTP Seqnum of First Multicast Packet (32 bits): Optional
TLV element that specifies the extended RTP sequence number of the TLV element that specifies the extended RTP sequence number of the
first packet received from the SSM session for a particular first packet received from the SSM session for a particular
primary multicast stream. The low 16 bits contain the sequence primary multicast stream. The low 16 bits contain the sequence
number of the first packet received from the SSM session, and the number of the first packet received from the SSM session, and the
most significant 16 bits extend that sequence number with the most significant 16 bits extend that sequence number with the
corresponding count of sequence number cycles, which can be corresponding count of sequence number cycles, which can be
maintained according to the algorithm in Appendix A.1 of maintained according to the algorithm in Appendix A.1 of
[RFC3550]. [RFC3550].
Type: 61 Type: 61
The semantics of the RAMS-T feedback message is independent of the
payload type.
8. SDP Signaling 8. SDP Signaling
8.1. Definitions 8.1. Definitions
The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585]. The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585].
Here we add the following syntax to the 'rtcp-fb' attribute (the Here we add the following syntax to the 'rtcp-fb' attribute (the
feedback type and optional parameters are all case sensitive): feedback type and optional parameters are all case sensitive):
(In the following ABNF [RFC5234], fmt, SP and CRLF are used as (In the following ABNF [RFC5234], rtcp-fb-nack-param is used as
defined in [RFC4566].) defined in [RFC4566].)
rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF
rtcp-fb-pt = "*" ; wildcard: applies to all formats rtcp-fb-nack-param =/ SP "rai"
/ fmt ; as defined in SDP spec
rtcp-fb-val = "nack" SP "rai"
The following parameter is defined in this document for use with The following parameter is defined in this document for use with
'nack': 'nack':
o 'rai' stands for Rapid Acquisition Indication and indicates the o 'rai' stands for Rapid Acquisition Indication and indicates the
use of RAMS messages as defined in Section 7. use of RAMS messages as defined in Section 7.
This document also defines a new media-level SDP attribute ('rams- This document also defines a new media-level SDP attribute ('rams-
updates') that indicates whether BRS supports updated request updates') that indicates whether the BRS supports updated request
messages or not. This attribute is used in a declarative manner and messages or not. This attribute is used in a declarative manner and
no Offer/Answer Model behavior is specified. If BRS supports updated no Offer/Answer Model behavior is specified. If the BRS supports
request messages and this attribute is included in the SDP updated request messages and this attribute is included in the SDP
description, RTP_Rx can send updated requests. BRS might or might description, the RTP_Rx can send updated requests. The BRS might or
not be able to accept value changes in every field in an updated might not be able to accept value changes in every field in an
RAMS-R message. However, if the 'rams-updates' attribute is not updated RAMS-R message. However, if the 'rams-updates' attribute is
included in the SDP description, RTP_Rx SHALL NOT send updated not included in the SDP description, the RTP_Rx SHALL NOT send
requests. RTP_Rx MAY still repeat its initial request without updated requests. The RTP_Rx MAY still repeat its initial request
changes, though. without changes, though.
8.2. Requirements 8.2. Requirements
The use of SDP to describe the RAMS entities normatively requires the The use of SDP to describe the RAMS entities normatively requires the
support for: support for:
o The SDP grouping framework and flow identification (FID) semantics o The SDP grouping framework and flow identification (FID) semantics
[RFC5888] [RFC5888]
o The RTP/AVPF profile [RFC4585] o The RTP/AVPF profile [RFC4585]
skipping to change at page 37, line 48 skipping to change at page 38, line 43
In this example SDP description, we have a primary multicast (source) In this example SDP description, we have a primary multicast (source)
stream and a unicast retransmission stream. The source stream is stream and a unicast retransmission stream. The source stream is
multicast from a distribution source (with a source IP address of 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 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 port 41000. The corresponding RTCP traffic is multicast to the same
multicast destination address at port 42000. Here, we are assuming multicast destination address at port 42000. Here, we are assuming
that the multicast RTP and RTCP ports are carefully chosen so that that the multicast RTP and RTCP ports are carefully chosen so that
different RTP and RTCP streams do not collide with each other. different RTP and RTCP streams do not collide with each other.
The feedback target (FT_Ap) residing on RS (with an address of 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 192.0.2.1) at port 43000 is declared with the "a=rtcp" line
[RFC3605]. The support for the conventional retransmission is [RFC3605]. The support for the conventional retransmission is
indicated through the "a=rtcp-fb:98 nack" line. The RTP receiver(s) indicated through the "a=rtcp-fb:98 nack" line. The RTP receiver(s)
can report missing packets on the source stream to the feedback can report missing packets on the source stream to the feedback
target and request retransmissions. The SDP above includes the target and request retransmissions. The SDP above includes the
"a=sendonly" line for the media description of the retransmission "a=sendonly" line for the media description of the retransmission
stream since the retransmissions are sent in only one direction. stream since the retransmissions are sent in only one direction.
The support for rapid acquisition is indicated through the "a=rtcp- The support for rapid acquisition is indicated through the "a=rtcp-
fb:98 nack rai" line. The parameter 'rtx-time' applies to both the fb:98 nack rai" line. The parameter 'rtx-time' applies to both the
conventional retransmissions and rapid acquisition. However, when conventional retransmissions and rapid acquisition. However, when
rapid acquisition is enabled, the standard definition for the rapid acquisition is enabled, the standard definition for the
parameter 'rtx-time' given in [RFC4588] is not followed. Instead, parameter 'rtx-time' given in [RFC4588] is not followed. Instead,
when rapid acquisition support is enabled, 'rtx-time' specifies the when rapid acquisition support is enabled, 'rtx-time' specifies the
time in milliseconds that BRS keeps an RTP packet in its cache time in milliseconds that the BRS keeps an RTP packet in its cache
available for retransmission (measured from the time the packet was available for retransmission (measured from the time the packet was
received by BRS, not from the time indicated in the packet received by the BRS, not from the time indicated in the packet
timestamp). timestamp).
Once an RTP_Rx has acquired an SDP description, it can ask for rapid 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 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 so, it sends a RAMS-R message to the feedback target of that primary
multicast RTP session. If FT_Ap is associated with only one RTP multicast RTP session. If the FT_Ap is associated with only one RTP
stream, RTP_Rx does not need to learn the SSRC of that stream via an stream, the RTP_Rx does not need to learn the SSRC of that stream via
out-of-band method. If BRS accepts the rapid acquisition request, it an out-of-band method. If the BRS accepts the rapid acquisition
will send an RAMS-I message with the correct SSRC identifier. If request, it will send an RAMS-I message with the correct SSRC
FT_Ap is associated with a multi-stream RTP session and RTP_Rx is identifier. If the FT_Ap is associated with a multi-stream RTP
willing to request rapid acquisition for the entire session, RTP_Rx session and the RTP_Rx is willing to request rapid acquisition for
again does not need to learn the SSRCs via an out-of-band method. the entire session, the RTP_Rx again does not need to learn the SSRCs
However, if RTP_Rx intends to request a particular subset of the via an out-of-band method. However, if the RTP_Rx intends to request
primary multicast streams, it must learn their SSRC identifiers and a particular subset of the primary multicast streams, it must learn
list them in the RAMS-R message. Since this RTP_Rx has not yet their SSRC identifiers and list them in the RAMS-R message. Since
received any RTP packets for the primary multicast stream(s), RTP_Rx this RTP_Rx has not yet received any RTP packets for the primary
must in this case learn the SSRC value(s) from the 'ssrc' attribute multicast stream(s), the RTP_Rx must in this case learn the SSRC
of the media description [RFC5576]. In addition to the SSRC value, value(s) from the 'ssrc' attribute of the media description
the 'cname' source attribute must also be present in the SDP [RFC5576]. In addition to the SSRC value, the 'cname' source
description [RFC5576]. attribute must also be present in the SDP description [RFC5576].
Listing the SSRC values for the primary multicast streams in the SDP 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 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 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] SSRC collision with a media sender must change its own SSRC [RFC5760]
by following the rules defined in [RFC3550]. by following the rules defined in [RFC3550].
A feedback target that receives a RAMS-R feedback message becomes A feedback target that receives a RAMS-R message becomes aware that
aware that the prediction chain at RTP_Rx side has been broken or the RTP_Rx wants to rapidly catch up with a primary multicast RTP
does not exist anymore. If the necessary conditions are satisfied session. If the necessary conditions are satisfied (as outlined in
(as outlined in Section 7 of [RFC4585]) and available resources Section 7 of [RFC4585]) and available resources exist, the BRS can
exist, BRS can react to the RAMS-R message by sending any transport- react to the RAMS-R message by sending any transport-layer (and
layer (and optional payload-specific, when allowed) feedback optional payload-specific, when allowed) feedback message(s) and
message(s) and starting the unicast burst. starting the unicast burst.
In this section, we considered the simplest scenario where the In this section, we considered the simplest scenario where the
primary multicast RTP session carried only one stream and RTP_Rx primary multicast RTP session carried only one stream and the RTP_Rx
wanted to rapidly acquire this stream only. Best practices for wanted to rapidly acquire this stream only. Best practices for
scenarios where the primary multicast RTP session carries two or more scenarios where the primary multicast RTP session carries two or more
streams or RTP_Rx wants to acquire one or more streams from multiple streams or the RTP_Rx wants to acquire one or more streams from
primary multicast RTP sessions at the same time are presented in multiple primary multicast RTP sessions at the same time are
[I-D.begen-avt-rams-scenarios]. presented in [I-D.begen-avt-rams-scenarios].
9. NAT Considerations 9. NAT Considerations
For a variety of reasons, one or more NAPT devices (hereafter simply For a variety of reasons, one or more NAPT devices (hereafter simply
called NAT) can exist between RTP_Rx and RS. NATs have a variety of called NAT) can exist between the RTP_Rx and RS. NATs have a variety
operating characteristics for UDP traffic [RFC4787]. For a NAT to of operating characteristics for UDP traffic [RFC4787]. For a NAT to
permit traffic from BRS to arrive at RTP_Rx, the NAT(s) must first permit traffic from the BRS to arrive at the RTP_Rx, the NAT(s) must
either: first either:
a. See UDP traffic sent from RTP_Rx (which is on the 'inside' of the a. See UDP traffic sent from the RTP_Rx (which is on the 'inside' of
NAT) to BRS (which is on the 'outside' of the NAT). This traffic the NAT) to the BRS (which is on the 'outside' of the NAT). This
has the same transport address as the subsequent response traffic has the same transport address as the subsequent response
traffic, or; traffic, or;
b. Be configured to forward certain ports (e.g., using HTML b. Be configured to forward certain ports (e.g., using HTML
configuration, UPnP IGD [UPnP-IGD], DLNA [DLNA]). Details of configuration and UPnP IGD [UPnP-IGD]). Details of this are out
this are out of scope of this document. of scope of this document.
For both (a) and (b), RTP_Rx is responsible for maintaining the NAT's For both (a) and (b), the RTP_Rx is responsible for maintaining the
state if it wants to receive traffic from the BRS on that port. For NAT's state if it wants to receive traffic from the BRS on that port.
(a), RTP_Rx MUST send UDP traffic to keep the NAT binding alive, at For (a), the RTP_Rx MUST send UDP traffic to keep the NAT binding
least every 30 seconds [RFC4787]. While (a) is more like an alive, at least every 30 seconds [RFC4787]. While (a) is more like
automatic/dynamic configuration, (b) is more like a manual/static an automatic/dynamic configuration, (b) is more like a manual/static
configuration. configuration.
When RTP_Rx sends a request (RAMS-R) message to FT as unicast 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 feedback in the primary multicast RTP session, and the request is
received by FT, a new unicast burst RTP session will be established received by the FT, a new unicast burst RTP session will be
between BRS and RTP_Rx. established between the BRS and RTP_Rx.
While the FT and BRS ports on RS are already signaled via out-of-band While the FT and BRS ports on the RS are already signaled via out-of-
means (e.g., SDP), RTP_Rx needs to convey the RTP and RTCP ports it band means (e.g., SDP), the RTP_Rx needs to convey the RTP and RTCP
wants to use on its side for the new session. Since there are two ports it wants to use on its side for the new session. Since there
RTP sessions (one multicast and one unicast) involved during this are two RTP sessions (one multicast and one unicast) involved during
process and one of them is established upon a feedback message sent this process and one of them is established upon a feedback message
in the other one, this requires an explicit port mapping method. sent in the other one, this requires an explicit port mapping method.
Applications using RAMS MUST support the solution presented in Applications using RAMS MUST support the solution presented in
[I-D.ietf-avt-ports-for-ucast-mcast-rtp] both on the RS and RTP_Rx [I-D.ietf-avt-ports-for-ucast-mcast-rtp] both on the RS and RTP_Rx
side to allow RTP receivers to use their desired ports and to support side to allow RTP receivers to use their desired ports and to support
RAMS behind NAT devices. The port mapping message exchange needs to RAMS behind NAT devices. The port mapping message exchange needs to
take place whenever RTP_Rx intends to make use of the RAMS protocol take place whenever the RTP_Rx intends to make use of the RAMS
for rapidly acquiring a specific multicast RTP session, prior to protocol for rapidly acquiring a specific multicast RTP session,
joining the associated SSM session. prior to joining the associated SSM session.
10. Security Considerations 10. Security Considerations
Applications that are using RAMS make heavy use of the unicast Applications that are using RAMS make heavy use of the unicast
feedback mechanism described in [RFC5760], the payload format defined feedback mechanism described in [RFC5760], the payload format defined
in [RFC4588] and the port mapping solution specified in in [RFC4588] and the port mapping solution specified in
[I-D.ietf-avt-ports-for-ucast-mcast-rtp]. Thus, these applications [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. Thus, these applications
are subject to the general security considerations discussed in are subject to the general security considerations discussed in
[RFC5760], [RFC4588] and [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. [RFC5760], [RFC4588] and [I-D.ietf-avt-ports-for-ucast-mcast-rtp].
In this section, we give an overview of the guidelines and In this section, we give an overview of the guidelines and
skipping to change at page 45, line 31 skipping to change at page 46, line 17
response codes should be classified following the guidelines below: response codes should be classified following the guidelines below:
Code Level Purpose Code Level Purpose
---------- --------------- ---------- ---------------
1xx Informational 1xx Informational
2xx Success 2xx Success
3xx Redirection 3xx Redirection
4xx RTP Receiver Error 4xx RTP Receiver Error
5xx Retransmission Server Error 5xx Retransmission Server Error
The Response code 65536 is reserved for future use. The Response code 65535 is reserved for future use.
The registry is initialized with the following entries: The registry is initialized with the following entries:
Code Description Reference Code Description Reference
----- -------------------------------------------------- ------------- ----- -------------------------------------------------- -------------
0 A private response code is included in the message [RFCXXXX] 0 A private response code is included in the message [RFCXXXX]
100 Parameter update for RAMS session [RFCXXXX] 100 Parameter update for RAMS session [RFCXXXX]
200 RAMS request has been accepted [RFCXXXX] 200 RAMS request has been accepted [RFCXXXX]
skipping to change at page 48, line 36 skipping to change at page 49, line 36
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009. and Consequences", RFC 5506, April 2009.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008. Header Extensions", RFC 5285, July 2008.
[I-D.ietf-avt-rapid-rtp-sync] [I-D.ietf-avt-rapid-rtp-sync]
Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", draft-ietf-avt-rapid-rtp-sync-11 (work in Flows", draft-ietf-avt-rapid-rtp-sync-12 (work in
progress), May 2010. progress), July 2010.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[I-D.ietf-avt-rtcp-port-for-ssm] [I-D.ietf-avt-rtcp-port-for-ssm]
Begen, A., "RTP Control Protocol (RTCP) Port for Multicast Begen, A., "RTP Control Protocol (RTCP) Port for Source-
Sessions", draft-ietf-avt-rtcp-port-for-ssm-00 (work in Specific Multicast (SSM) Sessions",
progress), June 2010. draft-ietf-avt-rtcp-port-for-ssm-01 (work in progress),
August 2010.
[I-D.ietf-avt-ports-for-ucast-mcast-rtp] [I-D.ietf-avt-ports-for-ucast-mcast-rtp]
Begen, A. and B. Steeg, "Port Mapping Between Unicast and Begen, A. and B. Steeg, "Port Mapping Between Unicast and
Multicast RTP Sessions", Multicast RTP Sessions",
draft-ietf-avt-ports-for-ucast-mcast-rtp-02 (work in draft-ietf-avt-ports-for-ucast-mcast-rtp-02 (work in
progress), May 2010. progress), May 2010.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
skipping to change at page 49, line 46 skipping to change at page 50, line 47
[I-D.ietf-avt-multicast-acq-rtcp-xr] [I-D.ietf-avt-multicast-acq-rtcp-xr]
Begen, A. and E. Friedrich, "Multicast Acquisition Report Begen, A. and E. Friedrich, "Multicast Acquisition Report
Block Type for RTP Control Protocol (RTCP) Extended Block Type for RTP Control Protocol (RTCP) Extended
Reports (XRs)", draft-ietf-avt-multicast-acq-rtcp-xr-01 Reports (XRs)", draft-ietf-avt-multicast-acq-rtcp-xr-01
(work in progress), May 2010. (work in progress), May 2010.
[I-D.ietf-avt-ecn-for-rtp] [I-D.ietf-avt-ecn-for-rtp]
Westerlund, M., Johansson, I., Perkins, C., and K. Westerlund, M., Johansson, I., Perkins, C., and K.
Carlberg, "Explicit Congestion Notification (ECN) for RTP Carlberg, "Explicit Congestion Notification (ECN) for RTP
over UDP", draft-ietf-avt-ecn-for-rtp-01 (work in over UDP", draft-ietf-avt-ecn-for-rtp-02 (work in
progress), March 2010. progress), July 2010.
[I-D.ietf-fecframe-interleaved-fec-scheme] [I-D.ietf-fecframe-interleaved-fec-scheme]
Begen, A., "RTP Payload Format for 1-D Interleaved Parity Begen, A., "RTP Payload Format for 1-D Interleaved Parity
FEC", draft-ietf-fecframe-interleaved-fec-scheme-09 (work FEC", draft-ietf-fecframe-interleaved-fec-scheme-09 (work
in progress), January 2010. in progress), January 2010.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC5762] Perkins, C., "RTP and the Datagram Congestion Control [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control
Protocol (DCCP)", RFC 5762, April 2010. Protocol (DCCP)", RFC 5762, April 2010.
[I-D.ietf-avt-srtp-ekt] [I-D.ietf-avt-srtp-ekt]
McGrew, D., Andreasen, F., Wing, D., and L. Dondeti, McGrew, D., Andreasen, F., Wing, D., and K. Fischer,
"Encrypted Key Transport for Secure RTP", "Encrypted Key Transport for Secure RTP",
draft-ietf-avt-srtp-ekt-00 (work in progress), March 2010. draft-ietf-avt-srtp-ekt-01 (work in progress), July 2010.
[UPnP-IGD] [UPnP-IGD]
Forum, UPnP., "Universal Plug and Play (UPnP) Internet Forum, UPnP., "Universal Plug and Play (UPnP) Internet
Gateway Device (IGD)", November 2001. Gateway Device (IGD)", November 2001.
[DLNA] , DLNA., "http://www.dlna.org/home".
[IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing [IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing
Channel Change Times in IPTV with Real-Time Transport Channel Change Times in IPTV with Real-Time Transport
Protocol (IEEE Internet Computing)", May 2009. Protocol (IEEE Internet Computing)", May 2009.
Authors' Addresses Authors' Addresses
Bill VerSteeg Bill VerSteeg
Cisco Cisco
5030 Sugarloaf Parkway 5030 Sugarloaf Parkway
Lawrenceville, GA 30044 Lawrenceville, GA 30044
 End of changes. 155 change blocks. 
598 lines changed or deleted 618 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/