AVT A. Begen
Internet-Draft E. Friedrich
Intended status: Standards Track Cisco Systems
Expires: November 14, 2009 May 13, 2009
Multicast Acquisition Report Block Type for RTCP XR
draft-begen-avt-rapid-sync-rtcp-xr-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 14, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Begen & Friedrich Expires November 14, 2009 [Page 1]
Internet-Draft MA Report Block Type for RTCP XR May 2009
Abstract
In most RTP-based multicast applications, the RTP source sends inter-
related data. Due to this interdependency, randomly joining RTP
receivers usually cannot start consuming the multicast data right
after they join the session. Thus, they often experience a random
acquisition delay. One approach to reduce this delay is to use an
auxiliary unicast RTP session with a retransmission server to receive
a burst stream that facilitates rapid acquisition of the multicast
stream. An RTP receiver may use this approach (or any other
approach) to achieve rapid acquisition. Yet, due to various factors,
performance of the rapid acquisition methods usually varies.
Furthermore, in some cases the RTP receiver may (or may have to) do a
simple multicast join. For quality reporting, monitoring and
diagnostics purposes, it is important to collect detailed information
from the RTP receivers about their acquisition experiences. This
document addresses this issue by defining a new report block type,
called Multicast Acquisition (MA) Report Block, within the framework
of RTP Control Protocol (RTCP) Extended Reports (XR). This document
also defines the necessary signaling of the new MA report block type
in the Session Description Protocol (SDP).
Begen & Friedrich Expires November 14, 2009 [Page 2]
Internet-Draft MA Report Block Type for RTCP XR May 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Multicast Acquisition (MA) Report Block . . . . . . . . . . . 7
4.1. Base Report . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 8
4.2.2. Private Extensions . . . . . . . . . . . . . . . . . . 11
5. Session Description Protocol Signaling . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.1. RTCP XR Block Type . . . . . . . . . . . . . . . . . . . . 15
7.2. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 15
7.3. Multicast Acquisition Report Block TLV Space Registry . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Begen & Friedrich Expires November 14, 2009 [Page 3]
Internet-Draft MA Report Block Type for RTCP XR May 2009
1. Introduction
RTP Control Protocol (RTCP) is the out-of-band control protocol for
the applications that are using the Real-time Transport Protocol
(RTP) for media transport [RFC3550]. In addition to providing
minimal control functionality to RTP entities, RTCP also enables a
basic level monitoring of RTP sessions via sender and receiver
reports. More statistically detailed monitoring as well as
application-specific monitoring is usually achieved through the RTCP
Extended Reports (XR) [RFC3611].
In most RTP-based multicast applications such as the ones carrying
video content, the RTP source sends inter-related data.
Consequently, the RTP application may not be able to decode and
present the data in an RTP packet before decoding one or more earlier
RTP packets and/or before acquiring some Reference Information about
the content itself. Thus, RTP receivers that are randomly joining a
multicast session often experience a random acquisition delay. In
order to reduce this delay, [I-D.ietf-avt-rapid-acquisition-for-rtp]
proposes an approach where an auxiliary unicast RTP session is
established between a retransmission server and the joining RTP
receiver. Over this unicast RTP session, the retransmission server
provides the Reference Information, which is all the information the
RTP receiver needs to rapidly acquire the multicast stream. However,
depending on the variability in the Source Filtering Group Management
Protocol (SFGMP) processing times, availability of network resources
for rapid acquisition and nature of the RTP data, not all RTP
receivers can acquire the multicast stream in the same amount of
time. The performance of rapid acquisition may vary not only for
different RTP receivers but also over time.
To increase the visibility of the multicast service provider into its
network, to diagnose slow multicast acquisition issues and to collect
the acquisition experiences of the RTP receivers, this document
defines a new report block type, which is called Multicast
Acquisition (MA) Report Block, within the framework of RTCP XR. RTP
receivers that are using the method described in
[I-D.ietf-avt-rapid-acquisition-for-rtp] MAY use this report every
time they join a new multicast RTP session. RTP receivers that use a
different method for rapid acquisition or those do not use any method
but rather do a simple multicast join MAY also use this report. This
way, the multicast service provider can quantitatively compare the
improvements achieved by different methods.
Begen & Friedrich Expires November 14, 2009 [Page 4]
Internet-Draft MA Report Block Type for RTCP XR May 2009
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Begen & Friedrich Expires November 14, 2009 [Page 5]
Internet-Draft MA Report Block Type for RTCP XR May 2009
3. Definitions
This document uses the following acronyms and definitions from
[I-D.ietf-avt-rapid-acquisition-for-rtp]:
Primary Multicast Session: A multicast session which RTP receivers
can join at a random point in time.
Primary Multicast Stream: The RTP stream to be acquired by the RTP
receiver.
Source Filtering Group Management Protocol (SFGMP): Following the
definition in [RFC4604], SFGMP refers to the Internet Group
Management Protocol (IGMP) version 3 [RFC3376] and the Multicast
Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and
IPv6 networks, respectively.
Retransmission Packet: An RTP packet that is formatted as defined in
[RFC4588].
Reference Information: The set of certain media content and metadata
information that is sufficient for an RTP receiver to start usefully
consuming a media stream. The meaning, format and size of this
information are specific to the application.
(Unicast) Burst (Stream): A unicast stream of RTP retransmission
packets that enable an RTP receiver to rapidly acquire the Reference
Information. The burst stream is typically transmitted at an
accelerated rate.
Retransmission Server (RS): The RTP/RTCP endpoint that can generate
the retransmission packets and the burst stream.
Begen & Friedrich Expires November 14, 2009 [Page 6]
Internet-Draft MA Report Block Type for RTCP XR May 2009
4. Multicast Acquisition (MA) Report Block
This section defines the format of the MA report block. The base
report is payload-independent. An extension mechanism is provided
where further optional payload-independent and payload-specific
information can be included in the report as desired.
The optional extensions that are defined in this document are
primarily developed for the method presented in
[I-D.ietf-avt-rapid-acquisition-for-rtp]. Other methods that provide
rapid acquisition of multicast streams MAY define their own
extensions to be used in the MA report block.
The packet format for the RTCP XR is defined in Section 2 of
[RFC3611]. Each XR packet has a fixed-length field for version,
padding, reserved bits, payload type (PT), length, SSRC of packet
sender as well as a variable-length field for report blocks. In the
XR packets, the PT field is set to XR (207).
4.1. Base Report
The base report format is shown in Figure 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=TBD | Status | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of the Primary Multicast Stream |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Base report format for the MA report block
o BT (8 bits): Mandatory field that denotes the type for this block
format. The MA report block is identified by the constant TBD.
o Status (8 bits): Mandatory field that denotes the status code.
Editor's note: Status codes will be defined and registered with
IANA in a later version. It is desirable to have status codes
corresponding to the response codes that are proposed in Section
7.2 of [I-D.ietf-avt-rapid-acquisition-for-rtp].
o Block Length (16 bits): The length of this report block,
including the header, in 32-bit words minus one.
Begen & Friedrich Expires November 14, 2009 [Page 7]
Internet-Draft MA Report Block Type for RTCP XR May 2009
o SSRC of the Primary Multicast Stream (32 bits): Mandatory field
that denotes the SSRC of the primary multicast stream.
4.2. Extensions
To improve the reporting scope, it may be desirable to define new
fields in the MA report block. Such fields MUST be encoded as TLV
elements as described below and sketched in Figure 2:
o Type: A single-octet identifier that defines the type of the
parameter represented in this TLV element.
o Length: A two-octet field that indicates the length of the TLV
element excluding the Type and Length fields in octets. Note that
this length does not include any padding that is required for
alignment.
o Value: Variable-size set of octets that contains the specific
value for the parameter.
If a TLV element does not fall on a 32-bit boundary, the last word
MUST be padded to the boundary using further bits set to zero.
In the MA report block, any vendor-neutral or private extension MUST
be placed after the base report. The support for extensions is
OPTIONAL.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value contd. /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Structure of a TLV element
4.2.1. Vendor-Neutral Extensions
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
through the guidelines provided in Section 7.3.
The current document defines several vendor-neutral extensions.
First, we present the TLV elements that can be used by any RTP-based
multicast application.
Begen & Friedrich Expires November 14, 2009 [Page 8]
Internet-Draft MA Report Block Type for RTCP XR May 2009
o Extended RTP Seqnum of First Multicast Packet: Optional TLV
element that specifies the extended RTP sequence number of the
first multicast packet received for the primary multicast stream.
If no such packet has been received, this element SHALL NOT exist.
Type: TBD
Length: TBD
o SFGMP Join Time: Optional TLV element that denotes the greater of
zero or the time difference (in ms) between the instant SFGMP Join
message has been sent and the instant the first RTP packet was
received from the primary multicast session. If no RTP packet has
been received from the primary multicast session, this element
SHALL NOT exist.
Type: TBD
Length: TBD
o Application Request-to-Multicast Delta Time: Optional TLV element
that denotes the time difference (in ms) between the instant the
application became aware it would join a new multicast session and
the instant the first RTP multicast packet was received for the
primary multicast stream. If no such packet has been received,
this element SHALL NOT exist.
Type: TBD
Length: TBD
o Application Request-to-Presentation Delta Time: Optional TLV
element that denotes the time difference (in ms) between the
instant the application became aware it would join a new multicast
session and the instant the media is first presented. If the RTP
receiver cannot succesfully present the media, this element SHALL
NOT exist.
Type: TBD
Length: TBD
We next present the TLV elements that can be used when the RTP
receiver supports and uses the method described in
[I-D.ietf-avt-rapid-acquisition-for-rtp]. However, if the RTP
receiver does not send a rapid acquisition request, the following TLV
elements MUST NOT exist in the MA report block. Some elements may or
may not exist depending on whether the RTP receiver receives any
Begen & Friedrich Expires November 14, 2009 [Page 9]
Internet-Draft MA Report Block Type for RTCP XR May 2009
packet from the unicast and/or the primary multicast session or not.
These are explained below.
o Application Request-to-RTCP Request Delta Time: Optional TLV
element that denotes the time difference (in ms) between the
instant the application became aware it would request a rapid
acquisition and the instant the rapid acquisition request was
actually sent by the application.
Type: TBD
Length: TBD
o Request-to-Burst Delta Time: Optional TLV element that denotes
the time difference (in ms) between the instant the rapid
acquisition request has been sent and the instant the first burst
packet was received from the unicast session. If no RTP packet
has been received from the unicast session, this element SHALL NOT
exist.
Type: TBD
Length: TBD
o Request-to-Multicast Delta Time: Optional TLV element that
denotes the time difference (in ms) between the instant the rapid
acquisition request has been sent and the instant the first RTP
multicast packet was received for the primary multicast stream.
If no such packet has been received, this element SHALL NOT exist.
Type: TBD
Length: TBD
o Request-to-Burst-Completion Delta Time: Optional TLV element that
denotes the time difference (in ms) between the instant the rapid
acquisition request has been sent and the instant the last burst
packet was received from the unicast session. If no RTP packet
has been received from the unicast session, this element SHALL NOT
exist.
Type: TBD
Length: TBD
o Number of Duplicate Packets: Optional TLV element that denotes
the number of duplicate packets due to receiving the same packet
from both unicast and primary multicast sessions. If no RTP
Begen & Friedrich Expires November 14, 2009 [Page 10]
Internet-Draft MA Report Block Type for RTCP XR May 2009
multicast packet has been received for the primary multicast
stream, this element SHALL NOT exist. If no RTP packet has been
received from the unicast session, the value of this element SHALL
be set to zero.
Type: TBD
Length: TBD
o Size of Burst-to-Multicast Gap: Optional TLV element that denotes
the greater of zero or the difference between the sequence number
of the first multicast packet (received for the primary multicast
stream) and the sequence number of the last burst packet minus 1
(considering the wrapping of the sequence numbers). If no RTP
packet has been received from the unicast session or no RTP
multicast packet has been received for the primary multicast
stream, this element SHALL NOT exist.
Type: TBD
Length: TBD
4.2.2. Private Extensions
It is desirable to allow vendors to use private extensions in TLV
format. For interoperability, such extensions MUST NOT collide with
each other.
A certain range of TLV Types is reserved for private extensions
(Refer to Section 7.3). IANA management for these extensions is
unnecessary and they are the responsibility of individual vendors.
The structure that MUST be used for the private extensions is
depicted in Figure 3. Here, the enterprise numbers are used from
http://www.iana.org/assignments/enterprise-numbers. This will ensure
the uniqueness of the private extensions and avoid any collision.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Ent. Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ent. Number contd. | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value contd. /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Begen & Friedrich Expires November 14, 2009 [Page 11]
Internet-Draft MA Report Block Type for RTCP XR May 2009
Figure 3: Structure of a private extension
Begen & Friedrich Expires November 14, 2009 [Page 12]
Internet-Draft MA Report Block Type for RTCP XR May 2009
5. Session Description Protocol Signaling
A new parameter is defined for the MA report block to be used with
Session Description Protocol (SDP) [RFC4566]. It has the following
syntax within the 'rtcp-xr' attribute:
rtcp-xr-attrib = "a=rtcp-xr:" [xr-format *(SP xr-format)] CRLF
xr-format = "multicast-acq"
CRLF = %d13.10
Figure 4
Refer to Section 5.1 of [RFC3611] for a detailed description and the
full syntax of the "rtcp-xr" attribute.
Begen & Friedrich Expires November 14, 2009 [Page 13]
Internet-Draft MA Report Block Type for RTCP XR May 2009
6. Security Considerations
The security considerations of [RFC3611] apply in this document as
well. If desired, similar to other RTCP XR reports, the MA reports
MAY be protected by using SRTP and SRTCP [RFC3711].
Using the MA reports to provide feedback into the acquisition of the
multicast streams can introduce possible additional security
implications. If a forged or otherwise modified MA report is
received for an earlier acquisition attempt, invalid data may be used
as input in later rapid acquisition attempts. For example,
incorrectly small SFGMP join times may cause the unicast burst to be
too short, leading to gaps in sequence numbers in the approach
discussed in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Additionally,
forged reports may give the appearance that rapid acquisition is
performing correctly, when it is in fact failing, or vice versa.
Further security considerations are TBD.
Begen & Friedrich Expires November 14, 2009 [Page 14]
Internet-Draft MA Report Block Type for RTCP XR May 2009
7. IANA Considerations
7.1. RTCP XR Block Type
New block types for RTCP XR are subject to IANA registration. For
general guidelines on IANA considerations for RTCP XR, refer to
[RFC3611].
This document (provisionally) assigns the block type value TBD in the
RTCP XR Block Type Registry to "Multicast Acquisition Report Block."
7.2. RTCP XR SDP Parameter
This document registers the SDP [RFC4566] parameter 'multicast-acq'
for the 'rtcp-xr' attribute in the RTCP XR SDP Parameters Registry.
The contact information for the registrations is:
Ali Begen
abegen@cisco.com
170 West Tasman Drive
San Jose, CA 95134 USA
7.3. Multicast Acquisition Report Block TLV Space Registry
This document creates a new IANA TLV space registry for the MA report
block extensions. The registry is called the Multicast Acquisition
Report Block TLV Space Registry. This registry is to be managed by
the IANA according to the Specification Required policy of [RFC5226].
The length of the Type field in the TLV elements is a single octet,
allowing 256 values. The registry is initialized with the following
entries:
Type Description Reference
---- -------------------------------------------------- -------------
TBD Extended RTP Seqnum of First Multicast Packet This document
... ...
The registry entries are TBC.
The TYPE values 0 and 255 are reserved for future use. The TYPE
values between (and including) 128 and 254 are reserved for private
extensions.
Begen & Friedrich Expires November 14, 2009 [Page 15]
Internet-Draft MA Report Block Type for RTCP XR May 2009
Any registration for an unassigned TYPE value MUST contain the
following information:
o Contact information of the one doing the registration, including
at least name, address, and email.
o A detailed description of what the new TLV element represents and
how it shall be interpreted.
Begen & Friedrich Expires November 14, 2009 [Page 16]
Internet-Draft MA Report Block Type for RTCP XR May 2009
8. Acknowledgments
This specification has greatly benefited from discussions with
Michael Lague, Dong Hsu, Carol Iturralde, Xuan Zhong, Dave Oran and
many others. The authors would like to thank each of these
individuals for their contributions.
Begen & Friedrich Expires November 14, 2009 [Page 17]
Internet-Draft MA Report Block Type for RTCP XR May 2009
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611,
November 2003.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, August 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
9.2. Informative References
[I-D.ietf-avt-rapid-acquisition-for-rtp]
Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast-
Based Rapid Acquisition of Multicast RTP Sessions",
draft-ietf-avt-rapid-acquisition-for-rtp-00 (work in
progress), May 2009.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
Begen & Friedrich Expires November 14, 2009 [Page 18]
Internet-Draft MA Report Block Type for RTCP XR May 2009
RFC 3711, March 2004.
Begen & Friedrich Expires November 14, 2009 [Page 19]
Internet-Draft MA Report Block Type for RTCP XR May 2009
Authors' Addresses
Ali Begen
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Email: abegen@cisco.com
Eric Friedrich
Cisco Systems
1414 Massachusetts Ave.
Boxborough, MA 01719
USA
Email: efriedri@cisco.com
Begen & Friedrich Expires November 14, 2009 [Page 20]