doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc7002.txt b/doc/rfc/rfc7002.txt
new file mode 100644
index 0000000..26860e1
--- /dev/null
+++ b/doc/rfc/rfc7002.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          A. Clark
+Request for Comments: 7002                                      Telchemy
+Category: Standards Track                                        G. Zorn
+ISSN: 2070-1721                                              Network Zen
+                                                                   Q. Wu
+                                                                  Huawei
+                                                          September 2013
+
+
+         RTP Control Protocol (RTCP) Extended Report (XR) Block
+                   for Discard Count Metric Reporting
+
+Abstract
+
+   This document defines an RTP Control Protocol (RTCP) Extended Report
+   (XR) block that allows the reporting of a simple discard count metric
+   for use in a range of RTP applications.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7002.
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+Clark, et al.                Standards Track                    [Page 1]
+
+RFC 7002                     RTCP XR Discard              September 2013
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.1.  Discard Count Report Block  . . . . . . . . . . . . . . .   2
+     1.2.  RTCP and RTCP Extended Reports  . . . . . . . . . . . . .   3
+     1.3.  Performance Metrics Framework . . . . . . . . . . . . . .   3
+     1.4.  Applicability . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Discard Count Metrics Block . . . . . . . . . . . . . . . . .   4
+     3.1.  Report Block Structure  . . . . . . . . . . . . . . . . .   5
+     3.2.  Definition of Fields in the Discard Count Metrics Block .   5
+   4.  SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . .   7
+     4.1.  SDP rtcp-xr Attribute Extension . . . . . . . . . . . . .   7
+     4.2.  Offer/Answer Usage  . . . . . . . . . . . . . . . . . . .   7
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
+     5.1.  New RTCP XR Block Type Value  . . . . . . . . . . . . . .   8
+     5.2.  New RTCP XR SDP Parameter . . . . . . . . . . . . . . . .   8
+     5.3.  Contact Information for Registrations . . . . . . . . . .   8
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
+   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   8
+   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
+     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
+   Appendix A.  Metrics Represented Using the Template from RFC 6390  11
+
+1.  Introduction
+
+1.1.  Discard Count Report Block
+
+   This document defines a new block type to augment those defined in
+   [RFC3611] for use in a range of RTP applications.  The new block type
+   supports the reporting of the number of packets that are received
+   correctly but are never played out, typically because they arrive too
+   late (buffer underflow) or too early (buffer overflow) to be played
+   out.  The metric is applicable both to systems that use packet loss
+   repair techniques (such as forward error correction [RFC5109] or
+   retransmission [RFC4588]) and to those that do not.
+
+   This metric is useful for identifying the existence, and
+   characterizing the severity, of packet transport problems that may
+   affect users' perceptions of a service delivered over RTP.
+
+   This block may be used in conjunction with [RFC7003], which provides
+   additional information on the pattern of discarded packets.  However,
+   the metric in [RFC7003] may be used independently of the metrics in
+   this block.
+
+
+
+
+Clark, et al.                Standards Track                    [Page 2]
+
+RFC 7002                     RTCP XR Discard              September 2013
+
+
+   When a Discard Count Metrics Block is sent together with a Burst/Gap
+   Discard Metrics Block (defined in [RFC7003]) to the media sender or
+   RTP-based network management system, the information carried in the
+   Discard Count Metrics Block and the Burst/Gap Discard Metrics Block
+   allows systems receiving the blocks to calculate burst/gap summary
+   statistics (e.g., the gap discard rate).
+
+   The metric belongs to the class of transport-related end-system
+   metrics defined in [RFC6792].
+
+1.2.  RTCP and RTCP Extended Reports
+
+   The use of RTCP for reporting is defined in [RFC3550].  [RFC3611]
+   defined an extensible structure for reporting using an RTCP Extended
+   Report (XR).  This document defines a new Extended Report block for
+   use with [RFC3550] and [RFC3611].
+
+1.3.  Performance Metrics Framework
+
+   "Guidelines for Considering New Performance Metric Development"
+   [RFC6390] provides guidance on the definition and specification of
+   performance metrics.  "Guidelines for Use of the RTP Monitoring
+   Framework" [RFC6792] provides guidance for reporting block format
+   using RTCP XR.  The metrics block described in this document is in
+   accordance with the guidelines in [RFC6390] and [RFC6792].
+
+1.4.  Applicability
+
+   This metric is believed to be applicable to a large class of RTP
+   applications that use a de-jitter buffer [RFC5481].
+
+   Discards due to late or early arriving packets affect user
+   experience.  The reporting of discards alerts senders and other
+   receivers to the need to adjust their transmission or reception
+   strategies.  The reports allow network managers to diagnose these
+   user experience problems.
+
+   The ability to detect duplicate packets can be used by managers to
+   detect network layer or sender behavior, which may indicate network
+   or device issues.  Based on the reports, these issues may be
+   addressed prior to any impact on user experience.
+
+2.  Terminology
+
+   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 RFC 2119 [RFC2119].
+
+
+
+
+Clark, et al.                Standards Track                    [Page 3]
+
+RFC 7002                     RTCP XR Discard              September 2013
+
+
+   In addition, the following terms are defined:
+
+   Received, Lost, and Discarded
+
+      A packet shall be regarded as lost if it fails to arrive within an
+      implementation-specific time window.  A packet that arrives within
+      this time window but is either too early or too late to be played
+      out or is thrown away before playout due to packet duplication or
+      redundancy shall be regarded as discarded.  A packet shall not be
+      regarded as discarded if it arrives within this time window but is
+      dropped during decoding by some higher layer decoder, e.g., due to
+      a decoding error.  A packet shall be classified as one of the
+      following: received (or OK), discarded, or lost.  The discard
+      count metric counts only discarded packets.  The metric
+      "cumulative number of packets lost" defined in [RFC3550] reports a
+      count of packets lost from the media stream (single
+      synchronization source (SSRC) within a single RTP session).
+      Similarly, the metric "number of packets discarded" reports a
+      count of packets discarded from the media stream (single SSRC
+      within a single RTP session) arriving at the receiver.  Another
+      metric defined in [RFC5725] is available to report on packets that
+      are not recovered by any repair techniques that may be in use.
+
+3.  Discard Count Metrics Block
+
+   Metrics in this block report on the number of packets discarded in
+   the stream arriving at the RTP end system.  The measurement of these
+   metrics is made at the receiving end of the RTP stream.  Instances of
+   this metrics block use the SSRC to refer to the separate auxiliary
+   Measurement Information Block [RFC6776], which describes measurement
+   periods in use (see [RFC6776], Section 4.2).  This metrics block
+   relies on the measurement interval in the Measurement Information
+   Block indicating the span of the report and MUST be sent in the same
+   compound RTCP packet as the Measurement Information Block.  If the
+   measurement interval is not received in the same compound RTCP packet
+   as this metrics block, this metrics block MUST be discarded.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                    [Page 4]
+
+RFC 7002                     RTCP XR Discard              September 2013
+
+
+3.1.  Report Block Structure
+
+   The structure of the Discard Count Metrics Block is as follows.
+
+    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=24     | I |DT |  resv |      Block Length = 2         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        SSRC of Source                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        Discard Count                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 1: Report Block Structure
+
+3.2.  Definition of Fields in the Discard Count Metrics Block
+
+   Block Type (BT): 8 bits
+
+      A Discard Count Metrics Block is identified by the constant 24.
+
+   Interval Metric flag (I): 2 bits
+
+      This field indicates whether the reported metric is an Interval,
+      Cumulative, or Sampled metric [RFC6792]:
+
+         I=10: Interval Duration - the reported value applies to the
+         most recent measurement interval duration between successive
+         metrics reports.
+
+         I=11: Cumulative Duration - the reported value applies to the
+         accumulation period characteristic of cumulative measurements.
+
+         I=01: Sampled Value - the reported value is a sampled
+         instantaneous value.
+
+      In this document, the discard count metric can only be measured
+      over definite intervals and cannot be sampled.  Accordingly, the
+      value I=01, indicating a sampled value, MUST NOT be sent, and MUST
+      be discarded when received.  In addition, the value I=00 is
+      reserved and also MUST NOT be sent, and MUST be discarded when
+      received.
+
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                    [Page 5]
+
+RFC 7002                     RTCP XR Discard              September 2013
+
+
+   Discard Type (DT): 2 bits
+
+      This field is used to identify the discard type used in this
+      report block.  The discard type is defined as follows:
+
+         00: Report packet discarded or being thrown away before playout
+         due to packet duplication.
+
+         01: Report packet discarded due to too early to be played out.
+
+         10: Report packet discarded due to too late to be played out.
+
+      The value DT=11 is reserved for future definition and MUST NOT be
+      sent, and MUST be discarded when received.
+
+      An endpoint MAY report any combination of discard types in each
+      reporting interval by including several Discard Count Metrics
+      Blocks in a single RTCP XR packet.
+
+      Some systems send duplicate RTP packets for robustness or error
+      resilience.  This is NOT RECOMMENDED since it breaks RTCP packet
+      statistics.  If duplication is desired for error resilience, the
+      mechanism described in [RTPDUP] can be used, since this will not
+      cause breakage of RTP streams or RTCP statistics.
+
+   Reserved (resv): 4 bits
+
+      These bits are reserved.  They MUST be set to zero by senders and
+      ignored by receivers (see [RFC6709], Section 4.2).
+
+   Block Length: 16 bits
+
+      The length of this report block in 32-bit words, minus one, in
+      accordance with the definition in [RFC3611].  This field MUST be
+      set to 2 to match the fixed length of the report block.  The block
+      MUST be discarded if the block length is set to a different value.
+
+   SSRC of Source: 32 bits
+
+      As defined in Section 4.1 of [RFC3611].
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                    [Page 6]
+
+RFC 7002                     RTCP XR Discard              September 2013
+
+
+   Discard Count
+
+      Number of packets discarded over the period (Interval or
+      Cumulative) covered by this report.
+
+      The measured value is an unsigned value.  If the measured value
+      exceeds 0xFFFFFFFD, the value 0xFFFFFFFE MUST be reported to
+      indicate an over-range measurement.  If the measurement is
+      unavailable, the value 0xFFFFFFFF MUST be reported.
+
+      Note that the number of packets expected in the period associated
+      with this metric (whether Interval or Cumulative) is available
+      from the difference between a pair of extended sequence numbers in
+      the Measurement Information Block [RFC6776], so it need not be
+      repeated in this block.
+
+4.  SDP Signaling
+
+   [RFC3611] defines the use of the Session Description Protocol (SDP)
+   [RFC4566] for signaling the use of XR blocks.  However, XR blocks MAY
+   be used without prior signaling (see Section 5 of RFC 3611).
+
+4.1.  SDP rtcp-xr Attribute Extension
+
+   This section augments the SDP [RFC4566] attribute "rtcp-xr" defined
+   in [RFC3611] by providing an additional value of "xr-format" to
+   signal the use of the report block defined in this document.  The
+   ABNF [RFC5234] syntax is as follows.
+
+   xr-format =/ xr-pdc-block
+   xr-pdc-block = "pkt-discard-count"
+
+
+4.2.  Offer/Answer Usage
+
+   When SDP is used in Offer/Answer context, the SDP Offer/Answer usage
+   defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters
+   applies.  For detailed usage of Offer/Answer for unilateral
+   parameters, refer to Section 5.2 of [RFC3611].
+
+5.  IANA Considerations
+
+   New block types for RTCP XR are subject to IANA registration.  For
+   general guidelines on IANA considerations for RTCP XR, refer to
+   [RFC3611].
+
+
+
+
+
+
+Clark, et al.                Standards Track                    [Page 7]
+
+RFC 7002                     RTCP XR Discard              September 2013
+
+
+5.1.  New RTCP XR Block Type Value
+
+   This document assigns the block type value 24 in the IANA "RTP
+   Control Protocol Extended Reports (RTCP XR) Block Type Registry" to
+   the "Discard Count Metrics Block".
+
+5.2.  New RTCP XR SDP Parameter
+
+   This document also registers a new parameter "pkt-discard-count" in
+   the "RTP Control Protocol Extended Reports (RTCP XR) Session
+   Description Protocol (SDP) Parameters Registry".
+
+5.3.  Contact Information for Registrations
+
+   The following contact information is provided for all registrations
+   in this document:
+
+   Qin Wu (sunseawq@huawei.com)
+   101 Software Avenue, Yuhua District
+   Nanjing, Jiangsu  210012
+   China
+
+6.  Security Considerations
+
+   In some situations, returning very detailed error information (e.g.,
+   over-range measurement or measurement unavailable) using this report
+   block can provide an attacker with insight into the security
+   processing.  Where this is a concern, the implementation should apply
+   encryption and authentication to this report block.  For example,
+   this can be achieved by using the Audio-Visual Profile with Feedback
+   (AVPF) profile together with the Secure RTP profile, as defined in
+   [RFC3711]; an appropriate combination of those two profiles ("SAVPF")
+   is specified in [RFC5124].
+
+   Besides this, it is believed that this RTCP XR block introduces no
+   new security considerations beyond those described in [RFC3611].
+   This block does not provide per-packet statistics, so the risk to
+   confidentiality documented in Section 7, paragraph 3 of [RFC3611]
+   does not apply.
+
+7.  Contributors
+
+   Geoff Hunt wrote the initial draft of this document.
+
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                    [Page 8]
+
+RFC 7002                     RTCP XR Discard              September 2013
+
+
+8.  Acknowledgments
+
+   The authors gratefully acknowledge reviews and feedback provided by
+   Bruce Adams, Philip Arden, Amit Arora, Claire Bi, Bob Biskner,
+   Gonzalo Camarillo, Benoit Claise, Kevin Connor, Claus Dahm, Spencer
+   Dawkins, Randy Ethier, Roni Even, Stephen Farrel, Jim Frauenthal,
+   Kevin Gross, Albert Higashi, Tom Hock, Shane Holthaus, Paul Jones,
+   Rajesh Kumar, Keith Lantz, Jonathan Lennox, Mohamed Mostafa, Amy
+   Pendleton, Colin Perkins, Mike Ramalho, Ravi Raviraj, Dan Romascanu,
+   Albrecht Schwarz, Varun Singh, Tom Taylor, Dan Wing, and Hideaki
+   Yamada.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", STD 64, RFC 3550, July 2003.
+
+   [RFC3611]  Friedman, T., Caceres, R., and A. Clark, "RTP Control
+              Protocol Extended Reports (RTCP XR)", RFC 3611, November
+              2003.
+
+   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
+              RFC 3711, March 2004.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, July 2006.
+
+   [RFC5124]  Ott, J. and E. Carrara, "Extended Secure RTP Profile for
+              Real-time Transport Control Protocol (RTCP)-Based Feedback
+              (RTP/SAVPF)", RFC 5124, February 2008.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [RFC6709]  Carpenter, B., Aboba, B., and S. Cheshire, "Design
+              Considerations for Protocol Extensions", RFC 6709,
+              September 2012.
+
+   [RFC6776]  Clark, A. and Q. Wu, "Measurement Identity and Information
+              Reporting Using a Source Description (SDES) Item and an
+              RTCP Extended Report (XR) Block", RFC 6776, October 2012.
+
+
+
+Clark, et al.                Standards Track                    [Page 9]
+
+RFC 7002                     RTCP XR Discard              September 2013
+
+
+9.2.  Informative References
+
+   [RFC4588]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
+              Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
+              July 2006.
+
+   [RFC5109]  Li, A., "RTP Payload Format for Generic Forward Error
+              Correction", RFC 5109, December 2007.
+
+   [RFC5481]  Morton, A. and B. Claise, "Packet Delay Variation
+              Applicability Statement", RFC 5481, March 2009.
+
+   [RFC5725]  Begen, A., Hsu, D., and M. Lague, "Post-Repair Loss RLE
+              Report Block Type for RTP Control Protocol (RTCP) Extended
+              Reports (XRs)", RFC 5725, February 2010.
+
+   [RFC6390]  Clark, A. and B. Claise, "Guidelines for Considering New
+              Performance Metric Development", BCP 170, RFC 6390,
+              October 2011.
+
+   [RFC6792]  Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
+              RTP Monitoring Framework", RFC 6792, November 2012.
+
+   [RFC7003]  Clark, A., Huang, R., and Q. Wu, Ed., "RTP Control
+              Protocol(RTCP) Extended Report (XR) Block for Burst/Gap
+              Discard Metric Reporting", RFC 7003, September 2013.
+
+   [RTPDUP]   Begen, A. and C. Perkins, "Duplicating RTP Streams", Work
+              in Progress, March 2013.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                   [Page 10]
+
+RFC 7002                     RTCP XR Discard              September 2013
+
+
+Appendix A.  Metrics Represented Using the Template from RFC 6390
+
+   a.  Number of Packets Discarded Metric
+
+       *  Metric Name: Number of RTP packets discarded.
+
+       *  Metric Description: Number of RTP packets discarded over the
+          period covered by this report.
+
+       *  Method of Measurement or Calculation: See Section 3.2, Discard
+          Count definition.
+
+       *  Units of Measurement: See Section 3.2, Discard Count
+          definition.
+
+       *  Measurement Point(s) with Potential Measurement Domain: See
+          Section 3, 1st paragraph.
+
+       *  Measurement Timing: See Section 3, 1st paragraph for
+          measurement timing and Section 3.2 for Interval Metric flag.
+
+       *  Use and Applications: See Section 1.4.
+
+       *  Reporting Model: See RFC 3611.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                   [Page 11]
+
+RFC 7002                     RTCP XR Discard              September 2013
+
+
+Authors' Addresses
+
+   Alan Clark
+   Telchemy Incorporated
+   2905 Premiere Parkway, Suite 280
+   Duluth, GA  30097
+   USA
+
+   EMail: alan.d.clark@telchemy.com
+
+
+   Glen Zorn
+   Network Zen
+   227/358 Thanon Sanphawut
+   Bang Na, Bangkok  10260
+   Thailand
+
+   Phone: +66 (0) 8-1000-4155
+   EMail: glenzorn@gmail.com
+
+
+   Qin Wu
+   Huawei
+   101 Software Avenue, Yuhua District
+   Nanjing, Jiangsu  210012
+   China
+
+   EMail: sunseawq@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                   [Page 12]
+