idnits 2.17.1 draft-ietf-ippm-metrics-registry-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 61 has weird spacing: '...scribed in th...' -- 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 (June 18, 2002) is 7982 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) == Missing Reference: '5' is mentioned on line 68, but not defined ** Obsolete normative reference: RFC 2679 (ref. '3') (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (ref. '4') (Obsoleted by RFC 7680) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Stephan 4 Internet Draft France Telecom R&D 6 Document: draft-ietf-ippm-metrics-registry-00.txt June 18, 2002 8 IPPM metrics registry 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This memo defines a registry of the IPPM working group metrics. It 32 provides an OBJECT IDENTIFIER to each metric currently standardized 33 by the IPPM WG. It defines the rules for the identification of the 34 metrics standardized in the future. 36 Table of Contents 38 1. Introduction................................................2 39 2. The IPPM Framework..........................................2 40 3. Overview....................................................2 41 4. IPPM metrics Registry framework.............................2 42 4.1. Metrics specified in a RFC..................................3 43 4.2. Metrics specified in a WG draft.............................4 44 4.3. Metrics specified in other documents........................5 45 5. Initial IPPM registry.......................................5 46 6. References..................................................6 47 7. Author's Addresses..........................................7 49 1. Introduction 51 This memo defines a registry of the IPPM working group metrics. It 52 provides an OBJECT IDENTIFIER to each metric currently standardized 53 by the IPPM WG. It defines the rules for the identification of the 54 metrics standardized in the future. 56 2. The IPPM Framework 58 The IPPM Framework consists in four major components: 60 + A general framework for defining performance metrics, 61 described in the Framework for IP Performance Metrics, RFC 62 2330; 64 + A set of standardized metrics, which conform to this 65 framework. The IPPM Metrics for Measuring Connectivity, RFC 2678 66 [2]. The One-way Delay Metric for IPPM, RFC 2679 [3]. The One- 67 way Packet Loss Metric for IPPM, RFC 2680 [4]. The Round-trip 68 Delay Metric for IPPM, RFC 2681 [5]; 70 + Emerging metrics which are being specified in respect of this 71 framework; 73 + The IPPM-REPORTING-MIB for reporting the results of the 74 measures and for interfacing heterogeneous measurement systems 75 with management entities. 77 3. Overview 79 This memo defines a registry of the current metrics and a framework 80 for the integration of the future metrics for the following reasons: 82 + to permit metrics to be clearly referenced by MIBs or other 83 data models; 85 + Metrics identifiers are needed to allow measurement 86 interoperability; 88 + Specification of new metrics is a continuous process, special 89 care must be taken for the integration of the future 90 standardized metrics. 92 4. IPPM metrics Registry framework 94 MIBs need OBJECT INDENTIFIER to refer precisely to the standardized 95 metrics. The registry associates an OBJECT IDENTIFIER to each metric. As 96 an example onewayDelay and onewayDelayPoissonStream have different 97 identifiers. 99 The registry has three root branches. The category of the document 100 determines the node the branch the metric is identified in: 102 + Metrics defined in a RFC are identified in the 'rfc' tree; 103 + Metrics defined in a draft of a working group are identified in 104 the 'draft' tree; 105 + Metrics defined elsewhere may be identified in the 'other' tree. 106 The name of the metric has to respect ASN.1 constraints. The name has to 107 start with a lower case. The letter - is forbidden (more or less) in the 108 name. In a way to preserve the readability of the metric name the 109 letters following a - are forced to upper case. 111 Sometime the name of the metric starts with 'Type-P'. It depends on the 112 document not the semantic of the metric. In the registry it is removed 113 from the name of the metric to reduce the length of the name and to 114 uniforms the metrics names. 116 Each sub-tree has specific rules to assign a node to a metric. 118 Each metrics specification will include a section describing its metrics 119 identifiers. 121 IPPM metrics are numbered using the specifications submissions order and 122 the metrics definitions order in each memo. 124 4.1. Metrics specified in a RFC 126 4.1.1. Rules 128 The metrics specified in a RFC are registered in the node rfc(1). 130 They are numbered using the RFC order and the metrics definitions order 131 in each memo. 133 The value assigned to a metric is definitive and can not be reused. 135 4.1.2. Current WG RFC integration in the registry 137 These rules are applied to initiate the registry. The metrics already 138 standardized are identified in the section 5 'IPPM registry' of this 139 memo. 141 4.1.3. Identification of the metrics standardized in future RFC 143 The specification of metrics is a continuous process. The same rules are 144 applied to number the metrics of the new RFC. The identifiers are 145 included in the section 'Standard metrics registry' of the RFC which 146 lists the identifier of the metrics at the format 'metricName OBJECT 147 IDENTIFIER ::= { rfc }' 148 The temporary identifiers assigned previously to the draft corresponding 149 to the new RFC are considered obsolete and may be reassigned. 151 4.2. Metrics specified in a WG draft 153 Usually, metrics are implemented during the specification process. At 154 this step, a metric is not identified as an IPPM metric. There is a need 155 to provide temporary metric identifiers to facilitate software 156 integration and to permit interoperability measurement among different 157 implementations. Otherwise the interoperability will be extremely 158 limited du to the fact that implementers will choose arbitrary values to 159 identify the new metrics. 161 4.2.1. Rules 163 The metrics specified in an IPPM draft are registered in the node 164 draft(2). 166 A draft is more or less released two times a year. It looks ambiguous to 167 use the chronological order of the successive drafts submissions to 168 numbered the metrics because usually the metric name does not change 169 among the different releases. On the other hand new metrics may be added 170 in successive releases of a draft. 172 When a draft disappears the temporary identifiers assigned to the 173 metrics defined in the draft are considered obsolete and may be 174 reassigned. 176 4.2.2. Current WG drafts integration in the registry 178 The current drafts are numbered using the submission orders of their 179 current release and using the order of the metrics definition in each 180 memo. 182 The previous rules are applied to initiate the registry. The metrics 183 specified in current WG drafts are identified in the section 5 'IPPM 184 registry' of this memo. 186 4.2.3. Identification of a metric added to an existing WG draft 188 Despite new metrics are rarely created in successive releases of a 189 draft, an arbitrary metric identifier may be provided by the IPPM WG to 190 identify the new metric. 192 The identifier is added in the section named 'Draft metrics registry' of 193 the draft. This section list the identifier of the metrics at the format 194 'draftMetricName OBJECT IDENTIFIER ::= { draft }' 196 4.2.4. Identification of the metrics defined in future WG drafts 197 They are numbered using the chronological orders of the first submission 198 of the draft and using the order of the metrics definition in each memo. 200 These identifiers are included in the draft in a section named 'Draft 201 metrics registry'. This section list the identifier of the metrics at 202 the format 'draftMetricName OBJECT IDENTIFIER ::= { draft 203 }' 205 4.3. Metrics specified in other documents 207 Other metrics may be associated with identifiers in the sub tree 208 other(4). The identifiers are provided by the IPPM WG. 210 These identifiers are included in the corresponding document in a 211 section named 'IPPM registry identifiers'. This section list the 212 identifier of the metrics at the format 'MetricName OBJECT IDENTIFIER 213 ::= { other }' 215 5. Initial IPPM registry 217 ippm OBJECT IDENTIFIER ::= XXXX -- To be assigned 218 registry OBJECT IDENTIFIER ::= { ippm 1 } 220 rfc OBJECT IDENTIFIER ::= { registry 1 } 221 draft OBJECT IDENTIFIER ::= { registry 2 } 222 other OBJECT IDENTIFIER ::= { registry 4 } 224 -- 225 -- Registry of the metrics of the IPPM WG RFCs 226 -- 228 instantaneousUnidirectionalConnectivity OBJECT IDENTIFIER::={rfc 1} 229 instantaneousBidirectionalConnectivity OBJECT IDENTIFIER ::={rfc 2} 230 intervalUnidirectionalConnectivity OBJECT IDENTIFIER ::= { rfc 3 } 231 intervalBidirectionalConnectivity OBJECT IDENTIFIER ::= { rfc 4 } 232 intervalTemporalConnectivity OBJECT IDENTIFIER ::= { rfc 5 } 233 onewayDelay OBJECT IDENTIFIER ::= { rfc 6 } 234 onewayDelayPoissonStream OBJECT IDENTIFIER ::= { rfc 7 } 235 onewayDelayPercentile OBJECT IDENTIFIER ::= { rfc 8 } 236 onewayDelayMedian OBJECT IDENTIFIER ::= { rfc 9 } 237 onewayDelayMinimum OBJECT IDENTIFIER ::= { rfc 10 } 238 onewayDelayInversePercentile OBJECT IDENTIFIER ::= { rfc 11 } 239 onewayPacketLoss OBJECT IDENTIFIER ::= { rfc 12 } 240 onewayPacketLossPoissonStream OBJECT IDENTIFIER ::= { rfc 13 } 241 onewayPacketLossAverage OBJECT IDENTIFIER ::= { rfc 14 } 242 roundtripDelay OBJECT IDENTIFIER ::= { rfc 15 } 243 roundtripDelayPoissonStream OBJECT IDENTIFIER ::= { rfc 16 } 244 roundtripDelayPercentile OBJECT IDENTIFIER ::= { rfc 17 } 245 roundtripDelayMedian OBJECT IDENTIFIER ::= { rfc 18 } 246 roundtripDelayMinimum OBJECT IDENTIFIER ::= { rfc 19 } 247 roundtripDelayInversePercentile OBJECT IDENTIFIER ::= { rfc 20 } 249 -- 250 -- Registry of the metrics of the IPPM WG drafts 251 -- 253 -- 254 -- One-way Loss Pattern Sample Metrics draft 255 -- 257 oneWayLossDistanceStream OBJECT IDENTIFIER::={draft 1} 258 oneWayLossPeriodStream OBJECT IDENTIFIER ::={draft 2} 259 oneWayLossDistanceStream OBJECT IDENTIFIER ::= { draft 3 } 260 oneWayLossPeriodStream OBJECT IDENTIFIER ::= { draft 4 } 261 oneWayLossDistanceStream OBJECT IDENTIFIER ::= { draft 5 } 262 oneWayLossPeriodStream OBJECT IDENTIFIER ::= { draft 6 } 263 oneWayLossNoticeableRate OBJECT IDENTIFIER ::= { draft 7 } 264 oneWayLossPeriodTotal OBJECT IDENTIFIER ::= { draft 8 } 265 oneWayLossPeriodLengths OBJECT IDENTIFIER ::= { draft 9 } 266 oneWayInterLossPeriodLengths OBJECT IDENTIFIER ::= { draft 10 } 268 -- 269 -- Network performance measurement with periodic streams draft 270 -- 272 oneWayDelayPeriodicStream OBJECT IDENTIFIER ::= { draft 11 } 274 -- 275 -- IP Packet Delay Variation Metrics draft 276 -- 278 oneWayIpdv OBJECT IDENTIFIER ::= { draft 12 } 279 oneWayIpdvPoissonStream OBJECT IDENTIFIER ::= { draft 13 } 280 oneWayIpdvPercentile OBJECT IDENTIFIER ::= { draft 14 } 281 oneWayIpdvJitter OBJECT IDENTIFIER ::= { draft 15 } 282 oneWayPeakToPeakIpdv OBJECT IDENTIFIER ::= { draft 16 } 284 -- 285 -- Metrics registry from other documents 286 -- 288 6. References 290 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 291 9, RFC 2026, October 1996. 293 [2] Mahdavi J. and V. Paxson, "IPPM Metrics for Measuring 294 Connectivity", RFC 2678, September 1999. 296 [3] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay 297 Metric for IPPM", RFC 2679, September 1999. 299 [4] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet 300 Loss Metric for IPPM", RFC 2680, September 1999. 302 [5]Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip Delay 303 Metric for IPPM.", RFC 2681, September 1999. 305 7. Author's Addresses 307 Emile STEPHAN 308 France Telecom R & D 309 2 avenue Pierre Marzin 310 F-22307 Lannion cedex 311 Phone: (+ 33) 2 96 05 11 11 312 Email: emile.stephan@francetelecom.com 314 Full Copyright Statement 316 "Copyright (C) The Internet Society (2001). All Rights Reserved. 318 This document and translations of it may be copied and furnished to 319 others, and derivative works that comment on or otherwise explain it 320 or assist its implementation may be prepared, copied, published and 321 distributed, in whole or in part, without restriction of any kind, 322 provided that the above copyright notice and this paragraph are 323 included on all such copies and derivative works. However, this 324 document itself may not be modified in any way, such as by removing 325 the copyright notice or references to the Internet Society or other 326 Internet organizations, except as needed for the purpose of 327 developing Internet standards in which case the procedures for 328 copyrights defined in the Internet Standards process must be 329 followed, or as required to translate it into languages other than 330 English. 332 The limited permissions granted above are perpetual and will not be 333 revoked by the Internet Society or its successors or assigns. 335 This document and the information contained herein is provided on an 336 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 337 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 338 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 339 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 340 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.