--- 1/draft-ietf-avtext-multicast-acq-rtcp-xr-01.txt 2011-04-06 17:15:51.000000000 +0200 +++ 2/draft-ietf-avtext-multicast-acq-rtcp-xr-02.txt 2011-04-06 17:15:51.000000000 +0200 @@ -1,31 +1,31 @@ AVT A. Begen Internet-Draft E. Friedrich Intended status: Standards Track Cisco -Expires: October 1, 2011 March 30, 2011 +Expires: October 8, 2011 April 6, 2011 Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) - draft-ietf-avtext-multicast-acq-rtcp-xr-01 + draft-ietf-avtext-multicast-acq-rtcp-xr-02 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 may use one ore more different + acquisition delay. An RTP receiver can use one ore more different approaches to achieve rapid acquisition. Yet, due to various 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 + Furthermore, in some cases the RTP receiver can (or be compelled 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) (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 @@ -36,21 +36,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on October 1, 2011. + This Internet-Draft will expire on October 8, 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 @@ -59,21 +59,22 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Multicast Acquisition (MA) Report Block . . . . . . . . . . . 6 4.1. Base Report . . . . . . . . . . . . . . . . . . . . . . . 6 - 4.1.1. Status Code Rules . . . . . . . . . . . . . . . . . . 7 + 4.1.1. Status Code Rules for New MA Methods . . . . . . . . . 7 + 4.1.2. Status Code Rules for the RAMS Method . . . . . . . . 8 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 9 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 Method Registry . . . . . . . . . . 15 7.4. Multicast Acquisition Report Block TLV Space Registry . . 16 @@ -140,85 +141,81 @@ This document uses the following acronyms and definitions from [I-D.ietf-avt-rapid-acquisition-for-rtp]: (Primary) Multicast Session: The multicast session to which RTP receivers can join at a random point in time. Primary Multicast RTP Session: The multicast RTP session an RTP receiver is interested in acquiring. - Primary Multicast (RTP) Streams: The RTP stream(s) carried in the - primary multicast RTP session. - Source Filtering Group Management Protocol (SFGMP): Following the 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. However, the report block type introduced in this document does not depend on a specific version of either of these group management protocols. In the remainder of this document, SFGMP will refer to any group management protocol that has Join and Leave functionalities. Retransmission (Burst) Packet: An RTP packet that is formatted as - defined in [RFC4588]. + defined in Section 4 of [RFC4588]. Reference Information: The set of certain media content and metadata 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 associated with a primary multicast stream. Each burst - stream is identified by its SSRC identifier that is unique in the - primary multicast RTP session. The burst streams are typically - transmitted at an accelerated rate. + stream is identified by its Synchronization Source (SSRC) identifier + that is unique in the primary multicast RTP session. Retransmission Server (RS): The RTP/RTCP endpoint that can generate - the retransmission packets and the burst streams. RS may also + the retransmission packets and the burst streams. The RS may also generate other non-retransmission packets to aid the rapid acquisition process. 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 MAY define their own extensions to be used in the + rapid acquisition can define their own extensions to be used in the MA report block. 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). - The MA report block is better to be sent after all the necessary + It is better to send the MA report block after all the necessary information is collected and computed. Partial reporting is - generally not useful as it may not give the full picture of the + generally not useful as it cannot give the full picture of the multicast acquisition, and causes additional complexity in terms of - report block matching and correlation. The MA report block SHOULD - only be sent as a part of an RTCP compound packet, and it is sent in - the primary multicast session. + 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 reliability of the MA report block is not any more essential than - other report blocks or types. If desired, the report block could be - repeated for redundancy purposes while respecting to the RTCP - scheduling algorithms. + 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 to the + RTCP scheduling algorithms. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -243,143 +240,144 @@ that denotes the SSRC of the primary multicast stream. 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 in Section 7.5. 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. + management. Section 4.2.2 defines how a vendor defines and uses + private extensions to convey its messages. To indicate a private + extension, the RTP receiver MUST set the Status field to zero. - o Rsvd. (16 bits): This field SHALL be set to 0 and ignored on - reception. + o Rsvd. (16 bits): The RTP receiver MUST set this bit to zero. The + recipient MUST ignore this bit when received. 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 +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) 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. + 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 may generate a status code - for its multicast acquisition attempt, or may be told by another + 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. 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 + 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 [I-D.ietf-avt-rapid-acquisition-for-rtp]. - Section 12.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 - 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. + Section 11.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] 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 MUST be encoded as TLV + fields in the MA report block. Such fields are to be encoded as TLV elements as described below and sketched in Figure 2: 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 (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 required for alignment. + 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 SHALL 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 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, any vendor-neutral or private extension MUST - be placed after the base report. + 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 MUST be registered with IANA - through the guidelines provided in Section 7.4. + block in a vendor-neutral manner, they need to 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 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. + 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 SFGMP Join message has been sent and the instant the first packet was received in the multicast session. If the multicast join was - successful, this element MUST exist. If no multicast packet has - been received, this element SHALL NOT exist. + 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 SHALL NOT exist. + 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 is first presented. If the RTP receiver cannot successfully present the - media, this element SHALL NOT exist. + media, this element MUST NOT exist in the report block. Type: 4 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 burst and/or the primary multicast stream or @@ -391,83 +389,81 @@ 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 message was received in the unicast session. If no such message has been received, this - element SHALL NOT exist. + 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 has been sent and the instant the first burst packet was received in the unicast session. If no burst - packet has been received, this element SHALL NOT exist. + packet has been received, this element MUST NOT exist in the + report block. Type: 13 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 packet was received from the primary multicast stream. If no such packet has been received, this - element SHALL NOT exist. + 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 has been sent and the instant the last burst packet was received in the unicast session. - If no burst packet has been received, this element SHALL NOT - exist. + 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 SHALL NOT exist. If no burst packet has been - received in the unicast session, the value of this element SHALL - be set to zero. + 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 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 SHALL NOT exist. + 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. For interoperability, such extensions MUST NOT collide with - each other. - - The range of [128-254] of TLV Types is reserved for private + format. The range of [128-254] of TLV Types is reserved for private extensions. 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 private enterprise numbers are used + Implementations use the structure depicted in Figure 3 for the + private extensions. Here, the private 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 | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | @@ -497,36 +493,46 @@ The security considerations of [RFC3611] apply in this document as well. The information contained in MA reports could be stolen as any other RTCP reports if proper protection mechanism(s) are not in place. If desired, similar to other RTCP XR reports, 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 extensions need to be studied when + considering the necessity to secure the MA reports since application- + level performance data might be present that is not otherwise + available to an attacker as with the required fields and vendor- + neutral extensions. + Using the MA reports to provide feedback into the acquisition of the 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 + 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 [I-D.ietf-avt-rapid-acquisition-for-rtp]. Additionally, forged reports could give the appearance that rapid acquisition is performing correctly, when it is in fact failing, or vice versa. However, the MA reports are believed not to introduce any additional risks from a confidentiality viewpoint. 7. IANA Considerations - The following contact information shall be used for all registrations + The following contact information is provided for all registrations in this document: Ali Begen abegen@cisco.com Note to the RFC Editor: In the following, please replace "XXXX" with the number of this document prior to publication as an RFC. 7.1. RTCP XR Block Type @@ -595,21 +601,21 @@ 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 shall be interpreted. + how it is interpreted. 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 @@ -642,21 +648,21 @@ during RAMS [RFCXXXX] 1007 A presentation error has occurred during RAMS [RFCXXXX] 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 shall be interpreted. + 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. 9. References @@ -688,35 +694,35 @@ [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. + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", + RFC 3711, March 2004. 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-17 (work in progress), November 2010. - [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. - Norrman, "The Secure Real-time Transport Protocol (SRTP)", - RFC 3711, March 2004. + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. Authors' Addresses Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada Email: abegen@cisco.com