One document matched: draft-ietf-avtcore-monarch-17.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="info" docName="draft-ietf-avtcore-monarch-17.txt"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="RTP Monitoring Framework">Guidelines for Use of the RTP
Monitoring Framework</title>
<author fullname="Qin Wu" initials="Q." role="editor" surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>sunseawq@huawei.com</email>
</address>
</author>
<author fullname="Geoff Hunt" initials="G." surname="Hunt">
<organization>Unaffiliated</organization>
<address>
<email>r.geoff.hunt@gmail.com</email>
</address>
</author>
<author fullname="Philip Arden" initials="P.J." surname="Arden">
<organization abbrev="BT">BT</organization>
<address>
<postal>
<street>Orion 3/7 PP4</street>
<street>Adastral Park</street>
<street>Martlesham Heath</street>
<city>Ipswich</city>
<region>Suffolk</region>
<code>IP5 3RE</code>
<country>United Kingdom</country>
</postal>
<phone>+44 1473 644192</phone>
<email>philip.arden@bt.com</email>
</address>
</author>
<date year="2012" />
<area>Real-time Applications and Infrastructure Area</area>
<workgroup>Audio/Video Transport Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Real Time Control Protocol</keyword>
<abstract>
<t>This memo proposes an extensible RTP monitoring framework for
extending RTP Control Protocol (RTCP) with a new RTCP Extended Reports
(XR) block type to report new metrics regarding media transmission or
reception quality. In this framework, a new XR block should contain a
single metric or a small number of metrics relevant to a single
parameter of interest or concern, rather than containing a number of
metrics which attempt to provide full coverage of all those parameters
of concern to a specific application. Applications may then "mix and
match" to create a set of blocks which covers their set of concerns.
Where possible, a specific block should be designed to be re-usable
across more than one application, for example, for all of voice,
streaming audio and video. </t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Multimedia services using the Real-Time Protocol (RTP) are seeing
increased use. Standard methods for gathering RTP performance metrics
from these applications are needed to manage uncertainties in the
behavior and availability of their services. Standards , such as RTP
Control Protocol Extended Reports (RTCP XR)<xref
target="RFC3611"></xref> and other RTCP extension to Sender Reports
(SR), Receiver Reports (RR) <xref target="RFC3550"></xref> are being
developed for the purpose of collecting and reporting performance
metrics from endpoint devices that can be used to correlate the metrics,
provide end to end service visibility and measure and monitor Quality of
Experience (QoE) <xref target="RFC6390"></xref>.</t>
<t>However the proliferation of RTP/RTCP specific metrics for transport
and application quality monitoring has been identified as a potential
problem for interoperability when using RTP/RTCP to communicate all the
parameters of concern to a specific application. Given that different
applications layered on RTP may have some monitoring requirements in
common, these metrics should be satisfied by a common design.</t>
<t>The objective of this document is to describe an extensible RTP
monitoring framework to provide a small number of re-usable Quality of
Service (QoS) / QoE metrics which facilitate reduced implementation
costs and help maximize inter-operability. The "Guidelines for Extending
the RTP Control Protocol (RTCP)" <xref target="RFC5968"></xref> has
stated that, where RTCP is to be extended with a new metric, the
preferred mechanism is by the addition of a new RTCP XR <xref
target="RFC3611"></xref> block. This memo assumes that any requirement
for a new metric to be transported in RTCP will use a new RTCP XR
block.</t>
</section>
<section title="Terminology">
<t>This memo is informative and as such contains no normative
requirements.</t>
<t>In addition, the following terms are defined:</t>
<t><list style="hanging">
<t hangText="Transport level metrics"><vspace blankLines="1" />A set
of metrics which characterise the three transport impairments of
packet loss, packet delay, and packet delay variation. These metrics
should be usable by any application which uses RTP transport.<vspace
blankLines="1" /></t>
<t hangText="Application level metrics"><vspace blankLines="1" />
Metrics relating to application specific parameters or QoE related
parameters. Application specific parameters are measured at the
application level and focus on quality of content rather than
network performance. QoE related parameters reflect the end-to-end
performance at the services level and are ususally measured at the
user endpoint. One example of such metrics is the QoE Metric
specified in QoE metric reporting Block <xref target="QOE"></xref>.
<vspace blankLines="1" /></t>
<t hangText="End System metrics"><vspace blankLines="1" />Metrics
relating to the way a terminal deals with transport impairments
affecting the incident RTP stream. These may include de-jitter
buffering, packet loss concealment, and the use of redundant streams
(if any) for correction of error or loss.<vspace
blankLines="1" /></t>
<t hangText="Direct metrics"><vspace blankLines="1" />Metrics that
can be directly measured or calculated and are not dependent on
other metrics.<vspace blankLines="1" /></t>
<t hangText="Composed metrics"><vspace blankLines="1" />Metrics that
are not measured directly but rather are derived by algorithmically
combining one or more measured metrics. An example is a metric
derived based on direct metrics that have been measured.<vspace
blankLines="1" /></t>
<t hangText="Interval metrics"><vspace blankLines="1" />Metrics
measured over the course of a single reporting interval between two
successive report blocks. This may be the most recent RTCP reporting
interval (<xref target="RFC3550"></xref>, section 6.2) or some other
interval signalled using an RTCP Measurement Information XR Block
<xref target="MEASI"></xref>. An example interval metric is the
count of the number of RTP packets lost over the course of the last
RTCP reporting interval. <vspace blankLines="1" /></t>
<t hangText="Cumulative metrics"><vspace blankLines="1" />Metrics
measured over several reporting intervals for accumulating
statistics. The time period over which measurements are accumulated
can be the complete RTP session, or some other interval signalled
using an RTCP Measurement Information XR Block <xref
target="MEASI"></xref>. An example cumulative metric is the total
number of RTP packets lost since the start of the RTP
session.<vspace blankLines="1" /></t>
<t hangText="Sampled metrics"><vspace blankLines="1" />Metrics
measured at a particular time instant and sampled from the values of
a continuously measured or calculated metric within a reporting
interval (generally the value of some measurement as taken at the
end of the reporting interval). An example is the inter-arrival
jitter reported in RTCP SR and RR packets, which is continually
updated as each RTP data packet arrives, but only reported based on
a snapshot of the value which is sampled at the instant the
reporting interval ends. <vspace blankLines="1" /></t>
</list></t>
</section>
<section title="RTP Monitoring Framework">
<t>There are many ways in which the performance of an RTP session can be
monitored. These include RTP-based mechanisms such as the RTP SNMP MIB
<xref target="RFC2959"></xref>, or the SIP event package for RTCP
summary reports <xref target="RFC6035"></xref>, or non-RTP mechanisms
such as generic MIBs, NetFlow, IPFix, and so on. Together, these provide
useful mechanisms for exporting data on the performance of an RTP
session to non-RTP network management systems. It is desirable to also
perform in-session monitoring of RTP performance. RTCP provides the
means to do this. In the following, we review the RTP Monitoring
Framework, and give guidance for using and extending RTCP for monitoring
RTP sessions. One major benefit of such framework is ease of integration
with other RTP/RTCP mechanisms.</t>
<section title="Overview of the RTP Monitoring Framework">
<t>The RTP monitoring Framework comprises the following two key
functional components shown below:<list style="symbols">
<t>RTP Monitor</t>
<t>RTP Metric Block</t>
</list></t>
<t>RTP Monitor is the functional component defined in the Real-time
Transport Protocol <xref target="RFC3550"></xref>. It acts as a
repository of information gathered for monitoring purposes.</t>
<t>According to the definition of monitor in the RTP Protocol <xref
target="RFC3550"></xref>, the end system that runs an application
program that sends or receives RTP data packets, an
intermediate-system that forwards RTP packets to End-devices or a
third party that observes the RTP and RTCP traffic but does not make
itself visible to the RTP Session participants can play the role of
the RTP monitor within the RTP monitoring Framework. As shown in <xref
target="fig1"></xref>, the third party RTP monitor can be a passive
monitor that sees the RTP/RTCP stream pass it, or a system that gets
sent RTCP reports but not RTP and uses that to collect information.
The third party RTP monitor should be placed on the RTP/RTCP path
between the sender, intermediate and the receiver.</t>
<t>The RTP Metric Block (MB) conveys real time Application QoS/QoE
metric information and is used by the RTP monitor to exchange with
other RTP monitors in the appropriate report block format. The
information contained in the RTP MBs is collected by RTP monitors and
can be formulated as various types of metrics, e.g., direct
metrics/composed metrics or interval metrics/ cumulative
metrics/sampled metrics, etc. Both the RTCP or RTCP XR can be extended
to transport these metrics, e.g., the basic RTCP Reception Report (RR)
<xref target="RFC3550"></xref> that conveys reception statistics
(i.e., transport level statistics) for multiple RTP media streams, the
RTCP XRs <xref target="RFC3611"></xref> that supplement the existing
RTCP packets and provide more detailed feedback on reception quality
and RTCP NACK <xref target="RFC4585"></xref> that provides feedback on
the RTP sequence numbers for a subset of the lost packets or all the
currently lost packets. Ultimately the metric information collected by
RTP monitors within the RTP monitoring framework may go to the network
management tools beyond the RTP monitoring framework, e.g., as shown
<xref target="fig1"></xref>, the RTP monitors may export the metric
information derived from the RTP monitoring framework to the
management system using non-RTP means.</t>
<t><figure align="center" anchor="fig1"
title="Example showing the components of the RTP monitoring framework">
<artwork>
+-----------+ +----------+
|Third Party| |Management|
|RTP Monitor| >>>>>>>>| System |<<<<<
+-----------+ ^ +----------+ ^
: ^ ^ ^
: | ^ ^
+---------------+ : | +-------------+ +-------------+
| +-----------+ | : | |+-----------+| |+-----------+|
| |RTP Monitor| |..:...|.......||RTP Monitor||........||RTP Monitor||
| +-----------+ | | |+-----------+| |+-----------+|
| |------+------>| |------->| |
| RTP Sender | |RTP Mixer or | |RTP Receiver |
| | |Translator | | |
+---------------+ +-------------+ +-------------+
----> RTP media traffic
..... RTCP control channel
>>>>> Non-RTP/RTCP management flows
</artwork>
</figure></t>
<t>RTP may be used with multicast groups, both Any Source Multicast
(ASM) and Source Specific Multicast (SSM). These groups can be
monitored using RTCP. In the ASM case, the RTP monitor is a member of
the multicast group and listens to RTCP reports from all members of
the ASM group. In the SSM case, there is a unicast feedback target
that receives RTCP feedback from receivers and distributes it to other
members of the SSM group (see figure 1 of <xref
target="RFC5760"></xref> ). The RTP monitor will need to be co-located
with the feedback target to receive all feedback from the receivers
(this may also be an intermediate system). In both ASM and SSM
scenarios, receivers can send RTCP reports to enhance the reception
quality reporting.</t>
</section>
<section title="Location of RTP Monitors">
<t>As shown in the <xref target="fig1"></xref>, there are several
possible locations from where RTP sessions can be monitored. These
include end-systems that terminate RTP sessions, intermediate-systems
that are an active part of an RTP session, and third-party devices
that passively monitor an RTP session. Not every RTP sessions will
include monitoring, and those sessions that are monitored will not all
include each type of monitor. The performance metrics collected by RTP
monitors can be divided into end system metrics, application level
metrics, and transport level metrics. Some of these metrics may be
specific to the measurement point of the RTP monitor, or depend on
where the RTP monitors are located in the network, while others are
more general and can be collected in any monitoring location.</t>
<t>End-system monitoring is monitoring that is deployed on devices
that terminate RTP flows. Flows can be terminated in user equipment,
such as phones, video conferencing systems, or IPTV set-top boxes.
Alternatively, they can be terminated in devices that gateway between
RTP and other transport protocols. Transport and end system metrics,
application level metrics that don’t reflect end to end user
experience may be collected at all types of end system, but some
application level metrics (i.e.,quality of experience (QoE) metrics)
may only be applicable for user-facing end systems.</t>
<t>RTP sessions can include intermediate-systems that are an active
part of the system. These intermediate-systems include RTP mixers and
translators, MCUs, retransmission servers, etc. If the
intermediate-system establishes separate RTP sessions to the other
participants, then it must act as an end system in each of those
separate RTP sessions for the purposes of monitoring. If a single RTP
session traverses the intermediate-system, then the
intermediate-system can be assigned an SSRC in that session which it
can use for it's reports. Transport level metrics may be collected at
such intermediate-system.</t>
<t>Third-party monitors may be deployed that passively monitor RTP
sessions for network management purposes. Third-party monitors often
do not send reports into the RTP session being monitored, but instead
collect transport and end system metrics, application level metrics
that are reported via some network management application. In some
cases, however, third-party monitors can send reports to some or all
participants in the session being monitored. For example, in a media
streaming scenario, third-party monitors may be deployed that
passively monitor the session and send reception quality reports to
the media source, but not to the receivers.</t>
</section>
</section>
<section title="Issues with reporting metric block using RTCP XR extension">
<t>The following sections discuss four issues that have come up in the
past with reporting metric block using RTCP XR extensions.</t>
<section title="Using compound metrics block">
<t>A compound metrics block is designed to contain a large number of
parameters from different classes for a specific application in a
single block. For example, the RTCP Extended Reports (XRs) <xref
target="RFC3611"></xref> defines seven report block formats for
network management and quality monitoring. Some of these block types
defined in the RTCP XRs <xref target="RFC3611"></xref> are only
specifically designed for conveying multicast inference of network
characteristics (MINC) or voice over IP (VoIP) monitoring. However
different applications layered on RTP may have different monitoring
requirements. Designing compound metrics block only for specific
applications may increase implementation cost and minimize
interoperability.</t>
</section>
<section title="Correlating RTCP XR with the non-RTP data">
<t>Canonical End-Point Identifier SDES Item (CNAME), defined in the
RTP Protocol <xref target="RFC3550"></xref>, is an example of an
existing tool that allows binding a Synchronization source (SSRC) that
may change to a name that is fixed within one RTP session. CNAME may
be 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 the SIP RTCP Summary Report Protocol <xref
target="RFC6035"></xref>, the data contained in RTCP XR VoIP metrics
reports <xref target="RFC3611"></xref> 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. With these minimal
number of RTCP statistics parameters mapped to non-RTCP measurements,
it is hard to provide accurate measures of real time application
quality, conduct detailed data analysis and creates alerts timly to
the users. Therefore correlation between RTCP XR and non-RTP data
should be provided.</t>
</section>
<section title="Measurement Information duplication">
<t>We may set a measurement interval for the session and monitor RTP
packets within one or several consecutive report intervals. In such
case, the extra measurement information (e.g., extended sequence
number of 1st packet, measurement period) may be expected. However if
we put such extra measurement information into each metric block,
there may be situations where an RTCP XR packet containing multiple
metric blocks, reports on the same streams from the same source. In
other words, duplicated data for the measurement is provided multiple
times, once in every metric block. Though this design ensures immunity
to packet loss, it may bring more packetization complexity and the
processing overhead is not completely trivial in some cases. Therefore
compromise between processing overhead and reliability should be taken
into account.</t>
</section>
<section title="Consumption of XR block code points">
<t>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. Anticipating the potential need to extend the block type
space, it is noted that Block Type 255 is reserved for future
extensions in <xref target="RFC3611"></xref>.</t>
</section>
</section>
<section title="Guidelines for reporting metric block using RTCP XR">
<section anchor="smallblock"
title="Contain the single metrics in the Metric Block">
<t>Different applications using RTP for media transport certainly have
differing requirements for metrics transported in RTCP to support
their operation. For many applications, the basic metrics for
transport impairments provided in RTCP SR and RR packets <xref
target="RFC3550"></xref> (together with source identification provided
in RTCP SDES packets) are sufficient. For other applications
additional metrics may be required or at least sufficiently useful to
justify the overhead, both of processing in endpoints and of increased
session bandwidth. For example an IPTV application using Forward Error
Correction (FEC) might use either a metric of post-repair loss or a
metric giving detailed information about pre-repair loss bursts to
optimise payload bandwidth and the strength of FEC required for
changing network conditions. However there are many metrics available.
It is likely that different applications or classes of applications
will wish to use different metrics. Any one application is likely to
require metrics for more than one parameter but if this is the case,
different applications will almost certainly require different
combinations of metrics. If larger blocks are defined containing
multiple metrics to address the needs of each application, it becomes
likely that many different such larger blocks are defined, which
becomes a danger to interoperability.</t>
<t>To avoid this pitfall, this memo recommends the definition of
metrics blocks containing a very small number of individual metrics
characterizing only one parameter of interest to an application
running over RTP. For example, at the RTP transport layer, the
parameter of interest might be packet delay variation, and
specifically the metric "IP Packet Delay Variation (IPDV)" defined by
<xref target="Y1540"></xref>. See <xref target="example"></xref> for
architectural considerations for a metrics block, using as an example
a metrics block to report packet delay variation. Further, it is
appropriate to not only define report blocks separately, but also to
do so in separate documents where possible. This makes it easier to
evolve the reports (i.e., to update each type of report block
separately), and also makes it easier to require compliance with a
particular report block.</t>
</section>
<section title="Include the payload type in the Metric Block">
<t>There are some classes of metrics that can only be interpreted with
knowledge of the media codec that is being used (audio mean opinion
scores (MOS) were the triggering example, but there may be others). In
such cases the correlation of RTCP XR with RTP data is needed. Report
blocks that require such correlation need to include the payload type
of the reported media. In addition, it is necessary to signal the
details and parameters of the payload format to which that payload
type is bound using some out-of-band means (e.g., as part of an SDP
offer/answer exchange).</t>
</section>
<section title="Use RTCP SDES to correlate XR reports with non-RTP data">
<t>There may be situations where more than one media transport
protocol is used by one application to interconnect to the same
session in the gateway. For example, one RTCP XR Packet is sent to the
participating endpoints using non-RTP-based media transport (e.g.,
using SIP) in a VOIP session. One crucial factor lies in how to handle
their different identities that are corresponding to different media
transport.</t>
<t>This memo recommends an approach to facilitate the correlation of
the RTCP Session with other session-related non-RTP data. That is to
say if there is a need to correlate RTP sessions with non-RTP
sessions, then the correlation information needed should be conveyed
in a new RTCP Source Description (SDES) item, since such correlation
information describes the source, rather than providing a quality
report. An example use case is for a participant endpoint may convey a
call identifier or a global call identifier associated with the SSRC
of measured RTP stream. In such case, the participant endpoint uses
the SSRC of source to bind the call identifier using SDES item in the
SDES RTCP packet and send such correlation to the network management
system. A flow measurement tool that is configured with 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 Block
header and 5-tuple to the network management system. Network
management system can then correlate this report using SSRC with other
diagnostic information such as call detail records.</t>
</section>
<section title="Reduce Measurement information repetition across metric blocks">
<t>When multiple metric blocks are carried in one RTCP XR packet,
reporting on the same stream from the same source for the same time
period, RTCP should use the SSRC to identify and correlate the
multiple metric blocks between metric blocks. Measurement Identity and
information Reporting using SDES item and XR Block" <xref
target="MEASI"></xref>enables an RTCP sender to convey the common time
period and the number of packets sent during this period. If the
measurement interval for a metric is different from the RTCP reporting
interval, then this measurement duration in the Measurement
information block should be used to specify the interval. When there
may be multiple measurements information blocks with the same SSRC in
one RTCP XR compound packet, the measurement information block should
be put in order and followed by all the metric blocks associated with
this measurement information block. New RTCP XR metric blocks that
rely on the Measurement information block <xref target="MEASI"></xref>
must specify the response in case the new RTCP XR metric block is
received without an associated measurement information block. In most
cases, it is expected that the correct response is to discard the
received metric. In order to reduce measurement information repetition
in one RTCP XR compound packet containing multiple metric blocks, the
measurement information shall be sent before the related metric blocks
that are 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 though they will be the same.</t>
</section>
</section>
<section anchor="example" title="An example of a metric block">
<t>This section uses the example of an existing proposed metrics block
to illustrate the application of the principles set out in <xref
target="smallblock"></xref>.</t>
<t>The example <xref target="PDV"></xref> is a block to convey
information about packet delay variation (PDV) only, consistent with the
principle that a metrics block should address only one parameter of
interest. One simple metric of PDV is available in the RTCP RR packet as
the "interarrival jitter" field. There are other PDV metrics with a
certain similarity in metric structure which may be more useful to
certain applications. Two such metrics are the IPDV metric (<xref
target="Y1540"></xref>, <xref target="RFC3393"></xref>) and the mean
absolute packet delay variation 2 (MAPDV2) metric <xref
target="G1020"></xref>. Use of these metrics is consistent with the
principle in Section 5 of RTCP guideline <xref target="RFC5968"></xref>
that metrics should usually be defined elsewhere, so that RTCP standards
define only the transport of the metric rather than its nature. The
purpose of this section is to illustrate the architectural consideration
using the example of <xref target="PDV"></xref> rather than to document
the design of the PDV metrics block or to provide a tutorial on PDV in
general.</t>
<t>Given the availability of at least three metrics for PDV, there are
design options for the allocation of metrics to RTCP XR blocks:</t>
<t><list style="symbols">
<t>provide an RTCP XR block per metric</t>
<t>provide a single RTCP XR block which contains all three
metrics</t>
<t>provide a single RTCP block to convey any one of the three
metrics, together with a identifier to inform the receiving RTP
system of the specific metric being conveyed</t>
</list></t>
<t>In choosing between these options, extensibility is important,
because additional metrics of PDV may well be standardized and require
inclusion in this framework. The first option is extensible but only by
use of additional RTCP XR blocks, which may consume the limited
namespace for RTCP XR blocks at an unacceptable rate. The second option
is not extensible, so could be rejected on that basis, but in any case a
single application is quite unlikely to require transport of more than
one metric for PDV. Hence the third option was chosen. This implies the
creation of a subsidiary namespace to enumerate the PDV metrics which
may be transported by this block, as discussed further in <xref
target="PDV"></xref>.</t>
</section>
<section anchor="topologies" title="Application to RFC 5117 topologies">
<t>The topologies specified in <xref target="RFC5117"></xref> fall into
two categories. The first category relates to the RTP system model
utilizing multicast and/or unicast. The topologies in this category are
specifically Topo-Point-to-Point, Topo- Multicast, Topo-Translator (both
variants, Topo-Trn-Translator and Topo-Media-Translator, and
combinations of the two), and Topo-Mixer. These topologies use RTP end
systems, RTP mixers and RTP translators defined in the RTP protocol
<xref target="RFC3550"></xref>. For purposes of reporting connection
quality to other RTP systems, RTP mixers and RTP end systems are very
similar. Mixers resynchronize packets and do not relay RTCP reports
received from one cloud towards other cloud(s). Translators do not
resynchronize packets and should forward certain RTCP reports between
clouds. In this category, the RTP system (end system, mixer or
translator) which originates, terminates or forwards RTCP XR blocks is
expected to handle RTCP, including RTCP XR, according to the RTP
protocol <xref target="RFC3550"></xref>. Provided this expectation is
met, an RTP system using RTCP XR is architecturally no different from an
RTP system of the same class (end system, mixer, or translator) which
does not use RTCP XR. The second category relates to deployed system
models used in many H.323 <xref target="H323"></xref> video conferences.
The topologies in this category are Topo-Video-Switch-MCU and
Topo-RTCP-terminating-MCU. Such topologies based on systems (e.g.,MCUs)
do not behave according to the RTP protocol <xref
target="RFC3550"></xref>.</t>
<t>Considering the translator and MCU are two typical
intermediate-systems in these two categories mentioned above, this
document will take them as two typical examples to explain how RTCP XR
report works in different RFC5117 topologies.</t>
<section anchor="txlat" title="Applicability to Translators">
<t>Section 7.2 of the RTP protocol <xref target="RFC3550"></xref>
describes processing of RTCP by translators. RTCP XR is within the
scope of the recommendations of the RTP protocol <xref
target="RFC3550"></xref>. Some RTCP XR metrics blocks may usefully be
measured at, and reported by, translators. As described in the RTP
protocol <xref target="RFC3550"></xref> this creates a requirement for
the translator to allocate an SSRC for the monitor collocated with
itself so that the monitor may populate the SSRC in the RTCP XR packet
header as packet sender SSRC and send it out(although the translator
is not a Synchronisation Source in the sense of originating RTP media
packets). It must also supply this SSRC and the corresponding CNAME in
RTCP SDES packets.</t>
<t>In RTP sessions where one or more translators generate any RTCP
traffic towards their next-neighbour RTP system, other translators in
the session have a choice as to whether they forward a translator's
RTCP packets. Forwarding may provide additional information to other
RTP systems in the connection but increases RTCP bandwidth and may in
some cases present a security risk. RTP translators may have
forwarding behaviour based on local policy, which might differ between
different interfaces of the same translator.</t>
</section>
<section title="Applicability to MCU">
<t>Topo-Video-Switch-MCU and Topo-RTCP-terminating-MCU, suffer from
the difficulties described in <xref target="RFC5117"></xref>. These
difficulties apply to systems sending, and expecting to receive, RTCP
XR blocks as much as to systems using other RTCP packet types. For
example, a participant RTP end system may send media to a video switch
MCU. If the media stream is not selected for forwarding by the switch,
neither RTCP RR packets nor RTCP XR blocks referring to the end
system's generated stream will be received at the RTP end system.
Strictly the RTP end system can only conclude that its RTP has been
lost in the network, though an RTP end system complying with the
robustness principle of <xref target="RFC1122"></xref> should survive
with essential functions (i.e.,media distribution) unimpaired.</t>
</section>
</section>
<section title="IANA Considerations">
<t>There is no IANA action in this document.</t>
</section>
<section title="Security Considerations">
<t>This document focuses on the RTCP reporting extension using RTCP XR
and should not give rise to any new security vulnerabilities beyond
those described in RTCP XRs <xref target="RFC3611"></xref>. However it
also describes the architectural framework to be used for monitoring at
RTP layer. The security issues with monitoring needs to be
considered.</t>
<t>In RTP sessions, a RTP system may use its own SSRC to send its
monitoring reports towards its next-neighbour RTP system. Other RTP
system in the session may have a choice as to whether they forward this
RTP system's RTCP packets. This present a security issue since the
information in the report may be exposed by the other RTP system to any
malicious node. Therefore if the information is considered as sensitive,
the monitoring report should be encrypted.</t>
</section>
<section title="Acknowledgement">
<t>The authors would also like to thank Colin Perkins, Charles Eckel,
Robert Sparks, Salvatore Loreto, Graeme Gibbs, Debbie Greenstreet, Keith
Drage, Dan Romascanu, Ali C. Begen, Roni Even, Magnus Westerlund for
their valuable comments and suggestions on the early version of this
document.</t>
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor="RFC1122">
<front>
<title>Requirements for Internet Hosts -- Communication
Layers</title>
<author initials="R." surname="Braden">
<organization>USC/ISI</organization>
</author>
<date month="October" year="1989" />
</front>
<seriesInfo name="RFC" value="1122" />
<format type="TXT" />
</reference>
<reference anchor="RFC3393">
<front>
<title>IP Packet Delay Variation Metric for IP Performance Metrics
(IPPM)</title>
<author fullname="Carlo Demichelis" initials="C."
surname="Demichelis">
<organization>Telecomitalia Lab</organization>
</author>
<date month="November" year="2002" />
</front>
<seriesInfo name="RFC" value="3393" />
<format type="TXT" />
</reference>
<reference anchor="RFC6390">
<front>
<title>Guidelines for Considering New Performance Metric
Development</title>
<author fullname="A.Clark" initials="A." surname="Clark">
<organization></organization>
</author>
<author fullname="B. Claise" initials="B." surname="Claise">
<organization></organization>
</author>
<date month="October" year="2011" />
</front>
<seriesInfo name="RFC" value="6390" />
<format type="TXT" />
</reference>
<reference anchor="RFC3550">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname="Henning Schulzrinne" initials="H."
surname="Schulzrinne">
<organization>Columbia University</organization>
</author>
<date month="July" year="2003" />
</front>
<seriesInfo name="RFC" value="3550" />
<format type="TXT" />
</reference>
<reference anchor="RFC3611">
<front>
<title>RTP Control Protocol Extended Reports (RTCP XR)</title>
<author fullname="Timur Friedman" initials="T. (Ed)"
surname="Friedman">
<organization>Paris 6</organization>
</author>
<date month="November" year="2003" />
</front>
<seriesInfo name="RFC" value="3611" />
<format type="TXT" />
</reference>
<reference anchor="RFC5117">
<front>
<title>RTP Topologies</title>
<author fullname="Magnus Westerlund" initials="M."
surname="Westerlund">
<organization>Ericsson Research</organization>
</author>
<date month="January" year="2008" />
</front>
<seriesInfo name="RFC" value="5117" />
<format type="TXT" />
</reference>
<reference anchor="RFC5968">
<front>
<title>Guidelines for Extending the RTP Control Protocol
(RTCP)</title>
<author fullname="Joerg Ott" initials="J." surname="Ott">
<organization>Helsinki University of Technology</organization>
</author>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization>University of Glasgow</organization>
</author>
<date month="September" year="2010" />
</front>
<seriesInfo name="RFC" value="5968" />
<format type="TXT" />
</reference>
<reference anchor="RFC4585">
<front>
<title>Extended RTP Profile for Real-time Transport Control Protocol
(RTCP)-Based Feedback (RTP/AVPF)</title>
<author fullname="Joerg Ott" initials="J." surname="Ott">
<organization>Helsinki University of Technology</organization>
</author>
<author fullname="S. Wenger" initials="S." surname="Wenger">
<organization>Nokia</organization>
</author>
<date month="July" year="2006" />
</front>
<seriesInfo name="RFC" value="4585" />
<format type="TXT" />
</reference>
<reference anchor="RFC6035">
<front>
<title>Session Initiation Protocol Event Package for Voice Quality
Reporting</title>
<author fullname="A. Pendleton" initials="A." surname="Pendleton">
<organization>Telchemy Incorporated</organization>
</author>
<author fullname="A. Clark" initials="A." surname="Clark">
<organization>Telchemy Incorporated</organization>
</author>
<author fullname="A. Johnston" initials="A." surname="Johnston">
<organization>Avaya</organization>
</author>
<author fullname="H. Sinnreich" initials="H." surname="Sinnreich">
<organization>Unaffiliated</organization>
</author>
<date month="November" year="2010" />
</front>
<seriesInfo name="RFC" value="6035" />
<format type="TXT" />
</reference>
<reference anchor="RFC2959">
<front>
<title>Real-Time Transport Protocol Management Information
Base</title>
<author fullname="M. Baugher" initials="M." surname="Baugher">
<organization></organization>
</author>
<author fullname="B. Strahm" initials="B." surname="Strahm">
<organization></organization>
</author>
<author fullname="I. Suconick" initials="I." surname="Suconick">
<organization></organization>
</author>
<date month="October" year="2000" />
</front>
<seriesInfo name="RFC" value="2959" />
<format type="TXT" />
</reference>
<reference anchor="RFC5760">
<front>
<title>RTP Control Protocol (RTCP) Extensions for Single-Source
Multicast Sessions with Unicast Feedback</title>
<author fullname="Joerg Ott" initials="J." surname="Ott">
<organization>Helsinki University of Technology</organization>
</author>
<author fullname="Julian Chesterfield" initials="J."
surname="Chesterfield">
<organization>University of Cambridge</organization>
</author>
<author fullname="Eve Schooler" initials="E." surname="Schooler">
<organization>Intel Research / CTL</organization>
</author>
<date month="February" year="2010" />
</front>
<seriesInfo name="RFC" value="5760" />
<format type="TXT" />
</reference>
<reference anchor="PDV">
<front>
<title>RTCP XR Report Block for Packet Delay Variation Metric
Reporting</title>
<author fullname="Geoff Hunt" initials="G." surname="Hunt">
<organization>BT</organization>
</author>
<author fullname="Alan Clark " initials="A." surname="Clark">
<organization></organization>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization></organization>
</author>
<date month="May" year="2012" />
</front>
<seriesInfo name="ID" value="draft-ietf-xrblock-rtcp-xr-pdv-03" />
<format type="TXT" />
</reference>
<reference anchor="MEASI">
<front>
<title>Measurement Identity and information Reporting using SDES
item and XR Block</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization></organization>
</author>
<date month="June" year="2012" />
</front>
<seriesInfo name="ID"
value="draft-ietf-xrblock-rtcp-xr-meas-identity-07" />
<format type="TXT" />
</reference>
<reference anchor="QOE">
<front>
<title>RTCP XR Blocks for QoE Metric Reporting</title>
<author fullname="G.Hunt" initials="G." surname="Hunt">
<organization></organization>
</author>
<author fullname="A.Clark" initials="A." surname="Clark">
<organization></organization>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization></organization>
</author>
<author fullname="Roland Schott" initials="R." surname="Schott">
<organization></organization>
</author>
<author fullname="Glen Zorn" initials="G." surname="Zorn">
<organization></organization>
</author>
<date month="May" year="2012" />
</front>
<seriesInfo name="ID" value="draft-ietf-xrblock-rtcp-xr-qoe-01" />
<format type="TXT" />
</reference>
<reference anchor="P.NAMS">
<front>
<title>Non-intrusive parametric model for the Assessment of
performance of Multimedia Streaming</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="November" year="2009" />
</front>
<seriesInfo name="ITU-T Recommendation" value="P.NAMS" />
</reference>
<reference anchor="G1020">
<front>
<title>ITU-T Rec. G.1020, Performance parameter definitions for
quality of speech and other voiceband applications utilizing IP
networks</title>
<author>
<organization>ITU-T</organization>
</author>
<date month="July" year="2006" />
</front>
<format type="TXT" />
</reference>
<reference anchor="Y1540">
<front>
<title>ITU-T Rec. Y.1540, IP packet transfer and availability
performance parameters</title>
<author fullname="" initials="" surname="">
<organization>ITU-T</organization>
</author>
<date month="November" year="2007" />
</front>
<format type="TXT" />
</reference>
<reference anchor="H323">
<front>
<title>ITU-T Rec. H.323, Packet-based multimedia communications
systems</title>
<author fullname="" initials="" surname="">
<organization>ITU-T</organization>
</author>
<date month="June" year="2006" />
</front>
<format type="TXT" />
</reference>
</references>
<section title="Change Log">
<t>Note to the RFC-Editor: please remove this section prior to
publication as an RFC.</t>
<section title="draft-ietf-avtcore-monarch-17">
<t>The following are the major changes compared to 16: <list
style="symbols">
<t>Some Editorial changes.</t>
</list></t>
</section>
<section title="draft-ietf-avtcore-monarch-16">
<t>The following are the major changes compared to 15: <list
style="symbols">
<t>A few modification to the figure 1.</t>
<t>Change RTCP XR reports into RTCP reports in the section
3.1.</t>
<t>References Update.</t>
</list></t>
</section>
<section title="draft-ietf-avtcore-monarch-15">
<t>The following are the major changes compared to 14: <list
style="symbols">
<t>Add figure 1 in section 3 to describe RTP monitoring
framework.</t>
<t>Change the title as Guidelines for Use of the RTP Monitoring
Framework.</t>
<t>Other editorial change to get in line with the title change in
the section 3.</t>
</list></t>
</section>
<section title="draft-ietf-avtcore-monarch-14">
<t>The following are the major changes compared to 13: <list
style="symbols">
<t>Incorporate the key points in the section 3.2 into overview
section.</t>
<t>Remove the figure 1 and use the description instead.</t>
<t>Add description in the section 3.3 to discuss the possible
location of the monitors and the types of metric at that
location.</t>
<t>Add the description to make the definition of Interval
metrics/cumulative metrics/sampled metrics clear.</t>
<t>Editorial Changes.</t>
</list></t>
</section>
<section title="draft-ietf-avtcore-monarch-13">
<t>The following are the major changes compared to 12: <list
style="symbols">
<t>Editorial Changes.</t>
</list></t>
</section>
<section title="draft-ietf-avtcore-monarch-12">
<t>The following are the major changes compared to 11: <list
style="symbols">
<t>Editorial Changes based on Charles' Comments.</t>
<t>Reference update.</t>
<t>Add one new section 5.2 to discuss Correlating RTCP XR with RTP
data.</t>
<t>Add text in section 5.1 to highlight it is more appropriate to
define each block in a separate draft.</t>
</list></t>
</section>
<section title="draft-ietf-avtcore-monarch-11">
<t>The following are the major changes compared to 10: <list
style="symbols">
<t>Editorial Changes.</t>
</list></t>
</section>
<section title="draft-ietf-avtcore-monarch-10">
<t>The following are the major changes compared to 09: <list
style="symbols">
<t>Discuss what exist already for monitoring in section 3.1.</t>
<t>Provide benefit using RTCP XR based monitoring in section
3.1.</t>
<t>add one new paragraph in section 3.1 to describe how monitoring
architecture is applied to ASM/SSM.</t>
<t>Other Editorial Changes.</t>
</list></t>
</section>
<section title="draft-ietf-avtcore-monarch-09">
<t>The following are the major changes compared to 07: <list
style="symbols">
<t>Rephrase application level metric definition.</t>
<t>Add one new section to clarify where to measure QoE related
parameters.</t>
<t>Add text in section 5.3 to clarify the failure case when
measurement interval is not sent.</t>
<t>Add text in section 5.3 to clarify how to deal with multiple
measurements information blocks carried in the same packet.</t>
</list></t>
</section>
<section title="draft-ietf-avtcore-monarch-08">
<t>The following are the major changes compared to 07: <list
style="symbols">
<t>Editorial change to the reference.</t>
</list></t>
</section>
<section title="draft-ietf-avtcore-monarch-07">
<t>The following are the major changes compared to 06: <list
style="symbols">
<t>Clarify the XR block code points consumption issue in the
section 4 and new section 5.4.</t>
<t>Other editorial changes.</t>
</list></t>
</section>
<section title="draft-ietf-avtcore-monarch-06">
<t>The following are the major changes compared to 05: <list
style="symbols">
<t>Some editorial changes.</t>
</list></t>
</section>
<section title="draft-ietf-avtcore-monarch-05">
<t>The following are the major changes compared to 04: <list
style="symbols">
<t>Replace "chunk" with "new SDES item".</t>
<t>Add texts in security section to discussion potential security
issues.</t>
<t>Add new sub-section 5.3 to discuss Reducing Measurement
information repetition.</t>
<t>Other editorial changes.</t>
</list></t>
</section>
<section title="draft-ietf-avtcore-monarch-04">
<t>The following are the major changes compared to 03: <list
style="symbols">
<t>Update section 5.2 to clarify using SDES packet to carry
correlation information.</t>
<t>Remove section 5.3 since additional identity information goes
to SDES packet and using SSRC to identify each block is standard
RTP feature.</t>
<t>Swap the last two paragraphs in the section 4 since identity
information duplication can not been 100% avoided.</t>
<t>Other editorial changes.</t>
</list></t>
</section>
<section title="draft-ietf-avtcore-monarch-03">
<t>The following are the major changes compared to 02: <list
style="symbols">
<t>Update bullet 2 in section 4 to explain the ill-effect of
Identity Information duplication.</t>
<t>Update bullet 3 in section 4 to explain why Correlating RTCP XR
with the non-RTP data is needed.</t>
<t>Update section 5.2 to focus on how to reduce the identity
information repetition</t>
<t>Update section 5.3 to explain how to correlate identity
information with the non-RTP data</t>
</list></t>
</section>
<section title="draft-ietf-avtcore-monarch-02">
<t>The following are the major changes compared to 01: <list
style="symbols">
<t>Deleting first paragraph of Section 1.</t>
<t>Deleting Section 3.1, since the interaction with the management
application is out of scope of this draft.</t>
<t>Separate identity information correlation from section 5.2 as
new section 5.3.</t>
<t>Remove figure 2 and related text from section 5.2.</t>
<t>Editorial changes in the section 4 and the first paragraph of
section 7.</t>
</list></t>
</section>
<section title="draft-ietf-avtcore-monarch-01">
<t>The following are the major changes compared to 00: <list
style="symbols">
<t>Restructure the document by merging section 4 into section
3.</t>
<t>Remove section 4.1,section 5 that is out of scope of this
document.</t>
<t>Remove the last bullet in section 6 and section 7.3 based on
conclusion of last meeting.</t>
<t>Update figure 1 and related text in section 3 according to the
monitor definition in RFC3550.</t>
<t>Revise section 9 to address monitor declaration issue.</t>
<t>Merge the first two bullet in section 6.</t>
<t>Add one new bullet to discuss metric block association in
section 6.</t>
</list></t>
</section>
<section title="draft-ietf-avtcore-monarch-00">
<t>The following are the major changes compared to
draft-hunt-avtcore-monarch-02: <list style="symbols">
<t>Move Geoff Hunt and Philip Arden to acknowledgement
section.</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:56:29 |