draft-ietf-avt-rapid-acquisition-for-rtp-05.txt   draft-ietf-avt-rapid-acquisition-for-rtp-06.txt 
AVT B. VerSteeg AVT B. VerSteeg
Internet-Draft A. Begen Internet-Draft A. Begen
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: May 20, 2010 T. VanCaenegem Expires: August 8, 2010 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Z. Vax Z. Vax
Microsoft Corporation Microsoft Corporation
November 16, 2009 February 4, 2010
Unicast-Based Rapid Acquisition of Multicast RTP Sessions Unicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-ietf-avt-rapid-acquisition-for-rtp-05 draft-ietf-avt-rapid-acquisition-for-rtp-06
Abstract Abstract
When an RTP receiver joins a primary multicast session, it may need When an RTP receiver joins a multicast session, it may need to
to acquire and parse certain Reference Information before it can acquire and parse certain Reference Information before it can process
process any data sent in the multicast session. Depending on the any data sent in the multicast session. Depending on the join time,
join time, length of the Reference Information repetition interval, length of the Reference Information repetition (or appearance)
size of the Reference Information as well as the application and interval, size of the Reference Information as well as the
transport properties, the time lag before an RTP receiver can application and transport properties, the time lag before an RTP
usefully consume the multicast data, which we refer to as the receiver can usefully consume the multicast data, which we refer to
Acquisition Delay, varies and may be large. This is an undesirable as the Acquisition Delay, varies and may be large. This is an
phenomenon for receivers that frequently switch among different undesirable phenomenon for receivers that frequently switch among
multicast sessions, such as video broadcasts. different multicast sessions, such as video broadcasts.
In this document, we describe a method using the existing RTP and In this document, we describe a method using the existing RTP and
RTCP protocol machinery that reduces the acquisition delay. In this RTCP protocol machinery that reduces the acquisition delay. In this
method, an auxiliary unicast RTP session carrying the Reference method, an auxiliary unicast RTP session carrying the Reference
Information to the receiver precedes/accompanies the primary Information to the receiver precedes/accompanies the multicast
multicast stream. This unicast RTP flow may be transmitted at a stream. This unicast RTP flow may be transmitted at a faster than
faster than natural rate to further accelerate the acquisition. The natural rate to further accelerate the acquisition. The motivating
motivating use case for this capability is multicast applications use case for this capability is multicast applications that carry
that carry real-time compressed audio and video. However, the real-time compressed audio and video. However, the proposed method
proposed method can also be used in other types of multicast can also be used in other types of multicast applications where the
applications where the acquisition delay is long enough to be a acquisition delay is long enough to be a problem.
problem.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 16 skipping to change at page 2, line 14
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 20, 2010. This Internet-Draft will expire on August 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 8 skipping to change at page 3, line 8
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7 1.1. Acquisition of RTP Streams vs. RTP Sessions . . . . . . . 7
1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 8
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Elements of Delay in Multicast Applications . . . . . . . . . 8 4. Elements of Delay in Multicast Applications . . . . . . . . . 10
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 . . . . . . . . . . 11
6. Rapid Acquisition of Multicast RTP Sessions . . . . . . . . . 12 6. Rapid Acquisition of Multicast RTP Sessions . . . . . . . . . 13
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 14
6.3. Shaping the Unicast Burst . . . . . . . . . . . . . . . . 21 6.3. Synchronization of Primary Multicast Streams . . . . . . 23
6.4. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 23 6.4. Shaping the Unicast Burst . . . . . . . . . . . . . . . . 24
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 24 6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 25 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 27
7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 25 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . 27
7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 26 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 28
7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 26 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 28
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 28 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . 29
7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 30 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . 32
8. SDP Definitions and Examples . . . . . . . . . . . . . . . . . 31 7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . 34
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 31 8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 35
8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 35
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 35 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 36
10. Known Implementations . . . . . . . . . . . . . . . . . . . . 35 8.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1. Open Source RTP Receiver Implementation by Cisco . . . . . 35 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 39
10.2. IPTV Commercial Implementation by Microsoft . . . . . . . 36 10. Congestion Control Considerations . . . . . . . . . . . . . . 40
11. Security Considerations . . . . . . . . . . . . . . . . . . . 36 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
12.1. Registration of SDP Attributes . . . . . . . . . . . . . . 38 12.1. Registration of SDP Attributes . . . . . . . . . . . . . 42
12.2. Registration of SDP Attribute Values . . . . . . . . . . . 38 12.2. Registration of SDP Attribute Values . . . . . . . . . . 43
12.3. Registration of FMT Values . . . . . . . . . . . . . . . . 38 12.3. Registration of FMT Values . . . . . . . . . . . . . . . 43
12.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 39 12.4. SFMT Values for RAMS Messages Registry . . . . . . . . . 43
12.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 39 12.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 44
12.6. RAMS Response Code Space Registry . . . . . . . . . . . . 40 12.6. RAMS Response Code Space Registry . . . . . . . . . . . . 45
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 47
14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 42 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47
14.1. draft-ietf-avt-rapid-acquisition-for-rtp-05 . . . . . . . 42 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 47
14.2. draft-ietf-avt-rapid-acquisition-for-rtp-04 . . . . . . . 42 15.1. draft-ietf-avt-rapid-acquisition-for-rtp-06 . . . . . . . 47
14.3. draft-ietf-avt-rapid-acquisition-for-rtp-03 . . . . . . . 42 15.2. draft-ietf-avt-rapid-acquisition-for-rtp-05 . . . . . . . 47
14.4. draft-ietf-avt-rapid-acquisition-for-rtp-02 . . . . . . . 42 15.3. draft-ietf-avt-rapid-acquisition-for-rtp-04 . . . . . . . 47
14.5. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 43 15.4. draft-ietf-avt-rapid-acquisition-for-rtp-03 . . . . . . . 48
14.6. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 43 15.5. draft-ietf-avt-rapid-acquisition-for-rtp-02 . . . . . . . 48
14.7. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 43 15.6. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 48
14.8. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 43 15.7. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 48
14.9. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 44 15.8. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 49
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 15.9. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 49
15.1. Normative References . . . . . . . . . . . . . . . . . . . 44 15.10. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 49
15.2. Informative References . . . . . . . . . . . . . . . . . . 45 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 16.1. Normative References . . . . . . . . . . . . . . . . . . 50
16.2. Informative References . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
Most multicast flows carry a stream of inter-related data. Certain Most multicast flows carry a stream of inter-related data. Certain
information must first be acquired by the receivers to start information must first be acquired by the receivers to start
processing any data sent in the multicast session. This document processing any data sent in the multicast session. This document
refers to this information as Reference Information. The Reference refers to this information as Reference Information. The Reference
Information is conventionally sent periodically in the multicast Information is conventionally sent periodically in the multicast
session and usually consists of items such as a description of the session (although its content may change over time) and usually
schema for the rest of the data, references to which data to process, consists of items such as a description of the schema for the rest of
encryption information including keys, as well as any other the data, references to which data to process, encryption information
information required to process the data in the primary multicast including keys, as well as any other information required to process
stream. the data in the multicast stream [IC2009].
Real-time multicast applications require the receivers to buffer Real-time multicast applications require the receivers to buffer
data. The receiver may have to buffer data to smooth out the network data. The receiver may have to buffer data to smooth out the network
jitter, to allow loss-repair methods such as Forward Error Correction jitter, to allow loss-repair methods such as Forward Error Correction
and retransmission to recover the missing packets, and to satisfy the and 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 may join the session right before the Reference Information receiver may join the session right before the Reference Information
skipping to change at page 5, line 45 skipping to change at page 5, line 45
arrive before starting to process the rest of the data. arrive before starting to process the rest of the 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 the receivers may experience for various buffers to fill up is that the receivers may 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 joins the refer to the difference between the time an RTP receiver joins the
multicast session and the time the RTP receiver acquires all the multicast session and the time the RTP receiver acquires all the
necessary Reference Information as the Acquisition Delay. The necessary Reference Information as the Acquisition Delay. The
acquisition delay may not be the same for different receivers; it acquisition delay may 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 interval, size of the Reference Information as Information repetition (or appearance) interval, size of the
well as the application and transport properties. Reference Information as well as the application and transport
properties.
The varying nature of the acquisition delay adversely affects the The varying nature of the acquisition delay adversely affects the
receivers that frequently switch among multicast sessions. In this receivers that frequently switch among multicast sessions. In this
specification, we address this problem for RTP-based multicast specification, we address this problem for RTP-based multicast
applications and describe a method that uses the fundamental tools applications and describe a method that uses the fundamental tools
offered by the existing RTP and RTCP protocols [RFC3550]. In this offered by the existing RTP and RTCP protocols [RFC3550]. In this
method, either the multicast source (or the distribution source in a method, either the multicast source (or the distribution source in a
single-source multicast (SSM) session) retains the Reference source-specific multicast (SSM) session) retains the Reference
Information for a period after its transmission, or an intermediary Information for a period after its transmission, or an intermediary
network element (that we refer to as Retransmission Server) joins the network element (that we refer to as Retransmission Server) joins the
multicast session and continuously caches the Reference Information multicast session and continuously caches the Reference Information
as it is sent in the session and acts as a feedback target (See as it is sent in the session and acts as a feedback target (See
[I-D.ietf-avt-rtcpssm]) for the session. When an RTP receiver wishes [I-D.ietf-avt-rtcpssm]) for the session. When an RTP receiver wishes
to join the same multicast session, instead of simply issuing a to join the same multicast session, instead of simply issuing a
Source Filtering Group Management Protocol (SFGMP) Join message, it Source Filtering Group Management Protocol (SFGMP) Join message, it
sends a request to the feedback target for the session asking for the sends a request to the feedback target for the session and asks for
Reference Information. The Retransmission Server starts a unicast the Reference Information. The Retransmission Server starts a new
retransmission RTP session and sends the Reference Information to the unicast RTP (retransmission) session and sends the Reference
RTP receiver over that session. If there is spare bandwidth, the Information to the RTP receiver over that session. If there is spare
Retransmission Server may also burst the Reference Information at a bandwidth, the Retransmission Server may burst the Reference
faster than its natural rate. As soon as the receiver acquires the Information faster than its natural rate. As soon as the receiver
Reference Information, it can join the multicast session and start acquires the Reference Information, it can join the multicast session
processing the multicast data. This method potentially reduces the and start processing the multicast data. A simplified network
acquisition delay. We refer to this method as Unicast-based Rapid diagram showing this method through an intermediary network element
Acquisition of Multicast RTP Sessions. A simplified network diagram is depicted in Figure 1.
showing this method through an intermediary network element is
depicted in Figure 1.
+-----------------------+ This method potentially reduces the acquisition delay. We refer to
this method as Unicast-based Rapid Acquisition of Multicast RTP
Sessions. A primary use case for this method is to reduce the
channel-change times in IPTV networks where compressed video streams
are multicast in different SSM sessions and viewers randomly join
these sessions.
-----------------------
+--->| Intermediary | +--->| Intermediary |
| ...| Network Element | | | Network Element |
| : |(Retransmission Server)| | ...|(Retransmission Server)|
| : +-----------------------+ | : -----------------------
| : | :
| v | v
+-----------+ +----------+ +----------+ ----------- ---------- ----------
| Multicast | | Router |---------->| Joining | | Multicast | | |---------->| Joining |
| Source |------->| |..........>| RTP | | Source |------->| Router |..........>| RTP |
+-----------+ +----------+ | Receiver | | | | | | Receiver |
| +----------+ ----------- ---------- ----------
| |
| +----------+ | ----------
+---------------->| Existing | +---------------->| Existing |
| RTP | | RTP |
| Receiver | | Receiver |
+----------+ ----------
...> Unicast RTP Flow -------> Multicast RTP Flow
---> Multicast RTP Flow .......> Unicast RTP Flow
Figure 1: Rapid acquisition through an intermediary network element Figure 1: Rapid acquisition through an intermediary network element
A primary 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. The to handle the signaling needed to accomplish the acquisition.
packet(s) carrying the Reference Information are sent by the
Retransmission Server in the auxiliary unicast RTP session for rapid 1.1. Acquisition of RTP Streams vs. RTP Sessions
acquisition. These are constructed as retransmission packets that
would have been sent in a unicast RTP session to recover the missing By the definition given in [RFC3550], an RTP session may involve one
packets at an RTP receiver that has never received any packet. In or more RTP streams each identified with a unique SSRC. All RTP
fact, a single RTP session SHOULD be used for both rapid acquisition streams within a single RTP session are sent towards the same
and retransmission-based loss repair. This session can be used to transport address, i.e., they share the same destination IP address
simultaneously provide the unicast burst for the rapid acquisition and port. In RTP jargon, these streams are said to be SSRC-
and the repair packets requested by the RTP receivers when they multiplexed. On the other hand, an SSM session is uniquely
detect lost burst packets or lost RTP packets in the primary identified by its source address and destination group address.
multicast stream. The conventional RTCP feedback (NACK) message that However, it may carry one or more RTP sessions, each associated with
requests the retransmission of the missing packets [RFC4585] a different destination port. Consequently, while it is not very
indicates their sequence numbers. However, upon joining a new practical, it is still possible for an SSM session to carry multiple
session the RTP receiver has never received a packet, and thus, does RTP sessions each carrying multiple SSRC-multiplexed RTP streams.
not know the sequence numbers. Instead, the RTP receiver sends a
newly defined RTCP feedback message to request the Reference Developing a protocol that can jointly handle the rapid acquisition
Information needed to rapidly get on the track with the primary of all of the RTP sessions in an SSM session is neither practical nor
multicast session. It is also worth noting that in order to issue necessary. Rather, in this specification we focus on developing a
the initial RTCP message to the feedback target, the SSRC of the protocol that handles the rapid acquisition of a single RTP session
session to be joined must be known prior to any packet reception, and (called primary multicast RTP session) carrying one or more RTP
hence, needs to be signaled out-of-band (or otherwise communicated to streams (called primary multicast streams). If desired, multiple
the RTP receiver in advance of the initiation of the rapid instances of this protocol may be run in parallel to acquire multiple
acquisition operation). In a Session Description Protocol (SDP) RTP sessions simultaneously.
description, the SSRC MUST be signaled through the 'ssrc' attribute
[I-D.ietf-avt-rtcpssm]. When an RTP receiver requests the Reference Information from the
Retransmission Server, it may opt to rapidly acquire a specific
subset of the available RTP streams in the primary multicast RTP
session. Alternatively, it may request the rapid acquisition of all
of the RTP streams in that RTP session. Regardless of how many RTP
streams are requested by the RTP receiver or how many will be
actually sent by the Retransmission Server, only one unicast RTP
(retransmission) session will be established by the Retransmission
Server serving as the feedback target for that RTP session. The RTP
receiver multiplexes this unicast RTP session with the primary
multicast RTP session it receives as part of the SSM session. If the
RTP receiver wants to rapidly acquire multiple RTP sessions
simultaneously, separate unicast RTP (retransmission) sessions will
be established for each of them.
1.2. Outline
In the rest of this specification, we have the following outline: In In the rest of this specification, we have the following outline: In
Section 4, we describe the delay components in generic multicast Section 4, we describe the delay components in generic multicast
applications. Section 5 presents an overview of the protocol design applications. Section 5 presents an overview of the protocol design
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 Section 6 and Section 7.
Section 8 and Section 9 discuss the SDP signaling issues with Section 8 and Section 9 discuss the SDP signaling issues with
examples and NAT-related issues, respectively. examples and NAT-related issues, respectively. Section 10 and
Section 11 discuss the congestion control and security
considerations, respectively.
Note that Section 3 provides a list of the definitions frequently Section 3 provides a list of the definitions frequently used in this
used in this document. 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 Multicast Session: The multicast RTP session to which RTP (Primary) SSM (or Multicast) Session: The multicast session to which
receivers can join at a random point in time. RTP receivers can join at a random point in time.
Primary Multicast Stream: The RTP stream carried in the primary Primary Multicast RTP Session: The multicast RTP session an RTP
multicast session. receiver is interested in acquiring rapidly. A primary SSM session
may carry multiple multicast RTP sessions, but only one of them can
be the primary from the viewpoint of rapid acquisition.
Primary Multicast (RTP) Streams: The RTP stream(s) carried in the
primary multicast RTP session.
Source Filtering Group Management Protocol (SFGMP): Following the Source Filtering Group Management Protocol (SFGMP): Following the
definition in [RFC4604], SFGMP refers to the Internet Group definition in [RFC4604], SFGMP refers to the Internet Group
Management Protocol (IGMP) version 3 [RFC3376] and the Multicast Management Protocol (IGMP) version 3 [RFC3376] and the Multicast
Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and
IPv6 networks, respectively. However, the rapid acquisition method IPv6 networks, respectively. However, the rapid acquisition method
introduced in this document does not depend on a specific version of introduced in this document does not depend on a specific version of
either of these group management protocols. In the remainder of this either of these group management protocols. In the remainder of this
document, SFGMP will refer to any group management protocol that has document, SFGMP will refer to any group management protocol that has
Join and Leave functionalities. Join and Leave functionalities.
Feedback Target: (Unicast RTCP) Feedback target as defined in Feedback Target (FT): Unicast RTCP feedback target as defined in
[I-D.ietf-avt-rtcpssm]. [I-D.ietf-avt-rtcpssm]. FT_Ap denotes a specific feedback target
running on a particular address and port.
Retransmission Packet: An RTP packet that is formatted as defined in Retransmission Packet: An RTP packet that is formatted as defined in
[RFC4588]. [RFC4588].
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 scope of
this document. this document.
Preamble Information: A more compact form of the whole or a subset
of the Reference Information transmitted out-of-band.
(Unicast) Burst (Stream): A unicast stream of RTP retransmission (Unicast) Burst (Stream): A unicast stream of RTP retransmission
packets that enable an RTP receiver to rapidly acquire the Reference packets that enable an RTP receiver to rapidly acquire the Reference
Information. The burst stream is typically transmitted at an Information associated with a primary multicast stream. Each burst
accelerated rate. stream is identified by its unique SSRC identifier in the primary
multicast RTP session. The burst streams are typically transmitted
at an accelerated rate.
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 stream. RS may also the retransmission packets and the burst streams. RS may also
generate other non-retransmission packets to aid the RAMS process. generate other non-retransmission packets to aid the rapid
acquisition process.
4. Elements of Delay in Multicast Applications 4. Elements of Delay in Multicast Applications
In an any-source (ASM) or a single-source (SSM) multicast delivery In an any-source (ASM) or a source-specific (SSM) multicast delivery
system, there are three major elements that contribute to the overall system, there are three major elements that contribute to the overall
acquisition delay when an RTP receiver switches from one multicast acquisition delay when an RTP receiver switches from one multicast
session to another one. These are: session to another one. These are:
o Multicast switching delay o Multicast switching delay
o Reference Information latency o Reference Information latency
o Buffering delays o Buffering delays
skipping to change at page 10, line 4 skipping to change at page 11, line 11
carry compressed audio/video. For these flows, the Reference carry compressed audio/video. For these flows, the Reference
Information latency may become quite large and be a major contributor Information latency may become quite large and be a major contributor
to the overall delay. Refer to [I-D.begen-avt-rtp-mpeg2ts-preamble] to the overall delay. Refer to [I-D.begen-avt-rtp-mpeg2ts-preamble]
for details. for details.
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
multicast applications, an unreliable transport protocol such as UDP multicast applications, an unreliable transport protocol such as UDP
[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 and retransmission as Forward Error Correction (e.g.,
[I-D.ietf-rmt-pi-norm-revised]. These loss-repair methods require [I-D.ietf-fecframe-interleaved-fec-scheme]) and retransmission.
buffering at the receiver side to function properly. In many These loss-repair methods require buffering at the receiver side to
applications, it is also often necessary to de-jitter the incoming function properly. In many applications, it is also often necessary
data packets before feeding them to the application. The de- to de-jitter the incoming data packets before feeding them to the
jittering process also increases the buffering delays. Besides these application. The de-jittering process also increases the buffering
network-related buffering delays, there are also specific buffering delays. Besides these network-related buffering delays, there are
needs that are required by the individual applications. For example, also specific buffering needs that are required by the individual
standard video decoders typically require an amount, sometimes a applications. For example, standard video decoders typically require
significant amount, of coded video data to be available in the pre- an amount, sometimes a significant amount, of coded video data to be
decoding buffers prior to starting to decode the video bitstream. available in the pre-decoding buffers prior to starting to 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
Rapid acquisition is an optimization of a system that must continue Rapid acquisition is an optimization of a system that must continue
to work correctly whether or not the optimization is effective, or to work correctly and properly whether or not the optimization is
even fails due to lost control messages, congestion, or other effective, or even fails due to lost control and feedback messages,
problems. This is fundamental to the overall design requirements congestion, or other problems. This is fundamental to the overall
surrounding the protocol definition and to the resource management design requirements surrounding the protocol definition and to the
schemes to be employed together with the protocol (e.g., QoS resource management schemes to be employed together with the protocol
machinery, server load management, etc). In particular, the system (e.g., QoS machinery, server load management, etc). In particular,
needs to operate within a number of constraints: the system 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, except perhaps in pathological user experience must, except perhaps in pathological
circumstances, be not significantly worse for trying and failing circumstances, be not significantly worse for trying and failing
to complete rapid acquisition compared to simply joining the to complete rapid acquisition compared to simply joining the
multicast session. multicast session.
o Second, providing the rapid acquisition optimizations must not o Second, providing the rapid acquisition optimizations must not
cause collateral damage to either the multicast session being cause collateral damage to either the multicast session being
joined, or other multicast sessions sharing resources with the joined, or other multicast sessions sharing resources with the
rapid acquisition operation. In particular, the rapid acquisition rapid acquisition operation. In particular, the rapid acquisition
operation must avoid self-interference with the multicast session operation must avoid interference with the multicast session that
that may be simultaneously being received by other hosts. In may be simultaneously being received by other hosts. In addition,
addition, it must also avoid interference with other multicast it must also avoid interference with other multicast sessions
sessions sharing the same network resources. These properties are sharing the same network resources. These properties are
possible, but are usually difficult to achieve. 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, DOCSIS) and in the home network of the subscribers. Some
of these links may serve only a single subscriber, limiting of these links may serve only a single subscriber, limiting
congestion impact to the traffic of only that subscriber, but others congestion impact to the traffic of only that subscriber, but others
skipping to change at page 11, line 31 skipping to change at page 12, line 39
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 RSVP have too much
latency and control channel overhead to be a good fit for rapid latency and control channel overhead to be a good fit for rapid
acquisition. Similarly, using a TCP (or TCP-like) approach with a acquisition. Similarly, using a TCP (or TCP-like) approach with a
3-way handshake and slow-start to avoid inducing congestion would 3-way handshake and slow-start to avoid inducing congestion would
defeat the purpose of attempting rapid acquisition in the first place defeat the purpose of attempting rapid acquisition in the first place
by introducing many RTTs of delay. by introducing many round-trip times (RTT) 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 stream, and e is the nominal bandwidth of the primary multicast streams, and e is
an "excess-bandwidth" coefficient The total duration of the an excess-bandwidth coefficient. The total duration of the
unicast burst must have a reasonable bound; long unicast bursts unicast burst must have a reasonable bound; long unicast bursts
devolve to the bandwidth profile of multi-unicast for the whole devolve to 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.
skipping to change at page 12, line 41 skipping to change at page 13, line 47
multicast sessions (RAMS) method. multicast sessions (RAMS) method.
6.1. Overview 6.1. Overview
[I-D.ietf-avt-rtcpssm] specifies an extension to the RTP Control [I-D.ietf-avt-rtcpssm] specifies an extension to the RTP Control
Protocol (RTCP) to use unicast feedback in an SSM session. It Protocol (RTCP) to use unicast feedback in an SSM session. It
defines an architecture that introduces the concept of Distribution defines an architecture that introduces the concept of Distribution
Source, which - in an SSM context - distributes the RTP data and Source, which - in an SSM context - distributes the RTP data and
redistributes RTCP information to all RTP receivers. This RTCP redistributes RTCP information to all RTP receivers. This RTCP
information is retrieved from the Feedback Target, to which RTCP information is retrieved from the Feedback Target, to which RTCP
unicast feedback traffic is sent. The Feedback Target MAY be unicast feedback traffic is sent. The feedback target MAY be
implemented in one or more entities different from the Distribution implemented in one or more entities different from the Distribution
Source, and different RTP receivers MAY use different Feedback Source, 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 time 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 session are the most recent packets from the primary multicast RTP session are
continuously stored. When an RTP receiver wants to receive the continuously stored. When an RTP receiver wants to receive a primary
primary multicast stream, prior to joining the SSM session, it may multicast stream prior to joining the SSM session, it may first
first request a unicast burst from the Burst Source. In this burst, request a unicast burst from the Burst Source. In this burst, the
the packets are formatted as RTP retransmission packets [RFC4588] and packets are formatted as RTP retransmission packets [RFC4588] and
carry the Reference Information. This information allows the RTP carry the Reference Information. This information allows the RTP
receiver to start usefully consuming the RTP packets sent in the receiver to start usefully consuming the RTP packets sent in the
primary multicast session. primary multicast RTP session.
Using an accelerated rate (as compared to the rate of the primary Using an accelerated rate (as compared to the nominal rate of the
multicast stream) for the unicast burst implies that at a certain primary multicast stream) for the unicast burst implies that at a
point in time, the payload transmitted in the unicast burst is going certain point in time, the payload transmitted in the unicast burst
to be the same as the payload multicast in the SSM session, i.e., the is going to be the same as the payload in the associated multicast
unicast burst will catch up with the primary multicast stream. At stream, i.e., the unicast burst will catch up with the primary
this point, the RTP receiver no longer needs to receive the unicast multicast stream. At this point, the RTP receiver no longer needs to
burst and can join the primary multicast session. This method is receive the unicast burst and can join the SSM session. This method
referred to as the Rapid Acquisition of Multicast Sessions (RAMS). is referred to as the Rapid Acquisition of Multicast Sessions (RAMS).
This document proposes extensions to [RFC4585] for an RTP receiver to This document proposes 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: Figure 2 shows the main entities involved in rapid acquisition and
the message flows. They are
o Multicast Source o Multicast Source
o Feedback Target (FT) o Feedback Target (FT)
o Burst/Retransmission Source o Burst/Retransmission Source
o RTP Receiver (RTP_Rx) o RTP Receiver (RTP_Rx)
+----------------------------------------------+ ----------- ---------------- --------------
| Retransmission Server | | | | Retransmission | | |
| (RS) | | Multicast |------->| Server (RS) |--------->| |
| +----------+ +---------------------------+ | | Source |.-.-.-.>| |.-.-.-.-.>| |
| | Feedback | | Burst/Retransmission | | | | | ------------ | | |
| | Target | | Source | | ----------- | | Feedback | |<.=.=.=.=.| |
| +----------+ +---------------------------+ | | | Target | |<~~~~~~~~~| RTP Receiver |
+----------------------------------------------+ | ------------ | | (RTP_Rx) |
^ ^ : | | | |
| ' : | ------------ | | |
| ' : | | Burst and | |<~~~~~~~~>| |
| ' v | | Retrans. | |.........>| |
+-----------+ +----------+ +----------+ | | Source | |<.=.=.=.=>| |
| | | |'''''''''''>| | | ------------ | | |
| Multicast |------->| Router |...........>| RTP | | | | |
| Source | | |<~~~~~~~~~~~| Receiver | ---------------- --------------
| | | |----------->| (RTP_Rx) |
+-----------+ +----------+ +----------+
'''> Unicast RTCP Messages -------> Multicast RTP Flow
~~~> SFGMP Messages .-.-.-.> Multicast RTCP Flow
...> Unicast RTP Flow .=.=.=.> Unicast RTCP Reports
---> Multicast RTP Flow ~~~~~~~> Unicast RTCP Feedback Messages
.......> 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 The feedback target (FT) is the entity as defined in
[I-D.ietf-avt-rtcpssm], to which RTP_Rx sends its RTCP feedback [I-D.ietf-avt-rtcpssm], to which RTP_Rx sends its RTCP feedback
messages indicating packet loss in the primary multicast stream by messages indicating packet loss by means of an RTCP NACK message or
means of an RTCP NACK message or indicating RTP_Rx's desire to indicating RTP_Rx's desire to rapidly acquire the primary multicast
rapidly acquire the primary multicast stream by means of an RTCP RTP session by means of an RTCP feedback message defined in this
feedback message defined in this document. While the Burst/ document. While the Burst/Retransmission Source is responsible for
Retransmission Source is responsible for responding to these messages responding to these messages and for further RTCP interaction with
and for further RTCP interaction with RTP_Rx in the case of a rapid RTP_Rx in the case of a rapid acquisition process, it is assumed in
acquisition process, it is assumed in the remainder of the document the remainder of the document that these two logical entities (FT and
that these two logical entities (FT and Burst/Retransmission Source) Burst/Retransmission Source) are combined in a single physical entity
are combined in a single physical entity and they share state. In and they share state. In the remainder of the text, the term
the remainder of the text, the term Retransmission Server will be Retransmission Server (RS) will be used whenever appropriate, to
used whenever appropriate, to refer to the combined functionality of refer to the combined functionality of the FT and Burst/
the FT and Burst/Retransmission Source. Retransmission Source.
However, it must be noted that only FT is involved in the primary However, it must be noted that only FT is involved in the primary
multicast session, whereas the Burst/Retransmission Source transmits multicast RTP session, whereas the Burst/Retransmission Source
the unicast burst and retransmission packets both formatted as RTP transmits the unicast burst and retransmission packets both formatted
retransmission packets [RFC4588] in a single separate unicast RTP as RTP retransmission packets [RFC4588] in a single separate unicast
retransmission session to each RTP_Rx. In the retransmission RTP retransmission session to each RTP_Rx. In the retransmission
session, as in any other RTP session, RS and RTP_Rx regularly send session, as in any other RTP session, RS and RTP_Rx regularly send
the periodic sender and receiver reports, respectively. the periodic sender and receiver reports, respectively.
Note also that the same method (with the identical message flows)
would also apply in a scenario where rapid acquisition is performed
by a feedback target co-located with the media source.
The unicast burst is triggered by an RTCP feedback message that is The unicast burst is triggered by an RTCP feedback message that is
defined in this document, whereas an RTP retransmission is triggered defined in this document based on the common packet format provided
by an RTCP NACK message defined in [RFC4585]. Based on its design, in [RFC4585], whereas an RTP retransmission is triggered by an RTCP
in an RAMS implementation, there may be a gap between the end of the NACK message defined in [RFC4585]. In the RTP/AVPF profile, there
burst and the reception of the primary multicast stream because of are certain rules that apply to scheduling of both of these messages,
the imperfections in the switch-over. If needed, RTP_Rx may make use which are detailed in Section 3.5 of [RFC4585]. One of the rules
of the RTCP NACK message to request a retransmission for the missing states that in a multi-party session such as the SSM sessions we are
packets in the gap. considering in this specification, an RTP receiver cannot send an
RTCP feedback message for a minimum of one second period after
joining the session (i.e., Tmin=1.0 second). While this rule has the
goal of avoiding problems associated with flash crowds in typical
multi-party sessions, it defeats the purpose of rapid acquisition.
Furthermore, when RTP receivers delay their messages requesting a
burst by a deterministic or even a random amount, it still does not
make a difference since such messages are not related and their
timings are independent from each other. Thus, in this specification
we initialize Tmin to zero and allow the RTP receivers to send a
burst request message right at the beginning. It should, however, be
emphasized that for the subsequent messages 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. Note that the The RTCP feedback messages are explained below. The optional
messages indicated in parentheses may or may not be present during messages are indicated in parentheses and they may or may not be
rapid acquisition. present during rapid acquisition. Note that in a scenario where
rapid acquisition is performed by a feedback target co-located with
the media sender, the same method (with the identical message flows)
still applies.
+-----------+ +----------------+ +----------+ +------------+ -------------------------
| Multicast | | Retransmission | | | | RTP | | Retransmission Server |
| Source | | Server | | Router | | Receiver | ----------- | ------ ------------ | -------- ------------
| | | (RS) | | | | (RTP_Rx) | | Multicast | | | FT | | Burst/Ret. | | | | | RTP |
+-----------+ +----------------+ +----------+ +------------+ | Source | | | | | Source | | | Router | | Receiver |
| | | | | | | ------ ------------ | | | | (RTP_Rx) |
|-- RTP Multicast ------------------->| | ----------- | | | | -------- ------------
| | | | | ------------------------- | |
|-- RTP Multicast ->| | | | | | | |
| | | | |-- RTP Multicast ---------->--------------->| |
| |<'''''''''''''''''' RTCP RAMS-R ''| |-. RTCP Multicast -.-.-.-.->-.-.-.-.-.-.-.->| |
| | | | | | | | |
| | | | | | |********************************|
| |'' (RTCP RAMS-I) ''''''''''''''''>| | | |* PORT MAPPING SETUP *|
| | | | | | |********************************|
| | | | | | | | |
| |.. Unicast RTP Burst ............>| | |<~~~~~~~~~~~~~~~~~~~~~~~~~ RTCP RAMS-R ~~~|
| | | | | | | | |
| |<''''''''''''''''''(RTCP RAMS-R)''| | | |********************************|
| | | | | | |* UNICAST SESSION ESTABLISHED *|
| | | | | | |********************************|
| |'' (RTCP RAMS-I) ''''''''''''''''>| | | | | |
| | | | | | |~~~ RTCP RAMS-I ~~~~~~~~~~~~~~~>|
| | | | | | | | |
| | |<~ SFGMP Join ~~| | | |... Unicast RTP Burst .........>|
| | | | | | | | |
| | | | | |<~~~~~~~~~~~~~~~~~~~~~~~~ (RTCP RAMS-R) ~~|
|-- RTP Multicast ------------------------------------>| | | | | |
| | | | | | |~~ (RTCP RAMS-I) ~~~~~~~~~~~~~~>|
| | | | | | | | |
| |<'''''''''''''''''' RTCP RAMS-T ''| | | | | |
| | | | | | | |<= SFGMP Join ==|
| | | | | | | | |
| |<''''''''''''''''''' (RTCP NACK)''| |-- RTP Multicast ------------------------------------------->|
| | | | |-. RTCP Multicast -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.>|
| | | | | | | | |
| |.. (Unicast Retransmissions) ....>| | | | | |
| | | | | | |<~~~~~~~~~~~~~~~ RTCP RAMS-T ~~~|
| | | | | | | | |
| |<''''''''''''''''''' (RTCP BYE) ''| | | | | |
| | | | | |<~~~~~~~~~~~~~~~~~~~~~~~~~~ (RTCP NACK) ~~|
| | | | | | | | |
| | | | |
| | |...(Unicast Retransmissions)...>|
| | | | |
: : : : :
: : : : :
| | |<.=.= Unicast RTCP Reports .=.=>|
: : : : :
: : : : :
| | | | |
-------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages
=======> SFGMP Messages
.......> Unicast RTP Flow
'''> Unicast RTCP Messages
~~~> SFGMP Messages
...> Unicast RTP Flow
---> Multicast RTP Flow
Figure 3: Message flows for unicast-based rapid acquisition Figure 3: Message flows for unicast-based rapid acquisition
This document defines the expected behaviors of RS and RTP_Rx. It is This document defines the expected behaviors of RS and RTP_Rx. It is
instructive to have independently operating implementations on RS and instructive to have independently operating implementations on RS and
RTP_Rx that request the burst, describe the burst, start the burst, RTP_Rx that request the burst, describe the burst, start the burst,
join the multicast session and stop the burst. These implementations join the multicast session and stop the burst. These implementations
send messages to each other, but there MUST be provisions for the send messages to each other, but there must be provisions for the
cases where the control messages get lost, or re-ordered, or are not cases where the control messages get lost, or re-ordered, or are not
being delivered to their destinations. being delivered to their destinations.
The following steps describe rapid acquisition in detail: The following steps describe rapid acquisition in detail:
1. Request: RTP_Rx sends a rapid acquisition request for the new 1. Port Mapping Setup: For the primary multicast RTP session, the
multicast RTP session to the feedback target address of that RTP and RTCP destination ports are declaratively specified
session. The request contains the SSRC of RTP_Rx and the SSRC of (Refer to Section 8 for examples in SDP). However, in the
the media source. This RTCP feedback message is defined as the unicast RTP retransmission session, RTP_Rx often needs to choose
RAMS-Request (RAMS-R) message and MAY contain parameters, which its receive ports for RTP and RTCP. Since this unicast session
may constrain the burst, such as the bandwidth limit. Other is established after RTP_Rx sends its rapid acquisition request
parameters may be related to the amount of buffering capacity and it is received by RS in the primary multicast RTP session,
available at RTP_Rx, which may be used by RS to prepare a burst RTP_Rx MUST setup the port mappings between the unicast and
that conforms with RTP_Rx's requirements. multicast sessions and send this mapping information to RS
before it sends its request so that RS knows how to communicate
with RTP_Rx.
Before joining the primary multicast session, a new joining The details of this setup procedure and other NAT-related issues
RTP_Rx learns the addresses associated with the new multicast are left to Section 9 to keep the present discussion focused on
session (addresses for the multicast source, group and the RAMS message flows.
retransmission server) by out-of-band means. Also note that
since no RTP packets have been received yet for this session, the
SSRC must be obtained out-of-band. See Section 8 for details.
2. Response: RS receives the RAMS-R message and decides whether to 2. Request: RTP_Rx sends a rapid acquisition request for the
accept it or not. RS MUST send an (at least one) RAMS- primary multicast RTP session to the feedback target address of
Information (RAMS-I) message to RTP_Rx. The first RAMS-I message that session. The request contains the SSRC identifier of
MAY precede the unicast burst or it MAY be sent during the burst. RTP_Rx and may contain the media sender SSRC identifier(s)
Additional RAMS-I messages MAY be sent during the burst and these associated with the desired primary multicast stream(s). This
RAMS-I messages may or may not be a direct response to an RAMS-R RTCP feedback message is defined as the RAMS-Request (RAMS-R)
message. The RAMS-I message is sent by the Burst/Retransmission message and may contain parameters that constrain the burst,
Source logical entity that is part of RS. such as the buffer and bandwidth limits.
Note that RS learns the IP address information for RTP_Rx from Before joining the SSM session, RTP_Rx learns the addresses for
the RAMS-R message it received. (This description glosses over the multicast source, group and RS by out-of-band means. If
the NAT details. Refer to Section 9 for a discussion of NAT- RTP_Rx desires to rapidly acquire only a subset of the primary
related issues.) multicast streams available in the primary multicast RTP
session, the SSRC identifiers for the desired RTP streams MUST
also be obtained out-of-band, since no RTP packets have been
received yet for those streams. Based on this information,
RTP_Rx populates the desired SSRC(s) in its request message.
If RS cannot provide a rapid acquisition service, RS rejects the When RS successfully receives the RAMS-R message, it responds to
request and informs RTP_Rx immediately via an RAMS-I message. If it by accepting or rejecting the request. Right before RS sends
RTP_Rx receives a message indicating that its rapid acquisition any RTP or RTCP packet(s) described below, it establishes the
request has been denied, it abandons the rapid acquisition unicast RTP retransmission session.
attempt and MAY immediately join the multicast session by sending
an SFGMP Join message towards its upstream multicast router for
the new primary multicast session.
If RS accepts the request, it sends an RAMS-I message to RTP_Rx 3. Response: RS sends RAMS-Information (RAMS-I) message(s) to
(before commencing the unicast burst or during the unicast burst) RTP_Rx to convey the status for the burst(s) requested by
that comprises fields that can be used to describe the unicast RTP_Rx. The RAMS-I message is sent by the Burst/Retransmission
burst (e.g., the maximum bitrate and the duration of the unicast Source logical entity that is part of RS.
burst). A particularly important field in the RAMS-I message
carries the RTP sequence number of the first packet transmitted
in the retransmission session to allow RTP_Rx to detect any
missing initial packet(s). Note that the first RTP packet
transmitted in the retransmission session is not necessarily a
burst packet. It could be a payload-specific RTP packet (See
[I-D.begen-avt-rtp-mpeg2ts-preamble] for an example). When RS
accepts the request, this field MUST be populated in the RAMS-I
message and it is RECOMMENDED that the RAMS-I message is sent
early enough in the session to be useful. If RS rejects the
request, this field SHALL NOT exist in the RAMS-I message.
It is RECOMMENDED to include a sender report with the RAMS-I In cases where the primary multicast RTP session associated with
message in the same compound RTCP packet. This allows rapid FT_Ap on which the RAMS-R message was received contains only a
synchronization among multiple RTP flows single primary multicast stream, RS SHALL always use the SSRC of
[I-D.ietf-avt-rapid-rtp-sync]. the RTP stream associated with FT_Ap in the RAMS-I message(s)
regardless of the media sender SSRC specified in the RAMS-R
message. In such cases the 'ssrc' attribute MAY be omitted from
the media description. If the requested SSRC and the actual
media sender SSRC do not match, RS SHOULD explicitly populate
the correct media sender SSRC in the initial RAMS-I message.
The unicast burst duration MAY be calculated by RS, and its value FT_Ap could also be associated with an RTP session that carries
MAY be updated by messages received from RTP_Rx. If RS accepts two or more primary multicast streams. If RTP_Rx will issue a
the request, the join time information (for the new multicast collective request to receive the whole primary multicast RTP
session) MUST be populated in at least one of the RAMS-I session, it does not need the 'ssrc' attributes to be described
messages. If RS rejects the request, including the join time in the media description. Note that if FT_Ap is associated with
information in a RAMS-I message is OPTIONAL. two or more RTP sessions, RTP_Rx's request will be ambiguous.
Thus, each FT_Ap MUST be associated with a single RTP session.
RS MAY send the RAMS-I message after a significant delay, so If RTP_Rx is willing to rapidly acquire only a subset of the
RTP_Rx SHOULD NOT make protocol dependencies on quickly receiving primary multicast streams, the RAMS-R message MUST explicitly
an RAMS-I message. list the media sender SSRCs. Upon receiving such a message, RS
MAY accept the request for only the media sender SSRC(s) that
matched one of the RTP streams it serves. It MUST reject all
other requests with the appropriate response code.
3. Unicast Burst: If the request is accepted, RS starts sending the * Reject Responses: RS MUST take into account any limitations
unicast burst that comprises one or more RTP retransmission that MAY have been specified by RTP_Rx in the RAMS-R message
packets (The burst packet(s) are sent by the Burst/Retransmission when making a decision regarding the request. If RTP_Rx has
Source logical entity). In addition, there MAY be optional requested to acquire the whole primary multicast RTP session
payload-specific information that RS chooses to send to RTP_Rx. but RS cannot provide a rapid acquisition service for any of
Such an example is discussed in the primary multicast streams, RS MUST reject the request via
[I-D.begen-avt-rtp-mpeg2ts-preamble] for transmitting the a single RAMS-I message with a collective reject response
payload-specific information for MPEG2 Transport Streams. code and whose media sender SSRC field is set to one of SSRCs
served by this FT_Ap. Upon receiving this RAMS-I message,
RTP_Rx abandons the rapid acquisition attempt and may
immediately join the multicast session by sending an SFGMP
Join message towards its upstream multicast router.
4. Updated Request: RTP_Rx MAY send a new RAMS-R message (to the FT In all other cases, RS MUST send a separate RAMS-I message
entity of RS) with a different value for one or more fields of an with the appropriate response code for each primary multicast
earlier RAMS-R message. Upon receiving an updated request, RS stream that has been requested by RTP_Rx but cannot be served
MAY use the updated values for sending/shaping the burst, or by RS.
refine the values and use the refined values for sending/shaping
the burst.
RS MAY send a new RAMS-I message to indicate the changes it made. * Accept Responses: RS MUST send a separate RAMS-I message
However, note that RS does not have to send a new RAMS-I, or the with the appropriate response code for each primary multicast
new RAMS-I message may get lost. It is also possible that the stream that has been requested by RTP_Rx and will be served
updated RAMS-R message could have been lost. Thus, RTP_Rx SHOULD by RS. Such RAMS-I messages comprise fields that can be used
NOT make protocol dependencies on quickly (or ever) receiving a to describe the individual unicast burst streams.
new RAMS-I message, or assume that RS will honor the requested
changes.
RTP_Rx may be in an environment where the available resources are A particularly important field carries the RTP sequence
time-varying, which may or may not deserve sending a new updated number of the first packet transmitted in the respective RTP
request. Determining the circumstances where RTP_Rx should or stream to allow RTP_Rx to detect any missing initial
should not send an updated request and the methods that RTP_Rx packet(s). Note that the first RTP packet transmitted in an
can use to detect and evaluate the time-varying available RTP stream is not necessarily a burst packet. It could be a
resources are not specified in this document. payload-specific RTP packet, which is payload-type-
multiplexed with the burst packets (See
[I-D.begen-avt-rtp-mpeg2ts-preamble] for an example). When
RS accepts the request, this field MUST be populated in the
RAMS-I message and the initial RAMS-I message SHOULD precede
the unicast burst or be sent at the start of the burst so
that RTP_Rx may quickly detect any missing initial packet(s).
5. Updated Response: RS may send more than one RAMS-I messages, Where possible, it is RECOMMENDED to include all RAMS-I messages
e.g., to update the value of one or more fields in an earlier in the same compound RTCP packet. However, it is possible that
RAMS-I message and/or to signal RTP_Rx in real time to join the the RAMS-I message for a primary multicast stream may get
primary multicast session. RTP_Rx usually depends on RS to learn delayed or lost, and RTP_Rx may start receiving RTP packets
the join time, which can be conveyed by the first RAMS-I message, before receiving a RAMS-I message. Thus, RTP_Rx SHOULD NOT make
or can be sent/revised in a later RAMS-I message. If RS is not protocol dependencies on quickly receiving the initial RAMS-I
capable of determining the join time in the first RAMS-I message, message. For redundancy purposes, it is RECOMMENDED that RS
it MUST send another RAMS-I message (with the join time repeats the RAMS-I messages multiple times as long as it follows
information) later. the RTCP timer rules defined in [RFC4585].
6. Multicast Join Signaling: In principal, RTP_Rx can join the 4. Unicast Burst: For the primary multicast stream(s) for which
primary multicast session any time during or after the end of the the request is accepted, RS starts sending the unicast burst(s)
unicast burst via an SFGMP Join message. However, there may be that comprises one or more RTP retransmission packets. The
missing packets if RTP_Rx joins the primary multicast session too burst packet(s) are sent by the Burst/Retransmission Source
early or too late. For example, if RTP_Rx starts receiving the logical entity. In addition, there MAY be optional payload-
primary multicast stream while it is still receiving the unicast specific information that RS chooses to send to RTP_Rx. Such an
burst at a high excess bitrate, this may result in an increased example is discussed in [I-D.begen-avt-rtp-mpeg2ts-preamble] for
risk of packet loss. Or, if RTP_Rx joins the primary multicast transmitting the payload-specific information for MPEG2
session some time after the unicast burst is finished, there may Transport Streams.
be a gap between the burst and multicast data (a number of RTP
packets may be missing). In both cases, RTP_Rx MAY issue
retransmissions requests (via RTCP NACK messages) [RFC4585] to
fill the gap.
Yet, there are cases where the remaining available bandwidth may 5. Updated Request: RTP_Rx MAY send an updated RAMS-R message (to
limit the number of retransmissions that can be provided within a the FT entity of RS) with a different value for one or more
certain time period, causing the retransmission data to arrive fields of an earlier RAMS-R message. Upon receiving an updated
too late at RTP_Rx (from an application-layer point of view). To request, RS may use the updated values for sending/shaping the
cope with such cases, the RAMS-I message allows RS to signal burst, or refine the values and use the refined values for
explicitly when RTP_Rx should send the SFGMP Join message. sending/shaping the burst. Subsequently, RS MAY send an updated
RAMS-I message to indicate the changes it made.
Alternatively, RS may pre-compute the burst duration and the time However, the updated RAMS-I message may get lost. It is also
RTP_Rx should send the SFGMP Join message. This information may possible that the updated RAMS-R message could have been lost.
be conveyed in the RAMS-I message and can be updated in a
subsequent RAMS-I message. While RTP_Rx MAY use a locally
calculated join time, it SHOULD use the information from the most
recent RAMS-I message.
7. Multicast Receive: After the join, RTP_Rx starts receiving the Thus, RTP_Rx SHOULD NOT make protocol dependencies on quickly
primary multicast stream. (or ever) receiving an updated RAMS-I message, or assume that RS
will honor the requested changes.
8. Terminate: RS may know when it needs to stop the unicast burst RTP_Rx may be in an environment where the available resources
based on the burst parameters, or RTP_Rx MAY explicitly let RS are time-varying, which may or may not deserve sending a new
know the sequence number of the first RTP packet it received from updated request. Determining the circumstances where RTP_Rx
the multicast session, or RTP_Rx MAY request RS to terminate the should or should not send an updated request and the methods
burst immediately. that RTP_Rx can use to detect and evaluate the time-varying
available resources are not specified in this document.
Regardless of whether or not RS knows when it needs to stop the 6. Updated Response: RS may send more than one RAMS-I messages,
burst, RTP_Rx SHALL use the RAMS-Termination (RAMS-T) message at e.g., to update the value of one or more fields in an earlier
an appropriate time. RTP_Rx can choose to send the RAMS-T RAMS-I message. The updated RAMS-I messages may or may not be a
message before or after it starts receiving the multicast data. direct response to a RAMS-R message. RS may also send updated
In the latter case, RTP_Rx SHALL include the sequence number of RAMS-I messages to signal RTP_Rx in real time to join the
the first RTP packet received in the primary multicast session in multicast session. RTP_Rx depends on RS to learn the join time,
the RAMS-T message, and RS SHOULD terminate the burst after it which can be conveyed by the first RAMS-I message, or can be
sends the unicast burst packet whose Original Sequence Number sent/revised in a later RAMS-I message. If RS is not capable of
(OSN) field in the RTP retransmission payload header matches this determining the join time in the initial RAMS-I message, it MUST
number minus one. send another RAMS-I message (with the join time information)
later.
If RTP_Rx wants to stop the burst prior to receiving the 7. Multicast Join Signaling: The RAMS-I message allows RS to
multicast data, it sends an RAMS-T message without an RTP signal explicitly when RTP_Rx SHOULD send the SFGMP Join
sequence number. message. If the request is accepted, this information MUST be
conveyed in at least one RAMS-I message and its value MAY be
updated by subsequent RAMS-I messages. If RTP_Rx has received
multiple RAMS-I messages, it SHOULD use the information from the
most recent RAMS-I message.
RTP_Rx MUST send at least one RAMS-T message (if an RTCP BYE There may be missing packets if RTP_Rx joins the multicast
message has not been issued yet as described in Step 9), and the session too early or too late. For example, if RTP_Rx starts
RAMS-T message MUST be addressed to the RTCP port of the receiving the primary multicast stream while it is still
retransmission session. Against the possibility of a message receiving the unicast burst at a high excess bitrate, this may
loss, RTP_Rx MAY repeat the RAMS-T message multiple times as long result in an increased risk of packet loss. Or, if RTP_Rx joins
as it follows the RTCP timer rules defined in [RFC4585]. the multicast session some time after the unicast burst is
finished, there may be a gap between the burst and multicast
data (a number of RTP packets may be missing). In both cases,
RTP_Rx may issue retransmissions requests (via RTCP NACK
messages) [RFC4585] to the FT entity of RS to fill the gap. RS
may or may not respond to such requests. When it responds and
the response causes significant changes in one or more values
reported earlier to RTP_Rx, an updated RAMS-I should be sent to
RTP_Rx.
9. Terminate with RTCP BYE: When RTP_Rx is receiving the burst, if 8. Multicast Receive: After the join, RTP_Rx starts receiving the
RTP_Rx becomes no longer interested in the primary multicast primary multicast stream(s).
stream, RTP_Rx SHALL issue an RTCP BYE message for the RTP
retransmission session and another RTCP BYE message for the
primary multicast session.
Upon receiving an RTCP BYE message, RS MUST terminate the rapid 9. Terminate: RS may know when it needs to ultimately stop the
acquisition operation, and cease transmitting any further regular unicast burst based on its parameters. However, RTP_Rx may need
retransmission packets as well as retransmission packets to ask RS to terminate the burst prematurely or at a specific
associated with the unicast burst. If support for [RFC5506] has sequence number. For this purpose, it uses the RAMS-Termination
been signaled, the RTCP BYE message MAY be sent in a reduced-size (RAMS-T) message. A separate RAMS-T message is sent for each
RTCP packet. Otherwise, Section 6.1 of [RFC3550] mandates the primary multicast stream served by RS unless an RTCP BYE message
RTCP BYE message always to be sent with a sender or receiver has been sent as described in Step 10. For the burst requests
report in a compound RTCP packet (If no data has been received, that were rejected by RS, there is no need to send a RAMS-T
an empty receiver report MUST be included). With the information message.
contained in the receiver report, RS can also figure out how many
duplicate RTP packets have been delivered to RTP_Rx (Note that
this will be an upper-bound estimate as one or more packets might
have been lost during the burst transmission). The impact of
duplicate packets and measures that can be taken to minimize the
impact of receiving duplicate packets will be addressed in
Section 6.3.
Note that an RTCP BYE message issued for the RTP retransmission If RTP_Rx wants to terminate a burst prematurely, it SHALL send
session terminates the whole session and ceases transmitting any a plain RAMS-T message for the particular primary multicast
further packets in that RTP session. Thus, in this case there is stream, and upon receiving this message RS MUST terminate the
no need for sending an (explicit) RAMS-T message, which would unicast burst. If RTP_Rx requested to acquire the entire
only terminate the burst. primary multicast RTP session but wants to terminate this
request before it learns the individual media sender SSRC(s) via
RAMS-I message(s), it cannot use RAMS-T message(s) and thus MUST
send an RTCP BYE message to terminate the request.
Note that for the purpose of gathering detailed information about Otherwise, the default behavior for RTP_Rx is to send a RAMS-T
RTP_Rx's rapid acquisition experience, message right after it joined the multicast session and started
[I-D.begen-avt-rapid-sync-rtcp-xr] defines an RTCP Extended Report receiving multicast packets. In that case, RTP_Rx SHALL send a
(XR) Block. This report is designed to be payload-independent, thus, RAMS-T message with the sequence number of the first RTP packet
it can be used by any multicast application that supports rapid received in the primary multicast stream, and RS SHOULD
acquisition. Support for this XR report is, however, optional. terminate the respective burst after it sends the unicast burst
packet whose Original Sequence Number (OSN) field in the RTP
retransmission payload header matches this number minus one.
6.3. Shaping the Unicast Burst RTP_Rx MUST send at least one RAMS-T message for each primary
multicast stream served by RS (if an RTCP BYE message has not
been issued yet as described in Step 10). The RAMS-T message(s)
MUST be addressed to the Burst/Retransmission Source logical
entity. Against the possibility of a message loss, it is
RECOMMENDED that RTP_Rx repeats the RAMS-T messages multiple
times as long as it follows the RTCP timer rules defined in
[RFC4585].
10. Terminate with RTCP BYE: When RTP_Rx is receiving one or more
burst streams, if RTP_Rx becomes no longer interested in
acquiring any of the primary multicast streams, RTP_Rx SHALL
issue an RTCP BYE message for the RTP retransmission session and
another RTCP BYE message for the primary multicast RTP session.
These RTCP BYE messages are sent to the Burst/Retransmission
Source and FT logical entities, respectively.
Upon receiving an RTCP BYE message, the Burst/Retransmission
Source logical entity MUST terminate the rapid acquisition
operation, and cease transmitting any further burst packets and
retransmission packets. If support for [RFC5506] has been
signaled, the RTCP BYE message MAY be sent in a reduced-size
RTCP packet. Otherwise, Section 6.1 of [RFC3550] mandates the
RTCP BYE message always to be sent with a sender or receiver
report in a compound RTCP packet (If no data has been received,
an empty receiver report MUST be still included). With the
information contained in the receiver report, RS can figure out
how many duplicate RTP packets have been delivered to RTP_Rx
(Note that this will be an upper-bound estimate as one or more
packets might have been lost during the burst transmission).
The impact of duplicate packets and measures that can be taken
to minimize the impact of receiving duplicate packets will be
addressed in Section 6.4.
Note that an RTCP BYE message issued for the RTP retransmission
session terminates the whole session and ceases transmitting any
further packets in that RTP session. Thus, in this case there
is no need for sending explicit RAMS-T messages, which would
only terminate their respective bursts.
For the purpose of gathering detailed information about RTP_Rx's
rapid acquisition experience, [I-D.begen-avt-rapid-sync-rtcp-xr]
defines an RTCP Extended Report (XR) Block. This report is designed
to be payload-independent, thus, it can be used by any multicast
application that supports rapid acquisition. Support for this XR
report is, however, OPTIONAL.
6.3. Synchronization of Primary Multicast Streams
When RTP_Rx acquires multiple primary multicast streams, it may need
to synchronize them for the playout. This synchronization is
traditionally achieved by the help of the RTCP sender reports
[RFC3550]. If the playout will start before RTP_Rx has joined the
multicast session, RTP_Rx must receive the information reflecting the
synchronization among the primary multicast streams early enough so
that it can play out the media in a synchronized fashion. However,
this would require RS to cache the sender reports sent in the primary
multicast RTP session(s), and piggyback the latest synchronization
information on its own sender report and send an early sender report
in the unicast RTP retransmission session. This issue and its
implications are discussed in detail in
[I-D.ietf-avt-rapid-rtp-sync].
An alternative approach is to use the RTP header extension mechanism
[RFC5285] and convey the synchronization information in a header
extension as defined in [I-D.ietf-avt-rapid-rtp-sync].
[RFC4588] says that retransmission packets SHOULD carry the same
header extension carried in the header of the original RTP packets.
Thus, as long as the multicast source emits a header extension with
the synchronization information frequently enough, there is no
additional task that needs to be carried out by RS. The
synchronization information will be sent to RTP_Rx along with the
burst packets. The frequent header extensions sent in the primary
multicast RTP sessions also allow rapid synchronization of the RTP
streams for the RTP receivers that do not support RAMS or that
directly join the multicast session without running RAMS. Thus, in
RAMS applications, it is RECOMMENDED that the multicast sources
frequently send synchronization information by using header
extensions following the rules presented in
[I-D.ietf-avt-rapid-rtp-sync]. It should be noted that the regular
sender reports are still sent in the unicast session by following the
rules of [RFC3550].
6.4. Shaping the Unicast Burst
This section provides informative guidelines about how RS can shape This section provides informative guidelines about how RS can shape
the transmission of the unicast burst. the transmission of the unicast burst.
A higher bitrate for the unicast burst naturally conveys the A higher bitrate for the unicast burst naturally conveys the
Reference Information and media content to RTP_Rx faster. This way, Reference Information and media content to RTP_Rx faster. This way,
RTP_Rx can start consuming the data sooner, which results in a faster RTP_Rx can start consuming the data sooner, which results in a faster
acquisition. acquisition.
A higher rate also represents a better utilization of RS resources. A higher rate also represents a better utilization of RS resources.
As the burst may continue until it catches up with the primary As the burst may continue until it catches up with the primary
multicast stream, the higher the bursting rate, the less data RS multicast stream, the higher the bursting rate, the less data RS
needs to transmit. However, a higher rate for the burst also needs to transmit. However, a higher rate for the burst also
increases the chances for congestion-caused packet loss. Thus, as increases the chances for congestion-caused packet loss. Thus, as
discussed in Section 5, there must be an upper bound on the extra discussed in Section 5, there must be an upper bound on the extra
bandwidth used by the burst. bandwidth used by the burst.
When RS transmits the burst, it SHOULD take into account all When RS transmits the burst, it should take into account all
available information to prevent any packet loss that may take place available information to prevent any packet loss that may take place
during the bursting as a result of buffer overflow on the path during the bursting as a result of buffer overflow on the path
between RS and RTP_Rx and at RTP_Rx itself. The bursting rate may be between RS and RTP_Rx and at RTP_Rx itself. The bursting rate may be
determined by taking into account the following data, when available: determined by taking into account the following data, when available:
a. Information obtained via the RAMS-R message, such as Max RAMS a. Information obtained via the RAMS-R message, such as Max RAMS
Buffer Fill Requirement and/or Max Receive Bitrate (See Buffer Fill Requirement and/or Max Receive Bitrate (See
Section 7.2). Section 7.2).
b. Information obtained via RTCP receiver reports provided by RTP_Rx b. Information obtained via RTCP receiver reports provided by RTP_Rx
in the retransmission session, allowing in-session rate in the retransmission session, allowing in-session rate
adaptations for the burst. When these receiver reports indicate adaptations for the burst. When these receiver reports indicate
packet loss, this may indicate a certain congestion state in the packet loss, this may indicate a certain congestion state in the
path from RS to RTP_Rx. Heuristics or algorithms that deduce path from RS to RTP_Rx. Heuristics or algorithms that deduce
such congestion state and how subsequently the RS should act, are such congestion state and how subsequently the RS should act, are
outside the scope of this document. outside the scope of this document.
c. Information obtained via RTCP NACKs provided by RTP_Rx in the c. Information obtained via RTCP NACKs provided by RTP_Rx in the
primary multicast session, allowing in-session rate adaptations primary multicast RTP session, allowing in-session rate
for the burst. Such RTCP NACKs are transmitted by RTP_Rx in adaptations for the burst. Such RTCP NACKs are transmitted by
response to packet loss detection by RTP_Rx in the burst. NACKs RTP_Rx in response to packet loss detection by RTP_Rx in the
may indicate a certain congestion state on the path from RS to burst. NACKs may indicate a certain congestion state on the path
RTP_Rx. Heuristics or algorithms that deduce such congestion from RS to RTP_Rx. Heuristics or algorithms that deduce such
state and how subsequently the RS should act, are outside the congestion state and how subsequently the RS should act, are
scope of this document. outside the scope of this document.
d. There may be other feedback received from RTP_Rx, e.g., in the d. There may be other feedback received from RTP_Rx, e.g., in the
form of ECN-CE RTCP feedback messages form of ECN-CE RTCP feedback messages
[I-D.westerlund-avt-ecn-for-rtp] that may influence in-session [I-D.westerlund-avt-ecn-for-rtp] that may influence in-session
rate adaptations. rate adaptations.
e. Information obtained via updated RAMS-R messages, allowing in- e. Information obtained via updated RAMS-R messages, allowing in-
session rate adaptations, if supported by RS. session rate adaptations, if supported by RS.
f. Pre-configured settings for each RTP_Rx or a set of RTP_Rxs that f. Pre-configured settings for each RTP_Rx or a set of RTP_Rxs that
indicate the upper-bound bursting rates for which no packet loss indicate the upper-bound bursting rates for which no packet loss
will occur as a result of congestion along the path of RS to will occur as a result of congestion along the path of RS to
RTP_Rx. For example, in managed IPTV networks, where the RTP_Rx. For example, in managed IPTV networks, where the
bottleneck bandwidth along the end-to-end path is known (which is bottleneck bandwidth along the end-to-end path is known and where
generally the access network link) and where the network between the network between RS and this link is provisioned and
RS and this link is provisioned and dimensioned to carry the dimensioned to carry the burst streams, the bursting rate does
burst streams, the bursting rate does not exceed the provisioned not exceed the provisioned value. These settings may also be
value. These settings may also be dynamically adapted using dynamically adapted using application-aware knowledge.
application-aware knowledge.
The initial bursting rate of the unicast burst to RTP_Rx is The initial bursting rate of the unicast burst to RTP_Rx is
determined by parameters directly obtained from RTP_Rx (a) or by pre- determined by parameters directly obtained from RTP_Rx (a) or by pre-
configured settings (f). If such information is not available, RS configured settings (f). If such information is not available, RS
may choose an appropriate initial bursting rate, and could increase may choose an appropriate initial bursting rate, and could increase
or decrease the rate based on the feedback information (b, c, d or or decrease the rate based on the feedback information (b, c, d or
e). However, this may not be an easy task as by the time packet loss e). However, this may not be an easy task as by the time packet loss
is reported back to RS triggering a rate reduction, packet loss may is reported back to RS triggering a rate reduction, packet loss may
have occurred. have occurred.
A specific situation occurs near the end of the unicast burst, when A specific situation occurs near the end of the unicast burst, when
RS has almost no more additional data to sustain the relatively RS has almost no more additional data to sustain the relatively
higher bursting rate, thus, the upper-bound bursting rate higher bursting rate, thus, the upper-bound bursting rate
automatically gets limited by the nominal rate of the primary automatically gets limited by the nominal rate of the primary
multicast stream. During this time frame, RTP_Rx will join the multicast stream. During this time frame, RTP_Rx eventually needs to
primary multicast session because it was instructed to do so via an join the multicast session. This means that both the burst packets
RAMS-I message or based on some heuristics. This means that both the and the multicast packets may be simultaneously received by RTP_Rx
burst packets and the primary multicast stream packets will be for a period of time.
simultaneously received by RTP_Rx for a period of time.
In this case, when the unicast burst is close to catch up with the Since RS signals RTP_Rx when it should send the SFGMP Join message,
primary multicast stream, RS may, for example, keep on sending burst RS may have a rough estimate of when RTP_Rx will start receiving
packets but should reduce the rate accordingly by taking the nominal multicast packets in the SSM session. RS may keep on sending burst
rate of the primary multicast stream into account. Alternatively, RS packets but should reduce the rate accordingly at the appropriate
may immediately cease transmitting the burst packets, when being instant by taking the rate of the SSM session into account. If RS
close to catch-up. Any gap resulting from an imperfect switch by ceases transmitting the burst packets before the burst catches up,
RTP_Rx in receiving first the burst packets and then only primary any gap resulting from this imperfect switch-over by RTP_Rx can be
multicast stream packets, can be later repaired by requesting later repaired by requesting retransmissions of the missing packets
retransmissions of the missing packets from RS. The retransmissions from RS. The retransmissions may be shaped by RS to make sure that
may also be shaped by RS to make sure that they do not cause they do not cause collateral loss in the primary multicast RTP
collateral loss in the primary multicast and retransmission sessions. session and the RTP retransmission session.
6.4. Failure Cases 6.5. Failure Cases
All RAMS messages MAY be sent several times against the possibility In the following, we examine the implications of losing the RAMS-R,
of message loss as long as RS/RTP_Rx follows the RTCP timer rules RAMS-I or RAMS-T messages and other failure cases.
defined in [RFC4585]. In the following, we examine the implications
of losing the RAMS-R, RAMS-I or RAMS-T messages.
When RTP_Rx sends an RAMS-R message to initiate a rapid acquisition When RTP_Rx sends a RAMS-R message to initiate a rapid acquisition
but the message gets lost and RS does not receive it, RTP_Rx will not but the message gets lost and RS does not receive it, RTP_Rx will get
get an RAMS-I message, nor a unicast burst. In this case, RTP_Rx MAY neither a RAMS-I message, nor a unicast burst. In this case, RTP_Rx
resend the request when it is eligible to do so. Or, after a MAY resend the request when it is eligible to do so based on the RTCP
reasonable amount of time, RTP_Rx MAY time out (based on the previous timer rules defined in [RFC4585]. Or, after a reasonable amount of
observed response times) and immediately join the primary multicast time, RTP_Rx may time out (based on the previous observed response
session. In this case, RTP_Rx MUST still send an RAMS-T message. times) and immediately join the SSM session.
In the case RTP_Rx starts receiving a unicast burst but it does not In the case RTP_Rx starts receiving a unicast burst but it does not
receive a corresponding RAMS-I message within a reasonable amount of receive a corresponding RAMS-I message within a reasonable amount of
time, RTP_Rx MAY either discard the burst data and stop the burst by time, RTP_Rx may either discard the burst data or decide not to
sending an RAMS-T message to RS, or decide not to interrupt the interrupt the unicast burst, and be prepared to join the SSM session
unicast burst and be prepared to join the primary multicast session at an appropriate time it determines or as indicated in a subsequent
at an appropriate time it determines or indicated in a subsequent RAMS-I message (if available). To minimize the chances of losing the
RAMS-I message (if available). In either case, RTP_Rx SHALL send an RAMS-I messages, it is RECOMMENDED that RS repeats the RAMS-I
RAMS-T message to RS at an appropriate time. messages multiple times based on the RTCP timer rules defined in
[RFC4585].
In the case the RAMS-T message sent by RTP_Rx does not reach its In the failure cases where the RAMS-R message is lost and RTP_Rx
destination, RS may continue sending the unicast burst even though gives up, or the RAMS-I message is lost, RTP_Rx MUST still terminate
RTP_Rx no longer needs it. In some cases, RS has not pre-computed the burst(s) it requested by following the rules described in
the burst duration and does not know when to stop the burst. To Section 6.2.
cover that case, RTP_Rx MAY repeat the RAMS-T message multiple times
as long as it follows the RTCP timer rules defined in [RFC4585]. RS
MUST be provisioned to deterministically terminate the burst at some
point, even if it never receives an RAMS-T message for an ongoing
burst.
If RTP_Rx becomes no longer interested in receiving the primary In the case a RAMS-T message sent by RTP_Rx does not reach its
multicast stream and the associated unicast burst, RTP_Rx SHALL issue destination, RS may continue sending burst packets even though RTP_Rx
an RTCP BYE message to RS to terminate the RTP retransmission no longer needs them. In such cases, it is RECOMMENDED that RTP_Rx
session. Only after that, RTP_Rx MAY send a new rapid acquisition repeats the RAMS-T message multiple times based on the RTCP timer
request for another primary multicast session. rules defined in [RFC4585]. In the worst case, RS MUST be
provisioned to deterministically terminate the burst when it can no
longer send the burst packets faster than it receives the primary
multicast stream packets.
Section 6.3.5 of [RFC3550] explains the rules pertaining to timing
out an SSRC. When RS accepts to serve the requested burst(s) and
establishes the retransmission session, it should check the liveness
of RTP_Rx via the RTCP messages and reports RTP_Rx sends.
Editor's note: What would the timeout duration be and what action
should RS take?
7. Encoding of the Signaling Protocol in RTCP 7. Encoding of the Signaling Protocol in RTCP
This section defines the formats of the RTCP transport-layer feedback This section defines the formats of the RTCP transport-layer feedback
messages that are exchanged between the Retransmission Server (RS) messages that are exchanged between the Retransmission Server (RS)
and RTP Receiver (RTP_Rx) during rapid acquisition. These messages and RTP Receiver (RTP_Rx) during rapid acquisition. These messages
are referred to as the RAMS Messages. They are payload-independent are referred to as the RAMS Messages. They are payload-independent
and MUST be used by all RTP-based multicast applications that support and MUST be used by all RTP-based multicast applications that support
rapid acquisition regardless of the payload they carry. rapid acquisition regardless of the payload they carry.
Payload-specific feedback messages are not defined in this document, Payload-specific feedback messages are not defined in this document.
but an extension mechanism is provided where further optional However, further optional payload-independent and payload-specific
payload-independent and payload-specific information can be included information can be included in the exchange.
in the exchange.
The common packet format for the RTCP feedback messages is defined in The common packet format for the RTCP feedback messages is defined in
Section 6.1 of [RFC4585]. Each feedback message has a fixed-length Section 6.1 of [RFC4585]. Each feedback message has a fixed-length
field for version, padding, feedback message type (FMT), payload type field for version, padding, feedback message type (FMT), payload type
(PT), length, SSRC of packet sender, SSRC of media source as well as (PT), length, SSRC of packet sender, SSRC of media sender as well as
a variable-length field for feedback control information (FCI). a variable-length field for 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). a sub-field called Sub Feedback Message Type (SFMT). Any Reserved
field SHALL be set to zero and ignored.
Depending on the specific scenario and timeliness/importance of a Depending on the specific scenario and timeliness/importance of a
RAMS message, it may be desirable to send it in a reduced-size RTCP RAMS message, it may 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
messages defined below are carried in network-byte order, that is,
most significant byte (octet) first, also known as big-endian.
Unless otherwise noted, 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 may be desirable to define new fields in the RAMS applications, it may 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 TLV elements as described below and sketched in Figure 4: encoded as TLV elements as described below and sketched in Figure 4:
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 of the TLV o Length: A two-octet field that indicates the length (in octets)
element excluding the Type and Length fields in octets. Note that of the TLV element excluding the Type and Length fields, and the
this length does not include any padding that is required for 8-bit Reserved field between them. Note that this length does not
alignment. include 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.
If a TLV element does not fall on a 32-bit boundary, the last word In the extensions, the Reserved field SHALL be set to zero and
must be padded to the boundary using further bits set to 0. ignored. If a TLV element does not fall on a 32-bit boundary, the
last word MUST be padded to the boundary using further bits set to
zero.
In an RAMS message any vendor-neutral or private extension MUST be In a RAMS message, any vendor-neutral or private extension MUST be
placed after the mandatory fields (if any). The support for placed after the mandatory fields (if any). The extensions MAY be
extensions is OPTIONAL. placed in any order. The support for extensions is OPTIONAL.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value | | Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value contd. / : Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Structure of a TLV element Figure 4: 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 12.5. with IANA through the guidelines provided in Section 12.5.
The current document defines several vendor-neutral extensions in the The current document defines several vendor-neutral extensions in the
following sections. subsequent sections.
7.1.2. Private Extensions 7.1.2. Private Extensions
It is desirable to allow vendors to use private extensions in 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 is reserved for private extensions A certain range of TLV Types (between - and including - 128 and 254 )
(Refer to Section 12.5). IANA management for these extensions is is reserved for private extensions (Refer to Section 12.5). IANA
unnecessary and they are the responsibility of individual vendors. management for these extensions is unnecessary and they are the
responsibility of individual vendors.
The structure that MUST be used for the private extensions is The structure that MUST be used for the private extensions is
depicted in Figure 5. Here, the enterprise numbers are used from depicted in Figure 5. Here, the enterprise numbers are used from
http://www.iana.org/assignments/enterprise-numbers. This will ensure http://www.iana.org/assignments/enterprise-numbers. This will ensure
the uniqueness of the private extensions and avoid any collision. the uniqueness of the private 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 | Length | Ent. Number | | Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ent. Number contd. | Value | | Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value contd. / : Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Structure of a private extension Figure 5: Structure of a private extension
7.2. RAMS Request 7.2. RAMS Request
The RAMS Request message is identified by SFMT=1. The RAMS Request message is identified by SFMT=1. This message is
used by RTP_Rx to request rapid acquisition for a primary multicast
RTP session, or one or more primary multicast streams belonging to
the same primary multicast RTP session.
The FCI field MUST contain only one RAMS Request. Unless signaled otherwise, a RAMS-R message is used to request a
single primary multicast stream whose SSRC is indicated in the media
sender SSRC field of the message header. In cases where RTP_Rx does
not know the media sender SSRC, it MUST set that field to its own
SSRC.
The RAMS Request is used by RTP_Rx to request rapid acquisition for a If RTP_Rx wants to request two or more primary multicast streams or
new multicast RTP session. all of the streams in the primary multicast RTP session, RTP_Rx MUST
provide explicit signaling as described below and set the media
sender SSRC field to its own SSRC to minimize the chances of
accidentally requesting a wrong primary multicast stream.
The FCI field has the structure depicted in Figure 6. The FCI field MUST contain only one RAMS Request. The FCI field has
the structure depicted in Figure 6.
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 | Optional TLV-encoded Fields | | SFMT=1 | Reserved |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) : : Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: FCI field syntax for the RAMS Request message Figure 6: FCI field syntax for the RAMS Request message
o Requested Media Sender SSRC(s): Optional TLV element that lists
the media sender SSRC(s) requested by RTP_Rx. If this TLV element
does not exist in the RAMS-R message, it means that RTP_Rx is only
interested in a single primary multicast stream whose media sender
SSRC is already specified in the header of the RAMS-R message.
However, if this TLV element exists, RS MUST ignore the media
sender SSRC specified in the header of the RAMS-R message. If
this TLV element exists but the Length field is set to zero,
meaning that no media sender SSRC is listed, it means that RTP_Rx
is requesting to rapidly acquire the entire primary multicast RTP
session. Otherwise, RTP_Rx lists the individual media sender
SSRCs in this TLV element and sets the Length field of the TLV
element to 4*n, where n is the number of SSRC entries.
Type: 1
o Min RAMS Buffer Fill Requirement (32 bits): Optional TLV element o Min RAMS Buffer Fill Requirement (32 bits): Optional TLV element
that denotes the minimum milliseconds of data that RTP_Rx desires that denotes the minimum milliseconds of data that RTP_Rx desires
to have in its buffer before allowing the data to be consumed by to have in its buffer before allowing the data to be consumed by
the application. the application.
RTP_Rx may have knowledge of its buffering requirements. These RTP_Rx may have knowledge of its buffering requirements. These
requirements may be application and/or device specific. For requirements may be application and/or device specific. For
instance, RTP_Rx may need to have a certain amount of data in its instance, RTP_Rx may need to have a certain amount of data in its
application buffer to handle transmission jitter and/or to be able application buffer to handle transmission jitter and/or to be able
to support error-control methods. If RS is told the minimum to support error-control methods. If RS is told the minimum
buffering requirement of the receiver, it may tailor the burst buffering requirement of the receiver, it may tailor the burst(s)
more precisely, e.g., by choosing an appropriate starting point. more precisely, e.g., by choosing an appropriate starting point.
The methods used by RTP_Rx to determine this value are application The methods used by RTP_Rx to determine this value are application
specific, and thus, out of the scope of this document. specific, and thus, out of the scope of this document.
If specified, the amount of backfill that will be provided by the If specified, the amount of backfill that will be provided by the
unicast burst SHOULD NOT be smaller than the specified value since unicast bursts and any payload-specific information MUST NOT be
it will not be able to build up the desired level of buffer at smaller than the specified value since it will not be able to
RTP_Rx and may cause buffer underruns. build up the desired level of buffer at RTP_Rx and may cause
buffer underruns.
Type: 1 Type: 2
o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element
that denotes the maximum milliseconds of data that RTP_Rx can that denotes the maximum milliseconds of data that RTP_Rx can
buffer without losing the burst data due to buffer overflow. buffer without losing the data due to buffer overflow.
RTP_Rx may have knowledge of its buffering requirements. These RTP_Rx may have knowledge of its buffering requirements. These
requirements may be application or device specific. For instance, requirements may be application or device specific. For instance,
one particular RTP_Rx may have more physical memory than another one particular RTP_Rx may have more physical memory than another
RTP_Rx, and thus, can buffer more data. If RS knows the buffering RTP_Rx, and thus, can buffer more data. If RS knows the buffering
ability of the receiver, it may tailor the burst more precisely. ability of the receiver, it may tailor the burst(s) more
The methods used by the receiver to determine this value are precisely. The methods used by the receiver to determine this
application specific, and thus, out of scope. value are application specific, and thus, out of scope.
If specified, the amount of backfill that will be provided by the If specified, the amount of backfill that will be provided by the
unicast burst SHOULD NOT be larger than this value since it may unicast bursts and any payload-specific information MUST NOT be
cause buffer overflows at RTP_Rx. larger than this value since it may cause buffer overflows at
RTP_Rx.
Type: 2 Type: 3
o Max Receive Bitrate (32 bits): Optional TLV element that denotes o Max Receive Bitrate (64 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that the RTP receiver can the maximum bitrate (in bits per second) that the RTP receiver can
process the unicast burst. This rate should include whatever process the aggregation of the unicast burst(s) and any payload-
knowledge the receiver has that would provide an upper bound on specific information that will be provided by RS. The limits may
the unicast burst bitrate. The limits may include local receiver include local receiver limits as well as network limits that are
limits as well as network limits that are known to the receiver. known to the receiver.
If specified, the unicast burst bitrate SHOULD NOT be larger than If specified, the total bitrate of the unicast burst(s) plus any
this value since it may cause congestion and packet loss. payload-specific information MUST NOT be larger than this value
since it may cause congestion and packet loss.
Type: 3 Type: 4
o Request for Preamble Only (0 bits): Optional TLV element that
indicates that RTP_Rx is only requesting the preamble information
for the desired primary multicast stream(s). If this TLV element
exists in the RAMS-R message, RS SHOULD NOT send any burst packets
other than the preamble packets. Note that this TLV element does
not carry a Value field. Thus, the Length field MUST be set to
zero.
Type: 5
The semantics of the RAMS-R feedback message is independent of the The semantics of the RAMS-R feedback message is independent of the
payload type. payload type.
7.3. RAMS Information 7.3. RAMS Information
The RAMS Information message is identified by SFMT=2. The RAMS Information message is identified by SFMT=2. This message
is used to describe the unicast burst that will be sent for rapid
The FCI field MUST contain only one RAMS Information. acquisition. It also includes other useful information for RTP_Rx as
described below.
The RAMS Information is used to describe the unicast burst that will A separate RAMS-I message with the appropriate media sender SSRC and
be sent for rapid acquisition. It also includes other useful response code is sent by RS for each primary multicast stream that
information for RTP_Rx as described below. Optional payload-specific has been requested by RTP_Rx.
information MAY follow RAMS Information.
The FCI field has the structure depicted in Figure 7. The FCI field MUST contain only one RAMS Information. The FCI field
has the structure depicted in Figure 7.
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 7: FCI field syntax for the RAMS Information message Figure 7: FCI field syntax for the RAMS Information message
o Message Sequence Number (8 bits) : Mandatory field that denotes o Message Sequence Number (8 bits) : Mandatory field that denotes
the sequence number of this RAMS-I message. During rapid the sequence number of the RAMS-I message for the particular media
acquisition, multiple RAMS-I messages MAY be sent and/or the same sender SSRC specified in the message header. The MSN value SHALL
RAMS-I message MAY be repeated. The first RAMS-I message SHALL be set to zero only when a new RAMS request is received. During
have an MSN value of 0. This value SHALL NOT be changed if the rapid acquisition, the same RAMS-I message MAY be repeated for
same RAMS-I message is sent to the same RTP_Rx multiple times for redundancy purposes without incrementing the MSN value. If an
redundancy purposes. If a new information is conveyed in a new updated RAMS-I message will be sent (either with a new information
RAMS-I message, the MSN value SHALL be incremented by one. or an updated information), the MSN value SHALL be incremented by
one. In the MSN field, the regular wrapping rules apply.
o Response (16 bits): Mandatory field that denotes the RS response o Response (16 bits): Mandatory field that denotes the RS response
code for this RAMS-I message. This document defines several code for this RAMS-I message. This document defines several
initial response codes and registers them with IANA. If a new initial response codes and registers them with IANA. If a new
vendor-neutral response code will be defined, it MUST be vendor-neutral response code will be defined, it MUST be
registered with IANA through the guidelines specified in registered with IANA through the guidelines specified in
Section 12.6. If the new response code is intended to be used Section 12.6. If the new response code is intended to be used
privately by a vendor, there is no need for IANA management. privately by a vendor, there is no need for IANA management.
Instead, the vendor MUST use the private extension mechanism Instead, the vendor MUST use the private extension mechanism
(Section 7.1.2) to convey its message and MUST indicate this by (Section 7.1.2) to convey its message and MUST indicate this by
putting zero in the Response field. putting zero in the Response field.
o Media Sender SSRC (32 bits): Optional TLV element that specifies
the media sender SSRC of the unicast burst stream. While this
information is already available in the message header, it may be
useful to repeat it in an explicit field. For example, if FT_Ap
that received the RAMS-R message is associated with a single
primary multicast stream but the requested media sender SSRC does
not match the SSRC of the RTP stream associated with this FT_Ap,
RS SHOULD include this TLV element in the initial RAMS-I message
to let RTP_Rx know that the media sender SSRC has changed. If the
two SSRCs match, there is no need to include this TLV element.
Type: 31
o RTP Seqnum of the First Packet (16 bits): TLV element that o RTP Seqnum of the First Packet (16 bits): TLV element that
specifies the RTP sequence number of the first packet that will be specifies the RTP sequence number of the first packet that will be
sent in the retransmission session. This allows RTP_Rx to know sent in the respective RTP stream. This allows RTP_Rx to know
whether one or more packets sent by RS have been dropped at the whether one or more packets sent by RS have been dropped at the
beginning of the retransmission session. If RS accepts the RAMS beginning of the stream. If RS accepts the RAMS request, this
request, this element MUST exist. If RS rejects the RAMS request, element MUST exist. If RS rejects the RAMS request, this element
this element SHALL NOT exist. SHALL NOT exist.
Type: 31 Type: 32
o Earliest Multicast Join Time (32 bits): Optional TLV element that o Earliest Multicast Join Time (32 bits): TLV element that
specifies the time difference (i.e., delta time) between the specifies the delta time (in ms) between the arrival of the first
arrival of this RAMS-I message and the earliest time instant when RTP packet in the RTP stream (which could be a burst packet or a
RTP_Rx could join the primary multicast session in RTP ticks. A payload-specific packet) and the earliest time instant when RTP_Rx
zero value in this field means that RTP_Rx can join the primary SHOULD send an SFGMP Join message to join the multicast session.
multicast session right away. A zero value in this field means that RTP_Rx may send the SFGMP
Join message right away.
Note that if the RAMS request has been accepted, RS MUST send this If the RAMS request has been accepted, RS MUST send this field at
field at least once, so that RTP_Rx knows when to join the primary least once, so that RTP_Rx knows when to join the multicast
multicast session. If the burst request has been rejected as session. If the burst request has been rejected as indicated in
indicated in the Response field, this field MAY be omitted or set the Response field, this field MAY be omitted or set to zero. In
to 0. In that case, it is up to RTP_Rx when or whether to join that case, it is up to RTP_Rx when or whether to join the
the primary multicast session. multicast session.
Type: 32 It should be noted that when RS serves two or more bursts and
sends a separate RAMS-I message for each burst, the join times
specified in these RAMS-I messages should correspond to more or
less the same time instant, and RTP_Rx sends the SFGMP Join
message based on the earliest join time.
Type: 33
o Burst Duration (32 bits): Optional TLV element that denotes the o Burst Duration (32 bits): Optional TLV element that denotes the
duration of the burst that RS is planning to send (in RTP ticks). duration of the burst, i.e., the delta difference between the
In the absence of additional stimulus, RS will send a burst of first and the last burst packet, that RS is planning to send (in
this duration. However, the burst duration may be modified by ms) in the respective RTP stream. In the absence of additional
subsequent events, including changes in the primary multicast stimulus, RS will send a burst of this duration. However, the
stream and reception of RAMS-T messages. burst duration may be modified by subsequent events, including
changes in the primary multicast stream and reception of RAMS-T
messages.
Note that RS MUST terminate the flow in a deterministic timeframe, Note that RS MUST terminate the flow in a deterministic timeframe,
even if it does not get an RAMS-T or a BYE from RTP_Rx. It is even if it does not get a RAMS-T or a BYE from RTP_Rx. It is
optional to send this field in an RAMS-I message when the burst OPTIONAL to send this field in a RAMS-I message when the burst
request is accepted. If the burst request has been rejected as request is accepted. If the burst request has been rejected as
indicated in the Response field, this field MAY be omitted or set indicated in the Response field, this field MAY be omitted or set
to 0. to zero.
Type: 33 Type: 34
o Max Transmit Bitrate (32 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 RS. the maximum bitrate (in bits per second) that will be used by RS
for the RTP stream associated with this RAMS-I message.
Type: 34 Type: 35
The semantics of the RAMS-I feedback message is independent of the The semantics of the RAMS-I feedback message is independent of the
payload type. payload type.
The RAMS-I message MAY be sent multiple times at the start of, prior The initial RAMS-I message SHOULD precede the unicast burst or be
to, or during the unicast burst. The subsequent RAMS-I messages MAY sent at the start of the burst. Subsequent RAMS-I message(s) MAY be
signal changes in any of the fields. sent during the unicast burst and convey changes in any of the
fields.
7.4. RAMS Termination 7.4. RAMS Termination
The RAMS Termination message is identified by SFMT=3. The RAMS Termination message is identified by SFMT=3.
The FCI field MUST contain only one RAMS Termination. The RAMS Termination is used to assist RS in determining when to stop
the burst. A separate RAMS-T message is sent by RTP_Rx for each
The RAMS Termination may be used to assist RS in determining when to primary multicast stream that has been served by RS. Each of these
stop the burst. RAMS-T messages has the appropriate media sender SSRC populated in
its message header.
If prior to sending the RAMS-T message RTP_Rx has already joined the If RTP_Rx wants RS to stop a burst prematurely, it sends a plain
primary multicast session and received at least one RTP packet from RAMS-T message as described below. Upon receiving this message, RS
the multicast session, RTP_Rx includes the sequence number of the stops the respective burst immediately. If RTP_Rx wants RS to
first RTP packet in the RAMS-T message. With this information, RS terminate all of the bursts, it should send all of the respective
can decide when to terminate the unicast burst. RAMS-T messages in a single compound RTCP packet.
If RTP_Rx issues the RAMS-T message before it has joined and/or begun The default behavior for RTP_Rx is to send a RAMS-T message right
receiving RTP packets from the primary multicast session, RTP_Rx does after it joined the multicast session and started receiving multicast
not specify any sequence number in the RAMS-T message, which packets. In that case, RTP_Rx includes the sequence number of the
indicates RS to stop the burst immediately. However, the RAMS-T first RTP packet received in the primary multicast stream in the
message may get lost and RS may not receive this message. RAMS-T message. With this information, RS can decide when to
terminate the unicast burst.
The FCI field has the structure depicted in Figure 8. The FCI field MUST contain only one RAMS Termination. The FCI field
has the structure depicted in Figure 8.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=3 | Optional TLV-encoded Fields | | SFMT=3 | Reserved |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) : : Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: FCI field syntax for the RAMS Termination message Figure 8: FCI field syntax for the RAMS Termination message
o Extended RTP Seqnum of First Multicast Packet (32 bits): Optional o Extended RTP Seqnum of First Multicast Packet (32 bits): Optional
TLV element that specifies the extended RTP sequence number of the TLV element that specifies the extended RTP sequence number of the
of the first multicast packet received by RTP_Rx. If no RTP first packet received from the SSM session for a particular
packet has been received from the primary multicast session, this primary multicast stream. The low 16 bits contain the sequence
field does not exist and tells RS to stop the burst immediately. number of the first packet received from the SSM session, and the
most significant 16 bits extend that sequence number with the
corresponding count of sequence number cycles, which may be
maintained according to the algorithm in Appendix A.1 of
[RFC3550].
Type: 61 Type: 61
The semantics of the RAMS-T feedback message is independent of the The semantics of the RAMS-T feedback message is independent of the
payload type. payload type.
8. SDP Definitions and Examples 8. SDP Signaling
8.1. Definitions 8.1. Definitions
The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585]. The syntax of the 'rtcp-fb' attribute has been defined in [RFC4585].
Here we add the following syntax to the 'rtcp-fb' attribute (the Here we add the following syntax to the 'rtcp-fb' attribute (the
feedback type and optional parameters are all case sensitive): feedback type and optional parameters are all case sensitive):
(In the following ABNF [RFC5234], fmt, SP and CRLF are used as (In the following ABNF [RFC5234], fmt, SP and CRLF are used as
defined in [RFC4566].) defined in [RFC4566].)
rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF rtcp-fb-syntax = "a=rtcp-fb:" rtcp-fb-pt SP rtcp-fb-val CRLF
rtcp-fb-pt = "*" ; wildcard: applies to all formats rtcp-fb-pt = "*" ; wildcard: applies to all formats
/ fmt ; as defined in SDP spec / fmt ; as defined in SDP spec
rtcp-fb-val = "nack" SP "ssli" rtcp-fb-val = "nack" SP "ssli"
The following parameter is defined in this document for use with The following parameter is defined in this document for use with
'nack': 'nack':
skipping to change at page 31, line 34 skipping to change at page 36, line 17
/ fmt ; as defined in SDP spec / fmt ; as defined in SDP spec
rtcp-fb-val = "nack" SP "ssli" rtcp-fb-val = "nack" SP "ssli"
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 'ssli' stands for Stream Synchronization Loss Indication and o 'ssli' stands for Stream Synchronization Loss Indication and
indicates the use of RAMS messages as defined in Section 7. indicates the use of RAMS messages as defined in Section 7.
This document also defines a new SDP attribute ('rams-updates') that This document also defines a new media-level SDP attribute ('rams-
indicates whether RS supports updated request messages or not. This updates') that indicates whether RS supports updated request messages
attribute is used in a declarative manner. If RS supports updated or not. This attribute is used in a declarative manner. If RS
request messages and this attribute is included in the SDP supports updated request messages and this attribute is included in
description, RTP_Rx MAY send updated requests. RS may or may not be the SDP description, RTP_Rx may send updated requests. RS may or may
able to accept value changes in every field in an RAMS-R message. not be able to accept value changes in every field in an updated
However, if the 'rams-updates' attribute is not included in the SDP RAMS-R message. However, if the 'rams-updates' attribute is not
description, RTP_Rx SHALL NOT send updated requests (RTP_Rx MAY included in the SDP description, RTP_Rx SHALL NOT send updated
repeat its initial request without changes, though). requests (RTP_Rx MAY still repeat its initial request without
changes, though).
8.2. Examples 8.2. Requirements
This section provides a declarative SDP [RFC4566] example for The use of SDP to describe the RAMS entities normatively requires the
enabling rapid acquisition of multicast RTP sessions. The following support for:
example uses the SDP grouping semantics [I-D.ietf-mmusic-rfc3388bis],
the RTP/AVPF profile [RFC4585], the RTP retransmissions [RFC4588],
the RTCP extensions for SSM sessions with unicast feedback
[I-D.ietf-avt-rtcpssm] and the source-specific media attributes
[RFC5576]. o The SDP grouping semantics [I-D.ietf-mmusic-rfc3388bis]
In the example shown Figure 9, we have a primary multicast stream and o The RTP/AVPF profile [RFC4585]
a unicast retransmission stream. The source stream is multicast from
a distribution source (with a source IP address of 192.0.2.2) to the
multicast destination address of 233.252.0.2 and port 41000. A
Retransmission Server including feedback target functionality (with
an address of 192.0.2.1 and port of 41001) is specified with the
'rtcp' attribute. The RTP receiver(s) can report missing packets on
the source stream to the feedback target and request retransmissions.
In the RAMS context, the parameter 'rtx-time' specifies the time in
milliseconds that the Retransmission Server keeps an RTP packet in
its buffer available for retransmission (measured from the time the
packet was received by the Retransmission Server).
The RTP retransmissions are sent on a unicast session with a o The RTP retransmissions [RFC4588]
destination port of 41002. The RTCP port for the unicast session
(41003) is specified with the 'rtcp' attribute. In this example,
both the conventional retransmission and rapid acquisition support
are enabled. This is achieved by the additional "a=rtcp-fb:98 nack
ssli" line. Note that this SDP includes the "a=sendonly" line for
the media description of the retransmission stream and is for the
Retransmission Server (RS). Its counterpart for the RTP Receiver
(RTP_Rx) includes the "a=recvonly" line as shown in Figure 10.
When an RTP receiver requires rapid acquisition for a new multicast o The RTCP extensions for SSM sessions with unicast feedback
session it wants to join, it sends an RAMS-R message to the feedback [I-D.ietf-avt-rtcpssm]
target of that primary multicast session. This feedback message has
to have the SSRC of the primary multicast stream for which rapid
acquisition is requested for. However, since this RTP receiver has
not received any RTP packets from the primary multicast session yet,
the RTP receiver MUST learn the SSRC value from the 'ssrc' attribute
of the media description [I-D.ietf-avt-rtcpssm]. In addition to the
SSRC value, the 'cname' source attribute MUST also be present in the
SDP description [RFC5576].
Note that listing the SSRC values for the primary multicast sessions The support for the source-specific media attributes [RFC5576] may be
required in some deployments as described below.
8.3. Examples
This section provides a declarative SDP [RFC4566] example for
enabling rapid acquisition of multicast RTP sessions.
In the example shown Figure 9, we have a primary multicast (source)
stream and a unicast retransmission stream. The source stream is
multicast from a distribution source (with a source IP address of
198.51.100.1) to the multicast destination address of 233.252.0.2 and
port 41000. A Retransmission Server including feedback target
functionality (with an address of 192.0.2.1 and port of 41001) is
specified with the 'rtcp' attribute. The RTP receiver(s) can report
missing packets on the source stream to the feedback target and
request retransmissions. In the RAMS context, the parameter 'rtx-
time' specifies the time in milliseconds that the Retransmission
Server keeps an RTP packet in its cache available for retransmission
(measured from the time the packet was received by the Retransmission
Server).
In this example, both the conventional retransmission and rapid
acquisition support are enabled. This is achieved by the "a=rtcp-
fb:98 nack ssli" line. Note that this SDP includes the "a=sendonly"
line for the media description of the retransmission stream and is
for the Retransmission Server (RS). Its counterpart for the RTP
Receiver (RTP_Rx) includes the "a=recvonly" line as shown in
Figure 10.
When an RTP receiver asks for rapid acquisition before it joins a
primary multicast RTP session, it sends a RAMS-R message to the
feedback target of that primary multicast RTP session. If FT_Ap is
associated with only one RTP stream, the RTP receiver does not need
to learn the SSRC of that stream via an out-of-band method. If RS
accepts the request, it will send an RAMS-I message with the correct
SSRC identifier. If FT_Ap is associated with a multi-stream RTP
session and the RTP receiver is willing to request rapid acquisition
for the entire session, the RTP receiver again does not need to learn
the SSRCs via an out-of-band method. However, if the RTP receiver is
willing to request a particular subset of the primary multicast
streams, it must learn their SSRC identifiers and list them in the
RAMS-R message. Since this RTP receiver has not yet received any RTP
packets for the primary multicast stream(s), the RTP receiver must in
this case learn the SSRC value(s) from the 'ssrc' attribute of the
media description. In addition to the SSRC value, the 'cname' source
attribute must also be present in the SDP description [RFC5576].
Note that listing the SSRC values for the primary multicast streams
in the SDP file does not create a problem in SSM sessions when an in the SDP file does not create a problem in SSM sessions when an
SSRC collision occurs. This is because in SSM sessions, an RTP SSRC collision occurs. This is because in SSM sessions, an RTP
receiver that observed an SSRC collision with a media source MUST receiver that observed an SSRC collision with a media sender MUST
change its own SSRC [I-D.ietf-avt-rtcpssm] by following the rules change its own SSRC [I-D.ietf-avt-rtcpssm] by following the rules
defined in [RFC3550]. defined in [RFC3550].
A feedback target that receives an RAMS-R feedback message becomes A feedback target that receives a RAMS-R feedback message becomes
aware that the prediction chain at the RTP receiver side has been aware that the prediction chain at the RTP receiver side has been
broken or does not exist any more. If the necessary conditions are broken or does not exist anymore. If the necessary conditions are
satisfied (as outlined in Section 7 of [RFC4585]) and available satisfied (as outlined in Section 7 of [RFC4585]) and available
resources exist, RS MAY react to the RAMS-R message by sending any resources exist, RS may react to the RAMS-R message by sending any
transport-layer and payload-specific feedback message(s) and starting transport-layer and payload-specific feedback message(s) and starting
the unicast burst. the unicast burst.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=Rapid Acquisition Example s=Rapid Acquisition Example
t=0 0 t=0 0
a=group:FID 3 4 a=group:FID 1 2
a=rtcp-unicast:rsi a=rtcp-unicast:rsi
m=video 41000 RTP/AVPF 98 m=video 41000 RTP/AVPF 98
i=Primary Multicast Stream #2 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 192.0.2.2 a=source-filter: incl IN IP4 233.252.0.2 198.51.100.1
a=recvonly a=recvonly
a=rtpmap:98 MP2T/90000 a=rtpmap:98 MP2T/90000
a=rtcp:41001 IN IP4 192.0.2.1 a=rtcp:41001 IN IP4 192.0.2.1
a=rtcp-fb:98 nack a=rtcp-fb:98 nack
a=rtcp-fb:98 nack ssli a=rtcp-fb:98 nack ssli
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=mid:3 a=mid:1
m=video 41002 RTP/AVPF 99 m=video 41002 RTP/AVPF 99
i=Unicast Retransmission Stream #2 (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:41003 a=rtcp:41003
a=fmtp:99 apt=98; rtx-time=5000 a=fmtp:99 apt=98; rtx-time=5000
a=mid:4 a=mid:2
Figure 9: Example SDP for RS when RAMS support is enabled Figure 9: Example SDP for RS when RAMS support is enabled
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=Rapid Acquisition Example s=Rapid Acquisition Example
t=0 0 t=0 0
a=group:FID 3 4 a=group:FID 1 2
a=rtcp-unicast:rsi a=rtcp-unicast:rsi
m=video 41000 RTP/AVPF 98 m=video 41000 RTP/AVPF 98
i=Primary Multicast Stream #2 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 192.0.2.2 a=source-filter: incl IN IP4 233.252.0.2 198.51.100.1
a=recvonly a=recvonly
a=rtpmap:98 MP2T/90000 a=rtpmap:98 MP2T/90000
a=rtcp:41001 IN IP4 192.0.2.1 a=rtcp:41001 IN IP4 192.0.2.1
a=rtcp-fb:98 nack a=rtcp-fb:98 nack
a=rtcp-fb:98 nack ssli a=rtcp-fb:98 nack ssli
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=mid:3 a=mid:1
m=video 41002 RTP/AVPF 99 m=video 41002 RTP/AVPF 99
i=Unicast Retransmission Stream #2 (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=recvonly a=recvonly
a=rtpmap:99 rtx/90000 a=rtpmap:99 rtx/90000
a=rtcp:41003 a=rtcp:41003
a=fmtp:99 apt=98; rtx-time=5000 a=fmtp:99 apt=98; rtx-time=5000
a=mid:4 a=mid:2
Figure 10: Example SDP for RTP_Rx when RAMS support is enabled Figure 10: Example SDP for RTP_Rx when RAMS support is enabled
In the above SDP descriptions, the ports for the unicast session are
also declaratively specified and the RTP receivers are required to
use them. In certain scenarios, however, RTP receivers may want to
use other desired ports to receive the burst and retransmission
packets. A current work considers this feature in more general terms
and provides the recommended mechanisms
[I-D.begen-avt-ports-for-ucast-mcast-rtp].
In this section, we considered the simplest scenario where the In this section, we considered the simplest scenario where the
primary multicast session carried only one multicast stream and the primary multicast RTP session carried only one stream and the RTP
RTP receiver wanted to rapidly acquire this stream only. Discussions receiver wanted to rapidly acquire this stream only. Best practices
on scenarios where the primary multicast session carries two or more for scenarios where the primary multicast RTP session carries two or
multicast streams or the RTP receiver wants to acquire one or more more streams or the RTP receiver wants to acquire one or more streams
multicast streams from multiple multicast RTP sessions at the same from multiple primary multicast RTP sessions at the same time are
time are presented in [I-D.begen-avt-rams-scenarios]. presented in [I-D.begen-avt-rams-scenarios].
Editor's note: Should we keep the text above?
9. NAT Considerations 9. NAT Considerations
For a variety of reasons, one or more NAPT devices (hereafter simply For a variety of reasons, one or more NAPT devices (hereafter simply
called NAT) are expected to exist between RTP_Rx and RS. NATs have a called NAT) may exist between RTP_Rx and RS. NATs have a variety of
variety of operating characteristics for UDP traffic [RFC4787]. For operating characteristics for UDP traffic [RFC4787]. For a NAT to
a NAT to permit traffic from RS to arrive at RTP_Rx, the NAT(s) must permit traffic from RS to arrive at RTP_Rx, the NAT(s) must first
first either: either:
a. See UDP traffic sent from RTP_Rx (which is on the 'inside' of the a. See UDP traffic sent from RTP_Rx (which is on the 'inside' of the
NAT) to RS (which is on the 'outside' of the NAT). This traffic NAT) to RS (which is on the 'outside' of the NAT). This traffic
is sent to the same transport address as the subsequent response is sent to the same transport address as the subsequent response
traffic, OR; traffic, or;
b. Be configured to forward certain ports (e.g., using HTML b. Be configured to forward certain ports (e.g., using HTML
configuration, UPnP IGD [UPnP-IGD], DLNA [DLNA]). Details of configuration, UPnP IGD [UPnP-IGD], DLNA [DLNA]). Details of
this are out of scope of this document. this are out of scope of this document.
For both (a) and (b), RTP_Rx is responsible for maintaining the NAT's For both (a) and (b), RTP_Rx is responsible for maintaining the NAT's
state if it wants to receive traffic from the RS on that port. For state if it wants to receive traffic from the RS on that port. For
(a), RTP_Rx MUST send UDP traffic to keep the NAT binding alive, at (a), RTP_Rx MUST send UDP traffic to keep the NAT binding alive, at
least every 30 seconds [RFC4787]. Note that while (a) is more like least every 30 seconds [RFC4787]. Note that 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.
10. Known Implementations When RTP_Rx sends a RAMS-R message in the primary multicast RTP
session and the request is received by RS, a new unicast RTP
10.1. Open Source RTP Receiver Implementation by Cisco retransmission session will be established between RS and RTP_Rx.
An open source RTP Receiver code that implements the functionalities
introduced in this document is available. For documentation, visit
the following URL:
http://www.cisco.com/en/US/docs/video/cds/cda/vqe/3_4/user/guide/
vqe_guide3_4.html
The code is also available at:
ftp://ftpeng.cisco.com/ftp/vqec/
Note that this code is under development and may be based on an
earlier version of this document. As we make progress in the draft,
the source code will also be updated to reflect the changes.
Some preliminary results based on this code are available in [CCNC09]
and [IC2009].
10.2. IPTV Commercial Implementation by Microsoft While the ports on the RS side are already signaled via out-of-band
means (e.g., SDP), RTP_Rx may need to convey to RS the RTP and RTCP
ports it wants to use on its side for the new session. Since there
are two RTP sessions involved during this process and one of them is
established upon a feedback message sent in the other one, this
requires an explicit port mapping method. This problem equally
applies to scenarios where the RTP media is multicast in an SSM
session, and an RTP receiver requests retransmission from a local
repair server by using the RTCP NACK messages for the missing packets
and the repair server retransmits the requested packets over a
unicast session. Thus, instead of laying out a specific solution for
the RAMS applications, a general solution is introduced in
[I-D.begen-avt-ports-for-ucast-mcast-rtp].
Rapid Acquisition of Multicast RTP Sessions is supported as part of Applications using RAMS MUST support this solution both on the RS and
the Microsoft Mediaroom Internet Protocol Television (IPTV) and RTP_Rx side to allow RTP receivers to use their desired ports and to
multimedia software platform. This system is in wide commercial support RAMS behind NAT devices.
deployment. More information can be found at:
http://www.microsoft.com/mediaroom 10. Congestion Control Considerations
http://informitv.com/articles/2008/10/13/channelchangetimes/ Editor's note: Text for this section will be provided by Magnus W.
11. Security Considerations 11. 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 [I-D.ietf-avt-rtcpssm] and the feedback mechanism described in [I-D.ietf-avt-rtcpssm] and the
payload format defined in [RFC4588]. Thus, these applications are payload format defined in [RFC4588]. Thus, these applications are
subject to the general security considerations discussed in subject to the general security considerations discussed in
[I-D.ietf-avt-rtcpssm] and [RFC4588]. In this section, we give an [I-D.ietf-avt-rtcpssm] and [RFC4588]. In this section, we give an
overview of the guidelines and suggestions described in these overview of the guidelines and suggestions described in these
specifications from a RAMS perspective. We also discuss the security specifications from a RAMS perspective. We also discuss the security
considerations that explicitly apply to RAMS applications. considerations that 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
sources, Retransmission Servers and RTP Receivers. Adequate security senders, Retransmission Servers and RTP receivers. Adequate security
measures are RECOMMENDED to ensure the integrity and authenticity of measures are RECOMMENDED to ensure the integrity and authenticity of
the SDP descriptions so that transport addresses of the media the SDP descriptions so that transport addresses of the media
sources, Feedback Targets as well as other session-specific senders, distribution sources, feedback targets as well as other
information can be authenticated. session-specific information can be authenticated.
Compared to an RTCP NACK message that triggers one or more Compared to an RTCP NACK message that triggers one or more
retransmissions, an RAMS Request (RAMS-R) message may trigger a new retransmissions, a RAMS Request (RAMS-R) message may 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 may contain potentially a large number of resulting burst stream may contain potentially a large number of
retransmission packets. Since these packets are sent at a faster retransmission packets. Since these packets are sent at a faster
than the nominal rate of the multicast session, RAMS consumes more than the nominal rate, RAMS consumes more resources on the
resources on the Retransmission Server, the RTP Receiver and the Retransmission Server, the RTP receiver and the network. This
network. This particularly makes denial-of-service attacks more particularly makes denial-of-service attacks more intense, and hence,
intense, and hence, more harmful than attacks that target ordinary more harmful than attacks that target ordinary retransmission
retransmission sessions. sessions.
Following the suggestions given in [RFC4588], counter-measures SHOULD Following the suggestions given in [RFC4588], counter-measures SHOULD
be taken to prevent tampered or spoofed RTCP packets. Tampered be taken to prevent tampered or spoofed RTCP packets. Tampered
RAMS-R messages may trigger inappropriate burst streams or alter the RAMS-R messages may trigger inappropriate burst streams or alter the
existing burst streams in an inappropriate way. For example, if the existing burst streams in an inappropriate way. For example, if the
Max Receive Bitrate field is altered by a tampered RAMS-R message, Max Receive Bitrate field is altered by a tampered RAMS-R message,
the updated burst may overflow the buffer on the receiver side, or the updated burst may overflow the buffer on the receiver side, or
oppositely, may slow down the burst to the point that it is useless. oppositely, may slow down the burst to the point that it becomes
Tampered RAMS Termination (RAMS-T) messages may terminate valid burst useless. Tampered RAMS Termination (RAMS-T) messages may terminate
streams pre-maturely resulting in gaps in the received RTP packets. valid burst streams pre-maturely resulting in gaps in the received
RAMS Information (RAMS-I) messages contain fields that are critical RTP packets. RAMS Information (RAMS-I) messages contain fields that
for the success of the RAMS operation. Any tampered information in are critical for the success of the RAMS operation. Any tampered
the RAMS-I message may easily cause the RTP Receiver to make wrong information in the RAMS-I message may easily cause the RTP receiver
decisions. Consequently, the RAMS operation may fail. to make wrong decisions. Consequently, the RAMS operation may fail.
While most of the denial-of-service attacks can be prevented by the While most of the denial-of-service attacks can be prevented by the
integrity and authenticity checks enabled by SRTP, an attack can integrity and authenticity checks enabled by SRTP, an attack can
still be started by legitimate endpoints that send several valid still be started by legitimate endpoints that send several valid
RAMS-R messages to a particular Feedback Target in a synchronized RAMS-R messages to a particular feedback target in a synchronized
fashion and very short amount of time. Since a RAMS operation may fashion and very short amount of time. Since a RAMS operation may
temporarily consume a large amount of resources, a series of the temporarily consume a large amount of resources, a series of the
RAMS-R messages may temporarily overload the Retransmission Server. RAMS-R messages may temporarily overload the Retransmission Server.
In these circumstances, the Retransmission Server may, for example, In these circumstances, the Retransmission Server may, for example,
reject incoming RAMS requests until its resources become available reject incoming RAMS requests until its resources become available
again. One means to ameliorate this threat is to apply a per- again. One means to ameliorate this threat is to apply a per-
endpoint policing mechanism on the incoming RAMS requests. A endpoint policing mechanism on the incoming RAMS requests. A
reasonable policing mechanism should consider application-specific reasonable policing mechanism should consider application-specific
requirements and minimize false negatives. requirements and minimize false negatives.
skipping to change at page 39, line 24 skipping to change at page 44, line 7
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 to be managed by the IANA according to
the Specification Required policy of [RFC5226]. the 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]
1 RAMS Request [RFCXXXX] 1 RAMS Request [RFCXXXX]
2 RAMS Information [RFCXXXX] 2 RAMS Information [RFCXXXX]
3 RAMS Termination [RFCXXXX] 3 RAMS Termination [RFCXXXX]
4-254 Specification Reqired
255 Reserved [RFCXXXX]
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 MUST contain the Any registration for an unassigned SFMT value MUST 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
skipping to change at page 40, line 12 skipping to change at page 45, line 7
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
---- -------------------------------------------------- ------------- ---- -------------------------------------------------- -------------
1 Min RAMS Buffer Fill Requirement [RFCXXXX] 0 Reserved [RFCXXXX]
2 Max RAMS Buffer Fill Requirement [RFCXXXX] 1 Requested Media Sender SSRC(s) [RFCXXXX]
3 Max Receive Bitrate [RFCXXXX] 2 Min RAMS Buffer Fill Requirement [RFCXXXX]
31 RTP Seqnum of the First Packet [RFCXXXX] 3 Max RAMS Buffer Fill Requirement [RFCXXXX]
32 Earliest Multicast Join Time [RFCXXXX] 4 Max Receive Bitrate [RFCXXXX]
33 Burst Duration [RFCXXXX] 5 Request for Preamble Only [RFCXXXX]
34 Max Transmit Bitrate [RFCXXXX] 6-30 Specification Reqired
31 Media Sender SSRC [RFCXXXX]
32 RTP Seqnum of the First Packet [RFCXXXX]
33 Earliest Multicast Join Time [RFCXXXX]
34 Burst Duration [RFCXXXX]
35 Max Transmit Bitrate [RFCXXXX]
36-60 Specification Reqired
61 Extended RTP Seqnum of First Multicast Packet [RFCXXXX] 61 Extended RTP Seqnum of First Multicast Packet [RFCXXXX]
62-127 Specification Reqired
128-254 No IANA Maintenance
255 Reserved [RFCXXXX]
Any registration for an unassigned Type value MUST contain the Any registration for an unassigned Type value MUST 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.
skipping to change at page 41, line 4 skipping to change at page 46, line 12
following an HTTP-style code numbering in this document. New following an HTTP-style code numbering in this document. New
response codes SHALL follow the guidelines below: response codes SHALL follow the guidelines below:
Code Level Purpose Code Level Purpose
---------- --------------- ---------- ---------------
1xx Informational 1xx Informational
2xx Success 2xx Success
3xx Redirection 3xx Redirection
4xx RTP Receiver Error 4xx RTP Receiver Error
5xx Retransmission Server Error 5xx Retransmission Server Error
The Response code 65536 is reserved for future use. The Response code 65536 is reserved for future use.
The registry is initialized with the following entries: The registry is initialized with the following entries:
Code Description Reference Code Description Reference
----- -------------------------------------------------- ------------- ----- -------------------------------------------------- -------------
0 A private response code is included in the message [RFCXXXX] 0 A private response code is included in the message [RFCXXXX]
100 Parameter update for RAMS session [RFCXXXX] 100 Parameter update for RAMS session [RFCXXXX]
101 RAMS session was terminated by RAMS-T [RFCXXXX]
102 RAMS session was terminated by RS [RFCXXXX]
200 RAMS request has been accepted [RFCXXXX] 200 RAMS request has been accepted [RFCXXXX]
201 Unicast burst has been completed [RFCXXXX] 201 Unicast burst has been completed [RFCXXXX]
400 Invalid RAMS-R message syntax 400 Invalid RAMS-R message syntax
401 Invalid min buffer requirement in RAMS-R message [RFCXXXX] 401 Invalid min buffer requirement in RAMS-R message [RFCXXXX]
402 Invalid max buffer requirement in RAMS-R message [RFCXXXX] 402 Invalid max buffer requirement in RAMS-R message [RFCXXXX]
403 Invalid max bw requirement in RAMS-R message [RFCXXXX] 403 Invalid max bitrate requirement in RAMS-R message [RFCXXXX]
500 An unspecified RS internal error has occurred [RFCXXXX] 500 An unspecified RS internal error has occurred [RFCXXXX]
501 RS has no bandwidth to start RAMS session [RFCXXXX] 501 RS has no bandwidth to start RAMS session [RFCXXXX]
502 RS has no CPU available to start RAMS session [RFCXXXX] 502 RS has no CPU available to start RAMS session [RFCXXXX]
503 RAMS functionality is not available on RS [RFCXXXX] 503 RAMS functionality is not available on RS [RFCXXXX]
504 RAMS functionality is not available for RTP_Rx [RFCXXXX] 504 RAMS functionality is not available for RTP_Rx [RFCXXXX]
505 RAMS functionality is not available for 505 RAMS functionality is not available for
the requested multicast stream [RFCXXXX] the requested multicast stream [RFCXXXX]
506 RS has no a valid starting point available for 506 RS has no valid starting point available for
the requested multicast stream [RFCXXXX] the requested multicast stream [RFCXXXX]
507 RS has no reference information available for 507 RS has no reference information available for
the requested multicast stream [RFCXXXX] the requested multicast stream [RFCXXXX]
508 RS has no RTP stream matching the requested SSRC [RFCXXXX]
509 RAMS request to acquire the entire session
has been denied [RFCXXXX]
510 Only the preamble information is sent [RFCXXXX]
511 RAMS request has been denied due to a policy [RFCXXXX]
Any registration for an unassigned Response code MUST contain the Any registration for an unassigned Response code MUST 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.
13. Acknowledgments 13. Contributors
The authors would like to specially thank Peilin Yang for his Dave Oran and Magnus Westerlund have contributed significantly to
contributions to this document and detailed reviews. this specification by providing text and solutions to some of the
issues raised during the development of this specification.
The authors also thank the following individuals for their 14. Acknowledgments
contributions, comments and suggestions to this document: Dave Oran,
Dan Wing, Tony Faustini, Jeff Goldberg, Muriel Deschanel, Orit Levin,
Roni Even, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui Wang, Zixuan
Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan Lennox and
Sean Sheedy.
14. Change Log The following individuals have reviewed the earlier versions of this
specification and provided helpful comments: Colin Perkins, Joerg
Ott, Roni Even, Dan Wing, Tony Faustini, Peilin Yang, Jeff Goldberg,
Muriel Deschanel, Orit Levin, Guy Hirson, Tom Taylor, Xavier Marjou,
Ye-Kui Wang, Zixuan Zou, Ingemar Johansson, Haibin Song, Ning Zong,
Jonathan Lennox and Sean Sheedy.
14.1. draft-ietf-avt-rapid-acquisition-for-rtp-05 15. Change Log
15.1. draft-ietf-avt-rapid-acquisition-for-rtp-06
The following are the major changes compared to version 05:
o Comments from WGLC have been addressed. See the mailing list for
the list of changes.
o Support for multi-stream RTP sessions has been added.
o NAT section has been revised.
15.2. draft-ietf-avt-rapid-acquisition-for-rtp-05
The following are the major changes compared to version 04: The following are the major changes compared to version 04:
o Editorial changes throughout the document. o Editorial changes throughout the document.
14.2. draft-ietf-avt-rapid-acquisition-for-rtp-04 15.3. draft-ietf-avt-rapid-acquisition-for-rtp-04
The following are the major changes compared to version 03: The following are the major changes compared to version 03:
o Clarifications for the definition of RS. o Clarifications for the definition of RS.
o Response codes have been defined. o Response codes have been defined.
14.3. draft-ietf-avt-rapid-acquisition-for-rtp-03 15.4. draft-ietf-avt-rapid-acquisition-for-rtp-03
The following are the major changes compared to version 02: The following are the major changes compared to version 02:
o Clarifications for the RAMS-I message. o Clarifications for the RAMS-I message.
o Type values have been assigned. o Type values have been assigned.
14.4. draft-ietf-avt-rapid-acquisition-for-rtp-02 15.5. draft-ietf-avt-rapid-acquisition-for-rtp-02
The following are the major changes compared to version 01: The following are the major changes compared to version 01:
o Port mapping discussion has been removed since it will be o Port mapping discussion has been removed since it will be
discussed in a separate draft. discussed in a separate draft.
o Security considerations section has been added. o Security considerations section has been added.
o Burst shaping section has been completed. o Burst shaping section has been completed.
o Most of the outstanding open issues have been addressed. o Most of the outstanding open issues have been addressed.
14.5. draft-ietf-avt-rapid-acquisition-for-rtp-01 15.6. draft-ietf-avt-rapid-acquisition-for-rtp-01
The following are the major changes compared to version 00: The following are the major changes compared to version 00:
o Formal definitions of vendor-neutral and private extensions and o Formal definitions of vendor-neutral and private extensions and
their IANA registries have been added. their IANA registries have been added.
o SDP examples were explained in more detail. o SDP examples were explained in more detail.
o The sub-FMT field has been introduced in the RAMS messages for o The sub-FMT field has been introduced in the RAMS messages for
message type identification. message type identification.
o Some terminology has been fixed. o Some terminology has been fixed.
o NAT considerations section has been added. o NAT considerations section has been added.
14.6. draft-ietf-avt-rapid-acquisition-for-rtp-00 15.7. draft-ietf-avt-rapid-acquisition-for-rtp-00
This is a resubmission of version 03 as a WG item. This is a resubmission of version 03 as a WG item.
14.7. draft-versteeg-avt-rapid-synchronization-for-rtp-03 15.8. draft-versteeg-avt-rapid-synchronization-for-rtp-03
The following are the major changes compared to version 02: The following are the major changes compared to version 02:
o The title and message names have been changed. o The title and message names have been changed.
o RTCP message semantics have been added. RAMS protocol has been o RTCP message semantics have been added. RAMS protocol has been
revised to handle updated requests and responses. revised to handle updated requests and responses.
o Definitions have been revised. o Definitions have been revised.
o RTP/RTCP muxing reference has been added. o RTP/RTCP muxing reference has been added.
14.8. draft-versteeg-avt-rapid-synchronization-for-rtp-02 15.9. draft-versteeg-avt-rapid-synchronization-for-rtp-02
The following are the major changes compared to version 01: The following are the major changes compared to version 01:
o The discussion around MPEG2-TS has been moved to another document. o The discussion around MPEG2-TS has been moved to another document.
o The RAMS-R, RAMS-I and RAMS-T messages have been extensively o The RAMS-R, RAMS-I and RAMS-T messages have been extensively
modified and they have been made mandatory. modified and they have been made mandatory.
o IANA Considerations section has been updated. o IANA Considerations section has been updated.
o The discussion of RTCP XR report has been moved to another o The discussion of RTCP XR report has been moved to another
document. document.
o A new section on protocol design considerations has been added. o A new section on protocol design considerations has been added.
14.9. draft-versteeg-avt-rapid-synchronization-for-rtp-01 15.10. draft-versteeg-avt-rapid-synchronization-for-rtp-01
The following are the major changes compared to version 00: The following are the major changes compared to version 00:
o The core of the rapid synchronization method is now payload- o The core of the rapid synchronization method is now payload-
independent. But, the draft still defines payload-specific independent. But, the draft still defines payload-specific
messages that are required for enabling rapid synch for the RTP messages that are required for enabling rapid synch for the RTP
flows carrying MPEG2-TS. flows carrying MPEG2-TS.
o RTCP APP packets have been removed, new RTCP transport-layer and o RTCP APP packets have been removed, new RTCP transport-layer and
payload-specific feedback messages have been defined. payload-specific feedback messages have been defined.
o The step for leaving the current multicast session has been o The step for leaving the current multicast session has been
removed from Section 6.2. removed from Section 6.2.
o A new RTCP XR (Multicast Join) report has been defined. o A new RTCP XR (Multicast Join) report has been defined.
o IANA Considerations section have been updated. o IANA Considerations section have been updated.
o Editorial changes to clarify several points. o Editorial changes to clarify several points.
15. References 16. References
15.1. Normative References 16.1. Normative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. 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.
[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
skipping to change at page 45, line 38 skipping to change at page 51, line 17
Media Attributes in the Session Description Protocol Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, June 2009. (SDP)", RFC 5576, June 2009.
[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.
[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
Header Extensions", RFC 5285, July 2008.
[I-D.ietf-avt-rapid-rtp-sync]
Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", draft-ietf-avt-rapid-rtp-sync-09 (work in
progress), January 2010.
[I-D.begen-avt-ports-for-ucast-mcast-rtp]
Begen, A. and B. Steeg, "Port Mapping Between Unicast and
Multicast RTP Sessions",
draft-begen-avt-ports-for-ucast-mcast-rtp-01 (work in
progress), October 2009.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
15.2. Informative References 16.2. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[I-D.ietf-rmt-pi-norm-revised]
Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast Transport Protocol",
draft-ietf-rmt-pi-norm-revised-14 (work in progress),
September 2009.
[I-D.begen-avt-rams-scenarios] [I-D.begen-avt-rams-scenarios]
Begen, A., "Considerations for RAMS Scenarios", Begen, A., "Considerations for RAMS Scenarios",
draft-begen-avt-rams-scenarios-00 (work in progress), draft-begen-avt-rams-scenarios-00 (work in progress),
October 2009. October 2009.
[I-D.begen-avt-rtp-mpeg2ts-preamble] [I-D.begen-avt-rtp-mpeg2ts-preamble]
Begen, A. and E. Friedrich, "RTP Payload Format for Begen, A. and E. Friedrich, "RTP Payload Format for
MPEG2-TS Preamble", MPEG2-TS Preamble",
draft-begen-avt-rtp-mpeg2ts-preamble-03 (work in draft-begen-avt-rtp-mpeg2ts-preamble-04 (work in
progress), October 2009. progress), December 2009.
[I-D.begen-avt-rapid-sync-rtcp-xr] [I-D.begen-avt-rapid-sync-rtcp-xr]
Begen, A. and E. Friedrich, "Multicast Acquisition Report Begen, A. and E. Friedrich, "Multicast Acquisition Report
Block Type for RTCP XR", Block Type for RTCP XR",
draft-begen-avt-rapid-sync-rtcp-xr-03 (work in progress), draft-begen-avt-rapid-sync-rtcp-xr-03 (work in progress),
October 2009. October 2009.
[I-D.ietf-avt-rapid-rtp-sync]
Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", draft-ietf-avt-rapid-rtp-sync-07 (work in
progress), November 2009.
[I-D.westerlund-avt-ecn-for-rtp] [I-D.westerlund-avt-ecn-for-rtp]
Westerlund, M., Johansson, I., Perkins, C., and K. Westerlund, M., Johansson, I., Perkins, C., and K.
Carlberg, "Explicit Congestion Notification (ECN) for RTP Carlberg, "Explicit Congestion Notification (ECN) for RTP
over UDP", draft-westerlund-avt-ecn-for-rtp-02 (work in over UDP", draft-westerlund-avt-ecn-for-rtp-02 (work in
progress), October 2009. progress), October 2009.
[I-D.ietf-avt-rtp-and-rtcp-mux] [I-D.ietf-fecframe-interleaved-fec-scheme]
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Begen, A., "RTP Payload Format for 1-D Interleaved Parity
Control Packets on a Single Port", FEC", draft-ietf-fecframe-interleaved-fec-scheme-09 (work
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), in progress), January 2010.
August 2007.
[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.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [I-D.ietf-dccp-rtp]
"Session Traversal Utilities for NAT (STUN)", RFC 5389, Perkins, C., "RTP and the Datagram Congestion Control
October 2008. Protocol (DCCP)", draft-ietf-dccp-rtp-07 (work in
progress), June 2007.
[I-D.begen-avt-ports-for-ucast-mcast-rtp]
Begen, A. and B. Steeg, "Port Mapping Between Unicast and
Multicast RTP Sessions",
draft-begen-avt-ports-for-ucast-mcast-rtp-01 (work in
progress), October 2009.
[UPnP-IGD] [UPnP-IGD]
Forum, UPnP., "Universal Plug and Play (UPnP) Internet Forum, UPnP., "Universal Plug and Play (UPnP) Internet
Gateway Device (IGD)", November 2001. Gateway Device (IGD)", November 2001.
[DLNA] , DLNA., "http://www.dlna.org/home". [DLNA] , DLNA., "http://www.dlna.org/home".
[CCNC09] Begen, A., Glazebrook, N., and W. VerSteeg, "A Unified
Approach for Repairing Packet Loss and Accelerating
Channel Changes in Multicast IPTV (IEEE CCNC)",
January 2009.
[IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing [IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing
Channel Change Times in IPTV with Real-Time Transport Channel Change Times in IPTV with Real-Time Transport
Protocol (IEEE Internet Computing)", May 2009. Protocol (IEEE Internet Computing)", May 2009.
Authors' Addresses Authors' Addresses
Bill VerSteeg Bill VerSteeg
Cisco Cisco
5030 Sugarloaf Parkway 5030 Sugarloaf Parkway
Lawrenceville, GA 30044 Lawrenceville, GA 30044
 End of changes. 223 change blocks. 
847 lines changed or deleted 1110 lines changed or added

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