idnits 2.17.1 draft-akhter-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 (March 3, 2014) is 3706 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) == Outdated reference: A later version (-14) exists of draft-ietf-lmap-framework-03 -- Obsolete informational reference (is this intentional?): RFC 5102 (Obsoleted by RFC 7012) Summary: 0 errors (**), 0 flaws (~~), 2 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: Standards Track Cisco Systems, Inc. 5 Expires: September 4, 2014 March 3, 2014 7 Passive Performance Metrics Sub-Registry 8 draft-akhter-ippm-registry-passive-01.txt 10 Abstract 12 This memo defines the Passive Performance Metrics sub-registry of the 13 Performance Metric Registry. This sub-registry will contain Passive 14 Performance Metrics, especially those defined in RFCs prepared in the 15 IP Performance Metrics (IPPM) Working Group of the IETF, and possibly 16 applicable to other IETF metrics. 18 IPPM Passive metric registration is meant to allow wider adoption of 19 common metrics in an inter-operable way. There are challenges with 20 metric interoperability and adoption (to name a few) due to flexible 21 input parameters, confusion between many similar metrics, and varying 22 output formats. 24 This memo proposes a way to organize registry entries into columns 25 that are well-defined, permitting consistent development of entries 26 over time (a column may be marked NA if it is not applicable for that 27 metric). The design is intended to foster development of registry 28 entries based on existing reference RFCs, whilst each column serves 29 as a check-list item to avoid omissions during the registration 30 process. Every entry in the registry, before IANA action, requires 31 Expert review as defined by concurrent IETF work in progress 32 "Registry for Performance Metrics" (draft-manyfolks-ippm-metric- 33 registry). 35 The document contains example entries for the Passive Performance 36 Metrics sub-registry: a registry entry for a passive metric based on 37 octetTotalCount as defined in RFC5102 and a protocol specific passive 38 metric based on RTP packets lost as defined in RFC3550. The examples 39 are for Informational purposes and do not create any entry in the 40 IANA registry. 42 Requirements Language 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119 [RFC2119]. 48 Status of This Memo 50 This Internet-Draft is submitted in full conformance with the 51 provisions of BCP 78 and BCP 79. 53 Internet-Drafts are working documents of the Internet Engineering 54 Task Force (IETF). Note that other groups may also distribute 55 working documents as Internet-Drafts. The list of current Internet- 56 Drafts is at http://datatracker.ietf.org/drafts/current/. 58 Internet-Drafts are draft documents valid for a maximum of six months 59 and may be updated, replaced, or obsoleted by other documents at any 60 time. It is inappropriate to use Internet-Drafts as reference 61 material or to cite them other than as "work in progress." 63 This Internet-Draft will expire on September 4, 2014. 65 Copyright Notice 67 Copyright (c) 2014 IETF Trust and the persons identified as the 68 document authors. All rights reserved. 70 This document is subject to BCP 78 and the IETF Trust's Legal 71 Provisions Relating to IETF Documents 72 (http://trustee.ietf.org/license-info) in effect on the date of 73 publication of this document. Please review these documents 74 carefully, as they describe your rights and restrictions with respect 75 to this document. Code Components extracted from this document must 76 include Simplified BSD License text as described in Section 4.e of 77 the Trust Legal Provisions and are provided without warranty as 78 described in the Simplified BSD License. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 83 2. Background and Motivation: . . . . . . . . . . . . . . . . . 6 84 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 85 4. Passive Registry Categories and Columns . . . . . . . . . . . 7 86 4.1. Common Registry Indexes and Information . . . . . . . . . 7 87 4.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 7 88 4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 7 89 4.1.3. Status . . . . . . . . . . . . . . . . . . . . . . . 7 90 4.1.4. Requester . . . . . . . . . . . . . . . . . . . . . . 7 91 4.1.5. Revision . . . . . . . . . . . . . . . . . . . . . . 7 92 4.1.6. Revision Date . . . . . . . . . . . . . . . . . . . . 7 93 4.1.7. Description . . . . . . . . . . . . . . . . . . . . . 7 94 4.1.8. Reference Specification(s) . . . . . . . . . . . . . 8 95 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 8 96 4.2.1. Reference Definition . . . . . . . . . . . . . . . . 8 97 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 8 98 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 8 99 4.3.1. Reference Implementation . . . . . . . . . . . . . . 8 100 4.3.2. Traffic Filter Criteria . . . . . . . . . . . . . . . 9 101 4.3.3. Measurement Timing . . . . . . . . . . . . . . . . . 9 102 4.3.4. Output Type(s) and Data Format . . . . . . . . . . . 9 103 4.3.5. Metric Units . . . . . . . . . . . . . . . . . . . . 10 104 4.3.6. Run-time Parameters and Data Format . . . . . . . . . 10 105 4.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 10 106 5. Example Generalized Passive Octet Count Entry . . . . . . . . 11 107 5.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 11 108 5.1.1. Element Identifier . . . . . . . . . . . . . . . . . 11 109 5.1.2. Metric Name . . . . . . . . . . . . . . . . . . . . . 11 110 5.1.3. Status . . . . . . . . . . . . . . . . . . . . . . . 11 111 5.1.4. Requester . . . . . . . . . . . . . . . . . . . . . . 11 112 5.1.5. Revision . . . . . . . . . . . . . . . . . . . . . . 11 113 5.1.6. Revision Date . . . . . . . . . . . . . . . . . . . . 11 114 5.1.7. Metric Description . . . . . . . . . . . . . . . . . 12 115 5.1.8. Reference Specification(s) . . . . . . . . . . . . . 12 116 5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 12 117 5.2.1. Reference Definition . . . . . . . . . . . . . . . . 12 118 5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 12 119 5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 12 120 5.3.1. Reference Implementation . . . . . . . . . . . . . . 12 121 5.3.2. Traffic Filter Criteria . . . . . . . . . . . . . . . 12 122 5.3.3. Measurement Timing . . . . . . . . . . . . . . . . . 12 123 5.3.4. Output Type(s) and Data Format . . . . . . . . . . . 13 124 5.3.5. Metric Units . . . . . . . . . . . . . . . . . . . . 13 125 5.3.6. Run-time Parameters and Data Format . . . . . . . . . 13 126 5.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 13 127 6. Example 5min Passive Egress Octet Count Entry on WAN 128 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 13 129 6.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 14 130 6.1.1. Element Identifier . . . . . . . . . . . . . . . . . 14 131 6.1.2. Metric Name . . . . . . . . . . . . . . . . . . . . . 14 132 6.1.3. Status . . . . . . . . . . . . . . . . . . . . . . . 14 133 6.1.4. Requester . . . . . . . . . . . . . . . . . . . . . . 14 134 6.1.5. Revision . . . . . . . . . . . . . . . . . . . . . . 14 135 6.1.6. Revision Date . . . . . . . . . . . . . . . . . . . . 14 136 6.1.7. Metric Description . . . . . . . . . . . . . . . . . 14 137 6.1.8. Reference Specification(s) . . . . . . . . . . . . . 15 138 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 15 139 6.2.1. Reference Definition . . . . . . . . . . . . . . . . 15 140 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 15 141 6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 15 142 6.3.1. Reference Implementation . . . . . . . . . . . . . . 15 143 6.3.2. Traffic Filter Criteria . . . . . . . . . . . . . . . 15 144 6.3.3. Measurement Timing . . . . . . . . . . . . . . . . . 16 145 6.3.4. Output Type(s) and Data Format . . . . . . . . . . . 16 146 6.3.5. Metric Units . . . . . . . . . . . . . . . . . . . . 16 147 6.3.6. Run-time Parameters and Data Format . . . . . . . . . 16 148 6.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 16 149 7. Example Passive RTP Lost Packet Count . . . . . . . . . . . . 16 150 8. Example BLANK Registry Entry . . . . . . . . . . . . . . . . 16 151 8.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 17 152 8.1.1. Element Identifier . . . . . . . . . . . . . . . . . 17 153 8.1.2. Metric Name . . . . . . . . . . . . . . . . . . . . . 17 154 8.1.3. Status . . . . . . . . . . . . . . . . . . . . . . . 17 155 8.1.4. Requester . . . . . . . . . . . . . . . . . . . . . . 17 156 8.1.5. Revision . . . . . . . . . . . . . . . . . . . . . . 17 157 8.1.6. Revision Date . . . . . . . . . . . . . . . . . . . . 17 158 8.1.7. Metric Description . . . . . . . . . . . . . . . . . 17 159 8.1.8. Reference Specification(s) . . . . . . . . . . . . . 17 160 8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 17 161 8.2.1. Reference Definition . . . . . . . . . . . . . . . . 17 162 8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 18 163 8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 18 164 8.3.1. Reference Implementation . . . . . . . . . . . . . . 18 165 8.3.2. Traffic Filter Criteria . . . . . . . . . . . . . . . 18 166 8.3.3. Measurement Timing . . . . . . . . . . . . . . . . . 18 167 8.3.4. Output Type(s) and Data Format . . . . . . . . . . . 18 168 8.3.5. Metric Units . . . . . . . . . . . . . . . . . . . . 18 169 8.3.6. Run-time Parameters and Data Format . . . . . . . . . 18 170 8.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 19 171 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 172 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 173 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 174 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 175 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 176 12.2. Informative References . . . . . . . . . . . . . . . . . 20 177 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 179 1. Introduction 181 The IETF has been specifying and continues to specify Performance 182 Metrics. While IP Performance Metrics (IPPM) is the working group 183 (WG) primarily focusing on Performance Metrics definition at the 184 IETF, other working groups, have also specified Performance Metrics: 186 The "Metric Blocks for use with RTCP's Extended Report Framework" 187 [XRBLOCK] WG recently specified many Performance Metrics related 188 to "RTP Control Protocol Extended Reports (RTCP XR)" [RFC3611], 189 which establishes a framework to allow new information to be 190 conveyed in RTCP, supplementing the original report blocks defined 191 in "RTP: A Transport Protocol for Real-Time Applications", 192 [RFC3550]. 194 The Benchmarking Methodology" [BMWG] WG proposed some Performance 195 Metrics as part of the benchmarking methodology. 197 The IP Flow Information eXport WG (IPFIX) [IPFIX] has existing and 198 proposed Information Elements related to performance metrics. 200 The Performance Metrics for Other Layers (PMOL) [PMOL], a 201 concluded working group, defined some Performance Metrics related 202 to Session Initiation Protocol (SIP) voice quality [RFC6035], as 203 well as guidelines for defining performance metrics [RFC6390] 205 It is expected that more and more Performance Metrics will be defined 206 in the future, not only IP based metrics, but also protocol-specific 207 ones and application-specific ones. 209 However, there is currently no Performance Metrics registry in IANA. 210 "Registry for Performance Metrics" 211 [I-D.manyfolks-ippm-metric-registry] defines a common registry for 212 metrics. The registry proposes the creation of two sub-registries, 213 one for active metrics and another for passive measurements. 215 There is a sister document for the active metric sub-registry in 216 "Active Performance Metric Sub-Registry" 217 [I-D.mornuley-ippm-registry-active]. 219 This document defines the Passive Performance Measurements Sub- 220 Registry of the Performance Metric Registry. This sub-registry will 221 contain passive performance metrics that meet the criteria set by the 222 IETF and review of the Performance Metric Experts. It is expected 223 that the majority of the metrics will have been defined elsewhere 224 within the IETF working groups such as IPPM, BMWG, IPFIX, etc. 226 This sub-registry is part of the Performance Metric Registry 227 [I-D.manyfolks-ippm-metric-registry] which specifies that all sub- 228 registries must contain at least the following common fields: the 229 identifier, the name, the status, the requester, the revision, the 230 revision date, the description for each entry, and the reference 231 specifications used as the foundation for the Registered Performance 232 Metric (see [I-D.manyfolks-ippm-metric-registry]). In addition to 233 these common fields the passive metrics sub-registry has additional 234 fields that provide the necessary background for interoperability and 235 adoption. 237 2. Background and Motivation: 239 (from draft-mornuley-ippm-registry-active): 241 One clear motivation for having such a registry is to allow a 242 controller to request a measurement agent to perform a measurement 243 using a specific metric (see [I-D.ietf-lmap-framework]). Such a 244 request can be performed using any control protocol that refers to 245 the value assigned to the specific metric in the registry. 246 Similarly, the measurement agent can report the results of the 247 measurement and by referring to the metric value it can unequivocally 248 identify the metric that the results correspond to. 250 There are several side benefits of having a registry with well-chosen 251 entries. First, the registry could serve as an inventory of useful 252 and used metrics that are normally supported by different 253 implementations of measurement agents. Second, the results of the 254 metrics would be comparable even if they are performed by different 255 implementations and in different networks, as the metric and method 256 is unambiguously defined. 258 3. Scope 260 [I-D.manyfolks-ippm-metric-registry] defines the overall structure 261 for a Performance Metric Registry and provides guidance for defining 262 a sub registry. 264 This document defines the Passive Performance Metrics Sub-registry; 265 passive metrics are those where the measurements are based the 266 observation of on user traffic. Specifically, this traffic has not 267 been generated for the purpose of measurement. 269 A row in the registry corresponds to one Registered Performance 270 Metric, with entries in the various columns specifying the metric. 271 Section 4 defines the additional columns for a Registered Passive 272 Performance Metric. 274 As discussed in [I-D.manyfolks-ippm-metric-registry], each entry 275 (row) must be tightly defined; the definition must leave open only a 276 few parameters that do not change the fundamental nature of the 277 measurement (such as source and destination addresses), and so 278 promotes comparable results across independent implementations. 279 Also, each registered entry must be based on existing reference RFCs 280 (or other standards) for performance metrics, and must be 281 operationally useful and have significant industry interest. This is 282 ensured by expert review for every entry before IANA action. 284 4. Passive Registry Categories and Columns 286 This section defines the categories and columns of the registry. 287 Below, categories are described at the 4.x heading level, and columns 288 are at the 4.x.y heading level. There are three categories, divided 289 into common information (from [I-D.manyfolks-ippm-metric-registry]), 290 metric definition and an open Comments section. 292 4.1. Common Registry Indexes and Information 294 This category has multiple indexes to each registry entry. It is 295 defined in [I-D.manyfolks-ippm-metric-registry]: 297 4.1.1. Identifier 299 Defined in [I-D.manyfolks-ippm-metric-registry]. Definition text to 300 be copied once source is stable. 302 4.1.2. Name 304 Defined in [I-D.manyfolks-ippm-metric-registry], same comment as 305 above. 307 4.1.3. Status 309 Defined in [I-D.manyfolks-ippm-metric-registry], same comment as 310 above. 312 4.1.4. Requester 314 Defined in [I-D.manyfolks-ippm-metric-registry], same comment as 315 above. 317 4.1.5. Revision 319 Defined in [I-D.manyfolks-ippm-metric-registry], same comment as 320 above. 322 4.1.6. Revision Date 324 Defined in [I-D.manyfolks-ippm-metric-registry], same comment as 325 above. 327 4.1.7. Description 329 Defined in [I-D.manyfolks-ippm-metric-registry], same comment as the 330 above. 332 4.1.8. Reference Specification(s) 334 Defined in [I-D.manyfolks-ippm-metric-registry], same comment as the 335 above. 337 4.2. Metric Definition 339 This category includes columns to prompt all necessary details 340 related to the metric definition, including the RFC reference and 341 values of input factors, called fixed parameters, which are left open 342 in the origin definition but have a particular value defined by the 343 performance metric. 345 4.2.1. Reference Definition 347 This entry provides references to relevant sections of the RFC(s) 348 defining the metric, as well as any supplemental information needed 349 to ensure an unambiguous definition for implementations. 351 4.2.2. Fixed Parameters 353 Fixed Parameters are input factors whose value must be specified in 354 the Registry. The measurement system uses these values. 356 Where referenced metrics supply a list of Parameters as part of their 357 descriptive template, a sub-set of the Parameters will be designated 358 as Fixed Parameters. For example, for RTP packet loss calculation 359 relies on the validation of a packet as RTP which is a multi-packet 360 validation controlled by MIN_SEQUENTIAL as defined by [RFC3550]. 361 Varying MIN_SEQUENTIAL values can alter the loss report and this 362 value could be set as a fixed parameter. 364 A Parameter which is Fixed for one Registry entry may be designated 365 as a Run-time Parameter for another Registry entry. 367 4.3. Method of Measurement 369 This category includes columns for references to relevant sections of 370 the RFC(s) and any supplemental information needed to ensure an 371 unambiguous method for implementations. 373 4.3.1. Reference Implementation 375 This entry provides references to relevant sections of the RFC(s) 376 describing the method of measurement, as well as any supplemental 377 information needed to ensure unambiguous interpretation for 378 implementations referring to the RFC text. 380 Specifically, this section should include pointers to pseudocode or 381 actual code that could be used for an unambigious implementation. 383 4.3.2. Traffic Filter Criteria 385 The filter specifies the traffic constraints that the passive 386 measurement method used is valid (or invalid) for. This includes 387 valid packet sampling ranges, width of valid traffic matches (eg. all 388 traffic on interface, UDP packets packets in a flow (eg. same RTP 389 session). 391 It is possible that the measurement method may not have a specific 392 limitation. However, this specific registry entry with it's 393 combination of fixed parameters implies restrictions. These 394 restrictions would be listed in this field. 396 4.3.3. Measurement Timing 398 Measurement timing defines the behavior of the measurement method 399 with respect to timing. 401 Is the measurement continuous? 403 If the measurement is sampled, what is the format of sampling? (eg 404 random packet, random time, etc.) 406 How long is the measurement interval? 408 4.3.4. Output Type(s) and Data Format 410 For entries which involve a stream and many singleton measurements, a 411 statistic may be specified in this column to summarize the results to 412 a single value. If the complete set of measured singletons is 413 output, this will be specified here. 415 Some metrics embed one specific statistic in the reference metric 416 definition, while others allow several output types or statistics. 418 Each entry in the output type column contains the following 419 information: 421 o Value: The name of the output type 423 o Data Format: provided to simplify the communication with 424 collection systems and implementation of measurement devices. 426 o Reference: the specification where the output type is defined 427 The output type defines the type of result that the metric produces. 428 It can be the raw result(s) or it can be some form of statistic. The 429 specification of the output type must define the format of the 430 output. In some systems, format specifications will simplify both 431 measurement implementation and collection/storage tasks. Note that 432 if two different statistics are required from a single measurement 433 (for example, both "Xth percentile mean" and "Raw"), then a new 434 output type must be defined ("Xth percentile mean AND Raw"). 436 4.3.5. Metric Units 438 The measured results must be expressed using some standard dimension 439 or units of measure. This column provides the units. 441 When a sample of singletons (see [RFC2330] for definitions of these 442 terms) is collected, this entry will specify the units for each 443 measured value. 445 4.3.6. Run-time Parameters and Data Format 447 Run-Time Parameters are input factors that must be determined, 448 configured into the measurement system, and reported with the results 449 for the context to be complete. However, the values of these 450 parameters is not specified in the Registry, rather these parameters 451 are listed as an aid to the measurement system implementor or user 452 (they must be left as variables, and supplied on execution). 454 Where metrics supply a list of Parameters as part of their 455 descriptive template, a sub-set of the Parameters will be designated 456 as Run-Time Parameters. 458 The Data Format of each Run-time Parameter SHALL be specified in this 459 column, to simplify the control and implementation of measurement 460 devices. 462 Examples of Run-time Parameters include IP addresses, measurement 463 point designations, start times and end times for measurement, and 464 other information essential to the method of measurement. 466 4.4. Comments and Remarks 468 Besides providing additional details which do not appear in other 469 categories, this open Category (single column) allows for unforeseen 470 issues to be addressed by simply updating this Informational entry. 472 5. Example Generalized Passive Octet Count Entry 474 tbd 476 This section is Informational. 478 This section gives an example registry entry for a generalized the 479 passive metric octetDeltaCount described in [RFC5102]. 481 5.1. Registry Indexes 483 This category includes multiple indexes to the registry entries, the 484 element ID and metric name. 486 5.1.1. Element Identifier 488 An integer having enough digits to uniquely identify each entry in 489 the Registry. 491 TBD by IANA. 493 5.1.2. Metric Name 495 A metric naming convention is TBD. 497 One possibility based on the proposal in 498 [I-D.manyfolks-ippm-metric-registry]: 500 Pas_IP-Octet-Delta-General 502 5.1.3. Status 504 Current 506 5.1.4. Requester 508 TBD 510 5.1.5. Revision 512 0 514 5.1.6. Revision Date 516 TBD 518 5.1.7. Metric Description 520 A delta count of the number of octets observed. 522 5.1.8. Reference Specification(s) 524 octetDeltaCount described in section 5.10.1 of [RFC5102] 526 5.2. Metric Definition 528 This category includes columns to prompt the entry of all necessary 529 details related to the metric definition, including the RFC reference 530 and values of input factors, called fixed parameters. 532 5.2.1. Reference Definition 534 octetDeltaCount described in section 5.10.1 of [RFC5102] 536 5.2.2. Fixed Parameters 538 As this is the generalised version of the IP delta count metric, 539 there are no fixed parameters. 541 5.3. Method of Measurement 543 5.3.1. Reference Implementation 545 For . 547
549 5.3.2. Traffic Filter Criteria 551 This measurement only covers IP packets and the IP payload (including 552 the IP header) of these packets. Non-IP packets (BPDUs, ISIS) will 553 not be accounted. Layer 2 overhead (Ethernet headers, MPLS, QinQ, 554 etc.) will also not be represented in the measurement. 556 5.3.3. Measurement Timing 558 This is a continous measurement of the IP octets seen in the traffic 559 selection scope (run-time parameter). 561 The measurement interval is a run time parameter. 563 There is no sampling. 565 5.3.4. Output Type(s) and Data Format 567 It is possible that multiple observation intervals are reported in a 568 single report. In such a case concatination of the interval reports 569 (deltaOctetCount, start-time, end-time) is allowed. 571 The delta octet count metric reports a observation start time and end 572 time. 574 o Value: observation-start-time and observation-end-time 576 o Data Format: 64-bit NTP Time-stamp Format 578 o Reference: section 6 of [RFC5905] 580 5.3.5. Metric Units 582 The measured results are expressed in octets with a data format of 583 unsigned64 as described in [RFC5102] 585 5.3.6. Run-time Parameters and Data Format 587 Run-time Parameters are input factors that must be determined, 588 configured into the measurement system, and reported with the results 589 for the context to be complete. 591 o samplingTimeInterval, length of time a single report covers. 592 unsigned32 microseconds [RFC5477] 594 o observationInterface, ifindex of interface to monitor. -1 595 represents all interfaces. -2 representings WAN facing and -3 596 represnets LAN facing. unsigned32. 598 o observation direction, unsigned8 where 0 represents incoming 599 traffic on interface, 1 outgoing and 2 represents both incoming 600 and outgoing. 602 5.4. Comments and Remarks 604 Additional (Informational) details for this entry 606 6. Example 5min Passive Egress Octet Count Entry on WAN Interface 608 tbd 610 This section is Informational. 612 This section gives an example registry entry for accounting of 613 outgoing WAN IP traffic the passive metric in terms of 614 octetDeltaCount, as described in [RFC5102]. 616 6.1. Registry Indexes 618 This category includes multiple indexes to the registry entries, the 619 element ID and metric name. 621 6.1.1. Element Identifier 623 An integer having enough digits to uniquely identify each entry in 624 the Registry. 626 TBD by IANA. 628 6.1.2. Metric Name 630 A metric naming convention is TBD. 632 One possibility based on the proposal in 633 [I-D.manyfolks-ippm-metric-registry]: 635 Pas_IP-Octet-Delta-WAN-egress 637 6.1.3. Status 639 Current 641 6.1.4. Requester 643 TBD 645 6.1.5. Revision 647 0 649 6.1.6. Revision Date 651 TBD 653 6.1.7. Metric Description 655 A delta count of the number of octets observed outgoing on WAN 656 interface. 658 6.1.8. Reference Specification(s) 660 octetDeltaCount described in section 5.10.1 of [RFC5102] 662 6.2. Metric Definition 664 This category includes columns to prompt the entry of all necessary 665 details related to the metric definition, including the RFC reference 666 and values of input factors, called fixed parameters. 668 6.2.1. Reference Definition 670 octetDeltaCount described in section 5.10.1 of [RFC5102] 672 6.2.2. Fixed Parameters 674 As this is a specific version of Pas_IP-Octet-Delta-General that 675 performs metering of all outgoing WAN traffic. 677 o samplingTimeInterval= 300000000, length of time a single report 678 covers. unsigned32 microseconds [RFC5477] 680 o observationInterface= -2, ifindex of interface to monitor. -1 681 represents all interfaces. -2 representings WAN facing and -3 682 represnets LAN facing. unsigned32. 684 o observation direction= 1, unsigned8 where 0 represents incoming 685 traffic on interface, 1 outgoing and 2 represents both incoming 686 and outgoing. 688 6.3. Method of Measurement 690 6.3.1. Reference Implementation 692 For . 694
696 6.3.2. Traffic Filter Criteria 698 This measurement only covers IP packets observed in the WAN outgoing 699 direction. The bytes counted are the IP payload (including the IP 700 header) of these packets. Non-IP packets (BPDUs, ISIS) will not be 701 accounted. Layer 2 overhead (Ethernet headers, MPLS, QinQ, etc.) 702 will also not be represented in the measurement. 704 6.3.3. Measurement Timing 706 This is a continous measurement of the IP octets seen in the traffic 707 selection scope (run-time parameter), each of a 5 minute duration. 709 There is no sampling. 711 6.3.4. Output Type(s) and Data Format 713 It is possible that multiple observation intervals are reported in a 714 single report. In such a case concatination of the interval reports 715 (deltaOctetCount, start-time, end-time) is allowed. 717 The delta octet count metric reports a observation start time and end 718 time. 720 o Value: observation-start-time and observation-end-time 722 o Data Format: 64-bit NTP Time-stamp Format 724 o Reference: section 6 of [RFC5905] 726 6.3.5. Metric Units 728 The measured results are expressed in octets with a data format of 729 unsigned64 as described in [RFC5102] 731 6.3.6. Run-time Parameters and Data Format 733 There are no run-time parameters for this registry entry. 735 6.4. Comments and Remarks 737 Additional (Informational) details for this entry 739 7. Example Passive RTP Lost Packet Count 741 tbd 743 8. Example BLANK Registry Entry 745 This section is Informational. (?) 747 This section gives an example registry entry for the . 750 8.1. Registry Indexes 752 This category includes multiple indexes to the registry entries, the 753 element ID and metric name. 755 8.1.1. Element Identifier 757 An integer having enough digits to uniquely identify each entry in 758 the Registry. 760 8.1.2. Metric Name 762 A metric naming convention is TBD. 764 8.1.3. Status 766 Current 768 8.1.4. Requester 770 TBD 772 8.1.5. Revision 774 0 776 8.1.6. Revision Date 778 TBD 780 8.1.7. Metric Description 782 A metric Description is TBD. 784 8.1.8. Reference Specification(s) 786 Section YY, RFCXXXX 788 8.2. Metric Definition 790 8.2.1. Reference Definition 792 < possible section reference> 794 8.2.2. Fixed Parameters 796 Fixed Parameters are input factors that must be determined and 797 embedded in the measurement system for use when needed. The values 798 of these parameters is specified in the Registry. 800 802 8.3. Method of Measurement 804 8.3.1. Reference Implementation 806 For . 808
810 8.3.2. Traffic Filter Criteria 812 814 8.3.3. Measurement Timing 816 < list timing requirements and limitations > 818 8.3.4. Output Type(s) and Data Format 820 The output types define the type of result that the metric produces. 822 o Value: 824 o Data Format: (There may be some precedent to follow here, but 825 otherwise use 64-bit NTP Time-stamp Format, see section 6 of 826 [RFC5905]). 828 o Reference:
830 8.3.5. Metric Units 832 The measured results are expressed in , 834
. 836 8.3.6. Run-time Parameters and Data Format 838 Run-time Parameters are input factors that must be determined, 839 configured into the measurement system, and reported with the results 840 for the context to be complete. 842 844 . 846 8.4. Comments and Remarks 848 Additional (Informational) details for this entry 850 9. Security Considerations 852 This registry has no known implications on Internet Security. 854 10. IANA Considerations 856 IANA is requested to create The Passive Performance Metric Sub- 857 registry within the Performance Metric Registry defined in 858 [I-D.manyfolks-ippm-metric-registry]. The Sub-registry will contain 859 the following categories and (bullet) columns, (as defined in section 860 3 above): 862 Common Registry Indexes and Info 864 o Identifier 866 o Name 868 o Status 870 o Requester 872 o Revision 874 o Revision Date 876 o Description 878 o Reference Specification(s) 880 Metric Definition 882 o Reference Definition 884 o Fixed Parameters 886 Method of Measurement 888 o Reference Implementation 889 o Traffic Filter Criteria 891 o Measurement Timing 893 o Output Type(s) and Data format 895 o Metric Units 897 o Run-time Parameters 899 Comments and Remarks 901 11. Acknowledgements 903 The authors thank the prior work of Al Morton, Marcelo Bagnulo and 904 Phil Eardley in "draft-mornuley-ippm-registry-active" which was used 905 both as a template for this document and source of text. 907 12. References 909 12.1. Normative References 911 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 912 Requirement Levels", BCP 14, RFC 2119, March 1997. 914 12.2. Informative References 916 [BMWG] IETF, , "Benchmarking Methodology (BMWG) Working Group, 917 http://datatracker.ietf.org/wg/bmwg/charter/", . 919 [I-D.ietf-lmap-framework] 920 Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 921 Aitken, P., and A. Akhter, "A framework for large-scale 922 measurement platforms (LMAP)", draft-ietf-lmap- 923 framework-03 (work in progress), January 2014. 925 [I-D.manyfolks-ippm-metric-registry] 926 Bagnulo, M., Claise, B., Eardley, P., and A. Morton, 927 "Registry for Performance Metrics", draft-manyfolks-ippm- 928 metric-registry-00 (work in progress), February 2014. 930 [I-D.mornuley-ippm-registry-active] 931 Morton, A., Bagnulo, M., and P. Eardley, "Active 932 Performance Metric Sub-Registry", draft-mornuley-ippm- 933 registry-active-00 (work in progress), February 2014. 935 [IPFIX] IETF, , "IP Flow Information eXport (IPFIX) Working Group, 936 http://datatracker.ietf.org/wg/ipfix/charter/", . 938 [PMOL] IETF, , "IP Performance Metrics for Other Layers (PMOL) 939 Working Group, 940 http://datatracker.ietf.org/wg/pmol/charter/", . 942 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 943 "Framework for IP Performance Metrics", RFC 2330, May 944 1998. 946 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 947 Jacobson, "RTP: A Transport Protocol for Real-Time 948 Applications", STD 64, RFC 3550, July 2003. 950 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 951 Protocol Extended Reports (RTCP XR)", RFC 3611, November 952 2003. 954 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 955 Meyer, "Information Model for IP Flow Information Export", 956 RFC 5102, January 2008. 958 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 959 Carle, "Information Model for Packet Sampling Exports", 960 RFC 5477, March 2009. 962 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 963 Time Protocol Version 4: Protocol and Algorithms 964 Specification", RFC 5905, June 2010. 966 [RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich, 967 "Session Initiation Protocol Event Package for Voice 968 Quality Reporting", RFC 6035, November 2010. 970 [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New 971 Performance Metric Development", BCP 170, RFC 6390, 972 October 2011. 974 [XRBLOCK] IETF, , "Metric Blocks for use with RTCP's Extended Report 975 Framework (XRBLOCK), 976 http://datatracker.ietf.org/wg/xrblock/charter/", . 978 Authors' Addresses 979 Aamer Akhter 980 Cisco Systems, Inc. 981 7025 Kit Creek Road 982 RTP, NC 27709 983 USA 985 Email: aakhter@cisco.com 987 Benoit Claise 988 Cisco Systems, Inc. 989 De Kleetlaan 6a b1 990 1831 Diegem 991 Belgium 993 Phone: +32 2 704 5622 994 Email: bclaise@cisco.com