idnits 2.17.1 draft-chen-ippm-coloring-based-ipfpm-framework-06.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 17, 2016) is 2962 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 569 -- Looks like a reference, but probably isn't: '2' on line 502 == Unused Reference: 'RFC2460' is defined on line 705, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 709, but no explicit reference was found in the text == Unused Reference: 'RFC3260' is defined on line 719, but no explicit reference was found in the text == Unused Reference: 'RFC4656' is defined on line 723, but no explicit reference was found in the text == Unused Reference: 'RFC5357' is defined on line 728, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-chen-ippm-ipfpm-report-00 == Outdated reference: A later version (-12) exists of draft-ietf-bier-mpls-encapsulation-03 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Chen, Ed. 3 Internet-Draft L. Zheng, Ed. 4 Intended status: Informational Huawei Technologies 5 Expires: September 18, 2016 G. Mirsky, Ed. 6 Ericsson 7 G. Fioccola, Ed. 8 Telecom Italia 9 T. Mizrahi, Ed. 10 Marvell 11 March 17, 2016 13 IP Flow Performance Measurement Framework 14 draft-chen-ippm-coloring-based-ipfpm-framework-06 16 Abstract 18 This document specifies a measurement method, the IP flow performance 19 measurement (IPFPM). With IPFPM, data packets are marked into 20 different blocks of markers by changing one or more bits of packets. 21 No additional delimiting packet is needed and the performance is 22 measured in-service and in-band without the insertion of additional 23 traffic. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 18, 2016. 48 Copyright Notice 50 Copyright (c) 2016 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Overview and Concept . . . . . . . . . . . . . . . . . . . . 4 68 4. Consideration on Marking Bits . . . . . . . . . . . . . . . . 6 69 5. Reference Model and Functional Components . . . . . . . . . . 6 70 5.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 6 71 5.2. Measurement Control Point . . . . . . . . . . . . . . . . 7 72 5.3. Measurement Agent . . . . . . . . . . . . . . . . . . . . 7 73 6. Period Number . . . . . . . . . . . . . . . . . . . . . . . . 8 74 7. Re-ordering Tolerance . . . . . . . . . . . . . . . . . . . . 8 75 8. Packet Loss Measurement . . . . . . . . . . . . . . . . . . . 9 76 9. Packet Delay Measurement . . . . . . . . . . . . . . . . . . 10 77 10. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 11 78 10.1. Synchronization for the Period Number . . . . . . . . . 12 79 10.2. Synchronization for Delay Measurement . . . . . . . . . 12 80 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 82 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 83 14. Contributing Authors . . . . . . . . . . . . . . . . . . . . 14 84 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 15.1. Normative References . . . . . . . . . . . . . . . . . . 15 86 15.2. Informative References . . . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 89 1. Introduction 91 Performance Measurement (PM) is an important tool for service 92 providers, used for Service Level Agreement (SLA) verification, 93 troubleshooting (e.g., fault localization or fault delimitation) and 94 network visualization. Measurement methods could be roughly put into 95 two categories - active measurement methods and passive measurement 96 methods. Active methods measure performance or reliability 97 parameters by the examination of traffic (IP Packets) injected into 98 the network, expressly for the purpose of measurement by the intended 99 measurement points. In contrast, passive method measures some 100 performance or reliability parameters associated with the existing 101 traffic (packets) on the network. Both passive and active methods 102 have their strengths and should be regarded as complementary. There 103 are certain scenarios where active measurement alone is not enough or 104 applicable and passive measurement is 105 desirable[I-D.deng-ippm-passive-wireless-usecase]. 107 With active measurement methods, the rate, numbers and interval 108 between the injected packets may affect the accuracy of the results. 109 Moreover, injected test packets are not always guaranteed to be in- 110 band with the data traffic in the pure IP network due to Equal Cost 111 Multi-Path (ECMP). 113 The Multiprotocol Label Switching (MPLS) PM protocol [RFC6374] for 114 packet loss could be considered an example of a passive performance 115 measurement method. By periodically inserting auxiliary Operations, 116 Administration and Maintenance (OAM) packets, the traffic is 117 delimited by OAM packets into consecutive blocks, and the receivers 118 count the packets and calculate the packets lost in each block. 119 However, solutions like [RFC6374] depend on the fixed positions of 120 the delimiting OAM packets for packets counting, and thus are 121 vulnerable to out-of-order arrival of packets. This could happen 122 particularly with out-of-band OAM channels, but might also happen 123 with in-band OAM because of the presence of multipath forwarding 124 within the network. Out of order delivery of data and the delimiting 125 OAM packets can give rise to inaccuracies in the performance 126 measurement figures. The scale of these inaccuracies will depend on 127 data speeds and the variation in delivery, but with out-of-band OAM, 128 this could result in significant differences between real and 129 reported performance. 131 This document specifies a different measurement method, the IP flow 132 performance measurement (IPFPM). With IPFPM, data packets are marked 133 into different blocks of markers by changing one or more bits of 134 packets without altering normal processing in the network. No 135 additional delimiting packet is needed and the performance can be 136 measured in-service without the insertion of additional traffic. 137 Furthermore, because marking-based IP performance measurement does 138 not require extra OAM packets for traffic delimitation, it can be 139 used in situations where there is packet re-ordering. IP Flow 140 Information eXport (IPFIX) [RFC7011] is used for reporting the 141 measurement data of IPFPM to a central calculation element for 142 performance metrics calculation. Several new Information Elements of 143 IPFIX are defined for IPFPM. These are described in the companion 144 document [I-D.chen-ippm-ipfpm-report]. 146 2. Terminology 148 The acronyms used in this document will be listed here. 150 3. Overview and Concept 152 The concept of marking IP packets for performance measurement is 153 described in [I-D.tempia-opsawg-p3m]. Marking of packets in a 154 specific IP flow to different colors divides the flows into different 155 consecutive blocks. Packets in a block have same marking and 156 consecutive blocks will have different markings. This enables the 157 measuring node to count and calculate packet loss and/or delay based 158 on each block of markers without any additional auxiliary OAM 159 packets. The following figure (Figure 1) is an example that 160 illustrates the different markings in a single IP flow in alternate 0 161 and 1 blocks. 163 | 0 Block | 1 Block | 0 Block | 1 Block | 164 000000000000 111111111111 000000000000 111111111111 166 Figure 1: Packet Marking 168 For packet loss measurement, there are two ways to mark packets: 169 fixed packet numbers or fixed time period for each block of markers. 170 This document considers only fixed time period method. The sender 171 and receiver nodes count the transmitted and received packets/octets 172 based on each block of markers. By counting and comparing the 173 transmitted and received packets/octets, the packet loss can be 174 computed. 176 For packet delay measurement, there are three solutions. One is 177 similar to the packet loss, it still marks the IP flows to different 178 blocks of markers and uses the time of the marking change as the 179 reference time for delay calculations. This solution requires that 180 there must not be any out-of-order packets; otherwise, the result 181 will not be accurate. Because it uses the first packet of each block 182 of markers for delay measurement, if there is packet reordering, the 183 first packet of each block at the sender will be probably different 184 from the first packet of the block at the receiver. An alternate way 185 is to periodically mark a single packet in the IP flow. Within a 186 given time period, there is only one packet that can be marked. The 187 sender records the timestamp when the marked packet is transmitted, 188 and the receiver records the timestamp when receiving the marked 189 packet. With the two timestamps, the packet delay can be computed. 191 An additional method consists of taking into account the average 192 arrival time of the packets within a single block (i.e. the same 193 block of markers used for packet loss measurement). The network 194 device locally sums all the timestamps and divides by the total 195 number of packets received, so the average arrival time for that 196 block of packets can be calculated. By subtracting the average 197 arrival times of two adjacent devices it is possible to calculate the 198 average delay between those nodes. This method is robust to out of 199 order packets and also to packet loss (only an error is introduced 200 dependent from the number of lost packets). 202 A centralized calculation element Measurement Control Point (MCP) is 203 introduced in Section 5.2 of this document, to collect the packet 204 counts and timestamps from the senders and receivers for metrics 205 calculation. The IP Flow Information eXport (IPFIX) [RFC7011] 206 protocol is used for collecting the performance measurement statistic 207 information [I-D.chen-ippm-ipfpm-report]. For the statistic 208 information collected, the MCP has to know exactly what packet pair 209 counts (one from the sender and the other is from the receiver) are 210 based on the same block of markers and a pair of timestamps (one from 211 the sender and the other is from the receiver) are based on the same 212 marked packet. In case of average delay calculation the MCP has to 213 know in addition to the packet pair counters also the pair of average 214 timestamps for the same block of markers. The "Period Number" based 215 solution Section 6 is introduced to achieve this. 217 For a specific IP flow to be measured, there may be one or more 218 upstream and downstream Measurement Agents (MAs)( Section 5.3). An 219 IP flow can be identified by the Source IP (SIP) and Destination IP 220 (DIP) addresses, and it may combine the SIP and DIP with any or all 221 of the Protocol number, the Source port, the Destination port, and 222 the Type of Service (TOS) to identify an IP flow. For each flow, 223 there will be a flow identifier that is unique within a certain 224 administrative domain. To simplify the process description, the 225 flows discussed in this document are all unidirectional. A 226 bidirectional flow can be seen as two unidirectional flows. 228 IFPFM supports the measurement of a Multipoint-to-Multipoint (MP2MP) 229 model, which satisfies all the scenarios that include Point-to-Point 230 (P2P), Point-to-Multipoint (P2MP), Multipoint-to-Point (MP2P), and 231 MP2MP. The P2P scenario is obvious and can be used anywhere. P2MP 232 and MP2P are very common in mobile backhaul networks. For example, a 233 Cell Site Gateway (CSG) that uses multi-homing to two Radio Network 234 Controller (RNC) Site Gateways (RSGs) is a typical network design. 235 When there is a failure, there is a requirement to monitor the flows 236 between the CSG and the two RSGs hence to determine whether the fault 237 is in the transport network or in the wireless network (typically 238 called "fault delimitation"). This is especially useful in the 239 situation where the transport network belongs to one service provider 240 and the wireless network belongs to other service providers. 242 4. Consideration on Marking Bits 244 The marking bits selection is encapsulation-related; different bits 245 for marking should be allocated by different encapsulations. This 246 document does not define any marking bits. The marking bits 247 selection for specific encapsulations will be defined in the relevant 248 documents. In general, at least one marking bit is required to 249 support loss and delay measurement. Specifically, if the second 250 delay measurement solution is used (see Section 3), then at least two 251 marking bits are needed; one bit for packet loss measurement, the 252 other for packet delay measurement. 254 In theory, so long as there are unused bits that could be allocated 255 for marking purpose, the marking-based measurement mechanism can be 256 applied to any encapsulation. It is relatively easier for new 257 encapsulations to allocate marking bits. An example of such a case 258 is Bit Indexed Explicit Replication (BIER). Two marking bits for 259 passive performance measurement has been allocated in the BIER 260 encapsulation [I-D.ietf-bier-mpls-encapsulation] (Section 3.). 261 However, for sophisticated encapsulations, it is harder or even 262 impossible to allocate bits for marking purpose. The IPv4 263 encapsulation is one of the examples. The IPv6 encapsulation is in a 264 similar situation, but for IPv6, an alternative solution is to 265 leverage the IPv6 extension header for marking. 267 Since marking will directly change some bits (of the header) of the 268 real traffic packets, the marking operations MUST NOT affect the 269 forwarding and processing of packets. Specifically, the marking bits 270 MUST NOT be used for ECMP hashing. In addition, to increase the 271 accuracy of measurement, hardware-based implementation is desired. 272 Thus, the location of the marking bits SHOULD be easy for hardware 273 implementation. For example, the marking bits would be best located 274 at fixed positions in a packet header. 276 5. Reference Model and Functional Components 278 5.1. Reference Model 280 The outline of the measurement system of large-scale measurement 281 platforms (LMAP) is introduced in [I-D.ietf-lmap-framework]. It 282 describes the main functional components of the LMAP measurement 283 system, and the interactions between the components. The Measurement 284 Agent (MA) of IPFPM could be considered equivalent to the MA of LMAP. 285 The Measurement Control Point (MCP) of IPFPM could be considered as 286 the combined function of Controller and Collector. The IP Flow 287 Information eXport (IPFIX) [RFC7011] protocol is used for collecting 288 the performance measurement data on the MAs and reporting to the MCP. 289 The details are specified in the companion document 290 [I-D.chen-ippm-ipfpm-report]. The control between MCP and MAs are 291 left for future study. Figure 2 presents the reference model of 292 IPFPM. 294 +-----+ 295 +------| MCP |------+ 296 | +-----+ | 297 +-----+ | +---/ \---+ | +-----+ 298 | MA1 |---+ | | +---| MA3 | 299 +-----+ | | +-----+ 300 +-----+ | | +-----+ 301 | MA2 |------+ +------| MA4 | 302 +-----+ +-----+ 303 Figure 2: IPFPM Reference Model 305 5.2. Measurement Control Point 307 The Measurement Control Point (MCP) is responsible for collecting the 308 measurement data from the Measurement Agents (MAs) and calculating 309 the performance metrics according to the collected measurement data. 310 For packet loss, based on each block of markers, the difference 311 between the total counts received from all upstream MAs and the total 312 counts received from all downstream MAs are the lost packet numbers. 313 The MCP must make sure that the counts from the upstream MAs and 314 downstream MAs are related to the same marking/packets block. For 315 packet delay (e.g., one way delay), the difference between the 316 timestamps from the downstream MA and upstream MA is the packet 317 delay. Similarly to packet loss, the MCP must make sure the two 318 timestamps are based on the same marked packet. This document 319 introduces a Period Number (PN) based synchronization mechanism which 320 is discussed in details in Section 6. 322 5.3. Measurement Agent 324 The Measurement Agent (MA) executes the measurement actions (e.g., 325 marks the packets, counts the packets, records the timestamps, etc.), 326 and reports the data to the Measurement Control Point (MCP). Each MA 327 maintains two timers, one (C-timer, used at upstream MA) is for 328 marking change, the other (R-timer, used at downstream MA) is for 329 reading the packet counts and timestamps. The two timers have the 330 same time interval but are started at different times. An MA can be 331 either an upstream or a downstream MA: the role is specific to an IP 332 flow to be measured. For a specific IP flow, the upstream MA will 333 change the marking and read the packet counts and timestamps when the 334 C-timer expires, the downstream MA just reads the packet counts and 335 timestamps when the R-timer expires. The MA may delay the reading 336 for a certain time period when the R-timer expires, in order to be 337 tolerant to a certain degree of packet re-ordering. Section 7 338 describes this in details. 340 For each Measurement Task (corresponding to an IP flow) 341 [I-D.ietf-lmap-framework], an MA maintains a pair of packet counters 342 and a timestamp counter for each block of markers. As for the pair 343 of packet counters, one is for counting packets and the other is for 344 counting octets. 346 6. Period Number 348 When data is collected on the upstream MA and downstream MA, e.g., 349 packet counts or timestamps, and periodically reported to the MCP, a 350 certain synchronization mechanism is required to ensure that the 351 collected data is correlated. Synchronization aspects are further 352 discussed in Section 10. This document introduces the Period Number 353 (PN) to help the MCP to determine whether any two or more packet 354 counts (from distributed MAs) are related to the same block of 355 markers, or any two timestamps are related to the same marked packet. 357 Period Numbers assure the data correlation by literally splitting the 358 packets into different measurement periods. The PN is generated each 359 time an MA reads the packet counts or timestamps, and is associated 360 with each packet count and timestamp reported to the MCP. For 361 example, when the MCP sees two PNs associated with two packet counts 362 from an upstream and a downstream MA, it assumes that these two 363 packet counts correspond to the same measurement period by the same 364 PN, i.e., that these two packet counts are related to the same block 365 of markers. The assumption is that the upstream and downstream MAs 366 are time synchronized. This requires the upstream and downstream MAs 367 to have a certain time synchronization capability (e.g., the Network 368 Time Protocol (NTP) [RFC5905], or the IEEE 1588 Precision Time 369 Protocol (PTP) [IEEE1588]), as further discussed in Section 10. The 370 PN is calculated as the modulo of the local time (when the counts or 371 timestamps are read) and the interval of the marking time period. 373 7. Re-ordering Tolerance 375 In order to allow for a certain degree of packet re-ordering, the 376 R-timer on downstream MAs should be started delta-t (Dt) later than 377 the C-timer is started. Dt is a defined period of time and should 378 satisfy the following conditions: 380 (Time-L - Time-MRO ) < Dt < (Time-L + Time-MRO ) 382 Where 383 Time-L: the link delay time between the sender and receiver; 385 Time-MRO: the maximum re-ordering time difference; if a packet is 386 expected to arrive at t1 but actually arrives at t2, then the Time- 387 MRO = | t2 - t1|. 389 Thus, the R-timer should be started at "t + Dt" (where t is the time 390 at which C-timer is started). 392 For simplicity, the C-timer should be started at the beginning of 393 each time period. This document recommends the implementation to 394 support at least these time periods (1s, 10s, 1min, 10min and 1h). 395 Thus, if the time period is 10s, then the C-timer should be started 396 at the time of any multiples of 10 in seconds (e.g., 0s, 10s, 20s, 397 etc.), and the R-timer should be started, for example, at 0s+Dt, 398 10s+Dt, 20s+Dt, etc. With this method, each MA can independently 399 start its C-timer and R-timer given that the clocks have been 400 synchronized. 402 8. Packet Loss Measurement 404 To simplify the process description, the flows discussed in this 405 document are all unidirectional. A bidirectional flow can be seen as 406 two unidirectional flows. For a specific flow, there will be an 407 upstream MA and a downstream MA, and for each of these MAs there will 408 be corresponding packet counts/timestamp. 410 For packet loss measurement, this document defines the following 411 counters and quantities: 413 U-CountP[n][m]: U-CountP is a two-dimensional array that stores the 414 number of packets transmitted by each upstream MA in each marking 415 time period. Specifically, parameter "n" is the "period number" of 416 measured blocks of markers while parameter "m" refers to the m-th MA 417 of the upstream MAs. 419 D-CountP[n][m]: D-CountP is a two-dimensional array that stores the 420 number of packets received by each downstream MA in each marking time 421 period. Specifically, parameter "n" is the "period number" of 422 measured blocks of markers while parameter "m" refers to the m-th MA 423 of the downstream MAs. 425 U-CountO[n][m]: U-CountO is a two-dimensional array that stores the 426 number of octets transmitted by each upstream MA in each marking time 427 period. Specifically, parameter "n" is the "period number" of 428 measured blocks of markers while parameter "m" refers to the m-th MA 429 of the upstream MAs. 431 D-CountO[n][m]: D-CountO is a two-dimensional array that stores the 432 number of octets received by each downstream MA in each marking time 433 period. Specifically, parameter "n" is the "period number" of 434 measured blocks of markers while parameter "m" refers to the m-th MA 435 of the downstream MAs. 437 LossP: the number of packets transmitted by the upstream MAs but not 438 received at the downstream MAs. 440 LossO: the total octets transmitted by the upstream MAs but not 441 received at the downstream MAs. 443 The total packet loss of a flow can be computed as follows: 445 LossP = U-CountP[1][1] + U-CountP[1][2] + .... + U-CountP[n][m] - 446 D-CountP[1][1] - D-CountP[1][2] - .... - D-CountP[n][m']. 448 LossO = U-CountO[1][1] + U-CountO[1][2] + .... + U-CountO[n][m] - 449 D-CountO[1][1] - D-CountO[1][2] - .... - D-CountO[n][m']. 451 Where the m and m' are the number of upstream MAs and downstream MAs 452 of the measured flow, respectively. 454 9. Packet Delay Measurement 456 For packet delay measurement, there will be only one upstream MA and 457 may be one or more (P2MP) downstream MAs. Although the marking-based 458 IPFPM supports P2MP model, this document only discusses P2P model. 459 The P2MP model is left for future study. This document defines the 460 following timestamps and quantities: 462 U-Time[n]: U-Time is a one-dimension array that stores the time when 463 marked packets are sent; in case the "average delay" method is being 464 used, U-Time stores the average of the time when the packets of the 465 same block are sent; parameter "n" is the "period number" of marked 466 packets. 468 D-Time[n]: D-Time is a one-dimension array that stores the time when 469 marked packets are received; in case the "average delay" method is 470 being used, D-Time stores the average of the time when the packets of 471 the same block are received; parameter "n" is the "period number" of 472 marked packets. This is only for P2P model. 474 D-Time[n][m]: D-Time a two-dimension array that stores the time when 475 the marked packet is received by downstream MAs at each marking time 476 period; in case the "average delay" method is being used, D-Time 477 stores the average of the times when the packets of the same block 478 are received by downstream MAs at each marking time period. Here, 479 parameter "n" is the "period number" of marked packets while 480 parameter "m" refers to the m-th MA of the downstream MAs. This is 481 for P2MP model which is left for future study. 483 One-way Delay[n]: The one-way delay metric for packet networks is 484 described in [RFC2679]. The "n" identifies the "period number" of 485 the marked packet. 487 One-way Delay[1] = D-Time[1] - U-Time[1]. 489 One-way Delay[2] = D-Time[2] - U-Time[2]. 491 ... 493 One-way Delay[n] = D-Time[n] - U-Time[n]. 495 In the case of two-way delay, the delay is the sum of the two one-way 496 delays of the two flows that have the same MAs but have opposite 497 directions. 499 Two-way Delay[1] = (D-Time[1] - U-Time[1]) + (D-Time'[1] - 500 U-Time'[1]). 502 Two-way Delay[2] = (D-Time[2] - U-Time[2]) + (D-Time'[2] - 503 U-Time'[2]). 505 ... 507 Two-way Delay[n] = (D-Time[n] - U-Time[n]) + (D-Time'[n] - 508 U-Time'[n]). 510 Where the D-Time and U-Time are for one forward flow, the D-Time' and 511 U-Time' are for reverse flow. 513 10. Synchronization Aspects 515 As noted in the previous sections, there are two mechanisms in IPFPM 516 that require MAs to have synchronized clocks: (i) the period number 517 (Section 6), and (ii) delay measurement. 519 This section elaborates on the level of synchronization that is 520 required for each of the two mechanisms. Interestingly, IPFPM can be 521 implemented even with very coarse-grained synchronization. 523 10.1. Synchronization for the Period Number 525 Period numbers are used to uniquely identify blocks, allowing the MCP 526 to match the measurements of each block from multipe MAs. 528 The period number of each measurement is computed by the modulo of 529 the local time. Therefore, if the length of the measurement period 530 is L time units, then all MAs must be synchronized to the same clock 531 reference with an accuracy of +/- L/2 time units. This level of 532 accuracy gurantees that all MAs consistently match the color bit to 533 the correct block. For example, if the color is toggeled every 534 second (L = 1 second), then clocks must be synchronized with an 535 accuracy of +/- 0.5 second to a common time reference. 537 The synchronization requirement for maintaining the period number can 538 be satisfied even with a relatively inaccurate synchronization 539 method. 541 10.2. Synchronization for Delay Measurement 543 As discussed in Section 9, the delay between two MAs is computed by 544 D-Time[1] - U-Time[1], requiring the two MAs to be synchronized. 546 Notably, two-way delay measurement does not require the two MAs to be 547 time synchronized. Therefore, a system that uses only two-way delay 548 measurement does not require synchronization between MAs. 550 U-Time[1] D-Time'[1] 551 MA A -----+--------------------+-------- 552 \ /\ 553 \ / 554 \ / 555 \/ / 556 MA B ---------+------------+------------ 557 D-Time[1] U-Time'[1] 558 Figure 3: Two-way Delay Measurement 560 As shown in Section 9, the two way delay between two MAs is given by 561 (see Figure 3): 563 (D-Time[1] - U-Time[1]) + (D-Time'[1] - U-Time'[1]) 565 Therefore, the two-way delay is equal to: 567 (D-Time'[1] - U-Time[1]) - (U-Time'[1] - D-Time'[1]) 568 The latter implies that the two-way delay is comprised of two time 569 differences, (D-Time'[1] - U-Time[1]), and (U-Time'[1] - D-Time'[1]). 570 Thus, the value of the clocks of MA A and MA B does not affect the 571 computation, and synchronization is not required. 573 11. IANA Considerations 575 This document makes no request to IANA. 577 12. Security Considerations 579 This document specifies a passive mechanism for measuring packet loss 580 and delay within a Service Provider's network where the IP packets 581 are marked using unused bits in IP head field, thus avoiding the need 582 to insert additional OAM packets during the measurement. Obviously, 583 such a mechanism does not directly affect other applications running 584 on the Internet but may potentially affect the measurement itself. 586 First, the measurement itself may be affected by routers (or other 587 network devices) along the path of IP packets intentionally altering 588 the value of marking bits of packets. As mentioned above, the 589 mechanism specified in this document is just in the context of one 590 Service Provider's network, and thus the routers (or other network 591 devices) are locally administered and this type of attack can be 592 avoided. 594 Second, one of the main security threats in OAM protocols is network 595 reconnaissance; an attacker can gather information about the network 596 performance by passively eavesdropping to OAM messages. The 597 advantage of the methods described in this document is that the color 598 bits are the only information that is exchanged between the MAs. 599 Therefore, passive eavesdropping to data plane traffic does not allow 600 attackers to gain information about the network performance. We note 601 that the information exported from the MAs to the MCP can be subject 602 to eavesdropping, and thus it should be encrypted. 604 Finally, delay attacks are another potential threat in the context of 605 this document. Delay measurement is performed using a specific 606 packet in each block, marked by a dedicated color bit. Therefore, a 607 man-in-the-middle attacker can selectively induce synthetic delay 608 only to delay-colored packets, causing systematic error in the delay 609 measurements. As discussed in previous sections, the methods 610 described in this document rely on an underlying time synchronization 611 protocol. Thus, by attacking the time protocol an attacker can 612 potentially compromise the integrity of the measurement. A detailed 613 discussion about the threats against time protocols and how to 614 mitigate them is presented in RFC 7384 [RFC7384]. 616 13. Acknowledgements 618 The authors would like to thank Adrian Farrel for his review, 619 suggestion and comments to this document. 621 14. Contributing Authors 623 Hongming Liu 624 Huawei Technologies 626 Email: liuhongming@huawei.com 628 Yuanbin Yin 629 Huawei Technologies 631 Email: yinyuanbin@huawei.com 633 Rajiv Papneja 634 Huawei Technologies 636 Email: Rajiv.Papneja@huawei.com 638 Shailesh Abhyankar 639 Vodafone 640 Vodafone House, Ganpat Rao kadam Marg Lower Parel 641 Mumbai 40003 642 India 644 Email: shailesh.abhyankar@vodafone.com 646 Guangqing Deng 647 CNNIC 648 4 South 4th Street, Zhongguancun, Haidian District 649 Beijing 650 China 652 Email: dengguangqing@cnnic.cn 654 Yongliang Huang 655 China Unicom 657 Email: huangyl@dipmt.com 659 15. References 661 15.1. Normative References 663 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 664 Requirement Levels", BCP 14, RFC 2119, 665 DOI 10.17487/RFC2119, March 1997, 666 . 668 15.2. Informative References 670 [I-D.chen-ippm-ipfpm-report] 671 Chen, M., Zheng, L., Liu, H., Yin, Y., Papneja, R., 672 Abhyankar, S., Deng, G., and Y. Huang, "IP Flow 673 Performance Measurement Report", draft-chen-ippm-ipfpm- 674 report-00 (work in progress), July 2014. 676 [I-D.deng-ippm-passive-wireless-usecase] 677 Lingli, D., Zheng, L., and G. Mirsky, "Use-cases for 678 Passive Measurement in Wireless Networks", draft-deng- 679 ippm-passive-wireless-usecase-01 (work in progress), 680 January 2015. 682 [I-D.ietf-bier-mpls-encapsulation] 683 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and 684 S. Aldrin, "Encapsulation for Bit Index Explicit 685 Replication in MPLS Networks", draft-ietf-bier-mpls- 686 encapsulation-03 (work in progress), February 2016. 688 [I-D.ietf-lmap-framework] 689 Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., 690 Aitken, P., and A. Akhter, "A framework for Large-Scale 691 Measurement of Broadband Performance (LMAP)", draft-ietf- 692 lmap-framework-14 (work in progress), April 2015. 694 [I-D.tempia-opsawg-p3m] 695 Capello, A., Cociglio, M., Castaldelli, L., and A. Bonda, 696 "A packet based method for passive performance 697 monitoring", draft-tempia-opsawg-p3m-04 (work in 698 progress), February 2014. 700 [IEEE1588] 701 IEEE, "1588-2008 IEEE Standard for a Precision Clock 702 Synchronization Protocol for Networked Measurement and 703 Control Systems", March 2008. 705 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 706 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 707 December 1998, . 709 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 710 "Definition of the Differentiated Services Field (DS 711 Field) in the IPv4 and IPv6 Headers", RFC 2474, 712 DOI 10.17487/RFC2474, December 1998, 713 . 715 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 716 Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, 717 September 1999, . 719 [RFC3260] Grossman, D., "New Terminology and Clarifications for 720 Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002, 721 . 723 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 724 Zekauskas, "A One-way Active Measurement Protocol 725 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 726 . 728 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 729 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 730 RFC 5357, DOI 10.17487/RFC5357, October 2008, 731 . 733 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 734 "Network Time Protocol Version 4: Protocol and Algorithms 735 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 736 . 738 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 739 Measurement for MPLS Networks", RFC 6374, 740 DOI 10.17487/RFC6374, September 2011, 741 . 743 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 744 "Specification of the IP Flow Information Export (IPFIX) 745 Protocol for the Exchange of Flow Information", STD 77, 746 RFC 7011, DOI 10.17487/RFC7011, September 2013, 747 . 749 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 750 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 751 October 2014, . 753 Authors' Addresses 755 Mach(Guoyi) Chen (editor) 756 Huawei Technologies 758 Email: mach.chen@huawei.com 760 Lianshu Zheng (editor) 761 Huawei Technologies 763 Email: vero.zheng@huawei.com 765 Greg Mirsky (editor) 766 Ericsson 767 USA 769 Email: gregory.mirsky@ericsson.com 771 Giuseppe Fioccola (editor) 772 Telecom Italia 773 Via Reiss Romoli, 274 774 Torino 10148 775 Italy 777 Email: giuseppe.fioccola@telecomitalia.it 779 Tal Mizrahi (editor) 780 Marvell 781 6 Hamada st. 782 Yokneam 783 Israel 785 Email: talmi@marvell.com