idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-pdv-06.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 (September 14, 2012) is 4240 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'G.1020' == Outdated reference: A later version (-10) exists of draft-ietf-xrblock-rtcp-xr-meas-identity-06 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-22) exists of draft-ietf-avtcore-monarch-13 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Working Group A. Clark 3 Internet-Draft Telchemy 4 Intended status: Standards Track Q. Wu 5 Expires: March 18, 2013 Huawei 6 September 14, 2012 8 RTCP XR Report Block for Packet Delay Variation Metric Reporting 9 draft-ietf-xrblock-rtcp-xr-pdv-06.txt 11 Abstract 13 This document defines a Real-Time Control Protocol (RTCP) Extended 14 Report (XR) block that allows the reporting of Packet Delay Variation 15 metrics for a range of Real-time Transport Protocol (RTP) 16 applications. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 18, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Packet Delay Variation Metrics Block . . . . . . . . . . . 3 54 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 3 55 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 3 56 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Standards Language . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Packet Delay Variation Metrics Block . . . . . . . . . . . . . 5 61 3.1. Report Block Structure . . . . . . . . . . . . . . . . . . 5 62 3.2. Definition of Fields in PDV Metrics Block . . . . . . . . 5 63 3.3. Guidance on use of PDV metrics . . . . . . . . . . . . . . 9 64 3.4. Examples of use . . . . . . . . . . . . . . . . . . . . . 9 65 4. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 11 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 67 5.1. New RTCP XR Block Type value . . . . . . . . . . . . . . . 12 68 5.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 12 69 5.3. Contact information for registrations . . . . . . . . . . 12 70 5.4. New registry of PDV types . . . . . . . . . . . . . . . . 12 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 77 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19 78 A.1. draft-ietf-xrblock-rtcp-xr-pdv-06 . . . . . . . . . . . . 19 79 A.2. draft-ietf-xrblock-rtcp-xr-pdv-05 . . . . . . . . . . . . 19 80 A.3. draft-ietf-xrblock-rtcp-xr-pdv-04 . . . . . . . . . . . . 19 81 A.4. draft-ietf-xrblock-rtcp-xr-pdv-03 . . . . . . . . . . . . 19 82 A.5. draft-ietf-xrblock-rtcp-xr-pdv-02 . . . . . . . . . . . . 20 83 A.6. draft-ietf-xrblock-rtcp-xr-pdv-01 . . . . . . . . . . . . 20 84 A.7. draft-ietf-xrblock-rtcp-xr-pdv-00 . . . . . . . . . . . . 20 85 A.8. draft-ietf-avt-rtcp-xr-pdv-03 . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 88 1. Introduction 90 1.1. Packet Delay Variation Metrics Block 92 This draft defines a new block type to augment those defined in 93 [RFC3611], for use in a range of RTP applications. 95 The new block type provides information on Packet Delay Variation 96 (PDV) using one of several standard metrics,, for example, Mean 97 Absolute Packet Delay Variation 2 (MAPDV2) (Clause 6.2.3.2 of 98 [G.1020]), or 2-point PDV (Clause 6.2.4 of [Y.1540]). 100 The metrics belong to the class of transport metrics defined in 101 [MONARCH]. 103 1.2. RTCP and RTCP XR Reports 105 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 106 defined an extensible structure for reporting using an RTCP Extended 107 Report (XR). This draft defines a new Extended Report block for use 108 with [RFC3550] and [RFC3611]. 110 1.3. Performance Metrics Framework 112 The Performance Metrics Framework [RFC6390] provides guidance on the 113 definition and specification of performance metrics. The RTP 114 Monitoring Architectures [MONARCH] provides guideline for reporting 115 block format using RTCP XR. The XR Block described in this document 116 are in accordance with the guidelines in [RFC6390] and [MONARCH]. 118 1.4. Applicability 120 These metrics are applicable to a wide range of RTP applications in 121 which the application streams are sensitive to delay variation. 122 Application designers can know the range of delay variation they must 123 accommodate, whether they are designing fixed or adaptive buffer 124 systems. Network manager also can constrain delay variation to 125 ensure the quality of real-time applications, and monitor this metric 126 (possibly to compare with a numerical objective or Service Level 127 Agreement) [RFC5481]. 129 2. Terminology 131 This document uses ABNF from [RFC5234] as a terminology statement. 133 2.1. Standards Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 2.2. Notations 141 This report block makes use of binary fractions. The terminology 142 used is 144 Numeric formats S X:Y 146 where S indicates a two's complement signed representation, X 147 the number of bits prior to the decimal place and Y the number 148 of bits after the decimal place. 150 Hence 8:8 represents an unsigned number in the range 0.0 to 151 255.996 with a granularity of 0.0039. S7:8 would represent the 152 range -127.996 to +127.996. 0:16 represents a proper binary 153 fraction with range 155 0.0 to 1 - 1/65536 = 0.9999847 157 though note that use of flag values at the top of the numeric 158 range slightly reduces this upper limit. For example, if the 159 16- bit values 0xfffe and 0xffff are used as flags for "over- 160 range" and "unavailable" conditions, a 0:16 quantity has range 162 0.0 to 1 - 3/65536 = 0.9999542 164 3. Packet Delay Variation Metrics Block 166 Metrics in this block report on packet delay variation in the stream 167 arriving at the RTP system. The measurement of these metrics are 168 made at the receiving end of the RTP stream. Instances of this 169 Metrics Block refer by Synchronization source (SSRC) to the separate 170 auxiliary Measurement Information block [MEASI] which contains 171 measurement intervals. This metric block relies on the measurement 172 interval in the Measurement Information block indicating the span of 173 the report and SHOULD be sent in the same compound RTCP packet as the 174 measurement information block. If the measurement interval is not 175 received for this metric block, this metric block MUST be discarded ( 176 See timing details in section 5.4 of[MONARCH]). 178 3.1. Report Block Structure 180 PDV metrics block 182 0 1 2 3 183 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | BT=NPDV | I |pdvtyp |Rsv| block length=4 | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | SSRC of Source | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Pos PDV Threshold/Peak | Pos PDV Percentile | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Neg PDV Threshold/Peak | Neg PDV Percentile | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Mean PDV | Reserved | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 1: Report Block Structure 198 3.2. Definition of Fields in PDV Metrics Block 200 Block type (BT): 8 bits 202 A Packet Delay Variation Metrics Report Block is identified by the 203 constant NPDV. 205 [Note to RFC Editor: please replace NPDV with the IANA provided 206 RTCP XR block type for this block.] 208 Interval Metric flag (I): 2 bit 210 This field is used to indicate whether the Packet Delay variation 211 metrics are Sampled, Interval or Cumulative metrics [MONARCH], 212 that is, whether the reported values applies to the most recent 213 measurement interval duration between successive metrics reports 214 (I=10) (the Interval Duration) or to the accumulation period 215 characteristic of cumulative measurements (I=11) (the Cumulative 216 Duration) or is a sampled instantaneous value (I=01) (Sampled 217 Value). The value I=00 is reserved, and MUST NOT be used. If the 218 value I=00 is received, it MUST be ignored by the receiver. 220 Packet Delay Variation Metric Type (pdvtyp): 4 bits 222 Packet Delay Variation Metric Type is of type enumerated and is 223 interpreted as Integer. This field is used to identify the Packet 224 Delay Variation Metric Type used in this report block, according 225 to the following code: 227 bits 014-011 229 0: MAPDV2, Clause 6.2.3.2 of [G.1020], 231 1: 2-point PDV, Clause 6.2.4 of [Y.1540]. 233 Rsv.: 2 bits 235 This field is reserved for future definition. In the absence of 236 such a definition, the bits in this field MUST be set to zero and 237 ignored by the receiver. 239 Block Length: 16 bits 241 The length of this report block in 32-bit words, minus one. For 242 the Packet Delay Variation Metrics block, the block length is 243 equal to 4. 245 SSRC of source: 32 bits 247 As defined in Section 4.1 of [RFC3611]. 249 Positive PDV Threshold/Peak: 16 bits 251 This field is associated with the Positive PDV percentile and 252 expressed in Milliseconds with numeric format S11:4. The term 253 Positive represents that the packets are arriving later than the 254 expected time. 256 If the measured value is more negative than -2047.9375 (the value 257 which would be coded as 0x8001), the value 0x8000 SHOULD be 258 reported to indicate an over-range negative measurement. If the 259 measured value is more positive than +2047.8125 (the value which 260 would be coded as 0x7FFD), the value 0x7FFE SHOULD be reported to 261 indicate an over-range positive measurement. If the measurement 262 is unavailable, the value 0x7FFF MUST be reported. 264 Positive PDV Percentile: 16 bits 266 The percentages of packets in the RTP stream for which individual 267 packet delays were less than the Positive PDV Threshold. It is 268 expressed in numeric format 8:8 with values from 0 to 100th 269 percentile. 271 If the measurement is unavailable, the value 0xFFFF MUST be 272 reported. 274 Negative PDV Threshold/Peak: 16 bits 276 This field is associated with the Negative PDV percentile and 277 expressed in Milliseconds with numeric format S11:4. The term 278 Negative represents that the packets are arriving earlier than the 279 expected time. 281 If the measured value is more negative than -2047.9375 (the value 282 which would be coded as 0x8001), the value 0x8000 SHOULD be 283 reported to indicate an over-range negative measurement. If the 284 measured value is more positive than +2047.8125 (the value which 285 would be coded as 0x7FFD), the value 0x7FFE SHOULD be reported to 286 indicate an over-range positive measurement. If the measurement 287 is unavailable, the value 0x7FFF MUST be reported. 289 Negative PDV Percentile: 16 bits 291 The percentages of packets in the RTP stream for which individual 292 packet delays were more than the Negative PDV Threshold. It is 293 expressed in numeric format 8:8 with values from 0 to 100th 294 percentile. 296 If the measurement is unavailable, the value 0xFFFF MUST be 297 reported. 299 If the PDV Type indicated is 2-point PDV and the Positive and 300 Negative PDV Percentiles are set to 100.0 then the Positive and 301 Negative Threshold/Peak PDV values are the peak values measured 302 during the reporting interval (which may be from the start of the 303 call for cumulative reports). In this case, the difference 304 between the Positive and Negative Threshold/Peak values defines 305 the range of 2-point PDV. 307 Mean PDV: 16 bits 309 The mean PDV value of data packets is expressed in milliseconds 310 with Numeric format S11:4 format. 312 For MAPDV2 this value is generated according to Clause 6.2.3.2 of 313 [G.1020]. For interval reports the MAPDV2 value is reset at the 314 start of the interval. 316 For 2-point PDV, the value reported is the mean of per-packet 317 2-point PDV values. This metric indicates the arrival time of the 318 first media packet of the session with respect to the mean of the 319 arrival times of every packet of the session. A single value of 320 the metric (for a single session) may not be useful by itself, but 321 its average over a number of sessions may be useful in diagnosing 322 media delay at session startup. For example, this might occur if 323 media packets are often delayed behind signalling packets due to 324 head-of-line blocking. 326 If the measured value is more negative than -2047.9375 (the value 327 which would be coded as 0x8001), the value 0x8000 SHOULD be 328 reported to indicate an over-range negative measurement. If the 329 measured value is more positive than +2047.8125 (the value which 330 would be coded as 0x7FFD), the value 0x7FFE SHOULD be reported to 331 indicate an over-range positive measurement. If the measurement 332 is unavailable, the value 0x7FFF MUST be reported. 334 Reserved: 16 bits 336 These bits are reserved for future definition. They MUST be set 337 to zero by the sender and ignored by the receiver. 339 3.3. Guidance on use of PDV metrics 341 This subsection provides informative guidance on when it might be 342 appropriate to use each of the PDV metric types. 344 MAPDV2 (Clause 6.2.3.2 of [G.1020]) is the envelope of instantaneous 345 (per-packet) delay when compared to the short term moving average 346 delay. This metric could be useful in determining residual 347 impairment when an RTP end system uses an adaptive de-jitter buffer 348 which tracks the average delay variation, provided the adaptive de- 349 jitter buffer have similar averaging behaviour as the MAPDV2 350 algorithm. 352 2-point PDV (Clause 6.2.4 of [Y.1540]) reports absolute packet delay 353 variation with respect to a defined reference packet transfer delay . 354 Note that the reference packet is generally selected as the packet 355 with minimum delay based on the most common criterion (See section 1 356 and section 5.1 of [RFC5481] ). In an RTP context, the two "points" 357 are at the sender (the synchronization source which applies RTP 358 timestamps) and at the receiver. The value of this metric for the 359 packet with index j is identical to the quantity D(i,j) defined in 360 Section 6.4.1 of [RFC3550] and the packet index i should be set equal 361 to the index of the reference packet for the metric in practice. The 362 metric includes the effect of the frequency offsets of clocks in both 363 the sender and receiver end systems, so it is useful mainly in 364 network where synchronisation is distributed. As well as measuring 365 packet delay variation in such networks, it may be used to ensure 366 that synchronisation is effective, for example where the network 367 carries ISDN data traffic over RTP [RFC4040]. The metric is likely 368 to be useful in networks which use fixed de-jitter buffering, because 369 it may be used to determine the length of the required de-jitter 370 buffer, or to determine if network performance has deteriorated such 371 that existing de-jitter buffers are too small to accommodate the 372 observed delay variation. 374 3.4. Examples of use 376 (b) To report MAPDV2 [G.1020]: 378 Pos PDV Threshold = 50.0; Pos PDV Percentile = 95.3; Neg PDV 379 Threshold = 50.0 (note this implies -50ms); Neg PDV Percentile 380 = 98.4; PDV type = 1 (MAPDV2) 382 causes average MAPDV2 to be reported in the Mean PDV field. 384 Note that implementations may either fix the reported 385 percentile and calculate the associated PDV level or may fix a 386 threshold PDV level and calculate the associated percentile. 388 From a practical implementation perspective it is simpler to 389 use the second of these approaches (except of course in the 390 extreme case of a 100% percentile). 392 (b) To report 2-point PDV [Y.1540]: 394 Pos PDV Threshold = 60 (note this implies +60ms); Pos PDV 395 Percentile = 96.3; Neg PDV Threshold = 0; Neg PDV Percentile = 396 0; PDV type = 1 (2-point PDV) 398 causes 2-point PDV to be reported in the Mean PDV field. 400 2-point PDV, according to [Y.1540] is the difference in delay 401 between the current packet and the referenced packet of the 402 stream. If the sending and receiving clocks are not 403 synchronized, this metric includes the effect of relative 404 timing drift. 406 4. SDP Signaling 408 [RFC3611] defines the use of SDP (Session Description Protocol) 409 [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 410 without prior signaling. 412 This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 413 in [RFC3611] by providing an additional value of "xr-format" to 414 signal the use of the report block defined in this document. 416 xr-format =/ xr-pdv-block 418 xr-pdv-block = "pkt-dly-var" [ "," pdvtype ] [ "," nspec "," pspec ] 420 pdvtype = "pdv=" ( "0" ; MAPDV2 ITU-T G.1020 421 / "1" ; 2-point PDV ITU-T Y.1540 422 / 1*2DIGIT ) ;Value 2~15 are valid and 423 ;reserved for future use 424 nspec = ("nthr=" fixpoint) ; negative PDV threshold (ms) 425 / ("npc=" fixpoint ) ; negative PDV percentile 426 pspec = ("pthr=" fixpoint) ; positive PDV threshold (ms) 427 / ("ppc=" fixpoint) ; positive PDV percentile 429 fixpoint = 1*DIGIT "." 1*DIGIT ; fixed point decimal 430 DIGIT = 432 When SDP is used in offer-answer, a system sending SDP may request a 433 specific type of PDV measurement. In addition, they may state a 434 specific percentile or threshold value, and expect to receive the 435 corresponding threshold or percentile metric, respectively. The 436 system receiving the SDP SHOULD send the PDV metrics requested, but 437 if the metric is not available, the system receiving the SDP MUST 438 send the metric block with the flag value indicating that the metric 439 is unavailable. 441 5. IANA Considerations 443 New block types for RTCP XR are subject to IANA registration. For 444 general guidelines on IANA considerations for RTCP XR, refer to 445 [RFC3611]. 447 5.1. New RTCP XR Block Type value 449 This document assigns the block type value NPDV in the IANA "RTCP XR 450 Block Type Registry" to the "Packet Delay Variation Metrics Block". 452 [Note to RFC Editor: please replace NPDV with the IANA provided RTCP 453 XR block type for this block.] 455 5.2. New RTCP XR SDP Parameter 457 This document also registers a new parameter "pkt-dly-var" in the 458 "RTCP XR SDP Parameters Registry". 460 5.3. Contact information for registrations 462 The contact information for the registrations is: 464 Qin Wu (sunseawq@huawei.com) 466 101 Software Avenue, Yuhua District 467 Nanjing, Jiangsu 210012 468 China 470 5.4. New registry of PDV types 472 This document creates a new registry to be called "RTCP XR PDV block 473 - PDV type" as a sub-registry of the "RTP Control Protocol Extended 474 Reports (RTCP XR) Block Type Registry". Policies for this new 475 registry are as follows: 477 o The information required to support an assignment is an 478 unambiguous definition of the new metric, covering the base 479 measurements and how they are processed to generate the reported 480 metric. This should include the units of measurement, how values 481 of the metric are reported in the three 16-bit fields "Pos PDV 482 Threshold/Peak", "Neg PDV Threshold/Peak" and "Mean PDV" within 483 the report block, and how the metric uses the two 16-bit fields 484 "Pos PDV Percentile" and "Neg PDV Percentile". 486 o The review process for the registry is "Specification Required" as 487 described in Section 4.1 of [RFC5226]. 489 o Entries in the registry are integers. The valid range is 0 to 15 490 corresponding to the 4-bit field "pdvtyp" in the block. Values 491 are to be recorded in decimal. 493 o Initial assignments are as follows: 495 * 0: MAPDV2, Clause 6.2.3.2 of [G.1020], 497 * 1: 2-point PDV, Clause 6.2.4 of [Y.1540] 499 6. Security Considerations 501 It is believed that this proposed RTCP XR report block introduces no 502 new security considerations beyond those described in [RFC3611]. 503 This block does not provide per-packet statistics so the risk to 504 confidentiality documented in Section 7, paragraph 3 of [RFC3611] 505 does not apply. 507 7. Contributors 509 Geoff Hunt wrote the initial version of this document. 511 8. Acknowledgments 513 The authors gratefully acknowledge the comments and contributions 514 made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin 515 Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert 516 Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith 517 Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, 518 Ravi Raviraj, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada,Jing 519 Zhao,Kevin Gross, Colin Perkins, Charles Eckel, Glen Zorn,Shida 520 Schubert, Benoit Claise, Adrian Farrel, Pete Resnick. 522 9. References 524 9.1. Normative References 526 [G.1020] ITU-T, "ITU-T Rec. G.1020, Performance parameter 527 definitions for quality of speech and other voiceband 528 applications utilizing IP networks", July 2006. 530 [MEASI] Hunt, G., "Measurement Identity and information Reporting 531 using SDES item and XR Block", 532 ID draft-ietf-xrblock-rtcp-xr-meas-identity-06, 533 April 2012. 535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 536 Requirement Levels", March 1997. 538 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 539 Applications", RFC 3550, July 2003. 541 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 542 Protocol Extended Reports (RTCP XR)", November 2003. 544 [RFC4040] Kreuter, R., "RTP Payload Format for a 64 kbit/s 545 Transparent Call", April 2005. 547 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 548 Description Protocol", July 2006. 550 [RFC5226] Narten, T., "Guidelines for Writing an IANA Considerations 551 Section in RFCs", May 2008. 553 BCP 26 555 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 556 Specifications: ABNF", January 2008. 558 [Y.1540] ITU-T, "ITU-T Rec. Y.1540, IP packet transfer and 559 availability performance parameters", November 2007. 561 9.2. Informative References 563 [MONARCH] Hunt, G., "Monitoring Architectures for RTP", 564 ID draft-ietf-avtcore-monarch-13, May 2012. 566 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 567 Applicability Statement", RFC 5481, March 2009. 569 [RFC6390] Clark, A. and B. Claise, "Framework for Performance Metric 570 Development", RFC 6390, October 2011. 572 Appendix A. Change Log 574 Note to the RFC-Editor: please remove this section prior to 575 publication as an RFC. 577 A.1. draft-ietf-xrblock-rtcp-xr-pdv-06 579 The following are the major changes to previous version 580 draft-ietf-xrblock-rtcp-xr-pdv-05: 582 o Editorial change based on IESG Review. 584 o SDP element update based on pete's suggestion. 586 o Clarify the value of PDV in the applicability section. 588 o Clarify measurement point and timing in section 3. 590 A.2. draft-ietf-xrblock-rtcp-xr-pdv-05 592 The following are the major changes to previous version 593 draft-ietf-xrblock-rtcp-xr-pdv-04: 595 o Move Geoff Hunt from author list to Contributors section based on 596 his suggestion. 598 A.3. draft-ietf-xrblock-rtcp-xr-pdv-04 600 The following are the major changes to previous version 601 draft-ietf-xrblock-rtcp-xr-pdv-03: 603 o Editorial changes based on Gen-Art Review and Secdir Review. 605 A.4. draft-ietf-xrblock-rtcp-xr-pdv-03 607 The following are the major changes to previous version 608 draft-ietf-xrblock-rtcp-xr-pdv-02: 610 o Make definition of pdvtype get alignment with IANA section. 612 o Make Guidance on use of PDV metrics get alignment with RFC5481. 614 o Other Editorial changes. 616 A.5. draft-ietf-xrblock-rtcp-xr-pdv-02 618 The following are the major changes to previous version 619 draft-ietf-xrblock-rtcp-xr-pdv-01: 621 o Updated references. 623 o Allocate one more bit for Interval metric flag to indicate sampled 624 metric can be used. 626 o Add a few clarification text for failure mode. 628 A.6. draft-ietf-xrblock-rtcp-xr-pdv-01 630 The following are the major changes to previous version 631 draft-ietf-xrblock-rtcp-xr-pdv-00: 633 o Fix typos or nits in the definition of Negative PDV Threshold/ 634 Peak. 636 o Fix nits in Numeric format S7:8. 638 o remove the text that is relevant to tag field. 640 o Add text in SDP signaling section to clarify indicationof metric 641 unavailable. 643 A.7. draft-ietf-xrblock-rtcp-xr-pdv-00 645 The following are the major changes to previous version 646 draft-ietf-avt-rtcp-xr-pdv-03: 648 o Updated references. 650 A.8. draft-ietf-avt-rtcp-xr-pdv-03 652 The following are the major changes to previous version : 654 o Changed BNF for SDP following Christian Groves' and Tom Taylor's 655 comments (4th and 5th May 2009). 657 o Updated references. 659 Authors' Addresses 661 Alan Clark 662 Telchemy Incorporated 663 2905 Premiere Parkway, Suite 280 664 Duluth, GA 30097 665 USA 667 Email: alan.d.clark@telchemy.com 669 Qin Wu 670 Huawei 671 101 Software Avenue, Yuhua District 672 Nanjing, Jiangsu 210012 673 China 675 Email: sunseawq@huawei.com