idnits 2.17.1 draft-friedman-avt-rtcp-report-extns-02.txt: -(101): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(221): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(230): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(245): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(347): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(390): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(399): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(439): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(446): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(509): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(535): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(638): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(640): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(707): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(710): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(722): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 25 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: run length: 14 bits A value between 1 and 16,383. The value MUST not be zero (zeroes in both the run type and run length fields would make the chunk a terminating null chunk). Run lengths of 15 or less MAY be described with a run length chunk despite the fact that they could also be described as part of a bit vector chunk. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (28 February 2002) is 8092 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) == Unused Reference: '2' is defined on line 673, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 683, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2028 (ref. '5') (Obsoleted by RFC 9281) ** Obsolete normative reference: RFC 1700 (ref. '6') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1889 (ref. '7') (Obsoleted by RFC 3550) -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 28 February 2002 3 Internet Engineering Task Force Expires: 28 August 2002 4 Audio/Video Transport Working Group 6 Timur Friedman, LiP6 7 Ramon Caceres, ShieldIP 8 Kevin Almeroth, UCSB 9 Kamil Sarac, UCSB 11 RTCP Reporting Extensions 13 draft-friedman-avt-rtcp-report-extns-02.txt 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright Notice 38 Copyright (C) The Internet Society (2002). All Rights Reserved. 40 Abstract 42 This document defines the XR (extended report) RTCP packet type, for 43 carrying information beyond that which is contained in the SR (sender 44 report) and RR (receiver report) packets that are defined in the RTP 45 specification. Within their "reception report blocks", SR and RR 46 packets are limited to reporting six specified statistics on any 47 given data source. This document describes how other information can 48 be reported in "extended report blocks" that are contained within an 49 XR packet. Some specific block formats are provided here. For other 50 formats that may be defined as the need arises, this document 51 specifies a simple framework that they must adhere to. 53 1. Introduction 55 This document defines the XR (extended report) RTCP packet type for 56 RTCP, the control portion of RTP [7]. The definition consists of 57 three parts. First, Section 2 of this document defines a general 58 packet framework capable of including a number of different "extended 59 report blocks." Second, Section 3 defines the general format for 60 such blocks. Third, Section 4 defines a number of such blocks. 62 The extended report blocks convey information beyond that which is 63 already contained in the reception report blocks of RTCP's SR or RR 64 packets. For example, while a reception report block contains an 65 average loss rate field, an application might opt to use an extended 66 report block that details exactly which packets were received and 67 which were lost. 69 The framework for these blocks is minimal: only a type field and a 70 length field are required. The purpose is to maintain flexibility 71 and to keep overhead low. While some specific block formats are 72 provided here, others may be defined as the need arises. 74 1.1 Terminology 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 [3] and 79 indicate requirement levels for compliant RTP implementations. 81 2. XR Packet Format 83 The XR packet consists of a header of two 32-bit words, followed by a 84 number, possibly zero, of extended report blocks. This packet format 85 has been deployed, as described in [4] and [1], as an RTCP APP 86 (application-specific) packet. The XR packet header is identical to 87 that of the APP packet, with the name field removed and the subtype 88 field cleared. 90 0 1 2 3 91 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 92 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 93 |V=2|P|reserved | PT=XP=205 | length | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 | SSRC/CSRC | 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 : report blocks : 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 100 version (V): 2 bits 101 Identifies the version of RTP. This specification applies to RTP ver� 102 sion two (2). 104 padding (P): 1 bit 105 If the padding bit is set, this individual RTCP packet contains some 106 additional padding octets at the end that are not part of the control 107 information but are included in the length field. The last octet of 108 the padding is a count of how many padding octets should be ignored, 109 including itself (it will be a multiple of four). A full description 110 of padding in RTCP packets may be found in the RTP specification. 112 reserved: 5 bits 113 This field is reserved for future definition. The bits in this field 114 MUST be set to zero unless otherwise defined. 116 packet type (PT): 8 bits 117 Contains the constant 205 to identify this as an RTCP XR packet. 118 This is a proposed value, pending assignment of a number by the 119 Internet Assigned Numbers Authority [6]. 121 length: 16 bits 122 The length of this RTCP packet in 32-bit words minus one, including 123 the header and any padding. (The offset of one makes zero a valid 124 length and avoids a possible infinite loop in scanning a compound 125 RTCP packet, while counting 32-bit words avoids a validity check for 126 a multiple of 4.) 128 SSRC: 32 bits 129 The synchronization source identifier for the originator of this XR 130 packet. 132 report blocks: variable length. 133 Zero or more extended report blocks. The blocks MUST be a multiple 134 of 32 bits long. They MAY be zero bits long. 136 3. Extended Report Block Framework 138 Extended report blocks MUST be stacked, one after the other, at the 139 end of an XR packet. An individual block's length MUST be a multiple 140 of 4 octets. The XR header's length field MUST describe the total 141 length of the packet, including these extended report blocks. 143 Each block has block type and length fields that facilitate parsing. 144 A receiving application can demultiplex the blocks based upon their 145 type, and can use the length information to locate each successive 146 block, even in the presence of block types it does not recognize. 148 An extended report block has the following format: 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | BT | type-specific | length | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 : type-specific data : 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 block type (BT): 8 bits 159 Identifies the specific block format. 161 type-specific: 8 bits 162 The use of these bits is defined by the particular block type. 164 length: 16 bits 165 The length of this report block in 32-bit words minus one, including 166 the header. 168 type-specific data: variable length 169 This MUST be a multiple of 32 bits long. It MAY be zero bits long. 171 4. Specific Extended Report Blocks 173 This section defines five extended report blocks: an experimental 174 block type and block types for losses, duplicates, timestamps, and 175 detailed statistics. Other block types MAY be defined in the future. 176 Any such definition MUST include block type numbers assigned by the 177 Internet Assigned Numbers Authority [6]. 179 4.1 Experimental Block 180 This type MUST be used for extended report block types that have not 181 been standardized. In addition to the standard type and length 182 fields, it includes a 32 bit name field that serves to distinguish 183 one experimental block type from another. 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | BT=0 | app-specific | length | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | name (ASCII) | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 : application-specific data : 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 block type (BT): 8 bits 196 Block type 0 identifies this as an experimental block. 198 app-specific: 8 bits 199 The use of these bits is defined by the application that uses this 200 block. 202 length: 16 bits 203 The length of this report block in 32-bit words minus one, including 204 the header. 206 name: 4 octets 207 A name chosen by the person definining the experimental block to be 208 unique with respect to other experimental blocks the application 209 might receive. 211 application-specific data: variable length. 212 This MUST be a multiple of 32 bits long. It MAY be zero bits long. 214 4.2 Loss RLE Block 216 With this block type, a boolean trace of lost and received packets 217 can be conveyed in compressed form using run length encoding. This 218 block type has been deployed on the internet, as part of an RTCP APP 219 (application-specific) packet, as described in [4] and [1]. 221 Caution SHOULD be used in sending such blocks because, even with com� 222 pression, they can easily consume bandwidth out of proportion with 223 normal RTCP packets. 225 Each block reports on a single source, identified by its SSRC. The 226 receiver that is supplying the report is identified in the header of 227 the RTCP packet. 229 The beginning and ending sequence numbers for the trace are specified 230 in the block, the ending sequence number being the last sequence num� 231 ber in the trace plus one. The last sequence number in the trace MAY 232 or may not be the sequence number reported on accompanying SR or RR 233 packets, depending on the needs of the application. 235 The encoding itself consists of a series of 16 bit chunks. Each 236 chunk either specifies a run length or a bit vector, or, if the trace 237 otherwise encodes into an odd number of chunks, MUST be a terminating 238 null chunk used to round out the block to a 32 bit word boundary. 240 The mapping from a sequence of lost and received packets into a 241 sequence of chunks is not unique and is left to the application. A 242 run length chunk can describe runs of between 1 and 16,383 packet 243 losses or receipts whereas a bit vector chunk can describe a sequence 244 of 15 packet losses and receipts. It is RECOMMENDED that the 245 description of run lengths of 14 or shorter be subsumed into bit vec� 246 tor chunks, for purposes of brevity. 248 A bit vector chunk MAY purport to contain information on packets at 249 or beyond the ending sequence number. Any such purported information 250 MUST be ignored. 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | BT=17 | rsvd. | T | block length | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | SSRC of source | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | begin_seq | end_seq | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | chunk 1 | chunk 2 | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 : : 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | chunk n-1 | chunk n | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 block type (BT): 8 bits 269 A Loss RLE block is identified by the constant 17 = 0x11. 271 rsvd.: 4 bits 272 This field is reserved for future definition. The bits in this field 273 MUST be set to zero unless otherwise defined. 275 thinning (T): 4 bits 276 The amount of thinning performed on the sequence space. Only those 277 packets with sequence numbers 0 mod 2^T are reported on by this 278 block. A value of 0 indicates that there is no thinning, and all 279 packets are reported on. The maximum thinning is one packet in every 280 32,768 (amounting to two packets within each 16-bit sequence space). 282 length: 16 bits 283 The length of this report block in 32-bit words minus one, including 284 the header. 286 begin_seq: 16 bits 287 The first sequence number that this block reports on. 289 end_seq: 16 bits 290 The last sequence number that this block reports on plus one. 292 chunk i: 16 bits 293 There are three chunk types: run length, bit vector, and terminating 294 null. If the chunk is all zeroes then it is a terminating null 295 chunk. Otherwise, the leftmost bit of the chunk determines its type: 296 0 for run length and 1 for bit vector. 298 4.2.1 Run-Length Chunk 300 0 1 301 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 |C|R| run length | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 chunk type (C): 1 bit 307 A zero identifies this as a runlength chunk. 309 run type (R): 1 bit 310 Zero indicates a run of losses. One indicates a run of received 311 packets. 313 run length: 14 bits 314 A value between 1 and 16,383. The value MUST not be zero (zeroes in 315 both the run type and run length fields would make the chunk a 316 terminating null chunk). Run lengths of 15 or less MAY be described 317 with a run length chunk despite the fact that they could also be 318 described as part of a bit vector chunk. 320 4.2.2 Bit Vector Chunk 322 0 1 323 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 |C| bit vector | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 chunk type (C): 1 bit 329 A one identifies this as a bit vector chunk. 331 bit vector: 15 bits 332 In the bit vector, as in the run length chunk, a zero indicates a 333 loss and a one indicates a received packet. 335 4.2.3 Terminating Null Chunk 337 This chunk is all zeroes. 339 0 1 340 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 4.3 Duplicate RLE Block 347 This block is identical in format to the Loss RLE Block type but car� 348 ries information about individual or runs of duplicate packets. A 349 zero indicates the presence of duplicate packets for a given sequence 350 number, whereas a one indicates that no duplicates were received. 351 Note that a packet loss is encoded as a one in this case. 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | BT=33 | reserved | length | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | SSRC of source | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | begin_seq | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | end_seq | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | chunk 1 | chunk 2 | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 : : 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | chunk n-1 | chunk n | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 block type (BT): 8 bits 372 A Duplicate RLE block is identified by the constant 33 = 0x21. 374 reserved: 8 bits 375 This field is reserved for future definition All of the bits in this 376 field MUST be set to zero unless otherwise defined. 378 length: 16 bits 379 The length of this report block in 32-bit words minus one, including 380 the header. 382 begin_seq: 32 bits 383 The first sequence number that this block reports on. 385 end_seq: 32 bits 386 The last sequence number that this block reports on plus one. 388 chunk i: 16 bits 389 There are three chunk types: run length, bit vector, and terminating 390 null. All zeroes indicates a terminating null. Otherwise, the left� 391 most bit of the chunk determines its type: 0 for run length and 1 for 392 bit vector. See the descriptions of these block types in the section 393 on the Loss RLE Block, above, for details. 395 4.4 Timestamp Report Block 397 This block carries RTCP-style timestamps for each packet in the range 398 of packet sequence numbers. A similar caution, but more emphatic, is 399 made for timestamp report blocks as was made for Loss RLE Block pack� 400 ets. For each packet in the sequence number range, a 32 bit value 401 MUST be recorded and sent. This could easily consume significant 402 bandwidth. Care SHOULD be taken in the size of the sequence space 403 over which to monitor timestamps. 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | BT=48 | reserved | length | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | SSRC of source | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | begin_seq | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | end_seq | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | RTP timestamp (pkt n) | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 : : 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 block type (BT): 8 bits 422 A Timestamp block is identified by the constant 48 = 0x30. 424 reserved: 8 bits 425 This field is reserved for future definition. All bits in this field 426 MUST be set to zero unless otherwise defined. 428 length: 16 bits 429 The length of this report block in 32-bit words minus one, including 430 the header. 432 begin_seq: 32 bits 433 The first sequence number that this block reports on. 435 end_seq: 32 bits 436 The last sequence number that this block reports on plus one. 438 RTP timestamp: 32 bits 439 Corresponds to the same units as the RTP timestamp in RTP data pack� 440 ets. The timestamp is established upon packet arrival. It can be 441 used to measure partial path characteristics and to model distribu� 442 tions for packet jitter. 444 4.4.1 Statistics Summary Block 446 This block reports detailed statistics above and beyond the informa� 447 tion carried in the standard RTCP packet format. Information is 448 recorded about lost packets, duplicate packets, jitter measurements, 449 and TTL values. The packet contents are dependent upon a bit vector 450 carried in the first part of the header. Not all values need to be 451 carried in each packet. Header fields for values not carried are not 452 included in the packet. 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | BT=1 |L|D|J|T|resvd. | length | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | SSRC of source | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | begin_seq | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | end_seq | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | lost_packets | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | dup_packets | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | min_jitter | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | max_jitter | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | avg_jitter | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | dev_jitter | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | min_ttl | max_ttl | avg_ttl | dev_ttl | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 block type (BT): 8 bits 481 A Statistics Summary block is identified by the constant 1 = 0x01. 483 content bits (L,D,J,T): 4 bits 484 Bit set to 1 if packet contains (L)oss, (D)uplicate, (J)itter, and/or 485 (T)TL report. 487 resvd.: 4 bits 488 This field is reserved for future definition. All bits in this field 489 MUST be set to zero unless otherwise defined. 491 length: 16 bits 492 The length of this report block in 32-bit words minus one, including 493 the header. 495 begin_seq: 32 bits 496 The first sequence number that this block reports on. 498 end_seq: 32 bits 499 The last sequence number that this block reports on plus one. 501 lost_packets: 32 bits 502 Number of lost packets in the above sequence number interval. 504 dup_packets: 32 bits 505 Number of duplicate packets in the above sequence number interval. 507 min_jitter: 32 bits 508 The minimum relative transit time between two packets in the above 509 sequence number interval. All jitter values are measured as the dif� 510 ference between a packet's RTP timestamp and the reporter's clock at 511 the time of arrival, measured in the same units. 513 max_jitter: 32 bits 514 The maximum relative transit time between two packets in the above 515 sequence number interval. 517 avg_jitter: 32 bits 518 The average relative transit time between each two packet series in 519 the above sequence number interval. 521 dev_jitter: 32 bits 522 The standard deviation of the relative transit time between each two 523 packet series in the above sequence number interval. 525 min_ttl: 8 bits 526 The minimum TTL value of data packets in sequence number range. 528 max_ttl: 8 bits 529 The maximum TTL value of data packets in sequence number range. 531 avg_ttl: 8 bits 532 The average TTL value of data packets in sequence number range. 534 dev_ttl: 8 bits 535 The standard deviation of TTL values of data packets in sequence num� 536 ber range. 538 4.4.2 Receiver Timestamp Report Block 540 This block extends RTCP's timestamp reporting so that non-senders may 541 also send timestamps. It recapitulates the NTP timestamp fields from 542 the RTCP Sender Report [7, Sec. 6.3.1]. A non-sender may estimate 543 its RTT to other participants, as proposed in [8], by sending this 544 report block and receiving DLRR report blocks (see next section) in 545 reply. 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | BT=2 | reserved | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | NTP timestamp, most significant word | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | NTP timestamp, least significant word | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 block type (BT): 8 bits 558 A Receiver Timestamp block is identified by the constant 2 = 0x02. 560 reserved: 24 bits 561 This field is reserved for future definition. The bits in this field 562 MUST be set to zero unless otherwise defined. 564 NTP timestamp: 64 bits 565 Indicates the wallclock time when this block was sent so that it may 566 be used in combination with timestamps returned in DLRR report blocks 567 from other receivers to measure round-trip propagation to those 568 receivers. Receivers should expect that the measurement accuracy of 569 the timestamp may be limited to far less than the resolution of the 570 NTP timestamp. The measurement uncertainty of the timestamp is not 571 indicated as it may not be known. A report block sender that can keep 572 track of elapsed time but has no notion of wallclock time may use the 573 elapsed time since joining the session instead. This is assumed to be 574 less than 68 years, so the high bit will be zero. It is permissible 575 to use the sampling clock to estimate elapsed wallclock time. A 576 report sender that has no notion of wallclock or elapsed time may set 577 the NTP timestamp to zero. 579 4.4.3 DLRR Report Block 581 This block extends RTCP's DLSR mechanism [7, Sec. 6.3.1] so that non- 582 senders may also calculate round trip times, as proposed in [8]. It 583 is termed DLRR for Delay since Last Receiver Report, and may be sent 584 in response to a Receiver Timestamp report block (see previous sec� 585 tion) from a receiver to allow that receiver to calculate its round 586 trip time to the respondant. The report consists of one or more 3 587 word sub-blocks: one sub-block per receiver report. 589 0 1 2 3 590 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 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | BT=3 | reserved | length | 593 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 594 | SSRC_1 (SSRC of first receiver) | sub- 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 596 | last RR (LRR) | 1 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | delay since last RR (DLRR) | 599 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 600 | SSRC_2 (SSRC of second receiver) | sub- 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 602 : ... : 2 603 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 605 block type (BT): 8 bits 606 A DLRR block is identified by the constant 3 = 0x03. 608 reserved: 8 bits 609 This field is reserved for future definition. All bits in this field 610 MUST be set to zero unless otherwise defined. 612 length: 16 bits 613 The length of this report block in 32-bit words minus one, including 614 the header. The number of sub-blocks is length divided by three (3). 616 last RR timestamp (LRR): 32 bits 617 The middle 32 bits out of 64 in the NTP timestamp (as explained in 618 the previous section) received as part of a Receiver Timestamp report 619 block from participant SSRC_n. If no such block has been received, 620 the field is set to zero. 622 delay since last RR (DLRR): 32 bits 623 The delay, expressed in units of 1/65536 seconds, between receiving 624 the last Receiver Timestamp report block from participant SSRC_n and 625 sending this DLRR report block. If no Receiver Timestamp report 626 block has been received yet from SSRC_n, the DLRR field is set to 627 zero (or the DLRR is omitted entirely). Let SSRC_r denote the 628 receiver issuing this DLRR report block. Participant SSRC_n can 629 compute the round-trip propagation delay to SSRC_r by recording the 630 time A when this Receiver Timestamp report block is received. It 631 calculates the total round-trip time A-LSR using the last SR times� 632 tamp (LSR) field, and then subtracting this field to leave the round- 633 trip propagation delay as (A- LSR - DLSR). This is illustrated in [7, 634 Fig. 2]. 636 5. Acknowledgements 638 We thank the following people: Colin Perkins, Steve Casner, and Hen� 639 ning Schulzrinne for their considered guidance; Nick Duffield for 640 extensive ongoing contributions; Sue Moon for helping foster collabo� 641 ration between the authors of this document; and Mounir Benzaid for 642 drawing our attention to the reporting needs of MLDA. 644 6. Intellectual Property 646 The IETF takes no position regarding the validity or scope of any 647 intellectual property or other rights that might be claimed to per� 648 tain to the implementation or use of the technology described in this 649 document or the extent to which any license under such rights might 650 or might not be available; neither does it represent that it has made 651 any effort to identify any such rights. Information on the IETF's 652 procedures with respect to rights in standards-track and standards- 653 related documentation can be found in BCP 11 [5]. Copies of claims 654 of rights made available for publication and any assurances of 655 licenses to be made available, or the result of an attempt made to 656 obtain a general license or permission for the use of such propri� 657 etary rights by implementors or users of this specification can be 658 obtained from the IETF Secretariat. 660 The IETF invites any interested party to bring to its attention any 661 copyrights, patents or patent applications, or other proprietary 662 rights which may cover technology that may be required to practice 663 this standard. Please address the information to the IETF Executive 664 Director. 666 7. References 668 [1] A. Adams, T. Bu, R. C�ceres, N.G. Duffield, T. Friedman, J. 669 Horowitz, F. Lo Presti, S.B. Moon, V. Paxson, and D. Towsley, "The 670 Use of End-to-End Multicast Measurements for Characterizing Internal 671 Network Behavior," IEEE Communications Magazine, May 2000. 673 [2] S. Bradner, "The Internet Standards Process -- Revision 3," BCP 674 9, RFC 2026, IETF, October 1996. 676 [3] S. Bradner, "Key words for use in RFCs to indicate requirement 677 levels," BCP 14, RFC 2119, IETF, March 1997. 679 [4] R. Caceres, N.G. Duffield, and T. Friedman, "Impromptu measure� 680 ment infrastructures using RTP," Proc. IEEE Infocom 2002, New York, 681 23-27 June 2002, to appear. 683 [5] R. Hovey and S. Bradner, "The Organizations Involved in the IETF 684 Standards Process," BCP 11, RFC 2028, IETF, October 1996. 686 [6] J. Reynolds and J. Postel, "Assigned Numbers," STD 2, RFC 1700, 687 IETF, October 1994. 689 [7] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A 690 transport protocol for real-time applications," RFC 1889, IETF, 691 February 1996. 693 [8] D. Sisalem and A. Wolisz, "MLDA: A TCP-friendly Congestion Con� 694 trol Framework for Heterogeneous Multicast Environments", Eighth 695 International Workshop on Quality of Service (IWQoS 2000), Pitts� 696 burgh, 5-7 June 2000. 698 8. Full Copyright Statement 700 Copyright (C) The Internet Society (2002). All Rights Reserved. 702 This document and translations of it may be copied and furnished to 703 others, and derivative works that comment on or otherwise explain it 704 or assist in its implementation may be prepared, copied, published 705 and distributed, in whole or in part, without restriction of any 706 kind, provided that the above copyright notice and this paragraph are 707 included on all such copies and derivative works. However, this doc� 708 ument itself may not be modified in any way, such as by removing the 709 copyright notice or references to the Internet Society or other 710 Internet organizations, except as needed for the purpose of develop� 711 ing Internet standards in which case the procedures for copyrights 712 defined in the Internet Standards process must be followed, or as 713 required to translate it into languages other than English. 715 The limited permissions granted above are perpetual and will not be 716 revoked by the Internet Society or its successors or assigns. 718 This document and the information contained herein is provided on an 719 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 720 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 721 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 722 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER� 723 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 725 9. Authors' Addresses 727 Timur Friedman 728 Laboratoire d'informatique de Paris 6 729 8, rue du Capitaine Scott 730 75015 PARIS, FRANCE 732 Ramon Caceres 733 ShieldIP, Inc. 734 11 West 42nd Street, 31st Floor 735 New York, NY 10036, USA 737 Kevin Almeroth 738 Department of Computer Science 739 University of California 740 Santa Barbara, CA 93106, USA 742 Kamil Sarac 743 Department of Computer Science 744 University of California 745 Santa Barbara, CA 93106, USA 747 10. Expiry 749 This draft expires 28 August 2002.