draft-ietf-avt-rapid-acquisition-for-rtp-10.txt   draft-ietf-avt-rapid-acquisition-for-rtp-11.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: November 30, 2010 T. VanCaenegem Expires: January 10, 2011 T. VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Z. Vax Z. Vax
Microsoft Corporation Microsoft Corporation
May 29, 2010 July 9, 2010
Unicast-Based Rapid Acquisition of Multicast RTP Sessions Unicast-Based Rapid Acquisition of Multicast RTP Sessions
draft-ietf-avt-rapid-acquisition-for-rtp-10 draft-ietf-avt-rapid-acquisition-for-rtp-11
Abstract Abstract
When an RTP receiver joins a multicast session, it may need to When an RTP receiver joins a multicast session, it may need to
acquire and parse certain Reference Information before it can process acquire and parse certain Reference Information before it can process
any data sent in the multicast session. Depending on the join time, any data sent in the multicast session. Depending on the join time,
length of the Reference Information repetition (or appearance) length of the Reference Information repetition (or appearance)
interval, size of the Reference Information as well as the interval, size of the Reference Information as well as the
application and transport properties, the time lag before an RTP application and transport properties, the time lag before an RTP
receiver can usefully consume the multicast data, which we refer to receiver can usefully consume the multicast data, which we refer to
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 30, 2010. This Internet-Draft will expire on January 10, 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 25 skipping to change at page 3, line 25
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 . . . . . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . 23
6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 23 6.4. Burst Shaping and Congestion Control in RAMS . . . . . . . 23
6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 26 6.5. Failure Cases . . . . . . . . . . . . . . . . . . . . . . 26
7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 27 7. Encoding of the Signaling Protocol in RTCP . . . . . . . . . . 27
7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 28 7.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 29 7.1.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 29
7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 29 7.1.2. Private Extensions . . . . . . . . . . . . . . . . . . 29
7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 30 7.2. RAMS Request . . . . . . . . . . . . . . . . . . . . . . . 29
7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 32 7.3. RAMS Information . . . . . . . . . . . . . . . . . . . . . 32
7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 35 7.4. RAMS Termination . . . . . . . . . . . . . . . . . . . . . 34
8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 36 8. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 35
8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 36 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 35
8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 36 8.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 36
8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 37 8.3. Example and Discussion . . . . . . . . . . . . . . . . . . 37
9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 40 9. NAT Considerations . . . . . . . . . . . . . . . . . . . . . . 39
10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 40
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 43 11.1. Registration of SDP Attributes . . . . . . . . . . . . . . 42
11.2. Registration of SDP Attribute Values . . . . . . . . . . . 43 11.2. Registration of SDP Attribute Values . . . . . . . . . . . 42
11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 44 11.3. Registration of FMT Values . . . . . . . . . . . . . . . . 43
11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 44 11.4. SFMT Values for RAMS Messages Registry . . . . . . . . . . 43
11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 45 11.5. RAMS TLV Space Registry . . . . . . . . . . . . . . . . . 44
11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 46 11.6. RAMS Response Code Space Registry . . . . . . . . . . . . 45
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 47
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
14.1. Normative References . . . . . . . . . . . . . . . . . . . 48 14.1. Normative References . . . . . . . . . . . . . . . . . . . 47
14.2. Informative References . . . . . . . . . . . . . . . . . . 50 14.2. Informative References . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
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. The
information must first be acquired by the receivers to start receivers need to acquire certain information to start processing any
processing any data sent in the multicast session. This document data sent in the multicast session. This document refers to this
refers to this information as Reference Information. The Reference information as Reference Information. The Reference Information is
Information is conventionally sent periodically in the multicast conventionally sent periodically in the multicast session (although
session (although its content can change over time) and usually its content can change over time) and usually consists of items such
consists of items such as a description of the schema for the rest of as a description of the schema for the rest of the data, references
the data, references to which data to process, encryption information to which data to process, encryption information including keys, as
including keys, as well as any other information required to process well as any other information required to process the data in the
the data in the multicast stream [IC2009]. multicast stream [IC2009].
Real-time multicast applications require the receivers to buffer Real-time multicast applications require the receivers to buffer
data. The receiver may have to buffer data to smooth out the network data. The receiver may have to buffer data to smooth out the network
jitter, to allow loss-repair methods such as Forward Error Correction jitter, to allow loss-repair methods such as Forward Error Correction
and retransmission to recover the missing packets, and to satisfy the and retransmission to recover the missing packets, and to satisfy the
data processing requirements of the application layer. data processing requirements of the application layer.
When a receiver joins a multicast session, it has no control over When a receiver joins a multicast session, it has no control over
what point in the flow is currently being transmitted. Sometimes the what point in the flow is currently being transmitted. Sometimes the
receiver might join the session right before the Reference receiver might join the session right before the Reference
skipping to change at page 8, line 45 skipping to change at page 8, line 45
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 must use the same SSRC and CNAME as its primary multicast RTP stream will use the same SSRC and CNAME as its primary multicast RTP
stream. stream.
Retransmission Server (RS): The RTP/RTCP endpoint that can generate Retransmission Server (RS): The RTP/RTCP endpoint that can generate
the retransmission packets and the burst streams. RS may also the retransmission packets and the burst streams. RS may also
generate other non-retransmission packets to aid rapid acquisition. generate other non-retransmission packets to aid rapid acquisition.
4. Elements of Delay in Multicast Applications 4. Elements of Delay in Multicast Applications
In a source-specific (SSM) multicast delivery system, there are three In a source-specific (SSM) multicast delivery system, there are three
major elements that contribute to the overall acquisition delay when major elements that contribute to the overall acquisition delay when
skipping to change at page 15, line 33 skipping to change at page 15, line 33
such as the SSM sessions we are considering in this specification, an such as the SSM sessions we are considering in this specification, an
RTP_Rx cannot send an RTCP feedback message for a minimum of one RTP_Rx cannot send an RTCP feedback message for a minimum of one
second period after joining the session (i.e., Tmin=1.0 second). second period after joining the session (i.e., Tmin=1.0 second).
While this rule has the goal of avoiding problems associated with While this rule has the goal of avoiding problems associated with
flash crowds in typical multi-party sessions, it defeats the purpose flash crowds in typical multi-party sessions, it defeats the purpose
of rapid acquisition. Furthermore, when RTP receivers delay their of rapid acquisition. Furthermore, when RTP receivers delay their
messages requesting a burst by a deterministic or even a random messages requesting a burst by a deterministic or even a random
amount, it still does not make a difference since such messages are amount, it still does not make a difference since such messages are
not related and their timings are independent from each other. Thus, not related and their timings are independent from each other. Thus,
in this specification we initialize Tmin to zero and allow the RTP in this specification we initialize Tmin to zero and allow the RTP
receivers to send a burst request message right at the beginning. It receivers to send a burst request message right at the beginning.
should, however, be emphasized that for the subsequent messages For the subsequent messages during rapid acquisition, the timing
during rapid acquisition, the timing rules of [RFC4585] still apply. 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 17, line 12 skipping to change at page 17, line 12
~~~~~~~> Unicast RTCP Feedback Messages ~~~~~~~> Unicast RTCP Feedback Messages
=======> SFGMP Messages =======> SFGMP Messages
.......> Unicast RTP Flow .......> Unicast RTP Flow
Figure 3: Message flows for unicast-based rapid acquisition Figure 3: Message flows for unicast-based rapid acquisition
This document defines the expected behaviors of RS and RTP_Rx. It is This document defines the expected behaviors of RS and RTP_Rx. It is
instructive to have independently operating implementations on RS and instructive to have independently operating implementations on RS and
RTP_Rx that request the burst, describe the burst, start the burst, RTP_Rx that request the burst, describe the burst, start the burst,
join the multicast session and stop the burst. These implementations join the multicast session and stop the burst. These implementations
send messages to each other, but there must be provisions for the send messages to each other, but provisions are needed for the cases
cases where the control messages get lost, or re-ordered, or are not where the control messages get lost, or re-ordered, or are not being
being delivered to their destinations. delivered to their destinations.
The following steps describe rapid acquisition in detail: The following steps describe rapid acquisition in detail:
1. Port Mapping Setup: For the primary multicast RTP session, the 1. Port Mapping Setup: For the primary multicast RTP session, the
RTP and RTCP destination ports are declaratively specified RTP and RTCP destination ports are declaratively specified
(Refer to Section 8 for examples in SDP). However, RTP_Rx needs (Refer to Section 8 for examples in SDP). However, RTP_Rx needs
to choose its RTP and RTCP receive ports in the unicast burst to choose its RTP and RTCP receive ports in the unicast burst
RTP session. Since this unicast session is established after RTP session. Since this unicast session is established after
RTP_Rx has sent a RAMS-Request (RAMS-R) message as unicast RTP_Rx has sent a RAMS-Request (RAMS-R) message as unicast
feedback in the primary multicast RTP session, RTP_Rx MUST first feedback in the primary multicast RTP session, RTP_Rx MUST first
skipping to change at page 17, line 47 skipping to change at page 17, line 47
RTP_Rx (aka SSRC of packet sender) and can contain the media RTP_Rx (aka SSRC of packet sender) and can contain the media
sender SSRC identifier(s) of the primary multicast stream(s) of sender SSRC identifier(s) of the primary multicast stream(s) of
interest (aka SSRC of media source). The RAMS-R message can interest (aka SSRC of media source). The RAMS-R message can
contain parameters that constrain the burst, such as the buffer contain parameters that constrain the burst, such as the buffer
and bandwidth limits. and bandwidth limits.
Before joining the SSM session, RTP_Rx learns the addresses for Before joining the SSM session, RTP_Rx learns the addresses for
the multicast source, group and RS by out-of-band means. If the multicast source, group and RS by out-of-band means. If
RTP_Rx desires to rapidly acquire only a subset of the primary RTP_Rx desires to rapidly acquire only a subset of the primary
multicast streams available in the primary multicast RTP multicast streams available in the primary multicast RTP
session, it MUST also acquire the SSRC identifiers for the session, RTP_Rx MUST also acquire the SSRC identifiers for the
desired RTP streams out-of-band. Based on this information, desired RTP streams out-of-band. Based on this information,
RTP_Rx populates the desired SSRC(s) in the RAMS-R message. RTP_Rx populates the desired SSRC(s) in the RAMS-R message.
When FT successfully receives the RAMS-R message, BRS responds When FT successfully receives the RAMS-R message, BRS responds
to it by accepting or rejecting the request. Immediately before to it by accepting or rejecting the request. Immediately before
BRS sends any RTP or RTCP packet(s) described below, it BRS sends any RTP or RTCP packet(s) described below, it
establishes the unicast burst RTP session. establishes the unicast burst RTP session.
3. Response: BRS sends RAMS-Information (RAMS-I) message(s) to 3. Response: BRS sends RAMS-Information (RAMS-I) message(s) to
RTP_Rx to convey the status for the burst(s) requested by RTP_Rx to convey the status for the burst(s) requested by
skipping to change at page 18, line 31 skipping to change at page 18, line 31
Section 7.3). Section 7.3).
FT_Ap could also be associated with an RTP session that carries FT_Ap could also be associated with an RTP session that carries
two or more primary multicast streams. If RTP_Rx will issue a two or more primary multicast streams. If RTP_Rx will issue a
collective request to receive the whole primary multicast RTP collective request to receive the whole primary multicast RTP
session, it does not need the 'ssrc' attributes to be described session, it does not need the 'ssrc' attributes to be described
in the media description. in the media description.
If FT_Ap is associated with two or more RTP sessions, RTP_Rx's If FT_Ap is associated with two or more RTP sessions, RTP_Rx's
request will be ambiguous. To avoid any ambiguity, each FT_Ap request will be ambiguous. To avoid any ambiguity, each FT_Ap
MUST be associated with a single RTP session. MUST only associate itself with a single RTP session.
If RTP_Rx is willing to rapidly acquire only a subset of the If RTP_Rx is willing to rapidly acquire only a subset of the
primary multicast streams, the RAMS-R message MUST explicitly primary multicast streams, RTP_Rx MUST list all the media sender
list the media sender SSRCs denoting the stream(s) it wishes to SSRC(s) denoting the stream(s) it wishes to acquire in the
acquire. Upon receiving such a message, BRS MAY accept the RAMS-R message. Upon receiving such a message, BRS MAY accept
request for all or a subset of the media sender SSRC(s) that the request for all or a subset of the media sender SSRC(s) that
matched the RTP stream(s) it serves. BRS MUST reject all other matched the RTP stream(s) it serves. BRS MUST reject all other
requests with the appropriate response code. requests with an appropriate response code.
* Reject Responses: BRS MUST take into account any limitations * Reject Responses: BRS MUST take into account any limitations
that may have been specified by RTP_Rx in the RAMS-R message that may have been specified by RTP_Rx in the RAMS-R message
when making a decision regarding the request. If RTP_Rx has when making a decision regarding the request. If RTP_Rx has
requested to acquire the whole primary multicast RTP session requested to acquire the whole primary multicast RTP session
but BRS cannot provide a rapid acquisition service for any of but BRS cannot provide a rapid acquisition service for any of
the primary multicast streams, BRS MUST reject the request the primary multicast streams, BRS MUST reject the request
via a single RAMS-I message with a collective reject response via a single RAMS-I message with a collective reject response
code and whose media sender SSRC field is set to one of SSRCs code and whose media sender SSRC field is set to one of SSRCs
served by this FT_Ap. Upon receiving this RAMS-I message, served by this FT_Ap. Upon receiving this RAMS-I message,
RTP_Rx abandons the rapid acquisition attempt and can RTP_Rx abandons the rapid acquisition attempt and can
immediately join the multicast session by sending an SFGMP immediately join the multicast session by sending an SFGMP
Join message towards its upstream multicast router. Join message towards its upstream multicast router.
In all other cases, BRS MUST send a separate RAMS-I message In all other cases, BRS MUST send a separate RAMS-I message
with the appropriate response code for each primary multicast with the appropriate response code for each primary multicast
stream that has been requested by RTP_Rx but cannot be served stream that has been requested by RTP_Rx but cannot be served
by BRS. by BRS.
* Accept Responses: BRS MUST send a separate RAMS-I message * Accept Responses: BRS MUST send at least one separate RAMS-I
with the appropriate response code for each primary multicast message with the appropriate response code for each primary
stream that has been requested by RTP_Rx and will be served multicast stream that has been requested by RTP_Rx and will
by BRS. Such RAMS-I messages comprise fields that can be be served by BRS. Such RAMS-I messages comprise fields that
used to describe the individual unicast burst streams. can be used to describe the individual unicast burst streams.
When there is a RAMS-R request for multiple primary multicast
streams, BRS MUST include all the individual RAMS-I messages
corresponding to that RAMS-R request in the same compound
RTCP packet if these messages fit in the same packet.
A particularly important field in the RAMS-I message carries The RAMS-I message carries the RTP sequence number of the
the RTP sequence number of the first packet transmitted in first packet transmitted in the respective RTP stream to
the respective RTP stream to allow RTP_Rx to detect any allow RTP_Rx to detect any missing initial packet(s). When
missing initial packet(s). When BRS accepts the request, BRS accepts a request for a primary multicast stream, this
this field MUST be populated in the RAMS-I message and the field MUST always be populated in the RAMS-I message(s) sent
initial RAMS-I message SHOULD precede the unicast burst or be for this particular primary multicast stream. It is
sent at the start of the burst so that RTP_Rx can quickly RECOMMENDED that BRS sends a RAMS-I message at the start of
detect any missing initial packet(s). the burst so that RTP_Rx can quickly detect any missing
initial packet(s).
Where possible, it is RECOMMENDED to include all RAMS-I messages It is possible that the RAMS-I message for a primary multicast
in the same compound RTCP packet. However, it is possible that stream can get delayed or lost, and RTP_Rx can start receiving
the RAMS-I message for a primary multicast stream can get RTP packets before receiving a RAMS-I message. RTP_Rx MUST NOT
delayed or lost, and RTP_Rx can start receiving RTP packets make protocol dependencies on quickly receiving the initial
before receiving a RAMS-I message. RTP_Rx MUST NOT make RAMS-I message. For redundancy purposes, it is RECOMMENDED that
protocol dependencies on quickly receiving the initial RAMS-I BRS repeats the RAMS-I messages multiple times as long as it
message. For redundancy purposes, it is RECOMMENDED that BRS follows the RTCP timer rules defined in [RFC4585].
repeats the RAMS-I messages multiple times as long as it follows
the RTCP timer rules defined in [RFC4585].
4. Unicast Burst: For the primary multicast stream(s) for which 4. Unicast Burst: For the primary multicast stream(s) for which
the request is accepted, BRS starts sending the unicast burst(s) the request is accepted, BRS starts sending the unicast burst(s)
that comprises one or more RTP retransmission packets sent in that comprises one or more RTP retransmission packets sent in
the unicast burst RTP session. In addition, BRS MAY send the unicast burst RTP session. In addition, BRS MAY send
preamble information data to RTP_Rx in addition to the requested preamble information data to RTP_Rx in addition to the requested
burst, to prime the media decoder(s). The format of this burst, to prime the media decoder(s). The format of this
preamble data is RTP-payload specific and not specified here. preamble data is RTP-payload specific and not specified here.
5. Updated Request: RTP_Rx MAY send an updated RAMS-R message (as 5. Updated Request: RTP_Rx MAY send an updated RAMS-R message (as
unicast feedback in the primary multicast RTP session) with a unicast feedback in the primary multicast RTP session) with a
different value for one or more fields of an earlier RAMS-R different value for one or more fields of an earlier RAMS-R
message. If there is already a burst planned for or being message. If there is already a burst planned for or being
transmitted to a particular RTP_Rx for a particular stream, the transmitted to a particular RTP_Rx for a particular stream, the
newly arriving RAMS-R is an updated request; otherwise, it is a newly arriving RAMS-R is an updated request; otherwise, it is a
new request. BRS determines the identity of the requesting new request. BRS determines the identity of the requesting
RTP_Rx by looking at its canonical name identifier (CNAME item RTP_Rx by looking at its canonical name identifier (CNAME item
in the SDES source description). To choose a globally unique in the SDES source description). Thus, RTP_Rx MUST choose a
CNAME identifier, RTP_Rx SHOULD follow the guidelines given in globally unique CNAME identifier. Different such ways are
[I-D.begen-avt-rtp-cnames]. In addition to one or more fields provided in [I-D.ietf-avt-rtp-cnames]. In addition to one or
with updated values, an updated RAMS-R message may also include more fields with updated values, an updated RAMS-R message may
the fields whose values did not change. also include the fields whose values did not change.
Upon receiving an updated request, BRS can use the updated Upon receiving an updated request, BRS can use the updated
values for sending/shaping the burst, or refine the values and values for sending/shaping the burst, or refine the values and
use the refined values for sending/shaping the burst. use the refined values for sending/shaping the burst.
Subsequently, BRS MAY send an updated RAMS-I message in the Subsequently, BRS MAY send an updated RAMS-I message in the
unicast burst RTP session to indicate the changes it made. unicast burst RTP session to indicate the changes it made.
However, the updated RAMS-I message can get lost. It is also
possible that the updated RAMS-R message could have been lost.
RTP_Rx MUST NOT make protocol dependencies on quickly (or ever)
receiving an updated RAMS-I message, or assume that BRS will
honor the requested changes.
RTP_Rx may be in an environment where the available resources RTP_Rx may be in an environment where the available resources
are time-varying, which may or may not deserve sending a new are time-varying, which may or may not deserve sending a new
updated request. Determining the circumstances where RTP_Rx updated request. Determining the circumstances where RTP_Rx
should or should not send an updated request and the methods needs or does not need to send an updated request and the
that RTP_Rx can use to detect and evaluate the time-varying methods that RTP_Rx can use to detect and evaluate the time-
available resources are not specified in this document. varying available resources are not specified in this document.
6. Updated Response: BRS can send more than one RAMS-I messages in 6. Updated Response: BRS can send more than one RAMS-I messages in
the unicast burst RTP session, e.g., to update the value of one the unicast burst RTP session, e.g., to update the value of one
or more fields in an earlier RAMS-I message. The updated RAMS-I or more fields in an earlier RAMS-I message. The updated RAMS-I
messages might or might not be a direct response to a RAMS-R messages might or might not be a direct response to a RAMS-R
message. BRS can also send updated RAMS-I messages to signal message. BRS can also send updated RAMS-I messages to signal
RTP_Rx in real time to join the SSM session. RTP_Rx depends on RTP_Rx in real time to join the SSM session, when BRS had
BRS to learn the join time, which can be conveyed by the first already sent an initial RAMS-I message, e.g., at the start of
RAMS-I message, or can be sent/revised in a later RAMS-I the burst. RTP_Rx depends on BRS to learn the join time, which
message. If BRS is not capable of determining the join time in can be conveyed by the first RAMS-I message, or can be sent/
the initial RAMS-I message, BRS MUST send another RAMS-I message revised in a later RAMS-I message. If BRS is not capable of
(with the join time information) later. determining the join time in the initial RAMS-I message, BRS
MUST send another RAMS-I message (with the join time
information) later.
7. Multicast Join Signaling: The RAMS-I message allows BRS to 7. Multicast Join Signaling: The RAMS-I message allows BRS to
signal explicitly when RTP_Rx SHOULD send the SFGMP Join signal explicitly when RTP_Rx needs to send the SFGMP Join
message. If the request is accepted, this information MUST be message. RTP_Rx SHOULD use this information from the most
conveyed in at least one RAMS-I message and its value MAY be recent RAMS-I message unless it has more accurate information.
updated by subsequent RAMS-I messages. If RTP_Rx has received If the request is accepted, this information MUST be conveyed in
multiple RAMS-I messages, RTP_Rx SHOULD use the information from at least one RAMS-I message and its value MAY be updated by
the most recent RAMS-I message. subsequent RAMS-I messages.
There can be missing packets if RTP_Rx joins the multicast There can be missing packets if RTP_Rx joins the multicast
session too early or too late. For example, if RTP_Rx starts session too early or too late. For example, if RTP_Rx starts
receiving the primary multicast stream while it is still receiving the primary multicast stream while it is still
receiving the unicast burst at a high excess bitrate, this can receiving the unicast burst at a high excess bitrate, this can
result in an increased risk of packet loss. Or, if RTP_Rx joins result in an increased risk of packet loss. Or, if RTP_Rx joins
the multicast session some time after the unicast burst is the multicast session some time after the unicast burst is
finished, there can be a gap between the burst and multicast finished, there can be a gap between the burst and multicast
data (a number of RTP packets might be missing). In both cases, data (a number of RTP packets might be missing). In both cases,
RTP_Rx can issue retransmission requests (via RTCP NACK messages RTP_Rx can issue retransmission requests (via RTCP NACK messages
sent as unicast feedback in the primary multicast RTP session) sent as unicast feedback in the primary multicast RTP session)
[RFC4585] to the FT entity of RS to fill the gap. BRS might or [RFC4585] to the FT entity of RS to fill the gap. BRS might or
might not respond to such requests. When it responds and the might not respond to such requests. When it responds and the
response causes significant changes in one or more values response causes significant changes in one or more values
reported earlier to RTP_Rx, an updated RAMS-I should be sent to reported earlier to RTP_Rx, an updated RAMS-I SHOULD be sent to
RTP_Rx. RTP_Rx.
8. Multicast Receive: After the join, RTP_Rx starts receiving the 8. Multicast Receive: After the join, RTP_Rx starts receiving the
primary multicast stream(s). primary multicast stream(s).
9. Terminate: BRS can know when it needs to ultimately stop the 9. Terminate: BRS can know when it needs to ultimately stop the
unicast burst based on its parameters. However, RTP_Rx may need unicast burst based on its parameters. However, RTP_Rx may need
to ask BRS to terminate the burst prematurely or at a specific to ask BRS to terminate the burst prematurely or at a specific
sequence number. For this purpose, it uses the RAMS-Termination sequence number. For this purpose, it uses the RAMS-Termination
(RAMS-T) message sent as RTCP feedback in the unicast burst RTP (RAMS-T) message sent as RTCP feedback in the unicast burst RTP
skipping to change at page 21, line 49 skipping to change at page 21, line 48
request before it learns the individual media sender SSRC(s) via request before it learns the individual media sender SSRC(s) via
RAMS-I message(s) or RTP packets, RTP_Rx cannot use RAMS-T RAMS-I message(s) or RTP packets, RTP_Rx cannot use RAMS-T
message(s) and thus MUST send an RTCP BYE message in the unicast message(s) and thus MUST send an RTCP BYE message in the unicast
burst RTP session to terminate the request. burst RTP session to terminate the request.
Otherwise, the default behavior for RTP_Rx is to send a RAMS-T Otherwise, the default behavior for RTP_Rx is to send a RAMS-T
message in the unicast burst RTP session immediately after it message in the unicast burst RTP session immediately after it
joins the multicast session and started receiving multicast joins the multicast session and started receiving multicast
packets. In that case, RTP_Rx SHALL send a RAMS-T message with packets. In that case, RTP_Rx SHALL send a RAMS-T message with
the sequence number of the first RTP packet received in the the sequence number of the first RTP packet received in the
primary multicast stream. Then, BRS SHOULD terminate the primary multicast stream. Then, BRS MUST terminate the
respective burst after it sends the unicast burst packet whose respective burst after it sends the unicast burst packet whose
Original Sequence Number (OSN) field in the RTP retransmission Original Sequence Number (OSN) field in the RTP retransmission
payload header matches this number minus one. payload header matches this number minus one.
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
Step 10, RTP_Rx MUST send at least one RAMS-T message for each Step 10, RTP_Rx MUST send at least one RAMS-T message for each
primary multicast stream served by BRS. The RAMS-T message(s) primary multicast stream served by BRS. The RAMS-T message(s)
MUST be addressed to BRS and sent in the unicast burst RTP MUST be addressed to BRS and sent in the unicast burst RTP
session. Against the possibility of a message loss, it is session. Against the possibility of a message loss, it is
RECOMMENDED that RTP_Rx repeats the RAMS-T messages multiple RECOMMENDED that RTP_Rx repeats the RAMS-T messages multiple
skipping to change at page 23, line 21 skipping to change at page 23, line 19
When RTP_Rx acquires multiple primary multicast streams, RTP_Rx can When RTP_Rx acquires multiple primary multicast streams, RTP_Rx can
need to synchronize them for the playout. This synchronization is need to synchronize them for the playout. This synchronization is
traditionally achieved by the help of the RTCP sender reports traditionally achieved by the help of the RTCP sender reports
[RFC3550]. If the playout will start before RTP_Rx has joined the [RFC3550]. If the playout will start before RTP_Rx has joined the
multicast session, RTP_Rx needs to receive the information reflecting multicast session, RTP_Rx needs to receive the information reflecting
the synchronization among the primary multicast streams early enough the synchronization among the primary multicast streams early enough
so that it can play out the media in a synchronized fashion. so that it can play out the media in a synchronized fashion.
The suggested approach is to use the RTP header extension mechanism The suggested approach is to use the RTP header extension mechanism
[RFC5285] and convey the synchronization information in a header [RFC5285] and convey the synchronization information in a header
extension as defined in [I-D.ietf-avt-rapid-rtp-sync]. [RFC4588] extension as defined in [I-D.ietf-avt-rapid-rtp-sync]. Per [RFC4588]
says that retransmission packets should carry the same header "if the original RTP header carried an RTP header extension, the
extension carried in the header of the original RTP packets. Thus, retransmission packet SHOULD carry the same header extension." Thus,
as long as the multicast source emits a header extension with the as long as the multicast source emits a header extension with the
synchronization information frequently enough, there is no additional synchronization information frequently enough, there is no additional
task that needs to be carried out by BRS. The synchronization task that needs to be carried out by BRS. The synchronization
information will be sent to RTP_Rx along with the burst packets. The information will be sent to RTP_Rx along with the burst packets. The
frequent header extensions sent in the primary multicast RTP sessions frequent header extensions sent in the primary multicast RTP sessions
also allow rapid synchronization of the RTP streams for the RTP also allow rapid synchronization of the RTP streams for the RTP
receivers that do not support RAMS or that directly join the receivers that do not support RAMS or that directly join the
multicast session without running RAMS. Thus, in RAMS applications, multicast session without running RAMS. Thus, in RAMS applications,
it is RECOMMENDED that the multicast sources frequently send it is RECOMMENDED that the multicast sources frequently send
synchronization information by using header extensions following the synchronization information by using header extensions following the
skipping to change at page 24, line 6 skipping to change at page 24, line 4
immediately to stop the unicast burst. immediately to stop the unicast burst.
A higher bitrate for the unicast burst naturally conveys the A higher bitrate for the unicast burst naturally conveys the
Reference Information and media content to RTP_Rx faster. This way, Reference Information and media content to RTP_Rx faster. This way,
RTP_Rx can start consuming the data sooner, which results in a faster RTP_Rx can start consuming the data sooner, which results in a faster
acquisition. A higher bitrate also represents a better utilization acquisition. A higher bitrate also represents a better utilization
of BRS resources. As the burst may continue until it catches up with of BRS resources. As the burst may continue until it catches up with
the primary multicast stream, the higher the bursting bitrate, the the primary multicast stream, the higher the bursting bitrate, the
less data BRS needs to transmit. However, a higher bitrate for the less data BRS needs to transmit. However, a higher bitrate for the
burst also increases the chances for congestion-caused packet loss. burst also increases the chances for congestion-caused packet loss.
Thus, as discussed in Section 5, there has to be an upper bound on Thus, as discussed in Section 5, there has to be an upper bound on
the bandwidth used by the burst. the bandwidth used by the burst.
When BRS transmits the unicast burst, it should take into account all When BRS transmits the unicast burst, it is expected to take into
available information to prevent any packet loss that might take account all available information to prevent any packet loss that
place during the bursting as a result of buffer overflow on the path might take place during the bursting as a result of buffer overflow
between RS and RTP_Rx and at RTP_Rx itself. The bursting bitrate can on the path between RS and RTP_Rx and at RTP_Rx itself. The bursting
be determined by taking into account the following information, when bitrate can be determined by taking into account the following
available: 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 bitrate in the retransmission session, allowing in-session bitrate
adaptations for the burst. When these receiver reports indicate adaptations for the burst. When these receiver reports indicate
packet loss, this can indicate a certain congestion state in the packet loss, this can indicate a certain congestion state in the
path from RS to RTP_Rx. path from RS to RTP_Rx.
skipping to change at page 25, line 15 skipping to change at page 25, line 13
dynamically adapted using application-aware knowledge. dynamically adapted using application-aware knowledge.
BRS chooses the initial burst bitrate as follows: BRS chooses the initial burst bitrate as follows:
o When using RAMS in environments as described in (g), BRS MUST o When using RAMS in environments as described in (g), BRS MUST
transmit the burst packets at an initial bitrate higher than the transmit the burst packets at an initial bitrate higher than the
nominal bitrate, but within the engineered or reserved bandwidth nominal bitrate, but within the engineered or reserved bandwidth
limit. limit.
o When BRS cannot determine a reliable bitrate value for the unicast o When BRS cannot determine a reliable bitrate value for the unicast
burst (through a or g), BRS should choose an appropriate initial burst (using a through g), it is desirable that BRS chooses an
bitrate not above the nominal bitrate and increase it gradually appropriate initial bitrate not above the nominal bitrate and
unless a congestion is detected. increases it gradually unless a congestion is detected.
In both cases, during the burst transmission BRS MUST continuously In both cases, during the burst transmission BRS MUST continuously
monitor for packet losses as a result of congestion by means of one monitor for packet losses as a result of congestion by means of one
or more of the mechanisms described in (b,c,d,e,f). When BRS relies or more of the mechanisms described in (b,c,d,e,f). When BRS relies
on RTCP receiver reports, sufficient bandwidth needs to be provided on RTCP receiver reports, sufficient bandwidth needs to be provided
to RTP Rx for RTCP transmission in the unicast burst RTP session. To to RTP Rx for RTCP transmission in the unicast burst RTP session. To
achieve a reasonable fast adaptation against congestion, it is achieve a reasonable fast adaptation against congestion, it is
recommended that RTP_Rx sends a receiver report at least once every recommended that RTP_Rx sends a receiver report at least once every
two RTTs between RS and RTP_Rx. Although the specific heuristics and two RTTs between RS and RTP_Rx. Although the specific heuristics and
algorithms that deduce a congestion state and how subsequently BRS algorithms that deduce a congestion state and how subsequently BRS
should act are outside the scope of this specification, the following acts are outside the scope of this specification, the following two
two practices are recommended: methods are the best practices:
o Upon detection of a significant amount of packet loss, which BRS o Upon detection of a significant amount of packet loss, which BRS
attributes to congestion, BRS should decrease the burst bitrate. attributes to congestion, BRS decreases the burst bitrate. The
The rate by which BRS increases and decreases the bitrate for the rate by which BRS increases and decreases the bitrate for the
burst can be determined by a TCP-friendly bitrate adaptation burst can be determined by a TCP-friendly bitrate adaptation
algorithm for RTP over UDP , or in the case of (f) by the algorithm for RTP over UDP , or in the case of (f) by the
congestion control algorithms defined in DCCP [RFC5762]. congestion control algorithms defined in DCCP [RFC5762].
o If the congestion is persistent and BRS has to reduce the burst o If the congestion is persistent and BRS has to reduce the burst
bitrate to a point where the RTP Rx buffer might underrun or the bitrate to a point where the RTP Rx buffer might underrun or the
burst will consume too many resources, BRS should terminate the burst will consume too many resources, BRS terminates the burst
burst and transmit a RAMS-I message to RTP Rx with the appropriate and transmits a RAMS-I message to RTP Rx with the appropriate
response code. It is then up to RTP Rx to decide when to join the response code. It is then up to RTP Rx to decide when to join the
multicast session. multicast session.
Even though there is no congestion experienced during the burst, Even though there is no congestion experienced during the burst,
congestion may anyway arise near the end of the burst as RTP_Rx congestion may anyway arise near the end of the burst as RTP_Rx
eventually needs to join the multicast session. During this brief eventually needs to join the multicast session. During this brief
period both the burst packets and the multicast packets can be period both the burst packets and the multicast packets can be
simultaneously received by RTP_Rx, thus enhancing the risk of simultaneously received by RTP_Rx, thus enhancing the risk of
congestion. congestion.
Since BRS signals RTP_Rx when BRS expects RTP_Rx to send the SFGMP Since BRS signals RTP_Rx when BRS expects RTP_Rx to send the SFGMP
Join message, BRS can have a rough estimate of when RTP_Rx will start Join message, BRS can have a rough estimate of when RTP_Rx will start
receiving multicast packets in the SSM session. BRS can keep on receiving multicast packets in the SSM session. BRS can keep on
sending burst packets but should reduce the bitrate accordingly at sending burst packets but reduces the bitrate accordingly at the
the appropriate instant by taking the bitrate of the whole SSM appropriate instant by taking the bitrate of the whole SSM session
session into account. If BRS ceases transmitting the burst packets into account. If BRS ceases transmitting the burst packets before
before the burst catches up, any gap resulting from this imperfect the burst catches up, any gap resulting from this imperfect switch-
switch-over by RTP_Rx can be later repaired by requesting over by RTP_Rx can be later repaired by requesting retransmissions
retransmissions for the missing packets from RS. The retransmissions for the missing packets from RS. The retransmissions can be shaped
can be shaped by BRS to make sure that they do not cause collateral by BRS to make sure that they do not cause collateral loss in the
loss in the primary multicast RTP session and the unicast burst RTP primary multicast RTP session and the unicast burst RTP session.
session.
6.5. Failure Cases 6.5. Failure Cases
In the following, we examine the implications of losing the RAMS-R, In the following, we examine the implications of losing the RAMS-R,
RAMS-I or RAMS-T messages and other failure cases. RAMS-I or RAMS-T messages and other failure cases.
When RTP_Rx sends a RAMS-R message to initiate a rapid acquisition When RTP_Rx sends a RAMS-R message to initiate a rapid acquisition
but the message gets lost and FT does not receive it, RTP_Rx will get but the message gets lost and FT does not receive it, RTP_Rx will get
neither a RAMS-I message, nor a unicast burst. In this case, RTP_Rx neither a RAMS-I message, nor a unicast burst. In this case, RTP_Rx
MAY resend the request when it is eligible to do so based on the RTCP MAY resend the request when it is eligible to do so based on the RTCP
timer rules defined in [RFC4585]. Or, after a reasonable amount of timer rules defined in [RFC4585]. Or, after a reasonable amount of
time, RTP_Rx can time out (based on the previous observed response time, RTP_Rx can time out (based on the previous observed response
times) and immediately join the SSM session. times) and immediately join the SSM session.
In the case RTP_Rx starts receiving a unicast burst but it does not In the case RTP_Rx starts receiving a unicast burst but it does not
receive a corresponding RAMS-I message within a reasonable amount of receive a corresponding RAMS-I message within a reasonable amount of
time, RTP_Rx can either discard the burst data or decide not to time, RTP_Rx can either discard the burst data or decide not to
interrupt the unicast burst, and be prepared to join the SSM session interrupt the unicast burst, and be prepared to join the SSM session
at an appropriate time it determines or as indicated in a subsequent at an appropriate time it determines or as indicated in a subsequent
RAMS-I message (if available). To minimize the chances of losing the RAMS-I message (if available). If the network is subject to packet
RAMS-I messages, it is RECOMMENDED that BRS repeats the RAMS-I loss, it is RECOMMENDED that BRS repeats the RAMS-I messages multiple
messages multiple times based on the RTCP timer rules defined in times based on the RTCP timer rules defined in [RFC4585].
[RFC4585].
In the failure cases where the RAMS-R message is lost and RTP_Rx In the failure cases where the RAMS-R message is lost and RTP_Rx
gives up, or the RAMS-I message is lost, RTP_Rx MUST still terminate gives up, or the RAMS-I message is lost, RTP_Rx MUST still terminate
the burst(s) it requested by following the rules described in the burst(s) it requested by following the rules described in
Section 6.2. Section 6.2.
In the case a RAMS-T message sent by RTP_Rx does not reach its In the case a RAMS-T message sent by RTP_Rx does not reach its
destination, BRS can continue sending burst packets even though destination, BRS can continue sending burst packets even though
RTP_Rx no longer needs them. In such cases, it is RECOMMENDED that RTP_Rx no longer needs them. In such cases, it is RECOMMENDED that
RTP_Rx repeats the RAMS-T message multiple times based on the RTCP RTP_Rx repeats the RAMS-T message multiple times based on the RTCP
timer rules defined in [RFC4585]. BRS MUST be provisioned to timer rules defined in [RFC4585]. BRS MUST be provisioned to
deterministically terminate the burst when it can no longer send the deterministically terminate the burst when it can no longer send the
burst packets faster than it receives the primary multicast stream burst packets faster than it receives the primary multicast stream
packets. packets.
Section 6.3.5 of [RFC3550] explains the rules pertaining to timing Section 6.3.5 of [RFC3550] explains the rules pertaining to timing
out an SSRC. When BRS accepts to serve the requested burst(s) and out an SSRC. When BRS accepts to serve the requested burst(s) and
establishes the retransmission session, it should check the liveness establishes the retransmission session, BRS needs to check the
of RTP_Rx via the RTCP messages and reports RTP_Rx sends. The liveness of RTP_Rx via the RTCP messages and reports RTP_Rx sends.
default rules explained in [RFC3550] apply in RAMS as well. The default rules explained in [RFC3550] apply in RAMS as well.
7. Encoding of the Signaling Protocol in RTCP 7. Encoding of the Signaling Protocol in RTCP
This section defines the formats of the RTCP transport-layer feedback This section defines the formats of the RTCP transport-layer feedback
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 33, line 27 skipping to change at page 33, line 15
putting zero in the Response field. putting zero in the Response field.
The following TLV elements have been defined for the RAMS-I messages: The following TLV elements have been defined for the RAMS-I messages:
o Media Sender SSRC (32 bits): Optional TLV element that specifies o Media Sender SSRC (32 bits): Optional TLV element that specifies
the media sender SSRC of the unicast burst stream. While this the media sender SSRC of the unicast burst stream. While this
information is already available in the message header, it can be information is already available in the message header, it can be
useful to repeat it in an explicit field. If FT_Ap that received useful to repeat it in an explicit field. If FT_Ap that received
the RAMS-R message is associated with a single primary multicast the RAMS-R message is associated with a single primary multicast
stream but the requested media sender SSRC does not match the SSRC stream but the requested media sender SSRC does not match the SSRC
of the RTP stream associated with this FT_Ap, BRS MUST include of the RTP stream associated with this FT_Ap, BRS includes this
this TLV element in the initial RAMS-I message to let RTP_Rx know TLV element in the initial RAMS-I message to let RTP_Rx know that
that the media sender SSRC has changed. If the two SSRCs match, the media sender SSRC has changed. If the two SSRCs match, there
there is no need to include this TLV element. is no need to include this TLV element.
Type: 31 Type: 31
o RTP Seqnum of the First Packet (16 bits): TLV element that o RTP Seqnum of the First Packet (16 bits): TLV element that
specifies the RTP sequence number of the first packet that will be specifies the RTP sequence number of the first packet that will be
sent in the respective RTP stream. This allows RTP_Rx to know sent in the respective RTP stream. This allows RTP_Rx to know
whether one or more packets sent by BRS have been dropped at the whether one or more packets sent by BRS have been dropped at the
beginning of the stream. If BRS accepts the RAMS request, this beginning of the stream. If BRS accepts the RAMS request, this
element MUST exist. If BRS rejects the RAMS request, this element element exists. If BRS rejects the RAMS request, this element
SHALL NOT exist. SHALL NOT exist.
Type: 32 Type: 32
o Earliest Multicast Join Time (32 bits): TLV element that o Earliest Multicast Join Time (32 bits): TLV element that
specifies the delta time (in ms) between the arrival of the first specifies the delta time (in ms) between the arrival of the first
RTP packet in the RTP stream (which could be a burst packet or a RTP packet in the RTP stream (which could be a burst packet or a
payload-specific packet) and the earliest time instant when RTP_Rx payload-specific packet) and the earliest time instant when RTP_Rx
SHOULD send an SFGMP Join message to join the multicast session. sends an SFGMP Join message to join the multicast session. A zero
A zero value in this field means that RTP_Rx can send the SFGMP value in this field means that RTP_Rx can send the SFGMP Join
Join message right away. message right away.
If the RAMS request has been accepted, BRS MUST send this field at If the RAMS request has been accepted, BRS sends this field at
least once, so that RTP_Rx knows when to join the multicast least once, so that RTP_Rx knows when to join the multicast
session. If the burst request has been rejected as indicated in session. If the burst request has been rejected as indicated in
the Response field, this field MUST be set to zero. In that case, the Response field, this field MUST be set to zero. In that case,
it is up to RTP_Rx when or whether to join the multicast session. it is up to RTP_Rx when or whether to join the multicast session.
When BRS serves two or more bursts and sends a separate RAMS-I When 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
messages should correspond to more or less the same time instant, messages should correspond to more or less the same time instant,
and RTP_Rx sends the SFGMP Join message based on the earliest join and RTP_Rx sends the SFGMP Join message based on the earliest join
time. time.
skipping to change at page 34, line 45 skipping to change at page 34, line 33
o Max Transmit Bitrate (64 bits): Optional TLV element that denotes o Max Transmit Bitrate (64 bits): Optional TLV element that denotes
the maximum bitrate (in bits per second) that will be used by BRS the maximum bitrate (in bits per second) that will be used by BRS
for the RTP stream associated with this RAMS-I message. for the RTP stream associated with this RAMS-I message.
Type: 35 Type: 35
The semantics of the RAMS-I feedback message is independent of the The semantics of the RAMS-I feedback message is independent of the
payload type. payload type.
The initial RAMS-I message SHOULD precede the unicast burst or be
sent at the start of the burst. Subsequent RAMS-I message(s) MAY be
sent during the unicast burst and convey changes in any of the
fields.
7.4. RAMS Termination 7.4. RAMS Termination
The RAMS Termination message is identified by SFMT=3. The RAMS Termination message is identified by SFMT=3.
The RAMS Termination is used to assist BRS in determining when to The RAMS Termination is used to assist BRS in determining when to
stop the burst. A separate RAMS-T message is sent in the unicast stop the burst. A separate RAMS-T message is sent in the unicast
burst RTP session by RTP_Rx for each primary multicast stream that burst RTP session by RTP_Rx for each primary multicast stream that
has been served by BRS. Each of these RAMS-T messages has the has been served by BRS. Each of these RAMS-T messages has the
appropriate media sender SSRC populated in its message header. appropriate media sender SSRC populated in its message header.
skipping to change at page 36, line 50 skipping to change at page 36, line 35
included in the SDP description, RTP_Rx SHALL NOT send updated included in the SDP description, RTP_Rx SHALL NOT send updated
requests. RTP_Rx MAY still repeat its initial request without requests. RTP_Rx MAY still repeat its initial request without
changes, though. changes, though.
8.2. Requirements 8.2. Requirements
The use of SDP to describe the RAMS entities normatively requires the The use of SDP to describe the RAMS entities normatively requires the
support for: support for:
o The SDP grouping framework and flow identification (FID) semantics o The SDP grouping framework and flow identification (FID) semantics
[I-D.ietf-mmusic-rfc3388bis] [RFC5888]
o The RTP/AVPF profile [RFC4585] o The RTP/AVPF profile [RFC4585]
o The RTP retransmission payload format [RFC4588] o The RTP retransmission payload format [RFC4588]
o The RTCP extensions for SSM sessions with unicast feedback o The RTCP extensions for SSM sessions with unicast feedback
[RFC5760] [RFC5760]
o The multicast RTCP port attribute o The multicast RTCP port attribute [I-D.ietf-avt-rtcp-port-for-ssm]
[I-D.begen-avt-rtcp-port-for-ssm]
o Multiplexing RTP and RTCP on a single port on both endpoints in o Multiplexing RTP and RTCP on a single port on both endpoints in
the unicast session[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.
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
skipping to change at page 40, line 43 skipping to change at page 39, line 48
feedback in the primary multicast RTP session, and the request is feedback in the primary multicast RTP session, and the request is
received by FT, a new unicast burst RTP session will be established received by FT, a new unicast burst RTP session will be established
between BRS and RTP_Rx. between BRS and RTP_Rx.
While the FT and BRS ports on RS are already signaled via out-of-band While the FT and BRS ports on RS are already signaled via out-of-band
means (e.g., SDP), RTP_Rx needs to convey the RTP and RTCP ports it means (e.g., SDP), RTP_Rx needs to convey the RTP and RTCP ports it
wants to use on its side for the new session. Since there are two wants to use on its side for the new session. Since there are two
RTP sessions (one multicast and one unicast) involved during this RTP sessions (one multicast and one unicast) involved during this
process and one of them is established upon a feedback message sent process and one of them is established upon a feedback message sent
in the other one, this requires an explicit port mapping method. in the other one, this requires an explicit port mapping method.
This problem equally applies to scenarios where the RTP media is
multicast in an SSM session, and an RTP_Rx requests retransmission
from a local repair server by using the RTCP NACK messages for the
missing packets and the repair server retransmits the requested
packets over a unicast session. Thus, instead of laying out a
specific solution for the RAMS applications, a general solution is
introduced in [I-D.ietf-avt-ports-for-ucast-mcast-rtp]. This generic
solution implies the exchange of port mapping RTCP messages between
RTP_Rx and BRS.
Applications using RAMS MUST support the solution presented in Applications using RAMS MUST support the solution presented in
[I-D.ietf-avt-ports-for-ucast-mcast-rtp] both on the RS and RTP_Rx [I-D.ietf-avt-ports-for-ucast-mcast-rtp] both on the RS and RTP_Rx
side to allow RTP receivers to use their desired ports and to support side to allow RTP receivers to use their desired ports and to support
RAMS behind NAT devices. The port mapping message exchange needs to RAMS behind NAT devices. The port mapping message exchange needs to
take place whenever RTP_Rx intends to make use of the RAMS protocol take place whenever RTP_Rx intends to make use of the RAMS protocol
for rapidly acquiring a specific multicast RTP session, prior to for rapidly acquiring a specific multicast RTP session, prior to
joining the associated SSM session. joining the associated SSM session.
10. Security Considerations 10. Security Considerations
skipping to change at page 44, line 43 skipping to change at page 43, line 43
----- -------------------------------------------------- ------------- ----- -------------------------------------------------- -------------
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 Assignable - Specification Required 4-254 Assignable - 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 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 SFMT represents and how it o A detailed description of what the new SFMT represents and how it
shall be interpreted. shall be interpreted.
New RAMS functionality is intended to be introduced by using the New RAMS functionality is intended to be introduced by using the
extension mechanism within the existing RAMS message types not by extension mechanism within the existing RAMS message types not by
skipping to change at page 45, line 46 skipping to change at page 44, line 46
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 Assignable - Specification Required 36-60 Assignable - Specification Required
61 Extended RTP Seqnum of First Multicast Packet [RFCXXXX] 61 Extended RTP Seqnum of First Multicast Packet [RFCXXXX]
62-127 Assignable - Specification Required 62-127 Assignable - 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 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 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.
11.6. RAMS Response Code Space Registry 11.6. RAMS Response Code Space Registry
skipping to change at page 47, line 39 skipping to change at page 46, line 39
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]
Any registration for an unassigned Response code MUST 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.
12. Contributors 12. Contributors
skipping to change at page 48, line 47 skipping to change at page 47, line 47
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source- Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, August 2006. Specific Multicast", RFC 4604, August 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[I-D.ietf-mmusic-rfc3388bis] [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description
Camarillo, G. and H. Schulzrinne, "The SDP (Session Protocol (SDP) Grouping Framework", RFC 5888, June 2010.
Description Protocol) Grouping Framework",
draft-ietf-mmusic-rfc3388bis-04 (work in progress),
November 2009.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006. July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006. July 2006.
skipping to change at page 49, line 37 skipping to change at page 48, line 34
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009. and Consequences", RFC 5506, April 2009.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, July 2008. Header Extensions", RFC 5285, July 2008.
[I-D.begen-avt-rtp-cnames]
Begen, A., Perkins, C., and D. Wing, "Guidelines for
Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs)", draft-begen-avt-rtp-cnames-02 (work in
progress), May 2010.
[I-D.ietf-avt-rapid-rtp-sync] [I-D.ietf-avt-rapid-rtp-sync]
Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", draft-ietf-avt-rapid-rtp-sync-10 (work in Flows", draft-ietf-avt-rapid-rtp-sync-11 (work in
progress), May 2010. progress), May 2010.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[I-D.begen-avt-rtcp-port-for-ssm] [I-D.ietf-avt-rtcp-port-for-ssm]
Begen, A., "RTP Control Protocol (RTCP) Port for Multicast Begen, A., "RTP Control Protocol (RTCP) Port for Multicast
Sessions", draft-begen-avt-rtcp-port-for-ssm-01 (work in Sessions", draft-ietf-avt-rtcp-port-for-ssm-00 (work in
progress), April 2010. progress), June 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.
[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.
skipping to change at page 50, line 40 skipping to change at page 49, line 31
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.
[I-D.ietf-avt-rtp-cnames]
Begen, A., Perkins, C., and D. Wing, "Guidelines for
Choosing RTP Control Protocol (RTCP) Canonical Names
(CNAMEs)", draft-ietf-avt-rtp-cnames-00 (work in
progress), June 2010.
[I-D.ietf-avt-multicast-acq-rtcp-xr] [I-D.ietf-avt-multicast-acq-rtcp-xr]
Begen, A. and E. Friedrich, "Multicast Acquisition Report Begen, A. and E. Friedrich, "Multicast Acquisition Report
Block Type for RTP Control Protocol (RTCP) Extended Block Type for RTP Control Protocol (RTCP) Extended
Reports (XRs)", draft-ietf-avt-multicast-acq-rtcp-xr-01 Reports (XRs)", draft-ietf-avt-multicast-acq-rtcp-xr-01
(work in progress), May 2010. (work in progress), May 2010.
[I-D.ietf-avt-ecn-for-rtp] [I-D.ietf-avt-ecn-for-rtp]
Westerlund, M., Johansson, I., Perkins, C., and K. Westerlund, M., Johansson, I., Perkins, C., and K.
Carlberg, "Explicit Congestion Notification (ECN) for RTP Carlberg, "Explicit Congestion Notification (ECN) for RTP
over UDP", draft-ietf-avt-ecn-for-rtp-01 (work in over UDP", draft-ietf-avt-ecn-for-rtp-01 (work in
skipping to change at page 51, line 46 skipping to change at page 50, line 41
5030 Sugarloaf Parkway 5030 Sugarloaf Parkway
Lawrenceville, GA 30044 Lawrenceville, GA 30044
USA USA
Email: billvs@cisco.com Email: billvs@cisco.com
Ali Begen Ali Begen
Cisco Cisco
181 Bay Street 181 Bay Street
Toronto, ON M5J 2T3 Toronto, ON M5J 2T3
CANADA Canada
Email: abegen@cisco.com Email: abegen@cisco.com
Tom VanCaenegem Tom VanCaenegem
Alcatel-Lucent Alcatel-Lucent
Copernicuslaan 50 Copernicuslaan 50
Antwerpen, 2018 Antwerpen, 2018
Belgium Belgium
Email: Tom.Van_Caenegem@alcatel-lucent.be Email: Tom.Van_Caenegem@alcatel-lucent.be
 End of changes. 53 change blocks. 
176 lines changed or deleted 156 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/