doc: Add RFC documents

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