diff options
Diffstat (limited to 'doc/rfc/rfc7380.txt')
| -rw-r--r-- | doc/rfc/rfc7380.txt | 619 |
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] + |