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