summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6792.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6792.txt')
-rw-r--r--doc/rfc/rfc6792.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc6792.txt b/doc/rfc/rfc6792.txt
new file mode 100644
index 0000000..1a24f4a
--- /dev/null
+++ b/doc/rfc/rfc6792.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) Q. Wu, Ed.
+Request for Comments: 6792 Huawei
+Category: Informational G. Hunt
+ISSN: 2070-1721 Unaffiliated
+ P. Arden
+ BT
+ November 2012
+
+
+ Guidelines for Use of the RTP Monitoring Framework
+
+Abstract
+
+ This memo proposes an extensible Real-time Transport Protocol (RTP)
+ monitoring framework for extending the RTP Control Protocol (RTCP)
+ with a new RTCP Extended Reports (XR) block type to report new
+ metrics regarding media transmission or reception quality. In this
+ framework, a new XR block should contain a single metric or a small
+ number of metrics relevant to a single parameter of interest or
+ concern, rather than containing a number of metrics that attempt to
+ provide full coverage of all those parameters of concern to a
+ specific application. Applications may then "mix and match" to
+ create a set of blocks that cover their set of concerns. Where
+ possible, a specific block should be designed to be reusable across
+ more than one application, for example, for all of voice, streaming
+ audio, and video.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6792.
+
+
+
+
+
+
+
+
+
+Wu, et al. Informational [Page 1]
+
+RFC 6792 RTP Monitoring Framework November 2012
+
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................3
+ 3. RTP Monitoring Framework ........................................5
+ 3.1. Overview of the RTP Monitoring Framework ...................5
+ 3.2. Location of Monitors .......................................7
+ 4. Issues with Reporting Metrics Blocks Using RTCP XR Extensions ...8
+ 4.1. Using a Compound Metrics Block .............................8
+ 4.2. Correlating RTCP XR with Non-RTP Data ......................8
+ 4.3. Measurement Information Duplication ........................9
+ 4.4. Consumption of XR Block Code Points ........................9
+ 5. Guidelines for Reporting Metrics Blocks Using RTCP XR ...........9
+ 5.1. Use a Single Metric in the Metrics Block ...................9
+ 5.2. Include the Payload Type in the Metrics Block .............10
+ 5.3. Use RTCP SDES to Correlate XRs with Non-RTP Data ..........10
+ 5.4. Reduce Measurement Information Repetition across
+ Metrics Blocks ............................................11
+ 6. An Example of a Metrics Block ..................................11
+ 7. Application to RFC 5117 Topologies .............................12
+ 7.1. Applicability to Translators ..............................13
+ 7.2. Applicability to MCUs .....................................13
+ 8. Security Considerations ........................................14
+ 9. Acknowledgements ...............................................14
+ 10. Informative References ........................................15
+
+
+
+
+
+
+
+
+
+
+
+Wu, et al. Informational [Page 2]
+
+RFC 6792 RTP Monitoring Framework November 2012
+
+
+1. Introduction
+
+ Multimedia services using the Real-time Transport Protocol (RTP) are
+ seeing increased use. Standard methods for gathering RTP performance
+ metrics from these applications are needed to manage uncertainties in
+ the behavior and availability of their services. Standards such as
+ "RTP Control Protocol Extended Reports (RTCP XR)" [RFC3611] as well
+ as other RTCP extensions to sender reports (SRs) and receiver reports
+ (RRs) [RFC3550] are being developed for the purpose of collecting and
+ reporting performance metrics from endpoint devices that can be used
+ to correlate the metrics, provide end-to-end service visibility, and
+ measure and monitor Quality of Experience (QoE) [RFC6390].
+
+ However, the proliferation of RTP-/RTCP-specific metrics for
+ transport and application quality monitoring has been identified as a
+ potential problem for interoperability when using RTP/RTCP to
+ communicate all the parameters of concern to a specific application.
+ Given that different applications layered on RTP may have some
+ monitoring requirements in common, these metrics should be satisfied
+ by a common design.
+
+ The objective of this document is to describe an extensible RTP
+ monitoring framework to provide a small number of reusable Quality of
+ Service (QoS) / QoE metrics that facilitate reduced implementation
+ costs and help maximize interoperability. "Guidelines for Extending
+ the RTP Control Protocol (RTCP)" [RFC5968] has stated that where RTCP
+ is to be extended with a new metric, the preferred mechanism is by
+ the addition of a new RTCP XR [RFC3611] block. This memo assumes
+ that all the guidelines from RFC 5968 must apply on top of the
+ guidelines in this document. Guidelines for developing new
+ performance metrics are specified in [RFC6390]. New RTCP XR report
+ block definitions should not define new performance metrics but
+ should rather refer to metrics defined elsewhere.
+
+2. Terminology
+
+ This memo is informative and as such contains no normative
+ requirements.
+
+ In addition, the following terms are defined:
+
+ Transport-level metrics
+
+ A set of metrics that characterize the three transport impairments
+ of packet loss, packet delay, and jitter (also known as delay
+ variation). These metrics should be usable by any application
+ that uses RTP transport.
+
+
+
+
+Wu, et al. Informational [Page 3]
+
+RFC 6792 RTP Monitoring Framework November 2012
+
+
+ Application-level metrics
+
+ Metrics relating to application-specific parameters or QoE-related
+ parameters. Application-specific parameters are measured at the
+ application level and focus on quality of content rather than
+ network performance. QoE-related parameters reflect the end-to-
+ end performance at the services level and are usually measured at
+ the user endpoint. One example of such metrics is the QoE metric
+ as specified in the QoE Metrics Report Block; see [QOE_BLOCK].
+
+ End-system metrics
+
+ Metrics relating to the way a terminal deals with transport
+ impairments affecting the incident RTP stream. These may include
+ de-jitter buffering, packet loss concealment, and the use of
+ redundant streams (if any) for correction of error or loss.
+
+ Direct metrics
+
+ Metrics that can be directly measured or calculated and are not
+ dependent on other metrics.
+
+ Interval metrics
+
+ Metrics measured over the course of a single reporting interval
+ between two successive report blocks. This may be the most recent
+ RTCP reporting interval ([RFC3550], Section 6.2) or some other
+ interval signaled using an RTCP Measurement Information XR Block
+ [RFC6776]. An example interval metric is the count of the number
+ of RTP packets lost over the course of the last RTCP reporting
+ interval.
+
+ Cumulative metrics
+
+ Metrics measured over several reporting intervals for accumulating
+ statistics. The time period over which measurements are
+ accumulated can be the complete RTP session, or some other
+ interval signaled using an RTCP Measurement Information XR Block
+ [RFC6776]. An example cumulative metric is the total number of
+ RTP packets lost since the start of the RTP session.
+
+ Sampled metrics
+
+ Metrics measured at a particular time instant and sampled from the
+ values of a continuously measured or calculated metric within a
+ reporting interval (generally, the value of some measurement as
+ taken at the end of the reporting interval). An example is the
+ inter-arrival jitter reported in RTCP SR and RR packets, which is
+
+
+
+Wu, et al. Informational [Page 4]
+
+RFC 6792 RTP Monitoring Framework November 2012
+
+
+ continually updated as each RTP data packet arrives but is only
+ reported based on a snapshot of the value that is sampled at the
+ instant the reporting interval ends.
+
+3. RTP Monitoring Framework
+
+ There are many ways in which the performance of an RTP session can be
+ monitored. These include RTP-based mechanisms such as the RTP MIB
+ module [RFC2959]; or the Session Initiation Protocol (SIP) event
+ package for RTCP summary reports [RFC6035]; or non-RTP mechanisms
+ such as generic MIBs, NetFlow [RFC3954], IP Flow Information Export
+ (IPFIX) [RFC5101] [RFC5102], and so on. Together, these provide
+ useful mechanisms for exporting data on the performance of an RTP
+ session to non-RTP network management systems. It is desirable to
+ also perform in-session monitoring of RTP performance. RTCP provides
+ the means to do this. In the following, we review the RTP Monitoring
+ Framework, and give guidance for using and extending RTCP for
+ monitoring RTP sessions. One major benefit of such a framework is
+ ease of integration with other RTP/RTCP mechanisms.
+
+3.1. Overview of the RTP Monitoring Framework
+
+ The RTP monitoring Framework comprises the following two key
+ functional components described below:
+
+ o Monitor
+
+ o RTP Metrics Block
+
+ "Monitor" is the functional component defined in the RTP
+ specification [RFC3550]. It acts as a repository of information
+ gathered for monitoring purposes.
+
+ According to the definition of "monitor" in [RFC3550], the end system
+ that runs an application program that sends or receives RTP data
+ packets, an intermediate system that forwards RTP packets to end
+ devices, or a third party that observes the RTP and RTCP traffic but
+ does not make itself visible to the RTP Session participants can play
+ the role of the monitor within the RTP monitoring framework. As
+ shown in Figure 1, the third-party monitor can be a passive monitor
+ that sees the RTP/RTCP stream pass it, or a system that gets sent
+ RTCP reports but not RTP and uses that to collect information. The
+ third-party monitor should be placed on the RTP/RTCP path between the
+ sender, the intermediate system, and the receiver.
+
+ The RTP Metrics Block (MB) conveys real-time application QoS/QoE
+ metric information and is used by the monitor to exchange information
+ with other monitors in the appropriate report block format. The
+
+
+
+Wu, et al. Informational [Page 5]
+
+RFC 6792 RTP Monitoring Framework November 2012
+
+
+ information contained in the RTP MBs is collected by monitors and can
+ be formulated as various types of metrics, e.g., direct metrics/
+ composed performance metrics [RFC6390] or interval metrics/cumulative
+ metrics/sampled metrics, etc. Both the RTCP and RTCP XR can be
+ extended to transport these metrics, e.g., the basic RTCP reception
+ report [RFC3550] that conveys reception statistics (i.e., transport-
+ level statistics) for multiple RTP media streams, the RTCP XRs
+ [RFC3611] that supplement the existing RTCP packets and provide more
+ detailed feedback on reception quality, and an RTCP NACK [RFC4585]
+ that provides feedback on the RTP sequence numbers for a subset of
+ the lost packets or all the currently lost packets. Ultimately, the
+ metric information collected by monitors within the RTP monitoring
+ framework may go to the network management tools beyond the RTP
+ monitoring framework; e.g., as shown in Figure 1, the monitors may
+ export the metric information derived from the RTP monitoring
+ framework to the management system using non-RTP means.
+
+ +-----------+ +----------+
+ |Third-Party| |Management|
+ | Monitor | >>>>>>>>| System |<<<<<
+ +-----------+ ^ +----------+ ^
+ : ^ ^ ^
+ : | ^ ^
+ +---------------+ : | +-------------+ +-------------+
+ | +-----------+ | : | |+-----------+| |+-----------+|
+ | | Monitor | |..:...|.......|| Monitor ||........|| Monitor ||
+ | +-----------+ | | |+-----------+| |+-----------+|
+ | |------+------>| |------->| |
+ | RTP Sender | |RTP Mixer or | |RTP Receiver |
+ | | |Translator | | |
+ +---------------+ +-------------+ +-------------+
+
+ ----> RTP media traffic
+ ..... RTCP control channel
+ >>>>> Non-RTP/RTCP management flows
+
+ Figure 1: Example Showing the Components
+ of the RTP Monitoring Framework
+
+ RTP may be used with multicast groups: both Any-Source Multicast
+ (ASM) and Source-Specific Multicast (SSM). These groups can be
+ monitored using RTCP. In the ASM case, the monitor is a member of
+ the multicast group and listens to RTCP reports from all members of
+ the ASM group. In the SSM case, there is a unicast feedback target
+ that receives RTCP feedback from receivers and distributes it to
+ other members of the SSM group (see Figure 1 of [RFC5760]). The
+ monitor will need to be co-located with the feedback target to
+
+
+
+
+Wu, et al. Informational [Page 6]
+
+RFC 6792 RTP Monitoring Framework November 2012
+
+
+ receive all feedback from the receivers (this may also be an
+ intermediate system). In both ASM and SSM scenarios, receivers can
+ send RTCP reports to enhance reception-quality reporting.
+
+3.2. Location of Monitors
+
+ As shown in Figure 1, there are several possible locations from which
+ RTP sessions can be monitored. These include end systems that
+ terminate RTP sessions, intermediate systems that are an active part
+ of an RTP session, and third-party devices that passively monitor an
+ RTP session. Not every RTP session will include monitoring, and
+ those sessions that are monitored will not all include each type of
+ monitor. The performance metrics collected by monitors can be
+ divided into end-system metrics, application-level metrics, and
+ transport-level metrics. Some of these metrics may be specific to
+ the measurement point of the monitor or may depend on where the
+ monitors are located in the network, while others are more general
+ and can be collected in any monitoring location.
+
+ End-system monitoring is monitoring that is deployed on devices that
+ terminate RTP flows. Flows can be terminated in user equipment, such
+ as phones, videoconferencing systems, or IPTV set-top boxes.
+ Alternatively, they can be terminated in devices that gateway between
+ RTP and other transport protocols. Transport-level metrics, end-
+ system metrics, and application-level metrics that don't reflect the
+ end-to-end user experience may be collected at all types of end
+ systems, but some application-level metrics (i.e., quality of
+ experience (QoE) metrics) may only be applicable for user-facing end
+ systems.
+
+ RTP sessions can include intermediate systems that are an active part
+ of the system. These intermediate systems include RTP mixers and
+ translators, Multipoint Control Units (MCUs), retransmission servers,
+ etc. If the intermediate system establishes separate RTP sessions to
+ the other participants, then it must act as an end system in each of
+ those separate RTP sessions for the purposes of monitoring. If a
+ single RTP session traverses the intermediate system, then the
+ intermediate system can be assigned a synchronization source (SSRC)
+ in that session, which it can use for its reports. Transport-level
+ metrics may be collected at such an intermediate system.
+
+ Third-party monitors may be deployed that passively monitor RTP
+ sessions for network management purposes. Third-party monitors often
+ do not send reports into the RTP session being monitored but instead
+ collect transport-level metrics, end-system metrics, and application-
+ level metrics. In some cases, however, third-party monitors can send
+ reports to some or all participants in the session being monitored.
+
+
+
+
+Wu, et al. Informational [Page 7]
+
+RFC 6792 RTP Monitoring Framework November 2012
+
+
+ For example, in a media streaming scenario, third-party monitors may
+ be deployed that passively monitor the session and send reception-
+ quality reports to the media source but not to the receivers.
+
+4. Issues with Reporting Metrics Blocks Using RTCP XR Extensions
+
+ The following sections discuss four issues that have come up in the
+ past with reporting metrics blocks using RTCP XR extensions.
+
+4.1. Using a Compound Metrics Block
+
+ A compound metrics block is designed to contain a large number of
+ parameters from different classes for a specific application in a
+ single block. For example, "RTP Control Protocol Extended Reports
+ (RTCP XR)" [RFC3611] defines seven report block formats for network
+ management and quality monitoring. Some of these block types defined
+ in the RTCP XRs [RFC3611] are only specifically designed for
+ conveying multicast inference of network characteristics (MINC) or
+ voice over IP (VoIP) monitoring. However, different applications
+ layered on RTP may have different monitoring requirements. Designing
+ a compound metrics block only for specific applications may increase
+ implementation costs and minimize interoperability.
+
+4.2. Correlating RTCP XR with Non-RTP Data
+
+ The Canonical End-Point Identifier SDES Item (CNAME), as defined in
+ RTP [RFC3550], is an example of an existing tool that allows binding
+ an SSRC that may change to a name that is fixed within one RTP
+ session. The CNAME may also be fixed across multiple RTP sessions
+ from the same source. However, there may be situations where RTCP
+ reports are sent to other participating endpoints using a non-RTP
+ protocol in a session. For example, as described in [RFC6035] in
+ relation to summary reports, the data contained in RTCP XR VoIP
+ metrics reports [RFC3611] is forwarded to a central collection server
+ system using SIP. In such a case, there is a large portfolio of
+ quality parameters that can be associated with real-time
+ applications, e.g., VOIP applications, but only a minimal number of
+ parameters are included in the RTCP XRs. With this minimal number of
+ RTCP statistical parameters mapped to non-RTCP measurements, it is
+ hard to provide accurate measurements of real-time application
+ quality, conduct detailed data analysis, and create timely alerts for
+ users. Therefore, a correlation between RTCP XRs and non-RTP data
+ should be provided.
+
+
+
+
+
+
+
+
+Wu, et al. Informational [Page 8]
+
+RFC 6792 RTP Monitoring Framework November 2012
+
+
+4.3. Measurement Information Duplication
+
+ We may set a measurement interval for the session and monitor RTP
+ packets within one or several consecutive report intervals. In such
+ a case, extra measurement information (e.g., extended sequence number
+ of the first packet, measurement period) may be expected. However,
+ if we put such extra measurement information into each metrics block,
+ there may be situations where an RTCP XR packet that contains
+ multiple metrics blocks will report on the same streams from the same
+ source. In other words, duplicated data for the measurement is
+ provided multiple times, once in every metrics block. Though this
+ design ensures immunity to packet loss, it may result in more
+ packetization complexity, and this processing overhead is not
+ completely trivial in some cases. Therefore, a compromise between
+ processing overhead and reliability should be taken into account.
+
+4.4. Consumption of XR Block Code Points
+
+ The RTCP XR block namespace is limited by the 8-bit block type field
+ in the RTCP XR header. Space exhaustion may be a concern in the
+ future. In anticipation of the potential need to extend the block
+ type space, it is noted that Block Type 255 is reserved for future
+ extensions in [RFC3611].
+
+5. Guidelines for Reporting Metrics Blocks Using RTCP XR
+
+5.1. Use a Single Metric in the Metrics Block
+
+ Different applications using RTP for media transport certainly have
+ differing requirements for metrics transported in RTCP to support
+ their operation. For many applications, the basic metrics for
+ transport impairments provided in RTCP SR and RR packets [RFC3550]
+ (together with source identification provided in RTCP Source
+ Description (SDES) packets) are sufficient. For other applications,
+ additional metrics may be required or at least may be sufficiently
+ useful to justify the overhead, in terms of both processing in
+ endpoints and of increased session bandwidth. For example, an IPTV
+ application using Forward Error Correction (FEC) might use either a
+ metric of post-repair loss or a metric giving detailed information
+ about pre-repair loss bursts to optimize payload bandwidth and the
+ strength of FEC required for changing network conditions. However,
+ there are many metrics available. It is likely that different
+ applications or classes of applications will wish to use different
+ metrics. Any one application is likely to require metrics for more
+ than one parameter, but if this is the case, different applications
+ will almost certainly require different combinations of metrics. If
+
+
+
+
+
+Wu, et al. Informational [Page 9]
+
+RFC 6792 RTP Monitoring Framework November 2012
+
+
+ larger blocks are defined containing multiple metrics to address the
+ needs of each application, it becomes likely that many such different
+ larger blocks are defined, which poses a danger to interoperability.
+
+ To avoid this pitfall, this memo recommends the definition of metrics
+ blocks containing a very small number of individual metrics
+ characterizing only one parameter of interest to an application
+ running over RTP. For example, at the RTP transport layer, the
+ parameter of interest might be packet delay variation, and
+ specifically the metric "IP Packet Delay Variation (IPDV)" defined by
+ [Y1540]. See Section 6 for architectural considerations for a
+ metrics block, using as an example a metrics block to report packet
+ delay variation. Further, it is appropriate to not only define
+ report blocks separately but also to do so in separate documents
+ where possible. This makes it easier to evolve the reports (i.e., to
+ update each type of report block separately) and also makes it easier
+ to require compliance with a particular report block.
+
+5.2. Include the Payload Type in the Metrics Block
+
+ There are some classes of metrics that can only be interpreted with
+ knowledge of the media codec that is being used (audio mean opinion
+ scores (MOSs) were the triggering example, but there may be others).
+ In such cases, the correlation of an RTCP XR with RTP data is needed.
+ Report blocks that require such correlation need to include the
+ payload type of the reported media. In addition, it is necessary to
+ signal the details and parameters of the payload format to which that
+ payload type is bound using some out-of-band means (e.g., as part of
+ a Session Description Protocol (SDP) offer/answer exchange).
+
+5.3. Use RTCP SDES to Correlate XRs with Non-RTP Data
+
+ There may be situations where more than one media transport protocol
+ is used by one application to interconnect to the same session in the
+ gateway. For example, one RTCP XR packet is sent to the
+ participating endpoints using non-RTP-based media transport (e.g.,
+ using SIP) in a VoIP session. One crucial factor lies in how to
+ handle the different identities that correspond to these different
+ media transport protocols.
+
+ This memo recommends an approach to facilitate the correlation of the
+ RTCP session with other session-related non-RTP data. That is to
+ say, if there is a need to correlate RTP sessions with non-RTP
+ sessions, then the correlation information needed should be conveyed
+ in a new RTCP SDES item, since such correlation information describes
+ the source rather than providing a quality report. An example use
+ case is where a participant endpoint may convey a call identifier or
+ a global call identifier associated with the SSRC of a measured RTP
+
+
+
+Wu, et al. Informational [Page 10]
+
+RFC 6792 RTP Monitoring Framework November 2012
+
+
+ stream. In such a case, the participant endpoint uses the SSRC to
+ bind the call identifier using the SDES item in the SDES RTCP packet
+ and sends this correlation to the network management system. A flow
+ measurement tool that is configured with the 5-tuple and is not call-
+ aware then forwards the RTCP XRs along with the SSRC of the measured
+ RTP stream, which is included in the XR Block header and 5-tuple to
+ the network management system. The network management system can
+ then correlate this report using SSRC with other diagnostic
+ information, such as call detail records.
+
+5.4. Reduce Measurement Information Repetition across Metrics Blocks
+
+ When multiple metrics blocks are carried in one RTCP XR packet,
+ reporting on the same stream from the same source for the same time
+ period, RTCP should use the SSRC to identify and correlate the
+ multiple metrics blocks placed between Measurement Information
+ Blocks; see "Measurement Identity and Information Reporting Using a
+ Source Description (SDES) Item and an RTCP Extended Report (XR)
+ Block" [RFC6776]. [RFC6776] enables an RTCP sender to convey the
+ common time period and the number of packets sent during this period.
+ If the measurement interval for a metric is different from the RTCP
+ reporting interval, then this measurement duration in the Measurement
+ Information Block should be used to specify the interval. When there
+ may be multiple Measurement Information Blocks with the same SSRC in
+ one RTCP XR compound packet, the Measurement Information Block should
+ be put in order and followed by all the metrics blocks associated
+ with this Measurement Information Block. New RTCP XR metrics blocks
+ that rely on the Measurement Information Block must specify the
+ response in case the new RTCP XR metrics block is received without an
+ associated Measurement Information Block. In most cases, it is
+ expected that the correct response is to discard the received metric.
+ In order to reduce measurement information repetition in one RTCP XR
+ compound packet containing multiple metrics blocks, the measurement
+ information shall be sent before the related metrics blocks that are
+ from the same reporting interval. Note that for packet loss
+ robustness, if the report blocks for the same interval span more than
+ one RTCP packet, then each block must have the measurement identity
+ information sent together with itself in the same RTCP compound
+ packet, even though the information will be the same.
+
+6. An Example of a Metrics Block
+
+ This section uses the example of an existing proposed metrics block
+ to illustrate the application of the principles set out in Section 5.
+
+ The example [RFC6798] is a block to convey information about packet
+ delay variation (PDV) only, consistent with the principle that a
+ metrics block should address only one parameter of interest. One
+
+
+
+Wu, et al. Informational [Page 11]
+
+RFC 6792 RTP Monitoring Framework November 2012
+
+
+ simple metric of PDV is available in the RTCP RR packet as the
+ "inter-arrival jitter" field. There are other PDV metrics with a
+ certain similarity in metric structure that may be more useful to
+ certain applications. Two such metrics are the IPDV metric ([Y1540]
+ [RFC3393]) and the mean absolute packet delay variation 2 (MAPDV2)
+ metric [G1020]. The use of these metrics is consistent with the
+ principle in Section 5 of the RTCP guidelines document [RFC5968] that
+ metrics should usually be defined elsewhere, so that RTCP standards
+ define only the transport of the metric rather than its nature. The
+ purpose of this section is to illustrate the architectural
+ considerations, using the example of [RFC6798], rather than to
+ document the design of the PDV metrics block or to provide a tutorial
+ on PDV in general.
+
+ Given the availability of at least three metrics for PDV, there are
+ design options for the allocation of metrics to RTCP XR blocks:
+
+ o Provide an RTCP XR block per metric.
+
+ o Provide a single RTCP XR block that contains all three metrics.
+
+ o Provide a single RTCP block to convey any one of the three
+ metrics, together with an identifier to inform the receiving RTP
+ system of the specific metric being conveyed.
+
+ In choosing between these options, extensibility is important,
+ because additional metrics of PDV may well be standardized and
+ require inclusion in this framework. The first option is extensible
+ but only by the use of additional RTCP XR blocks, which may consume
+ the limited namespace for RTCP XR blocks at an unacceptable rate.
+ The second option is not extensible and so could be rejected on that
+ basis, but in any case a single application is quite unlikely to
+ require the transport of more than one metric for PDV. Hence, the
+ third option was chosen. This implies the creation of a subsidiary
+ namespace to enumerate the PDV metrics that may be transported by
+ this block, as discussed further in [RFC6798].
+
+7. Application to RFC 5117 Topologies
+
+ The topologies specified in [RFC5117] fall into two categories. The
+ first category relates to the RTP system model utilizing multicast
+ and/or unicast. The topologies in this category are specifically
+ Topo-Point-to-Point, Topo-Multicast, Topo-Translator (both variants
+ Topo-Trn-Translator and Topo-Media-Translator as well as combinations
+ of the two), and Topo-Mixer. These topologies use RTP end systems,
+ RTP mixers, and RTP translators as defined in [RFC3550]. For the
+ purposes of reporting connection quality to other RTP systems, RTP
+ mixers and RTP end systems are very similar. Mixers resynchronize
+
+
+
+Wu, et al. Informational [Page 12]
+
+RFC 6792 RTP Monitoring Framework November 2012
+
+
+ packets and do not relay RTCP reports received from one cloud towards
+ other cloud(s). Translators do not resynchronize packets and should
+ forward certain RTCP reports between clouds. In this category, the
+ RTP system (end system, mixer, or translator) that originates,
+ terminates, or forwards RTCP XR blocks is expected to handle RTCP,
+ including RTCP XR, according to RTP [RFC3550]. Provided this
+ expectation is met, an RTP system using RTCP XR is architecturally no
+ different from an RTP system of the same class (end system, mixer, or
+ translator) that does not use RTCP XR. The second category relates
+ to deployed system models used in many H.323 [H323] videoconferences.
+ The topologies in this category are Topo-Video-switch-MCU and
+ Topo-RTCP-terminating-MCU. Such topologies based on systems (e.g.,
+ MCUs) do not behave according to RTP [RFC3550].
+
+ Considering that the translator and MCU are two typical intermediate
+ systems in these two categories mentioned above, this document will
+ take them as two typical examples to explain how RTCP XR works in
+ different [RFC5117] topologies.
+
+7.1. Applicability to Translators
+
+ Section 7.2 of the RTP specification [RFC3550] describes the
+ processing of RTCP by translators. RTCP XR is within the scope of
+ the recommendations of [RFC3550]. Some RTCP XR metrics blocks may
+ usefully be measured at, and reported by, translators. As described
+ in [RFC3550], this creates a requirement for the translator to
+ allocate an SSRC for the monitor co-located with itself so that the
+ monitor may populate the SSRC in the RTCP XR packet header as the
+ packet sender SSRC and send it out (although the translator is not a
+ synchronization source in the sense of originating RTP media
+ packets). It must also supply this SSRC and the corresponding CNAME
+ in RTCP SDES packets.
+
+ In RTP sessions where one or more translators generate any RTCP
+ traffic towards their next-neighbor RTP system, other translators in
+ the session have a choice as to whether they forward a translator's
+ RTCP packets. Forwarding may provide additional information to other
+ RTP systems in the connection but increases RTCP bandwidth and may in
+ some cases present a security risk. RTP translators may have
+ forwarding behavior based on local policy, which might differ between
+ different interfaces of the same translator.
+
+7.2. Applicability to MCUs
+
+ Topo-Video-switch-MCU and Topo-RTCP-terminating-MCU suffer from the
+ difficulties described in [RFC5117]. These difficulties apply to
+ systems sending, and expecting to receive, RTCP XR blocks as much as
+ to systems using other RTCP packet types. For example, a participant
+
+
+
+Wu, et al. Informational [Page 13]
+
+RFC 6792 RTP Monitoring Framework November 2012
+
+
+ RTP end system may send media to a video switch MCU. If the media
+ stream is not selected for forwarding by the switch, neither RTCP RR
+ packets nor RTCP XR blocks referring to the end system's generated
+ stream will be received at the RTP end system. Strictly speaking,
+ the RTP end system can only conclude that its RTP has been lost in
+ the network, though an RTP end system complying with the robustness
+ principle of [RFC1122] should survive with essential functions (i.e.,
+ media distribution) unimpaired.
+
+8. Security Considerations
+
+ This document focuses on the RTCP reporting extension using RTCP XR
+ and should not give rise to any new security vulnerabilities beyond
+ those described in RTCP XRs [RFC3611]. However, it also describes
+ the architectural framework to be used for monitoring at the RTP
+ layer. The security issues with monitoring need to be considered.
+
+ In RTP sessions, an RTP system may use its own SSRC to send its
+ monitoring reports towards its next-neighbor RTP system. Other RTP
+ systems in the session may have a choice as to whether they forward
+ this RTP system's RTCP packets. This presents a security issue,
+ since the information in the report may be exposed by the other RTP
+ system to any malicious node. Therefore, if the information is
+ considered sensitive, the monitoring reports should be secured to the
+ same extent as the RTP flows that they measure. If encryption is
+ used and the encrypted monitoring report is received by the RTP
+ system that deploys the third-party monitor, the RTP system may
+ decrypt the monitor report for the third-party monitor based on local
+ policy (e.g., third-party monitors are allowed access to the metric)
+ and forward it to the third-party monitor; otherwise, the third-party
+ monitor should discard the received encrypted monitoring report.
+
+9. Acknowledgements
+
+ The authors would like to thank Colin Perkins, Charles Eckel, Robert
+ Sparks, Salvatore Loreto, Graeme Gibbs, Debbie Greenstreet, Keith
+ Drage, Dan Romascanu, Ali C. Begen, Roni Even, Magnus Westerlund,
+ Meral Shirazipour, Tina Tsou, Barry Leiba, Benoit Claise, Russ
+ Housley, and Stephen Farrell for their valuable comments and
+ suggestions on early versions of this document.
+
+
+
+
+
+
+
+
+
+
+
+Wu, et al. Informational [Page 14]
+
+RFC 6792 RTP Monitoring Framework November 2012
+
+
+10. Informative References
+
+ [G1020] ITU-T, "Performance parameter definitions for quality of
+ speech and other voiceband applications utilizing IP
+ networks", ITU-T Rec. G.1020, July 2006.
+
+ [H323] ITU-T, "Packet-based multimedia communications systems",
+ ITU-T Rec. H.323, December 2009.
+
+ [QOE_BLOCK] Clark, A., Wu, Q., Schott, R., and G. Zorn, "RTP Control
+ Protocol (RTCP) Extended Report (XR) Blocks for QoE
+ Metric Reporting", Work in Progress, October 2012.
+
+ [RFC1122] Braden, R., "Requirements for Internet Hosts -
+ Communication Layers", STD 3, RFC 1122, October 1989.
+
+ [RFC2959] Baugher, M., Strahm, B., and I. Suconick, "Real-Time
+ Transport Protocol Management Information Base",
+ RFC 2959, October 2000.
+
+ [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay
+ Variation Metric for IP Performance Metrics (IPPM)",
+ RFC 3393, November 2002.
+
+ [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
+ Jacobson, "RTP: A Transport Protocol for Real-Time
+ Applications", STD 64, RFC 3550, July 2003.
+
+ [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
+ Protocol Extended Reports (RTCP XR)", RFC 3611,
+ November 2003.
+
+ [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export
+ Version 9", RFC 3954, October 2004.
+
+ [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J.
+ Rey, "Extended RTP Profile for Real-time Transport
+ Control Protocol (RTCP)-Based Feedback (RTP/AVPF)",
+ RFC 4585, July 2006.
+
+ [RFC5101] Claise, B., "Specification of the IP Flow Information
+ Export (IPFIX) Protocol for the Exchange of IP Traffic
+ Flow Information", RFC 5101, January 2008.
+
+ [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
+ Meyer, "Information Model for IP Flow Information
+ Export", RFC 5102, January 2008.
+
+
+
+
+Wu, et al. Informational [Page 15]
+
+RFC 6792 RTP Monitoring Framework November 2012
+
+
+ [RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies",
+ RFC 5117, January 2008.
+
+ [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
+ Protocol (RTCP) Extensions for Single-Source Multicast
+ Sessions with Unicast Feedback", RFC 5760,
+ February 2010.
+
+ [RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the
+ RTP Control Protocol (RTCP)", RFC 5968, September 2010.
+
+ [RFC6035] Pendleton, A., Clark, A., Johnston, A., and H.
+ Sinnreich, "Session Initiation Protocol Event Package
+ for Voice Quality Reporting", RFC 6035, November 2010.
+
+ [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
+ Performance Metric Development", BCP 170, RFC 6390,
+ October 2011.
+
+ [RFC6776] Clark, A. and Q. Wu, "Measurement Identity and
+ Information Reporting Using a Source Description (SDES)
+ Item and an RTCP Extended Report (XR) Block", RFC 6776,
+ October 2012.
+
+ [RFC6798] Clark, A. and Q. Wu, "RTP Control Protocol (RTCP)
+ Extended Report (XR) Block for Packet Delay Variation
+ Metric Reporting", RFC 6798, November 2012.
+
+ [Y1540] ITU-T, "IP packet transfer and availability performance
+ parameters", ITU-T Rec. Y.1540, March 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wu, et al. Informational [Page 16]
+
+RFC 6792 RTP Monitoring Framework November 2012
+
+
+Authors' Addresses
+
+ Qin Wu (editor)
+ Huawei
+ 101 Software Avenue, Yuhua District
+ Nanjing, Jiangsu 210012
+ China
+
+ EMail: sunseawq@huawei.com
+
+
+ Geoff Hunt
+ Unaffiliated
+
+ EMail: r.geoff.hunt@gmail.com
+
+
+ Philip Arden
+ BT
+ Orion 3/7 PP4
+ Adastral Park
+ Martlesham Heath
+ Ipswich, Suffolk IP5 3RE
+ United Kingdom
+
+ Phone: +44 1473 644192
+ EMail: philip.arden@bt.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wu, et al. Informational [Page 17]
+