draft-ietf-avt-rapid-acquisition-for-rtp-01.txt   draft-ietf-avt-rapid-acquisition-for-rtp-02.txt 
AVT B. VerSteeg AVT B. VerSteeg
Internet-Draft A. Begen Internet-Draft A. Begen
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: December 18, 2009 T. VanCaenegem Expires: February 26, 2010 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Z. Vax Z. Vax
Microsoft Corporation Microsoft Corporation
June 16, 2009 August 25, 2009
Unicast-Based Rapid Acquisition of Multicast RTP Sessions Unicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-ietf-avt-rapid-acquisition-for-rtp-01 draft-ietf-avt-rapid-acquisition-for-rtp-02
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 46 skipping to change at page 1, line 46
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 18, 2009. This Internet-Draft will expire on February 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
skipping to change at page 3, line 17 skipping to change at page 3, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Elements of Delay in Multicast Applications . . . . . . . . . 7 4. Elements of Delay in Multicast Applications . . . . . . . . . 7
5. Protocol Design Considerations and Their Effect on 5. Protocol Design Considerations and Their Effect on
Resource Management for Rapid Acquisition . . . . . . . . . . 9 Resource Management for Rapid Acquisition . . . . . . . . . . 9
6. Rapid Acquisition of Multicast RTP Sessions . . . . . . . . . 11 6. Rapid Acquisition of Multicast RTP Sessions . . . . . . . . . 11
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Shaping the Unicast Burst . . . . . . . . . . . . . . . . 20 6.3. Shaping the Unicast Burst . . . . . . . . . . . . . . . . 20
6.4. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 20 6.4. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 22
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 21 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 23
7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 22 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 24
7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 22 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 24
7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 23 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 25
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 24 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 27
7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 27 7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 29
8. SDP Definitions and Examples . . . . . . . . . . . . . . . . . 28 8. SDP Definitions and Examples . . . . . . . . . . . . . . . . . 30
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 30
8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 30
9. Signaling Ports via Publish Ports (PubPorts) RTCP Message . . 31 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 33
10. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 32 10. Known Implementations . . . . . . . . . . . . . . . . . . . . 34
11. Known Implementations . . . . . . . . . . . . . . . . . . . . 33 10.1. Open Source RTP Receiver Implementation by Cisco . . . . . 34
11.1. Open Source RTP Receiver Implementation by Cisco . . . . . 33 10.2. IPTV Commercial Implementation by Microsoft . . . . . . . 35
11.2. IPTV Commercial Implementation by Microsoft . . . . . . . 34 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35
12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 34 12. Security Considerations . . . . . . . . . . . . . . . . . . . 35
13. Security Considerations . . . . . . . . . . . . . . . . . . . 34 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 13.1. Registration of SDP Attributes . . . . . . . . . . . . . . 37
14.1. Registration of SDP Attribute Values . . . . . . . . . . . 34 13.2. Registration of SDP Attribute Values . . . . . . . . . . . 37
14.2. Registration of FMT Values . . . . . . . . . . . . . . . . 35 13.3. Registration of FMT Values . . . . . . . . . . . . . . . . 37
14.3. SFMT Values for RAMS Messages Registry . . . . . . . . . . 35 13.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 38
14.4. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 36 13.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 38
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
16. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 37 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 39
16.1. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 37 15.1. draft-ietf-avt-rapid-acquisition-for-rtp-02 . . . . . . . 39
16.2. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 37 15.2. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 40
16.3. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 37 15.3. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 40
16.4. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 37 15.4. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 40
16.5. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 38 15.5. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 40
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 15.6. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 41
17.1. Normative References . . . . . . . . . . . . . . . . . . . 38 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
17.2. Informative References . . . . . . . . . . . . . . . . . . 40 16.1. Normative References . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 16.2. Informative References . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
Most multicast flows carry a stream of inter-related data. Certain Most multicast flows carry a stream of inter-related data. Certain
information must first be acquired by the receivers to start information must first be acquired by the receivers to start
processing any data sent in the multicast session. This document processing any data sent in the multicast session. This document
refers to this information as Reference Information. The Reference refers to this information as Reference Information. The Reference
Information is conventionally sent periodically in the multicast Information is conventionally sent periodically in the multicast
session and usually consists of items such as a description of the session and usually consists of items such as a description of the
schema for the rest of the data, references to which data to process, schema for the rest of the data, references to which data to process,
skipping to change at page 5, line 7 skipping to change at page 5, line 7
well as the application and transport properties. well as the application and transport properties.
The varying nature of the acquisition delay adversely affects the The varying nature of the acquisition delay adversely affects the
receivers that frequently switch among multicast sessions. In this receivers that frequently switch among multicast sessions. In this
specification, we address this problem for RTP-based multicast specification, we address this problem for RTP-based multicast
applications and describe a method that uses the fundamental tools applications and describe a method that uses the fundamental tools
offered by the existing RTP and RTCP protocols [RFC3550]. In this offered by the existing RTP and RTCP protocols [RFC3550]. In this
method, either the multicast source (or the distribution source in a method, either the multicast source (or the distribution source in a
single-source multicast (SSM) session) retains the Reference single-source multicast (SSM) session) retains the Reference
Information for a period after its transmission, or an intermediary Information for a period after its transmission, or an intermediary
network element joins the multicast session and continuously caches network element (that we refer to as Retransmission Server) joins the
the Reference Information as it is sent in the session and acts as a multicast session and continuously caches the Reference Information
feedback target (See [I-D.ietf-avt-rtcpssm]) for the session. When as it is sent in the session and acts as a feedback target (See
an RTP receiver wishes to join the same multicast session, instead of [I-D.ietf-avt-rtcpssm]) for the session. When an RTP receiver wishes
simply issuing a Source Filtering Group Management Protocol (SFGMP) to join the same multicast session, instead of simply issuing a
Join message, it sends a request to the feedback target for the Source Filtering Group Management Protocol (SFGMP) Join message, it
session asking for the Reference Information. The feedback target sends a request to the feedback target for the session asking for the
starts a unicast retransmission RTP session and sends the Reference Reference Information. The Retransmission Server starts a unicast
Information to the RTP receiver over that session. If there is spare retransmission RTP session and sends the Reference Information to the
bandwidth, the feedback target may also burst the Reference RTP receiver over that session. If there is spare bandwidth, the
Information at a faster than its natural rate. As soon as the Retransmission Server may also burst the Reference Information at a
receiver acquires the Reference Information, it can join the faster than its natural rate. As soon as the receiver acquires the
multicast session and start processing the multicast data. This Reference Information, it can join the multicast session and start
method potentially reduces the acquisition delay. We refer to this processing the multicast data. This method potentially reduces the
method as Unicast-based Rapid Acquisition of Multicast RTP Sessions. acquisition delay. We refer to this method as Unicast-based Rapid
A simplified network diagram showing this method through an Acquisition of Multicast RTP Sessions. A simplified network diagram
intermediary network element is depicted in Figure 1. showing this method through an intermediary network element is
depicted in Figure 1.
+-------------------+ +-----------------------+
+--->| Intermediary | +--->| Intermediary |
| ...| Network Element | | ...| Network Element |
| : +-------------------+ | : |(Retransmission Server)|
| : +-----------------------+
| : | :
| v | v
+-----------+ +----------+ +----------+ +-----------+ +----------+ +----------+
| Multicast | | Router |---------->| Joining | | Multicast | | Router |---------->| Joining |
| Source |------->| |..........>| RTP | | Source |------->| |..........>| RTP |
+-----------+ +----------+ | Receiver | +-----------+ +----------+ | Receiver |
| +----------+ | +----------+
| |
| +----------+ | +----------+
+---------------->| Existing | +---------------->| Existing |
skipping to change at page 6, line 7 skipping to change at page 6, line 9
---> Multicast RTP Flow ---> Multicast RTP Flow
Figure 1: Rapid acquisition through an intermediary network element Figure 1: Rapid acquisition through an intermediary network element
A primary design goal in this solution is to use the existing tools A primary design goal in this solution is to use the existing tools
in the RTP/RTCP protocol family. This improves the versatility of in the RTP/RTCP protocol family. This improves the versatility of
the existing implementations, and promotes faster deployment and the existing implementations, and promotes faster deployment and
better interoperability. To this effect, we use the unicast better interoperability. To this effect, we use the unicast
retransmission support of RTP [RFC4588] and the capabilities of RTCP retransmission support of RTP [RFC4588] and the capabilities of RTCP
to handle the signaling needed to accomplish the acquisition. The to handle the signaling needed to accomplish the acquisition. The
packet(s) carrying the Reference Information are sent by the feedback packet(s) carrying the Reference Information are sent by the
target in the auxiliary unicast RTP session for rapid acquisition. Retransmission Server in the auxiliary unicast RTP session for rapid
These are constructed as retransmission packets that would have been acquisition. These are constructed as retransmission packets that
sent in a unicast RTP session to recover the missing packets at an would have been sent in a unicast RTP session to recover the missing
RTP receiver that has never received any packet. In fact, a single packets at an RTP receiver that has never received any packet. In
RTP session SHOULD be used for both rapid acquisition and fact, a single RTP session SHOULD be used for both rapid acquisition
retransmission-based loss repair. This session can be used to and retransmission-based loss repair. This session can be used to
simultaneously provide the unicast burst for the rapid acquisition simultaneously provide the unicast burst for the rapid acquisition
and the repair packets requested by the RTP receivers when they and the repair packets requested by the RTP receivers when they
detect lost burst packets or lost RTP packets in the primary detect lost burst packets or lost RTP packets in the primary
multicast stream. The conventional RTCP feedback (NACK) message that multicast stream. The conventional RTCP feedback (NACK) message that
requests the retransmission of the missing packets [RFC4585] requests the retransmission of the missing packets [RFC4585]
indicates their sequence numbers. However, upon joining a new indicates their sequence numbers. However, upon joining a new
session the RTP receiver has never received a packet, and thus, does session the RTP receiver has never received a packet, and thus, does
not know the sequence numbers. Instead, the RTP receiver sends a not know the sequence numbers. Instead, the RTP receiver sends a
newly defined RTCP feedback message to request the Reference newly defined RTCP feedback message to request the Reference
Information needed to rapidly get on the track with the primary Information needed to rapidly get on the track with the primary
skipping to change at page 6, line 38 skipping to change at page 6, line 40
the RTP receiver in advance of the initiation of the rapid the RTP receiver in advance of the initiation of the rapid
acquisition operation). In a Session Description Protocol (SDP) acquisition operation). In a Session Description Protocol (SDP)
description, the SSRC MUST be signaled through the 'ssrc' attribute description, the SSRC MUST be signaled through the 'ssrc' attribute
[I-D.ietf-avt-rtcpssm]. [I-D.ietf-avt-rtcpssm].
In the rest of this specification, we have the following outline: In In the rest of this specification, we have the following outline: In
Section 4, we describe the delay components in generic multicast Section 4, we describe the delay components in generic multicast
applications. Section 5 presents an overview of the protocol design applications. Section 5 presents an overview of the protocol design
considerations for rapid acquisition. We provide the protocol considerations for rapid acquisition. We provide the protocol
details of the rapid acquisition method in Section 6 and Section 7. details of the rapid acquisition method in Section 6 and Section 7.
Section 8, Section 9 and Section 10 discuss the SDP signaling issues Section 8 and Section 9 discuss the SDP signaling issues with
with examples, an RTCP port signaling method and NAT-related issues, examples and NAT-related issues, respectively.
respectively.
Note that Section 3 provides a list of the definitions frequently Note that Section 3 provides a list of the definitions frequently
used in this document. used in this document.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 12, line 32 skipping to change at page 12, line 32
that can be leveraged during the acquisition process. that can be leveraged during the acquisition process.
6.2. Message Flows 6.2. Message Flows
Figure 2 shows the main entities involved in rapid acquisition: Figure 2 shows the main entities involved in rapid acquisition:
o Multicast Source o Multicast Source
o Feedback Target (FT) o Feedback Target (FT)
o Burst Source o Burst/Retransmission Source
o Retransmission Source
o RTP Receiver (RR) o RTP Receiver (RR)
+----------------------------------------------+ +----------------------------------------------+
| Retransmission Server | | Retransmission Server |
| (RS) | | (RS) |
| +----------+ +--------+ +----------------+ | | +----------+ +---------------------------+ |
| | Feedback | | Burst | | Retransmission | | | | Feedback | | Burst/Retransmission | |
| | Target | | Source | | Source | | | | Target | | Source | |
| +----------+ +--------+ +----------------+ | | +----------+ +---------------------------+ |
+----------------------------------------------+ +----------------------------------------------+
^ ^ : ^ ^ :
| ' : | ' :
| ' : | ' :
| ' v | ' v
+-----------+ +----------+ +----------+ +-----------+ +----------+ +----------+
| | | |'''''''''''>| | | | | |'''''''''''>| |
| Multicast |------->| Router |...........>| RTP | | Multicast |------->| Router |...........>| RTP |
| Source | | |<~~~~~~~~~~~| Receiver | | Source | | |<~~~~~~~~~~~| Receiver |
| | | |----------->| (RR) | | | | |----------->| (RR) |
+-----------+ +----------+ +----------+ +-----------+ +----------+ +----------+
'''> Unicast RTCP Messages '''> Unicast RTCP Messages
~~~> SFGMP Messages ~~~> SFGMP Messages
...> Unicast RTP Flow ...> Unicast RTP Flow
---> Multicast RTP Flow ---> Multicast RTP Flow
Figure 2: Flow diagram for unicast-based rapid acquisition Figure 2: Flow diagram for unicast-based rapid acquisition
A Retransmission Source may equally act as a Burst Source. The The feedback target (FT) is the entity as defined in
Retransmission Source may also incorporate the Feedback Target [I-D.ietf-avt-rtcpssm], to which RR sends its RTCP feedback messages
([I-D.ietf-avt-rtcpssm] permits the feedback target to be a indicating packet loss in the primary multicast stream by means of an
retransmission server, since it is a logical function to which RRs RTCP NACK message or indicating RR's desire to rapidly acquire the
send their unicast feedback), and we will use the term Retransmission primary multicast stream by means of an RTCP feedback message defined
Server (RS) in the remainder of the document to refer to a single in this document. While the Burst/Retransmission Source is
physical entity comprising these three entities that share state. responsible for responding to these messages and for further RTCP
Note that the same method (with the identical message flows) would interaction with RR in the case of a rapid acquisition process, it is
also apply in a scenario where rapid acquisition is performed by a assumed in the remainder of the document that these two logical
feedback target co-located with the media source. entities (FT and Burst/Retransmission Source) are combined in a
single physical entity and they share state. In the remainder of the
text, the term Retransmission Server will be used whenever
appropriate, to refer to the combined functionality of the FT and
Burst/Retransmission Source.
As the unicast burst packets are formatted as RTP retransmission However, it must be noted that only FT is involved in the primary
packets [RFC4585], the unicast burst and RTP retransmissions are sent multicast session, whereas the Burst/Retransmission Source transmits
over the same RTP (retransmission) session. the unicast burst and retransmission packets both formatted as RTP
retransmission packets [RFC4588] in a single separate unicast RTP
retransmission session to each RR. In the retransmission session, as
in any other RTP session, RS and RR regularly send the periodic
sender and receiver reports, respectively.
The unicast burst is triggered by an RTCP feedback message defined in Note also that the same method (with the identical message flows)
this document, whereas an RTP retransmission is triggered by an RTCP would also apply in a scenario where rapid acquisition is performed
NACK message defined in [RFC4585]. Based on its design, in an RAMS by a feedback target co-located with the media source.
implementation, there may be a gap between the end of the burst and
the reception of the primary multicast stream because of the The unicast burst is triggered by an RTCP feedback message that is
imperfections in the switch-over. If needed, RR may make use of the defined in this document, whereas an RTP retransmission is triggered
RTCP NACK message to request a retransmission for the missing packets by an RTCP NACK message defined in [RFC4585]. Based on its design,
in the gap. in an RAMS implementation, there may be a gap between the end of the
burst and the reception of the primary multicast stream because of
the imperfections in the switch-over. If needed, RR may make use of
the RTCP NACK message to request a retransmission for the missing
packets in the gap.
Figure 3 depicts an example of messaging flow for rapid acquisition. Figure 3 depicts an example of messaging flow for rapid acquisition.
The RTCP feedback messages are explained below. Note that the The RTCP feedback messages are explained below. Note that the
messages indicated in parentheses may or may not be present during messages indicated in parentheses may or may not be present during
rapid acquisition. rapid acquisition.
+-----------+ +----------------+ +----------+ +------------+ +-----------+ +----------------+ +----------+ +------------+
| Multicast | | Retransmission | | | | RTP | | Multicast | | Retransmission | | | | RTP |
| Source | | Server | | Router | | Receiver | | Source | | Server | | Router | | Receiver |
| | | (RS) | | | | (RR) | | | | (RS) | | | | (RR) |
skipping to change at page 16, line 39 skipping to change at page 16, line 39
server) by out-of-band means. Also note that since no RTP server) by out-of-band means. Also note that since no RTP
packets have been received yet for this session, the SSRC must be packets have been received yet for this session, the SSRC must be
obtained out-of-band. See Section 8 for details. obtained out-of-band. See Section 8 for details.
2. Response: RS receives the RAMS-R message and decides whether to 2. Response: RS receives the RAMS-R message and decides whether to
accept it or not. RS MUST send an (at least one) RAMS- accept it or not. RS MUST send an (at least one) RAMS-
Information (RAMS-I) message to RR. The first RAMS-I message MAY Information (RAMS-I) message to RR. The first RAMS-I message MAY
precede the unicast burst or it MAY be sent during the burst. precede the unicast burst or it MAY be sent during the burst.
Additional RAMS-I messages MAY be sent during the burst and these Additional RAMS-I messages MAY be sent during the burst and these
RAMS-I messages may or may not be a direct response to an RAMS-R RAMS-I messages may or may not be a direct response to an RAMS-R
message. message. The RAMS-I message is sent by the Burst/Retransmission
Source logical entity that is part of RS.
Note that RS learns the IP address information for RR from the Note that RS learns the IP address information for RR from the
RAMS-R message it received. (This description glosses over the RAMS-R message it received. (This description glosses over the
NAT details. Refer to Section 10 for a discussion of NAT-related NAT details. Refer to Section 9 for a discussion of NAT-related
issues.) issues.)
If RS cannot provide a rapid acquisition service, RS rejects the If RS cannot provide a rapid acquisition service, RS rejects the
request and informs RR immediately via an RAMS-I message. If RR request and informs RR immediately via an RAMS-I message. If RR
receives a message indicating that its rapid acquisition request receives a message indicating that its rapid acquisition request
has been denied, it abandons the rapid acquisition attempt and has been denied, it abandons the rapid acquisition attempt and
MAY immediately join the multicast session by sending an SFGMP MAY immediately join the multicast session by sending an SFGMP
Join message towards its upstream multicast router for the new Join message towards its upstream multicast router for the new
primary multicast session. primary multicast session.
If RS accepts the request, it sends an RAMS-I message to RR If RS accepts the request, it sends an RAMS-I message to RR
(before commencing the unicast burst or during the unicast burst) (before commencing the unicast burst or during the unicast burst)
that comprises fields that can be used to describe the unicast that comprises fields that can be used to describe the unicast
burst (e.g., the maximum bitrate and the duration of the unicast burst (e.g., the maximum bitrate and the duration of the unicast
burst). burst). A particularly important, thus mandatory, field in the
RAMS-I message carries the RTP sequence number of the first burst
packet.
It is RECOMMENDED to include a sender report with the RAMS-I
message in the same compound RTCP packet. This also allows rapid
synchronization among multiple RTP flows
[I-D.ietf-avt-rapid-rtp-sync].
The unicast burst duration MAY be calculated by RS, and its value The unicast burst duration MAY be calculated by RS, and its value
MAY be updated by messages received from RR. The join time MAY be updated by messages received from RR. The join time
information (for the new multicast session) MUST be populated in information (for the new multicast session) SHOULD be populated
at least one of the RAMS-I messages. Note that RS MAY send the in at least one of the RAMS-I messages. Note that RS MAY send
RAMS-I message after a significant delay, so RR SHOULD NOT make the RAMS-I message after a significant delay, so RR SHOULD NOT
protocol dependencies on quickly receiving an RAMS-I message. make protocol dependencies on quickly receiving an RAMS-I
message.
3. Unicast Burst: If the request is accepted, RS starts sending the 3. Unicast Burst: If the request is accepted, RS starts sending the
unicast burst that comprises one or more RTP retransmission unicast burst that comprises one or more RTP retransmission
packets. In addition, there MAY be optional payload-specific packets (The burst packet(s) are sent by the Burst/Retransmission
information that RS chooses to send to RR. Such an example is Source logical entity). In addition, there MAY be optional
discussed in [I-D.begen-avt-rtp-mpeg2ts-preamble] for payload-specific information that RS chooses to send to RR. Such
transmitting the payload-specific information for MPEG2 Transport an example is discussed in [I-D.begen-avt-rtp-mpeg2ts-preamble]
Streams. for transmitting the payload-specific information for MPEG2
Transport Streams.
4. Updated Request: RR MAY send a new RAMS-R message with a 4. Updated Request: RR MAY send a new RAMS-R message (to the FT
different value for one or more fields of an earlier RAMS-R entity of RS) with a different value for one or more fields of an
message. Upon receiving an updated request, RS MAY use the earlier RAMS-R message. Upon receiving an updated request, RS
updated values for sending/shaping the burst, or refine the MAY use the updated values for sending/shaping the burst, or
values and use the refined values for sending/shaping the burst. refine the values and use the refined values for sending/shaping
the burst.
RS MAY send a new RAMS-I message to indicate the changes it made. RS MAY send a new RAMS-I message to indicate the changes it made.
However, note that RS does not have to send a new RAMS-I, or the However, note that RS does not have to send a new RAMS-I, or the
new RAMS-I message may get lost. It is also possible that the new RAMS-I message may get lost. It is also possible that the
updated RAMS-R message could have been lost. Thus, RR SHOULD NOT updated RAMS-R message could have been lost. Thus, RR SHOULD NOT
make protocol dependencies on quickly (or ever) receiving a new make protocol dependencies on quickly (or ever) receiving a new
RAMS-I message, or assume that RS will honor the requested RAMS-I message, or assume that RS will honor the requested
changes. changes.
RR may be in an environment where the available resources are RR may be in an environment where the available resources are
skipping to change at page 19, line 11 skipping to change at page 19, line 22
latter case, RR SHALL include the sequence number of the first latter case, RR SHALL include the sequence number of the first
RTP packet received in the primary multicast session in the RTP packet received in the primary multicast session in the
RAMS-T message, and RS SHOULD terminate the burst after it sends RAMS-T message, and RS SHOULD terminate the burst after it sends
the unicast burst packet whose Original Sequence Number (OSN) the unicast burst packet whose Original Sequence Number (OSN)
field in the RTP retransmission payload header matches this field in the RTP retransmission payload header matches this
number minus one. number minus one.
If RR wants to stop the burst prior to receiving the multicast If RR wants to stop the burst prior to receiving the multicast
data, it sends an RAMS-T message without an RTP sequence number. data, it sends an RAMS-T message without an RTP sequence number.
Note that RR MUST send at least one RAMS-T message. Against the RR MUST send at least one RAMS-T message (if an RTCP BYE message
possibility of a message loss, RR MAY repeat the RAMS-T message has not been issued yet as described in Step 9), and the RAMS-T
multiple times as long as it follows the RTCP timer rules defined message MUST be addressed to the RTCP port of the retransmission
in [RFC4585]. session. Against the possibility of a message loss, RR MAY
repeat the RAMS-T message multiple times as long as it follows
the RTCP timer rules defined in [RFC4585].
9. Terminate with RTCP BYE: When RR is receiving the burst, if RR 9. Terminate with RTCP BYE: When RR is receiving the burst, if RR
becomes no longer interested in the primary multicast stream, RR becomes no longer interested in the primary multicast stream, RR
SHALL issue an RTCP BYE message for the RTP retransmission SHALL issue an RTCP BYE message for the RTP retransmission
session and another RTCP BYE message for the primary multicast session and another RTCP BYE message for the primary multicast
session. session.
Upon receiving an RTCP BYE message, RS MUST terminate the rapid Upon receiving an RTCP BYE message, RS MUST terminate the rapid
acquisition operation, and cease transmitting any further regular acquisition operation, and cease transmitting any further regular
retransmission packets as well as retransmission packets retransmission packets as well as retransmission packets
associated with the unicast burst. Section 6.1 of [RFC3550] associated with the unicast burst. If support for [RFC5506] has
mandates the RTCP BYE message always to be sent with a sender or been signaled, the RTCP BYE message MAY be sent in a reduced-size
receiver report in a compound RTCP packet (If no data has been RTCP packet. Otherwise, Section 6.1 of [RFC3550] mandates the
received, an empty receiver report MUST be included). With the RTCP BYE message always to be sent with a sender or receiver
information contained in the receiver report, RS can also figure report in a compound RTCP packet (If no data has been received,
out how many duplicate RTP packets have been delivered to RR an empty receiver report MUST be included). With the information
(Note that this will be an upper-bound estimate as one or more contained in the receiver report, RS can also figure out how many
packets might have been lost during the burst transmission). The duplicate RTP packets have been delivered to RR (Note that this
impact of duplicate packets and measures that can be taken to will be an upper-bound estimate as one or more packets might have
minimize the impact of receiving duplicate packets will be been lost during the burst transmission). The impact of
addressed in Section 6.3. duplicate packets and measures that can be taken to minimize the
impact of receiving duplicate packets will be addressed in
Section 6.3.
Note that an RTCP BYE message issued for the RTP retransmission Note that an RTCP BYE message issued for the RTP retransmission
session terminates the whole session and ceases transmitting any session terminates the whole session and ceases transmitting any
further packets in that RTP session. Thus, in this case there is further packets in that RTP session. Thus, in this case there is
no need for sending an (explicit) RAMS-T message, which would no need for sending an (explicit) RAMS-T message, which would
only terminate the burst. only terminate the burst.
Note that for the purpose of gathering detailed information about Note that for the purpose of gathering detailed information about
RR's rapid acquisition experience, [I-D.begen-avt-rapid-sync-rtcp-xr] RR's rapid acquisition experience, [I-D.begen-avt-rapid-sync-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. Shaping the Unicast Burst 6.3. Shaping the Unicast Burst
Editor's note: This section may discuss sizing of the buffers, This section provides informative guidelines about how RS can shape
output buffer overload protection, output bandwidth management, the transmission of the unicast burst.
adjustment of burst rate and duration.
TBC. A higher bitrate for the unicast burst naturally conveys the
Reference Information and media content to RR faster. This way, RR
can start consuming the data sooner, which results in a faster
acquisition.
A higher rate also represents a better utilization of RS resources.
As the burst may continue until it catches up with the primary
multicast stream, the higher the bursting rate, the less data RS
needs to transmit. However, a higher rate for the burst also
increases the chances for congestion-caused packet loss. Thus, as
discussed in Section 5, there must be an upper bound on the extra
bandwidth used by the burst.
When RS transmits the burst, it SHOULD take into account all
available information to prevent any packet loss that may take place
during the bursting as a result of buffer overflow on the path
between RS and RR and at RR itself. The bursting rate may be
determined by taking into account the following data, when available:
a. Information obtained via the RAMS-R message, such as Max RAMS
Buffer Fill Requirement and/or Max Receive Bitrate (See
Section 7.2).
b. Information obtained via RTCP receiver reports provided by RR in
the retransmission session, allowing in-session rate adaptations
for the burst. When these receiver reports indicate packet loss,
this may indicate a certain congestion state in the path from RS
to RR. Heuristics or algorithms that deduce such congestion
state and how subsequently the RS should act, are outside the
scope of this document.
c. Information obtained via RTCP NACKs provided by RR in the primary
multicast session, allowing in-session rate adaptations for the
burst. Such RTCP NACKs are transmitted by RR in response to
packet loss detection by RR in the burst. NACKs may indicate a
certain congestion state on the path from RS to RR. Heuristics
or algorithms that deduce such congestion state and how
subsequently the RS should act, are outside the scope of this
document.
d. There may be other feedback received from RR, e.g., in the form
of ECN-CE RTCP feedback messages [I-D.westerlund-avt-ecn-for-rtp]
that may influence in-session rate adaptations.
e. Information obtained via updated RAMS-R messages, allowing in-
session rate adaptations, if supported by RS.
f. Pre-configured settings for each RR or a set of RRs that indicate
the upper-bound bursting rates for which no packet loss will
occur as a result of congestion along the path of RS to RR. For
example, in managed IPTV networks, where the bottleneck bandwidth
along the end-to-end path is known (which is generally the access
network link) and where the network between RS and this link is
provisioned and dimensioned to carry the burst streams, the
bursting rate does not exceed the provisioned value. These
settings may also be dynamically adapted using application-aware
knowledge.
The initial bursting rate of the unicast burst to RR is determined by
parameters directly obtained from RR (a) or by pre-configured
settings (f). If such information is not available, RS may choose an
appropriate initial bursting rate, and could increase or decrease the
rate based on the feedback information (b, c, d or e). However, this
may not be an easy task as by the time packet loss is reported back
to RS triggering a rate reduction, packet loss may have occurred.
A specific situation occurs near the end of the unicast burst, when
RS has almost no more additional data to sustain the relatively
higher bursting rate, thus, the upper-bound bursting rate
automatically gets limited by the nominal rate of the primary
multicast stream. During this time frame, RR will join the primary
multicast session because it was instructed to do so via an RAMS-I
message or based on some heuristics. This means that both the burst
packets and the primary multicast stream packets will be
simultaneously received by RR for a period of time.
In this case, when the unicast burst is close to catch up with the
primary multicast stream, RS may, for example, keep on sending burst
packets but should reduce the rate accordingly by taking the nominal
rate of the primary multicast stream into account. Alternatively, RS
may immediately cease transmitting the burst packets, when being
close to catch-up. Any gap resulting from an imperfect switch by RR
in receiving first the burst packets and then only primary multicast
stream packets, can be later repaired by requesting retransmissions
of the missing packets from RS. The retransmissions may also be
shaped by RS to make sure that they do not cause collateral loss in
the primary multicast and retransmission sessions.
6.4. Failure Cases 6.4. Failure Cases
All RAMS messages MAY be sent several times against the possibility All RAMS messages MAY be sent several times against the possibility
of message loss as long as RS/RR follows the RTCP timer rules defined of message loss as long as RS/RR follows the RTCP timer rules defined
in [RFC4585]. In the following, we examine the implications of in [RFC4585]. In the following, we examine the implications of
losing the RAMS-R, RAMS-I or RAMS-T messages. losing the RAMS-R, RAMS-I or RAMS-T messages.
When RR sends an RAMS-R message to initiate a rapid acquisition but When RR sends an RAMS-R message to initiate a rapid acquisition but
the message gets lost and RS does not receive it, RR will not get an the message gets lost and RS does not receive it, RR will not get an
skipping to change at page 21, line 29 skipping to change at page 23, line 29
The common packet format for the RTCP feedback messages is defined in The common packet format for the RTCP feedback messages is defined in
Section 6.1 of [RFC4585]. Each feedback message has a fixed-length Section 6.1 of [RFC4585]. Each feedback message has a fixed-length
field for version, padding, feedback message type (FMT), payload type field for version, padding, feedback message type (FMT), payload type
(PT), length, SSRC of packet sender, SSRC of media source as well as (PT), length, SSRC of packet sender, SSRC of media source as well as
a variable-length field for feedback control information (FCI). a variable-length field for feedback control information (FCI).
In the RAMS messages, the PT field is set to RTPFB (205) and the FMT In the RAMS messages, the PT field is set to RTPFB (205) and the FMT
field is set to RAMS (6). Individual RAMS messages are identified by field is set to RAMS (6). Individual RAMS messages are identified by
a sub-field called Sub Feedback Message Type (SFMT). a sub-field called Sub Feedback Message Type (SFMT).
Depending on the specific scenario and timeliness/importance of a
RAMS message, it may be desirable to send it in a reduced-size RTCP
packet [RFC5506]. However, unless support for [RFC5506] has been
signaled, compound RTCP packets MUST be used by following [RFC3550]
rules.
7.1. Extensions 7.1. Extensions
To improve the functionality of the RAMS method in certain To improve the functionality of the RAMS method in certain
applications, it may be desirable to define new fields in the RAMS applications, it may be desirable to define new fields in the RAMS
Request, Information and Termination messages. Such fields MUST be Request, Information and Termination messages. Such fields MUST be
encoded as TLV elements as described below and sketched in Figure 4: encoded as TLV elements as described below and sketched in Figure 4:
o Type: A single-octet identifier that defines the type of the o Type: A single-octet identifier that defines the type of the
parameter represented in this TLV element. parameter represented in this TLV element.
skipping to change at page 22, line 19 skipping to change at page 24, line 26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value contd. / | Value contd. /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Structure of a TLV element Figure 4: Structure of a TLV element
7.1.1. Vendor-Neutral Extensions 7.1.1. Vendor-Neutral Extensions
If the goal in defining new TLV elements is to extend the If the goal in defining new TLV elements is to extend the
functionality in a vendor-neutral manner, they MUST be registered functionality in a vendor-neutral manner, they MUST be registered
with IANA through the guidelines provided in Section 14.4. with IANA through the guidelines provided in Section 13.5.
The current document defines several vendor-neutral extensions in the The current document defines several vendor-neutral extensions in the
following sections. following sections.
7.1.2. Private Extensions 7.1.2. Private Extensions
It is desirable to allow vendors to use private extensions in TLV It is desirable to allow vendors to use private extensions in TLV
format. For interoperability, such extensions MUST NOT collide with format. For interoperability, such extensions MUST NOT collide with
each other. each other.
A certain range of TLV Types is reserved for private extensions A certain range of TLV Types is reserved for private extensions
(Refer to Section 14.4). IANA management for these extensions is (Refer to Section 13.5). IANA management for these extensions is
unnecessary and they are the responsibility of individual vendors. unnecessary and they are the responsibility of individual vendors.
The structure that MUST be used for the private extensions is The structure that MUST be used for the private extensions is
depicted in Figure 5. Here, the enterprise numbers are used from depicted in Figure 5. Here, the enterprise numbers are used from
http://www.iana.org/assignments/enterprise-numbers. This will ensure http://www.iana.org/assignments/enterprise-numbers. This will ensure
the uniqueness of the private extensions and avoid any collision. the uniqueness of the private extensions and avoid any collision.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 30 skipping to change at page 25, line 42
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=1 | Optional TLV-encoded Fields | | SFMT=1 | Optional TLV-encoded Fields |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
: Optional TLV-encoded Fields (and Padding, if needed) : : Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: FCI field syntax for the RAMS Request message Figure 6: FCI field syntax for the RAMS Request message
o 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 number of octets of content the RTP that denotes the minimum milliseconds of data that RR desires to
receiver desires to have in its buffer as a result of the unicast have in its buffer before allowing the data to be consumed by the
burst. application.
The RTP receiver may have knowledge of its buffering requirements. RR may have knowledge of its buffering requirements. These
These requirements may be application or device specific. For requirements may be application and/or device specific. For
instance, the receiver may need to have a certain amount of data instance, RR may need to have a certain amount of data in its
in its application buffer to handle interdependency within the application buffer to handle transmission jitter and/or to be able
data. If RS is told the buffering ability of the receiver, it may to support error-control methods. If RS is told the minimum
tailor the burst more precisely. The methods used by the receiver buffering requirement of the receiver, it may tailor the burst
to determine this value are application specific, and thus, out of more precisely, e.g., by choosing an appropriate starting point.
scope. The methods used by RR to determine this value are application
specific, and thus, out of the scope of this document.
If specified, the amount of backfill that will be provided by the If specified, the amount of backfill that will be provided by the
unicast burst SHOULD NOT be smaller than this value since it will unicast burst SHOULD NOT be smaller than the specified value since
not be able to build up the desired level of buffer at RR and may it will not be able to build up the desired level of buffer at RR
cause buffer underruns. and may cause buffer underruns.
Type: TBD Type: TBD
Length: TBD Length: TBD
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 number of octets of content the RTP that denotes the maximum milliseconds of data that RR can buffer
receiver can buffer without losing the burst data due to buffer without losing the burst data due to buffer overflow.
overflow.
The RTP receiver may have knowledge of its buffering requirements. RR may have knowledge of its buffering requirements. These
These requirements may be application or device specific. For requirements may be application or device specific. For instance,
instance, one receiver may have more physical memory than another one particular RR may have more physical memory than another RR,
receiver, and thus, can buffer more data. If RS knows the and thus, can buffer more data. If RS knows the buffering ability
buffering ability of the receiver, it may tailor the burst more of the receiver, it may tailor the burst more precisely. The
precisely. The methods used by the receiver to determine this methods used by the receiver to determine this value are
value are application specific, and thus, out of scope. application specific, and thus, out of scope.
If specified, the amount of backfill that will be provided by the If specified, the amount of backfill that will be provided by the
unicast burst SHOULD NOT be larger than this value since it may unicast burst SHOULD NOT be larger than this value since it may
cause buffer overflows at RR. cause buffer overflows at RR.
Type: TBD Type: TBD
Length: TBD Length: TBD
o Max Receive Bitrate (32 bits): Optional TLV element that denotes o Max Receive Bitrate (32 bits): Optional TLV element that denotes
skipping to change at page 25, line 10 skipping to change at page 27, line 22
The RAMS Information is used to describe the unicast burst that will The RAMS Information is used to describe the unicast burst that will
be sent for rapid acquisition. It also includes other useful be sent for rapid acquisition. It also includes other useful
information for RR as described below. Optional payload-specific information for RR as described below. Optional payload-specific
information MAY follow RAMS Information. information MAY follow RAMS Information.
The FCI field has the structure depicted in Figure 7. The FCI field has the structure depicted in Figure 7.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFMT=2 | MSN |S| Response | Rsvd. | | SFMT=2 | MSN | Response |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended RTP Seqnum of the First Burst Packet | |RTP SN of the First Burst Pkt. | Optional TLV-encoded Fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Optional TLV-encoded Fields (and Padding, if needed) : : Optional TLV-encoded Fields (and Padding, if needed) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: FCI field syntax for the RAMS Information message Figure 7: FCI field syntax for the RAMS Information message
o Message Sequence Number (8 bits) : Mandatory field that denotes o Message Sequence Number (8 bits) : Mandatory field that denotes
the sequence number of this RAMS-I message. During rapid the sequence number of this RAMS-I message. During rapid
acquisition, multiple RAMS-I messages MAY be sent and/or the same acquisition, multiple RAMS-I messages MAY be sent and/or the same
RAMS-I message MAY be repeated. The first RAMS-I message SHALL RAMS-I message MAY be repeated. The first RAMS-I message SHALL
have an MSN value of 0. This value SHALL NOT be changed if the have an MSN value of 0. This value SHALL NOT be changed if the
same RAMS-I message is sent to the same RR multiple times for same RAMS-I message is sent to the same RR multiple times for
redundancy purposes. If a new information is conveyed in a new redundancy purposes. If a new information is conveyed in a new
RAMS-I message, the MSN value SHALL be incremented by one. RAMS-I message, the MSN value SHALL be incremented by one.
o Support for Updated Requests (1 bit): Mandatory field that o Response (16 bits): Mandatory field that denotes the RS response
denotes whether RS supports updated request messages or not. A
value of zero in this field means that RS does not support updated
request messages and RS will ignore such requests. In this case,
RR SHOULD NOT send updated requests. However, RR MAY repeat its
initial request. A value of one in this field means that RS
supports updated request messages. In this case, RR MAY send
updated requests.
Note that even if this field is set to one, RS may or may not be
able to accept value changes in every field in an RAMS-R message.
Furthermore, RS may or may not honor the requested changes
depending on the resources available.
Editor's note: The use of this flag is still under discussion.
o Response (8 bits): Mandatory field that denotes the RS response
code for this RAMS-I message. code for this RAMS-I message.
Editor's note: Response codes will be defined and registered with Editor's note: HTTP/SIP-like response codes will be defined and
IANA in a later version. Current proposals include: registered with IANA in a later version.
1. Success
2. Bad_Request
3. No_Server_Resources_Available
4. No_Network_Resources_Available
5. No_Buffered_Content_Available
o Rsvd (8 bits): Reserved. This field SHALL be set to 0.
o Extended RTP Seqnum of the First Burst Packet (32 bits): o RTP SN of the First Burst Pkt. (16 bits): Mandatory field that
Mandatory field that specifies the extended RTP sequence number of specifies the RTP sequence number of the first packet that will be
the first packet that will be sent as part of the burst. This sent as part of the burst. This allows RR to know if one or more
allows RR to know if one or more packets have been dropped at the packets have been dropped at the beginning of the burst.
beginning of the burst. 32-bit extended RTP sequence number is
constructed by putting the 16-bit RTP sequence number in the lower
two bytes and octet 0's in the higher two bytes.
o Earliest Multicast Join Time (32 bits): Optional TLV element that o Earliest Multicast Join Time (32 bits): Optional TLV element that
specifies the time difference (i.e., delta time) between the specifies the time difference (i.e., delta time) between the
arrival of this RAMS-I message and the earliest time instant when arrival of this RAMS-I message and the earliest time instant when
RR could join the primary multicast session. A zero value in this RR could join the primary multicast session in RTP ticks. A zero
field means that RR can join the primary multicast session right value in this field means that RR can join the primary multicast
away. session right away.
Editor's note: We need to decide whether we will use ms or RTP
ticks in this field.
Note that if the RAMS request has been accepted, RS MUST send this Note that if the RAMS request has been accepted, RS SHOULD send
field at least once, so that RR knows when to join the primary this field at least once, so that RR knows when to join the
multicast session. If the burst request has been rejected as primary multicast session. If the burst request has been rejected
indicated in the Response field, this field MAY be omitted or set as indicated in the Response field, this field MAY be omitted or
to 0. In that case, it is up to RR when or whether to join the set to 0. In that case, it is up to RR when or whether to join
primary multicast session. the primary multicast session.
Type: TBD Type: TBD
Length: TBD Length: TBD
o Burst Duration (32 bits): Optional TLV element that denotes the o Burst Duration (32 bits): Optional TLV element that denotes the
duration of the burst that RS is planning to send (in RTP ticks). duration of the burst that RS is planning to send (in RTP ticks).
In the absence of additional stimulus, RS will send a burst of In the absence of additional stimulus, RS will send a burst of
this duration. However, the burst duration may be modified by this duration. However, the burst duration may be modified by
subsequent events, including changes in the primary multicast subsequent events, including changes in the primary multicast
skipping to change at page 29, line 5 skipping to change at page 30, line 30
/ fmt ; as defined in SDP spec / fmt ; as defined in SDP spec
rtcp-fb-val = "nack" SP "ssli" rtcp-fb-val = "nack" SP "ssli"
The following parameter is defined in this document for use with The following parameter is defined in this document for use with
'nack': 'nack':
o 'ssli' stands for Stream Synchronization Loss Indication and o 'ssli' stands for Stream Synchronization Loss Indication and
indicates the use of RAMS messages as defined in Section 7. indicates the use of RAMS messages as defined in Section 7.
This document also defines a new SDP attribute ('rams-updates') that
indicates whether RS supports updated request messages or not. This
attribute is used in a declarative manner. If RS supports updated
request messages and this attribute is included in the SDP
description, RR MAY send updated requests. RS may or may not be able
to accept value changes in every field in an RAMS-R message.
However, if the 'rams-updates' attribute is not included in the SDP
description, RR SHALL NOT send updated requests (RR MAY repeat its
initial request without changes, though).
8.2. Examples 8.2. Examples
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. The following enabling rapid acquisition of multicast RTP sessions. The following
example uses the SDP grouping semantics [RFC3388], the RTP/AVPF example uses the SDP grouping semantics [RFC3388], the RTP/AVPF
profile [RFC4585], the RTP retransmissions [RFC4588], the RTCP profile [RFC4585], the RTP retransmissions [RFC4588], the RTCP
extensions for SSM sessions with unicast feedback extensions for SSM sessions with unicast feedback
[I-D.ietf-avt-rtcpssm] and the source-specific media attributes [I-D.ietf-avt-rtcpssm] and the source-specific media attributes
[I-D.ietf-mmusic-sdp-source-attributes]. [I-D.ietf-mmusic-sdp-source-attributes].
In the example shown Figure 9, we have a primary multicast stream and In the example shown Figure 9, we have a primary multicast stream and
a unicast retransmission stream. The source stream is multicast from a unicast retransmission stream. The source stream is multicast from
a distribution source (with a source IP address of 192.0.2.2) to the a distribution source (with a source IP address of 192.0.2.2) to the
multicast destination address of 233.252.0.2 and port 41000. A multicast destination address of 233.252.0.2 and port 41000. A
feedback target (with an address of 192.0.2.1 and port of 41001) is Retransmission Server including feedback target functionality (with
specified with the 'rtcp' attribute. The RTP receiver(s) can report an address of 192.0.2.1 and port of 41001) is specified with the
missing packets on the source stream to this feedback target and 'rtcp' attribute. The RTP receiver(s) can report missing packets on
request retransmissions. The parameter 'rtx-time' specifies the time the source stream to the feedback target and request retransmissions.
in milliseconds (measured from the time a packet was first sent) that In the RAMS context, the parameter 'rtx-time' specifies the time in
the sender (in this case the feedback target) keeps an RTP packet in milliseconds that the Retransmission Server keeps an RTP packet in
its buffers available for retransmission. its buffer available for retransmission (measured from the time the
packet was received by the Retransmission Server).
Editor's note: In the context of RAMS, we may need a clarification
on the selection/definition of rtx-time. Would it indicate the time
the packet needs to be available after it has been received by RS?
The RTP retransmissions are sent on a unicast session with a The RTP retransmissions are sent on a unicast session with a
destination port of 41002. The RTCP port for the unicast session destination port of 41002.
(41003) is specified with the 'rtcp' attribute. In this example,
both the conventional retransmission and rapid acquisition support Editor's note: This text will be updated in a later version to
are enabled. This is achieved by the additional "a=rtcp-fb:98 nack reflect the capability for RRs to use their desired ports to receive
ssli" line. Note that this declarative SDP includes the "a=sendonly" the burst and retransmission packets.
line for the media description of the retransmission stream and is
for the Retransmission Server (RS). Its counterpart for the RTP The RTCP port for the unicast session (41003) is specified with the
Receiver (RR) includes the "a=recvonly" line as shown in Figure 10. 'rtcp' attribute. In this example, both the conventional
retransmission and rapid acquisition support are enabled. This is
achieved by the additional "a=rtcp-fb:98 nack ssli" line. Note that
this SDP includes the "a=sendonly" line for the media description of
the retransmission stream and is for the Retransmission Server (RS).
Its counterpart for the RTP Receiver (RR) includes the "a=recvonly"
line as shown in Figure 10.
When an RTP receiver requires rapid acquisition for a new multicast When an RTP receiver requires rapid acquisition for a new multicast
session it wants to join, it sends an RAMS-R message to the feedback session it wants to join, it sends an RAMS-R message to the feedback
target of that primary multicast session. This feedback message has target of that primary multicast session. This feedback message has
to have the SSRC of the primary multicast stream for which rapid to have the SSRC of the primary multicast stream for which rapid
acquisition is requested for. However, since this RTP receiver has acquisition is requested for. However, since this RTP receiver has
not received any RTP packets from the primary multicast session yet, not received any RTP packets from the primary multicast session yet,
the RTP receiver MUST learn the SSRC value from the 'ssrc' attribute the RTP receiver MUST learn the SSRC value from the 'ssrc' attribute
of the media description [I-D.ietf-avt-rtcpssm]. In addition to the of the media description [I-D.ietf-avt-rtcpssm]. In addition to the
SSRC value, the 'cname' source attribute MUST also be present in the SSRC value, the 'cname' source attribute MUST also be present in the
skipping to change at page 30, line 14 skipping to change at page 32, line 6
in the SDP file does not create a problem in SSM sessions when an in the SDP file does not create a problem in SSM sessions when an
SSRC collision occurs. This is because in SSM sessions, an RTP SSRC collision occurs. This is because in SSM sessions, an RTP
receiver that observed an SSRC collision with a media source MUST receiver that observed an SSRC collision with a media source MUST
change its own SSRC [I-D.ietf-avt-rtcpssm] by following the rules change its own SSRC [I-D.ietf-avt-rtcpssm] by following the rules
defined in [RFC3550]. defined in [RFC3550].
A feedback target that receives an RAMS-R feedback message becomes A feedback target that receives an RAMS-R feedback message becomes
aware that the prediction chain at the RTP receiver side has been aware that the prediction chain at the RTP receiver side has been
broken or does not exist any more. If the necessary conditions are broken or does not exist any more. If the necessary conditions are
satisfied (as outlined in Section 7 of [RFC4585]) and available satisfied (as outlined in Section 7 of [RFC4585]) and available
resources exist, the feedback target MAY react to the RAMS-R message resources exist, RS MAY react to the RAMS-R message by sending any
by sending any transport-layer and payload-specific feedback transport-layer and payload-specific feedback message(s) and starting
message(s) and starting the unicast burst. the unicast burst.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=Rapid Acquisition Example s=Rapid Acquisition Example
t=0 0 t=0 0
a=group:FID 3 4 a=group:FID 3 4
a=rtcp-unicast:rsi a=rtcp-unicast:rsi
m=video 41000 RTP/AVPF 98 m=video 41000 RTP/AVPF 98
i=Primary Multicast Stream #2 i=Primary Multicast Stream #2
c=IN IP4 233.252.0.2/255 c=IN IP4 233.252.0.2/255
a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2 a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2
a=recvonly a=recvonly
a=rtpmap:98 MP2T/90000 a=rtpmap:98 MP2T/90000
a=rtcp:41001 IN IP4 192.0.2.1 a=rtcp:41001 IN IP4 192.0.2.1
a=rtcp-fb:98 nack a=rtcp-fb:98 nack
a=rtcp-fb:98 nack ssli a=rtcp-fb:98 nack ssli
a=ssrc:123321 cname:iptv-ch32@rams.example.com a=ssrc:123321 cname:iptv-ch32@rams.example.com
a=rams-updates
a=mid:3 a=mid:3
m=video 41002 RTP/AVPF 99 m=video 41002 RTP/AVPF 99
i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support) i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support)
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=sendonly a=sendonly
a=rtpmap:99 rtx/90000 a=rtpmap:99 rtx/90000
a=rtcp:41003 a=rtcp:41003
a=fmtp:99 apt=98; rtx-time=5000 a=fmtp:99 apt=98; rtx-time=5000
a=mid:4 a=mid:4
skipping to change at page 31, line 20 skipping to change at page 33, line 20
m=video 41000 RTP/AVPF 98 m=video 41000 RTP/AVPF 98
i=Primary Multicast Stream #2 i=Primary Multicast Stream #2
c=IN IP4 233.252.0.2/255 c=IN IP4 233.252.0.2/255
a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2 a=source-filter: incl IN IP4 233.252.0.2 192.0.2.2
a=recvonly a=recvonly
a=rtpmap:98 MP2T/90000 a=rtpmap:98 MP2T/90000
a=rtcp:41001 IN IP4 192.0.2.1 a=rtcp:41001 IN IP4 192.0.2.1
a=rtcp-fb:98 nack a=rtcp-fb:98 nack
a=rtcp-fb:98 nack ssli a=rtcp-fb:98 nack ssli
a=ssrc:123321 cname:iptv-ch32@rams.example.com a=ssrc:123321 cname:iptv-ch32@rams.example.com
a=rams-updates
a=mid:3 a=mid:3
m=video 41002 RTP/AVPF 99 m=video 41002 RTP/AVPF 99
i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support) i=Unicast Retransmission Stream #2 (Ret. and Rapid Acq. Support)
c=IN IP4 192.0.2.1 c=IN IP4 192.0.2.1
a=recvonly a=recvonly
a=rtpmap:99 rtx/90000 a=rtpmap:99 rtx/90000
a=rtcp:41003 a=rtcp:41003
a=fmtp:99 apt=98; rtx-time=5000 a=fmtp:99 apt=98; rtx-time=5000
a=mid:4 a=mid:4
Figure 10: Example SDP for RR when RAMS support is enabled Figure 10: Example SDP for RR when RAMS support is enabled
The offer/answer model considerations [RFC3264] for the 'rtcp-fb' The offer/answer model considerations [RFC3264] for the 'rtcp-fb'
attribute are provided in Section 4.2 of [RFC4585]. attribute are provided in Section 4.2 of [RFC4585].
Editor's note: We will provide more SDP examples in later versions 9. NAT Considerations
as needed.
9. Signaling Ports via Publish Ports (PubPorts) RTCP Message
Editor's note: The PubPorts message described in this section can be
used in non-RAMS contexts as well. Based on the feedback from AVT,
we can move this discussion to a separate document.
As described in Section 6.2, when RR wants to acquire a new multicast
RTP session, it sends an RAMS-R message to the feedback target
address of that session. Upon receipt of this RTCP message, RS
learns the IP address of RR. Depending on the available resources,
RS may accept the request message and create a new unicast RTP
session. While RS can normally use the port(s) specified in the SDP
for the unicast session, in certain situations (e.g., when another
application is already using the port or a NAPT(s) is between RS and
RR), RR may need to receive RTP (and RTCP) traffic on a different
transport address (i.e., a different UDP port). RTSP signaling is
too slow to accomplish this, so we propose to use a new RTCP
extension called PubPorts to communicate the new RTP (and RTCP) ports
to RS.
The PubPorts message has the following layout:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Packet Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Media Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Port | RTCP Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: FCI field syntax for the PubPorts message
Editor's note: We will finalize the layout of this feedback message
in a later version.
After RR sends this message to RS, RS will begin sending this SSRC to
the RTP (and RTCP) ports indicated.
If RTP/RTCP multiplexing [I-D.ietf-avt-rtp-and-rtcp-mux] is supported
by RR, it can provide the same port in the RTP and RTCP port fields.
A zero value in either the RTP or RTCP port fields indicates that RS
should send the RTP or RTCP to the transport address it received the
RTCP from; this is helpful to optimize NAT scenarios (Section 10).
10. NAT Considerations
For a variety of reasons, one or more NAPT devices (hereafter simply For a variety of reasons, one or more NAPT devices (hereafter simply
called NAT) are expected to exist between RR and RS. NATs have a called NAT) are expected to exist between RR and RS. NATs have a
variety of operating characteristics for UDP traffic [RFC4787]. For variety of operating characteristics for UDP traffic [RFC4787]. For
a NAT to permit traffic from RS to arrive at RR, the NAT(s) must a NAT to permit traffic from RS to arrive at RR, the NAT(s) must
first either: first either:
a. See UDP traffic sent from RR (which is on the 'inside' of the a. See UDP traffic sent from RR (which is on the 'inside' of the
NAT) to RS (which is on the 'outside' of the NAT). This traffic NAT) to RS (which is on the 'outside' of the NAT). This traffic
is sent to the same transport address as the subsequent response is sent to the same transport address as the subsequent response
skipping to change at page 33, line 19 skipping to change at page 34, line 15
For both (a) and (b), RR is responsible for maintaining the NAT's For both (a) and (b), RR is responsible for maintaining the NAT's
state if it wants to receive traffic from the RS on that port. For state if it wants to receive traffic from the RS on that port. For
(a), RR MUST send UDP traffic to keep the NAT binding alive, at least (a), RR MUST send UDP traffic to keep the NAT binding alive, at least
every 30 seconds [RFC4787]. Note that while (a) is more like an every 30 seconds [RFC4787]. Note that while (a) is more like an
automatic/dynamic configuration, (b) is more like a manual/static automatic/dynamic configuration, (b) is more like a manual/static
configuration. configuration.
When using (a), RR will need to first learn the UDP port(s) of the When using (a), RR will need to first learn the UDP port(s) of the
NAT's binding(s) from the perspective of RS. This is done by sending NAT's binding(s) from the perspective of RS. This is done by sending
a STUN [RFC5389] messages from RR to the RTP port of RS which will be a STUN [RFC5389] message from RR to the RTP port of RS which will be
used for incoming RTP traffic. If RTP/RTCP multiplexing is not used for incoming RTP traffic. If RTP/RTCP multiplexing on a single
supported by RR, it will need to send a second STUN message to the port [I-D.ietf-avt-rtp-and-rtcp-mux] is not supported by RR, it will
RTCP port of RS which will be used for incoming RTCP traffic. If need to send a second STUN message to the RTCP port of RS which will
RTP/RTCP multiplexing is supported by RR, it only needs to learn one be used for incoming RTCP traffic. If RTP/RTCP multiplexing is
port. RS receives the STUN message(s) and responds to them. RR now supported by RR, it only needs to learn one port. RS receives the
knows the UDP ports from the perspective of RS. RR sends a PubPorts STUN message(s) and responds to them. RR now knows the UDP ports
message to RS, following the procedures described in Section 9. The from the perspective of RS.
STUN round-trip can be avoided if RR supports RTP/RTCP multiplexing
and if RR can receive the RTP/RTCP from RS on the same transport
address on which RR transmits the RTCP messages to RS (See
Section 9).
11. Known Implementations Editor's note: The issues related to using ports across multicast
and unicast RTP sessions will be discussed in a separate draft and
the current document will normatively reference that document. The
updated text for this section will be provided in a later version.
11.1. Open Source RTP Receiver Implementation by Cisco 10. Known Implementations
10.1. Open Source RTP Receiver Implementation by Cisco
An open source RTP Receiver code that implements the functionalities An open source RTP Receiver code that implements the functionalities
introduced in this document is available. For documentation, visit introduced in this document is available. For documentation, visit
the following URL: the following URL:
http://www.cisco.com/en/US/docs/video/cds/cda/vqe/3_0/user/guide/ http://www.cisco.com/en/US/docs/video/cds/cda/vqe/3_3/user/guide/
ch1_over.html ch1_over.html
The code is also available at: The code is also available at:
ftp://ftpeng.cisco.com/ftp/vqec/ ftp://ftpeng.cisco.com/ftp/vqec/
Note that this code is under development and may be based on an Note that this code is under development and may be based on an
earlier version of this document. As we make progress in the draft, earlier version of this document. As we make progress in the draft,
the source code will also be updated to reflect the changes. the source code will also be updated to reflect the changes.
Some preliminary results based on this code are available in [CCNC09] Some preliminary results based on this code are available in [CCNC09]
and [IC2009]. and [IC2009].
11.2. IPTV Commercial Implementation by Microsoft 10.2. IPTV Commercial Implementation by Microsoft
Rapid Acquisition of Multicast RTP Sessions is supported as part of Rapid Acquisition of Multicast RTP Sessions is supported as part of
the Microsoft Mediaroom Internet Protocol Television (IPTV) and the Microsoft Mediaroom Internet Protocol Television (IPTV) and
multimedia software platform. This system is in wide commercial multimedia software platform. This system is in wide commercial
deployment. More information can be found at: deployment. More information can be found at:
http://www.microsoft.com/mediaroom http://www.microsoft.com/mediaroom
http://informitv.com/articles/2008/10/13/channelchangetimes/ http://informitv.com/articles/2008/10/13/channelchangetimes/
12. Open Issues 11. Open Issues
o Discussion of acquisition for the individual RTP streams vs. the o Discussion of acquisition for the individual RTP streams vs. the
whole RTP session. whole RTP session.
o The use of extended RTP sequence numbers in the RAMS messages. o Updating the NAT section.
o Check whether RFC 5506 should be used/supported. o Completing the TLV types, lengths, etc.
o Completing burst shaping, NAT and security considerations o Response/status codes for RAMS.
sections.
13. Security Considerations 12. Security Considerations
TBC. Applications that are using RAMS make heavy use of the unicast
feedback mechanism described in [I-D.ietf-avt-rtcpssm] and the
payload format defined in [RFC4588]. Thus, these applications are
subject to the general security considerations discussed in
[I-D.ietf-avt-rtcpssm] and [RFC4588]. In this section, we give an
overview of the guidelines and suggestions described in these
specifications from a RAMS perspective. We also discuss the security
considerations that explicitly apply to RAMS applications.
14. IANA Considerations First of all, much of the session description information is
available in the SDP descriptions that are distributed to the media
sources, Retransmission Servers and RTP Receivers. Adequate security
measures are RECOMMENDED to ensure the integrity and authenticity of
the SDP descriptions so that transport addresses of the media
sources, Feedback Targets as well as other session-specific
information can be authenticated.
Compared to an RTCP NACK message that triggers one or more
retransmissions, an RAMS Request (RAMS-R) message may trigger a new
burst stream to be sent by the Retransmission Server. Depending on
the application-specific requirements and conditions existing at the
time of the RAMS-R reception by the Retransmission Server, the
resulting burst stream may contain potentially a large number of
retransmission packets. Since these packets are sent at a faster
than the nominal rate of the multicast session, RAMS consumes more
resources on the Retransmission Server, the RTP Receiver and the
network. This particularly makes denial-of-service attacks more
intense, and hence, more harmful than attacks that target ordinary
retransmission sessions.
Following the suggestions given in [RFC4588], counter-measures SHOULD
be taken to prevent tampered or spoofed RTCP packets. Tampered
RAMS-R messages may trigger inappropriate burst streams or alter the
existing burst streams in an inappropriate way. For example, if the
Max Receive Bitrate field is altered by a tampered RAMS-R message,
the updated burst may overflow the buffer on the receiver side, or
oppositely, may slow down the burst to the point that it is useless.
Tampered RAMS Termination (RAMS-T) messages may terminate valid burst
streams pre-maturely resulting in gaps in the received RTP packets.
RAMS Information (RAMS-I) messages contain fields that are critical
for the success of the RAMS operation. Any tampered information in
the RAMS-I message may easily cause the RTP Receiver to make wrong
decisions. Consequently, the RAMS operation may fail.
While most of the denial-of-service attacks can be prevented by the
integrity and authenticity checks enabled by SRTP, an attack can
still be started by legitimate endpoints that send several valid
RAMS-R messages to a particular Feedback Target in a synchronized
fashion and very short amount of time. Since a RAMS operation may
temporarily consume a large amount of resources, a series of the
RAMS-R messages may temporarily overload the Retransmission Server.
In these circumstances, the Retransmission Server may, for example,
reject incoming RAMS requests until its resources become available
again. One means to ameliorate this threat is to apply a per-
endpoint policing mechanism on the incoming RAMS requests. A
reasonable policing mechanism should consider application-specific
requirements and minimize false negatives.
In addition to the denial-of-service attacks, man-in-the-middle and
replay attacks can also be harmful. However, RAMS itself does not
bring any new risks or threats other than the ones discussed in
[I-D.ietf-avt-rtcpssm].
[RFC4588] RECOMMENDS that the cryptography mechanisms are used for
the retransmission payload format to provide protection against known
plaintext attacks. As discussed in [RFC4588], the retransmission
payload format sets the timestamp field in the RTP header to the
media timestamp of the original packet and this does not compromise
the confidentiality. Furthermore, if cryptography is used to provide
security services on the original stream, then the same services,
with equivalent cryptographic strength, MUST be provided on the
retransmission stream per [RFC4588].
13. 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 170 West Tasman Drive
San Jose, CA 95134 USA San Jose, CA 95134 USA
14.1. Registration of SDP Attribute Values 13.1. Registration of SDP Attributes
This document registers a new attribute name in SDP.
SDP Attribute ("att-field"):
Attribute name: rams-updates
Long form: Support for Updated RAMS Request Messages
Type of name: att-field
Type of attribute: Media level
Subject to charset: No
Purpose: See this document
Reference: This document
Values: None
13.2. Registration of SDP Attribute Values
This document registers a new value for the 'nack' attribute to be This document registers a new value for the 'nack' attribute to be
used with the 'rtcp-fb' attribute in SDP. For more information about used with the 'rtcp-fb' attribute in SDP. For more information about
'rtcp-fb', refer to [RFC4585]. 'rtcp-fb', refer to [RFC4585].
Value name: ssli Value name: ssli
Long name: Stream Synchronization Loss Indication Long name: Stream Synchronization Loss Indication
Usable with: nack Usable with: nack
Reference: This document Reference: This document
14.2. Registration of FMT Values 13.3. Registration of FMT Values
Within the RTPFB range, the following format (FMT) value is Within the RTPFB range, the following format (FMT) value is
registered: registered:
Name: RAMS Name: RAMS
Long name: Rapid Acquisition of Multicast Sessions Long name: Rapid Acquisition of Multicast Sessions
Value: 6 Value: 6
Reference: This document Reference: This document
14.3. SFMT Values for RAMS Messages Registry 13.4. SFMT Values for RAMS Messages Registry
This document creates a new sub-registry for the sub-feedback message This document creates a new sub-registry for the sub-feedback message
type (SFMT) values to be used with the FMT value registered for RAMS type (SFMT) values to be used with the FMT value registered for RAMS
messages. The registry is called the SFMT Values for RAMS Messages messages. The registry is called the SFMT Values for RAMS Messages
Registry. This registry is to be managed by the IANA according to Registry. This registry is to be managed by the IANA according to
the Specification Required policy of [RFC5226]. the Specification Required policy of [RFC5226].
The length of the SFMT field in the RAMS messages is a single octet, The length of the SFMT field in the RAMS messages is a single octet,
allowing 256 values. The registry is initialized with the following allowing 256 values. The registry is initialized with the following
entries: entries:
skipping to change at page 36, line 12 skipping to change at page 38, line 43
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 Note that new RAMS functionality should 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.
14.4. RAMS TLV Space Registry 13.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].
The length of the Type field in the TLV elements is a single octet, The length of the Type field in the TLV elements is a single octet,
allowing 256 values. The registry is initialized with the following allowing 256 values. The registry is initialized with the following
entries: entries:
skipping to change at page 36, line 43 skipping to change at page 39, line 27
Any registration for an unassigned TYPE value MUST contain the Any registration for an unassigned TYPE value MUST contain the
following information: following information:
o Contact information of the one doing the registration, including o Contact information of the one doing the registration, including
at least name, address, and email. at least name, address, and email.
o A detailed description of what the new TLV element represents and o A detailed description of what the new TLV element represents and
how it shall be interpreted. how it shall be interpreted.
15. Acknowledgments 14. Acknowledgments
The authors would like to specially thank Peilin Yang for his The authors would like to specially thank Peilin Yang for his
contributions to this document and detailed reviews. contributions to this document and detailed reviews.
The authors also thank the following individuals for their The authors also thank the following individuals for their
contributions, comments and suggestions to this document: Dave Oran, contributions, comments and suggestions to this document: Dave Oran,
Dan Wing, Tony Faustini, Jeff Goldberg, Muriel Deschanel, Orit Levin, Dan Wing, Tony Faustini, Jeff Goldberg, Muriel Deschanel, Orit Levin,
Roni Even, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui Wang, Zixuan Roni Even, Guy Hirson, Tom Taylor, Xavier Marjou, Ye-Kui Wang, Zixuan
Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan Lennox and Zou, Ingemar Johansson, Haibin Song, Ning Zong, Jonathan Lennox and
Sean Sheedy. Sean Sheedy.
16. Change Log 15. Change Log
16.1. draft-ietf-avt-rapid-acquisition-for-rtp-01 15.1. 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.
15.2. draft-ietf-avt-rapid-acquisition-for-rtp-01
The following are the major changes compared to version 00: The following are the major changes compared to version 00:
o Formal definitions of vendor-neutral and private extensions and o Formal definitions of vendor-neutral and private extensions and
their IANA registries have been added. their IANA registries have been added.
o SDP examples were explained in more detail. o SDP examples were explained in more detail.
o The sub-FMT field has been introduced in the RAMS messages for o The sub-FMT field has been introduced in the RAMS messages for
message type identification. message type identification.
o Some terminology has been fixed. o Some terminology has been fixed.
o NAT considerations section has been added. o NAT considerations section has been added.
16.2. draft-ietf-avt-rapid-acquisition-for-rtp-00 15.3. draft-ietf-avt-rapid-acquisition-for-rtp-00
This is a resubmission of version 03 as a WG item. This is a resubmission of version 03 as a WG item.
16.3. draft-versteeg-avt-rapid-synchronization-for-rtp-03 15.4. draft-versteeg-avt-rapid-synchronization-for-rtp-03
The following are the major changes compared to version 02: The following are the major changes compared to version 02:
o The title and message names have been changed. o The title and message names have been changed.
o RTCP message semantics have been added. RAMS protocol has been o RTCP message semantics have been added. RAMS protocol has been
revised to handle updated requests and responses. revised to handle updated requests and responses.
o Definitions have been revised. o Definitions have been revised.
o RTP/RTCP muxing reference has been added. o RTP/RTCP muxing reference has been added.
16.4. draft-versteeg-avt-rapid-synchronization-for-rtp-02 15.5. draft-versteeg-avt-rapid-synchronization-for-rtp-02
The following are the major changes compared to version 01: The following are the major changes compared to version 01:
o The discussion around MPEG2-TS has been moved to another document. o The discussion around MPEG2-TS has been moved to another document.
o The RAMS-R, RAMS-I and RAMS-T messages have been extensively o The RAMS-R, RAMS-I and RAMS-T messages have been extensively
modified and they have been made mandatory. modified and they have been made mandatory.
o IANA Considerations section has been updated. o IANA Considerations section has been updated.
o The discussion of RTCP XR report has been moved to another o The discussion of RTCP XR report has been moved to another
document. document.
o A new section on protocol design considerations has been added. o A new section on protocol design considerations has been added.
16.5. draft-versteeg-avt-rapid-synchronization-for-rtp-01 15.6. draft-versteeg-avt-rapid-synchronization-for-rtp-01
The following are the major changes compared to version 00: The following are the major changes compared to version 00:
o The core of the rapid synchronization method is now payload- o The core of the rapid synchronization method is now payload-
independent. But, the draft still defines payload-specific independent. But, the draft still defines payload-specific
messages that are required for enabling rapid synch for the RTP messages that are required for enabling rapid synch for the RTP
flows carrying MPEG2-TS. flows carrying MPEG2-TS.
o RTCP APP packets have been removed, new RTCP transport-layer and o RTCP APP packets have been removed, new RTCP transport-layer and
payload-specific feedback messages have been defined. payload-specific feedback messages have been defined.
o The step for leaving the current multicast session has been o The step for leaving the current multicast session has been
removed from Section 6.2. removed from Section 6.2.
o A new RTCP XR (Multicast Join) report has been defined. o A new RTCP XR (Multicast Join) report has been defined.
o IANA Considerations section have been updated. o IANA Considerations section have been updated.
o Editorial changes to clarify several points. o Editorial changes to clarify several points.
17. References 16. References
17.1. Normative References 16.1. Normative References
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
skipping to change at page 39, line 46 skipping to change at page 42, line 43
(SDP)", draft-ietf-mmusic-sdp-source-attributes-02 (work (SDP)", draft-ietf-mmusic-sdp-source-attributes-02 (work
in progress), October 2008. in progress), October 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
17.2. Informative References 16.2. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[I-D.ietf-rmt-pi-norm-revised] [I-D.ietf-rmt-pi-norm-revised]
Adamson, B., Bormann, C., London, U., and J. Macker, Adamson, B., Bormann, C., London, U., and J. Macker,
"NACK-Oriented Reliable Multicast Transport Protocol", "NACK-Oriented Reliable Multicast Transport Protocol",
draft-ietf-rmt-pi-norm-revised-13 (work in progress), draft-ietf-rmt-pi-norm-revised-13 (work in progress),
June 2009. June 2009.
[I-D.begen-avt-rtp-mpeg2ts-preamble] [I-D.begen-avt-rtp-mpeg2ts-preamble]
Begen, A., "RTP Payload Format for MPEG2-TS Preamble", Begen, A. and E. Friedrich, "RTP Payload Format for
draft-begen-avt-rtp-mpeg2ts-preamble-00 (work in MPEG2-TS Preamble",
progress), March 2009. draft-begen-avt-rtp-mpeg2ts-preamble-02 (work in
progress), August 2009.
[I-D.begen-avt-rapid-sync-rtcp-xr] [I-D.begen-avt-rapid-sync-rtcp-xr]
Begen, A. and E. Friedrich, "Multicast Acquisition Report Begen, A. and E. Friedrich, "Multicast Acquisition Report
Block Type for RTCP XR", Block Type for RTCP XR",
draft-begen-avt-rapid-sync-rtcp-xr-01 (work in progress), draft-begen-avt-rapid-sync-rtcp-xr-02 (work in progress),
May 2009. August 2009.
[I-D.ietf-avt-rapid-rtp-sync]
Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", draft-ietf-avt-rapid-rtp-sync-05 (work in
progress), July 2009.
[I-D.westerlund-avt-ecn-for-rtp]
Westerlund, M., Johansson, I., and C. Perkins, "Explicit
Congestion Notification (ECN) for RTP over UDP",
draft-westerlund-avt-ecn-for-rtp-00 (work in progress),
July 2009.
[I-D.ietf-avt-rtp-and-rtcp-mux] [I-D.ietf-avt-rtp-and-rtcp-mux]
Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", Control Packets on a Single Port",
draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress), draft-ietf-avt-rtp-and-rtcp-mux-07 (work in progress),
August 2007. August 2007.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
 End of changes. 77 change blocks. 
325 lines changed or deleted 489 lines changed or added

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