draft-ietf-avt-rapid-acquisition-for-rtp-06.txt   draft-ietf-avt-rapid-acquisition-for-rtp-07.txt 
AVT B. VerSteeg AVT B. VerSteeg
Internet-Draft A. Begen Internet-Draft A. Begen
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: August 8, 2010 T. VanCaenegem Expires: August 22, 2010 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Z. Vax Z. Vax
Microsoft Corporation Microsoft Corporation
February 4, 2010 February 18, 2010
Unicast-Based Rapid Acquisition of Multicast RTP Sessions Unicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-ietf-avt-rapid-acquisition-for-rtp-06 draft-ietf-avt-rapid-acquisition-for-rtp-07
Abstract Abstract
When an RTP receiver joins a multicast session, it may need to When an RTP receiver joins a multicast session, it may need to
acquire and parse certain Reference Information before it can process acquire and parse certain Reference Information before it can process
any data sent in the multicast session. Depending on the join time, any data sent in the multicast session. Depending on the join time,
length of the Reference Information repetition (or appearance) length of the Reference Information repetition (or appearance)
interval, size of the Reference Information as well as the interval, size of the Reference Information as well as the
application and transport properties, the time lag before an RTP application and transport properties, the time lag before an RTP
receiver can usefully consume the multicast data, which we refer to receiver can usefully consume the multicast data, which we refer to
as the Acquisition Delay, varies and may be large. This is an as the Acquisition Delay, varies and may be large. This is an
undesirable phenomenon for receivers that frequently switch among undesirable phenomenon for receivers that frequently switch among
different multicast sessions, such as video broadcasts. different multicast sessions, such as video broadcasts.
In this document, we describe a method using the existing RTP and In this document, we describe a method using the existing RTP and
RTCP protocol machinery that reduces the acquisition delay. In this RTCP protocol machinery that reduces the acquisition delay. In this
method, an auxiliary unicast RTP session carrying the Reference method, an auxiliary unicast RTP session carrying the Reference
Information to the receiver precedes/accompanies the multicast Information to the receiver precedes/accompanies the multicast
stream. This unicast RTP flow may be transmitted at a faster than stream. This unicast RTP flow may be transmitted at a faster than
natural rate to further accelerate the acquisition. The motivating natural birate to further accelerate the acquisition. The motivating
use case for this capability is multicast applications that carry use case for this capability is multicast applications that carry
real-time compressed audio and video. However, the proposed method real-time compressed audio and video. However, the proposed method
can also be used in other types of multicast applications where the can also be used in other types of multicast applications where the
acquisition delay is long enough to be a problem. acquisition delay is long enough to be a problem.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 2, line 14 skipping to change at page 2, line 14
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 8, 2010. This Internet-Draft will expire on August 22, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 19 skipping to change at page 3, line 19
1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 8 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 8
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Elements of Delay in Multicast Applications . . . . . . . . . 10 4. Elements of Delay in Multicast Applications . . . . . . . . . 10
5. Protocol Design Considerations and Their Effect on 5. Protocol Design Considerations and Their Effect on
Resource Management for Rapid Acquisition . . . . . . . . . . 11 Resource Management for Rapid Acquisition . . . . . . . . . . 11
6. Rapid Acquisition of Multicast RTP Sessions . . . . . . . . . 13 6. Rapid Acquisition of Multicast RTP Sessions . . . . . . . . . 13
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 14
6.3. Synchronization of Primary Multicast Streams . . . . . . 23 6.3. Synchronization of Primary Multicast Streams . . . . . . 23
6.4. Shaping the Unicast Burst . . . . . . . . . . . . . . . . 24 6.4. Burst Shaping and Congestion Control in RAMS . . . . . . 24
6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 26 6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 27 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 27
7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . 27 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . 28
7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 28 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 29
7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 28 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 29
7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . 29 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . 30
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . 32 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . 32
7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . 34 7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . 35
8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 35 8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 36
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 35 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 36
8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 36 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 37
8.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 36 8.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 37
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 39 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 40
10. Congestion Control Considerations . . . . . . . . . . . . . . 40 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 11.1. Registration of SDP Attributes . . . . . . . . . . . . . 43
12.1. Registration of SDP Attributes . . . . . . . . . . . . . 42 11.2. Registration of SDP Attribute Values . . . . . . . . . . 44
12.2. Registration of SDP Attribute Values . . . . . . . . . . 43 11.3. Registration of FMT Values . . . . . . . . . . . . . . . 44
12.3. Registration of FMT Values . . . . . . . . . . . . . . . 43 11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . 44
12.4. SFMT Values for RAMS Messages Registry . . . . . . . . . 43 11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 45
12.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 44 11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 46
12.6. RAMS Response Code Space Registry . . . . . . . . . . . . 45 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 47 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 48
15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 47 14.1. draft-ietf-avt-rapid-acquisition-for-rtp-07 . . . . . . . 48
15.1. draft-ietf-avt-rapid-acquisition-for-rtp-06 . . . . . . . 47 14.2. draft-ietf-avt-rapid-acquisition-for-rtp-06 . . . . . . . 48
15.2. draft-ietf-avt-rapid-acquisition-for-rtp-05 . . . . . . . 47 14.3. draft-ietf-avt-rapid-acquisition-for-rtp-05 . . . . . . . 49
15.3. draft-ietf-avt-rapid-acquisition-for-rtp-04 . . . . . . . 47 14.4. draft-ietf-avt-rapid-acquisition-for-rtp-04 . . . . . . . 49
15.4. draft-ietf-avt-rapid-acquisition-for-rtp-03 . . . . . . . 48 14.5. draft-ietf-avt-rapid-acquisition-for-rtp-03 . . . . . . . 49
15.5. draft-ietf-avt-rapid-acquisition-for-rtp-02 . . . . . . . 48 14.6. draft-ietf-avt-rapid-acquisition-for-rtp-02 . . . . . . . 49
15.6. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 48 14.7. draft-ietf-avt-rapid-acquisition-for-rtp-01 . . . . . . . 49
15.7. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 48 14.8. draft-ietf-avt-rapid-acquisition-for-rtp-00 . . . . . . . 50
15.8. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 49 14.9. draft-versteeg-avt-rapid-synchronization-for-rtp-03 . . . 50
15.9. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 49 14.10. draft-versteeg-avt-rapid-synchronization-for-rtp-02 . . . 50
15.10. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 49 14.11. draft-versteeg-avt-rapid-synchronization-for-rtp-01 . . . 50
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
16.1. Normative References . . . . . . . . . . . . . . . . . . 50 15.1. Normative References . . . . . . . . . . . . . . . . . . 51
16.2. Informative References . . . . . . . . . . . . . . . . . 51 15.2. Informative References . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
Most multicast flows carry a stream of inter-related data. Certain Most multicast flows carry a stream of inter-related data. Certain
information must first be acquired by the receivers to start information must first be acquired by the receivers to start
processing any data sent in the multicast session. This document processing any data sent in the multicast session. This document
refers to this information as Reference Information. The Reference refers to this information as Reference Information. The Reference
Information is conventionally sent periodically in the multicast Information is conventionally sent periodically in the multicast
session (although its content may change over time) and usually session (although its content may change over time) and usually
consists of items such as a description of the schema for the rest of consists of items such as a description of the schema for the rest of
skipping to change at page 8, line 34 skipping to change at page 8, line 34
be established for each of them. be established for each of them.
1.2. Outline 1.2. Outline
In the rest of this specification, we have the following outline: In In the rest of this specification, we have the following outline: In
Section 4, we describe the delay components in generic multicast Section 4, we describe the delay components in generic multicast
applications. Section 5 presents an overview of the protocol design applications. Section 5 presents an overview of the protocol design
considerations for rapid acquisition. We provide the protocol considerations for rapid acquisition. We provide the protocol
details of the rapid acquisition method in Section 6 and Section 7. details of the rapid acquisition method in Section 6 and Section 7.
Section 8 and Section 9 discuss the SDP signaling issues with Section 8 and Section 9 discuss the SDP signaling issues with
examples and NAT-related issues, respectively. Section 10 and examples and NAT-related issues, respectively. Finally, Section 10
Section 11 discuss the congestion control and security discusses the security considerations.
considerations, respectively.
Section 3 provides a list of the definitions frequently used in this Section 3 provides a list of the definitions frequently used in this
document. document.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 9, line 30 skipping to change at page 9, line 30
IPv6 networks, respectively. However, the rapid acquisition method IPv6 networks, respectively. However, the rapid acquisition method
introduced in this document does not depend on a specific version of introduced in this document does not depend on a specific version of
either of these group management protocols. In the remainder of this either of these group management protocols. In the remainder of this
document, SFGMP will refer to any group management protocol that has document, SFGMP will refer to any group management protocol that has
Join and Leave functionalities. Join and Leave functionalities.
Feedback Target (FT): Unicast RTCP feedback target as defined in Feedback Target (FT): Unicast RTCP feedback target as defined in
[I-D.ietf-avt-rtcpssm]. FT_Ap denotes a specific feedback target [I-D.ietf-avt-rtcpssm]. FT_Ap denotes a specific feedback target
running on a particular address and port. running on a particular address and port.
Retransmission Packet: An RTP packet that is formatted as defined in Retransmission (Burst) Packet: An RTP packet that is formatted as
[RFC4588]. defined in [RFC4588].
Reference Information: The set of certain media content and metadata Reference Information: The set of certain media content and metadata
information that is sufficient for an RTP receiver to start usefully information that is sufficient for an RTP receiver to start usefully
consuming a media stream. The meaning, format and size of this consuming a media stream. The meaning, format and size of this
information are specific to the application and are out of scope of information are specific to the application and are out of scope of
this document. this document.
Preamble Information: A more compact form of the whole or a subset Preamble Information: A more compact form of the whole or a subset
of the Reference Information transmitted out-of-band. of the Reference Information transmitted out-of-band.
(Unicast) Burst (Stream): A unicast stream of RTP retransmission (Unicast) Burst (Stream): A unicast stream of RTP retransmission
packets that enable an RTP receiver to rapidly acquire the Reference packets that enable an RTP receiver to rapidly acquire the Reference
Information associated with a primary multicast stream. Each burst Information associated with a primary multicast stream. Each burst
stream is identified by its unique SSRC identifier in the primary stream is identified by its SSRC identifier that is unique in the
multicast RTP session. The burst streams are typically transmitted primary multicast RTP session. The burst streams are typically
at an accelerated rate. transmitted at an accelerated rate.
Retransmission Server (RS): The RTP/RTCP endpoint that can generate Retransmission Server (RS): The RTP/RTCP endpoint that can generate
the retransmission packets and the burst streams. RS may also the retransmission packets and the burst streams. RS may also
generate other non-retransmission packets to aid the rapid generate other non-retransmission packets to aid the rapid
acquisition process. acquisition process.
4. Elements of Delay in Multicast Applications 4. Elements of Delay in Multicast Applications
In an any-source (ASM) or a source-specific (SSM) multicast delivery In an any-source (ASM) or a source-specific (SSM) multicast delivery
system, there are three major elements that contribute to the overall system, there are three major elements that contribute to the overall
skipping to change at page 14, line 18 skipping to change at page 14, line 18
and new RTCP feedback messages. The Burst Source has a cache where and new RTCP feedback messages. The Burst Source has a cache where
the most recent packets from the primary multicast RTP session are the most recent packets from the primary multicast RTP session are
continuously stored. When an RTP receiver wants to receive a primary continuously stored. When an RTP receiver wants to receive a primary
multicast stream prior to joining the SSM session, it may first multicast stream prior to joining the SSM session, it may first
request a unicast burst from the Burst Source. In this burst, the request a unicast burst from the Burst Source. In this burst, the
packets are formatted as RTP retransmission packets [RFC4588] and packets are formatted as RTP retransmission packets [RFC4588] and
carry the Reference Information. This information allows the RTP carry the Reference Information. This information allows the RTP
receiver to start usefully consuming the RTP packets sent in the receiver to start usefully consuming the RTP packets sent in the
primary multicast RTP session. primary multicast RTP session.
Using an accelerated rate (as compared to the nominal rate of the Using an accelerated bitrate (as compared to the nominal bitrate of
primary multicast stream) for the unicast burst implies that at a the primary multicast stream) for the unicast burst implies that at a
certain point in time, the payload transmitted in the unicast burst certain point in time, the payload transmitted in the unicast burst
is going to be the same as the payload in the associated multicast is going to be the same as the payload in the associated multicast
stream, i.e., the unicast burst will catch up with the primary stream, i.e., the unicast burst will catch up with the primary
multicast stream. At this point, the RTP receiver no longer needs to multicast stream. At this point, the RTP receiver no longer needs to
receive the unicast burst and can join the SSM session. This method receive the unicast burst and can join the SSM session. This method
is referred to as the Rapid Acquisition of Multicast Sessions (RAMS). is referred to as the Rapid Acquisition of Multicast Sessions (RAMS).
This document proposes extensions to [RFC4585] for an RTP receiver to This document proposes extensions to [RFC4585] for an RTP receiver to
request a unicast burst as well as for additional control messaging request a unicast burst as well as for additional control messaging
that can be leveraged during the acquisition process. that can be leveraged during the acquisition process.
skipping to change at page 15, line 4 skipping to change at page 15, line 4
Figure 2 shows the main entities involved in rapid acquisition and Figure 2 shows the main entities involved in rapid acquisition and
the message flows. They are the message flows. They are
o Multicast Source o Multicast Source
o Feedback Target (FT) o Feedback Target (FT)
o Burst/Retransmission Source o Burst/Retransmission Source
o RTP Receiver (RTP_Rx) o RTP Receiver (RTP_Rx)
----------- ---------------- -------------- ----------- --------------
| | | Retransmission | | | | |----------------------------------->| |
| Multicast |------->| Server (RS) |--------->| | | |.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.>| |
| Source |.-.-.-.>| |.-.-.-.-.>| | | | | |
| Multicast | ---------------- | |
| Source | | Retransmission | | |
| |------->| Server (RS) |--------->| |
| |.-.-.-.>| |.-.-.-.-.>| |
| | | ------------ | | | | | | ------------ | | |
----------- | | Feedback | |<.=.=.=.=.| | ----------- | | Feedback | |<.=.=.=.=.| |
| | Target | |<~~~~~~~~~| RTP Receiver | | | Target | |<~~~~~~~~~| RTP Receiver |
| ------------ | | (RTP_Rx) | | ------------ | | (RTP_Rx) |
| | | | | | | |
| ------------ | | | | ------------ | | |
| | Burst and | |<~~~~~~~~>| | | | Burst and | |<~~~~~~~~>| |
| | Retrans. | |.........>| | | | Retrans. | |.........>| |
| | Source | |<.=.=.=.=>| | | | Source | |<.=.=.=.=>| |
| ------------ | | | | ------------ | | |
skipping to change at page 24, line 20 skipping to change at page 24, line 23
multicast RTP sessions also allow rapid synchronization of the RTP multicast RTP sessions also allow rapid synchronization of the RTP
streams for the RTP receivers that do not support RAMS or that streams for the RTP receivers that do not support RAMS or that
directly join the multicast session without running RAMS. Thus, in directly join the multicast session without running RAMS. Thus, in
RAMS applications, it is RECOMMENDED that the multicast sources RAMS applications, it is RECOMMENDED that the multicast sources
frequently send synchronization information by using header frequently send synchronization information by using header
extensions following the rules presented in extensions following the rules presented in
[I-D.ietf-avt-rapid-rtp-sync]. It should be noted that the regular [I-D.ietf-avt-rapid-rtp-sync]. It should be noted that the regular
sender reports are still sent in the unicast session by following the sender reports are still sent in the unicast session by following the
rules of [RFC3550]. rules of [RFC3550].
6.4. Shaping the Unicast Burst 6.4. Burst Shaping and Congestion Control in RAMS
This section provides informative guidelines about how RS can shape This section provides informative guidelines about how RS can shape
the transmission of the unicast burst. the transmission of the unicast burst and how congestion can be dealt
within the RAMS process.
A higher bitrate for the unicast burst naturally conveys the A higher bitrate for the unicast burst naturally conveys the
Reference Information and media content to RTP_Rx faster. This way, Reference Information and media content to RTP_Rx faster. This way,
RTP_Rx can start consuming the data sooner, which results in a faster RTP_Rx can start consuming the data sooner, which results in a faster
acquisition. acquisition. A higher bitrate also represents a better utilization
of RS resources. As the burst may continue until it catches up with
A higher rate also represents a better utilization of RS resources. the primary multicast stream, the higher the bursting bitrate, the
As the burst may continue until it catches up with the primary less data RS needs to transmit. However, a higher bitrate for the
multicast stream, the higher the bursting rate, the less data RS burst also increases the chances for congestion-caused packet loss.
needs to transmit. However, a higher rate for the burst also Thus, as discussed in Section 5, there must be an upper bound on the
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. bandwidth used by the burst.
When RS transmits the burst, it should take into account all When RS transmits the burst, it should take into account all
available information to prevent any packet loss that may take place available information to prevent any packet loss that may take place
during the bursting as a result of buffer overflow on the path during the bursting as a result of buffer overflow on the path
between RS and RTP_Rx and at RTP_Rx itself. The bursting rate may be between RS and RTP_Rx and at RTP_Rx itself. The bursting bitrate may
determined by taking into account the following data, when available: be determined by taking into account the following information, when
available:
a. Information obtained via the RAMS-R message, such as Max RAMS a. Information obtained via the RAMS-R message, such as Max RAMS
Buffer Fill Requirement and/or Max Receive Bitrate (See Buffer Fill Requirement and/or Max Receive Bitrate (See
Section 7.2). Section 7.2).
b. Information obtained via RTCP receiver reports provided by RTP_Rx b. Information obtained via RTCP receiver reports provided by RTP_Rx
in the retransmission session, allowing in-session rate in the retransmission session, allowing in-session bitrate
adaptations for the burst. When these receiver reports indicate adaptations for the burst. When these receiver reports indicate
packet loss, this may indicate a certain congestion state in the packet loss, this may indicate a certain congestion state in the
path from RS to RTP_Rx. Heuristics or algorithms that deduce path from RS to RTP_Rx.
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 RTP_Rx in the c. Information obtained via RTCP NACKs provided by RTP_Rx in the
primary multicast RTP session, allowing in-session rate primary multicast RTP session, allowing in-session bitrate
adaptations for the burst. Such RTCP NACKs are transmitted by adaptations for the burst. Such RTCP NACKs are transmitted by
RTP_Rx in response to packet loss detection by RTP_Rx in the RTP_Rx in response to packet loss detection in the burst. NACKs
burst. NACKs may indicate a certain congestion state on the path may indicate a certain congestion state on the path from RS to
from RS to RTP_Rx. Heuristics or algorithms that deduce such RTP_Rx.
congestion state and how subsequently the RS should act, are
outside the scope of this document.
d. There may be other feedback received from RTP_Rx, e.g., in the d. There may be other feedback received from RTP_Rx, e.g., in the
form of ECN-CE RTCP feedback messages form of ECN-CE markings [I-D.westerlund-avt-ecn-for-rtp] that may
[I-D.westerlund-avt-ecn-for-rtp] that may influence in-session influence in-session bitrate adaptation.
rate adaptations.
e. Information obtained via updated RAMS-R messages, allowing in- e. Information obtained via updated RAMS-R messages, allowing in-
session rate adaptations, if supported by RS. session bitrate adaptations, if supported by RS.
f. Pre-configured settings for each RTP_Rx or a set of RTP_Rxs that f. Transport protocol-specific information. For example, when DCCP
indicate the upper-bound bursting rates for which no packet loss is used to transport the RTP burst, the ACKs from the DCCP client
will occur as a result of congestion along the path of RS to can be leveraged by the RS / DCCP server for burst shaping and
congestion control.
g. Pre-configured settings for each RTP_Rx or a set of RTP_Rxs that
indicate the upper-bound bursting bitrates for which no packet
loss will occur as a result of congestion along the path of RS to
RTP_Rx. For example, in managed IPTV networks, where the RTP_Rx. For example, in managed IPTV networks, where the
bottleneck bandwidth along the end-to-end path is known and where bottleneck bandwidth along the end-to-end path is known and where
the network between RS and this link is provisioned and the network between RS and this link is provisioned and
dimensioned to carry the burst streams, the bursting rate does dimensioned to carry the burst streams, the bursting bitrate does
not exceed the provisioned value. These settings may also be not exceed the provisioned value. These settings may also be
dynamically adapted using application-aware knowledge. dynamically adapted using application-aware knowledge.
The initial bursting rate of the unicast burst to RTP_Rx is RS chooses the initial burst bitrate as follows:
determined by parameters directly obtained from RTP_Rx (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 o When using RAMS in environments as described in (g), RS MUST
RS has almost no more additional data to sustain the relatively transmit the burst packets at an initial bitrate higher than the
higher bursting rate, thus, the upper-bound bursting rate nominal bitrate, but within the engineered or reserved bandwidth
automatically gets limited by the nominal rate of the primary limit.
multicast stream. During this time frame, RTP_Rx eventually needs to
join the multicast session. This means that both the burst packets o When RS cannot determine a reliable bitrate value for the unicast
and the multicast packets may be simultaneously received by RTP_Rx burst (through a or g), RS should choose an appropriate initial
for a period of time. bitrate not above the nominal bitrate and increase it gradually
unless a congestion is detected.
In both cases, during the burst transmission RS MUST continuously
monitor for packet losses as a result of congestion by means of one
or more of the mechanisms described in (b,c,d,e,f). When RS relies
on RTCP receiver reports, sufficient bandwidth must be provided to
RTP Rx for RTCP transmission. To achieve a reasonable fast
adaptation against congestion, it is recommended that RTP_Rx sends a
receiver report at least once every two RTTs between RS and RTP_Rx.
Although the specific heuristics and algorithms that deduce a
congestion state and how subsequently RS should act are outside the
scope of this specification, the following two practices are
recommended:
o Upon detection of a significant packet loss, which RS attributes
to congestion, RS should decrease the burst bitrate. The rate by
which RS increases and decreases the bitrate for the burst may be
determined by a TCP-friendly bitrate adaptation algorithm for RTP
over UDP , or in the case of (f) by the congestion control
algorithms defined in DCCP [I-D.ietf-dccp-rtp].
o If the congestion is persistent and RS has to reduce the burst
bitrate to a point where the RTP Rx buffer may underrun or the
burst will consume too much RS resources, RS should terminate the
burst and transmit a RAMS-I message to RTP Rx with the appropriate
response code. It is then up to RTP Rx to decide when to join the
multicast session.
In case there is no congestion experienced during the burst, a
specific situation occurs near the end of the unicast burst, when RS
has almost no more additional data to sustain the relatively higher
burst bitrate, thus, the upper-bound burst bitrate automatically gets
limited by the nominal bitrate of the primary multicast stream.
During this time frame, RTP_Rx eventually needs to join the multicast
session. This means that both the burst packets and the multicast
packets may be simultaneously received by RTP_Rx for a period of
time, enhancing the risk of congestion again.
Since RS signals RTP_Rx when it should send the SFGMP Join message, Since RS signals RTP_Rx when it should send the SFGMP Join message,
RS may have a rough estimate of when RTP_Rx will start receiving RS may have a rough estimate of when RTP_Rx will start receiving
multicast packets in the SSM session. RS may keep on sending burst multicast packets in the SSM session. RS may keep on sending burst
packets but should reduce the rate accordingly at the appropriate packets but should reduce the bitrate accordingly at the appropriate
instant by taking the rate of the SSM session into account. If RS instant by taking the bitrate of the whole SSM session into account.
ceases transmitting the burst packets before the burst catches up, If RS ceases transmitting the burst packets before the burst catches
any gap resulting from this imperfect switch-over by RTP_Rx can be up, any gap resulting from this imperfect switch-over by RTP_Rx can
later repaired by requesting retransmissions of the missing packets be later repaired by requesting retransmissions for the missing
from RS. The retransmissions may be shaped by RS to make sure that packets from RS. The retransmissions may be shaped by RS to make
they do not cause collateral loss in the primary multicast RTP sure that they do not cause collateral loss in the primary multicast
session and the RTP retransmission session. RTP session and the RTP retransmission session.
6.5. Failure Cases 6.5. Failure Cases
In the following, we examine the implications of losing the RAMS-R, In the following, we examine the implications of losing the RAMS-R,
RAMS-I or RAMS-T messages and other failure cases. RAMS-I or RAMS-T messages and other failure cases.
When RTP_Rx sends a RAMS-R message to initiate a rapid acquisition When RTP_Rx sends a RAMS-R message to initiate a rapid acquisition
but the message gets lost and RS does not receive it, RTP_Rx will get but the message gets lost and RS does not receive it, RTP_Rx will get
neither a RAMS-I message, nor a unicast burst. In this case, RTP_Rx neither a RAMS-I message, nor a unicast burst. In this case, RTP_Rx
MAY resend the request when it is eligible to do so based on the RTCP MAY resend the request when it is eligible to do so based on the RTCP
skipping to change at page 27, line 8 skipping to change at page 27, line 45
no longer needs them. In such cases, it is RECOMMENDED that RTP_Rx no longer needs them. In such cases, it is RECOMMENDED that RTP_Rx
repeats the RAMS-T message multiple times based on the RTCP timer repeats the RAMS-T message multiple times based on the RTCP timer
rules defined in [RFC4585]. In the worst case, RS MUST be rules defined in [RFC4585]. In the worst case, RS MUST be
provisioned to deterministically terminate the burst when it can no provisioned to deterministically terminate the burst when it can no
longer send the burst packets faster than it receives the primary longer send the burst packets faster than it receives the primary
multicast stream packets. multicast stream packets.
Section 6.3.5 of [RFC3550] explains the rules pertaining to timing Section 6.3.5 of [RFC3550] explains the rules pertaining to timing
out an SSRC. When RS accepts to serve the requested burst(s) and out an SSRC. When RS accepts to serve the requested burst(s) and
establishes the retransmission session, it should check the liveness establishes the retransmission session, it should check the liveness
of RTP_Rx via the RTCP messages and reports RTP_Rx sends. of RTP_Rx via the RTCP messages and reports RTP_Rx sends. The
default rules explained in [RFC3550] apply in RAMS as well.
Editor's note: What would the timeout duration be and what action
should RS take?
7. Encoding of the Signaling Protocol in RTCP 7. Encoding of the Signaling Protocol in RTCP
This section defines the formats of the RTCP transport-layer feedback This section defines the formats of the RTCP transport-layer feedback
messages that are exchanged between the Retransmission Server (RS) messages that are exchanged between the Retransmission Server (RS)
and RTP Receiver (RTP_Rx) during rapid acquisition. These messages and RTP Receiver (RTP_Rx) during rapid acquisition. These messages
are referred to as the RAMS Messages. They are payload-independent are referred to as the RAMS Messages. They are payload-independent
and MUST be used by all RTP-based multicast applications that support and MUST be used by all RTP-based multicast applications that support
rapid acquisition regardless of the payload they carry. rapid acquisition regardless of the payload they carry.
skipping to change at page 28, line 41 skipping to change at page 29, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value : : Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Structure of a TLV element Figure 4: Structure of a TLV element
7.1.1. Vendor-Neutral Extensions 7.1.1. Vendor-Neutral Extensions
If the goal in defining new TLV elements is to extend the If the goal in defining new TLV elements is to extend the
functionality in a vendor-neutral manner, they MUST be registered functionality in a vendor-neutral manner, they MUST be registered
with IANA through the guidelines provided in Section 12.5. with IANA through the guidelines provided in Section 11.5.
The current document defines several vendor-neutral extensions in the The current document defines several vendor-neutral extensions in the
subsequent sections. subsequent sections.
7.1.2. Private Extensions 7.1.2. Private Extensions
It is desirable to allow vendors to use private extensions in a TLV It is desirable to allow vendors to use private extensions in a TLV
format. For interoperability, such extensions MUST NOT collide with format. For interoperability, such extensions MUST NOT collide with
each other. each other.
A certain range of TLV Types (between - and including - 128 and 254 ) A certain range of TLV Types (between - and including - 128 and 254 )
is reserved for private extensions (Refer to Section 12.5). IANA is reserved for private extensions (Refer to Section 11.5). IANA
management for these extensions is unnecessary and they are the management for these extensions is unnecessary and they are the
responsibility of individual vendors. responsibility of individual vendors.
The structure that MUST be used for the private extensions is The structure that MUST be used for the private extensions is
depicted in Figure 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 32, line 44 skipping to change at page 33, line 30
redundancy purposes without incrementing the MSN value. If an redundancy purposes without incrementing the MSN value. If an
updated RAMS-I message will be sent (either with a new information updated RAMS-I message will be sent (either with a new information
or an updated information), the MSN value SHALL be incremented by or an updated information), the MSN value SHALL be incremented by
one. In the MSN field, the regular wrapping rules apply. one. In the MSN field, the regular wrapping rules apply.
o Response (16 bits): Mandatory field that denotes the RS response o Response (16 bits): Mandatory field that denotes the RS response
code for this RAMS-I message. This document defines several code for this RAMS-I message. This document defines several
initial response codes and registers them with IANA. If a new initial response codes and registers them with IANA. If a new
vendor-neutral response code will be defined, it MUST be vendor-neutral response code will be defined, it MUST be
registered with IANA through the guidelines specified in registered with IANA through the guidelines specified in
Section 12.6. If the new response code is intended to be used Section 11.6. If the new response code is intended to be used
privately by a vendor, there is no need for IANA management. privately by a vendor, there is no need for IANA management.
Instead, the vendor MUST use the private extension mechanism Instead, the vendor MUST use the private extension mechanism
(Section 7.1.2) to convey its message and MUST indicate this by (Section 7.1.2) to convey its message and MUST indicate this by
putting zero in the Response field. putting zero in the Response field.
o Media Sender SSRC (32 bits): Optional TLV element that specifies o Media Sender SSRC (32 bits): Optional TLV element that specifies
the media sender SSRC of the unicast burst stream. While this the media sender SSRC of the unicast burst stream. While this
information is already available in the message header, it may be information is already available in the message header, it may be
useful to repeat it in an explicit field. For example, if FT_Ap useful to repeat it in an explicit field. For example, if FT_Ap
that received the RAMS-R message is associated with a single that received the RAMS-R message is associated with a single
skipping to change at page 39, line 42 skipping to change at page 40, line 42
Figure 10: Example SDP for RTP_Rx when RAMS support is enabled Figure 10: Example SDP for RTP_Rx when RAMS support is enabled
In this section, we considered the simplest scenario where the In this section, we considered the simplest scenario where the
primary multicast RTP session carried only one stream and the RTP primary multicast RTP session carried only one stream and the RTP
receiver wanted to rapidly acquire this stream only. Best practices receiver wanted to rapidly acquire this stream only. Best practices
for scenarios where the primary multicast RTP session carries two or for scenarios where the primary multicast RTP session carries two or
more streams or the RTP receiver wants to acquire one or more streams more streams or the RTP receiver wants to acquire one or more streams
from multiple primary multicast RTP sessions at the same time are from multiple primary multicast RTP sessions at the same time are
presented in [I-D.begen-avt-rams-scenarios]. presented in [I-D.begen-avt-rams-scenarios].
Editor's note: Should we keep the text above?
9. NAT Considerations 9. NAT Considerations
For a variety of reasons, one or more NAPT devices (hereafter simply For a variety of reasons, one or more NAPT devices (hereafter simply
called NAT) may exist between RTP_Rx and RS. NATs have a variety of called NAT) may exist between RTP_Rx and RS. NATs have a variety of
operating characteristics for UDP traffic [RFC4787]. For a NAT to operating characteristics for UDP traffic [RFC4787]. For a NAT to
permit traffic from RS to arrive at RTP_Rx, the NAT(s) must first permit traffic from RS to arrive at RTP_Rx, the NAT(s) must first
either: either:
a. See UDP traffic sent from RTP_Rx (which is on the 'inside' of the a. See UDP traffic sent from RTP_Rx (which is on the 'inside' of the
NAT) to RS (which is on the 'outside' of the NAT). This traffic NAT) to RS (which is on the 'outside' of the NAT). This traffic
skipping to change at page 40, line 43 skipping to change at page 41, line 43
repair server by using the RTCP NACK messages for the missing packets repair server by using the RTCP NACK messages for the missing packets
and the repair server retransmits the requested packets over a and the repair server retransmits the requested packets over a
unicast session. Thus, instead of laying out a specific solution for unicast session. Thus, instead of laying out a specific solution for
the RAMS applications, a general solution is introduced in the RAMS applications, a general solution is introduced in
[I-D.begen-avt-ports-for-ucast-mcast-rtp]. [I-D.begen-avt-ports-for-ucast-mcast-rtp].
Applications using RAMS MUST support this solution both on the RS and Applications using RAMS MUST support this solution both on the RS and
RTP_Rx side to allow RTP receivers to use their desired ports and to RTP_Rx side to allow RTP receivers to use their desired ports and to
support RAMS behind NAT devices. support RAMS behind NAT devices.
10. Congestion Control Considerations 10. Security Considerations
Editor's note: Text for this section will be provided by Magnus W.
11. Security Considerations
Applications that are using RAMS make heavy use of the unicast Applications that are using RAMS make heavy use of the unicast
feedback mechanism described in [I-D.ietf-avt-rtcpssm] and the feedback mechanism described in [I-D.ietf-avt-rtcpssm] and the
payload format defined in [RFC4588]. Thus, these applications are payload format defined in [RFC4588]. Thus, these applications are
subject to the general security considerations discussed in subject to the general security considerations discussed in
[I-D.ietf-avt-rtcpssm] and [RFC4588]. In this section, we give an [I-D.ietf-avt-rtcpssm] and [RFC4588]. In this section, we give an
overview of the guidelines and suggestions described in these overview of the guidelines and suggestions described in these
specifications from a RAMS perspective. We also discuss the security specifications from a RAMS perspective. We also discuss the security
considerations that explicitly apply to applications using RAMS. considerations that explicitly apply to applications using RAMS.
skipping to change at page 42, line 27 skipping to change at page 43, line 22
[RFC4588] RECOMMENDS that the cryptography mechanisms are used for [RFC4588] RECOMMENDS that the cryptography mechanisms are used for
the retransmission payload format to provide protection against known the retransmission payload format to provide protection against known
plaintext attacks. As discussed in [RFC4588], the retransmission plaintext attacks. As discussed in [RFC4588], the retransmission
payload format sets the timestamp field in the RTP header to the payload format sets the timestamp field in the RTP header to the
media timestamp of the original packet and this does not compromise media timestamp of the original packet and this does not compromise
the confidentiality. Furthermore, if cryptography is used to provide the confidentiality. Furthermore, if cryptography is used to provide
security services on the original stream, then the same services, security services on the original stream, then the same services,
with equivalent cryptographic strength, MUST be provided on the with equivalent cryptographic strength, MUST be provided on the
retransmission stream per [RFC4588]. retransmission stream per [RFC4588].
12. IANA Considerations 11. IANA Considerations
The following contact information shall be used for all registrations The following contact information shall be used for all registrations
in this document: in this document:
Ali Begen Ali Begen
abegen@cisco.com abegen@cisco.com
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 USA San Jose, CA 95134 USA
Note to the RFC Editor: In the following, please replace "XXXX" with Note to the RFC Editor: In the following, please replace "XXXX" with
the number of this document prior to publication as an RFC. the number of this document prior to publication as an RFC.
12.1. Registration of SDP Attributes 11.1. Registration of SDP Attributes
This document registers a new attribute name in SDP. This document registers a new attribute name in SDP.
SDP Attribute ("att-field"): SDP Attribute ("att-field"):
Attribute name: rams-updates Attribute name: rams-updates
Long form: Support for Updated RAMS Request Messages Long form: Support for Updated RAMS Request Messages
Type of name: att-field Type of name: att-field
Type of attribute: Media level Type of attribute: Media level
Subject to charset: No Subject to charset: No
Purpose: See this document Purpose: See this document
Reference: [RFCXXXX] Reference: [RFCXXXX]
Values: None Values: None
12.2. Registration of SDP Attribute Values 11.2. Registration of SDP Attribute Values
This document registers a new value for the 'nack' attribute to be This document registers a new value for the 'nack' attribute to be
used with the 'rtcp-fb' attribute in SDP. For more information about used with the 'rtcp-fb' attribute in SDP. For more information about
'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: [RFCXXXX] Reference: [RFCXXXX]
12.3. Registration of FMT Values 11.3. Registration of FMT Values
Within the RTPFB range, the following format (FMT) value is Within the RTPFB range, the following format (FMT) value is
registered: registered:
Name: RAMS Name: RAMS
Long name: Rapid Acquisition of Multicast Sessions Long name: Rapid Acquisition of Multicast Sessions
Value: 6 Value: 6
Reference: [RFCXXXX] Reference: [RFCXXXX]
12.4. SFMT Values for RAMS Messages Registry 11.4. SFMT Values for RAMS Messages Registry
This document creates a new sub-registry for the sub-feedback message This document creates a new sub-registry for the sub-feedback message
type (SFMT) values to be used with the FMT value registered for RAMS type (SFMT) values to be used with the FMT value registered for RAMS
messages. The registry is called the SFMT Values for RAMS Messages messages. The registry is called the SFMT Values for RAMS Messages
Registry. This registry is to be managed by the IANA according to Registry. This registry is to be managed by the IANA according to
the Specification Required policy of [RFC5226]. the Specification Required policy of [RFC5226].
The length of the SFMT field in the RAMS messages is a single octet, The length of the SFMT field in the RAMS messages is a single octet,
allowing 256 values. The registry is initialized with the following allowing 256 values. The registry is initialized with the following
entries: entries:
Value Name Reference Value Name Reference
----- -------------------------------------------------- ------------- ----- -------------------------------------------------- -------------
0 Reserved [RFCXXXX] 0 Reserved [RFCXXXX]
1 RAMS Request [RFCXXXX] 1 RAMS Request [RFCXXXX]
2 RAMS Information [RFCXXXX] 2 RAMS Information [RFCXXXX]
3 RAMS Termination [RFCXXXX] 3 RAMS Termination [RFCXXXX]
4-254 Specification Reqired 4-254 Specification Required
255 Reserved [RFCXXXX] 255 Reserved [RFCXXXX]
The SFMT values 0 and 255 are reserved for future use. The SFMT values 0 and 255 are reserved for future use.
Any registration for an unassigned SFMT value MUST contain the Any registration for an unassigned SFMT value MUST contain the
following information: following information:
o Contact information of the one doing the registration, including o Contact information of the one doing the registration, including
at least name, address, and email. at least name, address, and email.
o A detailed description of what the new SFMT represents and how it o A detailed description of what the new SFMT represents and how it
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.
12.5. RAMS TLV Space Registry 11.5. RAMS TLV Space Registry
This document creates a new IANA TLV space registry for the RAMS This document creates a new IANA TLV space registry for the RAMS
extensions. The registry is called the RAMS TLV Space Registry. extensions. The registry is called the RAMS TLV Space Registry.
This registry is to be managed by the IANA according to the This registry is to be managed by the IANA according to the
Specification Required policy of [RFC5226]. Specification Required policy of [RFC5226].
The length of the Type field in the TLV elements is a single octet, The length of the Type field in the TLV elements is a single octet,
allowing 256 values. The Type values 0 and 255 are reserved for allowing 256 values. The Type values 0 and 255 are reserved for
future use. The Type values between (and including) 128 and 254 are future use. The Type values between (and including) 128 and 254 are
reserved for private extensions. reserved for private extensions.
skipping to change at page 45, line 13 skipping to change at page 46, line 13
The registry is initialized with the following entries: The registry is initialized with the following entries:
Type Description Reference Type Description Reference
---- -------------------------------------------------- ------------- ---- -------------------------------------------------- -------------
0 Reserved [RFCXXXX] 0 Reserved [RFCXXXX]
1 Requested Media Sender SSRC(s) [RFCXXXX] 1 Requested Media Sender SSRC(s) [RFCXXXX]
2 Min RAMS Buffer Fill Requirement [RFCXXXX] 2 Min RAMS Buffer Fill Requirement [RFCXXXX]
3 Max RAMS Buffer Fill Requirement [RFCXXXX] 3 Max RAMS Buffer Fill Requirement [RFCXXXX]
4 Max Receive Bitrate [RFCXXXX] 4 Max Receive Bitrate [RFCXXXX]
5 Request for Preamble Only [RFCXXXX] 5 Request for Preamble Only [RFCXXXX]
6-30 Specification Reqired 6-30 Specification Required
31 Media Sender SSRC [RFCXXXX] 31 Media Sender SSRC [RFCXXXX]
32 RTP Seqnum of the First Packet [RFCXXXX] 32 RTP Seqnum of the First Packet [RFCXXXX]
33 Earliest Multicast Join Time [RFCXXXX] 33 Earliest Multicast Join Time [RFCXXXX]
34 Burst Duration [RFCXXXX] 34 Burst Duration [RFCXXXX]
35 Max Transmit Bitrate [RFCXXXX] 35 Max Transmit Bitrate [RFCXXXX]
36-60 Specification Reqired 36-60 Specification Required
61 Extended RTP Seqnum of First Multicast Packet [RFCXXXX] 61 Extended RTP Seqnum of First Multicast Packet [RFCXXXX]
62-127 Specification Reqired 62-127 Specification Required
128-254 No IANA Maintenance 128-254 No IANA Maintenance
255 Reserved [RFCXXXX] 255 Reserved [RFCXXXX]
Any registration for an unassigned Type value MUST contain the Any registration for an unassigned Type value MUST contain the
following information: following information:
o Contact information of the one doing the registration, including o Contact information of the one doing the registration, including
at least name, address, and email. at least name, address, and email.
o A detailed description of what the new TLV element represents and o A detailed description of what the new TLV element represents and
how it shall be interpreted. how it shall be interpreted.
12.6. RAMS Response Code Space Registry 11.6. RAMS Response Code Space Registry
This document creates a new IANA TLV space registry for the RAMS This document creates a new IANA TLV space registry for the RAMS
response codes. The registry is called the RAMS Response Code Space response codes. The registry is called the RAMS Response Code Space
Registry. This registry is to be managed by the IANA according to Registry. This registry is to be managed by the IANA according to
the Specification Required policy of [RFC5226]. the Specification Required policy of [RFC5226].
The length of the Response field is two octets, allowing 65536 codes. The length of the Response field is two octets, allowing 65536 codes.
However, the response codes have been classified and registered However, the response codes have been classified and registered
following an HTTP-style code numbering in this document. New following an HTTP-style code numbering in this document. New
response codes SHALL follow the guidelines below: response codes SHALL follow the guidelines below:
skipping to change at page 46, line 33 skipping to change at page 47, line 33
200 RAMS request has been accepted [RFCXXXX] 200 RAMS request has been accepted [RFCXXXX]
201 Unicast burst has been completed [RFCXXXX] 201 Unicast burst has been completed [RFCXXXX]
400 Invalid RAMS-R message syntax 400 Invalid RAMS-R message syntax
401 Invalid min buffer requirement in RAMS-R message [RFCXXXX] 401 Invalid min buffer requirement in RAMS-R message [RFCXXXX]
402 Invalid max buffer requirement in RAMS-R message [RFCXXXX] 402 Invalid max buffer requirement in RAMS-R message [RFCXXXX]
403 Invalid max bitrate requirement in RAMS-R message [RFCXXXX] 403 Invalid max bitrate requirement in RAMS-R message [RFCXXXX]
500 An unspecified RS internal error has occurred [RFCXXXX] 500 An unspecified RS internal error has occurred [RFCXXXX]
501 RS has no bandwidth to start RAMS session [RFCXXXX] 501 RS has no bandwidth to start RAMS session [RFCXXXX]
502 RS has no CPU available to start RAMS session [RFCXXXX] 502 Burst is terminated due to network congestion [RFCXXXX]
503 RAMS functionality is not available on RS [RFCXXXX] 503 RS has no CPU available to start RAMS session [RFCXXXX]
504 RAMS functionality is not available for RTP_Rx [RFCXXXX] 504 RAMS functionality is not available on RS [RFCXXXX]
505 RAMS functionality is not available for 505 RAMS functionality is not available for RTP_Rx [RFCXXXX]
506 RAMS functionality is not available for
the requested multicast stream [RFCXXXX] the requested multicast stream [RFCXXXX]
506 RS has no valid starting point available for 507 RS has no valid starting point available for
the requested multicast stream [RFCXXXX] the requested multicast stream [RFCXXXX]
507 RS has no reference information available for 508 RS has no reference information available for
the requested multicast stream [RFCXXXX] the requested multicast stream [RFCXXXX]
508 RS has no RTP stream matching the requested SSRC [RFCXXXX] 509 RS has no RTP stream matching the requested SSRC [RFCXXXX]
509 RAMS request to acquire the entire session 510 RAMS request to acquire the entire session
has been denied [RFCXXXX] has been denied [RFCXXXX]
510 Only the preamble information is sent [RFCXXXX] 511 Only the preamble information is sent [RFCXXXX]
511 RAMS request has been denied due to a policy [RFCXXXX] 512 RAMS request has been denied due to a policy [RFCXXXX]
Any registration for an unassigned Response code MUST contain the Any registration for an unassigned Response code MUST contain the
following information: following information:
o Contact information of the one doing the registration, including o Contact information of the one doing the registration, including
at least name, address, and email. at least name, address, and email.
o A detailed description of what the new Response code describes and o A detailed description of what the new Response code describes and
how it shall be interpreted. how it shall be interpreted.
13. Contributors 12. Contributors
Dave Oran and Magnus Westerlund have contributed significantly to Dave Oran and Magnus Westerlund have contributed significantly to
this specification by providing text and solutions to some of the this specification by providing text and solutions to some of the
issues raised during the development of this specification. issues raised during the development of this specification.
14. Acknowledgments 13. Acknowledgments
The following individuals have reviewed the earlier versions of this The following individuals have reviewed the earlier versions of this
specification and provided helpful comments: Colin Perkins, Joerg specification and provided helpful comments: Colin Perkins, Joerg
Ott, Roni Even, Dan Wing, Tony Faustini, Peilin Yang, Jeff Goldberg, Ott, Roni Even, Dan Wing, Tony Faustini, Peilin Yang, Jeff Goldberg,
Muriel Deschanel, Orit Levin, Guy Hirson, Tom Taylor, Xavier Marjou, Muriel Deschanel, Orit Levin, Guy Hirson, Tom Taylor, Xavier Marjou,
Ye-Kui Wang, Zixuan Zou, Ingemar Johansson, Haibin Song, Ning Zong, Ye-Kui Wang, Zixuan Zou, Ingemar Johansson, Haibin Song, Ning Zong,
Jonathan Lennox and Sean Sheedy. Jonathan Lennox and Sean Sheedy.
15. Change Log 14. Change Log
15.1. draft-ietf-avt-rapid-acquisition-for-rtp-06 14.1. draft-ietf-avt-rapid-acquisition-for-rtp-07
The following are the major changes compared to version 06:
o Congestion control considerations text has been added to Section
6.4.
14.2. draft-ietf-avt-rapid-acquisition-for-rtp-06
The following are the major changes compared to version 05: The following are the major changes compared to version 05:
o Comments from WGLC have been addressed. See the mailing list for o Comments from WGLC have been addressed. See the mailing list for
the list of changes. the list of changes.
o Support for multi-stream RTP sessions has been added. o Support for multi-stream RTP sessions has been added.
o NAT section has been revised. o NAT section has been revised.
15.2. draft-ietf-avt-rapid-acquisition-for-rtp-05 14.3. draft-ietf-avt-rapid-acquisition-for-rtp-05
The following are the major changes compared to version 04: The following are the major changes compared to version 04:
o Editorial changes throughout the document. o Editorial changes throughout the document.
15.3. draft-ietf-avt-rapid-acquisition-for-rtp-04 14.4. draft-ietf-avt-rapid-acquisition-for-rtp-04
The following are the major changes compared to version 03: The following are the major changes compared to version 03:
o Clarifications for the definition of RS. o Clarifications for the definition of RS.
o Response codes have been defined. o Response codes have been defined.
15.4. draft-ietf-avt-rapid-acquisition-for-rtp-03 14.5. draft-ietf-avt-rapid-acquisition-for-rtp-03
The following are the major changes compared to version 02: The following are the major changes compared to version 02:
o Clarifications for the RAMS-I message. o Clarifications for the RAMS-I message.
o Type values have been assigned. o Type values have been assigned.
15.5. draft-ietf-avt-rapid-acquisition-for-rtp-02 14.6. draft-ietf-avt-rapid-acquisition-for-rtp-02
The following are the major changes compared to version 01: The following are the major changes compared to version 01:
o Port mapping discussion has been removed since it will be o Port mapping discussion has been removed since it will be
discussed in a separate draft. discussed in a separate draft.
o Security considerations section has been added. o Security considerations section has been added.
o Burst shaping section has been completed. o Burst shaping section has been completed.
o Most of the outstanding open issues have been addressed. o Most of the outstanding open issues have been addressed.
15.6. draft-ietf-avt-rapid-acquisition-for-rtp-01 14.7. 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.
15.7. draft-ietf-avt-rapid-acquisition-for-rtp-00 14.8. 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.
15.8. draft-versteeg-avt-rapid-synchronization-for-rtp-03 14.9. 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.
15.9. draft-versteeg-avt-rapid-synchronization-for-rtp-02 14.10. 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.
15.10. draft-versteeg-avt-rapid-synchronization-for-rtp-01 14.11. 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.
16. References 15. References
16.1. Normative References 15.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 51, line 28 skipping to change at page 52, line 36
Header Extensions", RFC 5285, July 2008. Header Extensions", RFC 5285, July 2008.
[I-D.ietf-avt-rapid-rtp-sync] [I-D.ietf-avt-rapid-rtp-sync]
Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", draft-ietf-avt-rapid-rtp-sync-09 (work in Flows", draft-ietf-avt-rapid-rtp-sync-09 (work in
progress), January 2010. progress), January 2010.
[I-D.begen-avt-ports-for-ucast-mcast-rtp] [I-D.begen-avt-ports-for-ucast-mcast-rtp]
Begen, A. and B. Steeg, "Port Mapping Between Unicast and Begen, A. and B. Steeg, "Port Mapping Between Unicast and
Multicast RTP Sessions", Multicast RTP Sessions",
draft-begen-avt-ports-for-ucast-mcast-rtp-01 (work in draft-begen-avt-ports-for-ucast-mcast-rtp-02 (work in
progress), October 2009. progress), February 2010.
[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.
16.2. Informative References 15.2. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[I-D.begen-avt-rams-scenarios] [I-D.begen-avt-rams-scenarios]
Begen, A., "Considerations for RAMS Scenarios", Begen, A., "Considerations for RAMS Scenarios",
draft-begen-avt-rams-scenarios-00 (work in progress), draft-begen-avt-rams-scenarios-00 (work in progress),
October 2009. October 2009.
[I-D.begen-avt-rtp-mpeg2ts-preamble] [I-D.begen-avt-rtp-mpeg2ts-preamble]
 End of changes. 67 change blocks. 
164 lines changed or deleted 197 lines changed or added

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