draft-ietf-avtcore-monarch-11.txt   draft-ietf-avtcore-monarch-12.txt 
Audio/Video Transport Working Group Q. Wu, Ed. Audio/Video Transport Working Group Q. Wu, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational G. Hunt Intended status: Informational G. Hunt
Expires: September 3, 2012 Unaffiliated Expires: October 20, 2012 Unaffiliated
P. Arden P. Arden
BT BT
March 2, 2012 April 18, 2012
Monitoring Architecture for RTP Monitoring Architecture for RTP
draft-ietf-avtcore-monarch-11.txt draft-ietf-avtcore-monarch-12.txt
Abstract Abstract
This memo proposes an architecture for extending RTP Control Protocol This memo proposes an architecture for extending RTP Control Protocol
(RTCP) with a new RTCP Extended Reports (XR) (RFC3611) block type to (RTCP) with a new RTCP Extended Reports (XR) (RFC3611) block type to
report new metrics regarding media transmission or reception quality, report new metrics regarding media transmission or reception quality,
following RTCP guideline established in RFC5968. This memo suggests following RTCP guideline established in RFC5968. This memo suggests
that a new block should contain a single metric or a small number of that a new block should contain a single metric or a small number of
metrics relevant to a single parameter of interest or concern, rather metrics relevant to a single parameter of interest or concern, rather
than containing a number of metrics which attempt to provide full than containing a number of metrics which attempt to provide full
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 3, 2012. This Internet-Draft will expire on October 20, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 3, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. RTP monitoring architecture . . . . . . . . . . . . . . . . . 7 3. RTP monitoring architecture . . . . . . . . . . . . . . . . . 7
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. RTCP Metric Block Report and associated parameters . . . . 10 3.2. RTCP Metric Block Report and associated parameters . . . . 10
3.3. RTP Sender/Receiver entities located in network nodes . . 11 3.3. RTP Sender/Receiver entities located in network nodes . . 11
4. Issues with reporting metric block using RTCP XR extension . . 12 4. Issues with reporting metric block using RTCP XR extension . . 12
5. Guideline for reporting metric block using RTCP XR . . . . . . 14 5. Guideline for reporting metric block using RTCP XR . . . . . . 14
5.1. Using single metrics blocks . . . . . . . . . . . . . . . 14 5.1. Using single metrics blocks . . . . . . . . . . . . . . . 14
5.2. Correlating RTCP XR with the non-RTP data . . . . . . . . 14 5.2. Correlating RTCP XR with RTP data . . . . . . . . . . . . 14
5.3. Reducing Measurement information repetition . . . . . . . 15 5.3. Correlating RTCP XR with the non-RTP data . . . . . . . . 15
5.4. Expanding the RTCP XR block namespace . . . . . . . . . . 15 5.4. Reducing Measurement information repetition . . . . . . . 15
5.5. Expanding the RTCP XR block namespace . . . . . . . . . . 16
6. An example of a metric block . . . . . . . . . . . . . . . . . 17 6. An example of a metric block . . . . . . . . . . . . . . . . . 17
7. Application to RFC 5117 topologies . . . . . . . . . . . . . . 18 7. Application to RFC 5117 topologies . . . . . . . . . . . . . . 18
7.1. Applicability to MCU . . . . . . . . . . . . . . . . . . . 18 7.1. Applicability to MCU . . . . . . . . . . . . . . . . . . . 18
7.2. Applicability to Translators . . . . . . . . . . . . . . . 19 7.2. Applicability to Translators . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 22
11. Informative References . . . . . . . . . . . . . . . . . . . . 23 11. Informative References . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25
A.1. draft-ietf-avtcore-monarch-00 . . . . . . . . . . . . . . 25 A.1. draft-ietf-avtcore-monarch-12 . . . . . . . . . . . . . . 25
A.2. draft-ietf-avtcore-monarch-01 . . . . . . . . . . . . . . 25 A.2. draft-ietf-avtcore-monarch-11 . . . . . . . . . . . . . . 25
A.3. draft-ietf-avtcore-monarch-02 . . . . . . . . . . . . . . 25 A.3. draft-ietf-avtcore-monarch-10 . . . . . . . . . . . . . . 25
A.4. draft-ietf-avtcore-monarch-03 . . . . . . . . . . . . . . 26 A.4. draft-ietf-avtcore-monarch-09 . . . . . . . . . . . . . . 25
A.5. draft-ietf-avtcore-monarch-04 . . . . . . . . . . . . . . 26 A.5. draft-ietf-avtcore-monarch-08 . . . . . . . . . . . . . . 26
A.6. draft-ietf-avtcore-monarch-05 . . . . . . . . . . . . . . 26 A.6. draft-ietf-avtcore-monarch-07 . . . . . . . . . . . . . . 26
A.7. draft-ietf-avtcore-monarch-06 . . . . . . . . . . . . . . 27 A.7. draft-ietf-avtcore-monarch-06 . . . . . . . . . . . . . . 26
A.8. draft-ietf-avtcore-monarch-07 . . . . . . . . . . . . . . 27 A.8. draft-ietf-avtcore-monarch-05 . . . . . . . . . . . . . . 26
A.9. draft-ietf-avtcore-monarch-08 . . . . . . . . . . . . . . 27 A.9. draft-ietf-avtcore-monarch-04 . . . . . . . . . . . . . . 26
A.10. draft-ietf-avtcore-monarch-09 . . . . . . . . . . . . . . 27 A.10. draft-ietf-avtcore-monarch-03 . . . . . . . . . . . . . . 27
A.11. draft-ietf-avtcore-monarch-10 . . . . . . . . . . . . . . 27 A.11. draft-ietf-avtcore-monarch-02 . . . . . . . . . . . . . . 27
A.12. draft-ietf-avtcore-monarch-11 . . . . . . . . . . . . . . 28 A.12. draft-ietf-avtcore-monarch-01 . . . . . . . . . . . . . . 27
A.13. draft-ietf-avtcore-monarch-00 . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
As the delivery of multimedia services using the Real-Time Transport As the delivery of multimedia services using the Real-Time Transport
Protocol (RTP) over IP network is gaining an increasing popularity, Protocol (RTP) over IP network is gaining an increasing popularity,
uncertainties in the performance and availability of these services uncertainties in the performance and availability of these services
are driving the need to support new standard methods for gathering are driving the need to support new standard methods for gathering
performance metrics from RTP applications. These rapidly emerging performance metrics from RTP applications. These rapidly emerging
standards, such as RTP Control Protocol Extended Reports (RTCP standards, such as RTP Control Protocol Extended Reports (RTCP
XR)[RFC3611] and other RTCP extension to Sender Reports (SR), XR)[RFC3611] and other RTCP extension to Sender Reports (SR),
Receiver Reports (RR) [RFC3550] are being developed for the purpose Receiver Reports (RR) [RFC3550] are being developed for the purpose
of collecting and reporting performance metrics from endpoint devices of collecting and reporting performance metrics from endpoint devices
that can be used to correlate the metrics, provide end to end service that can be used to correlate the metrics, provide end to end service
visibility and measure and monitor Quality of Experience (QoE) visibility and measure and monitor Quality of Experience (QoE)
[RFC6390]. [RFC6390].
However the proliferation of RTP/RTCP specific metrics for transport However the proliferation of RTP/RTCP specific metrics for transport
and application quality monitoring has been identified as a potential and application quality monitoring has been identified as a potential
problem for RTP/RTCP interoperability, which attempt to provide full problem for interoperability when using RTP/RTCP to communicate all
coverage of all those parameters of concern to a specific the parameters of concern to a specific application. Given that
application. Given that different applications layered on RTP may different applications layered on RTP may have some monitoring
have some monitoring requirements in common, these metrics should be requirements in common, these metrics should be satisfied by a common
satisfied by a common design. design.
The objective of this document is to define an extensible RTP The objective of this document is to define an extensible RTP
monitoring framework to provide a small number of re-usable Quality monitoring framework to provide a small number of re-usable Quality
of Service (QoS)/QoE metrics which facilitate reduced implementation of Service (QoS)/QoE metrics which facilitate reduced implementation
costs and help maximize inter-operability. RTCP Guideline [RFC5968] costs and help maximize inter-operability. RTCP Guideline [RFC5968]
has stated that, where RTCP is to be extended with a new metric, the 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] preferred mechanism is by the addition of a new RTCP XR [RFC3611]
block. This memo assumes that any requirement for a new metric to be block. This memo assumes that any requirement for a new metric to be
transported in RTCP will use a new RTCP XR block. transported in RTCP will use a new RTCP XR block.
skipping to change at page 5, line 25 skipping to change at page 5, line 25
impairments of packet loss, packet delay, and packet delay impairments of packet loss, packet delay, and packet delay
variation. These metrics should be usable by any application variation. These metrics should be usable by any application
which uses RTP transport. which uses RTP transport.
Application level metrics Application level metrics
Metrics relating to application specific parameters or QoE related Metrics relating to application specific parameters or QoE related
parameters. Application specific parameters are measured at the parameters. Application specific parameters are measured at the
application level and focus on quality of content rather than application level and focus on quality of content rather than
network performance. QoE related parameters reflect the end-to- network performance. QoE related parameters reflect the end-to-
end performance at the services level and is ususally measured at end performance at the services level and are ususally measured at
the user endpoint. One example of such metrics is the QoE Metric the user endpoint. One example of such metrics is the QoE Metric
specified in QoE metric reporting Block [QOE]. specified in QoE metric reporting Block [QOE].
End System metrics End System metrics
Metrics relating to the way a terminal deals with transport Metrics relating to the way a terminal deals with transport
impairments affecting the incident RTP stream. These may include impairments affecting the incident RTP stream. These may include
de-jitter buffering, packet loss concealment, and the use of de-jitter buffering, packet loss concealment, and the use of
redundant streams (if any) for correction of error or loss. redundant streams (if any) for correction of error or loss.
Direct metrics Direct metrics
Metrics that can be directly measured or calculated and are not Metrics that can be directly measured or calculated and are not
dependent on other metric. dependent on other metrics.
Composed metrics Composed metrics
Metrics that are not directly measured and derived from other Metrics that are not measured directly but rather are derived from
metrics. One example of such metrics is the ones calculated based one or more other metrics. An example is a metric calculated
on Direct metric that have been measured. based on derived metrics that have been measured.
Interval metrics Interval metrics
It is referred to as the metrics of which the reported values It is referred to as the metrics of which the reported values
apply to the most recent measurement interval duration between apply to the most recent measurement interval duration between
successive metrics reports. successive metrics reports.
Cumulative metrics Cumulative metrics
It is referred to as the metrics of which the reported values It is referred to as the metrics of which the reported values
apply to the accumulation period characteristic of cumulative apply to the accumulation period characteristic of cumulative
measurements. measurements.
Sampled metrics Sampled metrics
It is referred to as the metrics of which the reported values only It is referred to as the metrics of which the reported values only
apply to the value of a continuously measured or calculated that apply to the value of a continuously measured or calculated metric
has been sampled at any given instance of the interval. that has been sampled at any given instance of the interval.
3. RTP monitoring architecture 3. RTP monitoring architecture
There are many ways in which the performance of an RTP session can be There are many ways in which the performance of an RTP session can be
monitored. These include RTP-based mechanisms such as the RTP SNMP monitored. These include RTP-based mechanisms such as the RTP SNMP
MIB [RFC2959], or the SIP event package for RTCP summary reports MIB [RFC2959], or the SIP event package for RTCP summary reports
[RFC6035], or non-RTP mechanisms such as generic MIBs, NetFlow, [RFC6035], or non-RTP mechanisms such as generic MIBs, NetFlow,
IPFix, and so on. Together, these provide useful mechanisms for IPFix, and so on. Together, these provide useful mechanisms for
exporting data on the performance of an RTP session to non-RTP exporting data on the performance of an RTP session to non-RTP
network management systems. It is desirable to also perform in- network management systems. It is desirable to also perform in-
session monitoring of RTP performance. RTCP provides the means to do session monitoring of RTP performance. RTCP provides the means to do
this. In the following, we specify an architecture for using and this. In the following, we specify an architecture for using and
extending RTCP for monitoring RTP sessions. One major benefit of extending RTCP for monitoring RTP sessions. One major benefit of
such architecture is ease of integration with other RTP/RTCP such architecture is ease of integration with other RTP/RTCP
mechanism. mechanisms.
3.1. Overview 3.1. Overview
The RTP monitoring architecture comprises the following two key The RTP monitoring architecture comprises the following two key
functional components shown below: functional components shown below:
o RTP Monitor o RTP Monitor
o RTP Metric Block Structure o RTP Metric Block Structure
skipping to change at page 10, line 13 skipping to change at page 10, line 13
2. Application level metrics collection. 2. Application level metrics collection.
3. Transport level metrics collection. 3. Transport level metrics collection.
4. End System metrics collection. 4. End System metrics collection.
5. Metrics Reporting over the RTP/RTCP paths 5. Metrics Reporting over the RTP/RTCP paths
6. RTCP information Export to the network management system. 6. RTCP information Export to the network management system.
RTP is used to multicast groups, both ASM and SSM. These groups can RTP may be used to multicast groups, both Any Source Multicast (ASM)
be monitored using RTCP. In the ASM case, the monitor is a member of and Source Specific Multicast (SSM). These groups can be monitored
the multicast group and listens to RTCP XR reports from all members using RTCP. In the ASM case, the monitor is a member of the
of the ASM group. In the SSM case, there is a unicast feedback multicast group and listens to RTCP XR reports from all members of
target that receives RTCP feedback from receivers and distributes it the ASM group. In the SSM case, there is a unicast feedback target
to other members of the SSM group (see figure 1 of RFC5760). The 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 monitor will need to be co-located with the feedback target to
receive all feedback from the receivers (this may also be an receive all feedback from the receivers (this may also be an
intermediate system). In both ASM and SSM scenarios, receivers can intermediate system). In both ASM and SSM scenarios, receivers can
send RTCP XR reports to enhance the reception quality reporting. send RTCP XR reports to enhance the reception quality reporting.
3.2. RTCP Metric Block Report and associated parameters 3.2. RTCP Metric Block Report and associated parameters
The basic RTCP Reception Report (RR) [RFC3550] conveys reception The basic RTCP Reception Report (RR) [RFC3550] conveys reception
statistics (i.e., transport level statistics) in metric block report statistics (i.e., transport level statistics) in metric block report
format for multiple RTP media streams including format for multiple RTP media streams including
skipping to change at page 12, line 21 skipping to change at page 12, line 21
o Using compound metrics block. A single report block o Using compound metrics block. A single report block
(i.e.,compound metrics block) is designed to contain a large (i.e.,compound metrics block) is designed to contain a large
number of parameters in different classes for a specific number of parameters in different classes for a specific
application. For example, the RTCP Extended Reports (XRs) application. For example, the RTCP Extended Reports (XRs)
[RFC3611] defines seven report block formats for network [RFC3611] defines seven report block formats for network
management and quality monitoring. Some of these block types management and quality monitoring. Some of these block types
defined in the RTCP XRs [RFC3611] are only specifically designed defined in the RTCP XRs [RFC3611] are only specifically designed
for conveying multicast inference of network characteristics for conveying multicast inference of network characteristics
(MINC) or voice over IP (VoIP) monitoring. However different (MINC) or voice over IP (VoIP) monitoring. However different
applications layered on RTP may have different monitoring applications layered on RTP may have different monitoring
requirements. Design compound metrics block only for specific requirements. Designing compound metrics block only for specific
applications may increase implementation cost and minimize applications may increase implementation cost and minimize
interoperability. interoperability.
o Correlating RTCP XR with the non-RTP data. Canonical End-Point o Correlating RTCP XR with the non-RTP data. Canonical End-Point
Identifier SDES Item (CNAME) defined in the RTP Protocol [RFC3550] Identifier SDES Item (CNAME), defined in the RTP Protocol
is an example of existing tool that allows to bind an [RFC3550], is an example of an existing tool that allows binding a
Synchronization source (SSRC) that may change to a fixed source Synchronization source (SSRC) that may change to a name that is
name in one RTP session. It may be also fixed across multiple RTP fixed within one RTP session. CNAME may be also fixed across
sessions from the same source. However there may be situations multiple RTP sessions from the same source. However there may be
where RTCP reports are sent to other participating endpoints using situations where RTCP reports are sent to other participating
non-RTP protocol in a session. For example, as described in the endpoints using non-RTP protocol in a session. For example, as
SIP RTCP Summary Report Protocol [RFC6035], the data contained in described in the SIP RTCP Summary Report Protocol [RFC6035], the
RTCP XR VoIP metrics reports [RFC3611] are forwarded to a central data contained in RTCP XR VoIP metrics reports [RFC3611] are
collection server systems using SIP. In such case, there is a forwarded to a central collection server systems using SIP. In
large portfolio of quality parameters that can be associated with such case, there is a large portfolio of quality parameters that
real time application, e.g., VOIP application, but only a minimal can be associated with real time application, e.g., VOIP
number of parameters are included on the RTCP-XR reports. application, but only a minimal number of parameters are included
Therefore correlation between RTCP XR and non-RTP data should be on the RTCP-XR reports. Therefore correlation between RTCP XR and
concerned if administration or management systems need to rely on non-RTP data should be provided if administration or management
the mapping RTCP statistics to non-RTCP measurements to conducts systems need to rely on the mapping RTCP statistics to non-RTCP
data analysis and creates alerts to the users. Without such measurements to conducts data analysis and creates alerts to the
correlation, it is hard to provide accurate measures of real time users. Without such correlation, it is hard to provide accurate
application quality with a minimal number of parameters included measures of real time application quality with a minimal number of
on the RTCP-XR reports in such case. parameters included on the RTCP-XR reports in such case.
o Measurement Information duplication. Measurement information o Measurement Information duplication. Measurement information
provides information relevant to a measurement reported in one or provides information relevant to a measurement reported in one or
more other block types. For example we may set a metric interval more other block types. For example we may set a metric interval
for the session and monitor RTP packets within one or several for the session and monitor RTP packets within one or several
consecutive metric interval. In such case, the extra measurement consecutive metric intervals. In such case, the extra measurement
information (e.g., extended sequence number of 1st packet, information (e.g., extended sequence number of 1st packet,
measurement period) may be expected. However if we put such extra measurement period) may be expected. However if we put such extra
measurement information into each metric block, there may be measurement information into each metric block, there may be
situations where an RTCP XR packet containing multiple metric situations where an RTCP XR packet containing multiple metric
blocks, reports on the same streams from the same source. In blocks, reports on the same streams from the same source. In
other words, duplicated data for the measurement is provided other words, duplicated data for the measurement is provided
multiple times, once in every metric block. Though this design multiple times, once in every metric block. Though this design
ensures immunity to packet loss, it may bring more packetization ensures immunity to packet loss, it may bring more packetization
complexity and the processing overhead is not completely trivial complexity and the processing overhead is not completely trivial
in some cases. Therefore compromise between processing overhead in some cases. Therefore compromise between processing overhead
skipping to change at page 14, line 31 skipping to change at page 14, line 31
conditions. However there are many metrics available. It is likely conditions. However there are many metrics available. It is likely
that different applications or classes of applications will wish to that different applications or classes of applications will wish to
use different metrics. Any one application is likely to require use different metrics. Any one application is likely to require
metrics for more than one parameter but if this is the case, metrics for more than one parameter but if this is the case,
different applications will almost certainly require different different applications will almost certainly require different
combinations of metrics. If larger blocks are defined containing combinations of metrics. If larger blocks are defined containing
multiple metrics to address the needs of each application, it becomes multiple metrics to address the needs of each application, it becomes
likely that many different such larger blocks are defined, which likely that many different such larger blocks are defined, which
becomes a danger to interoperability. becomes a danger to interoperability.
To avoid this pitfall, this memo proposes the use of single metrics To avoid this pitfall, this memo recommends the definition of metrics
blocks each containing a very small number of individual metrics blocks containing a very small number of individual metrics
characterizing only one parameter of interest to an application characterizing only one parameter of interest to an application
running over RTP. For example, at the RTP transport layer, the running over RTP. For example, at the RTP transport layer, the
parameter of interest might be packet delay variation, and parameter of interest might be packet delay variation, and
specifically the metric "IP Packet Delay Variation (IPDV)" defined by specifically the metric "IP Packet Delay Variation (IPDV)" defined by
[Y1540]. See Section 6 for architectural considerations for a [Y1540]. See Section 6 for architectural considerations for a
metrics block, using as an example a metrics block to report packet metrics block, using as an example a metrics block to report packet
delay variation. 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. Correlating RTCP XR with the non-RTP data 5.2. Correlating RTCP XR with RTP data
There may be situation where more than one media transport protocols There are some classes of metrics that can only be interpreted with
are used by one application to interconnect to the same session in knowledge of the media codec that is being used (audio MOS scores
the gateway. For example, one RTCP XR Packet is sent to the were the triggering example, but there may be others). In such cases
the correlation of RTCP XR with RTP data is needed. Report blocks
that require such correlation need to include the payload type of the
reported media, and must signal details and parameters of the payload
format to which that payload type is bound.
5.3. Correlating RTCP XR with the 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., participating endpoints using non-RTP-based media transport (e.g.,
using SIP) in a VOIP session, one crucial factor lies in how to using SIP) in a VOIP session. One crucial factor lies in how to
handle their different identities that are corresponding to different handle their different identities that are corresponding to different
media transport. media transport.
This memo proposes an approach to facilitate the correlation of the This memo recommends an approach to facilitate the correlation of the
RTCP Session with other session-related non-RTP data. That is to say 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, if there is a need to correlate RTP sessions with non-RTP sessions,
then the correlation information needed should be conveyed in a new then the correlation information needed should be conveyed in a new
RTCP Source Description (SDES) item, since such correlation RTCP Source Description (SDES) item, since such correlation
information describes the source, rather than providing a quality information describes the source, rather than providing a quality
report. An example use case is for a participant endpoint may convey report. An example use case is for a participant endpoint may convey
a call identifier or a global call identifier associated with the a call identifier or a global call identifier associated with the
SSRC of measured RTP stream. In such case, the participant endpoint SSRC of measured RTP stream. In such case, the participant endpoint
uses the SSRC of source to bind the call identifier using SDES item uses the SSRC of source to bind the call identifier using SDES item
in the SDES RTCP packet and send such correlation to the network in the SDES RTCP packet and send such correlation to the network
management system. A flow measurement tool that is configured with management system. A flow measurement tool that is configured with
the 5-tuple and not call-aware then forward the RTCP XR reports along the 5-tuple and not call-aware then forward the RTCP XR reports along
with the SSRC of the measured RTP stream which is included in the XR with the SSRC of the measured RTP stream which is included in the XR
Block header and 5-tuple to the network management system. Network Block header and 5-tuple to the network management system. Network
management system can then correlate this report using SSRC with management system can then correlate this report using SSRC with
other diagnostic information such as call detail records. other diagnostic information such as call detail records.
5.3. Reducing Measurement information repetition 5.4. Reducing Measurement information repetition
When multiple metric blocks are carried in one RTCP XR packet, When multiple metric blocks are carried in one RTCP XR packet,
reporting on the same stream from the same source for the same time reporting on the same stream from the same source for the same time
period, RTCP should use the SSRC to identify and correlate the period, RTCP should use the SSRC to identify and correlate the
multiple metric blocks between metric blocks. This memo proposes to multiple metric blocks between metric blocks. This memo proposes to
define a new XR Block that will be used to convey the common time define a new XR Block that will be used to convey the common time
period and the number of packets sent during this period. If the period and the number of packets sent during this period. If the
measurement interval for a metric is different from the RTCP measurement interval for a metric is different from the RTCP
reporting interval, then this measurement duration in the Measurement reporting interval, then this measurement duration in the Measurement
information block [MI] should be used to specify the interval. When information block [MI] should be used to specify the interval. When
skipping to change at page 15, line 48 skipping to change at page 16, line 14
most cases, it is expected that the correct response is to discard most cases, it is expected that the correct response is to discard
the received metric. In order to reduce measurement information the received metric. In order to reduce measurement information
repetition in one RTCP XR compound packet containing multiple metric repetition in one RTCP XR compound packet containing multiple metric
blocks, the measurement information shall be sent before the related blocks, the measurement information shall be sent before the related
metric blocks that are from the same reporting interval. Note that metric blocks that are from the same reporting interval. Note that
for packet loss robustness if the report blocks for the same interval for packet loss robustness if the report blocks for the same interval
span over more than one RTCP packet then each must have the span over more than one RTCP packet then each must have the
measurement identity information even if though they will be the measurement identity information even if though they will be the
same. same.
5.4. Expanding the RTCP XR block namespace 5.5. Expanding the RTCP XR block namespace
The consumption of XR block code points isn't a major issue. However The consumption of XR block code points isn't a major issue. However
if XR block codes points is really close to run out of space, it if XR block codes points is really close to run out of space, it
might be desirable to define new fields in the XR report block or might be desirable to define new fields in the XR report block or
define one XR block type for vendor-specific extensions, with an define one XR block type for vendor-specific extensions, with an
enterprise number included to identify the vendor making the enterprise number included to identify the vendor making the
extension. extension.
6. An example of a metric block 6. An example of a metric block
skipping to change at page 22, line 7 skipping to change at page 22, line 7
sensitive, the monitoring report should be encrypted. sensitive, the monitoring report should be encrypted.
Also note that the third party monitors are not visible at the RTP Also note that the third party monitors are not visible at the RTP
layer since they do not send any RTCP packets. In order to prevent layer since they do not send any RTCP packets. In order to prevent
any sensitive information leakage, the monitoring from the third any sensitive information leakage, the monitoring from the third
party monitors should be prohibited unless the security is in place party monitors should be prohibited unless the security is in place
to authenticate them. to authenticate them.
10. Acknowledgement 10. Acknowledgement
The authors would also like to thank Colin Perkins, Graeme Gibbs, The authors would also like to thank Colin Perkins, Charles Eckel,
Debbie Greenstreet, Keith Drage, Dan Romascanu, Ali C. Begen, Roni Graeme Gibbs, Debbie Greenstreet, Keith Drage, Dan Romascanu, Ali C.
Even, Magnus Westerlund for their valuable comments and suggestions Begen, Roni Even, Magnus Westerlund for their valuable comments and
on the early version of this document. suggestions on the early version of this document.
11. Informative References 11. Informative References
[ECN] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., [ECN] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN) and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", ID draft-ietf-avtcore-ecn-for-rtp-06, for RTP over UDP", ID draft-ietf-avtcore-ecn-for-rtp-07,
February 2012. March 2012.
[G1020] ITU-T, "ITU-T Rec. G.1020, Performance parameter [G1020] ITU-T, "ITU-T Rec. G.1020, Performance parameter
definitions for quality of speech and other voiceband definitions for quality of speech and other voiceband
applications utilizing IP networks", July 2006. applications utilizing IP networks", July 2006.
[H323] ITU-T, "ITU-T Rec. H.323, Packet-based multimedia [H323] ITU-T, "ITU-T Rec. H.323, Packet-based multimedia
communications systems", June 2006. communications systems", June 2006.
[MI] Wu, Q., "Measurement Identity and information Reporting [MI] Wu, Q., "Measurement Identity and information Reporting
using SDES item and XR Block", using SDES item and XR Block",
ID draft-ietf-xrblock-rtcp-xr-meas-identity-02, ID draft-ietf-xrblock-rtcp-xr-meas-identity-05,
January 2012. April 2012.
[P.NAMS] ITU-T, "Non-intrusive parametric model for the Assessment [P.NAMS] ITU-T, "Non-intrusive parametric model for the Assessment
of performance of Multimedia Streaming", ITU-T of performance of Multimedia Streaming", ITU-T
Recommendation P.NAMS, November 2009. Recommendation P.NAMS, November 2009.
[PDV] Hunt, G., Clark, A., and Q. Wu, "RTCP XR Report Block for [PDV] Hunt, G., Clark, A., and Q. Wu, "RTCP XR Report Block for
Packet Delay Variation Metric Reporting", Packet Delay Variation Metric Reporting",
ID draft-ietf-xrblock-rtcp-xr-pdv-02, December 2011. ID draft-ietf-xrblock-rtcp-xr-pdv-02, December 2011.
[QOE] Hunt, G., Clark, A., Wu, Q., Schott, R., and G. Zorn, [QOE] Hunt, G., Clark, A., Wu, Q., Schott, R., and G. Zorn,
skipping to change at page 25, line 10 skipping to change at page 25, line 10
Performance Metric Development", RFC 6390, October 2011. Performance Metric Development", RFC 6390, October 2011.
[Y1540] ITU-T, "ITU-T Rec. Y.1540, IP packet transfer and [Y1540] ITU-T, "ITU-T Rec. Y.1540, IP packet transfer and
availability performance parameters", November 2007. availability performance parameters", November 2007.
Appendix A. Change Log Appendix A. Change Log
Note to the RFC-Editor: please remove this section prior to Note to the RFC-Editor: please remove this section prior to
publication as an RFC. publication as an RFC.
A.1. draft-ietf-avtcore-monarch-00 A.1. draft-ietf-avtcore-monarch-12
The following are the major changes compared to The following are the major changes compared to 11:
draft-hunt-avtcore-monarch-02:
o Move Geoff Hunt and Philip Arden to acknowledgement section. o Editorial Changes based on Charles' Comments.
A.2. draft-ietf-avtcore-monarch-01 o Reference update.
The following are the major changes compared to 00: o Add one new section 5.2 to discuss Correlating RTCP XR with RTP
data.
o Restructure the document by merging section 4 into section 3. o Add text in section 5.1 to highlight it is more appropriate to
define each block in a separate draft.
o Remove section 4.1,section 5 that is out of scope of this A.2. draft-ietf-avtcore-monarch-11
document.
o Remove the last bullet in section 6 and section 7.3 based on The following are the major changes compared to 10:
conclusion of last meeting.
o Update figure 1 and related text in section 3 according to the o Editorial Changes.
monitor definition in RFC3550.
o Revise section 9 to address monitor declaration issue. A.3. draft-ietf-avtcore-monarch-10
o Merge the first two bullet in section 6. The following are the major changes compared to 09:
o Add one new bullet to discuss metric block association in section o Discuss what exist already for monitoring in section 3.1.
6.
A.3. draft-ietf-avtcore-monarch-02 o Provide benefit using RTCP XR based monitoring in section 3.1.
The following are the major changes compared to 01: o add one new paragraph in section 3.1 to describe how monitoring
architecture is applied to ASM/SSM.
o Deleting first paragraph of Section 1. o Other Editorial Changes.
o Deleting Section 3.1, since the interaction with the management A.4. draft-ietf-avtcore-monarch-09
application is out of scope of this draft.
o Separate identity information correlation from section 5.2 as new The following are the major changes compared to 07:
section 5.3.
o Remove figure 2 and related text from section 5.2. o Rephrase application level metric definition.
o Editorial changes in the section 4 and the first paragraph of o Add one new section to clarify where to measure QoE related
section 7. parameters.
A.4. draft-ietf-avtcore-monarch-03 o Add text in section 5.3 to clarify the failure case when
measurement interval is not sent.
The following are the major changes compared to 02: o Add text in section 5.3 to clarify how to deal with multiple
measurements information blocks carried in the same packet.
o Update bullet 2 in section 4 to explain the ill-effect of Identity A.5. draft-ietf-avtcore-monarch-08
Information duplication.
o Update bullet 3 in section 4 to explain why Correlating RTCP XR The following are the major changes compared to 07:
with the non-RTP data is needed.
o Update section 5.2 to focus on how to reduce the identity o Editorial change to the reference.
information repetition
o Update section 5.3 to explain how to correlate identity A.6. draft-ietf-avtcore-monarch-07
information with the non-RTP data
A.5. draft-ietf-avtcore-monarch-04 The following are the major changes compared to 06:
The following are the major changes compared to 03: o Clarify the XR block code points consumption issue in the section
4 and new section 5.4.
o Update section 5.2 to clarify using SDES packet to carry o Other editorial changes.
correlation information.
o Remove section 5.3 since additional identity information goes to A.7. draft-ietf-avtcore-monarch-06
SDES packet and using SSRC to identify each block is standard RTP
feature.
o Swap the last two paragraphs in the section 4 since identity The following are the major changes compared to 05:
information duplication can not been 100% avoided.
o Other editorial changes. o Some editorial changes.
A.6. draft-ietf-avtcore-monarch-05 A.8. draft-ietf-avtcore-monarch-05
The following are the major changes compared to 04: The following are the major changes compared to 04:
o Replace "chunk" with "new SDES item". o Replace "chunk" with "new SDES item".
o Add texts in security section to discussion potential security o Add texts in security section to discussion potential security
issues. issues.
o Add new sub-section 5.3 to discuss Reducing Measurement o Add new sub-section 5.3 to discuss Reducing Measurement
information repetition. information repetition.
o Other editorial changes. o Other editorial changes.
A.7. draft-ietf-avtcore-monarch-06 A.9. draft-ietf-avtcore-monarch-04
The following are the major changes compared to 05:
o Some editorial changes. The following are the major changes compared to 03:
A.8. draft-ietf-avtcore-monarch-07 o Update section 5.2 to clarify using SDES packet to carry
correlation information.
The following are the major changes compared to 06: o Remove section 5.3 since additional identity information goes to
SDES packet and using SSRC to identify each block is standard RTP
feature.
o Clarify the XR block code points consumption issue in the section o Swap the last two paragraphs in the section 4 since identity
4 and new section 5.4. information duplication can not been 100% avoided.
o Other editorial changes. o Other editorial changes.
A.9. draft-ietf-avtcore-monarch-08 A.10. draft-ietf-avtcore-monarch-03
The following are the major changes compared to 07: The following are the major changes compared to 02:
o Editorial change to the reference. o Update bullet 2 in section 4 to explain the ill-effect of Identity
Information duplication.
A.10. draft-ietf-avtcore-monarch-09 o Update bullet 3 in section 4 to explain why Correlating RTCP XR
with the non-RTP data is needed.
The following are the major changes compared to 07: o Update section 5.2 to focus on how to reduce the identity
information repetition
o Rephrase application level metric definition. o Update section 5.3 to explain how to correlate identity
information with the non-RTP data
o Add one new section to clarify where to measure QoE related A.11. draft-ietf-avtcore-monarch-02
parameters.
o Add text in section 5.3 to clarify the failure case when The following are the major changes compared to 01:
measurement interval is not sent.
o Add text in section 5.3 to clarify how to deal with multiple o Deleting first paragraph of Section 1.
measurements information blocks carried in the same packet.
A.11. draft-ietf-avtcore-monarch-10 o Deleting Section 3.1, since the interaction with the management
application is out of scope of this draft.
The following are the major changes compared to 09: o Separate identity information correlation from section 5.2 as new
section 5.3.
o Discuss what exist already for monitoring in section 3.1. o Remove figure 2 and related text from section 5.2.
o Provide benefit using RTCP XR based monitoring in section 3.1. o Editorial changes in the section 4 and the first paragraph of
section 7.
o add one new paragraph in section 3.1 to describe how monitoring A.12. draft-ietf-avtcore-monarch-01
architecture is applied to ASM/SSM.
o Other Editorial Changes. The following are the major changes compared to 00:
A.12. draft-ietf-avtcore-monarch-11 o Restructure the document by merging section 4 into section 3.
The following are the major changes compared to 10: o Remove section 4.1,section 5 that is out of scope of this
document.
o Editorial Changes. o Remove the last bullet in section 6 and section 7.3 based on
conclusion of last meeting.
o Update figure 1 and related text in section 3 according to the
monitor definition in RFC3550.
o Revise section 9 to address monitor declaration issue.
o Merge the first two bullet in section 6.
o Add one new bullet to discuss metric block association in section
6.
A.13. draft-ietf-avtcore-monarch-00
The following are the major changes compared to
draft-hunt-avtcore-monarch-02:
o Move Geoff Hunt and Philip Arden to acknowledgement section.
Authors' Addresses Authors' Addresses
Qin Wu (editor) Qin Wu (editor)
Huawei Huawei
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
Email: sunseawq@huawei.com Email: sunseawq@huawei.com
 End of changes. 82 change blocks. 
158 lines changed or deleted 188 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/