idnits 2.17.1 draft-ietf-ippm-metrics-registry-01.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 62 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 24, 2002) is 7976 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 69, 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-01.txt June 24, 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 registry format.....................................3 43 4.2. Metrics specified in a RFC..................................3 44 4.3. Metrics specified in a WG draft.............................4 45 4.4. Metrics specified in other documents........................5 46 5. Initial IPPM registry.......................................5 47 6. References.................................................12 48 7. Author's Addresses.........................................12 50 1. Introduction 52 This memo defines a registry of the IPPM working group metrics. It 53 provides an OBJECT IDENTIFIER to each metric currently standardized 54 by the IPPM WG. It defines the rules for the identification of the 55 metrics standardized in the future. 57 2. The IPPM Framework 59 The IPPM Framework consists in four major components: 61 + A general framework for defining performance metrics, 62 described in the Framework for IP Performance Metrics, RFC 63 2330; 65 + A set of standardized metrics, which conform to this 66 framework. The IPPM Metrics for Measuring Connectivity, RFC 2678 67 [2]. The One-way Delay Metric for IPPM, RFC 2679 [3]. The One- 68 way Packet Loss Metric for IPPM, RFC 2680 [4]. The Round-trip 69 Delay Metric for IPPM, RFC 2681 [5]; 71 + Emerging metrics which are being specified in respect of this 72 framework; 74 + The IPPM-REPORTING-MIB for reporting the results of the 75 measures and for interfacing heterogeneous measurement systems 76 with management entities. 78 3. Overview 80 This memo defines a registry of the current metrics and a framework 81 for the integration of the future metrics for the following reasons: 83 + to permit metrics to be clearly referenced by MIBs or other 84 data models; 86 + Metrics identifiers are needed to allow measurement 87 interoperability; 89 + Specification of new metrics is a continuous process, special 90 care must be taken for the integration of the future 91 standardized metrics. 93 4. IPPM metrics Registry framework 95 MIBs need OBJECT INDENTIFIER to refer precisely to the standardized 96 metrics. The registry associates an OBJECT IDENTIFIER to each metric. As 97 an example oneWayDelay and oneWayDelayPoissonStream have different 98 identifiers. 100 The registry has three root branches. The category of the document 101 determines the node the branch the metric is identified in: 103 + Metrics defined in a RFC are identified in the 'rfc' tree; 104 + Metrics defined in a draft of a working group are identified in 105 the 'draft' tree; 106 + Metrics defined elsewhere may be identified in the 'other' tree. 107 The name of the metric has to respect ASN.1 constraints. The name has to 108 start with a lower case. The letter - is forbidden (more or less) in the 109 name. In a way to preserve the readability of the metric name the 110 letters following a - are forced to upper case. 112 Sometime the name of the metric starts with 'Type-P'. It depends on the 113 document not the semantic of the metric. In the registry it is removed 114 from the name of the metric to reduce the length of the name and to 115 uniforms the metrics names. 117 Each sub-tree has specific rules to assign a node to a metric. 119 Each metrics specification will include a section describing its metrics 120 identifiers. 122 IPPM metrics are numbered using the specifications submissions order and 123 the metrics definitions order in each memo. 125 4.1. Metrics registry format 127 Each memo includes a registry where are identified the metrics. The name 128 of the section where is defined the registry terminate by 'metrics 129 registry'. The registry is defined using a MODULE-IDENTITY macro. Each 130 metric is identify in the registry using a OBJECT-IDENTITY macro. The 131 identification defines the metric name, status, reference and OBJECT 132 IDENTIFIER. 134 4.2. Metrics specified in a RFC 136 4.2.1. Rules 138 The metrics specified in a RFC are registered in the node rfc(1). 140 They are numbered using the RFC order and the metrics definitions order 141 in each memo. 143 The value assigned to a metric is definitive and can not be reused. 145 4.2.2. Current WG RFC integration in the registry 147 These rules are applied to initiate the registry. The metrics already 148 standardized are identified in the section 5 'IPPM metrics registry' of 149 this memo. The registry definition should be respectful of the format 150 defined in "4.1 Metrics registry format". 152 4.2.3. Identification of the metrics standardized in future RFC 154 The specification of metrics is a continuous process. The same rules are 155 applied to number the metrics of the new RFC. The identifiers are 156 included in the section 'Standard metrics registry' of the RFC. 158 The status of the identifiers assigned previously to the draft 159 corresponding to the new RFC are set up to 'obsolete' and may not be 160 reassigned. 162 4.3. Metrics specified in a WG draft 164 Usually, metrics are implemented during the specification process. At 165 this step, a metric is not identified as an IPPM metric. There is a need 166 to provide temporary metric identifiers to facilitate software 167 integration and to permit interoperability measurement among different 168 implementations. Otherwise the interoperability will be extremely 169 limited du to the fact that implementers will choose arbitrary values to 170 identify the new metrics. 172 4.3.1. Rules 174 The metrics specified in an IPPM draft are registered in the node 175 draft(2). 177 A draft is more or less released two times a year. It looks ambiguous to 178 use the chronological order of the successive drafts submissions to 179 numbered the metrics because usually the metric name does not change 180 among the different releases. On the other hand new metrics may be added 181 in successive releases of a draft. 183 4.3.2. Current WG drafts integration in the registry 185 The current drafts are numbered using the submission orders of their 186 current release and using the order of the metrics definition in each 187 memo. 189 The previous rules are applied to initiate the registry. The metrics 190 specified in current WG drafts are identified in the section 5 'draft 191 metrics registry' of this memo. The registry definition should be 192 respectful of the format defined in "4.1 Metrics registry format". 194 4.3.3. Identification of a metric added to an existing WG draft 196 Despite new metrics are rarely created in successive releases of a 197 draft, an arbitrary metric identifier may be provided by the IPPM WG to 198 identify the new metric. 200 The identifier is added in the section named 'Draft metrics registry' of 201 the draft. The registry definition should be respectful of the format 202 defined in "4.1 Metrics registry format". 204 4.3.4. Identification of the metrics defined in future WG drafts 206 They are numbered using the chronological orders of the first submission 207 of the draft and using the order of the metrics definition in each memo. 209 These identifiers are included in the draft in a section named 'Draft 210 metrics registry'. The registry definition should be respectful of the 211 format defined in "4.1 Metrics registry format". 213 The name of the metric starts with 'draft' to clearly distinguish the 214 draft OBJECT INDENTIFIER from the its future standard OBJECT 215 INDENTIFIER. 217 Example: 219 Consider a IPPM WG draft that defines the multicast metric Type-P- 220 Multicast-Instantaneous-Hop-One-way-Delay. 222 The name of this metric in the section 'Draft metrics registry' is 223 'draftMulticastInstantaneousHopOneWayDelay'. When this draft will go to 224 RFC, the metric name will become 'multicastInstantaneousHopOneWayDelay'. 226 4.4. Metrics specified in other documents 228 Other metrics may be associated with identifiers in the sub tree 229 other(4). The identifiers are provided by the IPPM WG. 231 These identifiers are included in the corresponding document in a 232 section named 'IPPM registry identifiers'. The registry definition 233 should be respectful of the format defined in "4.1 Metrics registry 234 format". 236 5. Initial IPPM registry 238 IPPM-METRICS-REGISTRY DEFINITIONS ::= BEGIN 240 IMPORTS 241 MODULE-IDENTITY 242 FROM SNMPv2-SMI; 244 ippmMetricsRegistry MODULE-IDENTITY 245 LAST-UPDATED "200206241100Z" -- June 24, 2002 246 ORGANIZATION "IPPM working Group" 247 CONTACT-INFO "ippm@advanced.org" 248 DESCRIPTION 250 " This memo defines a portion of the Management Information Base 251 (MIB) for use with network management protocols in TCP/IP-based 252 internets. In particular, it defines a registry of the IPPM working 253 group metrics." 254 REVISION "200206241100z" 255 DESCRIPTION 256 "Each metric identifier is defined in a OBJECT IDENTITY macro." 257 ::= { ippm 1 } 259 -- 260 -- ippm OBJECT IDENTIFIER ::= XXXX -- To be assigned 261 -- 263 rfc OBJECT IDENTIFIER ::= { registry 1 } 264 draft OBJECT IDENTIFIER ::= { registry 2 } 265 other OBJECT IDENTIFIER ::= { registry 4 } 267 -- 268 -- Registry of the metrics of the IPPM WG RFCs 269 -- 271 -- 272 -- RFC 2678 " IPPM Metrics for Measuring Connectivity" 273 -- 275 instantaneousUnidirectionalConnectivity OBJECT-IDENTITY 276 STATUS current 277 DESCRIPTION 278 "The identifier for the Type-P-Instantaneous-Unidirectional- 279 Connectivity metric." 280 REFERENCE "RFC2678, section 2." 281 ::={rfc 1} 283 instantaneousBidirectionalConnectivity OBJECT-IDENTITY 284 STATUS current 285 DESCRIPTION 286 "The identifier for the Type-P-Instantaneous-Bidirectional- 287 Connectivity metric." 288 REFERENCE "RFC2678, section 3." 289 ::={rfc 2} 291 intervalUnidirectionalConnectivity OBJECT-IDENTITY 292 STATUS current 293 DESCRIPTION 294 "The identifier for the Type-P-Interval-Unidirectional- 295 Connectivity metric." 296 REFERENCE "RFC2678, section 4." 297 ::= { rfc 3 } 299 intervalBidirectionalConnectivity OBJECT-IDENTITY 300 STATUS current 301 DESCRIPTION 302 "The identifier for the Type-P-Interval-Bidirectional- 303 Connectivity metric." 304 REFERENCE "RFC2678, section 5." 305 ::= { rfc 4 } 307 intervalTemporalConnectivity OBJECT-IDENTITY 308 STATUS current 309 DESCRIPTION 310 "The identifier for the Type-P1-P2-Interval-Temporal- 311 Connectivity metric. " 312 REFERENCE "RFC2678, section 6." 313 Type-P-One-way-Delay 314 ::= { rfc 5 } 316 -- 317 -- RFC 2679 "A One-way Delay Metric for IPPM" 318 -- 320 oneWayDelay OBJECT-IDENTITY 321 STATUS current 322 DESCRIPTION 323 "The identifier for the Type-P-One-way-Delay metric. " 324 REFERENCE "RFC2679, section 3." 325 ::= { rfc 6 } 327 oneWayDelayPoissonStream OBJECT-IDENTITY 328 STATUS current 329 DESCRIPTION 330 "The identifier for the Type-P-One-way-Delay-Poisson-Stream 331 metric. " 332 REFERENCE "RFC2679, section 4" 333 ::= { rfc 7 } 335 oneWayDelayPercentile OBJECT-IDENTITY 336 STATUS current 337 DESCRIPTION 338 "The identifier for the Type-P-One-way-Delay-Percentile metric." 339 REFERENCE "RFC2679, section 5.1." 340 ::= { rfc 8 } 342 oneWayDelayMedian OBJECT-IDENTITY 343 STATUS current 344 DESCRIPTION 345 "The identifier for the Type-P-One-way-Delay-Median metric." 346 REFERENCE "RFC2679, section 5.2." 347 ::= { rfc 9 } 349 oneWayDelayMinimum OBJECT-IDENTITY 350 STATUS current 351 DESCRIPTION 352 "The identifier for the Type-P-One-way-Delay-Minimum metric. " 353 REFERENCE "RFC2679, section 5.3." 354 ::= { rfc 10 } 356 oneWayDelayInversePercentile OBJECT-IDENTITY 357 STATUS current 358 DESCRIPTION 359 "The identifier for the Type-P-One-way-Delay-Inverse-Percentile 360 metric. " 361 REFERENCE "RFC2679, section 5.4." 362 ::= { rfc 11 } 364 -- 365 -- RFC 2680 "One Way Packet Loss Metric for IPPM" 366 -- 368 oneWayPacketLoss OBJECT-IDENTITY 369 STATUS current 370 DESCRIPTION 371 "The identifier for the Type-P-One-way-Packet-Loss metric." 372 REFERENCE "RFC2680, section 2." 373 ::= { rfc 12 } 375 oneWayPacketLossPoissonStream OBJECT-IDENTITY 376 STATUS current 377 DESCRIPTION 378 "The identifier for the Type-P-One-way-Packet-Loss-Poisson- 379 Stream metric." 380 REFERENCE "RFC2680, section 3." 381 ::= { rfc 13 } 383 oneWayPacketLossAverage OBJECT-IDENTITY 384 STATUS current 385 DESCRIPTION 386 "The identifier for the Type-P-One-way-Packet-Loss-Average 387 metric." 388 REFERENCE "RFC2680, section 4." 389 ::= { rfc 14 } 391 -- 392 -- RFC2681 "A Round-trip Delay Metric for IPPM" 393 -- 395 roundtripDelay OBJECT-IDENTITY 396 STATUS current 397 DESCRIPTION 398 "The identifier for the Type-P-Round-trip-Delay metric." 399 REFERENCE " section 2 of the rfc2681." 400 ::= { rfc 15 } 402 roundtripDelayPoissonStream OBJECT-IDENTITY 403 STATUS current 404 DESCRIPTION 405 "The identifier for the Type-P-Round-trip-Delay-Poisson-Stream 406 metric." 407 REFERENCE "RFC2681, section 4." 408 ::= { rfc 16 } 410 roundtripDelayPercentile OBJECT-IDENTITY 411 STATUS current 412 DESCRIPTION 413 "The identifier for the Type-P-Round-trip-Delay-Percentile 414 metric." 415 REFERENCE "RFC2681, section 4.1." 416 ::= { rfc 17 } 418 roundtripDelayMedian OBJECT-IDENTITY 419 STATUS current 420 DESCRIPTION 421 "The identifier for the Type-P-Round-trip-Delay-Median metric." 422 REFERENCE "RFC2681, section 4.2." 423 ::= { rfc 18 } 425 roundtripDelayMinimum OBJECT-IDENTITY 426 STATUS current 427 DESCRIPTION 428 "The identifier for the Type-P-Round-trip-Delay-Minimum metric." 429 REFERENCE "RFC2681, section 4.3." 430 ::= { rfc 19 } 432 roundtripDelayInversePercentile OBJECT-IDENTITY 433 STATUS current 434 DESCRIPTION 435 "The identifier for the Type-P-Round-trip-Inverse-Percentile 436 metric." 437 REFERENCE "RFC2681, section 4.4." 438 ::= { rfc 20 } 440 -- 441 -- Registry of the metrics of the IPPM WG drafts 442 -- 444 -- 445 -- One-way Loss Pattern Sample Metrics draft 446 -- 448 draftOneWayLossDistanceStream OBJECT-IDENTITY 449 STATUS current 450 DESCRIPTION 451 "The draft identifier for the Type-P-One-Way-Loss-Distance- 452 Stream metric." 453 REFERENCE "Work in progress" 454 ::={draft 1} 456 draftOneWayLossPeriodStream OBJECT-IDENTITY 457 STATUS current 458 DESCRIPTION 459 "The draft identifier for the Type-P-One-Way-Loss-Period-Stream 460 metric." 461 REFERENCE "Work in progress" 462 ::={draft 2} 464 draftOneWayLossNoticeableRate OBJECT-IDENTITY 465 STATUS current 466 DESCRIPTION 467 "The draft identifier for the Type-P-One-Way-Loss-Noticeable- 468 Rate metric." 469 REFERENCE "Work in progress" 470 ::= { draft 3 } 472 draftOneWayLossPeriodTotal OBJECT-IDENTITY 473 STATUS current 474 DESCRIPTION 475 "The draft identifier for the Type-P-One-Way-Loss-Period-Total 476 metric." 477 REFERENCE "Work in progress" 478 ::= { draft 4 } 480 draftOneWayLossPeriodLengths OBJECT-IDENTITY 481 STATUS current 482 DESCRIPTION 483 "The draft identifier for the Type-P-One-Way-Loss-Period-Lengths 484 metric." 485 REFERENCE "Work in progress" 486 ::= { draft 5 } 488 draftOneWayInterLossPeriodLengths OBJECT-IDENTITY 489 STATUS current 490 DESCRIPTION 491 "The draft identifier for the Type-P-One-Way-Inter-Loss-Period- 492 Lengths metric." 493 REFERENCE "Work in progress" 494 ::= { draft 6 } 496 -- 497 -- Network performance measurement with periodic streams draft 498 -- 500 draftOneWayDelayPeriodicStream OBJECT-IDENTITY 501 STATUS current 502 DESCRIPTION 503 "The draft identifier for the Type-P-One-way-Delay-Periodic- 504 Stream metric." 505 REFERENCE "Work in progress" 506 ::= { draft 7 } 508 -- 509 -- IP Packet Delay Variation Metrics draft 510 -- 512 draftOneWayIpdv OBJECT-IDENTITY 513 STATUS current 514 DESCRIPTION 515 "The draft identifier for the Type-P-One-way-ipdv metric." 516 REFERENCE "Work in progress" 517 ::= { draft 8 } 519 draftOneWayIpdvPoissonStream OBJECT-IDENTITY 520 STATUS current 521 DESCRIPTION 522 "The draft identifier for the Type-P-One-way-ipdv-Poisson-stream 523 metric." 524 REFERENCE "Work in progress" 525 ::= { draft 9 } 527 draftOneWayIpdvPercentile OBJECT-IDENTITY 528 STATUS current 529 DESCRIPTION 530 "The draft identifier for the Type-P-One-way-ipdv-percentile 531 metric." 532 REFERENCE "Work in progress" 533 ::= { draft 10 } 535 draftOneWayIpdvJitter OBJECT-IDENTITY 536 STATUS current 537 DESCRIPTION 538 "The draft identifier for the Type-P-One-way-ipdv-jitter 539 metric." 540 REFERENCE "Work in progress" 541 ::= { draft 11 } 543 draftOneWayPeakToPeakIpdv OBJECT-IDENTITY 544 STATUS current 545 DESCRIPTION 546 "The draft identifier for the Type-P-One-way-peak-to-peak-ipdv 547 metric." 548 REFERENCE "Work in progress" 549 ::= { draft 12 } 551 -- 552 -- Metrics registry from other documents 553 -- 555 END 557 6. References 559 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 560 9, RFC 2026, October 1996. 562 [2] Mahdavi J. and V. Paxson, "IPPM Metrics for Measuring 563 Connectivity", RFC 2678, September 1999. 565 [3] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay 566 Metric for IPPM", RFC 2679, September 1999. 568 [4] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet 569 Loss Metric for IPPM", RFC 2680, September 1999. 571 [5]Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip Delay 572 Metric for IPPM.", RFC 2681, September 1999. 574 7. Author's Addresses 576 Emile STEPHAN 577 France Telecom R & D 578 2 avenue Pierre Marzin 579 F-22307 Lannion cedex 580 Phone: (+ 33) 2 96 05 11 11 581 Email: emile.stephan@francetelecom.com 583 Full Copyright Statement 585 "Copyright (C) The Internet Society (2001). All Rights Reserved. 587 This document and translations of it may be copied and furnished to 588 others, and derivative works that comment on or otherwise explain it 589 or assist its implementation may be prepared, copied, published and 590 distributed, in whole or in part, without restriction of any kind, 591 provided that the above copyright notice and this paragraph are 592 included on all such copies and derivative works. However, this 593 document itself may not be modified in any way, such as by removing 594 the copyright notice or references to the Internet Society or other 595 Internet organizations, except as needed for the purpose of 596 developing Internet standards in which case the procedures for 597 copyrights defined in the Internet Standards process must be 598 followed, or as required to translate it into languages other than 599 English. 601 The limited permissions granted above are perpetual and will not be 602 revoked by the Internet Society or its successors or assigns. 604 This document and the information contained herein is provided on an 605 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 606 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 607 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 608 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 609 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.