draft-ietf-avt-rapid-acquisition-for-rtp-15.txt   draft-ietf-avt-rapid-acquisition-for-rtp-16.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: March 11, 2011 T. VanCaenegem Expires: April 19, 2011 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Z. Vax Z. Vax
Microsoft Corporation Microsoft Corporation
September 7, 2010 October 16, 2010
Unicast-Based Rapid Acquisition of Multicast RTP Sessions Unicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-ietf-avt-rapid-acquisition-for-rtp-15 draft-ietf-avt-rapid-acquisition-for-rtp-16
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 can be large. This is an as the Acquisition Delay, varies and can be large. This is an
undesirable phenomenon for receivers that frequently switch among undesirable phenomenon for receivers that frequently switch among
different multicast sessions, such as video broadcasts. different multicast sessions, such as video broadcasts.
In this document, we describe a method using the existing RTP and In this document, we describe a method using the existing RTP and RTP
RTCP protocol machinery that reduces the acquisition delay. In this Control Protocol (RTCP) machinery that reduces the acquisition delay.
method, an auxiliary unicast RTP session carrying the Reference In this method, an auxiliary unicast RTP session carrying the
Information to the receiver precedes/accompanies the multicast Reference Information to the receiver precedes/accompanies the
stream. This unicast RTP flow can be transmitted at a faster than multicast stream. This unicast RTP flow can be transmitted at a
natural bitrate to further accelerate the acquisition. The faster than natural bitrate to further accelerate the acquisition.
motivating use case for this capability is multicast applications The motivating use case for this capability is multicast applications
that carry real-time compressed audio and video. However, the that carry real-time compressed audio and video. However, the
proposed method can also be used in other types of multicast proposed method can also be used in other types of multicast
applications where the acquisition delay is long enough to be a applications where the acquisition delay is long enough to be a
problem. problem.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 11, 2011. This Internet-Draft will expire on April 19, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 16 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Acquisition of RTP Streams vs. RTP Sessions . . . . . . . 6 1.1. Acquisition of RTP Streams vs. RTP Sessions . . . . . . . 6
1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 7
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Elements of Delay in Multicast Applications . . . . . . . . . 9 4. Elements of Delay in Multicast Applications . . . . . . . . . 9
5. Protocol Design Considerations and Their Effect on 5. Protocol Design Considerations and Their Effect on
Resource Management for Rapid Acquisition . . . . . . . . . . 10 Resource Management for Rapid Acquisition . . . . . . . . . . 10
6. Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . 12 6. Rapid Acquisition of Multicast RTP Sessions (RAMS) . . . . . . 12
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Message Flows . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Synchronization of Primary Multicast Streams . . . . . . . 23 6.3. Synchronization of Primary Multicast Streams . . . . . . . 24
6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 24 6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 24
6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27 6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 27
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 28 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 28
7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 29 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 30 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 30
7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 30 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 30
7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 30 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 31
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 33 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 34
7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 36 7.3.1. Response Code Definitions . . . . . . . . . . . . . . 37
8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 37 7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 39
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 37 8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 40
8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 38 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 40
8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 38 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 41
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 41 8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 41
10. Security Considerations . . . . . . . . . . . . . . . . . . . 42 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 44
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 10. Security Considerations . . . . . . . . . . . . . . . . . . . 45
11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 44 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
11.2. Registration of SDP Attribute Values . . . . . . . . . . . 44 11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 48
11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 44 11.2. Registration of SDP Attribute Values . . . . . . . . . . . 48
11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 45 11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 48
11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 45 11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 49
11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 46 11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 49
11.6.1. Response Code Definitions . . . . . . . . . . . . . . 49 11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 50
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 52
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.1. Normative References . . . . . . . . . . . . . . . . . . . 51 14.1. Normative References . . . . . . . . . . . . . . . . . . . 52
14.2. Informative References . . . . . . . . . . . . . . . . . . 53 14.2. Informative References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
Most multicast flows carry a stream of inter-related data. The Most multicast flows carry a stream of inter-related data. Receivers
receivers need to acquire certain information to start processing any need to acquire certain information to start processing any data sent
data sent in the multicast session. This document refers to this in the multicast session. This document refers to this information
information as Reference Information. The Reference Information is as Reference Information. The Reference Information is
conventionally sent periodically in the multicast session (although conventionally sent periodically in the multicast session (although
its content can change over time) and usually consists of items such its content can change over time) and usually consists of items such
as a description of the schema for the rest of the data, references as a description of the schema for the rest of the data, references
to which data to process, encryption information including keys, as to which data to process, encryption information including keys, as
well as any other information required to process the data in the well as any other information required to process the data in the
multicast stream [IC2009]. multicast stream [IC2009].
Real-time multicast applications require the receivers to buffer Real-time multicast applications require receivers to buffer data.
data. The receiver may have to buffer data to smooth out the network Receivers may have to buffer data to smooth out the network jitter,
jitter, to allow loss-repair methods such as Forward Error Correction to allow loss-repair methods such as Forward Error Correction and
and retransmission to recover the missing packets, and to satisfy the retransmission to recover the missing packets, and to satisfy the
data processing requirements of the application layer. data processing requirements of the application layer.
When a receiver joins a multicast session, it has no control over When a receiver joins a multicast session, it has no control over
what point in the flow is currently being transmitted. Sometimes the what point in the flow is currently being transmitted. Sometimes the
receiver might join the session right before the Reference receiver might join the session right before the Reference
Information is sent in the session. In this case, the required Information is sent in the session. In this case, the required
waiting time is usually minimal. Other times, the receiver might waiting time is usually minimal. Other times, the receiver might
join the session right after the Reference Information has been join the session right after the Reference Information has been
transmitted. In this case, the receiver has to wait for the transmitted. In this case, the receiver has to wait for the
Reference Information to appear again in the flow before it can start Reference Information to appear again in the flow before it can start
processing any multicast data. In some other cases, the Reference processing any multicast data. In some other cases, the Reference
Information is not contiguous in the flow but dispersed over a large Information is not contiguous in the flow but dispersed over a large
period, which forces the receiver to wait for all of the Reference period, which forces the receiver to wait for the whole Reference
Information to arrive before starting to process the rest of the Information to arrive before starting to process the rest of the
data. data.
The net effect of waiting for the Reference Information and waiting The net effect of waiting for the Reference Information and waiting
for various buffers to fill up is that the receivers can experience for various buffers to fill up is that receivers can experience
significantly large delays in data processing. In this document, we significantly large delays in data processing. In this document, we
refer to the difference between the time an RTP receiver joins the refer to the difference between the time an RTP receiver joins the
multicast session and the time the RTP receiver acquires all the multicast session and the time the RTP receiver acquires all the
necessary Reference Information as the Acquisition Delay. The necessary Reference Information as the Acquisition Delay. The
acquisition delay might not be the same for different receivers; it acquisition delay might not be the same for different receivers; it
usually varies depending on the join time, length of the Reference usually varies depending on the join time, length of the Reference
Information repetition (or appearance) interval, size of the Information repetition (or appearance) interval, size of the
Reference Information as well as the application and transport Reference Information as well as the application and transport
properties. properties.
skipping to change at page 6, line 36 skipping to change at page 6, line 36
Figure 1: Rapid acquisition through an intermediary network element Figure 1: Rapid acquisition through an intermediary network element
A principle design goal in this solution is to use the existing tools A principle design goal in this solution is to use the existing tools
in the RTP/RTCP protocol family. This improves the versatility of in the RTP/RTCP protocol family. This improves the versatility of
the existing implementations, and promotes faster deployment and the existing implementations, and promotes faster deployment and
better interoperability. To this effect, we use the unicast better interoperability. To this effect, we use the unicast
retransmission support of RTP [RFC4588] and the capabilities of RTCP retransmission support of RTP [RFC4588] and the capabilities of RTCP
to handle the signaling needed to accomplish the acquisition. to handle the signaling needed to accomplish the acquisition.
A reasonable effort has been made in this specification to design a
solution that reliably works in both engineered and best-effort
networks. However, a proper congestion control combined with the
desired behavior of this solution is difficult to achieve. Rather,
this solution has been designed based on an assumption that the
retransmission server and the RTP receivers have some knowledge about
where the bottleneck between them is. This assumption may not hold
unless both the retransmission server and the RTP receiver are in the
same edge network. This solution is not designed to be used across
any best-effort path of the Internet. Thus, a careful consideration
should be given when deploying this solution in best-effort networks.
1.1. Acquisition of RTP Streams vs. RTP Sessions 1.1. Acquisition of RTP Streams vs. RTP Sessions
In this memo we describe a protocol that handles the rapid In this memo we describe a protocol that handles the rapid
acquisition of a single multicast RTP session (called primary acquisition of a single multicast RTP session (called primary
multicast RTP session) carrying one or more RTP streams (called multicast RTP session) carrying one or more RTP streams (called
primary multicast streams). If desired, multiple instances of this primary multicast streams). If desired, multiple instances of this
protocol may be run in parallel to acquire multiple RTP sessions protocol may be run in parallel to acquire multiple RTP sessions
simultaneously. simultaneously.
When an RTP receiver requests the Reference Information from the When an RTP receiver requests the Reference Information from the
skipping to change at page 8, line 45 skipping to change at page 9, line 8
session used to send one or more unicast burst RTP streams and their session used to send one or more unicast burst RTP streams and their
associated RTCP messages. The terms "burst RTP session" and associated RTCP messages. The terms "burst RTP session" and
"retransmission RTP session" can be used interchangeably. "retransmission RTP session" can be used interchangeably.
(Unicast) Burst (Stream): A unicast stream of RTP retransmission (Unicast) Burst (Stream): A unicast stream of RTP retransmission
packets that enable an RTP receiver to rapidly acquire the Reference packets that enable an RTP receiver to rapidly acquire the Reference
Information associated with a primary multicast stream. Each burst Information associated with a primary multicast stream. Each burst
stream is identified by its Synchronization Source (SSRC) identifier stream is identified by its Synchronization Source (SSRC) identifier
that is unique in the primary multicast RTP session. Following the that is unique in the primary multicast RTP session. Following the
session-multiplexing guidelines in [RFC4588], each unicast burst session-multiplexing guidelines in [RFC4588], each unicast burst
stream will use the same SSRC and CNAME as its primary multicast RTP stream will use the same SSRC and Canonical Name (CNAME) as its
stream. primary multicast RTP stream.
Retransmission Server (RS): The RTP/RTCP endpoint that can generate Retransmission Server (RS): The RTP/RTCP endpoint that can generate
the retransmission packets and the burst streams. The RS may also the retransmission packets and the burst streams. The RS may also
generate other non-retransmission packets to aid rapid acquisition. generate other non-retransmission packets to aid rapid acquisition.
4. Elements of Delay in Multicast Applications 4. Elements of Delay in Multicast Applications
In a source-specific (SSM) multicast delivery system, there are three In a source-specific (SSM) multicast delivery system, there are three
major elements that contribute to the overall acquisition delay when major elements that contribute to the overall acquisition delay when
an RTP receiver switches from one multicast session to another one. an RTP receiver switches from one multicast session to another one.
skipping to change at page 15, line 19 skipping to change at page 15, line 28
other RTP session, the BRS and RTP_Rx regularly send the periodic other RTP session, the BRS and RTP_Rx regularly send the periodic
sender and receiver reports, respectively. sender and receiver reports, respectively.
The unicast burst is started by an RTCP feedback message that is The unicast burst is started by an RTCP feedback message that is
defined in this document based on the common packet format provided defined in this document based on the common packet format provided
in [RFC4585]. An RTP retransmission is triggered by an RTCP NACK in [RFC4585]. An RTP retransmission is triggered by an RTCP NACK
message defined in [RFC4585]. Both of these messages are sent to the message defined in [RFC4585]. Both of these messages are sent to the
FT of the primary multicast RTP session, and can start the unicast FT of the primary multicast RTP session, and can start the unicast
burst/retransmission RTP session. burst/retransmission RTP session.
In the RTP/AVPF profile, there are certain rules that apply to In the extended RTP profile for RTCP-based feedback (RTP/AVPF), there
scheduling of both of these messages sent to the FT in the primary are certain rules that apply to scheduling of both of these messages
multicast RTP session, and these are detailed in Section 3.5 of sent to the FT in the primary multicast RTP session, and these are
[RFC4585]. One of the rules states that in a multi-party session detailed in Section 3.5 of [RFC4585]. One of the rules states that
such as the SSM sessions we are considering in this specification, an in a multi-party session such as the SSM sessions we are considering
RTP_Rx cannot send an RTCP feedback message for a minimum of one in this specification, an RTP_Rx cannot send an RTCP feedback message
second period after joining the session (i.e., Tmin=1.0 second). for a minimum of one second period after joining the session (i.e.,
While this rule has the goal of avoiding problems associated with Tmin=1.0 second). While this rule has the goal of avoiding problems
flash crowds in typical multi-party sessions, it defeats the purpose associated with flash crowds in typical multi-party sessions, it
of rapid acquisition. Furthermore, when RTP receivers delay their defeats the purpose of rapid acquisition. Furthermore, when RTP
messages requesting a burst by a deterministic or even a random receivers delay their messages requesting a burst by a deterministic
amount, it still does not make a difference since such messages are or even a random amount, it still does not make a difference since
not related and their timings are independent from each other. Thus, such messages are not related and their timings are independent from
in this specification we initialize Tmin to zero and allow the RTP each other. Thus, in this specification we initialize Tmin to zero
receivers to send a burst request message right at the beginning. and allow the RTP receivers to send a burst request message right at
For the subsequent messages (e.g., updated requests) during rapid the beginning. For the subsequent messages (e.g., updated requests)
acquisition, the timing rules of [RFC4585] still apply. during rapid acquisition, the timing rules of [RFC4585] still apply.
Figure 3 depicts an example of messaging flow for rapid acquisition. Figure 3 depicts an example of messaging flow for rapid acquisition.
The RTCP feedback messages are explained below. The optional The RTCP feedback messages are explained below. The optional
messages are indicated in parentheses and they might or might not be messages are indicated in parentheses and they might or might not be
present during rapid acquisition. In a scenario where rapid present during rapid acquisition. In a scenario where rapid
acquisition is performed by a feedback target co-located with the acquisition is performed by a feedback target co-located with the
media sender, the same method (with the identical message flows) media sender, the same method (with the identical message flows)
still applies. still applies.
------------------------- -------------------------
skipping to change at page 18, line 23 skipping to change at page 18, line 31
SSRC of the RTP stream associated with the FT_Ap in the RAMS-I SSRC of the RTP stream associated with the FT_Ap in the RAMS-I
message(s) regardless of the media sender SSRC requested in the message(s) regardless of the media sender SSRC requested in the
RAMS-R message. In such cases the 'ssrc' attribute MAY be RAMS-R message. In such cases the 'ssrc' attribute MAY be
omitted from the media description. If the requested SSRC and omitted from the media description. If the requested SSRC and
the actual media sender SSRC do not match, the BRS MUST the actual media sender SSRC do not match, the BRS MUST
explicitly populate the correct media sender SSRC in the initial explicitly populate the correct media sender SSRC in the initial
RAMS-I message (See Section 7.3). RAMS-I message (See Section 7.3).
The FT_Ap could also be associated with an RTP session that The FT_Ap could also be associated with an RTP session that
carries two or more primary multicast streams. If the RTP_Rx carries two or more primary multicast streams. If the RTP_Rx
will issue a collective request to receive the whole primary wants to issue a collective request to receive the whole primary
multicast RTP session, it does not need the 'ssrc' attributes to multicast RTP session, it does not need the 'ssrc' attributes to
be described in the media description. be described in the media description.
If the FT_Ap is associated with two or more RTP sessions, If the FT_Ap is associated with two or more RTP sessions,
RTP_Rx's request will be ambiguous. To avoid any ambiguity, RTP_Rx's request will be ambiguous. To avoid any ambiguity,
each FT_Ap MUST be only associated with a single RTP session. each FT_Ap MUST be only associated with a single RTP session.
If the RTP_Rx is willing to rapidly acquire only a subset of the If the RTP_Rx is willing to rapidly acquire only a subset of the
primary multicast streams, the RTP_Rx MUST list all the media primary multicast streams, the RTP_Rx MUST list all the media
sender SSRC(s) denoting the stream(s) it wishes to acquire in sender SSRC(s) denoting the stream(s) it wishes to acquire in
skipping to change at page 19, line 16 skipping to change at page 19, line 25
In all other cases, the BRS MUST send a separate RAMS-I In all other cases, the BRS MUST send a separate RAMS-I
message with the appropriate 5xx-level response code (as message with the appropriate 5xx-level response code (as
defined in Section 11.6) for each primary multicast stream defined in Section 11.6) for each primary multicast stream
that has been requested by the RTP_Rx but cannot be served by that has been requested by the RTP_Rx but cannot be served by
the BRS. There could be multiple reasons why the BRS has the BRS. There could be multiple reasons why the BRS has
rejected the request, however, the BRS chooses the most rejected the request, however, the BRS chooses the most
appropriate response code to inform the RTP_Rx. appropriate response code to inform the RTP_Rx.
Upon receiving a reject response indicating a transient Upon receiving a reject response indicating a transient
problem such as insufficient BRS or network resources, if the problem such as insufficient BRS or network resources, if the
RTP_Rx wants to retry sending the same request, it MUST RTP_Rx wants to retry sending the same request, the RTP_Rx
follow the RTCP timer rules of [RFC4585] to allow the MUST follow the RTCP timer rules of [RFC4585] to allow the
transient problems go away. However, if the reject response transient problems go away. However, if the reject response
indicates a non-transient problem (such as the ones reported indicates a non-transient problem (such as the ones reported
by response codes 504, 505 and 506), the RTP_Rx MUST NOT by response codes 504, 505 and 506), the RTP_Rx MUST NOT
attempt a retry. attempt a retry. Different response codes have different
scopes. Refer to Section 7.3.1 for details.
The BRS can employ a policing mechanism against the broken The BRS can employ a policing mechanism against the broken
RTP_Rx implementations that are not following these rules. RTP_Rx implementations that are not following these rules.
See Section 10 for details. See Section 10 for details.
* Accept Responses: The BRS MUST send at least one separate * Accept Responses: The BRS MUST send at least one separate
RAMS-I message with the appropriate response code (either RAMS-I message with the appropriate response code (either
zero indicating a private response or response code 200 zero indicating a private response or response code 200
indicating success as listed in Section 11.6) for each indicating success as listed in Section 11.6) for each
primary multicast stream that has been requested by the primary multicast stream that has been requested by the
skipping to change at page 20, line 8 skipping to change at page 20, line 18
When the BRS accepts a request for a primary multicast When the BRS accepts a request for a primary multicast
stream, this field MUST always be populated in the RAMS-I stream, this field MUST always be populated in the RAMS-I
message(s) sent for this particular primary multicast stream. message(s) sent for this particular primary multicast stream.
It is RECOMMENDED that the BRS sends a RAMS-I message at the It is RECOMMENDED that the BRS sends a RAMS-I message at the
start of the burst so that the RTP_Rx can quickly detect any start of the burst so that the RTP_Rx can quickly detect any
missing initial packet(s). missing initial packet(s).
It is possible that the RAMS-I message for a primary multicast It is possible that the RAMS-I message for a primary multicast
stream can get delayed or lost, and the RTP_Rx can start stream can get delayed or lost, and the RTP_Rx can start
receiving RTP packets before receiving a RAMS-I message. An receiving RTP packets before receiving a RAMS-I message. An
RTP-RX implementation MUST NOT assume it will quickly receive RTP_Rx implementation MUST NOT assume it will quickly receive
the initial RAMS-I message. For redundancy purposes, it is the initial RAMS-I message. For redundancy purposes, it is
RECOMMENDED that the BRS repeats the RAMS-I messages multiple RECOMMENDED that the BRS repeats the RAMS-I messages multiple
times as long as it follows the RTCP timer rules defined in times as long as it follows the RTCP timer rules defined in
[RFC4585]. [RFC4585].
4. Unicast Burst: For the primary multicast stream(s) for which 4. Unicast Burst: For the primary multicast stream(s) for which
the request is accepted, the BRS starts sending the unicast the request is accepted, the BRS starts sending the unicast
burst(s) that comprises one or more RTP retransmission packets burst(s) that comprises one or more RTP retransmission packets
sent in the unicast burst RTP session. In addition, in some sent in the unicast burst RTP session. In addition, in some
applications the BRS can send preamble information data to the applications the BRS can send preamble information data to the
skipping to change at page 20, line 33 skipping to change at page 20, line 43
preamble information in a particular format unless the RTP_Rx preamble information in a particular format unless the RTP_Rx
has signaled support for that format in the RAMS-R message has signaled support for that format in the RAMS-R message
through a public or private extension as defined in Section 7.1. through a public or private extension as defined in Section 7.1.
The format of this preamble data is RTP-payload specific and not The format of this preamble data is RTP-payload specific and not
specified here. specified here.
5. Updated Request: The RTP_Rx MAY send an updated RAMS-R message 5. Updated Request: The RTP_Rx MAY send an updated RAMS-R message
(as unicast feedback in the primary multicast RTP session) with (as unicast feedback in the primary multicast RTP session) with
a different value for one or more fields of an earlier RAMS-R a different value for one or more fields of an earlier RAMS-R
message. If there is already a burst planned for or being message. The BRS MUST be able to detect whether a burst is
transmitted to a particular RTP_Rx for a particular stream, the already planned for or being transmitted to this particular
newly arriving RAMS-R is an updated request; otherwise, it is a RTP_Rx for this particular media sender SSRC. If there is an
new request. It is also possible that the RTP_Rx has sent an existing burst planned for or being transmitted, the newly
arriving RAMS-R is an updated request; otherwise it is a new
request. It is also possible that the RTP_Rx has sent an
improperly formatted RAMS-R message or used an invalid value in improperly formatted RAMS-R message or used an invalid value in
the RAMS-R message. If notified by the BRS using a 4xx-level the RAMS-R message. If notified by the BRS using a 4xx-level
response code (as defined in Section 11.6), the RTP_Rx MAY re- response code (as defined in Section 11.6) and only after
send its corrected request only after following the timing rules following the timing rules of [RFC4585], the RTP_Rx MAY re-send
of [RFC4585]. its corrected request.
The BRS determines the identity of the requesting RTP_Rx by The BRS determines the identity of the requesting RTP_Rx by
looking at its canonical name identifier (CNAME item in the SDES looking at its canonical name identifier (CNAME item in the SDES
source description). Thus, the RTP_Rx MUST choose a globally source description). Thus, the RTP_Rx MUST choose a method that
unique CNAME identifier. Different such ways are provided in ensures it uses a unique CNAME identifier. Different such ways
[I-D.ietf-avt-rtp-cnames]. In addition to one or more fields are provided in [I-D.ietf-avt-rtp-cnames]. In addition to one
with updated values, an updated RAMS-R message may also include or more fields with updated values, an updated RAMS-R message
the fields whose values did not change. may also include the fields whose values did not change.
Upon receiving an updated request, the BRS can use the updated Upon receiving an updated request, the BRS can use the updated
values for sending/shaping the burst, or refine the values and values for sending/shaping the burst, or refine the values and
use the refined values for sending/shaping the burst. use the refined values for sending/shaping the burst.
Subsequently, the BRS MAY send an updated RAMS-I message in the Subsequently, the BRS MAY send an updated RAMS-I message in the
unicast burst RTP session to indicate the changes it made. unicast burst RTP session to indicate the changes it made.
It is an implementation-dependent decision for an RTP_RX whether It is an implementation-dependent decision for an RTP_RX whether
and when to send an updated request. and when to send an updated request. However, note that the
updated request messages can get delayed and arrive at the BRS
after the initial unicast burst was completed. In this case,
the updated request message can trigger a new unicast burst and
by then if the RTP_Rx has already started receiving multicast
data, a congestion is likely to occur. In this case, the RTP_Rx
can detect this only after a delay and then it can try to
terminate the new burst. However, in the mean time, the RTP_Rx
can experience packet loss or other problems. This and other
similar corner cases SHOULD be carefully examined if updated
requests are to be used.
6. Updated Response: The BRS can send more than one RAMS-I 6. Updated Response: The BRS can send more than one RAMS-I
messages in the unicast burst RTP session, e.g., to update the messages in the unicast burst RTP session, e.g., to update the
value of one or more fields in an earlier RAMS-I message. The value of one or more fields in an earlier RAMS-I message. The
updated RAMS-I messages might or might not be a direct response updated RAMS-I messages might or might not be a direct response
to a RAMS-R message. The BRS can also send updated RAMS-I to a RAMS-R message. The BRS can also send updated RAMS-I
messages to signal the RTP_Rx in real time to join the SSM messages to signal the RTP_Rx in real time to join the SSM
session, when the BRS had already sent an initial RAMS-I session, when the BRS had already sent an initial RAMS-I
message, e.g., at the start of the burst. The RTP_Rx depends on message, e.g., at the start of the burst. The RTP_Rx depends on
the BRS to learn the join time, which can be conveyed by the the BRS to learn the join time, which can be conveyed by the
skipping to change at page 22, line 17 skipping to change at page 22, line 40
may need to ask the BRS to terminate the burst prematurely or at may need to ask the BRS to terminate the burst prematurely or at
a specific sequence number. For this purpose, the RTP_Rx uses a specific sequence number. For this purpose, the RTP_Rx uses
the RAMS-Termination (RAMS-T) message sent as RTCP feedback in the RAMS-Termination (RAMS-T) message sent as RTCP feedback in
the unicast burst RTP session. A separate RAMS-T message is the unicast burst RTP session. A separate RAMS-T message is
sent for each primary multicast stream served by the BRS unless sent for each primary multicast stream served by the BRS unless
an RTCP BYE message has been sent in the unicast burst RTP an RTCP BYE message has been sent in the unicast burst RTP
session as described in Step 10. For the burst requests that session as described in Step 10. For the burst requests that
were rejected by the BRS, there is no need to send a RAMS-T were rejected by the BRS, there is no need to send a RAMS-T
message. message.
If the RTP_Rx wants to terminate a burst prematurely, it SHALL If the RTP_Rx wants to terminate a burst prematurely, it MUST
send a RAMS-T message for the SSRC of the primary multicast send a RAMS-T message for the SSRC of the primary multicast
stream it wishes to terminate. This message is sent in the stream it wishes to terminate. This message is sent in the
unicast burst RTP session. Upon receiving this message, the BRS unicast burst RTP session. Upon receiving this message, the BRS
MUST terminate the unicast burst. If the RTP_Rx requested to MUST terminate the unicast burst. If the RTP_Rx requested to
acquire the entire primary multicast RTP session but wants to acquire the entire primary multicast RTP session but wants to
terminate this request before it learns the individual media terminate this request before it learns the individual media
sender SSRC(s) via RAMS-I message(s) or RTP packets, the RTP_Rx sender SSRC(s) via RAMS-I message(s) or RTP packets, the RTP_Rx
cannot use RAMS-T message(s) and thus MUST send an RTCP BYE cannot use RAMS-T message(s) and thus MUST send an RTCP BYE
message in the unicast burst RTP session to terminate the message in the unicast burst RTP session to terminate the
request. request.
Otherwise, the default behavior for the RTP_Rx is to send a Otherwise, the default behavior for the RTP_Rx is to send a
RAMS-T message in the unicast burst RTP session immediately RAMS-T message in the unicast burst RTP session immediately
after it joins the multicast session and started receiving after it joins the multicast session and has started receiving
multicast packets. In that case, the RTP_Rx SHALL send a RAMS-T multicast packets. In that case, the RTP_Rx MUST send a RAMS-T
message with the sequence number of the first RTP packet message with the sequence number of the first RTP packet
received in the primary multicast stream. Then, the BRS MUST received in the primary multicast stream. Then, the BRS MUST
terminate the respective burst after it sends the unicast burst terminate the respective burst after it sends the unicast burst
packet whose Original Sequence Number (OSN) field in the RTP packet whose Original Sequence Number (OSN) field in the RTP
retransmission payload header matches this number minus one. If retransmission payload header matches this number minus one. If
the BRS has already sent that unicast burst packet when the the BRS has already sent that unicast burst packet when the
RAMS-T message arrives, the BRS MUST terminate the respective RAMS-T message arrives, the BRS MUST terminate the respective
burst immediately. burst immediately.
If an RTCP BYE message has not been issued yet as described in If an RTCP BYE message has not been issued yet as described in
skipping to change at page 28, line 36 skipping to change at page 29, line 20
| SSRC of packet sender | | SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source | | SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) : : Feedback Control Information (FCI) :
: : : :
Figure 4: The common packet format for the RTCP feedback messages Figure 4: The common packet format for the RTCP feedback messages
Each feedback message has a fixed-length field for version, padding, Each feedback message has a fixed-length field for version, padding,
feedback message type (FMT), payload type (PT), length, SSRC of feedback message type (FMT), packet type (PT), length, SSRC of packet
packet sender, SSRC of media sender as well as a variable-length sender, SSRC of media source as well as a variable-length field for
field for feedback control information (FCI). feedback control information (FCI).
In the RAMS messages, the PT field is set to RTPFB (205) and the FMT In the RAMS messages, the PT field is set to RTPFB (205) and the FMT
field is set to RAMS (6). Individual RAMS messages are identified by field is set to RAMS (6). Individual RAMS messages are identified by
a sub-field called Sub Feedback Message Type (SFMT). Any Reserved a sub-field called Sub Feedback Message Type (SFMT). Any Reserved
field SHALL be set to zero and ignored. field SHALL be set to zero and ignored.
Depending on the specific scenario and timeliness/importance of a Depending on the specific scenario and timeliness/importance of a
RAMS message, it can be desirable to send it in a reduced-size RTCP RAMS message, it can be desirable to send it in a reduced-size RTCP
packet [RFC5506]. However, unless support for [RFC5506] has been packet [RFC5506]. However, unless support for [RFC5506] has been
signaled, compound RTCP packets MUST be used by following [RFC3550] signaled, compound RTCP packets MUST be used by following [RFC3550]
skipping to change at page 29, line 32 skipping to change at page 30, line 15
any padding that is required for alignment. any padding that is required for alignment.
o Value: Variable-size set of octets that contains the specific o Value: Variable-size set of octets that contains the specific
value for the parameter. value for the parameter.
In the extensions, the Reserved field SHALL be set to zero and In the extensions, the Reserved field SHALL be set to zero and
ignored. If a TLV element does not fall on a 32-bit boundary, the ignored. If a TLV element does not fall on a 32-bit boundary, the
last word MUST be padded to the boundary using further bits set to last word MUST be padded to the boundary using further bits set to
zero. zero.
The vendor-neutral and private extensions MAY exist in any RAMS An RTP_Rx or BRS MAY include vendor-neutral and private extensions in
message. Such extensions MUST be placed after the mandatory fields any RAMS message. The RTP_Rx or BRS MUST place such extensions after
and mandatory TLV elements (if any), and MAY be placed in any order. the mandatory fields and mandatory TLV elements (if any), and MAY
In a RAMS message, multiple TLV elements with the same Type value place such extensions in any order. The RTP_Rx or BRS MUST NOT
MUST NOT exist. include multiple TLV elements with the same Type value in a RAMS
message.
The support for extensions (unless specified otherwise) is OPTIONAL. The support for extensions (unless specified otherwise) is OPTIONAL.
An RTP_Rx or BRS receiving a vendor-neutral or private extension that An RTP_Rx or BRS receiving a vendor-neutral or private extension that
it does not understand MUST ignore that extension. it does not understand MUST ignore that extension.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length | | Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 32, line 45 skipping to change at page 33, line 36
o Max Receive Bitrate (64 bits): Optional TLV element that denotes o Max Receive Bitrate (64 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) at which the RTP_Rx can the maximum bitrate (in bits per second) at which the RTP_Rx can
process the aggregation of the unicast burst(s) and any payload- process the aggregation of the unicast burst(s) and any payload-
specific information that will be provided by the BRS. The limits specific information that will be provided by the BRS. The limits
can include local receiver limits as well as network limits that can include local receiver limits as well as network limits that
are known to the receiver. are known to the receiver.
If specified, the total bitrate of the unicast burst(s) plus any If specified, the total bitrate of the unicast burst(s) plus any
payload-specific information MUST NOT be larger than this value. payload-specific information MUST NOT be larger than this value.
Otherwise, congestion and packet loss may occur. Otherwise, congestion and packet loss are more likely to occur.
Type: 4 Type: 4
o Preamble-only Allowed (0 bits): Optional TLV element that o Preamble-only Allowed (0 bits): Optional TLV element that
indicates that the RTP_Rx is willing to receive only the preamble indicates that the RTP_Rx is willing to receive only the preamble
information for the desired primary multicast stream(s) in case information for the desired primary multicast stream(s) in case
the BRS cannot send the unicast burst stream(s) (In such cases, the BRS cannot send the unicast burst stream(s) (In such cases,
the BRS will not accept the request, but will send a response code the BRS will not accept the request, but will send a response code
511 in the RAMS-I message as defined in Section 11.6). Note that 511 in the RAMS-I message as defined in Section 11.6). Note that
the RTP_Rx signals the particular preamble format(s) it supports the RTP_Rx signals the particular preamble format(s) it supports
skipping to change at page 34, line 28 skipping to change at page 35, line 25
A RAMS-I message has the following fields: A RAMS-I message has the following fields:
o Message Sequence Number (8 bits) : Mandatory field that denotes o Message Sequence Number (8 bits) : Mandatory field that denotes
the sequence number of the RAMS-I message for the particular media the sequence number of the RAMS-I message for the particular media
sender SSRC specified in the message header. The MSN value SHALL sender SSRC specified in the message header. The MSN value SHALL
be set to zero only when a new RAMS request is received. During be set to zero only when a new RAMS request is received. During
rapid acquisition, the same RAMS-I message MAY be repeated for rapid acquisition, the same RAMS-I message MAY be repeated for
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. Note
that if the RTP_Rx has sent an updated request, it MUST check
every RAMS-I message entirely regardless of whether the MSN value
has changed or not.
o Response (16 bits): Mandatory field that denotes the response o Response (16 bits): Mandatory field that denotes the response
code for this RAMS-I message. This document defines several code for this RAMS-I message. This document defines several
initial response codes in Section 11.6 and registers them with initial response codes in Section 7.3.1 and registers them with
IANA. If a new vendor-neutral response code will be defined, it IANA in Section 11.6. If a new vendor-neutral response code will
MUST be registered with IANA through the guidelines specified in be defined, it MUST be registered with IANA through the guidelines
Section 11.6. If the new response code is intended to be used specified in Section 11.6. If the new response code is intended
privately by a vendor, there is no need for IANA management. to be used privately by a vendor, there is no need for IANA
Instead, the vendor MUST use the private extension mechanism management. Instead, the vendor MUST use the private extension
(Section 7.1.2) to convey its message and MUST indicate this by mechanism (Section 7.1.2) to convey its message and MUST indicate
putting zero in the Response field. this by putting zero in the Response field.
When the RTP_Rx receives a RAMS-I message with a response code When the RTP_Rx receives a RAMS-I message with a response code
that it does not understand, the RTP_Rx MUST send a RAMS-T message that it does not understand, the RTP_Rx MUST send a RAMS-T message
immediately to the BRS. immediately to the BRS.
The following TLV elements have been defined for the RAMS-I messages: The following TLV elements have been defined for the RAMS-I messages:
o Media Sender SSRC (32 bits): Optional TLV element that specifies o Media Sender SSRC (32 bits): Optional TLV element that specifies
the media sender SSRC of the unicast burst stream. While this the media sender SSRC of the unicast burst stream. If the FT_Ap
information is already available in the message header, it can be that received the RAMS-R message is associated with a single
useful to repeat it in an explicit field. If the FT_Ap that primary multicast stream but the requested media sender SSRC does
received the RAMS-R message is associated with a single primary not match the SSRC of the RTP stream associated with this FT_Ap,
multicast stream but the requested media sender SSRC does not the BRS includes this TLV element in the initial RAMS-I message to
match the SSRC of the RTP stream associated with this FT_Ap, the let the RTP_Rx know that the media sender SSRC has changed. If
BRS includes this TLV element in the initial RAMS-I message to let the two SSRCs match, there is no need to include this TLV element.
the RTP_Rx know that the media sender SSRC has changed. If the
two SSRCs match, there is no need to include this TLV element.
Type: 31 Type: 31
o RTP Seqnum of the First Packet (16 bits): TLV element that o RTP Seqnum of the First Packet (16 bits): TLV element that
specifies the RTP sequence number of the first packet that will be specifies the RTP sequence number of the first packet that will be
sent in the respective unicast RTP stream. This allows the RTP_Rx sent in the respective unicast RTP stream. This allows the RTP_Rx
to know whether one or more packets sent by the BRS have been to know whether one or more packets sent by the BRS have been
dropped at the beginning of the stream. If the BRS accepts the dropped at the beginning of the stream. If the BRS accepts the
RAMS request, this element exists. If the BRS rejects the RAMS RAMS request, this element exists. If the BRS rejects the RAMS
request, this element SHALL NOT exist. request, this element SHALL NOT exist.
Type: 32 Type: 32
o Earliest Multicast Join Time (32 bits): TLV element that o Earliest Multicast Join Time (32 bits): TLV element that
specifies the delta time (in ms) between the arrival of the first specifies the delta time (in ms) between the arrival of the first
RTP packet in the unicast RTP stream (which could be a burst RTP packet in the unicast RTP stream (which could be a burst
packet or a payload-specific packet) and the earliest time instant packet or a payload-specific packet) and the earliest time instant
when an RTP_Rx MAY send an SFGMP Join message to join the when an RTP_Rx MAY send an SFGMP Join message to join the
multicast session. A zero value in this field means that the multicast session. A zero value in this field means that the
RTP_Rx MAY send the SFGMP Join message right away. RTP_Rx MAY send the SFGMP Join message right away. If the RTP_Rx
does not want to wait until the earliest multicast join time, it
MAY send a RAMS-T message and only after a reasonable amount of
time, it MAY join the SSM session.
If the RAMS request has been accepted, the BRS sends this field at If the RAMS request has been accepted, the BRS sends this field at
least once, so that the RTP_Rx knows when to join the multicast least once, so that the RTP_Rx knows when to join the multicast
session. If the burst request has been rejected as indicated in session. If the burst request has been rejected as indicated in
the Response field, this field MUST be set to zero. In that case, the Response field, this field MUST be set to zero. In that case,
it is up to the RTP_Rx when or whether to join the multicast it is up to the RTP_Rx when or whether to join the multicast
session. session.
When the BRS serves two or more bursts and sends a separate RAMS-I When the BRS serves two or more bursts and sends a separate RAMS-I
message for each burst, the join times specified in these RAMS-I message for each burst, the join times specified in these RAMS-I
skipping to change at page 36, line 22 skipping to change at page 37, line 22
omitted or set to zero. omitted or set to zero.
Type: 34 Type: 34
o Max Transmit Bitrate (64 bits): Optional TLV element that denotes o Max Transmit Bitrate (64 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that will be used by the the maximum bitrate (in bits per second) that will be used by the
BRS for the RTP stream associated with this RAMS-I message. BRS for the RTP stream associated with this RAMS-I message.
Type: 35 Type: 35
7.3.1. Response Code Definitions
1xx-Level Response Codes: These response codes are sent for
informational purposes.
o 100: This is used when the BRS wants to update a value that was
sent earlier to the RTP_Rx.
2xx-Level Response Codes: These response codes are sent to indicate
success.
o 200: This is used when the server accepts the RAMS request.
o 201: This is used when the unicast burst has been completed and
the BRS wants to notify the RTP_Rx.
4xx-Level Response Codes: These response codes are sent to indicate
that the message sent by the RTP_Rx is either improperly formatted or
contains an invalid value. The rules the RTP_Rx needs to follow upon
receiving one of these response codes are outlined in Step 5 in
Section 6.2. The 4xx-level response codes are also used as status
codes in the Multicast Acquisition Report Block
[I-D.ietf-avt-multicast-acq-rtcp-xr] in order to collect RTP_Rx-based
error conditions.
o 400: This is used when the RAMS-R message is improperly
formatted.
o 401: This is used when the minimum RAMS buffer fill requirement
value indicated in the RAMS-R message is invalid.
o 402: This is used when the maximum RAMS buffer fill requirement
value indicated in the RAMS-R message is invalid.
o 403: This is used when the maximum receive bitrate value
indicated in the RAMS-R message is insufficient.
o 404: This is used when the RAMS-T message is improperly
formatted.
5xx-Level Response Codes: These response codes are sent to indicate
an error on the BRS side. The rules the RTP_Rx needs to follow upon
receiving one of these response codes are outlined in Step 3 in
Section 6.2 and Section 7.2. The 5xx-level response codes are also
used as status codes in the Multicast Acquisition Report Block
[I-D.ietf-avt-multicast-acq-rtcp-xr] in order to collect BRS-based
error conditions.
o 500: This is used when the BRS has experienced an internal error
and cannot accept the RAMS request.
o 501: This is used when the BRS does not have enough bandwidth to
send the unicast burst stream.
o 502: This is used when the BRS terminates the unicast burst
stream due to network congestion.
o 503: This is used when the BRS does not have enough CPU resources
to send the unicast burst stream.
o 504: This is used when the BRS does not support sending a unicast
burst stream.
o 505: This is used when the requesting RTP_Rx is not eligible to
receive a unicast burst stream.
o 506: This is used when RAMS functionality is not enabled for the
requested multicast stream.
o 507: This is used when the BRS cannot find a valid starting point
for the unicast burst stream satisfying the RTP_Rx's requirements.
o 508: This is used when the BRS cannot find the essential
reference information for the requested multicast stream.
o 509: This is used when the BRS cannot match the requested SSRC to
any of the streams it is serving.
o 510: This is used when the BRS cannot serve the requested entire
session.
o 511: This is used when the BRS sends only the preamble
information but not the whole unicast burst stream.
o 512: This is used when the RAMS request is denied due to a policy
specified for the requested multicast stream, requesting RTP_Rx or
this particular BRS.
7.4. RAMS Termination 7.4. RAMS Termination
The RAMS Termination (RAMS-T) message is identified by SFMT=3. The RAMS Termination (RAMS-T) message is identified by SFMT=3.
The RAMS Termination is used to assist the BRS in determining when to The RAMS Termination is used to assist the BRS in determining when to
stop the burst. A separate RAMS-T message is sent in the unicast stop the burst. A separate RAMS-T message is sent in the unicast
burst RTP session by the RTP_Rx for each primary multicast stream burst RTP session by the RTP_Rx for each primary multicast stream
that has been served by the BRS. Each of these RAMS-T messages has that has been served by the BRS. Each of these RAMS-T message's
the appropriate media sender SSRC populated in its message header. media sender SSRC field SHALL BE populated with the SSRC of the media
stream to be terminated. If the media sender SSRC populated in the
RAMS-T message does not match the SSRC of the burst served by the
BRS, BRS SHALL ignore the RAMS-T message.
If the RTP_Rx wants the BRS to stop a burst prematurely, it sends a If the RTP_Rx wants the BRS to stop a burst prematurely, it sends a
RAMS-T message as described below. Upon receiving this message, the RAMS-T message as described below. Upon receiving this message, the
BRS stops the respective burst immediately. If the RTP_Rx wants the BRS stops the respective burst immediately. If the RTP_Rx wants the
BRS to terminate all of the bursts, it needs to send all of the BRS to terminate all of the bursts, it needs to send all of the
respective RAMS-T messages in a single compound RTCP packet. respective RAMS-T messages in a single compound RTCP packet.
The default behavior for the RTP_Rx is to send a RAMS-T message The default behavior for the RTP_Rx is to send a RAMS-T message
immediately after it joined the multicast session and started immediately after it joined the multicast session and started
receiving multicast packets. In that case, the RTP_Rx includes the receiving multicast packets. In that case, the RTP_Rx includes the
skipping to change at page 38, line 32 skipping to change at page 41, line 32
o The RTCP extensions for SSM sessions with unicast feedback o The RTCP extensions for SSM sessions with unicast feedback
[RFC5760] [RFC5760]
o The multicast RTCP port attribute [I-D.ietf-avt-rtcp-port-for-ssm] o The multicast RTCP port attribute [I-D.ietf-avt-rtcp-port-for-ssm]
o Multiplexing RTP and RTCP on a single port on both endpoints in o Multiplexing RTP and RTCP on a single port on both endpoints in
the unicast session[RFC5761] the unicast session[RFC5761]
The support for the source-specific media attributes [RFC5576] can The support for the source-specific media attributes [RFC5576] can
also be needed. also be needed when the 'ssrc' attribute is to be used for the media
descriptions.
8.3. Example and Discussion 8.3. Example and Discussion
This section provides a declarative SDP [RFC4566] example for This section provides a declarative SDP [RFC4566] example (for the
enabling rapid acquisition of multicast RTP sessions. RTP_Rx side) for enabling rapid acquisition of multicast RTP
sessions.
v=0 v=0
o=ali 1122334455 1122334466 IN IP4 rams.example.com o=ali 1122334455 1122334466 IN IP4 rams.example.com
s=Rapid Acquisition Example s=Rapid Acquisition Example
t=0 0 t=0 0
a=group:FID 1 2 a=group:FID 1 2
a=rtcp-unicast:rsi a=rtcp-unicast:rsi
m=video 41000 RTP/AVPF 98 m=video 41000 RTP/AVPF 98
i=Primary Multicast Stream i=Primary Multicast Stream
c=IN IP4 233.252.0.2/255 c=IN IP4 233.252.0.2/255
skipping to change at page 41, line 10 skipping to change at page 44, line 10
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_Rx primary multicast RTP session carried only one stream and the RTP_Rx
wanted to rapidly acquire this stream only. Best practices for wanted to rapidly acquire this stream only. Best practices for
scenarios where the primary multicast RTP session carries two or more scenarios where the primary multicast RTP session carries two or more
streams or the RTP_Rx wants to acquire one or more streams from streams or the RTP_Rx wants to acquire one or more streams from
multiple primary multicast RTP sessions at the same time are 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].
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 Network Address Port
called NAT) can exist between the RTP_Rx and RS. NATs have a variety Translators (NAPT - hereafter simply called NAT) can exist between
of operating characteristics for UDP traffic [RFC4787]. For a NAT to the RTP_Rx and RS. NATs have a variety of operating characteristics
permit traffic from the BRS to arrive at the RTP_Rx, the NAT(s) must for UDP traffic [RFC4787]. For a NAT to permit traffic from the BRS
first either: to arrive at the RTP_Rx, the NAT(s) must first either:
a. See UDP traffic sent from the RTP_Rx (which is on the 'inside' of a. See UDP (or DCCP) traffic sent from the RTP_Rx (which is on the
the NAT) to the BRS (which is on the 'outside' of the NAT). This 'inside' of the NAT) to the BRS (which is on the 'outside' of the
traffic has the same transport address as the subsequent response NAT). This traffic has the same transport address as the
traffic, or; subsequent response traffic, or;
b. Be configured to forward certain ports (e.g., using HTML b. Be configured to forward certain ports (e.g., using HTML
configuration and UPnP IGD [UPnP-IGD]). Details of this are out configuration or UPnP IGD [UPnP-IGD]). Details of this are out
of scope of this document. of scope of this document.
For both (a) and (b), the RTP_Rx is responsible for maintaining the For both (a) and (b), the RTP_Rx is responsible for maintaining the
NAT's state if it wants to receive traffic from the BRS on that port. NAT's state if it wants to receive traffic from the BRS on that port.
For (a), the RTP_Rx MUST send UDP traffic to keep the NAT binding For (a), the RTP_Rx MUST send UDP traffic to keep the NAT binding
alive, at least every 30 seconds [RFC4787]. While (a) is more like alive, at least every 30 seconds [RFC4787]. While (a) is more like
an automatic/dynamic configuration, (b) is more like a manual/static an automatic/dynamic configuration, (b) is more like a manual/static
configuration. configuration.
When the RTP_Rx sends a request (RAMS-R) message to the FT as unicast When the RTP_Rx sends a request (RAMS-R) message to the FT as unicast
skipping to change at page 42, line 11 skipping to change at page 45, line 11
take place whenever the RTP_Rx intends to make use of the RAMS take place whenever the RTP_Rx intends to make use of the RAMS
protocol for rapidly acquiring a specific multicast RTP session, protocol for rapidly acquiring a specific multicast RTP session,
prior to joining the associated SSM session. prior to joining the associated SSM session.
10. Security Considerations 10. Security Considerations
Applications that are using RAMS make heavy use of the unicast Applications that are using RAMS make heavy use of the unicast
feedback mechanism described in [RFC5760], the payload format defined feedback mechanism described in [RFC5760], the payload format defined
in [RFC4588] and the port mapping solution specified in in [RFC4588] and the port mapping solution specified in
[I-D.ietf-avt-ports-for-ucast-mcast-rtp]. Thus, these applications [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. Thus, these applications
are subject to the general security considerations discussed in are subject to the general security considerations discussed in those
[RFC5760], [RFC4588] and [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. documents. In particular, the threats and risks discussed in
In this section, we give an overview of the guidelines and [RFC5760] need to be considered carefully. In this section, we give
suggestions described in these specifications from a RAMS an overview of the guidelines and suggestions described in these
perspective. We also discuss the security considerations that specifications from a RAMS perspective. We also discuss the security
explicitly apply to applications using RAMS. considerations that explicitly apply to applications using RAMS.
First of all, much of the session description information is First of all, much of the session description information is
available in the SDP descriptions that are distributed to the media available in the SDP descriptions that are distributed to the media
senders, retransmission servers and RTP receivers. Adequate security senders, retransmission servers and RTP receivers. Adequate security
measures are RECOMMENDED to ensure the integrity and authenticity of measures are RECOMMENDED to ensure the integrity and authenticity of
the SDP descriptions so that transport addresses of the media the SDP descriptions so that transport addresses of the media
senders, distribution sources, feedback targets as well as other senders, distribution sources, feedback targets as well as other
session-specific information can be protected. session-specific information can be protected. See [RFC4566] for
details.
Compared to an RTCP NACK message that triggers one or more Compared to an RTCP NACK message that triggers one or more
retransmissions, a RAMS Request (RAMS-R) message can trigger a new retransmissions, a RAMS Request (RAMS-R) message can trigger a new
burst stream to be sent by the retransmission server. Depending on burst stream to be sent by the retransmission server. Depending on
the application-specific requirements and conditions existing at the the application-specific requirements and conditions existing at the
time of the RAMS-R reception by the retransmission server, the time of the RAMS-R reception by the retransmission server, the
resulting burst stream can potentially contain a large number of resulting burst stream can potentially contain a large number of
retransmission packets. Since these packets are sent at a faster retransmission packets. Since these packets are sent faster than the
than the nominal rate, RAMS consumes more resources on the nominal rate, RAMS consumes more resources on the retransmission
retransmission servers, RTP receivers and the network. In servers, RTP receivers and the network. In particular, this can make
particular, this can make denial-of-service attacks more intense, and denial-of-service (DoS) attacks more intense, and hence, more harmful
hence, more harmful than attacks that target ordinary retransmission than attacks that target ordinary retransmission sessions.
sessions.
Following the suggestions given in [RFC4588], counter-measures SHOULD As RAMS messages are sent as RTCP messages, following the suggestions
be taken to prevent tampered or spoofed RTCP packets. Tampered given in [RFC4588], counter-measures SHOULD be taken to prevent
RAMS-R messages can trigger inappropriate burst streams or alter the tampered or spoofed RTCP packets. Tampered RAMS-R messages can
existing burst streams in an inappropriate way. For example, if the trigger inappropriate burst streams or alter the existing burst
Max Receive Bitrate field is altered by a tampered RAMS-R message, streams in an inappropriate way. For example, if the Max Receive
the updated burst can overflow the buffer at the receiver side, or Bitrate field is altered by a tampered RAMS-R message, the updated
oppositely, can slow down the burst to the point that it becomes burst can overflow the buffer at the receiver side, or oppositely,
useless. Tampered RAMS Termination (RAMS-T) messages can terminate can slow down the burst to the point that it becomes useless.
valid burst streams prematurely resulting in gaps in the received RTP Tampered RAMS Termination (RAMS-T) messages can terminate valid burst
packets. RAMS Information (RAMS-I) messages contain fields that are streams prematurely resulting in gaps in the received RTP packets.
critical for a successful rapid acquisition. Any tampered RAMS Information (RAMS-I) messages contain fields that are critical
information in the RAMS-I message can easily cause an RTP receiver to for a successful rapid acquisition. Any tampered information in the
make wrong decisions. Consequently, the RAMS operation can fail. RAMS-I message can easily cause an RTP receiver to make wrong
decisions. Consequently, the RAMS operation can fail.
While most of the denial-of-service attacks can be prevented by the RTCP BYE messages are similar to RAMS-T messages in the sense that
they can be used to stop an existing burst. The CNAME of an RTP
receiver is used to bind the RTCP BYE message to an existing burst.
Thus, one should be careful if the CNAMEs are reasonably easy to
guess and off-path attacks can be performed. Also note that the
CNAMEs might be redistributed to all participants in the multicast
group (as in ASM or the simple feedback model of [RFC5760]).
The retransmission server has to consider if values indicated in a
RAMS-R message are reasonable. For example, a request demanding a
large value of many seconds in the Min RAMS Buffer Fill Requirement
element should, unless special uses cases exist, likely be rejected
since it is likely to be an attempt to prolong a DoS attack on the
retransmission server, RTP receiver and/or the network. The Max
Receive Bitrate could also be set to a very large value to try to get
the retransmission server to cause massive congestion by bursting at
a bitrate that will not be supported by the network. An RTP_Rx
should also consider if the values for the Earliest Multicast Join
Time and Burst Duration indicated by the retransmission server in a
RAMS-I message are reasonable. For example, if the burst packets
stop arriving and the join time is still significantly far into the
future, this could be a sign of a man-in-the-middle attack where the
RAMS-I message has been manipulated by an attacker.
A basic mitigation against DoS attacks introduced by an attacker
injecting tampered RAMS messages is source address validation
[RFC2827]. Also, most of the DoS attacks can be prevented by the
integrity and authenticity checks enabled by Secure RTP (SRTP) integrity and authenticity checks enabled by Secure RTP (SRTP)
[RFC3711], an attack can still be started by legitimate endpoints [RFC3711]. However, an attack can still be started by legitimate
that send several valid RAMS-R messages to a particular feedback endpoints that send several valid RAMS-R messages to a particular
target in a synchronized fashion and very short amount of time. feedback target in a synchronized fashion and in a very short amount
Since a RAMS operation can temporarily consume a large amount of of time. Since a RAMS operation can temporarily consume a large
resources, a series of the RAMS-R messages can temporarily overload amount of resources, a series of the RAMS-R messages can temporarily
the retransmission server. In these circumstances, the overload the retransmission server. In these circumstances, the
retransmission server can, for example, reject incoming RAMS requests retransmission server can, for example, reject incoming RAMS requests
until its resources become available again. One means to ameliorate until its resources become available again. One means to ameliorate
this threat is to apply a per-endpoint policing mechanism on the this threat is to apply a per-endpoint policing mechanism on the
incoming RAMS requests. A reasonable policing mechanism should incoming RAMS requests. A reasonable policing mechanism should
consider application-specific requirements and minimize false consider application-specific requirements and minimize false
negatives. negatives.
In addition to the denial-of-service attacks, man-in-the-middle and In addition to the DoS attacks, man-in-the-middle and replay attacks
replay attacks can also be harmful. However, RAMS itself does not will also be harmful. RAMS-R messages do not carry any information
bring any new risks or threats other than the ones discussed in that allows the retransmission server to detect duplication or replay
[RFC5760]. attacks. Thus, the possibility of a replay attack using a captured
valid RAMS-R message exists unless a mitigation method such as Secure
RTCP (SRTCP) is used. Similarly, RAMS-T messages can be replayed.
The RAMS-I has sequence number that makes replay attacks less likely
but not impossible. Man-in-the-middle attacks that are capable of
capturing, injecting or modifying the RAMS messages can easily
accomplish the attacks described above. Thus, cryptographic
integrity and authentication is the only reliable protection. To
protect the RTCP messages from man-in-the-middle and replay attacks,
the RTP receivers and retransmission server SHOULD perform a DTLS-
SRTP handshake [RFC5764] over the RTCP channel. Because there is no
integrity-protected signaling channel between an RTP receiver and the
retransmission server, the retransmission server MUST maintain a list
of certificates owned by legitimate RTP receivers, or their
certificates MUST be signed by a trusted Certificate Authority. Once
the DTLS-SRTP security is established, non-SRTCP-protected messages
received from a particular RTP receiver are ignored by the
retransmission server. To reduce the impact of DTLS-SRTP overhead
when communicating with different feedback targets on the same
retransmission server, it is RECOMMENDED that RTP receivers and the
retransmission server both support TLS Session Resumption without
Server-side State [RFC5077]. To help scale SRTP to handle many RTP
receivers asking for retransmissions of identical data, implementors
may consider using the same SRTP key for SRTP data sent to the
receivers [I-D.ietf-avt-srtp-ekt] and be aware that such key sharing
allows those receivers to impersonate the sender, so source address
validation remains important.
[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
plain-text attacks. As discussed in [RFC4588], the retransmission plain-text attacks. As discussed in [RFC4588], the retransmission
payload format sets the timestamp field in the RTP header to the payload format sets the timestamp field in the RTP header to the
media timestamp of the original packet and this does not compromise media timestamp of the original packet and this does not compromise
the confidentiality. Furthermore, if cryptography is used to provide the confidentiality. Furthermore, if cryptography is used to provide
security services on the original stream, then the same services, security services on the original stream, then the same services,
with equivalent cryptographic strength, MUST be provided on the with equivalent cryptographic strength, MUST be provided on the
retransmission stream per [RFC4588]. retransmission stream per [RFC4588].
To protect the RTCP messages from man-in-the-middle and replay Finally, a retransmission server that has become subverted by an
attacks, the RTP receivers and retransmission server SHOULD perform a attacker is almost impossible to protect against as such a server can
DTLS-SRTP handshake [RFC5764] over the RTCP channel. Because there perform a large number of different actions to deny service to
is no integrity-protected signaling channel between an RTP receiver receivers.
and the retransmission server, the retransmission server MUST
maintain a list of certificates owned by legitimate RTP receivers, or
their certificates MUST be signed by a trusted Certificate Authority.
Once the DTLS-SRTP security is established, non-SRTCP-protected
messages received from a particular RTP receiver are ignored by the
retransmission server. To reduce the impact of DTLS-SRTP overhead
when communicating with different feedback targets on the same
retransmission server, it is RECOMMENDED that RTP receivers and the
retransmission server both support TLS Session Resumption without
Server-side State [RFC5077]. To help scale SRTP to handle many RTP
receivers asking for retransmissions of identical data, implementors
may consider using the same SRTP key for SRTP data sent to the
receivers [I-D.ietf-avt-srtp-ekt] and consider the security of such
SRTP key sharing.
11. IANA Considerations 11. IANA Considerations
The following contact information shall be used for all registrations The following contact information shall be used for all registrations
in this document: in this document:
Ali Begen Ali Begen
abegen@cisco.com abegen@cisco.com
Note to the RFC Editor: In the following, please replace "XXXX" with Note to the RFC Editor: In the following, please replace "XXXX" with
skipping to change at page 48, line 41 skipping to change at page 52, line 6
507 BRS has no valid starting point available for 507 BRS has no valid starting point available for
the requested multicast stream [RFCXXXX] the requested multicast stream [RFCXXXX]
508 BRS has no reference information available for 508 BRS has no reference information available for
the requested multicast stream [RFCXXXX] the requested multicast stream [RFCXXXX]
509 BRS has no RTP stream matching the requested SSRC [RFCXXXX] 509 BRS has no RTP stream matching the requested SSRC [RFCXXXX]
510 RAMS request to acquire the entire session 510 RAMS request to acquire the entire session
has been denied [RFCXXXX] has been denied [RFCXXXX]
511 Only the preamble information is sent [RFCXXXX] 511 Only the preamble information is sent [RFCXXXX]
512 RAMS request has been denied due to a policy [RFCXXXX] 512 RAMS request has been denied due to a policy [RFCXXXX]
The definitions for these codes are provided in Section 11.6.1.
Any registration for an unassigned Response code needs to contain the Any registration for an unassigned Response code needs to 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.
11.6.1. Response Code Definitions
1xx-Level Response Codes: These response codes are sent for
informational purposes.
o 100: This is used when the BRS wants to update a value that was
sent earlier to the RTP_Rx.
2xx-Level Response Codes: These response codes are sent to indicate
success.
o 200: This is used when the server accepts the RAMS request.
o 201: This is used when the unicast burst has been completed and
the BRS wants to notify the RTP_Rx.
4xx-Level Response Codes: These response codes are sent to indicate
that the message sent by the RTP_Rx is either improperly formatted or
contains an invalid value. The rules the RTP_Rx needs to follow upon
receiving one of these response codes are outlined in Step 5 in
Section 6.2. The 4xx-level response codes are also used as status
codes in the Multicast Acquisition Report Block
[I-D.ietf-avt-multicast-acq-rtcp-xr] in order to collect RTP_Rx-based
error conditions.
o 400: This is used when the RAMS-R message is improperly
formatted.
o 401: This is used when the minimum RAMS buffer fill requirement
value indicated in the RAMS-R message is invalid.
o 402: This is used when the maximum RAMS buffer fill requirement
value indicated in the RAMS-R message is invalid.
o 403: This is used when the maximum receive bitrate value
indicated in the RAMS-R message is insufficient.
o 404: This is used when the RAMS-T message is improperly
formatted.
5xx-Level Response Codes: These response codes are sent to indicate
an error on the BRS side. The rules the RTP_Rx needs to follow upon
receiving one of these response codes are outlined in Step 3 in
Section 6.2 and Section 7.2. The 5xx-level response codes are also
used as status codes in the Multicast Acquisition Report Block
[I-D.ietf-avt-multicast-acq-rtcp-xr] in order to collect BRS-based
error conditions.
o 500: This is used when the BRS has experienced an internal error
and cannot accept the RAMS request.
o 501: This is used when the BRS does not have enough bandwidth to
send the unicast burst stream.
o 502: This is used when the BRS terminates the unicast burst
stream due to network congestion.
o 503: This is used when the BRS does not have enough CPU resources
to send the unicast burst stream.
o 504: This is used when the BRS does not support sending a unicast
burst stream.
o 505: This is used when the requesting RTP_Rx is not eligible to
receive a unicast burst stream.
o 506: This is used when RAMS functionality is not enabled for the
requested multicast stream.
o 507: This is used when the BRS cannot find a valid starting point
for the unicast burst stream satisfying the RTP_Rx's requirements.
o 508: This is used when the BRS cannot find the essential
reference information for the requested multicast stream.
o 509: This is used when the BRS cannot match the requested SSRC to
any of the streams it is serving.
o 510: This is used when the BRS cannot serve the requested entire
session.
o 511: This is used when the BRS sends only the preamble
information but not the whole unicast burst stream.
o 512: This is used when the RAMS request is denied due to a policy
specified for the requested multicast stream, requesting RTP_Rx or
this particular BRS.
12. Contributors 12. Contributors
Dave Oran, Magnus Westerlund and Colin Perkins have contributed Dave Oran, Magnus Westerlund and Colin Perkins have contributed
significantly to this specification by providing text and solutions significantly to this specification by providing text and solutions
to some of the issues raised during the development of this to some of the issues raised during the development of this
specification. specification.
13. Acknowledgments 13. Acknowledgments
The following individuals have reviewed the earlier versions of this The following individuals have reviewed the earlier versions of this
skipping to change at page 52, line 47 skipping to change at page 54, line 18
Specific Multicast (SSM) Sessions", Specific Multicast (SSM) Sessions",
draft-ietf-avt-rtcp-port-for-ssm-02 (work in progress), draft-ietf-avt-rtcp-port-for-ssm-02 (work in progress),
August 2010. August 2010.
[I-D.ietf-avt-ports-for-ucast-mcast-rtp] [I-D.ietf-avt-ports-for-ucast-mcast-rtp]
Begen, A. and B. Steeg, "Port Mapping Between Unicast and Begen, A. and B. Steeg, "Port Mapping Between Unicast and
Multicast RTP Sessions", Multicast RTP Sessions",
draft-ietf-avt-ports-for-ucast-mcast-rtp-02 (work in draft-ietf-avt-ports-for-ucast-mcast-rtp-02 (work in
progress), May 2010. progress), May 2010.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. Server-Side State", RFC 5077, January 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
14.2. Informative References 14.2. Informative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[I-D.begen-avt-rams-scenarios] [I-D.begen-avt-rams-scenarios]
Begen, A., "Considerations for RAMS Scenarios", Begen, A., "Considerations for RAMS Scenarios",
draft-begen-avt-rams-scenarios-00 (work in progress), draft-begen-avt-rams-scenarios-00 (work in progress),
October 2009. October 2009.
skipping to change at page 54, line 19 skipping to change at page 55, line 39
draft-ietf-avt-srtp-ekt-01 (work in progress), July 2010. draft-ietf-avt-srtp-ekt-01 (work in progress), July 2010.
[UPnP-IGD] [UPnP-IGD]
Forum, UPnP., "Universal Plug and Play (UPnP) Internet Forum, UPnP., "Universal Plug and Play (UPnP) Internet
Gateway Device (IGD)", November 2001. Gateway Device (IGD)", November 2001.
[IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing [IC2009] Begen, A., Glazebrook, N., and W. VerSteeg, "Reducing
Channel Change Times in IPTV with Real-Time Transport Channel Change Times in IPTV with Real-Time Transport
Protocol (IEEE Internet Computing)", May 2009. Protocol (IEEE Internet Computing)", May 2009.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Authors' Addresses Authors' Addresses
Bill VerSteeg Bill VerSteeg
Cisco Cisco
5030 Sugarloaf Parkway 5030 Sugarloaf Parkway
Lawrenceville, GA 30044 Lawrenceville, GA 30044
USA USA
Email: billvs@cisco.com Email: billvs@cisco.com
 End of changes. 52 change blocks. 
278 lines changed or deleted 354 lines changed or added

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