idnits 2.17.1 draft-ietf-avt-rtcpxr-mpts-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 257. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 268. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 281. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2008) is 5943 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) == Unused Reference: '1' is defined on line 219, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 222, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 226, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force A. Clark 2 Internet-Draft Telchemy Incorporated 3 Expires: 4th January 2008 4 July 2007 6 RTCP XR - MPEG Transport Metrics Report Block 7 draft-ietf-avt-rtcpxr-mpts-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on 4th January 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document defines an extension to the RTCP XR extended report 41 packet type blocks to support the monitoring of video over IP 42 and the associated audio streams, if present, for video encapsulated 43 in MPEG Transport carried over RTP. 44 [Note: this draft contains the MPEG transport metrics that were 45 formerly in the draft-ietf-avt-rtcpxr-video-00.txt draft, which has 46 now been divided into four drafts] 48 Clark [Page 1] 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. MPEG Transport Metrics Report Block . . . . . . . . . . . . 3 54 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 5. Security Considerations . . . . . . . . . . . . . . . . . . 5 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 5 57 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 58 8. Informative References . . . . . . . . . . . . . . . . . . . 5 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 60 Intellectual Property and Copyright Statements . . . . . . . 62 1. Introduction 64 This draft defines a new block type to augment those defined 65 in RFC3611 for use in Quality of Service reporting for video over IP. 66 The new block type defined in this draft is the MPEG Transport 67 Metrics Report Block. It is intended to support both the 68 identification of problems affecting performance and the collection 69 of data that may be useful in optimizing system configuration. 71 The metrics defined in this document are based on terminology and 72 error events described in ETSI TR 101 290 [5] that relate to MPEG 73 Transport packets. The metrics that define summaries and counts 74 of these error events are based on work within the ATIS IIF QoSM 75 Working group [4] (Author's note, this is expected to be a published 76 ATIS standard by Q3, 2007). 78 2. Definitions 80 2.1 MPEG-2 Transport Protocol 82 The MPEG-2 Transport Protocol is a simple encapsulation of video 83 or audio data into fixed length packets with a header. MPEG-2 84 Transport packets are often multiplexed and may be carried over 85 RTP or directly over UDP. 87 Clark [Page 2] 88 3 Video Metrics Report Block 90 3.1 Block Description 92 MPEG Transport Metrics 94 0 1 2 3 95 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 96 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 97 | BT=N | | block length | 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | SSRC of source | 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 |0 0 0| Program ID | Reserved | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | Report Timestamp | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | Measurement Interval (ms) | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | Continuity Error Count | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | TS Sync Loss Error Count | Sync Byte Error Count | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | PSI Error Count | PID Error Count | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | PCR Jitter | PCR Failure Count | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 3.2.1 Header 117 The header comprises: 118 (i) Block Type for this report block 119 (ii) Reserved (set to 0xFF) 120 (iii) Block length in words (set to 0x0008) 121 (iv) SSRC of the received RTP stream that this report refers to 122 (v) Program ID (PID) for the audio or video stream to which 123 this report relates 124 (vi) Reserved (set to 0xFFFF) 126 3.2.2 Report Timestamp 127 The time at which this report was generated (format?) 129 3.2.3 Measurement Interval 130 The interval of time over which these metrics were measured, 131 expressed in milliseconds. 133 3.2.4 Continuity Error Count 134 A count of the number of Continuity_count_errors (as defined in 135 TR 101 290 [5]). This count shall not be reset if the maximum 136 value is reached. 138 Clark [Page 3] 139 Continuity count errors are defined as out-of-sequence, duplicate 140 and lost packets. 142 3.2.5 TS Sync Loss Count 143 A count of the number of TS_sync_loss errors (as defined in 144 TR 101 290 [5]). This count shall not be reset if the maximum 145 value is reached. 147 TS sync loss errors are defined as a loss of sychronization 148 by the transport stream. 150 3.2.6 Sync Byte Error Count 151 A count of the number of Sync_byte_error errors (as defined in 152 TR 101 290 [5]). This count shall not be reset if the maximum 153 value is reached. 155 Sync byte errors are defined as the value 0x47 not being 156 present as the first byte of the MPEG transport header. 158 3.2.7 PSI Error Count 159 A count of the number of PSI (Program Specific Information) errors. 160 This count shall not be reset if the maximum value is reached. 162 PSR errors are defined (in [4]) as TR 101 290 PAT and PMT errors 163 including PAT_error, PAT_error_2, PMT_error, PMT_error_2, CRC 164 error on PAT or PMT. 166 3.2.8 PID Error Count 167 A count of the number of PID_errors (as defined in TR 101 290 [5]). 168 This count shall not be reset if the maximum value is reached. 170 A PID error is the condition that a packet with the specified PID 171 has not occurred for a specified threshold period of time. 173 3.2.9 PCR Jitter 174 The PCR Overall Jitter, as defined in TR 101 290 [5] expressed in 175 microseconds. 177 Video systems that do not rely on the accuracy of the PCR clock 178 MAY set this value to 0. 180 3.2.10 PCR Failure Count 181 A count of the number of PCR failures. This count shall not be reset 182 if the maximum value is reached. 184 PCR failures are defined as TR 101 290 PCR_error, PCR_repitition_ 185 error, PCR_discontinuity_indicator_error, PCR_accuracy_error. 187 Video systems that do not rely on the accuracy of the PCR clock 188 MAY set this value to 0. 190 Clark [Page 4] 191 4. Summary 193 This draft defines an RTCP XR report block for MPEG Transport, for 194 use in video quality reporting. This is intended for in-service 195 monitoring of video streaming, IPTV and IP videoconferencing 196 services to provide real time performance feedback and support 197 performance management. 199 5. IANA Considerations 201 The block type "mmm" will need to be replaced with an IANA assigned 202 number within those allocated for RTCP XR report blocks (RFC 3611). 204 6. Security Considerations 206 RTCP reports can contain sensitive information since they can provide 207 information about the nature and duration of a session established 208 between two endpoints. As a result, any third party wishing to 209 obtain this information should be properly authenticated and the 210 information transferred securely. 212 7. Acknowledgments 214 The metrics in this draft are based on work performed in the ATIS 215 IIF QoSM WG. 217 8. Informative References 219 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 220 Levels", BCP 14, RFC 2119, March 1997. 222 [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 223 "RTP: A Transport Protocol for Real-Time Applications", STD 64, 224 RFC 3550, July 2003. 226 [3] Friedman, T., Caceres, R. and A. Clark, "RTP Control Protocol 227 Extended Reports (RTCP XR)", RFC 3611, November 2003. 229 [4] ATIS IIF [TBD], QoS Metrics for Linear Broadcast. 231 [5] ETSI TR 101 290, Digital Video Broadcasting (DVB); Measurement 232 guidelines for DVB Systems 234 Authors' Addresses 236 Alan Clark 237 Telchemy Incorporated 238 2905 Premiere Parkway, Suite 280 239 Duluth, GA 30097 240 Email: alan@telchemy.com 242 Clark [Page 5] 243 Full Copyright Statement 245 Copyright (C) The IETF Trust (2007). 247 This document is subject to the rights, licenses and restrictions 248 contained in BCP 78, and except as set forth therein, the authors 249 retain all their rights. 251 This document and the information contained herein are provided on an 252 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 253 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 254 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 255 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 256 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 257 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 259 Intellectual Property 261 The IETF takes no position regarding the validity or scope of any 262 Intellectual Property Rights or other rights that might be claimed to 263 pertain to the implementation or use of the technology described in 264 this document or the extent to which any license under such rights 265 might or might not be available; nor does it represent that it has 266 made any independent effort to identify any such rights. Information 267 on the procedures with respect to rights in RFC documents can be 268 found in BCP 78 and BCP 79. 270 Copies of IPR disclosures made to the IETF Secretariat and any 271 assurances of licenses to be made available, or the result of an 272 attempt made to obtain a general license or permission for the use of 273 such proprietary rights by implementers or users of this 274 specification can be obtained from the IETF on-line IPR repository at 275 http://www.ietf.org/ipr. 277 The IETF invites any interested party to bring to its attention any 278 copyrights, patents or patent applications, or other proprietary 279 rights that may cover technology that may be required to implement 280 this standard. Please address the information to the IETF at ietf- 281 ipr@ietf.org. 283 Acknowledgement 285 Funding for the RFC Editor function is provided by the IETF 286 Administrative Support Activity (IASA). 288 Clark [Page 6]