idnits 2.17.1 draft-ietf-xrblock-rtcp-xr-psi-decodability-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 10, 2014) is 3518 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ETSI' ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Tong 3 Internet-Draft C. Bi, Ed. 4 Intended status: Standards Track China Telecom 5 Expires: February 11, 2015 R. Even 6 Gesher Erove Ltd 7 Q. Wu, Ed. 8 R. Huang 9 Huawei 10 August 10, 2014 12 RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 13 Transport Stream (TS) Program Specific Information (PSI) Decodability 14 Statistics Metrics reporting 15 draft-ietf-xrblock-rtcp-xr-psi-decodability-07 17 Abstract 19 An MPEG2 Transport Stream (TS) is a standard container format used in 20 the transmission and storage of multimedia data. Unicast/Multicast 21 MPEG2 TS over RTP is widely deployed in IPTV systems. This document 22 defines an RTP Control Protocol (RTCP) Extended Report (XR) Block 23 that allows the reporting of MPEG2 TS decodability statistics metrics 24 related to transmissions of MPEG2 TS over RTP. The metrics specified 25 in the RTCP XR Block are related to Program Specific Information 26 carried in MPEG TS. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on February 11, 2015. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. MPEG2 Transport Stream Decodability Metrics . . . . . . . 2 64 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . 3 65 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 3 66 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1. Standards Language . . . . . . . . . . . . . . . . . . . 4 69 3. MPEG2 TS PSI Decodability Statistics Metrics Block . . . . . 4 70 4. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. SDP rtcp-xr-attrib Attribute Extension . . . . . . . . . 8 72 4.2. Offer/Answer Usage . . . . . . . . . . . . . . . . . . . 8 73 4.3. Usage Outside of Offer/Answer . . . . . . . . . . . . . . 8 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 5.1. New RTCP XR Block Type value . . . . . . . . . . . . . . 8 76 5.2. New RTCP XR SDP Parameter . . . . . . . . . . . . . . . . 9 77 5.3. Contact information for registrations . . . . . . . . . . 9 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 7.2. Informative References . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 1.1. MPEG2 Transport Stream Decodability Metrics 88 The European Telecommunications Standards Institute (ETSI) has 89 defined a set of syntax and information consistency tests and 90 corresponding indicators [ETSI] that are recommended for the 91 monitoring of MPEG2 Transport Streams [ISO-IEC.13818-1.2007]. The 92 tests and corresponding indicators are grouped according to priority: 94 o First priority - Necessary for decodability (basic monitoring) 95 o Second priority - Recommended for continuous or periodic 96 monitoring 97 o Third priority - Recommended for application-dependent monitoring 99 This memo defines a new block type for use with MPEG2 Transport 100 Stream (TS) [ISO-IEC.13818-1.2007], to augment those defined in 101 [RFC3611]. The new block type supports reporting of the number of 102 occurrences of each Program Specific Information (PSI) indicator in 103 the first and second priorities listed by [ETSI] sections 5.2.1 and 104 5.2.2 respectively. Third priority indicators are not supported. 105 The metrics defined here supplement information from the PSI- 106 independent Decodability Statistics Metrics Block [RFC6990]. 108 1.2. RTCP and RTCP XR Reports 110 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 111 defines an extensible structure for reporting using an RTCP Extended 112 Report (XR). This document defines a new Extended Report block for 113 use with [RFC3550] and [RFC3611]. 115 1.3. Performance Metrics Framework 117 The Performance Metrics Framework [RFC6390] provides guidance on the 118 definition and specification of performance metrics. The RTP 119 Monitoring Architectures [RFC6792] provides guidelines for RTCP XR 120 reporting block formats. The new report block described in this memo 121 is in compliance with the monitoring architecture specified in 122 [RFC6792] and the Performance Metrics Framework [RFC6390]. 124 1.4. Applicability 126 These metrics are applicable to any type of RTP application that uses 127 the MPEG2 TS standard format for multimedia data, for example, MPEG4 128 over MPEG2 TS over RTP. This new block type can be useful for 129 measuring content stream or TS quality by checking TS header 130 information [ETSI] and identifying the existence, and characterizing 131 the severity, of bitstream packetization problems which may affect 132 users' perception of a service delivered over RTP. It may also be 133 useful for verifying the continued correct operation of an existing 134 system management tool. 136 2. Terminology 137 2.1. Standards Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [RFC2119]. 143 3. MPEG2 TS PSI Decodability Statistics Metrics Block 145 ETSI TR 101290 [ETSI] generally defines indicators related to error 146 events, while the XR block defined in this document contains counts 147 of occurrences of the [ETSI] indicators. The block defined in this 148 document reports MPEG2 TS PSI decodability statistics metrics beyond 149 the information carried in the standard RTCP packet format and PSI- 150 independent Decodability Metrics Block [RFC6990], which are measured 151 at the receiving end of the RTP stream. It contains counts of seven 152 metrics defined in ETSI TR 101290 [ETSI]. Information is reported 153 about basic monitoring parameters necessary to ensure that the TS can 154 be decoded including: 156 o Program Association Table (PAT) errors 157 o PAT 2 errors 158 o Program Map Table (PMT) errors 159 o PMT 2 errors 160 o Packet Identifier (PID) errors 162 and continuous monitoring parameters necessary to ensure the 163 continuous decoding including: 165 o Cyclic Redundancy Check (CRC) errors 166 o Conditional Access Table (CAT) errors 168 In these parameters, PAT 2 errors and PMT 2 errors are actually 169 replacements for and improvements on PAT errors and PMT errors 170 respectively and are therefore preferred in future implementations. 171 In addition, measurement results for some of these parameters (e.g., 172 PAT errors or PMT errors) may be different based on whether 173 scrambling is employed. The other parameters defined in [ETSI] 174 Section 5 are ignored since they do not apply to all MPEG2 175 implementations. For further detailed information on these 176 parameters, see [ETSI]. 178 The MPEG2 TS PSI Decodability Metrics Block has the following format: 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | BT=MTPD | Reserved | block length | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | SSRC of source | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | begin_seq | end_seq | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | PAT_error_count | PAT_error_2_count | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | PMT_error_count | PMT_error_2_count | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | PID_error_count | CRC_error_count | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | CAT_error_count | Reserved | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 block type (BT): 8 bits 200 The MPEG2 TS PSI Decodability Metrics Block is identified by the 201 constant . 203 Reserved: 8 bits 205 These bits are reserved. They MUST be set to zero by senders 206 ignored by receivers (See [RFC6709] section 4.2). 208 block length: 16 bits 210 The constant 6, in accordance with the definition of this field in 211 Section 3 of RFC 3611. The block MUST be discarded if the block 212 length is set to a different value. 214 SSRC of source: 32 bits 216 As defined in Section 4.1 of RFC 3611. 218 begin_seq: 16 bits 220 As defined in Section 4.1 of RFC 3611. 222 end_seq: 16 bits 224 As defined in Section 4.1 of RFC 3611. 226 PAT_error_count: 16 bits 227 A count of the number of PAT errors that occurred in the above 228 sequence number interval. The program association table (PAT) is 229 the only packet with packet ID (PID) 0x 0000. A PAT error occurs 230 when: (1) a packet with PID 0x0000 does not occur at least every 231 0.5 seconds, or (2) a packet with PID 0x0000 does not contain a 232 table_id 0x00 (i.e., a PAT), or (3)Scrambling_control_field in the 233 TS packet header is not 00 for a packet with PID 0x0000. See 234 section 5.2.1 of [ETSI]. Every program within the MPEG TS stream 235 is listed in the PAT; if it is missing, then no programs can be 236 decoded. 238 The measured value is unsigned value. If the measurement is 239 unavailable, the value 0xFFFF MUST be reported. As indicated in 240 the NOTE 1 of the table in the section 5.2.1 of TR101.290, TR 241 101.290 recommends using PAT_error_2_count. Upon reception, If 242 PAT_error_2_count is available (that is, other than 0xFFFF), then 243 receivers MUST ignore PAT_error_count. 245 PAT_error_2_count: 16 bits 247 A count of the number of PAT2 errors that occurred in the above 248 sequence number interval. A PAT2 error occurs when: (1) a packet 249 with PID 0x0000 containing table_id 0x00 does not occur at least 250 every 0.5 seconds,or (2) a packet with PID 0x0000 contains a table 251 with table_id other than 0x00, or (3) Scrambling_control_field in 252 the TS packet header is not 00 for a packet with PID 0x0000. See 253 section 5.2.1 of [ETSI]. 255 The measured value is unsigned value. If the measurement is 256 unavailable, the value 0xFFFF MUST be reported. 258 PMT_error_count: 16 bits 260 A count of the number of PMT_errors that occurred in the above 261 sequence number interval. A PMT_error occurs when: (1) a packet 262 containing a table with table_id 0x02(i.e.,a PMT) does not occur 263 at least every 0.5s on the PID that is referred to in the PAT, 264 or(2) Scrambling_control_field in the TS packet header is not 00 265 for all packets with PID containing a table with table_id 0x02 266 (i.e. a PMT). See the section 5.2.1 of [ETSI]. 268 The measured value is unsigned value. If the measurement is 269 unavailable, the value 0xFFFF MUST be reported. As indicated in 270 the NOTE 2 of table in the section 5.2.1 of TR101.290, TR 101.290 271 recommends using PMT_error_2_count. Upon reception, If 272 PMT_error_2_count is available (that is, other than 0xFFFF), then 273 receivers MUST ignore PMT_error_count. 275 PMT_error_2_count: 16 bits 277 A count of the number of PMT2 errors that occurred in the above 278 sequence number interval. A PMT2_error occurs when: (1) a packet 279 containing table_id 0x02(i.e.,a PMT) does not occur at least every 280 0.5s on each program_map_PID which is referred to in the PAT, or 281 (2) Scrambling_control_field in the TS packet header is not 00 for 282 all packets containing a table with table_id 0x02 (i.e. a PMT) on 283 each program_map_PID which is referred to in the PAT. See section 284 5.2.1 of [ETSI]. 286 The measured value is unsigned value. If the measurement is 287 unavailable, the value 0xFFFF MUST be reported. 289 PID_error_count: 16 bits 291 A count of the number of PID_errors that occurred in the above 292 sequence number interval. A PID error occurs when no data stream 293 is present corresponding to a given PID. This may be caused by 294 multiplexing or demultiplexing, then remultiplexing. See section 295 5.2.1 of [ETSI]. 297 The measured value is unsigned value. If the measurement is 298 unavailable, the value 0xFFFF MUST be reported. 300 CRC_error_count: 16 bits 302 A count of the number of CRC_errors that occurred in the above 303 sequence number interval. A CRC_error occurs if data corruption 304 occurred in any of the following tables -- CAT, PAT, PMT, Network 305 Information Table (NIT), Event Information Table (EIT), Bouquet 306 Association Table (BAT), Service Description Table (SDT) or Time 307 Offset Table (TOT), as defined in the section 5.2.2 of [ETSI]. 309 The measured value is unsigned value. If the measurement is 310 unavailable, the value 0xFFFF MUST be reported. 312 CAT_error_count: 16 bits 314 A count of the number of CAT_errors that occurred in the above 315 sequence number interval. A CAT_error occurs when: (1) a packet 316 with PID 0x0001 contains a table with table_id other than 317 0x01(i.e.,not a CAT), or (2) A packet does not contain a table 318 with table_id = 0x01 (i.e. a CAT) when scrambling is employed 319 ((i.e., scrambling_control field is set as a value other than 320 00)). See the section 5.2.2 of [ETSI]. 322 The measured value is unsigned value. If the measurement is 323 unavailable, the value 0xFFFF MUST be reported. 325 Reserved: 16 bits 327 These bits are reserved. They MUST be set to zero by senders 328 ignored by receivers (See [RFC6709] section 4.2). 330 4. SDP Signaling 332 RFC 3611 defines the use of SDP (Session Description Protocol) 333 [RFC4566] for signaling the use of RTCP XR blocks. However XR blocks 334 MAY be used without prior signaling (See section 5 of RFC3611). 336 4.1. SDP rtcp-xr-attrib Attribute Extension 338 This session augments the SDP attribute "rtcp-xr" defined in 339 Section 5.1 of RFC 3611 by providing an additional value of "xr- 340 format" to signal the use of the report block defined in this 341 document. 343 xr-format =/ xr-tpd-block 345 xr-tpd-block = "ts-psi-decodability" 347 4.2. Offer/Answer Usage 349 When SDP is used in offer-answer context, the SDP Offer/Answer usage 350 defined in [RFC3611] for unilateral "rtcp-xr" attribute parameters 351 applies. For detailed usage of Offer/Answer for unilateral 352 parameter, refer to section 5.2 of [RFC3611]. 354 4.3. Usage Outside of Offer/Answer 356 For usage outside of Offer/Answer,refer to section 5.3 of [RFC3611]. 358 5. IANA Considerations 360 New report block types for RTCP XR are subject to IANA registration. 361 For general guidelines on IANA allocations for RTCP XR, refer to 362 Section 6.2 of RFC 3611. 364 5.1. New RTCP XR Block Type value 366 This document assigns the block type value MTPD in the IANA " RTP 367 Control Protocol Extended Reports (RTCP XR) Block Type Registry " to 368 the "MPEG2 Transport Stream PSI Decodability Statistics Metrics 369 Block". 371 [Note to RFC Editor: please replace MTPD with the IANA provided RTCP 372 XR block type for this block.] 374 5.2. New RTCP XR SDP Parameter 376 This document also registers a new parameter "ts-psi-decodability" in 377 the "RTP Control Protocol Extended Reports (RTCP XR) Session 378 Description Protocol (SDP) Parameters Registry". 380 5.3. Contact information for registrations 382 The contact information for the registrations is: 384 RAI Area Directors 386 6. Security Considerations 388 This proposed RTCP XR report block introduces no new security 389 considerations beyond those described in [RFC3611] [RFC6990]. 391 7. References 393 7.1. Normative References 395 [ETSI] ETSI, "Digital Video Broadcasting (DVB); Measurement 396 guidelines for DVB systems", Technical Report TR 101 290, 397 2001. 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, March 1997. 402 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 403 Applications", RFC 3550, July 2003. 405 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 406 Protocol Extended Reports (RTCP XR)", RFC 3611, November 407 2003. 409 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 410 Description Protocol", RFC 4566, July 2006. 412 7.2. Informative References 414 [ISO-IEC.13818-1.2007] 415 International Organization for Standardization, 416 "Information technology - Generic coding of moving 417 pictures and associated audio information: Systems", ISO 418 International Standard 13818-1, October 2007. 420 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 421 Performance Metric Development", BCP 170, RFC 6390, 422 October 2011. 424 [RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design 425 Considerations for Protocol Extensions", RFC 6709, 426 September 2012. 428 [RFC6792] Wu, Q., Hunt, G., and P. Arden, "Guidelines for Use of the 429 RTP Monitoring Framework", RFC 6792, November 2012. 431 [RFC6990] Wu, Q., "RTP Control Protocol (RTCP) Extended Report (XR) 432 Block for MPEG2 Transport Stream (TS) Program Specific 433 Information (PSI) Independent Decodability Statistics 434 Metrics reporting", RFC 6990, May 2013. 436 Authors' Addresses 438 Jiangang Tong 439 Shanghai Research Institure of China Telecom Corporation Limited 440 No.1835,South Pudong Road 441 Shanghai 200122 442 China 444 Email: tongjg@sttri.com.cn 446 Claire Bi (editor) 447 Shanghai Research Institure of China Telecom Corporation Limited 448 No.1835,South Pudong Road 449 Shanghai 200122 450 China 452 Email: bijy@sttri.com.cn 453 Roni Even 454 Gesher Erove Ltd 455 14 David Hamelech 456 Tel Aviv 64953 457 Israel 459 Email: ron.even.tlv@gmail.com 461 Qin Wu (editor) 462 Huawei 463 101 Software Avenue, Yuhua District 464 Nanjing, Jiangsu 210012 465 China 467 Email: bill.wu@huawei.com 469 Rachel Huang 470 Huawei 471 101 Software Avenue, Yuhua District 472 Nanjing, Jiangsu 210012 473 China 475 Email: rachel.huang@huawei.com