doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc7380.txt b/doc/rfc/rfc7380.txt
new file mode 100644
index 0000000..6a2ac59
--- /dev/null
+++ b/doc/rfc/rfc7380.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           J. Tong
+Request for Comments: 7380                                    C. Bi, Ed.
+Category: Standards Track                                  China Telecom
+ISSN: 2070-1721                                                  R. Even
+                                                              Q. Wu, Ed.
+                                                                R. Huang
+                                                                  Huawei
+                                                           November 2014
+
+
+    RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2
+ Transport Stream (TS) Program Specific Information (PSI) Decodability
+                      Statistics Metrics Reporting
+
+Abstract
+
+   An MPEG2 Transport Stream (TS) is a standard container format used in
+   the transmission and storage of multimedia data.  Unicast/multicast
+   MPEG2 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 MPEG2 TS decodability statistics metrics
+   related to transmissions of MPEG2 TS over RTP.  The metrics specified
+   in the RTCP XR block are related to Program Specific Information
+   (PSI) carried in MPEG 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/rfc7380.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tong, et al.                 Standards Track                    [Page 1]
+
+RFC 7380                 RTCP XR TS Decodability           November 2014
+
+
+Copyright Notice
+
+   Copyright (c) 2014 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. MPEG2 Transport Stream Decodability Metrics ................3
+      1.2. RTCP and RTCP XR Reports ...................................3
+      1.3. Performance Metrics Framework ..............................3
+      1.4. Applicability ..............................................3
+   2. Terminology .....................................................4
+      2.1. Standards Language .........................................4
+   3. MPEG2 TS PSI Decodability Statistics Metrics Block ..............4
+   4. SDP Signaling ...................................................8
+      4.1. SDP rtcp-xr-attrib Attribute Extension .....................8
+      4.2. Offer/Answer Usage .........................................8
+      4.3. Usage Outside of Offer/Answer ..............................8
+   5. IANA Considerations .............................................9
+      5.1. New RTCP XR Block Type Value ...............................9
+      5.2. New RTCP XR SDP Parameter ..................................9
+      5.3. Contact Information for Registrations ......................9
+   6. Security Considerations .........................................9
+   7. References ......................................................9
+      7.1. Normative References .......................................9
+      7.2. Informative References ....................................10
+  Authors' Addresses .................................................11
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tong, et al.                 Standards Track                    [Page 2]
+
+RFC 7380                 RTCP XR TS Decodability           November 2014
+
+
+1.  Introduction
+
+1.1.  MPEG2 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 MPEG2 Transport Streams [ISO-IEC.13818-1.2007].  The
+   tests and corresponding indicators are grouped according to priority:
+
+   First priority:  Necessary for decodability (basic monitoring)
+
+   Second priority:  Recommended for continuous or periodic monitoring
+
+   Third priority:  Recommended for application-dependent monitoring
+
+   This memo defines a new block type for use with MPEG2 Transport
+   Streams [ISO-IEC.13818-1.2007] to augment those defined in [RFC3611].
+   The new block type supports reporting of the number of occurrences of
+   each Program Specific Information (PSI) indicator in the first and
+   second priorities listed in Sections 5.2.1 and 5.2.2, respectively,
+   of [ETSI].  The third priority indicators are not supported.  The
+   metrics defined here supplement information from the PSI-Independent
+   Decodability Statistics Metrics Block [RFC6990].
+
+1.2.  RTCP and RTCP XR Reports
+
+   The use of RTCP for reporting is defined in [RFC3550].  [RFC3611]
+   defines 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 Architectures [RFC6792] provides guidelines for RTCP XR
+   block formats.  The new report block described in this memo is in
+   compliance with the monitoring architecture specified in [RFC6792]
+   and the Performance Metrics Framework [RFC6390].
+
+1.4.  Applicability
+
+   These metrics are applicable to any type of RTP application that uses
+   the MPEG2 TS standard format for multimedia data, for example, MPEG4
+   over MPEG2 TS over RTP.  This new block type can be useful for
+   measuring content stream or TS quality by checking TS header
+   information [ETSI] and identifying the existence (and characterizing
+
+
+
+Tong, et al.                 Standards Track                    [Page 3]
+
+RFC 7380                 RTCP XR TS Decodability           November 2014
+
+
+   the severity) of bitstream packetization problems that may affect
+   users' perception of a service delivered over RTP.  It may also be
+   useful for verifying the continued correct operation of an existing
+   system management tool.
+
+2.  Terminology
+
+2.1.  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.  MPEG2 TS PSI Decodability Statistics Metrics Block
+
+   ETSI TR 101 290 [ETSI] generally defines indicators related to error
+   events whereas the XR block defined in this document contains counts
+   of occurrences of the [ETSI] indicators.  The block defined in this
+   document reports MPEG2 TS PSI decodability statistics metrics beyond
+   the information carried in the standard RTCP packet format and PSI-
+   Independent Decodability Statistics Metrics Block [RFC6990], which
+   are measured at the receiving end of the RTP stream.  It contains
+   counts of seven metrics defined in ETSI TR 101 290 [ETSI].
+   Information is reported about basic monitoring parameters necessary
+   to ensure that the TS can be decoded, including:
+
+   o  Program Association Table (PAT) errors
+
+   o  PAT2 errors
+
+   o  Program Map Table (PMT) errors
+
+   o  PMT2 errors
+
+   o  Packet Identifier (PID) errors
+
+   Information is also reported about continuous monitoring parameters
+   necessary to ensure continuous decoding, including:
+
+   o  Cyclic Redundancy Check (CRC) errors
+
+   o  Conditional Access Table (CAT) errors
+
+   In these parameters, PAT2 errors and PMT2 errors are actually
+   replacements for and improvements on PAT errors and PMT errors,
+   respectively, and are therefore preferred in future implementations.
+   In addition, measurement results for some of these parameters (e.g.,
+   PAT errors or PMT errors) may be different based on whether
+
+
+
+Tong, et al.                 Standards Track                    [Page 4]
+
+RFC 7380                 RTCP XR TS Decodability           November 2014
+
+
+   scrambling is employed.  The other parameters defined in Section 5 of
+   [ETSI] are ignored since they do not apply to all MPEG2
+   implementations.  For further detailed information on these
+   parameters, see [ETSI].
+
+   The MPEG2 TS PSI Decodability 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=32    |    Reserved   |         block length          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                     SSRC of source                            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          begin_seq            |             end_seq           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        PAT_error_count        |      PAT_error_2_count        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        PMT_error_count        |      PMT_error_2_count        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |       PID_error_count         |      CRC_error_count          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        CAT_error_count        |        Reserved               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   block type (BT): 8 bits
+
+      The MPEG2 TS PSI Decodability Metrics Block is identified by the
+      constant 32;.
+
+   Reserved: 8 bits
+
+      These bits are reserved.  They MUST be set to zero by senders
+      ignored by receivers (see Section 4.2 of [RFC6709]).
+
+   block length: 16 bits
+
+      The constant 6, in accordance with the definition of this field in
+      Section 3 of [RFC3611].  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 [RFC3611].
+
+   begin_seq: 16 bits
+
+      As defined in Section 4.1 of [RFC3611].
+
+
+
+Tong, et al.                 Standards Track                    [Page 5]
+
+RFC 7380                 RTCP XR TS Decodability           November 2014
+
+
+   end_seq: 16 bits
+
+      As defined in Section 4.1 of [RFC3611].
+
+   PAT_error_count: 16 bits
+
+      A count of the number of PAT errors that occurred in the above
+      sequence number interval.  The Program Association Table (PAT) is
+      the only packet with Packet Identifier (PID) 0x0000.  A PAT error
+      occurs when (1) a packet with PID 0x0000 does not occur at least
+      every 0.5 seconds, (2) a packet with PID 0x0000 does not contain
+      table_id 0x00 (i.e., a PAT), or (3) the Scrambling_control_field
+      in the TS packet header is not 00 for a packet with PID 0x0000.
+      See Section 5.2.1 of [ETSI].  Every program within the MPEG TS
+      stream is listed in the PAT; if it is missing, then no programs
+      can be decoded.
+
+      The measured value is an unsigned value.  If the measurement is
+      unavailable, then the value 0xFFFF MUST be reported.  NOTE 1 of
+      the table in Section 5.2.1 of [ETSI] recommends using
+      PAT_error_2_count.  Upon reception, if PAT_error_2_count is
+      available (that is, other than 0xFFFF), then receivers MUST ignore
+      PAT_error_count.
+
+   PAT_error_2_count: 16 bits
+
+      A count of the number of PAT2 errors that occurred in the above
+      sequence number interval.  A PAT2 error occurs when (1) a packet
+      with PID 0x0000 containing table_id 0x00 does not occur at least
+      every 0.5 seconds, (2) a packet with PID 0x0000 contains a table
+      with a table_id other than 0x00, or (3) the
+      Scrambling_control_field in the TS packet header is not 00 for a
+      packet with PID 0x0000.  See Section 5.2.1 of [ETSI].
+
+      The measured value is an unsigned value.  If the measurement is
+      unavailable, then the value 0xFFFF MUST be reported.
+
+   PMT_error_count: 16 bits
+
+      A count of the number of PMT errors that occurred in the above
+      sequence number interval.  A PMT_error occurs when (1) a packet
+      containing a table with table_id 0x02 (i.e., a PMT) does not occur
+      at least every 0.5 seconds on the PID that is referred to in the
+      PAT or (2) the Scrambling_control_field in the TS packet header is
+      not 00 for all packets with PID containing a table with table_id
+      0x02 (i.e., a PMT).  See Section 5.2.1 of [ETSI].
+
+
+
+
+
+Tong, et al.                 Standards Track                    [Page 6]
+
+RFC 7380                 RTCP XR TS Decodability           November 2014
+
+
+      The measured value is an unsigned value.  If the measurement is
+      unavailable, the value 0xFFFF MUST be reported.  NOTE 2 of the
+      table in Section 5.2.1 of [ETSI] recommends using
+      PMT_error_2_count.  Upon reception, if PMT_error_2_count is
+      available (that is, other than 0xFFFF), then receivers MUST ignore
+      PMT_error_count.
+
+   PMT_error_2_count: 16 bits
+
+      A count of the number of PMT2 errors that occurred in the above
+      sequence number interval.  A PMT2_error occurs when (1) a packet
+      containing table_id 0x02 (i.e., a PMT) does not occur at least
+      every 0.5 seconds on each program_map_PID that is referred to in
+      the PAT or (2) the Scrambling_control_field in the TS packet
+      header is not 00 for all packets containing a table with table_id
+      0x02 (i.e., a PMT) on each program_map_PID that is referred to in
+      the PAT.  See Section 5.2.1 of [ETSI].
+
+      The measured value is an unsigned value.  If the measurement is
+      unavailable, then the value 0xFFFF MUST be reported.
+
+   PID_error_count: 16 bits
+
+      A count of the number of PID errors that occurred in the above
+      sequence number interval.  A PID error occurs when no data stream
+      is present corresponding to a given PID.  This may be caused by
+      multiplexing or demultiplexing, then remultiplexing.  See
+      Section 5.2.1 of [ETSI].
+
+      The measured value is an unsigned value.  If the measurement is
+      unavailable, then the value 0xFFFF MUST be reported.
+
+   CRC_error_count: 16 bits
+
+      A count of the number of CRC errors that occurred in the above
+      sequence number interval.  A CRC_error occurs if data corruption
+      occurred in any of the following tables -- CAT, PAT, PMT, Network
+      Information Table (NIT), Event Information Table (EIT), Bouquet
+      Association Table (BAT), Service Description Table (SDT), or Time
+      Offset Table (TOT), as defined in Section 5.2.2 of [ETSI].
+
+      The measured value is an unsigned value.  If the measurement is
+      unavailable, then the value 0xFFFF MUST be reported.
+
+
+
+
+
+
+
+
+Tong, et al.                 Standards Track                    [Page 7]
+
+RFC 7380                 RTCP XR TS Decodability           November 2014
+
+
+   CAT_error_count: 16 bits
+
+      A count of the number of CAT errors that occurred in the above
+      sequence number interval.  A CAT_error occurs when (1) a packet
+      with PID 0x0001 contains a table with a table_id other than 0x01
+      (i.e., not a CAT) or (2) a packet does not contain a table with
+      table_id = 0x01 (i.e., a CAT) when scrambling is employed (i.e.,
+      the Scrambling_control_field is set as a value other than 00).
+      See Section 5.2.2 of [ETSI].
+
+      The measured value is an unsigned value.  If the measurement is
+      unavailable, then the value 0xFFFF MUST be reported.
+
+   Reserved: 16 bits
+
+      These bits are reserved.  They MUST be set to zero by senders
+      ignored by receivers (see Section 4.2 of [RFC6709]).
+
+4.  SDP Signaling
+
+   [RFC3611] 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
+   [RFC3611]).
+
+4.1.  SDP rtcp-xr-attrib Attribute Extension
+
+   This session augments the SDP attribute "rtcp-xr" defined in
+   Section 5.1 of [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-tpd-block
+
+   xr-tpd-block = "ts-psi-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].
+
+4.3.  Usage Outside of Offer/Answer
+
+   For usage outside of Offer/Answer, refer to Section 5.3 of [RFC3611].
+
+
+
+
+
+Tong, et al.                 Standards Track                    [Page 8]
+
+RFC 7380                 RTCP XR TS Decodability           November 2014
+
+
+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 [RFC3611].
+
+5.1.  New RTCP XR Block Type Value
+
+   This document assigns the block type value 32 "MPEG2 Transport Stream
+   PSI Decodability Statistics Metrics Block" in the "RTCP XR Block
+   Type" subregistry of the IANA "RTP Control Protocol Extended Reports
+   (RTCP XR) Block Type Registry".
+
+5.2.  New RTCP XR SDP Parameter
+
+   This document also registers a new parameter "ts-psi-decodability" in
+   the "RTCP XR SDP Parameters" subregistry of the "RTP Control Protocol
+   Extended Reports (RTCP XR) Session Description Protocol (SDP)
+   Parameters Registry".
+
+5.3.  Contact Information for Registrations
+
+   The contact information for the registrations is:
+
+   RAI Area Directors <rai-ads@tools.ietf.org>
+
+6.  Security Considerations
+
+   This proposed RTCP XR block introduces no new security considerations
+   beyond those described in [RFC3611] and [RFC6990].
+
+7.  References
+
+7.1.  Normative References
+
+   [ETSI]     ETSI, "Digital Video Broadcasting (DVB); Measurement
+              guidelines for DVB systems", ETSI TR 101 290, June 2014.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3550]  Schulzrinne, H., "RTP: A Transport Protocol for Real-Time
+              Applications", RFC 3550, July 2003,
+              <http://www.rfc-editor.org/info/rfc3550>.
+
+
+
+
+
+
+Tong, et al.                 Standards Track                    [Page 9]
+
+RFC 7380                 RTCP XR TS Decodability           November 2014
+
+
+   [RFC3611]  Friedman, T., Caceres, R., and A. Clark, "RTP Control
+              Protocol Extended Reports (RTCP XR)", RFC 3611, November
+              2003, <http://www.rfc-editor.org/info/rfc3611>.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, July 2006,
+              <http://www.rfc-editor.org/info/rfc4566>.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008,
+              <http://www.rfc-editor.org/info/rfc5234>.
+
+7.2.  Informative References
+
+   [ISO-IEC.13818-1.2007]
+              ISO/IEC, "Information technology - Generic coding of
+              moving pictures and associated audio information - Part 1:
+              Systems", ISO International Standard 13818-1, 2013.
+
+   [RFC6390]  Clark, A. and B. Claise, "Guidelines for Considering New
+              Performance Metric Development", BCP 170, RFC 6390,
+              October 2011, <http://www.rfc-editor.org/info/rfc6390>.
+
+   [RFC6709]  Carpenter, B., Aboba, B., and S. Cheshire, "Design
+              Considerations for Protocol Extensions", RFC 6709,
+              September 2012, <http://www.rfc-editor.org/info/rfc6709>.
+
+   [RFC6792]  Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the
+              RTP Monitoring Framework", RFC 6792, November 2012,
+              <http://www.rfc-editor.org/info/rfc6792>.
+
+   [RFC6990]  Wu, Q., "RTP Control Protocol (RTCP) Extended Report (XR)
+              Block for MPEG2 Transport Stream (TS) Program Specific
+              Information (PSI) Independent Decodability Statistics
+              Metrics reporting", RFC 6990, May 2013,
+              <http://www.rfc-editor.org/info/rfc6990>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tong, et al.                 Standards Track                   [Page 10]
+
+RFC 7380                 RTCP XR TS Decodability           November 2014
+
+
+Authors' Addresses
+
+   Jiangang Tong
+   Shanghai Research Institute of China Telecom Corporation Limited
+   No. 1835, South Pudong Road
+   Shanghai  200122
+   China
+
+   EMail: tongjg@sttri.com.cn
+
+
+   Claire Bi (editor)
+   Shanghai Research Institure of China Telecom Corporation Limited
+   No. 1835, South Pudong Road
+   Shanghai  200122
+   China
+
+   EMail: bijy@sttri.com.cn
+
+
+   Roni Even
+   Huawei
+   14 David Hamelech
+   Tel Aviv  64953
+   Israel
+
+   EMail: roni.even@mail01.huawei.com
+
+
+   Qin Wu (editor)
+   Huawei
+   101 Software Avenue, Yuhua District
+   Nanjing, Jiangsu  210012
+   China
+
+   EMail: bill.wu@huawei.com
+
+
+   Rachel Huang
+   Huawei
+   101 Software Avenue, Yuhua District
+   Nanjing, Jiangsu  210012
+   China
+
+   EMail: rachel.huang@huawei.com
+
+
+
+
+
+
+Tong, et al.                 Standards Track                   [Page 11]
+