diff options
Diffstat (limited to 'doc/rfc/rfc5093.txt')
| -rw-r--r-- | doc/rfc/rfc5093.txt | 451 |
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc5093.txt b/doc/rfc/rfc5093.txt new file mode 100644 index 0000000..1b1e682 --- /dev/null +++ b/doc/rfc/rfc5093.txt @@ -0,0 +1,451 @@ + + + + + + +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] + |