idnits 2.17.1 draft-trammell-ippm-hybrid-ps-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 285: '... session SHOULD be started either pr...' RFC 2119 keyword, line 297: '... of such packets SHOULD be reliable an...' RFC 2119 keyword, line 298: '... it MUST be possible to secure the d...' RFC 2119 keyword, line 303: '...collection agent MAY actively poll the...' RFC 2119 keyword, line 308: '... period of reporting SHOULD be able to...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The measurement methodology MUST not impose security risks on the network. For example, the monitoring nodes should be prevented from being exploited by third parties to control measurement sessions arbitrarily, which might make the nodes vulnerable for DDoS attacks. If dynamic configuration is supported, the measurement session control packets need to be encrypted and authenticated. -- The document date (February 14, 2014) is 3724 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5905' is mentioned on line 319, but not defined == Missing Reference: 'IEEE1588' is mentioned on line 320, but not defined -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 2680 (Obsoleted by RFC 7680) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Performance Measurement (ippm) B. Trammell 3 Internet-Draft ETH Zurich 4 Intended status: Informational L. Zheng 5 Expires: August 18, 2014 Huawei 6 S. Silva 7 LACNIC 8 M. Bagnulo 9 UC3M 10 February 14, 2014 12 Hybrid Measurement using IPPM Metrics 13 draft-trammell-ippm-hybrid-ps-01 15 Abstract 17 Hybrid measurement is the combination of metrics derived from passive 18 and active measurement to produce a measurement result. This 19 document discusses use cases for hybrid measurement using metrics 20 defined within the IPPM framework, and discusses requirements for the 21 definition of passive methodologies for selected IPPM metrics. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 18, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 1. Introduction 57 Hybrid measurement is the combination of metrics derived from passive 58 and active measurement to produce a measurement result. This 59 combination can be either spatial or temporal. For example, one way 60 delay to a given endpoint could be derived from passive measurements 61 from a sample of remote endpoints with which traffic is frequently 62 exchanged, and supplemented with active measurements from endpoints 63 with less frequent traffic, to build a "delay map" to a certain point 64 in the network. On the temporal side, loss or delay metrics could be 65 passively measured and stored over time to provide a baseline against 66 which actively-measured loss or delay metrics could be compared 67 during troubleshooting, in order to determine whether a specific path 68 or path segment is contributing to an observed performance problem. 70 The IPPM working group has produced a framework [RFC2330] for and 71 rich set of well-defined metrics (e.g. [RFC2679], [RFC2680]) for IP 72 performance measurement using active methods, and protocols for 73 measuring them. These metrics could form the basis of a platform for 74 hybrid measurement, provided that passively-derived metrics were 75 defined to compatible with the corresponding actively-derived 76 metrics; or alternately, provided that methodologies for passive 77 measurement can be defined for each of the existing active metrics to 78 be used, such that those methodologies produce values for the metrics 79 equivalent to the active methodology for the same metric parameters, 80 given some assumptions about the packet stream to be observed to 81 perform the passive measurement, and given tolerances for uncertainty 82 in the results. 84 2. Problem Statement 86 Complicating the definition of hybrid measurements is that passive 87 measurement must make do with the traffic that is observable, while 88 active measurement has some control over the traffic observed. 89 Measurements for some set of parameters are not possible if no 90 suitable traffic is observed, and the timing of the measurement 91 cannot be controlled. Placement of the observation points for 92 passive measurement along a path additionally introduces uncertainty 93 in the results. For example, passive one-way delay measurement could 94 be performed using two measurement points, one close to each 95 endpoint, with synchronized clocks, comparing the observation times 96 of packets via their hashes. This will not produce a value which is 97 directly comparable to a Type-P-One-way-Delay measured as specified 98 in section 3.6 of [RFC2679], because it will not account for the one- 99 way-delay from the source to the source-side observation point, or 100 from the destination-side observation point to the destination. Any 101 specification of hybrid measurement using IPPM metrics must handle 102 these complications. 104 The proposed specification entails: 106 o Definition of scenarios and requirements for hybrid measurement. 108 o Selection of existing IPPM metrics to be used for the active side 109 of hybrid measurements to meet these requirements. 111 o Definition of equivalent passive measurement methodologies for 112 each selected metric, specifically addressing the assumptions 113 about the observed packet stream which must hold for the metric to 114 be valid, and with a specific allowance for the measurement and/or 115 estimation of uncertainty due to uncontrollable conditions or 116 observation point placement. 118 o Definition of metrics based on these passive methodologies, or 119 modification of the definition of existing metrics to add passive 120 methodologies. 122 o Definition of methods for comparison between active and passive 123 metrics allowing for estimated uncertainty. 125 o Definition of methods for spatial and temporal composition of 126 active and passive metrics together allowing for estimated 127 uncertainty. 129 3. Selected IPPM Metrics 131 [EDITOR'S NOTE: this section will contain information on the metrics 132 selected for passive measurement, and initial discussion of passive 133 measurement methodologies for them. Metric definition will 134 presumably be left for a future document.] 136 3.1. Packet Loss 138 In order to perform packet loss measurements on a live traffic flow, 139 different approaches exist. An approach is to count the number of 140 packets sent on one end, and the number of packets received on the 141 other end. Packet loss over a path is the difference between the 142 number of packets transmitted at the starting interface of the path 143 and received at the ending interface of this path. 145 3.1.1. Passive Measurement Method 147 In order to count the number of packets sent and received and to 148 compare two counters, it is required that the two counters refer 149 exactly to the same set of packets. One difficulty is it is hard to 150 determine exactly when to read the counter since a flow is 151 continuous. A possible solution is to virtually split the flow in 152 consecutive blocks by periodically inserting a delimiting packet, so 153 that each counter refers exactly to the same block of packets. 154 However, delimiting the flow using specific packets requires 155 generating additional packets within the flow and requires the 156 equipment to be able to process those packets. In addition, the 157 method is vulnerable to out of order reception and the loss of 158 delimiting packets. 160 An existing method by "coloring" IP packets for performance 161 measurement is introduced in [I-D.tempia-opsawg-p3m]. This "colored" 162 based approach doesn't use delimiting packets. Instead, it "colours" 163 the packets so that the packets belonging to the same block will have 164 the same "colour", while consecutive blocks will have different 165 colours. Each change of colour represents a sort of auto- 166 synchronization signal that guarantees the consistency of 167 measurements taken by different devices along the path. 169 3.2. One-way Delay 171 IPPM has defined a protocol for active one way delay measurement 172 OWAMP in [RFC4656] It consists of a control protocol for negotiating 173 measurement sessions and a data plane protocol for test packets. 174 OWAMP is an active protocol meaning that the one delay is measured 175 for artificial packets the are generated for this purpose. 177 It would be natural to pursue passive and/or hybrid approaches for 178 measuring one way delay. In this case, the goal would be to measure 179 one way delay for packets that are flowing through the network. This 180 can be achieved by defining two observation points that will record 181 the packets they see and the corresponding timestamps. This 182 information will be used to determine the one way delay of the 183 observed packets, similarly than in the active measurement approach. 184 In order to do that, it is necessary to identify which packets are 185 the ones that the measurement will be performed with. One way to do 186 this is to define a certain flow of packets and then record some 187 fields of the packets that are unlikely to change during its journey 188 through their journey between the observation points. One the 189 packets have been properly identified, and the timestamp information 190 about them has been recorded in the observation points, it should be 191 possible to calculate the one way delay for the observed packets. 193 If defining a passive metric for one way delay is deemed interesting, 194 it would be then needed to perform a gap analysis for the additional 195 protocols that are needed for this. As the passive approach would 196 also need to negotiate measurement sessions, it may be worth 197 exploring the re use of OWAMP for this. Similarly, both observation 198 points should agree what packet flow will be used for the 199 measurement, so additional negotiation is needed. Finally, IPFIX 200 could be used to report the results so that the actual delay can be 201 calculated. 203 An additional exercise that would be then relevant is to understand 204 how comparable are measurements obtained through the active and 205 passive measurements. In particular, depending on the packet 206 frequency, it may or may not be possible to achieve the different 207 packet streams available in active measurements. 209 A hybrid approach for measuring one way delay seems attractive as it 210 would be possible to measure reliably one way delay reusing the 211 packets available in the network when they exist and generating 212 artificial traffic when they don't exist. This requires careful 213 consideration in order to obtain the desired packet streams and it is 214 likely to require additional control protocol to specific the hybrid 215 measurement. 217 3.3. Round-trip Delay 219 Round-trip delay is used to measure the expected time for network 220 interaction between two hosts on a network; conceptually, it is 221 equivalent to Delay in each direction between the two hosts. 223 Active measurement of round-trip delay as defined in [RFC2681] 224 requires the observation of test packets transmitted in both 225 directions between two endpoints across a network, a "source" host, 226 which sends the first packet, and a "destination" host, which 227 receives the first test packet and sends a test packet back to the 228 source in reply. The round-trip delay is then calculated as the 229 difference between the time at which the reply is received at the 230 source and the time at which the original test packet was sent from 231 this same source. 233 IPPM has defined the Two-Way Active Measurement Protocol (TWAMP) 234 [RFC5357] for round trip delay measurement. TWAMP is essentially an 235 extension of OWAMP for the IPPM round-trip delay metric. Like OWAMP, 236 TWAMP consists of a control protocol to negotiate active performance 237 measurement sessions, and a test protocol for transmission of actual 238 test packets. 240 TWAMP is defined for active performance metrics, which means that the 241 Round-trip delay is measured for packets the are generated 242 specifically for this purpose. 244 3.3.1. Passive Measurement Method 246 The passive approach for measuring Round-trip delay would consist on 247 measuring this delay for existent packets in contrast with the active 248 approach in which test packets are generated. Similarly to the 249 method used for measuring One-way Delay, for Round-trip Delay it 250 would be needed to define two observation points that will record the 251 packets they see and the corresponding timestamps. 253 The procedure for passive measurement of round-trip delay is similar 254 to the procedure for active measurement: a packet sent from a source 255 to a destination is recorded; that packet causes the destination to 256 send a reply back to the source. This reply is also recorded. The 257 packets are identifiable at the source in order to correlate each 258 packet of the round trip in order to calculate a delay. 260 There are two potential architectures here; one utilizing a source 261 Observation Point (OP) placed topologically close to the source of 262 traffic, and one utilizing an additional destination OP placed 263 topologically close to the destination of traffic. 265 In order to be able to measure the Round-trip Delay of the observed 266 packets, it would be necessary to identify which packets will be used 267 to perform the measurement. 269 4. Methodology 271 For certain performance metrics, many passive measurement 272 methodologies may exist. This section give the fuctional reqirements 273 and design considerations of the passive measurement methodology. 275 4.1. Measurement Session Management 277 A measurement session refers to the period of time in which 278 measurement for certain performance metrics is enabled over a 279 forwarding path. When an interface on the measurement node is 280 activated, the interfaces start collecting statistics. When both the 281 upstream and downstream measurement interfaces are activated, the 282 measurement session starts. During a measurement session, data from 283 two active interfaces are periodically collected and the performance 284 metrics, such as loss rate or delay, are derived. A measurement 285 session SHOULD be started either proactively or on demand. 287 4.1.1. Measurement Configuration 289 A measurement session can be configured statically. In this case, 290 network operators activate the two interfaces or configure their 291 parameter settings on the relevant nodes either manually or 292 automatically through agents of network management system (NMS). 293 Alternatively, a measurement session can be configured dynamically. 294 In this case, an interface may coordinate another interface on its 295 forwarding path to start or stop a session. Accordingly, the format 296 and process routines of the measurement session control packets need 297 to be specified. The delivery of such packets SHOULD be reliable and 298 it MUST be possible to secure the delivery of such packets. 300 4.2. Measurement Result Report 302 Performance reports contain streams of measurement data over a period 303 of time. A data collection agent MAY actively poll the monitoring 304 nodes and collect the measurement reports from all active interfaces. 305 Alternatively, the monitoring nodes might be configured to upload the 306 reports to the specific data collection agents once the data become 307 available. To save bandwidth, the content of the reports might be 308 aggregated and compressed. The period of reporting SHOULD be able to 309 be configured or controlled by rate limitation mechanisms. 311 4.3. Synchronization 313 During a measurement session, data from the active upstream and 314 downstream interfaces are periodically collected and the performance 315 metrics are derived. Certain synchronization mechenism is required 316 to ensure the data are correlated. This may further requires that 317 the upstream and downstream interfaces having a certain time 318 synchronization capability (e.g., supporting the Network Time 319 Protocol (NTP) [RFC5905], or the IEEE 1588 Precision Time Protocol 320 (PTP) [IEEE1588].) For packet delay measurement, this requirement 321 for time synchronization is already present. 323 4.4. Scalability 325 The measurement methodology MUST be scalable. A service provider 326 production network usually comprises of thousands of nodes. Given 327 the scale, the collecting, processing and reporting overhead of 328 performance measurement data SHOULD NOT overwhelm either monitoring 329 nodes or management nodes. The volume of reporting traffic should be 330 reasonable and not cause any network congestion. 332 4.5. Robustness 334 The measurements MUST be independent of the failure of the underlying 335 network. For example, the correct measurement result SHOULD be 336 generated even if some measurement coordinating packets are lost; 337 invalid performance reports should be able to be identified in case 338 that the underlying network is undergoing drastic changes. If 339 dynamic measurement configuration is supported, the delivery of 340 measurement session control packets SHOULD be reliable so that the 341 measurement sessions can be started, ended and performed in a 342 predictable manner. 344 4.6. Security 346 The measurement methodology MUST not impose security risks on the 347 network. For example, the monitoring nodes should be prevented from 348 being exploited by third parties to control measurement sessions 349 arbitrarily, which might make the nodes vulnerable for DDoS attacks. 350 If dynamic configuration is supported, the measurement session 351 control packets need to be encrypted and authenticated. 353 5. Security Considerations 355 [EDITOR'S NOTE: this section will discuss general security 356 considerations of using passive measurement for performance, both on 357 the potential for attacks against the measurement system as well as 358 the potential for privacy or security threats posed by the 359 measurement system itself.] 361 6. IANA Considerations 363 This document contains no considerations for IANA. 365 7. References 367 7.1. Normative References 369 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 370 "Framework for IP Performance Metrics", RFC 2330, May 371 1998. 373 7.2. Informative References 375 [I-D.tempia-opsawg-p3m] 376 Capello, A., Cociglio, M., Castaldelli, L., and A. Bonda, 377 "A packet based method for passive performance 378 monitoring", draft-tempia-opsawg-p3m-04 (work in 379 progress), February 2014. 381 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 382 Delay Metric for IPPM", RFC 2679, September 1999. 384 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 385 Packet Loss Metric for IPPM", RFC 2680, September 1999. 387 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 388 Delay Metric for IPPM", RFC 2681, September 1999. 390 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 391 Zekauskas, "A One-way Active Measurement Protocol 392 (OWAMP)", RFC 4656, September 2006. 394 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 395 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 396 RFC 5357, October 2008. 398 Authors' Addresses 400 Brian Trammell 401 Swiss Federal Institute of Technology Zurich 402 Gloriastrasse 35 403 8092 Zurich 404 Switzerland 406 Phone: +41 44 632 70 13 407 Email: trammell@tik.ee.ethz.ch 409 Lianshu Zheng 410 Huawei Technologies 411 China 413 Email: vero.zheng@huawei.com 415 Sofia Silva 416 LACNIC 417 Uruguay 419 Email: sofia@lacnic.net 420 Marcelo Bagnulo 421 Universidad Carlos III de Madrid 422 Av. Universidad 30 423 Leganes 424 Spain 426 Email: bagnulo@it.uc3m.es