Network Working Group G. Hunt
Request for Comments: 5093 BT
Category: Informational December 2007
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)
英国电信的扩展网络质量RTP控制协议扩展报告（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
IESG注释
The IESG has concerns about vendor code points allocation in this small namespace and might not approve similar documents in the future.
IESG担心在这个小名称空间中分配供应商代码点，将来可能不会批准类似的文档。
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.
本文档描述了一个RTCP XR报告块，用于报告数据包传输参数。该报告块由英国电信开发，用于英国电信下一代网络的预标准使用。编制本文件的目的是充分详细地描述报告块，以便根据RFC 3611的规范要求政策向IANA注册块类型。本规范并未对新报告块进行标准化，以便在BT网络之外使用。
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
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
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].
英国电信定义了一组数据包传输质量指标，用于其网络中的预标准使用。这些指标被称为“扩展网络质量”的“XNQ”。本文档定义了一个RTCP-XR报告块，以使用[1]中定义的扩展机制，将XNQ测量值从RTP端系统传输到其对等系统。
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.
这些指标旨在补充RTCP[2]中的丢包指标和RTCP提供的往返延迟测量。它们提供基于[3]中定义的IPDV度量的IP数据包延迟变化度量、报告RTP终端系统接收机抖动缓冲区活动的度量以及报告“出错”和“严重出错”秒的度量。
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.
编制本文件是为了充分详细地描述报告块，以便根据[1]的规范要求政策向IANA注册块类型。本规范并未对新报告块进行标准化，以便在BT网络之外使用。
Work in progress on RTCP HR [5] is likely to obsolete these metrics and the RTCP-XR Report Block defined here.
正在进行的RTCP HR[5]工作可能会淘汰这些指标和此处定义的RTCP-XR报告块。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[4]中所述进行解释。
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".
英国电信定义了一组数据包传输质量指标，用于其网络中的预标准使用。这些指标被称为“扩展网络质量”的“XNQ”。
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.
本文档使用[1]中定义的扩展机制定义RTCP-XR报告块。新的报告块提供了从RTP端系统到对等系统的XNQ测量传输。
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.
下文将介绍这些指标。然而，对于度量数据包延迟变化的指标vmaxdiff、vrange、vsum和c，还需要一些额外的解释。这些指标基于[3]中定义的称为IP数据包延迟变化（IPDV）的度量。数据包的IPDV是数据包在网络中的延迟量减去参考数据包在网络中的延迟量。参考数据包通常是连接的第一个数据包。IPDV是一个有符号的数量。
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.
度量vrange是迄今为止在连接持续时间内看到的最长和最短网络数据包延迟之间的差值（最长减去最短）。度量vrange通常是一个正数，但如果数据包延迟在到目前为止的连接生命周期内保持不变，则可能为零。
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.
指标vmaxdiff如下所示。对于每个RTCP测量周期，找出该测量周期内最长和最短网络数据包延迟之间的差异（最长减去最短）。这些差异通常都是正值，但如果包延迟在整个测量周期内保持不变，则差异可能为零。取这些差异的集合并找到最大值，即vmaxdiff。指标vmaxdiff通常也是一个正数，但如果每个周期差异集合的所有成员都为零，则该指标将为零。
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.
度量vsum只是每个RTCP周期差异的总和，如上文所述，这些差异是为了找到vmaxdiff而获得的。度量c是每个RTCP周期的差异数，即差异集的基数。两个指标vsum和c允许计算vsum/c，即每个RTCP测量周期的平均IPDV。
The format of the report is as shown in Figure 1.
报告的格式如图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 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
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
图1
The report consists of an RTCP-XR block header and a single 8-word sub-block.
该报告由一个RTCP-XR块头和一个8字子块组成。
block type (BT): 8 bits
块类型（BT）：8位
An XNQ Metrics Report Block is identified by the constant 8.
XNQ度量报告块由常量8标识。
reserved: 8 bits
保留：8位
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
块长度：16位
Defined in Section 3 of [1].
定义见[1]第3节。
begin_seq: 16 bits
开始顺序：16位
As defined in Section 4.1 of [1].
如[1]第4.1节所定义。
end_seq: 16 bits
结束顺序：16位
As defined in Section 4.1 of [1].
如[1]第4.1节所定义。
vmaxdiff: 16 bits unsigned
vmaxdiff:16位无符号
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.
迄今为止在单个RTCP测量周期内看到的最大IPDV差异，以RTP时间戳单位测量。如果测量值超过0xFFFE，则应报告值0xFFFF以指示超量程测量。
vrange: 16 bits unsigned
vrange:16位无符号
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.
迄今为止RTP流生命周期内的最大IPDV差异，以RTP时间戳单位测量。如果测量值超过0xFFFE，则应报告值0xFFFF以指示超量程测量。
vsum: 32 bits unsigned
vsum:32位无符号
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.
每个RTCP周期内的峰值IPDV差值之和，在RTP流到目前为止的生存期内，在RTCP周期内求和。如果测量值超过0xFFFFFE，则应报告值0xFFFFFFFF以指示超量程测量。
c: 16 bits unsigned
c:16位无符号
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.
累积vsum的RTCP周期数。如果测量值超过0xFFFE，则应报告值0xFFFF以指示超量程测量。
jbevents: 16 bits unsigned
jbevents:16位无符号
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.
迄今为止，RTP流生命周期内抖动缓冲区自适应事件的累积数量。如果测量值超过0xFFFE，则应报告值0xFFFF以指示超量程测量。
tdegnet: 24 bits unsigned
tdegnet:24位无符号
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.
自传输开始以来，由于网络丢失导致的数据包不可用或数据包延迟交付而影响的采样周期内的总时间。如果测量值超过0xFFFFFE，则应报告值0xFFFFFF以指示超量程测量。
tdegjit: 24 bits unsigned
tdegjit:24位无符号
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.
由抖动缓冲器适配事件降级的采样周期内的总时间，例如，抖动缓冲器要么播放非源于发射机的采样序列，要么重复采样，或者选择不播放发射机发送的采样序列。如果测量值超过0xFFFFFE，则应报告值0xFFFFFF以指示超量程测量。
es: 24 bits unsigned
es:24位无符号
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.
迄今为止，在此短暂的生命周期内受“不可用数据包”事件影响的累计秒数。如果测量值超过0xFFFFFE，则应报告值0xFFFFFF以指示超量程测量。
ses: 24 bits unsigned
ses:24位无符号
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.
迄今为止，在此短暂的生命周期内，受严重“不可用数据包”事件影响的累计秒数。如果测量值超过0xFFFFFE，则应报告值0xFFFFFF以指示超量程测量。
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].
IANA已将注册表“RTP控制协议扩展报告（RTCP XR）块类型”中的数字8分配给此处描述的RTCP XR报告块。此注册表在[1]中定义。
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.
据信，除了[1]中所述的安全注意事项外，建议的RTCP XR报告块未引入任何新的安全注意事项。[1]中的某些注意事项不适用于此报告块。具体而言，XNQ不提供每个数据包的统计数据，因此[1]第7节第3段中记录的保密风险不适用，XNQ数据包不可能很大，因此[1]第7节第7段中记录的拒绝服务风险不适用。
[1] Friedman, T., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[1] Friedman，T.，“RTP控制协议扩展报告（RTCP XR）”，RFC 3611，2003年11月。
[2] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003.
[2] Schulzrinne，H.，“RTP：实时应用的传输协议”，RFC3550，2003年7月。
[3] ITU-T, "Recommendation Y.1540, Internet protocol data communication service -- IP packet transfer and availability performance parameters", December 2002.
[3] ITU-T，“建议Y.1540，互联网协议数据通信服务——IP数据包传输和可用性性能参数”，2002年12月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 2119，BCP 14，1997年3月。
[5] Clark, A., "RTCP HR - High Resolution VoIP Metrics Report Blocks", Work in Progress, November 2007.
[5] Clark，A.，“RTCP HR-高分辨率VoIP度量报告块”，正在进行的工作，2007年11月。
Author's Address
作者地址
Geoff Hunt BT Orion 1 PP9 Adastral Park Martlesham Heath Ipswich, Suffolk IP5 3RE United Kingdom
Geoff Hunt BT Orion 1 PP9英国萨福克郡Martlesham Heath Ipswich Adastral Park IP5 3RE
Phone: +44 1473 608325
EMail: geoff.hunt@bt.com
Phone: +44 1473 608325
EMail: geoff.hunt@bt.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.