BT's eXtended Network Quality RTP Control Protocol Extended Reports (RTCP XR XNQ)
RFC 5093
| Document | Type |
RFC - Informational
(December 2007; No errata)
Was draft-hunt-avt-rtcpxnq (individual in rai area)
|
|
|---|---|---|---|
| Author | Geoff Hunt | ||
| Last updated | 2015-10-14 | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text html pdf htmlized bibtex | ||
| Reviews | |||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 5093 (Informational) | |
| Action Holders |
(None)
|
||
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Cullen Jennings | ||
| Send notices to | avt-chairs@ietf.org | ||
Network Working Group G. Hunt
Request for Comments: 5093 BT
Category: Informational December 2007
BT's eXtended Network Quality RTP Control Protocol Extended Reports
(RTCP XR XNQ)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
IESG Note
The IESG has concerns about vendor code points allocation in this
small namespace and might not approve similar documents in the
future.
Abstract
This document describes an RTCP XR report block, which reports packet
transport parameters. The report block was developed by BT for pre-
standards use in BT's next-generation network. This document has
been produced to describe the report block in sufficient detail to
register the block type with IANA in accordance with the
Specification Required policy of RFC 3611. This specification does
not standardise the new report block for use outside BT's network.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 2
3. Extended Network Quality (XNQ) Report Block . . . . . . . . . . 2
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 6
Hunt Informational [Page 1]
RFC 5093 RTCP XR eXtended Network Quality December 2007
1. Introduction
A set of metrics of packet-transport quality has been defined by BT
for pre-standards use in its network. These metrics are known as
"XNQ" for "eXtended Network Quality". This document defines an
RTCP-XR Report Block to transport the XNQ measures from an RTP end
system to its peer, using the extension mechanism defined in [1].
The metrics are designed to supplement the packet-loss metric in RTCP
[2] and the roundtrip delay measurement provided by RTCP. They
provide metrics for IP Packet Delay Variation based on the IPDV
metric defined in [3], metrics reporting the activity of the RTP end
system's receiver's jitter buffer, and metrics reporting "errored"
and "severely errored" seconds.
This document has been produced to describe the report block in
sufficient detail to register the block type with IANA in accordance
with the Specification Required policy of [1]. This specification
does not standardise the new report block for use outside BT's
network.
Work in progress on RTCP HR [5] is likely to obsolete these metrics
and the RTCP-XR Report Block defined here.
2. Requirements Notation
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 [4].
3. Extended Network Quality (XNQ) Report Block
A set of metrics of packet-transport quality has been defined by BT
for pre-standards use in its network. These metrics are known as
"XNQ" for "eXtended Network Quality".
This document defines an RTCP-XR Report Block using the extension
mechanism defined in [1]. The new Report Block provides transport of
the XNQ measures from an RTP end system to its peer.
The metrics are described in the following text. However, some
additional explanation is required for the metrics vmaxdiff, vrange,
vsum, and c, which measure aspects of packet delay variation. The
metrics are based on the measure known as IP Packet Delay Variation
(IPDV) defined in [3]. The IPDV of a packet is the amount by which
the packet was delayed in the network, minus the amount a reference
packet was delayed in the network. The reference packet is usually
the first packet of the connection. IPDV is a signed quantity.
Hunt Informational [Page 2]
RFC 5093 RTCP XR eXtended Network Quality December 2007
The metric vrange is the difference (longest minus shortest) between
the longest and shortest network packet delays seen over the duration
of the connection to date. The metric vrange is usually a positive
quantity, but may be zero if the packet delay is exactly constant
over the lifetime of the connection to date.
The metric vmaxdiff is found as follows. For each RTCP measurement
cycle, find the difference (longest minus shortest) between the
longest and shortest network packet delays within that measurement
cycle. These differences are usually all positive quantities, but a
difference may be zero if the packet delay is exactly constant
throughout the measurement cycle. Take the set of these differences
and find the maximum, which is vmaxdiff. The metric vmaxdiff is also
usually a positive quantity, but will be zero if all the members of
the set of per-cycle differences are zero.
The metric vsum is simply the sum of the per-RTCP-cycle differences,
which were obtained to find vmaxdiff as described above. The metric
c is the number of per-RTCP-cycle differences, that is, the
cardinality of the set of differences. The two metrics vsum and c
allow calculation of vsum/c, the average IPDV per RTCP measurement
cycle.
The format of the report is as shown in Figure 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=8 | reserved | block length = 8 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| vmaxdiff | vrange |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| vsum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| c | jbevents |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | tdegnet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | tdegjit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | es |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | ses |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 1
Hunt Informational [Page 3]
RFC 5093 RTCP XR eXtended Network Quality December 2007
The report consists of an RTCP-XR block header and a single 8-word
sub-block.
block type (BT): 8 bits
An XNQ Metrics Report Block is identified by the constant 8.
reserved: 8 bits
These fields are reserved for future definition. In the absence
of such a definition, the bits in these fields MUST be set to zero
and MUST be ignored by the receiver.
block length: 16 bits
Defined in Section 3 of [1].
begin_seq: 16 bits
As defined in Section 4.1 of [1].
end_seq: 16 bits
As defined in Section 4.1 of [1].
vmaxdiff: 16 bits unsigned
Largest IPDV difference seen to date within a single RTCP
measurement cycle, measured in RTP timestamp units. If the
measured value exceeds 0xFFFE, the value 0xFFFF should be reported
to indicate an over-range measurement.
vrange: 16 bits unsigned
Largest IPDV difference over the lifetime of the RTP flow to date,
measured in RTP timestamp units. If the measured value exceeds
0xFFFE, the value 0xFFFF should be reported to indicate an over-
range measurement.
vsum: 32 bits unsigned
Sum of the peak IPDV difference values within each RTCP cycle,
summed over RTCP cycles over the lifetime of the RTP flow to date.
If the measured value exceeds 0xFFFFFFFE, the value 0xFFFFFFFF
should be reported to indicate an over-range measurement.
Hunt Informational [Page 4]
RFC 5093 RTCP XR eXtended Network Quality December 2007
c: 16 bits unsigned
Number of RTCP cycles over which vsum was accumulated. If the
measured value exceeds 0xFFFE, the value 0xFFFF should be reported
to indicate an over-range measurement.
jbevents: 16 bits unsigned
Cumulative number of jitter buffer adaptation events over the
lifetime of the RTP flow to date. If the measured value exceeds
0xFFFE, the value 0xFFFF should be reported to indicate an over-
range measurement.
tdegnet: 24 bits unsigned
The total time in sample periods affected either by packets
unavailable due to network loss, or late delivery of packets,
since the start of transmission. If the measured value exceeds
0xFFFFFE, the value 0xFFFFFF should be reported to indicate an
over-range measurement.
tdegjit: 24 bits unsigned
The total time in sample periods degraded by jitter buffer
adaptation events, e.g., where the jitter buffer either plays out
a sample sequence not originating at the transmitter, repeats
samples, or chooses not to play out a sample sequence that was
sent by the transmitter. If the measured value exceeds 0xFFFFFE,
the value 0xFFFFFF should be reported to indicate an over-range
measurement.
es: 24 bits unsigned
cumulative seconds affected by "unavailable packet" events over
the lifetime of this ephemeral, to date. If the measured value
exceeds 0xFFFFFE, the value 0xFFFFFF should be reported to
indicate an over-range measurement.
ses: 24 bits unsigned
cumulative seconds affected by severe "unavailable packet" events
over the lifetime of this ephemeral, to date. If the measured
value exceeds 0xFFFFFE, the value 0xFFFFFF should be reported to
indicate an over-range measurement.
Hunt Informational [Page 5]
RFC 5093 RTCP XR eXtended Network Quality December 2007
4. IANA Considerations
IANA has allocated the number 8 within the registry "RTP Control
Protocol Extended Reports (RTCP XR) Block Types" to the RTCP XR
report block described here. This registry is defined in [1].
5. Security Considerations
It is believed that this proposed RTCP XR report block introduces no
new security considerations beyond those described in [1]. Some of
the considerations in [1] do not apply to this report block.
Specifically, XNQ does not provide per-packet statistics so the risk
to confidentiality documented in Section 7, paragraph 3 of [1] does
not apply, and XNQ packets cannot be very large so the risk of denial
of service documented in Section 7, paragraph 7 of [1] does not
apply.
6. References
6.1. Normative References
[1] Friedman, T., "RTP Control Protocol Extended Reports (RTCP XR)",
RFC 3611, November 2003.
[2] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time
Applications", RFC 3550, July 2003.
[3] ITU-T, "Recommendation Y.1540, Internet protocol data
communication service -- IP packet transfer and availability
performance parameters", December 2002.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
6.2. Informative References
[5] Clark, A., "RTCP HR - High Resolution VoIP Metrics Report
Blocks", Work in Progress, November 2007.
Hunt Informational [Page 6]
RFC 5093 RTCP XR eXtended Network Quality December 2007
Author's Address
Geoff Hunt
BT
Orion 1 PP9
Adastral Park
Martlesham Heath
Ipswich, Suffolk IP5 3RE
United Kingdom
Phone: +44 1473 608325
EMail: geoff.hunt@bt.com
Hunt Informational [Page 7]
RFC 5093 RTCP XR eXtended Network Quality December 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Hunt Informational [Page 8]