AVT A. Begen Internet-Draft E. Friedrich Intended status: Standards Track Cisco Expires: April 25, 2010 October 22, 2009 Multicast Acquisition Report Block Type for RTCP XR draft-begen-avt-rapid-sync-rtcp-xr-03 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 April 25, 2010. 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 April 25, 2010 [Page 1] Internet-Draft MA Report Block Type for RTCP XR October 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 and presentation 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 April 25, 2010 [Page 2] Internet-Draft MA Report Block Type for RTCP XR October 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.1.1. Status Code Rules . . . . . . . . . . . . . . . . . . 8 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 9 4.2.2. Private Extensions . . . . . . . . . . . . . . . . . . 12 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 Method Registry . . . . . . . . . . 15 7.4. Multicast Acquisition Report Block TLV Space Registry . . 16 7.5. Multicast Acquisition Status Code Space Registry . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Begen & Friedrich Expires April 25, 2010 [Page 3] Internet-Draft MA Report Block Type for RTCP XR October 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. This method is referred to as the Rapid Acquisition of Multicast Sessions (RAMS). 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 April 25, 2010 [Page 4] Internet-Draft MA Report Block Type for RTCP XR October 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 April 25, 2010 [Page 5] Internet-Draft MA Report Block Type for RTCP XR October 2009 3. Definitions This document uses the following acronyms and definitions from [I-D.ietf-avt-rapid-acquisition-for-rtp]: Primary Multicast Session: The multicast RTP session to which RTP receivers can join at a random point in time. Primary Multicast Stream: The RTP stream carried in the primary multicast session. 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 and are out of scope of this document. (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. RS may also generate other non-retransmission packets to aid the RAMS process. Begen & Friedrich Expires April 25, 2010 [Page 6] Internet-Draft MA Report Block Type for RTCP XR October 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 | 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): Mandatory field that denotes the type for this block format. The MA report block is identified by the constant TBD. o MA Method (8 bits): Mandatory field that denotes the type of the MA method (e.g., simple join, RAMS, etc.). See Section 7.3 for details. 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): Mandatory field that denotes the SSRC of the primary multicast stream. Begen & Friedrich Expires April 25, 2010 [Page 7] Internet-Draft MA Report Block Type for RTCP XR October 2009 o Status (16 bits): Mandatory field that denotes the status code for the MA operation. This document defines several status codes and registers them with IANA. If a new vendor-neutral status code will be defined, it MUST be registered with IANA through 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. Instead, the vendor MUST use the private extension mechanism (Section 4.2.2) to convey its message and MUST indicate this by putting zero in the Status field. o Rsvd. (16 bits): This field SHALL be set to 0 and ignored. If the multicast join was successful meaning that at least one multicast packet has been received, some additional information MUST be appended to the base report as will be described in Section 4.2.1. 4.1.1. Status Code Rules Different MA methods usually use different status codes, although some status codes (e.g., a code indicating that multicast join has failed) may apply to more than one MA method. However, 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 may generate a status code for its multicast acquisition attempt, or may 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. It is RECOMMENDED that each MA method outlines the rules pertaining to its response and status codes so that RTP receiver implementations can determine what to report in any given scenario. Below, we provide these rules for the RAMS method described in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Section 13.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] defines several response codes for its MA method. 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, it MUST use one of the 1xxx-level status codes defined in Section 7.5 of this document. The RTP receiver may also receive a 4xx or 5xx-level response code (indicating receiver-side and server- side errors, respectively). In that case, 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. The 5xx-level response codes have a higher priority Begen & Friedrich Expires April 25, 2010 [Page 8] Internet-Draft MA Report Block Type for RTCP XR October 2009 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 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.4. The current document defines several vendor-neutral extensions. First, we present the TLV elements that can be used by any RTP-based Begen & Friedrich Expires April 25, 2010 [Page 9] Internet-Draft MA Report Block Type for RTCP XR October 2009 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 exist. If no multicast packet has been received, this element SHALL NOT exist. 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 SFGMP Join message has been sent and the instant the first RTP packet was received from the primary multicast session. If the multicast join was successful, this element MUST exist. If no multicast packet has been received, this element SHALL NOT exist. 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 multicast packet was received for the primary multicast stream. If no such packet has been received, this element SHALL NOT exist. 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 is first presented. If the RTP receiver cannot successfully present the media, this element SHALL NOT exist. Type: 4 We next present the TLV elements that can be used when the RTP receiver supports and uses the RAMS 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 packet from the unicast and/or the primary multicast session or not. These are explained below. Begen & Friedrich Expires April 25, 2010 [Page 10] Internet-Draft MA Report Block Type for RTCP XR October 2009 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 has been sent and the instant the first RAMS Information packet was received from the unicast session. If no such packet has been received from the unicast session, this element SHALL NOT exist. 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 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: 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 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: 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 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: 15 o Number of Duplicate Packets (32 bits): 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 multicast packet has been received for the primary multicast Begen & Friedrich Expires April 25, 2010 [Page 11] Internet-Draft MA Report Block Type for RTCP XR October 2009 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: 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 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: 17 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.4). 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. / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Structure of a private extension Begen & Friedrich Expires April 25, 2010 [Page 12] Internet-Draft MA Report Block Type for RTCP XR October 2009 5. Session Description Protocol Signaling A new parameter is defined for the MA report block to be used with the Session Description Protocol (SDP) [RFC4566] using the Augmented Backus-Naur Form (ABNF) [RFC5234]. It has the following syntax within the 'rtcp-xr' attribute [RFC3611]: rtcp-xr-attrib = "a=rtcp-xr:" [xr-format *(SP xr-format)] CRLF xr-format =/ "multicast-acq" 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 April 25, 2010 [Page 13] Internet-Draft MA Report Block Type for RTCP XR October 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. Begen & Friedrich Expires April 25, 2010 [Page 14] Internet-Draft MA Report Block Type for RTCP XR October 2009 7. IANA Considerations The following contact information shall be used for all registrations in this document: Ali Begen abegen@cisco.com 170 West Tasman Drive San Jose, CA 95134 USA 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. 7.3. Multicast Acquisition Method Registry This document creates a new IANA registry for the MA methods. The registry is called the Multicast Acquisition Method Registry. This registry is to be managed by the 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 --------- ------------------------------------ ------------- 1 Simple join (No explicit method) N/A 2 RAMS [I-D.ietf-avt-rapid-acquisition-for-rtp] The MA Method values 0 and 255 are reserved for future use. Any registration for an unassigned value MUST contain the following information: Begen & Friedrich Expires April 25, 2010 [Page 15] Internet-Draft MA Report Block Type for RTCP XR October 2009 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 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 ---- -------------------------------------------------- ------------- 1 RTP Seqnum of the First Multicast Packet This document 2 SFGMP Join Time This document 3 Application Request-to-Multicast Delta Time This document 4 Application Request-to-Presentation Delta Time This document 11 Application Request-to-RAMS Request Delta Time This document 12 RAMS Request-to-RAMS Information Delta Time This document 13 RAMS Request-to-Burst Delta Time This document 14 RAMS Request-to-Multicast Delta Time This document 15 RAMS Request-to-Burst-Completion Delta Time This document 16 Number of Duplicate Packets This document 17 Size of Burst-to-Multicast Gap This document 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 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 April 25, 2010 [Page 16] Internet-Draft MA Report Block Type for RTCP XR October 2009 7.5. Multicast Acquisition Status Code Space Registry This document creates a new IANA TLV space registry for the status codes. 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 [I-D.ietf-avt-rapid-acquisition-for-rtp]. When registering new status codes for the existing MA methods or newly defined MA methods, a similar classification scheme SHOULD be followed. The Status code 65536 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 This document 1 Multicast join was successful This document 2 Multicast join has failed This document 3 A presentation error has occurred This document 4 An unspecified RR internal error has occurred This document 1001 RAMS has been successfully completed This document 1002 No RAMS-R message has been sent This document 1003 Invalid RAMS-I message syntax This document 1004 RAMS-I message has timed out This document 1005 RAMS unicast burst has timed out This document 1006 An unspecified RR internal error has occurred during RAMS This document 1007 A presentation error has occurred during RAMS This document Any registration for an unassigned Status code 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 Status code describes and how it shall be interpreted. Begen & Friedrich Expires April 25, 2010 [Page 17] Internet-Draft MA Report Block Type for RTCP XR October 2009 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 Expires April 25, 2010 [Page 18] Internet-Draft MA Report Block Type for RTCP XR October 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. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [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-04 (work in progress), October 2009. Begen & Friedrich Expires April 25, 2010 [Page 19] Internet-Draft MA Report Block Type for RTCP XR October 2009 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. Begen & Friedrich Expires April 25, 2010 [Page 20] Internet-Draft MA Report Block Type for RTCP XR October 2009 Authors' Addresses Ali Begen Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: abegen@cisco.com Eric Friedrich Cisco 1414 Massachusetts Ave. Boxborough, MA 01719 USA Email: efriedri@cisco.com Begen & Friedrich Expires April 25, 2010 [Page 21]