idnits 2.17.1 draft-ietf-avtext-multicast-acq-rtcp-xr-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 26, 2011) is 4690 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '128-254' is mentioned on line 430, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 634, but not defined == Unused Reference: 'RFC3376' is defined on line 667, but no explicit reference was found in the text == Unused Reference: 'RFC3810' is defined on line 671, but no explicit reference was found in the text == Unused Reference: 'RFC4604' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'RFC4588' is defined on line 679, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AVT A. Begen 3 Internet-Draft E. Friedrich 4 Intended status: Standards Track Cisco 5 Expires: November 27, 2011 May 26, 2011 7 Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) 8 Extended Reports (XRs) 9 draft-ietf-avtext-multicast-acq-rtcp-xr-05 11 Abstract 13 In most RTP-based multicast applications, the RTP source sends inter- 14 related data. Due to this interdependency, randomly joining RTP 15 receivers usually cannot start consuming the multicast data right 16 after they join the session. Thus, they often experience a random 17 acquisition delay. An RTP receiver can use one or more different 18 approaches to achieve rapid acquisition. Yet, due to various 19 factors, performance of the rapid acquisition methods usually varies. 20 Furthermore, in some cases the RTP receiver can do a simple multicast 21 join (in other cases it is compelled to do so). For quality 22 reporting, monitoring and diagnostics purposes, it is important to 23 collect detailed information from the RTP receivers about their 24 acquisition and presentation experiences. This document addresses 25 this issue by defining a new report block type, called Multicast 26 Acquisition (MA) Report Block, within the framework of RTP Control 27 Protocol (RTCP) Extended Reports (XR) (RFC 3611). This document also 28 defines the necessary signaling of the new MA report block type in 29 the Session Description Protocol (SDP). 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 27, 2011. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 66 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Multicast Acquisition (MA) Report Block . . . . . . . . . . . 6 68 4.1. Base Report . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1.1. Status Code Rules for New MA Methods . . . . . . . . . 8 70 4.1.2. Status Code Rules for the RAMS Method . . . . . . . . 8 71 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.2.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 9 73 4.2.2. Private Extensions . . . . . . . . . . . . . . . . . . 12 74 5. Session Description Protocol Signaling . . . . . . . . . . . . 13 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 77 7.1. RTCP XR Block Type . . . . . . . . . . . . . . . . . . . . 15 78 7.2. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 15 79 7.3. Multicast Acquisition Method Registry . . . . . . . . . . 15 80 7.4. Multicast Acquisition Report Block TLV Space Registry . . 16 81 7.5. Multicast Acquisition Status Code Space Registry . . . . . 17 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 88 1. Introduction 90 RTP Control Protocol (RTCP) is the out-of-band control protocol for 91 the applications that are using the Real-time Transport Protocol 92 (RTP) for media transport [RFC3550]. In addition to providing 93 minimal control functionality to RTP entities, RTCP also enables a 94 basic level monitoring of RTP sessions via sender and receiver 95 reports. More statistically detailed monitoring as well as 96 application-specific monitoring is usually achieved through the RTCP 97 Extended Reports (XRs) [RFC3611]. 99 In most RTP-based multicast applications such as the ones carrying 100 video content, the RTP source sends inter-related data. 101 Consequently, the RTP application may not be able to decode and 102 present the data in an RTP packet before decoding one or more earlier 103 RTP packets and/or before acquiring some Reference Information about 104 the content itself. Thus, RTP receivers that are randomly joining a 105 multicast session often experience a random acquisition delay. In 106 order to reduce this delay, [I-D.ietf-avt-rapid-acquisition-for-rtp] 107 proposes an approach where an auxiliary unicast RTP session is 108 established between a retransmission server and the joining RTP 109 receiver. Over this unicast RTP session, the retransmission server 110 provides the Reference Information, which is all the information the 111 RTP receiver needs to rapidly acquire the multicast stream. This 112 method is referred to as the Rapid Acquisition of Multicast Sessions 113 (RAMS). However, depending on the variability in the Source 114 Filtering Group Management Protocol (SFGMP) processing times, 115 availability of network resources for rapid acquisition and nature of 116 the RTP data, not all RTP receivers can acquire the multicast stream 117 in the same amount of time. The performance of rapid acquisition may 118 vary not only for different RTP receivers but also over time. 120 To increase the visibility of the multicast service provider into its 121 network, to diagnose slow multicast acquisition issues and to collect 122 the acquisition experiences of the RTP receivers, this document 123 defines a new report block type, which is called Multicast 124 Acquisition (MA) Report Block, within the framework of RTCP XR. RTP 125 receivers that are using the method described in 126 [I-D.ietf-avt-rapid-acquisition-for-rtp] may use this report every 127 time they join a new multicast RTP session. RTP receivers that use a 128 different method for rapid acquisition or those do not use any method 129 but rather do a simple multicast join may also use this report to 130 collect information. This way, the multicast service provider can 131 quantitatively compare the improvements achieved by different 132 methods. 134 2. Requirements Notation 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 138 "OPTIONAL" in this document are to be interpreted as described in 139 [RFC2119]. 141 3. Definitions 143 This document uses the acronyms and definitions from Section 3 of 144 [I-D.ietf-avt-rapid-acquisition-for-rtp]. 146 4. Multicast Acquisition (MA) Report Block 148 This section defines the format of the MA report block. The base 149 report is payload-independent. An extension mechanism is provided 150 where further optional payload-independent and payload-specific 151 information can be included in the report as desired. 153 The OPTIONAL extensions that are defined in this document are 154 primarily developed for the method presented in 155 [I-D.ietf-avt-rapid-acquisition-for-rtp]. Other methods that provide 156 rapid acquisition can define their own extensions to be used in the 157 MA report block. 159 The packet format for the RTCP XR is defined in Section 2 of 160 [RFC3611]. Each XR packet has a fixed-length field for version, 161 padding, reserved bits, payload type (PT), length, SSRC of packet 162 sender as well as a variable-length field for report blocks. In the 163 XR packets, the PT field is set to XR (207). 165 It is better to send the MA report block after all the necessary 166 information is collected and computed. Partial reporting is 167 generally not useful as it cannot give the full picture of the 168 multicast acquisition, and causes additional complexity in terms of 169 report block matching and correlation. The MA report block is only 170 sent as a part of an RTCP compound packet, and it is sent in the 171 primary multicast session. 173 The need for reliability of the MA report block is not any greater 174 than other report blocks or types. If desired, the report block 175 could be repeated for redundancy purposes while respecting to the 176 RTCP scheduling algorithms. 178 Following the rules specified in [RFC3550], all integer fields in the 179 base report and extensions defined below are carried in network-byte 180 order, that is, most significant byte (octet) first, also known as 181 big-endian. Unless otherwise stated, numeric constants are in 182 decimal (base 10). 184 4.1. Base Report 186 The base report format is shown in Figure 1. 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | BT=11 | MA Method | Block Length | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | SSRC of the Primary Multicast Stream | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Status | Rsvd. | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 1: Base report format for the MA report block 200 o BT (8 bits): Field that denotes the type for this block format. 201 The MA report block is identified by the constant 11. 203 o MA Method (8 bits): Field that denotes the type of the MA method 204 (e.g., simple join, RAMS, etc.). See Section 7.3 for the values 205 registered with IANA. 207 o Block Length (16 bits): The length of this report block, 208 including the header, in 32-bit words minus one. 210 o SSRC of the Primary Multicast Stream (32 bits): Field that 211 denotes the SSRC of the primary multicast stream. 213 o Status (16 bits): Field that denotes the status code for the MA 214 operation. 216 This document defines several status codes and registers them with 217 IANA in Section 7.5. If a new vendor-neutral status code will be 218 defined, it MUST be registered with IANA through the guidelines 219 specified in Section 7.5. If the new status code is intended to 220 be used privately by a vendor, there is no need for IANA 221 management. Section 4.2.2 defines how a vendor defines and uses 222 private extensions to convey its messages. 224 To indicate use of a private extension, the RTP receiver MUST set 225 the Status field to zero. A private extension MUST NOT be used in 226 an XR report unless the RTP receiver knows from out-of-band 227 methods that the entity that will receive and process the XR 228 report understands the private extension. 230 o Rsvd. (16 bits): The RTP receiver MUST set this field to zero. 231 The recipient MUST ignore this field when received. 233 If the multicast join was successful meaning that at least one 234 multicast packet has been received, some additional information MUST 235 be appended to the base report as will be described in Section 4.2.1. 237 4.1.1. Status Code Rules for New MA Methods 239 Different MA methods usually use different status codes, although 240 some status codes (e.g., a code indicating that multicast join has 241 failed) can be common among multiple MA methods. The status code 242 reported in the base report MUST always be within the scope of the 243 particular MA method specified in the MA Method field. 245 In certain MA methods, the RTP receiver can generate a status code 246 for its multicast acquisition attempt, or can be told by another 247 network element or RTP endpoint what the current status is via a 248 response code. In such cases, the RTP receiver MAY report the value 249 of the received response code as its status code if the response code 250 has a higher priority. Each MA method needs to outline the rules 251 pertaining to its response and status codes so that RTP receiver 252 implementations can determine what to report in any given scenario. 254 4.1.2. Status Code Rules for the RAMS Method 256 In this section, we provide the status code rules for the RAMS method 257 described in [I-D.ietf-avt-rapid-acquisition-for-rtp]. 259 Section 11.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] defines 260 several response codes. The 1xx and 2xx-level response codes are 261 informational and success response codes, respectively. If the RTP 262 receiver receives a 1xx or 2xx-level response code, then the RTP 263 receiver MUST use one of the 1xxx-level status codes defined in 264 Section 7.5 of this document. If the RTP receiver receives a 4xx or 265 5xx-level response code (indicating receiver-side and server-side 266 errors, respectively), then the RTP receiver MUST use the response 267 code as its status code. In other words, the 4xx and 5xx-level 268 response codes have a higher priority than the 1xxx-level status 269 codes. 271 4.2. Extensions 273 To improve the reporting scope, it might be desirable to define new 274 fields in the MA report block. Such fields are to be encoded as TLV 275 elements as described below and sketched in Figure 2: 277 o Type: A single-octet identifier that defines the type of the 278 parameter represented in this TLV element. 280 o Length: A two-octet field that indicates the length (in octets) 281 of the TLV element excluding the Type and Length fields, and the 282 8-bit Reserved field between them. Note that this length does not 283 include any padding that is needed for alignment. 285 o Value: Variable-size set of octets that contains the specific 286 value for the parameter. 288 In the extensions, the Reserved field MUST be set to zero and ignored 289 on reception. If a TLV element does not fall on a 32-bit boundary, 290 the last word MUST be padded to the boundary using further bits set 291 to zero. 293 In the MA report block, the RTP receiver MUST place any vendor- 294 neutral or private extension after the base report. 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Type | Reserved | Length | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 : Value : 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 2: Structure of a TLV element 306 4.2.1. Vendor-Neutral Extensions 308 If the goal in defining new TLV elements is to extend the report 309 block in a vendor-neutral manner, they need to be registered with 310 IANA through the guidelines provided in Section 7.4. 312 The current document defines several vendor-neutral extensions. 313 First, we present the TLV elements that can be used by any RTP-based 314 multicast application. 316 o RTP Seqnum of the First Multicast Packet (16 bits): TLV element 317 that specifies the RTP sequence number of the first multicast 318 packet received for the primary multicast stream. If the 319 multicast join was successful, this element MUST be included. If 320 no multicast packet has been received, this element MUST NOT exist 321 in the report block. 323 Type: 1 325 o SFGMP Join Time (32 bits): TLV element that denotes the greater 326 of zero or the time difference (in ms) between the instant SFGMP 327 Join message has been sent and the instant the first packet was 328 received in the multicast session. If the multicast join was 329 successful, this element MUST be included. If no multicast packet 330 has been received, this element MUST NOT exist in the report 331 block. 333 Type: 2 335 o Application Request-to-Multicast Delta Time (32 bits): OPTIONAL 336 TLV element that denotes the time difference (in ms) between the 337 instant the application became aware it would join a new multicast 338 session and the instant the first RTP packet was received from the 339 primary multicast stream. If no such packet has been received, 340 this element MUST NOT exist in the report block. 342 Type: 3 344 o Application Request-to-Presentation Delta Time (32 bits): 345 OPTIONAL TLV element that denotes the time difference (in ms) 346 between the instant the application became aware it would join a 347 new multicast session and the instant the media is first 348 presented. If the RTP receiver cannot successfully present the 349 media, this element MUST NOT exist in the report block. 351 Type: 4 353 We next present the TLV elements that can be used when the RTP 354 receiver supports and uses the RAMS method described in 355 [I-D.ietf-avt-rapid-acquisition-for-rtp]. However, if the RTP 356 receiver does not send a rapid acquisition request, the following TLV 357 elements MUST NOT exist in the MA report block. Some elements may or 358 may not exist depending on whether the RTP receiver receives any 359 packet from the unicast burst and/or the primary multicast stream or 360 not. These are explained below. 362 o Application Request-to-RAMS Request Delta Time (32 bits): 363 OPTIONAL TLV element that denotes the time difference (in ms) 364 between the instant the application became aware it would request 365 a rapid acquisition and the instant the rapid acquisition request 366 was actually sent by the application. 368 Type: 11 370 o RAMS Request-to-RAMS Information Delta Time (32 bits): OPTIONAL 371 TLV element that denotes the time difference (in ms) between the 372 instant the rapid acquisition request has been sent and the 373 instant the first RAMS Information message was received in the 374 unicast session. If no such message has been received, this 375 element MUST NOT exist in the report block. 377 Type: 12 379 o RAMS Request-to-Burst Delta Time (32 bits): OPTIONAL TLV element 380 that denotes the time difference (in ms) between the instant the 381 rapid acquisition request has been sent and the instant the first 382 burst packet was received in the unicast session. If no burst 383 packet has been received, this element MUST NOT exist in the 384 report block. 386 Type: 13 388 o RAMS Request-to-Multicast Delta Time (32 bits): OPTIONAL TLV 389 element that denotes the time difference (in ms) between the 390 instant the rapid acquisition request has been sent and the 391 instant the first RTP packet was received from the primary 392 multicast stream. If no such packet has been received, this 393 element MUST NOT exist in the report block. 395 Type: 14 397 o RAMS Request-to-Burst-Completion Delta Time (32 bits): OPTIONAL 398 TLV element that denotes the time difference (in ms) between the 399 instant the rapid acquisition request has been sent and the 400 instant the last burst packet was received in the unicast session. 401 If no burst packet has been received, this element MUST NOT exist 402 in the report block. 404 Type: 15 406 o Number of Duplicate Packets (32 bits): OPTIONAL TLV element that 407 denotes the number of duplicate packets due to receiving the same 408 packet in both unicast and primary multicast RTP sessions. If no 409 RTP packet has been received from the primary multicast stream, 410 this element MUST NOT exist. If no burst packet has been received 411 in the unicast session, the value of this element MUST be set to 412 zero. 414 Type: 16 416 o Size of Burst-to-Multicast Gap (32 bits): OPTIONAL TLV element 417 that denotes the greater of zero or the difference between the 418 sequence number of the first multicast packet (received from the 419 primary multicast stream) and the sequence number of the last 420 burst packet minus 1 (considering the wrapping of the sequence 421 numbers). If no burst packet has been received in the unicast 422 session or no RTP packet has been received from the primary 423 multicast stream, this element MUST NOT exist in the report block. 425 Type: 17 427 4.2.2. Private Extensions 429 It is desirable to allow vendors to use private extensions in TLV 430 format. The range of [128-254] of TLV Types is reserved for private 431 extensions. IANA management for these extensions is unnecessary and 432 they are the responsibility of individual vendors. 434 Implementations use the structure depicted in Figure 3 for the 435 private extensions. Here, the private enterprise numbers are used 436 from http://www.iana.org/assignments/enterprise-numbers. This will 437 ensure the uniqueness of the private extensions and avoid any 438 collision. 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Type | Reserved | Length | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Enterprise Number | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 : Value : 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Figure 3: Structure of a private extension 452 5. Session Description Protocol Signaling 454 A new unilateral parameter is defined for the MA report block to be 455 used with the Session Description Protocol (SDP) [RFC4566] using the 456 Augmented Backus-Naur Form (ABNF) [RFC5234]. It has the following 457 syntax within the 'rtcp-xr' attribute [RFC3611]: 459 xr-format = 460 xr-format /= multicast-acq-ext 462 multicast-acq-ext = "multicast-acq" 464 Refer to Section 5.1 of [RFC3611] for a detailed description and the 465 full syntax of the "rtcp-xr" attribute. The "multicast-acq-ext" 466 parameter is compatible with the definition of "format-ext" in the 467 "rtcp-xr" attribute. 469 6. Security Considerations 471 The security considerations of [RFC3611] apply in this document as 472 well. 474 The information contained in MA reports could be stolen as any other 475 RTCP reports if proper protection mechanism(s) are not in place. If 476 desired, similar to other RTCP XR reports, the MA reports MAY be 477 protected by using Secure RTP (SRTP) and Secure RTP Control Protocol 478 (SRTCP) [RFC3711]. 480 Malicious sniffing or otherwise obtaining MA report blocks can reveal 481 performance characteristics of the RTP service and underlying 482 network. This information is mostly available to an observer with 483 the ability to capture RTP and RTCP session traffic. The contents 484 and value of any private extensions need to be studied when 485 considering the necessity to secure the MA reports since application- 486 level performance data might be present that is not otherwise 487 available to an attacker as with the required fields and vendor- 488 neutral extensions. 490 Using the MA reports to provide feedback into the acquisition of the 491 multicast streams can introduce possible additional security 492 implications. If a forged or otherwise modified MA report is 493 received for an earlier acquisition attempt, invalid data can be used 494 as input in later rapid acquisition attempts. For example, 495 incorrectly small SFGMP join times could cause the unicast burst to 496 be too short, leading to gaps in sequence numbers in the approach 497 discussed in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Additionally, 498 forged reports could give the appearance that rapid acquisition is 499 performing correctly, when it is in fact failing, or vice versa. 500 While integrity protection can be achieved through different ways, we 501 RECOMMEND the use of SRTCP [RFC3711]. 503 7. IANA Considerations 505 The following contact information is provided for all registrations 506 in this document: 508 Ali Begen 509 abegen@cisco.com 511 Note to the RFC Editor: In the following, please replace "XXXX" with 512 the number of this document prior to publication as an RFC. 514 7.1. RTCP XR Block Type 516 Note to IANA: Type value 11 has been pre-registered with IANA for 517 the "Multicast Acquisition Report Block" in the RTCP XR Block Type 518 Registry. Please replace the existing reference with the RFC number 519 of this document. 521 7.2. RTCP XR SDP Parameter 523 This document registers the SDP [RFC4566] parameter 'multicast-acq' 524 for the 'rtcp-xr' attribute in the RTCP XR SDP Parameters Registry. 526 7.3. Multicast Acquisition Method Registry 528 This document creates a new IANA registry for the MA methods. The 529 registry is called the Multicast Acquisition Method Registry. This 530 registry is to be managed by the IANA according to the Specification 531 Required policy of [RFC5226]. 533 The length of the MA Method field is a single octet, allowing 256 534 values. The registry is initialized with the following entries: 536 MA Method Description Reference 537 --------- ------------------------------------ ------------- 538 0 Reserved [RFCXXXX] 539 1 Simple join (No explicit method) [RFCXXXX] 540 2 RAMS [I-D.ietf-avt-rapid-acquisition-for-rtp] 541 3-254 Specification Required 542 255 Reserved [RFCXXXX] 544 The MA Method values 0 and 255 are reserved for future use. 546 Any registration for an unassigned value needs to contain the 547 following information: 549 o Contact information of the one doing the registration, including 550 at least name, address, and email. 552 o A detailed description of how the MA method works. 554 7.4. Multicast Acquisition Report Block TLV Space Registry 556 This document creates a new IANA TLV space registry for the MA report 557 block extensions. The registry is called the Multicast Acquisition 558 Report Block TLV Space Registry. This registry is to be managed by 559 the IANA according to the Specification Required policy of [RFC5226]. 561 The length of the Type field in the TLV elements is a single octet, 562 allowing 256 values. The registry is initialized with the following 563 entries: 565 Type Description Reference 566 ------- -------------------------------------------------- --------- 567 0 Reserved [RFCXXXX] 568 1 RTP Seqnum of the First Multicast Packet [RFCXXXX] 569 2 SFGMP Join Time [RFCXXXX] 570 3 Application Request-to-Multicast Delta Time [RFCXXXX] 571 4 Application Request-to-Presentation Delta Time [RFCXXXX] 572 11 Application Request-to-RAMS Request Delta Time [RFCXXXX] 573 12 RAMS Request-to-RAMS Information Delta Time [RFCXXXX] 574 13 RAMS Request-to-Burst Delta Time [RFCXXXX] 575 14 RAMS Request-to-Multicast Delta Time [RFCXXXX] 576 15 RAMS Request-to-Burst-Completion Delta Time [RFCXXXX] 577 16 Number of Duplicate Packets [RFCXXXX] 578 17 Size of Burst-to-Multicast Gap [RFCXXXX] 579 18-127 Specification Required 580 128-254 Reserved for private extensions [RFCXXXX] 581 255 Reserved [RFCXXXX] 583 The Type values 0 and 255 are reserved for future use. The Type 584 values between (and including) 128 and 254 are reserved for private 585 extensions. 587 Any registration for an unassigned Type value needs to contain the 588 following information: 590 o Contact information of the one doing the registration, including 591 at least name, address, and email. 593 o A detailed description of what the new TLV element represents and 594 how it is interpreted. 596 7.5. Multicast Acquisition Status Code Space Registry 598 This document creates a new IANA TLV space registry for the status 599 codes. The registry is called the Multicast Acquisition Status Code 600 Space Registry. This registry is to be managed by the IANA according 601 to the Specification Required policy of [RFC5226]. 603 The length of the Status field is two octets, allowing 65536 codes. 604 However, the status codes have been registered to allow for an easier 605 classification. For example, the values between (and including) 1 606 and 1000 are primarily used by the MA method of simple join. The 607 values between (and including) 1001 and 2000 are used by the MA 608 method described in [I-D.ietf-avt-rapid-acquisition-for-rtp]. When 609 registering new status codes for the existing MA methods or newly 610 defined MA methods, registrants are encouraged to allocate sufficient 611 continuous space. Note that because of the limited space, not every 612 MA method can be assigned 1000 different values for its Status codes. 614 The Status code 65535 is reserved for future use. The registry is 615 initialized with the following entries: 617 Code Description Reference 618 ----- -------------------------------------------------- ------------- 619 0 A private status code is included in the message [RFCXXXX] 621 1 Multicast join was successful [RFCXXXX] 622 2 Multicast join has failed [RFCXXXX] 623 3 A presentation error has occurred [RFCXXXX] 624 4 An unspecified RR internal error has occurred [RFCXXXX] 626 1001 RAMS has been successfully completed [RFCXXXX] 627 1002 No RAMS-R message has been sent [RFCXXXX] 628 1003 Invalid RAMS-I message syntax [RFCXXXX] 629 1004 RAMS-I message has timed out [RFCXXXX] 630 1005 RAMS unicast burst has timed out [RFCXXXX] 631 1006 An unspecified RR internal error has occurred 632 during RAMS [RFCXXXX] 633 1007 A presentation error has occurred during RAMS [RFCXXXX] 634 65535 Reserved [RFCXXXX] 636 Any registration for an unassigned Status code needs to contain the 637 following information: 639 o Contact information of the one doing the registration, including 640 at least name, address, and email. 642 o A detailed description of what the new Status code describes and 643 how it is interpreted. 645 8. Acknowledgments 647 This specification has greatly benefited from discussions with 648 Michael Lague, Dong Hsu, Carol Iturralde, Xuan Zhong, Dave Oran, Tom 649 Van Caenegem and many others. The authors would like to thank each 650 of these individuals for their contributions. 652 9. References 654 9.1. Normative References 656 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 657 Requirement Levels", BCP 14, RFC 2119, March 1997. 659 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 660 Jacobson, "RTP: A Transport Protocol for Real-Time 661 Applications", STD 64, RFC 3550, July 2003. 663 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 664 Protocol Extended Reports (RTCP XR)", RFC 3611, 665 November 2003. 667 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 668 Thyagarajan, "Internet Group Management Protocol, Version 669 3", RFC 3376, October 2002. 671 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 672 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 674 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 675 Group Management Protocol Version 3 (IGMPv3) and Multicast 676 Listener Discovery Protocol Version 2 (MLDv2) for Source- 677 Specific Multicast", RFC 4604, August 2006. 679 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 680 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 681 July 2006. 683 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 684 Description Protocol", RFC 4566, July 2006. 686 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 687 Specifications: ABNF", STD 68, RFC 5234, January 2008. 689 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 690 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 691 RFC 3711, March 2004. 693 9.2. Informative References 695 [I-D.ietf-avt-rapid-acquisition-for-rtp] 696 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 697 Based Rapid Acquisition of Multicast RTP Sessions", 698 draft-ietf-avt-rapid-acquisition-for-rtp-17 (work in 699 progress), November 2010. 701 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 702 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 703 May 2008. 705 Authors' Addresses 707 Ali Begen 708 Cisco 709 181 Bay Street 710 Toronto, ON M5J 2T3 711 Canada 713 Email: abegen@cisco.com 715 Eric Friedrich 716 Cisco 717 1414 Massachusetts Ave. 718 Boxborough, MA 01719 719 USA 721 Email: efriedri@cisco.com