idnits 2.17.1 draft-ietf-avtext-multicast-acq-rtcp-xr-02.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 (April 6, 2011) is 4768 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 454, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 649, but not defined ** 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 (~~), 3 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: October 8, 2011 April 6, 2011 7 Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) 8 Extended Reports (XRs) 9 draft-ietf-avtext-multicast-acq-rtcp-xr-02 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 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 can (or be compelled to) 21 do a 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 8, 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 . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . 18 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 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", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 3. Definitions 142 This document uses the following acronyms and definitions from 143 [I-D.ietf-avt-rapid-acquisition-for-rtp]: 145 (Primary) Multicast Session: The multicast session to which RTP 146 receivers can join at a random point in time. 148 Primary Multicast RTP Session: The multicast RTP session an RTP 149 receiver is interested in acquiring. 151 Source Filtering Group Management Protocol (SFGMP): Following the 152 definition in [RFC4604], SFGMP refers to the Internet Group 153 Management Protocol (IGMP) version 3 [RFC3376] and the Multicast 154 Listener Discovery Protocol (MLD) version 2 [RFC3810] in the IPv4 and 155 IPv6 networks, respectively. However, the report block type 156 introduced in this document does not depend on a specific version of 157 either of these group management protocols. In the remainder of this 158 document, SFGMP will refer to any group management protocol that has 159 Join and Leave functionalities. 161 Retransmission (Burst) Packet: An RTP packet that is formatted as 162 defined in Section 4 of [RFC4588]. 164 Reference Information: The set of certain media content and metadata 165 information that is sufficient for an RTP receiver to start usefully 166 consuming a media stream. The meaning, format and size of this 167 information are specific to the application and are out of scope of 168 this document. 170 (Unicast) Burst (Stream): A unicast stream of RTP retransmission 171 packets that enable an RTP receiver to rapidly acquire the Reference 172 Information associated with a primary multicast stream. Each burst 173 stream is identified by its Synchronization Source (SSRC) identifier 174 that is unique in the primary multicast RTP session. 176 Retransmission Server (RS): The RTP/RTCP endpoint that can generate 177 the retransmission packets and the burst streams. The RS may also 178 generate other non-retransmission packets to aid the rapid 179 acquisition process. 181 4. Multicast Acquisition (MA) Report Block 183 This section defines the format of the MA report block. The base 184 report is payload-independent. An extension mechanism is provided 185 where further optional payload-independent and payload-specific 186 information can be included in the report as desired. 188 The optional extensions that are defined in this document are 189 primarily developed for the method presented in 190 [I-D.ietf-avt-rapid-acquisition-for-rtp]. Other methods that provide 191 rapid acquisition can define their own extensions to be used in the 192 MA report block. 194 The packet format for the RTCP XR is defined in Section 2 of 195 [RFC3611]. Each XR packet has a fixed-length field for version, 196 padding, reserved bits, payload type (PT), length, SSRC of packet 197 sender as well as a variable-length field for report blocks. In the 198 XR packets, the PT field is set to XR (207). 200 It is better to send the MA report block after all the necessary 201 information is collected and computed. Partial reporting is 202 generally not useful as it cannot give the full picture of the 203 multicast acquisition, and causes additional complexity in terms of 204 report block matching and correlation. The MA report block is only 205 sent as a part of an RTCP compound packet, and it is sent in the 206 primary multicast session. 208 The need for reliability of the MA report block is not any greater 209 than other report blocks or types. If desired, the report block 210 could be repeated for redundancy purposes while respecting to the 211 RTCP scheduling algorithms. 213 4.1. Base Report 215 The base report format is shown in Figure 1. 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | BT=11 | MA Method | Block Length | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | SSRC of the Primary Multicast Stream | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Status | Rsvd. | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Figure 1: Base report format for the MA report block 229 o BT (8 bits): Mandatory field that denotes the type for this block 230 format. The MA report block is identified by the constant 11. 232 o MA Method (8 bits): Mandatory field that denotes the type of the 233 MA method (e.g., simple join, RAMS, etc.). See Section 7.3 for 234 the values registered with IANA. 236 o Block Length (16 bits): The length of this report block, 237 including the header, in 32-bit words minus one. 239 o SSRC of the Primary Multicast Stream (32 bits): Mandatory field 240 that denotes the SSRC of the primary multicast stream. 242 o Status (16 bits): Mandatory field that denotes the status code 243 for the MA operation. 245 This document defines several status codes and registers them with 246 IANA in Section 7.5. If a new vendor-neutral status code will be 247 defined, it MUST be registered with IANA through the guidelines 248 specified in Section 7.5. If the new status code is intended to 249 be used privately by a vendor, there is no need for IANA 250 management. Section 4.2.2 defines how a vendor defines and uses 251 private extensions to convey its messages. To indicate a private 252 extension, the RTP receiver MUST set the Status field to zero. 254 o Rsvd. (16 bits): The RTP receiver MUST set this bit to zero. The 255 recipient MUST ignore this bit when received. 257 If the multicast join was successful meaning that at least one 258 multicast packet has been received, some additional information MUST 259 be appended to the base report as will be described in Section 4.2.1. 261 4.1.1. Status Code Rules for New MA Methods 263 Different MA methods usually use different status codes, although 264 some status codes (e.g., a code indicating that multicast join has 265 failed) can be common among multiple MA methods. The status code 266 reported in the base report MUST always be within the scope of the 267 particular MA method specified in the MA Method field. 269 In certain MA methods, the RTP receiver can generate a status code 270 for its multicast acquisition attempt, or can be told by another 271 network element or RTP endpoint what the current status is via a 272 response code. In such cases, the RTP receiver MAY report the value 273 of the received response code as its status code if the response code 274 has a higher priority. Each MA method needs to outline the rules 275 pertaining to its response and status codes so that RTP receiver 276 implementations can determine what to report in any given scenario. 278 4.1.2. Status Code Rules for the RAMS Method 280 In this section, we provide the status code rules for the RAMS method 281 described in [I-D.ietf-avt-rapid-acquisition-for-rtp]. 283 Section 11.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] defines 284 several response codes. The 1xx and 2xx-level response codes are 285 informational and success response codes, respectively. If the RTP 286 receiver receives a 1xx or 2xx-level response code, then the RTP 287 receiver MUST use one of the 1xxx-level status codes defined in 288 Section 7.5 of this document. If the RTP receiver receives a 4xx or 289 5xx-level response code (indicating receiver-side and server-side 290 errors, respectively), then the RTP receiver MUST use the response 291 code as its status code. In other words, the 4xx and 5xx-level 292 response codes have a higher priority than the 1xxx-level status 293 codes. 295 4.2. Extensions 297 To improve the reporting scope, it might be desirable to define new 298 fields in the MA report block. Such fields are to be encoded as TLV 299 elements as described below and sketched in Figure 2: 301 o Type: A single-octet identifier that defines the type of the 302 parameter represented in this TLV element. 304 o Length: A two-octet field that indicates the length (in octets) 305 of the TLV element excluding the Type and Length fields, and the 306 8-bit Reserved field between them. Note that this length does not 307 include any padding that is needed for alignment. 309 o Value: Variable-size set of octets that contains the specific 310 value for the parameter. 312 In the extensions, the Reserved field MUST be set to zero and ignored 313 on reception. If a TLV element does not fall on a 32-bit boundary, 314 the last word MUST be padded to the boundary using further bits set 315 to zero. 317 In the MA report block, the RTP receiver MUST place any vendor- 318 neutral or private extension after the base report. 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type | Reserved | Length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 : Value : 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Figure 2: Structure of a TLV element 330 4.2.1. Vendor-Neutral Extensions 332 If the goal in defining new TLV elements is to extend the report 333 block in a vendor-neutral manner, they need to be registered with 334 IANA through the guidelines provided in Section 7.4. 336 The current document defines several vendor-neutral extensions. 337 First, we present the TLV elements that can be used by any RTP-based 338 multicast application. 340 o RTP Seqnum of the First Multicast Packet (16 bits): TLV element 341 that specifies the RTP sequence number of the first multicast 342 packet received for the primary multicast stream. If the 343 multicast join was successful, this element MUST be included. If 344 no multicast packet has been received, this element MUST NOT exist 345 in the report block. 347 Type: 1 349 o SFGMP Join Time (32 bits): TLV element that denotes the greater 350 of zero or the time difference (in ms) between the instant SFGMP 351 Join message has been sent and the instant the first packet was 352 received in the multicast session. If the multicast join was 353 successful, this element MUST be included. If no multicast packet 354 has been received, this element MUST NOT exist in the report 355 block. 357 Type: 2 359 o Application Request-to-Multicast Delta Time (32 bits): Optional 360 TLV element that denotes the time difference (in ms) between the 361 instant the application became aware it would join a new multicast 362 session and the instant the first RTP packet was received from the 363 primary multicast stream. If no such packet has been received, 364 this element MUST NOT exist in the report block. 366 Type: 3 368 o Application Request-to-Presentation Delta Time (32 bits): 369 Optional TLV element that denotes the time difference (in ms) 370 between the instant the application became aware it would join a 371 new multicast session and the instant the media is first 372 presented. If the RTP receiver cannot successfully present the 373 media, this element MUST NOT exist in the report block. 375 Type: 4 377 We next present the TLV elements that can be used when the RTP 378 receiver supports and uses the RAMS method described in 379 [I-D.ietf-avt-rapid-acquisition-for-rtp]. However, if the RTP 380 receiver does not send a rapid acquisition request, the following TLV 381 elements MUST NOT exist in the MA report block. Some elements may or 382 may not exist depending on whether the RTP receiver receives any 383 packet from the unicast burst and/or the primary multicast stream or 384 not. These are explained below. 386 o Application Request-to-RAMS Request Delta Time (32 bits): 387 Optional TLV element that denotes the time difference (in ms) 388 between the instant the application became aware it would request 389 a rapid acquisition and the instant the rapid acquisition request 390 was actually sent by the application. 392 Type: 11 394 o RAMS Request-to-RAMS Information Delta Time (32 bits): Optional 395 TLV element that denotes the time difference (in ms) between the 396 instant the rapid acquisition request has been sent and the 397 instant the first RAMS Information message was received in the 398 unicast session. If no such message has been received, this 399 element MUST NOT exist in the report block. 401 Type: 12 403 o RAMS Request-to-Burst Delta Time (32 bits): Optional TLV element 404 that denotes the time difference (in ms) between the instant the 405 rapid acquisition request has been sent and the instant the first 406 burst packet was received in the unicast session. If no burst 407 packet has been received, this element MUST NOT exist in the 408 report block. 410 Type: 13 412 o RAMS Request-to-Multicast Delta Time (32 bits): Optional TLV 413 element that denotes the time difference (in ms) between the 414 instant the rapid acquisition request has been sent and the 415 instant the first RTP packet was received from the primary 416 multicast stream. If no such packet has been received, this 417 element MUST NOT exist in the report block. 419 Type: 14 421 o RAMS Request-to-Burst-Completion Delta Time (32 bits): Optional 422 TLV element that denotes the time difference (in ms) between the 423 instant the rapid acquisition request has been sent and the 424 instant the last burst packet was received in the unicast session. 425 If no burst packet has been received, this element MUST NOT exist 426 in the report block. 428 Type: 15 430 o Number of Duplicate Packets (32 bits): Optional TLV element that 431 denotes the number of duplicate packets due to receiving the same 432 packet in both unicast and primary multicast RTP sessions. If no 433 RTP packet has been received from the primary multicast stream, 434 this element MUST NOT exist. If no burst packet has been received 435 in the unicast session, the value of this element MUST be set to 436 zero. 438 Type: 16 440 o Size of Burst-to-Multicast Gap (32 bits): Optional TLV element 441 that denotes the greater of zero or the difference between the 442 sequence number of the first multicast packet (received from the 443 primary multicast stream) and the sequence number of the last 444 burst packet minus 1 (considering the wrapping of the sequence 445 numbers). If no burst packet has been received in the unicast 446 session or no RTP packet has been received from the primary 447 multicast stream, this element MUST NOT exist in the report block. 449 Type: 17 451 4.2.2. Private Extensions 453 It is desirable to allow vendors to use private extensions in TLV 454 format. The range of [128-254] of TLV Types is reserved for private 455 extensions. IANA management for these extensions is unnecessary and 456 they are the responsibility of individual vendors. 458 Implementations use the structure depicted in Figure 3 for the 459 private extensions. Here, the private enterprise numbers are used 460 from http://www.iana.org/assignments/enterprise-numbers. This will 461 ensure the uniqueness of the private extensions and avoid any 462 collision. 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Type | Reserved | Length | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Enterprise Number | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 : Value : 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 Figure 3: Structure of a private extension 476 5. Session Description Protocol Signaling 478 A new unilateral parameter is defined for the MA report block to be 479 used with the Session Description Protocol (SDP) [RFC4566] using the 480 Augmented Backus-Naur Form (ABNF) [RFC5234]. It has the following 481 syntax within the 'rtcp-xr' attribute [RFC3611]: 483 multicast-acq-ext = "multicast-acq" 485 Figure 4 487 Refer to Section 5.1 of [RFC3611] for a detailed description and the 488 full syntax of the "rtcp-xr" attribute. The "multicast-acq-ext" 489 parameter is compatible with the definition of "format-ext" in the 490 "rtcp-xr" attribute. 492 6. Security Considerations 494 The security considerations of [RFC3611] apply in this document as 495 well. 497 The information contained in MA reports could be stolen as any other 498 RTCP reports if proper protection mechanism(s) are not in place. If 499 desired, similar to other RTCP XR reports, the MA reports MAY be 500 protected by using Secure RTP (SRTP) and Secure RTP Control Protocol 501 (SRTCP) [RFC3711]. 503 Malicious sniffing or otherwise obtaining MA report blocks can reveal 504 performance characteristics of the RTP service and underlying 505 network. This information is mostly available to an observer with 506 the ability to capture RTP and RTCP session traffic. The contents 507 and value of any private extensions need to be studied when 508 considering the necessity to secure the MA reports since application- 509 level performance data might be present that is not otherwise 510 available to an attacker as with the required fields and vendor- 511 neutral extensions. 513 Using the MA reports to provide feedback into the acquisition of the 514 multicast streams can introduce possible additional security 515 implications. If a forged or otherwise modified MA report is 516 received for an earlier acquisition attempt, invalid data can be used 517 as input in later rapid acquisition attempts. For example, 518 incorrectly small SFGMP join times could cause the unicast burst to 519 be too short, leading to gaps in sequence numbers in the approach 520 discussed in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Additionally, 521 forged reports could give the appearance that rapid acquisition is 522 performing correctly, when it is in fact failing, or vice versa. 523 However, the MA reports are believed not to introduce any additional 524 risks from a confidentiality viewpoint. 526 7. IANA Considerations 528 The following contact information is provided for all registrations 529 in this document: 531 Ali Begen 532 abegen@cisco.com 534 Note to the RFC Editor: In the following, please replace "XXXX" with 535 the number of this document prior to publication as an RFC. 537 7.1. RTCP XR Block Type 539 Type value 11 has been pre-registered with IANA for the "Multicast 540 Acquisition Report Block" in the RTCP XR Block Type Registry. 542 7.2. RTCP XR SDP Parameter 544 This document registers the SDP [RFC4566] parameter 'multicast-acq' 545 for the 'rtcp-xr' attribute in the RTCP XR SDP Parameters Registry. 547 7.3. Multicast Acquisition Method Registry 549 This document creates a new IANA registry for the MA methods. The 550 registry is called the Multicast Acquisition Method Registry. This 551 registry is to be managed by the IANA according to the Specification 552 Required policy of [RFC5226]. 554 The length of the MA Method field is a single octet, allowing 256 555 values. The registry is initialized with the following entries: 557 MA Method Description Reference 558 --------- ------------------------------------ ------------- 559 0 Reserved [RFCXXXX] 560 1 Simple join (No explicit method) [RFCXXXX] 561 2 RAMS [I-D.ietf-avt-rapid-acquisition-for-rtp] 562 3-254 Specification Required 563 255 Reserved [RFCXXXX] 565 The MA Method values 0 and 255 are reserved for future use. 567 Any registration for an unassigned value needs to contain the 568 following information: 570 o Contact information of the one doing the registration, including 571 at least name, address, and email. 573 o A detailed description of how the MA method works. 575 7.4. Multicast Acquisition Report Block TLV Space Registry 577 This document creates a new IANA TLV space registry for the MA report 578 block extensions. The registry is called the Multicast Acquisition 579 Report Block TLV Space Registry. This registry is to be managed by 580 the IANA according to the Specification Required policy of [RFC5226]. 582 The length of the Type field in the TLV elements is a single octet, 583 allowing 256 values. The registry is initialized with the following 584 entries: 586 Type Description Reference 587 ---- -------------------------------------------------- ------------- 588 1 RTP Seqnum of the First Multicast Packet [RFCXXXX] 589 2 SFGMP Join Time [RFCXXXX] 590 3 Application Request-to-Multicast Delta Time [RFCXXXX] 591 4 Application Request-to-Presentation Delta Time [RFCXXXX] 592 11 Application Request-to-RAMS Request Delta Time [RFCXXXX] 593 12 RAMS Request-to-RAMS Information Delta Time [RFCXXXX] 594 13 RAMS Request-to-Burst Delta Time [RFCXXXX] 595 14 RAMS Request-to-Multicast Delta Time [RFCXXXX] 596 15 RAMS Request-to-Burst-Completion Delta Time [RFCXXXX] 597 16 Number of Duplicate Packets [RFCXXXX] 598 17 Size of Burst-to-Multicast Gap [RFCXXXX] 600 The Type values 0 and 255 are reserved for future use. The Type 601 values between (and including) 128 and 254 are reserved for private 602 extensions. 604 Any registration for an unassigned Type value needs to contain the 605 following information: 607 o Contact information of the one doing the registration, including 608 at least name, address, and email. 610 o A detailed description of what the new TLV element represents and 611 how it is interpreted. 613 7.5. Multicast Acquisition Status Code Space Registry 615 This document creates a new IANA TLV space registry for the status 616 codes. The registry is called the Multicast Acquisition Status Code 617 Space Registry. This registry is to be managed by the IANA according 618 to the Specification Required policy of [RFC5226]. 620 The length of the Status field is two octets, allowing 65536 codes. 621 However, the status codes have been registered to allow for an easier 622 classification. For example, the values between (and including) 1 623 and 1000 are primarily used by the MA method of simple join. The 624 values between (and including) 1001 and 2000 are used by the MA 625 method described in [I-D.ietf-avt-rapid-acquisition-for-rtp]. When 626 registering new status codes for the existing MA methods or newly 627 defined MA methods, a similar classification scheme is encouraged to 628 be followed. 630 The Status code 65535 is reserved for future use. The registry is 631 initialized with the following entries: 633 Code Description Reference 634 ----- -------------------------------------------------- ------------- 635 0 A private status code is included in the message [RFCXXXX] 637 1 Multicast join was successful [RFCXXXX] 638 2 Multicast join has failed [RFCXXXX] 639 3 A presentation error has occurred [RFCXXXX] 640 4 An unspecified RR internal error has occurred [RFCXXXX] 642 1001 RAMS has been successfully completed [RFCXXXX] 643 1002 No RAMS-R message has been sent [RFCXXXX] 644 1003 Invalid RAMS-I message syntax [RFCXXXX] 645 1004 RAMS-I message has timed out [RFCXXXX] 646 1005 RAMS unicast burst has timed out [RFCXXXX] 647 1006 An unspecified RR internal error has occurred 648 during RAMS [RFCXXXX] 649 1007 A presentation error has occurred during RAMS [RFCXXXX] 651 Any registration for an unassigned Status code needs to contain the 652 following information: 654 o Contact information of the one doing the registration, including 655 at least name, address, and email. 657 o A detailed description of what the new Status code describes and 658 how it is interpreted. 660 8. Acknowledgments 662 This specification has greatly benefited from discussions with 663 Michael Lague, Dong Hsu, Carol Iturralde, Xuan Zhong, Dave Oran, Tom 664 Van Caenegem and many others. The authors would like to thank each 665 of these individuals for their contributions. 667 9. References 669 9.1. Normative References 671 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 672 Requirement Levels", BCP 14, RFC 2119, March 1997. 674 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 675 Jacobson, "RTP: A Transport Protocol for Real-Time 676 Applications", STD 64, RFC 3550, July 2003. 678 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 679 Protocol Extended Reports (RTCP XR)", RFC 3611, 680 November 2003. 682 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 683 Thyagarajan, "Internet Group Management Protocol, Version 684 3", RFC 3376, October 2002. 686 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 687 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 689 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 690 Group Management Protocol Version 3 (IGMPv3) and Multicast 691 Listener Discovery Protocol Version 2 (MLDv2) for Source- 692 Specific Multicast", RFC 4604, August 2006. 694 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 695 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 696 July 2006. 698 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 699 Description Protocol", RFC 4566, July 2006. 701 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 702 Specifications: ABNF", STD 68, RFC 5234, January 2008. 704 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 705 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 706 RFC 3711, March 2004. 708 9.2. Informative References 710 [I-D.ietf-avt-rapid-acquisition-for-rtp] 711 Steeg, B., Begen, A., Caenegem, T., and Z. Vax, "Unicast- 712 Based Rapid Acquisition of Multicast RTP Sessions", 713 draft-ietf-avt-rapid-acquisition-for-rtp-17 (work in 714 progress), November 2010. 716 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 717 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 718 May 2008. 720 Authors' Addresses 722 Ali Begen 723 Cisco 724 181 Bay Street 725 Toronto, ON M5J 2T3 726 Canada 728 Email: abegen@cisco.com 730 Eric Friedrich 731 Cisco 732 1414 Massachusetts Ave. 733 Boxborough, MA 01719 734 USA 736 Email: efriedri@cisco.com