idnits 2.17.1 draft-ietf-avtext-multicast-acq-rtcp-xr-00.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 5, 2011) is 4799 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: 'RFCXXXX' is mentioned on line 630, 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 (~~), 2 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: September 6, 2011 March 5, 2011 7 Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) 8 Extended Reports (XRs) 9 draft-ietf-avtext-multicast-acq-rtcp-xr-00 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. One approach to reduce this delay is to receive a 18 burst stream from a retransmission server that facilitates rapid 19 acquisition of the multicast stream. An RTP receiver may use this 20 approach (or any other approach) to achieve rapid acquisition. Yet, 21 due to various factors, performance of the rapid acquisition methods 22 usually varies. Furthermore, in some cases the RTP receiver may (or 23 may have to) do a simple multicast join. For quality reporting, 24 monitoring and diagnostics purposes, it is important to collect 25 detailed information from the RTP receivers about their acquisition 26 and presentation experiences. This document addresses this issue by 27 defining a new report block type, called Multicast Acquisition (MA) 28 Report Block, within the framework of RTP Control Protocol (RTCP) 29 Extended Reports (XR) (RFC 3611). This document also defines the 30 necessary signaling of the new MA report block type in the Session 31 Description Protocol (SDP). 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 6, 2011. 50 Copyright Notice 52 Copyright (c) 2011 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 69 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 4. Multicast Acquisition (MA) Report Block . . . . . . . . . . . 6 71 4.1. Base Report . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.1.1. Status Code Rules . . . . . . . . . . . . . . . . . . 7 73 4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.2.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 8 75 4.2.2. Private Extensions . . . . . . . . . . . . . . . . . . 11 76 5. Session Description Protocol Signaling . . . . . . . . . . . . 12 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 7.1. RTCP XR Block Type . . . . . . . . . . . . . . . . . . . . 14 80 7.2. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 14 81 7.3. Multicast Acquisition Method Registry . . . . . . . . . . 14 82 7.4. Multicast Acquisition Report Block TLV Space Registry . . 15 83 7.5. Multicast Acquisition Status Code Space Registry . . . . . 16 84 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 90 1. Introduction 92 RTP Control Protocol (RTCP) is the out-of-band control protocol for 93 the applications that are using the Real-time Transport Protocol 94 (RTP) for media transport [RFC3550]. In addition to providing 95 minimal control functionality to RTP entities, RTCP also enables a 96 basic level monitoring of RTP sessions via sender and receiver 97 reports. More statistically detailed monitoring as well as 98 application-specific monitoring is usually achieved through the RTCP 99 Extended Reports (XRs) [RFC3611]. 101 In most RTP-based multicast applications such as the ones carrying 102 video content, the RTP source sends inter-related data. 103 Consequently, the RTP application may not be able to decode and 104 present the data in an RTP packet before decoding one or more earlier 105 RTP packets and/or before acquiring some Reference Information about 106 the content itself. Thus, RTP receivers that are randomly joining a 107 multicast session often experience a random acquisition delay. In 108 order to reduce this delay, [I-D.ietf-avt-rapid-acquisition-for-rtp] 109 proposes an approach where an auxiliary unicast RTP session is 110 established between a retransmission server and the joining RTP 111 receiver. Over this unicast RTP session, the retransmission server 112 provides the Reference Information, which is all the information the 113 RTP receiver needs to rapidly acquire the multicast stream. This 114 method is referred to as the Rapid Acquisition of Multicast Sessions 115 (RAMS). However, depending on the variability in the Source 116 Filtering Group Management Protocol (SFGMP) processing times, 117 availability of network resources for rapid acquisition and nature of 118 the RTP data, not all RTP receivers can acquire the multicast stream 119 in the same amount of time. The performance of rapid acquisition may 120 vary not only for different RTP receivers but also over time. 122 To increase the visibility of the multicast service provider into its 123 network, to diagnose slow multicast acquisition issues and to collect 124 the acquisition experiences of the RTP receivers, this document 125 defines a new report block type, which is called Multicast 126 Acquisition (MA) Report Block, within the framework of RTCP XR. RTP 127 receivers that are using the method described in 128 [I-D.ietf-avt-rapid-acquisition-for-rtp] may use this report every 129 time they join a new multicast RTP session. RTP receivers that use a 130 different method for rapid acquisition or those do not use any method 131 but rather do a simple multicast join may also use this report to 132 collect information. This way, the multicast service provider can 133 quantitatively compare the improvements achieved by different 134 methods. 136 2. Requirements Notation 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 3. Definitions 144 This document uses the following acronyms and definitions from 145 [I-D.ietf-avt-rapid-acquisition-for-rtp]: 147 (Primary) Multicast Session: The multicast session to which RTP 148 receivers can join at a random point in time. 150 Primary Multicast RTP Session: The multicast RTP session an RTP 151 receiver is interested in acquiring. 153 Primary Multicast (RTP) Streams: The RTP stream(s) carried in the 154 primary multicast RTP session. 156 Source Filtering Group Management Protocol (SFGMP): Following the 157 definition in [RFC4604], SFGMP refers to the Internet Group 158 Management Protocol (IGMP) version 3 [RFC3376] and the Multicast 159 Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and 160 IPv6 networks, respectively. However, the report block type 161 introduced in this document does not depend on a specific version of 162 either of these group management protocols. In the remainder of this 163 document, SFGMP will refer to any group management protocol that has 164 Join and Leave functionalities. 166 Retransmission (Burst) Packet: An RTP packet that is formatted as 167 defined in [RFC4588]. 169 Reference Information: The set of certain media content and metadata 170 information that is sufficient for an RTP receiver to start usefully 171 consuming a media stream. The meaning, format and size of this 172 information are specific to the application and are out of scope of 173 this document. 175 (Unicast) Burst (Stream): A unicast stream of RTP retransmission 176 packets that enable an RTP receiver to rapidly acquire the Reference 177 Information associated with a primary multicast stream. Each burst 178 stream is identified by its SSRC identifier that is unique in the 179 primary multicast RTP session. The burst streams are typically 180 transmitted at an accelerated rate. 182 Retransmission Server (RS): The RTP/RTCP endpoint that can generate 183 the retransmission packets and the burst streams. RS may also 184 generate other non-retransmission packets to aid the rapid 185 acquisition process. 187 4. Multicast Acquisition (MA) Report Block 189 This section defines the format of the MA report block. The base 190 report is payload-independent. An extension mechanism is provided 191 where further optional payload-independent and payload-specific 192 information can be included in the report as desired. 194 The optional extensions that are defined in this document are 195 primarily developed for the method presented in 196 [I-D.ietf-avt-rapid-acquisition-for-rtp]. Other methods that provide 197 rapid acquisition MAY define their own extensions to be used in the 198 MA report block. 200 The packet format for the RTCP XR is defined in Section 2 of 201 [RFC3611]. Each XR packet has a fixed-length field for version, 202 padding, reserved bits, payload type (PT), length, SSRC of packet 203 sender as well as a variable-length field for report blocks. In the 204 XR packets, the PT field is set to XR (207). 206 4.1. Base Report 208 The base report format is shown in Figure 1. 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | BT=11 | MA Method | Block Length | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | SSRC of the Primary Multicast Stream | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Status | Rsvd. | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Figure 1: Base report format for the MA report block 222 o BT (8 bits): Mandatory field that denotes the type for this block 223 format. The MA report block is identified by the constant 11. 225 o MA Method (8 bits): Mandatory field that denotes the type of the 226 MA method (e.g., simple join, RAMS, etc.). See Section 7.3 for 227 the values registered with IANA. 229 o Block Length (16 bits): The length of this report block, 230 including the header, in 32-bit words minus one. 232 o SSRC of the Primary Multicast Stream (32 bits): Mandatory field 233 that denotes the SSRC of the primary multicast stream. 235 o Status (16 bits): Mandatory field that denotes the status code 236 for the MA operation. 238 This document defines several status codes and registers them with 239 IANA. If a new vendor-neutral status code will be defined, it 240 MUST be registered with IANA through the guidelines specified in 241 Section 7.5. If the new status code is intended to be used 242 privately by a vendor, there is no need for IANA management. 243 Instead, the vendor MUST use the private extension mechanism 244 (Section 4.2.2) to convey its message and MUST indicate this by 245 putting zero in the Status field. 247 o Rsvd. (16 bits): This field SHALL be set to 0 and ignored. 249 If the multicast join was successful meaning that at least one 250 multicast packet has been received, some additional information MUST 251 be appended to the base report as will be described in Section 4.2.1. 253 4.1.1. Status Code Rules 255 Different MA methods usually use different status codes, although 256 some status codes (e.g., a code indicating that multicast join has 257 failed) may apply to more than one MA method. However, the status 258 code reported in the base report MUST always be within the scope of 259 the particular MA method specified in the MA Method field. 261 In certain MA methods, the RTP receiver may generate a status code 262 for its multicast acquisition attempt, or may be told by another 263 network element or RTP endpoint what the current status is via a 264 response code. In such cases, the RTP receiver MAY report the value 265 of the received response code as its status code if the response code 266 has a higher priority. It is RECOMMENDED that each MA method 267 outlines the rules pertaining to its response and status codes so 268 that RTP receiver implementations can determine what to report in any 269 given scenario. Below, we provide these rules for the RAMS method 270 described in [I-D.ietf-avt-rapid-acquisition-for-rtp]. 272 Section 12.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] defines 273 several response codes for its MA method. The 1xx and 2xx-level 274 response codes are informational and success response codes, 275 respectively. If the RTP receiver receives a 1xx or 2xx-level 276 response code, it MUST use one of the 1xxx-level status codes defined 277 in Section 7.5 of this document. The RTP receiver may also receive a 278 4xx or 5xx-level response code (indicating receiver-side and server- 279 side errors, respectively). In that case, the RTP receiver MUST use 280 the response code as its status code. In other words, the 4xx and 281 5xx-level response codes have a higher priority than the 1xxx-level 282 status codes. The 5xx-level response codes have a higher priority 283 than the 4xx-level response codes and MUST be reported in the base 284 report in case the RTP receiver receives both 4xx and 5xx-level 285 response codes (in different RAMS-I messages) during the same RAMS 286 session. 288 4.2. Extensions 290 To improve the reporting scope, it may be desirable to define new 291 fields in the MA report block. Such fields MUST be encoded as TLV 292 elements as described below and sketched in Figure 2: 294 o Type: A single-octet identifier that defines the type of the 295 parameter represented in this TLV element. 297 o Length: A two-octet field that indicates the length (in octets) 298 of the TLV element excluding the Type and Length fields, and the 299 8-bit Reserved field between them. Note that this length does not 300 include any padding that is required for alignment. 302 o Value: Variable-size set of octets that contains the specific 303 value for the parameter. 305 In the extensions, the Reserved field SHALL be set to zero and 306 ignored. If a TLV element does not fall on a 32-bit boundary, the 307 last word MUST be padded to the boundary using further bits set to 308 zero. 310 In the MA report block, any vendor-neutral or private extension MUST 311 be placed after the base report. 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Type | Reserved | Length | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 : Value : 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 2: Structure of a TLV element 323 4.2.1. Vendor-Neutral Extensions 325 If the goal in defining new TLV elements is to extend the report 326 block in a vendor-neutral manner, they MUST be registered with IANA 327 through the guidelines provided in Section 7.4. 329 The current document defines several vendor-neutral extensions. 331 First, we present the TLV elements that can be used by any RTP-based 332 multicast application. 334 o RTP Seqnum of the First Multicast Packet (16 bits): TLV element 335 that specifies the RTP sequence number of the first multicast 336 packet received for the primary multicast stream. If the 337 multicast join was successful, this element MUST exist. If no 338 multicast packet has been received, this element SHALL NOT exist. 340 Type: 1 342 o SFGMP Join Time (32 bits): TLV element that denotes the greater 343 of zero or the time difference (in ms) between the instant SFGMP 344 Join message has been sent and the instant the first packet was 345 received in the multicast session. If the multicast join was 346 successful, this element MUST exist. If no multicast packet has 347 been received, this element SHALL NOT exist. 349 Type: 2 351 o Application Request-to-Multicast Delta Time (32 bits): Optional 352 TLV element that denotes the time difference (in ms) between the 353 instant the application became aware it would join a new multicast 354 session and the instant the first RTP packet was received from the 355 primary multicast stream. If no such packet has been received, 356 this element SHALL NOT exist. 358 Type: 3 360 o Application Request-to-Presentation Delta Time (32 bits): 361 Optional TLV element that denotes the time difference (in ms) 362 between the instant the application became aware it would join a 363 new multicast session and the instant the media is first 364 presented. If the RTP receiver cannot successfully present the 365 media, this element SHALL NOT exist. 367 Type: 4 369 We next present the TLV elements that can be used when the RTP 370 receiver supports and uses the RAMS method described in 371 [I-D.ietf-avt-rapid-acquisition-for-rtp]. However, if the RTP 372 receiver does not send a rapid acquisition request, the following TLV 373 elements MUST NOT exist in the MA report block. Some elements may or 374 may not exist depending on whether the RTP receiver receives any 375 packet from the unicast burst and/or the primary multicast stream or 376 not. These are explained below. 378 o Application Request-to-RAMS Request Delta Time (32 bits): 379 Optional TLV element that denotes the time difference (in ms) 380 between the instant the application became aware it would request 381 a rapid acquisition and the instant the rapid acquisition request 382 was actually sent by the application. 384 Type: 11 386 o RAMS Request-to-RAMS Information Delta Time (32 bits): Optional 387 TLV element that denotes the time difference (in ms) between the 388 instant the rapid acquisition request has been sent and the 389 instant the first RAMS Information message was received in the 390 unicast session. If no such message has been received, this 391 element SHALL NOT exist. 393 Type: 12 395 o RAMS Request-to-Burst Delta Time (32 bits): Optional TLV element 396 that denotes the time difference (in ms) between the instant the 397 rapid acquisition request has been sent and the instant the first 398 burst packet was received in the unicast session. If no burst 399 packet has been received, this element SHALL NOT exist. 401 Type: 13 403 o RAMS Request-to-Multicast Delta Time (32 bits): Optional TLV 404 element that denotes the time difference (in ms) between the 405 instant the rapid acquisition request has been sent and the 406 instant the first RTP packet was received from the primary 407 multicast stream. If no such packet has been received, this 408 element SHALL NOT exist. 410 Type: 14 412 o RAMS Request-to-Burst-Completion Delta Time (32 bits): Optional 413 TLV element that denotes the time difference (in ms) between the 414 instant the rapid acquisition request has been sent and the 415 instant the last burst packet was received in the unicast session. 416 If no burst packet has been received, this element SHALL NOT 417 exist. 419 Type: 15 421 o Number of Duplicate Packets (32 bits): Optional TLV element that 422 denotes the number of duplicate packets due to receiving the same 423 packet in both unicast and primary multicast RTP sessions. If no 424 RTP packet has been received from the primary multicast stream, 425 this element SHALL NOT exist. If no burst packet has been 426 received in the unicast session, the value of this element SHALL 427 be set to zero. 429 Type: 16 431 o Size of Burst-to-Multicast Gap (32 bits): Optional TLV element 432 that denotes the greater of zero or the difference between the 433 sequence number of the first multicast packet (received from the 434 primary multicast stream) and the sequence number of the last 435 burst packet minus 1 (considering the wrapping of the sequence 436 numbers). If no burst packet has been received in the unicast 437 session or no RTP packet has been received from the primary 438 multicast stream, this element SHALL NOT exist. 440 Type: 17 442 4.2.2. Private Extensions 444 It is desirable to allow vendors to use private extensions in TLV 445 format. For interoperability, such extensions MUST NOT collide with 446 each other. 448 A certain range of TLV Types is reserved for private extensions 449 (Refer to Section 7.4). IANA management for these extensions is 450 unnecessary and they are the responsibility of individual vendors. 452 The structure that MUST be used for the private extensions is 453 depicted in Figure 3. Here, the enterprise numbers are used from 454 http://www.iana.org/assignments/enterprise-numbers. This will ensure 455 the uniqueness of the private extensions and avoid any collision. 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Type | Reserved | Length | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Enterprise Number | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 : Value : 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Figure 3: Structure of a private extension 469 5. Session Description Protocol Signaling 471 A new parameter is defined for the MA report block to be used with 472 the Session Description Protocol (SDP) [RFC4566] using the Augmented 473 Backus-Naur Form (ABNF) [RFC5234]. It has the following syntax 474 within the 'rtcp-xr' attribute [RFC3611]: 476 multicast-acq-ext = "multicast-acq" 478 Figure 4 480 Refer to Section 5.1 of [RFC3611] for a detailed description and the 481 full syntax of the "rtcp-xr" attribute. The "multicast-acq-ext" 482 parameter is compatible with the definition of "format-ext" in the 483 "rtcp-xr" attribute. 485 6. Security Considerations 487 The security considerations of [RFC3611] apply in this document as 488 well. If desired, similar to other RTCP XR reports, the MA reports 489 MAY be protected by using Secure RTP (SRTP) and Secure RTP Control 490 Protocol (SRTCP) [RFC3711]. 492 Using the MA reports to provide feedback into the acquisition of the 493 multicast streams can introduce possible additional security 494 implications. If a forged or otherwise modified MA report is 495 received for an earlier acquisition attempt, invalid data may be used 496 as input in later rapid acquisition attempts. For example, 497 incorrectly small SFGMP join times may cause the unicast burst to be 498 too short, leading to gaps in sequence numbers in the approach 499 discussed in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Additionally, 500 forged reports may give the appearance that rapid acquisition is 501 performing correctly, when it is in fact failing, or vice versa. 503 7. IANA Considerations 505 The following contact information shall be used 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 New block types for RTCP XR are subject to IANA registration. For 517 general guidelines on IANA considerations for RTCP XR, refer to 518 [RFC3611]. 520 This document assigns the block type value 11 in the RTCP XR Block 521 Type Registry to "Multicast Acquisition Report Block." 523 7.2. RTCP XR SDP Parameter 525 This document registers the SDP [RFC4566] parameter 'multicast-acq' 526 for the 'rtcp-xr' attribute in the RTCP XR SDP Parameters Registry. 528 7.3. Multicast Acquisition Method Registry 530 This document creates a new IANA registry for the MA methods. The 531 registry is called the Multicast Acquisition Method Registry. This 532 registry is to be managed by the IANA according to the Specification 533 Required policy of [RFC5226]. 535 The length of the MA Method field is a single octet, allowing 256 536 values. The registry is initialized with the following entries: 538 MA Method Description Reference 539 --------- ------------------------------------ ------------- 540 0 Reserved [RFCXXXX] 541 1 Simple join (No explicit method) [RFCXXXX] 542 2 RAMS [I-D.ietf-avt-rapid-acquisition-for-rtp] 543 3-254 Specification Required 544 255 Reserved [RFCXXXX] 546 The MA Method values 0 and 255 are reserved for future use. 548 Any registration for an unassigned value MUST contain the following 549 information: 551 o Contact information of the one doing the registration, including 552 at least name, address, and email. 554 o A detailed description of how the MA method works. 556 7.4. Multicast Acquisition Report Block TLV Space Registry 558 This document creates a new IANA TLV space registry for the MA report 559 block extensions. The registry is called the Multicast Acquisition 560 Report Block TLV Space Registry. This registry is to be managed by 561 the IANA according to the Specification Required policy of [RFC5226]. 563 The length of the Type field in the TLV elements is a single octet, 564 allowing 256 values. The registry is initialized with the following 565 entries: 567 Type Description Reference 568 ---- -------------------------------------------------- ------------- 569 1 RTP Seqnum of the First Multicast Packet [RFCXXXX] 570 2 SFGMP Join Time [RFCXXXX] 571 3 Application Request-to-Multicast Delta Time [RFCXXXX] 572 4 Application Request-to-Presentation Delta Time [RFCXXXX] 573 11 Application Request-to-RAMS Request Delta Time [RFCXXXX] 574 12 RAMS Request-to-RAMS Information Delta Time [RFCXXXX] 575 13 RAMS Request-to-Burst Delta Time [RFCXXXX] 576 14 RAMS Request-to-Multicast Delta Time [RFCXXXX] 577 15 RAMS Request-to-Burst-Completion Delta Time [RFCXXXX] 578 16 Number of Duplicate Packets [RFCXXXX] 579 17 Size of Burst-to-Multicast Gap [RFCXXXX] 581 The Type values 0 and 255 are reserved for future use. The Type 582 values between (and including) 128 and 254 are reserved for private 583 extensions. 585 Any registration for an unassigned Type value MUST contain the 586 following information: 588 o Contact information of the one doing the registration, including 589 at least name, address, and email. 591 o A detailed description of what the new TLV element represents and 592 how it shall be interpreted. 594 7.5. Multicast Acquisition Status Code Space Registry 596 This document creates a new IANA TLV space registry for the status 597 codes. The registry is called the Multicast Acquisition Status Code 598 Space Registry. This registry is to be managed by the IANA according 599 to the Specification Required policy of [RFC5226]. 601 The length of the Status field is two octets, allowing 65536 codes. 602 However, the status codes have been registered to allow for an easier 603 classification. For example, the values between (and including) 1 604 and 1000 are primarily used by the MA method of simple join. The 605 values between (and including) 1001 and 2000 are used by the MA 606 method described in [I-D.ietf-avt-rapid-acquisition-for-rtp]. When 607 registering new status codes for the existing MA methods or newly 608 defined MA methods, a similar classification scheme SHOULD be 609 followed. 611 The Status code 65536 is reserved for future use. The registry is 612 initialized with the following entries: 614 Code Description Reference 615 ----- -------------------------------------------------- ------------- 616 0 A private status code is included in the message [RFCXXXX] 618 1 Multicast join was successful [RFCXXXX] 619 2 Multicast join has failed [RFCXXXX] 620 3 A presentation error has occurred [RFCXXXX] 621 4 An unspecified RR internal error has occurred [RFCXXXX] 623 1001 RAMS has been successfully completed [RFCXXXX] 624 1002 No RAMS-R message has been sent [RFCXXXX] 625 1003 Invalid RAMS-I message syntax [RFCXXXX] 626 1004 RAMS-I message has timed out [RFCXXXX] 627 1005 RAMS unicast burst has timed out [RFCXXXX] 628 1006 An unspecified RR internal error has occurred 629 during RAMS [RFCXXXX] 630 1007 A presentation error has occurred during RAMS [RFCXXXX] 632 Any registration for an unassigned Status code MUST contain the 633 following information: 635 o Contact information of the one doing the registration, including 636 at least name, address, and email. 638 o A detailed description of what the new Status code describes and 639 how it shall be interpreted. 641 8. Acknowledgments 643 This specification has greatly benefited from discussions with 644 Michael Lague, Dong Hsu, Carol Iturralde, Xuan Zhong, Dave Oran, Tom 645 Van Caenegem and many others. The authors would like to thank each 646 of these individuals for their contributions. 648 9. References 650 9.1. Normative References 652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 653 Requirement Levels", BCP 14, RFC 2119, March 1997. 655 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 656 Jacobson, "RTP: A Transport Protocol for Real-Time 657 Applications", STD 64, RFC 3550, July 2003. 659 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 660 Protocol Extended Reports (RTCP XR)", RFC 3611, 661 November 2003. 663 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 664 Thyagarajan, "Internet Group Management Protocol, Version 665 3", RFC 3376, October 2002. 667 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 668 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 670 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 671 Group Management Protocol Version 3 (IGMPv3) and Multicast 672 Listener Discovery Protocol Version 2 (MLDv2) for Source- 673 Specific Multicast", RFC 4604, August 2006. 675 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 676 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 677 July 2006. 679 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 680 Description Protocol", RFC 4566, July 2006. 682 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 683 Specifications: ABNF", STD 68, RFC 5234, January 2008. 685 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 686 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 687 May 2008. 689 9.2. Informative References 691 [I-D.ietf-avt-rapid-acquisition-for-rtp] 692 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 693 Based Rapid Acquisition of Multicast RTP Sessions", 694 draft-ietf-avt-rapid-acquisition-for-rtp-17 (work in 695 progress), November 2010. 697 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 698 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 699 RFC 3711, March 2004. 701 Authors' Addresses 703 Ali Begen 704 Cisco 705 181 Bay Street 706 Toronto, ON M5J 2T3 707 Canada 709 Email: abegen@cisco.com 711 Eric Friedrich 712 Cisco 713 1414 Massachusetts Ave. 714 Boxborough, MA 01719 715 USA 717 Email: efriedri@cisco.com