summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6332.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6332.txt')
-rw-r--r--doc/rfc/rfc6332.txt899
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc6332.txt b/doc/rfc/rfc6332.txt
new file mode 100644
index 0000000..7c3c9fc
--- /dev/null
+++ b/doc/rfc/rfc6332.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Begen
+Request for Comments: 6332 E. Friedrich
+Category: Standards Track Cisco
+ISSN: 2070-1721 July 2011
+
+
+ Multicast Acquisition Report Block Type for
+ RTP Control Protocol (RTCP) Extended Reports (XRs)
+
+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. An RTP receiver can use one or more different
+ approaches to achieve rapid acquisition. Yet, due to various
+ factors, performance of the rapid acquisition methods usually varies.
+ Furthermore, in some cases, the RTP receiver can do a simple
+ multicast join (in other cases, it is compelled to do so). For
+ quality reporting, monitoring, and diagnostic purposes, it is
+ important to collect detailed information from the RTP receivers
+ about their acquisition and presentation experiences. This document
+ addresses this issue by defining a new report block type, called the
+ Multicast Acquisition (MA) report block, within the framework of RTP
+ Control Protocol (RTCP) Extended Reports (XRs) (RFC 3611). This
+ document also defines the necessary signaling of the new MA report
+ block type in the Session Description Protocol (SDP).
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6332.
+
+
+
+
+
+
+
+
+
+Begen & Friedrich Standards Track [Page 1]
+
+RFC 6332 MA Report Block Type for RTCP XR July 2011
+
+
+Copyright Notice
+
+ Copyright (c) 2011 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
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
+ 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Multicast Acquisition (MA) Report Block . . . . . . . . . . . 4
+ 4.1. Base Report . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.1.1. Status Code Rules for New MA Methods . . . . . . . . . 6
+ 4.1.2. Status Code Rules for the RAMS Method . . . . . . . . 6
+ 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 4.2.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 7
+ 4.2.2. Private Extensions . . . . . . . . . . . . . . . . . . 10
+ 5. Session Description Protocol Signaling . . . . . . . . . . . . 10
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
+ 7.1. RTCP XR Block Type . . . . . . . . . . . . . . . . . . . . 11
+ 7.2. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 12
+ 7.3. Multicast Acquisition Method Registry . . . . . . . . . . 12
+ 7.4. Multicast Acquisition Report Block TLV Space Registry . . 12
+ 7.5. Multicast Acquisition Status Code Space Registry . . . . . 13
+ 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+Begen & Friedrich Standards Track [Page 2]
+
+RFC 6332 MA Report Block Type for RTCP XR July 2011
+
+
+1. Introduction
+
+ The RTP Control Protocol (RTCP) is the out-of-band control protocol
+ for applications that use 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 are usually achieved through the RTCP Extended Reports
+ (XRs) [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 the data in 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, [RFC6285] 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. This method is
+ referred to as the Rapid Acquisition of Multicast RTP Sessions
+ (RAMS). However, depending on the variability in the Source
+ Filtering Group Management Protocol (SFGMP) processing times, the
+ availability of network resources for rapid acquisition, and the
+ 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 in 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 the
+ Multicast Acquisition (MA) report block, within the framework of RTCP
+ XR. RTP receivers that use the method described in [RFC6285] 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
+ that 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 Standards Track [Page 3]
+
+RFC 6332 MA Report Block Type for RTCP XR July 2011
+
+
+2. Requirements Notation
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ [RFC2119].
+
+3. Definitions
+
+ This document uses the acronyms and definitions from Section 3 of
+ [RFC6285].
+
+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 [RFC6285]. Other
+ methods that provide rapid acquisition can 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, synchronization
+ source (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).
+
+ It is better to send the MA report block after all the necessary
+ information is collected and computed. Partial reporting is
+ generally not useful as it cannot give the full picture of the
+ multicast acquisition, and it causes additional complexity in terms
+ of report block matching and correlation. The MA report block is
+ only sent as a part of an RTCP compound packet, and it is sent in the
+ primary multicast session.
+
+ The need for reliability of the MA report block is not any greater
+ than other report blocks or types. If desired, the report block
+ could be repeated for redundancy purposes while respecting the RTCP
+ scheduling algorithms.
+
+ Following the rules specified in [RFC3550], all integer fields in the
+ base report and extensions defined below are carried in network-byte
+ order, that is, most significant byte (octet) first, also known as
+ big-endian. Unless otherwise stated, numeric constants are in
+ decimal (base 10).
+
+
+
+Begen & Friedrich Standards Track [Page 4]
+
+RFC 6332 MA Report Block Type for RTCP XR July 2011
+
+
+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=11 | MA Method | Block Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | SSRC of the Primary Multicast Stream |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Status | Rsvd. |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: Base Report Format for the MA Report Block
+
+ o BT (8 bits): Field that denotes the type for this block format.
+ The MA report block is identified by the constant 11.
+
+ o MA Method (8 bits): Field that denotes the type of the MA method
+ (e.g., simple join, RAMS, etc.). See Section 7.3 for the values
+ registered with IANA.
+
+ o Block Length (16 bits): The length of this report block, including
+ the header, in 32-bit words minus one.
+
+ o SSRC of the Primary Multicast Stream (32 bits): Field that denotes
+ the SSRC of the primary multicast stream.
+
+ o Status (16 bits): Field that denotes the status code for the MA
+ operation.
+
+ This document defines several status codes and registers them with
+ IANA in Section 7.5. If a new vendor-neutral status code will be
+ defined, it MUST be registered with IANA according to the
+ guidelines 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 management. Section 4.2.2 defines how a vendor defines and
+ uses private extensions to convey its messages.
+
+ To indicate use of a private extension, the RTP receiver MUST set
+ the Status field to zero. A private extension MUST NOT be used in
+ an XR unless the RTP receiver knows from out-of-band methods that
+ the entity that will receive and process the XR understands the
+ private extension.
+
+ o Rsvd. (16 bits): The RTP receiver MUST set this field to zero.
+ The recipient MUST ignore this field when received.
+
+
+
+Begen & Friedrich Standards Track [Page 5]
+
+RFC 6332 MA Report Block Type for RTCP XR July 2011
+
+
+ If the multicast join was successful, meaning that at least one
+ multicast packet was received, some additional information MUST be
+ appended to the base report as described in Section 4.2.1.
+
+4.1.1. Status Code Rules for New MA Methods
+
+ Different MA methods usually use different status codes, although
+ some status codes (e.g., a code indicating that multicast join has
+ failed) can be common among multiple MA methods. The status code
+ reported in the base report MUST always be within the scope of the
+ particular MA method specified in the MA Method field.
+
+ In certain MA methods, the RTP receiver can generate a status code
+ for its multicast acquisition attempt or can be told by another
+ network element or RTP endpoint what the current status is via a
+ 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
+ has a higher priority. Each MA method needs to outline the rules
+ pertaining to its response and status codes so that RTP receiver
+ implementations can determine what to report in any given scenario.
+
+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 [RFC6285].
+
+ Section 11.6 of [RFC6285] defines several response codes. The 1xx-
+ and 2xx-level response codes are informational and success response
+ codes, respectively. If the RTP receiver receives a 1xx- or 2xx-
+ level response code, then the RTP receiver MUST use one of the 1xxx-
+ level status codes defined in Section 7.5 of this document. If the
+ RTP receiver receives a 4xx- or 5xx-level response code (indicating
+ receiver-side and server-side errors, respectively), then the RTP
+ receiver MUST use the response code as its status code. In other
+ words, the 4xx- and 5xx-level response codes have a higher priority
+ than the 1xxx-level status codes.
+
+4.2. Extensions
+
+ To improve the reporting scope, it might be desirable to define new
+ fields in the MA report block. Such fields are to 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.
+
+
+
+
+
+
+Begen & Friedrich Standards Track [Page 6]
+
+RFC 6332 MA Report Block Type for RTCP XR July 2011
+
+
+ o Length: A two-octet field that indicates the length (in octets) of
+ the TLV element excluding the Type and Length fields and the 8-bit
+ Reserved field between them. Note that this length does not
+ include any padding that is needed for alignment.
+
+ o Value: Variable-size set of octets that contains the specific
+ value for the parameter.
+
+ In the extensions, the Reserved field MUST be set to zero and ignored
+ on reception. 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, the RTP receiver MUST place any vendor-
+ neutral or private extension after the base report.
+
+ 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 | Reserved | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ : Value :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ 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 need to be registered with
+ IANA according to the guidelines provided in Section 7.4.
+
+ This document defines several vendor-neutral extensions. First, we
+ present the TLV elements that can be used by any RTP-based multicast
+ application.
+
+ o RTP Seqnum of the First Multicast Packet (16 bits): TLV element
+ that specifies the RTP sequence number of the first multicast
+ packet received for the primary multicast stream. If the
+ multicast join was successful, this element MUST be included. If
+ no multicast packet has been received, this element MUST NOT exist
+ in the report block.
+
+ Type: 1
+
+ o SFGMP Join Time (32 bits): TLV element that denotes the greater of
+ zero or the time difference (in ms) between the instant the SFGMP
+ Join message was sent and the instant the first packet was
+
+
+
+Begen & Friedrich Standards Track [Page 7]
+
+RFC 6332 MA Report Block Type for RTCP XR July 2011
+
+
+ received in the multicast session. If the multicast join was
+ successful, this element MUST be included. If no multicast packet
+ has been received, this element MUST NOT exist in the report
+ block.
+
+ Type: 2
+
+ o Application Request-to-Multicast Delta Time (32 bits): 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 packet was received from the
+ primary multicast stream. If no such packet has been received,
+ this element MUST NOT exist in the report block.
+
+ Type: 3
+
+ o Application Request-to-Presentation Delta Time (32 bits): 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 was first presented. If the RTP
+ receiver cannot successfully present the media, this element MUST
+ NOT exist in the report block.
+
+ Type: 4
+
+ We next present the TLV elements that can be used when the RTP
+ receiver supports and uses the RAMS method described in [RFC6285].
+ 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 or
+ not the RTP receiver receives any packet from the unicast burst
+ and/or the primary multicast stream. These are explained below.
+
+ o Application Request-to-RAMS Request Delta Time (32 bits): 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: 11
+
+ o RAMS Request-to-RAMS Information Delta Time (32 bits): OPTIONAL
+ TLV element that denotes the time difference (in ms) between the
+ instant the rapid acquisition request was sent and the instant the
+
+
+
+
+
+
+
+Begen & Friedrich Standards Track [Page 8]
+
+RFC 6332 MA Report Block Type for RTCP XR July 2011
+
+
+ first RAMS Information message was received in the unicast
+ session. If no such message has been received, this element MUST
+ NOT exist in the report block.
+
+ Type: 12
+
+ o RAMS Request-to-Burst Delta Time (32 bits): OPTIONAL TLV element
+ that denotes the time difference (in ms) between the instant the
+ rapid acquisition request was sent and the instant the first burst
+ packet was received in the unicast session. If no burst packet
+ has been received, this element MUST NOT exist in the report
+ block.
+
+ Type: 13
+
+ o RAMS Request-to-Multicast Delta Time (32 bits): OPTIONAL TLV
+ element that denotes the time difference (in ms) between the
+ instant the rapid acquisition request was sent and the instant the
+ first RTP packet was received from the primary multicast stream.
+ If no such packet has been received, this element MUST NOT exist
+ in the report block.
+
+ Type: 14
+
+ o RAMS Request-to-Burst-Completion Delta Time (32 bits): OPTIONAL
+ TLV element that denotes the time difference (in ms) between the
+ instant the rapid acquisition request was sent and the instant the
+ last burst packet was received in the unicast session. If no
+ burst packet has been received, this element MUST NOT exist in the
+ report block.
+
+ Type: 15
+
+ o Number of Duplicate Packets (32 bits): OPTIONAL TLV element that
+ denotes the number of duplicate packets due to receiving the same
+ packet in both unicast and primary multicast RTP sessions. If no
+ RTP packet has been received from the primary multicast stream,
+ this element MUST NOT exist. If no burst packet has been received
+ in the unicast session, the value of this element MUST be set to
+ zero.
+
+ Type: 16
+
+ o Size of Burst-to-Multicast Gap (32 bits): OPTIONAL TLV element
+ that denotes the greater of zero or the difference between the
+ sequence number of the first multicast packet (received from the
+ primary multicast stream) and the sequence number of the last
+ burst packet minus 1 (considering the wrapping of the sequence
+
+
+
+Begen & Friedrich Standards Track [Page 9]
+
+RFC 6332 MA Report Block Type for RTCP XR July 2011
+
+
+ numbers). If no burst packet has been received in the unicast
+ session or no RTP packet has been received from the primary
+ multicast stream, this element MUST NOT exist in the report block.
+
+ Type: 17
+
+4.2.2. Private Extensions
+
+ It is desirable to allow vendors to use private extensions in TLV
+ format. The range of [128-254] of TLV Types is reserved for private
+ extensions. IANA management for these extensions is unnecessary;
+ they are the responsibility of individual vendors.
+
+ Implementations use the structure depicted in Figure 3 for private
+ extensions. Here, the private enterprise numbers are used from
+ http://www.iana.org. 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 | Reserved | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Enterprise Number |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ : Value :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 3: Structure of a Private Extension
+
+5. Session Description Protocol Signaling
+
+ A new unilateral parameter is defined for the MA report block to be
+ used with the Session Description Protocol (SDP) [RFC4566]. In the
+ following ABNF [RFC5234], xr-format is used as defined in [RFC3611].
+
+ xr-format =/ multicast-acq-ext
+ multicast-acq-ext = "multicast-acq"
+
+ Refer to Section 5.1 of [RFC3611] for a detailed description and the
+ full syntax of the 'rtcp-xr' attribute.
+
+
+
+
+
+
+
+
+
+
+Begen & Friedrich Standards Track [Page 10]
+
+RFC 6332 MA Report Block Type for RTCP XR July 2011
+
+
+6. Security Considerations
+
+ The security considerations of [RFC3611] apply in this document as
+ well.
+
+ The information contained in MA reports could be stolen as with any
+ other RTCP reports if proper protection mechanism(s) are not in
+ place. If desired, similar to other RTCP XRs, the MA reports MAY be
+ protected by using Secure RTP (SRTP) and Secure RTP Control Protocol
+ (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 extension 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
+ 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 can be used
+ as input in later rapid acquisition attempts. For example,
+ incorrectly small SFGMP join times could cause the unicast burst to
+ be too short, leading to gaps in sequence numbers in the approach
+ discussed in [RFC6285]. Additionally, forged reports could give the
+ appearance that rapid acquisition is performing correctly when it is
+ in fact failing, or vice versa. While integrity protection can be
+ achieved in different ways, we RECOMMEND the use of SRTCP [RFC3711].
+
+7. IANA Considerations
+
+ The following contact information is provided for all registrations
+ in this document:
+
+ Ali Begen
+ abegen@cisco.com
+
+7.1. RTCP XR Block Type
+
+ Type value 11 has been registered with IANA for the "Multicast
+ Acquisition Report Block" in the RTCP XR Block Type Registry.
+
+
+
+
+
+
+Begen & Friedrich Standards Track [Page 11]
+
+RFC 6332 MA Report Block Type for RTCP XR July 2011
+
+
+7.2. RTCP XR SDP Parameter
+
+ The SDP [RFC4566] parameter 'multicast-acq' for the 'rtcp-xr'
+ attribute has been registered in the RTCP XR SDP Parameters Registry.
+
+7.3. Multicast Acquisition Method Registry
+
+ A new IANA registry for the MA methods has been created. The
+ registry is called the "Multicast Acquisition Method Registry". This
+ registry is to be managed by IANA according to the Specification
+ Required policy of [RFC5226].
+
+ The length of the MA Method field is a single octet, allowing 256
+ values. The registry is initialized with the following entries:
+
+ MA Method Description Reference
+ --------- ------------------------------------ -------------
+ 0 Reserved [RFC6332]
+ 1 Simple join (No explicit method) [RFC6332]
+ 2 RAMS [RFC6285]
+ 3-254 Unassigned Specification Required
+ 255 Reserved [RFC6332]
+
+ The MA Method values 0 and 255 are reserved for future use.
+
+ Any registration for an unassigned value needs to 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 how the MA method works.
+
+7.4. Multicast Acquisition Report Block TLV Space Registry
+
+ A new IANA TLV space registry for the MA report block extensions has
+ been created. 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:
+
+
+
+
+
+
+
+
+Begen & Friedrich Standards Track [Page 12]
+
+RFC 6332 MA Report Block Type for RTCP XR July 2011
+
+
+ Type Description Reference
+ ------- -------------------------------------------------- ---------
+ 0 Reserved [RFC6332]
+ 1 RTP Seqnum of the First Multicast Packet [RFC6332]
+ 2 SFGMP Join Time [RFC6332]
+ 3 Application Request-to-Multicast Delta Time [RFC6332]
+ 4 Application Request-to-Presentation Delta Time [RFC6332]
+ 5-10 Unassigned Specification Required
+ 11 Application Request-to-RAMS Request Delta Time [RFC6332]
+ 12 RAMS Request-to-RAMS Information Delta Time [RFC6332]
+ 13 RAMS Request-to-Burst Delta Time [RFC6332]
+ 14 RAMS Request-to-Multicast Delta Time [RFC6332]
+ 15 RAMS Request-to-Burst-Completion Delta Time [RFC6332]
+ 16 Number of Duplicate Packets [RFC6332]
+ 17 Size of Burst-to-Multicast Gap [RFC6332]
+ 18-127 Unassigned Specification Required
+ 128-254 Reserved for private extensions [RFC6332]
+ 255 Reserved [RFC6332]
+
+ 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.
+
+ Any registration for an unassigned Type value needs to 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 is interpreted.
+
+7.5. Multicast Acquisition Status Code Space Registry
+
+ A new IANA TLV space registry for the status codes has been created.
+ The registry is called the "Multicast Acquisition Status Code Space
+ Registry". This registry is to be managed by the IANA according to
+ the Specification Required policy of [RFC5226].
+
+ The length of the Status field is two octets, allowing 65536 codes.
+ However, the status codes have been registered to allow for an easier
+ classification. For example, the values between (and including) 1
+ and 1000 are primarily used by the MA method of simple join. The
+ values between (and including) 1001 and 2000 are used by the MA
+ method described in [RFC6285]. When registering new status codes for
+ the existing MA methods or newly defined MA methods, registrants are
+
+
+
+
+
+Begen & Friedrich Standards Track [Page 13]
+
+RFC 6332 MA Report Block Type for RTCP XR July 2011
+
+
+ encouraged to allocate sufficient continuous space. Note that
+ because of the limited space, not every MA method can be assigned
+ 1000 different values for its status codes.
+
+ The status code 65535 is reserved for future use. The registry is
+ initialized with the following entries:
+
+ Code Description Reference
+ --------- ------------------------------------------------ ---------
+ 0 A private status code is included in the message [RFC6332]
+ 1 Multicast join was successful [RFC6332]
+ 2 Multicast join has failed [RFC6332]
+ 3 A presentation error has occurred [RFC6332]
+ 4 An unspecified RTP receiver internal error has
+ occurred [RFC6332]
+ 5-1000 Unassigned
+ 1001 RAMS has been successfully completed [RFC6332]
+ 1002 No RAMS-R message has been sent [RFC6332]
+ 1003 Invalid RAMS-I message syntax [RFC6332]
+ 1004 RAMS-I message has timed out [RFC6332]
+ 1005 RAMS unicast burst has timed out [RFC6332]
+ 1006 An unspecified RTP receiver internal error has
+ occurred during RAMS [RFC6332]
+ 1007 A presentation error has occurred during RAMS [RFC6332]
+ 1008-65534 Unassigned
+ 65535 Reserved [RFC6332]
+
+ Any registration for an unassigned status code needs to 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 status code describes and
+ how it is interpreted.
+
+8. Acknowledgments
+
+ This specification has greatly benefited from discussions with
+ Michael Lague, Dong Hsu, Carol Iturralde, Xuan Zhong, Dave Oran, Tom
+ Van Caenegem, and many others. The authors would like to thank each
+ of these individuals for their contributions.
+
+
+
+
+
+
+
+
+
+Begen & Friedrich Standards Track [Page 14]
+
+RFC 6332 MA Report Block Type for RTCP XR July 2011
+
+
+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.
+
+ [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+ Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+ RFC 3711, March 2004.
+
+ [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+ Description Protocol", RFC 4566, July 2006.
+
+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+ [RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax,
+ "Unicast-Based Rapid Acquisition of Multicast RTP
+ Sessions", RFC 6285, June 2011.
+
+9.2. Informative References
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen & Friedrich Standards Track [Page 15]
+
+RFC 6332 MA Report Block Type for RTCP XR July 2011
+
+
+Authors' Addresses
+
+ Ali Begen
+ Cisco
+ 181 Bay Street
+ Toronto, ON M5J 2T3
+ Canada
+
+ EMail: abegen@cisco.com
+
+
+ Eric Friedrich
+ Cisco
+ 1414 Massachusetts Ave.
+ Boxborough, MA 01719
+ USA
+
+ EMail: efriedri@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Begen & Friedrich Standards Track [Page 16]
+