doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc7003.txt b/doc/rfc/rfc7003.txt
new file mode 100644
index 0000000..5bbb62b
--- /dev/null
+++ b/doc/rfc/rfc7003.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          A. Clark
+Request for Comments: 7003                                      Telchemy
+Category: Standards Track                                       R. Huang
+ISSN: 2070-1721                                               Q. Wu, Ed.
+                                                                  Huawei
+                                                          September 2013
+
+
+         RTP Control Protocol (RTCP) Extended Report (XR) Block
+                 for Burst/Gap Discard Metric Reporting
+
+Abstract
+
+   This document defines an RTP Control Protocol (RTCP) Extended Report
+   (XR) block that allows the reporting of burst and gap discard metrics
+   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/rfc7003.
+
+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 7003                RTCP XR Burst/Gap Discard         September 2013
+
+
+Table of Contents
+   1. Introduction ....................................................2
+      1.1. Burst/Gap Discard Metrics Block ............................2
+      1.2. RTCP and RTCP Extended Reports .............................3
+      1.3. Performance Metrics Framework ..............................3
+      1.4. Applicability ..............................................3
+   2. Terminology .....................................................3
+   3. Burst/Gap Discard Metrics Block .................................4
+      3.1. Report Block Structure .....................................5
+      3.2. Definition of Fields in Burst/Gap Discard Metrics Block ....5
+      3.3. Derived Metrics Based on Reported Metrics ..................7
+   4. Considerations for Voice-over-IP Applications ...................7
+   5. SDP Signaling ...................................................8
+      5.1. SDP rtcp-xr Attribute Extension ............................8
+      5.2. Offer/Answer Usage .........................................8
+   6. IANA Considerations .............................................8
+      6.1. New RTCP XR Block Type Value ...............................8
+      6.2. New RTCP XR SDP Parameter ..................................9
+      6.3. Contact Information for Registrations ......................9
+   7. Security Considerations .........................................9
+   8. Contributors ....................................................9
+   9. Acknowledgments .................................................9
+   10. References ....................................................10
+      10.1. Normative References .....................................10
+      10.2. Informative References ...................................10
+   Appendix A.  Metrics Represented Using the Template from RFC 6390..12
+
+1.  Introduction
+
+1.1.  Burst/Gap Discard Metrics 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 proportion of packets discarded by the
+   jitter buffer at the receiver, using packet discard logic according
+   to the jitter buffer algorithms.  The discards during discard bursts
+   are reported, together with the number of bursts.  This block is
+   intended to be used in conjunction with [RFC7002], which provides the
+   total packets discarded and on which this block therefore depends.
+   However, the metric in [RFC7002] may be used independently of the
+   metrics in this block.
+
+   This block provides information on transient IP problems.  Burst/gap
+   metrics are typically used in cumulative reports; however, they also
+   may be used in interval reports (see the Interval Metric flag in
+   Section 3.2).  The burstiness of packet discard affects user
+   experience, may influence any sender strategies to mitigate the
+   problem, and may also have diagnostic value.
+
+
+
+Clark, et al.                Standards Track                    [Page 2]
+
+RFC 7003                RTCP XR Burst/Gap Discard         September 2013
+
+
+   The metric belongs to the class of transport-related end-system
+   metrics defined in [RFC6792].
+
+   The definitions of "burst", "gap", "loss", and "discard" are
+   consistent with the definitions in [RFC3611].  To accommodate the
+   range of jitter buffer algorithms and packet discard logic that may
+   be used by implementors, the method used to distinguish between
+   bursts and gaps shall use an equivalent method to that defined in
+   Section 4.7.2 of [RFC3611].  Note that reporting the specific jitter
+   buffer algorithms and/or packet discard logic is out of the scope of
+   this document.
+
+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
+
+   The Performance Metrics Framework [RFC6390] provides guidance on the
+   definition and specification of performance metrics.  The RTP
+   Monitoring Framework [RFC6792] provides guidelines 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
+
+   These metrics are applicable to a range of RTP applications that
+   contain de-jitter buffers [RFC5481] at the receiving end to smooth
+   variation in packet-arrival time and don't use stream repair means,
+   e.g., Forward Error Correction (FEC) [RFC5109] and/or retransmission
+   [RFC4588].
+
+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 7003                RTCP XR Burst/Gap 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 too early to be played out, too
+      late to be played out, or 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 received (or OK), discarded, or lost.  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" defined in
+      [RFC7002] 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.  Note that the term "discard" defined here
+      builds on the "discard" definition in [RFC3611] but extends the
+      concept to take into account packet duplication and reports
+      different types of discard counts [RFC7002].
+
+   Bursts and Gaps
+
+      The terms "burst" and "gap" are used in a manner consistent with
+      that of RTCP XR [RFC3611].  RTCP XR views an RTP stream as being
+      divided into bursts, which are periods during which the discard
+      rate is high enough to cause noticeable quality degradation
+      (generally over 5 percent discard rate), and gaps, which are
+      periods during which discarded packets are infrequent and hence
+      quality is generally acceptable.
+
+3.  Burst/Gap Discard Metrics Block
+
+   Metrics in this block report on burst/gap discard in the stream
+   arriving at the RTP system.  Measurements of these metrics are made
+   at the receiving end of the RTP stream.  Instances of this metrics
+   block use the synchronization source (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 period in the
+   Measurement Information Block indicating the span of the report.
+   Senders MUST send this block in the same compound RTCP packet as the
+
+
+
+Clark, et al.                Standards Track                    [Page 4]
+
+RFC 7003                RTCP XR Burst/Gap Discard         September 2013
+
+
+   Measurement Information Block.  Receivers MUST verify that the
+   measurement period is received in the same compound RTCP packet as
+   this metrics block.  If not, this metrics block MUST be discarded.
+
+3.1.  Report Block Structure
+
+   The structure of the Burst/Gap Discard 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=20     | I |   resv    |      Block Length = 3         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        SSRC of Source                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Threshold   |         Packets Discarded in Bursts           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |       Total Packets Expected in Bursts        |   Reserved    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 1: Report Block Structure
+
+3.2.  Definition of Fields in Burst/Gap Discard Metrics Block
+
+   Block Type (BT): 8 bits
+
+      A Burst/Gap Discard Metrics Block is identified by the constant
+      20.
+
+   Interval Metric flag (I): 2 bits
+
+      This field is used to indicate whether the burst/gap discard
+      metrics are Sampled, Interval, or Cumulative metrics [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.
+
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                    [Page 5]
+
+RFC 7003                RTCP XR Burst/Gap Discard         September 2013
+
+
+      In this document, burst/gap discard metrics can only be measured
+      over definite intervals and cannot be sampled.  Also, the value
+      I=00 is reserved for future use.  Senders MUST NOT use the values
+      I=00 or I=01.  If a block is received with I=00 or I=01, the
+      receiver MUST discard the block.
+
+   Reserved (resv): 6 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.  For
+      the Burst/Gap Discard Metrics Block, the block length is equal to
+      3.  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].
+
+   Threshold: 8 bits
+
+      The Threshold is equivalent to Gmin in [RFC3611], i.e., the number
+      of successive packets that must not be discarded prior to and
+      following a discard packet in order for this discarded packet to
+      be regarded as part of a gap.  Note that the Threshold is set in
+      accordance with the Gmin calculation defined in Section 4.7.2 of
+      [RFC3611].
+
+   Packets Discarded in Bursts: 24 bits
+
+      The total number of packets discarded during discard bursts.
+
+      The measured value is unsigned value.  If the measured value
+      exceeds 0xFFFFFD, the value 0xFFFFFE MUST be reported to indicate
+      an over-range measurement.  If the measurement is unavailable, the
+      value 0xFFFFFF MUST be reported.
+
+   Total Packets Expected in Bursts: 24 bits
+
+      The total number of packets expected during discard bursts (that
+      is, the sum of received packets and lost packets).
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                    [Page 6]
+
+RFC 7003                RTCP XR Burst/Gap Discard         September 2013
+
+
+      The measured value is unsigned value.  If the measured value
+      exceeds 0xFFFFFD, the value 0xFFFFFE MUST be reported to indicate
+      an over-range measurement.  If the measurement is unavailable, the
+      value 0xFFFFFF MUST be reported.
+
+   Reserved: 8 bits
+
+      These bits are reserved.  They MUST be set to zero by senders and
+      ignored by receivers (See [RFC6709], Section 4.2).
+
+3.3.  Derived Metrics Based on Reported Metrics
+
+   The metrics described here are intended to be used in conjunction
+   with information from the Measurement Information Block [RFC6776] and
+   also with the metric "number of packets discarded" provided in the
+   RTCP XR Discard Count Metrics Block [RFC7002].
+
+   These metrics provide the following information relevant to
+   statistical parameters, including:
+
+   o  The fraction of packets discarded during bursts (Burst Discard
+      Rate in [RFC7004]), which can be calculated using the metric
+      "Packets Discarded in Bursts" and the metric "Total Packets
+      Expected in Bursts" provided in the Burst/Gap Discard Metrics
+      Block.
+
+   o  The fraction of packets discarded during gaps (Gap Discard Rate in
+      [RFC7004]), which can be calculated using the metric "Packets
+      Discarded in Bursts" and the metric "Total Packets Expected in
+      Bursts" provided in the Burst/Gap Discard Metrics Block.
+
+   The details on calculation these parameters in the metrics are
+   described in [RFC7004].
+
+4.  Considerations for Voice-over-IP Applications
+
+   This metrics block is applicable to a broad range of RTP
+   applications.  Where the metric is used with a Voice-over-IP (VoIP)
+   application and the stream repair means is not available, the
+   following considerations apply.
+
+   RTCP XR views a call as being divided into bursts, which are periods
+   during which the discard rate is high enough to cause noticeable call
+   quality degradation (generally over 5 percent discard rate) and gaps,
+   which are periods during which discarded packets are infrequent and
+   hence call quality is generally acceptable.
+
+
+
+
+
+Clark, et al.                Standards Track                    [Page 7]
+
+RFC 7003                RTCP XR Burst/Gap Discard         September 2013
+
+
+   If voice activity detection is used, the burst and gap duration shall
+   be determined as if silence packets had been sent, i.e., a period of
+   silence in excess of Gmin packets will terminate a burst condition.
+
+   The recommended value for the threshold Gmin in [RFC3611] results in
+   a burst being a period of time during which the call quality is
+   degraded to a similar extent to a typical pulse code modulation (PCM)
+   severely errored second.
+
+5.  SDP Signaling
+
+   [RFC3611] defines the use of SDP (Session Description Protocol)
+   [RFC4566] for signaling the use of XR blocks.  XR blocks MAY be used
+   without prior signaling.
+
+5.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-bgd-block
+
+   xr-bgd-block = "burst-gap-discard"
+
+5.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 in Offer/Answer for unilateral
+   parameters, refer to Section 5.2 of [RFC3611].
+
+6.  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].
+
+6.1.  New RTCP XR Block Type Value
+
+   This document assigns the block type value 20 in the IANA "RTP
+   Control Protocol Extended Reports (RTCP XR) Block Type Registry" to
+   the "Burst/Gap Discard Metrics Block".
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                    [Page 8]
+
+RFC 7003                RTCP XR Burst/Gap Discard         September 2013
+
+
+6.2.  New RTCP XR SDP Parameter
+
+   This document also registers a new parameter "burst-gap-discard" in
+   the "RTP Control Protocol Extended Reports (RTCP XR) Session
+   Description Protocol (SDP) Parameters Registry".
+
+6.3.  Contact Information for Registrations
+
+   The contact information for the registrations is:
+
+   Qin Wu (sunseawq@huawei.com)
+   101 Software Avenue, Yuhua District
+   Nanjing, Jiangsu  210012
+   China
+
+7.  Security Considerations
+
+   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.
+
+8.  Contributors
+
+   Geoff Hunt wrote the initial draft of this document.
+
+9.  Acknowledgments
+
+   The authors gratefully acknowledge reviews and feedback provided by
+   Bruce Adams, Philip Arden, Amit Arora, Claire Bi, Bob Biskner, Benoit
+   Claise, Kevin Connor, Claus Dahm, Randy Ethier, Roni Even, Stephen
+   Farrell, Jim Frauenthal, Albert Higashi, Tom Hock, Shane Holthaus,
+   Paul Jones, Rajesh Kumar, Paul Kyzivat, Keith Lantz, Mohamed Mostafa,
+   Amy Pendleton, Colin Perkins, Mike Ramalho, Ravi Raviraj, Dan
+   Romascanu, Albrecht Schwarz, Tom Taylor, and Hideaki Yamada.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                    [Page 9]
+
+RFC 7003                RTCP XR Burst/Gap Discard         September 2013
+
+
+10.  References
+
+10.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.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, July 2006.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [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.
+
+   [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.
+
+   [RFC7002]  Clark, A., Zorn, G., and Q. Wu, "RTP Control Protocol
+              (RTCP) Extended Report (XR) for Discard Count Metric
+              Reporting", RFC 7002, September 2013.
+
+   [RFC7004]  Zorn, G., Schott, R., Wu, Q., Ed., and R. Huang, "RTP
+              Control Protocol (RTCP) Extended Report (XR) Blocks for
+              Summary Statistics Metrics Reporting", RFC 7004, September
+              2013.
+
+10.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.
+
+
+
+
+
+Clark, et al.                Standards Track                   [Page 10]
+
+RFC 7003                RTCP XR Burst/Gap Discard         September 2013
+
+
+   [RFC5481]  Morton, A. and B. Claise, "Packet Delay Variation
+              Applicability Statement", RFC 5481, March 2009.
+
+   [RFC6390]  Clark, A. and B. Claise, "Guidelines for Considering New
+              Performance Metric Development", BCP 170, RFC 6390,
+              October 2011.
+
+   [RFC6709]  Carpenter, B., Aboba, B., and S. Cheshire, "Design
+              Considerations for Protocol Extensions", RFC 6709,
+              September 2012.
+
+   [RFC6792]  Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
+              RTP Monitoring Framework", RFC 6792, November 2012.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                   [Page 11]
+
+RFC 7003                RTCP XR Burst/Gap Discard         September 2013
+
+
+Appendix A.  Metrics Represented Using the Template from RFC 6390
+
+   a.  Burst/Gap Discard Threshold in RTP Metric
+
+       *  Metric Name: Burst/gap discard threshold in RTP
+
+       *  Metric Description: The Threshold is equivalent to Gmin in
+          [RFC3611], i.e., the number of successive packets that must
+          not be discarded prior to and following a discard packet in
+          order for this discarded packet to be regarded as part of a
+          gap.
+
+       *  Method of Measurement or Calculation: See Section 3.2,
+          Threshold definition.
+
+       *  Units of Measurement: See Section 3.2, Threshold definition.
+
+       *  Measurement Point(s) with Potential Measurement Domain: See
+          Section 3, 1st paragraph.
+
+       *  Measurement Timing: See Section 3, 2nd paragraph for
+          measurement timing and Section 3.2 for Interval Metric flag.
+
+       *  Use and Applications: See Section 1.4.
+
+       *  Reporting Model: See RFC 3611.
+
+   b.  Packets Discarded in Bursts Metric
+
+       *  Metric Name: RTP packets discarded in bursts
+
+       *  Metric Description: The total number of RTP packets discarded
+          during discard bursts.
+
+       *  Method of Measurement or Calculation: See Section 3.2, Packets
+          Discarded in Bursts definition.
+
+       *  Units of Measurement: See Section 3.2, Packets Discarded in
+          Bursts definition.
+
+       *  Measurement Point(s) with Potential Measurement Domain: See
+          Section 3, 1st paragraph.
+
+       *  Measurement Timing: See Section 3, 2nd paragraph for
+          measurement timing and Section 3.2 for Interval Metric flag.
+
+
+
+
+
+
+Clark, et al.                Standards Track                   [Page 12]
+
+RFC 7003                RTCP XR Burst/Gap Discard         September 2013
+
+
+       *  Use and Applications: See Section 1.4.
+
+       *  Reporting Model: See RFC 3611.
+
+   c.  Total Packets Expected in Discard Bursts Metric
+
+       *  Metric Name: Total RTP packets expected in discard bursts
+
+       *  Metric Description: The total number of packets expected
+          during discard bursts (that is, the sum of received packets
+          and lost packets).
+
+       *  Method of Measurement or Calculation: See Section 3.2, Total
+          Packets Expected in Bursts definition.
+
+       *  Units of Measurement: See Section 3.2, Total Packets Expected
+          in Bursts definition.
+
+       *  Measurement Point(s) with Potential Measurement Domain: See
+          Section 3, 1st paragraph.
+
+       *  Measurement Timing: See Section 3, 2nd 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 13]
+
+RFC 7003                RTCP XR Burst/Gap Discard         September 2013
+
+
+Authors' Addresses
+
+   Alan Clark
+   Telchemy Incorporated
+   2905 Premiere Parkway, Suite 280
+   Duluth, GA  30097
+   USA
+
+   EMail: alan.d.clark@telchemy.com
+
+
+   Rachel Huang
+   Huawei Technologies Co., Ltd.
+   101 Software Avenue, Yuhua District
+   Nanjing, Jiangsu  210012
+   China
+
+   EMail: Rachel@huawei.com
+
+
+   Qin Wu (editor)
+   Huawei
+   101 Software Avenue, Yuhua District
+   Nanjing, Jiangsu  210012
+   China
+
+   EMail: sunseawq@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark, et al.                Standards Track                   [Page 14]
+