One document matched: draft-ietf-xrblock-rtcp-xr-delay-10.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="std" docName="draft-ietf-xrblock-rtcp-xr-delay-10.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="RTCP XR Delay">RTP Control Protocol (RTCP) Extended Report
(XR) Block for Delay metric Reporting</title>
<author fullname="Alan Clark" initials="A." surname="Clark">
<organization abbrev="Telchemy">Telchemy Incorporated</organization>
<address>
<postal>
<street>2905 Premiere Parkway, Suite 280</street>
<city>Duluth</city>
<region>GA</region>
<code>30097</code>
<country>USA</country>
</postal>
<email>alan.d.clark@telchemy.com</email>
</address>
</author>
<author fullname="Kevin Gross" initials="K." surname="Gross">
<organization>AVA Networks</organization>
<address>
<email>kevin.gross@avanw.com</email>
</address>
</author>
<author fullname="Qin Wu" initials="Q." 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>
<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 document defines an RTP Control Protocol(RTCP) Extended Report
(XR) Block that allows the reporting of Delay metrics for use in a range
of Real-time Transport Protocol applications.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<section title="Packet Delay Metrics Block">
<t>This draft defines a new block type to augment those defined in
[RFC3611] for use in a range of RTP applications. The new block type
supports the reporting of the mean, minimum and maximum values of the
network round-trip delay between RTP interfaces in peer RTP end
systems as measured, for example, using the RTCP method described in
<xref target="RFC3550"></xref>. It also supports reporting of the
component of the round- trip delay internal to the local RTP
system.</t>
<t>The network metrics belong to the class of transport metrics
defined in <xref target="MONARCH"></xref>.</t>
</section>
<section title="RTCP and RTCP XR Reports">
<t>The use of RTCP for reporting is defined in <xref
target="RFC3550"></xref>. <xref target="RFC3611"></xref> defined an
extensible structure for reporting using an RTCP Extended Report (XR).
This draft defines a new Extended Report block for use with<xref
target="RFC3550"></xref> and <xref target="RFC3611"></xref>.</t>
</section>
<section title="Performance Metrics Framework">
<t>The Performance Metrics Framework <xref target="RFC6390"></xref>
provides guidance on the definition and specification of performance
metrics. The RTP Monitoring Architectures <xref
target="MONARCH"></xref> provides guideline for reporting block format
using RTCP XR. The Metrics Block described in this document are in
accordance with the guidelines in <xref target="RFC6390"></xref> and
<xref target="MONARCH"></xref>.</t>
</section>
<section title="Applicability">
<t>These metrics are applicable to a range of RTP applications in
which this report block would be useful, such as multimedia
conferencing and streaming audio and video. Knowledge of the
round-trip delay and delay characteristics can aid other receivers in
sizing their receive buffers and selecting a playout delay. The same
information is also valuable to network managers in troubleshooting
network and user experience issues.</t>
</section>
</section>
<section title="Terminology">
<section title="Standards Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Delay Block">
<t>Metrics in this block report on packet delay in the stream arriving
at the RTP system. The measurement of these metrics are made either at
the receiving end of the RTP stream or at the sending end of the RTP
stream. Instances of this Metrics Block refer by Synchronization source
(SSRC) to the separate auxiliary Measurement Information block <xref
target="MEASI"></xref> which contains measurement intervals. This metric
block relies on the measurement interval in the Measurement Information
block indicating the span of the report and SHOULD be sent in the same
compound RTCP packet as the measurement information block. If the
measurement interval is not received in the same compound RTCP packet as
this metric block, this metric block MUST be discarded.</t>
<section title="Report Block Structure">
<t>Delay metrics block<figure title="Figure 1: Report Block Structure">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=NDEL | I | resv. | block length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mean Network Round Trip Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Network Round Trip Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Network Round Trip Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End System Delay - Seconds (bit 0-31) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End System Delay - Fraction (bit 0-31) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
</section>
<section title="Definition of Fields in Delay Metrics Report Block">
<t><list style="hanging">
<t hangText="Block type (BT): 8 bits"><vspace blankLines="1" />A
Delay Report Block is identified by the constant NDEL.<vspace
blankLines="1" />[Note to RFC Editor: please replace NDEL with the
IANA provided RTCP XR block type for this block.]<vspace
blankLines="1" /></t>
<t hangText="Interval Metric flag (I): 2 bit"><vspace
blankLines="1" />This field is used to indicate whether the Delay
metrics are Sampled, Interval or Cumulative metrics, that is,
whether the reported values applies to the most recent measurement
interval duration between successive metrics reports (I=10) (the
Interval Duration) or to the accumulation period characteristic of
cumulative measurements (I=11) (the Cumulative Duration) or is a
sampled instantaneous value (I=01) (Sampled Value). <vspace
blankLines="1" /></t>
<t hangText="Reserved (resv): 6 bits"><vspace
blankLines="1" />These bits are reserved. They MUST be set to zero
by senders and SHOULD be ignored by receivers.<vspace
blankLines="1" /></t>
<t hangText="block length: 16 bits"><vspace blankLines="1" /> The
length of this report block in 32-bit words, minus one. For the
Delay block, the block length is equal to 6.<vspace
blankLines="1" /></t>
<t hangText="SSRC of source: 32 bits"><vspace blankLines="1" />As
defined in Section 4.1 of <xref target="RFC3611"></xref>.<vspace
blankLines="1" /></t>
<t hangText="Mean Network Round Trip Delay: 32 bits"><vspace
blankLines="1" />The Mean Network Round Trip Delay is the mean
value of the RTP-to- RTP interface round trip delay over the
measurement period, expressed in units of 1/65536 seconds. This
value is typically determined using RTCP SR/RR (See RFC 3550
section 6.4.1). It also can be determined using RTCP Receiver
Reference Time Report Block and DLRR Report Block (See RFC3611
section 4.5).<vspace blankLines="1" /> If only one measurement of
Round Trip Delay is available for the timespan of the report
(i.e.,the measurement period) (whether Interval or Cumulative),
this single value SHOULD be reported as the mean value.<vspace
blankLines="1" />If the measurement is unavailable, the value of
this field with all bits set to 1 MUST be reported.<vspace
blankLines="1" /></t>
<t hangText="Min Network Round Trip Delay: 32 bits"><vspace
blankLines="1" />The Min Network Round Trip Delay is the minimum
value of the RTP- to-RTP interface round trip delay over the
measurement period, expressed in units of 1/65536 seconds. This
value is typically determined using RTCP SR/RR. It also can be
determined using RTCP Receiver Reference Time Report Block and
DLRR Report Block.<vspace blankLines="1" /> If only one
measurement of Round Trip Delay is available for the timespan of
the report (i.e.,the measurement period) (whether Interval or
Cumulative), this single value SHOULD be reported as the minimum
value.<vspace blankLines="1" />If the measurement is unavailable,
the value of this field with all bits set to 1 MUST be
reported.</t>
<t hangText="Max Network Round Trip Delay: 32 bits"><vspace
blankLines="1" />The Max Network Round Trip Delay is the maximum
value of the RTP- to-RTP interface round trip delay over the
measurement period, expressed in units of 1/65536 seconds. This
value is typically determined using RTCP SR/RR. It also can be
determined using RTCP Receiver Reference Time Report Block and
DLRR Report Block.<vspace blankLines="1" /> If only one
measurement of Round Trip Delay is available for the timespan of
the report (i.e.,the measurement period) (whether Interval or
Cumulative), this single value SHOULD be reported as the maximum
value.<vspace blankLines="1" />If the measurement is unavailable,
the value of this field with all bits set to 1 MUST be
reported.<vspace blankLines="1" /></t>
<t hangText="End System Delay: 64 bits"><vspace
blankLines="1" />The End System Delay is the internal round trip
delay within the reporting endpoint, calculated using the nominal
value of the jitter buffer delay plus the accumulation/encoding
and decoding/playout delay associated with the codec being used.
The value of this field is represented using a 64-bit NTP-format
timestamp as defined in <xref target="RFC5905"></xref>, which is
64-bit unsigned fixed-point number with the integer part in the
first 32 bits and the fractional part in the last 32 bits. <vspace
blankLines="1" />If the measurement is unavailable, the value of
this field with all bits set to 1 MUST be reported.<vspace
blankLines="1" /></t>
</list></t>
</section>
</section>
<section title="SDP Signaling">
<t>[RFC3611] defines the use of SDP (Session Description Protocol) <xref
target="RFC4566"></xref> for signaling the use of XR blocks. XR blocks
MAY be used without prior signaling.</t>
<section title="SDP rtcp-xr-attrib Attribute Extension">
<t>This section augments the SDP <xref target="RFC4566"></xref>
attribute "rtcp-xr" defined in <xref target="RFC3611"></xref> by
providing an additional value of "xr-format" to signal the use of the
report block defined in this document.<figure>
<artwork>
xr-format =/ xr-delay-block
xr-delay-block ="delay"
</artwork>
</figure></t>
</section>
<section title="Offer/Answer Usage">
<t>When SDP is used in offer-answer context, the SDP Offer/Answer
usage defined in <xref target="RFC3611"></xref> applies.</t>
</section>
</section>
<section title="IANA Considerations">
<t>New block types for RTCP XR are subject to IANA registration. For
general guidelines on IANA considerations for RTCP XR, refer to <xref
target="RFC3611"></xref>.</t>
<section title="New RTCP XR Block Type value">
<t>This document assigns the block type value NDEL in the IANA "RTCP
XR Block Type Registry" to the "Delay Metrics Block".</t>
<t>[Note to RFC Editor: please replace NDEL with the IANA provided
RTCP XR block type for this block.]</t>
</section>
<section title="New RTCP XR SDP Parameter">
<t>This document also registers a new parameter "delay" in the "RTCP
XR SDP Parameters Registry".</t>
</section>
<section title="Contact information for registrations">
<t><figure>
<artwork>
The contact information for the registrations is:
Qin Wu (sunseawq@huawei.com)
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
</artwork>
</figure><vspace blankLines="1" /></t>
</section>
</section>
<section title="Security Considerations">
<t>It is believed that this proposed RTCP XR report block introduces no
new security considerations beyond those described in <xref
target="RFC3611"></xref>. This block does not provide per-packet
statistics, so the risk to confidentiality documented in Section 7,
paragraph 3 of <xref target="RFC3611"></xref> does not apply.</t>
</section>
<section title="Contributors">
<t>Geoff Hunt wrote the initial version of this document.</t>
</section>
<section title="Acknowledgments">
<t>The authors gratefully acknowledge the comments and contributions
made by Bruce Adams, Philip Arden, Amit Arora, Bob Biskner, Kevin
Connor, Claus Dahm, Randy Ethier, Roni Even, Jim Frauenthal, Albert
Higashi, Tom Hock, Shane Holthaus, Paul Jones, Rajesh Kumar, Keith
Lantz, Mohamed Mostafa, Amy Pendleton, Colin Perkins, Mike Ramalho, Ravi
Raviraj, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada,Jing
Zhao,Kevin Gross, Colin Perkins, Charles Eckel, Glen Zorn,Shida
Schubert.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3611">
<front>
<title>RTP Control Protocol Extended Reports (RTCP XR)</title>
<author fullname="T. Friedman" initials="T." surname="Friedman">
<organization></organization>
</author>
<author fullname="R. Caceres" initials="R." surname="Caceres">
<organization></organization>
</author>
<author fullname="A. Clark" initials="A." surname="Clark">
<organization></organization>
</author>
<date month="November" year="2003" />
<abstract>
<t>This document defines the Extended Report (XR) packet type for
the RTP Control Protocol (RTCP), and defines how the use of XR
packets can be signaled by an application if it employs the
Session Description Protocol (SDP). XR packets are composed of
report blocks, and seven block types are defined here. The purpose
of the extended reporting format is to convey information that
supplements the six statistics that are contained in the report
blocks used by RTCP's Sender Report (SR) and Receiver Report (RR)
packets. Some applications, such as multicast inference of network
characteristics (MINC) or voice over IP (VoIP) monitoring, require
other and more detailed statistics. In addition to the block types
defined here, additional block types may be defined in the future
by adhering to the framework that this document provides.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4566">
<front>
<title>SDP: Session Description Protocol</title>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization></organization>
</author>
<author fullname="V. Jacobson" initials="V." surname="Jacobson">
<organization></organization>
</author>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization></organization>
</author>
<date month="July" year="2006" />
<abstract>
<t>This memo defines the Session Description Protocol (SDP). SDP
is intended for describing multimedia sessions for the purposes of
session announcement, session invitation, and other forms of
multimedia session initiation. [STANDARDS-TRACK]</t>
</abstract>
</front>
</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="RFC5905">
<front>
<title>Network Time Protocol Version 4: Protocol and Algorithms
Specification</title>
<author fullname="D.Mills" initials="D." surname="Mills">
<organization></organization>
</author>
<author fullname="J.Martin" initials="J." surname="Martin">
<organization></organization>
</author>
<author fullname="J.Burbank" initials="J." surname="Burbank">
<organization></organization>
</author>
<author fullname="W. Kasch" initials="W." surname="Kasch">
<organization></organization>
</author>
<date month="June" year="2010" />
</front>
<seriesInfo name="RFC" value="5905" />
<format type="TXT" />
</reference>
</references>
<references title="Informative References">
<reference anchor="MONARCH">
<front>
<title>Monitoring Architectures for RTP</title>
<author fullname="Geoff Hunt" initials="G." surname="Hunt">
<organization></organization>
</author>
<date month="September" year="2012" />
</front>
<seriesInfo name="ID" value="draft-ietf-avtcore-monarch-22" />
<format type="TXT" />
</reference>
<reference anchor="MEASI">
<front>
<title>Measurement Identity and information Reporting using SDES
item and XR Block</title>
<author fullname="Geoff Hunt" initials="G." surname="Hunt">
<organization></organization>
</author>
<date month="August" year="2012" />
</front>
<seriesInfo name="ID"
value="draft-ietf-xrblock-rtcp-xr-meas-identity-10" />
<format type="TXT" />
</reference>
<reference anchor="RFC6390">
<front>
<title>Framework for Performance Metric Development</title>
<author fullname="Alan Clark" initials="A." surname="Clark">
<organization></organization>
</author>
<author fullname="Benoit Claise " initials="B." surname="Claise">
<organization></organization>
</author>
<date month="October" year="2011" />
</front>
<seriesInfo name="RFC" value="6390" />
</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-xrblock-rtcp-xr-delay-10">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Editorial changes based on SDP directorate Review.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-delay-09">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Editorial changes based on comments that are applied to PDV
draft.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-delay-08">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Move Geoff Hunt from author list to Contributors section based
on his suggestion.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-delay-07">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Editorial changes.</t>
<t>Reference updates.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-delay-06">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Editorial changes.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-delay-05">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>One typo fixed.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-delay-04">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Revise the definition of sampled metric to get alignment with
MONARCH.</t>
<t>Clarify sending the metric block in the same RTCP compound
packet as the measurement information block.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-delay-03">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Allocate 64 bit for end system delay and represent it using 64
bit NTP-Timestamp.</t>
<t>Other editorial changes.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-delay-02">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Allocate 32bits for each metrics and change unit for each
metric from ms to 1/65536 seconds.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-delay-01">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Updated references.</t>
<t>Allocate one more bit for Interval metric flag to indicate
sampled metric can be used.</t>
<t>add a few clarification text for failure mode.</t>
</list></t>
</section>
<section title="draft-ietf-xrblock-rtcp-xr-delay-00">
<t>The following are the major changes to previous version : <list
style="symbols">
<t>Changed BNF for SDP following Christian Groves' and Tom
Taylor's comments (4th and 5th May 2009).</t>
<t>Updated references.</t>
</list></t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:53:48 |