draft-ietf-avtext-multicast-acq-rtcp-xr-01.txt   draft-ietf-avtext-multicast-acq-rtcp-xr-02.txt 
AVT A. Begen AVT A. Begen
Internet-Draft E. Friedrich Internet-Draft E. Friedrich
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: October 1, 2011 March 30, 2011 Expires: October 8, 2011 April 6, 2011
Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP)
Extended Reports (XRs) Extended Reports (XRs)
draft-ietf-avtext-multicast-acq-rtcp-xr-01 draft-ietf-avtext-multicast-acq-rtcp-xr-02
Abstract Abstract
In most RTP-based multicast applications, the RTP source sends inter- In most RTP-based multicast applications, the RTP source sends inter-
related data. Due to this interdependency, randomly joining RTP related data. Due to this interdependency, randomly joining RTP
receivers usually cannot start consuming the multicast data right receivers usually cannot start consuming the multicast data right
after they join the session. Thus, they often experience a random after they join the session. Thus, they often experience a random
acquisition delay. An RTP receiver may use one ore more different acquisition delay. An RTP receiver can use one ore more different
approaches to achieve rapid acquisition. Yet, due to various approaches to achieve rapid acquisition. Yet, due to various
factors, performance of the rapid acquisition methods usually varies. factors, performance of the rapid acquisition methods usually varies.
Furthermore, in some cases the RTP receiver may (or may have to) do a Furthermore, in some cases the RTP receiver can (or be compelled to)
simple multicast join. For quality reporting, monitoring and do a simple multicast join. For quality reporting, monitoring and
diagnostics purposes, it is important to collect detailed information diagnostics purposes, it is important to collect detailed information
from the RTP receivers about their acquisition and presentation from the RTP receivers about their acquisition and presentation
experiences. This document addresses this issue by defining a new experiences. This document addresses this issue by defining a new
report block type, called Multicast Acquisition (MA) Report Block, report block type, called Multicast Acquisition (MA) Report Block,
within the framework of RTP Control Protocol (RTCP) Extended Reports within the framework of RTP Control Protocol (RTCP) Extended Reports
(XR) (RFC 3611). This document also defines the necessary signaling (XR) (RFC 3611). This document also defines the necessary signaling
of the new MA report block type in the Session Description Protocol of the new MA report block type in the Session Description Protocol
(SDP). (SDP).
Status of this Memo Status of this Memo
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 October 1, 2011. This Internet-Draft will expire on October 8, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 2, line 24 skipping to change at page 2, line 24
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Multicast Acquisition (MA) Report Block . . . . . . . . . . . 6 4. Multicast Acquisition (MA) Report Block . . . . . . . . . . . 6
4.1. Base Report . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Base Report . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Status Code Rules . . . . . . . . . . . . . . . . . . 7 4.1.1. Status Code Rules for New MA Methods . . . . . . . . . 7
4.1.2. Status Code Rules for the RAMS Method . . . . . . . . 8
4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 9 4.2.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 9
4.2.2. Private Extensions . . . . . . . . . . . . . . . . . . 11 4.2.2. Private Extensions . . . . . . . . . . . . . . . . . . 11
5. Session Description Protocol Signaling . . . . . . . . . . . . 13 5. Session Description Protocol Signaling . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. RTCP XR Block Type . . . . . . . . . . . . . . . . . . . . 15 7.1. RTCP XR Block Type . . . . . . . . . . . . . . . . . . . . 15
7.2. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 15 7.2. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 15
7.3. Multicast Acquisition Method Registry . . . . . . . . . . 15 7.3. Multicast Acquisition Method Registry . . . . . . . . . . 15
7.4. Multicast Acquisition Report Block TLV Space Registry . . 16 7.4. Multicast Acquisition Report Block TLV Space Registry . . 16
skipping to change at page 5, line 16 skipping to change at page 5, line 16
This document uses the following acronyms and definitions from This document uses the following acronyms and definitions from
[I-D.ietf-avt-rapid-acquisition-for-rtp]: [I-D.ietf-avt-rapid-acquisition-for-rtp]:
(Primary) Multicast Session: The multicast session to which RTP (Primary) Multicast Session: The multicast session to which RTP
receivers can join at a random point in time. receivers can join at a random point in time.
Primary Multicast RTP Session: The multicast RTP session an RTP Primary Multicast RTP Session: The multicast RTP session an RTP
receiver is interested in acquiring. receiver is interested in acquiring.
Primary Multicast (RTP) Streams: The RTP stream(s) carried in the
primary multicast RTP session.
Source Filtering Group Management Protocol (SFGMP): Following the Source Filtering Group Management Protocol (SFGMP): Following the
definition in [RFC4604], SFGMP refers to the Internet Group definition in [RFC4604], SFGMP refers to the Internet Group
Management Protocol (IGMP) version 3 [RFC3376] and the Multicast Management Protocol (IGMP) version 3 [RFC3376] and the Multicast
Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and
IPv6 networks, respectively. However, the report block type IPv6 networks, respectively. However, the report block type
introduced in this document does not depend on a specific version of introduced in this document does not depend on a specific version of
either of these group management protocols. In the remainder of this either of these group management protocols. In the remainder of this
document, SFGMP will refer to any group management protocol that has document, SFGMP will refer to any group management protocol that has
Join and Leave functionalities. Join and Leave functionalities.
Retransmission (Burst) Packet: An RTP packet that is formatted as Retransmission (Burst) Packet: An RTP packet that is formatted as
defined in [RFC4588]. defined in Section 4 of [RFC4588].
Reference Information: The set of certain media content and metadata Reference Information: The set of certain media content and metadata
information that is sufficient for an RTP receiver to start usefully information that is sufficient for an RTP receiver to start usefully
consuming a media stream. The meaning, format and size of this consuming a media stream. The meaning, format and size of this
information are specific to the application and are out of scope of information are specific to the application and are out of scope of
this document. this document.
(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 SSRC identifier that is unique in the stream is identified by its Synchronization Source (SSRC) identifier
primary multicast RTP session. The burst streams are typically that is unique in the primary multicast RTP session.
transmitted at an accelerated rate.
Retransmission Server (RS): The RTP/RTCP endpoint that can generate Retransmission Server (RS): The RTP/RTCP endpoint that can generate
the retransmission packets and the burst streams. RS may also the retransmission packets and the burst streams. The RS may also
generate other non-retransmission packets to aid the rapid generate other non-retransmission packets to aid the rapid
acquisition process. acquisition process.
4. Multicast Acquisition (MA) Report Block 4. Multicast Acquisition (MA) Report Block
This section defines the format of the MA report block. The base This section defines the format of the MA report block. The base
report is payload-independent. An extension mechanism is provided report is payload-independent. An extension mechanism is provided
where further optional payload-independent and payload-specific where further optional payload-independent and payload-specific
information can be included in the report as desired. information can be included in the report as desired.
The optional extensions that are defined in this document are The optional extensions that are defined in this document are
primarily developed for the method presented in primarily developed for the method presented in
[I-D.ietf-avt-rapid-acquisition-for-rtp]. Other methods that provide [I-D.ietf-avt-rapid-acquisition-for-rtp]. Other methods that provide
rapid acquisition MAY define their own extensions to be used in the rapid acquisition can define their own extensions to be used in the
MA report block. MA report block.
The packet format for the RTCP XR is defined in Section 2 of The packet format for the RTCP XR is defined in Section 2 of
[RFC3611]. Each XR packet has a fixed-length field for version, [RFC3611]. Each XR packet has a fixed-length field for version,
padding, reserved bits, payload type (PT), length, SSRC of packet padding, reserved bits, payload type (PT), length, SSRC of packet
sender as well as a variable-length field for report blocks. In the sender as well as a variable-length field for report blocks. In the
XR packets, the PT field is set to XR (207). XR packets, the PT field is set to XR (207).
The MA report block is better to be sent after all the necessary It is better to send the MA report block after all the necessary
information is collected and computed. Partial reporting is information is collected and computed. Partial reporting is
generally not useful as it may not give the full picture of the generally not useful as it cannot give the full picture of the
multicast acquisition, and causes additional complexity in terms of multicast acquisition, and causes additional complexity in terms of
report block matching and correlation. The MA report block SHOULD report block matching and correlation. The MA report block is only
only be sent as a part of an RTCP compound packet, and it is sent in sent as a part of an RTCP compound packet, and it is sent in the
the primary multicast session. primary multicast session.
The reliability of the MA report block is not any more essential than The need for reliability of the MA report block is not any greater
other report blocks or types. If desired, the report block could be than other report blocks or types. If desired, the report block
repeated for redundancy purposes while respecting to the RTCP could be repeated for redundancy purposes while respecting to the
scheduling algorithms. RTCP scheduling algorithms.
4.1. Base Report 4.1. Base Report
The base report format is shown in Figure 1. The base report format is shown in Figure 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=11 | MA Method | Block Length | | BT=11 | MA Method | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 26 skipping to change at page 7, line 26
that denotes the SSRC of the primary multicast stream. that denotes the SSRC of the primary multicast stream.
o Status (16 bits): Mandatory field that denotes the status code o Status (16 bits): Mandatory field that denotes the status code
for the MA operation. for the MA operation.
This document defines several status codes and registers them with This document defines several status codes and registers them with
IANA in Section 7.5. If a new vendor-neutral status code will be IANA in Section 7.5. If a new vendor-neutral status code will be
defined, it MUST be registered with IANA through the guidelines defined, it MUST be registered with IANA through the guidelines
specified in Section 7.5. If the new status code is intended to specified in Section 7.5. If the new status code is intended to
be used privately by a vendor, there is no need for IANA be used privately by a vendor, there is no need for IANA
management. Instead, the vendor MUST use the private extension management. Section 4.2.2 defines how a vendor defines and uses
mechanism (Section 4.2.2) to convey its message and MUST indicate private extensions to convey its messages. To indicate a private
this by putting zero in the Status field. extension, the RTP receiver MUST set the Status field to zero.
o Rsvd. (16 bits): This field SHALL be set to 0 and ignored on o Rsvd. (16 bits): The RTP receiver MUST set this bit to zero. The
reception. recipient MUST ignore this bit when received.
If the multicast join was successful meaning that at least one If the multicast join was successful meaning that at least one
multicast packet has been received, some additional information MUST multicast packet has been received, some additional information MUST
be appended to the base report as will be described in Section 4.2.1. be appended to the base report as will be described in Section 4.2.1.
4.1.1. Status Code Rules 4.1.1. Status Code Rules for New MA Methods
Different MA methods usually use different status codes, although Different MA methods usually use different status codes, although
some status codes (e.g., a code indicating that multicast join has some status codes (e.g., a code indicating that multicast join has
failed) may apply to more than one MA method. However, the status failed) can be common among multiple MA methods. The status code
code reported in the base report MUST always be within the scope of reported in the base report MUST always be within the scope of the
the particular MA method specified in the MA Method field. particular MA method specified in the MA Method field.
In certain MA methods, the RTP receiver may generate a status code In certain MA methods, the RTP receiver can generate a status code
for its multicast acquisition attempt, or may be told by another for its multicast acquisition attempt, or can be told by another
network element or RTP endpoint what the current status is via a network element or RTP endpoint what the current status is via a
response code. In such cases, the RTP receiver MAY report the value response code. In such cases, the RTP receiver MAY report the value
of the received response code as its status code if the response code of the received response code as its status code if the response code
has a higher priority. It is RECOMMENDED that each MA method has a higher priority. Each MA method needs to outline the rules
outlines the rules pertaining to its response and status codes so pertaining to its response and status codes so that RTP receiver
that RTP receiver implementations can determine what to report in any implementations can determine what to report in any given scenario.
given scenario. Below, we provide these rules for the RAMS method
4.1.2. Status Code Rules for the RAMS Method
In this section, we provide the status code rules for the RAMS method
described in [I-D.ietf-avt-rapid-acquisition-for-rtp]. described in [I-D.ietf-avt-rapid-acquisition-for-rtp].
Section 12.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] defines Section 11.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] defines
several response codes for its MA method. The 1xx and 2xx-level several response codes. The 1xx and 2xx-level response codes are
response codes are informational and success response codes, informational and success response codes, respectively. If the RTP
respectively. If the RTP receiver receives a 1xx or 2xx-level receiver receives a 1xx or 2xx-level response code, then the RTP
response code, it MUST use one of the 1xxx-level status codes defined receiver MUST use one of the 1xxx-level status codes defined in
in Section 7.5 of this document. The RTP receiver may also receive a Section 7.5 of this document. If the RTP receiver receives a 4xx or
4xx or 5xx-level response code (indicating receiver-side and server- 5xx-level response code (indicating receiver-side and server-side
side errors, respectively). In that case, the RTP receiver MUST use errors, respectively), then the RTP receiver MUST use the response
the response code as its status code. In other words, the 4xx and code as its status code. In other words, the 4xx and 5xx-level
5xx-level response codes have a higher priority than the 1xxx-level response codes have a higher priority than the 1xxx-level status
status codes. The 5xx-level response codes have a higher priority codes.
than the 4xx-level response codes and MUST be reported in the base
report in case the RTP receiver receives both 4xx and 5xx-level
response codes (in different RAMS-I messages) during the same RAMS
session.
4.2. Extensions 4.2. Extensions
To improve the reporting scope, it might be desirable to define new To improve the reporting scope, it might be desirable to define new
fields in the MA report block. Such fields MUST be encoded as TLV fields in the MA report block. Such fields are to be encoded as TLV
elements as described below and sketched in Figure 2: elements as described below and sketched in Figure 2:
o Type: A single-octet identifier that defines the type of the o Type: A single-octet identifier that defines the type of the
parameter represented in this TLV element. parameter represented in this TLV element.
o Length: A two-octet field that indicates the length (in octets) o Length: A two-octet field that indicates the length (in octets)
of the TLV element excluding the Type and Length fields, and the of the TLV element excluding the Type and Length fields, and the
8-bit Reserved field between them. Note that this length does not 8-bit Reserved field between them. Note that this length does not
include any padding that is required for alignment. include any padding that is needed 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 MUST be set to zero and ignored
ignored on reception. If a TLV element does not fall on a 32-bit on reception. If a TLV element does not fall on a 32-bit boundary,
boundary, the last word MUST be padded to the boundary using further the last word MUST be padded to the boundary using further bits set
bits set to zero. to zero.
In the MA report block, any vendor-neutral or private extension MUST In the MA report block, the RTP receiver MUST place any vendor-
be placed after the base report. neutral or private extension after the base report.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value : : Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Structure of a TLV element Figure 2: Structure of a TLV element
4.2.1. Vendor-Neutral Extensions 4.2.1. Vendor-Neutral Extensions
If the goal in defining new TLV elements is to extend the report If the goal in defining new TLV elements is to extend the report
block in a vendor-neutral manner, they MUST be registered with IANA block in a vendor-neutral manner, they need to be registered with
through the guidelines provided in Section 7.4. IANA through the guidelines provided in Section 7.4.
The current document defines several vendor-neutral extensions. The current document defines several vendor-neutral extensions.
First, we present the TLV elements that can be used by any RTP-based First, we present the TLV elements that can be used by any RTP-based
multicast application. multicast application.
o RTP Seqnum of the First Multicast Packet (16 bits): TLV element o RTP Seqnum of the First Multicast Packet (16 bits): TLV element
that specifies the RTP sequence number of the first multicast that specifies the RTP sequence number of the first multicast
packet received for the primary multicast stream. If the packet received for the primary multicast stream. If the
multicast join was successful, this element MUST exist. If no multicast join was successful, this element MUST be included. If
multicast packet has been received, this element SHALL NOT exist. no multicast packet has been received, this element MUST NOT exist
in the report block.
Type: 1 Type: 1
o SFGMP Join Time (32 bits): TLV element that denotes the greater o SFGMP Join Time (32 bits): TLV element that denotes the greater
of zero or the time difference (in ms) between the instant SFGMP of zero or the time difference (in ms) between the instant SFGMP
Join message has been sent and the instant the first packet was Join message has been sent and the instant the first packet was
received in the multicast session. If the multicast join was received in the multicast session. If the multicast join was
successful, this element MUST exist. If no multicast packet has successful, this element MUST be included. If no multicast packet
been received, this element SHALL NOT exist. has been received, this element MUST NOT exist in the report
block.
Type: 2 Type: 2
o Application Request-to-Multicast Delta Time (32 bits): Optional o Application Request-to-Multicast Delta Time (32 bits): Optional
TLV element that denotes the time difference (in ms) between the TLV element that denotes the time difference (in ms) between the
instant the application became aware it would join a new multicast instant the application became aware it would join a new multicast
session and the instant the first RTP packet was received from the session and the instant the first RTP packet was received from the
primary multicast stream. If no such packet has been received, primary multicast stream. If no such packet has been received,
this element SHALL NOT exist. this element MUST NOT exist in the report block.
Type: 3 Type: 3
o Application Request-to-Presentation Delta Time (32 bits): o Application Request-to-Presentation Delta Time (32 bits):
Optional TLV element that denotes the time difference (in ms) Optional TLV element that denotes the time difference (in ms)
between the instant the application became aware it would join a between the instant the application became aware it would join a
new multicast session and the instant the media is first new multicast session and the instant the media is first
presented. If the RTP receiver cannot successfully present the presented. If the RTP receiver cannot successfully present the
media, this element SHALL NOT exist. media, this element MUST NOT exist in the report block.
Type: 4 Type: 4
We next present the TLV elements that can be used when the RTP We next present the TLV elements that can be used when the RTP
receiver supports and uses the RAMS method described in receiver supports and uses the RAMS method described in
[I-D.ietf-avt-rapid-acquisition-for-rtp]. However, if the RTP [I-D.ietf-avt-rapid-acquisition-for-rtp]. However, if the RTP
receiver does not send a rapid acquisition request, the following TLV receiver does not send a rapid acquisition request, the following TLV
elements MUST NOT exist in the MA report block. Some elements may or elements MUST NOT exist in the MA report block. Some elements may or
may not exist depending on whether the RTP receiver receives any may not exist depending on whether the RTP receiver receives any
packet from the unicast burst and/or the primary multicast stream or packet from the unicast burst and/or the primary multicast stream or
skipping to change at page 10, line 33 skipping to change at page 10, line 36
a rapid acquisition and the instant the rapid acquisition request a rapid acquisition and the instant the rapid acquisition request
was actually sent by the application. was actually sent by the application.
Type: 11 Type: 11
o RAMS Request-to-RAMS Information Delta Time (32 bits): Optional o RAMS Request-to-RAMS Information Delta Time (32 bits): Optional
TLV element that denotes the time difference (in ms) between the TLV element that denotes the time difference (in ms) between the
instant the rapid acquisition request has been sent and the instant the rapid acquisition request has been sent and the
instant the first RAMS Information message was received in the instant the first RAMS Information message was received in the
unicast session. If no such message has been received, this unicast session. If no such message has been received, this
element SHALL NOT exist. element MUST NOT exist in the report block.
Type: 12 Type: 12
o RAMS Request-to-Burst Delta Time (32 bits): Optional TLV element o RAMS Request-to-Burst Delta Time (32 bits): Optional TLV element
that denotes the time difference (in ms) between the instant the that denotes the time difference (in ms) between the instant the
rapid acquisition request has been sent and the instant the first rapid acquisition request has been sent and the instant the first
burst packet was received in the unicast session. If no burst burst packet was received in the unicast session. If no burst
packet has been received, this element SHALL NOT exist. packet has been received, this element MUST NOT exist in the
report block.
Type: 13 Type: 13
o RAMS Request-to-Multicast Delta Time (32 bits): Optional TLV o RAMS Request-to-Multicast Delta Time (32 bits): Optional TLV
element that denotes the time difference (in ms) between the element that denotes the time difference (in ms) between the
instant the rapid acquisition request has been sent and the instant the rapid acquisition request has been sent and the
instant the first RTP packet was received from the primary instant the first RTP packet was received from the primary
multicast stream. If no such packet has been received, this multicast stream. If no such packet has been received, this
element SHALL NOT exist. element MUST NOT exist in the report block.
Type: 14 Type: 14
o RAMS Request-to-Burst-Completion Delta Time (32 bits): Optional o RAMS Request-to-Burst-Completion Delta Time (32 bits): Optional
TLV element that denotes the time difference (in ms) between the TLV element that denotes the time difference (in ms) between the
instant the rapid acquisition request has been sent and the instant the rapid acquisition request has been sent and the
instant the last burst packet was received in the unicast session. instant the last burst packet was received in the unicast session.
If no burst packet has been received, this element SHALL NOT If no burst packet has been received, this element MUST NOT exist
exist. in the report block.
Type: 15 Type: 15
o Number of Duplicate Packets (32 bits): Optional TLV element that o Number of Duplicate Packets (32 bits): Optional TLV element that
denotes the number of duplicate packets due to receiving the same denotes the number of duplicate packets due to receiving the same
packet in both unicast and primary multicast RTP sessions. If no packet in both unicast and primary multicast RTP sessions. If no
RTP packet has been received from the primary multicast stream, RTP packet has been received from the primary multicast stream,
this element SHALL NOT exist. If no burst packet has been this element MUST NOT exist. If no burst packet has been received
received in the unicast session, the value of this element SHALL in the unicast session, the value of this element MUST be set to
be set to zero. zero.
Type: 16 Type: 16
o Size of Burst-to-Multicast Gap (32 bits): Optional TLV element o Size of Burst-to-Multicast Gap (32 bits): Optional TLV element
that denotes the greater of zero or the difference between the that denotes the greater of zero or the difference between the
sequence number of the first multicast packet (received from the sequence number of the first multicast packet (received from the
primary multicast stream) and the sequence number of the last primary multicast stream) and the sequence number of the last
burst packet minus 1 (considering the wrapping of the sequence burst packet minus 1 (considering the wrapping of the sequence
numbers). If no burst packet has been received in the unicast numbers). If no burst packet has been received in the unicast
session or no RTP packet has been received from the primary session or no RTP packet has been received from the primary
multicast stream, this element SHALL NOT exist. multicast stream, this element MUST NOT exist in the report block.
Type: 17 Type: 17
4.2.2. Private Extensions 4.2.2. Private Extensions
It is desirable to allow vendors to use private extensions in TLV It is desirable to allow vendors to use private extensions in TLV
format. For interoperability, such extensions MUST NOT collide with format. The range of [128-254] of TLV Types is reserved for private
each other.
The range of [128-254] of TLV Types is reserved for private
extensions. IANA management for these extensions is unnecessary and extensions. IANA management for these extensions is unnecessary and
they are the responsibility of individual vendors. they are the responsibility of individual vendors.
The structure that MUST be used for the private extensions is Implementations use the structure depicted in Figure 3 for the
depicted in Figure 3. Here, the private enterprise numbers are used private extensions. Here, the private enterprise numbers are used
from http://www.iana.org/assignments/enterprise-numbers. This will from http://www.iana.org/assignments/enterprise-numbers. This will
ensure the uniqueness of the private extensions and avoid any ensure the uniqueness of the private extensions and avoid any
collision. collision.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length | | Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number | | Enterprise Number |
skipping to change at page 14, line 16 skipping to change at page 14, line 16
The security considerations of [RFC3611] apply in this document as The security considerations of [RFC3611] apply in this document as
well. well.
The information contained in MA reports could be stolen as any other The information contained in MA reports could be stolen as any other
RTCP reports if proper protection mechanism(s) are not in place. If RTCP reports if proper protection mechanism(s) are not in place. If
desired, similar to other RTCP XR reports, the MA reports MAY be desired, similar to other RTCP XR reports, the MA reports MAY be
protected by using Secure RTP (SRTP) and Secure RTP Control Protocol protected by using Secure RTP (SRTP) and Secure RTP Control Protocol
(SRTCP) [RFC3711]. (SRTCP) [RFC3711].
Malicious sniffing or otherwise obtaining MA report blocks can reveal
performance characteristics of the RTP service and underlying
network. This information is mostly available to an observer with
the ability to capture RTP and RTCP session traffic. The contents
and value of any private extensions need to be studied when
considering the necessity to secure the MA reports since application-
level performance data might be present that is not otherwise
available to an attacker as with the required fields and vendor-
neutral extensions.
Using the MA reports to provide feedback into the acquisition of the Using the MA reports to provide feedback into the acquisition of the
multicast streams can introduce possible additional security multicast streams can introduce possible additional security
implications. If a forged or otherwise modified MA report is implications. If a forged or otherwise modified MA report is
received for an earlier acquisition attempt, invalid data may be used received for an earlier acquisition attempt, invalid data can be used
as input in later rapid acquisition attempts. For example, as input in later rapid acquisition attempts. For example,
incorrectly small SFGMP join times could cause the unicast burst to incorrectly small SFGMP join times could cause the unicast burst to
be too short, leading to gaps in sequence numbers in the approach be too short, leading to gaps in sequence numbers in the approach
discussed in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Additionally, discussed in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Additionally,
forged reports could give the appearance that rapid acquisition is forged reports could give the appearance that rapid acquisition is
performing correctly, when it is in fact failing, or vice versa. performing correctly, when it is in fact failing, or vice versa.
However, the MA reports are believed not to introduce any additional However, the MA reports are believed not to introduce any additional
risks from a confidentiality viewpoint. risks from a confidentiality viewpoint.
7. IANA Considerations 7. IANA Considerations
The following contact information shall be used for all registrations The following contact information is provided 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
the number of this document prior to publication as an RFC. the number of this document prior to publication as an RFC.
7.1. RTCP XR Block Type 7.1. RTCP XR Block Type
skipping to change at page 16, line 46 skipping to change at page 16, line 46
values between (and including) 128 and 254 are reserved for private values between (and including) 128 and 254 are reserved for private
extensions. extensions.
Any registration for an unassigned Type value needs to 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 is interpreted.
7.5. Multicast Acquisition Status Code Space Registry 7.5. Multicast Acquisition Status Code Space Registry
This document creates a new IANA TLV space registry for the status This document creates a new IANA TLV space registry for the status
codes. The registry is called the Multicast Acquisition Status Code codes. The registry is called the Multicast Acquisition Status Code
Space Registry. This registry is to be managed by the IANA according Space Registry. This registry is to be managed by the IANA according
to the Specification Required policy of [RFC5226]. to the Specification Required policy of [RFC5226].
The length of the Status field is two octets, allowing 65536 codes. The length of the Status field is two octets, allowing 65536 codes.
However, the status codes have been registered to allow for an easier However, the status codes have been registered to allow for an easier
skipping to change at page 17, line 50 skipping to change at page 17, line 50
during RAMS [RFCXXXX] during RAMS [RFCXXXX]
1007 A presentation error has occurred during RAMS [RFCXXXX] 1007 A presentation error has occurred during RAMS [RFCXXXX]
Any registration for an unassigned Status code needs to contain the Any registration for an unassigned Status 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 Status code describes and o A detailed description of what the new Status code describes and
how it shall be interpreted. how it is interpreted.
8. Acknowledgments 8. Acknowledgments
This specification has greatly benefited from discussions with This specification has greatly benefited from discussions with
Michael Lague, Dong Hsu, Carol Iturralde, Xuan Zhong, Dave Oran, Tom Michael Lague, Dong Hsu, Carol Iturralde, Xuan Zhong, Dave Oran, Tom
Van Caenegem and many others. The authors would like to thank each Van Caenegem and many others. The authors would like to thank each
of these individuals for their contributions. of these individuals for their contributions.
9. References 9. References
skipping to change at page 19, line 42 skipping to change at page 19, line 42
[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.
[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.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
IANA Considerations Section in RFCs", BCP 26, RFC 5226, Norrman, "The Secure Real-time Transport Protocol (SRTP)",
May 2008. RFC 3711, March 2004.
9.2. Informative References 9.2. Informative References
[I-D.ietf-avt-rapid-acquisition-for-rtp] [I-D.ietf-avt-rapid-acquisition-for-rtp]
Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast-
Based Rapid Acquisition of Multicast RTP Sessions", Based Rapid Acquisition of Multicast RTP Sessions",
draft-ietf-avt-rapid-acquisition-for-rtp-17 (work in draft-ietf-avt-rapid-acquisition-for-rtp-17 (work in
progress), November 2010. progress), November 2010.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
Norrman, "The Secure Real-time Transport Protocol (SRTP)", IANA Considerations Section in RFCs", BCP 26, RFC 5226,
RFC 3711, March 2004. May 2008.
Authors' Addresses Authors' Addresses
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
 End of changes. 46 change blocks. 
96 lines changed or deleted 102 lines changed or added

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