idnits 2.17.1 draft-ietf-avtcore-monarch-17.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 (June 28, 2012) is 4320 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-xrblock-rtcp-xr-meas-identity-07 == Outdated reference: A later version (-08) exists of draft-ietf-xrblock-rtcp-xr-pdv-03 == Outdated reference: A later version (-17) exists of draft-ietf-xrblock-rtcp-xr-qoe-01 -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Working Group Q. Wu, Ed. 3 Internet-Draft Huawei 4 Intended status: Informational G. Hunt 5 Expires: December 30, 2012 Unaffiliated 6 P. Arden 7 BT 8 June 28, 2012 10 Guidelines for Use of the RTP Monitoring Framework 11 draft-ietf-avtcore-monarch-17.txt 13 Abstract 15 This memo proposes an extensible RTP monitoring framework for 16 extending RTP Control Protocol (RTCP) with a new RTCP Extended 17 Reports (XR) block type to report new metrics regarding media 18 transmission or reception quality. In this framework, a new XR block 19 should contain a single metric or a small number of metrics relevant 20 to a single parameter of interest or concern, rather than containing 21 a number of metrics which attempt to provide full coverage of all 22 those parameters of concern to a specific application. Applications 23 may then "mix and match" to create a set of blocks which covers their 24 set of concerns. Where possible, a specific block should be designed 25 to be re-usable across more than one application, for example, for 26 all of voice, streaming audio and video. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 30, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. RTP Monitoring Framework . . . . . . . . . . . . . . . . . . . 7 65 3.1. Overview of the RTP Monitoring Framework . . . . . . . . . 7 66 3.2. Location of RTP Monitors . . . . . . . . . . . . . . . . . 9 67 4. Issues with reporting metric block using RTCP XR extension . . 10 68 4.1. Using compound metrics block . . . . . . . . . . . . . . . 10 69 4.2. Correlating RTCP XR with the non-RTP data . . . . . . . . 10 70 4.3. Measurement Information duplication . . . . . . . . . . . 10 71 4.4. Consumption of XR block code points . . . . . . . . . . . 11 72 5. Guidelines for reporting metric block using RTCP XR . . . . . 12 73 5.1. Contain the single metrics in the Metric Block . . . . . . 12 74 5.2. Include the payload type in the Metric Block . . . . . . . 12 75 5.3. Use RTCP SDES to correlate XR reports with non-RTP data . 13 76 5.4. Reduce Measurement information repetition across 77 metric blocks . . . . . . . . . . . . . . . . . . . . . . 13 78 6. An example of a metric block . . . . . . . . . . . . . . . . . 15 79 7. Application to RFC 5117 topologies . . . . . . . . . . . . . . 16 80 7.1. Applicability to Translators . . . . . . . . . . . . . . . 16 81 7.2. Applicability to MCU . . . . . . . . . . . . . . . . . . . 17 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 84 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 20 85 11. Informative References . . . . . . . . . . . . . . . . . . . . 21 86 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 23 87 A.1. draft-ietf-avtcore-monarch-17 . . . . . . . . . . . . . . 23 88 A.2. draft-ietf-avtcore-monarch-16 . . . . . . . . . . . . . . 23 89 A.3. draft-ietf-avtcore-monarch-15 . . . . . . . . . . . . . . 23 90 A.4. draft-ietf-avtcore-monarch-14 . . . . . . . . . . . . . . 23 91 A.5. draft-ietf-avtcore-monarch-13 . . . . . . . . . . . . . . 24 92 A.6. draft-ietf-avtcore-monarch-12 . . . . . . . . . . . . . . 24 93 A.7. draft-ietf-avtcore-monarch-11 . . . . . . . . . . . . . . 24 94 A.8. draft-ietf-avtcore-monarch-10 . . . . . . . . . . . . . . 24 95 A.9. draft-ietf-avtcore-monarch-09 . . . . . . . . . . . . . . 24 96 A.10. draft-ietf-avtcore-monarch-08 . . . . . . . . . . . . . . 25 97 A.11. draft-ietf-avtcore-monarch-07 . . . . . . . . . . . . . . 25 98 A.12. draft-ietf-avtcore-monarch-06 . . . . . . . . . . . . . . 25 99 A.13. draft-ietf-avtcore-monarch-05 . . . . . . . . . . . . . . 25 100 A.14. draft-ietf-avtcore-monarch-04 . . . . . . . . . . . . . . 26 101 A.15. draft-ietf-avtcore-monarch-03 . . . . . . . . . . . . . . 26 102 A.16. draft-ietf-avtcore-monarch-02 . . . . . . . . . . . . . . 26 103 A.17. draft-ietf-avtcore-monarch-01 . . . . . . . . . . . . . . 27 104 A.18. draft-ietf-avtcore-monarch-00 . . . . . . . . . . . . . . 27 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 107 1. Introduction 109 Multimedia services using the Real-Time Protocol (RTP) are seeing 110 increased use. Standard methods for gathering RTP performance 111 metrics from these applications are needed to manage uncertainties in 112 the behavior and availability of their services. Standards , such as 113 RTP Control Protocol Extended Reports (RTCP XR)[RFC3611] and other 114 RTCP extension to Sender Reports (SR), Receiver Reports (RR) 115 [RFC3550] are being developed for the purpose of collecting and 116 reporting performance metrics from endpoint devices that can be used 117 to correlate the metrics, provide end to end service visibility and 118 measure and monitor Quality of Experience (QoE) [RFC6390]. 120 However the proliferation of RTP/RTCP specific metrics for transport 121 and application quality monitoring has been identified as a potential 122 problem for interoperability when using RTP/RTCP to communicate all 123 the parameters of concern to a specific application. Given that 124 different applications layered on RTP may have some monitoring 125 requirements in common, these metrics should be satisfied by a common 126 design. 128 The objective of this document is to describe an extensible RTP 129 monitoring framework to provide a small number of re-usable Quality 130 of Service (QoS) / QoE metrics which facilitate reduced 131 implementation costs and help maximize inter-operability. The 132 "Guidelines for Extending the RTP Control Protocol (RTCP)" [RFC5968] 133 has stated that, where RTCP is to be extended with a new metric, the 134 preferred mechanism is by the addition of a new RTCP XR [RFC3611] 135 block. This memo assumes that any requirement for a new metric to be 136 transported in RTCP will use a new RTCP XR block. 138 2. Terminology 140 This memo is informative and as such contains no normative 141 requirements. 143 In addition, the following terms are defined: 145 Transport level metrics 147 A set of metrics which characterise the three transport 148 impairments of packet loss, packet delay, and packet delay 149 variation. These metrics should be usable by any application 150 which uses RTP transport. 152 Application level metrics 154 Metrics relating to application specific parameters or QoE related 155 parameters. Application specific parameters are measured at the 156 application level and focus on quality of content rather than 157 network performance. QoE related parameters reflect the end-to- 158 end performance at the services level and are ususally measured at 159 the user endpoint. One example of such metrics is the QoE Metric 160 specified in QoE metric reporting Block [QOE]. 162 End System metrics 164 Metrics relating to the way a terminal deals with transport 165 impairments affecting the incident RTP stream. These may include 166 de-jitter buffering, packet loss concealment, and the use of 167 redundant streams (if any) for correction of error or loss. 169 Direct metrics 171 Metrics that can be directly measured or calculated and are not 172 dependent on other metrics. 174 Composed metrics 176 Metrics that are not measured directly but rather are derived by 177 algorithmically combining one or more measured metrics. An 178 example is a metric derived based on direct metrics that have been 179 measured. 181 Interval metrics 183 Metrics measured over the course of a single reporting interval 184 between two successive report blocks. This may be the most recent 185 RTCP reporting interval ([RFC3550], section 6.2) or some other 186 interval signalled using an RTCP Measurement Information XR Block 187 [MEASI]. An example interval metric is the count of the number of 188 RTP packets lost over the course of the last RTCP reporting 189 interval. 191 Cumulative metrics 193 Metrics measured over several reporting intervals for accumulating 194 statistics. The time period over which measurements are 195 accumulated can be the complete RTP session, or some other 196 interval signalled using an RTCP Measurement Information XR Block 197 [MEASI]. An example cumulative metric is the total number of RTP 198 packets lost since the start of the RTP session. 200 Sampled metrics 202 Metrics measured at a particular time instant and sampled from the 203 values of a continuously measured or calculated metric within a 204 reporting interval (generally the value of some measurement as 205 taken at the end of the reporting interval). An example is the 206 inter-arrival jitter reported in RTCP SR and RR packets, which is 207 continually updated as each RTP data packet arrives, but only 208 reported based on a snapshot of the value which is sampled at the 209 instant the reporting interval ends. 211 3. RTP Monitoring Framework 213 There are many ways in which the performance of an RTP session can be 214 monitored. These include RTP-based mechanisms such as the RTP SNMP 215 MIB [RFC2959], or the SIP event package for RTCP summary reports 216 [RFC6035], or non-RTP mechanisms such as generic MIBs, NetFlow, 217 IPFix, and so on. Together, these provide useful mechanisms for 218 exporting data on the performance of an RTP session to non-RTP 219 network management systems. It is desirable to also perform in- 220 session monitoring of RTP performance. RTCP provides the means to do 221 this. In the following, we review the RTP Monitoring Framework, and 222 give guidance for using and extending RTCP for monitoring RTP 223 sessions. One major benefit of such framework is ease of integration 224 with other RTP/RTCP mechanisms. 226 3.1. Overview of the RTP Monitoring Framework 228 The RTP monitoring Framework comprises the following two key 229 functional components shown below: 231 o RTP Monitor 233 o RTP Metric Block 235 RTP Monitor is the functional component defined in the Real-time 236 Transport Protocol [RFC3550]. It acts as a repository of information 237 gathered for monitoring purposes. 239 According to the definition of monitor in the RTP Protocol [RFC3550], 240 the end system that runs an application program that sends or 241 receives RTP data packets, an intermediate-system that forwards RTP 242 packets to End-devices or a third party that observes the RTP and 243 RTCP traffic but does not make itself visible to the RTP Session 244 participants can play the role of the RTP monitor within the RTP 245 monitoring Framework. As shown in Figure 1, the third party RTP 246 monitor can be a passive monitor that sees the RTP/RTCP stream pass 247 it, or a system that gets sent RTCP reports but not RTP and uses that 248 to collect information. The third party RTP monitor should be placed 249 on the RTP/RTCP path between the sender, intermediate and the 250 receiver. 252 The RTP Metric Block (MB) conveys real time Application QoS/QoE 253 metric information and is used by the RTP monitor to exchange with 254 other RTP monitors in the appropriate report block format. The 255 information contained in the RTP MBs is collected by RTP monitors and 256 can be formulated as various types of metrics, e.g., direct metrics/ 257 composed metrics or interval metrics/ cumulative metrics/sampled 258 metrics, etc. Both the RTCP or RTCP XR can be extended to transport 259 these metrics, e.g., the basic RTCP Reception Report (RR) [RFC3550] 260 that conveys reception statistics (i.e., transport level statistics) 261 for multiple RTP media streams, the RTCP XRs [RFC3611] that 262 supplement the existing RTCP packets and provide more detailed 263 feedback on reception quality and RTCP NACK [RFC4585] that provides 264 feedback on the RTP sequence numbers for a subset of the lost packets 265 or all the currently lost packets. Ultimately the metric information 266 collected by RTP monitors within the RTP monitoring framework may go 267 to the network management tools beyond the RTP monitoring framework, 268 e.g., as shown Figure 1, the RTP monitors may export the metric 269 information derived from the RTP monitoring framework to the 270 management system using non-RTP means. 272 +-----------+ +----------+ 273 |Third Party| |Management| 274 |RTP Monitor| >>>>>>>>| System |<<<<< 275 +-----------+ ^ +----------+ ^ 276 : ^ ^ ^ 277 : | ^ ^ 278 +---------------+ : | +-------------+ +-------------+ 279 | +-----------+ | : | |+-----------+| |+-----------+| 280 | |RTP Monitor| |..:...|.......||RTP Monitor||........||RTP Monitor|| 281 | +-----------+ | | |+-----------+| |+-----------+| 282 | |------+------>| |------->| | 283 | RTP Sender | |RTP Mixer or | |RTP Receiver | 284 | | |Translator | | | 285 +---------------+ +-------------+ +-------------+ 287 ----> RTP media traffic 288 ..... RTCP control channel 289 >>>>> Non-RTP/RTCP management flows 291 Figure 1: Example showing the components of the RTP monitoring 292 framework 294 RTP may be used with multicast groups, both Any Source Multicast 295 (ASM) and Source Specific Multicast (SSM). These groups can be 296 monitored using RTCP. In the ASM case, the RTP monitor is a member 297 of the multicast group and listens to RTCP reports from all members 298 of the ASM group. In the SSM case, there is a unicast feedback 299 target that receives RTCP feedback from receivers and distributes it 300 to other members of the SSM group (see figure 1 of [RFC5760] ). The 301 RTP monitor will need to be co-located with the feedback target to 302 receive all feedback from the receivers (this may also be an 303 intermediate system). In both ASM and SSM scenarios, receivers can 304 send RTCP reports to enhance the reception quality reporting. 306 3.2. Location of RTP Monitors 308 As shown in the Figure 1, there are several possible locations from 309 where RTP sessions can be monitored. These include end-systems that 310 terminate RTP sessions, intermediate-systems that are an active part 311 of an RTP session, and third-party devices that passively monitor an 312 RTP session. Not every RTP sessions will include monitoring, and 313 those sessions that are monitored will not all include each type of 314 monitor. The performance metrics collected by RTP monitors can be 315 divided into end system metrics, application level metrics, and 316 transport level metrics. Some of these metrics may be specific to 317 the measurement point of the RTP monitor, or depend on where the RTP 318 monitors are located in the network, while others are more general 319 and can be collected in any monitoring location. 321 End-system monitoring is monitoring that is deployed on devices that 322 terminate RTP flows. Flows can be terminated in user equipment, such 323 as phones, video conferencing systems, or IPTV set-top boxes. 324 Alternatively, they can be terminated in devices that gateway between 325 RTP and other transport protocols. Transport and end system metrics, 326 application level metrics that don't reflect end to end user 327 experience may be collected at all types of end system, but some 328 application level metrics (i.e.,quality of experience (QoE) metrics) 329 may only be applicable for user-facing end systems. 331 RTP sessions can include intermediate-systems that are an active part 332 of the system. These intermediate-systems include RTP mixers and 333 translators, MCUs, retransmission servers, etc. If the intermediate- 334 system establishes separate RTP sessions to the other participants, 335 then it must act as an end system in each of those separate RTP 336 sessions for the purposes of monitoring. If a single RTP session 337 traverses the intermediate-system, then the intermediate-system can 338 be assigned an SSRC in that session which it can use for it's 339 reports. Transport level metrics may be collected at such 340 intermediate-system. 342 Third-party monitors may be deployed that passively monitor RTP 343 sessions for network management purposes. Third-party monitors often 344 do not send reports into the RTP session being monitored, but instead 345 collect transport and end system metrics, application level metrics 346 that are reported via some network management application. In some 347 cases, however, third-party monitors can send reports to some or all 348 participants in the session being monitored. For example, in a media 349 streaming scenario, third-party monitors may be deployed that 350 passively monitor the session and send reception quality reports to 351 the media source, but not to the receivers. 353 4. Issues with reporting metric block using RTCP XR extension 355 The following sections discuss four issues that have come up in the 356 past with reporting metric block using RTCP XR extensions. 358 4.1. Using compound metrics block 360 A compound metrics block is designed to contain a large number of 361 parameters from different classes for a specific application in a 362 single block. For example, the RTCP Extended Reports (XRs) [RFC3611] 363 defines seven report block formats for network management and quality 364 monitoring. Some of these block types defined in the RTCP XRs 365 [RFC3611] are only specifically designed for conveying multicast 366 inference of network characteristics (MINC) or voice over IP (VoIP) 367 monitoring. However different applications layered on RTP may have 368 different monitoring requirements. Designing compound metrics block 369 only for specific applications may increase implementation cost and 370 minimize interoperability. 372 4.2. Correlating RTCP XR with the non-RTP data 374 Canonical End-Point Identifier SDES Item (CNAME), defined in the RTP 375 Protocol [RFC3550], is an example of an existing tool that allows 376 binding a Synchronization source (SSRC) that may change to a name 377 that is fixed within one RTP session. CNAME may be also fixed across 378 multiple RTP sessions from the same source. However there may be 379 situations where RTCP reports are sent to other participating 380 endpoints using non-RTP protocol in a session. For example, as 381 described in the SIP RTCP Summary Report Protocol [RFC6035], the data 382 contained in RTCP XR VoIP metrics reports [RFC3611] are forwarded to 383 a central collection server systems using SIP. In such case, there 384 is a large portfolio of quality parameters that can be associated 385 with real time application, e.g., VOIP application, but only a 386 minimal number of parameters are included on the RTCP-XR reports. 387 With these minimal number of RTCP statistics parameters mapped to 388 non-RTCP measurements, it is hard to provide accurate measures of 389 real time application quality, conduct detailed data analysis and 390 creates alerts timly to the users. Therefore correlation between 391 RTCP XR and non-RTP data should be provided. 393 4.3. Measurement Information duplication 395 We may set a measurement interval for the session and monitor RTP 396 packets within one or several consecutive report intervals. In such 397 case, the extra measurement information (e.g., extended sequence 398 number of 1st packet, measurement period) may be expected. However 399 if we put such extra measurement information into each metric block, 400 there may be situations where an RTCP XR packet containing multiple 401 metric blocks, reports on the same streams from the same source. In 402 other words, duplicated data for the measurement is provided multiple 403 times, once in every metric block. Though this design ensures 404 immunity to packet loss, it may bring more packetization complexity 405 and the processing overhead is not completely trivial in some cases. 406 Therefore compromise between processing overhead and reliability 407 should be taken into account. 409 4.4. Consumption of XR block code points 411 The RTCP XR block namespace is limited by the 8-bit block type field 412 in the RTCP XR header. Space exhaustion may be a concern in the 413 future. Anticipating the potential need to extend the block type 414 space, it is noted that Block Type 255 is reserved for future 415 extensions in [RFC3611]. 417 5. Guidelines for reporting metric block using RTCP XR 419 5.1. Contain the single metrics in the Metric Block 421 Different applications using RTP for media transport certainly have 422 differing requirements for metrics transported in RTCP to support 423 their operation. For many applications, the basic metrics for 424 transport impairments provided in RTCP SR and RR packets [RFC3550] 425 (together with source identification provided in RTCP SDES packets) 426 are sufficient. For other applications additional metrics may be 427 required or at least sufficiently useful to justify the overhead, 428 both of processing in endpoints and of increased session bandwidth. 429 For example an IPTV application using Forward Error Correction (FEC) 430 might use either a metric of post-repair loss or a metric giving 431 detailed information about pre-repair loss bursts to optimise payload 432 bandwidth and the strength of FEC required for changing network 433 conditions. However there are many metrics available. It is likely 434 that different applications or classes of applications will wish to 435 use different metrics. Any one application is likely to require 436 metrics for more than one parameter but if this is the case, 437 different applications will almost certainly require different 438 combinations of metrics. If larger blocks are defined containing 439 multiple metrics to address the needs of each application, it becomes 440 likely that many different such larger blocks are defined, which 441 becomes a danger to interoperability. 443 To avoid this pitfall, this memo recommends the definition of metrics 444 blocks containing a very small number of individual metrics 445 characterizing only one parameter of interest to an application 446 running over RTP. For example, at the RTP transport layer, the 447 parameter of interest might be packet delay variation, and 448 specifically the metric "IP Packet Delay Variation (IPDV)" defined by 449 [Y1540]. See Section 6 for architectural considerations for a 450 metrics block, using as an example a metrics block to report packet 451 delay variation. Further, it is appropriate to not only define 452 report blocks separately, but also to do so in separate documents 453 where possible. This makes it easier to evolve the reports (i.e., to 454 update each type of report block separately), and also makes it 455 easier to require compliance with a particular report block. 457 5.2. Include the payload type in the Metric Block 459 There are some classes of metrics that can only be interpreted with 460 knowledge of the media codec that is being used (audio mean opinion 461 scores (MOS) were the triggering example, but there may be others). 462 In such cases the correlation of RTCP XR with RTP data is needed. 463 Report blocks that require such correlation need to include the 464 payload type of the reported media. In addition, it is necessary to 465 signal the details and parameters of the payload format to which that 466 payload type is bound using some out-of-band means (e.g., as part of 467 an SDP offer/answer exchange). 469 5.3. Use RTCP SDES to correlate XR reports with non-RTP data 471 There may be situations where more than one media transport protocol 472 is used by one application to interconnect to the same session in the 473 gateway. For example, one RTCP XR Packet is sent to the 474 participating endpoints using non-RTP-based media transport (e.g., 475 using SIP) in a VOIP session. One crucial factor lies in how to 476 handle their different identities that are corresponding to different 477 media transport. 479 This memo recommends an approach to facilitate the correlation of the 480 RTCP Session with other session-related non-RTP data. That is to say 481 if there is a need to correlate RTP sessions with non-RTP sessions, 482 then the correlation information needed should be conveyed in a new 483 RTCP Source Description (SDES) item, since such correlation 484 information describes the source, rather than providing a quality 485 report. An example use case is for a participant endpoint may convey 486 a call identifier or a global call identifier associated with the 487 SSRC of measured RTP stream. In such case, the participant endpoint 488 uses the SSRC of source to bind the call identifier using SDES item 489 in the SDES RTCP packet and send such correlation to the network 490 management system. A flow measurement tool that is configured with 491 the 5-tuple and not call-aware then forward the RTCP XR reports along 492 with the SSRC of the measured RTP stream which is included in the XR 493 Block header and 5-tuple to the network management system. Network 494 management system can then correlate this report using SSRC with 495 other diagnostic information such as call detail records. 497 5.4. Reduce Measurement information repetition across metric blocks 499 When multiple metric blocks are carried in one RTCP XR packet, 500 reporting on the same stream from the same source for the same time 501 period, RTCP should use the SSRC to identify and correlate the 502 multiple metric blocks between metric blocks. Measurement Identity 503 and information Reporting using SDES item and XR Block" 504 [MEASI]enables an RTCP sender to convey the common time period and 505 the number of packets sent during this period. If the measurement 506 interval for a metric is different from the RTCP reporting interval, 507 then this measurement duration in the Measurement information block 508 should be used to specify the interval. When there may be multiple 509 measurements information blocks with the same SSRC in one RTCP XR 510 compound packet, the measurement information block should be put in 511 order and followed by all the metric blocks associated with this 512 measurement information block. New RTCP XR metric blocks that rely 513 on the Measurement information block [MEASI] must specify the 514 response in case the new RTCP XR metric block is received without an 515 associated measurement information block. In most cases, it is 516 expected that the correct response is to discard the received metric. 517 In order to reduce measurement information repetition in one RTCP XR 518 compound packet containing multiple metric blocks, the measurement 519 information shall be sent before the related metric blocks that are 520 from the same reporting interval. Note that for packet loss 521 robustness if the report blocks for the same interval span over more 522 than one RTCP packet, then each must have the measurement identity 523 information even though they will be the same. 525 6. An example of a metric block 527 This section uses the example of an existing proposed metrics block 528 to illustrate the application of the principles set out in 529 Section 5.1. 531 The example [PDV] is a block to convey information about packet delay 532 variation (PDV) only, consistent with the principle that a metrics 533 block should address only one parameter of interest. One simple 534 metric of PDV is available in the RTCP RR packet as the "interarrival 535 jitter" field. There are other PDV metrics with a certain similarity 536 in metric structure which may be more useful to certain applications. 537 Two such metrics are the IPDV metric ([Y1540], [RFC3393]) and the 538 mean absolute packet delay variation 2 (MAPDV2) metric [G1020]. Use 539 of these metrics is consistent with the principle in Section 5 of 540 RTCP guideline [RFC5968] that metrics should usually be defined 541 elsewhere, so that RTCP standards define only the transport of the 542 metric rather than its nature. The purpose of this section is to 543 illustrate the architectural consideration using the example of [PDV] 544 rather than to document the design of the PDV metrics block or to 545 provide a tutorial on PDV in general. 547 Given the availability of at least three metrics for PDV, there are 548 design options for the allocation of metrics to RTCP XR blocks: 550 o provide an RTCP XR block per metric 552 o provide a single RTCP XR block which contains all three metrics 554 o provide a single RTCP block to convey any one of the three 555 metrics, together with a identifier to inform the receiving RTP 556 system of the specific metric being conveyed 558 In choosing between these options, extensibility is important, 559 because additional metrics of PDV may well be standardized and 560 require inclusion in this framework. The first option is extensible 561 but only by use of additional RTCP XR blocks, which may consume the 562 limited namespace for RTCP XR blocks at an unacceptable rate. The 563 second option is not extensible, so could be rejected on that basis, 564 but in any case a single application is quite unlikely to require 565 transport of more than one metric for PDV. Hence the third option 566 was chosen. This implies the creation of a subsidiary namespace to 567 enumerate the PDV metrics which may be transported by this block, as 568 discussed further in [PDV]. 570 7. Application to RFC 5117 topologies 572 The topologies specified in [RFC5117] fall into two categories. The 573 first category relates to the RTP system model utilizing multicast 574 and/or unicast. The topologies in this category are specifically 575 Topo-Point-to-Point, Topo- Multicast, Topo-Translator (both variants, 576 Topo-Trn-Translator and Topo-Media-Translator, and combinations of 577 the two), and Topo-Mixer. These topologies use RTP end systems, RTP 578 mixers and RTP translators defined in the RTP protocol [RFC3550]. 579 For purposes of reporting connection quality to other RTP systems, 580 RTP mixers and RTP end systems are very similar. Mixers 581 resynchronize packets and do not relay RTCP reports received from one 582 cloud towards other cloud(s). Translators do not resynchronize 583 packets and should forward certain RTCP reports between clouds. In 584 this category, the RTP system (end system, mixer or translator) which 585 originates, terminates or forwards RTCP XR blocks is expected to 586 handle RTCP, including RTCP XR, according to the RTP protocol 587 [RFC3550]. Provided this expectation is met, an RTP system using 588 RTCP XR is architecturally no different from an RTP system of the 589 same class (end system, mixer, or translator) which does not use RTCP 590 XR. The second category relates to deployed system models used in 591 many H.323 [H323] video conferences. The topologies in this category 592 are Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU. Such 593 topologies based on systems (e.g.,MCUs) do not behave according to 594 the RTP protocol [RFC3550]. 596 Considering the translator and MCU are two typical intermediate- 597 systems in these two categories mentioned above, this document will 598 take them as two typical examples to explain how RTCP XR report works 599 in different RFC5117 topologies. 601 7.1. Applicability to Translators 603 Section 7.2 of the RTP protocol [RFC3550] describes processing of 604 RTCP by translators. RTCP XR is within the scope of the 605 recommendations of the RTP protocol [RFC3550]. Some RTCP XR metrics 606 blocks may usefully be measured at, and reported by, translators. As 607 described in the RTP protocol [RFC3550] this creates a requirement 608 for the translator to allocate an SSRC for the monitor collocated 609 with itself so that the monitor may populate the SSRC in the RTCP XR 610 packet header as packet sender SSRC and send it out(although the 611 translator is not a Synchronisation Source in the sense of 612 originating RTP media packets). It must also supply this SSRC and 613 the corresponding CNAME in RTCP SDES packets. 615 In RTP sessions where one or more translators generate any RTCP 616 traffic towards their next-neighbour RTP system, other translators in 617 the session have a choice as to whether they forward a translator's 618 RTCP packets. Forwarding may provide additional information to other 619 RTP systems in the connection but increases RTCP bandwidth and may in 620 some cases present a security risk. RTP translators may have 621 forwarding behaviour based on local policy, which might differ 622 between different interfaces of the same translator. 624 7.2. Applicability to MCU 626 Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU, suffer from the 627 difficulties described in [RFC5117]. These difficulties apply to 628 systems sending, and expecting to receive, RTCP XR blocks as much as 629 to systems using other RTCP packet types. For example, a participant 630 RTP end system may send media to a video switch MCU. If the media 631 stream is not selected for forwarding by the switch, neither RTCP RR 632 packets nor RTCP XR blocks referring to the end system's generated 633 stream will be received at the RTP end system. Strictly the RTP end 634 system can only conclude that its RTP has been lost in the network, 635 though an RTP end system complying with the robustness principle of 636 [RFC1122] should survive with essential functions (i.e.,media 637 distribution) unimpaired. 639 8. IANA Considerations 641 There is no IANA action in this document. 643 9. Security Considerations 645 This document focuses on the RTCP reporting extension using RTCP XR 646 and should not give rise to any new security vulnerabilities beyond 647 those described in RTCP XRs [RFC3611]. However it also describes the 648 architectural framework to be used for monitoring at RTP layer. The 649 security issues with monitoring needs to be considered. 651 In RTP sessions, a RTP system may use its own SSRC to send its 652 monitoring reports towards its next-neighbour RTP system. Other RTP 653 system in the session may have a choice as to whether they forward 654 this RTP system's RTCP packets. This present a security issue since 655 the information in the report may be exposed by the other RTP system 656 to any malicious node. Therefore if the information is considered as 657 sensitive, the monitoring report should be encrypted. 659 10. Acknowledgement 661 The authors would also like to thank Colin Perkins, Charles Eckel, 662 Robert Sparks, Salvatore Loreto, Graeme Gibbs, Debbie Greenstreet, 663 Keith Drage, Dan Romascanu, Ali C. Begen, Roni Even, Magnus 664 Westerlund for their valuable comments and suggestions on the early 665 version of this document. 667 11. Informative References 669 [G1020] ITU-T, "ITU-T Rec. G.1020, Performance parameter 670 definitions for quality of speech and other voiceband 671 applications utilizing IP networks", July 2006. 673 [H323] ITU-T, "ITU-T Rec. H.323, Packet-based multimedia 674 communications systems", June 2006. 676 [MEASI] Wu, Q., "Measurement Identity and information Reporting 677 using SDES item and XR Block", 678 ID draft-ietf-xrblock-rtcp-xr-meas-identity-07, June 2012. 680 [P.NAMS] ITU-T, "Non-intrusive parametric model for the Assessment 681 of performance of Multimedia Streaming", ITU-T 682 Recommendation P.NAMS, November 2009. 684 [PDV] Hunt, G., Clark, A., and Q. Wu, "RTCP XR Report Block for 685 Packet Delay Variation Metric Reporting", 686 ID draft-ietf-xrblock-rtcp-xr-pdv-03, May 2012. 688 [QOE] Hunt, G., Clark, A., Wu, Q., Schott, R., and G. Zorn, 689 "RTCP XR Blocks for QoE Metric Reporting", 690 ID draft-ietf-xrblock-rtcp-xr-qoe-01, May 2012. 692 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 693 Communication Layers", RFC 1122, October 1989. 695 [RFC2959] Baugher, M., Strahm, B., and I. Suconick, "Real-Time 696 Transport Protocol Management Information Base", RFC 2959, 697 October 2000. 699 [RFC3393] Demichelis, C., "IP Packet Delay Variation Metric for IP 700 Performance Metrics (IPPM)", RFC 3393, November 2002. 702 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 703 Applications", RFC 3550, July 2003. 705 [RFC3611] Friedman, T., "RTP Control Protocol Extended Reports (RTCP 706 XR)", RFC 3611, November 2003. 708 [RFC4585] Ott, J. and S. Wenger, "Extended RTP Profile for Real-time 709 Transport Control Protocol (RTCP)-Based Feedback (RTP/ 710 AVPF)", RFC 4585, July 2006. 712 [RFC5117] Westerlund, M., "RTP Topologies", RFC 5117, January 2008. 714 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 715 Protocol (RTCP) Extensions for Single-Source Multicast 716 Sessions with Unicast Feedback", RFC 5760, February 2010. 718 [RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP 719 Control Protocol (RTCP)", RFC 5968, September 2010. 721 [RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, 722 "Session Initiation Protocol Event Package for Voice 723 Quality Reporting", RFC 6035, November 2010. 725 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 726 Performance Metric Development", RFC 6390, October 2011. 728 [Y1540] ITU-T, "ITU-T Rec. Y.1540, IP packet transfer and 729 availability performance parameters", November 2007. 731 Appendix A. Change Log 733 Note to the RFC-Editor: please remove this section prior to 734 publication as an RFC. 736 A.1. draft-ietf-avtcore-monarch-17 738 The following are the major changes compared to 16: 740 o Some Editorial changes. 742 A.2. draft-ietf-avtcore-monarch-16 744 The following are the major changes compared to 15: 746 o A few modification to the figure 1. 748 o Change RTCP XR reports into RTCP reports in the section 3.1. 750 o References Update. 752 A.3. draft-ietf-avtcore-monarch-15 754 The following are the major changes compared to 14: 756 o Add figure 1 in section 3 to describe RTP monitoring framework. 758 o Change the title as Guidelines for Use of the RTP Monitoring 759 Framework. 761 o Other editorial change to get in line with the title change in the 762 section 3. 764 A.4. draft-ietf-avtcore-monarch-14 766 The following are the major changes compared to 13: 768 o Incorporate the key points in the section 3.2 into overview 769 section. 771 o Remove the figure 1 and use the description instead. 773 o Add description in the section 3.3 to discuss the possible 774 location of the monitors and the types of metric at that location. 776 o Add the description to make the definition of Interval metrics/ 777 cumulative metrics/sampled metrics clear. 779 o Editorial Changes. 781 A.5. draft-ietf-avtcore-monarch-13 783 The following are the major changes compared to 12: 785 o Editorial Changes. 787 A.6. draft-ietf-avtcore-monarch-12 789 The following are the major changes compared to 11: 791 o Editorial Changes based on Charles' Comments. 793 o Reference update. 795 o Add one new section 5.2 to discuss Correlating RTCP XR with RTP 796 data. 798 o Add text in section 5.1 to highlight it is more appropriate to 799 define each block in a separate draft. 801 A.7. draft-ietf-avtcore-monarch-11 803 The following are the major changes compared to 10: 805 o Editorial Changes. 807 A.8. draft-ietf-avtcore-monarch-10 809 The following are the major changes compared to 09: 811 o Discuss what exist already for monitoring in section 3.1. 813 o Provide benefit using RTCP XR based monitoring in section 3.1. 815 o add one new paragraph in section 3.1 to describe how monitoring 816 architecture is applied to ASM/SSM. 818 o Other Editorial Changes. 820 A.9. draft-ietf-avtcore-monarch-09 822 The following are the major changes compared to 07: 824 o Rephrase application level metric definition. 826 o Add one new section to clarify where to measure QoE related 827 parameters. 829 o Add text in section 5.3 to clarify the failure case when 830 measurement interval is not sent. 832 o Add text in section 5.3 to clarify how to deal with multiple 833 measurements information blocks carried in the same packet. 835 A.10. draft-ietf-avtcore-monarch-08 837 The following are the major changes compared to 07: 839 o Editorial change to the reference. 841 A.11. draft-ietf-avtcore-monarch-07 843 The following are the major changes compared to 06: 845 o Clarify the XR block code points consumption issue in the section 846 4 and new section 5.4. 848 o Other editorial changes. 850 A.12. draft-ietf-avtcore-monarch-06 852 The following are the major changes compared to 05: 854 o Some editorial changes. 856 A.13. draft-ietf-avtcore-monarch-05 858 The following are the major changes compared to 04: 860 o Replace "chunk" with "new SDES item". 862 o Add texts in security section to discussion potential security 863 issues. 865 o Add new sub-section 5.3 to discuss Reducing Measurement 866 information repetition. 868 o Other editorial changes. 870 A.14. draft-ietf-avtcore-monarch-04 872 The following are the major changes compared to 03: 874 o Update section 5.2 to clarify using SDES packet to carry 875 correlation information. 877 o Remove section 5.3 since additional identity information goes to 878 SDES packet and using SSRC to identify each block is standard RTP 879 feature. 881 o Swap the last two paragraphs in the section 4 since identity 882 information duplication can not been 100% avoided. 884 o Other editorial changes. 886 A.15. draft-ietf-avtcore-monarch-03 888 The following are the major changes compared to 02: 890 o Update bullet 2 in section 4 to explain the ill-effect of Identity 891 Information duplication. 893 o Update bullet 3 in section 4 to explain why Correlating RTCP XR 894 with the non-RTP data is needed. 896 o Update section 5.2 to focus on how to reduce the identity 897 information repetition 899 o Update section 5.3 to explain how to correlate identity 900 information with the non-RTP data 902 A.16. draft-ietf-avtcore-monarch-02 904 The following are the major changes compared to 01: 906 o Deleting first paragraph of Section 1. 908 o Deleting Section 3.1, since the interaction with the management 909 application is out of scope of this draft. 911 o Separate identity information correlation from section 5.2 as new 912 section 5.3. 914 o Remove figure 2 and related text from section 5.2. 916 o Editorial changes in the section 4 and the first paragraph of 917 section 7. 919 A.17. draft-ietf-avtcore-monarch-01 921 The following are the major changes compared to 00: 923 o Restructure the document by merging section 4 into section 3. 925 o Remove section 4.1,section 5 that is out of scope of this 926 document. 928 o Remove the last bullet in section 6 and section 7.3 based on 929 conclusion of last meeting. 931 o Update figure 1 and related text in section 3 according to the 932 monitor definition in RFC3550. 934 o Revise section 9 to address monitor declaration issue. 936 o Merge the first two bullet in section 6. 938 o Add one new bullet to discuss metric block association in section 939 6. 941 A.18. draft-ietf-avtcore-monarch-00 943 The following are the major changes compared to 944 draft-hunt-avtcore-monarch-02: 946 o Move Geoff Hunt and Philip Arden to acknowledgement section. 948 Authors' Addresses 950 Qin Wu (editor) 951 Huawei 952 101 Software Avenue, Yuhua District 953 Nanjing, Jiangsu 210012 954 China 956 Email: sunseawq@huawei.com 958 Geoff Hunt 959 Unaffiliated 961 Email: r.geoff.hunt@gmail.com 963 Philip Arden 964 BT 965 Orion 3/7 PP4 966 Adastral Park 967 Martlesham Heath 968 Ipswich, Suffolk IP5 3RE 969 United Kingdom 971 Phone: +44 1473 644192 972 Email: philip.arden@bt.com