idnits 2.17.1 draft-mizrahi-ippm-compact-alternate-marking-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 4, 2018) is 2244 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 8321 (Obsoleted by RFC 9341) == Outdated reference: A later version (-04) exists of draft-fioccola-ippm-multipoint-alt-mark-02 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-rfc6374-sfl-01 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-sfl-framework-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Mizrahi 3 Internet-Draft C. Arad 4 Intended status: Informational Marvell 5 Expires: September 5, 2018 G. Fioccola 6 M. Cociglio 7 Telecom Italia 8 M. Chen 9 L. Zheng 10 Huawei Technologies 11 G. Mirsky 12 ZTE Corp. 13 March 4, 2018 15 Compact Alternate Marking Methods for Passive and Hybrid Performance 16 Monitoring 17 draft-mizrahi-ippm-compact-alternate-marking-01 19 Abstract 21 This memo introduces new alternate marking methods that require a 22 compact overhead of either a single bit per packet, or zero bits per 23 packet. This memo also presents a summary of alternate marking 24 methods, and discusses the tradeoffs among them. The target audience 25 of this document is network protocol designers; this document is 26 intended to help protocol designers choose the best alternate marking 27 method(s) based on the protocol's constraints and requirements. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 5, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. The Scope of This Document . . . . . . . . . . . . . . . 4 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 68 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 69 3. Marking Abstractions . . . . . . . . . . . . . . . . . . . . 5 70 4. Double Marking . . . . . . . . . . . . . . . . . . . . . . . 7 71 5. Single-bit Marking . . . . . . . . . . . . . . . . . . . . . 8 72 5.1. Single Marking Using the First Packet . . . . . . . . . . 8 73 5.2. Single Marking using the Mean Delay . . . . . . . . . . . 8 74 5.3. Single Marking using a Multiplexed Marking Bit . . . . . 8 75 5.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 8 76 5.3.2. Timing and Synchronization Aspects . . . . . . . . . 9 77 5.4. Pulse Marking . . . . . . . . . . . . . . . . . . . . . . 11 78 6. Zero Marking Hashed . . . . . . . . . . . . . . . . . . . . . 12 79 6.1. Hash-based Sampling . . . . . . . . . . . . . . . . . . . 12 80 6.1.1. Hashed Pulse Marking . . . . . . . . . . . . . . . . 13 81 6.1.2. Hashed Step Marking . . . . . . . . . . . . . . . . . 13 82 7. Single Marking Hashed . . . . . . . . . . . . . . . . . . . . 13 83 8. Summary of Marking Methods . . . . . . . . . . . . . . . . . 14 84 9. Alternate Marking using Reserved Values . . . . . . . . . . . 19 85 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 89 12.2. Informative References . . . . . . . . . . . . . . . . . 20 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 92 1. Introduction 94 1.1. Background 96 Alternate marking, defined in [RFC8321], is a method for measuring 97 packet loss, packet delay, and packet delay variation. Typical delay 98 measurement protocols require the two measurement points (MPs) to 99 exchange timestamped test packets. In contrast, the alternate 100 marking method does not require control packets to be exchanged. 101 Instead, every data packet carries a color indicator, which divides 102 the traffic into consecutive blocks of packets. 104 The color value is toggled periodically, as illustrated in Figure 1. 106 A: packet with color 0 107 B: packet with color 1 109 Packets AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA 110 Time ----------------------------------------------------------> 111 | | | | | 112 | Block 1 | Block 2 | Block 3 | Block 4 | Block 5 ... 113 | | | | | 114 Color 0000000000 1111111111 0000000000 1111111111 0000000000 116 Figure 1: Alternate marking: packets are monitored on a per-color 117 basis. 119 Alternate marking is used between two MPs, the initiating MP, and the 120 monitoring MP. The initiating MP incorporates the marking field into 121 en-route packets, allowing the monitoring MP to use the marking field 122 in order to bind each packet to the corresponding block. 124 Each of the MPs maintains two counters, one per color. At the end of 125 each block the counter values can be collected by a central 126 management system, and analyzed; the packet loss can be computed by 127 comparing the counter values of the two MPs. 129 When using alternate marking delay measurement can be performed in 130 one of three ways (as per [RFC8321]): 132 o Single marking using the first packet: in this method each packet 133 uses a single marking bit, used as a color indicator. The first 134 packet of each block is used by both MPs as a reference for delay 135 measurement. The timestamp of this packet is measured by the two 136 measurement points, and can be collected by the mangement system 137 from each of the measurement points, which can compute the path 138 delay by comparing the two timestamps. The drawback of this 139 approach is that it is not accurate when packets arrive out-of- 140 order, as the two MPs may have a different view of which packet 141 was the first in the block. 143 o Single marking using the mean delay: as in the previous method, 144 each packet uses a single marking method, indicating the color. 145 Each of the MPs computes the average packet timestamp of each 146 block. The management system can then compute the delay by 147 comparing the average times of the two MPs. The drawback of this 148 approach is that it may be computationally heavy, or difficult to 149 implement at the data plane. 151 o Double marking: each packet uses two marking bits. One bit is 152 used as a color indicator, and one is used as a timestamping 153 indicator. This method resolves the drawbacks raised for the two 154 previous methods, at the expense of an extra bit in the packet 155 header. 157 The double marking method is the most straightforward approach. It 158 allows for accurate measurement without incurring expensive 159 computational load. However, in some cases allocating two bits for 160 passive measurement is not possible. For example, if alternate 161 marking is implemented over IPv4, allocating 2 marking bits in the 162 IPv4 header is challenging, as every bit in the 20-octet header is 163 costly; one of the possible approaches discussed in [RFC8321] is to 164 reserve one or two bits from the DSCP field for remarking. In this 165 case every marking bit comes at the expense of reducing the DSCP 166 range by a factor of two. 168 1.2. The Scope of This Document 170 This memo extends the marking methods of [RFC8321], and introduces 171 methods that require a single marking bit, or zero marking bits. 173 Two single-bit marking methods are proposed, multiplexed marking and 174 pulse marking. In multiplexed marking the color indicator and the 175 timestamp indicator are multiplexed into a single bit, providing the 176 advantages of the double marking method while using a single bit in 177 the packet header. In pulse marking both delay and loss measurement 178 are triggered by a 'pulse' value in a single marking field. 180 This document also discusses zero-bit marking methods that leverage 181 well-known hash-based selection approaches ([RFC5474], [RFC5475]). 183 Alternate marking is discussed in this memo as a single-bit or a two- 184 bit marking method. However, these methods can similarly be applied 185 to larger fields, such as an IPv6 Flow Label or an MPLS Label; 186 single-bit marking can be applied using two reserved values, and two- 187 bit marking can be applied using four reserved values. Marking based 188 on reserved values is further discussed in this document, including 189 its application to MPLS and IPv6. 191 Finally, this memo summarizes the alternate marking methods, and 192 discusses the tradeoffs among them. It is expected that different 193 network protocols will have different constraints, and therefore may 194 choose to use different alternate marking methods. In some cases it 195 may be preferable to support more than one marking method; in this 196 case the particular marking method may be signaled through the 197 control plane. 199 2. Terminology 201 2.1. Requirements Language 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in RFC 2119 [RFC2119]. 207 2.2. Abbreviations 209 The following abbreviations are used in this document: 211 DSCP Differentiated Services Code Point 213 DM Delay Measurement 215 LM Loss Measurement 217 LSP Label Switched Path 219 MP Measurement Point 221 MPLS Multiprotocol Label Switching 223 SFL Synonymous Flow Label [I-D.ietf-mpls-sfl-framework] 225 3. Marking Abstractions 227 The marking methods that were discussed in Section 1, as well as the 228 methods introduced in this document, use two basic abstractions, 229 pulse detection, and step detection. 231 The common thread along the various marking methods is that one or 232 two marking bits are used by the MPs to signal a measurement event. 233 The value of the marking bit indicates when the event takes place, in 234 one of two ways: 236 Pulse An event is detected when the value of the marking bit 237 is toggled in a single packet. 239 Step An event is detected when the value of the marking bit 240 is toggled, and remains at the new value. 242 The double marking method (Section 1) uses pulse-based detection for 243 DM, and step-based detection for LM. 245 Pulse-based detection affects the processing of a single packet; the 246 packet that indicates the pulse is processed differently than the 247 packets around it. For example, in the double marking method, the 248 marked packet is timestamped for DM, without affecting the packets 249 before or after it. Note that if the marked packet is lost, no pulse 250 is detected, yielding a missing measurement (see Figure 2). 252 P: indicates a packet 254 Packets PPPPPPPPPP PPPPPPPPPP PPPPPPPPPP PPPPPPPPPP PPPPPPPPPP 255 Time ----------------------------------------------------------> 256 Marking bit 0000010000 0000010000 0000010000 0000010000 00000 0000 257 ^ ^ ^ ^ ^ 258 Pulse-based | | | | | 259 detection | | | | | 260 Dropped packet: 261 no detection 263 Figure 2: Pulse-based Detection. 265 In step-based detection the event is detected by observing a value 266 change in stream of packets. Specifically, when the step approach is 267 used for LM (as in the double marking method), two counters are used 268 per flow; each MP decides which counter to use based on the value of 269 the marking bit. Thus, the step-based approach allows accurate 270 counting even when packets arrive out-of-order (see Figure 3). When 271 the step approach is used for DM (e.g., single marking using the 272 first packet), out-of-order causes the delay measurement to be false, 273 without any indication to the management system. 275 P: indicates a packet 277 Packets PPPPPPPPPP PPPPPPPPPP PPPPPPPPPP PPPPPPPPPP PPPPPPPPPP 278 Time ----------------------------------------------------------> 279 Marking bit 0000000000 1111111111 000000000 10111111111 0000000000 280 ^ ^ ^ ^ 281 Step-based | | | | 282 detection | | | | 283 out-of-order 285 Figure 3: Step-based Detection. 287 4. Double Marking 289 The two-bit marking method of [RFC8321] uses two marking bits: a 290 color indicator, and a delay measurement indicator. The color bit is 291 used for step-based LM, while the delay bit is used as a pulse-based 292 DM trigger. This double marking approach is the most straightforward 293 of the approaches discussed in this memo, as it allows accurate 294 measurement, it is resilient to out-of-order delivery, and is 295 relatively simple to implement. The main drawback is that it 296 requires two bits, which are not always available. 298 Figure 4 illustrates the double marking method: each block of packets 299 includes a packet that is marked for timestamping, and therefore has 300 its delay bit set. 302 A: packet with color 0 303 B: packet with color 1 305 Packets AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA 306 Time ----------------------------------------------------------> 307 | | | | | 308 | Block 1 | Block 2 | Block 3 | Block 4 | Block 5 ... 309 | | | | | 310 Color bit 0000000000 1111111111 0000000000 1111111111 0000000000 311 Delay bit 0000100000 0000100000 0000100000 0000100000 0001000000 312 ^ ^ ^ ^ ^ 313 Packets | | | | | 314 marked for | | | | | 315 timestamping | | | | | 317 Figure 4: The double marking method. 319 5. Single-bit Marking 321 5.1. Single Marking Using the First Packet 323 This method uses a single marking bit that indicates the color, as 324 described in [RFC8321]. Both LM and DM are implemented using a step- 325 based approach; LM is implemented using two color-based counters per 326 flow. The first packet of every period is used by the two MPs as the 327 reference for measuring the delay. As denoted above, the delay 328 computed in this method may be erroneous when packets are delivered 329 out-of-order. 331 A: packet with color 0 332 B: packet with color 1 334 Packets AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA 335 Time ----------------------------------------------------------> 336 | | | | | 337 | Block 1 | Block 2 | Block 3 | Block 4 | Block 5 ... 338 | | | | | 339 Color bit 0000000000 1111111111 0000000000 1111111111 0000000000 340 ^ ^ ^ ^ ^ 341 Packets | | | | | 342 used for DM | | | | | 344 Figure 5: Single marking using the first packet of the block. 346 5.2. Single Marking using the Mean Delay 348 As in the first-packet approach, in the mean delay approach 349 ([RFC8321]) a single marking bit is used to indicate the color, 350 enabling step-based loss measurement. Delay is measured in each 351 period by averaging the measured delay over all the packets in the 352 period. As discussed above, this approach is not sensitive to out- 353 of-order delivery, but may be heavy from a computational perspective. 355 5.3. Single Marking using a Multiplexed Marking Bit 357 5.3.1. Overview 359 This section introduces a method that uses a single marking bit that 360 serves two purposes: a color indicator, and a timestamp indicator. 361 The double marking method that was discussed in the previous section 362 uses two 1-bit values: a color indicator C, and a timestamp indicator 363 T. The multiplexed marking bit, denoted by M, is an exclusive or 364 between these two values: M = C XOR T. 366 An example of the use of the multiplexed marking bit is depicted in 367 Figure 6. The example considers two routers, R1 and R2, that use the 368 multiplexed bit method to measure traffic from R1 to R2. In each 369 block R1 designates one of the packets for delay measurement. In 370 each of these designated packets the value of the multiplexed bit is 371 reversed compared to the other packets in the same block, allowing R2 372 to distinguish the designated packets from the other packets. 374 A: packet with color 0 375 B: packet with color 1 377 Packets AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA 378 Time ----------------------------------------------------------> 379 | | | | | 380 | Block 1 | Block 2 | Block 3 | Block 4 | Block 5 ... 381 | | | | | 382 Color 0000000000 1111111111 0000000000 1111111111 0000000000 383 ^ ^ ^ ^ ^ 384 Packets | | | | | 385 marked for | | | | | 386 timestamping | | | | | 387 v v v v v 388 Muxed bit 0000100000 1111011111 0000100000 1111101111 0001000000 390 Figure 6: Alternate marking with multiplexed bit. 392 5.3.2. Timing and Synchronization Aspects 394 It is assumed that all MPs are synchronized to a common reference 395 time with an accuracy of +/- A/2. Thus, the difference between the 396 clock values of any two MPs is bounded by A. Clocks can be 397 synchronized for example using NTP [RFC5905], PTP [IEEE1588], or by 398 other means. The common reference time is used for dividing the time 399 domain into equal-sized measurement periods, such that all packets 400 forwarded during a measurement period have the same color, and 401 consecutive periods have alternating colors. 403 The single marking bit incorporates two multiplexed values. From the 404 monitoring MP's perspective, the two values are Time-Division 405 Multiplexed (TDM), as depicted in Figure 7. It is assumed that the 406 start time of every measurement period is known to both the 407 initiating MP and the monitoring MP. If the measurement period is L, 408 then during the first and the last L/4 time units of each block the 409 marking bit is interpreted by the monitoring MP as a color indicator. 410 During the middle part of the block, the marking bit is interpreted 411 as a timestamp indicator; if the value of this bit is different than 412 the color value, the corresponding packet is used as a reference for 413 delay measurement. 415 +--- Beginning of measurement period 416 | 417 v 419 ...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB... 420 |<======================================>| 421 | L | 422 <========>|<========><==================><========>|<========> 423 L/4 L/4 L/2 L/4 L/4 425 <===================><==================><===================> 426 Detect color Detect timestamping Detect color 427 change indication change 429 Figure 7: Multiplexed marking field interpretation at the receiving 430 measurement point. 432 In order to prevent ambiguity in the receiver's interpretation of the 433 marking field, the initiating MP is permitted to set the timestamp 434 indication only during a specific interval, as depicted in Figure 8. 435 Since the receiver is willing to receive the timestamp indication 436 during the middle L/2 time units of the block, the sender refrains 437 from sending the timestamp indication during a guardband interval of 438 d time units at the beginning and end of the L/2-period. 440 +--- Beginning of measurement period 441 | 442 v 444 ...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB... 445 |<======================================>| 446 | L | 447 <========>|<========>|<================>|<========>| 448 L/4 L/4 | L/2 | L/4 449 <=>|<=> <=>|<=> 450 d d d d 451 <==========> 452 permissible 453 timestamping 454 indication 455 interval 457 Figure 8: A time domain view. 459 The guardband d is given by d = A + D_max - D_min, where A is the 460 clock accuracy, D_max is an upper bound on the network delay between 461 the MPs, and D_min is a lower bound on the delay. It is 462 straightforward from Figure 8 that d < L/4 must be satisfied. The 463 latter implies a minimal requirement on the synchronization accuracy. 465 All MPs must be synchronized to the same reference time with an 466 accuracy of +/- L/8. Depending on the system topology, in some 467 systems the accuracy requirement will be even more stringent, subject 468 to d < L/4. Note that the accuracy requirement of the conventional 469 alternate marking method [RFC8321] is +/- L/2, while the multiplexed 470 marking method requires an accuracy of +/- L/8. 472 Note that we assume that the middle L/2-period is designated as the 473 timestamp indication period, allowing a sufficiently long guardband 474 between the transitions. However, a system may be configured to use 475 a longer timestamp indication period or a shorter one, if it is 476 guaranteed that the synchronization accuracy meets the guardband 477 requirements (i.e., the constraints on d). 479 5.4. Pulse Marking 481 Pulse marking uses a single marking bit that is used as a trigger for 482 both LM and DM. In this method the two MPs maintain a single per- 483 flow counter for LM, in contrast to the color-based methods which 484 require two counters per flow. In each block one of the packets is 485 marked. The marked packet triggers two actions in each of MPs: 487 o The timestamp is captured for DM. 489 o The value of the counter is captured for LM. 491 In each period, each of the MPs exports the timestamp and counter- 492 stamp to the management system, which can then compute the loss and 493 delay in that period. It should be noted that as in [RFC8321], if 494 the length of the measurement period is L time units, then all 495 network devices must be synchronized to the same clock reference with 496 an accuracy of +/- L/2 time units. 498 The pulse marking approach is illustrated in Figure 9. Since both LM 499 and DM use a pulse-based trigger, if the marked packet is lost then 500 no measurement is available in this period. Moreover, the LM 501 accuracy may be affected by out-of-order delivery. 503 P: packet - all packets have the same color 505 Packets PPPPPPPPPP PPPPPPPPP PPPPPPPPPP PPPPPPPPPP PPPPPPPPPP 506 Time ----------------------------------------------------------> 507 | | | | | 508 | Block 1 | Block 2 | Block 3 | Block 4 | Block 5 ... 509 | | | | | 510 ^ ^ ^ ^ ^ 511 Packets | | | | | 512 marked for | | | | | 513 DM and LM | | | | | 514 v v v v v 515 Marking bit 0000100000 0000100000 0000100000 0000010000 0001000000 517 Figure 9: Pulse marking method. 519 6. Zero Marking Hashed 521 6.1. Hash-based Sampling 523 Hash based selection [RFC5475] is a well-known method for sampling a 524 subset of packets. As defined in [RFC5475]: 526 A Hash Function h maps the Packet Content c, or some portion of 527 it, onto a Hash Range R. The packet is selected if h(c) is an 528 element of S, which is a subset of R called the Hash Selection 529 Range. 531 Hash-based selection can be leveraged as a marking method, allowing a 532 zero-bit marking approach. Specifically, the pulse and step 533 abstractions can be implemented using hashed selection: 535 o Hashed pulse-based trigger: in this approach, a packet is selected 536 if h(c) is an element of S, which is a strict subset of the hash 537 range R. When |S|<<|R|, the average sampling period is long, 538 reducing the probability of ambiguity between consecutive 539 packets. |S| and |R| denote the number of elements in S and R, 540 respectively. 542 o Hashed step-based trigger: the hash values of a given traffic flow 543 are said to be monotonically increasing if for two packets p1 and 544 p2, if p1 is sent before p2 then h(p1)<=h(p2). If it is 545 guaranteed that the hash values of a flow are monotonically 546 increasing, then a step-based approach can be used on the range R. 547 For example, in an IPv4 flow the Identification field can be used 548 as the hash value of each packet. Since the Identification field 549 is monotonically increasing, the step-based trigger can be 550 implemented using consecutive ranges of the Identification value. 551 For example, the fourth bit of the Identification field is toggled 552 every 8 packets. Thus, a possible hash function simply takes the 553 fourth bit of the Identification field as the hash value. This 554 hash value is toggled every 8 packets, simulating the alternate 555 marking behavior of Section 4. 557 Note that as opposed to the double marking and single marking 558 methods, hashed sampling is not based on fixed time intervals, as the 559 duration between sampled packets depends only on the hash value. 561 It is also important to note that all methods that use hash-based 562 marking require the hash function and the set S to be configured 563 consistently across the MPs. 565 6.1.1. Hashed Pulse Marking 567 In this approach a hash is computed over the packet content, and both 568 LM and DM are triggered based on the pulse-based trigger 569 (Section 6.1). A pulse is detected when the hash value h(c) is equal 570 to one of the values in S. The hash function h and the set S 571 determine the probability (or frequency) of the pulse event. 573 6.1.2. Hashed Step Marking 575 As in the previous approach, hashed step marking also uses a hash 576 that is computed over the packet content. In this approach DM is 577 performed using a pulse-based trigger, whereas the LM trigger is 578 step-based (Section 6.1). The main drawback of this method is that 579 the step-based trigger is possible only under the assumption that the 580 hash function is monotonically increasing, which is not necessarily 581 possible in all cases. Specifically, a measured flow is not 582 necessarily an IPv4 5-tuple. For example, a measured flow may 583 include multiple IPv4 5-tuple flows, and in this case the 584 Identification field is not monotonically increasing. 586 7. Single Marking Hashed 588 Mixed hashed marking combines the single marking approach with hash- 589 based sampling. A single marking bit is used in the packet header as 590 a color indicator, while a hash-based pulse is used to trigger DM. 591 Although this method requires a single bit, it is described in this 592 section as it is closely related to the other hash-based methods that 593 require zero marking bits. 595 The hash-based selection for DM can be applied in one of two possible 596 approaches: the basic approach, and the dynamic approach. In the 597 basic approach, packets forwarded between two MPs, MP1 and MP2, are 598 selected using a hash function, as described above. One of the 599 challenges is that the frequency of the sampled packets may vary 600 considerably, making it difficult for the management system to 601 correlate samples from the two MPs. Thus, the dynamic approach can 602 be used. 604 In the dynamic hash-based sampling, alternate marking is used to 605 create divide time into periods, so that hash-based samples are 606 divided into batches, allowing to anchor the selected samples to 607 their period. Moreover, by dynamically adapting the length of the 608 hash value, the number of samples is bounded in each marking period. 609 This can be realized by choosing first the maximum number of samples 610 (NMAX) to be used with the initial hash length. The algorithm starts 611 with only few hash bits, that permit to select a greater percentage 612 of packets (e.g. with 1 bit of hash half of the packets are sampled). 613 When the number of selected packets reaches NMAX, a hashing bit is 614 added. As a consequence, the sampling proceeds at half of the 615 original rate and the packets already selected that do not match the 616 new hash are discarded. This step can be repeated iteratively. It 617 is assumed that each sample includes the timestamp (used for DM) and 618 the hash value, allowing the management system to match the samples 619 received from the two MPs. 621 The dynamic process statistically converges at the end of a marking 622 period and the number of selected samples beyond the initial NMAX 623 samples mentioned above is between NMAX/2 and NMAX. Therefore, the 624 dynamic approach paces the sampling rate, allowing to bound the 625 number of sampled packets per sampling period. 627 8. Summary of Marking Methods 629 This section summarizes the marking methods described in this memo. 630 Each row in the table of Figure 10 represents a marking method. For 631 each method the table specifies the number of bits required in the 632 header, the number of counters per flow for LM, the methods used for 633 LM and DM (pulse or step), and also the resilience to disturbances. 635 +--------------+----+----+------+------+-------------+-------------+ 636 | Method |# of|# of|LM |DM |Resilience to|Resilience to| 637 | |bits|coun|Method|Method|Reordering |Packet drops | 638 | | |ters| | +------+------+------+------+ 639 | | | | | | LM | DM | LM | DM | 640 +--------------+----+----+------+------+------+------+------+------+ 641 |Single marking| 1 | 2 |Step |Step | + | -- | + | -- | 642 |- 1st packet | | | | | | | | | 643 +--------------+----+----+------+------+------+------+------+------+ 644 |Single marking| 1 | 2 |Step |Mean | + | + | + | - | 645 |- mean delay | | | | | | | | | 646 +--------------+----+----+------+------+------+------+------+------+ 647 |Double marking| 2 | 2 |Step |Pulse | + | + | + | = | 648 +--------------+----+----+------+------+------+------+------+------+ 649 |Single marking| 1 | 2 |Step |Pulse | + | + | + | = | 650 |multiplexed | | | | | | | | | 651 +--------------+----+----+------+------+------+------+------+------+ 652 |Pulse marking | 1 | 1 |Pulse |Pulse | -- | + | - | = | 653 +--------------+----+----+------+------+------+------+------+------+ 654 |Zero marking | 0 | 1 |Hashed|Hashed| -- | + | - | + | 655 |hashed | |(2) |pulse |pulse | (-) | | | | 656 | | | |(step)| | | | | | 657 +--------------+----+----+------+------+------+------+------+------+ 658 |Single marking| 1 | 2 |Step |Hashed| + | + | + | + | 659 |hashed | | | |pulse | | | | | 660 +--------------+----+----+------+------+------+------+------+------+ 662 + Accurate measurement. 663 = Invalidate only if a measured packet is lost (detectable) 664 - No measurement in case of disturbance (detectable). 665 -- False measurement in case of disturbance (not detectable). 667 Figure 10: Detailed Summary of Marking Methods 669 In the context of this comparison two possible disturbances are 670 considered: out-of-order delivery, and packet drops. Generally 671 speaking, pulse based methods are sensitive to packet drops, since if 672 the marked packet is dropped no measurement is recorded in the 673 current period. Notably, a missing measurement is detectable by the 674 management system, and is not as severe as a false measurement. 675 Step-based triggers are generally resilient to out-of-order delivery 676 for LM, but are not resilient to out-of-order delivery for DM. 677 Notably, a step-based trigger may yield a false delay measurement 678 when packets are delivered out-of-order, and this inaccuracy is not 679 detectable. 681 As mentioned above, the double marking method is the most 682 straightforward approach, and is resilient to most of the 683 disturbances that were analyzed. Its obvious drawback is that it 684 requires two marking bits. 686 Several single marking methods are discussed in this memo. In this 687 case there is no clear verdict which method is the optimal one. The 688 first packet method may be simple to implement, but may present 689 erroneous delay measurements in case of dropped or reordered packets. 690 Arguably, the mean delay approach and the multiplexed approach may be 691 more difficult to implement (depending on the underlying platform), 692 but are more resilient to the disturbances that were considered here. 693 Note that the computational complexity of the mean delay approach can 694 be reduced by combining it with a hashed approach, i.e., by computing 695 the mean delay over a hash-based subset of the packets. The pulse 696 marking method requires only a single counter per flow, while the 697 other methods require two counters per flow. 699 The hash-based sampling approaches reduce the overhead to zero bits, 700 which is a significant advantage. However, the sampling period in 701 these approaches is not associated with a fixed time interval. 702 Therefore, in some cases adjacent packets may be selected for the 703 sampling, potentially causing measurement errors. Furthermore, when 704 the traffic rate is low, measurements may become signifcantly 705 infrequent. 707 It should be noted that most of the marking methods that were 708 presented in this memo are intended for point-to-point measurements, 709 e.g., from MP1 to MP2 in Figure 11. In point-to-multipoint 710 measurements, the mean delay method can be used to measure the loss 711 and delay of the entire point-to-multipoint flow (which includes all 712 the traffic from MP3 to either MP4 or MP5), while other methods such 713 as double marking can be used to measure the point-to-point 714 performance, for example from MP3 to MP5. Alternate marking in 715 multipoint scenarios is discussed in detail in 716 [I-D.fioccola-ippm-multipoint-alt-mark]. 718 MP1 MP2 MP3 MP4 719 +--+ +--+ +--+ +--+ +--+ 720 | |---------->| | | |----->| |----->| | 721 +--+ +--+ +--+ +--+ +--+ 722 | 723 | MP5 724 | +--+ 725 +------>| | 726 +--+ 728 Point-to-point measurement Point-to-multipoint measurement 730 Figure 11: Point-to-point and point-to-multipoint measurements. 732 It is clear from the previous table that packet loss measurement can 733 be considered resilient to both reordering and packet drops if at 734 least one bit is used with a step-based approach. Thus, since the 735 packet loss can be considered obvious, the previous table can be 736 simplified into Figure 12, where only the characteristics of delay 737 measurements are highlighted, along with multipoint-to-multipoint 738 delay measurement compatibility (refer to 739 [I-D.fioccola-ippm-multipoint-alt-mark] for more details). 741 +--------------+----+--------+------------+------------+-----------+ 742 | Marking |# of|LM |DM |DM |DM | 743 | Method |bits|on |Resilience |Resilience |Multipoint | 744 | | |All |to |to |compatible | 745 | | |Packets |Reordering |Packet drops| | 746 +--------------+----+--------+------------+------------+-----------+ 747 |Single marking| 1 | Yes | -- | - | No | 748 |- 1st packet | | | | | | 749 +--------------+----+--------+------------+------------+-----------+ 750 |Single marking| 1 | Yes | + | - | Yes | 751 |- mean delay | | | | | | 752 +--------------+----+--------+------------+------------+-----------+ 753 |Double marking| 2 | Yes | + | = | No | 754 +--------------+----+--------+------------+------------+-----------+ 755 |Single marking| 1 | Yes | + | = | No | 756 |multiplexed | | | | | | 757 +--------------+----+--------+------------+------------+-----------+ 758 |Pulse marking | 1 | No | + | = | No | 759 +--------------+----+--------+------------+------------+-----------+ 760 |Zero marking | 0 | No | + | + | Yes | 761 |hashed | | | | | | 762 | | | | | | | 763 +--------------+----+--------+------------+------------+-----------+ 764 |Single marking| 1 | Yes | + | + | Yes | 765 |hashed | | | | | | 766 +--------------+----+--------+------------+------------+-----------+ 768 + Accurate measurement. 769 = Invalidate only if a measured packet is lost (detectable) 770 - No measurement in case of disturbance (detectable). 771 -- False measurement in case of disturbance (not detectable). 773 Figure 12: Summary of Marking Methods: focus on Delay Measurement 775 In the context of delay measurement, both zero marking hashed and 776 single marking hashed are resilient to packet drops. Using double 777 marking it could also be possible to perform an accurate measurement 778 in case of packet drops, as long as the packet that is marked for DM 779 is not dropped. 781 The single marking hashed method seems the most complete approach, 782 especially because it is also compatible with multipoint-to- 783 multipoint measurements. 785 9. Alternate Marking using Reserved Values 787 As mentioned in Section 1, a marking bit is not necessarily a single 788 bit, but may be implemented by using two well-known values in one of 789 the header fields. Similarly, two-bit marking can be implemented 790 using four reserved values. 792 A notable example is MPLS Synonymous Flow Labels (SFL), as defined in 793 [I-D.ietf-mpls-rfc6374-sfl]. Two MPLS Label values can be used to 794 indicate the two colors of a given LSP: the original Label value, and 795 an SFL value. A similar approach can be applied to IPv6 using the 796 Flow Label field. 798 The following example illustrates how alternate marking can be 799 implemented using reserved values. The bit multiplexing approach of 800 Section 5.3 is applicable not only to single-bit color indicators, 801 but also to two-value indicators; instead of using a single bit that 802 is toggled between '0' and '1', two values of the indicator field, U 803 and W, can be used in the same manner, allowing both loss and delay 804 measurement to be performed using only two reserved values. Thus, 805 the multiplexing approach of Figure 6 can be illustrated more 806 generally with two values, U and W, as depicted in Figure 13. 808 A: packet with color 0 809 B: packet with color 1 811 Packets AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA 812 Time ----------------------------------------------------------> 813 | | | | | 814 | Block 1 | Block 2 | Block 3 | Block 4 | Block 5 ... 815 | | | | | 816 Color 0000000000 1111111111 0000000000 1111111111 0000000000 817 ^ ^ ^ ^ ^ 818 Packets | | | | | 819 marked for | | | | | 820 timestamping | | | | | 821 v v v v v 822 Muxed UUUUWUUUUU WWWWUWWWWW UUUUWUUUUU WWWWWUWWWW UUUWUUUUUU 823 marking 824 values 826 Figure 13: Alternate marking with two multiplexed marking values, U 827 and W. 829 10. IANA Considerations 831 This memo includes no requests from IANA. 833 11. Security Considerations 835 The security considerations of the alternate marking method are 836 discussed in [RFC8321]. The analysis of Section 8 emphasizes the 837 sensitivity of some of the alternate marking methods to packet drops 838 and to packet reordering. Thus, a malicious attacker may attempt to 839 tamper with the measurements by either selectively dropping packets, 840 or by selectively reordering specific packets. The multiplexed 841 marking method Section 5.3 that is defined in this document requires 842 slightly more stringent synchronization than the conventional marking 843 method, potentially making the method more vulnerable to attacks on 844 the time synchronization protocol. A detailed discussion about the 845 threats against time protocols and how to mitigate them is presented 846 in [RFC7384]. 848 12. References 850 12.1. Normative References 852 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 853 Requirement Levels", BCP 14, RFC 2119, 854 DOI 10.17487/RFC2119, March 1997, 855 . 857 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 858 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 859 "Alternate-Marking Method for Passive and Hybrid 860 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 861 January 2018, . 863 12.2. Informative References 865 [I-D.fioccola-ippm-multipoint-alt-mark] 866 Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto, 867 "Multipoint Alternate Marking method for passive and 868 hybrid performance monitoring", draft-fioccola-ippm- 869 multipoint-alt-mark-02 (work in progress), March 2018. 871 [I-D.ietf-mpls-rfc6374-sfl] 872 Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., 873 Mirsky, G., and G. Fioccola, "RFC6374 Synonymous Flow 874 Labels", draft-ietf-mpls-rfc6374-sfl-01 (work in 875 progress), December 2017. 877 [I-D.ietf-mpls-sfl-framework] 878 Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., 879 and G. Mirsky, "Synonymous Flow Label Framework", draft- 880 ietf-mpls-sfl-framework-01 (work in progress), January 881 2018. 883 [IEEE1588] 884 IEEE, "IEEE 1588 Standard for a Precision Clock 885 Synchronization Protocol for Networked Measurement and 886 Control Systems Version 2", 2008. 888 [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., 889 Grossglauser, M., and J. Rexford, "A Framework for Packet 890 Selection and Reporting", RFC 5474, DOI 10.17487/RFC5474, 891 March 2009, . 893 [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. 894 Raspall, "Sampling and Filtering Techniques for IP Packet 895 Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, 896 . 898 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 899 "Network Time Protocol Version 4: Protocol and Algorithms 900 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 901 . 903 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 904 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 905 October 2014, . 907 Authors' Addresses 909 Tal Mizrahi 910 Marvell 911 6 Hamada st. 912 Yokneam 913 Israel 915 Email: talmi@marvell.com 917 Carmi Arad 918 Marvell 919 6 Hamada st. 920 Yokneam 921 Israel 923 Email: carmi.arad@gmail.com 924 Giuseppe Fioccola 925 Telecom Italia 926 Via Reiss Romoli, 274 927 Torino 10148 928 Italy 930 Email: giuseppe.fioccola@telecomitalia.it 932 Mauro Cociglio 933 Telecom Italia 934 Via Reiss Romoli, 274 935 Torino 10148 936 Italy 938 Email: mauro.cociglio@telecomitalia.it 940 Mach(Guoyi) Chen 941 Huawei Technologies 943 Email: mach.chen@huawei.com 945 Lianshu Zheng 946 Huawei Technologies 948 Email: vero.zheng@huawei.com 950 Greg Mirsky 951 ZTE Corp. 953 Email: gregimirsky@gmail.com