Movatterモバイル変換

Network Working Group                                            G. HuntRequest for Comments: 5093                                            BTCategory: Informational                                    December 2007BT'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 ofRFC 3611.  This specification does   not standardise the new report block for use outside BT's network.Table of Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .22.  Requirements Notation . . . . . . . . . . . . . . . . . . . . .23.  Extended Network Quality (XNQ) Report Block . . . . . . . . . .24.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .65.  Security Considerations . . . . . . . . . . . . . . . . . . . .66.  References  . . . . . . . . . . . . . . . . . . . . . . . . . .66.1.  Normative References  . . . . . . . . . . . . . . . . . . .66.2.  Informative References  . . . . . . . . . . . . . . . . . .6Hunt                         Informational                      [Page 1]

RFC 5093            RTCP XR eXtended Network Quality       December 20071.  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 1Hunt                         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 20074.  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 inSection 7, paragraph 3 of [1] does   not apply, and XNQ packets cannot be very large so the risk of denial   of service documented inSection 7, paragraph 7 of [1] does not   apply.6.  References6.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 2007Author'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.comHunt                         Informational                      [Page 7]

RFC 5093            RTCP XR eXtended Network Quality       December 2007Full Copyright Statement   Copyright (C) The IETF Trust (2007).   This document is subject to the rights, licenses and restrictions   contained inBCP 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 inBCP 78 andBCP 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 athttp://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]