draft-ietf-avt-rapid-acquisition-for-rtp-17.txt   rfc6285.txt 
AVT B. VerSteeg Internet Engineering Task Force (IETF) B. Ver Steeg
Internet-Draft A. Begen Request for Comments: 6285 A. Begen
Intended status: Standards Track Cisco Category: Standards Track Cisco
Expires: May 22, 2011 T. VanCaenegem ISSN: 2070-1721 T. Van Caenegem
Alcatel-Lucent Alcatel-Lucent
Z. Vax Z. Vax
Microsoft Corporation Magnum Semiconductor
November 18, 2010 June 2011
Unicast-Based Rapid Acquisition of Multicast RTP Sessions Unicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-ietf-avt-rapid-acquisition-for-rtp-17
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, and the application and
application and transport properties, the time lag before an RTP transport properties, the time lag before an RTP receiver can
receiver can usefully consume the multicast data, which we refer to usefully consume the multicast data, which we refer to as the
as the Acquisition Delay, varies and can be large. This is an Acquisition Delay, varies and can be large. This is an undesirable
undesirable phenomenon for receivers that frequently switch among phenomenon for receivers that frequently switch among different
different multicast sessions, such as video broadcasts. multicast sessions, such as video broadcasts.
In this document, we describe a method using the existing RTP and RTP In this document, we describe a method using the existing RTP and RTP
Control Protocol (RTCP) machinery that reduces the acquisition delay. Control Protocol (RTCP) machinery that reduces the acquisition delay.
In this method, an auxiliary unicast RTP session carrying the In this method, an auxiliary unicast RTP session carrying the
Reference Information to the receiver precedes/accompanies the Reference Information to the receiver precedes or accompanies the
multicast stream. This unicast RTP flow can be transmitted at a multicast stream. This unicast RTP flow can be transmitted at a
faster than natural bitrate to further accelerate the acquisition. faster than natural bitrate to further accelerate the acquisition.
The motivating use case for this capability is multicast applications The motivating use case for this capability is multicast applications
that carry real-time compressed audio and video. However, this that carry real-time compressed audio and video. However, this
method can also be used in other types of multicast applications method can also be used in other types of multicast applications
where the acquisition delay is long enough to be a problem. where the acquisition delay is long enough to be a problem.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on May 22, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6285.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 2, line 38
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Acquisition of RTP Streams vs. RTP Sessions . . . . . . . 7 1.1. Acquisition of RTP Streams vs. RTP Sessions . . . . . . . 6
1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Elements of Delay in Multicast Applications . . . . . . . . . 9 4. Elements of Delay in Multicast Applications . . . . . . . . . 8
5. Protocol Design Considerations and Their Effect on 5. Protocol Design Considerations and Their Effect on
Resource Management for Rapid Acquisition . . . . . . . . . . 10 Resource Management for Rapid Acquisition . . . . . . . . . . 10
6. Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . 13 6. Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . 12
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Synchronization of Primary Multicast Streams . . . . . . . 24 6.3. Synchronization of Primary Multicast Streams . . . . . . . 24
6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 24 6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 25
6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27 6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 28 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 28
7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 29 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 30 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 30
7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 30 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 30
7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 31 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 31
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 34 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 34
7.3.1. Response Code Definitions . . . . . . . . . . . . . . 37 7.3.1. Response Code Definitions . . . . . . . . . . . . . . 37
7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 38 7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 39
8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 40 8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 40
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 40 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 40
8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 40 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 41
8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 41 8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 41
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 44 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 44
10. Security Considerations . . . . . . . . . . . . . . . . . . . 45 10. Security Considerations . . . . . . . . . . . . . . . . . . . 45
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 48 11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 48
11.2. Registration of SDP Attribute Values . . . . . . . . . . . 48 11.2. Registration of SDP Attribute Values . . . . . . . . . . . 48
11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 48 11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 48
11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 49 11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 48
11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 49 11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 49
11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 50 11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 50
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 52
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.1. Normative References . . . . . . . . . . . . . . . . . . . 53 14.1. Normative References . . . . . . . . . . . . . . . . . . . 52
14.2. Informative References . . . . . . . . . . . . . . . . . . 55 14.2. Informative References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
Most multicast flows carry a stream of inter-related data. Receivers Most multicast flows carry a stream of inter-related data. Receivers
need to acquire certain information to start processing any data sent need to acquire certain information to start processing any data sent
in the multicast session. This document refers to this information in the multicast session. This document refers to this information
as Reference Information. The Reference Information is 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
to which data to process, encryption information including keys, as to which data to process, encryption information including keys, and
well as any other information required to process the data in the any other information required to process the data in the multicast
multicast stream [IC2009]. stream [IC2009].
Real-time multicast applications require receivers to buffer data. Real-time multicast applications require receivers to buffer data.
Receivers may have to buffer data to smooth out the network jitter, Receivers may have to buffer data to smooth out the network jitter,
to allow loss-repair methods such as Forward Error Correction and to allow loss-repair methods such as Forward Error Correction and
retransmission to recover the missing packets, and to satisfy the retransmission to recover the missing packets, and to satisfy the
data processing requirements of the application layer. data-processing requirements of the application layer.
When a receiver joins a multicast session, it has no control over When a receiver joins a multicast session, it has no control over
what point in the flow is currently being transmitted. Sometimes the what point in the flow is currently being transmitted. Sometimes the
receiver might join the session right before the Reference receiver might join the session right before the Reference
Information is sent in the session. In this case, the required Information is sent in the session. In this case, the required
waiting time is usually minimal. Other times, the receiver might waiting time is usually minimal. Other times, the receiver might
join the session right after the Reference Information has been join the session right after the Reference Information has been
transmitted. In this case, the receiver has to wait for the transmitted. In this case, the receiver has to wait for the
Reference Information to appear again in the flow before it can start Reference Information to appear again in the flow before it can start
processing any multicast data. In some other cases, the Reference processing any multicast data. In some other cases, the Reference
skipping to change at page 4, line 46 skipping to change at page 4, line 23
data. data.
The net effect of waiting for the Reference Information and waiting The net effect of waiting for the Reference Information and waiting
for various buffers to fill up is that receivers can experience for various buffers to fill up is that receivers can experience
significantly large delays in data processing. In this document, we significantly large delays in data processing. In this document, we
refer to the difference between the time an RTP receiver wants to refer to the difference between the time an RTP receiver wants to
join the multicast session and the time the RTP receiver acquires all join the multicast session and the time the RTP receiver acquires all
the necessary Reference Information as the Acquisition Delay. The 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, and 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. While receivers that frequently switch among multicast sessions. While
this problem equally applies to both any-source (ASM) and source- this problem equally applies to both any-source multicast (ASM) and
specific (SSM) multicast applications, in this specification we source-specific multicast (SSM) applications, in this specification
address it for the SSM-based multicast applications by describing a we address it for the SSM-based applications by describing a method
method that uses the fundamental tools offered by the existing RTP that uses the fundamental tools offered by the existing RTP and RTCP
and RTCP protocols [RFC3550]. In this method, either the multicast protocols [RFC3550]. In this method, either the multicast source (or
source (or the distribution source in an SSM session) retains the the distribution source in an SSM session) retains the Reference
Reference Information for a period after its transmission, or an Information for a period after its transmission, or an intermediary
intermediary network element (that we refer to as Retransmission network element (that we refer to as Retransmission Server) joins the
Server) joins the multicast session and continuously caches the multicast session and continuously caches the Reference Information
Reference Information as it is sent in the session and acts as a as it is sent in the session and acts as a feedback target (see
feedback target (See [RFC5760]) for the session. When an RTP [RFC5760]) for the session. When an RTP receiver wishes to join the
receiver wishes to join the same multicast session, instead of simply same multicast session, instead of simply issuing a Source Filtering
issuing a Source Filtering Group Management Protocol (SFGMP) Join Group Management Protocol (SFGMP) Join message, it sends a request to
message, it sends a request to the feedback target for the session the feedback target for the session and asks for the Reference
and asks for the Reference Information. The retransmission server Information. The retransmission server starts a new unicast RTP
starts a new unicast RTP (retransmission) session and sends the (retransmission) session and sends the Reference Information to the
Reference Information to the RTP receiver over that session. If RTP receiver over that session. If there is residual bandwidth, the
there is residual bandwidth, the retransmission server might burst retransmission server might burst the Reference Information faster
the Reference Information faster than its natural rate. As soon as than its natural rate. As soon as the receiver acquires the
the receiver acquires the Reference Information, it can join the Reference Information, it can join the multicast session and start
multicast session and start processing the multicast data. A processing the multicast data. A simplified network diagram showing
simplified network diagram showing this method through an this method through an intermediary network element is depicted in
intermediary network element is depicted in Figure 1. 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 |
| | Network Element | | | Network Element |
| ...|(Retransmission Server)| | ...|(Retransmission Server)|
| : ----------------------- | : -----------------------
skipping to change at page 6, line 27 skipping to change at page 5, line 34
| |
| ---------- | ----------
+---------------->| Existing | +---------------->| Existing |
| RTP | | RTP |
| Receiver | | Receiver |
---------- ----------
-------> Multicast RTP Flow -------> Multicast RTP Flow
.......> Unicast RTP Flow .......> Unicast RTP Flow
Figure 1: Rapid acquisition through an intermediary network element Figure 1: Rapid Acquisition through an Intermediary Network Element
A principle design goal in this solution is to use the existing tools A principle design goal in this solution is to use the existing tools
in the RTP/RTCP protocol family. This improves the versatility of in the RTP/RTCP protocol family. This improves the versatility of
the existing implementations, and promotes faster deployment and the existing implementations and promotes faster deployment and
better interoperability. To this effect, we use the unicast better interoperability. To this effect, we use the unicast
retransmission support of RTP [RFC4588] and the capabilities of RTCP retransmission support of RTP [RFC4588] and the capabilities of RTCP
to handle the signaling needed to accomplish the acquisition. to handle the signaling needed to accomplish the acquisition.
A reasonable effort has been made in this specification to design a A reasonable effort has been made in this specification to design a
solution that reliably works in both engineered and best-effort solution that reliably works in both engineered and best-effort
networks. However, a proper congestion control combined with the networks. However, a proper congestion control combined with the
desired behavior of this solution is difficult to achieve. Rather, desired behavior of this solution is difficult to achieve. Rather,
this solution has been designed based on an assumption that the this solution has been designed based on the assumption that the
retransmission server and the RTP receivers have some knowledge about retransmission server and the RTP receivers have some knowledge about
where the bottleneck between them is. This assumption does not where the bottleneck between them is. This assumption does not
generally hold unless both the retransmission server and the RTP generally hold unless both the retransmission server and the RTP
receivers are in the same edge network. Thus, this solution should receivers are in the same edge network. Thus, this solution should
not be used across any best-effort path of the Internet. not be used across any best-effort path of the Internet.
Furthermore, this solution should only be used in networks that are Furthermore, this solution should only be used in networks that are
already carrying non-congestion-responsive multicast traffic and have already carrying non-congestion-responsive multicast traffic and have
throttling mechanisms in the retransmission servers to ensure the throttling mechanisms in the retransmission servers to ensure the
(unicast) burst traffic is a known constant upper-bound multiplier on (unicast) burst traffic is a known constant upper-bound multiplier on
the multicast load. the multicast load.
1.1. Acquisition of RTP Streams vs. RTP Sessions 1.1. Acquisition of RTP Streams vs. RTP Sessions
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 a 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, the RTP receiver can request the rapid session. Alternatively, the RTP receiver can request the rapid
acquisition of all of the RTP streams in that RTP session. acquisition of all of the RTP streams in that RTP session.
skipping to change at page 7, line 34 skipping to change at page 6, line 40
different RTP sessions in a single instance of the rapid acquisition different RTP sessions in a single instance of the rapid acquisition
protocol: (i) the primary multicast RTP session with its associated protocol: (i) the primary multicast RTP session with its associated
unicast 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 The rest of this specification is as follows. Section 3 provides a
list of the definitions frequently used in this document. In
Section 4, we describe the delay components in generic multicast 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
considerations for rapid acquisition. We provide the protocol considerations for rapid acquisition. We provide the protocol
details of the rapid acquisition method in Section 6 and Section 7. details of the rapid acquisition method in Sections 6 and 7.
Section 8 and Section 9 discuss the SDP signaling issues with Sections 8 and 9 discuss the Session Description Protocol (SDP)
examples and NAT-related issues, respectively. Finally, Section 10 signaling issues with examples and NAT-related issues, respectively.
discusses the security considerations. Finally, Section 10 discusses the security considerations, and
Section 11 details the IANA considerations.
Section 3 provides a list of the definitions frequently used in this
document.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Definitions 3. Definitions
This document uses the following acronyms and definitions frequently: This document uses the following acronyms and definitions frequently:
(Primary) SSM (or Multicast) Session: The multicast session to which (Primary) SSM Session: The multicast session to which RTP receivers
RTP receivers can join at a random point in time. A primary SSM can join at a random point in time. A primary SSM session can carry
session can carry multiple RTP streams. multiple RTP streams.
Primary Multicast RTP Session: The multicast RTP session an RTP Primary Multicast RTP Session: The multicast RTP session an RTP
receiver is interested in acquiring rapidly. From the RTP receiver's receiver is interested in acquiring rapidly. From the RTP receiver's
viewpoint, the primary multicast RTP session has one associated viewpoint, the primary multicast RTP session has one associated
unicast RTCP feedback stream to a Feedback Target, in addition to the unicast RTCP feedback stream to a Feedback Target, in addition to the
primary multicast RTP stream(s). primary multicast RTP stream(s).
Primary Multicast (RTP) Streams: The RTP stream(s) carried in the Primary Multicast (RTP) Streams: The RTP stream(s) carried in the
primary multicast RTP session. primary multicast RTP session.
skipping to change at page 8, line 43 skipping to change at page 7, line 49
[RFC5760]. FT_Ap denotes a specific feedback target running on a [RFC5760]. FT_Ap denotes a specific feedback target running on a
particular address and port. particular address and port.
Retransmission (or Burst) Packet: An RTP packet that is formatted as Retransmission (or Burst) Packet: An RTP packet that is formatted as
defined in Section 4 of [RFC4588]. The payload of a retransmission defined in Section 4 of [RFC4588]. The payload of a retransmission
or burst packet comprises the retransmission payload header followed or burst packet comprises the retransmission payload header followed
by the payload of the original RTP packet. by the payload of the original RTP packet.
Reference Information: The set of certain media content and metadata Reference Information: The set of certain media content and metadata
information that is sufficient for an RTP receiver to start usefully information that is sufficient for an RTP receiver to start usefully
consuming a media stream. The meaning, format and size of this consuming a media stream. The meaning, format, and size of this
information are specific to the application and are out of scope of information are specific to the application and are out of the scope
this document. of this document.
Preamble Information: A more compact form of the whole or a subset Preamble Information: A more compact form of the whole or a subset
of the Reference Information transmitted out-of-band. of the Reference Information transmitted out-of-band.
(Unicast) Burst (or Retransmission) RTP Session: The unicast RTP (Unicast) Burst (or Retransmission) RTP Session: The unicast RTP
session used to send one or more unicast burst RTP streams and their session used to send one or more unicast burst RTP streams and their
associated RTCP messages. The terms "burst RTP session" and associated RTCP messages. The terms "burst RTP session" and
"retransmission RTP session" can be used interchangeably. "retransmission RTP session" can be used interchangeably.
(Unicast) Burst (Stream): A unicast stream of RTP retransmission (Unicast) Burst (Stream): A unicast stream of RTP retransmission
skipping to change at page 9, line 21 skipping to change at page 8, line 28
session-multiplexing guidelines in [RFC4588], each unicast burst session-multiplexing guidelines in [RFC4588], each unicast burst
stream will use the same SSRC and Canonical Name (CNAME) as its stream will use the same SSRC and Canonical Name (CNAME) as its
primary multicast RTP stream. primary multicast RTP 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. The 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 multicast (SSM) delivery system, there are three
major elements that contribute to the acquisition delay when an RTP major elements that contribute to the acquisition delay when an RTP
receiver switches from one multicast session to another one. These receiver switches from one multicast session to another one. These
are: are:
o Multicast switching delay o Multicast-switching delay
o Reference Information latency o Reference Information latency
o Buffering delays o Buffering delays
Multicast switching delay is the delay that is experienced to leave Multicast-switching delay is the delay that is experienced when
the current multicast session (if any) and join the new multicast leaving the current multicast session (if any) and joining the new
session. In typical systems, the multicast join and leave operations multicast session. In typical systems, the multicast join and leave
are handled by a group management protocol. For example, the operations are handled by a group management protocol. For example,
receivers and routers participating in a multicast session can use the receivers and routers participating in a multicast session can
the Internet Group Management Protocol (IGMP) version 3 [RFC3376] or use the Internet Group Management Protocol (IGMP) version 3 [RFC3376]
the Multicast Listener Discovery Protocol (MLD) version 2 [RFC3810]. or the Multicast Listener Discovery Protocol (MLD) version 2
In either of these protocols, when a receiver wants to join a [RFC3810]. In either of these protocols, when a receiver wants to
multicast session, it sends a message to its upstream router and the join a multicast session, it sends a message to its upstream router
routing infrastructure sets up the multicast forwarding state to and the routing infrastructure sets up the multicast forwarding state
deliver the packets of the multicast session to the new receiver. to deliver the packets of the multicast session to the new receiver.
Depending on the proximity of the upstream router, the current state The join times vary depending on the proximity of the upstream
of the multicast tree, the load on the system and the protocol router, the current state of the multicast tree, the load on the
implementation, the join times vary. Current systems provide join system, and the protocol implementation. Current systems provide
latencies usually less than 200 milliseconds (ms). If the receiver join latencies, usually less than 200 milliseconds (ms). If the
had been participating in another multicast session before joining receiver had been participating in another multicast session before
the new session, it needs to send a Leave message to its upstream joining the new session, it needs to send a Leave message to its
router to leave the session. In common multicast routing protocols, upstream router to leave the session. In common multicast routing
the leave times are usually smaller than the join times, however, it protocols, the leave times are usually smaller than the join times;
is possible that the Leave and Join messages might get lost, in which however, it is possible that the Leave and Join messages might get
case the multicast switching delay inevitably increases. lost, in which case the multicast-switching delay inevitably
increases.
Reference Information latency is the time it takes the receiver to Reference Information latency is the time it takes the receiver to
acquire the Reference Information. It is highly dependent on the acquire the Reference Information. It is highly dependent on the
proximity of the actual time the receiver joined the session to the proximity of the actual time the receiver joined the session to the
next time the Reference Information will be sent to the receivers in next time the Reference Information will be sent to the receivers in
the session, whether the Reference Information is sent contiguously the session, whether or not the Reference Information is sent
or not, and the size of the Reference Information. For some contiguously, and the size of the Reference Information. For some
multicast flows, there is a little or no interdependency in the data, multicast flows, there is a little or no interdependency in the data,
in which case the Reference Information latency will be nil or in which case the Reference Information latency will be nil or
negligible. For other multicast flows, there is a high degree of negligible. For other multicast flows, there is a high degree of
interdependency. One example of interest is the multicast flows that interdependency. One example of interest is the multicast flows that
carry compressed audio/video. For these flows, the Reference carry compressed audio/video. For these flows, the Reference
Information latency can become quite large and be a major contributor Information latency can become quite large and be a major contributor
to the overall delay. to the overall delay.
The buffering component of the overall acquisition delay is driven by The buffering component of the overall acquisition delay is driven by
the way the application layer processes the payload. In many the way the application layer processes the payload. In many
skipping to change at page 10, line 34 skipping to change at page 9, line 40
[RFC0768] is often used to transmit the data packets, and the [RFC0768] is often used to transmit the data packets, and the
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., [RFC6015]) and retransmission. as Forward Error Correction (e.g., [RFC6015]) 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 up to a few seconds, of coded video data to be a certain amount, sometimes up to a few seconds, of coded video data
available in the pre-decoding buffers prior to starting to decode the to be available in the pre-decoding buffers prior to starting to
video bitstream. decode the 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., Quality of Service (QoS)
management, etc). In particular, the system needs to operate within machinery, server load management, etc). In particular, the system
a number of constraints: needs to operate within 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 be not significantly worse for trying and user experience must not be significantly worse for trying and
failing to complete rapid acquisition compared to simply joining failing to complete rapid acquisition compared to simply joining
the multicast session. the 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 and addition, it must also avoid interference with other multicast and
non-multicast sessions sharing the same network resources. These non-multicast sessions sharing the same network resources. These
properties are possible, but are usually difficult to achieve. properties are possible but are usually difficult to achieve.
One challenge is the existence of multiple bandwidth bottlenecks One challenge is the existence of multiple bandwidth bottlenecks
between the receiver and the server(s) in the network providing the between the receiver and the server(s) in the network providing the
rapid acquisition service. In commercial IPTV deployments, for rapid acquisition service. In commercial IPTV deployments, for
example, bottlenecks are often present in the aggregation network example, bottlenecks are often present in the aggregation network
connecting the IPTV servers to the network edge, the access links connecting the IPTV servers to the network edge, the access links
(e.g., DSL, DOCSIS) and in the home network of the subscribers. Some (e.g., DSL, Data Over Cable Service Interface Specification
of these links might serve only a single subscriber, limiting (DOCSIS)), and the home network of the subscribers. Some of these
congestion impact to the traffic of only that subscriber, but others links might serve only a single subscriber, limiting congestion
can be shared links carrying multicast sessions of many subscribers. impact to the traffic of only that subscriber, but others can be
Also note that the state of these links can vary over time. The shared links carrying multicast sessions of many subscribers. Also
receiver might have knowledge of a portion of this network, or might note that the state of these links can vary over time. The receiver
have partial knowledge of the entire network. The methods employed might have knowledge of a portion of this network or might have
by the devices to acquire this network state information is out of partial knowledge of the entire network. The methods employed by the
scope for this document. The receiver should be able to signal the devices to acquire this network state information is out of the scope
server with the bandwidth that it believes it can handle. The server of this document. The receiver should be able to signal the server
also needs to be able to rate limit the flow in order to stay within with the bandwidth that it believes it can handle. The server also
the performance envelope that it knows about. Both the server and needs to be able to rate limit the flow in order to stay within the
performance envelope that it knows about. Both the server and
receiver need to be able to inform the other of changes in the receiver need to be able to inform the other of changes in the
requested and delivered rates. However, the protocol must be robust requested and delivered rates. However, the protocol must be robust
in the presence of packet loss, so this signaling must include the in the presence of packet loss, so this signaling must include the
appropriate default behaviors. appropriate default behaviors.
A second challenge is that for some uses (e.g., high-bitrate video) A second challenge is that for some uses (e.g., high-bitrate video)
the unicast burst bitrate is high while the flow duration of the the unicast burst bitrate is high while the flow duration of the
unicast burst is short. This is because the purpose of the unicast unicast burst is short. This is because the purpose of the unicast
burst is to allow the RTP receiver to join the multicast quickly and burst is to allow the RTP receiver to join the multicast quickly and
thereby limit the overall resources consumed by the burst. Such thereby limit the overall resources consumed by the burst. Such
high-bitrate, short-duration flows are not amenable to conventional high-bitrate, short-duration flows are not amenable to conventional
admission control techniques. For example, end-to-end per-flow admission-control techniques. For example, end-to-end per-flow
signaled admission control techniques such as RSVP have too much signaled admission-control techniques such as Resource Reservation
latency and control channel overhead to be a good fit for rapid Protocol (RSVP) have too much latency and control channel overhead to
acquisition. Similarly, using a TCP (or TCP-like) approach with a be a good fit for rapid acquisition. Similarly, using a TCP (or TCP-
3-way handshake and slow-start to avoid inducing congestion would like) approach with a 3-way handshake and slow-start to avoid
defeat the purpose of attempting rapid acquisition in the first place inducing congestion would defeat the purpose of attempting rapid
by introducing many round-trip times (RTT) of delay. acquisition in the first place by introducing many round-trip times
(RTTs) of delay.
These observations lead to certain unavoidable requirements and goals These observations lead to certain unavoidable requirements and goals
for a rapid acquisition protocol. These are: for a rapid acquisition protocol. These are:
o The protocol must be designed to allow a deterministic upper bound o The protocol must be designed to allow a deterministic upper bound
on the extra bandwidth used (compared to just joining the on the extra bandwidth used (compared to just joining the
multicast session). A reasonable size bound is e*B, where B is multicast session). A reasonable size bound is e*B, where B is
the nominal bandwidth of the primary multicast streams, and e is the nominal bandwidth of the primary multicast streams and e is an
an excess-bandwidth coefficient. The total duration of the excess-bandwidth coefficient. The total duration of the unicast
unicast burst must have a reasonable bound; long unicast bursts burst must have a reasonable bound; long unicast bursts devolve to
devolve to the bandwidth profile of multi-unicast for the whole the bandwidth profile of multi-unicast for the whole system.
system.
o The scheme should minimize (or better eliminate) the overlap of o The scheme should minimize (or better eliminate) the overlap of
the unicast burst and the primary multicast stream. This the unicast burst and the primary multicast stream. This
minimizes the window during which congestion could be induced on a minimizes the window during which congestion could be induced on a
bottleneck link compared to just carrying the multicast or unicast bottleneck link compared to just carrying the multicast or unicast
packets alone. packets alone.
o The scheme must minimize (or better eliminate) any gap between the o The scheme must minimize (or better eliminate) any gap between the
unicast burst and the primary multicast stream, which has to be unicast burst and the primary multicast stream, which has to be
repaired later, or in the absence of repair, will result in loss repaired later or, in the absence of repair, will result in loss
being experienced by the application. being experienced by the application.
In addition to the above, there are some other protocol design issues In addition to the above, there are some other protocol design issues
to be considered. First, there is at least one RTT of "slop" in the to be considered. First, there is at least one RTT of "slop" in the
control loop. In starting a rapid acquisition burst, this manifests control loop. In starting a rapid acquisition burst, this manifests
as the time between the client requesting the unicast burst and the as the time between the client requesting the unicast burst and the
burst description and/or the first unicast burst packets arriving at burst description and/or the first unicast burst packets arriving at
the receiver. For managing and terminating the unicast burst, there the receiver. For managing and terminating the unicast burst, there
are two possible approaches for the control loop: The receiver can are two possible approaches for the control loop. First, the
adapt to the unicast burst as received, converge based on observation receiver can adapt to the unicast burst as received, converge based
and explicitly terminate the unicast burst with a second control loop on observation, and explicitly terminate the unicast burst with a
exchange (which takes a minimum of one RTT, just as starting the second control loop exchange (which takes a minimum of one RTT, just
unicast burst does). Alternatively, the server generating the as starting the unicast burst does). Alternatively, the server
unicast burst can pre-compute the burst parameters based on the generating the unicast burst can precompute the burst parameters
information in the initial request and tell the receiver the burst based on the information in the initial request and tell the receiver
duration. the burst duration.
The protocol described in the next section allows either method of The protocol described in the next section allows either method of
controlling the rapid acquisition unicast burst. controlling the rapid acquisition unicast burst.
6. Rapid Acquisition of Multicast RTP Sessions (RAMS) 6. Rapid Acquisition of Multicast RTP Sessions (RAMS)
We start this section with an overview of the rapid acquisition of We start this section with an overview of the Rapid Acquisition of
multicast sessions (RAMS) method. Multicast RTP Sessions (RAMS) method.
6.1. Overview 6.1. Overview
[RFC5760] specifies an extension to the RTP Control Protocol (RTCP) [RFC5760] specifies an extension to the RTP Control Protocol (RTCP)
to use unicast feedback in an SSM session. It defines an to use unicast feedback in an SSM session. It defines an
architecture that introduces the concept of Distribution Source, architecture that introduces the concept of Distribution Source,
which - in an SSM context - distributes the RTP data and which, in an SSM context, distributes the RTP data and redistributes
redistributes RTCP information to all RTP receivers. This RTCP RTCP information to all RTP receivers. This RTCP information is
information is retrieved from the Feedback Target, to which RTCP retrieved from the Feedback Target, to which RTCP unicast feedback
unicast feedback traffic is sent. One or more entities different traffic is sent. One or more entities different from the
from the Distribution Source MAY implement the feedback target Distribution Source MAY implement the feedback target functionality,
functionality, and different RTP receivers MAY use different feedback and different RTP receivers MAY use different feedback targets.
targets.
This document builds further on these concepts to reduce the This document builds further on these concepts to reduce the
acquisition delay when an RTP receiver joins a multicast session at a acquisition delay when an RTP receiver joins a multicast session at a
random point in time by introducing the concept of the Burst Source random point in time by introducing the concept of the Burst Source
and new RTCP feedback messages. The Burst Source has a cache where and new RTCP feedback messages. The Burst Source has a cache where
the most recent packets from the primary multicast RTP session are the most recent packets from the primary multicast RTP session are
continuously stored. When an RTP receiver wants to receive a primary continuously stored. When an RTP receiver wants to receive a primary
multicast stream, it can first request a unicast burst from the Burst multicast stream, it can first request a unicast burst from the Burst
Source before it joins the SSM session. In this burst, the packets Source before it joins the SSM session. In this burst, the packets
are formatted as RTP retransmission packets [RFC4588] and carry are formatted as RTP retransmission packets [RFC4588] and carry
skipping to change at page 13, line 43 skipping to change at page 13, line 6
start usefully consuming the RTP packets sent in the primary start usefully consuming the RTP packets sent in the primary
multicast RTP session. multicast RTP session.
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 RTP Sessions
(RAMS).
This document defines 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 As shown in Figure 2, the main entities involved in rapid acquisition
the message flows. They are and the message flows are:
o Multicast Source o Multicast Source
o Feedback Target (FT) o Feedback Target (FT)
o Burst/Retransmission Source (BRS) o Burst/Retransmission Source (BRS)
o RTP Receiver (RTP_Rx) o RTP Receiver (RTP_Rx)
----------- -------------- ----------- --------------
| |------------------------------------>| | | |------------------------------------>| |
| |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| | | |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| |
| | | | | | | |
| Multicast | ---------------- | | | Multicast | ---------------- | |
| Source | | Retransmission | | | | Source | | Retransmission | | |
| |-------->| Server (RS) | | | | |-------->| Server (RS) | | |
| |.-.-.-.->| | | | | |.-.-.-.->| | | |
| | | ------------ | | | | | | ------------ | | |
----------- | | Feedback | |<.=.=.=.=.| | ----------- | | Feedback | |<.=.=.=.=.| |
skipping to change at page 14, line 30 skipping to change at page 14, line 22
| | | ------------ | | | | | | ------------ | | |
----------- | | Feedback | |<.=.=.=.=.| | ----------- | | Feedback | |<.=.=.=.=.| |
| | Target (FT)| |<~~~~~~~~~| RTP Receiver | | | Target (FT)| |<~~~~~~~~~| RTP Receiver |
PRIMARY MULTICAST | ------------ | | (RTP_Rx) | PRIMARY MULTICAST | ------------ | | (RTP_Rx) |
RTP SESSION with | | | | RTP SESSION with | | | |
UNICAST FEEDBACK | | | | UNICAST FEEDBACK | | | |
| | | | | | | |
- - - - - - - - - - - |- - - - - - - - |- - - - - |- - - - - - - |- - - - - - - - - - - - - |- - - - - - - - |- - - - - |- - - - - - - |- -
| | | | | | | |
UNICAST BURST | ------------ | | | UNICAST BURST | ------------ | | |
(or RETRANSMISSION) | | Burst and | |<~~~~~~~~>| | (or RETRANSMISSION) | | Burst/ | |<~~~~~~~~>| |
RTP SESSION | | Retrans. | |.........>| | RTP SESSION | | Retrans. | |.........>| |
| |Source (BRS)| |<.=.=.=.=>| | | |Source (BRS)| |<.=.=.=.=>| |
| ------------ | | | | ------------ | | |
| | | | | | | |
---------------- -------------- ---------------- --------------
-------> 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 As defined in [RFC5760], the feedback target (FT) is the entity to
which the RTP_Rx sends its RTCP feedback messages indicating packet which the RTP_Rx sends its RTCP feedback messages indicating packet
loss by means of an RTCP NACK message or indicating RTP_Rx's desire loss by means of an RTCP NACK message or indicating RTP_Rx's desire
to rapidly acquire the primary multicast RTP session by means of an to rapidly acquire the primary multicast RTP session by means of an
RTCP 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 the RTP_Rx in the case messages and for further RTCP interaction with the RTP_Rx in the case
of a rapid acquisition process, it is assumed in the remainder of the of a rapid acquisition process, it is assumed in the remainder of
document that these two logical entities (FT and BRS) are combined in this document that these two logical entities (FT and BRS) are
a single physical entity and they share state. In the remainder of combined in a single physical entity and they share state. In the
the text, the term Retransmission Server (RS) is used whenever remainder of the text, the term Retransmission Server (RS) is used
appropriate, to refer to this single physical entity. whenever appropriate, to refer to this single physical entity.
The 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]. The BRS is unicast feedback for that session as in [RFC5760]. The BRS is
involved in the unicast burst (or retransmission) RTP session and involved in the unicast burst (or retransmission) RTP session and
transmits the unicast burst and retransmission packets formatted as transmits the unicast burst and retransmission packets formatted as
RTP 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 the message defined in [RFC4585]. Both of these messages are sent to the
FT 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 extended RTP profile for RTCP-based feedback (RTP/AVPF), there In the extended RTP profile for RTCP-based feedback (RTP/Audio-Visual
are certain rules that apply to scheduling of both of these messages Profile with Feedback (AVPF)), there are certain rules that apply to
sent to the FT in the primary multicast RTP session, and these are scheduling of both of these messages sent to the FT in the primary
detailed in Section 3.5 of [RFC4585]. One of the rules states that multicast RTP session; these are detailed in Section 3.5 of
in a multi-party session such as the SSM sessions we are considering [RFC4585]. One of the rules states that in a multi-party session
in this specification, an RTP_Rx cannot send an RTCP feedback message such as the SSM sessions we are considering in this specification, an
for a minimum of one second period after joining the session (i.e., RTP_Rx cannot send an RTCP feedback message for a minimum of one
Tmin=1.0 second). While this rule has the goal of avoiding problems second after joining the session (i.e., Tmin=1.0 second). While this
associated with flash crowds in typical multi-party sessions, it rule has the goal of avoiding problems associated with flash crowds
defeats the purpose of rapid acquisition. Furthermore, when RTP in typical multi-party sessions, it defeats the purpose of rapid
receivers delay their messages requesting a burst by a deterministic acquisition. Furthermore, when RTP receivers delay their messages
or even a random amount, it still does not make a difference since requesting a burst by a deterministic or even a random amount, it
such messages are not related and their timings are independent from still does not make a difference since such messages are not related
each other. Thus, in this specification we initialize Tmin to zero and their timings are independent from each other. Thus, in this
and allow the RTP receivers to send a burst request message right at specification, we initialize Tmin to zero and allow the RTP receivers
the beginning. For the subsequent messages (e.g., updated requests) to send a burst request message right at the beginning. For the
during rapid acquisition, the timing rules of [RFC4585] still apply. subsequent messages (e.g., updated requests) during rapid
acquisition, the timing rules of [RFC4585] still apply.
Figure 3 depicts an example of messaging flow for rapid acquisition. Figure 3 depicts an example of messaging flow for rapid acquisition.
The RTCP feedback messages are explained below. The optional The RTCP feedback messages are explained below. The optional
messages are indicated in parentheses and they might or might not be messages are indicated in parentheses, and they might or might not be
present during rapid acquisition. In a scenario where rapid present during rapid acquisition. In a scenario where rapid
acquisition is performed by a feedback target co-located with the acquisition is performed by a feedback target co-located with the
media sender, the same method (with the identical message flows) media sender, the same method (with the identical message flows)
still applies. still applies.
------------------------- -------------------------
| Retransmission Server | | Retransmission Server |
----------- | ------ ------------ | -------- ------------ ----------- | ------ ------------ | -------- ------------
| Multicast | | | FT | | Burst/Ret. | | | | | RTP | | Multicast | | | FT | | Burst/Ret. | | | | | RTP |
| Source | | | | | Source | | | Router | | Receiver | | Source | | | | | Source | | | Router | | Receiver |
skipping to change at page 16, line 25 skipping to change at page 16, line 24
|-- RTP Multicast ---------->--------------->| | |-- RTP Multicast ---------->--------------->| |
|-. RTCP Multicast -.-.-.-.->-.-.-.-.-.-.-.->| | |-. RTCP Multicast -.-.-.-.->-.-.-.-.-.-.-.->| |
| | | | | | | | | |
| | |********************************| | | |********************************|
| | |* PORT MAPPING SETUP *| | | |* PORT MAPPING SETUP *|
| | |********************************| | | |********************************|
| | | | | | | | | |
| |<~~~~~~~~~~~~~~~~~~~~~~~~~ RTCP RAMS-R ~~~| | |<~~~~~~~~~~~~~~~~~~~~~~~~~ RTCP RAMS-R ~~~|
| | | | | | | | | |
| | |********************************| | | |********************************|
| | |* UNICAST SESSION ESTABLISHED *| | | |* UNICAST SESSION ESTABLISHED *|
| | |********************************| | | |********************************|
| | | | | | | | | |
| | |~~~ RTCP RAMS-I ~~~~~~~~~~~~~~~>| | | |~~~ RTCP RAMS-I ~~~~~~~~~~~~~~~>|
| | | | | | | | | |
| | |... Unicast RTP Burst .........>| | | |... Unicast RTP Burst .........>|
| | | | | | | | | |
| |<~~~~~~~~~~~~~~~~~~~~~~~~ (RTCP RAMS-R) ~~| | |<~~~~~~~~~~~~~~~~~~~~~~~~ (RTCP RAMS-R) ~~|
| | | | | | | | | |
| | |~~ (RTCP RAMS-I) ~~~~~~~~~~~~~~>| | | |~~ (RTCP RAMS-I) ~~~~~~~~~~~~~~>|
| | | | | | | | | |
skipping to change at page 16, line 47 skipping to change at page 16, line 46
| | | |<= 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 the RS and RTP_Rx. This document defines the expected behaviors of the RS and RTP_Rx.
It is instructive to consider independently operating implementations It is instructive to consider independently operating implementations
on the RS and RTP_Rx that request the burst, describe the burst, on the RS and RTP_Rx that request the burst, describe the burst,
start the burst, join the multicast session and stop the burst. start the burst, join the multicast session, and stop the burst.
These implementations send messages to each other, but provisions are These implementations send messages to each other, but provisions are
needed for the cases where the control messages get lost, or re- needed for the cases where the control messages get lost, or
ordered, or are not being delivered to their destinations. reordered, 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, the RTP_Rx (refer to Section 8 for examples in SDP). However, the RTP_Rx
needs to choose its RTP and RTCP receive ports for the unicast needs to choose its RTP and RTCP receive ports for the unicast
burst RTP session. Since this unicast session is established burst RTP session. Since this unicast session is established
after the RTP_Rx has sent a RAMS-Request (RAMS-R) message as after the RTP_Rx has sent a RAMS Request (RAMS-R) message as
unicast feedback in the primary multicast RTP session, the unicast feedback in the primary multicast RTP session, the
RTP_Rx MUST first setup the port mappings between the unicast RTP_Rx MUST first set up the port mappings between the unicast
and multicast sessions and send this mapping information to the and multicast sessions and send this mapping information to the
FT along with the RAMS-R message so that the BRS knows how to FT along with the RAMS-R message so that the BRS knows how to
communicate with the RTP_Rx. communicate with the RTP_Rx.
The details of this setup procedure are explained in The details of this setup procedure are explained in [RFC6284].
[I-D.ietf-avt-ports-for-ucast-mcast-rtp]. Other NAT-related Other NAT-related issues are left to Section 9 to keep the
issues are left to Section 9 to keep the present discussion present discussion focused on the RAMS message flows.
focused on the RAMS message flows.
2. Request: the RTP_Rx sends a rapid acquisition request (RAMS-R) 2. Request: The RTP_Rx sends a rapid acquisition request (RAMS-R)
for the primary multicast RTP session to the unicast feedback for the primary multicast RTP session to the unicast feedback
target of that session. The request contains the SSRC target of that session. The request contains the SSRC
identifier of the RTP_Rx (aka SSRC of packet sender) and can identifier of the RTP_Rx (aka SSRC of packet sender) and can
contain the media sender SSRC identifier(s) of the primary contain the media sender SSRC identifier(s) of the primary
multicast stream(s) of interest (aka SSRC of media source). The multicast stream(s) of interest (aka SSRC of media source). The
RAMS-R message can contain parameters that constrain the burst, RAMS-R message can contain parameters that constrain the burst,
such as the buffer and bandwidth limits. such as the buffer and bandwidth limits.
Before joining the SSM session, the RTP_Rx learns the addresses Before joining the SSM session, the RTP_Rx learns the addresses
for the multicast source, group and RS by out-of-band means. If for the multicast source, group, and RS by out-of-band means.
the RTP_Rx desires to rapidly acquire only a subset of the If the RTP_Rx desires to rapidly acquire only a subset of the
primary multicast streams available in the primary multicast RTP primary multicast streams available in the primary multicast RTP
session, the RTP_Rx MUST also acquire the SSRC identifiers for session, the RTP_Rx MUST also acquire the SSRC identifiers for
the desired RTP streams out-of-band. Based on this information, the desired RTP streams out-of-band. Based on this information,
the RTP_Rx populates the desired SSRC(s) in the RAMS-R message. the RTP_Rx populates the desired SSRC(s) in the RAMS-R message.
When the FT successfully receives the RAMS-R message, the BRS When the FT successfully receives the RAMS-R message, the BRS
responds to it by accepting or rejecting the request. responds to it by accepting or rejecting the request.
Immediately before the BRS sends any RTP or RTCP packet(s) Immediately before the BRS sends any RTP or RTCP packet(s)
described below, it establishes the unicast burst RTP session. described below, it establishes the unicast burst RTP session.
3. Response: The BRS sends RAMS-Information (RAMS-I) message(s) to 3. Response: The BRS sends RAMS Information (RAMS-I) message(s) to
the RTP_Rx to convey the status for the burst(s) requested by the RTP_Rx to convey the status for the burst(s) requested by
the RTP_Rx. the RTP_Rx.
If the primary multicast RTP session associated with the FT_Ap If the primary multicast RTP session associated with the FT_Ap
(a specific feedback target running on a particular address and (a specific feedback target running on a particular address and
port) on which the RAMS-R message was received contains only a port) on which the RAMS-R message was received contains only a
single primary multicast stream, the BRS SHALL always use the single primary multicast stream, the BRS SHALL always use the
SSRC of the RTP stream associated with the FT_Ap in the RAMS-I 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 message(s) regardless of the media sender SSRC requested in the
RAMS-R message. In such cases the 'ssrc' attribute MAY be RAMS-R message. In such cases the 'ssrc' attribute MAY be
omitted from the media description. If the requested SSRC and omitted from the media description. If the requested SSRC and
the actual media sender SSRC do not match, the BRS MUST the actual media sender SSRC do not match, the BRS MUST
explicitly populate the correct media sender SSRC in the initial explicitly populate the correct media sender SSRC in the initial
RAMS-I message (See Section 7.3). RAMS-I message (see Section 7.3).
The FT_Ap could also be associated with an RTP session that The FT_Ap could also be associated with an RTP session that
carries two or more primary multicast streams. If the RTP_Rx carries two or more primary multicast streams. If the RTP_Rx
wants to issue a collective request to receive the whole primary wants to issue a collective request to receive the whole primary
multicast RTP session, it does not need the 'ssrc' attributes to multicast RTP session, it does not need the 'ssrc' attributes to
be described in the media description. be described in the media description.
If the FT_Ap is associated with two or more RTP sessions, If the FT_Ap is associated with two or more RTP sessions,
RTP_Rx's request will be ambiguous. To avoid any ambiguity, RTP_Rx's request will be ambiguous. To avoid any ambiguity,
each FT_Ap MUST be only associated with a single RTP session. each FT_Ap MUST be only associated with a single RTP session.
If the RTP_Rx is willing to rapidly acquire only a subset of the If the RTP_Rx is willing to rapidly acquire only a subset of the
primary multicast streams, the RTP_Rx MUST list all the media primary multicast streams, the RTP_Rx MUST list all the media
sender SSRC(s) denoting the stream(s) it wishes to acquire in sender SSRC(s) denoting the stream(s) it wishes to acquire in
the RAMS-R message. Upon receiving such a message, the BRS MAY the RAMS-R message. Upon receiving such a message, the BRS MAY
accept the request for all or a subset of the media sender accept the request for all or a subset of the media sender
SSRC(s) that matched the RTP stream(s) it serves. The BRS MUST SSRC(s) that match the RTP stream(s) it serves. The BRS MUST
reject all other requests with an appropriate response code. reject all other requests with an appropriate response code.
* Reject Responses: The BRS MUST take into account any * Reject Responses: The BRS MUST take into account any
limitations that may have been specified by the RTP_Rx in the limitations that may have been specified by the RTP_Rx in the
RAMS-R message when making a decision regarding the request. RAMS-R message when making a decision regarding the request.
If the RTP_Rx has requested to acquire the whole primary If the RTP_Rx has requested to acquire the whole primary
multicast RTP session but the BRS cannot provide a rapid multicast RTP session but the BRS cannot provide a rapid
acquisition service for any of the primary multicast streams, acquisition service for any of the primary multicast streams,
the BRS MUST reject the request via a single RAMS-I message the BRS MUST reject the request via a single RAMS-I message
with a collective reject response code, which is defined as with a collective reject response code, which is defined as
510 in Section 11.6, and whose media sender SSRC field is set 510 in Section 11.6 and whose media sender SSRC field is set
to one of SSRCs served by this FT_Ap. Upon receiving this to one of SSRCs served by this FT_Ap. Upon receiving this
RAMS-I message, the RTP_Rx abandons the rapid acquisition RAMS-I message, the RTP_Rx abandons the rapid acquisition
attempt and can immediately join the multicast session by attempt and can immediately join the multicast session by
sending an SFGMP Join message towards its upstream multicast sending an SFGMP Join message towards its upstream multicast
router. router.
In all other cases, the BRS MUST send a separate RAMS-I In all other cases, the BRS MUST send a separate RAMS-I
message with the appropriate 5xx-level response code (as message with the appropriate 5xx-level response code (as
defined in Section 11.6) for each primary multicast stream defined in Section 11.6) for each primary multicast stream
that has been requested by the RTP_Rx but cannot be served by that has been requested by the RTP_Rx but cannot be served by
the BRS. There could be multiple reasons why the BRS has the BRS. There could be multiple reasons why the BRS has
rejected the request, however, the BRS chooses the most rejected the request; however, the BRS chooses the most
appropriate response code to inform the RTP_Rx. appropriate response code to inform the RTP_Rx.
Upon receiving a reject response indicating a transient Upon receiving a reject response indicating a transient
problem such as insufficient BRS or network resources, if the problem such as insufficient BRS or network resources, if the
RTP_Rx wants to retry sending the same request, the RTP_Rx RTP_Rx wants to retry sending the same request, the RTP_Rx
MUST follow the RTCP timer rules of [RFC4585] to allow the MUST follow the RTCP timer rules of [RFC4585] to allow the
transient problems go away. However, if the reject response transient problems to go away. However, if the reject
indicates a non-transient problem (such as the ones reported response indicates a non-transient problem (such as the ones
by response codes 504, 505 and 506), the RTP_Rx MUST NOT reported by response codes 504, 505, and 506), the RTP_Rx
attempt a retry. Different response codes have different MUST NOT attempt a retry. Different response codes have
scopes. Refer to Section 7.3.1 for details. different scopes. Refer to Section 7.3.1 for details.
The BRS can employ a policing mechanism against the broken The BRS can employ a policing mechanism against the broken
RTP_Rx implementations that are not following these rules. RTP_Rx implementations that are not following these rules.
See Section 10 for details. See Section 10 for details.
* Accept Responses: The BRS MUST send at least one separate * Accept Responses: The BRS MUST send at least one separate
RAMS-I message with the appropriate response code (either RAMS-I message with the appropriate response code (either
zero indicating a private response or response code 200 zero indicating a private response or response code 200
indicating success as listed in Section 11.6) for each indicating success as listed in Section 11.6) for each
primary multicast stream that has been requested by the primary multicast stream that has been requested by the
RTP_Rx and will be served by the BRS. Such RAMS-I messages RTP_Rx and will be served by the BRS. Such RAMS-I messages
comprise fields that can be used to describe the individual comprise fields that can be used to describe the individual
unicast burst streams. When there is a RAMS-R request for unicast burst streams. When there is a RAMS-R request for
multiple primary multicast streams, the BRS MUST include all multiple primary multicast streams, the BRS MUST include all
the individual RAMS-I messages corresponding to that RAMS-R the individual RAMS-I messages corresponding to that RAMS-R
request in the same compound RTCP packet if these messages request in the same compound RTCP packet if these messages
fit in the same packet. Note that if the BRS is sending only fit in the same packet. Note that if the BRS is sending only
the preamble information but not the whole unicast burst the preamble information but not the whole unicast burst
stream, it will not accept the request, but will send a stream, it will not accept the request but will send a
response code 511 instead as defined in Section 11.6. response code 511 instead, as defined in Section 11.6.
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 the RTP_Rx to detect any missing initial packet(s). allow the RTP_Rx to detect any missing initial packet(s).
When the BRS accepts a request for a primary multicast When the BRS accepts a request for a primary multicast
stream, this field MUST always be populated in the RAMS-I stream, this field MUST always be populated in the RAMS-I
message(s) sent for this particular primary multicast stream. message(s) sent for this particular primary multicast stream.
It is RECOMMENDED that the BRS sends a RAMS-I message at the It is RECOMMENDED that the BRS sends a RAMS-I message at the
start of the burst so that the RTP_Rx can quickly detect any start of the burst so that the RTP_Rx can quickly detect any
missing initial packet(s). missing initial packet(s).
skipping to change at page 20, line 27 skipping to change at page 20, line 27
receiving RTP packets before receiving a RAMS-I message. An receiving RTP packets before receiving a RAMS-I message. An
RTP_Rx implementation MUST NOT assume it will quickly receive RTP_Rx implementation MUST NOT assume it will quickly receive
the initial RAMS-I message. For redundancy purposes, it is the initial RAMS-I message. For redundancy purposes, it is
RECOMMENDED that the BRS repeats the RAMS-I messages multiple RECOMMENDED that the BRS repeats the RAMS-I 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].
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, the BRS starts sending the unicast the request is accepted, the BRS starts sending the unicast
burst(s) that comprises one or more RTP retransmission packets burst(s) that comprises one or more RTP retransmission packets
sent in the unicast burst RTP session. In addition, in some sent in the unicast burst RTP session. In some applications,
applications the BRS can send preamble information data to the the BRS can send preamble information data to the RTP_Rx in
RTP_Rx in addition to the requested burst to prime the media addition to the requested burst to prime the media decoder(s).
decoder(s). However, for the BRS to send the preamble However, for the BRS to send the preamble information in a
information in a particular format, explicit signaling from the particular format, explicit signaling from the RTP_Rx is
RTP_Rx is required. In other words, the BRS MUST NOT send required. In other words, the BRS MUST NOT send preamble
preamble information in a particular format unless the RTP_Rx information in a particular format unless the RTP_Rx has
has signaled support for that format in the RAMS-R message signaled support for that format in the RAMS-R message through a
through a public or private extension as defined in Section 7.1. public or private extension as defined in Section 7.1.
The format of this preamble data is RTP-payload specific and not The format of this preamble data is RTP-payload specific and not
specified here. specified here.
5. Updated Request: The RTP_Rx MAY send an updated RAMS-R message 5. Updated Request: The RTP_Rx MAY send an updated RAMS-R message
(as unicast feedback in the primary multicast RTP session) with (as unicast feedback in the primary multicast RTP session) with
a 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. The BRS MUST be able to detect whether a burst is message. The BRS MUST be able to detect whether a burst is
already planned for or being transmitted to this particular already planned for or being transmitted to this particular
RTP_Rx for this particular media sender SSRC. If there is an RTP_Rx for this particular media sender SSRC. If there is an
existing burst planned for or being transmitted, the newly existing burst planned for or being transmitted, the newly
arriving RAMS-R is an updated request; otherwise it is a new arriving RAMS-R is an updated request; otherwise, it is a new
request. It is also possible that the RTP_Rx has sent an request. It is also possible that the RTP_Rx has sent an
improperly formatted RAMS-R message or used an invalid value in improperly formatted RAMS-R message or used an invalid value in
the RAMS-R message. If notified by the BRS using a 4xx-level the RAMS-R message. If notified by the BRS using a 4xx-level
response code (as defined in Section 11.6) and only after response code (as defined in Section 11.6) and only after
following the timing rules of [RFC4585], the RTP_Rx MAY re-send following the timing rules of [RFC4585], the RTP_Rx MAY resend
its corrected request. its corrected request.
The BRS determines the identity of the requesting RTP_Rx by The BRS determines the identity of the requesting RTP_Rx by
looking at its canonical name identifier (CNAME item in the SDES looking at its canonical name identifier (CNAME item in the
source description). Thus, the RTP_Rx MUST choose a method that source description (SDES)). Thus, the RTP_Rx MUST choose a
ensures it uses a unique CNAME identifier. Different such ways method that ensures it uses a unique CNAME identifier. Such
are provided in [I-D.ietf-avt-rtp-cnames]. In addition to one methods are provided in [RFC6222]. In addition to one or more
or more fields with updated values, an updated RAMS-R message fields with updated values, an updated RAMS-R message may also
may also include the fields whose values did not change. include the fields whose values did not change.
Upon receiving an updated request, the 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, the 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.
It is an implementation-dependent decision for an RTP_RX whether It is an implementation-dependent decision for an RTP_RX whether
and when to send an updated request. However, note that the and when to send an updated request. However, note that the
updated request messages can get delayed and arrive at the BRS updated request messages can get delayed and arrive at the BRS
after the initial unicast burst was completed. In this case, after the initial unicast burst was completed. In this case,
the updated request message can trigger a new unicast burst and the updated request message can trigger a new unicast burst, and
by then if the RTP_Rx has already started receiving multicast by then if the RTP_Rx has already started receiving multicast
data, a congestion is likely to occur. In this case, the RTP_Rx data, a congestion is likely to occur. In this case, the RTP_Rx
can detect this only after a delay and then it can try to can detect this only after a delay, and then it can try to
terminate the new burst. However, in the mean time, the RTP_Rx terminate the new burst. However, in the meantime, the RTP_Rx
can experience packet loss or other problems. This and other can experience packet loss or other problems. This and other
similar corner cases SHOULD be carefully examined if updated similar corner cases SHOULD be carefully examined if updated
requests are to be used. requests are to be used.
6. Updated Response: The BRS can send more than one RAMS-I 6. Updated Response: The BRS can send more than one RAMS-I message
messages in the unicast burst RTP session, e.g., to update the in the unicast burst RTP session, e.g., to update the value of
value of one or more fields in an earlier RAMS-I message. The one or more fields in an earlier RAMS-I message. The updated
updated RAMS-I messages might or might not be a direct response RAMS-I messages might or might not be a direct response to a
to a RAMS-R message. The BRS can also send updated RAMS-I RAMS-R message. The BRS can also send updated RAMS-I messages
messages to signal the RTP_Rx in real time to join the SSM to signal the RTP_Rx in real time to join the SSM session when
session, when the BRS had already sent an initial RAMS-I the BRS had already sent an initial RAMS-I message, e.g., at the
message, e.g., at the start of the burst. The RTP_Rx depends on start of the burst. The RTP_Rx depends on the BRS to learn the
the BRS to learn the join time, which can be conveyed by the join time, which can be conveyed by the first RAMS-I message or
first RAMS-I message, or can be sent/revised in a later RAMS-I can be sent/revised in a later RAMS-I message. If the BRS is
message. If the BRS is not capable of determining the join time not capable of determining the join time in the initial RAMS-I
in the initial RAMS-I message, the BRS MUST send another RAMS-I message, the BRS MUST send another RAMS-I message (with the join
message (with the join time information) later. time information) later.
7. Multicast Join Signaling: The RAMS-I message allows the BRS to 7. Multicast Join Signaling: The RAMS-I message allows the BRS to
signal explicitly when the RTP_Rx needs to send the SFGMP Join signal explicitly when the RTP_Rx needs to send the SFGMP Join
message. The 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 the 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 the RTP_Rx session too early or too late. For example, if the RTP_Rx
starts 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 the RTP_Rx result in an increased risk of packet loss. Or, if the RTP_Rx
joins 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,
skipping to change at page 22, line 32 skipping to change at page 22, line 32
more values reported earlier to the RTP_Rx, an updated RAMS-I more values reported earlier to the RTP_Rx, an updated RAMS-I
SHOULD be sent to the RTP_Rx. SHOULD be sent to the RTP_Rx.
8. Multicast Receive: After the join, the RTP_Rx starts receiving 8. Multicast Receive: After the join, the RTP_Rx starts receiving
the primary multicast stream(s). the primary multicast stream(s).
9. Terminate: The BRS can know when it needs to ultimately stop 9. Terminate: The BRS can know when it needs to ultimately stop
the unicast burst based on its parameters. However, the RTP_Rx the unicast burst based on its parameters. However, the RTP_Rx
may need to ask the BRS to terminate the burst prematurely or at may need to ask the BRS to terminate the burst prematurely or at
a specific sequence number. For this purpose, the RTP_Rx uses a specific sequence number. For this purpose, the RTP_Rx uses
the RAMS-Termination (RAMS-T) message sent as RTCP feedback in the RAMS Termination (RAMS-T) message sent as RTCP feedback in
the unicast burst RTP session. A separate RAMS-T message is the unicast burst RTP session. A separate RAMS-T message is
sent for each primary multicast stream served by the BRS unless sent for each primary multicast stream served by the BRS unless
an RTCP BYE message has been sent in the unicast burst RTP an RTCP BYE message has been sent in the unicast burst RTP
session as described in Step 10. For the burst requests that session as described in Step 10. For the burst requests that
were rejected by the BRS, there is no need to send a RAMS-T were rejected by the BRS, there is no need to send a RAMS-T
message. message.
If the RTP_Rx wants to terminate a burst prematurely, it MUST If the RTP_Rx wants to terminate a burst prematurely, it MUST
send a 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
skipping to change at page 23, line 26 skipping to change at page 23, line 28
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, the RTP_Rx MUST send at least one RAMS-T message for Step 10, the RTP_Rx MUST send at least one RAMS-T message for
each primary multicast stream served by the BRS. The RAMS-T each primary multicast stream served by the BRS. The RAMS-T
message(s) MUST be sent to the BRS 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 the 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 the RTP_Rx is receiving one or 10. Terminate with RTCP BYE: When the RTP_Rx is receiving one or
more burst streams, if the RTP_Rx becomes no longer interested more burst streams, if the RTP_Rx becomes no longer interested
in acquiring any of the primary multicast streams, the RTP_Rx in acquiring any of the primary multicast streams, the RTP_Rx
SHALL issue an RTCP BYE message for the unicast burst RTP SHALL issue an RTCP BYE message for the unicast burst RTP
session and another RTCP BYE message for the primary multicast session and another RTCP BYE message for the primary multicast
RTP session. These RTCP BYE messages are sent to the BRS and FT RTP session. These RTCP BYE messages are sent to the BRS and FT
logical entities, respectively. logical entities, respectively.
Upon receiving an RTCP BYE message, the BRS MUST terminate the Upon receiving an RTCP BYE message, the BRS MUST terminate the
rapid acquisition operation, and cease transmitting any further rapid acquisition operation and cease transmitting any further
burst packets and retransmission packets. If support for burst packets and retransmission packets. If support for
[RFC5506] has been signaled, the RTCP BYE message MAY be sent in [RFC5506] has been signaled, the RTCP BYE message MAY be sent in
a 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 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, the RS can the information contained in the receiver report, the RS can
figure out how many duplicate RTP packets have been delivered to figure out how many duplicate RTP packets have been delivered to
the RTP_Rx (Note that this will be an upper-bound estimate as the RTP_Rx (note that this will be an upper-bound estimate as
one or more packets might have been lost during the burst one or more packets might have been lost during the burst
transmission). The impact of duplicate packets and measures transmission). The impact of duplicate packets and measures
that can be taken to minimize the impact of receiving duplicate that can be taken to minimize the impact of receiving duplicate
packets will be 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, [MULTICAST-ACQ] defines an RTCP
defines an RTCP Extended Report (XR) Block. This report is designed Extended Report (XR) Block. This report is designed to be payload-
to be payload-independent, thus, it can be used by any multicast independent; thus, it can be used by any multicast application that
application that supports rapid acquisition. supports rapid acquisition.
6.3. Synchronization of Primary Multicast Streams 6.3. Synchronization of Primary Multicast Streams
When an RTP_RX acquires multiple primary multicast streams, it might When an RTP_RX acquires multiple primary multicast streams, it might
need to synchronize them for playout. This synchronization is need to synchronize them for playout. This synchronization is
achieved by the help of the RTCP sender reports [RFC3550]. If the achieved by the help of the RTCP sender reports [RFC3550]. If the
playout will start before the RTP_Rx has joined the multicast playout will start before the RTP_Rx has joined the multicast
session, the RTP_Rx needs to receive the information reflecting the session, the RTP_Rx needs to receive the information reflecting the
synchronization among the primary multicast streams early enough so synchronization among the primary multicast streams early enough 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 [RFC6051]. Per [RFC4588] "if the original extension as defined in [RFC6051]. Per [RFC4588], "if the original
RTP header carried an RTP header extension, the retransmission packet RTP header carried an RTP header extension, the retransmission packet
SHOULD carry the same header extension." Thus, as long as the SHOULD carry the same header extension". Thus, as long as the
multicast source emits a header extension with the synchronization multicast source emits a header extension with the synchronization
information frequently enough, there is no additional task that needs information frequently enough, there is no additional task that needs
to be carried out by the BRS. The synchronization information will to be carried out by the BRS. The synchronization information will
be sent to the RTP_Rx along with the burst packets. The frequent be sent to the RTP_Rx along with the burst packets. The frequent
header extensions sent in the primary multicast RTP sessions also header extensions sent in the primary multicast RTP sessions also
allow rapid synchronization of the RTP streams for the RTP receivers allow rapid synchronization of the RTP streams for the RTP receivers
that do not support RAMS or that directly join the multicast session that do not support RAMS or that directly join the multicast session
without running RAMS. Thus, in RAMS applications, it is RECOMMENDED without running RAMS. Thus, in RAMS applications, it is RECOMMENDED
that the multicast sources frequently send synchronization that the multicast sources frequently send synchronization
information by using header extensions following the rules presented information by using header extensions following the rules presented
in [RFC6051]. The regular sender reports are still sent in the in [RFC6051]. The regular sender reports are still sent in the
unicast session by following the rules of [RFC3550]. unicast session by following the rules 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 the BRS can This section provides informative guidelines about how the BRS can
shape the transmission of the unicast burst and how congestion can be shape the transmission of the unicast burst and how congestion can be
dealt within the RAMS process. When the RTP_Rx detects that the dealt with in the RAMS process. When the RTP_Rx detects that the
unicast burst is causing severe congestion, it can prefer to send a unicast burst is causing severe congestion, it can prefer to send a
RAMS-T message 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 the RTP_Rx faster. This Reference Information and media content to the RTP_Rx faster. This
way, the RTP_Rx can start consuming the data sooner, which results in way, the RTP_Rx can start consuming the data sooner, which results in
a faster acquisition. A higher bitrate also represents a better a faster acquisition. A higher bitrate also represents a better
utilization of the BRS resources. As the burst may continue until it utilization of the BRS resources. As the burst may continue until it
catches up with the primary multicast stream, the higher the bursting catches up with the primary multicast stream, the higher the bursting
bitrate, the less data the BRS needs to transmit. However, a higher bitrate, the less data the BRS needs to transmit. However, a higher
skipping to change at page 25, line 24 skipping to change at page 25, line 31
caused packet loss. Thus, as discussed in Section 5, there has to be caused packet loss. Thus, as discussed in Section 5, there has to be
an upper bound on the bandwidth used by the burst. an upper bound on the bandwidth used by the burst.
When the 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 the RS and RTP_Rx and at the RTP_Rx itself. The on the path between the RS and RTP_Rx and at the RTP_Rx itself. The
bursting bitrate can be determined by taking into account the bursting bitrate can be determined by taking into account the
following 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 the (b) Information obtained via RTCP receiver reports provided by the
RTP_Rx in the retransmission session, allowing in-session bitrate RTP_Rx in the retransmission session, allowing in-session
adaptations for the burst. When these receiver reports indicate bitrate adaptations for the burst. When these receiver reports
packet loss, this can indicate a certain congestion state in the indicate packet loss, this can indicate a certain congestion
path from the RS to the RTP_Rx. state in the path from the RS to the RTP_Rx.
c. Information obtained via RTCP NACKs provided by the RTP_Rx in the (c) Information obtained via RTCP NACKs provided by the RTP_Rx in
primary multicast RTP session, allowing in-session bitrate the 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
the RTP_Rx in response to packet loss detection in the burst. the RTP_Rx in response to packet loss detection in the burst.
NACKs can indicate a certain congestion state on the path from NACKs can indicate a certain congestion state on the path from
the RS to RTP_Rx. the RS to RTP_Rx.
d. There can be other feedback received from the RTP_Rx, e.g., in (d) There can be other feedback received from the RTP_Rx, e.g., in
the form of ECN-CE markings [I-D.ietf-avt-ecn-for-rtp] that can the form of Explicit Congestion Notification - Congestion
influence in-session bitrate adaptation. Experienced (ECN-CE) markings [ECN-FOR-RTP] that can 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 the 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
is used to transport the RTP burst, the ACKs from the DCCP client Datagram Congestion Control Protocol (DCCP) is used to transport
can be leveraged by the BRS / DCCP server for burst shaping and the RTP burst, the ACKs from the DCCP client can be leveraged by
congestion control. the BRS / DCCP server for burst shaping and congestion control.
g. Pre-configured settings for each RTP_Rx or a set of RTP_Rxs that (g) Preconfigured 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 the loss will occur as a result of congestion along the path of the
RS to RTP_Rx. For example, in managed IPTV networks, where the 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
the network between the RS and this link is provisioned and where the network between the RS and this link is provisioned
dimensioned to carry the burst streams, the bursting bitrate does and dimensioned to carry the burst streams, the bursting bitrate
not exceed the provisioned value. These settings can also be does not exceed the provisioned value. These settings can also
dynamically adapted using application-aware knowledge. be dynamically adapted using application-aware knowledge.
The 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), the 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 the BRS cannot determine a reliable bitrate value for the o When the BRS cannot determine a reliable bitrate value for the
unicast burst (using a through g), it is desirable that the BRS unicast burst (using (a) through (g)), it is desirable for the BRS
chooses an appropriate initial bitrate not above the nominal to choose an appropriate initial bitrate not above the nominal
bitrate and increases it gradually unless a congestion is bitrate and increase it gradually unless a congestion is detected.
detected.
In both cases, during the burst transmission the BRS MUST In both cases, during the burst transmission, the BRS MUST
continuously monitor for packet losses as a result of congestion by continuously monitor for packet losses as a result of congestion by
means of one or more of the mechanisms described in (b,c,d,e,f). means of one or more of the mechanisms described in (b) through (f).
When the BRS relies on RTCP receiver reports, sufficient bandwidth When the BRS relies on RTCP receiver reports, sufficient bandwidth
needs to be provided to RTP Rx for RTCP transmission in the unicast needs to be provided to RTP_Rx for RTCP transmission in the unicast
burst RTP session. To achieve a reasonable fast adaptation against burst RTP session. To achieve a reasonable fast adaptation against
congestion, it is recommended that the RTP_Rx sends a receiver report congestion, it is recommended that the RTP_Rx sends a receiver report
at least once every two RTTs between the RS and RTP_Rx. Although the at least once every two RTTs between the RS and RTP_Rx. Although the
specific heuristics and algorithms that deduce a congestion state and specific heuristics and algorithms that deduce a congestion state and
how subsequently the BRS acts are outside the scope of this how the BRS acts subsequently are outside the scope of this
specification, the following two 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 the o Upon detection of a significant amount of packet loss, which the
BRS attributes to congestion, the BRS decreases the burst bitrate. BRS attributes to congestion, the BRS decreases the burst bitrate.
The rate by which the BRS increases and decreases the bitrate for The rate by which the BRS increases and decreases the bitrate for
the 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 the BRS has to reduce the o If the congestion is persistent and the BRS has to reduce the
burst bitrate to a point where the RTP Rx buffer might underrun or burst bitrate to a point where the RTP_Rx buffer might underrun or
the burst will consume too many resources, the BRS terminates the the burst will consume too many resources, the BRS terminates the
burst and transmits a RAMS-I message to RTP Rx with the burst and transmits a RAMS-I message to RTP_Rx with the
appropriate response code. It is then up to RTP Rx to decide when appropriate response code. It is then up to RTP_Rx to decide when
to join the 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 the 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 the RTP_Rx, thus enhancing the risk of simultaneously received by the RTP_Rx, thus enhancing the risk of
congestion. congestion.
Since the BRS signals the RTP_Rx when the BRS expects the RTP_Rx to Since the BRS signals the RTP_Rx when the BRS expects the RTP_Rx to
send the SFGMP Join message, the BRS can have a rough estimate of send the SFGMP Join message, the BRS can have a rough estimate of
when the RTP_Rx will start receiving multicast packets in the SSM when the RTP_Rx will start receiving multicast packets in the SSM
session. The BRS can keep on sending burst packets but reduces the session. The BRS can keep on sending burst packets but reduces the
bitrate accordingly at the appropriate instant by taking the bitrate bitrate accordingly at the appropriate instant by taking the bitrate
of the whole SSM session into account. If the BRS ceases of the whole SSM session into account. If the BRS ceases
transmitting the burst packets before the burst catches up, any gap transmitting the burst packets before the burst catches up, any gap
resulting from this imperfect switch-over by the RTP_Rx can be later resulting from this imperfect switch-over by the RTP_Rx can be later
repaired by requesting retransmissions for the missing packets from repaired by requesting retransmissions for the missing packets from
the RS. The retransmissions can be shaped by the BRS to make sure the RS. The retransmissions can be shaped by the BRS to make sure
that they do not cause collateral loss in the primary multicast RTP that they do not cause collateral loss in the primary multicast RTP
session and the unicast burst RTP session. 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 this section, 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 the RTP_Rx sends a RAMS-R message to initiate a rapid When the RTP_Rx sends a RAMS-R message to initiate a rapid
acquisition but the message gets lost and the FT does not receive it, acquisition but the message gets lost and the FT does not receive it,
the RTP_Rx will get neither a RAMS-I message, nor a unicast burst. the RTP_Rx will get neither a RAMS-I message nor a unicast burst. In
In this case, the RTP_Rx MAY resend the request when it is eligible this case, the RTP_Rx MAY resend the request when it is eligible to
to do so based on the RTCP timer rules defined in [RFC4585]. Or, do so based on the RTCP timer rules defined in [RFC4585]. Or, after
after a reasonable amount of time, the RTP_Rx can time out (based on a reasonable amount of time, the RTP_Rx can time out (based on the
the previous observed response times) and immediately join the SSM previous observed response times) and immediately join the SSM
session. session.
In the case the RTP_Rx starts receiving a unicast burst but it does In the case where RTP_Rx starts receiving a unicast burst but does
not receive a corresponding RAMS-I message within a reasonable amount not receive a corresponding RAMS-I message within a reasonable amount
of time, the RTP_Rx can either discard the burst data or decide not of time, the RTP_Rx can either discard the burst data or decide not
to interrupt the unicast burst, and be prepared to join the SSM to interrupt the unicast burst and be prepared to join the SSM
session at an appropriate time it determines or as indicated in a session at an appropriate time it determines or as indicated in a
subsequent RAMS-I message (if available). If the network is subject subsequent RAMS-I message (if available). If the network is subject
to packet loss, it is RECOMMENDED that the BRS repeats the RAMS-I to packet loss, it is RECOMMENDED that the BRS repeats the RAMS-I
messages multiple times based on the RTCP timer rules defined in messages multiple times based on the RTCP timer rules defined in
[RFC4585]. [RFC4585].
In the failure cases where the RAMS-R message is lost and the RTP_Rx In the failure cases where the RAMS-I message is lost or the RAMS-R
gives up, or the RAMS-I message is lost, the RTP_Rx MUST still message is lost and the RTP_Rx gives up, the RTP_Rx MUST still
terminate the burst(s) it requested by following the rules described terminate the burst(s) it requested by following the rules described
in Section 6.2. in Section 6.2.
In the case a RAMS-T message sent by the RTP_Rx does not reach its In the case where a RAMS-T message sent by the RTP_Rx does not reach
destination, the BRS can continue sending burst packets even though its destination, the BRS can continue sending burst packets even
the RTP_Rx no longer needs them. If an RTP_Rx is receiving burst though the RTP_Rx no longer needs them. If an RTP_Rx is receiving
packets it no longer needs after sending a RAMS-T message, it is burst packets it no longer needs after sending a RAMS-T message, it
RECOMMENDED that the RTP_Rx repeats the RAMS-T message multiple times is RECOMMENDED that the RTP_Rx repeats the RAMS-T message multiple
based on the RTCP timer rules defined in [RFC4585]. The BRS MUST be times based on the RTCP timer rules defined in [RFC4585]. The BRS
provisioned to terminate the burst when it can no longer send the MUST be provisioned to terminate the burst when it can no longer send
burst packets faster than it receives the primary multicast stream the burst packets faster than it receives the primary multicast
packets. stream 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 the BRS accepts to serve the requested burst(s) out an SSRC. When the BRS accepts to serve the requested burst(s)
and establishes the retransmission session, the BRS needs to check and establishes the retransmission session, the BRS needs to check
the liveness of the RTP_Rx via the RTCP messages and reports the the liveness of the RTP_Rx via the RTCP messages and reports the
RTP_Rx sends. The default rules explained in [RFC3550] apply in RAMS RTP_Rx sends. The default rules explained in [RFC3550] apply in RAMS
as well. as well.
7. Encoding of the Signaling Protocol in RTCP 7. Encoding of the Signaling Protocol in RTCP
skipping to change at page 28, line 50 skipping to change at page 29, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | length | |V=2|P| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender | | SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source | | SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) : : Feedback Control Information (FCI) :
: : : :
Figure 4: The common packet format for the RTCP feedback messages Figure 4: The Common Packet Format for the RTCP Feedback Messages
Each feedback message has a fixed-length field for version, padding, Each feedback message has a fixed-length field for version, padding,
feedback message type (FMT), packet type (PT), length, SSRC of packet feedback message type (FMT), packet type (PT), length, SSRC of packet
sender, SSRC of media source as well as a variable-length field for sender, SSRC of media source, and a variable-length field for
feedback control information (FCI). feedback control information (FCI).
In the RAMS messages, the PT field is set to RTPFB (205) and the FMT In the RAMS messages, the PT field is set to RTPFB (205) and the FMT
field is set to RAMS (6). Individual RAMS messages are identified by field is set to RAMS (6). Individual RAMS messages are identified by
a sub-field called Sub Feedback Message Type (SFMT). Any Reserved a sub-field called sub-feedback message type (SFMT). Any Reserved
field SHALL be set to zero and ignored. field SHALL be set to zero and ignored.
Depending on the specific scenario and timeliness/importance of a Depending on the specific scenario and timeliness/importance of a
RAMS message, it can be desirable to send it in a reduced-size RTCP RAMS message, it can be desirable to send it in a reduced-size RTCP
packet [RFC5506]. However, unless support for [RFC5506] has been packet [RFC5506]. However, unless support for [RFC5506] has been
signaled, compound RTCP packets MUST be used by following [RFC3550] signaled, compound RTCP packets MUST be used by following [RFC3550]
rules. rules.
Following the rules specified in [RFC3550], all integer fields in the Following the rules specified in [RFC3550], all integer fields in the
messages defined below are carried in network-byte order, that is, messages defined below are carried in network-byte order, that is,
most significant byte (octet) first, also known as big-endian. most significant byte (octet) first, also known as big-endian.
Unless otherwise stated, numeric constants are in decimal (base 10). Unless otherwise stated, numeric constants are in decimal (base 10).
7.1. Extensions 7.1. Extensions
To improve the functionality of the RAMS method in certain To improve the functionality of the RAMS method in certain
applications, it can be desirable to define new fields in the RAMS applications, it can be desirable to define new fields in the RAMS
Request, Information and Termination messages. Such fields MUST be Request, Information, and Termination messages. Such fields MUST be
encoded as Type-Length-Value (TLV) elements as described below and encoded as Type-Length-Value (TLV) elements as described below and
sketched in Figure 5: sketched in Figure 5:
o Type: A single-octet identifier that defines the type of the o Type: A single-octet identifier that defines the type of the
parameter represented in this TLV element. parameter represented in this TLV element.
o Length: A two-octet field that indicates the length (in octets) o Length: A two-octet field that indicates the length (in octets)
of the TLV element excluding the Type and Length fields, and the of the TLV element excluding the Type and Length fields and the
8-bit Reserved field between them. This length does not include 8-bit Reserved field between them. This length does not include
any padding that is required for alignment. any padding that is required for alignment.
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.
An RTP_Rx or BRS MAY include vendor-neutral and private extensions in An RTP_Rx or BRS MAY include vendor-neutral and private extensions in
any RAMS message. The RTP_Rx or BRS MUST place such extensions after any RAMS message. The RTP_Rx or BRS MUST place such extensions after
the mandatory fields and mandatory TLV elements (if any), and MAY the mandatory fields and mandatory TLV elements (if any) and MAY
place such extensions in any order. The RTP_Rx or BRS MUST NOT place such extensions in any order. The RTP_Rx or BRS MUST NOT
include multiple TLV elements with the same Type value in a RAMS include multiple TLV elements with the same Type value in a RAMS
message. message.
The support for extensions (unless specified otherwise) is OPTIONAL. The support for extensions (unless specified otherwise) is OPTIONAL.
An RTP_Rx or BRS receiving a vendor-neutral or private extension that An RTP_Rx or BRS receiving a vendor-neutral or private extension that
it does not understand MUST ignore that extension. it does not understand MUST ignore that extension.
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
7.1.1. Vendor-Neutral Extensions 7.1.1. Vendor-Neutral Extensions
If the goal in defining new TLV elements is to extend the If the goal in defining new TLV elements is to extend the
functionality in a vendor-neutral manner, they MUST be registered functionality in a vendor-neutral manner, they MUST be registered
with IANA through the guidelines provided in Section 11.5. with IANA through the guidelines provided in Section 11.5.
The current document defines several vendor-neutral extensions in the The current document defines several vendor-neutral extensions in the
subsequent sections. subsequent sections.
7.1.2. Private Extensions 7.1.2. Private Extensions
It is desirable to allow vendors to use private extensions in a TLV It is desirable to allow vendors to use private extensions in a TLV
format. For interoperability, such extensions must not collide with format. For interoperability, such extensions must not collide with
each other. each other.
A certain range of TLV Types (between - and including - 128 and 254 ) A certain range of TLV Types (between and including 128 and 254 ) is
is reserved for private extensions (Refer to Section 11.5). IANA reserved for private extensions (refer to Section 11.5). IANA
management for these extensions is unnecessary and they are the management for these extensions is unnecessary, and they are the
responsibility of individual vendors. responsibility of individual vendors.
The structure that MUST be used for the private extensions is The structure that MUST be used for the private extensions is
depicted in Figure 6. Here, the enterprise numbers are used from depicted in Figure 6. Here, the enterprise numbers are as listed on
http://www.iana.org/assignments/enterprise-numbers. This will ensure http://www.iana.org. This will ensure the uniqueness of the private
the uniqueness of the private extensions and avoid any collision. extensions and avoid any collision.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 (RAMS-R) message is identified by SFMT=1. This The RAMS Request (RAMS-R) message is identified by SFMT=1. This
message is sent as unicast feedback in the primary multicast RTP message is sent as unicast feedback in the primary multicast RTP
session by the RTP_Rx to request rapid acquisition of a primary session by the RTP_Rx to request rapid acquisition of a primary
multicast RTP session, or one or more primary multicast streams multicast RTP session or one or more primary multicast streams
belonging to the same primary multicast RTP session. In the RAMS-R belonging to the same primary multicast RTP session. In the RAMS-R
message, the RTP_Rx MUST set both the packet sender SSRC and media message, the RTP_Rx MUST set both the packet sender SSRC and media
sender SSRC fields to its own SSRC since the media sender SSRC may sender SSRC fields to its own SSRC since the media sender SSRC may
not be known. The RTP_Rx MUST provide explicit signaling as not be known. The RTP_Rx MUST provide explicit signaling as
described below to request stream(s). This minimizes the chances of described below to request stream(s). This minimizes the chances of
accidentally requesting a 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.
skipping to change at page 31, line 46 skipping to change at page 32, line 15
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) : : 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 the RTP_Rx. The BRS MUST the media sender SSRC(s) requested by the RTP_Rx. The BRS MUST
ignore the media sender SSRC specified in the header of the RAMS-R ignore the media sender SSRC specified in the header of the RAMS-R
message. 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 the RTP_Rx is requesting to rapidly acquire listed), it means that the RTP_Rx is requesting to rapidly acquire
the entire primary multicast RTP session. Otherwise, the RTP_Rx the entire primary multicast RTP session. Otherwise, the RTP_Rx
lists the individual media sender SSRCs in this TLV element and lists the individual media sender SSRCs in this TLV element and
skipping to change at page 32, line 27 skipping to change at page 32, line 44
consumed by the application. consumed by the application.
The RTP_Rx can have knowledge of its buffering requirements. The RTP_Rx can have knowledge of its buffering requirements.
These requirements can be application and/or device specific. For These requirements can be application and/or device specific. For
instance, the RTP_Rx might need to have a certain amount of data instance, the RTP_Rx might need to have a certain amount of data
in its application buffer to handle transmission jitter and/or to in its application buffer to handle transmission jitter and/or to
be able to support error-control methods. If the BRS is told the be able to support error-control methods. If the BRS is told the
minimum buffering requirement of the receiver, the BRS can tailor minimum buffering requirement of the receiver, the BRS can tailor
the burst(s) more precisely, e.g., by choosing an appropriate the burst(s) more precisely, e.g., by choosing an appropriate
starting point. The methods used by the RTP_Rx to determine this starting point. The methods used by the RTP_Rx to determine this
value are application specific, and thus, out of the scope of this value are application specific and thus out of the scope of this
document. 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 the RTP_Rx not be able to build up the desired level of buffer at the RTP_Rx
and 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 the 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.
The RTP_Rx can have knowledge of its buffering requirements. The RTP_Rx can have knowledge of its buffering requirements.
These requirements can be application or device specific. For These requirements can be application or device specific. For
instance, one particular RTP_Rx might have more physical memory instance, one particular RTP_Rx might have more physical memory
than another RTP_Rx, and thus, can buffer more data. If the BRS than another RTP_Rx and thus can buffer more data. If the BRS
knows the buffering ability of the receiver, the BRS can tailor knows the buffering ability of the receiver, the BRS can tailor
the burst(s) more precisely. The methods used by the receiver to the burst(s) more precisely. The methods used by the receiver to
determine this value are application specific, and thus, out of determine this value are application specific and thus out of the
scope. 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
larger than this value. Otherwise, the backfill may cause buffer larger than this value. Otherwise, the backfill may cause buffer
overflows at the 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
skipping to change at page 33, line 25 skipping to change at page 33, line 49
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 are more likely to occur. Otherwise, congestion and packet loss are more likely to occur.
Type: 4 Type: 4
o Preamble-only Allowed (0 bits): Optional TLV element that o Preamble-only Allowed (0 bits): Optional TLV element that
indicates that the RTP_Rx is willing to receive only the preamble indicates that the RTP_Rx is willing to receive only the preamble
information for the desired primary multicast stream(s) in case information for the desired primary multicast stream(s) in case
the BRS cannot send the unicast burst stream(s) (In such cases, the BRS cannot send the unicast burst stream(s). (In such cases,
the BRS will not accept the request, but will send a response code the BRS will not accept the request, but will send a response code
511 in the RAMS-I message as defined in Section 11.6). Note that 511 in the RAMS-I message as defined in Section 11.6.) Note that
the RTP_Rx signals the particular preamble format(s) it supports the RTP_Rx signals the particular preamble format(s) it supports
through a public or a private extension in the same RAMS-R through a public or a private extension in the same RAMS-R
message. message.
If this TLV element does not exist in the RAMS-R message, the BRS If this TLV element does not exist in the RAMS-R message, the BRS
MUST NOT respond to the RAMS-R message by sending the preamble MUST NOT respond to the RAMS-R message by sending the preamble
information only. Since this TLV element does not carry a Value information only. Since this TLV element does not carry a Value
field, the Length field MUST be set to zero. field, the Length field MUST be set to zero.
Type: 5 Type: 5
o Supported Enterprise Number(s): Optional TLV element that o Supported Enterprise Number(s): Optional TLV element that
indicates the enterprise number(s) that the RTP_Rx implementation indicates the enterprise number(s) that the RTP_Rx implementation
supports. Similar to the private extensions, the enterprise supports. Similar to the private extensions, the enterprise
numbers here are used from numbers here are as listed on http://www.iana.org. This TLV
http://www.iana.org/assignments/enterprise-numbers. This TLV element, if exists, provides a hint to the BRS about which private
element, if exists, provides a hint information to the BRS about extensions the RTP_Rx can potentially support. Note that an
which private extensions the RTP_Rx can potentially support. Note RTP_Rx does not necessarily support all the private extensions
that an RTP_Rx does not necessarily support all the private under a particular enterprise number. Unless the BRS explicitly
extensions under a particular enterprise number. Unless the BRS knows which private extensions an RTP_Rx supports (through this or
explicitly knows which private extensions an RTP_Rx supports some out-of-band means), the BRS SHOULD NOT use private extensions
(through this or some out-of-band means), the BRS SHOULD NOT use in the RAMS-I messages. The BRS SHOULD rather use only vendor-
private extensions in the RAMS-I messages. The BRS SHOULD rather neutral extensions. The Length field of this TLV element is set
use only vendor-neutral extensions. The Length field of this TLV to 4*n, where n is the number of enterprise number entries.
element is set to 4*n, where n is the number of enterprise number
entries.
Type: 6 Type: 6
7.3. RAMS Information 7.3. RAMS Information
The RAMS Information (RAMS-I) message is identified by SFMT=2. This The RAMS Information (RAMS-I) message is identified by SFMT=2. This
message is used to describe the unicast burst that will be sent for message is used to describe the unicast burst that will be sent for
rapid acquisition. It also includes other useful information for the rapid acquisition. It also includes other useful information for the
RTP_Rx as described below. RTP_Rx as described below.
skipping to change at page 34, line 37 skipping to change at page 35, line 13
type carried in the primary multicast RTP session. 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
A RAMS-I message has the following fields: A RAMS-I message has the following fields:
o Message Sequence Number (MSN) (8 bits) : Mandatory field that o Message Sequence Number (MSN) (8 bits) : Mandatory field that
denotes the sequence number of the RAMS-I message for the denotes the sequence number of the RAMS-I message for the
particular media sender SSRC specified in the message header. The particular media sender SSRC specified in the message header. The
MSN value SHALL be set to zero when a new RAMS request is MSN value SHALL be set to zero when a new RAMS request is
received. During rapid acquisition, the same RAMS-I message MAY received. During rapid acquisition, the same RAMS-I message MAY
be repeated for redundancy purposes without incrementing the MSN be repeated for redundancy purposes without incrementing the MSN
value. If an updated RAMS-I message will be sent (either with a value. If an updated RAMS-I message will be sent (either with new
new information or an updated information), the MSN value SHALL be information or updated information), the MSN value SHALL be
incremented by one. In the MSN field, the regular wrapping rules incremented by one. In the MSN field, the regular wrapping rules
apply. Note that if the RTP_Rx has sent an updated request, it apply. Note that if the RTP_Rx has sent an updated request, it
MUST check every RAMS-I message entirely regardless of whether the MUST check every RAMS-I message entirely, regardless of whether or
MSN value has changed or not. not the MSN value has changed.
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 in Section 7.3.1 and registers them with initial response codes in Section 7.3.1 and registers them with
IANA in Section 11.6. If a new vendor-neutral response code will IANA in Section 11.6. If a new vendor-neutral response code will
be defined, it MUST be registered with IANA through the guidelines be defined, it MUST be registered with IANA through the guidelines
specified in Section 11.6. If the new response code is intended specified in Section 11.6. If the new response code is intended
to be used privately by a vendor, there is no need for IANA to be used privately by a vendor, there is no need for IANA
management. Instead, the vendor MUST use the private extension management. Instead, the vendor MUST use the private extension
mechanism (Section 7.1.2) to convey its message and MUST indicate mechanism (Section 7.1.2) to convey its message and MUST indicate
skipping to change at page 35, line 50 skipping to change at page 36, line 25
RAMS request, this element exists. If the BRS rejects the RAMS RAMS request, this element exists. If the BRS rejects the RAMS
request, this element 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 unicast RTP stream (which could be a burst RTP packet in the unicast RTP stream (which could be a burst
packet or a payload-specific packet) and the earliest time instant packet or a payload-specific packet) and the earliest time instant
when an RTP_Rx MAY send an SFGMP Join message to join the when an RTP_Rx MAY send an SFGMP Join message to join the
multicast session. A zero value in this field means that the multicast session. A zero value indicated in this element means
RTP_Rx MAY send the SFGMP Join message right away. If the RTP_Rx that the RTP_Rx MAY send the SFGMP Join message right away. If
does not want to wait until the earliest multicast join time, it the RTP_Rx does not want to wait until the earliest multicast join
MAY send a RAMS-T message and only after a reasonable amount of time, it MAY send a RAMS-T message, and after a reasonable amount
time, it MAY join the SSM session. of time, it MAY join the SSM session.
If the RAMS request has been accepted, the BRS sends this field at If the RAMS request has been accepted, the BRS sends this element
least once, so that the RTP_Rx knows when to join the multicast at least once so that the RTP_Rx knows when to join the multicast
session. If the burst request has been rejected as indicated in 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 element MUST indicate a zero value. In
it is up to the RTP_Rx when or whether to join the multicast that case, it is up to the RTP_Rx when or whether to join the
session. multicast session.
When the 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 the RTP_Rx sends the SFGMP Join message based on the earliest and the RTP_Rx sends the SFGMP Join message based on the earliest
join 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
time the burst will last (in ms), i.e., the difference between the time the burst will last (in ms), i.e., the difference between the
expected transmission times of the first and the last burst expected transmission times of the first and the last burst
packets that the BRS is planning to send in the respective unicast packets that the BRS is planning to send in the respective unicast
RTP stream. In the absence of additional stimulus, the BRS will RTP stream. In the absence of additional stimulus, the BRS will
send a burst of this duration. However, the burst duration can be send a burst of this duration. However, the burst duration can be
modified by subsequent events, including changes in the primary modified by subsequent events, including changes in the primary
multicast stream and reception of RAMS-T messages. multicast stream and reception of RAMS-T messages.
The BRS MUST terminate the flow in the timeframe indicated by this The BRS MUST terminate the flow in the timeframe indicated by this
burst duration or the duration established by those subsequent burst duration or the duration established by those subsequent
events, even if it does not get a RAMS-T or a BYE message from the events even if it does not get a RAMS-T or a BYE message from the
RTP_Rx. It is OPTIONAL to send this field in a RAMS-I message RTP_Rx. It is OPTIONAL to send this element in a RAMS-I message
when the burst request is accepted. If the burst request has been when the burst request is accepted. If the burst request has been
rejected as indicated in the Response field, this field MAY be rejected as indicated in the Response field, this element MAY be
omitted or set to zero. omitted or indicate a zero value.
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 the the maximum bitrate (in bits per second) that will be used by the
BRS 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
7.3.1. Response Code Definitions 7.3.1. Response Code Definitions
skipping to change at page 37, line 26 skipping to change at page 37, line 45
o 200: This is used when the server accepts the RAMS request. o 200: This is used when the server accepts the RAMS request.
o 201: This is used when the unicast burst has been completed and o 201: This is used when the unicast burst has been completed and
the BRS wants to notify the RTP_Rx. the BRS wants to notify the RTP_Rx.
4xx-Level Response Codes: These response codes are sent to indicate 4xx-Level Response Codes: These response codes are sent to indicate
that the message sent by the RTP_Rx is either improperly formatted or that the message sent by the RTP_Rx is either improperly formatted or
contains an invalid value. The rules the RTP_Rx needs to follow upon contains an invalid value. The rules the RTP_Rx needs to follow upon
receiving one of these response codes are outlined in Step 5 in receiving one of these response codes are outlined in Step 5 in
Section 6.2. The 4xx-level response codes are also used as status Section 6.2. The 4xx-level response codes are also used as status
codes in the Multicast Acquisition Report Block codes in the Multicast Acquisition Report Block [MULTICAST-ACQ] in
[I-D.ietf-avt-multicast-acq-rtcp-xr] in order to collect RTP_Rx-based order to collect RTP_Rx-based error conditions.
error conditions.
o 400: This is used when the RAMS-R message is improperly o 400: This is used when the RAMS-R message is improperly
formatted. formatted.
o 401: This is used when the minimum RAMS buffer fill requirement o 401: This is used when the minimum RAMS buffer fill requirement
value indicated in the RAMS-R message is invalid. value indicated in the RAMS-R message is invalid.
o 402: This is used when the maximum RAMS buffer fill requirement o 402: This is used when the maximum RAMS buffer fill requirement
value indicated in the RAMS-R message is invalid. value indicated in the RAMS-R message is invalid.
o 403: This is used when the maximum receive bitrate value o 403: This is used when the maximum receive bitrate value
indicated in the RAMS-R message is insufficient. indicated in the RAMS-R message is insufficient.
o 404: This is used when the RAMS-T message is improperly o 404: This is used when the RAMS-T message is improperly
formatted. formatted.
5xx-Level Response Codes: These response codes are sent to indicate 5xx-Level Response Codes: These response codes are sent to indicate
an error on the BRS side. The rules the RTP_Rx needs to follow upon an error on the BRS side. The rules the RTP_Rx needs to follow upon
receiving one of these response codes are outlined in Step 3 in receiving one of these response codes are outlined in Step 3 in
Section 6.2 and Section 7.2. The 5xx-level response codes are also Section 6.2. The 5xx-level response codes are also used as status
used as status codes in the Multicast Acquisition Report Block codes in the Multicast Acquisition Report Block [MULTICAST-ACQ] in
[I-D.ietf-avt-multicast-acq-rtcp-xr] in order to collect BRS-based order to collect BRS-based error conditions.
error conditions.
o 500: This is used when the BRS has experienced an internal error o 500: This is used when the BRS has experienced an internal error
and cannot accept the RAMS request. and cannot accept the RAMS request.
o 501: This is used when the BRS does not have enough bandwidth to o 501: This is used when the BRS does not have enough bandwidth to
send the unicast burst stream. send the unicast burst stream.
o 502: This is used when the BRS terminates the unicast burst o 502: This is used when the BRS terminates the unicast burst
stream due to network congestion. stream due to network congestion.
skipping to change at page 38, line 27 skipping to change at page 38, line 46
o 504: This is used when the BRS does not support sending a unicast o 504: This is used when the BRS does not support sending a unicast
burst stream. burst stream.
o 505: This is used when the requesting RTP_Rx is not eligible to o 505: This is used when the requesting RTP_Rx is not eligible to
receive a unicast burst stream. receive a unicast burst stream.
o 506: This is used when RAMS functionality is not enabled for the o 506: This is used when RAMS functionality is not enabled for the
requested multicast stream. requested multicast stream.
o 507: This is used when the BRS cannot find a valid starting point o 507: This is used when the BRS cannot find a valid starting point
for the unicast burst stream satisfying the RTP_Rx's requirements. for the unicast burst stream that satisfies the RTP_Rx's
requirements.
o 508: This is used when the BRS cannot find the essential o 508: This is used when the BRS cannot find the essential
reference information for the requested multicast stream. reference information for the requested multicast stream.
o 509: This is used when the BRS cannot match the requested SSRC to o 509: This is used when the BRS cannot match the requested SSRC to
any of the streams it is serving. any of the streams it is serving.
o 510: This is used when the BRS cannot serve the requested entire o 510: This is used when the BRS cannot serve the requested entire
session. session.
o 511: This is used when the BRS sends only the preamble o 511: This is used when the BRS sends only the preamble
information but not the whole unicast burst stream. information but not the whole unicast burst stream.
o 512: This is used when the RAMS request is denied due to a policy o 512: This is used when the RAMS request is denied due to a policy
specified for the requested multicast stream, requesting RTP_Rx or for the requested multicast stream, the RTP_Rx, or this particular
this particular BRS. BRS.
7.4. RAMS Termination 7.4. RAMS Termination
The RAMS Termination (RAMS-T) message is identified by SFMT=3. The RAMS Termination (RAMS-T) message is identified by SFMT=3.
The RAMS Termination is used to assist the 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 the RTP_Rx for each primary multicast stream burst RTP session by the RTP_Rx for each primary multicast stream
that has been served by the BRS. Each of these RAMS-T message's that has been served by the BRS. Each of these RAMS-T message's
media sender SSRC field SHALL BE populated with the SSRC of the media media sender SSRC field SHALL BE populated with the SSRC of the media
skipping to change at page 40, line 14 skipping to change at page 40, line 36
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], rtcp-fb-nack-param is used as (In the following ABNF [RFC5234], rtcp-fb-nack-param is used as
defined in [RFC4566].) defined in [RFC4585].)
rtcp-fb-nack-param =/ SP "rai" rtcp-fb-nack-param =/ 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
updates') that indicates whether the BRS supports updated request ('rams-updates') that indicates whether or not the BRS supports
messages or not. This attribute is used in a declarative manner and updated request messages. This attribute is used in a declarative
no Offer/Answer Model behavior is specified. If the BRS supports manner and no Offer/Answer Model behavior is specified. If the BRS
updated request messages and this attribute is included in the SDP supports updated request messages and this attribute is included in
description, the RTP_Rx can send updated requests. The BRS might or the SDP description, the RTP_Rx can send updated requests. The BRS
might not be able to accept value changes in every field in an might or might not be able to accept value changes in every field in
updated RAMS-R message. However, if the 'rams-updates' attribute is an updated RAMS-R message. However, if the 'rams-updates' attribute
not included in the SDP description, the RTP_Rx SHALL NOT send is not included in the SDP description, the RTP_Rx SHALL NOT send
updated requests. The RTP_Rx MAY still repeat its initial request updated requests. The RTP_Rx MAY still repeat its initial request
without 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
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]
o The RTP retransmission payload format [RFC4588] o The RTP retransmission payload format [RFC4588]
o The RTCP extensions for SSM sessions with unicast feedback o The RTCP extensions for SSM sessions with unicast feedback
[RFC5760] [RFC5760]
o The 'multicast-rtcp' attribute [I-D.ietf-avt-rtcp-port-for-ssm] o The 'multicast-rtcp' attribute [RFC6128]
o Multiplexing RTP and RTCP on a single port on both endpoints in o Multiplexing RTP and RTCP on a single port on both endpoints in
the unicast session [RFC5761] the unicast session [RFC5761]
o The 'portmapping-req' attribute o The 'portmapping-req' attribute [RFC6284]
[I-D.ietf-avt-ports-for-ucast-mcast-rtp]
The support for the source-specific media attributes [RFC5576] can Support for the source-specific media attributes [RFC5576] can also
also be needed when the 'ssrc' attribute is to be used for the media be needed when the 'ssrc' attribute is to be used for the media
descriptions. descriptions.
8.3. Example and Discussion 8.3. Example and Discussion
This section provides a declarative SDP [RFC4566] example (for the This section provides a declarative SDP [RFC4566] example (for the
RTP_Rx side) for enabling rapid acquisition of multicast RTP RTP_Rx side) for enabling rapid acquisition of multicast RTP
sessions. sessions.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com o=ali 1122334455 1122334466 IN IP4 rams.example.com
skipping to change at page 42, line 22 skipping to change at page 42, line 10
i=Primary Multicast Stream i=Primary Multicast Stream
c=IN IP4 233.252.0.2/255 c=IN IP4 233.252.0.2/255
a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1 a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
a=rtpmap:98 MP2T/90000 a=rtpmap:98 MP2T/90000
a=multicast-rtcp:42000 a=multicast-rtcp:42000
a=rtcp:43000 IN IP4 192.0.2.1 a=rtcp:43000 IN IP4 192.0.2.1
a=rtcp-fb:98 nack a=rtcp-fb:98 nack
a=rtcp-fb:98 nack rai a=rtcp-fb:98 nack rai
a=ssrc:123321 cname:iptv-ch32@rams.example.com a=ssrc:123321 cname:iptv-ch32@rams.example.com
a=rams-updates a=rams-updates
a=portmapping-req:54000 IN IP4 192.0.2.1
a=mid:1 a=mid:1
m=video 51000 RTP/AVPF 99 m=video 51000 RTP/AVPF 99
i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support) i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support)
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=sendonly a=sendonly
a=rtpmap:99 rtx/90000 a=rtpmap:99 rtx/90000
a=rtcp-mux a=rtcp-mux
a=rtcp:51500 a=rtcp:51500
a=fmtp:99 apt=98;rtx-time=5000 a=fmtp:99 apt=98;rtx-time=5000
a=portmapping-req:55000 a=portmapping-req:55000
a=mid:2 a=mid:2
Figure 10: Example SDP for a single-channel RAMS scenario Figure 10: Example SDP for a Single-Channel RAMS Scenario
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.
skipping to change at page 44, line 8 skipping to change at page 43, line 47
react to the RAMS-R message by sending any transport-layer (and react to the RAMS-R message by sending any transport-layer (and
optional payload-specific, when allowed) feedback message(s) and optional payload-specific, when allowed) feedback 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 the 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 the RTP_Rx wants to acquire one or more streams from streams or the RTP_Rx wants to acquire one or more streams from
multiple primary multicast RTP sessions at the same time are multiple primary multicast RTP sessions at the same time are
presented in [I-D.begen-avt-rams-scenarios]. presented in [RAMS-SCENARIOS].
9. NAT Considerations 9. NAT Considerations
For a variety of reasons, one or more Network Address Port For a variety of reasons, one or more Network Address Port
Translators (NAPT - hereafter simply called NAT) can exist between Translators (NAPT, hereafter simply called NAT) can exist between the
the RTP_Rx and RS. NATs have a variety of operating characteristics RTP_Rx and RS. NATs have a variety of operating characteristics for
for UDP traffic [RFC4787]. For a NAT to permit traffic from the BRS UDP traffic [RFC4787]. For a NAT to permit traffic from the BRS to
to arrive at the RTP_Rx, the NAT(s) must first either: arrive at the RTP_Rx, the NAT(s) must first either:
a. See UDP (or DCCP) traffic sent from the RTP_Rx (which is on the a. See UDP (or DCCP) traffic sent from the RTP_Rx (which is on the
'inside' of the NAT) to the BRS (which is on the 'outside' of the 'inside' of the NAT) to the BRS (which is on the 'outside' of the
NAT). This traffic has the same transport address as the NAT). This traffic has the same transport address as the
subsequent response traffic, or; subsequent response 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 or UPnP IGD [UPnP-IGD]). Details of this are out configuration or Universal Plug and Play (UPnP) Internet Gateway
of scope of this document. Device (IGD) [UPnP-IGD]). Details of this are out of the scope
of this document.
For both (a) and (b), the RTP_Rx is responsible for maintaining the For both (a) and (b), the RTP_Rx is responsible for maintaining the
NAT's state if it wants to receive traffic from the BRS on that port. NAT's state if it wants to receive traffic from the BRS on that port.
For (a), the RTP_Rx MUST send UDP traffic to keep the NAT binding For (a), the RTP_Rx MUST send UDP traffic to keep the NAT binding
alive, at least every 30 seconds [RFC4787]. While (a) is more like alive, at least every 30 seconds [RFC4787]. While (a) is more like
an automatic/dynamic configuration, (b) is more like a manual/static an automatic/dynamic configuration, (b) is more like a manual/static
configuration. configuration.
When the RTP_Rx sends a request (RAMS-R) message to the 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 the FT, a new unicast burst RTP session will be received by the FT, a new unicast burst RTP session will be
established between the BRS and RTP_Rx. established between the BRS and RTP_Rx.
While the FT and BRS ports on the RS are already signaled via out-of- While the FT and BRS ports on the RS are already signaled via out-of-
band means (e.g., SDP), the RTP_Rx needs to convey the RTP and RTCP band means (e.g., SDP), the RTP_Rx needs to convey the RTP and RTCP
ports it wants to use on its side for the new session. Since there ports it wants to use on its side for the new session. Since there
are two RTP sessions (one multicast and one unicast) involved during are two RTP sessions (one multicast and one unicast) involved during
this process and one of them is established upon a feedback message this process and one of them is established upon a feedback message
sent 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 method presented in Applications using RAMS MUST support the method presented in
[I-D.ietf-avt-ports-for-ucast-mcast-rtp] both on the RS and RTP_Rx [RFC6284] both on the RS and RTP_Rx side to allow RTP receivers to
side to allow RTP receivers to use their desired ports and to support use their desired ports and to support RAMS behind NAT devices. The
RAMS behind NAT devices. The port mapping message exchange needs to port mapping message exchange needs to take place whenever the RTP_Rx
take place whenever the RTP_Rx intends to make use of the RAMS intends to make use of the RAMS protocol for rapidly acquiring a
protocol for rapidly acquiring a specific multicast RTP session, specific multicast RTP session prior to joining the associated SSM
prior to joining the associated SSM session. 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 [RFC6284].
[I-D.ietf-avt-ports-for-ucast-mcast-rtp]. Thus, these applications Thus, these applications are subject to the general security
are subject to the general security considerations discussed in those considerations discussed in those documents. In particular, the
documents. In particular, the threats and risks discussed in threats and risks discussed in [RFC5760] need to be considered
[RFC5760] need to be considered carefully. In this section, we give carefully. In this section, we give an overview of the guidelines
an overview of the guidelines and suggestions described in these and suggestions described in these specifications from a RAMS
specifications from a RAMS perspective. We also discuss the security perspective. We also discuss the security considerations that
considerations that explicitly apply to applications using RAMS. explicitly apply to applications using RAMS.
First of all, much of the session description information is First of all, much of the session description information is
available in the SDP descriptions that are distributed to the media available in the SDP descriptions that are distributed to the media
senders, retransmission servers and RTP receivers. Adequate security senders, retransmission servers, and RTP receivers. Adequate
measures are RECOMMENDED to ensure the integrity and authenticity of security measures are RECOMMENDED to ensure the integrity and
the SDP descriptions so that transport addresses of the media authenticity of the SDP descriptions so that transport addresses of
senders, distribution sources, feedback targets as well as other the media senders, distribution sources, feedback targets, and other
session-specific information can be protected. See [RFC4566] for session-specific information can be protected. See [RFC4566] for
details. details.
Compared to an RTCP NACK message that triggers one or more Compared to an RTCP NACK message that triggers one or more
retransmissions, a RAMS Request (RAMS-R) message can trigger a new retransmissions, a RAMS Request (RAMS-R) message can trigger a new
burst stream to be sent by the retransmission server. Depending on burst stream to be sent by the retransmission server. Depending on
the application-specific requirements and conditions existing at the the application-specific requirements and conditions existing at the
time of the RAMS-R reception by the retransmission server, the time of the RAMS-R reception by the retransmission server, the
resulting burst stream can potentially contain a large number of resulting burst stream can potentially contain a large number of
retransmission packets. Since these packets are sent faster than the retransmission packets. Since these packets are sent faster than the
nominal rate, RAMS consumes more resources on the retransmission nominal rate, RAMS consumes more resources on the retransmission
servers, RTP receivers and the network. In particular, this can make servers, RTP receivers, and the network. In particular, this can
denial-of-service (DoS) attacks more intense, and hence, more harmful make denial-of-service (DoS) attacks more intense and hence more
than attacks that target ordinary retransmission sessions. harmful than attacks that target ordinary retransmission sessions.
As RAMS messages are sent as RTCP messages, following the suggestions
given in [RFC4588], counter-measures SHOULD be taken to prevent
tampered or spoofed RTCP packets. Tampered RAMS-R messages can
trigger inappropriate burst streams or alter the existing burst
streams in an inappropriate way. For example, if the Max Receive
Bitrate field is altered by a tampered RAMS-R message, the updated
burst can overflow the buffer at the receiver side, or oppositely,
can slow down the burst to the point that it becomes useless.
Tampered RAMS Termination (RAMS-T) messages can terminate valid burst
streams prematurely resulting in gaps in the received RTP packets.
RAMS Information (RAMS-I) messages contain fields that are critical As RAMS messages are sent as RTCP messages, counter-measures SHOULD
for a successful rapid acquisition. Any tampered information in the be taken to prevent tampered or spoofed RTCP packets, following the
RAMS-I message can easily cause an RTP receiver to make wrong suggestions given in [RFC4588]. Tampered RAMS-R messages can trigger
decisions. Consequently, the RAMS operation can fail. inappropriate burst streams or alter the existing burst streams in an
inappropriate way. For example, if the Max Receive Bitrate field is
altered by a tampered RAMS-R message, the updated burst can overflow
the buffer at the receiver side or, oppositely, can slow down the
burst to the point that it becomes useless. Tampered RAMS
Termination (RAMS-T) messages can terminate valid burst streams
prematurely resulting in gaps in the received RTP packets. RAMS
Information (RAMS-I) messages contain fields that are critical for a
successful rapid acquisition. Any tampered information in the RAMS-I
message can easily cause an RTP receiver to make wrong decisions.
Consequently, the RAMS operation can fail.
RTCP BYE messages are similar to RAMS-T messages in the sense that RTCP BYE messages are similar to RAMS-T messages in the sense that
they can be used to stop an existing burst. The CNAME of an RTP they can be used to stop an existing burst. The CNAME of an RTP
receiver is used to bind the RTCP BYE message to an existing burst. receiver is used to bind the RTCP BYE message to an existing burst.
Thus, one should be careful if the CNAMEs are reasonably easy to Thus, one should be careful if the CNAMEs are reasonably easy to
guess and off-path attacks can be performed. Also note that the guess and off-path attacks can be performed. Also note that the
CNAMEs might be redistributed to all participants in the multicast CNAMEs might be redistributed to all participants in the multicast
group (as in ASM or the simple feedback model of [RFC5760]). group (as in ASM or the simple feedback model of [RFC5760]).
The retransmission server has to consider if values indicated in a The retransmission server has to consider if values indicated in a
RAMS-R message are reasonable. For example, a request demanding a RAMS-R message are reasonable. For example, a request demanding a
large value of many seconds in the Min RAMS Buffer Fill Requirement large value of many seconds in the Min RAMS Buffer Fill Requirement
element should, unless special uses cases exist, likely be rejected element should, unless special use cases exist, likely be rejected
since it is likely to be an attempt to prolong a DoS attack on the since it is likely to be an attempt to prolong a DoS attack on the
retransmission server, RTP receiver and/or the network. The Max retransmission server, RTP receiver, and/or the network. The Max
Receive Bitrate could also be set to a very large value to try to get Receive Bitrate could also be set to a very large value to try to get
the retransmission server to cause massive congestion by bursting at the retransmission server to cause massive congestion by bursting at
a bitrate that will not be supported by the network. An RTP_Rx a bitrate that will not be supported by the network. An RTP_Rx
should also consider if the values for the Earliest Multicast Join should also consider if the values for the Earliest Multicast Join
Time and Burst Duration indicated by the retransmission server in a Time and Burst Duration indicated by the retransmission server in a
RAMS-I message are reasonable. For example, if the burst packets RAMS-I message are reasonable. For example, if the burst packets
stop arriving and the join time is still significantly far into the stop arriving and the join time is still significantly far into the
future, this could be a sign of a man-in-the-middle attack where the future, this could be a sign of a man-in-the-middle attack where the
RAMS-I message has been manipulated by an attacker. RAMS-I message has been manipulated by an attacker.
skipping to change at page 47, line 8 skipping to change at page 46, line 52
incoming RAMS requests. A reasonable policing mechanism should incoming RAMS requests. A reasonable policing mechanism should
consider application-specific requirements and minimize false consider application-specific requirements and minimize false
negatives. negatives.
In addition to the DoS attacks, man-in-the-middle and replay attacks In addition to the DoS attacks, man-in-the-middle and replay attacks
will also be harmful. RAMS-R messages do not carry any information will also be harmful. RAMS-R messages do not carry any information
that allows the retransmission server to detect duplication or replay that allows the retransmission server to detect duplication or replay
attacks. Thus, the possibility of a replay attack using a captured attacks. Thus, the possibility of a replay attack using a captured
valid RAMS-R message exists unless a mitigation method such as Secure valid RAMS-R message exists unless a mitigation method such as Secure
RTCP (SRTCP) is used. Similarly, RAMS-T messages can be replayed. RTCP (SRTCP) is used. Similarly, RAMS-T messages can be replayed.
The RAMS-I has sequence number that makes replay attacks less likely The RAMS-I has a sequence number that makes replay attacks less
but not impossible. Man-in-the-middle attacks that are capable of likely but not impossible. Man-in-the-middle attacks that are
capturing, injecting or modifying the RAMS messages can easily capable of capturing, injecting, or modifying the RAMS messages can
accomplish the attacks described above. Thus, cryptographic easily accomplish the attacks described above. Thus, cryptographic
integrity and authentication is the only reliable protection. To integrity and authentication is the only reliable protection. To
protect the RTCP messages from man-in-the-middle and replay attacks, protect the RTCP messages from man-in-the-middle and replay attacks,
the RTP receivers and retransmission server SHOULD perform a DTLS- the RTP receivers and retransmission server SHOULD perform a Datagram
SRTP handshake [RFC5764] over the RTCP channel. Because there is no Transport Layer Security (DTLS)-SRTP handshake [RFC5764] over the
integrity-protected signaling channel between an RTP receiver and the RTCP channel. Because there is no integrity-protected signaling
retransmission server, the retransmission server MUST maintain a list channel between an RTP receiver and the retransmission server, the
of certificates owned by legitimate RTP receivers, or their retransmission server MUST maintain a list of certificates owned by
certificates MUST be signed by a trusted Certificate Authority. Once legitimate RTP receivers, or their certificates MUST be signed by a
the DTLS-SRTP security is established, non-SRTCP-protected messages trusted Certificate Authority. Once the DTLS-SRTP security is
received from a particular RTP receiver are ignored by the established, non-SRTCP-protected messages received from a particular
retransmission server. To reduce the impact of DTLS-SRTP overhead RTP receiver are ignored by the retransmission server. To reduce the
when communicating with different feedback targets on the same impact of DTLS-SRTP overhead when communicating with different
retransmission server, it is RECOMMENDED that RTP receivers and the feedback targets on the same retransmission server, it is RECOMMENDED
retransmission server both support TLS Session Resumption without that RTP receivers and the retransmission server both support TLS
Server-side State [RFC5077]. To help scale SRTP to handle many RTP Session Resumption without Server-side State [RFC5077]. To help
receivers asking for retransmissions of identical data, implementors scale SRTP to handle many RTP receivers asking for retransmissions of
may consider using the same SRTP key for SRTP data sent to the identical data, implementors may consider using the same SRTP key for
receivers [I-D.ietf-avt-srtp-ekt] and be aware that such key sharing SRTP data sent to the receivers [SRTP-EKT] and be aware that such key
allows those receivers to impersonate the sender, so source address sharing allows those receivers to impersonate the sender. Thus,
validation remains important. source address validation remains important.
[RFC4588] RECOMMENDS that the cryptography mechanisms are used for [RFC4588] RECOMMENDS that cryptography mechanisms be used for the
the retransmission payload format to provide protection against known retransmission payload format to provide protection against known
plain-text attacks. As discussed in [RFC4588], the retransmission plain-text attacks. As discussed in [RFC4588], the retransmission
payload format sets the timestamp field in the RTP header to the payload format sets the timestamp field in the RTP header to the
media timestamp of the original packet and this does not compromise media timestamp of the original packet, and this does not compromise
the confidentiality. Furthermore, if cryptography is used to provide the confidentiality. Furthermore, if cryptography is used to provide
security services on the original stream, then the same services, security services on the original stream, then the same services,
with equivalent cryptographic strength, MUST be provided on the with equivalent cryptographic strength, MUST be provided on the
retransmission stream per [RFC4588]. retransmission stream per [RFC4588].
Finally, a retransmission server that has become subverted by an Finally, a retransmission server that has become subverted by an
attacker is almost impossible to protect against as such a server can attacker is almost impossible to protect against as such a server can
perform a large number of different actions to deny service to perform a large number of different actions to deny service to
receivers. receivers.
11. IANA Considerations 11. IANA Considerations
The following contact information shall be used for all registrations The following contact information is used for all registrations in
in this document: this document:
Ali Begen Ali Begen
abegen@cisco.com abegen@cisco.com
Note that the "RAMS" (value 2) in the Multicast Acquisition Method
Note to the RFC Editor: In the following, please replace "XXXX" with Registry refers to the method described in Section 6 of this
the number of this document prior to publication as an RFC. document.
11.1. Registration of SDP Attributes 11.1. Registration of SDP Attributes
This document registers a new attribute name in SDP. This document registers a new attribute name in SDP.
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: rams-updates Attribute name: rams-updates
Long form: Support for Updated RAMS Request Messages Long form: Support for Updated RAMS Request Messages
Type of name: att-field Type of name: att-field
Type of attribute: Media level Type of attribute: Media level
Subject to charset: No Subject to charset: No
Purpose: See this document Purpose: See this document
Reference: [RFCXXXX] Reference: [RFC6285]
Values: None Values: None
11.2. Registration of SDP Attribute Values 11.2. Registration of SDP Attribute Values
This document registers a new value for the 'nack' attribute to be This document registers a new value for the 'nack' attribute to be
used with the 'rtcp-fb' attribute in SDP. For more information about used with the 'rtcp-fb' attribute in SDP. For more information about
the 'rtcp-fb' attribute, refer to Sections 4.2 and 6.2 of [RFC4585]. the 'rtcp-fb' attribute, refer to Section 4.2 of [RFC4585].
Value name: rai Value name: rai
Long name: Rapid Acquisition Indication Long name: Rapid Acquisition Indication
Usable with: nack Usable with: nack
Reference: [RFCXXXX] Reference: [RFC6285]
11.3. Registration of FMT Values 11.3. Registration of FMT Values
Within the RTPFB range, the following format (FMT) value is Within the RTPFB range, the following format (FMT) value is
registered: registered:
Name: RAMS Name: RAMS
Long name: Rapid Acquisition of Multicast Sessions Long name: Rapid Acquisition of Multicast Sessions
Value: 6 Value: 6
Reference: [RFCXXXX] Reference: [RFC6285]
11.4. SFMT Values for RAMS Messages Registry 11.4. SFMT Values for RAMS Messages Registry
This document creates a new sub-registry for the sub-feedback message This document creates a new sub-registry for the sub-feedback message
type (SFMT) values to be used with the FMT value registered for RAMS type (SFMT) values to be used with the FMT value registered for RAMS
messages. The registry is called the SFMT Values for RAMS Messages messages. The registry is called the SFMT Values for RAMS Messages
Registry. This registry is to be managed by the IANA according to Registry. This registry is managed by the IANA according to the
the Specification Required policy of [RFC5226]. Specification Required policy of [RFC5226].
The length of the SFMT field in the RAMS messages is a single octet, The length of the SFMT field in the RAMS messages is a single octet,
allowing 256 values. The registry is initialized with the following allowing 256 values. The registry is initialized with the following
entries: entries:
Value Name Reference Value Name Reference
----- -------------------------------------------------- ------------- ----- -------------------------------------------------- ------------
0 Reserved [RFCXXXX] 0 Reserved [RFC6285]
1 RAMS Request [RFCXXXX] 1 RAMS Request [RFC6285]
2 RAMS Information [RFCXXXX] 2 RAMS Information [RFC6285]
3 RAMS Termination [RFCXXXX] 3 RAMS Termination [RFC6285]
4-254 Assignable - Specification Required 4-254 Unassigned - Specification Required
255 Reserved [RFCXXXX] 255 Reserved [RFC6285]
The SFMT values 0 and 255 are reserved for future use. The SFMT values 0 and 255 are reserved for future use.
Any registration for an unassigned SFMT value needs to contain the Any registration for an unassigned SFMT value needs to contain the
following information: following information:
o Contact information of the one doing the registration, including o Contact information of the one doing the registration, including
at least name, address, and email. at least name, address, and email.
o A detailed description of what the new SFMT represents and how it o A detailed description of what the new SFMT represents and how it
shall be interpreted. shall be interpreted.
New RAMS functionality is intended to be introduced by using the New RAMS functionality is intended to be introduced by using the
extension mechanism within the existing RAMS message types not by extension mechanism within the existing RAMS message types not by
introducing new message types unless it is absolutely necessary. introducing new message types unless it is absolutely necessary.
11.5. RAMS TLV Space Registry 11.5. RAMS TLV Space Registry
This document creates a new IANA TLV space registry for the RAMS This document creates a new IANA TLV space registry for the RAMS
extensions. The registry is called the RAMS TLV Space Registry. extensions. The registry is called the RAMS TLV Space Registry.
This registry is to be managed by the IANA according to the This registry is managed by the IANA according to the Specification
Specification Required policy of [RFC5226]. Required policy of [RFC5226].
The length of the Type field in the TLV elements is a single octet, The length of the Type field in the TLV elements is a single octet,
allowing 256 values. The Type values 0 and 255 are reserved for allowing 256 values. The Type values 0 and 255 are reserved for
future use. The Type values between (and including) 128 and 254 are future use. The Type values between (and including) 128 and 254 are
reserved for private extensions. reserved for private extensions.
The registry is initialized with the following entries: The registry is initialized with the following entries:
Type Description Reference Type Description Reference
---- -------------------------------------------------- ------------- ---- ----------------------------------------------- -------------
0 Reserved [RFCXXXX] 0 Reserved [RFC6285]
1 Requested Media Sender SSRC(s) [RFCXXXX] 1 Requested Media Sender SSRC(s) [RFC6285]
2 Min RAMS Buffer Fill Requirement [RFCXXXX] 2 Min RAMS Buffer Fill Requirement [RFC6285]
3 Max RAMS Buffer Fill Requirement [RFCXXXX] 3 Max RAMS Buffer Fill Requirement [RFC6285]
4 Max Receive Bitrate [RFCXXXX] 4 Max Receive Bitrate [RFC6285]
5 Request for Preamble Only [RFCXXXX] 5 Request for Preamble Only [RFC6285]
6 Supported Enterprise Number(s) [RFCXXXX] 6 Supported Enterprise Number(s) [RFC6285]
7-30 Assignable - Specification Required 7-30 Unassigned - Specification Required
31 Media Sender SSRC [RFCXXXX] 31 Media Sender SSRC [RFC6285]
32 RTP Seqnum of the First Packet [RFCXXXX] 32 RTP Seqnum of the First Packet [RFC6285]
33 Earliest Multicast Join Time [RFCXXXX] 33 Earliest Multicast Join Time [RFC6285]
34 Burst Duration [RFCXXXX] 34 Burst Duration [RFC6285]
35 Max Transmit Bitrate [RFCXXXX] 35 Max Transmit Bitrate [RFC6285]
36-60 Assignable - Specification Required 36-60 Unassigned - Specification Required
61 Extended RTP Seqnum of First Multicast Packet [RFCXXXX] 61 Extended RTP Seqnum of First Multicast Packet [RFC6285]
62-127 Assignable - Specification Required 62-127 Unassigned - Specification Required
128-254 No IANA Maintenance 128-254 Reserved for Private Use
255 Reserved [RFCXXXX] 255 Reserved [RFC6285]
Any registration for an unassigned Type value needs to contain the Any registration for an unassigned Type value needs to contain the
following information: following information:
o Contact information of the one doing the registration, including o Contact information of the one doing the registration, including
at least name, address, and email. at least name, address, and email.
o A detailed description of what the new TLV element represents and o A detailed description of what the new TLV element represents and
how it shall be interpreted. how it shall be interpreted.
11.6. RAMS Response Code Space Registry 11.6. RAMS Response Code Space Registry
This document creates a new IANA TLV space registry for the RAMS This document creates a new IANA TLV space registry for the RAMS
response codes. The registry is called the RAMS Response Code Space response codes. The registry is called the RAMS Response Code Space
Registry. This registry is to be managed by the IANA according to Registry. This registry is managed by the IANA according to the
the Specification Required policy of [RFC5226]. Specification Required policy of [RFC5226].
The length of the Response field is two octets, allowing 65536 codes. The length of the Response field is two octets, allowing 65536 codes.
However, the response codes have been classified and registered However, in this document, the response codes have been classified
following an HTTP-style code numbering in this document. New and registered following an HTTP-style code numbering. New response
response codes should be classified following the guidelines below: 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 (RTP_Rx) Error 4xx RTP Receiver (RTP_Rx) Error
5xx Burst/Retransmission Source (BRS) Error 5xx Burst/Retransmission Source (BRS) Error
The Response code 65535 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 [RFC6285]
100 Parameter update for RAMS session [RFCXXXX]
200 RAMS request has been accepted [RFCXXXX] 100 Parameter update for RAMS session [RFC6285]
201 Unicast burst has been completed [RFCXXXX]
400 Invalid RAMS-R message syntax [RFCXXXX] 200 RAMS request has been accepted [RFC6285]
401 Invalid min buffer requirement in RAMS-R message [RFCXXXX] 201 Unicast burst has been completed [RFC6285]
402 Invalid max buffer requirement in RAMS-R message [RFCXXXX]
403 Insufficient max bitrate requirement in RAMS-R
message [RFCXXXX]
404 Invalid RAMS-T message syntax [RFCXXXX]
500 An unspecified BRS internal error has occurred [RFCXXXX] 400 Invalid RAMS-R message syntax [RFC6285]
501 BRS has insufficient bandwidth to start RAMS 401 Invalid min buffer requirement in RAMS-R message [RFC6285]
session [RFCXXXX] 402 Invalid max buffer requirement in RAMS-R message [RFC6285]
502 Burst is terminated due to network congestion [RFCXXXX] 403 Insufficient max bitrate requirement in RAMS-R
503 BRS has insufficient CPU cycles to start RAMS message [RFC6285]
session [RFCXXXX] 404 Invalid RAMS-T message syntax [RFC6285]
504 RAMS functionality is not available on BRS [RFCXXXX]
505 RAMS functionality is not available for RTP_Rx [RFCXXXX]
506 RAMS functionality is not available for
the requested multicast stream [RFCXXXX]
507 BRS has no valid starting point available for
the requested multicast stream [RFCXXXX]
508 BRS has no reference information available for
the requested multicast stream [RFCXXXX]
509 BRS has no RTP stream matching the requested SSRC [RFCXXXX]
510 RAMS request to acquire the entire session
has been denied [RFCXXXX]
511 Only the preamble information is sent [RFCXXXX]
512 RAMS request has been denied due to a policy [RFCXXXX]
500 An unspecified BRS internal error has occurred [RFC6285]
501 BRS has insufficient bandwidth to start RAMS
session [RFC6285]
502 Burst is terminated due to network congestion [RFC6285]
503 BRS has insufficient CPU cycles to start RAMS
session [RFC6285]
504 RAMS functionality is not available on BRS [RFC6285]
505 RAMS functionality is not available for RTP_Rx [RFC6285]
506 RAMS functionality is not available for
the requested multicast stream [RFC6285]
507 BRS has no valid starting point available for
the requested multicast stream [RFC6285]
508 BRS has no reference information available for
the requested multicast stream [RFC6285]
509 BRS has no RTP stream matching the requested SSRC [RFC6285]
510 RAMS request to acquire the entire session
has been denied [RFC6285]
511 Only the preamble information is sent [RFC6285]
512 RAMS request has been denied due to a policy [RFC6285]
Any registration for an unassigned Response code needs to contain the Any registration for an unassigned Response code needs to contain the
following information: following information:
o Contact information of the one doing the registration, including o Contact information of the one doing the registration, including
at least name, address, and email. at least name, address, and email.
o A detailed description of what the new Response code describes and o A detailed description of what the new Response code describes and
how it shall be interpreted. how it shall be interpreted.
12. Contributors 12. Contributors
Dave Oran, Magnus Westerlund and Colin Perkins have contributed Dave Oran, Magnus Westerlund, and Colin Perkins have contributed
significantly to this specification by providing text and solutions significantly to this specification by providing text and solutions
to some of the issues raised during the development of this to some of the issues raised during the development of this
specification. specification.
13. Acknowledgments 13. Acknowledgments
The following individuals have reviewed the earlier versions of this The following individuals reviewed earlier versions of this
specification and provided helpful comments: Joerg Ott, Roni Even, specification and provided helpful comments: Joerg Ott, Roni Even,
Dan Wing, Tony Faustini, Peilin Yang, Jeff Goldberg, Muriel Dan Wing, Tony Faustini, Peilin Yang, Jeff Goldberg, Muriel
Deschanel, Orit Levin, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui Deschanel, Orit Levin, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui
Wang, Zixuan Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan Wang, Zixuan Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan
Lennox, Jose Rey, Sean Sheedy and Keith Drage. Lennox, Jose Rey, Sean Sheedy, and Keith Drage.
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, October 2002.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute
in Session Description Protocol (SDP)", RFC 3605,
October 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, August 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006. July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Protocol (RTCP) Extensions for Single-Source Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010. Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, August 2006.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009.
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
in Session Description Protocol (SDP)", RFC 3605, "Transport Layer Security (TLS) Session Resumption without
October 2003. Server-Side State", RFC 5077, January 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [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 [RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Header Extensions", RFC 5285, July 2008. Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Flows", RFC 6051, November 2010. Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [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]
Begen, A., "RTP Control Protocol (RTCP) Port for Source-
Specific Multicast (SSM) Sessions",
draft-ietf-avt-rtcp-port-for-ssm-03 (work in progress),
October 2010.
[I-D.ietf-avt-ports-for-ucast-mcast-rtp]
Begen, A. and B. Steeg, "Port Mapping Between Unicast and
Multicast RTP Sessions",
draft-ietf-avt-ports-for-ucast-mcast-rtp-02 (work in
progress), May 2010.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
"Transport Layer Security (TLS) Session Resumption without Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
Server-Side State", RFC 5077, January 2008.
14.2. Informative References [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", RFC 6051, November 2010.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC6128] Begen, A., "RTP Control Protocol (RTCP) Port for Source-
August 1980. Specific Multicast (SSM) Sessions", RFC 6128,
February 2011.
[I-D.begen-avt-rams-scenarios] [RFC6284] Begen, A., Wing, D., and T. Van Caenegem, "Port Mapping
Begen, A., "Considerations for RAMS Scenarios", Between Unicast and Multicast RTP Sessions", RFC 6284,
draft-begen-avt-rams-scenarios-00 (work in progress), June 2011.
October 2009.
[I-D.ietf-avt-rtp-cnames] 14.2. Informative References
Begen, A., Perkins, C., and D. Wing, "Guidelines for
Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs)", draft-ietf-avt-rtp-cnames-02 (work in
progress), November 2010.
[I-D.ietf-avt-multicast-acq-rtcp-xr] [ECN-FOR-RTP]
Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", Work in Progress, May 2011.
[IC2009] Begen, A., Glazebrook, N., and W. Ver Steeg, "Reducing
Channel Change Times in IPTV with Real-Time Transport
Protocol (IEEE Internet Computing)", May 2009.
[MULTICAST-ACQ]
Begen, A. and E. Friedrich, "Multicast Acquisition Report 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)", Work in Progress, May 2011.
(work in progress), May 2010.
[I-D.ietf-avt-ecn-for-rtp] [RAMS-SCENARIOS]
Westerlund, M., Johansson, I., Perkins, C., and K. Begen, A., "Considerations and Guidelines for Deploying
Carlberg, "Explicit Congestion Notification (ECN) for RTP the Rapid Acquisition of Multicast Sessions (RAMS)
over UDP", draft-ietf-avt-ecn-for-rtp-03 (work in Method", Work in Progress, June 2011.
progress), October 2010.
[RFC6015] Begen, A., "RTP Payload Format for 1-D Interleaved Parity [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
Forward Error Correction (FEC)", RFC 6015, October 2010. August 1980.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5762] Perkins, C., "RTP and the Datagram Congestion Control [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] [RFC6015] Begen, A., "RTP Payload Format for 1-D Interleaved Parity
McGrew, D., Andreasen, F., Wing, D., and K. Fischer, Forward Error Correction (FEC)", RFC 6015, October 2010.
"Encrypted Key Transport for Secure RTP",
draft-ietf-avt-srtp-ekt-01 (work in progress), July 2010.
[UPnP-IGD] [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for
Forum, UPnP., "Universal Plug and Play (UPnP) Internet Choosing RTP Control Protocol (RTCP) Canonical Names
Gateway Device (IGD)", November 2001. (CNAMEs)", RFC 6222, April 2011.
[IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing [SRTP-EKT] McGrew, D., Andreasen, F., Wing, D., and K. Fischer,
Channel Change Times in IPTV with Real-Time Transport "Encrypted Key Transport for Secure RTP", Work
Protocol (IEEE Internet Computing)", May 2009. in Progress, March 2011.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [UPnP-IGD] UPnP Forum, "Universal Plug and Play (UPnP) Internet
IANA Considerations Section in RFCs", BCP 26, RFC 5226, Gateway Device (IGD)", December 2010.
May 2008.
Authors' Addresses Authors' Addresses
Bill VerSteeg Bill Ver Steeg
Cisco Cisco
5030 Sugarloaf Parkway 5030 Sugarloaf Parkway
Lawrenceville, GA 30044 Lawrenceville, GA 30044
USA USA
Email: billvs@cisco.com EMail: billvs@cisco.com
Ali Begen Ali Begen
Cisco Cisco
181 Bay Street 181 Bay Street
Toronto, ON M5J 2T3 Toronto, ON M5J 2T3
Canada Canada
Email: abegen@cisco.com EMail: abegen@cisco.com
Tom VanCaenegem
Tom Van Caenegem
Alcatel-Lucent Alcatel-Lucent
Copernicuslaan 50 Copernicuslaan 50
Antwerpen, 2018 Antwerpen 2018
Belgium Belgium
Email: Tom.Van_Caenegem@alcatel-lucent.be EMail: Tom.Van_Caenegem@alcatel-lucent.be
Zeev Vax Zeev Vax
Microsoft Corporation Magnum Semiconductor, Inc.
1065 La Avenida 591 Yosemite Drive
Mountain View, CA 94043 Milpitas, CA 95035
USA USA
Email: zeevvax@microsoft.com EMail: zeev.vax@magnumsemi.com
 End of changes. 224 change blocks. 
670 lines changed or deleted 652 lines changed or added

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