doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc6990.txt b/doc/rfc/rfc6990.txt
new file mode 100644
index 0000000..0c90b33
--- /dev/null
+++ b/doc/rfc/rfc6990.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          R. Huang
+Request for Comments: 6990                                         Q. Wu
+Category: Standards Track                                         Huawei
+ISSN: 2070-1721                                                H. Asaeda
+                                                                    NICT
+                                                                 G. Zorn
+                                                             Network Zen
+                                                             August 2013
+
+
+   RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG-2
+  Transport Stream (TS) Program Specific Information (PSI) Independent
+               Decodability Statistics Metrics Reporting
+
+Abstract
+
+   An MPEG-2 Transport Stream (TS) is a standard container format used
+   in the transmission and storage of multimedia data.  Unicast/
+   multicast MPEG-2 TS over RTP is widely deployed in IPTV systems.
+   This document defines an RTP Control Protocol (RTCP) Extended Report
+   (XR) block that allows the reporting of MPEG-2 TS decodability
+   statistics metrics related to transmissions of MPEG-2 TS over RTP.
+   The metrics specified in the RTCP XR block are not dependent on
+   Program Specific Information (PSI) carried in MPEG-2 TS.
+
+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/rfc6990.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huang, et al.                Standards Track                    [Page 1]
+
+RFC 6990                 RTCP XR TS Decodability             August 2013
+
+
+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.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  MPEG-2 Transport Stream Decodability Metrics  . . . . . .   3
+     1.2.  RTCP and RTCP Extended Reports  . . . . . . . . . . . . .   3
+     1.3.  Performance Metrics Framework . . . . . . . . . . . . . .   3
+     1.4.  Applicability . . . . . . . . . . . . . . . . . . . . . .   4
+   2.  Standards Language  . . . . . . . . . . . . . . . . . . . . .   4
+   3.  MPEG-2 TS PSI-Independent Decodability Statistics Metrics
+       Block . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   4.  SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . .   8
+     4.1.  SDP rtcp-xr Attribute Extension . . . . . . . . . . . . .   8
+     4.2.  Offer/Answer Usage  . . . . . . . . . . . . . . . . . . .   8
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
+     5.1.  New RTCP XR Block Type Value  . . . . . . . . . . . . . .   8
+     5.2.  New RTCP XR SDP Parameter . . . . . . . . . . . . . . . .   9
+     5.3.  Contact Information for Registrations . . . . . . . . . .   9
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
+   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
+     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huang, et al.                Standards Track                    [Page 2]
+
+RFC 6990                 RTCP XR TS Decodability             August 2013
+
+
+1.  Introduction
+
+1.1.  MPEG-2 Transport Stream Decodability Metrics
+
+   The European Telecommunications Standards Institute (ETSI) has
+   defined a set of syntax and information consistency tests and
+   corresponding indicators [ETSI] that are recommended for the
+   monitoring of MPEG-2 Transport Streams [ISO-IEC.13818-1.2013].  The
+   tests and corresponding indicators are grouped according to priority:
+
+   o  First priority - Necessary for decodability (basic monitoring)
+
+   o  Second priority - Recommended for continuous or periodic
+      monitoring
+
+   o  Third priority - Recommended for application-dependent monitoring
+
+   This memo is based on information consistency tests and resulting
+   indicators defined by ETSI [ETSI] and defines a new block type to
+   augment those defined in [RFC3611] for use with MPEG-2 Transport
+   Stream (TS) [ISO-IEC.13818-1.2013].  The new block type supports
+   reporting of the number of occurrences of each PSI-independent
+   indicator in the first and second priorities; third priority
+   indicators are not supported.
+
+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 on the reporting block format
+   using RTCP XR.  The new report block described in this memo is in
+   compliance with the monitoring architecture specified in [RFC6792]
+   and the performance metrics framework [RFC6390].
+
+
+
+
+
+
+
+
+
+
+Huang, et al.                Standards Track                    [Page 3]
+
+RFC 6990                 RTCP XR TS Decodability             August 2013
+
+
+1.4.  Applicability
+
+   This block type allows a count of MPEG-2 Transport Stream quality
+   metrics that are measured in accordance with ETSI TR 101290 [ETSI] to
+   be reported by an endpoint.  These metrics are useful for identifying
+   bitstream packetization and transport stream encoding problems that
+   may affect the user's perception of a video service delivered over
+   RTP.
+
+2.  Standards Language
+
+   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].
+
+3.  MPEG-2 TS PSI-Independent Decodability Statistics Metrics Block
+
+   ETSI TR 101290 [ETSI] generally defines metrics related to error
+   events while this document contains counts of those metrics defined
+   in [ETSI].  The block defined in this document reports MPEG-2 TS PSI-
+   independent decodability statistics metrics beyond the information
+   carried in the standard RTCP packet format, which are measured at the
+   receiving end of the RTP stream.  It contains counts of eight metrics
+   defined in ETSI TR 101290 [ETSI].  Information is reported about
+   basic monitoring parameters necessary to ensure that the TS can be
+   decoded, including:
+
+   o  Transport Stream Synchronization Losses
+
+   o  Sync byte errors
+
+   o  Continuity count errors
+
+   and continuous monitoring parameters necessary to ensure the
+   continuous decoding, including:
+
+   o  Transport errors
+
+   o  Program Clock Reference (PCR) errors
+
+   o  PCR repetition errors
+
+   o  PCR discontinuity indicator errors
+
+   o  PCR accuracy errors
+
+   o  Presentation Time Stamp (PTS) errors
+
+
+
+
+Huang, et al.                Standards Track                    [Page 4]
+
+RFC 6990                 RTCP XR TS Decodability             August 2013
+
+
+   The other parameters are ignored since they do not apply to all
+   MPEG-2 implementations.  For further information on these parameters,
+   see [ETSI].  Note that when the report of this block spans across
+   more than one measurement interval [RFC6776], the count of the
+   metrics (e.g., Sync byte errors and PCR errors) defined in [ETSI] may
+   reflect a problem in the current or previous measurement interval.
+
+   The MPEG-2 TS PSI-Independent Decodability Statistics Metrics Block
+   has the following format:
+
+    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=22     |    Reserved   |         Block Length          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     SSRC of Source                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |          begin_seq            |             end_seq           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      TS_sync_loss_count                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Sync_byte_error_count                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Continuity_count_error_count                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Transport_error_count                    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                        PCR_error_count                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                   PCR_repetition_error_count                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            PCR_discontinuity_indicator_error_count            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                     PCR_accuracy_error_count                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       PTS_error_count                         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Block Type (BT): 8 bits
+
+      The MPEG-2 TS PSI-Independent Decodability Statistics Metrics
+      Block is identified by the constant 22.
+
+
+   Reserved: 8 bits
+
+      These bits are reserved.  They MUST be set to zero by senders and
+      ignored by receivers (see [RFC6709] Section 4.2).
+
+
+
+Huang, et al.                Standards Track                    [Page 5]
+
+RFC 6990                 RTCP XR TS Decodability             August 2013
+
+
+   Block Length: 16 bits
+
+      The constant 11, in accordance with the definition of this field
+      in Section 3 of RFC 3611.  The block MUST be discarded if the
+      block length is set to a different value.
+
+
+   Synchronization source (SSRC) of Source: 32 bits
+
+      As defined in Section 4.1 of RFC 3611.
+
+
+   begin_seq: 16 bits
+
+      The RTP sequence number corresponding to the start of the
+      measurement period, as defined in Section 4.1 of RFC 3611.
+
+
+   end_seq: 16 bits
+
+      The RTP sequence number corresponding to the end of the
+      measurement period, as defined in Section 4.1 of RFC 3611.
+
+
+   TS_sync_loss_count: 32 bits
+
+      A count of the number of TS_sync_loss errors that occurred in the
+      above sequence number interval.  A TS_sync_loss error occurs when
+      there are two or more consecutive incorrect sync bytes within the
+      MPEG-2 TS, as defined in Section 5.2.1 of [ETSI].
+
+
+   Sync_byte_error_count: 32 bits
+
+      A count of the number of Sync_byte_errors that occurred in the
+      above sequence number interval.  A sync byte error occurs when the
+      sync byte is not equal to 0x47 in any TS packet contained in the
+      MPEG-2 TS, as defined in Section 5.2.1 of [ETSI].
+
+
+   Continuity_count_error_count: 32 bits
+
+      A count of the number of Continuity_count_errors that occurred in
+      the above sequence number interval.  A Continuity_count_error
+      occurs when any of the following faults happen within the MPEG-2
+      TS -- incorrect packet order, a packet occurs more than twice, or
+      a packet is lost, as defined in Section 5.2.1 of [ETSI].
+
+
+
+
+Huang, et al.                Standards Track                    [Page 6]
+
+RFC 6990                 RTCP XR TS Decodability             August 2013
+
+
+   Transport_error_count: 32 bits
+
+      A count of the number of Transport_errors that occurred in the
+      above sequence number interval.  A Transport_error occurs when an
+      erroneous TS packet cannot be corrected within the MPEG-2 TS, as
+      defined in Section 5.2.2 of [ETSI].
+
+
+   PCR_error_count: 32 bits
+
+      A count of the number of PCR_errors that occurred in the above
+      sequence number interval.  A PCR_error occurs if the primary clock
+      reference (PCR) is not seen for more than 100 ms within the MPEG-2
+      TS, as defined in Section 5.2.2 of [ETSI].  The time interval
+      between two consecutive PCR values should be no more than 40 ms.
+
+
+   PCR_repetition_error_count: 32 bits
+
+      A count of the number of PCR_repetition_errors that occurred in
+      the above sequence number interval.  A PCR_repetition_error occurs
+      when the time interval between two consecutive PCR values is more
+      than 40 ms within the MPEG-2 TS, as defined in Section 5.2.2 of
+      [ETSI].
+
+
+   PCR_discontinuity_indicator_error_count: 32 bits
+
+      A count of the number of PCR_discontinuity_indicator_errors that
+      occurred in the above sequence number interval.  A
+      PCR_discontinuity_indicator_error occurs if the time interval
+      between two consecutive PCR values is more than 100 ms within the
+      MPEG-2 TS, as defined in Section 5.2.2 of [ETSI].
+
+
+   PCR_accuracy_error_count: 32 bits
+
+      A count of the number of PCR_accuracy_errors that occurred in the
+      above sequence number interval.  A PCR_accuracy_error occurs when
+      the PCR accuracy of the selected program is outside the range of
+      +/-500 ns within the MPEG-2 TS, as defined in Section 5.2.2 of
+      [ETSI].
+
+
+
+
+
+
+
+
+
+Huang, et al.                Standards Track                    [Page 7]
+
+RFC 6990                 RTCP XR TS Decodability             August 2013
+
+
+   PTS_error_count: 32 bits
+
+      A count of the number of PTS_errors that occurred in the above
+      sequence number interval.  A PTS_error occurs when the PTS
+      repetition is more than 700 ms within the MPEG-2 TS, as defined in
+      Section 5.2.2 of [ETSI].  Note that the PTS is contained in the
+      MPEG-2 TS and is used to aid the decoder in presenting the program
+      on time, at the correct speed, and synchronized.
+
+4.  SDP Signaling
+
+   RFC 3611 defines the use of the Session Description Protocol (SDP)
+   [RFC4566] for signaling the use of RTCP 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 session augments the SDP attribute "rtcp-xr" defined in
+   Section 5.1 of RFC 3611 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-tpid-block
+
+   xr-tpid-block = "ts-psi-indep-decodability"
+
+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 report block types for RTCP XR are subject to IANA registration.
+   For general guidelines on IANA allocations for RTCP XR, refer to
+   Section 6.2 of RFC 3611.
+
+5.1.  New RTCP XR Block Type Value
+
+   This document assigns the block type value 22 in the IANA "RTP
+   Control Protocol Extended Reports (RTCP XR) Block Type Registry" to
+   the "MPEG-2 Transport Stream PSI-Independent Decodability Statistics
+   Metrics Block".
+
+
+
+
+
+Huang, et al.                Standards Track                    [Page 8]
+
+RFC 6990                 RTCP XR TS Decodability             August 2013
+
+
+5.2.  New RTCP XR SDP Parameter
+
+   This document also registers the new parameter "ts-psi-
+   indep-decodability" in the "RTP Control Protocol Extended Reports
+   (RTCP XR) Session Description Protocol (SDP) Parameters Registry".
+
+5.3.  Contact Information for Registrations
+
+   The contact information for registrations is:
+
+   Qin Wu (sunseawq@huawei.com)
+   101 Software Avenue, Yuhua District
+   Nanjing, Jiangsu  210012
+   China
+
+6.  Security Considerations
+
+   There might be some relationship between reported error counters and
+   contractual Service Level Agreements (SLAs); hence, an attack (e.g.,
+   RTP endpoints reporting false data, or an attacker in the path
+   modifying the data being reported) might deliberately corrupt these
+   error counters, resulting in financial implications for the network
+   operator (either as a result of unneeded performance metrics, or
+   penalty charges for SLA failure).
+
+   A solution to prevent such an attack is to apply an authentication
+   and integrity protection framework for the RTCP XR block.  This can
+   be accomplished using the RTP profile that combines Secure RTP
+   [RFC3711] and the Audio-Visual Profile with Feedback (AVPF) into
+   Secure AVPF (SAVPF) [RFC5124].
+
+   Besides this, the RTCP XR block in this document introduces no new
+   security considerations beyond those described in [RFC3611].
+
+7.  Acknowledgements
+
+   Thanks to Ray van Brandenburg, Claire Bi, Colin Perkins, Roni Even,
+   Dan Romascanu, Ali Begen, Alexey Melnikov, Bert Wijnen, Gonzalo
+   Camarillo, Benoit Claise, and Alan Clark for useful reviews and
+   suggestions.
+
+8.  References
+
+8.1.  Normative References
+
+   [ETSI]     ETSI, "Digital Video Broadcasting (DVB); Measurement
+              guidelines for DVB systems", Technical Report TR 101 290,
+              2001.
+
+
+
+Huang, et al.                Standards Track                    [Page 9]
+
+RFC 6990                 RTCP XR TS Decodability             August 2013
+
+
+   [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.
+
+8.2.  Informative References
+
+   [ISO-IEC.13818-1.2013]
+              International Organization for Standardization,
+              "Information technology - Generic coding of moving
+              pictures and associated audio information: Systems", ISO
+              International Standard 13818-1, May 2013.
+
+   [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.
+
+   [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.
+
+   [RFC6792]  Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
+              RTP Monitoring Framework", RFC 6792, November 2012.
+
+
+
+
+Huang, et al.                Standards Track                   [Page 10]
+
+RFC 6990                 RTCP XR TS Decodability             August 2013
+
+
+Authors' Addresses
+
+   Rachel Huang
+   Huawei
+   101 Software Avenue, Yuhua District
+   Nanjing  210012
+   China
+
+   EMail: rachel.huang@huawei.com
+
+
+   Qin Wu
+   Huawei
+   101 Software Avenue, Yuhua District
+   Nanjing, Jiangsu  210012
+   China
+
+   EMail: bill.wu@huawei.com
+
+
+   Hitoshi Asaeda
+   National Institute of Information and Communications Technology
+   4-2-1 Nukui-Kitamachi
+   Koganei, Tokyo  184-8795
+   Japan
+
+   EMail: asaeda@nict.go.jp
+
+
+   Glen Zorn
+   Network Zen
+   227/358 Thanon Sanphawut
+   Bang Na, Bangkok  10260
+   Thailand
+
+   Phone: +66 (0) 8-1000-4155
+   EMail: glenzorn@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huang, et al.                Standards Track                   [Page 11]
+