idnits 2.17.1 draft-zheng-ippm-framework-passive-03.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 11, 2015) is 3333 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBD' is mentioned on line 495, but not defined == Unused Reference: 'I-D.li-mpls-seamless-mpls-mbb' is defined on line 510, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) == Outdated reference: A later version (-24) exists of draft-ietf-ippm-metric-registry-01 == Outdated reference: A later version (-14) exists of draft-ietf-lmap-framework-10 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Zheng 3 Internet-Draft Huawei Technologies 4 Intended status: Informational N. Elkins 5 Expires: August 15, 2015 Inside Products, Inc. 6 L. Deng 7 China Mobile 8 M. Ackermann 9 Blue Cross Blue Shield of Michigan 10 G. Mirsky 11 Ericsson 12 February 11, 2015 14 Framework for IP Passive Performance Measurements 15 draft-zheng-ippm-framework-passive-03 17 Abstract 19 This document describes the framework for passive measurement. In 20 particular, the differences between passive and active measurements 21 are analyzed, general considerations for both metric definition and 22 measurement methodology are discussed, and requirements for various 23 entities performing a given passive measurement task are described 24 according to a reference model. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 15, 2015. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Measurement Methods . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Active Measurement Method . . . . . . . . . . . . . . . . 3 64 3.2. Passive Measurement Method . . . . . . . . . . . . . . . 3 65 3.3. Hybrid Measurement Method . . . . . . . . . . . . . . . . 4 66 4. Measured Metrics . . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. Active Metrics . . . . . . . . . . . . . . . . . . . . . 4 68 4.2. Passive Metrics . . . . . . . . . . . . . . . . . . . . . 4 69 4.2.1. Passive Measurement Metric Elements . . . . . . . . . 6 70 5. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 6.1. Discussion of Errors / Unintended Consequences . . . . . 10 73 6.2. Control Protocol . . . . . . . . . . . . . . . . . . . . 10 74 6.3. Measurement Session Management . . . . . . . . . . . . . 10 75 6.4. Data Collected Correlation . . . . . . . . . . . . . . . 11 76 6.5. Measurement Configuration . . . . . . . . . . . . . . . . 11 77 6.6. Scalability and Robustness . . . . . . . . . . . . . . . 11 78 6.7. Privacy Issues . . . . . . . . . . . . . . . . . . . . . 11 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 83 9.2. Informational References . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 This document describes the framework for passive measurement. In 89 particular, the differences between passive and active measurements 90 are analyzed, general considerations for both metric definition and 91 measurement methodology are discussed, and requirements for various 92 entities performing a given passive measurement task are described 93 according to a reference model. 95 The IETF IP Performance Metrics (IPPM) working group first created a 96 framework for metric development in [RFC2330], which enabled 97 development of many fundamental metrics. [RFC2330] has been updated 98 once by [RFC5835], which describes a detailed framework for composing 99 and aggregating metrics originally defined in [RFC2330]. 101 2. Terminology 103 TBD 105 3. Measurement Methods 107 3.1. Active Measurement Method 109 Active Measurement Method: The process of measuring performance or 110 reliability parameters by the examination of traffic (IP Packets) 111 injected into the network, expressly for the purpose of measurement 112 by intended Measurement Point(s). 114 The packets in an Active Measurement Stream typically have fields 115 which are dedicated to and customized for measurement purposes. As 116 an example, a sequence number is a common information field used for 117 dedicated measurements, potentially at multiple measurement points. 119 Packet stream characteristics (e.g. Protocol Type) and specific 120 field information (e.g. IP Address), are known at the source and 121 usually communicated to the measurement point(s) as well. 123 Because traffic stream characteristics (e.g. number of packets), and 124 traffic type (e.g. protocol) are known to the Active Measurement 125 Point receivers, more efficient and focused operations are possible. 127 3.2. Passive Measurement Method 129 Passive Measurement Method: The process of measuring some performance 130 or reliability parameter associated with the existing traffic 131 (packets) on the network. 133 [Note: There are definitions for both active and passive measurement 134 methods in [I-D.ietf-ippm-metric-registry]. Further discussion and 135 coordination may be needed.] 137 Some passive methods observe and collect information on all packets 138 that pass the observation or Measurement Point(s), while other 139 Passive Methods filter the packets as a first step and only process 140 information on packets that match the filter criteria. 142 Passive Methods may be conducted at one or more Measurement Points. 143 Certain Metrics (e.g. latency across a particular network path), 144 require multiple Measurement Points and observed packets must include 145 sufficient information (e.g. sequence number), to correlate packets 146 from different observation points. 148 Passive traffic may be observed/measured at any point in an IP 149 session path, including source host, destination host and 150 middleboxes. Passive traffic may also be observed/measured by ""Out 151 of band"" devices, which do not participate in processing the actual 152 session traffic. This parallel approach typically has the least 153 effect upon network conditions and the session traffic being 154 measured. 156 3.3. Hybrid Measurement Method 158 Hybrid Measurement Method: Methods of Measurement which use a 159 combination of Active Methods and Passive Methods. 161 Hybrid Methods are not fully defined or delineated at this time. 162 Details and examples will be forthcoming. As this occurs, this 163 section will be expanded upon accordingly. 165 4. Measured Metrics 167 The de facto focus of RFC2330 is on active measurement. Although 168 many of the concepts discussed in RFC2330, metrics, measurement 169 methodology, errors with time apply to both passive and active 170 methods of measurement techniques, there are considerable differences 171 in terms of metric definition and measurement methodology for passive 172 measurement. 174 4.1. Active Metrics 176 Active Metrics: A set of standard measurements for evaluating network 177 performance or reliability, based upon the results of active traffic 178 (IP Packets), injected into the network by a source node, expressly 179 for the purpose of measurement and examined by one or more 180 Measurement Points. 182 Examples of Active Metrics include: Latency, Throughput, errors, etc. 184 4.2. Passive Metrics 186 Passive Metrics: A set of standard measurements for evaluating 187 network performance or reliability, based upon the results of Passive 188 traffic (IP Packets), existing on the network and examined by one or 189 more Measurement Points. 191 [Editor Note]: While Active and Passive Methods differ considerably, 192 the Metrics requirements and definitions for Active and Passive are 193 similar if not identical. Both can be described as defined reference 194 events, as packets pass defined reference points. These concepts are 195 consistent with and further elucidated by ITU-T Recommendation Y.1540 196 [Y.1540.2011]. 198 Therefore it makes sense to be agnostic to the distinction between 199 active and passive, with respect to Metrics. Distinctions or 200 different definitions for Active and Passive Metrics, should only be 201 created as needed, consistent with the IPPM Metric Registry 202 [I-D.ietf-ippm-metric-registry]. 204 Passive measurements may be used in scenarios where active 205 measurement alone is not enough or applicable. Since no extra in- 206 band traffic which may alter service and performance behavior is 207 introduced, passive measurement may be done during peak traffic. 209 Passive measurement is not without cost. In the best scenario, the 210 passive measurement point is external to the devices participating in 211 the network traffic. For example, a passive network TAP may be 212 placed at a switch to capture traffic. This would create very 213 little, if any, interference with in-band traffic. Alternatively, 214 care must be taken if a passive measurement technique creates load on 215 a participant in the network. For example, a packet trace taken at 216 one of the end host points may add load to the device thus 217 potentially changing the environment which it is measuring. The 218 benefits of this method for measurement and diagnostics must be 219 weighed with the costs. 221 For networks where charges are based on the amount of data sent, 222 passive measurement may be the first choice for end-to-end 223 measurement, as it does not introduce any extra expense to the 224 subscriber. In terms of Quality of Experience (QoE) measurement, 225 passive measurement is expected to be more accurate and helpful in 226 troubleshooting as it reflects the status of real application 227 traffic. 229 For passive measurement, the concepts of singleton, sample and 230 statistical, as defined in [RFC2330], also apply. However, there are 231 some differences. The singleton, sample, and statistical 232 measurements are those taken within the boundaries of captured 233 traffic. 235 4.2.1. Passive Measurement Metric Elements 237 In passive measurement, the most important aspects have to do with 238 the portion of reality which is actually measured at any point in 239 time. So, it may be useful to define some terms for passive 240 measurement. These are as follows: 242 1. Capture content: this is the type(s) of packet or metric found. 244 2. Capture distribution: this is the actual pattern of data in the 245 collected packets. The pattern or distribution may be Poisson 246 but it may also be bimodal, uniform, or skewed. For example, one 247 might see an FTP transfer as a relatively uniform distribution, a 248 TCP connection with a windowing issue may display a skewed 249 distribution, etc. 251 3. Capture limits: this is the way the set of packets or metrics are 252 selected. For example, one may decide to take a trace that 253 consists of 1,000 packets. Alternatively, one might take a 254 packet capture for 5 minutes with no regard to how many packets 255 are found. 257 4. Capture methodology: this is the area in which passive differs 258 most greatly from active methods. For example, [RFC2679], 259 section 3.6. Methodologies discusses the various techniques of 260 injecting test packets into the network. This is not applicable 261 to passive measurement. Passive measurement simply collects that 262 which exists. 264 5. Unruly Nature of Capture: With reality, there are no guarantees. 265 That is, if one imagines a passive sample to be a packet trace 266 taken at a host. If the metric one is looking for is IP/TCP 267 connectivity measured by a TCP three way handshake, then in 268 active measurement, one can be guaranteed to find that metric 269 because one has injected packets of that type into the stream. 270 In passive measurement, the capture may contain anywhere from 271 zero occurrences of the desired metric to many instances of the 272 desired metric. 274 6. Capture Selection: With active measurement, one may create 500 275 packets of a certain type and pick according to the sampling 276 distribution desired. 278 For example, [RFC2330] in the discussion of generating Poisson 279 distributions (11.1.3), discusses a method: 281 Method 1 is to proceed as follows: 283 1. Generate E1 and wait that long. 285 2. Perform a measurement. 287 3. Generate E2 and wait that long. 289 4. Perform a measurement. 291 5. Generate E3 and wait that long. 293 6. Perform a measurement ... 295 With passive measurement, one has no way of knowing if a particular 296 desired packet or packet sequence exists at all in the set of packets 297 captured. 299 Having said that, if there do exist many such packets, one may use a 300 random (or another) sampling method to pick the instances desired. 301 That is, if one has 100,000 instances of TCP three-way handshakes, 302 one may decide to randomly choose 50 to examine more closely. 304 Inherent Inequality of Active and Passive Measurements: due to the 305 nature of data traffic, depending on what metric is measured, it is 306 unlikely that it will have a random or Poisson distribution. Hence, 307 metrics created using Active methods and those generated using 308 Passive methods are likely to differ. It is not known at this point 309 whether that difference is significant or not. 311 [TBD: More discussion here on distributions and inequality] 313 . Point of View: In passive measurement, it matters greatly where 314 the measurement is being done. Point of view is critical. Passive 315 measurement only knows what it sees from its own perspective. 317 In troubleshooting problems using passive measurement, it is often 318 necessary to get multiple points of view. Let us take a simple case 319 of diagnosing packet loss from an end user perspective. If one takes 320 a packet trace at the client host, one sees that certain packets are 321 not being received. If one takes two packet traces at the same time 322 at the server and client, one sees that the server sends these 323 packets yet the client does not receive them. Hence, the problem 324 must be at a middle box. So, then, one must start taking traces at 325 client, server, and a trace point after the first middle box, etc. 327 The measurement techniques for passive measurement must accommodate 328 and facilitate such tasks. 330 Active measurement techniques know clearly the measurement point and 331 path because that is a part of the definition of the Active 332 measurement task. 334 5. Reference Model 336 This section describes the main functional components of the passive 337 measurement system, and the interactions between the components. 338 Some new terms are defined in this document and some are borrowed 339 from the LMAP Framework [I-D.ietf-lmap-framework]. 341 +---------------+ +---------------+ 342 | Measurement | Coordination | Measurement | 343 | Agent A |--------------| Agent B | 344 +---------------+ +---------------+ 345 ^ | ^ | 346 Control | | Report Control | | Report 347 | | +-----------------+ | 348 | +-----|-------------------+ | 349 | | | | 350 v v v v 351 +------------+ +------------+ 352 | Controller |---------| Collector | 353 +------------+ +------------+ 355 Figure 1: Passive Measurement Reference Model 357 Although there are considerable similarities between the proposed 358 reference model and the LMAP framework [I-D.ietf-lmap-framework], it 359 should be noted that the above architecture is provided as a more 360 general outline of an integral collection of functional components 361 collaborating in performing a specific instance of passive 362 measurement method. Various functions from LMAP framework in 363 performing a passive measurement task represent a specific way of 364 realizing the general model. 366 Controller: A entity that exchanges the Control of the Measurement 367 Task with the Measurement Entity, receives the Report from the 368 Collector and conducts the value calculation/derivation for the 369 metrics measured of the Measurement Task. When multiple Measurement 370 Entities are involved for a certain Measurement Task, Controller may 371 only have Control exchanged with one or some of the Measurement 372 Entities. 374 Collector: A entity that receives a Report from a Measurement Entity 375 and provides the Report to the Controller for metric calculation / 376 derivation. 378 Measurement Agent: An entity that exchanges the Control of the 379 Measurement Task with the Controller, performs Measurement Tasks and 380 sends the Report to Collector. When multiple Measurement Agents are 381 involved for a certain Measurement Task, Coordination may be required 382 between Measurement Entities. 384 Control: The collective description of information exchanged between 385 Controller and Measurement Agent, i.e. configurations, instructions, 386 states, etc. for a Measurement Agent to perform and Report 387 Measurement Tasks. 389 Coordination: [TBD. Discuss coordination with MAs and Controller] 391 Report: The set of Measurement Results and other associated 392 information as defined by the Control. 394 [Measurement Task]: The act that consists of the single operation of 395 the Measurement Method at a particular time and with all its Input 396 Parameters set to specific values. 398 [Measurement Result]: The output of a single Measurement Task (the 399 value obtained for the parameter of interest or Metric). 401 [Note: further discussion and clarifications regarding these borrowed 402 terms from LMAP framework are to be expected, with coordination with 403 [I-D.ietf-lmap-framework].] 405 6. Methodology 407 For a given set of well-defined metrics, a number of distinct 408 measurement methodologies may exist. Let us take One-way Packet Loss 409 as example. Packet loss over a path is the difference between the 410 number of packets transmitted at the starting interface of the path 411 and received at the ending interface of this path. In order to 412 perform packet loss measurements on a live traffic flow, different 413 methodologies exist. A partial list includes: 415 1. observation, e.g. Sequence Number, pros and cons 417 2. inserting a delimiting packet: Y.1731, RFC6374, pros and cons 419 3. altering the packet: 421 Note: This list is by no means exhaustive. The purpose is to point 422 out the variety of measurement techniques. 424 Note: A methodology for a metric should have the property that it is 425 repeatable: if the methodology is used multiple times under identical 426 conditions, it should result in consistent measurements. A 427 methodology for a metric should be scalable, robust and secured. 429 Following sections list the functional requirements and design 430 considerations of any passive measurement methodology. 432 6.1. Discussion of Errors / Unintended Consequences 434 As discussed in Section 6.3 Measurements, Uncertainties and Errors of 435 RFC2330, the measurement technique itself can introduce errors. 437 "consider the timing error due to measurement overheads within the 438 computer making the measurement, as opposed to delays due to the 439 Internet component being measured. The former is a measurement 440 error, while the latter reflects the metric of interest. Note that 441 one technique that can help avoid this overhead is the use of a 442 packet filter/sniffer, running on a separate computer that records 443 network packets and timestamps them accurately." 445 With some types of passive measurement, changing the packet may 446 create extra load on the network, change the characteristics of 447 network traffic, or change the nature of the problem itself. 448 Obviously, the benefits of the measurement must be such as to offset 449 the potential unintended consequences. 451 6.2. Control Protocol 453 As depicted by the reference model, there are different functional 454 components residing along an end-to-end path or within an ISP's 455 domain that cooperate to perform a specific passive measurement task. 456 This section describes the high level function requirements for the 457 control protocol between these collaborating components. 459 Note: LMAP is developing the control protocol between MA and 460 controller, here will be the discussion for control protocol between 461 measurement parties, i.e. MA to MA or MA to MP. 463 6.3. Measurement Session Management 465 A measurement session refers to the period of time in which 466 measurement for certain performance metrics is enabled over a 467 forwarding path. A measurement session may be started either 468 proactively or on demand. The methodology must indicate how the 469 measurement session is to be started. 471 6.4. Data Collected Correlation 473 When there is no coordination between MAs during a measurement 474 session, data collected on the upstream MA and downstream MA, e.g. 475 packet counts or timestamps, may be periodically report to the 476 Controller. And the value of the performance metrics are calculated/ 477 derived on the Controller. Certain synchronization mechanism is 478 required to ensure the data collected on upstream and downstream are 479 correlated. This may further require that the upstream and 480 downstream MEs have a certain time synchronization capability (e.g., 481 supporting the Network Time Protocol (NTP) [RFC5905], or the IEEE 482 1588 Precision Time Protocol (PTP) [IEEE.1588.2008].) 484 6.5. Measurement Configuration 486 A measurement session can be configured statically or dynamically. 487 The methods must be discussed. 489 6.6. Scalability and Robustness 491 [TBD] 493 6.7. Privacy Issues 495 [TBD] 497 7. Security Considerations 499 This document does not bring new security issues to IPPM. 501 8. Acknowledgements 503 The authors would like to thank Al Morton, Brian Trammell and Robert 504 Hamilton for their valuable comments. 506 9. References 508 9.1. Normative References 510 [I-D.li-mpls-seamless-mpls-mbb] 511 Li, Z., Li, L., Morillo, M., and T. Yang, "Seamless MPLS 512 for Mobile Backhaul", draft-li-mpls-seamless-mpls-mbb-01 513 (work in progress), February 2014. 515 [IEEE.1588.2008] 516 "Standard for a Precision Clock Synchronization Protocol 517 for Networked Measurement and Control Systems", IEEE 518 Standard 1588, March 2008. 520 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 521 "Framework for IP Performance Metrics", RFC 2330, May 522 1998. 524 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 525 Delay Metric for IPPM", RFC 2679, September 1999. 527 [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric 528 Composition", RFC 5835, April 2010. 530 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 531 Time Protocol Version 4: Protocol and Algorithms 532 Specification", RFC 5905, June 2010. 534 9.2. Informational References 536 [I-D.ietf-ippm-metric-registry] 537 Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A. 538 Akhter, "Registry for Performance Metrics", draft-ietf- 539 ippm-metric-registry-01 (work in progress), September 540 2014. 542 [I-D.ietf-lmap-framework] 543 Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 544 Aitken, P., and A. Akhter, "A framework for large-scale 545 measurement platforms (LMAP)", draft-ietf-lmap- 546 framework-10 (work in progress), January 2015. 548 [Y.1540.2011] 549 "Internet protocol data communication service - IP packet 550 transfer and availability performance parameters", ITU-T 551 Y.1540, March 2011. 553 Authors' Addresses 555 Lianshu Zheng 556 Huawei Technologies 557 China 559 Email: vero.zheng@huawei.com 561 Nalini Elkins 562 Inside Products, Inc. 563 USA 565 Email: nalini.elkins@insidethestack.com 566 Lingli Deng 567 China Mobile 568 China 570 Email: denglingli@chinamobile.com 572 Michael Ackermann 573 Blue Cross Blue Shield of Michigan 574 USA 576 Email: mike.ackermann@bcbsmi.com 578 Greg Mirsky 579 Ericsson 580 USA 582 Email: gregory.mirsky@ericsson.com