    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]