idnits 2.17.1 draft-ietf-avt-rtcp-xr-meas-identity-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 370. 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 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 (October 25, 2008) is 5662 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: 'RFC2119' is defined on line 283, but no explicit reference was found in the text == Unused Reference: 'MONARCH' is defined on line 301, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-02) exists of draft-ietf-avt-rtcp-xr-meas-identity-00 == Outdated reference: A later version (-02) exists of draft-ietf-avt-rtcp-xr-meas-identity-00 -- Duplicate reference: draft-ietf-avt-rtcp-xr-meas-identity, mentioned in 'MPEG2', was also mentioned in 'BASICLOSS'. == Outdated reference: A later version (-12) exists of draft-ietf-pmol-metrics-framework-00 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Audio/Video Transport Working G. Hunt 3 Group BT 4 Internet-Draft A. Clark 5 Intended status: Standards Track Telchemy 6 Expires: April 28, 2009 October 25, 2008 8 RTCP XR Report Block for Measurement Identity 9 draft-ietf-avt-rtcp-xr-meas-identity-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 28, 2009. 36 Abstract 38 This document defines an RTCP XR Report Block carrying parameters 39 which identify a measurement, to which one or more other RTCP XR 40 Report Blocks may refer. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 1.1. Measurement Identity Report Block . . . . . . . . . . . . 3 46 1.2. RTCP and RTCP XR Reports . . . . . . . . . . . . . . . . . 4 47 1.3. Performance Metrics Framework . . . . . . . . . . . . . . 4 48 1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 49 2. Measurement Identity Block . . . . . . . . . . . . . . . . . . 5 50 2.1. Report Block Structure . . . . . . . . . . . . . . . . . . 5 51 2.2. Definition of Fields in Measurement Identity Report 52 Block . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 8 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 56 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 57 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 58 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 60 Intellectual Property and Copyright Statements . . . . . . . . . . 13 62 1. Introduction 64 1.1. Measurement Identity Report Block 66 This draft defines a new block type to augment those defined in 67 [RFC3611] for use in a range of RTP applications. This block type 68 does not itself contain any measurement results (metrics). However, 69 this new block type provides information relevant to a measurement 70 reported in one or more other block types, including 72 o a tag or key by which other blocks (containing metrics 73 information) may refer to this block 75 o the SSRC of the measured stream, 77 o a field for incorporation of an application-specific auxiliary 78 identifier, 80 o the extended sequence numbers of the first packet of the RTP 81 session, the first packet of the current measurement interval, and 82 the last packet included in the measurement, 84 o the duration of the most recent measurement interval and 86 o the duration of the interval applicable to cumulative measurements 87 (which may be the duration of the RTP session to date). 89 The method for calculation of the extended RTP sequence number is 90 provide in [RFC3550]. 92 This block is intended to provide a single copy of the information 93 necessary to relate measurement data in other blocks to the stream, 94 and measurement period, to which they refer. Commonly, multiple 95 other small blocks contain measurement data for the same stream and 96 period, and it would be a large overhead if all of these blocks 97 carried duplicated data for measurement identification. Other blocks 98 make a reference to this block (by tag). 100 A Measurement Identity block is associated with the set of RTCP XR 101 metrics blocks which share its tag value. There MAY be several such 102 sets in an RTCP packet, up to a limit of 8 arising from the use of 103 3-bit tags. There MAY also be RTCP XR blocks in the packet which are 104 not associated with a Measurement Identity block, for example blocks 105 which were defined before the Measurement Identity mechanism was 106 introduced by this document. 108 1.2. RTCP and RTCP XR Reports 110 The use of RTCP for reporting is defined in [RFC3550]. [RFC3611] 111 defined an extensible structure for reporting using an RTCP Extended 112 Report (XR). This draft defines a new Extended Report block that 113 MUST be used as defined in [RFC3550] and [RFC3611]. 115 1.3. Performance Metrics Framework 117 The Performance Metrics Framework [PMOLFRAME] provides guidance on 118 the definition and specification of performance metrics. Metrics 119 described in this draft either reference external definitions or 120 define metrics generally in accordance with the guidelines in 121 [PMOLFRAME]. 123 1.4. Applicability 125 This block provides identification information for members of a 126 family of RTCP XR metrics blocks which are designed to use it. To 127 use the mechanism defined here, a metrics block must be in the same 128 RTCP packet as the Measurement Identity block and must refer to the 129 Measurement Identity block via the 3-bit tag field defined below. 131 2. Measurement Identity Block 133 2.1. Report Block Structure 135 0 1 2 3 136 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 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | BT=NMI |0| tag | fwd | block length = 7 | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | SSRC of stream source | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | sub-identifier | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | extended first sequence number (cumulative) | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | extended first sequence number of interval | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | extended last sequence number | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Measurement Duration (Cumulative) (ms) | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Measurement Duration (Interval) (ms) | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 Figure 1: Report Block Structure 157 2.2. Definition of Fields in Measurement Identity Report Block 159 Bits shown as '0' in the figure SHOULD be set to zero. 161 block type (BT): 8 bits 163 A Measurement Identity Report Block is identified by the constant 164 NMI. 166 [Note to RFC Editor: please replace NMI with the IANA provided RTCP 167 XR block type for this block.] 169 tag: 3 bits 171 This field is a tag or key which identifies this Measurement 172 Identity block within the scope of an RTCP packet. If an RTCP 173 packet contains more than one Measurement Identity block, each 174 Measurement Identity block MUST have a unique tag field to enable 175 metrics blocks in the same RTCP packet to refer unambiguously to 176 the correct Measurement Identity block. The 3-bit field allows up 177 to 8 Measurement Identity blocks in each RTCP packet. If 178 additional metrics must be sent at a given time, and they require 179 more than 8 blocks of Measurement Identity information, then the 180 metrics must be sent in multiple RTCP packets. 182 Forwarding count (fwd): 4 bits 184 These bits provide a count of the number of times the block, and 185 those blocks which refer to it have been forwarded. They MUST be 186 set to zero by the RTP system which creates the Measurement 187 Identity block. The Forwarding count SHOULD be incremented by any 188 RTP system which forwards the block, provided that the operation 189 does not cause the Forwarding count to wrap from 0xF to 0x0. 190 Then, values of the Forwarding count less than 0xF are 191 unambiguous. An RTP system which receives a block with Forwarding 192 count set to 0xF may deduce that the block has been forwarded 15 193 or more times. 195 block length: 16 bits 197 The length of this report block in 32-bit words minus one. For 198 the Measurement Identity block, the block length is equal to 5. 200 SSRC of source: 32 bits 202 The SSRC [RFC3550] of the source of the stream being reported. 203 Note that the SSRC of the reporting RTP system (the originator of 204 the report block) is present in the RTCP XR header defined in 205 Section 2 of [RFC3611]. 207 sub-identifier: 32 bits 209 An additional identifier which is useful in the context of a 210 specific application, e.g. an MPEG-2 transport identifier [MPEG2]. 211 Where the identifier is less than 32 bits, the identifier SHOULD 212 be mapped into the most significant bits of the field. If no 213 additional identifier is provided, all bits of the field MUST be 214 set to zero. This field MUST be ignored by applications which are 215 not configured to make use of it. 217 extended first sequence number (cumulative): 32 bits 219 The extended RTP sequence number of the first received RTP packet 220 relevant to cumulative measurements. Usually this will be the 221 extended sequence number of the first packet of the RTP session. 223 extended first sequence number of interval: 32 bits 224 The extended RTP sequence number of the first received RTP packet 225 of the current measurement interval. 227 extended last sequence number: 32 bits 229 The extended RTP sequence number of the last received RTP packet 230 which contributed to this measurement. 232 Measurement Duration (Cumulative) (ms): 32 bits 234 The duration in ms of the reporting interval applicable to 235 Cumulative reports which use this Measurement Identity block. 237 Measurement Duration (Interval) (ms): 32 bits 239 The duration in ms of the reporting interval applicable to 240 Interval reports which use this Measurement Identity block. 242 3. SDP Signaling 244 [RFC3611] defines the use of SDP (Session Description Protocol) 245 [RFC4566] for signaling the use of XR blocks. XR blocks MAY be used 246 without prior signaling. 248 This section augments the SDP [RFC4566] attribute "rtcp-xr" defined 249 in [RFC3611] by providing a "xr-format" to signal the use of the 250 report block defined in this document. 252 The need for this block could be inferred from a request in SDP 253 signalling for a block type (such as [BASICLOSS]) which depends on 254 it. However to remove ambiguity, if SDP is used to signal a desire 255 to receive a block type which depends on the Measurement Identity 256 block, then the Measurement Identity block itself MUST be signalled 257 explicitly in SDP as described here. 259 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF 261 (defined in RFC3611) 263 xr-format = xr-format / xr-mi-block 265 xr-mi-block = "xr-mi" 267 4. IANA Considerations 269 This document creates a new block type within the IANA "RTCP XR Block 270 Type Registry" called the Measurement Identity Block, and a new 271 parameter xr-mi within the "RTCP XR SDP Parameters Registry". 273 5. Security Considerations 275 RTCP reports can contain sensitive information since they can provide 276 information about the nature and duration of a session established 277 between two or more endpoints. 279 6. References 281 6.1. Normative References 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", RFC 2119, BCP 14, March 1997. 286 [RFC3550] Schulzrinne, H., "RTP: A Transport Protocol for Real-Time 287 Applications", RFC 3550, July 2003. 289 [RFC3611] Friedman, T., "RTP Control Protocol Extended Reports (RTCP 290 XR)", RFC 3611, November 2003. 292 [RFC4566] Handley, M., "SDP: Session Description Protocol", 293 RFC 4566, July 2006. 295 6.2. Informative References 297 [BASICLOSS] 298 Hunt, G., "RTCP XR Block for Measurement Identity", 299 ID draft-ietf-avt-rtcp-xr-meas-identity-00, October 2008. 301 [MONARCH] Hunt, G., "Monitoring Architectures for RTP", 302 ID draft-hunt-avt-monarch-01, August 2008. 304 [MPEG2] ISO/IEC, "Standard 13818-1", 305 ID draft-ietf-avt-rtcp-xr-meas-identity-00, December 2000. 307 [PMOLFRAME] 308 Clark, A., "Framework for Performance Metric Development", 309 ID draft-ietf-pmol-metrics-framework-00, July 2008. 311 Authors' Addresses 313 Geoff Hunt 314 BT 315 Orion 1 PP9 316 Adastral Park 317 Martlesham Heath 318 Ipswich, Suffolk IP4 2TH 319 United Kingdom 321 Phone: +44 1473 608325 322 Email: geoff.hunt@bt.com 324 Alan Clark 325 Telchemy Incorporated 326 2905 Premiere Parkway, Suite 280 327 Duluth, GA 30097 328 USA 330 Email: alan.d.clark@telchemy.com 332 Full Copyright Statement 334 Copyright (C) The IETF Trust (2008). 336 This document is subject to the rights, licenses and restrictions 337 contained in BCP 78, and except as set forth therein, the authors 338 retain all their rights. 340 This document and the information contained herein are provided on an 341 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 342 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 343 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 344 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 345 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 346 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 348 Intellectual Property 350 The IETF takes no position regarding the validity or scope of any 351 Intellectual Property Rights or other rights that might be claimed to 352 pertain to the implementation or use of the technology described in 353 this document or the extent to which any license under such rights 354 might or might not be available; nor does it represent that it has 355 made any independent effort to identify any such rights. Information 356 on the procedures with respect to rights in RFC documents can be 357 found in BCP 78 and BCP 79. 359 Copies of IPR disclosures made to the IETF Secretariat and any 360 assurances of licenses to be made available, or the result of an 361 attempt made to obtain a general license or permission for the use of 362 such proprietary rights by implementers or users of this 363 specification can be obtained from the IETF on-line IPR repository at 364 http://www.ietf.org/ipr. 366 The IETF invites any interested party to bring to its attention any 367 copyrights, patents or patent applications, or other proprietary 368 rights that may cover technology that may be required to implement 369 this standard. Please address the information to the IETF at 370 ietf-ipr@ietf.org.