draft-ietf-avtcore-monarch-05.txt   draft-ietf-avtcore-monarch-06.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: April 27, 2012 Unaffiliated Expires: May 17, 2012 Unaffiliated
P. Arden P. Arden
BT BT
October 25, 2011 November 14, 2011
Monitoring Architectures for RTP Monitoring Architectures for RTP
draft-ietf-avtcore-monarch-05.txt draft-ietf-avtcore-monarch-06.txt
Abstract Abstract
This memo proposes an architecture for extending RTCP with a new RTCP This memo proposes an architecture for extending RTCP with a new RTCP
XR (RFC3611) block type to report new metrics regarding media XR (RFC3611) block type to report new metrics regarding media
transmission or reception quality, following RTCP guideline transmission or reception quality, following RTCP guideline
established in RFC5968. This memo suggests that a new block should established in RFC5968. This memo suggests that a new block should
contain a single metric or a small number of metrics relevant to a contain a single metric or a small number of metrics relevant to a
single parameter of interest or concern, rather than containing a single parameter of interest or concern, rather than containing a
number of metrics which attempt to provide full coverage of all those number of metrics which attempt to provide full coverage of all those
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 April 27, 2012. This Internet-Draft will expire on May 17, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
3. RTP monitoring architecture . . . . . . . . . . . . . . . . . 5 3. RTP monitoring architecture . . . . . . . . . . . . . . . . . 6
3.1. RTCP Metric Block Report and associated parameters . . . . 7 3.1. RTCP Metric Block Report and associated parameters . . . . 8
4. Issues with reporting metric block using RTCP XR extension . . 9 4. Issues with reporting metric block using RTCP XR extension . . 10
5. Guideline for reporting metric block using RTCP XR . . . . . . 11 5. Guideline for reporting metric block using RTCP XR . . . . . . 12
5.1. Using single metric blocks . . . . . . . . . . . . . . . . 11 5.1. Using single metrics blocks . . . . . . . . . . . . . . . 12
5.2. Correlating RTCP XR with the non-RTP data . . . . . . . . 11 5.2. Correlating RTCP XR with the non-RTP data . . . . . . . . 12
5.3. Reducing Measurement information repetition . . . . . . . 12 5.3. Reducing Measurement information repetition . . . . . . . 13
6. An example of a metric block . . . . . . . . . . . . . . . . . 13 6. An example of a metric block . . . . . . . . . . . . . . . . . 14
7. Application to RFC 5117 topologies . . . . . . . . . . . . . . 14 7. Application to RFC 5117 topologies . . . . . . . . . . . . . . 15
7.1. Applicability to MCU . . . . . . . . . . . . . . . . . . . 14 7.1. Applicability to MCU . . . . . . . . . . . . . . . . . . . 15
7.2. Applicability to Translators . . . . . . . . . . . . . . . 15 7.2. Applicability to Translators . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19
11. Informative References . . . . . . . . . . . . . . . . . . . . 19 11. Informative References . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22
A.1. draft-ietf-avtcore-monarch-00 . . . . . . . . . . . . . . 21 A.1. draft-ietf-avtcore-monarch-00 . . . . . . . . . . . . . . 22
A.2. draft-ietf-avtcore-monarch-01 . . . . . . . . . . . . . . 21 A.2. draft-ietf-avtcore-monarch-01 . . . . . . . . . . . . . . 22
A.3. draft-ietf-avtcore-monarch-02 . . . . . . . . . . . . . . 21 A.3. draft-ietf-avtcore-monarch-02 . . . . . . . . . . . . . . 22
A.4. draft-ietf-avtcore-monarch-03 . . . . . . . . . . . . . . 22 A.4. draft-ietf-avtcore-monarch-03 . . . . . . . . . . . . . . 23
A.5. draft-ietf-avtcore-monarch-04 . . . . . . . . . . . . . . 22 A.5. draft-ietf-avtcore-monarch-04 . . . . . . . . . . . . . . 23
A.6. draft-ietf-avtcore-monarch-05 . . . . . . . . . . . . . . 22 A.6. draft-ietf-avtcore-monarch-05 . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
As more users and subscribers rely on real time application services, As more users and subscribers rely on real time application services,
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 RTCP XR [RFC3611] and other RTCP extension to standards, such as RTCP XR [RFC3611] and other RTCP extension to
Sender Reports (SR), Receiver Reports (RR) [RFC3550] are being Sender Reports (SR), Receiver Reports (RR) [RFC3550] are being
developed for the purpose of collecting and reporting performance developed for the purpose of collecting and reporting performance
skipping to change at page 5, line 5 skipping to change at page 4, line 33
rather than network parameters. One example of such metrics is rather than network parameters. One example of such metrics is
the QoE Metric specified in QoE metric reporting Block [MQ]. the QoE Metric specified in QoE metric reporting Block [MQ].
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
Metrics that can be directly measured or calculated and are not
dependent on other metric.
Composed metrics
Metrics that are calculated based on direct metric or combination
of direct metric and derived metrics.
Interval metrics
It is referred to as the metrics of which the reported values
apply to the most recent measurement interval duration between
successive metrics reports
Cumulative metrics
It is referred to as the metrics of which the reported values
apply to the accumulation period characteristic of cumulative
measurements
Sample metrics
It is referred to as the metrics of which the reported values only
apply to the value of a continuously measured or calculated that
has been sampled at end of the interval .
3. RTP monitoring architecture 3. RTP monitoring architecture
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 Monitor o Monitor
o Metric Block Structure o Metric Block Structure
Monitor is the functional component defined in the Real-time Monitor is the functional component defined in the Real-time
skipping to change at page 5, line 26 skipping to change at page 6, line 26
information gathered for monitoring purposes. It may gather such information gathered for monitoring purposes. It may gather such
information reported by RTCP XR or other RTCP extension and calculate information reported by RTCP XR or other RTCP extension and calculate
statistics from multiple source. According to the definition of statistics from multiple source. According to the definition of
monitor in the RTP Protocol [RFC3550], the end system that source RTP monitor in the RTP Protocol [RFC3550], the end system that source RTP
streams, an intermediate-system that forwards RTP packets to End- streams, an intermediate-system that forwards RTP packets to End-
devices or a third party that does not participate in the RTP session devices or a third party that does not participate in the RTP session
(i.e., the third party monitor depicted in figure 1) can be (i.e., the third party monitor depicted in figure 1) can be
envisioned to act as the Monitor within the RTP monitoring envisioned to act as the Monitor within the RTP monitoring
architecture. architecture.
The Metric Block exposes real time Application Quality information in The Metric Block exposes real time Application QoS/QoE metric
the appropriate report block format to the management system within information in the appropriate report block format to the management
the RTP monitoring architecture. Such information can be formulated system within the RTP monitoring architecture. Such information can
as: be formulated as:
o The basic metric that is directly measured. o The direct metrics
o or the composed metric that is derived from one or more basic o or the composed metrics.
metrics.
or formulated as
o The Interval metrics
o or cumulative metrics
o or sample metrics.
Both the RTCP or RTCP XR can be extended to convey these metrics. Both the RTCP or RTCP XR can be extended to convey these metrics.
The details on transport protocols for metric blocks are described in The details on transport protocols for metric blocks are described in
Section 3.1. Section 3.1.
+-------------------+ +-------------------+
| RTP Sender | +----------+ | RTP Sender | +----------+
| +-----------+ | |Management| | +-----------+ | |Management|
---------------->| Monitor |---------5------->| System | ---------------->| Monitor |---------5------->| System |
| | | | | | | | | | | | | |
skipping to change at page 9, line 20 skipping to change at page 10, line 20
o Using large block. A single report block or metric is designed to o Using large block. A single report block or metric is designed to
contain a large number of parameters in different classes for a contain a large number of parameters in different classes for a
specific application. For example, the RTCP Extended Reports specific application. For example, the RTCP Extended Reports
(XRs) [RFC3611] defines seven report block formats for network (XRs) [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 large block only for specific applications requirements. Design large block only for specific applications
may increase implementation cost and minimize interoperability. may increase implementation cost and minimize interoperability.
o Correlating RTCP XR with the non-RTP data. CNAME defined in the o Correlating RTCP XR with the non-RTP data. CNAME defined in the
RTP Protocol [RFC3550] is an example of existing tool that allows RTP Protocol [RFC3550] is an example of existing tool that allows
to bind an SSRC that may change to a fixed source name in one RTP to bind an SSRC that may change to a fixed source name in one RTP
session. It may be also fixed across multiple RTP sessions from session. It may be also fixed across multiple RTP sessions from
the same source. However there may be situations where RTCP the same source. However there may be situations where RTCP
reports are sent to other participating endpoints using non-RTP reports are sent to other participating endpoints using non-RTP
protocol in a session. For example, as described in the SIP RTCP protocol in a session. For example, as described in the SIP RTCP
Summary Report Protocol [RFC6035], the data contained in RTCP XR Summary Report Protocol [RFC6035], the data contained in RTCP XR
VoIP metrics reports [RFC3611] are forwarded to a central VoIP metrics reports [RFC3611] are forwarded to a central
collection server systems using SIP. In such case, there is a collection server systems using SIP. In such case, there is a
large portfolio of quality parameters that can be associated with large portfolio of quality parameters that can be associated with
real time application,e.g., VOIP application, but only a minimal real time application,e.g., VOIP application, but only a minimal
number of parameters are included on the RTCP-XR reports. number of parameters are included on the RTCP-XR reports.
Therefore correlation between RTCP XR and non-RTP data should be Therefore correlation between RTCP XR and non-RTP data should be
concerned if administration or management systems need to rely on concerned if administration or management systems need to rely on
the mapping RTCP statistics to non-RTCP measurements to conducts the mapping RTCP statistics to non-RTCP measurements to conducts
data analysis and creates alerts to the users. Without such data analysis and creates alerts to the users. Without such
correlation, it is hardly to provide accurate measures of real correlation, it is hard to provide accurate measures of real time
time application quality with a minimal number of parameters application quality with a minimal number of parameters included
included on the RTCP-XR reports in such case. 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 meaurement consecutive metric interval. In such case, the extra meaurement
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
and reliability should be taken into account. and reliability should be taken into account.
5. Guideline for reporting metric block using RTCP XR 5. Guideline for reporting metric block using RTCP XR
5.1. Using single metric blocks 5.1. Using single metrics blocks
Different applications using RTP for media transport certainly have Different applications using RTP for media transport certainly have
differing requirements for metrics transported in RTCP to support differing requirements for metrics transported in RTCP to support
their operation. For many applications, the basic metrics for their operation. For many applications, the basic metrics for
transport impairments provided in RTCP SR and RR packets [RFC3550] transport impairments provided in RTCP SR and RR packets [RFC3550]
(together with source identification provided in RTCP SDES packets) (together with source identification provided in RTCP SDES packets)
are sufficient. For other applications additional metrics may be are sufficient. For other applications additional metrics may be
required or at least sufficiently useful to justify the overheads, required or at least sufficiently useful to justify the overheads,
both of processing in endpoints and of increased session bandwidth. both of processing in endpoints and of increased session bandwidth.
For example an IPTV application using Forward Error Correction (FEC) For example an IPTV application using Forward Error Correction (FEC)
skipping to change at page 12, line 22 skipping to change at page 13, line 22
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.3. 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 streams from the same source, RTCP should use reporting on the same stream from the same source for the same time
the SSRC to identify and correlate and group participants between period, RTCP should use the SSRC to identify and correlate the
metric blocks. If extra measurement information (e.g., measurement multiple metric blocks between metric blocks. This memo proposes to
period) is expected and this information relates measurement data in define a new XR Block that will be used to convey the common time
the different metric blocks to the same stream, and measurement period and the number of packets sent during this period [MI]. In
period, this memo propose to define new XR Block to convey it. In
order to reduce measurement information repetition in one RTCP XR order to reduce measurement information repetition in one RTCP XR
packet containing multiple metric blocks, the measurement information compound packet containing multiple metric blocks, the measurement
should be sent together with the related metric block if measurement information shall be sent before the related metric blocks that are
information changes. from the same reporting interval. Note that for packet loss
robustness if the report blocks for the same interval span over more
than one RTCP packet then each must have the measurement identity
information even if though they will be the same.
6. An example of a metric block 6. An example of a metric block
This section uses the example of an existing proposed metrics block This section uses the example of an existing proposed metrics block
to illustrate the application of the principles set out in to illustrate the application of the principles set out in
Section 5.1. Section 5.1.
The example [PDV] is a block to convey information about packet delay The example [PDV] is a block to convey information about packet delay
variation (PDV) only, consistent with the principle that a metrics variation (PDV) only, consistent with the principle that a metrics
block should address only one parameter of interest. One simple block should address only one parameter of interest. One simple
skipping to change at page 15, line 28 skipping to change at page 17, line 5
In RTP sessions where one or more translators generate any RTCP In RTP sessions where one or more translators generate any RTCP
traffic towards their next-neighbour RTP system, other translators in traffic towards their next-neighbour RTP system, other translators in
the session have a choice as to whether they forward a translator's the session have a choice as to whether they forward a translator's
RTCP packets. Forwarding may provide additional information to other RTCP packets. Forwarding may provide additional information to other
RTP systems in the connection but increases RTCP bandwidth and may in RTP systems in the connection but increases RTCP bandwidth and may in
some cases present a security risk. RTP translators may have some cases present a security risk. RTP translators may have
forwarding behaviour based on local policy, which might differ forwarding behaviour based on local policy, which might differ
between different interfaces of the same translator. between different interfaces of the same translator.
For bidirectional unicast, an RTP system may check the presence of a
translator by receiving RTCP XR and noting that the sending SSRC in
the XR packet is not present in any RTP media packet. However the
RTP system can't determine that an SSRC in the XR packet is
associated with a translator rather than a receiving only end-point
unless the necessary session information on RTP node type is
expected. This Checking may fail if a source sends RTCP XR before it
has sent any RTP media (leading to transient mis-categorisation of an
RTP end system or RTP mixer as a translator). Another case is, for
multicast sessions - or unidirectional/streaming unicast, there is
also a possibility of a receive-only end system being permanently
mis-categorised as a translator sending XR report, i.e.,the monitor
sending XR report within the translator. Hence it is desirable for a
translator that sends XR report to have a way to announce its SSRC
and asscociated RTP node type explicitly to the management system.
8. IANA Considerations 8. IANA Considerations
There is no IANA action in this document. At the time of writing, the consumption of XR block code points isn't
a major issue. However when XR block codes points is really close to
run out of space, it might be desirable to define new fields encoded
as TLV elements in the XR report block or define one XR block type
for vendor-specific extensions, with an enterprise number included to
identify the vendor making the extension.
9. Security Considerations 9. Security Considerations
This document focuses on the RTCP reporting extension using RTCP XR This document focuses on the RTCP reporting extension using RTCP XR
and should not give rise to any new security vulnerabilities beyond and should not give rise to any new security vulnerabilities beyond
those described in RTCP XRs [RFC3611]. However it also describes the those described in RTCP XRs [RFC3611]. However it also describes the
architectural framework to be used for monitoring at RTP layer. The architectural framework to be used for monitoring at RTP layer. The
security issues with monitoring needs to be considered. security issues with monitoring needs to be considered.
In RTP sessions, a translator may use its own SSRC to send its In RTP sessions, a translator may use its own SSRC to send its
skipping to change at page 19, line 19 skipping to change at page 20, line 19
for RTP over UDP", ID draft-ietf-avtcore-ecn-for-rtp-04, for RTP over UDP", ID draft-ietf-avtcore-ecn-for-rtp-04,
July 2011. July 2011.
[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] ITU-T, "Measurement Identity and information Reporting
using SDES item and XR Block", October 2011.
[MQ] Wu, Q., Zorn, G., Schott, R., and K. Lee, "RTCP XR Blocks [MQ] Wu, Q., Zorn, G., Schott, R., and K. Lee, "RTCP XR Blocks
for multimedia quality metric reporting", for multimedia quality metric reporting",
ID draft-wu-xrblock-rtcp-xr-quality-monitoring-02, ID draft-wu-xrblock-rtcp-xr-quality-monitoring-02,
May 2011. May 2011.
[PDV] Hunt, G., "RTCP XR Report Block for Packet Delay Variation [PDV] Hunt, G., "RTCP XR Report Block for Packet Delay Variation
Metric Reporting", ID draft-ietf-xrblock-rtcp-xr-pdv-00, Metric Reporting", ID draft-ietf-xrblock-rtcp-xr-pdv-00,
September 2011. September 2011.
[RFC1122] Braden, R., "Requirements for Internet Hosts -- [RFC1122] Braden, R., "Requirements for Internet Hosts --
 End of changes. 18 change blocks. 
66 lines changed or deleted 95 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/