draft-ietf-avt-rapid-acquisition-for-rtp-16.txt   draft-ietf-avt-rapid-acquisition-for-rtp-17.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: April 19, 2011 T. VanCaenegem Expires: May 22, 2011 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Z. Vax Z. Vax
Microsoft Corporation Microsoft Corporation
October 16, 2010 November 18, 2010
Unicast-Based Rapid Acquisition of Multicast RTP Sessions Unicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-ietf-avt-rapid-acquisition-for-rtp-16 draft-ietf-avt-rapid-acquisition-for-rtp-17
Abstract Abstract
When an RTP receiver joins a multicast session, it may need to When an RTP receiver joins a multicast session, it may need to
acquire and parse certain Reference Information before it can process acquire and parse certain Reference Information before it can process
any data sent in the multicast session. Depending on the join time, any data sent in the multicast session. Depending on the join time,
length of the Reference Information repetition (or appearance) length of the Reference Information repetition (or appearance)
interval, size of the Reference Information as well as the interval, size of the Reference Information as well as the
application and transport properties, the time lag before an RTP application and transport properties, the time lag before an RTP
receiver can usefully consume the multicast data, which we refer to receiver can usefully consume the multicast data, which we refer to
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 RTP In this document, we describe a method using the existing RTP and RTP
Control Protocol (RTCP) machinery that reduces the acquisition delay. Control Protocol (RTCP) machinery that reduces the acquisition delay.
In this method, an auxiliary unicast RTP session carrying the In this method, an auxiliary unicast RTP session carrying the
Reference Information to the receiver precedes/accompanies the Reference Information to the receiver precedes/accompanies the
multicast stream. This unicast RTP flow can be transmitted at a multicast stream. This unicast RTP flow can be transmitted at a
faster than natural bitrate to further accelerate the acquisition. faster than natural bitrate to further accelerate the acquisition.
The motivating use case for this capability is multicast applications The motivating use case for this capability is multicast applications
that carry real-time compressed audio and video. However, the that carry real-time compressed audio and video. However, this
proposed method can also be used in other types of multicast method can also be used in other types of multicast applications
applications where the acquisition delay is long enough to be a 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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). 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 April 19, 2011. This Internet-Draft will expire on May 22, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Acquisition of RTP Streams vs. RTP Sessions . . . . . . . 6 1.1. Acquisition of RTP Streams vs. RTP Sessions . . . . . . . 7
1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Elements of Delay in Multicast Applications . . . . . . . . . 9 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 . . . . . . . . . . 10 Resource Management for Rapid Acquisition . . . . . . . . . . 10
6. Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . 12 6. Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . 13
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Synchronization of Primary Multicast Streams . . . . . . . 24 6.3. Synchronization of Primary Multicast Streams . . . . . . . 24
6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 24 6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 24
6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27 6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 28 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 28
7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 29 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 30 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 30
7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 30 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 30
7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 31 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 31
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 34 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 34
7.3.1. Response Code Definitions . . . . . . . . . . . . . . 37 7.3.1. Response Code Definitions . . . . . . . . . . . . . . 37
7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 39 7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 38
8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 40 8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 40
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 40 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 40
8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 41 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 40
8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 41 8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 41
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 44 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 44
10. Security Considerations . . . . . . . . . . . . . . . . . . . 45 10. Security Considerations . . . . . . . . . . . . . . . . . . . 45
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 48 11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 48
11.2. Registration of SDP Attribute Values . . . . . . . . . . . 48 11.2. Registration of SDP Attribute Values . . . . . . . . . . . 48
11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 48 11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 48
11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 49 11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 49
11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 49 11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 49
11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 50 11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 50
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 52 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
14.1. Normative References . . . . . . . . . . . . . . . . . . . 52 14.1. Normative References . . . . . . . . . . . . . . . . . . . 53
14.2. Informative References . . . . . . . . . . . . . . . . . . 54 14.2. Informative References . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
Most multicast flows carry a stream of inter-related data. Receivers Most multicast flows carry a stream of inter-related data. Receivers
need to acquire certain information to start processing any data sent need to acquire certain information to start processing any data sent
in the multicast session. This document refers to this information in the multicast session. This document refers to this information
as Reference Information. The Reference Information is as Reference Information. The Reference Information is
conventionally sent periodically in the multicast session (although conventionally sent periodically in the multicast session (although
its content can change over time) and usually consists of items such its content can change over time) and usually consists of items such
as a description of the schema for the rest of the data, references as a description of the schema for the rest of the data, references
skipping to change at page 4, line 41 skipping to change at page 4, line 41
Reference Information to appear again in the flow before it can start Reference Information to appear again in the flow before it can start
processing any multicast data. In some other cases, the Reference processing any multicast data. In some other cases, the Reference
Information is not contiguous in the flow but dispersed over a large Information is not contiguous in the flow but dispersed over a large
period, which forces the receiver to wait for the whole Reference period, which forces the receiver to wait for the whole Reference
Information to arrive before starting to process the rest of the Information to arrive before starting to process the rest of the
data. data.
The net effect of waiting for the Reference Information and waiting The net effect of waiting for the Reference Information and waiting
for various buffers to fill up is that receivers can experience for various buffers to fill up is that receivers can experience
significantly large delays in data processing. In this document, we significantly large delays in data processing. In this document, we
refer to the difference between the time an RTP receiver joins the refer to the difference between the time an RTP receiver wants to
multicast session and the time the RTP receiver acquires all the join the multicast session and the time the RTP receiver acquires all
necessary Reference Information as the Acquisition Delay. The the necessary Reference Information as the Acquisition Delay. The
acquisition delay might not be the same for different receivers; it acquisition delay might not be the same for different receivers; it
usually varies depending on the join time, length of the Reference usually varies depending on the join time, length of the Reference
Information repetition (or appearance) interval, size of the Information repetition (or appearance) interval, size of the
Reference Information as well as the application and transport Reference Information as well as the application and transport
properties. properties.
The varying nature of the acquisition delay adversely affects the The varying nature of the acquisition delay adversely affects the
receivers that frequently switch among multicast sessions. While receivers that frequently switch among multicast sessions. While
this problem equally applies to both any-source (ASM) and source- this problem equally applies to both any-source (ASM) and source-
specific (SSM) multicast applications, in this specification we specific (SSM) multicast applications, in this specification we
skipping to change at page 5, line 20 skipping to change at page 5, line 20
intermediary network element (that we refer to as Retransmission intermediary network element (that we refer to as Retransmission
Server) joins the multicast session and continuously caches the Server) joins the multicast session and continuously caches the
Reference Information as it is sent in the session and acts as a Reference Information as it is sent in the session and acts as a
feedback target (See [RFC5760]) for the session. When an RTP feedback target (See [RFC5760]) for the session. When an RTP
receiver wishes to join the same multicast session, instead of simply receiver wishes to join the same multicast session, instead of simply
issuing a Source Filtering Group Management Protocol (SFGMP) Join issuing a Source Filtering Group Management Protocol (SFGMP) Join
message, it sends a request to the feedback target for the session message, it sends a request to the feedback target for the session
and asks for the Reference Information. The retransmission server and asks for the Reference Information. The retransmission server
starts a new unicast RTP (retransmission) session and sends the starts a new unicast RTP (retransmission) session and sends the
Reference Information to the RTP receiver over that session. If Reference Information to the RTP receiver over that session. If
there is spare bandwidth, the retransmission server might burst the there is residual bandwidth, the retransmission server might burst
Reference Information faster than its natural rate. As soon as the the Reference Information faster than its natural rate. As soon as
receiver acquires the Reference Information, it can join the the receiver acquires the Reference Information, it can join the
multicast session and start processing the multicast data. A multicast session and start processing the multicast data. A
simplified network diagram showing this method through an simplified network diagram showing this method through an
intermediary network element is depicted in Figure 1. 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.
skipping to change at page 6, line 42 skipping to change at page 6, line 42
better interoperability. To this effect, we use the unicast better interoperability. To this effect, we use the unicast
retransmission support of RTP [RFC4588] and the capabilities of RTCP retransmission support of RTP [RFC4588] and the capabilities of RTCP
to handle the signaling needed to accomplish the acquisition. to handle the signaling needed to accomplish the acquisition.
A reasonable effort has been made in this specification to design a A reasonable effort has been made in this specification to design a
solution that reliably works in both engineered and best-effort solution that reliably works in both engineered and best-effort
networks. However, a proper congestion control combined with the networks. However, a proper congestion control combined with the
desired behavior of this solution is difficult to achieve. Rather, desired behavior of this solution is difficult to achieve. Rather,
this solution has been designed based on an assumption that the this solution has been designed based on an assumption that the
retransmission server and the RTP receivers have some knowledge about retransmission server and the RTP receivers have some knowledge about
where the bottleneck between them is. This assumption may not hold where the bottleneck between them is. This assumption does not
unless both the retransmission server and the RTP receiver are in the generally hold unless both the retransmission server and the RTP
same edge network. This solution is not designed to be used across receivers are in the same edge network. Thus, this solution should
any best-effort path of the Internet. Thus, a careful consideration not be used across any best-effort path of the Internet.
should be given when deploying this solution in best-effort networks. Furthermore, this solution should only be used in networks that are
already carrying non-congestion-responsive multicast traffic and have
throttling mechanisms in the retransmission servers to ensure the
(unicast) burst traffic is a known constant upper-bound multiplier on
the multicast load.
1.1. Acquisition of RTP Streams vs. RTP Sessions 1.1. Acquisition of RTP Streams vs. RTP Sessions
In this memo we describe a protocol that handles the rapid In this memo we describe a protocol that handles the rapid
acquisition of a single multicast RTP session (called primary acquisition of a single multicast RTP session (called 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.
skipping to change at page 9, line 18 skipping to change at page 9, line 22
stream will use the same SSRC and Canonical Name (CNAME) as its stream will use the same SSRC and Canonical Name (CNAME) as its
primary multicast RTP stream. primary multicast RTP stream.
Retransmission Server (RS): The RTP/RTCP endpoint that can generate Retransmission Server (RS): The RTP/RTCP endpoint that can generate
the retransmission packets and the burst streams. The RS may also the retransmission packets and the burst streams. The RS may also
generate other non-retransmission packets to aid rapid acquisition. generate other non-retransmission packets to aid rapid acquisition.
4. Elements of Delay in Multicast Applications 4. Elements of Delay in Multicast Applications
In a source-specific (SSM) multicast delivery system, there are three In a source-specific (SSM) multicast delivery system, there are three
major elements that contribute to the overall acquisition delay when major elements that contribute to the acquisition delay when an RTP
an RTP receiver switches from one multicast session to another one. receiver switches from one multicast session to another one. These
These are: are:
o Multicast switching delay o Multicast switching delay
o Reference Information latency o Reference Information latency
o Buffering delays o Buffering delays
Multicast switching delay is the delay that is experienced to leave Multicast switching delay is the delay that is experienced 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
skipping to change at page 10, line 22 skipping to change at page 10, line 26
interdependency. One example of interest is the multicast flows that interdependency. One example of interest is the multicast flows that
carry compressed audio/video. For these flows, the Reference carry compressed audio/video. For these flows, the Reference
Information latency can become quite large and be a major contributor Information latency can become quite large and be a major contributor
to the overall delay. to the overall delay.
The buffering component of the overall acquisition delay is driven by The buffering component of the overall acquisition delay is driven by
the way the application layer processes the payload. In many the way the application layer processes the payload. In many
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., [RFC6015]) and retransmission.
[I-D.ietf-fecframe-interleaved-fec-scheme]) and retransmission.
These loss-repair methods require buffering at the receiver side to These loss-repair methods require buffering at the receiver side to
function properly. In many applications, it is also often necessary function properly. In many applications, it is also often necessary
to de-jitter the incoming data packets before feeding them to the to de-jitter the incoming data packets before feeding them to the
application. The de-jittering process also increases the buffering application. The de-jittering process also increases the buffering
delays. Besides these network-related buffering delays, there are delays. Besides these network-related buffering delays, there are
also specific buffering needs that are required by the individual also specific buffering needs that are required by the individual
applications. For example, standard video decoders typically require applications. For example, standard video decoders typically require
an amount, sometimes up to a few seconds, of coded video data to be an amount, sometimes up to a few seconds, of coded video data to be
available in the pre-decoding buffers prior to starting to decode the available in the pre-decoding buffers prior to starting to decode the
video bitstream. video bitstream.
skipping to change at page 11, line 16 skipping to change at page 11, line 18
user experience must be not significantly worse for trying and user experience must be not significantly worse for trying and
failing to complete rapid acquisition compared to simply joining failing to complete rapid acquisition compared to simply joining
the multicast session. the multicast session.
o Second, providing the rapid acquisition optimizations must not o Second, providing the rapid acquisition optimizations must not
cause collateral damage to either the multicast session being cause collateral damage to either the multicast session being
joined, or other multicast sessions sharing resources with the joined, or other multicast sessions sharing resources with the
rapid acquisition operation. In particular, the rapid acquisition rapid acquisition operation. In particular, the rapid acquisition
operation must avoid interference with the multicast session that operation must avoid interference with the multicast session that
might be simultaneously being received by other hosts. In might be simultaneously being received by other hosts. In
addition, it must also avoid interference with other multicast addition, it must also avoid interference with other multicast and
sessions sharing the same network resources. These properties are non-multicast sessions sharing the same network resources. These
possible, but are usually difficult to achieve. properties are possible, but are usually difficult to achieve.
One challenge is the existence of multiple bandwidth bottlenecks One challenge is the existence of multiple bandwidth bottlenecks
between the receiver and the server(s) in the network providing the between the receiver and the server(s) in the network providing the
rapid acquisition service. In commercial IPTV deployments, for rapid acquisition service. In commercial IPTV deployments, for
example, bottlenecks are often present in the aggregation network example, bottlenecks are often present in the aggregation network
connecting the IPTV servers to the network edge, the access links connecting the IPTV servers to the network edge, the access links
(e.g., DSL, DOCSIS) and in the home network of the subscribers. Some (e.g., DSL, DOCSIS) and in the home network of the subscribers. Some
of these links might 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.
skipping to change at page 24, line 16 skipping to change at page 24, line 16
Since an RTCP BYE message issued for the unicast burst RTP Since an RTCP BYE message issued for the unicast burst RTP
session terminates that session and ceases transmitting any session terminates that session and ceases transmitting any
further packets in that session, there is no need for sending further packets in that session, there is no need for sending
explicit RAMS-T messages, which would only terminate their explicit RAMS-T messages, which would only terminate their
respective bursts. respective bursts.
For the purpose of gathering detailed information about RTP_Rx's For the purpose of gathering detailed information about RTP_Rx's
rapid acquisition experience, [I-D.ietf-avt-multicast-acq-rtcp-xr] rapid acquisition experience, [I-D.ietf-avt-multicast-acq-rtcp-xr]
defines an RTCP Extended Report (XR) Block. This report is designed defines an RTCP Extended Report (XR) Block. This report is designed
to be payload-independent, thus, it can be used by any multicast to be payload-independent, thus, it can be used by any multicast
application that supports rapid acquisition. Support for this XR application that supports rapid acquisition.
report is, however, OPTIONAL.
6.3. Synchronization of Primary Multicast Streams 6.3. Synchronization of Primary Multicast Streams
When an RTP_RX acquires multiple primary multicast streams, it might When an RTP_RX acquires multiple primary multicast streams, it might
need to synchronize them for playout. This synchronization is need to synchronize them for playout. This synchronization is
achieved by the help of the RTCP sender reports [RFC3550]. If the achieved by the help of the RTCP sender reports [RFC3550]. If the
playout will start before the RTP_Rx has joined the multicast playout will start before the RTP_Rx has joined the multicast
session, the RTP_Rx needs to receive the information reflecting the session, the RTP_Rx needs to receive the information reflecting the
synchronization among the primary multicast streams early enough so synchronization among the primary multicast streams early enough so
that it can play out the media in a synchronized fashion. that it can play out the media in a synchronized fashion.
The suggested approach is to use the RTP header extension mechanism The suggested approach is to use the RTP header extension mechanism
[RFC5285] and convey the synchronization information in a header [RFC5285] and convey the synchronization information in a header
extension as defined in [I-D.ietf-avt-rapid-rtp-sync]. Per [RFC4588] extension as defined in [RFC6051]. Per [RFC4588] "if the original
"if the original RTP header carried an RTP header extension, the RTP header carried an RTP header extension, the retransmission packet
retransmission packet SHOULD carry the same header extension." Thus, SHOULD carry the same header extension." Thus, as long as the
as long as the multicast source emits a header extension with the multicast source emits a header extension with the synchronization
synchronization information frequently enough, there is no additional information frequently enough, there is no additional task that needs
task that needs to be carried out by the BRS. The synchronization to be carried out by the BRS. The synchronization information will
information will be sent to the RTP_Rx along with the burst packets. be sent to the RTP_Rx along with the burst packets. The frequent
The frequent header extensions sent in the primary multicast RTP header extensions sent in the primary multicast RTP sessions also
sessions also allow rapid synchronization of the RTP streams for the allow rapid synchronization of the RTP streams for the RTP receivers
RTP receivers that do not support RAMS or that directly join the that do not support RAMS or that directly join the multicast session
multicast session without running RAMS. Thus, in RAMS applications, without running RAMS. Thus, in RAMS applications, it is RECOMMENDED
it is RECOMMENDED that the multicast sources frequently send that the multicast sources frequently send synchronization
synchronization information by using header extensions following the information by using header extensions following the rules presented
rules presented in [I-D.ietf-avt-rapid-rtp-sync]. The regular sender in [RFC6051]. The regular sender reports are still sent in the
reports are still sent in the unicast session by following the rules unicast session by following the rules of [RFC3550].
of [RFC3550].
6.4. Burst Shaping and Congestion Control in RAMS 6.4. Burst Shaping and Congestion Control in RAMS
This section provides informative guidelines about how the BRS can This section provides informative guidelines about how the BRS can
shape the transmission of the unicast burst and how congestion can be shape the transmission of the unicast burst and how congestion can be
dealt within the RAMS process. When the RTP_Rx detects that the dealt within the RAMS process. When the RTP_Rx detects that the
unicast burst is causing severe congestion, it can prefer to send a unicast burst is causing severe congestion, it can prefer to send a
RAMS-T message immediately to stop the unicast burst. RAMS-T message immediately to stop the unicast burst.
A higher bitrate for the unicast burst naturally conveys the A higher bitrate for the unicast burst naturally conveys the
skipping to change at page 35, line 17 skipping to change at page 34, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=2 | MSN | Response | | SFMT=2 | MSN | Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) : : Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: FCI field syntax for the RAMS Information message Figure 8: FCI field syntax for the RAMS Information message
A RAMS-I message has the following fields: A RAMS-I message has the following fields:
o Message Sequence Number (8 bits) : Mandatory field that denotes o Message Sequence Number (MSN) (8 bits) : Mandatory field that
the sequence number of the RAMS-I message for the particular media denotes the sequence number of the RAMS-I message for the
sender SSRC specified in the message header. The MSN value SHALL particular media sender SSRC specified in the message header. The
be set to zero only when a new RAMS request is received. During MSN value SHALL be set to zero when a new RAMS request is
rapid acquisition, the same RAMS-I message MAY be repeated for received. During rapid acquisition, the same RAMS-I message MAY
redundancy purposes without incrementing the MSN value. If an be repeated for redundancy purposes without incrementing the MSN
updated RAMS-I message will be sent (either with a new information value. If an updated RAMS-I message will be sent (either with a
or an updated information), the MSN value SHALL be incremented by new information or an updated information), the MSN value SHALL be
one. In the MSN field, the regular wrapping rules apply. Note incremented by one. In the MSN field, the regular wrapping rules
that if the RTP_Rx has sent an updated request, it MUST check apply. Note that if the RTP_Rx has sent an updated request, it
every RAMS-I message entirely regardless of whether the MSN value MUST check every RAMS-I message entirely regardless of whether the
has changed or not. MSN value has changed or not.
o Response (16 bits): Mandatory field that denotes the response o Response (16 bits): Mandatory field that denotes the response
code for this RAMS-I message. This document defines several code for this RAMS-I message. This document defines several
initial response codes in Section 7.3.1 and registers them with initial response codes in Section 7.3.1 and registers them with
IANA in Section 11.6. If a new vendor-neutral response code will IANA in Section 11.6. If a new vendor-neutral response code will
be defined, it MUST be registered with IANA through the guidelines be defined, it MUST be registered with IANA through the guidelines
specified in Section 11.6. If the new response code is intended specified in Section 11.6. If the new response code is intended
to be used privately by a vendor, there is no need for IANA to be used privately by a vendor, there is no need for IANA
management. Instead, the vendor MUST use the private extension management. Instead, the vendor MUST use the private extension
mechanism (Section 7.1.2) to convey its message and MUST indicate mechanism (Section 7.1.2) to convey its message and MUST indicate
skipping to change at page 41, line 26 skipping to change at page 41, line 5
o The SDP grouping framework and flow identification (FID) semantics o The SDP grouping framework and flow identification (FID) semantics
[RFC5888] [RFC5888]
o The RTP/AVPF profile [RFC4585] o The RTP/AVPF profile [RFC4585]
o The RTP retransmission payload format [RFC4588] o The RTP retransmission payload format [RFC4588]
o The RTCP extensions for SSM sessions with unicast feedback o The RTCP extensions for SSM sessions with unicast feedback
[RFC5760] [RFC5760]
o The multicast RTCP port attribute [I-D.ietf-avt-rtcp-port-for-ssm] o The 'multicast-rtcp' attribute [I-D.ietf-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[RFC5761] the unicast session [RFC5761]
o The 'portmapping-req' attribute
[I-D.ietf-avt-ports-for-ucast-mcast-rtp]
The support for the source-specific media attributes [RFC5576] can The support for the source-specific media attributes [RFC5576] can
also be needed when the 'ssrc' attribute is to be used for the media also be needed when the 'ssrc' attribute is to be used for the media
descriptions. descriptions.
8.3. Example and Discussion 8.3. Example and Discussion
This section provides a declarative SDP [RFC4566] example (for the This section provides a declarative SDP [RFC4566] example (for the
RTP_Rx side) for enabling rapid acquisition of multicast RTP RTP_Rx side) for enabling rapid acquisition of multicast RTP
sessions. sessions.
skipping to change at page 42, line 29 skipping to change at page 42, line 29
a=rtcp-fb:98 nack rai a=rtcp-fb:98 nack rai
a=ssrc:123321 cname:iptv-ch32@rams.example.com a=ssrc:123321 cname:iptv-ch32@rams.example.com
a=rams-updates a=rams-updates
a=mid:1 a=mid:1
m=video 51000 RTP/AVPF 99 m=video 51000 RTP/AVPF 99
i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support) i=Unicast Retransmission Stream (Ret. and Rapid Acq. Support)
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=sendonly a=sendonly
a=rtpmap:99 rtx/90000 a=rtpmap:99 rtx/90000
a=rtcp-mux a=rtcp-mux
a=rtcp:51500
a=fmtp:99 apt=98;rtx-time=5000 a=fmtp:99 apt=98;rtx-time=5000
a=portmapping-req:55000
a=mid:2 a=mid:2
Figure 10: Example SDP for a single-channel RAMS scenario Figure 10: Example SDP for a single-channel RAMS scenario
In this example SDP description, we have a primary multicast (source) In this example SDP description, we have a primary multicast (source)
stream and a unicast retransmission stream. The source stream is stream and a unicast retransmission stream. The source stream is
multicast from a distribution source (with a source IP address of multicast from a distribution source (with a source IP address of
198.51.100.1) to the multicast destination address of 233.252.0.2 and 198.51.100.1) to the multicast destination address of 233.252.0.2 and
port 41000. The corresponding RTCP traffic is multicast to the same port 41000. The corresponding RTCP traffic is multicast to the same
multicast destination address at port 42000. Here, we are assuming multicast destination address at port 42000. Here, we are assuming
skipping to change at page 44, line 44 skipping to change at page 44, line 46
received by the FT, a new unicast burst RTP session will be received by the FT, a new unicast burst RTP session will be
established between the BRS and RTP_Rx. established between the BRS and RTP_Rx.
While the FT and BRS ports on the RS are already signaled via out-of- While the FT and BRS ports on the RS are already signaled via out-of-
band means (e.g., SDP), the RTP_Rx needs to convey the RTP and RTCP band means (e.g., SDP), the RTP_Rx needs to convey the RTP and RTCP
ports it wants to use on its side for the new session. Since there ports it wants to use on its side for the new session. Since there
are two RTP sessions (one multicast and one unicast) involved during are two RTP sessions (one multicast and one unicast) involved during
this process and one of them is established upon a feedback message this process and one of them is established upon a feedback message
sent in the other one, this requires an explicit port mapping method. sent in the other one, this requires an explicit port mapping method.
Applications using RAMS MUST support the solution presented in Applications using RAMS MUST support the method presented in
[I-D.ietf-avt-ports-for-ucast-mcast-rtp] both on the RS and RTP_Rx [I-D.ietf-avt-ports-for-ucast-mcast-rtp] both on the RS and RTP_Rx
side to allow RTP receivers to use their desired ports and to support side to allow RTP receivers to use their desired ports and to support
RAMS behind NAT devices. The port mapping message exchange needs to RAMS behind NAT devices. The port mapping message exchange needs to
take place whenever the RTP_Rx intends to make use of the RAMS take place whenever the RTP_Rx intends to make use of the RAMS
protocol for rapidly acquiring a specific multicast RTP session, protocol for rapidly acquiring a specific multicast RTP session,
prior to joining the associated SSM session. prior to joining the associated SSM session.
10. Security Considerations 10. Security Considerations
Applications that are using RAMS make heavy use of the unicast Applications that are using RAMS make heavy use of the unicast
skipping to change at page 53, line 47 skipping to change at page 54, line 34
[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.ietf-avt-rapid-rtp-sync] [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Flows", RFC 6051, November 2010.
Flows", draft-ietf-avt-rapid-rtp-sync-12 (work in
progress), July 2010.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[I-D.ietf-avt-rtcp-port-for-ssm] [I-D.ietf-avt-rtcp-port-for-ssm]
Begen, A., "RTP Control Protocol (RTCP) Port for Source- Begen, A., "RTP Control Protocol (RTCP) Port for Source-
Specific Multicast (SSM) Sessions", Specific Multicast (SSM) Sessions",
draft-ietf-avt-rtcp-port-for-ssm-02 (work in progress), draft-ietf-avt-rtcp-port-for-ssm-03 (work in progress),
August 2010. October 2010.
[I-D.ietf-avt-ports-for-ucast-mcast-rtp] [I-D.ietf-avt-ports-for-ucast-mcast-rtp]
Begen, A. and B. Steeg, "Port Mapping Between Unicast and Begen, A. and B. Steeg, "Port Mapping Between Unicast and
Multicast RTP Sessions", Multicast RTP Sessions",
draft-ietf-avt-ports-for-ucast-mcast-rtp-02 (work in draft-ietf-avt-ports-for-ucast-mcast-rtp-02 (work in
progress), May 2010. progress), May 2010.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
skipping to change at page 54, line 47 skipping to change at page 55, line 34
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-rtp-cnames] [I-D.ietf-avt-rtp-cnames]
Begen, A., Perkins, C., and D. Wing, "Guidelines for Begen, A., Perkins, C., and D. Wing, "Guidelines for
Choosing RTP Control Protocol (RTCP) Canonical Names Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs)", draft-ietf-avt-rtp-cnames-01 (work in (CNAMEs)", draft-ietf-avt-rtp-cnames-02 (work in
progress), August 2010. progress), November 2010.
[I-D.ietf-avt-multicast-acq-rtcp-xr] [I-D.ietf-avt-multicast-acq-rtcp-xr]
Begen, A. and E. Friedrich, "Multicast Acquisition Report Begen, A. and E. Friedrich, "Multicast Acquisition Report
Block Type for RTP Control Protocol (RTCP) Extended Block Type for RTP Control Protocol (RTCP) Extended
Reports (XRs)", draft-ietf-avt-multicast-acq-rtcp-xr-01 Reports (XRs)", draft-ietf-avt-multicast-acq-rtcp-xr-01
(work in progress), May 2010. (work in progress), May 2010.
[I-D.ietf-avt-ecn-for-rtp] [I-D.ietf-avt-ecn-for-rtp]
Westerlund, M., Johansson, I., Perkins, C., and K. Westerlund, M., Johansson, I., Perkins, C., and K.
Carlberg, "Explicit Congestion Notification (ECN) for RTP Carlberg, "Explicit Congestion Notification (ECN) for RTP
over UDP", draft-ietf-avt-ecn-for-rtp-02 (work in over UDP", draft-ietf-avt-ecn-for-rtp-03 (work in
progress), July 2010. progress), October 2010.
[I-D.ietf-fecframe-interleaved-fec-scheme] [RFC6015] Begen, A., "RTP Payload Format for 1-D Interleaved Parity
Begen, A., "RTP Payload Format for 1-D Interleaved Parity Forward Error Correction (FEC)", RFC 6015, October 2010.
FEC", draft-ietf-fecframe-interleaved-fec-scheme-09 (work
in progress), January 2010.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC5762] Perkins, C., "RTP and the Datagram Congestion Control [RFC5762] Perkins, C., "RTP and the Datagram Congestion Control
Protocol (DCCP)", RFC 5762, April 2010. Protocol (DCCP)", RFC 5762, April 2010.
[I-D.ietf-avt-srtp-ekt] [I-D.ietf-avt-srtp-ekt]
McGrew, D., Andreasen, F., Wing, D., and K. Fischer, McGrew, D., Andreasen, F., Wing, D., and K. Fischer,
 End of changes. 30 change blocks. 
85 lines changed or deleted 86 lines changed or added

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