doc: Add RFC documents

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]
+