draft-ietf-avtcore-monarch-06.txt   draft-ietf-avtcore-monarch-07.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: May 17, 2012 Unaffiliated Expires: June 1, 2012 Unaffiliated
P. Arden P. Arden
BT BT
November 14, 2011 November 29, 2011
Monitoring Architectures for RTP Monitoring Architectures for RTP
draft-ietf-avtcore-monarch-06.txt draft-ietf-avtcore-monarch-07.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 May 17, 2012. This Internet-Draft will expire on June 1, 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
3. RTP monitoring architecture . . . . . . . . . . . . . . . . . 6 3. RTP monitoring architecture . . . . . . . . . . . . . . . . . 6
3.1. RTCP Metric Block Report and associated parameters . . . . 8 3.1. RTCP Metric Block Report and associated parameters . . . . 8
4. Issues with reporting metric block using RTCP XR extension . . 10 4. Issues with reporting metric block using RTCP XR extension . . 10
5. Guideline for reporting metric block using RTCP XR . . . . . . 12 5. Guideline for reporting metric block using RTCP XR . . . . . . 12
5.1. Using single metrics blocks . . . . . . . . . . . . . . . 12 5.1. Using single metrics blocks . . . . . . . . . . . . . . . 12
5.2. Correlating RTCP XR with the non-RTP data . . . . . . . . 12 5.2. Correlating RTCP XR with the non-RTP data . . . . . . . . 12
5.3. Reducing Measurement information repetition . . . . . . . 13 5.3. Reducing Measurement information repetition . . . . . . . 13
5.4. Expanding the RTCP XR block namespace . . . . . . . . . . 13
6. An example of a metric block . . . . . . . . . . . . . . . . . 14 6. An example of a metric block . . . . . . . . . . . . . . . . . 14
7. Application to RFC 5117 topologies . . . . . . . . . . . . . . 15 7. Application to RFC 5117 topologies . . . . . . . . . . . . . . 15
7.1. Applicability to MCU . . . . . . . . . . . . . . . . . . . 15 7.1. Applicability to MCU . . . . . . . . . . . . . . . . . . . 15
7.2. Applicability to Translators . . . . . . . . . . . . . . . 16 7.2. Applicability to Translators . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19
11. Informative References . . . . . . . . . . . . . . . . . . . . 20 11. Informative References . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22
A.1. draft-ietf-avtcore-monarch-00 . . . . . . . . . . . . . . 22 A.1. draft-ietf-avtcore-monarch-00 . . . . . . . . . . . . . . 22
A.2. draft-ietf-avtcore-monarch-01 . . . . . . . . . . . . . . 22 A.2. draft-ietf-avtcore-monarch-01 . . . . . . . . . . . . . . 22
A.3. draft-ietf-avtcore-monarch-02 . . . . . . . . . . . . . . 22 A.3. draft-ietf-avtcore-monarch-02 . . . . . . . . . . . . . . 22
A.4. draft-ietf-avtcore-monarch-03 . . . . . . . . . . . . . . 23 A.4. draft-ietf-avtcore-monarch-03 . . . . . . . . . . . . . . 23
A.5. draft-ietf-avtcore-monarch-04 . . . . . . . . . . . . . . 23 A.5. draft-ietf-avtcore-monarch-04 . . . . . . . . . . . . . . 23
A.6. draft-ietf-avtcore-monarch-05 . . . . . . . . . . . . . . 23 A.6. draft-ietf-avtcore-monarch-05 . . . . . . . . . . . . . . 23
A.7. draft-ietf-avtcore-monarch-06 . . . . . . . . . . . . . . 24
A.8. draft-ietf-avtcore-monarch-07 . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 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
skipping to change at page 5, line 11 skipping to change at page 5, line 11
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
Sample 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 that
has been sampled at end of the interval . 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
skipping to change at page 6, line 41 skipping to change at page 6, line 41
o The direct metrics o The direct metrics
o or the composed metrics. o or the composed metrics.
or formulated as or formulated as
o The Interval metrics o The Interval metrics
o or cumulative metrics o or cumulative metrics
o or sample metrics. o or sampled 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 12, line 5 skipping to change at page 11, line 12
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.
o 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. We therefore may
need a way to extend the block type space, so that new
specifications may continue to be developed.
5. Guideline for reporting metric block using RTCP XR 5. Guideline for reporting metric block using RTCP XR
5.1. Using single metrics 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
skipping to change at page 13, line 26 skipping to change at page 13, line 26
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 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 [MI]. In period and the number of packets sent during this period [MI]. If
order to reduce measurement information repetition in one RTCP XR the measurement interval for a metric is different from the RTCP
compound packet containing multiple metric blocks, the measurement reporting interval, then this measurement duration in the [MI] SHOULD
information shall be sent before the related metric blocks that are be used to specify the interval. In order to reduce measurement
from the same reporting interval. Note that for packet loss information repetition in one RTCP XR compound packet containing
robustness if the report blocks for the same interval span over more multiple metric blocks, the measurement information shall be sent
than one RTCP packet then each must have the measurement identity before the related metric blocks that are from the same reporting
information even if though they will be the same. 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.
5.4. Expanding the RTCP XR block namespace
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
might be desirable to define new fields 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.
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 17, line 7 skipping to change at page 17, line 7
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.
8. IANA Considerations 8. IANA Considerations
At the time of writing, the consumption of XR block code points isn't There is no IANA action in this document.
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 RTP system may use its own SSRC to send its
monitoring reports towards its next-neighbour RTP system. Other monitoring reports towards its next-neighbour RTP system. Other RTP
translators in the session may have a choice as to whether they system in the session may have a choice as to whether they forward
forward the translator's RTCP packets. This present a security issue this RTP system's RTCP packets. This present a security issue since
since the information in the report may be exposed by the other the information in the report may be exposed by the other RTP system
translator to any malicious node. Therefore if the information is to any malicious node. Therefore if the information is considered as
considered as 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, Graeme Gibbs,
skipping to change at page 20, 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 --
skipping to change at page 25, line 5 skipping to change at page 24, line 7
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
The following are the major changes compared to 05:
o Some editorial changes.
A.8. draft-ietf-avtcore-monarch-07
The following are the major changes compared to 06:
o Clarify the XR block code points consumption issue in the section
4 and new section 5.4.
o Other editorial changes.
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. 15 change blocks. 
31 lines changed or deleted 59 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/