idnits 2.17.1 draft-ietf-ippm-registry-passive-01.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 (July 4, 2014) is 3555 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-24) exists of draft-ietf-ippm-metric-registry-00 == Outdated reference: A later version (-01) exists of draft-ietf-ippm-registry-active-00 == Outdated reference: A later version (-14) exists of draft-ietf-lmap-framework-07 -- Obsolete informational reference (is this intentional?): RFC 5102 (Obsoleted by RFC 7012) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM Working Group A. Akhter 3 Internet-Draft B. Claise 4 Intended status: Best Current Practice Cisco Systems, Inc. 5 Expires: January 5, 2015 July 4, 2014 7 Passive Performance Metrics Sub-Registry 8 draft-ietf-ippm-registry-passive-01.txt 10 Abstract 12 This document specifies the Passive Performance Metrics sub-registry 13 of the Performance Metric Registry. This sub-registry contains 14 Passive Performance Metrics, especially those defined in RFCs 15 prepared in the IP Performance Metrics (IPPM) Working Group of the 16 IETF, and possibly applicable to other IETF metrics. 18 This document specifies a way to organize registry entries into 19 columns that are well-defined, permitting consistent development of 20 entries over time (a column may be marked NA if it is not applicable 21 for that metric). The design is intended to foster development of 22 registry entries based on existing reference RFCs, whilst each column 23 serves as a check-list item to avoid omissions during the 24 registration process. Every entry in the registry, before IANA 25 action, requires Expert review as defined by concurrent IETF work in 26 progress "Registry for Performance Metrics" (draft-ietf-ippm-metric- 27 registry). 29 The document contains example entries for the Passive Performance 30 Metrics sub-registry: a registry entry for a passive metric based on 31 octetTotalCount as defined in RFC5102 and a protocol specific passive 32 metric based on RTP packets lost as defined in RFC3550. The examples 33 are for Informational purposes and do not create any entry in the 34 IANA registry. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in RFC 2119 [RFC2119]. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on January 5, 2015. 59 Copyright Notice 61 Copyright (c) 2014 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 4. Background and Motivation . . . . . . . . . . . . . . . . . . 6 80 5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 6. Passive Registry Categories and Columns . . . . . . . . . . . 7 82 6.1. Common Registry Indexes and Information . . . . . . . . . 8 83 6.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 8 84 6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 8 85 6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 6.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 8 87 6.1.5. Requester . . . . . . . . . . . . . . . . . . . . . . 8 88 6.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 8 89 6.1.7. Revision Date . . . . . . . . . . . . . . . . . . . . 8 90 6.1.8. Description . . . . . . . . . . . . . . . . . . . . . 8 91 6.1.9. Reference Specification(s) . . . . . . . . . . . . . 8 92 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 9 93 6.2.1. Reference Definition . . . . . . . . . . . . . . . . 9 94 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 9 95 6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 9 96 6.3.1. Reference Implementation . . . . . . . . . . . . . . 9 97 6.3.2. Traffic Filter Criteria . . . . . . . . . . . . . . . 10 98 6.3.3. Measurement Timing . . . . . . . . . . . . . . . . . 10 99 6.3.4. Output Type(s) and Data Format . . . . . . . . . . . 10 100 6.3.5. Metric Units . . . . . . . . . . . . . . . . . . . . 11 101 6.3.6. Run-time Parameters and Data Format . . . . . . . . . 11 102 6.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 11 103 7. Example Generalized Passive Octet Count Entry . . . . . . . . 11 104 7.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 12 105 7.1.1. Element Identifier . . . . . . . . . . . . . . . . . 12 106 7.1.2. Metric Name . . . . . . . . . . . . . . . . . . . . . 12 107 7.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 12 108 7.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 12 109 7.1.5. Requester . . . . . . . . . . . . . . . . . . . . . . 12 110 7.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 12 111 7.1.7. Revision Date . . . . . . . . . . . . . . . . . . . . 12 112 7.1.8. Metric Description . . . . . . . . . . . . . . . . . 13 113 7.1.9. Reference Specification(s) . . . . . . . . . . . . . 13 114 7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 13 115 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 13 116 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 13 117 7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 13 118 7.3.1. Reference Implementation . . . . . . . . . . . . . . 13 119 7.3.2. Traffic Filter Criteria . . . . . . . . . . . . . . . 13 120 7.3.3. Measurement Timing . . . . . . . . . . . . . . . . . 13 121 7.3.4. Output Type(s) and Data Format . . . . . . . . . . . 14 122 7.3.5. Metric Units . . . . . . . . . . . . . . . . . . . . 14 123 7.3.6. Run-time Parameters and Data Format . . . . . . . . . 14 124 7.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 14 125 8. Example 5min Passive Egress Octet Count Entry on WAN 126 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 14 127 8.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 15 128 8.1.1. Element Identifier . . . . . . . . . . . . . . . . . 15 129 8.1.2. Metric Name . . . . . . . . . . . . . . . . . . . . . 15 130 8.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 15 131 8.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 15 132 8.1.5. Requester . . . . . . . . . . . . . . . . . . . . . . 15 133 8.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 15 134 8.1.7. Revision Date . . . . . . . . . . . . . . . . . . . . 15 135 8.1.8. Metric Description . . . . . . . . . . . . . . . . . 16 136 8.1.9. Reference Specification(s) . . . . . . . . . . . . . 16 137 8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 16 138 8.2.1. Reference Definition . . . . . . . . . . . . . . . . 16 139 8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 16 140 8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 16 141 8.3.1. Reference Implementation . . . . . . . . . . . . . . 16 142 8.3.2. Traffic Filter Criteria . . . . . . . . . . . . . . . 16 143 8.3.3. Measurement Timing . . . . . . . . . . . . . . . . . 17 144 8.3.4. Output Type(s) and Data Format . . . . . . . . . . . 17 145 8.3.5. Metric Units . . . . . . . . . . . . . . . . . . . . 17 146 8.3.6. Run-time Parameters and Data Format . . . . . . . . . 17 147 8.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 17 148 9. Example Passive RTP Lost Packet Count . . . . . . . . . . . . 17 149 10. Example BLANK Registry Entry . . . . . . . . . . . . . . . . 17 150 10.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 18 151 10.1.1. Element Identifier . . . . . . . . . . . . . . . . . 18 152 10.1.2. Metric Name . . . . . . . . . . . . . . . . . . . . 18 153 10.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 18 154 10.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 18 155 10.1.5. Requester . . . . . . . . . . . . . . . . . . . . . 18 156 10.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 18 157 10.1.7. Revision Date . . . . . . . . . . . . . . . . . . . 18 158 10.1.8. Metric Description . . . . . . . . . . . . . . . . . 18 159 10.1.9. Reference Specification(s) . . . . . . . . . . . . . 18 160 10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 18 161 10.2.1. Reference Definition . . . . . . . . . . . . . . . . 19 162 10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 19 163 10.3. Method of Measurement . . . . . . . . . . . . . . . . . 19 164 10.3.1. Reference Implementation . . . . . . . . . . . . . . 19 165 10.3.2. Traffic Filter Criteria . . . . . . . . . . . . . . 19 166 10.3.3. Measurement Timing . . . . . . . . . . . . . . . . . 19 167 10.3.4. Output Type(s) and Data Format . . . . . . . . . . . 19 168 10.3.5. Metric Units . . . . . . . . . . . . . . . . . . . . 19 169 10.3.6. Run-time Parameters and Data Format . . . . . . . . 20 170 10.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 20 171 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 172 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 173 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 174 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 175 14.1. Normative References . . . . . . . . . . . . . . . . . . 21 176 14.2. Informative References . . . . . . . . . . . . . . . . . 21 177 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 179 1. Open Issues 181 1. This draft must be aligned with draft-ietf-ippm-registry-active: 182 structure, content, examples, etc. 184 2. Do we need definitions for Active Metric and Passive Metric? To 185 be decided with the authors of ietf-ippm-metric-registry and 186 ietf-ippm-registry-active 188 Active (Performance) Metric: specific to Performance Metrics 189 metered by an Active Measurement Method. 191 Passive (Performance) Metric: specific to Performance Metrics 192 metered by an Passive Measurement Method. 194 3. See the EDITOR's NOTE within this draft. 196 4. Should the "Measurement Timing" be part of the registry? 198 5. What is difference between "Reference Specification(s)" and 199 "Reference Definition" 201 6. draft-ietf-ippm-metric-registry contain requester and reviewer 202 guidelines for performance metrics. Do we have guidelines 203 specifc to the extra passive performance metric fields in this 204 document? 206 2. Introduction 208 The IETF has been specifying and continues to specify Performance 209 Metrics. While IP Performance Metrics (IPPM) is the working group 210 (WG) primarily focusing on Performance Metrics definition at the 211 IETF, other working groups, have also specified Performance Metrics: 213 The "Metric Blocks for use with RTCP's Extended Report Framework" 214 [XRBLOCK] WG recently specified many Performance Metrics related 215 to "RTP Control Protocol Extended Reports (RTCP XR)" [RFC3611], 216 which establishes a framework to allow new information to be 217 conveyed in RTCP, supplementing the original report blocks defined 218 in "RTP: A Transport Protocol for Real-Time Applications", 219 [RFC3550]. 221 The Benchmarking Methodology" [BMWG] WG proposed some Performance 222 Metrics as part of the benchmarking methodology. 224 The IP Flow Information eXport WG (IPFIX) [IPFIX] has existing and 225 proposed Information Elements related to performance metrics. 227 The Performance Metrics for Other Layers (PMOL) [PMOL], a 228 concluded working group, defined some Performance Metrics related 229 to Session Initiation Protocol (SIP) voice quality [RFC6035], as 230 well as guidelines for defining performance metrics [RFC6390] 232 It is expected that more and more Performance Metrics will be defined 233 in the future, not only IP based metrics, but also protocol-specific 234 ones and application-specific ones. 236 "Registry for Performance Metrics" [I-D.ietf-ippm-metric-registry] 237 specifies a common registry for Performance Metrics. This document 238 specifies the creation of a sub-registry specific to Performance 239 Metrics metered by an Passive Measurement Method (passive metrics). 240 Note that a sister document, "Active Performance Metric Sub-Registry" 242 [I-D.ietf-ippm-registry-active], specifies a sub-registry for the 243 active metric (Performance Metrics metered by an Active Measurement. 245 The Passive Performance Measurements Sub-Registry contains passive 246 performance metrics that meet the criteria set by the IETF and review 247 of the Performance Metric Experts. It is expected that the majority 248 of the metrics will have been defined elsewhere within the IETF 249 working groups such as IPPM, BMWG, IPFIX, etc. 251 This sub-registry is part of the Performance Metric Registry 252 [I-D.ietf-ippm-metric-registry] which specifies that all sub- 253 registries must contain at least the following common fields: the 254 identifier, the name, the URI, the status, the requester, the 255 revision, the revision date, the description, and the reference 256 specification(s). In addition to these common fields the passive 257 metrics sub-registry has additional fields that provide the necessary 258 background for interoperability and adoption. 260 3. Terminology 262 "Registry for Performance Metrics" [I-D.ietf-ippm-metric-registry] 263 specifies the following terms: Performance Metric, Registered 264 Performance Metric, Performance Metrics Registry (also known as 265 Registry), Proprietary Registry, Performance Metrics Experts, 266 Performance Metrics Directorate, Parameter, Active Measurement 267 Method, Passive Measurement Method, and Hybrid Measurement Method. 269 Capitalized terms used in this document that are defined in the 270 Terminology section of [I-D.ietf-ippm-metric-registry] are to be 271 interpreted as defined there. 273 4. Background and Motivation 275 EDITOR's NOTE: from draft-manyfolks-ippm-metric-registry-00. 276 Proposal: we can simply refers to draft-ietf-ippm-registry-active-00 277 section 5, instead of duplicating text. 279 IPPM Passive Performance Metric registration is meant to allow wider 280 adoption of common metrics in an inter-operable way. There are 281 challenges with metric interoperability and adoption (to name a few) 282 due to flexible input parameters, confusion between many similar 283 metrics, and varying output formats. 285 One clear motivation for having such a registry is to allow a 286 controller to request a measurement agent to perform a measurement 287 using a specific metric (see [I-D.ietf-lmap-framework]). Such a 288 request can be performed using any control protocol that refers to 289 the value assigned to the specific metric in the registry. 291 Similarly, the measurement agent can report the results of the 292 measurement and by referring to the metric value it can unequivocally 293 identify the metric that the results correspond to. 295 There are several side benefits of having a registry with well-chosen 296 entries. First, the registry could serve as an inventory of useful 297 and used metrics that are normally supported by different 298 implementations of measurement agents. Second, the results of the 299 metrics would be comparable even if they are performed by different 300 implementations and in different networks, as the metric and method 301 is unambiguously defined. 303 5. Scope 305 [I-D.ietf-ippm-metric-registry] defines the overall structure for a 306 Performance Metric Registry and provides guidance for defining a sub 307 registry. 309 This document defines the Passive Performance Metrics Sub-registry; 310 passive metrics are those where the measurements are based the 311 observation of on network traffic, generated either from the end 312 users or from network elements. Specifically, this traffic has not 313 been generated for the purpose of measurement. 315 A row in the registry corresponds to one Registered Performance 316 Metric, with entries in the various columns specifying the metric. 317 Section 6 defines the additional columns for a Registered Passive 318 Performance Metric. 320 As discussed in [I-D.ietf-ippm-metric-registry], each entry (row) 321 must be tightly defined; the definition must leave open only a few 322 parameters that do not change the fundamental nature of the 323 measurement (such as source and destination addresses), and so 324 promotes comparable results across independent implementations. 325 Also, each registered entry must be based on existing reference RFCs 326 (or other standards) for performance metrics, and must be 327 operationally useful and have significant industry interest. This is 328 ensured by expert review for every entry before IANA action. 330 6. Passive Registry Categories and Columns 332 This section defines the categories and columns of the registry. 333 Below, categories are described at the 6.x heading level, and columns 334 are at the 6.x.y heading level. There are three categories, divided 335 into common information (from [I-D.ietf-ippm-metric-registry]), 336 metric definition and an open Comments section. 338 6.1. Common Registry Indexes and Information 340 This category has multiple indexes to each registry entry. It is 341 defined in [I-D.ietf-ippm-metric-registry]: 343 6.1.1. Identifier 345 Defined in [I-D.ietf-ippm-metric-registry]. Definition text to be 346 copied once source is stable. 348 6.1.2. Name 350 Defined in [I-D.ietf-ippm-metric-registry], same comment as above. 352 6.1.3. URI 354 Defined in [I-D.ietf-ippm-metric-registry], same comment as above. 356 6.1.4. Status 358 Defined in [I-D.ietf-ippm-metric-registry], same comment as above. 360 6.1.5. Requester 362 Defined in [I-D.ietf-ippm-metric-registry], same comment as above. 364 6.1.6. Revision 366 Defined in [I-D.ietf-ippm-metric-registry], same comment as above. 368 6.1.7. Revision Date 370 Defined in [I-D.ietf-ippm-metric-registry], same comment as above. 372 6.1.8. Description 374 Defined in [I-D.ietf-ippm-metric-registry], same comment as the 375 above. 377 6.1.9. Reference Specification(s) 379 Defined in [I-D.ietf-ippm-metric-registry], same comment as the 380 above. 382 6.2. Metric Definition 384 This category includes columns to prompt all necessary details 385 related to the passive performance metric definition, including the 386 RFC reference and values of input factors, called fixed parameters, 387 which are left open in the origin definition but have a particular 388 value defined by the performance metric. 390 6.2.1. Reference Definition 392 This entry provides references to relevant sections of the RFC(s) 393 defining the metric, as well as any supplemental information needed 394 to ensure an unambiguous definition for implementations. 396 6.2.2. Fixed Parameters 398 Fixed Parameters are input factors whose value must be specified in 399 the Registry. The measurement system uses these values. 401 Where referenced metrics supply a list of Parameters as part of their 402 descriptive template, a sub-set of the Parameters will be designated 403 as Fixed Parameters. For example, for RTP packet loss calculation 404 relies on the validation of a packet as RTP which is a multi-packet 405 validation controlled by MIN_SEQUENTIAL as defined by [RFC3550]. 406 Varying MIN_SEQUENTIAL values can alter the loss report and this 407 value could be set as a fixed parameter. 409 A Parameter which is Fixed for one Registry entry may be designated 410 as a Run-time Parameter for another Registry entry. 412 6.3. Method of Measurement 414 This category includes columns for references to relevant sections of 415 the RFC(s) and any supplemental information needed to ensure an 416 unambiguous method for implementations. 418 6.3.1. Reference Implementation 420 This entry provides references to relevant sections of the RFC(s) 421 describing the method of measurement, as well as any supplemental 422 information needed to ensure unambiguous interpretation for 423 implementations referring to the RFC text. 425 Specifically, this section should include pointers to pseudocode or 426 actual code that could be used for an unambigious implementation. 428 6.3.2. Traffic Filter Criteria 430 The filter specifies the traffic constraints that the passive 431 measurement method used is valid (or invalid) for. This includes 432 valid packet sampling ranges, width of valid traffic matches (eg. all 433 traffic on interface, UDP packets packets in a flow (eg. same RTP 434 session). 436 It is possible that the measurement method may not have a specific 437 limitation. However, this specific registry entry with it's 438 combination of fixed parameters implies restrictions. These 439 restrictions would be listed in this field. 441 6.3.3. Measurement Timing 443 Measurement timing defines the behavior of the measurement method 444 with respect to timing. 446 Is the measurement continuous? 448 If the measurement is sampled, what is the format of sampling? (eg 449 random packet, random time, etc.) 451 How long is the measurement interval? 453 6.3.4. Output Type(s) and Data Format 455 For entries which involve a stream and many singleton measurements, a 456 statistic may be specified in this column to summarize the results to 457 a single value. If the complete set of measured singletons is 458 output, this will be specified here. 460 Some metrics embed one specific statistic in the reference metric 461 definition, while others allow several output types or statistics. 463 Each entry in the output type column contains the following 464 information: 466 o Value: The name of the output type 468 o Data Format: provided to simplify the communication with 469 collection systems and implementation of measurement devices. 471 o Reference: the specification where the output type is defined 473 The output type defines the type of result that the metric produces. 474 It can be the raw result(s) or it can be some form of statistic. The 475 specification of the output type must define the format of the 476 output. In some systems, format specifications will simplify both 477 measurement implementation and collection/storage tasks. Note that 478 if two different statistics are required from a single measurement 479 (for example, both "Xth percentile mean" and "Raw"), then a new 480 output type must be defined ("Xth percentile mean AND Raw"). 482 6.3.5. Metric Units 484 The measured results must be expressed using some standard dimension 485 or units of measure. This column provides the units. 487 When a sample of singletons (see [RFC2330] for definitions of these 488 terms) is collected, this entry will specify the units for each 489 measured value. 491 6.3.6. Run-time Parameters and Data Format 493 Run-Time Parameters are input factors that must be determined, 494 configured into the measurement system, and reported with the results 495 for the context to be complete. However, the values of these 496 parameters is not specified in the Registry, rather these parameters 497 are listed as an aid to the measurement system implementor or user 498 (they must be left as variables, and supplied on execution). 500 Where metrics supply a list of Parameters as part of their 501 descriptive template, a sub-set of the Parameters will be designated 502 as Run-Time Parameters. 504 The Data Format of each Run-time Parameter SHALL be specified in this 505 column, to simplify the control and implementation of measurement 506 devices. 508 Examples of Run-time Parameters include IP addresses, measurement 509 point designations, start times and end times for measurement, and 510 other information essential to the method of measurement. 512 6.4. Comments and Remarks 514 Besides providing additional details which do not appear in other 515 categories, this open Category (single column) allows for unforeseen 516 issues to be addressed by simply updating this Informational entry. 518 7. Example Generalized Passive Octet Count Entry 520 tbd 522 This section is Informational. 524 This section gives an example registry entry for a generalized the 525 passive metric octetDeltaCount described in [RFC5102]. 527 7.1. Registry Indexes 529 This category includes multiple indexes to the registry entries, the 530 element ID and metric name. 532 7.1.1. Element Identifier 534 An integer having enough digits to uniquely identify each entry in 535 the Registry. 537 TBD by IANA. 539 7.1.2. Metric Name 541 A metric naming convention is TBD. 543 One possibility based on the proposal in 544 [I-D.ietf-ippm-metric-registry]: 546 Pas_IP-Octet-Delta-General 548 7.1.3. URI 550 urn:ietf:params:performance:metric-something 552 7.1.4. Status 554 Current 556 7.1.5. Requester 558 TBD 560 7.1.6. Revision 562 0 564 7.1.7. Revision Date 566 TBD 568 7.1.8. Metric Description 570 A delta count of the number of octets observed. 572 7.1.9. Reference Specification(s) 574 octetDeltaCount described in section 5.10.1 of [RFC5102] 576 7.2. Metric Definition 578 This category includes columns to prompt the entry of all necessary 579 details related to the metric definition, including the RFC reference 580 and values of input factors, called fixed parameters. 582 7.2.1. Reference Definition 584 octetDeltaCount described in section 5.10.1 of [RFC5102] 586 7.2.2. Fixed Parameters 588 As this is the generalised version of the IP delta count metric, 589 there are no fixed parameters. 591 7.3. Method of Measurement 593 7.3.1. Reference Implementation 595 For . 597
599 7.3.2. Traffic Filter Criteria 601 This measurement only covers IP packets and the IP payload (including 602 the IP header) of these packets. Non-IP packets (BPDUs, ISIS) will 603 not be accounted. Layer 2 overhead (Ethernet headers, MPLS, QinQ, 604 etc.) will also not be represented in the measurement. 606 7.3.3. Measurement Timing 608 This is a continous measurement of the IP octets seen in the traffic 609 selection scope (run-time parameter). 611 The measurement interval is a run time parameter. 613 There is no sampling. 615 7.3.4. Output Type(s) and Data Format 617 It is possible that multiple observation intervals are reported in a 618 single report. In such a case concatination of the interval reports 619 (deltaOctetCount, start-time, end-time) is allowed. 621 The delta octet count metric reports a observation start time and end 622 time. 624 o Value: observation-start-time and observation-end-time 626 o Data Format: 64-bit NTP Time-stamp Format 628 o Reference: section 6 of [RFC5905] 630 7.3.5. Metric Units 632 The measured results are expressed in octets with a data format of 633 unsigned64 as described in [RFC5102] 635 7.3.6. Run-time Parameters and Data Format 637 Run-time Parameters are input factors that must be determined, 638 configured into the measurement system, and reported with the results 639 for the context to be complete. 641 o samplingTimeInterval, length of time a single report covers. 642 unsigned32 microseconds [RFC5477] 644 o observationInterface, ifindex of interface to monitor. -1 645 represents all interfaces. -2 representings WAN facing and -3 646 represnets LAN facing. unsigned32. 648 o observation direction, unsigned8 where 0 represents incoming 649 traffic on interface, 1 outgoing and 2 represents both incoming 650 and outgoing. 652 7.4. Comments and Remarks 654 Additional (Informational) details for this entry 656 8. Example 5min Passive Egress Octet Count Entry on WAN Interface 658 tbd 660 This section is Informational. 662 This section gives an example registry entry for accounting of 663 outgoing WAN IP traffic the passive metric in terms of 664 octetDeltaCount, as described in [RFC5102]. 666 8.1. Registry Indexes 668 This category includes multiple indexes to the registry entries, the 669 element ID and metric name. 671 8.1.1. Element Identifier 673 An integer having enough digits to uniquely identify each entry in 674 the Registry. 676 TBD by IANA. 678 8.1.2. Metric Name 680 A metric naming convention is TBD. 682 One possibility based on the proposal in 683 [I-D.ietf-ippm-metric-registry]: 685 Pas_IP-Octet-Delta-WAN-egress 687 8.1.3. URI 689 urn:ietf:params:performance:metric-something 691 8.1.4. Status 693 Current 695 8.1.5. Requester 697 TBD 699 8.1.6. Revision 701 0 703 8.1.7. Revision Date 705 TBD 707 8.1.8. Metric Description 709 A delta count of the number of octets observed outgoing on WAN 710 interface. 712 8.1.9. Reference Specification(s) 714 octetDeltaCount described in section 5.10.1 of [RFC5102] 716 8.2. Metric Definition 718 This category includes columns to prompt the entry of all necessary 719 details related to the metric definition, including the RFC reference 720 and values of input factors, called fixed parameters. 722 8.2.1. Reference Definition 724 octetDeltaCount described in section 5.10.1 of [RFC5102] 726 8.2.2. Fixed Parameters 728 As this is a specific version of Pas_IP-Octet-Delta-General that 729 performs metering of all outgoing WAN traffic. 731 o samplingTimeInterval= 300000000, length of time a single report 732 covers. unsigned32 microseconds [RFC5477] 734 o observationInterface= -2, ifindex of interface to monitor. -1 735 represents all interfaces. -2 representings WAN facing and -3 736 represnets LAN facing. unsigned32. 738 o observation direction= 1, unsigned8 where 0 represents incoming 739 traffic on interface, 1 outgoing and 2 represents both incoming 740 and outgoing. 742 8.3. Method of Measurement 744 8.3.1. Reference Implementation 746 For . 748
750 8.3.2. Traffic Filter Criteria 752 This measurement only covers IP packets observed in the WAN outgoing 753 direction. The bytes counted are the IP payload (including the IP 754 header) of these packets. Non-IP packets (BPDUs, ISIS) will not be 755 accounted. Layer 2 overhead (Ethernet headers, MPLS, QinQ, etc.) 756 will also not be represented in the measurement. 758 8.3.3. Measurement Timing 760 This is a continous measurement of the IP octets seen in the traffic 761 selection scope (run-time parameter), each of a 5 minute duration. 763 There is no sampling. 765 8.3.4. Output Type(s) and Data Format 767 It is possible that multiple observation intervals are reported in a 768 single report. In such a case concatination of the interval reports 769 (deltaOctetCount, start-time, end-time) is allowed. 771 The delta octet count metric reports a observation start time and end 772 time. 774 o Value: observation-start-time and observation-end-time 776 o Data Format: 64-bit NTP Time-stamp Format 778 o Reference: section 6 of [RFC5905] 780 8.3.5. Metric Units 782 The measured results are expressed in octets with a data format of 783 unsigned64 as described in [RFC5102] 785 8.3.6. Run-time Parameters and Data Format 787 There are no run-time parameters for this registry entry. 789 8.4. Comments and Remarks 791 Additional (Informational) details for this entry 793 9. Example Passive RTP Lost Packet Count 795 tbd 797 10. Example BLANK Registry Entry 799 This section is Informational. (?) 801 This section gives an example registry entry for the . 804 10.1. Registry Indexes 806 This category includes multiple indexes to the registry entries, the 807 element ID and metric name. 809 10.1.1. Element Identifier 811 An integer having enough digits to uniquely identify each entry in 812 the Registry. 814 10.1.2. Metric Name 816 A metric naming convention is TBD. 818 10.1.3. URI 820 urn:ietf:params:performance:metric-something 822 10.1.4. Status 824 Current 826 10.1.5. Requester 828 TBD 830 10.1.6. Revision 832 0 834 10.1.7. Revision Date 836 TBD 838 10.1.8. Metric Description 840 A metric Description is TBD. 842 10.1.9. Reference Specification(s) 844 Section YY, RFCXXXX 846 10.2. Metric Definition 847 10.2.1. Reference Definition 849 < possible section reference> 851 10.2.2. Fixed Parameters 853 Fixed Parameters are input factors that must be determined and 854 embedded in the measurement system for use when needed. The values 855 of these parameters is specified in the Registry. 857 859 10.3. Method of Measurement 861 10.3.1. Reference Implementation 863 For . 865
867 10.3.2. Traffic Filter Criteria 869 871 10.3.3. Measurement Timing 873 < list timing requirements and limitations > 875 10.3.4. Output Type(s) and Data Format 877 The output types define the type of result that the metric produces. 879 o Value: 881 o Data Format: (There may be some precedent to follow here, but 882 otherwise use 64-bit NTP Time-stamp Format, see section 6 of 883 [RFC5905]). 885 o Reference:
887 10.3.5. Metric Units 889 The measured results are expressed in , 891
. 893 10.3.6. Run-time Parameters and Data Format 895 Run-time Parameters are input factors that must be determined, 896 configured into the measurement system, and reported with the results 897 for the context to be complete. 899 901 . 903 10.4. Comments and Remarks 905 Additional (Informational) details for this entry 907 11. Security Considerations 909 This registry has no known implications on Internet Security. 911 12. IANA Considerations 913 IANA is requested to create The Passive Performance Metric Sub- 914 registry within the Performance Metric Registry defined in 915 [I-D.ietf-ippm-metric-registry]. The Sub-registry will contain the 916 following categories and (bullet) columns, (as defined in section 6 917 above): 919 Common Registry Indexes and Info 921 o Identifier 923 o Name 925 o URI 927 o Status 929 o Requester 931 o Revision 933 o Revision Date 935 o Description 937 o Reference Specification(s) 939 Metric Definition 940 o Reference Definition 942 o Fixed Parameters 944 Method of Measurement 946 o Reference Implementation 948 o Traffic Filter Criteria 950 o Measurement Timing 952 o Output Type(s) and Data format 954 o Metric Units 956 o Run-time Parameters 958 Comments and Remarks 960 13. Acknowledgements 962 The authors thank the prior work of Al Morton, Marcelo Bagnulo and 963 Phil Eardley in "draft-ietf-ippm-registry-active" which was used both 964 as a template for this document and source of text. 966 14. References 968 14.1. Normative References 970 [I-D.ietf-ippm-metric-registry] 971 Bagnulo, M., Claise, B., Eardley, P., and A. Morton, 972 "Registry for Performance Metrics", draft-ietf-ippm- 973 metric-registry-00 (work in progress), July 2014. 975 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 976 Requirement Levels", BCP 14, RFC 2119, March 1997. 978 14.2. Informative References 980 [BMWG] IETF, , "Benchmarking Methodology (BMWG) Working Group, 981 http://datatracker.ietf.org/wg/bmwg/charter/", . 983 [I-D.ietf-ippm-registry-active] 984 Morton, A., Bagnulo, M., and P. Eardley, "Active 985 Performance Metric Sub-Registry", draft-ietf-ippm- 986 registry-active-00 (work in progress), April 2014. 988 [I-D.ietf-lmap-framework] 989 Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 990 Aitken, P., and A. Akhter, "A framework for large-scale 991 measurement platforms (LMAP)", draft-ietf-lmap- 992 framework-07 (work in progress), June 2014. 994 [IPFIX] IETF, , "IP Flow Information eXport (IPFIX) Working Group, 995 http://datatracker.ietf.org/wg/ipfix/charter/", . 997 [PMOL] IETF, , "IP Performance Metrics for Other Layers (PMOL) 998 Working Group, 999 http://datatracker.ietf.org/wg/pmol/charter/", . 1001 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1002 "Framework for IP Performance Metrics", RFC 2330, May 1003 1998. 1005 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1006 Jacobson, "RTP: A Transport Protocol for Real-Time 1007 Applications", STD 64, RFC 3550, July 2003. 1009 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 1010 Protocol Extended Reports (RTCP XR)", RFC 3611, November 1011 2003. 1013 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 1014 Meyer, "Information Model for IP Flow Information Export", 1015 RFC 5102, January 2008. 1017 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 1018 Carle, "Information Model for Packet Sampling Exports", 1019 RFC 5477, March 2009. 1021 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1022 Time Protocol Version 4: Protocol and Algorithms 1023 Specification", RFC 5905, June 2010. 1025 [RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, 1026 "Session Initiation Protocol Event Package for Voice 1027 Quality Reporting", RFC 6035, November 2010. 1029 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 1030 Performance Metric Development", BCP 170, RFC 6390, 1031 October 2011. 1033 [XRBLOCK] IETF, , "Metric Blocks for use with RTCP's Extended Report 1034 Framework (XRBLOCK), 1035 http://datatracker.ietf.org/wg/xrblock/charter/", . 1037 Authors' Addresses 1039 Aamer Akhter 1040 Cisco Systems, Inc. 1041 7025 Kit Creek Road 1042 RTP, NC 27709 1043 USA 1045 Email: aakhter@cisco.com 1047 Benoit Claise 1048 Cisco Systems, Inc. 1049 De Kleetlaan 6a b1 1050 1831 Diegem 1051 Belgium 1053 Phone: +32 2 704 5622 1054 Email: bclaise@cisco.com