draft-ietf-avtext-multicast-acq-rtcp-xr-03.txt   draft-ietf-avtext-multicast-acq-rtcp-xr-04.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 13, 2011 April 11, 2011 Expires: October 14, 2011 April 12, 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-03 draft-ietf-avtext-multicast-acq-rtcp-xr-04
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 can 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 can (or be compelled to) Furthermore, in some cases the RTP receiver can do a simple multicast
do a simple multicast join. For quality reporting, monitoring and join (in other cases it is compelled to do so). For quality
diagnostics purposes, it is important to collect detailed information reporting, monitoring and diagnostics purposes, it is important to
from the RTP receivers about their acquisition and presentation collect detailed information from the RTP receivers about their
experiences. This document addresses this issue by defining a new acquisition and presentation experiences. This document addresses
report block type, called Multicast Acquisition (MA) Report Block, this issue by defining a new report block type, called Multicast
within the framework of RTP Control Protocol (RTCP) Extended Reports Acquisition (MA) Report Block, within the framework of RTP Control
(XR) (RFC 3611). This document also defines the necessary signaling Protocol (RTCP) Extended Reports (XR) (RFC 3611). This document also
of the new MA report block type in the Session Description Protocol defines the necessary signaling of the new MA report block type in
(SDP). the Session Description Protocol (SDP).
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 13, 2011. This Internet-Draft will expire on October 14, 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 13, line 12 skipping to change at page 13, line 12
Figure 3: Structure of a private extension Figure 3: Structure of a private extension
5. Session Description Protocol Signaling 5. Session Description Protocol Signaling
A new unilateral parameter is defined for the MA report block to be A new unilateral parameter is defined for the MA report block to be
used with the Session Description Protocol (SDP) [RFC4566] using the used with the Session Description Protocol (SDP) [RFC4566] using the
Augmented Backus-Naur Form (ABNF) [RFC5234]. It has the following Augmented Backus-Naur Form (ABNF) [RFC5234]. It has the following
syntax within the 'rtcp-xr' attribute [RFC3611]: syntax within the 'rtcp-xr' attribute [RFC3611]:
xr-format = <See RFC 3611> xr-format = <See RFC 3611>
xr-format /= multicast-acq-ext xr-format /= multicast-acq-ext
multicast-acq-ext = "multicast-acq"
Figure 4 multicast-acq-ext = "multicast-acq"
Refer to Section 5.1 of [RFC3611] for a detailed description and the Refer to Section 5.1 of [RFC3611] for a detailed description and the
full syntax of the "rtcp-xr" attribute. The "multicast-acq-ext" full syntax of the "rtcp-xr" attribute. The "multicast-acq-ext"
parameter is compatible with the definition of "format-ext" in the parameter is compatible with the definition of "format-ext" in the
"rtcp-xr" attribute. "rtcp-xr" attribute.
6. Security Considerations 6. Security Considerations
The security considerations of [RFC3611] apply in this document as The security considerations of [RFC3611] apply in this document as
well. well.
skipping to change at page 14, line 36 skipping to change at page 14, line 36
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 can 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 While integrity protection can be achieved through different ways, we
risks from a confidentiality viewpoint. RECOMMEND the use of SRTCP [RFC3711].
7. IANA Considerations 7. IANA Considerations
The following contact information is provided 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
 End of changes. 7 change blocks. 
20 lines changed or deleted 18 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/