idnits 2.17.1 draft-ietf-avtcore-monarch-22.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 655: '...nitoring reports SHOULD be secured to ...' RFC 2119 keyword, line 661: '...erwise, the third party monitor SHOULD...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 25, 2012) is 4224 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-xrblock-rtcp-xr-pdv-05 -- Obsolete informational reference (is this intentional?): RFC 5101 (Obsoleted by RFC 7011) -- Obsolete informational reference (is this intentional?): RFC 5102 (Obsoleted by RFC 7012) -- Obsolete informational reference (is this intentional?): RFC 5117 (Obsoleted by RFC 7667) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 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: March 29, 2013 Unaffiliated 6 P. Arden 7 BT 8 September 25, 2012 10 Guidelines for Use of the RTP Monitoring Framework 11 draft-ietf-avtcore-monarch-22.txt 13 Abstract 15 This memo proposes an extensible Real-Time Protocol (RTP) monitoring 16 framework for extending RTP Control Protocol (RTCP) with a new RTCP 17 Extended Reports (XR) block type to report new metrics regarding 18 media transmission or reception quality. In this framework, a new XR 19 block should contain a single metric or a small number of metrics 20 relevant to a single parameter of interest or concern, rather than 21 containing a number of metrics which attempt to provide full coverage 22 of all those parameters of concern to a specific application. 23 Applications may then "mix and match" to create a set of blocks which 24 covers their set of concerns. Where possible, a specific block 25 should be designed to be re-usable across more than one application, 26 for example, for 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 March 29, 2013. 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 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-22 . . . . . . . . . . . . . . 23 88 A.2. draft-ietf-avtcore-monarch-20 . . . . . . . . . . . . . . 23 89 A.3. draft-ietf-avtcore-monarch-19 . . . . . . . . . . . . . . 23 90 A.4. draft-ietf-avtcore-monarch-18 . . . . . . . . . . . . . . 23 91 A.5. draft-ietf-avtcore-monarch-17 . . . . . . . . . . . . . . 23 92 A.6. draft-ietf-avtcore-monarch-16 . . . . . . . . . . . . . . 24 93 A.7. draft-ietf-avtcore-monarch-15 . . . . . . . . . . . . . . 24 94 A.8. draft-ietf-avtcore-monarch-14 . . . . . . . . . . . . . . 24 95 A.9. draft-ietf-avtcore-monarch-13 . . . . . . . . . . . . . . 24 96 A.10. draft-ietf-avtcore-monarch-12 . . . . . . . . . . . . . . 25 97 A.11. draft-ietf-avtcore-monarch-11 . . . . . . . . . . . . . . 25 98 A.12. draft-ietf-avtcore-monarch-10 . . . . . . . . . . . . . . 25 99 A.13. draft-ietf-avtcore-monarch-09 . . . . . . . . . . . . . . 25 100 A.14. draft-ietf-avtcore-monarch-08 . . . . . . . . . . . . . . 26 101 A.15. draft-ietf-avtcore-monarch-07 . . . . . . . . . . . . . . 26 102 A.16. draft-ietf-avtcore-monarch-06 . . . . . . . . . . . . . . 26 103 A.17. draft-ietf-avtcore-monarch-05 . . . . . . . . . . . . . . 26 104 A.18. draft-ietf-avtcore-monarch-04 . . . . . . . . . . . . . . 26 105 A.19. draft-ietf-avtcore-monarch-03 . . . . . . . . . . . . . . 27 106 A.20. draft-ietf-avtcore-monarch-02 . . . . . . . . . . . . . . 27 107 A.21. draft-ietf-avtcore-monarch-01 . . . . . . . . . . . . . . 27 108 A.22. draft-ietf-avtcore-monarch-00 . . . . . . . . . . . . . . 28 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 111 1. Introduction 113 Multimedia services using the Real-Time Protocol (RTP) are seeing 114 increased use. Standard methods for gathering RTP performance 115 metrics from these applications are needed to manage uncertainties in 116 the behavior and availability of their services. Standards , such as 117 RTP Control Protocol Extended Reports (RTCP XR)[RFC3611] and other 118 RTCP extension to Sender Reports (SR), Receiver Reports (RR) 119 [RFC3550] are being developed for the purpose of collecting and 120 reporting performance metrics from endpoint devices that can be used 121 to correlate the metrics, provide end to end service visibility and 122 measure and monitor Quality of Experience (QoE) [RFC6390]. 124 However the proliferation of RTP/RTCP specific metrics for transport 125 and application quality monitoring has been identified as a potential 126 problem for interoperability when using RTP/RTCP to communicate all 127 the parameters of concern to a specific application. Given that 128 different applications layered on RTP may have some monitoring 129 requirements in common, these metrics should be satisfied by a common 130 design. 132 The objective of this document is to describe an extensible RTP 133 monitoring framework to provide a small number of re-usable Quality 134 of Service (QoS) / QoE metrics which facilitate reduced 135 implementation costs and help maximize inter-operability. The 136 "Guidelines for Extending the RTP Control Protocol (RTCP)" [RFC5968] 137 has stated that, where RTCP is to be extended with a new metric, the 138 preferred mechanism is by the addition of a new RTCP XR [RFC3611] 139 block. This memo assumes that all the guidelines from RFC 5968 must 140 apply on top of the guidelines in this document. Guidelines for 141 developing new performance metrics are specified in [RFC6390]. New 142 RTCP XR report block definitions should not define new performance 143 metrics, but should rather refer to metrics defined elsewhere. 145 2. Terminology 147 This memo is informative and as such contains no normative 148 requirements. 150 In addition, the following terms are defined: 152 Transport level metrics 154 A set of metrics which characterise the three transport 155 impairments of packet loss, packet delay, jitter (also known as 156 delay variation). These metrics should be usable by any 157 application which uses RTP transport. 159 Application level metrics 161 Metrics relating to application specific parameters or QoE related 162 parameters. Application specific parameters are measured at the 163 application level and focus on quality of content rather than 164 network performance. QoE related parameters reflect the end-to- 165 end performance at the services level and are usually measured at 166 the user endpoint. One example of such metrics is the QoE Metric 167 specified in QoE metric reporting Block [QOE_BLOCK]. 169 End System metrics 171 Metrics relating to the way a terminal deals with transport 172 impairments affecting the incident RTP stream. These may include 173 de-jitter buffering, packet loss concealment, and the use of 174 redundant streams (if any) for correction of error or loss. 176 Direct metrics 178 Metrics that can be directly measured or calculated and are not 179 dependent on other metrics. 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 MIB 215 module [RFC2959], or the Session Initiation Protocol (SIP) event 216 package for RTCP summary reports [RFC6035], or non-RTP mechanisms 217 such as generic MIBs, NetFlow [RFC3954], IPFIX [RFC5101][RFC5102], 218 and so on. Together, these provide useful mechanisms for exporting 219 data on the performance of an RTP session to non-RTP network 220 management systems. It is desirable to also perform in-session 221 monitoring of RTP performance. RTCP provides the means to do this. 222 In the following, we review the RTP Monitoring Framework, and give 223 guidance for using and extending RTCP for monitoring RTP sessions. 224 One major benefit of such framework is ease of integration with other 225 RTP/RTCP mechanisms. 227 3.1. Overview of the RTP Monitoring Framework 229 The RTP monitoring Framework comprises the following two key 230 functional components described below: 232 o Monitor 234 o RTP Metric Block 236 Monitor is the functional component defined in the Real-time 237 Transport Protocol [RFC3550]. It acts as a repository of information 238 gathered for monitoring purposes. 240 According to the definition of monitor in the RTP Protocol [RFC3550], 241 the end system that runs an application program that sends or 242 receives RTP data packets, an intermediate-system that forwards RTP 243 packets to End-devices or a third party that observes the RTP and 244 RTCP traffic but does not make itself visible to the RTP Session 245 participants can play the role of the monitor within the RTP 246 monitoring Framework. As shown in Figure 1, the third party monitor 247 can be a passive monitor that sees the RTP/RTCP stream pass it, or a 248 system that gets sent RTCP reports but not RTP and uses that to 249 collect information. The third party monitor should be placed on the 250 RTP/RTCP path between the sender, intermediate and the receiver. 252 The RTP Metric Block (MB) conveys real time Application QoS/QoE 253 metric information and is used by the monitor to exchange with other 254 monitors in the appropriate report block format. The information 255 contained in the RTP MBs is collected by monitors and can be 256 formulated as various types of metrics, e.g., direct metrics/composed 257 performance metrics [RFC6390]or interval metrics/ cumulative metrics/ 258 sampled metrics, etc. Both the RTCP or RTCP XR can be extended to 259 transport these metrics, e.g., the basic RTCP Reception Report (RR) 260 [RFC3550] that conveys reception statistics (i.e., transport level 261 statistics) for multiple RTP media streams, the RTCP XRs [RFC3611] 262 that 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 monitors within the RTP monitoring framework may go to 267 the network management tools beyond the RTP monitoring framework, 268 e.g., as shown Figure 1, the 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 | Monitor | >>>>>>>>| System |<<<<< 275 +-----------+ ^ +----------+ ^ 276 : ^ ^ ^ 277 : | ^ ^ 278 +---------------+ : | +-------------+ +-------------+ 279 | +-----------+ | : | |+-----------+| |+-----------+| 280 | | Monitor | |..:...|.......|| Monitor ||........|| 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 monitor is a member of 297 the multicast group and listens to RTCP reports from all members of 298 the ASM group. In the SSM case, there is a unicast feedback target 299 that receives RTCP feedback from receivers and distributes it to 300 other members of the SSM group (see Figure 1 of [RFC5760] ). The 301 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 Monitors 308 As shown in Figure 1, there are several possible locations from where 309 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 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 monitor, or depend on where the monitors 318 are located in the network, while others are more general and can be 319 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, Multipoint Control Units (MCUs), retransmission servers, 334 etc. If the intermediate-system establishes separate RTP sessions to 335 the other participants, then it must act as an end system in each of 336 those separate RTP sessions for the purposes of monitoring. If a 337 single RTP session traverses the intermediate-system, then the 338 intermediate-system can be assigned an Synchronization source (SSRC) 339 in that session which it can use for its reports. Transport level 340 metrics may be collected at such 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 level metrics, end system metrics and application 346 level metrics. In some cases, however, third-party monitors can send 347 reports to some or all participants in the session being monitored. 348 For example, in a media streaming scenario, third-party monitors may 349 be deployed that passively monitor the session and send reception 350 quality reports to the media source, but not to the receivers. 352 4. Issues With Reporting Metric Block Using RTCP XR Extension 354 The following sections discuss four issues that have come up in the 355 past with reporting metric block using RTCP XR extensions. 357 4.1. Using compound metrics block 359 A compound metrics block is designed to contain a large number of 360 parameters from different classes for a specific application in a 361 single block. For example, the RTCP Extended Reports (XRs) [RFC3611] 362 defines seven report block formats for network management and quality 363 monitoring. Some of these block types defined in the RTCP XRs 364 [RFC3611] are only specifically designed for conveying multicast 365 inference of network characteristics (MINC) or voice over IP (VoIP) 366 monitoring. However different applications layered on RTP may have 367 different monitoring requirements. Designing compound metrics block 368 only for specific applications may increase implementation cost and 369 minimize interoperability. 371 4.2. Correlating RTCP XR with the non-RTP data 373 Canonical End-Point Identifier SDES Item (CNAME), defined in the RTP 374 Protocol [RFC3550], is an example of an existing tool that allows 375 binding an SSRC that may change to a name that is fixed within one 376 RTP session. CNAME may be also fixed across multiple RTP sessions 377 from the same source. However there may be situations where RTCP 378 reports are sent to other participating endpoints using non-RTP 379 protocol in a session. For example, as described in the SIP RTCP 380 Summary Report Protocol [RFC6035], the data contained in RTCP XR VoIP 381 metrics reports [RFC3611] are forwarded to a central collection 382 server systems using SIP. In such case, there is a large portfolio 383 of quality parameters that can be associated with real time 384 application, e.g., VOIP application, but only a minimal number of 385 parameters are included on the RTCP-XR reports. With these minimal 386 number of RTCP statistics parameters mapped to non-RTCP measurements, 387 it is hard to provide accurate measures of real time application 388 quality, conduct detailed data analysis and creates alerts timely to 389 the users. Therefore correlation between RTCP XR and non-RTP data 390 should be provided. 392 4.3. Measurement Information duplication 394 We may set a measurement interval for the session and monitor RTP 395 packets within one or several consecutive report intervals. In such 396 case, the extra measurement information (e.g., extended sequence 397 number of 1st packet, measurement period) may be expected. However 398 if we put such extra measurement information into each metric block, 399 there may be situations where an RTCP XR packet containing multiple 400 metric blocks, reports on the same streams from the same source. In 401 other words, duplicated data for the measurement is provided multiple 402 times, once in every metric block. Though this design ensures 403 immunity to packet loss, it may bring more packetization complexity 404 and the processing overhead is not completely trivial in some cases. 405 Therefore compromise between processing overhead and reliability 406 should be taken into account. 408 4.4. Consumption of XR block code points 410 The RTCP XR block namespace is limited by the 8-bit block type field 411 in the RTCP XR header. Space exhaustion may be a concern in the 412 future. Anticipating the potential need to extend the block type 413 space, it is noted that Block Type 255 is reserved for future 414 extensions in [RFC3611]. 416 5. Guidelines For Reporting Metric Block Using RTCP XR 418 5.1. Contain the single metrics in the Metric Block 420 Different applications using RTP for media transport certainly have 421 differing requirements for metrics transported in RTCP to support 422 their operation. For many applications, the basic metrics for 423 transport impairments provided in RTCP SR and RR packets [RFC3550] 424 (together with source identification provided in RTCP SDES packets) 425 are sufficient. For other applications additional metrics may be 426 required or at least sufficiently useful to justify the overhead, 427 both of processing in endpoints and of increased session bandwidth. 428 For example an IPTV application using Forward Error Correction (FEC) 429 might use either a metric of post-repair loss or a metric giving 430 detailed information about pre-repair loss bursts to optimise payload 431 bandwidth and the strength of FEC required for changing network 432 conditions. However there are many metrics available. It is likely 433 that different applications or classes of applications will wish to 434 use different metrics. Any one application is likely to require 435 metrics for more than one parameter but if this is the case, 436 different applications will almost certainly require different 437 combinations of metrics. If larger blocks are defined containing 438 multiple metrics to address the needs of each application, it becomes 439 likely that many different such larger blocks are defined, which 440 becomes a danger to interoperability. 442 To avoid this pitfall, this memo recommends the definition of metrics 443 blocks containing a very small number of individual metrics 444 characterizing only one parameter of interest to an application 445 running over RTP. For example, at the RTP transport layer, the 446 parameter of interest might be packet delay variation, and 447 specifically the metric "IP Packet Delay Variation (IPDV)" defined by 448 [Y1540]. See Section 6 for architectural considerations for a 449 metrics block, using as an example a metrics block to report packet 450 delay variation. Further, it is appropriate to not only define 451 report blocks separately, but also to do so in separate documents 452 where possible. This makes it easier to evolve the reports (i.e., to 453 update each type of report block separately), and also makes it 454 easier to require compliance with a particular report block. 456 5.2. Include the payload type in the Metric Block 458 There are some classes of metrics that can only be interpreted with 459 knowledge of the media codec that is being used (audio mean opinion 460 scores (MOS) were the triggering example, but there may be others). 461 In such cases the correlation of RTCP XR with RTP data is needed. 462 Report blocks that require such correlation need to include the 463 payload type of the reported media. In addition, it is necessary to 464 signal the details and parameters of the payload format to which that 465 payload type is bound using some out-of-band means (e.g., as part of 466 an SDP offer/answer exchange). 468 5.3. Use RTCP SDES to correlate XR reports with non-RTP data 470 There may be situations where more than one media transport protocol 471 is used by one application to interconnect to the same session in the 472 gateway. For example, one RTCP XR Packet is sent to the 473 participating endpoints using non-RTP-based media transport (e.g., 474 using SIP) in a VoIP session. One crucial factor lies in how to 475 handle their different identities that are corresponding to different 476 media transport. 478 This memo recommends an approach to facilitate the correlation of the 479 RTCP Session with other session-related non-RTP data. That is to say 480 if there is a need to correlate RTP sessions with non-RTP sessions, 481 then the correlation information needed should be conveyed in a new 482 RTCP Source Description (SDES) item, since such correlation 483 information describes the source, rather than providing a quality 484 report. An example use case is for a participant endpoint may convey 485 a call identifier or a global call identifier associated with the 486 SSRC of measured RTP stream. In such case, the participant endpoint 487 uses the SSRC to bind the call identifier using SDES item in the SDES 488 RTCP packet and send such correlation to the network management 489 system. A flow measurement tool that is configured with the 5-tuple 490 and not call-aware then forwards the RTCP XR reports along with the 491 SSRC of the measured RTP stream which is included in the XR Block 492 header and 5-tuple to the network management system. Network 493 management system can then correlate this report using SSRC with 494 other diagnostic information such as call detail records. 496 5.4. Reduce Measurement information repetition across metric blocks 498 When multiple metric blocks are carried in one RTCP XR packet, 499 reporting on the same stream from the same source for the same time 500 period, RTCP should use the SSRC to identify and correlate the 501 multiple metric blocks between metric blocks. "Measurement Identity 502 and information Reporting using SDES item and XR Block" [MEASI] 503 enables an RTCP sender to convey the common time period and the 504 number of packets sent during this period. If the measurement 505 interval for a metric is different from the RTCP reporting interval, 506 then this measurement duration in the Measurement information block 507 should be used to specify the interval. When there may be multiple 508 measurements information blocks with the same SSRC in one RTCP XR 509 compound packet, the measurement information block should be put in 510 order and followed by all the metric blocks associated with this 511 measurement information block. New RTCP XR metric blocks that rely 512 on the Measurement information block [MEASI] must specify the 513 response in case the new RTCP XR metric block is received without an 514 associated measurement information block. In most cases, it is 515 expected that the correct response is to discard the received metric. 516 In order to reduce measurement information repetition in one RTCP XR 517 compound packet containing multiple metric blocks, the measurement 518 information shall be sent before the related metric blocks that are 519 from the same reporting interval. Note that for packet loss 520 robustness if the report blocks for the same interval span over more 521 than one RTCP packet, then each must have the measurement identity 522 information even though they will be the same. 524 6. An Example of a Metric Block 526 This section uses the example of an existing proposed metrics block 527 to illustrate the application of the principles set out in Section 5. 529 The example [PDV] is a block to convey information about packet delay 530 variation (PDV) only, consistent with the principle that a metrics 531 block should address only one parameter of interest. One simple 532 metric of PDV is available in the RTCP RR packet as the "interarrival 533 jitter" field. There are other PDV metrics with a certain similarity 534 in metric structure which may be more useful to certain applications. 535 Two such metrics are the IPDV metric ([Y1540], [RFC3393]) and the 536 mean absolute packet delay variation 2 (MAPDV2) metric [G1020]. Use 537 of these metrics is consistent with the principle in Section 5 of 538 RTCP guideline [RFC5968] that metrics should usually be defined 539 elsewhere, so that RTCP standards define only the transport of the 540 metric rather than its nature. The purpose of this section is to 541 illustrate the architectural consideration using the example of [PDV] 542 rather than to document the design of the PDV metrics block or to 543 provide a tutorial on PDV in general. 545 Given the availability of at least three metrics for PDV, there are 546 design options for the allocation of metrics to RTCP XR blocks: 548 o provide an RTCP XR block per metric 550 o provide a single RTCP XR block which contains all three metrics 552 o provide a single RTCP block to convey any one of the three 553 metrics, together with a identifier to inform the receiving RTP 554 system of the specific metric being conveyed 556 In choosing between these options, extensibility is important, 557 because additional metrics of PDV may well be standardized and 558 require inclusion in this framework. The first option is extensible 559 but only by use of additional RTCP XR blocks, which may consume the 560 limited namespace for RTCP XR blocks at an unacceptable rate. The 561 second option is not extensible, so could be rejected on that basis, 562 but in any case a single application is quite unlikely to require 563 transport of more than one metric for PDV. Hence the third option 564 was chosen. This implies the creation of a subsidiary namespace to 565 enumerate the PDV metrics which may be transported by this block, as 566 discussed further in [PDV]. 568 7. Application To RFC 5117 Topologies 570 The topologies specified in [RFC5117] fall into two categories. The 571 first category relates to the RTP system model utilizing multicast 572 and/or unicast. The topologies in this category are specifically 573 Topo-Point-to-Point, Topo- Multicast, Topo-Translator (both variants, 574 Topo-Trn-Translator and Topo-Media-Translator, and combinations of 575 the two), and Topo-Mixer. These topologies use RTP end systems, RTP 576 mixers and RTP translators defined in the RTP protocol [RFC3550]. 577 For purposes of reporting connection quality to other RTP systems, 578 RTP mixers and RTP end systems are very similar. Mixers 579 resynchronize packets and do not relay RTCP reports received from one 580 cloud towards other cloud(s). Translators do not resynchronize 581 packets and should forward certain RTCP reports between clouds. In 582 this category, the RTP system (end system, mixer or translator) which 583 originates, terminates or forwards RTCP XR blocks is expected to 584 handle RTCP, including RTCP XR, according to the RTP protocol 585 [RFC3550]. Provided this expectation is met, an RTP system using 586 RTCP XR is architecturally no different from an RTP system of the 587 same class (end system, mixer, or translator) which does not use RTCP 588 XR. The second category relates to deployed system models used in 589 many H.323 [H323] video conferences. The topologies in this category 590 are Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU. Such 591 topologies based on systems (e.g.,MCUs) do not behave according to 592 the RTP protocol [RFC3550]. 594 Considering the translator and MCU are two typical intermediate- 595 systems in these two categories mentioned above, this document will 596 take them as two typical examples to explain how RTCP XR report works 597 in different RFC5117 topologies. 599 7.1. Applicability to Translators 601 Section 7.2 of the RTP protocol [RFC3550] describes processing of 602 RTCP by translators. RTCP XR is within the scope of the 603 recommendations of the RTP protocol [RFC3550]. Some RTCP XR metrics 604 blocks may usefully be measured at, and reported by, translators. As 605 described in the RTP protocol [RFC3550] this creates a requirement 606 for the translator to allocate an SSRC for the monitor collocated 607 with itself so that the monitor may populate the SSRC in the RTCP XR 608 packet header as packet sender SSRC and send it out(although the 609 translator is not a Synchronisation Source in the sense of 610 originating RTP media packets). It must also supply this SSRC and 611 the corresponding CNAME in RTCP SDES packets. 613 In RTP sessions where one or more translators generate any RTCP 614 traffic towards their next-neighbour RTP system, other translators in 615 the session have a choice as to whether they forward a translator's 616 RTCP packets. Forwarding may provide additional information to other 617 RTP systems in the connection but increases RTCP bandwidth and may in 618 some cases present a security risk. RTP translators may have 619 forwarding behaviour based on local policy, which might differ 620 between different interfaces of the same translator. 622 7.2. Applicability to MCU 624 Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU, suffer from the 625 difficulties described in [RFC5117]. These difficulties apply to 626 systems sending, and expecting to receive, RTCP XR blocks as much as 627 to systems using other RTCP packet types. For example, a participant 628 RTP end system may send media to a video switch MCU. If the media 629 stream is not selected for forwarding by the switch, neither RTCP RR 630 packets nor RTCP XR blocks referring to the end system's generated 631 stream will be received at the RTP end system. Strictly the RTP end 632 system can only conclude that its RTP has been lost in the network, 633 though an RTP end system complying with the robustness principle of 634 [RFC1122] should survive with essential functions (i.e.,media 635 distribution) unimpaired. 637 8. IANA Considerations 639 There is no IANA action in this document. 641 9. Security Considerations 643 This document focuses on the RTCP reporting extension using RTCP XR 644 and should not give rise to any new security vulnerabilities beyond 645 those described in RTCP XRs [RFC3611]. However it also describes the 646 architectural framework to be used for monitoring at RTP layer. The 647 security issues with monitoring needs to be considered. 649 In RTP sessions, a RTP system may use its own SSRC to send its 650 monitoring reports towards its next-neighbour RTP system. Other RTP 651 system in the session may have a choice as to whether they forward 652 this RTP system's RTCP packets. This present a security issue since 653 the information in the report may be exposed by the other RTP system 654 to any malicious node. Therefore if the information is considered as 655 sensitive, the monitoring reports SHOULD be secured to the same 656 extent as the RTP flows that they measure. If encryption is used and 657 the encrypted monitoring report is received by the RTP system that 658 deploy the third party monitor,the RTP system may decrypt the monitor 659 report for the third party monitor based on local policy(e.g.,third- 660 party monitors is allowed to access to the metric) and forward it to 661 the third party monitor, otherwise, the third party monitor SHOULD 662 discard the received encrypted monitoring report. 664 10. Acknowledgement 666 The authors would also like to thank Colin Perkins, Charles Eckel, 667 Robert Sparks, Salvatore Loreto, Graeme Gibbs, Debbie Greenstreet, 668 Keith Drage, Dan Romascanu, Ali C. Begen, Roni Even, Magnus 669 Westerlund,Meral Shirazipour,Tina Tsou,Barry Leiba,Benoit Claise,Russ 670 Housley,Stephen Farrell for their valuable comments and suggestions 671 on the early version of this document. 673 11. Informative References 675 [G1020] ITU-T, "ITU-T Rec. G.1020, Performance parameter 676 definitions for quality of speech and other voiceband 677 applications utilizing IP networks", July 2006. 679 [H323] ITU-T, "ITU-T Rec. H.323, Packet-based multimedia 680 communications systems", June 2006. 682 [MEASI] Wu, Q., "Measurement Identity and information Reporting 683 using SDES item and XR Block", 684 ID draft-ietf-xrblock-rtcp-xr-meas-identity-10, 685 August 2012. 687 [PDV] Hunt, G., Clark, A., and Q. Wu, "RTCP XR Report Block for 688 Packet Delay Variation Metric Reporting", 689 ID draft-ietf-xrblock-rtcp-xr-pdv-05, August 2012. 691 [QOE_BLOCK] 692 Hunt, G., Clark, A., Wu, Q., Schott, R., and G. Zorn, 693 "RTCP XR Blocks for QoE Metric Reporting", 694 ID draft-ietf-xrblock-rtcp-xr-qoe-02, July 2012. 696 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 697 Communication Layers", RFC 1122, October 1989. 699 [RFC2959] Baugher, M., Strahm, B., and I. Suconick, "Real-Time 700 Transport Protocol Management Information Base", RFC 2959, 701 October 2000. 703 [RFC3393] Demichelis, C., "IP Packet Delay Variation Metric for IP 704 Performance Metrics (IPPM)", RFC 3393, November 2002. 706 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 707 Applications", RFC 3550, July 2003. 709 [RFC3611] Friedman, T., "RTP Control Protocol Extended Reports (RTCP 710 XR)", RFC 3611, November 2003. 712 [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export Version 713 9", RFC 3954, October 2004. 715 [RFC4585] Ott, J. and S. Wenger, "Extended RTP Profile for Real-time 716 Transport Control Protocol (RTCP)-Based Feedback (RTP/ 717 AVPF)", RFC 4585, July 2006. 719 [RFC5101] Claise, B., "Specification of the IP Flow Information 720 Export (IPFIX) Protocol for the Exchange of IP Traffic 721 Flow Information", RFC 5101, January 2008. 723 [RFC5102] Quittek, J., , S., Claise, B., Aitken, P., and J. Meyer, 724 "Information Model for IP Flow Information Export", 725 RFC 5102, January 2008. 727 [RFC5117] Westerlund, M., "RTP Topologies", RFC 5117, January 2008. 729 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 730 Protocol (RTCP) Extensions for Single-Source Multicast 731 Sessions with Unicast Feedback", RFC 5760, February 2010. 733 [RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP 734 Control Protocol (RTCP)", RFC 5968, September 2010. 736 [RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, 737 "Session Initiation Protocol Event Package for Voice 738 Quality Reporting", RFC 6035, November 2010. 740 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 741 Performance Metric Development", RFC 6390, October 2011. 743 [Y1540] ITU-T, "ITU-T Rec. Y.1540, IP packet transfer and 744 availability performance parameters", November 2007. 746 Appendix A. Change Log 748 Note to the RFC-Editor: please remove this section prior to 749 publication as an RFC. 751 A.1. draft-ietf-avtcore-monarch-22 753 The following are the major changes compared to 20,21: 755 o Editorial changes based on Benoit and WG Review. 757 A.2. draft-ietf-avtcore-monarch-20 759 The following are the major changes compared to 19: 761 o Editorial changes based on IESG Review. 763 o Some new text in the security section to clarify encryption issue 764 for third party monitoring. 766 o Some new text in introduction section to clarify the relationship 767 with RFC5968 and RFC6390. 769 A.3. draft-ietf-avtcore-monarch-19 771 The following are the major changes compared to 18: 773 o Editorial changes based on Meral Shirazipour's second Gen-Art 774 review. 776 o Transport level metrics definition simplifying based on Robert's 777 comment. 779 A.4. draft-ietf-avtcore-monarch-18 781 The following are the major changes compared to 17: 783 o Some Editorial changes based on Gen-Art review and Secdir Review. 785 A.5. draft-ietf-avtcore-monarch-17 787 The following are the major changes compared to 16: 789 o Some Editorial changes. 791 A.6. draft-ietf-avtcore-monarch-16 793 The following are the major changes compared to 15: 795 o A few modification to the figure 1. 797 o Change RTCP XR reports into RTCP reports in the section 3.1. 799 o References Update. 801 A.7. draft-ietf-avtcore-monarch-15 803 The following are the major changes compared to 14: 805 o Add figure 1 in section 3 to describe RTP monitoring framework. 807 o Change the title as Guidelines for Use of the RTP Monitoring 808 Framework. 810 o Other editorial change to get in line with the title change in the 811 section 3. 813 A.8. draft-ietf-avtcore-monarch-14 815 The following are the major changes compared to 13: 817 o Incorporate the key points in the section 3.2 into overview 818 section. 820 o Remove the figure 1 and use the description instead. 822 o Add description in the section 3.3 to discuss the possible 823 location of the monitors and the types of metric at that location. 825 o Add the description to make the definition of Interval metrics/ 826 cumulative metrics/sampled metrics clear. 828 o Editorial Changes. 830 A.9. draft-ietf-avtcore-monarch-13 832 The following are the major changes compared to 12: 834 o Editorial Changes. 836 A.10. draft-ietf-avtcore-monarch-12 838 The following are the major changes compared to 11: 840 o Editorial Changes based on Charles' Comments. 842 o Reference update. 844 o Add one new section 5.2 to discuss Correlating RTCP XR with RTP 845 data. 847 o Add text in section 5.1 to highlight it is more appropriate to 848 define each block in a separate draft. 850 A.11. draft-ietf-avtcore-monarch-11 852 The following are the major changes compared to 10: 854 o Editorial Changes. 856 A.12. draft-ietf-avtcore-monarch-10 858 The following are the major changes compared to 09: 860 o Discuss what exist already for monitoring in section 3.1. 862 o Provide benefit using RTCP XR based monitoring in section 3.1. 864 o add one new paragraph in section 3.1 to describe how monitoring 865 architecture is applied to ASM/SSM. 867 o Other Editorial Changes. 869 A.13. draft-ietf-avtcore-monarch-09 871 The following are the major changes compared to 07: 873 o Rephrase application level metric definition. 875 o Add one new section to clarify where to measure QoE related 876 parameters. 878 o Add text in section 5.3 to clarify the failure case when 879 measurement interval is not sent. 881 o Add text in section 5.3 to clarify how to deal with multiple 882 measurements information blocks carried in the same packet. 884 A.14. draft-ietf-avtcore-monarch-08 886 The following are the major changes compared to 07: 888 o Editorial change to the reference. 890 A.15. draft-ietf-avtcore-monarch-07 892 The following are the major changes compared to 06: 894 o Clarify the XR block code points consumption issue in the section 895 4 and new section 5.4. 897 o Other editorial changes. 899 A.16. draft-ietf-avtcore-monarch-06 901 The following are the major changes compared to 05: 903 o Some editorial changes. 905 A.17. draft-ietf-avtcore-monarch-05 907 The following are the major changes compared to 04: 909 o Replace "chunk" with "new SDES item". 911 o Add texts in security section to discussion potential security 912 issues. 914 o Add new sub-section 5.3 to discuss Reducing Measurement 915 information repetition. 917 o Other editorial changes. 919 A.18. draft-ietf-avtcore-monarch-04 921 The following are the major changes compared to 03: 923 o Update section 5.2 to clarify using SDES packet to carry 924 correlation information. 926 o Remove section 5.3 since additional identity information goes to 927 SDES packet and using SSRC to identify each block is standard RTP 928 feature. 930 o Swap the last two paragraphs in the section 4 since identity 931 information duplication can not been 100% avoided. 933 o Other editorial changes. 935 A.19. draft-ietf-avtcore-monarch-03 937 The following are the major changes compared to 02: 939 o Update bullet 2 in section 4 to explain the ill-effect of Identity 940 Information duplication. 942 o Update bullet 3 in section 4 to explain why Correlating RTCP XR 943 with the non-RTP data is needed. 945 o Update section 5.2 to focus on how to reduce the identity 946 information repetition 948 o Update section 5.3 to explain how to correlate identity 949 information with the non-RTP data 951 A.20. draft-ietf-avtcore-monarch-02 953 The following are the major changes compared to 01: 955 o Deleting first paragraph of Section 1. 957 o Deleting Section 3.1, since the interaction with the management 958 application is out of scope of this draft. 960 o Separate identity information correlation from section 5.2 as new 961 section 5.3. 963 o Remove figure 2 and related text from section 5.2. 965 o Editorial changes in the section 4 and the first paragraph of 966 section 7. 968 A.21. draft-ietf-avtcore-monarch-01 970 The following are the major changes compared to 00: 972 o Restructure the document by merging section 4 into section 3. 974 o Remove section 4.1,section 5 that is out of scope of this 975 document. 977 o Remove the last bullet in section 6 and section 7.3 based on 978 conclusion of last meeting. 980 o Update figure 1 and related text in section 3 according to the 981 monitor definition in RFC3550. 983 o Revise section 9 to address monitor declaration issue. 985 o Merge the first two bullet in section 6. 987 o Add one new bullet to discuss metric block association in section 988 6. 990 A.22. draft-ietf-avtcore-monarch-00 992 The following are the major changes compared to 993 draft-hunt-avtcore-monarch-02: 995 o Move Geoff Hunt and Philip Arden to acknowledgement section. 997 Authors' Addresses 999 Qin Wu (editor) 1000 Huawei 1001 101 Software Avenue, Yuhua District 1002 Nanjing, Jiangsu 210012 1003 China 1005 Email: sunseawq@huawei.com 1007 Geoff Hunt 1008 Unaffiliated 1010 Email: r.geoff.hunt@gmail.com 1012 Philip Arden 1013 BT 1014 Orion 3/7 PP4 1015 Adastral Park 1016 Martlesham Heath 1017 Ipswich, Suffolk IP5 3RE 1018 United Kingdom 1020 Phone: +44 1473 644192 1021 Email: philip.arden@bt.com