idnits 2.17.1 draft-ietf-avtext-multicast-acq-rtcp-xr-01.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 (March 30, 2011) is 4748 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 458, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 643, but not defined ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: October 1, 2011 March 30, 2011 7 Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) 8 Extended Reports (XRs) 9 draft-ietf-avtext-multicast-acq-rtcp-xr-01 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 may use one ore 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 may (or may have to) do a 21 simple multicast join. For quality reporting, monitoring and 22 diagnostics purposes, it is important to collect detailed information 23 from the RTP receivers about their acquisition and presentation 24 experiences. This document addresses this issue by defining a new 25 report block type, called Multicast Acquisition (MA) Report Block, 26 within the framework of RTP Control Protocol (RTCP) Extended Reports 27 (XR) (RFC 3611). This document also defines the necessary signaling 28 of the new MA report block type in the Session Description Protocol 29 (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 October 1, 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 . . . . . . . . . . . . . . . . . . 7 70 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.2.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 9 72 4.2.2. Private Extensions . . . . . . . . . . . . . . . . . . 11 73 5. Session Description Protocol Signaling . . . . . . . . . . . . 13 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 76 7.1. RTCP XR Block Type . . . . . . . . . . . . . . . . . . . . 15 77 7.2. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 15 78 7.3. Multicast Acquisition Method Registry . . . . . . . . . . 15 79 7.4. Multicast Acquisition Report Block TLV Space Registry . . 16 80 7.5. Multicast Acquisition Status Code Space Registry . . . . . 17 81 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 84 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 87 1. Introduction 89 RTP Control Protocol (RTCP) is the out-of-band control protocol for 90 the applications that are using the Real-time Transport Protocol 91 (RTP) for media transport [RFC3550]. In addition to providing 92 minimal control functionality to RTP entities, RTCP also enables a 93 basic level monitoring of RTP sessions via sender and receiver 94 reports. More statistically detailed monitoring as well as 95 application-specific monitoring is usually achieved through the RTCP 96 Extended Reports (XRs) [RFC3611]. 98 In most RTP-based multicast applications such as the ones carrying 99 video content, the RTP source sends inter-related data. 100 Consequently, the RTP application may not be able to decode and 101 present the data in an RTP packet before decoding one or more earlier 102 RTP packets and/or before acquiring some Reference Information about 103 the content itself. Thus, RTP receivers that are randomly joining a 104 multicast session often experience a random acquisition delay. In 105 order to reduce this delay, [I-D.ietf-avt-rapid-acquisition-for-rtp] 106 proposes an approach where an auxiliary unicast RTP session is 107 established between a retransmission server and the joining RTP 108 receiver. Over this unicast RTP session, the retransmission server 109 provides the Reference Information, which is all the information the 110 RTP receiver needs to rapidly acquire the multicast stream. This 111 method is referred to as the Rapid Acquisition of Multicast Sessions 112 (RAMS). However, depending on the variability in the Source 113 Filtering Group Management Protocol (SFGMP) processing times, 114 availability of network resources for rapid acquisition and nature of 115 the RTP data, not all RTP receivers can acquire the multicast stream 116 in the same amount of time. The performance of rapid acquisition may 117 vary not only for different RTP receivers but also over time. 119 To increase the visibility of the multicast service provider into its 120 network, to diagnose slow multicast acquisition issues and to collect 121 the acquisition experiences of the RTP receivers, this document 122 defines a new report block type, which is called Multicast 123 Acquisition (MA) Report Block, within the framework of RTCP XR. RTP 124 receivers that are using the method described in 125 [I-D.ietf-avt-rapid-acquisition-for-rtp] may use this report every 126 time they join a new multicast RTP session. RTP receivers that use a 127 different method for rapid acquisition or those do not use any method 128 but rather do a simple multicast join may also use this report to 129 collect information. This way, the multicast service provider can 130 quantitatively compare the improvements achieved by different 131 methods. 133 2. Requirements Notation 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 3. Definitions 141 This document uses the following acronyms and definitions from 142 [I-D.ietf-avt-rapid-acquisition-for-rtp]: 144 (Primary) Multicast Session: The multicast session to which RTP 145 receivers can join at a random point in time. 147 Primary Multicast RTP Session: The multicast RTP session an RTP 148 receiver is interested in acquiring. 150 Primary Multicast (RTP) Streams: The RTP stream(s) carried in the 151 primary multicast RTP session. 153 Source Filtering Group Management Protocol (SFGMP): Following the 154 definition in [RFC4604], SFGMP refers to the Internet Group 155 Management Protocol (IGMP) version 3 [RFC3376] and the Multicast 156 Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and 157 IPv6 networks, respectively. However, the report block type 158 introduced in this document does not depend on a specific version of 159 either of these group management protocols. In the remainder of this 160 document, SFGMP will refer to any group management protocol that has 161 Join and Leave functionalities. 163 Retransmission (Burst) Packet: An RTP packet that is formatted as 164 defined in [RFC4588]. 166 Reference Information: The set of certain media content and metadata 167 information that is sufficient for an RTP receiver to start usefully 168 consuming a media stream. The meaning, format and size of this 169 information are specific to the application and are out of scope of 170 this document. 172 (Unicast) Burst (Stream): A unicast stream of RTP retransmission 173 packets that enable an RTP receiver to rapidly acquire the Reference 174 Information associated with a primary multicast stream. Each burst 175 stream is identified by its SSRC identifier that is unique in the 176 primary multicast RTP session. The burst streams are typically 177 transmitted at an accelerated rate. 179 Retransmission Server (RS): The RTP/RTCP endpoint that can generate 180 the retransmission packets and the burst streams. RS may also 181 generate other non-retransmission packets to aid the rapid 182 acquisition process. 184 4. Multicast Acquisition (MA) Report Block 186 This section defines the format of the MA report block. The base 187 report is payload-independent. An extension mechanism is provided 188 where further optional payload-independent and payload-specific 189 information can be included in the report as desired. 191 The optional extensions that are defined in this document are 192 primarily developed for the method presented in 193 [I-D.ietf-avt-rapid-acquisition-for-rtp]. Other methods that provide 194 rapid acquisition MAY define their own extensions to be used in the 195 MA report block. 197 The packet format for the RTCP XR is defined in Section 2 of 198 [RFC3611]. Each XR packet has a fixed-length field for version, 199 padding, reserved bits, payload type (PT), length, SSRC of packet 200 sender as well as a variable-length field for report blocks. In the 201 XR packets, the PT field is set to XR (207). 203 The MA report block is better to be sent after all the necessary 204 information is collected and computed. Partial reporting is 205 generally not useful as it may not give the full picture of the 206 multicast acquisition, and causes additional complexity in terms of 207 report block matching and correlation. The MA report block SHOULD 208 only be sent as a part of an RTCP compound packet, and it is sent in 209 the primary multicast session. 211 The reliability of the MA report block is not any more essential than 212 other report blocks or types. If desired, the report block could be 213 repeated for redundancy purposes while respecting to the RTCP 214 scheduling algorithms. 216 4.1. Base Report 218 The base report format is shown in Figure 1. 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | BT=11 | MA Method | Block Length | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | SSRC of the Primary Multicast Stream | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Status | Rsvd. | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 1: Base report format for the MA report block 232 o BT (8 bits): Mandatory field that denotes the type for this block 233 format. The MA report block is identified by the constant 11. 235 o MA Method (8 bits): Mandatory field that denotes the type of the 236 MA method (e.g., simple join, RAMS, etc.). See Section 7.3 for 237 the values registered with IANA. 239 o Block Length (16 bits): The length of this report block, 240 including the header, in 32-bit words minus one. 242 o SSRC of the Primary Multicast Stream (32 bits): Mandatory field 243 that denotes the SSRC of the primary multicast stream. 245 o Status (16 bits): Mandatory field that denotes the status code 246 for the MA operation. 248 This document defines several status codes and registers them with 249 IANA in Section 7.5. If a new vendor-neutral status code will be 250 defined, it MUST be registered with IANA through the guidelines 251 specified in Section 7.5. If the new status code is intended to 252 be used privately by a vendor, there is no need for IANA 253 management. Instead, the vendor MUST use the private extension 254 mechanism (Section 4.2.2) to convey its message and MUST indicate 255 this by putting zero in the Status field. 257 o Rsvd. (16 bits): This field SHALL be set to 0 and ignored on 258 reception. 260 If the multicast join was successful meaning that at least one 261 multicast packet has been received, some additional information MUST 262 be appended to the base report as will be described in Section 4.2.1. 264 4.1.1. Status Code Rules 266 Different MA methods usually use different status codes, although 267 some status codes (e.g., a code indicating that multicast join has 268 failed) may apply to more than one MA method. However, the status 269 code reported in the base report MUST always be within the scope of 270 the particular MA method specified in the MA Method field. 272 In certain MA methods, the RTP receiver may generate a status code 273 for its multicast acquisition attempt, or may be told by another 274 network element or RTP endpoint what the current status is via a 275 response code. In such cases, the RTP receiver MAY report the value 276 of the received response code as its status code if the response code 277 has a higher priority. It is RECOMMENDED that each MA method 278 outlines the rules pertaining to its response and status codes so 279 that RTP receiver implementations can determine what to report in any 280 given scenario. Below, we provide these rules for the RAMS method 281 described in [I-D.ietf-avt-rapid-acquisition-for-rtp]. 283 Section 12.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] defines 284 several response codes for its MA method. The 1xx and 2xx-level 285 response codes are informational and success response codes, 286 respectively. If the RTP receiver receives a 1xx or 2xx-level 287 response code, it MUST use one of the 1xxx-level status codes defined 288 in Section 7.5 of this document. The RTP receiver may also receive a 289 4xx or 5xx-level response code (indicating receiver-side and server- 290 side errors, respectively). In that case, the RTP receiver MUST use 291 the response code as its status code. In other words, the 4xx and 292 5xx-level response codes have a higher priority than the 1xxx-level 293 status codes. The 5xx-level response codes have a higher priority 294 than the 4xx-level response codes and MUST be reported in the base 295 report in case the RTP receiver receives both 4xx and 5xx-level 296 response codes (in different RAMS-I messages) during the same RAMS 297 session. 299 4.2. Extensions 301 To improve the reporting scope, it might be desirable to define new 302 fields in the MA report block. Such fields MUST be encoded as TLV 303 elements as described below and sketched in Figure 2: 305 o Type: A single-octet identifier that defines the type of the 306 parameter represented in this TLV element. 308 o Length: A two-octet field that indicates the length (in octets) 309 of the TLV element excluding the Type and Length fields, and the 310 8-bit Reserved field between them. Note that this length does not 311 include any padding that is required for alignment. 313 o Value: Variable-size set of octets that contains the specific 314 value for the parameter. 316 In the extensions, the Reserved field SHALL be set to zero and 317 ignored on reception. If a TLV element does not fall on a 32-bit 318 boundary, the last word MUST be padded to the boundary using further 319 bits set to zero. 321 In the MA report block, any vendor-neutral or private extension MUST 322 be placed after the base report. 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type | Reserved | Length | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 : Value : 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 2: Structure of a TLV element 334 4.2.1. Vendor-Neutral Extensions 336 If the goal in defining new TLV elements is to extend the report 337 block in a vendor-neutral manner, they MUST be registered with IANA 338 through the guidelines provided in Section 7.4. 340 The current document defines several vendor-neutral extensions. 341 First, we present the TLV elements that can be used by any RTP-based 342 multicast application. 344 o RTP Seqnum of the First Multicast Packet (16 bits): TLV element 345 that specifies the RTP sequence number of the first multicast 346 packet received for the primary multicast stream. If the 347 multicast join was successful, this element MUST exist. If no 348 multicast packet has been received, this element SHALL NOT exist. 350 Type: 1 352 o SFGMP Join Time (32 bits): TLV element that denotes the greater 353 of zero or the time difference (in ms) between the instant SFGMP 354 Join message has been sent and the instant the first packet was 355 received in the multicast session. If the multicast join was 356 successful, this element MUST exist. If no multicast packet has 357 been received, this element SHALL NOT exist. 359 Type: 2 361 o Application Request-to-Multicast Delta Time (32 bits): Optional 362 TLV element that denotes the time difference (in ms) between the 363 instant the application became aware it would join a new multicast 364 session and the instant the first RTP packet was received from the 365 primary multicast stream. If no such packet has been received, 366 this element SHALL NOT exist. 368 Type: 3 370 o Application Request-to-Presentation Delta Time (32 bits): 371 Optional TLV element that denotes the time difference (in ms) 372 between the instant the application became aware it would join a 373 new multicast session and the instant the media is first 374 presented. If the RTP receiver cannot successfully present the 375 media, this element SHALL NOT exist. 377 Type: 4 379 We next present the TLV elements that can be used when the RTP 380 receiver supports and uses the RAMS method described in 381 [I-D.ietf-avt-rapid-acquisition-for-rtp]. However, if the RTP 382 receiver does not send a rapid acquisition request, the following TLV 383 elements MUST NOT exist in the MA report block. Some elements may or 384 may not exist depending on whether the RTP receiver receives any 385 packet from the unicast burst and/or the primary multicast stream or 386 not. These are explained below. 388 o Application Request-to-RAMS Request Delta Time (32 bits): 389 Optional TLV element that denotes the time difference (in ms) 390 between the instant the application became aware it would request 391 a rapid acquisition and the instant the rapid acquisition request 392 was actually sent by the application. 394 Type: 11 396 o RAMS Request-to-RAMS Information Delta Time (32 bits): Optional 397 TLV element that denotes the time difference (in ms) between the 398 instant the rapid acquisition request has been sent and the 399 instant the first RAMS Information message was received in the 400 unicast session. If no such message has been received, this 401 element SHALL NOT exist. 403 Type: 12 405 o RAMS Request-to-Burst Delta Time (32 bits): Optional TLV element 406 that denotes the time difference (in ms) between the instant the 407 rapid acquisition request has been sent and the instant the first 408 burst packet was received in the unicast session. If no burst 409 packet has been received, this element SHALL NOT exist. 411 Type: 13 413 o RAMS Request-to-Multicast Delta Time (32 bits): Optional TLV 414 element that denotes the time difference (in ms) between the 415 instant the rapid acquisition request has been sent and the 416 instant the first RTP packet was received from the primary 417 multicast stream. If no such packet has been received, this 418 element SHALL NOT exist. 420 Type: 14 422 o RAMS Request-to-Burst-Completion Delta Time (32 bits): Optional 423 TLV element that denotes the time difference (in ms) between the 424 instant the rapid acquisition request has been sent and the 425 instant the last burst packet was received in the unicast session. 426 If no burst packet has been received, this element SHALL NOT 427 exist. 429 Type: 15 431 o Number of Duplicate Packets (32 bits): Optional TLV element that 432 denotes the number of duplicate packets due to receiving the same 433 packet in both unicast and primary multicast RTP sessions. If no 434 RTP packet has been received from the primary multicast stream, 435 this element SHALL NOT exist. If no burst packet has been 436 received in the unicast session, the value of this element SHALL 437 be set to zero. 439 Type: 16 441 o Size of Burst-to-Multicast Gap (32 bits): Optional TLV element 442 that denotes the greater of zero or the difference between the 443 sequence number of the first multicast packet (received from the 444 primary multicast stream) and the sequence number of the last 445 burst packet minus 1 (considering the wrapping of the sequence 446 numbers). If no burst packet has been received in the unicast 447 session or no RTP packet has been received from the primary 448 multicast stream, this element SHALL NOT exist. 450 Type: 17 452 4.2.2. Private Extensions 454 It is desirable to allow vendors to use private extensions in TLV 455 format. For interoperability, such extensions MUST NOT collide with 456 each other. 458 The range of [128-254] of TLV Types is reserved for private 459 extensions. IANA management for these extensions is unnecessary and 460 they are the responsibility of individual vendors. 462 The structure that MUST be used for the private extensions is 463 depicted in Figure 3. Here, the private enterprise numbers are used 464 from http://www.iana.org/assignments/enterprise-numbers. This will 465 ensure the uniqueness of the private extensions and avoid any 466 collision. 468 0 1 2 3 469 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 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Type | Reserved | Length | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Enterprise Number | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 : Value : 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Figure 3: Structure of a private extension 480 5. Session Description Protocol Signaling 482 A new unilateral parameter is defined for the MA report block to be 483 used with the Session Description Protocol (SDP) [RFC4566] using the 484 Augmented Backus-Naur Form (ABNF) [RFC5234]. It has the following 485 syntax within the 'rtcp-xr' attribute [RFC3611]: 487 multicast-acq-ext = "multicast-acq" 489 Figure 4 491 Refer to Section 5.1 of [RFC3611] for a detailed description and the 492 full syntax of the "rtcp-xr" attribute. The "multicast-acq-ext" 493 parameter is compatible with the definition of "format-ext" in the 494 "rtcp-xr" attribute. 496 6. Security Considerations 498 The security considerations of [RFC3611] apply in this document as 499 well. 501 The information contained in MA reports could be stolen as any other 502 RTCP reports if proper protection mechanism(s) are not in place. If 503 desired, similar to other RTCP XR reports, the MA reports MAY be 504 protected by using Secure RTP (SRTP) and Secure RTP Control Protocol 505 (SRTCP) [RFC3711]. 507 Using the MA reports to provide feedback into the acquisition of the 508 multicast streams can introduce possible additional security 509 implications. If a forged or otherwise modified MA report is 510 received for an earlier acquisition attempt, invalid data may be used 511 as input in later rapid acquisition attempts. For example, 512 incorrectly small SFGMP join times could cause the unicast burst to 513 be too short, leading to gaps in sequence numbers in the approach 514 discussed in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Additionally, 515 forged reports could give the appearance that rapid acquisition is 516 performing correctly, when it is in fact failing, or vice versa. 517 However, the MA reports are believed not to introduce any additional 518 risks from a confidentiality viewpoint. 520 7. IANA Considerations 522 The following contact information shall be used for all registrations 523 in this document: 525 Ali Begen 526 abegen@cisco.com 528 Note to the RFC Editor: In the following, please replace "XXXX" with 529 the number of this document prior to publication as an RFC. 531 7.1. RTCP XR Block Type 533 Type value 11 has been pre-registered with IANA for the "Multicast 534 Acquisition Report Block" in the RTCP XR Block Type Registry. 536 7.2. RTCP XR SDP Parameter 538 This document registers the SDP [RFC4566] parameter 'multicast-acq' 539 for the 'rtcp-xr' attribute in the RTCP XR SDP Parameters Registry. 541 7.3. Multicast Acquisition Method Registry 543 This document creates a new IANA registry for the MA methods. The 544 registry is called the Multicast Acquisition Method Registry. This 545 registry is to be managed by the IANA according to the Specification 546 Required policy of [RFC5226]. 548 The length of the MA Method field is a single octet, allowing 256 549 values. The registry is initialized with the following entries: 551 MA Method Description Reference 552 --------- ------------------------------------ ------------- 553 0 Reserved [RFCXXXX] 554 1 Simple join (No explicit method) [RFCXXXX] 555 2 RAMS [I-D.ietf-avt-rapid-acquisition-for-rtp] 556 3-254 Specification Required 557 255 Reserved [RFCXXXX] 559 The MA Method values 0 and 255 are reserved for future use. 561 Any registration for an unassigned value needs to contain the 562 following information: 564 o Contact information of the one doing the registration, including 565 at least name, address, and email. 567 o A detailed description of how the MA method works. 569 7.4. Multicast Acquisition Report Block TLV Space Registry 571 This document creates a new IANA TLV space registry for the MA report 572 block extensions. The registry is called the Multicast Acquisition 573 Report Block TLV Space Registry. This registry is to be managed by 574 the IANA according to the Specification Required policy of [RFC5226]. 576 The length of the Type field in the TLV elements is a single octet, 577 allowing 256 values. The registry is initialized with the following 578 entries: 580 Type Description Reference 581 ---- -------------------------------------------------- ------------- 582 1 RTP Seqnum of the First Multicast Packet [RFCXXXX] 583 2 SFGMP Join Time [RFCXXXX] 584 3 Application Request-to-Multicast Delta Time [RFCXXXX] 585 4 Application Request-to-Presentation Delta Time [RFCXXXX] 586 11 Application Request-to-RAMS Request Delta Time [RFCXXXX] 587 12 RAMS Request-to-RAMS Information Delta Time [RFCXXXX] 588 13 RAMS Request-to-Burst Delta Time [RFCXXXX] 589 14 RAMS Request-to-Multicast Delta Time [RFCXXXX] 590 15 RAMS Request-to-Burst-Completion Delta Time [RFCXXXX] 591 16 Number of Duplicate Packets [RFCXXXX] 592 17 Size of Burst-to-Multicast Gap [RFCXXXX] 594 The Type values 0 and 255 are reserved for future use. The Type 595 values between (and including) 128 and 254 are reserved for private 596 extensions. 598 Any registration for an unassigned Type value needs to contain the 599 following information: 601 o Contact information of the one doing the registration, including 602 at least name, address, and email. 604 o A detailed description of what the new TLV element represents and 605 how it shall be interpreted. 607 7.5. Multicast Acquisition Status Code Space Registry 609 This document creates a new IANA TLV space registry for the status 610 codes. The registry is called the Multicast Acquisition Status Code 611 Space Registry. This registry is to be managed by the IANA according 612 to the Specification Required policy of [RFC5226]. 614 The length of the Status field is two octets, allowing 65536 codes. 615 However, the status codes have been registered to allow for an easier 616 classification. For example, the values between (and including) 1 617 and 1000 are primarily used by the MA method of simple join. The 618 values between (and including) 1001 and 2000 are used by the MA 619 method described in [I-D.ietf-avt-rapid-acquisition-for-rtp]. When 620 registering new status codes for the existing MA methods or newly 621 defined MA methods, a similar classification scheme is encouraged to 622 be followed. 624 The Status code 65535 is reserved for future use. The registry is 625 initialized with the following entries: 627 Code Description Reference 628 ----- -------------------------------------------------- ------------- 629 0 A private status code is included in the message [RFCXXXX] 631 1 Multicast join was successful [RFCXXXX] 632 2 Multicast join has failed [RFCXXXX] 633 3 A presentation error has occurred [RFCXXXX] 634 4 An unspecified RR internal error has occurred [RFCXXXX] 636 1001 RAMS has been successfully completed [RFCXXXX] 637 1002 No RAMS-R message has been sent [RFCXXXX] 638 1003 Invalid RAMS-I message syntax [RFCXXXX] 639 1004 RAMS-I message has timed out [RFCXXXX] 640 1005 RAMS unicast burst has timed out [RFCXXXX] 641 1006 An unspecified RR internal error has occurred 642 during RAMS [RFCXXXX] 643 1007 A presentation error has occurred during RAMS [RFCXXXX] 645 Any registration for an unassigned Status code needs to contain the 646 following information: 648 o Contact information of the one doing the registration, including 649 at least name, address, and email. 651 o A detailed description of what the new Status code describes and 652 how it shall be interpreted. 654 8. Acknowledgments 656 This specification has greatly benefited from discussions with 657 Michael Lague, Dong Hsu, Carol Iturralde, Xuan Zhong, Dave Oran, Tom 658 Van Caenegem and many others. The authors would like to thank each 659 of these individuals for their contributions. 661 9. References 663 9.1. Normative References 665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 666 Requirement Levels", BCP 14, RFC 2119, March 1997. 668 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 669 Jacobson, "RTP: A Transport Protocol for Real-Time 670 Applications", STD 64, RFC 3550, July 2003. 672 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 673 Protocol Extended Reports (RTCP XR)", RFC 3611, 674 November 2003. 676 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 677 Thyagarajan, "Internet Group Management Protocol, Version 678 3", RFC 3376, October 2002. 680 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 681 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 683 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 684 Group Management Protocol Version 3 (IGMPv3) and Multicast 685 Listener Discovery Protocol Version 2 (MLDv2) for Source- 686 Specific Multicast", RFC 4604, August 2006. 688 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 689 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 690 July 2006. 692 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 693 Description Protocol", RFC 4566, July 2006. 695 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 696 Specifications: ABNF", STD 68, RFC 5234, January 2008. 698 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 699 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 700 May 2008. 702 9.2. Informative References 704 [I-D.ietf-avt-rapid-acquisition-for-rtp] 705 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 706 Based Rapid Acquisition of Multicast RTP Sessions", 707 draft-ietf-avt-rapid-acquisition-for-rtp-17 (work in 708 progress), November 2010. 710 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 711 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 712 RFC 3711, March 2004. 714 Authors' Addresses 716 Ali Begen 717 Cisco 718 181 Bay Street 719 Toronto, ON M5J 2T3 720 Canada 722 Email: abegen@cisco.com 724 Eric Friedrich 725 Cisco 726 1414 Massachusetts Ave. 727 Boxborough, MA 01719 728 USA 730 Email: efriedri@cisco.com