draft-ietf-avt-rapid-acquisition-for-rtp-09.txt   draft-ietf-avt-rapid-acquisition-for-rtp-10.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: October 28, 2010 T. VanCaenegem Expires: November 30, 2010 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Z. Vax Z. Vax
Microsoft Corporation Microsoft Corporation
April 26, 2010 May 29, 2010
Unicast-Based Rapid Acquisition of Multicast RTP Sessions Unicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-ietf-avt-rapid-acquisition-for-rtp-09 draft-ietf-avt-rapid-acquisition-for-rtp-10
Abstract Abstract
When an RTP receiver joins a multicast session, it may need to When an RTP receiver joins a multicast session, it may need to
acquire and parse certain Reference Information before it can process acquire and parse certain Reference Information before it can process
any data sent in the multicast session. Depending on the join time, any data sent in the multicast session. Depending on the join time,
length of the Reference Information repetition (or appearance) length of the Reference Information repetition (or appearance)
interval, size of the Reference Information as well as the interval, size of the Reference Information as well as the
application and transport properties, the time lag before an RTP application and transport properties, the time lag before an RTP
receiver can usefully consume the multicast data, which we refer to receiver can usefully consume the multicast data, which we refer to
as the Acquisition Delay, varies and may be large. This is an as the Acquisition Delay, varies and can be large. This is an
undesirable phenomenon for receivers that frequently switch among undesirable phenomenon for receivers that frequently switch among
different 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 multicast Information to the receiver precedes/accompanies the multicast
stream. This unicast RTP flow may be transmitted at a faster than stream. This unicast RTP flow can be transmitted at a faster than
natural bitrate to further accelerate the acquisition. The natural bitrate to further accelerate the acquisition. The
motivating use case for this capability is multicast applications motivating use case for this capability is multicast applications
that carry real-time compressed audio and video. However, the that carry real-time compressed audio and video. However, the
proposed method can also be used in other types of multicast proposed method can also be used in other types of multicast
applications where the acquisition delay is long enough to be a applications where the acquisition delay is long enough to be a
problem. problem.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 28, 2010. This Internet-Draft will expire on November 30, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Acquisition of RTP Streams vs. RTP Sessions . . . . . . . 7 1.1. Acquisition of RTP Streams vs. RTP Sessions . . . . . . . 6
1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 8 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Elements of Delay in Multicast Applications . . . . . . . . . 10 4. Elements of Delay in Multicast Applications . . . . . . . . . 9
5. Protocol Design Considerations and Their Effect on 5. Protocol Design Considerations and Their Effect on
Resource Management for Rapid Acquisition . . . . . . . . . . 11 Resource Management for Rapid Acquisition . . . . . . . . . . 10
6. Rapid Acquisition of Multicast RTP Sessions . . . . . . . . . 13 6. Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . 12
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Synchronization of Primary Multicast Streams . . . . . . 24 6.3. Synchronization of Primary Multicast Streams . . . . . . . 23
6.4. Burst Shaping and Congestion Control in RAMS . . . . . . 24 6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 23
6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27 6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 26
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 28 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 27
7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . 29 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 30 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 29
7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 30 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 29
7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . 30 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 30
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . 33 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 32
7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . 35 7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 35
8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 36 8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 36
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 36 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 36
8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 37 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 36
8.3. Example and Discussion . . . . . . . . . . . . . . . . . 38 8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 37
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 40 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 40
10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
11.1. Registration of SDP Attributes . . . . . . . . . . . . . 43 11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 43
11.2. Registration of SDP Attribute Values . . . . . . . . . . 44 11.2. Registration of SDP Attribute Values . . . . . . . . . . . 43
11.3. Registration of FMT Values . . . . . . . . . . . . . . . 44 11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 44
11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . 44 11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 44
11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 45 11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 45
11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 46 11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 46
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48
14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 48 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
14.1. draft-ietf-avt-rapid-acquisition-for-rtp-09 . . . . . . . 48 14.1. Normative References . . . . . . . . . . . . . . . . . . . 48
14.2. draft-ietf-avt-rapid-acquisition-for-rtp-08 . . . . . . . 48 14.2. Informative References . . . . . . . . . . . . . . . . . . 50
14.3. draft-ietf-avt-rapid-acquisition-for-rtp-07 . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
14.4. draft-ietf-avt-rapid-acquisition-for-rtp-06 . . . . . . . 49
14.5. draft-ietf-avt-rapid-acquisition-for-rtp-05 . . . . . . . 49
14.6. draft-ietf-avt-rapid-acquisition-for-rtp-04 . . . . . . . 49
14.7. draft-ietf-avt-rapid-acquisition-for-rtp-03 . . . . . . . 49
14.8. draft-ietf-avt-rapid-acquisition-for-rtp-02 . . . . . . . 49
14.9. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 50
14.10. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 50
14.11. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 50
14.12. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 50
14.13. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 51
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
15.1. Normative References . . . . . . . . . . . . . . . . . . 51
15.2. Informative References . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
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 (although its content may change over time) and usually session (although its content can change over time) and usually
consists of items such as a description of the schema for the rest of consists of items such as a description of the schema for the rest of
the data, references to which data to process, encryption information the data, references to which data to process, encryption information
including keys, as well as any other information required to process including keys, as well as any other information required to process
the data in the multicast stream [IC2009]. 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 might join the session right before the Reference
is sent in the session. In this case, the required waiting time is Information is sent in the session. In this case, the required
usually minimal. Other times, the receiver may join the session waiting time is usually minimal. Other times, the receiver might
right after the Reference Information has been transmitted. In this join the session right after the Reference Information has been
case, the receiver has to wait for the Reference Information to transmitted. In this case, the receiver has to wait for the
appear again in the flow before it can start processing any multicast Reference Information to appear again in the flow before it can start
data. In some other cases, the Reference Information is not processing any multicast data. In some other cases, the Reference
contiguous in the flow but dispersed over a large period, which Information is not contiguous in the flow but dispersed over a large
forces the receiver to wait for all of the Reference Information to period, which forces the receiver to wait for all of the Reference
arrive before starting to process the rest of the data. Information to 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 can experience
significantly large delays in data processing. In this document, we significantly large delays in data processing. In this document, we
refer to the difference between the time an RTP receiver 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 might not be the same for different receivers; it
usually varies depending on the join time, length of the Reference usually varies depending on the join time, length of the Reference
Information repetition (or appearance) interval, size of the Information repetition (or appearance) interval, size of the
Reference Information as well as the application and transport Reference Information as well as the application and transport
properties. properties.
The varying nature of the acquisition delay adversely affects the The varying nature of the acquisition delay adversely affects the
receivers that frequently switch among multicast sessions. In this receivers that frequently switch among multicast sessions. 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
skipping to change at page 6, line 18 skipping to change at page 5, line 19
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
[RFC5760]) for the session. When an RTP receiver wishes to join the [RFC5760]) for the session. When an RTP receiver wishes to join the
same multicast session, instead of simply issuing a Source Filtering same multicast session, instead of simply issuing a Source Filtering
Group Management Protocol (SFGMP) Join message, it sends a request to Group Management Protocol (SFGMP) Join message, it sends a request to
the feedback target for the session and asks for the Reference the feedback target for the session and asks for the Reference
Information. The retransmission server starts a new unicast RTP Information. The retransmission server starts a new unicast RTP
(retransmission) session and sends the Reference Information to the (retransmission) session and sends the Reference Information to the
RTP receiver over that session. If there is spare bandwidth, the RTP receiver over that session. If there is spare bandwidth, the
retransmission server may burst the Reference Information faster than retransmission server might burst the Reference Information faster
its natural rate. As soon as the receiver acquires the Reference than its natural rate. As soon as the receiver acquires the
Information, it can join the multicast session and start processing Reference Information, it can join the multicast session and start
the multicast data. A simplified network diagram showing this method processing the multicast data. A simplified network diagram showing
through an intermediary network element is depicted in Figure 1. this method through an intermediary network element is depicted in
Figure 1.
This method potentially reduces the acquisition delay. We refer to This method potentially reduces the acquisition delay. We refer to
this method as Unicast-based Rapid Acquisition of Multicast RTP this method as Unicast-based Rapid Acquisition of Multicast RTP
Sessions. A primary use case for this method is to reduce the Sessions. A primary use case for this method is to reduce the
channel-change times in IPTV networks where compressed video streams channel-change times in IPTV networks where compressed video streams
are multicast in different SSM sessions and viewers randomly join are multicast in different SSM sessions and viewers randomly join
these sessions. these sessions.
----------------------- -----------------------
+--->| Intermediary | +--->| Intermediary |
skipping to change at page 7, line 46 skipping to change at page 6, line 46
1.1. Acquisition of RTP Streams vs. RTP Sessions 1.1. Acquisition of RTP Streams vs. RTP Sessions
In this memo we describe a protocol that handles the rapid In this memo we describe a protocol that handles the rapid
acquisition of a single multicast RTP session (called primary acquisition of a single multicast RTP session (called primary
multicast RTP session) carrying one or more RTP streams (called multicast RTP session) carrying one or more RTP streams (called
primary multicast streams). If desired, multiple instances of this primary multicast streams). If desired, multiple instances of this
protocol may be run in parallel to acquire multiple RTP sessions protocol may be run in parallel to acquire multiple RTP sessions
simultaneously. simultaneously.
When an RTP receiver requests the Reference Information from the When an RTP receiver requests the Reference Information from the
retransmission server, it may opt to rapidly acquire a specific retransmission server, it can opt to rapidly acquire a specific
subset of the available RTP streams in the primary multicast RTP subset of the available RTP streams in the primary multicast RTP
session. Alternatively, it may request the rapid acquisition of all session. Alternatively, it can request the rapid acquisition of all
of the RTP streams in that RTP session. Regardless of how many RTP 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 streams are requested by the RTP receiver or how many will be
actually sent by the retransmission server, only one unicast RTP actually sent by the retransmission server, only one unicast RTP
session will be established by the retransmission server. This session will be established by the retransmission server. This
unicast RTP session is separate from the associated primary multicast unicast RTP session is separate from the associated primary multicast
RTP session. As a result, there are always two different RTP RTP session. As a result, there are always two different RTP
sessions in a single instance of the rapid acquisition protocol: (i) sessions in a single instance of the rapid acquisition protocol: (i)
the primary multicast RTP session with its associated unicast the primary multicast RTP session with its associated unicast
feedback and (ii) the unicast RTP session. feedback and (ii) the unicast RTP session.
skipping to change at page 8, line 41 skipping to change at page 7, line 41
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Definitions 3. Definitions
This document uses the following acronyms and definitions frequently: This document uses the following acronyms and definitions frequently:
(Primary) SSM (or Multicast) Session: The multicast session to which (Primary) SSM (or Multicast) Session: The multicast session to which
RTP receivers can join at a random point in time. A primary SSM RTP receivers can join at a random point in time. A primary SSM
session may carry multiple RTP streams. session can carry multiple RTP streams.
Primary Multicast RTP Session: The multicast RTP session an RTP Primary Multicast RTP Session: The multicast RTP session an RTP
receiver is interested in acquiring rapidly. From the RTP receiver's receiver is interested in acquiring rapidly. From the RTP receiver's
viewpoint, the primary multicast RTP session has one associated viewpoint, the primary multicast RTP session has one associated
unicast RTCP feedback stream to a Feedback Target, in addition to the unicast RTCP feedback stream to a Feedback Target, in addition to the
primary multicast RTP stream(s). primary multicast RTP stream(s).
Primary Multicast (RTP) Streams: The RTP stream(s) carried in the Primary Multicast (RTP) Streams: The RTP stream(s) carried in the
primary multicast RTP session. primary multicast RTP session.
skipping to change at page 9, line 42 skipping to change at page 8, line 42
of the Reference Information transmitted out-of-band. of the Reference Information transmitted out-of-band.
(Unicast) Burst (or Retransmission) RTP Session: The unicast RTP (Unicast) Burst (or Retransmission) RTP Session: The unicast RTP
session used to send one or more unicast burst RTP streams and their session used to send one or more unicast burst RTP streams and their
associated RTCP messages. The terms "burst RTP session" and associated RTCP messages. The terms "burst RTP session" and
"retransmission RTP session" can be used interchangeably. "retransmission RTP session" can be used interchangeably.
(Unicast) Burst (Stream): A unicast stream of RTP retransmission (Unicast) Burst (Stream): A unicast stream of RTP retransmission
packets that enable an RTP receiver to rapidly acquire the Reference packets that enable an RTP receiver to rapidly acquire the Reference
Information associated with a primary multicast stream. Each burst Information associated with a primary multicast stream. Each burst
stream is identified by its SSRC identifier that is unique in the stream is identified by its Synchronization Source (SSRC) identifier
primary multicast RTP session. Following the session-multiplexing that is unique in the primary multicast RTP session. Following the
guidelines in [RFC4588], each unicast burst stream must use the same session-multiplexing guidelines in [RFC4588], each unicast burst
SSRC and CNAME as its primary multicast RTP stream. stream must use the same SSRC and CNAME as its primary multicast RTP
stream.
Retransmission Server (RS): The RTP/RTCP endpoint that can generate Retransmission Server (RS): The RTP/RTCP endpoint that can generate
the retransmission packets and the burst streams. RS may also the retransmission packets and the burst streams. RS may also
generate other non-retransmission packets to aid rapid acquisition. generate other non-retransmission packets to aid rapid acquisition.
4. Elements of Delay in Multicast Applications 4. Elements of Delay in Multicast Applications
In a source-specific (SSM) multicast delivery system, there are three In a source-specific (SSM) multicast delivery system, there are three
major elements that contribute to the overall acquisition delay when major elements that contribute to the overall acquisition delay when
an RTP receiver switches from one multicast session to another one. an RTP receiver switches from one multicast session to another one.
skipping to change at page 10, line 22 skipping to change at page 9, line 22
o Multicast switching delay o Multicast switching delay
o Reference Information latency o Reference Information latency
o Buffering delays o Buffering delays
Multicast switching delay is the delay that is experienced to leave Multicast switching delay is the delay that is experienced to leave
the current multicast session (if any) and join the new multicast the current multicast session (if any) and join the new multicast
session. In typical systems, the multicast join and leave operations session. In typical systems, the multicast join and leave operations
are handled by a group management protocol. For example, the are handled by a group management protocol. For example, the
receivers and routers participating in a multicast session may use receivers and routers participating in a multicast session can use
the Internet Group Management Protocol (IGMP) version 3 [RFC3376] or the Internet Group Management Protocol (IGMP) version 3 [RFC3376] or
the Multicast Listener Discovery Protocol (MLD) version 2 [RFC3810]. the Multicast Listener Discovery Protocol (MLD) version 2 [RFC3810].
In either of these protocols, when a receiver wants to join a In either of these protocols, when a receiver wants to join a
multicast session, it sends a message to its upstream router and the multicast session, it sends a message to its upstream router and the
routing infrastructure sets up the multicast forwarding state to routing infrastructure sets up the multicast forwarding state to
deliver the packets of the multicast session to the new receiver. deliver the packets of the multicast session to the new receiver.
Depending on the proximity of the upstream router, the current state Depending on the proximity of the upstream router, the current state
of the multicast tree, the load on the system and the protocol of the multicast tree, the load on the system and the protocol
implementation, the join times vary. Current systems provide join implementation, the join times vary. Current systems provide join
latencies usually less than 200 milliseconds (ms). If the receiver latencies usually less than 200 milliseconds (ms). If the receiver
had been participating in another multicast session before joining had been participating in another multicast session before joining
the new session, it needs to send a Leave message to its upstream the new session, it needs to send a Leave message to its upstream
router to leave the session. In common multicast routing protocols, router to leave the session. In common multicast routing protocols,
the leave times are usually smaller than the join times, however, it the leave times are usually smaller than the join times, however, it
is possible that the Leave and Join messages may get lost, in which is possible that the Leave and Join messages might get lost, in which
case the multicast switching delay inevitably increases. case the multicast switching delay inevitably increases.
Reference Information latency is the time it takes the receiver to Reference Information latency is the time it takes the receiver to
acquire the Reference Information. It is highly dependent on the acquire the Reference Information. It is highly dependent on the
proximity of the actual time the receiver joined the session to the proximity of the actual time the receiver joined the session to the
next time the Reference Information will be sent to the receivers in next time the Reference Information will be sent to the receivers in
the session, whether the Reference Information is sent contiguously the session, whether the Reference Information is sent contiguously
or not, and the size of the Reference Information. For some or not, and the size of the Reference Information. For some
multicast flows, there is a little or no interdependency in the data, multicast flows, there is a little or no interdependency in the data,
in which case the Reference Information latency will be nil or in which case the Reference Information latency will be nil or
negligible. For other multicast flows, there is a high degree of negligible. For other multicast flows, there is a high degree of
interdependency. One example of interest is the multicast flows that interdependency. One example of interest is the multicast flows that
carry compressed audio/video. For these flows, the Reference carry compressed audio/video. For these flows, the Reference
Information latency may become quite large and be a major contributor Information latency can become quite large and be a major contributor
to the overall delay. to the overall delay.
The buffering component of the overall acquisition delay is driven by The buffering component of the overall acquisition delay is driven by
the way the application layer processes the payload. In many the way the application layer processes the payload. In many
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 (e.g., as Forward Error Correction (e.g.,
[I-D.ietf-fecframe-interleaved-fec-scheme]) and retransmission. [I-D.ietf-fecframe-interleaved-fec-scheme]) and retransmission.
These loss-repair methods require buffering at the receiver side to These loss-repair methods require buffering at the receiver side to
skipping to change at page 11, line 26 skipping to change at page 10, line 26
delays. Besides these network-related buffering delays, there are delays. Besides these network-related buffering delays, there are
also specific buffering needs that are required by the individual also specific buffering needs that are required by the individual
applications. For example, standard video decoders typically require applications. For example, standard video decoders typically require
an amount, sometimes a significant amount, of coded video data to be an amount, sometimes a significant amount, of coded video data to be
available in the pre-decoding buffers prior to starting to decode the available in the pre-decoding buffers prior to starting to decode the
video bitstream. video bitstream.
5. Protocol Design Considerations and Their Effect on Resource 5. Protocol Design Considerations and Their Effect on Resource
Management for Rapid Acquisition Management for Rapid Acquisition
Rapid acquisition is an optimization of a system that must continue This section is for informational purposes and does not contain
to work correctly and properly whether or not the optimization is requirements for implementations.
effective, or even fails due to lost control and feedback messages,
congestion, or other problems. This is fundamental to the overall Rapid acquisition is an optimization of a system that is expected to
design requirements surrounding the protocol definition and to the continue to work correctly and properly whether or not the
resource management schemes to be employed together with the protocol optimization is effective, or even fails due to lost control and
(e.g., QoS machinery, server load management, etc). In particular, feedback messages, congestion, or other problems. This is
the system needs to operate within a number of constraints: fundamental to the overall design requirements surrounding the
protocol definition and to the resource management schemes to be
employed together with the protocol (e.g., QoS machinery, server load
management, etc). In particular, the system needs to operate within
a number of constraints:
o First, a rapid acquisition operation must fail gracefully. The 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 interference with the multicast session that operation must avoid interference with the multicast session that
may be simultaneously being received by other hosts. In addition, might be simultaneously being received by other hosts. In
it must also avoid interference with other multicast sessions addition, it must also avoid interference with other multicast
sharing the same network resources. These properties are sessions sharing the same network resources. These properties are
possible, but are usually difficult to achieve. possible, but are usually difficult to achieve.
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 might 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
can be shared links carrying multicast sessions of many subscribers. can be shared links carrying multicast sessions of many subscribers.
Also note that the state of these links may be varying over time. Also note that the state of these links can vary over time. The
The receiver may have knowledge of a portion of this network, or may receiver might have knowledge of a portion of this network, or might
have partial knowledge of the entire network. The methods employed have partial knowledge of the entire network. The methods employed
by the devices to acquire this network state information is out of by the devices to acquire this network state information is out of
scope for this document. The receiver should be able to signal the scope for this document. The receiver should be able to signal the
server with the bandwidth that it believes it can handle. The server server with the bandwidth that it believes it can handle. The server
also needs to be able to rate limit the flow in order to stay within also needs to be able to rate limit the flow in order to stay within
the performance envelope that it knows about. Both the server and the performance envelope that it knows about. Both the server and
receiver need to be able to inform the other of changes in the receiver need to be able to inform the other of changes in the
requested and delivered rates. However, the protocol must be robust requested and delivered rates. However, the protocol must be robust
in the presence of packet loss, so this signaling must include the in the presence of packet loss, so this signaling must include the
appropriate default behaviors. appropriate default behaviors.
skipping to change at page 13, line 34 skipping to change at page 12, line 36
and explicitly terminate the unicast burst with a second control loop and explicitly terminate the unicast burst with a second control loop
exchange (which takes a minimum of one RTT, just as starting the exchange (which takes a minimum of one RTT, just as starting the
unicast burst does). Alternatively, the server generating the unicast burst does). Alternatively, the server generating the
unicast burst can pre-compute the burst parameters based on the unicast burst can pre-compute the burst parameters based on the
information in the initial request and tell the receiver the burst information in the initial request and tell the receiver the burst
duration. duration.
The protocol described in the next section allows either method of The protocol described in the next section allows either method of
controlling the rapid acquisition unicast burst. controlling the rapid acquisition unicast burst.
6. Rapid Acquisition of Multicast RTP Sessions 6. Rapid Acquisition of Multicast RTP Sessions (RAMS)
We start this section with an overview of the rapid acquisition of We start this section with an overview of the rapid acquisition of
multicast sessions (RAMS) method. multicast sessions (RAMS) method.
6.1. Overview 6.1. Overview
[RFC5760] specifies an extension to the RTP Control Protocol (RTCP) [RFC5760] specifies an extension to the RTP Control Protocol (RTCP)
to use unicast feedback in an SSM session. It defines an to use unicast feedback in an SSM session. It defines an
architecture that introduces the concept of Distribution Source, architecture that introduces the concept of Distribution Source,
which - in an SSM context - distributes the RTP data and which - in an SSM context - distributes the RTP data and
redistributes 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. One or more entities different
implemented in one or more entities different from the Distribution from the Distribution Source MAY implement the feedback target
Source, and different RTP receivers MAY use different feedback functionality, and different RTP receivers MAY use different feedback
targets. targets.
This document builds further on these concepts to reduce the This document builds further on these concepts to reduce the
acquisition delay when an RTP receiver joins a multicast session at a acquisition delay when an RTP receiver joins a multicast session at a
random point in time by introducing the concept of the Burst Source random point in time by introducing the concept of the Burst Source
and new RTCP feedback messages. The Burst Source has a cache where and new RTCP feedback messages. The Burst Source has a cache where
the most recent packets from the primary multicast RTP session are the most recent packets from the primary multicast RTP session are
continuously stored. When an RTP receiver wants to receive a primary continuously stored. When an RTP receiver wants to receive a primary
multicast stream, it may first request a unicast burst from the Burst multicast stream, it can first request a unicast burst from the Burst
Source before it joins the SSM session. In this burst, the packets Source before it joins the SSM session. In this burst, the packets
are formatted as RTP retransmission packets [RFC4588] and carry the are formatted as RTP retransmission packets [RFC4588] and carry
Reference Information. This information allows the RTP receiver to Reference Information. This information allows the RTP receiver to
start usefully consuming the RTP packets sent in the primary start usefully consuming the RTP packets sent in the primary
multicast RTP session. multicast RTP session.
Using an accelerated bitrate (as compared to the nominal bitrate of Using an accelerated bitrate (as compared to the nominal bitrate of
the primary multicast stream) for the unicast burst implies that at a the primary multicast stream) for the unicast burst implies that at a
certain point in time, the payload transmitted in the unicast burst certain point in time, the payload transmitted in the unicast burst
is going to be the same as the payload in the associated multicast is going to be the same as the payload in the associated multicast
stream, i.e., the unicast burst will catch up with the primary stream, i.e., the unicast burst will catch up with the primary
multicast stream. At this point, the RTP receiver no longer needs to multicast stream. At this point, the RTP receiver no longer needs to
skipping to change at page 15, line 14 skipping to change at page 14, line 14
----------- -------------- ----------- --------------
| |------------------------------------>| | | |------------------------------------>| |
| |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| | | |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->| |
| | | | | | | |
| Multicast | ---------------- | | | Multicast | ---------------- | |
| Source | | Retransmission | | | | Source | | Retransmission | | |
| |-------->| Server (RS) | | | | |-------->| Server (RS) | | |
| |.-.-.-.->| | | | | |.-.-.-.->| | | |
| | | ------------ | | | | | | ------------ | | |
----------- | | Feedback | |<.=.=.=.=.| | ----------- | | Feedback | |<.=.=.=.=.| |
| | Target | |<~~~~~~~~~| RTP Receiver | | | Target (FT)| |<~~~~~~~~~| RTP Receiver |
PRIMARY MULTICAST | ------------ | | (RTP_Rx) | PRIMARY MULTICAST | ------------ | | (RTP_Rx) |
RTP SESSION with | | | | RTP SESSION with | | | |
UNICAST FEEDBACK | | | | UNICAST FEEDBACK | | | |
| | | | | | | |
- - - - - - - - - - - |- - - - - - - - |- - - - - |- - - - - - - |- - - - - - - - - - - - - |- - - - - - - - |- - - - - |- - - - - - - |- -
| | | | | | | |
UNICAST BURST | ------------ | | | UNICAST BURST | ------------ | | |
(or RETRANSMISSION) | | Burst and | |<~~~~~~~~>| | (or RETRANSMISSION) | | Burst and | |<~~~~~~~~>| |
RTP SESSION | | Retrans. | |.........>| | RTP SESSION | | Retrans. | |.........>| |
| | Source | |<.=.=.=.=>| | | |Source (BRS)| |<.=.=.=.=>| |
| ------------ | | | | ------------ | | |
| | | | | | | |
---------------- -------------- ---------------- --------------
-------> Multicast RTP Flow -------> Multicast RTP Flow
.-.-.-.> Multicast RTCP Flow .-.-.-.> Multicast RTCP Flow
.=.=.=.> Unicast RTCP Reports .=.=.=.> Unicast RTCP Reports
~~~~~~~> Unicast RTCP Feedback Messages ~~~~~~~> Unicast RTCP Feedback Messages
.......> Unicast RTP Flow .......> Unicast RTP Flow
skipping to change at page 15, line 47 skipping to change at page 14, line 47
The feedback target (FT) is the entity as defined in [RFC5760], to The feedback target (FT) is the entity as defined in [RFC5760], to
which RTP_Rx sends its RTCP feedback messages indicating packet loss which RTP_Rx sends its RTCP feedback messages indicating packet loss
by means of an RTCP NACK message or indicating RTP_Rx's desire to by means of an RTCP NACK message or indicating RTP_Rx's desire to
rapidly acquire the primary multicast RTP session by means of an RTCP rapidly acquire the primary multicast RTP session by means of an RTCP
feedback message defined in this document. While the Burst/ feedback message defined in this document. While the Burst/
Retransmission Source (BRS) is responsible for responding to these Retransmission Source (BRS) is responsible for responding to these
messages and for further RTCP interaction with RTP_Rx in the case of messages and for further RTCP interaction with RTP_Rx in the case of
a rapid acquisition process, it is assumed in the remainder of the a rapid acquisition process, it is assumed in the remainder of the
document that these two logical entities (FT and BRS) are combined in document that these two logical entities (FT and BRS) are combined in
a single physical entity and they share state. In the remainder of a single physical entity and they share state. In the remainder of
the text, the term Retransmission Server (RS) may be used whenever the text, the term Retransmission Server (RS) is used whenever
appropriate, to refer to this single physical entity. appropriate, to refer to this single physical entity.
FT is involved in the primary multicast RTP session and receives FT is involved in the primary multicast RTP session and receives
unicast feedback for that session as in [RFC5760]. BRS is involved unicast feedback for that session as in [RFC5760]. BRS is involved
in the unicast burst (or retransmission) RTP session and transmits in the unicast burst (or retransmission) RTP session and transmits
the unicast burst and retransmission packets formatted as RTP the unicast burst and retransmission packets formatted as RTP
retransmission packets [RFC4588] in a single separate unicast RTP retransmission packets [RFC4588] in a single separate unicast RTP
session to each RTP_Rx. In the unicast burst RTP session, as in any session to each RTP_Rx. In the unicast burst RTP session, as in any
other RTP session, the BRS and RTP_Rx regularly send the periodic other RTP session, the BRS and RTP_Rx regularly send the periodic
sender and receiver reports, respectively. sender and receiver reports, respectively.
The unicast burst is started by an RTCP feedback message that is The unicast burst is started by an RTCP feedback message that is
defined in this document based on the common packet format provided defined in this document based on the common packet format provided
in [RFC4585]. An RTP retransmission is triggered by an RTCP NACK in [RFC4585]. An RTP retransmission is triggered by an RTCP NACK
message defined in [RFC4585]. Both of these messages are sent to FT message defined in [RFC4585]. Both of these messages are sent to FT
of the primary multicast RTP session, and may start the unicast of the primary multicast RTP session, and can start the unicast
burst/retransmission RTP session. burst/retransmission RTP session.
In the RTP/AVPF profile, there are certain rules that apply to In the RTP/AVPF profile, there are certain rules that apply to
scheduling of both of these messages sent to FT in the primary scheduling of both of these messages sent to FT in the primary
multicast RTP session, and these are detailed in Section 3.5 of multicast RTP session, and these are detailed in Section 3.5 of
[RFC4585]. One of the rules states that in a multi-party session [RFC4585]. One of the rules states that in a multi-party session
such as the SSM sessions we are considering in this specification, an such as the SSM sessions we are considering in this specification, an
RTP receiver cannot send an RTCP feedback message for a minimum of RTP_Rx cannot send an RTCP feedback message for a minimum of one
one second period after joining the session (i.e., Tmin=1.0 second). second period after joining the session (i.e., Tmin=1.0 second).
While this rule has the goal of avoiding problems associated with While this rule has the goal of avoiding problems associated with
flash crowds in typical multi-party sessions, it defeats the purpose flash crowds in typical multi-party sessions, it defeats the purpose
of rapid acquisition. Furthermore, when RTP receivers delay their of rapid acquisition. Furthermore, when RTP receivers delay their
messages requesting a burst by a deterministic or even a random messages requesting a burst by a deterministic or even a random
amount, it still does not make a difference since such messages are amount, it still does not make a difference since such messages are
not related and their timings are independent from each other. Thus, not related and their timings are independent from each other. Thus,
in this specification we initialize Tmin to zero and allow the RTP in this specification we initialize Tmin to zero and allow the RTP
receivers to send a burst request message right at the beginning. It receivers to send a burst request message right at the beginning. It
should, however, be emphasized that for the subsequent messages should, however, be emphasized that for the subsequent messages
during rapid acquisition, the timing rules of [RFC4585] still apply. during rapid acquisition, the timing rules of [RFC4585] still apply.
Figure 3 depicts an example of messaging flow for rapid acquisition. Figure 3 depicts an example of messaging flow for rapid acquisition.
The RTCP feedback messages are explained below. The optional The RTCP feedback messages are explained below. The optional
messages are indicated in parentheses and they may or may not be messages are indicated in parentheses and they might or might not be
present during rapid acquisition. Note that in a scenario where present during rapid acquisition. In a scenario where rapid
rapid acquisition is performed by a feedback target co-located with acquisition is performed by a feedback target co-located with the
the media sender, the same method (with the identical message flows) media sender, the same method (with the identical message flows)
still applies. still applies.
------------------------- -------------------------
| Retransmission Server | | Retransmission Server |
----------- | ------ ------------ | -------- ------------ ----------- | ------ ------------ | -------- ------------
| Multicast | | | FT | | Burst/Ret. | | | | | RTP | | Multicast | | | FT | | Burst/Ret. | | | | | RTP |
| Source | | | | | Source | | | Router | | Receiver | | Source | | | | | Source | | | Router | | Receiver |
| | | ------ ------------ | | | | (RTP_Rx) | | | | ------ ------------ | | | | (RTP_Rx) |
----------- | | | | -------- ------------ ----------- | | | | -------- ------------
| ------------------------- | | | ------------------------- | |
skipping to change at page 18, line 37 skipping to change at page 17, line 37
RAMS-R message so that BRS knows how to communicate with RTP_Rx. RAMS-R message so that BRS knows how to communicate with RTP_Rx.
The details of this setup procedure are explained in The details of this setup procedure are explained in
[I-D.ietf-avt-ports-for-ucast-mcast-rtp]. Other NAT-related [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. Other NAT-related
issues are left to Section 9 to keep the present discussion issues are left to Section 9 to keep the present discussion
focused on the RAMS message flows. focused on the RAMS message flows.
2. Request: RTP_Rx sends a rapid acquisition request (RAMS-R) for 2. Request: RTP_Rx sends a rapid acquisition request (RAMS-R) for
the primary multicast RTP session to the unicast feedback target the primary multicast RTP session to the unicast feedback target
of that session. The request contains the SSRC identifier of of that session. The request contains the SSRC identifier of
RTP_Rx (aka SSRC of packet sender) and may contain the media RTP_Rx (aka SSRC of packet sender) and can contain the media
sender SSRC identifier(s) of the primary multicast stream(s) of sender SSRC identifier(s) of the primary multicast stream(s) of
interest (aka SSRC of media source). The RAMS-R message may interest (aka SSRC of media source). The RAMS-R message can
contain parameters that constrain the burst, such as the buffer contain parameters that constrain the burst, such as the buffer
and bandwidth limits. and bandwidth limits.
Before joining the SSM session, RTP_Rx learns the addresses for Before joining the SSM session, RTP_Rx learns the addresses for
the multicast source, group and RS by out-of-band means. If the multicast source, group and RS by out-of-band means. If
RTP_Rx desires to rapidly acquire only a subset of the primary RTP_Rx desires to rapidly acquire only a subset of the primary
multicast streams available in the primary multicast RTP multicast streams available in the primary multicast RTP
session, the SSRC identifiers for the desired RTP streams MUST session, it MUST also acquire the SSRC identifiers for the
also be obtained out-of-band. Based on this information, RTP_Rx desired RTP streams out-of-band. Based on this information,
populates the desired SSRC(s) in the RAMS-R message. RTP_Rx populates the desired SSRC(s) in the RAMS-R message.
When FT successfully receives the RAMS-R message, BRS responds When FT successfully receives the RAMS-R message, BRS responds
to it by accepting or rejecting the request. Right before BRS to it by accepting or rejecting the request. Immediately before
sends any RTP or RTCP packet(s) described below, it establishes BRS sends any RTP or RTCP packet(s) described below, it
the unicast burst RTP session. establishes the unicast burst RTP session.
3. Response: BRS sends RAMS-Information (RAMS-I) message(s) to 3. Response: BRS sends RAMS-Information (RAMS-I) message(s) to
RTP_Rx to convey the status for the burst(s) requested by RTP_Rx to convey the status for the burst(s) requested by
RTP_Rx. RTP_Rx.
If the primary multicast RTP session associated with FT_Ap on If the primary multicast RTP session associated with FT_Ap on
which the RAMS-R message was received contains only a single which the RAMS-R message was received contains only a single
primary multicast stream, BRS SHALL always use the SSRC of the primary multicast stream, BRS SHALL always use the SSRC of the
RTP stream associated with FT_Ap in the RAMS-I message(s) RTP stream associated with FT_Ap in the RAMS-I message(s)
regardless of the media sender SSRC requested in the RAMS-R regardless of the media sender SSRC requested in the RAMS-R
message. In such cases the 'ssrc' attribute MAY be omitted from message. In such cases the 'ssrc' attribute MAY be omitted from
the media description. If the requested SSRC and the actual the media description. If the requested SSRC and the actual
media sender SSRC do not match, BRS SHOULD explicitly populate media sender SSRC do not match, BRS MUST explicitly populate the
the correct media sender SSRC in the initial RAMS-I message (See correct media sender SSRC in the initial RAMS-I message (See
Section 7.3). Section 7.3).
FT_Ap could also be associated with an RTP session that carries FT_Ap could also be associated with an RTP session that carries
two or more primary multicast streams. If RTP_Rx will issue a two or more primary multicast streams. If RTP_Rx will issue a
collective request to receive the whole primary multicast RTP collective request to receive the whole primary multicast RTP
session, it does not need the 'ssrc' attributes to be described session, it does not need the 'ssrc' attributes to be described
in the media description. Note that if FT_Ap is associated with in the media description.
two or more RTP sessions, RTP_Rx's request will be ambiguous.
Thus, each FT_Ap MUST be associated with a single RTP session. If FT_Ap is associated with two or more RTP sessions, RTP_Rx's
request will be ambiguous. To avoid any ambiguity, each FT_Ap
MUST be associated with a single RTP session.
If RTP_Rx is willing to rapidly acquire only a subset of the If RTP_Rx is willing to rapidly acquire only a subset of the
primary multicast streams, the RAMS-R message MUST explicitly primary multicast streams, the RAMS-R message MUST explicitly
list the media sender SSRCs. Upon receiving such a message, BRS list the media sender SSRCs denoting the stream(s) it wishes to
MAY accept the request for only the media sender SSRC(s) that acquire. Upon receiving such a message, BRS MAY accept the
matched the RTP stream(s) it serves. It MUST reject all other request for all or a subset of the media sender SSRC(s) that
matched the RTP stream(s) it serves. BRS MUST reject all other
requests with the appropriate response code. requests with the appropriate response code.
* Reject Responses: BRS MUST take into account any limitations * Reject Responses: BRS MUST take into account any limitations
that MAY have been specified by RTP_Rx in the RAMS-R message that may have been specified by RTP_Rx in the RAMS-R message
when making a decision regarding the request. If RTP_Rx has when making a decision regarding the request. If RTP_Rx has
requested to acquire the whole primary multicast RTP session requested to acquire the whole primary multicast RTP session
but BRS cannot provide a rapid acquisition service for any of but BRS cannot provide a rapid acquisition service for any of
the primary multicast streams, BRS MUST reject the request the primary multicast streams, BRS MUST reject the request
via a single RAMS-I message with a collective reject response via a single RAMS-I message with a collective reject response
code and whose media sender SSRC field is set to one of SSRCs code and whose media sender SSRC field is set to one of SSRCs
served by this FT_Ap. Upon receiving this RAMS-I message, served by this FT_Ap. Upon receiving this RAMS-I message,
RTP_Rx abandons the rapid acquisition attempt and may RTP_Rx abandons the rapid acquisition attempt and can
immediately join the multicast session by sending an SFGMP immediately join the multicast session by sending an SFGMP
Join message towards its upstream multicast router. Join message towards its upstream multicast router.
In all other cases, BRS MUST send a separate RAMS-I message In all other cases, BRS MUST send a separate RAMS-I message
with the appropriate response code for each primary multicast with the appropriate response code for each primary multicast
stream that has been requested by RTP_Rx but cannot be served stream that has been requested by RTP_Rx but cannot be served
by BRS. by BRS.
* Accept Responses: BRS MUST send a separate RAMS-I message * Accept Responses: BRS MUST send a separate RAMS-I message
with the appropriate response code for each primary multicast with the appropriate response code for each primary multicast
stream that has been requested by RTP_Rx and will be served stream that has been requested by RTP_Rx and will be served
by BRS. Such RAMS-I messages comprise fields that can be by BRS. Such RAMS-I messages comprise fields that can be
used to describe the individual unicast burst streams. used to describe the individual unicast burst streams.
A particularly important field carries the RTP sequence A particularly important field in the RAMS-I message carries
number of the first packet transmitted in the respective RTP the RTP sequence number of the first packet transmitted in
stream to allow RTP_Rx to detect any missing initial the respective RTP stream to allow RTP_Rx to detect any
packet(s). When BRS accepts the request, this field MUST be missing initial packet(s). When BRS accepts the request,
populated in the RAMS-I message and the initial RAMS-I this field MUST be populated in the RAMS-I message and the
message SHOULD precede the unicast burst or be sent at the initial RAMS-I message SHOULD precede the unicast burst or be
start of the burst so that RTP_Rx may quickly detect any sent at the start of the burst so that RTP_Rx can quickly
missing initial packet(s). detect any missing initial packet(s).
Where possible, it is RECOMMENDED to include all RAMS-I messages Where possible, it is RECOMMENDED to include all RAMS-I messages
in the same compound RTCP packet. However, it is possible that in the same compound RTCP packet. However, it is possible that
the RAMS-I message for a primary multicast stream may get the RAMS-I message for a primary multicast stream can get
delayed or lost, and RTP_Rx may start receiving RTP packets delayed or lost, and RTP_Rx can start receiving RTP packets
before receiving a RAMS-I message. Thus, RTP_Rx SHOULD NOT make before receiving a RAMS-I message. RTP_Rx MUST NOT make
protocol dependencies on quickly receiving the initial RAMS-I protocol dependencies on quickly receiving the initial RAMS-I
message. For redundancy purposes, it is RECOMMENDED that BRS message. For redundancy purposes, it is RECOMMENDED that BRS
repeats the RAMS-I messages multiple times as long as it follows repeats the RAMS-I messages multiple times as long as it follows
the RTCP timer rules defined in [RFC4585]. the RTCP timer rules defined in [RFC4585].
4. Unicast Burst: For the primary multicast stream(s) for which 4. Unicast Burst: For the primary multicast stream(s) for which
the request is accepted, BRS starts sending the unicast burst(s) the request is accepted, BRS starts sending the unicast burst(s)
that comprises one or more RTP retransmission packets sent in that comprises one or more RTP retransmission packets sent in
the unicast burst RTP session. In addition, BRS MAY send the unicast burst RTP session. In addition, BRS MAY send
preamble information data to RTP_Rx in addition to the requested preamble information data to RTP_Rx in addition to the requested
burst, to prime the media decoder(s). The format of this data burst, to prime the media decoder(s). The format of this
is RTP-payload specific and not specified here. preamble data is RTP-payload specific and not specified here.
5. Updated Request: RTP_Rx MAY send an updated RAMS-R message (as 5. Updated Request: RTP_Rx MAY send an updated RAMS-R message (as
unicast feedback in the primary multicast RTP session) with a unicast feedback in the primary multicast RTP session) with a
different value for one or more fields of an earlier RAMS-R different value for one or more fields of an earlier RAMS-R
message. If there is already a burst planned for or being message. If there is already a burst planned for or being
transmitted to a particular RTP_Rx for a particular stream, the transmitted to a particular RTP_Rx for a particular stream, the
newly arriving RAMS-R is an updated request; otherwise, it is a newly arriving RAMS-R is an updated request; otherwise, it is a
new request. BRS determines the identity of the requesting new request. BRS determines the identity of the requesting
RTP_Rx by looking at its canonical name identifier (CNAME item RTP_Rx by looking at its canonical name identifier (CNAME item
in the SDES source description). To choose a globally unique in the SDES source description). To choose a globally unique
CNAME identifier, RTP_Rx SHOULD follow the guidelines given in CNAME identifier, RTP_Rx SHOULD follow the guidelines given in
[RFC3550] Section 6.5.1 as updated by [I-D.begen-avt-rtp-cnames]. In addition to one or more fields
[I-D.begen-avt-rtp-cnames]. with updated values, an updated RAMS-R message may also include
the fields whose values did not change.
Upon receiving an updated request, BRS may use the updated Upon receiving an updated request, BRS can use the updated
values for sending/shaping the burst, or refine the values and values for sending/shaping the burst, or refine the values and
use the refined values for sending/shaping the burst. use the refined values for sending/shaping the burst.
Subsequently, BRS MAY send an updated RAMS-I message in the Subsequently, BRS MAY send an updated RAMS-I message in the
unicast burst RTP session to indicate the changes it made. unicast burst RTP session to indicate the changes it made.
However, the updated RAMS-I message may get lost. It is also However, the updated RAMS-I message can get lost. It is also
possible that the updated RAMS-R message could have been lost. possible that the updated RAMS-R message could have been lost.
Thus, RTP_Rx SHOULD NOT make protocol dependencies on quickly RTP_Rx MUST NOT make protocol dependencies on quickly (or ever)
(or ever) receiving an updated RAMS-I message, or assume that receiving an updated RAMS-I message, or assume that BRS will
BRS will honor the requested changes. honor the requested changes.
RTP_Rx may be in an environment where the available resources RTP_Rx may be in an environment where the available resources
are time-varying, which may or may not deserve sending a new are time-varying, which may or may not deserve sending a new
updated request. Determining the circumstances where RTP_Rx updated request. Determining the circumstances where RTP_Rx
should or should not send an updated request and the methods should or should not send an updated request and the methods
that RTP_Rx can use to detect and evaluate the time-varying that RTP_Rx can use to detect and evaluate the time-varying
available resources are not specified in this document. available resources are not specified in this document.
6. Updated Response: BRS may send more than one RAMS-I messages in 6. Updated Response: BRS can send more than one RAMS-I messages in
the unicast burst RTP session, e.g., to update the value of one the unicast burst RTP session, e.g., to update the value of one
or more fields in an earlier RAMS-I message. The updated RAMS-I or more fields in an earlier RAMS-I message. The updated RAMS-I
messages may or may not be a direct response to a RAMS-R messages might or might not be a direct response to a RAMS-R
message. BRS may also send updated RAMS-I messages to signal message. BRS can also send updated RAMS-I messages to signal
RTP_Rx in real time to join the SSM session. RTP_Rx depends on RTP_Rx in real time to join the SSM session. RTP_Rx depends on
BRS to learn the join time, which can be conveyed by the first BRS to learn the join time, which can be conveyed by the first
RAMS-I message, or can be sent/revised in a later RAMS-I RAMS-I message, or can be sent/revised in a later RAMS-I
message. If BRS is not capable of determining the join time in message. If BRS is not capable of determining the join time in
the initial RAMS-I message, it MUST send another RAMS-I message the initial RAMS-I message, BRS MUST send another RAMS-I message
(with the join time information) later. (with the join time information) later.
7. Multicast Join Signaling: The RAMS-I message allows BRS to 7. Multicast Join Signaling: The RAMS-I message allows BRS to
signal explicitly when RTP_Rx SHOULD send the SFGMP Join signal explicitly when RTP_Rx SHOULD send the SFGMP Join
message. If the request is accepted, this information MUST be message. If the request is accepted, this information MUST be
conveyed in at least one RAMS-I message and its value MAY 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 updated by subsequent RAMS-I messages. If RTP_Rx has received
multiple RAMS-I messages, it SHOULD use the information from the multiple RAMS-I messages, RTP_Rx SHOULD use the information from
most recent RAMS-I message. the most recent RAMS-I message.
There may be missing packets if RTP_Rx joins the multicast There can be missing packets if RTP_Rx joins the multicast
session too early or too late. For example, if RTP_Rx starts session too early or too late. For example, if RTP_Rx starts
receiving the primary multicast stream while it is still receiving the primary multicast stream while it is still
receiving the unicast burst at a high excess bitrate, this may receiving the unicast burst at a high excess bitrate, this can
result in an increased risk of packet loss. Or, if RTP_Rx joins result in an increased risk of packet loss. Or, if RTP_Rx joins
the multicast session some time after the unicast burst is the multicast session some time after the unicast burst is
finished, there may be a gap between the burst and multicast finished, there can be a gap between the burst and multicast
data (a number of RTP packets may be missing). In both cases, data (a number of RTP packets might be missing). In both cases,
RTP_Rx may issue retransmissions requests (via RTCP NACK RTP_Rx can issue retransmission requests (via RTCP NACK messages
messages sent as unicast feedback in the primary multicast RTP sent as unicast feedback in the primary multicast RTP session)
session) [RFC4585] to the FT entity of RS to fill the gap. BRS [RFC4585] to the FT entity of RS to fill the gap. BRS might or
may or may not respond to such requests. When it responds and might not respond to such requests. When it responds and the
the response causes significant changes in one or more values response causes significant changes in one or more values
reported earlier to RTP_Rx, an updated RAMS-I should be sent to reported earlier to RTP_Rx, an updated RAMS-I should be sent to
RTP_Rx. RTP_Rx.
8. Multicast Receive: After the join, RTP_Rx starts receiving the 8. Multicast Receive: After the join, RTP_Rx starts receiving the
primary multicast stream(s). primary multicast stream(s).
9. Terminate: BRS may know when it needs to ultimately stop the 9. Terminate: BRS can know when it needs to ultimately stop the
unicast burst based on its parameters. However, RTP_Rx may need unicast burst based on its parameters. However, RTP_Rx may need
to ask BRS to terminate the burst prematurely or at a specific to ask BRS to terminate the burst prematurely or at a specific
sequence number. For this purpose, it uses the RAMS-Termination sequence number. For this purpose, it uses the RAMS-Termination
(RAMS-T) message sent as RTCP feedback in the unicast burst RTP (RAMS-T) message sent as RTCP feedback in the unicast burst RTP
session. A separate RAMS-T message is sent for each primary session. A separate RAMS-T message is sent for each primary
multicast stream served by BRS unless an RTCP BYE message has multicast stream served by BRS unless an RTCP BYE message has
been sent in the unicast burst RTP session as described in Step been sent in the unicast burst RTP session as described in Step
10. For the burst requests that were rejected by BRS, there is 10. For the burst requests that were rejected by BRS, there is
no need to send a RAMS-T message. no need to send a RAMS-T message.
If RTP_Rx wants to terminate a burst prematurely, it SHALL send If RTP_Rx wants to terminate a burst prematurely, it SHALL send
a plain RAMS-T message for the SSRC of the primary multicast a plain RAMS-T message for the SSRC of the primary multicast
stream it wishes to terminate. This message is sent in the stream it wishes to terminate. This message is sent in the
unicast burst RTP session. Upon receiving this message BRS MUST unicast burst RTP session. Upon receiving this message BRS MUST
terminate the unicast burst. If RTP_Rx requested to acquire the terminate the unicast burst. If RTP_Rx requested to acquire the
entire primary multicast RTP session but wants to terminate this entire primary multicast RTP session but wants to terminate this
request before it learns the individual media sender SSRC(s) via request before it learns the individual media sender SSRC(s) via
RAMS-I message(s) or RTP packets, it cannot use RAMS-T RAMS-I message(s) or RTP packets, RTP_Rx cannot use RAMS-T
message(s) and thus MUST send an RTCP BYE message in the unicast message(s) and thus MUST send an RTCP BYE message in the unicast
burst RTP session to terminate the request. burst RTP session to terminate the request.
Otherwise, the default behavior for RTP_Rx is to send a RAMS-T Otherwise, the default behavior for RTP_Rx is to send a RAMS-T
message in the unicast burst RTP session immediately after it message in the unicast burst RTP session immediately after it
joins the multicast session and started receiving multicast joins the multicast session and started receiving multicast
packets. In that case, RTP_Rx SHALL send a RAMS-T message with packets. In that case, RTP_Rx SHALL send a RAMS-T message with
the sequence number of the first RTP packet received in the the sequence number of the first RTP packet received in the
primary multicast stream, and BRS SHOULD terminate the primary multicast stream. Then, BRS SHOULD terminate the
respective burst after it sends the unicast burst packet whose respective burst after it sends the unicast burst packet whose
Original Sequence Number (OSN) field in the RTP retransmission Original Sequence Number (OSN) field in the RTP retransmission
payload header matches this number minus one. payload header matches this number minus one.
RTP_Rx MUST send at least one RAMS-T message for each primary If an RTCP BYE message has not been issued yet as described in
multicast stream served by BRS (if an RTCP BYE message has not Step 10, RTP_Rx MUST send at least one RAMS-T message for each
been issued yet as described in Step 10). The RAMS-T message(s) primary multicast stream served by BRS. The RAMS-T message(s)
MUST be addressed to BRS and sent in the unicast burst RTP MUST be addressed to BRS and sent in the unicast burst RTP
session. Against the possibility of a message loss, it is session. Against the possibility of a message loss, it is
RECOMMENDED that RTP_Rx repeats the RAMS-T messages multiple RECOMMENDED that RTP_Rx repeats the RAMS-T messages multiple
times as long as it follows the RTCP timer rules defined in times as long as it follows the RTCP timer rules defined in
[RFC4585]. [RFC4585].
The binding between RAMS-T and ongoing bursts is achieved The binding between RAMS-T and ongoing bursts is achieved
through RTP_Rx's CNAME identifier, and packet sender and media through RTP_Rx's CNAME identifier, and packet sender and media
sender SSRCs. Choosing a globally unique CNAME makes sure that sender SSRCs. Choosing a globally unique CNAME makes sure that
the RAMS-T messages are processed correctly. the RAMS-T messages are processed correctly.
skipping to change at page 23, line 30 skipping to change at page 22, line 34
another RTCP BYE message for the primary multicast RTP session. another RTCP BYE message for the primary multicast RTP session.
These RTCP BYE messages are sent to BRS and FT logical entities, These RTCP BYE messages are sent to BRS and FT logical entities,
respectively. respectively.
Upon receiving an RTCP BYE message, BRS MUST terminate the rapid Upon receiving an RTCP BYE message, BRS MUST terminate the rapid
acquisition operation, and cease transmitting any further burst acquisition operation, and cease transmitting any further burst
packets and retransmission packets. If support for [RFC5506] packets and retransmission packets. If support for [RFC5506]
has been signaled, the RTCP BYE message MAY be sent in a has been signaled, the RTCP BYE message MAY be sent in a
reduced-size RTCP packet. Otherwise, Section 6.1 of [RFC3550] reduced-size RTCP packet. Otherwise, Section 6.1 of [RFC3550]
mandates the RTCP BYE message always to be sent with a sender or mandates the RTCP BYE message always to be sent with a sender or
receiver report in a compound RTCP packet (If no data has been receiver report in a compound RTCP packet. If no data has been
received, an empty receiver report MUST be still included). received, an empty receiver report MUST be still included. With
With the information contained in the receiver report, RS can the information contained in the receiver report, RS can figure
figure out how many duplicate RTP packets have been delivered to out how many duplicate RTP packets have been delivered to RTP_Rx
RTP_Rx (Note that this will be an upper-bound estimate as one or (Note that this will be an upper-bound estimate as one or more
more packets might have been lost during the burst packets might have been lost during the burst transmission).
transmission). The impact of duplicate packets and measures The impact of duplicate packets and measures that can be taken
that can be taken to minimize the impact of receiving duplicate to minimize the impact of receiving duplicate packets will be
packets will be addressed in Section 6.4. addressed in Section 6.4.
Note that an RTCP BYE message issued for the unicast burst RTP Since an RTCP BYE message issued for the unicast burst RTP
session terminates that session and ceases transmitting any session terminates that session and ceases transmitting any
further packets in that session. Thus, in this case there is no further packets in that session, there is no need for sending
need for sending explicit RAMS-T messages, which would only explicit RAMS-T messages, which would only terminate their
terminate their respective bursts. respective bursts.
For the purpose of gathering detailed information about RTP_Rx's For the purpose of gathering detailed information about RTP_Rx's
rapid acquisition experience, [I-D.ietf-avt-multicast-acq-rtcp-xr] rapid acquisition experience, [I-D.ietf-avt-multicast-acq-rtcp-xr]
defines an RTCP Extended Report (XR) Block. This report is designed defines an RTCP Extended Report (XR) Block. This report is designed
to be payload-independent, thus, it can be used by any multicast to be payload-independent, thus, it can be used by any multicast
application that supports rapid acquisition. Support for this XR application that supports rapid acquisition. Support for this XR
report is, however, OPTIONAL. report is, however, OPTIONAL.
6.3. Synchronization of Primary Multicast Streams 6.3. Synchronization of Primary Multicast Streams
When RTP_Rx acquires multiple primary multicast streams, it may need When RTP_Rx acquires multiple primary multicast streams, RTP_Rx can
to synchronize them for the playout. This synchronization is need to synchronize them for the playout. This synchronization is
traditionally achieved by the help of the RTCP sender reports traditionally achieved by the help of the RTCP sender reports
[RFC3550]. If the playout will start before RTP_Rx has joined the [RFC3550]. If the playout will start before RTP_Rx has joined the
multicast session, RTP_Rx must receive the information reflecting the multicast session, RTP_Rx needs to receive the information reflecting
synchronization among the primary multicast streams early enough so the synchronization among the primary multicast streams early enough
that it can play out the media in a synchronized fashion. so that it can play out the media in a synchronized fashion.
The suggested approach is to use the RTP header extension mechanism The suggested approach is to use the RTP header extension mechanism
[RFC5285] and convey the synchronization information in a header [RFC5285] and convey the synchronization information in a header
extension as defined in [I-D.ietf-avt-rapid-rtp-sync]. [RFC4588] extension as defined in [I-D.ietf-avt-rapid-rtp-sync]. [RFC4588]
says that retransmission packets SHOULD carry the same header says that retransmission packets should carry the same header
extension carried in the header of the original RTP packets. Thus, extension carried in the header of the original RTP packets. Thus,
as long as the multicast source emits a header extension with the as long as the multicast source emits a header extension with the
synchronization information frequently enough, there is no additional synchronization information frequently enough, there is no additional
task that needs to be carried out by BRS. The synchronization task that needs to be carried out by BRS. The synchronization
information will be sent to RTP_Rx along with the burst packets. The information will be sent to RTP_Rx along with the burst packets. The
frequent header extensions sent in the primary multicast RTP sessions frequent header extensions sent in the primary multicast RTP sessions
also allow rapid synchronization of the RTP streams for the RTP also allow rapid synchronization of the RTP streams for the RTP
receivers that do not support RAMS or that directly join the receivers that do not support RAMS or that directly join the
multicast session without running RAMS. Thus, in RAMS applications, multicast session without running RAMS. Thus, in RAMS applications,
it is RECOMMENDED that the multicast sources frequently send it is RECOMMENDED that the multicast sources frequently send
synchronization information by using header extensions following the synchronization information by using header extensions following the
rules presented in [I-D.ietf-avt-rapid-rtp-sync]. It should be noted rules presented in [I-D.ietf-avt-rapid-rtp-sync]. The regular sender
that the regular sender reports are still sent in the unicast session reports are still sent in the unicast session by following the rules
by following the rules of [RFC3550]. of [RFC3550].
6.4. Burst Shaping and Congestion Control in RAMS 6.4. Burst Shaping and Congestion Control in RAMS
This section provides informative guidelines about how BRS can shape This section provides informative guidelines about how BRS can shape
the transmission of the unicast burst and how congestion can be dealt the transmission of the unicast burst and how congestion can be dealt
within the RAMS process. Note that if RTP_Rx detects that the within the RAMS process. When RTP_Rx detects that the unicast burst
unicast burst is causing severe congestion, it can prefer to send a is causing severe congestion, it can prefer to send a RAMS-T message
RAMS-T message immediately to stop the unicast burst. immediately to stop the unicast burst.
A higher bitrate for the unicast burst naturally conveys the A higher bitrate for the unicast burst naturally conveys the
Reference Information and media content to RTP_Rx faster. This way, Reference Information and media content to 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. A higher bitrate also represents a better utilization acquisition. A higher bitrate also represents a better utilization
of BRS resources. As the burst may continue until it catches up with of BRS resources. As the burst may continue until it catches up with
the primary multicast stream, the higher the bursting bitrate, the the primary multicast stream, the higher the bursting bitrate, the
less data BRS needs to transmit. However, a higher bitrate for the less data BRS needs to transmit. However, a higher bitrate for the
burst also increases the chances for congestion-caused packet loss. burst also increases the chances for congestion-caused packet loss.
Thus, as discussed in Section 5, there must be an upper bound on the Thus, as discussed in Section 5, there has to be an upper bound on
bandwidth used by the burst. the bandwidth used by the burst.
When BRS transmits the unicast burst, it should take into account all When BRS transmits the unicast 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 might take
during the bursting as a result of buffer overflow on the path place during the bursting as a result of buffer overflow on the path
between RS and RTP_Rx and at RTP_Rx itself. The bursting bitrate may between RS and RTP_Rx and at RTP_Rx itself. The bursting bitrate can
be determined by taking into account the following information, when be determined by taking into account the following information, when
available: 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 bitrate in the retransmission session, allowing in-session bitrate
adaptations for the burst. When these receiver reports indicate adaptations for the burst. When these receiver reports indicate
packet loss, this may indicate a certain congestion state in the packet loss, this can indicate a certain congestion state in the
path from RS to RTP_Rx. path from RS to RTP_Rx.
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 RTP session, allowing in-session bitrate primary multicast RTP session, allowing in-session bitrate
adaptations for the burst. Such RTCP NACKs are transmitted by adaptations for the burst. Such RTCP NACKs are transmitted by
RTP_Rx in response to packet loss detection in the burst. NACKs RTP_Rx in response to packet loss detection in the burst. NACKs
may indicate a certain congestion state on the path from RS to can indicate a certain congestion state on the path from RS to
RTP_Rx. RTP_Rx.
d. There may be other feedback received from RTP_Rx, e.g., in the d. There can be other feedback received from RTP_Rx, e.g., in the
form of ECN-CE markings [I-D.ietf-avt-ecn-for-rtp] that may form of ECN-CE markings [I-D.ietf-avt-ecn-for-rtp] that can
influence in-session bitrate adaptation. influence in-session bitrate adaptation.
e. Information obtained via updated RAMS-R messages, allowing in- e. Information obtained via updated RAMS-R messages, allowing in-
session bitrate adaptations, if supported by BRS. session bitrate adaptations, if supported by BRS.
f. Transport protocol-specific information. For example, when DCCP f. Transport protocol-specific information. For example, when DCCP
is used to transport the RTP burst, the ACKs from the DCCP client is used to transport the RTP burst, the ACKs from the DCCP client
can be leveraged by the BRS / DCCP server for burst shaping and can be leveraged by the BRS / DCCP server for burst shaping and
congestion control. congestion control.
g. Pre-configured settings for each RTP_Rx or a set of RTP_Rxs that g. Pre-configured settings for each RTP_Rx or a set of RTP_Rxs that
indicate the upper-bound bursting bitrates for which no packet indicate the upper-bound bursting bitrates for which no packet
loss will occur as a result of congestion along the path of RS to loss will occur as a result of congestion along the path of 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 and where bottleneck bandwidth along the end-to-end path is known and where
the network between RS and this link is provisioned and the network between RS and this link is provisioned and
dimensioned to carry the burst streams, the bursting bitrate does dimensioned to carry the burst streams, the bursting bitrate does
not exceed the provisioned value. These settings may also be not exceed the provisioned value. These settings can also be
dynamically adapted using application-aware knowledge. dynamically adapted using application-aware knowledge.
BRS chooses the initial burst bitrate as follows: BRS chooses the initial burst bitrate as follows:
o When using RAMS in environments as described in (g), BRS MUST o When using RAMS in environments as described in (g), BRS MUST
transmit the burst packets at an initial bitrate higher than the transmit the burst packets at an initial bitrate higher than the
nominal bitrate, but within the engineered or reserved bandwidth nominal bitrate, but within the engineered or reserved bandwidth
limit. limit.
o When BRS cannot determine a reliable bitrate value for the unicast o When BRS cannot determine a reliable bitrate value for the unicast
burst (through a or g), BRS should choose an appropriate initial burst (through a or g), BRS should choose an appropriate initial
bitrate not above the nominal bitrate and increase it gradually bitrate not above the nominal bitrate and increase it gradually
unless a congestion is detected. unless a congestion is detected.
In both cases, during the burst transmission BRS MUST continuously In both cases, during the burst transmission BRS MUST continuously
monitor for packet losses as a result of congestion by means of one monitor for packet losses as a result of congestion by means of one
or more of the mechanisms described in (b,c,d,e,f). When BRS relies or more of the mechanisms described in (b,c,d,e,f). When BRS relies
on RTCP receiver reports, sufficient bandwidth must be provided to on RTCP receiver reports, sufficient bandwidth needs to be provided
RTP Rx for RTCP transmission in the unicast burst RTP session. To to RTP Rx for RTCP transmission in the unicast burst RTP session. To
achieve a reasonable fast adaptation against congestion, it is achieve a reasonable fast adaptation against congestion, it is
recommended that RTP_Rx sends a receiver report at least once every recommended that RTP_Rx sends a receiver report at least once every
two RTTs between RS and RTP_Rx. Although the specific heuristics and two RTTs between RS and RTP_Rx. Although the specific heuristics and
algorithms that deduce a congestion state and how subsequently BRS algorithms that deduce a congestion state and how subsequently BRS
should act are outside the scope of this specification, the following should act are outside the scope of this specification, the following
two practices are recommended: two practices are recommended:
o Upon detection of a significant packet loss, which BRS attributes o Upon detection of a significant amount of packet loss, which BRS
to congestion, BRS should decrease the burst bitrate. The rate by attributes to congestion, BRS should decrease the burst bitrate.
which BRS increases and decreases the bitrate for the burst may be The rate by which BRS increases and decreases the bitrate for the
determined by a TCP-friendly bitrate adaptation algorithm for RTP burst can be determined by a TCP-friendly bitrate adaptation
over UDP , or in the case of (f) by the congestion control algorithm for RTP over UDP , or in the case of (f) by the
algorithms defined in DCCP [I-D.ietf-dccp-rtp]. congestion control algorithms defined in DCCP [RFC5762].
o If the congestion is persistent and BRS has to reduce the burst o If the congestion is persistent and BRS has to reduce the burst
bitrate to a point where the RTP Rx buffer may underrun or the bitrate to a point where the RTP Rx buffer might underrun or the
burst will consume too many resources, BRS should terminate the burst will consume too many resources, BRS should terminate the
burst and transmit a RAMS-I message to RTP Rx with the appropriate burst and transmit a RAMS-I message to RTP Rx with the appropriate
response code. It is then up to RTP Rx to decide when to join the response code. It is then up to RTP Rx to decide when to join the
multicast session. multicast session.
In case there is no congestion experienced during the burst, a Even though there is no congestion experienced during the burst,
specific situation occurs near the end of the unicast burst, when BRS congestion may anyway arise near the end of the burst as RTP_Rx
has almost no more additional data to sustain the relatively higher eventually needs to join the multicast session. During this brief
burst bitrate, thus, the upper-bound burst bitrate automatically gets period both the burst packets and the multicast packets can be
limited by the nominal bitrate of the primary multicast stream. simultaneously received by RTP_Rx, thus enhancing the risk of
During this time frame, RTP_Rx eventually needs to join the multicast congestion.
session. This means that both the burst packets and the multicast
packets may be simultaneously received by RTP_Rx for a period of
time, enhancing the risk of congestion again.
Since BRS signals RTP_Rx when it should send the SFGMP Join message, Since BRS signals RTP_Rx when BRS expects RTP_Rx to send the SFGMP
BRS may have a rough estimate of when RTP_Rx will start receiving Join message, BRS can have a rough estimate of when RTP_Rx will start
multicast packets in the SSM session. BRS may keep on sending burst receiving multicast packets in the SSM session. BRS can keep on
packets but should reduce the bitrate accordingly at the appropriate sending burst packets but should reduce the bitrate accordingly at
instant by taking the bitrate of the whole SSM session into account. the appropriate instant by taking the bitrate of the whole SSM
If BRS ceases transmitting the burst packets before the burst catches session into account. If BRS ceases transmitting the burst packets
up, any gap resulting from this imperfect switch-over by RTP_Rx can before the burst catches up, any gap resulting from this imperfect
be later repaired by requesting retransmissions for the missing switch-over by RTP_Rx can be later repaired by requesting
packets from RS. The retransmissions may be shaped by BRS to make retransmissions for the missing packets from RS. The retransmissions
sure that they do not cause collateral loss in the primary multicast can be shaped by BRS to make sure that they do not cause collateral
RTP session and the unicast burst RTP session. loss in the primary multicast RTP session and the unicast burst RTP
session.
6.5. Failure Cases 6.5. Failure Cases
In the following, we examine the implications of losing the RAMS-R, In the following, we examine the implications of losing the RAMS-R,
RAMS-I or RAMS-T messages and other failure cases. RAMS-I or RAMS-T messages and other failure cases.
When RTP_Rx sends a RAMS-R message to initiate a rapid acquisition When RTP_Rx sends a RAMS-R message to initiate a rapid acquisition
but the message gets lost and FT does not receive it, RTP_Rx will get but the message gets lost and FT does not receive it, RTP_Rx will get
neither a RAMS-I message, nor a unicast burst. In this case, RTP_Rx neither a RAMS-I message, nor a unicast burst. In this case, RTP_Rx
MAY resend the request when it is eligible to do so based on the RTCP MAY resend the request when it is eligible to do so based on the RTCP
timer rules defined in [RFC4585]. Or, after a reasonable amount of timer rules defined in [RFC4585]. Or, after a reasonable amount of
time, RTP_Rx may time out (based on the previous observed response time, RTP_Rx can time out (based on the previous observed response
times) and immediately join the SSM session. 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 or decide not to time, RTP_Rx can either discard the burst data or decide not to
interrupt the unicast burst, and be prepared to join the SSM session interrupt the unicast burst, and be prepared to join the SSM session
at an appropriate time it determines or as indicated in a subsequent at an appropriate time it determines or as indicated in a subsequent
RAMS-I message (if available). To minimize the chances of losing the RAMS-I message (if available). To minimize the chances of losing the
RAMS-I messages, it is RECOMMENDED that BRS repeats the RAMS-I RAMS-I messages, it is RECOMMENDED that BRS repeats the RAMS-I
messages multiple times based on the RTCP timer rules defined in messages multiple times based on the RTCP timer rules defined in
[RFC4585]. [RFC4585].
In the failure cases where the RAMS-R message is lost and RTP_Rx In the failure cases where the RAMS-R message is lost and RTP_Rx
gives up, or the RAMS-I message is lost, RTP_Rx MUST still terminate gives up, or the RAMS-I message is lost, RTP_Rx MUST still terminate
the burst(s) it requested by following the rules described in the burst(s) it requested by following the rules described in
Section 6.2. Section 6.2.
In the case a RAMS-T message sent by RTP_Rx does not reach its In the case a RAMS-T message sent by RTP_Rx does not reach its
destination, BRS may continue sending burst packets even though destination, BRS can continue sending burst packets even though
RTP_Rx no longer needs them. In such cases, it is RECOMMENDED that RTP_Rx no longer needs them. In such cases, it is RECOMMENDED that
RTP_Rx repeats the RAMS-T message multiple times based on the RTCP RTP_Rx repeats the RAMS-T message multiple times based on the RTCP
timer rules defined in [RFC4585]. In the worst case, BRS MUST be timer rules defined in [RFC4585]. BRS MUST be provisioned to
provisioned to deterministically terminate the burst when it can no deterministically terminate the burst when it can no longer send the
longer send the burst packets faster than it receives the primary burst packets faster than it receives the primary multicast stream
multicast stream packets. packets.
Section 6.3.5 of [RFC3550] explains the rules pertaining to timing Section 6.3.5 of [RFC3550] explains the rules pertaining to timing
out an SSRC. When BRS accepts to serve the requested burst(s) and out an SSRC. When BRS accepts to serve the requested burst(s) and
establishes the retransmission session, it should check the liveness establishes the retransmission session, it should check the liveness
of RTP_Rx via the RTCP messages and reports RTP_Rx sends. The of RTP_Rx via the RTCP messages and reports RTP_Rx sends. The
default rules explained in [RFC3550] apply in RAMS as well. default rules explained in [RFC3550] apply in RAMS as well.
7. Encoding of the Signaling Protocol in RTCP 7. Encoding of the Signaling Protocol in RTCP
This section defines the formats of the RTCP transport-layer feedback This section defines the formats of the RTCP transport-layer feedback
skipping to change at page 29, line 4 skipping to change at page 28, line 7
feedback message type (FMT), payload type (PT), length, SSRC of feedback message type (FMT), payload type (PT), length, SSRC of
packet sender, SSRC of media sender as well as a variable-length packet sender, SSRC of media sender as well as a variable-length
field for feedback control information (FCI). 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). Any Reserved a sub-field called Sub Feedback Message Type (SFMT). Any Reserved
field SHALL be set to zero and ignored. field SHALL be set to zero and ignored.
Depending on the specific scenario and timeliness/importance of a Depending on the specific scenario and timeliness/importance of a
RAMS message, it may be desirable to send it in a reduced-size RTCP RAMS message, it can be desirable to send it in a reduced-size RTCP
packet [RFC5506]. However, unless support for [RFC5506] has been packet [RFC5506]. However, unless support for [RFC5506] has been
signaled, compound RTCP packets MUST be used by following [RFC3550] signaled, compound RTCP packets MUST be used by following [RFC3550]
rules. rules.
Following the rules specified in [RFC3550], all integer fields in the Following the rules specified in [RFC3550], all integer fields in the
messages defined below are carried in network-byte order, that is, messages defined below are carried in network-byte order, that is,
most significant byte (octet) first, also known as big-endian. most significant byte (octet) first, also known as big-endian.
Unless otherwise noted, numeric constants are in decimal (base 10). Unless otherwise stated, numeric constants are in decimal (base 10).
7.1. Extensions 7.1. Extensions
To improve the functionality of the RAMS method in certain To improve the functionality of the RAMS method in certain
applications, it may be desirable to define new fields in the RAMS applications, it can be desirable to define new fields in the RAMS
Request, Information and Termination messages. Such fields MUST be Request, Information and Termination messages. Such fields MUST be
encoded as TLV elements as described below and sketched in Figure 5: encoded as Type-Length-Value (TLV) elements as described below and
sketched in Figure 5:
o Type: A single-octet identifier that defines the type of the o Type: A single-octet identifier that defines the type of the
parameter represented in this TLV element. parameter represented in this TLV element.
o Length: A two-octet field that indicates the length (in octets) o Length: A two-octet field that indicates the length (in octets)
of the TLV element excluding the Type and Length fields, and the of the TLV element excluding the Type and Length fields, and the
8-bit Reserved field between them. Note that this length does not 8-bit Reserved field between them. This length does not include
include any padding that is required for alignment. any padding that is required for alignment.
o Value: Variable-size set of octets that contains the specific o Value: Variable-size set of octets that contains the specific
value for the parameter. value for the parameter.
In the extensions, the Reserved field SHALL be set to zero and In the extensions, the Reserved field SHALL be set to zero and
ignored. If a TLV element does not fall on a 32-bit boundary, the ignored. If a TLV element does not fall on a 32-bit boundary, the
last word MUST be padded to the boundary using further bits set to last word MUST be padded to the boundary using further bits set to
zero. zero.
In a RAMS message, any vendor-neutral or private extension MUST be In a RAMS message, any vendor-neutral or private extension MUST be
placed after the mandatory fields and mandatory TLV elements (if placed after the mandatory fields and mandatory TLV elements (if
any). The extensions MAY be placed in any order. The support for any). The extensions MAY be placed in any order. The support for
extensions (unless noted otherwise) is OPTIONAL. extensions (unless specified otherwise) is OPTIONAL.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length | | Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value : : Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Structure of a TLV element Figure 5: Structure of a TLV element
skipping to change at page 30, line 17 skipping to change at page 29, line 27
If the goal in defining new TLV elements is to extend the If the goal in defining new TLV elements is to extend the
functionality in a vendor-neutral manner, they MUST be registered functionality in a vendor-neutral manner, they MUST be registered
with IANA through the guidelines provided in Section 11.5. with IANA through the guidelines provided in Section 11.5.
The current document defines several vendor-neutral extensions in the The current document defines several vendor-neutral extensions in the
subsequent sections. subsequent sections.
7.1.2. Private Extensions 7.1.2. Private Extensions
It is desirable to allow vendors to use private extensions in a TLV It is desirable to allow vendors to use private extensions in a TLV
format. For interoperability, such extensions MUST NOT collide with format. For interoperability, such extensions must not collide with
each other. each other.
A certain range of TLV Types (between - and including - 128 and 254 ) A certain range of TLV Types (between - and including - 128 and 254 )
is reserved for private extensions (Refer to Section 11.5). IANA is reserved for private extensions (Refer to Section 11.5). IANA
management for these extensions is unnecessary and they are the management for these extensions is unnecessary and they are the
responsibility of individual vendors. responsibility of individual vendors.
The structure that MUST be used for the private extensions is The structure that MUST be used for the private extensions is
depicted in Figure 6. Here, the enterprise numbers are used from depicted in Figure 6. Here, the enterprise numbers are used from
http://www.iana.org/assignments/enterprise-numbers. This will ensure http://www.iana.org/assignments/enterprise-numbers. This will ensure
skipping to change at page 30, line 48 skipping to change at page 30, line 11
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Structure of a private extension Figure 6: Structure of a private extension
7.2. RAMS Request 7.2. RAMS Request
The RAMS Request message is identified by SFMT=1. This message is The RAMS Request message is identified by SFMT=1. This message is
sent as unicast feedback in the primary multicast RTP session by sent as unicast feedback in the primary multicast RTP session by
RTP_Rx to request rapid acquisition of a primary multicast RTP RTP_Rx to request rapid acquisition of a primary multicast RTP
session, or one or more primary multicast streams belonging to the session, or one or more primary multicast streams belonging to the
same primary multicast RTP session. In the RAMS-R message, both the same primary multicast RTP session. In the RAMS-R message, RTP_Rx
packet sender SSRC and media sender SSRC fields MUST be set to the MUST set both the packet sender SSRC and media sender SSRC fields to
SSRC of RTP_Rx, and RTP_Rx MUST provide explicit signaling as its own SSRC since the media sender SSRC may not be known. RTP_Rx
described below to request stream(s). This minimizes the chances of MUST provide explicit signaling as described below to request
accidentally requesting a wrong primary multicast stream. stream(s). This minimizes the chances of accidentally requesting a
wrong primary multicast stream.
The FCI field MUST contain only one RAMS Request. The FCI field has The FCI field MUST contain only one RAMS Request. The FCI field has
the structure depicted in Figure 7. 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=1 | Reserved | | SFMT=1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) : : Optional TLV-encoded Fields (and Padding, if needed) :
skipping to change at page 31, line 37 skipping to change at page 30, line 49
Length field of the TLV element to 4*n, where n is the number of Length field of the TLV element to 4*n, where n is the number of
SSRC entries. SSRC entries.
Type: 1 Type: 1
o Min RAMS Buffer Fill Requirement (32 bits): Optional TLV element o Min RAMS Buffer Fill Requirement (32 bits): Optional TLV element
that denotes the minimum milliseconds of data that RTP_Rx desires that denotes the minimum milliseconds of data that 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 can have knowledge of its buffering requirements. These
requirements may be application and/or device specific. For requirements can be application and/or device specific. For
instance, RTP_Rx may need to have a certain amount of data in its instance, RTP_Rx might need to have a certain amount of data in
application buffer to handle transmission jitter and/or to be able its application buffer to handle transmission jitter and/or to be
to support error-control methods. If BRS is told the minimum able to support error-control methods. If BRS is told the minimum
buffering requirement of the receiver, it may tailor the burst(s) buffering requirement of the receiver, BRS can 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 bursts and any payload-specific information MUST NOT be unicast bursts and any payload-specific information MUST NOT be
smaller than the specified value since it will not be able to smaller than the specified value. Otherwise, the backfill will
build up the desired level of buffer at RTP_Rx and may cause not be able to build up the desired level of buffer at RTP_Rx and
buffer underruns. can cause buffer underruns.
Type: 2 Type: 2
o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element o Max RAMS Buffer Fill Requirement (32 bits): Optional TLV element
that denotes the maximum milliseconds of data that RTP_Rx can that denotes the maximum milliseconds of data that RTP_Rx can
buffer without losing the 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 can have knowledge of its buffering requirements. These
requirements may be application or device specific. For instance, requirements can be application or device specific. For instance,
one particular RTP_Rx may have more physical memory than another one particular RTP_Rx might have more physical memory than another
RTP_Rx, and thus, can buffer more data. If BRS knows the RTP_Rx, and thus, can buffer more data. If BRS knows the
buffering ability of the receiver, it may tailor the burst(s) more buffering ability of the receiver, BRS can tailor the burst(s)
precisely. The methods used by the receiver to determine this more precisely. The methods used by the receiver to determine
value are application specific, and thus, out of scope. this value are application specific, and thus, out of scope.
If specified, the amount of backfill that will be provided by the If specified, the amount of backfill that will be provided by the
unicast bursts and any payload-specific information MUST NOT be unicast bursts and any payload-specific information MUST NOT be
larger than this value since it may cause buffer overflows at larger than this value. Otherwise, the backfill may cause buffer
RTP_Rx. overflows at RTP_Rx.
Type: 3 Type: 3
o Max Receive Bitrate (64 bits): Optional TLV element that denotes o Max Receive Bitrate (64 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that the RTP receiver can the maximum bitrate (in bits per second) at which the RTP_Rx can
process the aggregation of the unicast burst(s) and any payload- process the aggregation of the unicast burst(s) and any payload-
specific information that will be provided by BRS. The limits may specific information that will be provided by BRS. The limits can
include local receiver limits as well as network limits that are include local receiver limits as well as network limits that are
known to the receiver. known to the receiver.
If specified, the total bitrate of the unicast burst(s) plus any If specified, the total bitrate of the unicast burst(s) plus any
payload-specific information MUST NOT be larger than this value payload-specific information MUST NOT be larger than this value.
since it may cause congestion and packet loss. Otherwise, congestion and packet loss may occur.
Type: 4 Type: 4
o Request for Preamble Only (0 bits): Optional TLV element that o Request for Preamble Only (0 bits): Optional TLV element that
indicates that RTP_Rx is only requesting the preamble information indicates that RTP_Rx is only requesting the preamble information
for the desired primary multicast stream(s). If this TLV element for the desired primary multicast stream(s). If this TLV element
exists in the RAMS-R message, BRS SHOULD NOT send any burst exists in the RAMS-R message, BRS MUST NOT send any burst packets
packets other than the preamble packets. Note that this TLV other than the preamble packets. Since this TLV element does not
element does not carry a Value field. Thus, the Length field MUST carry a Value field, the Length field MUST be set to zero.
be set to zero.
Type: 5 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. This message The RAMS Information message is identified by SFMT=2. This message
is used to describe the unicast burst that will be sent for rapid is used to describe the unicast burst that will be sent for rapid
acquisition. It also includes other useful information for RTP_Rx as acquisition. It also includes other useful information for RTP_Rx as
described below. described below.
A separate RAMS-I message with the appropriate response code is sent A separate RAMS-I message with the appropriate response code is sent
in the unicast burst RTP session by BRS for each primary multicast in the unicast burst RTP session by BRS for each primary multicast
stream that has been requested by RTP_Rx. In the RAMS-I messages, stream that has been requested by RTP_Rx. In each of these RAMS-I
the media sender SSRC and packet sender SSRC fields are both set to messages, the media sender SSRC and packet sender SSRC fields are
the SSRC of the respective primary multicast stream. both set to the SSRC of BRS, which equals the SSRC of the respective
primary multicast stream.
The FCI field MUST contain only one RAMS Information. The FCI field The FCI field MUST contain only one RAMS Information. The FCI field
has the structure depicted in Figure 8. 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=2 | MSN | Response | | SFMT=2 | MSN | Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) : : Optional TLV-encoded Fields (and Padding, if needed) :
skipping to change at page 34, line 10 skipping to change at page 33, line 23
Section 11.6. If the new response code is intended to be used Section 11.6. If the new response code is intended to be used
privately by a vendor, there is no need for IANA management. privately by a vendor, there is no need for IANA management.
Instead, the vendor MUST use the private extension mechanism Instead, the vendor MUST use the private extension mechanism
(Section 7.1.2) to convey its message and MUST indicate this by (Section 7.1.2) to convey its message and MUST indicate this by
putting zero in the Response field. putting zero in the Response field.
The following TLV elements have been defined for the RAMS-I messages: The following TLV elements have been defined for the RAMS-I messages:
o Media Sender SSRC (32 bits): Optional TLV element that specifies o Media Sender SSRC (32 bits): Optional TLV element that specifies
the media sender SSRC of the unicast burst stream. While this the media sender SSRC of the unicast burst stream. While this
information is already available in the message header, it may be information is already available in the message header, it can be
useful to repeat it in an explicit field. For example, if FT_Ap useful to repeat it in an explicit field. If FT_Ap that received
that received the RAMS-R message is associated with a single the RAMS-R message is associated with a single primary multicast
primary multicast stream but the requested media sender SSRC does stream but the requested media sender SSRC does not match the SSRC
not match the SSRC of the RTP stream associated with this FT_Ap, of the RTP stream associated with this FT_Ap, BRS MUST include
BRS SHOULD include this TLV element in the initial RAMS-I message this TLV element in the initial RAMS-I message to let RTP_Rx know
to let RTP_Rx know that the media sender SSRC has changed. If the that the media sender SSRC has changed. If the two SSRCs match,
two SSRCs match, there is no need to include this TLV element. there is no need to include this TLV element.
Type: 31 Type: 31
o RTP Seqnum of the First Packet (16 bits): TLV element that o RTP Seqnum of the First Packet (16 bits): TLV element that
specifies the RTP sequence number of the first packet that will be specifies the RTP sequence number of the first packet that will be
sent in the respective RTP stream. This allows RTP_Rx to know sent in the respective RTP stream. This allows RTP_Rx to know
whether one or more packets sent by BRS have been dropped at the whether one or more packets sent by BRS have been dropped at the
beginning of the stream. If BRS accepts the RAMS request, this beginning of the stream. If BRS accepts the RAMS request, this
element MUST exist. If BRS rejects the RAMS request, this element element MUST exist. If BRS rejects the RAMS request, this element
SHALL NOT exist. SHALL NOT exist.
Type: 32 Type: 32
o Earliest Multicast Join Time (32 bits): TLV element that o Earliest Multicast Join Time (32 bits): TLV element that
specifies the delta time (in ms) between the arrival of the first specifies the delta time (in ms) between the arrival of the first
RTP packet in the RTP stream (which could be a burst packet or a RTP packet in the RTP stream (which could be a burst packet or a
payload-specific packet) and the earliest time instant when RTP_Rx payload-specific packet) and the earliest time instant when RTP_Rx
SHOULD send an SFGMP Join message to join the multicast session. SHOULD send an SFGMP Join message to join the multicast session.
A zero value in this field means that RTP_Rx may send the SFGMP A zero value in this field means that RTP_Rx can send the SFGMP
Join message right away. Join message right away.
If the RAMS request has been accepted, BRS MUST send this field at If the RAMS request has been accepted, BRS MUST send this field at
least once, so that RTP_Rx knows when to join the multicast least once, so that RTP_Rx knows when to join the multicast
session. If the burst request has been rejected as indicated in session. If the burst request has been rejected as indicated in
the Response field, this field MUST be set to zero. In that case, the Response field, this field MUST be set to zero. In that case,
it is up to RTP_Rx when or whether to join the multicast session. it is up to RTP_Rx when or whether to join the multicast session.
It should be noted that when BRS serves two or more bursts and When BRS serves two or more bursts and sends a separate RAMS-I
sends a separate RAMS-I message for each burst, the join times message for each burst, the join times specified in these RAMS-I
specified in these RAMS-I messages should correspond to more or messages should correspond to more or less the same time instant,
less the same time instant, and RTP_Rx sends the SFGMP Join and RTP_Rx sends the SFGMP Join message based on the earliest join
message based on the earliest join time. time.
Type: 33 Type: 33
o Burst Duration (32 bits): Optional TLV element that denotes the o Burst Duration (32 bits): Optional TLV element that denotes the
duration of the burst, i.e., the delta difference between the duration of the burst, i.e., the delta difference between the
first and the last burst packet, that BRS is planning to send (in first and the last burst packet, that BRS is planning to send (in
ms) in the respective RTP stream. In the absence of additional ms) in the respective RTP stream. In the absence of additional
stimulus, BRS will send a burst of this duration. However, the stimulus, BRS will send a burst of this duration. However, the
burst duration may be modified by subsequent events, including burst duration can be modified by subsequent events, including
changes in the primary multicast stream and reception of RAMS-T changes in the primary multicast stream and reception of RAMS-T
messages. messages.
Note that BRS MUST terminate the flow in a deterministic BRS MUST terminate the flow in a deterministic timeframe, even if
timeframe, even if it does not get a RAMS-T or a BYE from RTP_Rx. it does not get a RAMS-T or a BYE from RTP_Rx. It is OPTIONAL to
It is OPTIONAL to send this field in a RAMS-I message when the send this field in a RAMS-I message when the burst request is
burst request is accepted. If the burst request has been rejected accepted. If the burst request has been rejected as indicated in
as indicated in the Response field, this field MAY be omitted or the Response field, this field MAY be omitted or set to zero.
set to zero.
Type: 34 Type: 34
o Max Transmit Bitrate (64 bits): Optional TLV element that denotes o Max Transmit Bitrate (64 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that will be used by BRS the maximum bitrate (in bits per second) that will be used by BRS
for the RTP stream associated with this RAMS-I message. for the RTP stream associated with this RAMS-I message.
Type: 35 Type: 35
The semantics of the RAMS-I feedback message is independent of the The semantics of the RAMS-I feedback message is independent of the
skipping to change at page 35, line 50 skipping to change at page 35, line 18
The RAMS Termination is used to assist BRS in determining when to The RAMS Termination is used to assist BRS in determining when to
stop the burst. A separate RAMS-T message is sent in the unicast stop the burst. A separate RAMS-T message is sent in the unicast
burst RTP session by RTP_Rx for each primary multicast stream that burst RTP session by RTP_Rx for each primary multicast stream that
has been served by BRS. Each of these RAMS-T messages has the has been served by BRS. Each of these RAMS-T messages has the
appropriate media sender SSRC populated in its message header. appropriate media sender SSRC populated in its message header.
If RTP_Rx wants BRS to stop a burst prematurely, it sends a plain If RTP_Rx wants BRS to stop a burst prematurely, it sends a plain
RAMS-T message as described below. Upon receiving this message, BRS RAMS-T message as described below. Upon receiving this message, BRS
stops the respective burst immediately. If RTP_Rx wants BRS to stops the respective burst immediately. If RTP_Rx wants BRS to
terminate all of the bursts, it should send all of the respective terminate all of the bursts, it needs to send all of the respective
RAMS-T messages in a single compound RTCP packet. RAMS-T messages in a single compound RTCP packet.
The default behavior for RTP_Rx is to send a RAMS-T message The default behavior for RTP_Rx is to send a RAMS-T message
immediately after it joined the multicast session and started immediately after it joined the multicast session and started
receiving multicast packets. In that case, RTP_Rx includes the receiving multicast packets. In that case, RTP_Rx includes the
sequence number of the first RTP packet received in the primary sequence number of the first RTP packet received in the primary
multicast stream in the RAMS-T message. With this information, BRS multicast stream in the RAMS-T message. With this information, BRS
can decide when to terminate the unicast burst. can decide when to terminate the unicast burst.
The FCI field MUST contain only one RAMS Termination. The FCI field The FCI field MUST contain only one RAMS Termination. The FCI field
skipping to change at page 36, line 31 skipping to change at page 35, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: FCI field syntax for the RAMS Termination message Figure 9: FCI field syntax for the RAMS Termination message
o Extended RTP Seqnum of First Multicast Packet (32 bits): Optional o Extended RTP Seqnum of First Multicast Packet (32 bits): Optional
TLV element that specifies the extended RTP sequence number of the TLV element that specifies the extended RTP sequence number of the
first packet received from the SSM session for a particular first packet received from the SSM session for a particular
primary multicast stream. The low 16 bits contain the sequence primary multicast stream. The low 16 bits contain the sequence
number of the first packet received from the SSM session, and the number of the first packet received from the SSM session, and the
most significant 16 bits extend that sequence number with the most significant 16 bits extend that sequence number with the
corresponding count of sequence number cycles, which may be corresponding count of sequence number cycles, which can be
maintained according to the algorithm in Appendix A.1 of maintained according to the algorithm in Appendix A.1 of
[RFC3550]. [RFC3550].
Type: 61 Type: 61
The semantics of the RAMS-T feedback message is independent of the The semantics of the RAMS-T feedback message is independent of the
payload type. payload type.
8. SDP Signaling 8. SDP Signaling
skipping to change at page 37, line 22 skipping to change at page 36, line 37
'nack': 'nack':
o 'rai' stands for Rapid Acquisition Indication and indicates the o 'rai' stands for Rapid Acquisition Indication and indicates the
use of RAMS messages as defined in Section 7. use of RAMS messages as defined in Section 7.
This document also defines a new media-level SDP attribute ('rams- This document also defines a new media-level SDP attribute ('rams-
updates') that indicates whether BRS supports updated request updates') that indicates whether BRS supports updated request
messages or not. This attribute is used in a declarative manner and messages or not. This attribute is used in a declarative manner and
no Offer/Answer Model behavior is specified. If BRS supports updated no Offer/Answer Model behavior is specified. If BRS supports updated
request messages and this attribute is included in the SDP request messages and this attribute is included in the SDP
description, RTP_Rx may send updated requests. BRS may or may not be description, RTP_Rx can send updated requests. BRS might or might
able to accept value changes in every field in an updated RAMS-R not be able to accept value changes in every field in an updated
message. However, if the 'rams-updates' attribute is not included in RAMS-R message. However, if the 'rams-updates' attribute is not
the SDP description, RTP_Rx SHALL NOT send updated requests (RTP_Rx included in the SDP description, RTP_Rx SHALL NOT send updated
MAY still repeat its initial request without changes, though). requests. RTP_Rx MAY still repeat its initial request without
changes, though.
8.2. Requirements 8.2. Requirements
The use of SDP to describe the RAMS entities normatively requires the The use of SDP to describe the RAMS entities normatively requires the
support for: support for:
o The SDP grouping framework and flow identification (FID) semantics o The SDP grouping framework and flow identification (FID) semantics
[I-D.ietf-mmusic-rfc3388bis] [I-D.ietf-mmusic-rfc3388bis]
o The RTP/AVPF profile [RFC4585] o The RTP/AVPF profile [RFC4585]
o The RTP retransmission payload format [RFC4588] o The RTP retransmission payload format [RFC4588]
o The RTCP extensions for SSM sessions with unicast feedback o The RTCP extensions for SSM sessions with unicast feedback
[RFC5760] [RFC5760]
o The multicast RTCP port attribute
[I-D.begen-avt-rtcp-port-for-ssm]
o Multiplexing RTP and RTCP on a single port on both endpoints in o Multiplexing RTP and RTCP on a single port on both endpoints in
the unicast session[I-D.ietf-avt-rtp-and-rtcp-mux] the unicast session[RFC5761]
The support for the source-specific media attributes [RFC5576] and The support for the source-specific media attributes [RFC5576] can
multicast RTCP port attribute [I-D.begen-avt-rtcp-port-for-ssm] may
also be needed. also be needed.
8.3. Example and Discussion 8.3. Example and Discussion
This section provides a declarative SDP [RFC4566] example for This section provides a declarative SDP [RFC4566] example for
enabling rapid acquisition of multicast RTP sessions. enabling rapid acquisition of multicast RTP sessions.
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
skipping to change at page 38, line 48 skipping to change at page 38, line 43
In this example SDP description, we have a primary multicast (source) In this example SDP description, we have a primary multicast (source)
stream and a unicast retransmission stream. The source stream is stream and a unicast retransmission stream. The source stream is
multicast from a distribution source (with a source IP address of multicast from a distribution source (with a source IP address of
198.51.100.1) to the multicast destination address of 233.252.0.2 and 198.51.100.1) to the multicast destination address of 233.252.0.2 and
port 41000. The corresponding RTCP traffic is multicast to the same port 41000. The corresponding RTCP traffic is multicast to the same
multicast destination address at port 42000. Here, we are assuming multicast destination address at port 42000. Here, we are assuming
that the multicast RTP and RTCP ports are carefully chosen so that that the multicast RTP and RTCP ports are carefully chosen so that
different RTP and RTCP streams do not collide with each other. different RTP and RTCP streams do not collide with each other.
The feedback target (FT_Ap) residing on the retransmission server The feedback target (FT_Ap) residing on RS (with an address of
(with an address of 192.0.2.1) at port 43000 is declared with the 192.0.2.1) at port 43000 is declared with the "a=rtcp" line
"a=rtcp" line [RFC3605]. The support for the conventional [RFC3605]. The support for the conventional retransmission is
retransmission is indicated through the "a=rtcp-fb:98 nack" line. indicated through the "a=rtcp-fb:98 nack" line. The RTP receiver(s)
can report missing packets on the source stream to the feedback
The RTP receiver(s) can report missing packets on the source stream target and request retransmissions. The SDP above includes the
to the feedback target and request retransmissions. Note that this "a=sendonly" line for the media description of the retransmission
SDP includes the "a=sendonly" line for the media description of the stream since the retransmissions are sent in only one direction.
retransmission stream since the retransmissions are sent in only one
direction.
The support for rapid acquisition is indicated through the "a=rtcp- The support for rapid acquisition is indicated through the "a=rtcp-
fb:98 nack rai" line. The parameter 'rtx-time' applies to both the fb:98 nack rai" line. The parameter 'rtx-time' applies to both the
conventional retransmissions and rapid acquisition. However, when conventional retransmissions and rapid acquisition. However, when
rapid acquisition is enabled, the standard definition for the rapid acquisition is enabled, the standard definition for the
parameter 'rtx-time' given in [RFC4588] is not followed. Instead, parameter 'rtx-time' given in [RFC4588] is not followed. Instead,
when rapid acquisition support is enabled, 'rtx-time' specifies the when rapid acquisition support is enabled, 'rtx-time' specifies the
time in milliseconds that the retransmission server keeps an RTP time in milliseconds that BRS keeps an RTP packet in its cache
packet in its cache available for retransmission (measured from the available for retransmission (measured from the time the packet was
time the packet was received by the retransmission server, not from received by BRS, not from the time indicated in the packet
the time indicated in the packet timestamp). timestamp).
Once an RTP receiver has acquired an SDP description, it may ask for Once an RTP_Rx has acquired an SDP description, it can ask for rapid
rapid acquisition before it joins a primary multicast RTP session. acquisition before it joins a primary multicast RTP session. To do
To do so, it sends a RAMS-R message to the feedback target of that so, it sends a RAMS-R message to the feedback target of that primary
primary multicast RTP session. If FT_Ap is associated with only one multicast RTP session. If FT_Ap is associated with only one RTP
RTP stream, the RTP receiver does not need to learn the SSRC of that stream, RTP_Rx does not need to learn the SSRC of that stream via an
stream via an out-of-band method. If BRS accepts the rapid out-of-band method. If BRS accepts the rapid acquisition request, it
acquisition request, it will send an RAMS-I message with the correct will send an RAMS-I message with the correct SSRC identifier. If
SSRC identifier. If FT_Ap is associated with a multi-stream RTP FT_Ap is associated with a multi-stream RTP session and RTP_Rx is
session and the RTP receiver is willing to request rapid acquisition willing to request rapid acquisition for the entire session, RTP_Rx
for the entire session, the RTP receiver again does not need to learn again does not need to learn the SSRCs via an out-of-band method.
the SSRCs via an out-of-band method. However, if the RTP receiver However, if RTP_Rx intends to request a particular subset of the
intends to request a particular subset of the primary multicast primary multicast streams, it must learn their SSRC identifiers and
streams, it must learn their SSRC identifiers and list them in the list them in the RAMS-R message. Since this RTP_Rx has not yet
RAMS-R message. Since this RTP receiver has not yet received any RTP received any RTP packets for the primary multicast stream(s), RTP_Rx
packets for the primary multicast stream(s), the RTP receiver must in must in this case learn the SSRC value(s) from the 'ssrc' attribute
this case learn the SSRC value(s) from the 'ssrc' attribute of the of the media description [RFC5576]. In addition to the SSRC value,
media description [RFC5576]. In addition to the SSRC value, the the 'cname' source attribute must also be present in the SDP
'cname' source attribute must also be present in the SDP description description [RFC5576].
[RFC5576].
Note that listing the SSRC values for the primary multicast streams Listing the SSRC values for the primary multicast streams in the SDP
in the SDP file does not create a problem in SSM sessions when an file does not create a problem in SSM sessions when an SSRC collision
SSRC collision occurs. This is because in SSM sessions, an RTP occurs. This is because in SSM sessions, an RTP_Rx that observed an
receiver that observed an SSRC collision with a media sender MUST SSRC collision with a media sender must change its own SSRC [RFC5760]
change its own SSRC [RFC5760] by following the rules defined in by following the rules defined in [RFC3550].
[RFC3550].
A feedback target that receives a 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 RTP_Rx side has been broken or
broken or does not exist anymore. If the necessary conditions are does not exist anymore. If the necessary conditions are satisfied
satisfied (as outlined in Section 7 of [RFC4585]) and available (as outlined in Section 7 of [RFC4585]) and available resources
resources exist, BRS may react to the RAMS-R message by sending any exist, BRS can react to the RAMS-R message by sending any transport-
transport-layer (and optional payload-specific, when allowed) layer (and optional payload-specific, when allowed) feedback
feedback message(s) and starting the unicast burst. message(s) and starting the unicast burst.
In this section, we considered the simplest scenario where the In this section, we considered the simplest scenario where the
primary multicast RTP session carried only one stream and the RTP primary multicast RTP session carried only one stream and RTP_Rx
receiver wanted to rapidly acquire this stream only. Best practices wanted to rapidly acquire this stream only. Best practices for
for scenarios where the primary multicast RTP session carries two or scenarios where the primary multicast RTP session carries two or more
more streams or the RTP receiver wants to acquire one or more streams streams or RTP_Rx wants to acquire one or more streams from multiple
from multiple primary multicast RTP sessions at the same time are primary multicast RTP sessions at the same time are presented in
presented in [I-D.begen-avt-rams-scenarios]. [I-D.begen-avt-rams-scenarios].
9. NAT Considerations 9. NAT Considerations
For a variety of reasons, one or more NAPT devices (hereafter simply For a variety of reasons, one or more NAPT devices (hereafter simply
called NAT) may exist between RTP_Rx and RS. NATs have a variety of called NAT) can exist between RTP_Rx and RS. NATs have a variety of
operating characteristics for UDP traffic [RFC4787]. For a NAT to operating characteristics for UDP traffic [RFC4787]. For a NAT to
permit traffic from BRS to arrive at RTP_Rx, the NAT(s) must first permit traffic from BRS to arrive at RTP_Rx, the NAT(s) must 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 BRS (which is on the 'outside' of the NAT). This traffic NAT) to BRS (which is on the 'outside' of the NAT). This traffic
is sent to the same transport address as the subsequent response has the same transport address as the subsequent response
traffic, or; traffic, or;
b. Be configured to forward certain ports (e.g., using HTML b. Be configured to forward certain ports (e.g., using HTML
configuration, UPnP IGD [UPnP-IGD], DLNA [DLNA]). Details of configuration, 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 BRS on that port. For state if it wants to receive traffic from the BRS 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]. While (a) is more like an
an automatic/dynamic configuration, (b) is more like a manual/static automatic/dynamic configuration, (b) is more like a manual/static
configuration. configuration.
When RTP_Rx sends a RAMS-R message to FT as unicast feedback in the When RTP_Rx sends a request (RAMS-R) message to FT as unicast
primary multicast RTP session, and the request is received by FT, a feedback in the primary multicast RTP session, and the request is
new unicast burst RTP session will be established between BRS and received by FT, a new unicast burst RTP session will be established
RTP_Rx. between BRS and RTP_Rx.
While the FT and BRS ports on RS are already signaled via out-of-band While the FT and BRS ports on RS are already signaled via out-of-band
means (e.g., SDP), RTP_Rx needs to convey the RTP and RTCP ports it means (e.g., SDP), RTP_Rx needs to convey the RTP and RTCP ports it
wants to use on its side for the new session. Since there are two 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 RTP sessions (one multicast and one unicast) involved during this
established upon a feedback message sent in the other one, this process and one of them is established upon a feedback message sent
requires an explicit port mapping method. This problem equally in the other one, this requires an explicit port mapping method.
applies to scenarios where the RTP media is multicast in an SSM This problem equally applies to scenarios where the RTP media is
session, and an RTP receiver requests retransmission from a local multicast in an SSM session, and an RTP_Rx requests retransmission
repair server by using the RTCP NACK messages for the missing packets from a local repair server by using the RTCP NACK messages for the
and the repair server retransmits the requested packets over a missing packets and the repair server retransmits the requested
unicast session. Thus, instead of laying out a specific solution for packets over a unicast session. Thus, instead of laying out a
the RAMS applications, a general solution is introduced in specific solution for the RAMS applications, a general solution is
[I-D.ietf-avt-ports-for-ucast-mcast-rtp]. This generic solution introduced in [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. This generic
implies the exchange of port mapping RTCP messages between RTP_Rx and solution implies the exchange of port mapping RTCP messages between
BRS. RTP_Rx and BRS.
Applications using RAMS MUST support this solution both on the RS and Applications using RAMS MUST support the solution presented in
RTP_Rx side to allow RTP receivers to use their desired ports and to [I-D.ietf-avt-ports-for-ucast-mcast-rtp] both on the RS and RTP_Rx
support RAMS behind NAT devices. The port mapping message exchange side to allow RTP receivers to use their desired ports and to support
needs to take place whenever RTP_Rx intends to make use of the RAMS RAMS behind NAT devices. The port mapping message exchange needs to
protocol for rapidly acquiring a specific multicast RTP session, take place whenever RTP_Rx intends to make use of the RAMS protocol
prior to joining the associated SSM session. for rapidly acquiring a specific multicast RTP session, prior to
joining the associated SSM session.
10. Security Considerations 10. Security Considerations
Applications that are using RAMS make heavy use of the unicast Applications that are using RAMS make heavy use of the unicast
feedback mechanism described in [RFC5760], the payload format defined feedback mechanism described in [RFC5760], the payload format defined
in [RFC4588] and the port mapping solution specified in in [RFC4588] and the port mapping solution specified in
[I-D.ietf-avt-ports-for-ucast-mcast-rtp]. Thus, these applications [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. Thus, these applications
are subject to the general security considerations discussed in are subject to the general security considerations discussed in
[RFC5760], [RFC4588] and [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. [RFC5760], [RFC4588] and [I-D.ietf-avt-ports-for-ucast-mcast-rtp].
In this section, we give an overview of the guidelines and In this section, we give an overview of the guidelines and
suggestions described in these specifications from a RAMS suggestions described in these specifications from a RAMS
perspective. We also discuss the security considerations that perspective. We also discuss the security considerations that
explicitly apply to applications using RAMS. explicitly apply to applications using RAMS.
First of all, much of the session description information is First of all, much of the session description information is
available in the SDP descriptions that are distributed to the media available in the SDP descriptions that are distributed to the media
senders, retransmission servers and RTP receivers. Adequate security senders, retransmission servers and RTP receivers. Adequate 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
senders, distribution sources, feedback targets as well as other senders, distribution sources, feedback targets as well as other
session-specific information can be authenticated. session-specific information can be protected.
Compared to an RTCP NACK message that triggers one or more Compared to an RTCP NACK message that triggers one or more
retransmissions, a RAMS Request (RAMS-R) message may trigger a new retransmissions, a RAMS Request (RAMS-R) message can trigger a new
burst stream to be sent by the retransmission server. Depending on burst stream to be sent by the retransmission server. Depending on
the application-specific requirements and conditions existing at the the application-specific requirements and conditions existing at the
time of the RAMS-R reception by the retransmission server, the time of the RAMS-R reception by the retransmission server, the
resulting burst stream may contain potentially a large number of resulting burst stream can potentially contain 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, RAMS consumes more resources on the than the nominal rate, RAMS consumes more resources on the
retransmission server, the RTP receiver and the network. This may retransmission servers, RTP receivers and the network. In
particularly make denial-of-service attacks more intense, and hence, particular, this can make denial-of-service attacks more intense, and
more harmful than attacks that target ordinary retransmission hence, more harmful than attacks that target ordinary 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 can 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 at the receiver side, or the updated burst can overflow the buffer at the receiver side, or
oppositely, may slow down the burst to the point that it becomes oppositely, can slow down the burst to the point that it becomes
useless. Tampered RAMS Termination (RAMS-T) messages may terminate useless. Tampered RAMS Termination (RAMS-T) messages can terminate
valid burst streams prematurely resulting in gaps in the received RTP valid burst streams prematurely resulting in gaps in the received RTP
packets. RAMS Information (RAMS-I) messages contain fields that are packets. RAMS Information (RAMS-I) messages contain fields that are
critical for a successful rapid acquisition. Any tampered critical for a successful rapid acquisition. Any tampered
information in the RAMS-I message may easily cause the RTP receiver information in the RAMS-I message can easily cause an RTP receiver to
to make wrong decisions. Consequently, the RAMS operation may fail. make wrong decisions. Consequently, the RAMS operation can 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 Secure RTP (SRTP) integrity and authenticity checks enabled by Secure RTP (SRTP)
[RFC3711], an attack can still be started by legitimate endpoints [RFC3711], an attack can still be started by legitimate endpoints
that send several valid RAMS-R messages to a particular feedback that send several valid RAMS-R messages to a particular feedback
target in a synchronized fashion and very short amount of time. target in a synchronized fashion and very short amount of time.
Since a RAMS operation may temporarily consume a large amount of Since a RAMS operation can temporarily consume a large amount of
resources, a series of the RAMS-R messages may temporarily overload resources, a series of the RAMS-R messages can temporarily overload
the retransmission server. In these circumstances, the the retransmission server. In these circumstances, the
retransmission server may, for example, reject incoming RAMS requests retransmission server can, for example, reject incoming RAMS requests
until its resources become available again. One means to ameliorate until its resources become available again. One means to ameliorate
this threat is to apply a per-endpoint policing mechanism on the this threat is to apply a per-endpoint policing mechanism on the
incoming RAMS requests. A reasonable policing mechanism should incoming RAMS requests. A reasonable policing mechanism should
consider application-specific requirements and minimize false consider application-specific requirements and minimize false
negatives. negatives.
In addition to the denial-of-service attacks, man-in-the-middle and In addition to the denial-of-service attacks, man-in-the-middle and
replay attacks can also be harmful. However, RAMS itself does not replay attacks can also be harmful. However, RAMS itself does not
bring any new risks or threats other than the ones discussed in bring any new risks or threats other than the ones discussed in
[RFC5760]. [RFC5760].
skipping to change at page 43, line 7 skipping to change at page 42, line 47
plain-text attacks. As discussed in [RFC4588], the retransmission plain-text attacks. As discussed in [RFC4588], the retransmission
payload format sets the timestamp field in the RTP header to the payload format sets the timestamp field in the RTP header to the
media timestamp of the original packet and this does not compromise media timestamp of the original packet and this does not compromise
the confidentiality. Furthermore, if cryptography is used to provide the confidentiality. Furthermore, if cryptography is used to provide
security services on the original stream, then the same services, security services on the original stream, then the same services,
with equivalent cryptographic strength, MUST be provided on the with equivalent cryptographic strength, MUST be provided on the
retransmission stream per [RFC4588]. retransmission stream per [RFC4588].
To protect the RTCP messages from man-in-the-middle and replay To protect the RTCP messages from man-in-the-middle and replay
attacks, the RTP receivers and retransmission server SHOULD perform a attacks, the RTP receivers and retransmission server SHOULD perform a
DTLS-SRTP handshake [I-D.ietf-avt-dtls-srtp] over the RTCP channel. DTLS-SRTP handshake [RFC5764] over the RTCP channel. Because there
Because there is no integrity-protected signaling channel between an is no integrity-protected signaling channel between an RTP receiver
RTP receiver and the retransmission server, the retransmission server and the retransmission server, the retransmission server MUST
MUST maintain a list of certificates owned by legitimate RTP maintain a list of certificates owned by legitimate RTP receivers, or
receivers, or their certificates MUST be signed by a trusted their certificates MUST be signed by a trusted Certificate Authority.
Certificate Authority. Once the DTLS-SRTP security is established,
non-SRTCP-protected messages received from a particular RTP receiver Once the DTLS-SRTP security is established, non-SRTCP-protected
are ignored by the retransmission server. To reduce the impact of messages received from a particular RTP receiver are ignored by the
DTLS-SRTP overhead when communicating with different feedback targets retransmission server. To reduce the impact of DTLS-SRTP overhead
on the same retransmission server, it is RECOMMENDED that RTP when communicating with different feedback targets on the same
receivers and the retransmission server both support TLS Session retransmission server, it is RECOMMENDED that RTP receivers and the
Resumption without Server-side State [RFC5077]. retransmission server both support TLS Session Resumption without
Server-side State [RFC5077]. To help scale SRTP to handle many RTP
receivers asking for retransmissions of identical data, implementors
may consider using the same SRTP key for SRTP data sent to the
receivers [I-D.ietf-avt-srtp-ekt] and consider the security of such
SRTP key sharing.
11. IANA Considerations 11. IANA Considerations
The following contact information shall be used for all registrations The following contact information shall be used for all registrations
in this document: in this document:
Ali Begen Ali Begen
abegen@cisco.com abegen@cisco.com
170 West Tasman Drive
San Jose, CA 95134 USA
Note to the RFC Editor: In the following, please replace "XXXX" with Note to the RFC Editor: In the following, please replace "XXXX" with
the number of this document prior to publication as an RFC. the number of this document prior to publication as an RFC.
11.1. Registration of SDP Attributes 11.1. Registration of SDP Attributes
This document registers a new attribute name in SDP. This document registers a new attribute name in SDP.
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: rams-updates Attribute name: rams-updates
Long form: Support for Updated RAMS Request Messages Long form: Support for Updated RAMS Request Messages
skipping to change at page 45, line 14 skipping to change at page 45, line 8
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
shall be interpreted. shall be interpreted.
Note that new RAMS functionality should be introduced by using the New RAMS functionality is intended to be introduced by using the
extension mechanism within the existing RAMS message types not by extension mechanism within the existing RAMS message types not by
introducing new message types unless it is absolutely necessary. introducing new message types unless it is absolutely necessary.
11.5. RAMS TLV Space Registry 11.5. RAMS TLV Space Registry
This document creates a new IANA TLV space registry for the RAMS This document creates a new IANA TLV space registry for the RAMS
extensions. The registry is called the RAMS TLV Space Registry. extensions. The registry is called the RAMS TLV Space Registry.
This registry is to be managed by the IANA according to the This registry is to be managed by the IANA according to the
Specification Required policy of [RFC5226]. Specification Required policy of [RFC5226].
skipping to change at page 46, line 44 skipping to change at page 46, line 21
11.6. RAMS Response Code Space Registry 11.6. RAMS Response Code Space Registry
This document creates a new IANA TLV space registry for the RAMS This document creates a new IANA TLV space registry for the RAMS
response codes. The registry is called the RAMS Response Code Space response codes. The registry is called the RAMS Response Code Space
Registry. This registry is to be managed by the IANA according to Registry. This registry is to be managed by the IANA according to
the Specification Required policy of [RFC5226]. the Specification Required policy of [RFC5226].
The length of the Response field is two octets, allowing 65536 codes. The length of the Response field is two octets, allowing 65536 codes.
However, the response codes have been classified and registered However, the response codes have been classified and registered
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 should be classified following the guidelines below:
Code Level Purpose Code Level Purpose
---------- --------------- ---------- ---------------
1xx Informational 1xx Informational
2xx Success 2xx Success
3xx Redirection 3xx Redirection
4xx RTP Receiver Error 4xx RTP Receiver Error
5xx Retransmission Server Error 5xx Retransmission Server Error
The Response code 65536 is reserved for future use. The Response code 65536 is reserved for future use.
skipping to change at page 48, line 27 skipping to change at page 48, line 19
to some of the issues raised during the development of this to some of the issues raised during the development of this
specification. specification.
13. Acknowledgments 13. Acknowledgments
The following individuals have reviewed the earlier versions of this The following individuals have reviewed the earlier versions of this
specification and provided helpful comments: Colin Perkins, Joerg specification and provided helpful comments: Colin Perkins, Joerg
Ott, Roni Even, Dan Wing, Tony Faustini, Peilin Yang, Jeff Goldberg, Ott, Roni Even, Dan Wing, Tony Faustini, Peilin Yang, Jeff Goldberg,
Muriel Deschanel, Orit Levin, Guy Hirson, Tom Taylor, Xavier Marjou, Muriel Deschanel, Orit Levin, Guy Hirson, Tom Taylor, Xavier Marjou,
Ye-Kui Wang, Zixuan Zou, Ingemar Johansson, Haibin Song, Ning Zong, Ye-Kui Wang, Zixuan Zou, Ingemar Johansson, Haibin Song, Ning Zong,
Jonathan Lennox, Jose Rey and Sean Sheedy. Jonathan Lennox, Jose Rey, Sean Sheedy and Keith Drage.
14. Change Log
14.1. draft-ietf-avt-rapid-acquisition-for-rtp-09
The following are the major changes compared to version 08:
o Further fixes and changes requested by Magnus W. and Colin P. have
been addressed throughout the document.
14.2. draft-ietf-avt-rapid-acquisition-for-rtp-08
The following are the major changes compared to version 07:
o Fixes and changes requested by Magnus W. and Jose R. have been
addressed throughout the document.
o Some references have been updated.
14.3. draft-ietf-avt-rapid-acquisition-for-rtp-07
The following are the major changes compared to version 06:
o Congestion control considerations text has been added to Section
6.4.
14.4. 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.
14.5. draft-ietf-avt-rapid-acquisition-for-rtp-05
The following are the major changes compared to version 04:
o Editorial changes throughout the document.
14.6. draft-ietf-avt-rapid-acquisition-for-rtp-04
The following are the major changes compared to version 03:
o Clarifications for the definition of RS.
o Response codes have been defined.
14.7. draft-ietf-avt-rapid-acquisition-for-rtp-03
The following are the major changes compared to version 02:
o Clarifications for the RAMS-I message.
o Type values have been assigned.
14.8. draft-ietf-avt-rapid-acquisition-for-rtp-02
The following are the major changes compared to version 01:
o Port mapping discussion has been removed since it will be
discussed in a separate draft.
o Security considerations section has been added.
o Burst shaping section has been completed.
o Most of the outstanding open issues have been addressed.
14.9. draft-ietf-avt-rapid-acquisition-for-rtp-01
The following are the major changes compared to version 00:
o Formal definitions of vendor-neutral and private extensions and
their IANA registries have been added.
o SDP examples were explained in more detail.
o The sub-FMT field has been introduced in the RAMS messages for
message type identification.
o Some terminology has been fixed.
o NAT considerations section has been added.
14.10. draft-ietf-avt-rapid-acquisition-for-rtp-00
This is a resubmission of version 03 as a WG item.
14.11. draft-versteeg-avt-rapid-synchronization-for-rtp-03
The following are the major changes compared to version 02:
o The title and message names have been changed.
o RTCP message semantics have been added. RAMS protocol has been
revised to handle updated requests and responses.
o Definitions have been revised.
o RTP/RTCP muxing reference has been added.
14.12. draft-versteeg-avt-rapid-synchronization-for-rtp-02
The following are the major changes compared to version 01:
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
modified and they have been made mandatory.
o IANA Considerations section has been updated.
o The discussion of RTCP XR report has been moved to another
document.
o A new section on protocol design considerations has been added.
14.13. draft-versteeg-avt-rapid-synchronization-for-rtp-01
The following are the major changes compared to version 00:
o The core of the rapid synchronization method is now payload-
independent. But, the draft still defines payload-specific
messages that are required for enabling rapid synch for the RTP
flows carrying MPEG2-TS.
o RTCP APP packets have been removed, new RTCP transport-layer and
payload-specific feedback messages have been defined.
o The step for leaving the current multicast session has been
removed from Section 6.2.
o A new RTCP XR (Multicast Join) report has been defined.
o IANA Considerations section have been updated.
o Editorial changes to clarify several points.
15. References 14. References
15.1. Normative References 14.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 52, line 48 skipping to change at page 49, line 37
[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 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008. Header Extensions", RFC 5285, July 2008.
[I-D.begen-avt-rtp-cnames]
Begen, A., Perkins, C., and D. Wing, "Guidelines for
Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs)", draft-begen-avt-rtp-cnames-02 (work in
progress), May 2010.
[I-D.ietf-avt-rapid-rtp-sync] [I-D.ietf-avt-rapid-rtp-sync]
Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", draft-ietf-avt-rapid-rtp-sync-09 (work in Flows", draft-ietf-avt-rapid-rtp-sync-10 (work in
progress), January 2010. progress), May 2010.
[I-D.ietf-avt-rtp-and-rtcp-mux] [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010.
Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), [I-D.begen-avt-rtcp-port-for-ssm]
August 2007. Begen, A., "RTP Control Protocol (RTCP) Port for Multicast
Sessions", draft-begen-avt-rtcp-port-for-ssm-01 (work in
progress), April 2010.
[I-D.ietf-avt-ports-for-ucast-mcast-rtp] [I-D.ietf-avt-ports-for-ucast-mcast-rtp]
Begen, A. and B. Steeg, "Port Mapping Between Unicast and Begen, A. and B. Steeg, "Port Mapping Between Unicast and
Multicast RTP Sessions", Multicast RTP Sessions",
draft-ietf-avt-ports-for-ucast-mcast-rtp-01 (work in draft-ietf-avt-ports-for-ucast-mcast-rtp-02 (work in
progress), April 2010. progress), May 2010.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[I-D.ietf-avt-dtls-srtp] [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure
Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
Real-time Transport Protocol (SRTP)",
draft-ietf-avt-dtls-srtp-07 (work in progress),
February 2009.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. Server-Side State", RFC 5077, January 2008.
[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 14.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.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.ietf-avt-multicast-acq-rtcp-xr] [I-D.ietf-avt-multicast-acq-rtcp-xr]
Begen, A. and E. Friedrich, "Multicast Acquisition Report Begen, A. and E. Friedrich, "Multicast Acquisition Report
Block Type for RTP Control Protocol (RTCP) Extended Block Type for RTP Control Protocol (RTCP) Extended
Reports (XRs)", draft-ietf-avt-multicast-acq-rtcp-xr-00 Reports (XRs)", draft-ietf-avt-multicast-acq-rtcp-xr-01
(work in progress), February 2010. (work in progress), May 2010.
[I-D.begen-avt-rtp-cnames]
Begen, A. and C. Perkins, "Guidelines for Choosing an RTP
Control Protocol (RTCP) Canonical Name (CNAME) for Hosts
with Private IP Addresses", draft-begen-avt-rtp-cnames-00
(work in progress), April 2010.
[I-D.ietf-avt-ecn-for-rtp] [I-D.ietf-avt-ecn-for-rtp]
Westerlund, M., Johansson, I., Perkins, C., and K. Westerlund, M., Johansson, I., Perkins, C., and K.
Carlberg, "Explicit Congestion Notification (ECN) for RTP Carlberg, "Explicit Congestion Notification (ECN) for RTP
over UDP", draft-ietf-avt-ecn-for-rtp-01 (work in over UDP", draft-ietf-avt-ecn-for-rtp-01 (work in
progress), March 2010. progress), March 2010.
[I-D.ietf-fecframe-interleaved-fec-scheme] [I-D.ietf-fecframe-interleaved-fec-scheme]
Begen, A., "RTP Payload Format for 1-D Interleaved Parity Begen, A., "RTP Payload Format for 1-D Interleaved Parity
FEC", draft-ietf-fecframe-interleaved-fec-scheme-09 (work FEC", draft-ietf-fecframe-interleaved-fec-scheme-09 (work
in progress), January 2010. in progress), January 2010.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[I-D.begen-avt-rtcp-port-for-ssm] [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control
Begen, A., "RTP Control Protocol (RTCP) Port for Multicast Protocol (DCCP)", RFC 5762, April 2010.
Sessions", draft-begen-avt-rtcp-port-for-ssm-01 (work in
progress), April 2010.
[I-D.ietf-dccp-rtp] [I-D.ietf-avt-srtp-ekt]
Perkins, C., "RTP and the Datagram Congestion Control McGrew, D., Andreasen, F., Wing, D., and L. Dondeti,
Protocol (DCCP)", draft-ietf-dccp-rtp-07 (work in "Encrypted Key Transport for Secure RTP",
progress), June 2007. draft-ietf-avt-srtp-ekt-00 (work in progress), March 2010.
[UPnP-IGD] [UPnP-IGD]
Forum, UPnP., "Universal Plug and Play (UPnP) Internet Forum, UPnP., "Universal Plug and Play (UPnP) Internet
Gateway Device (IGD)", November 2001. Gateway Device (IGD)", November 2001.
[DLNA] , DLNA., "http://www.dlna.org/home". [DLNA] , DLNA., "http://www.dlna.org/home".
[IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing [IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing
Channel Change Times in IPTV with Real-Time Transport Channel Change Times in IPTV with Real-Time Transport
Protocol (IEEE Internet Computing)", May 2009. Protocol (IEEE Internet Computing)", May 2009.
skipping to change at page 55, line 17 skipping to change at page 51, line 44
Bill VerSteeg Bill VerSteeg
Cisco Cisco
5030 Sugarloaf Parkway 5030 Sugarloaf Parkway
Lawrenceville, GA 30044 Lawrenceville, GA 30044
USA USA
Email: billvs@cisco.com Email: billvs@cisco.com
Ali Begen Ali Begen
Cisco Cisco
170 West Tasman Drive 181 Bay Street
San Jose, CA 95134 Toronto, ON M5J 2T3
USA CANADA
Email: abegen@cisco.com Email: abegen@cisco.com
Tom VanCaenegem Tom VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Copernicuslaan 50 Copernicuslaan 50
Antwerpen, 2018 Antwerpen, 2018
Belgium Belgium
Email: Tom.Van_Caenegem@alcatel-lucent.be Email: Tom.Van_Caenegem@alcatel-lucent.be
Zeev Vax Zeev Vax
Microsoft Corporation Microsoft Corporation
 End of changes. 155 change blocks. 
602 lines changed or deleted 455 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/