[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 RFC 5093

Audio/Video Transport Working                                    G. Hunt
Group                                                                 BT
Internet-Draft                                           August 23, 2007
Intended status: Standards Track
Expires: February 24, 2008


  BT's eXtended Network Quality RTP Control Protocol Extended Reports
                             (RTCP XR XNQ)
                     draft-hunt-avt-rtcpxnq-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 24, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).












Hunt                    Expires February 24, 2008               [Page 1]

Internet-Draft      RTCP XR eXtended Network Quality         August 2007


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 [1].  This Specification does not
   standardise the new report block for use outside BT's network.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   3.  Extended Network Quality (XNQ) Report Block  . . . . . . . . .  5
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13




























Hunt                    Expires February 24, 2008               [Page 2]

Internet-Draft      RTCP XR eXtended Network Quality         August 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 round-trip 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.




























Hunt                    Expires February 24, 2008               [Page 3]

Internet-Draft      RTCP XR eXtended Network Quality         August 2007


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].














































Hunt                    Expires February 24, 2008               [Page 4]

Internet-Draft      RTCP XR eXtended Network Quality         August 2007


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.

   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.








Hunt                    Expires February 24, 2008               [Page 5]

Internet-Draft      RTCP XR eXtended Network Quality         August 2007


     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

   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





Hunt                    Expires February 24, 2008               [Page 6]

Internet-Draft      RTCP XR eXtended Network Quality         August 2007


      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.

   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






Hunt                    Expires February 24, 2008               [Page 7]

Internet-Draft      RTCP XR eXtended Network Quality         August 2007


      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 which 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                    Expires February 24, 2008               [Page 8]

Internet-Draft      RTCP XR eXtended Network Quality         August 2007


4.  IANA Considerations

   This document requests IANA to allocate the specific number 8 within
   the registry "RTP Control Protocol Extended Reports (RTCP XR) Block
   Types", http://www.iana.org/assignments/rtcp-xr-block-types, to the
   RTCP XR report block described here.  This registry is defined in
   [1].












































Hunt                    Expires February 24, 2008               [Page 9]

Internet-Draft      RTCP XR eXtended Network Quality         August 2007


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.










































Hunt                    Expires February 24, 2008              [Page 10]

Internet-Draft      RTCP XR eXtended Network Quality         August 2007


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", ID draft-ietf-avt-rtcphr-01, February 2007.






























Hunt                    Expires February 24, 2008              [Page 11]

Internet-Draft      RTCP XR eXtended Network Quality         August 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                    Expires February 24, 2008              [Page 12]

Internet-Draft      RTCP XR eXtended Network Quality         August 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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Hunt                    Expires February 24, 2008              [Page 13]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/