draft-ietf-avtcore-monarch-03.txt   draft-ietf-avtcore-monarch-04.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: December 18, 2011 Unaffiliated Expires: March 3, 2012 Unaffiliated
P. Arden P. Arden
BT BT
June 16, 2011 August 31, 2011
Monitoring Architectures for RTP Monitoring Architectures for RTP
draft-ietf-avtcore-monarch-03.txt draft-ietf-avtcore-monarch-04.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, as proposed in RFC5968. This memo transmission or reception quality, as proposed in RFC5968. This memo
suggests that a new block should contain a single metric or a small suggests that a new block should contain a single metric or a small
number of metrics relevant to a single parameter of interest or number of metrics relevant to a single parameter of interest or
concern, rather than containing a number of metrics which attempt to concern, rather than containing a number of metrics which attempt to
provide full coverage of all those parameters of concern to a provide full coverage of all those parameters of concern to a
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 December 18, 2011. This Internet-Draft will expire on March 3, 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 24 skipping to change at page 2, line 24
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 . . . . . . . . . . . . . . . . . 5
3.1. RTCP Metric Block Report and associated parameters . . . . 7 3.1. RTCP Metric Block Report and associated parameters . . . . 7
4. Issues with reporting metric block using RTCP XR extension . . 9 4. Issues with reporting metric block using RTCP XR extension . . 9
5. Guideline for reporting block format using RTCP XR . . . . . . 11 5. Guideline for reporting block format using RTCP XR . . . . . . 11
5.1. Using small blocks . . . . . . . . . . . . . . . . . . . . 11 5.1. Using small blocks . . . . . . . . . . . . . . . . . . . . 11
5.2. Reducing the identity information repetition . . . . . . . 11 5.2. Correlating identity information with the non-RTP data . . 11
5.3. Correlating identity information with the non-RTP data . . 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 . . . . . . . . . . . . . . . 14
7.2. Applicability to Translators . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . 21
A.1. draft-ietf-avtcore-monarch-00 . . . . . . . . . . . . . . 21 A.1. draft-ietf-avtcore-monarch-00 . . . . . . . . . . . . . . 21
A.2. draft-ietf-avtcore-monarch-01 . . . . . . . . . . . . . . 21 A.2. draft-ietf-avtcore-monarch-01 . . . . . . . . . . . . . . 21
A.3. draft-ietf-avtcore-monarch-02 . . . . . . . . . . . . . . 21 A.3. draft-ietf-avtcore-monarch-02 . . . . . . . . . . . . . . 21
A.4. draft-ietf-avtcore-monarch-03 . . . . . . . . . . . . . . 22 A.4. draft-ietf-avtcore-monarch-03 . . . . . . . . . . . . . . 22
A.5. draft-ietf-avtcore-monarch-04 . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
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 4, line 23 skipping to change at page 4, line 23
A set of metrics which characterise the three transport A set of metrics which characterise the three transport
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 QoE related parameters. These metrics are Metrics relating to QoE related parameters. These metrics are
measured at the application level and focus on quality of content measured at the application level and focus on quality of content
rather than network parameters. rather than network parameters. One example of such metrics is
the Multimedia Quality Metric specified in [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.
3. RTP monitoring architecture 3. RTP monitoring architecture
skipping to change at page 5, line 22 skipping to change at page 5, line 22
o Metric Block Structure o Metric Block Structure
Monitor is a functional component defined in RFC3550 that acts as a Monitor is a functional component defined in RFC3550 that acts as a
source of information gathered for monitoring purposes. It may also source of information gathered for monitoring purposes. It may also
collect statistics from multiple source, stores such information collect statistics from multiple source, stores such information
reported by RTCP XR or other RTCP extension appropriately as base reported by RTCP XR or other RTCP extension appropriately as base
metric or calculates composite metric. According to the definition metric or calculates composite metric. According to the definition
of monitor in RFC3550, the end system that source RTP streams, an of monitor in RFC3550, the end system that source RTP streams, an
intermediate-system that forwards RTP packets to End-devices or a intermediate-system that forwards RTP packets to End-devices or a
third party that does not participate RTP session (i.e., the third third party that does not participate RTP session (i.e., the third
party monitor depicted in figure 1) can be envisioned to act as party monitor depicted in figure 1) can be envisioned to act as the
Monitor within the RTP monitoring architecture. Monitor within the RTP monitoring architecture.
The Metric Block exposes real time Application Quality information in The Metric Block exposes real time Application Quality information in
the appropriate report block format to monitor within the RTP the appropriate report block format to the Monitor within the RTP
monitoring architecture. Both the RTCP or RTCP XR can be extended to monitoring architecture. Both the RTCP or RTCP XR can be extended to
convey such information. The details on transport protocol for convey such information. The details on transport protocol for
metric block is described in Section 3.1. metric block is described in Section 3.1.
|---------------+ |---------------+
| Management | | Management |
+-------------------+ | System | +-------------------+ | System |
| RTP Sender | | +----------+ | | RTP Sender | | +----------+ |
| +-----------+ | | | | | | +-----------+ | | | | |
---------------->| Monitor |---------5------->| Monitor | | ---------------->| Monitor |---------5------->| Monitor | |
skipping to change at page 6, line 49 skipping to change at page 6, line 49
| +-----------------+ | | +-----------------+ || | +-----------------+ | | +-----------------+ ||
| |Transport | | | |Transport | || | |Transport | | | |Transport | ||
| |-IP/UDP/RTP | | | |-IP/UDP/RTP >---|| | |-IP/UDP/RTP | | | |-IP/UDP/RTP >---||
| |-IP/TCP/RTP | | | | -IP/TCP/RTP | | | |-IP/TCP/RTP | | | | -IP/TCP/RTP | |
| |-IP/TCP/RTSP/RTP | | | |-IP/TCP/RTSP/RTP | | | |-IP/TCP/RTSP/RTP | | | |-IP/TCP/RTSP/RTP | |
| +-----------------+ | | +-----------------+ | | +-----------------+ | | +-----------------+ |
+------------------------+ +------------------------+ +------------------------+ +------------------------+
Figure 1: RTP Monitoring Architecture Figure 1: RTP Monitoring Architecture
1. RTP communication between real time applications 1. RTP communication between real time applications.
2. Application level metrics
3. Transport level metrics 2. Application level metrics collection.
4. End System metrics 3. Transport level metrics collection.
5. Reporting Session- metrics transmitted over specified interfaces 4. End System metrics collection.
5. Reporting Session- metrics transmitted over specified interfaces.
3.1. RTCP Metric Block Report and associated parameters 3.1. RTCP Metric Block Report and associated parameters
The basic RTCP Reception Report (RR) conveys reception statistics in The basic RTCP Reception Report (RR) conveys reception statistics in
metric block report format for multiple RTP media streams including metric block report format for multiple RTP media streams including
o transport level statistics o transport level statistics
o the fraction of packet lost since the last report o the fraction of packet lost since the last report
skipping to change at page 7, line 50 skipping to change at page 7, line 51
o Statistics Summary Reports o Statistics Summary Reports
There are also various other scenarios in which it is desirable to There are also various other scenarios in which it is desirable to
send RTCP Metric reports more frequently. The Audio/Video Profile send RTCP Metric reports more frequently. The Audio/Video Profile
with Feedback [RFC4585]extends the standard A/V Profile[RFC3551] to with Feedback [RFC4585]extends the standard A/V Profile[RFC3551] to
allow RTCP reports to be sent early provided RTCP bandwidth allow RTCP reports to be sent early provided RTCP bandwidth
allocation is respected. There are four use cases but are not allocation is respected. There are four use cases but are not
limited to: limited to:
o RTCP NACK is used to provide feedback on the RTP sequence number o RTCP NACK is used to provide feedback on the RTP sequence number
of the lost packets. of the lost packets. [RFC4585]
o RTCP XR is extended to provide feedback on multicast acquisition o RTCP XR is extended to provide feedback on multicast acquisition
statistics information and parameters. statistics information and parameters.[RFC6332]
o RTCP is extended to convey requests for full intra-coded frames or o RTCP is extended to convey requests for full intra-coded frames or
select the reference picture, and signalchanges in the desired select the reference picture, and signalchanges in the desired
temporal/spatial trade-off and maximum media bit rate. temporal/spatial trade-off and maximum media bit rate. [RFC5104]
o RTCP or RTCP XR is extended to provide feedback on ECN statistics o RTCP or RTCP XR is extended to provide feedback on ECN statistics
information. information. [ECN]
4. Issues with reporting metric block using RTCP XR extension 4. Issues with reporting metric block using RTCP XR extension
Issues that have come up in the past with reporting metric block Issues that have come up in the past with reporting metric block
using RTCP XR extensions include (but are probably not limited to) using RTCP XR extensions include (but are probably not limited to)
the following: the following:
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, RFC 3611 [RFC3611] defines specific application. For example, RFC 3611 [RFC3611] defines
seven report block formats for network management and quality seven report block formats for network management and quality
monitoring. However some of these block types defined in monitoring. However some of these block types defined in
[RFC3611] are only specifically designed for conveying multicast [RFC3611] are only specifically designed for conveying multicast
inference of network characteristics(MINC) or voice over IP (VoIP) inference of network characteristics(MINC) or voice over IP (VoIP)
monitoring. However different applications layered on RTP may monitoring. However different applications layered on RTP may
have some monitoring requirements in common, design large block have some monitoring requirements in common, design large block
only for specific applications may increase implementation cost only for specific applications may increase implementation cost
and minimize interoperability. and minimize interoperability.
o Correlating RTCP XR with the non-RTP data. CNAME [RFC3550] is an
example of existing tool that allows to bind an SSRC that may
change to a fixed source name in one RTP session. It is also
fixed across multiple RTP sessions from the same source. However
there may be situations where RTCP reports are sent to other
participating endpoints using non-RTP protocol in a session. For
example, as described in [RFC6035], the data contained in RTCP XR
VoIP metrics reports [RFC3611] are forwarded to a central
collection server systems using SIP. In such case, there is a
large portfolio of quality parameters that can be associated with
real time application,e.g., VOIP application, but only a minimal
number of parameters are included on the RTCP-XR reports.
Therefore correlation between RTCP XR and non-RTP data should be
concerned if administration or management systems need to rely on
the mapping RTCP statistics to non-RTCP measurements to conducts
data analysis and creates alerts to the users. Without such
correlation, it is hardly to provide accurate measures of real
time application quality with a minimal number of parameters
included on the RTCP-XR reports in such case.
o Identity Information duplication. Identity information is used to o Identity Information duplication. Identity information is used to
identify an instance of a metric block. The SSRC of the measured identify an instance of a metric block. The SSRC of the measured
stream as part of the metric block is one example of Identity stream as part of the metric block is one example of Identity
information. However in some cases, Identity information may be information. However in some cases, Identity information may be
not part of metric and include information more than one in the not part of metric and include information more than the SSRC in
metric block,e.g., when we set a metric interval for the session the metric block, e.g., when we set a metric interval for the
and monitor RTP packets within one or several consecutive metric session and monitor RTP packets within one or several consecutive
interval, extra identity information is expected. In such case, metric interval, extra identity information (e.g., sequence number
if we put such extra identity information into each metric block of 1st packet) is expected, if we put such extra identity
or create standalone block containing extra identity information, information into each metric block, there may be situations where
there may be situations where an RTCP XR packet containing more an RTCP XR packet containing more than two metric blocks including
than two metric blocks and other standalone block containing extra the duplicated extra identity information, reports on the same
identity information, reports on the same streams from the same streams from the same source. each block have the same extra
source. each block have the same identity information for identity information for measurement, if each metric block carry
measurement, if each metric block carry such duplicated data for such duplicated data for the measurement, it leads to redundant
the measurement, it leads to redundant information in this design information in this design since equivalent information is
since equivalent information is provided multiple times, once in provided multiple times, once in *every* metric block. Though
*every* metric block and other block containing identity this ensures immunity to packet loss, the design may bring more
information. Though this ensures immunity to packet loss, the complexity and the overhead is not completely trivial in some
design bring more complexity and the overhead is not completely cases.
trivial.
o Correlating RTCP XR with the non-RTP data. There may be
situations where RTCP reports are sent to other participating
endpoints using non-RTP protocol in a session. For example, as
described in [RFC6035], the data contained in RTCP XR VoIP metrics
reports [RFC3611] are forwarded to a central collection server
systems using SIP. In such case, there is a large portfolio of
quality parameters that can be associated with real time
application,e.g., VOIP application, but only a minimal number of
parameters are included on the RTCP-XR reports. Therefore
correlation between RTCP XR and non-RTP data should be concerned
if administration or management systems need to rely on the
mapping RTCP statistics to non-RTCP measurements to conducts data
analysis and creates alerts to the users. Without such
correlation, it is hardly to provide accurate measures of real
time application quality with a minimal number of parameters
included on the RTCP-XR reports in such case.
5. Guideline for reporting block format using RTCP XR 5. Guideline for reporting block format using RTCP XR
5.1. Using small blocks 5.1. Using small 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)
skipping to change at page 11, line 40 skipping to change at page 11, line 40
To avoid this pitfall, this memo proposes the use of small RTCP XR To avoid this pitfall, this memo proposes the use of small RTCP XR
metrics blocks each containing a very small number of individual metrics blocks each containing a very small number of individual
metrics characterizing only one parameter of interest to an metrics characterizing only one parameter of interest to an
application running over RTP. For example, at the RTP transport application running over RTP. For example, at the RTP transport
layer, the parameter of interest might be packet delay variation, and layer, the parameter of interest might be packet delay variation, and
specifically the metric "IPDV" defined by [Y1540]. See Section 6 for specifically the metric "IPDV" defined by [Y1540]. See Section 6 for
architectural considerations for a metrics block, using as an example architectural considerations for a metrics block, using as an example
a metrics block to report packet delay variation. a metrics block to report packet delay variation.
5.2. Reducing the identity information repetition 5.2. Correlating identity information with the non-RTP data
Any measurement must be identified. For example, an instance of a
metric must be identified using information which is likely to
include most of the following:
o the node at which it was measured,
o the source of the measured stream (for example, its CNAME),
o the SSRC of the measured stream,
o the sequence number of the first packet of the RTP session,
o the extended sequence numbers of the first packet of the current
measurement interval, and the last packet included in the
measurement,
o the duration of the most recent measurement interval and
o the duration of the interval applicable to cumulative measurements
(which may be the duration of the RTP session to date).
Note that this set of information (identity information) may overlap
with, but is more extensive than, that in the union of similar
information in RTCP RR packets. However we can not assume that RR
information is always present when XR is sent, since they may have
different measurement intervals. Also the reason for the additional
information carried in the XR is the perceived difficulty of
"locating" the *start* of the RTP session (sequence number of 1st
packet, duration of interval applicable to cumulative measurements)
using only RR. Therefore this set of information can provide more
detailed identity information relevant to the measurement report.
However if such detailed identity information are all put into each
metric and the metric are delivered in small blocks there is a danger
of inefficiency arising from repeating this information in a number
of metrics blocks within the same RTCP packet, in cases where the
same identification information applies to multiple metrics blocks.
This memo proposes an approach to minimise the inefficiency of
providing this identification information, assuming that an
architecture based on small blocks means that a typical RTCP packet
will contain more than one metrics block needing the same
identification. The choice of identification information to be
provided is discussed in [IDENTITY]. The approach is to define a
stand-alone block containing only identification information within
the scope of the containing RTCP XR packet. The "containing RTCP XR
packet" is defined here as the RTCP XR header with PT=XR=207 defined
in Section 2 of [RFC3611] and the associated payload defined by the
length field of this RTCP XR header. The RTCP XR header itself
includes the SSRC of the node at which all of the contained metrics
were measured, hence this SSRC need not be repeated in the stand-
alone identity block. A single RTCP XR packet containing multiple
metric block may contain multiple identity blocks. Typically there
will be one identity block per monitored source SSRC, but the use of
more than one identification block for a single monitored source SSRC
within a single containing RTCP XR packet is not ruled out. In order
to further reduce identity information repeatition, This stand-alone
block is recommended to only be exchanged occasionally, for example
sent once at the start of a session.
5.3. Correlating identity information with the non-RTP data
When more than one media transport protocols are used by one When more than one media transport protocols are used by one
application to interconnected to the same session (in gateway),e.g., application to interconnected to the same session (in gateway),e.g.,
one RTCP XR Packet is sent to the participating endpoints using non- one RTCP XR Packet is sent to the participating endpoints using non-
RTP-based media transport in a VOIP session, one crucial factor lies RTP-based media transport (e.g., using SIP) in a VOIP session, one
in how to handle their different identities that are corresponding to crucial factor lies in how to handle their different identities that
different media transport. are corresponding to different media transport.
This memo proposes an approach to facilitate the correlation of the This memo proposes an approach to facilitate the correlation of the
RTCP XR identity information with other session-related non-RTP data, RTCP Session with other session-related non-RTP data, i.e., if there
i.e., using SSRC of source in the identity information as the is a need to correlate RTP sessions with non-RTP sessions, then the
correlation tag to associate identity information with the non-RTP- correlation information needed should be conveyed in RTCP SDES
based data. packets since such correlation information describes the source,
rather than providing a quality report. An example use case is for a
An example use case is for an participant endpoint may convey a call participant endpoint may convey a call identifier or a global call
identifier or a global call identifier associated with the XR block identifier associated with the SSRC of measured RTP stream . In such
identity information and use SSRC of source in the identity case, the participant endpoint uses SSRC of source to bind the call
information as the correlation tag to the call identifier. A flow identifier in each chunk of the SDES RTCP packet and send such
measurement tool that is not call-aware then forward the subsequent correlation using the chunk containing SDES item to the network
metric reports along with this correlation tag which is included in management system. A flow measurement tool that is not call-aware
the XR Block header to the network management. Network management then forward the RTCP XR reports along with SSRC of the measured RTP
can then use this tag to correlate this report with other diagnostic stream which is included in the XR Block header to the network
information such as call detail records. management system. Network management system can then correlate this
report using SSRC with other diagnostic information such as call
detail records.
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] (work in progress) is a block to convey information The example [PDV] (work in progress) is a block to convey information
about packet delay variation (PDV) only, consistent with the about packet delay variation (PDV) only, consistent with the
principle that a metrics block should address only one parameter of principle that a metrics block should address only one parameter of
skipping to change at page 15, line 30 skipping to change at page 14, line 30
terminates or forwards RTCP XR blocks is expected to handle RTCP, terminates or forwards RTCP XR blocks is expected to handle RTCP,
including RTCP XR, according to [RFC3550]. Provided this expectation including RTCP XR, according to [RFC3550]. Provided this expectation
is met, an RTP system using RTCP XR is architecturally no different is met, an RTP system using RTCP XR is architecturally no different
from an RTP system of the same class (end system, mixer, or from an RTP system of the same class (end system, mixer, or
translator) which does not use RTCP XR. The second category relates translator) which does not use RTCP XR. The second category relates
to deployed system models used in many H.323 [H323] video to deployed system models used in many H.323 [H323] video
conferences. The topologies in this category are Topo-Video-Switch- conferences. The topologies in this category are Topo-Video-Switch-
MCU and Topo-RTCP-terminating-MCU. Such topologies based on systems MCU and Topo-RTCP-terminating-MCU. Such topologies based on systems
do not behave according to [RFC3550]. do not behave according to [RFC3550].
Considering the translator and MCU are two typical topologies in the
two categories mentioned above, this document will take them as two
typical examples to explain how RTCP XR report works in different
RFC5117 topologies.
7.1. Applicability to MCU 7.1. Applicability to MCU
Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU, suffer from the Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU, suffer from the
difficulties described in [RFC5117]. These difficulties apply to difficulties described in [RFC5117]. These difficulties apply to
systems sending, and expecting to receive, RTCP XR blocks as much as systems sending, and expecting to receive, RTCP XR blocks as much as
to systems using other RTCP packet types. For example, a participant to systems using other RTCP packet types. For example, a participant
RTP end system may send media to a video switch MCU. If the media RTP end system may send media to a video switch MCU. If the media
stream is not selected for forwarding by the switch, neither RTCP RR stream is not selected for forwarding by the switch, neither RTCP RR
packets nor RTCP XR blocks referring to the end system's generated packets nor RTCP XR blocks referring to the end system's generated
stream will be received at the RTP end system. Strictly the RTP end stream will be received at the RTP end system. Strictly the RTP end
skipping to change at page 15, line 48 skipping to change at page 15, line 4
packets nor RTCP XR blocks referring to the end system's generated packets nor RTCP XR blocks referring to the end system's generated
stream will be received at the RTP end system. Strictly the RTP end stream will be received at the RTP end system. Strictly the RTP end
system can only conclude that its RTP has been lost in the network, system can only conclude that its RTP has been lost in the network,
though an RTP end system complying with the robustness principle of though an RTP end system complying with the robustness principle of
[RFC1122] should survive with essential functions unimpaired. [RFC1122] should survive with essential functions unimpaired.
7.2. Applicability to Translators 7.2. Applicability to Translators
Section 7.2 of [RFC3550] describes processing of RTCP by translators. Section 7.2 of [RFC3550] describes processing of RTCP by translators.
RTCP XR is within the scope of the recommendations of [RFC3550]. RTCP XR is within the scope of the recommendations of [RFC3550].
Some RTCP XR metrics blocks may usefully be measured at, and reported Some RTCP XR metrics blocks may usefully be measured at, and reported
by, translators. As described in [RFC3550] this creates a by, translators. As described in [RFC3550] this creates a
requirement for the translator to allocate an SSRC for the monitor requirement for the translator to allocate an SSRC for the monitor
within itself so that it may populate the SSRC in the RTCP XR packet collocated with itself so that the monitor may populate the SSRC in
header (although the translator is not a Synchronisation Source in the RTCP XR packet header as packet sender SSRC and send it
the sense of originating RTP media packets). It must also supply out(although the translator is not a Synchronisation Source in the
this SSRC and the corresponding CNAME in RTCP SDES packets. sense of originating RTP media packets). It must also supply this
SSRC and the corresponding CNAME in RTCP SDES packets.
In RTP sessions where one or more translators generate any RTCP 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 usually detect RTCP XR For bidirectional unicast, an RTP system may usually detect RTCP XR
from a translator by noting that the sending SSRC is not present in from a translator by noting that the sending SSRC is not present in
any RTP media packet. However even for bidirectional unicast there any RTP media packet. However there is a possibility of a source
is a possibility of a source sending RTCP XR before it has sent any sending RTCP XR before it has sent any RTP media (leading to
RTP media (leading to transient mis-categorisation of an RTP end transient mis-categorisation of an RTP end system or RTP mixer as a
system or RTP mixer as a translator), and for multicast sessions - or translator), and for multicast sessions - or unidirectional/streaming
unidirectional/streaming unicast - there is a possibility of a unicast - there is also a possibility of a receive-only end system
receive-only end system being permanently mis-categorised as a being permanently mis-categorised as a translator sending XR report,
translator sending XR report, i.e.,monitor collocated with i.e.,the monitor sending XR report within the translator. Hence it
transaltor. Hence it is desirable for a translator that sends XR to is desirable for a translator that sends XR report to have a way to
have a way to declare itself explicitly. declare itself explicitly.
8. IANA Considerations 8. IANA Considerations
None. None.
9. Security Considerations 9. Security Considerations
This document itself contains no normative text and hence should not This document itself contains no normative text and hence should not
give rise to any new security considerations, to be confirmed. give rise to any new security considerations, to be confirmed.
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,
Debbie Greenstreet, Keith Drage,Dan Romascanu, Ali C. Begen, Roni Debbie Greenstreet, Keith Drage, Dan Romascanu, Ali C. Begen, Roni
Even for their valuable comments and suggestions on the early version Even for their valuable comments and suggestions on the early version
of this document. of this document.
11. Informative References 11. Informative References
[ECN] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", ID draft-ietf-avtcore-ecn-for-rtp-04,
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.
[IDENTITY] [MQ] Wu, Q., Zorn, G., Schott, R., and K. Lee, "RTCP XR Blocks
Hunt, G., "RTCP XR Report Block for Measurement Identity", for multimedia quality metric reporting",
ID draft-ietf-avt-rtcp-xr-meas-identity-02, May 2009. ID draft-wu-xrblock-rtcp-xr-quality-monitoring-02,
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-avt-rtcp-xr-pdv-03, Metric Reporting", ID draft-ietf-avt-rtcp-xr-pdv-03,
May 2009. May 2009.
[RFC1122] Braden, R., "Requirements for Internet Hosts -- [RFC1122] Braden, R., "Requirements for Internet Hosts --
Communication Layers", RFC 1122, October 1989. Communication Layers", RFC 1122, October 1989.
[RFC3393] Demichelis, C., "IP Packet Delay Variation Metric for IP [RFC3393] Demichelis, C., "IP Packet Delay Variation Metric for IP
Performance Metrics (IPPM)", RFC 3393, November 2002. Performance Metrics (IPPM)", RFC 3393, November 2002.
skipping to change at page 20, line 42 skipping to change at page 19, line 48
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/AVPF)", RFC 3551, July 2003. (RTP/AVPF)", RFC 3551, July 2003.
[RFC3611] Friedman, T., "RTP Control Protocol Extended Reports (RTCP [RFC3611] Friedman, T., "RTP Control Protocol Extended Reports (RTCP
XR)", RFC 3611, November 2003. XR)", RFC 3611, November 2003.
[RFC4585] Ott, J. and S. Wenger, "Extended RTP Profile for Real-time [RFC4585] Ott, J. and S. Wenger, "Extended RTP Profile for Real-time
Transport Control Protocol (RTCP)-Based Feedback (RTP/ Transport Control Protocol (RTCP)-Based Feedback (RTP/
AVPF)", RFC 4585, July 2006. AVPF)", RFC 4585, July 2006.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Session Initiation Protocol Event Package for Voice
Quality Reporting", RFC 5104, February 2008.
[RFC5117] Westerlund, M., "RTP Topologies", RFC 5117, January 2008. [RFC5117] Westerlund, M., "RTP Topologies", RFC 5117, January 2008.
[RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP [RFC5968] Ott, J. and C. Perkins, "Guidelines for Extending the RTP
Control Protocol (RTCP)", RFC 5968, September 2010. Control Protocol (RTCP)", RFC 5968, September 2010.
[RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, [RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich,
"Session Initiation Protocol Event Package for Voice "Session Initiation Protocol Event Package for Voice
Quality Reporting", RFC 6035, November 2010. Quality Reporting", RFC 6035, November 2010.
[RFC6332] Begen, A. and E. Friedrich, "Multicast Acquisition Report
Block Type for RTP Control Protocol (RTCP) Extended
Reports (XRs)", RFC 6332, July 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-00
skipping to change at page 22, line 10 skipping to change at page 22, line 10
o Separeate identity information correlation from section 5.2 as new o Separeate identity information correlation from section 5.2 as new
section 5.3. section 5.3.
o Remove figure 2 and related text from section 5.2. o Remove figure 2 and related text from section 5.2.
o Editorial changes in the section 4 and the first paragraph of o Editorial changes in the section 4 and the first paragraph of
section 7. section 7.
A.4. draft-ietf-avtcore-monarch-03 A.4. draft-ietf-avtcore-monarch-03
The following are the major changes compared to 01: The following are the major changes compared to 02:
o Update bullet 2 in section 4 to explain the ill-effect of Identity o Update bullet 2 in section 4 to explain the ill-effect of Identity
Information duplication. Information duplication.
o Update bullet 3 in section 4 to explain why Correlating RTCP XR o Update bullet 3 in section 4 to explain why Correlating RTCP XR
with the non-RTP data is needed. with the non-RTP data is needed.
o Update section 5.2 to focus on how to reduce the identity o Update section 5.2 to focus on how to reduce the identity
information repetition information repetition
o Update section 5.3 to explain how to correlate identity o Update section 5.3 to explain how to correlate identity
information with the non-RTP data information with the non-RTP data
A.5. draft-ietf-avtcore-monarch-04
The following are the major changes compared to 03:
o Update section 5.2 to clarify using SDES packet to carry
correlation information.
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 Swap the last two paragraphs in the section 4 since identity
information duplication can not been 100% avoided.
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. 33 change blocks. 
156 lines changed or deleted 139 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/