idnits 2.17.1 draft-mizrahi-ippm-compact-alternate-marking-05.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 (July 6, 2019) is 1756 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 (-09) exists of draft-ietf-ippm-multipoint-alt-mark-02 == Outdated reference: A later version (-10) exists of draft-ietf-mpls-rfc6374-sfl-03 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-sfl-framework-04 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 Huawei Network.IO Innovation Lab 4 Intended status: Informational C. Arad 5 Expires: January 7, 2020 6 G. Fioccola 7 Huawei Technologies 8 M. Cociglio 9 Telecom Italia 10 M. Chen 11 L. Zheng 12 Huawei Technologies 13 G. Mirsky 14 ZTE Corp. 15 July 6, 2019 17 Compact Alternate Marking Methods for Passive and Hybrid Performance 18 Monitoring 19 draft-mizrahi-ippm-compact-alternate-marking-05 21 Abstract 23 This memo introduces new alternate marking methods that require a 24 compact overhead of either a single bit per packet, or zero bits per 25 packet. This memo also presents a summary of alternate marking 26 methods, and discusses the tradeoffs among them. The target audience 27 of this document is network protocol designers; this document is 28 intended to help protocol designers choose the best alternate marking 29 method(s) based on the protocol's constraints and requirements. 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 https://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 January 7, 2020. 48 Copyright Notice 50 Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.2. The Scope of This Document . . . . . . . . . . . . . . . 4 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 70 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Marking Abstractions . . . . . . . . . . . . . . . . . . . . 5 72 4. Double Marking . . . . . . . . . . . . . . . . . . . . . . . 7 73 5. Single-bit Marking . . . . . . . . . . . . . . . . . . . . . 8 74 5.1. Single Marking Using the First Packet . . . . . . . . . . 8 75 5.2. Single Marking using the Mean Delay . . . . . . . . . . . 8 76 5.3. Single Marking using a Multiplexed Marking Bit . . . . . 8 77 5.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . 8 78 5.4. Pulse Marking . . . . . . . . . . . . . . . . . . . . . . 9 79 6. Zero Marking Hashed . . . . . . . . . . . . . . . . . . . . . 10 80 6.1. Hash-based Sampling . . . . . . . . . . . . . . . . . . . 10 81 6.1.1. Hashed Pulse Marking . . . . . . . . . . . . . . . . 11 82 6.1.2. Hashed Step Marking . . . . . . . . . . . . . . . . . 11 83 7. Single Marking Hashed . . . . . . . . . . . . . . . . . . . . 11 84 8. Timing and Synchronization Aspects . . . . . . . . . . . . . 12 85 8.1. Synchronization Aspects in Multiplexed Marking . . . . . 13 86 9. Multipoint Marking Methods . . . . . . . . . . . . . . . . . 14 87 10. Summary of Marking Methods . . . . . . . . . . . . . . . . . 15 88 11. Alternate Marking using Reserved Values . . . . . . . . . . . 19 89 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 90 13. Security Considerations . . . . . . . . . . . . . . . . . . . 20 91 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 14.1. Normative References . . . . . . . . . . . . . . . . . . 20 93 14.2. Informative References . . . . . . . . . . . . . . . . . 20 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 96 1. Introduction 98 1.1. Background 100 Alternate marking, defined in [RFC8321], is a method for measuring 101 packet loss, packet delay, and packet delay variation. Typical delay 102 measurement protocols require the two measurement points (MPs) to 103 exchange timestamped test packets. In contrast, the alternate 104 marking method does not require control packets to be exchanged. 105 Instead, every data packet carries a marking bit, which is used for 106 triggering measurement events. Note that the frequency of these 107 measurement events is dependent on the users' application(s) and the 108 node characteristics. 110 The marking bit can be used as a color indication, as defined in 111 [RFC8321], which is toggled periodically. This approach is 112 illustrated in Figure 1. 114 A: packet with color 0 115 B: packet with color 1 117 Packets AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA 118 Time ----------------------------------------------------------> 119 | | | | | 120 | Block 1 | Block 2 | Block 3 | Block 4 | Block 5 ... 121 | | | | | 122 Color 0000000000 1111111111 0000000000 1111111111 0000000000 124 Figure 1: Alternate marking: packets are monitored on a per-color 125 basis. 127 Alternate marking is used between two MPs, the initiating MP, and the 128 monitoring MP. The initiating MP incorporates the marking field into 129 en-route packets, allowing the monitoring MP to use the marking field 130 in order to bind each packet to the corresponding block. 132 Each of the MPs maintains two counters, one per color. At the end of 133 each block the counter values can be collected by a central 134 management system, and analyzed; the packet loss can be computed by 135 comparing the counter values of the two MPs. 137 When using alternate marking delay measurement can be performed in 138 one of three ways (as per [RFC8321]): 140 o Single marking using the first packet: in this method each packet 141 uses a single marking bit, used as a color indicator. The first 142 packet of each block is used by both MPs as a reference for delay 143 measurement. The timestamp of this packet is measured by the two 144 measurement points, and can be collected by the mangement system 145 from each of the measurement points, which can compute the path 146 delay by comparing the two timestamps. The drawback of this 147 approach is that it is not accurate when packets arrive out-of- 148 order, as the two MPs may have a different view of which packet 149 was the first in the block. 151 o Single marking using the mean delay: as in the previous method, 152 each packet uses a single marking method, indicating the color. 153 Each of the MPs computes the average packet timestamp of each 154 block. The management system can then compute the delay by 155 comparing the average times of the two MPs. The drawback of this 156 approach is that it may be computationally heavy, or difficult to 157 implement at the data plane. 159 o Double marking: each packet uses two marking bits. One bit is 160 used as a color indicator, and one is used as a timestamping 161 indicator. This method resolves the drawbacks raised for the two 162 previous methods, at the expense of an extra bit in the packet 163 header. 165 The double marking method is the most straightforward approach. It 166 allows for accurate measurement without incurring expensive 167 computational load. However, in some cases allocating two bits for 168 passive measurement is not possible. For example, if alternate 169 marking is implemented over IPv4, allocating 2 marking bits in the 170 IPv4 header is challenging, as every bit in the 20-octet header is 171 costly; one of the possible approaches discussed in [RFC8321] is to 172 reserve one or two bits from the DSCP field for remarking. In this 173 case every marking bit comes at the expense of reducing the DSCP 174 range by a factor of two. 176 1.2. The Scope of This Document 178 This memo extends the marking methods of [RFC8321], and introduces 179 methods that require a single marking bit, or zero marking bits. 181 Two single-bit marking methods are proposed, multiplexed marking and 182 pulse marking. In multiplexed marking the color indicator and the 183 timestamp indicator are multiplexed into a single bit, providing the 184 advantages of the double marking method while using a single bit in 185 the packet header. In pulse marking both delay and loss measurement 186 are triggered by a 'pulse' value in a single marking field. 188 This document also discusses zero-bit marking methods that leverage 189 well-known hash-based selection approaches ([RFC5474], [RFC5475]). 191 Alternate marking is discussed in this memo as a single-bit or a two- 192 bit marking method. However, these methods can similarly be applied 193 to larger fields, such as an IPv6 Flow Label or an MPLS Label; 194 single-bit marking can be applied using two reserved values, and two- 195 bit marking can be applied using four reserved values. Marking based 196 on reserved values is further discussed in this document, including 197 its application to MPLS and IPv6. 199 Finally, this memo summarizes the alternate marking methods, and 200 discusses the tradeoffs among them. It is expected that different 201 network protocols will have different constraints, and therefore may 202 choose to use different alternate marking methods. In some cases it 203 may be preferable to support more than one marking method; in this 204 case the particular marking method may be signaled through the 205 control plane. 207 2. Terminology 209 2.1. Requirements Language 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 213 document are to be interpreted as described in RFC 2119 [RFC2119]. 215 2.2. Abbreviations 217 The following abbreviations are used in this document: 219 DSCP Differentiated Services Code Point 221 DM Delay Measurement 223 LM Loss Measurement 225 LSP Label Switched Path 227 MP Measurement Point 229 MPLS Multiprotocol Label Switching 231 SFL Synonymous Flow Label [I-D.ietf-mpls-sfl-framework] 233 3. Marking Abstractions 235 The marking methods that were discussed in Section 1, as well as the 236 methods introduced in this document, use two basic abstractions, 237 pulse detection, and step detection. 239 The common thread along the various marking methods is that one or 240 two marking bits are used by the MPs to signal a measurement event. 241 The value of the marking bit indicates when the event takes place, in 242 one of two ways: 244 Pulse An event is detected when the value of the marking bit 245 is toggled in a single packet. 247 Step An event is detected when the value of the marking bit 248 is toggled, and remains at the new value. 250 The double marking method (Section 1) uses pulse-based detection for 251 DM, and step-based detection for LM. 253 Pulse-based detection affects the processing of a single packet; the 254 packet that indicates the pulse is processed differently than the 255 packets around it. For example, in the double marking method, the 256 marked packet is timestamped for DM, without affecting the packets 257 before or after it. Note that if the marked packet is lost, no pulse 258 is detected, yielding a missing measurement (see Figure 2). 260 P: indicates a packet 262 Packets PPPPPPPPPP PPPPPPPPPP PPPPPPPPPP PPPPPPPPPP PPPPPPPPPP 263 Time ----------------------------------------------------------> 264 Marking bit 0000010000 0000010000 0000010000 0000010000 00000 0000 265 ^ ^ ^ ^ ^ 266 Pulse-based | | | | | 267 detection | | | | | 268 Dropped packet: 269 no detection 271 Figure 2: Pulse-based Detection. 273 In step-based detection the event is detected by observing a value 274 change in stream of packets. Specifically, when the step approach is 275 used for LM (as in the double marking method), two counters are used 276 per flow; each MP decides which counter to use based on the value of 277 the marking bit. Thus, the step-based approach allows accurate 278 counting even when packets arrive out-of-order (see Figure 3). When 279 the step approach is used for DM (e.g., single marking using the 280 first packet), out-of-order causes the delay measurement to be false, 281 without any indication to the management system. 283 P: indicates a packet 285 Packets PPPPPPPPPP PPPPPPPPPP PPPPPPPPPP PPPPPPPPPP PPPPPPPPPP 286 Time ----------------------------------------------------------> 287 Marking bit 0000000000 1111111111 000000000 10111111111 0000000000 288 ^ ^ ^ ^ 289 Step-based | | | | 290 detection | | | | 291 out-of-order 293 Figure 3: Step-based Detection. 295 4. Double Marking 297 The two-bit marking method of [RFC8321] uses two marking bits: a 298 color indicator, and a delay measurement indicator. The color bit is 299 used for step-based LM, while the delay bit is used as a pulse-based 300 DM trigger. This double marking approach is the most straightforward 301 of the approaches discussed in this memo, as it allows accurate 302 measurement, it is resilient to out-of-order delivery, and is 303 relatively simple to implement. The main drawback is that it 304 requires two bits, which are not always available. 306 Figure 4 illustrates the double marking method: each block of packets 307 includes a packet that is marked for timestamping, and therefore has 308 its delay bit set. 310 A: packet with color 0 311 B: packet with color 1 313 Packets AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA 314 Time ----------------------------------------------------------> 315 | | | | | 316 | Block 1 | Block 2 | Block 3 | Block 4 | Block 5 ... 317 | | | | | 318 Color bit 0000000000 1111111111 0000000000 1111111111 0000000000 319 Delay bit 0000100000 0000100000 0000100000 0000100000 0001000000 320 ^ ^ ^ ^ ^ 321 Packets | | | | | 322 marked for | | | | | 323 timestamping | | | | | 325 Figure 4: The double marking method. 327 5. Single-bit Marking 329 5.1. Single Marking Using the First Packet 331 This method uses a single marking bit that indicates the color, as 332 described in [RFC8321]. Both LM and DM are implemented using a step- 333 based approach; LM is implemented using two color-based counters per 334 flow. The first packet of every period is used by the two MPs as the 335 reference for measuring the delay. As denoted above, the delay 336 computed in this method may be erroneous when packets are delivered 337 out-of-order. 339 A: packet with color 0 340 B: packet with color 1 342 Packets AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA 343 Time ----------------------------------------------------------> 344 | | | | | 345 | Block 1 | Block 2 | Block 3 | Block 4 | Block 5 ... 346 | | | | | 347 Color bit 0000000000 1111111111 0000000000 1111111111 0000000000 348 ^ ^ ^ ^ ^ 349 Packets | | | | | 350 used for DM | | | | | 352 Figure 5: Single marking using the first packet of the block. 354 5.2. Single Marking using the Mean Delay 356 As in the first-packet approach, in the mean delay approach 357 ([RFC8321]) a single marking bit is used to indicate the color, 358 enabling step-based loss measurement. Delay is measured in each 359 period by averaging the measured delay over all the packets in the 360 period. As discussed above, this approach is not sensitive to out- 361 of-order delivery, but may be heavy from a computational perspective. 363 5.3. Single Marking using a Multiplexed Marking Bit 365 5.3.1. Overview 367 This section introduces a method that uses a single marking bit that 368 serves two purposes: a color indicator, and a timestamp indicator. 369 The double marking method that was discussed in the previous section 370 uses two 1-bit values: a color indicator C, and a timestamp indicator 371 T. The multiplexed marking bit, denoted by M, is an exclusive or 372 between these two values: M = C XOR T. 374 An example of the use of the multiplexed marking bit is depicted in 375 Figure 6. The example considers two routers, R1 and R2, that use the 376 multiplexed bit method to measure traffic from R1 to R2. In each 377 block R1 designates one of the packets for delay measurement. In 378 each of these designated packets the value of the multiplexed bit is 379 reversed compared to the other packets in the same block, allowing R2 380 to distinguish the designated packets from the other packets. 382 A: packet with color 0 383 B: packet with color 1 385 Packets AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA 386 Time ----------------------------------------------------------> 387 | | | | | 388 | Block 1 | Block 2 | Block 3 | Block 4 | Block 5 ... 389 | | | | | 390 Color 0000000000 1111111111 0000000000 1111111111 0000000000 391 ^ ^ ^ ^ ^ 392 Packets | | | | | 393 marked for | | | | | 394 timestamping | | | | | 395 v v v v v 396 Muxed bit 0000100000 1111011111 0000100000 1111101111 0001000000 398 Figure 6: Alternate marking with multiplexed bit. 400 5.4. Pulse Marking 402 Pulse marking uses a single marking bit that is used as a trigger for 403 both LM and DM. In this method the two MPs maintain a single per- 404 flow counter for LM, in contrast to the color-based methods which 405 require two counters per flow. In each block one of the packets is 406 marked. The marked packet triggers two actions in each of MPs: 408 o The timestamp is captured for DM. 410 o The value of the counter is captured for LM. 412 In each period, each of the MPs exports the timestamp and counter- 413 stamp to the management system, which can then compute the loss and 414 delay in that period. It should be noted that as in [RFC8321], if 415 the length of the measurement period is L time units, then all 416 network devices must be synchronized to the same clock reference with 417 an accuracy of +/- L/2 time units. 419 The pulse marking approach is illustrated in Figure 7. Since both LM 420 and DM use a pulse-based trigger, if the marked packet is lost then 421 no measurement is available in this period. Moreover, the LM 422 accuracy may be affected by out-of-order delivery. 424 P: packet - all packets have the same color 426 Packets PPPPPPPPPP PPPPPPPPP PPPPPPPPPP PPPPPPPPPP PPPPPPPPPP 427 Time ----------------------------------------------------------> 428 | | | | | 429 | Block 1 | Block 2 | Block 3 | Block 4 | Block 5 ... 430 | | | | | 431 ^ ^ ^ ^ ^ 432 Packets | | | | | 433 marked for | | | | | 434 DM and LM | | | | | 435 v v v v v 436 Marking bit 0000100000 0000100000 0000100000 0000010000 0001000000 438 Figure 7: Pulse marking method. 440 6. Zero Marking Hashed 442 6.1. Hash-based Sampling 444 Hash based selection [RFC5475] is a well-known method for sampling a 445 subset of packets. As defined in [RFC5475]: 447 A Hash Function h maps the Packet Content c, or some portion of 448 it, onto a Hash Range R. The packet is selected if h(c) is an 449 element of S, which is a subset of R called the Hash Selection 450 Range. 452 Hash-based selection can be leveraged as a marking method, allowing a 453 zero-bit marking approach. Specifically, the pulse and step 454 abstractions can be implemented using hashed selection: 456 o Hashed pulse-based trigger: in this approach, a packet is selected 457 if h(c) is an element of S, which is a strict subset of the hash 458 range R. When |S|<<|R|, the average sampling period is long, 459 reducing the probability of ambiguity between consecutive 460 packets. |S| and |R| denote the number of elements in S and R, 461 respectively. 463 o Hashed step-based trigger: the hash values of a given traffic flow 464 are said to be monotonically increasing if for two packets p1 and 465 p2, if p1 is sent before p2 then h(p1)<=h(p2). If it is 466 guaranteed that the hash values of a flow are monotonically 467 increasing, then a step-based approach can be used on the range R. 468 For example, in an IPv4 flow the Identification field can be used 469 as the hash value of each packet. Since the Identification field 470 is monotonically increasing, the step-based trigger can be 471 implemented using consecutive ranges of the Identification value. 472 For example, the fourth bit of the Identification field is toggled 473 every 8 packets. Thus, a possible hash function simply takes the 474 fourth bit of the Identification field as the hash value. This 475 hash value is toggled every 8 packets, simulating the alternate 476 marking behavior of Section 4. 478 Note that as opposed to the double marking and single marking 479 methods, hashed sampling is not based on fixed time intervals, as the 480 duration between sampled packets depends only on the hash value. 482 It is also important to note that all methods that use hash-based 483 marking require the hash function and the set S to be configured 484 consistently across the MPs. 486 6.1.1. Hashed Pulse Marking 488 In this approach a hash is computed over the packet content, and both 489 LM and DM are triggered based on the pulse-based trigger 490 (Section 6.1). A pulse is detected when the hash value h(c) is equal 491 to one of the values in S. The hash function h and the set S 492 determine the probability (or frequency) of the pulse event. 494 6.1.2. Hashed Step Marking 496 As in the previous approach, hashed step marking also uses a hash 497 that is computed over the packet content. In this approach DM is 498 performed using a pulse-based trigger, whereas the LM trigger is 499 step-based (Section 6.1). The main drawback of this method is that 500 the step-based trigger is possible only under the assumption that the 501 hash function is monotonically increasing, which is not necessarily 502 possible in all cases. Specifically, a measured flow is not 503 necessarily an IPv4 5-tuple. For example, a measured flow may 504 include multiple IPv4 5-tuple flows, and in this case the 505 Identification field is not monotonically increasing. 507 7. Single Marking Hashed 509 Mixed hashed marking combines the single marking approach with hash- 510 based sampling. A single marking bit is used in the packet header as 511 a color indicator, while a hash-based pulse is used to trigger DM. 512 Although this method requires a single bit, it is described in this 513 section as it is closely related to the other hash-based methods that 514 require zero marking bits. 516 The hash-based selection for DM can be applied in one of two possible 517 approaches: the basic approach, and the dynamic approach. In the 518 basic approach, packets forwarded between two MPs, MP1 and MP2, are 519 selected using a hash function, as described above. One of the 520 challenges is that the frequency of the sampled packets may vary 521 considerably, making it difficult for the management system to 522 correlate samples from the two MPs. Thus, the dynamic approach can 523 be used. 525 In the dynamic hash-based sampling, alternate marking is used to 526 create divide time into periods, so that hash-based samples are 527 divided into batches, allowing to anchor the selected samples to 528 their period. Moreover, by dynamically adapting the length of the 529 hash value, the number of samples is bounded in each marking period. 530 This can be realized by choosing first the maximum number of samples 531 (NMAX) to be used with the initial hash length. The algorithm starts 532 with only few hash bits, that permit to select a greater percentage 533 of packets (e.g. with 1 bit of hash half of the packets are sampled). 534 When the number of selected packets reaches NMAX, a hashing bit is 535 added. As a consequence, the sampling proceeds at half of the 536 original rate and the packets already selected that do not match the 537 new hash are discarded. This step can be repeated iteratively. It 538 is assumed that each sample includes the timestamp (used for DM) and 539 the hash value, allowing the management system to match the samples 540 received from the two MPs. 542 The dynamic process statistically converges at the end of a marking 543 period and the number of selected samples beyond the initial NMAX 544 samples mentioned above is between NMAX/2 and NMAX. Therefore, the 545 dynamic approach paces the sampling rate, allowing to bound the 546 number of sampled packets per sampling period. 548 8. Timing and Synchronization Aspects 550 As pointed out in [RFC8321], it is assumed that all MPs are 551 synchronized to a common reference time with an accuracy of +/- L/2, 552 where L is the periodic measurement interval. Thus, the difference 553 between the clock values of any two MPs is bounded by L. Note that 554 this is a relatively relaxed synchronization requirement that does 555 not require complex means of synchronization. Clocks can be 556 synchronized for example using NTP [RFC5905], PTP [IEEE1588], or by 557 other means. 559 In the step-based approaches the common reference time is used for 560 dividing the time domain into equal-sized measurement periods, such 561 that all packets forwarded during a measurement period have the same 562 color, and consecutive periods have alternating colors. In the 563 pulse-based approaches the synchronization helps the management 564 system to correlate measurements from multiple measurement points 565 without ambiguity. 567 8.1. Synchronization Aspects in Multiplexed Marking 569 The single marking bit incorporates two multiplexed values. From the 570 monitoring MP's perspective, the two values are Time-Division 571 Multiplexed (TDM), as depicted in Figure 8. It is assumed that the 572 start time of every measurement period is known to both the 573 initiating MP and the monitoring MP. If the measurement period is L, 574 then during the first and the last L/4 time units of each block the 575 marking bit is interpreted by the monitoring MP as a color indicator. 576 During the middle part of the block, the marking bit is interpreted 577 as a timestamp indicator; if the value of this bit is different than 578 the color value, the corresponding packet is used as a reference for 579 delay measurement. 581 +--- Beginning of measurement period 582 | 583 v 585 ...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB... 586 |<======================================>| 587 | L | 588 <========>|<========><==================><========>|<========> 589 L/4 L/4 L/2 L/4 L/4 591 <===================><==================><===================> 592 Detect color Detect timestamping Detect color 593 change indication change 595 Figure 8: Multiplexed marking field interpretation at the receiving 596 measurement point. 598 In order to prevent ambiguity in the receiver's interpretation of the 599 marking field, the initiating MP is permitted to set the timestamp 600 indication only during a specific interval, as depicted in Figure 9. 601 Since the receiver is willing to receive the timestamp indication 602 during the middle L/2 time units of the block, the sender refrains 603 from sending the timestamp indication during a guardband interval of 604 d time units at the beginning and end of the L/2-period. 606 +--- Beginning of measurement period 607 | 608 v 610 ...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB... 611 |<======================================>| 612 | L | 613 <========>|<========>|<================>|<========>| 614 L/4 L/4 | L/2 | L/4 615 <=>|<=> <=>|<=> 616 d d d d 617 <==========> 618 permissible 619 timestamping 620 indication 621 interval 623 Figure 9: A time domain view. 625 The guardband d is given by d = A + D_max - D_min, where A is the 626 clock accuracy, D_max is an upper bound on the network delay between 627 the MPs, and D_min is a lower bound on the delay. It is 628 straightforward from Figure 9 that d < L/4 must be satisfied. The 629 latter implies a minimal requirement on the synchronization accuracy. 631 All MPs must be synchronized to the same reference time with an 632 accuracy of +/- L/8. Depending on the system topology, in some 633 systems the accuracy requirement will be even more stringent, subject 634 to d < L/4. Note that the accuracy requirement of the conventional 635 alternate marking method [RFC8321] is +/- L/2, while the multiplexed 636 marking method requires an accuracy of +/- L/8. 638 Note that we assume that the middle L/2-period is designated as the 639 timestamp indication period, allowing a sufficiently long guardband 640 between the transitions. However, a system may be configured to use 641 a longer timestamp indication period or a shorter one, if it is 642 guaranteed that the synchronization accuracy meets the guardband 643 requirements (i.e., the constraints on d). 645 9. Multipoint Marking Methods 647 It should be noted that most of the marking methods that were 648 presented in this memo are intended for point-to-point measurements, 649 e.g., from MP1 to MP2 in Figure 10. In point-to-multipoint 650 measurements, the mean delay method can be used to measure the loss 651 and delay of the entire point-to-multipoint flow (which includes all 652 the traffic from MP3 to either MP4 or MP5), while other methods such 653 as double marking can be used to measure the point-to-point 654 performance, for example from MP3 to MP5. Alternate marking in 655 multipoint scenarios is discussed in detail in 656 [I-D.ietf-ippm-multipoint-alt-mark]. 658 MP1 MP2 MP3 MP4 659 +--+ +--+ +--+ +--+ +--+ 660 | |---------->| | | |----->| |----->| | 661 +--+ +--+ +--+ +--+ +--+ 662 | 663 | MP5 664 | +--+ 665 +------>| | 666 +--+ 668 Point-to-point measurement Point-to-multipoint measurement 670 Figure 10: Point-to-point and point-to-multipoint measurements. 672 10. Summary of Marking Methods 674 This section summarizes the marking methods described in this memo. 675 Each row in the table of Figure 11 represents a marking method. For 676 each method the table specifies the number of bits required in the 677 header, the number of counters per flow for LM, the methods used for 678 LM and DM (pulse or step), and also the resilience to disturbances. 680 +--------------+----+----+------+------+-------------+-------------+ 681 | Method |# of|# of|LM |DM |Resilience to|Resilience to| 682 | |bits|coun|Method|Method|Reordering |Packet drops | 683 | | |ters| | +------+------+------+------+ 684 | | | | | | LM | DM | LM | DM | 685 +--------------+----+----+------+------+------+------+------+------+ 686 |Single marking| 1 | 2 |Step |Step | + | -- | + | -- | 687 |- 1st packet | | | | | | | | | 688 +--------------+----+----+------+------+------+------+------+------+ 689 |Single marking| 1 | 2 |Step |Mean | + | + | + | - | 690 |- mean delay | | | | | | | | | 691 +--------------+----+----+------+------+------+------+------+------+ 692 |Double marking| 2 | 2 |Step |Pulse | + | + | + | = | 693 +--------------+----+----+------+------+------+------+------+------+ 694 |Single marking| 1 | 2 |Step |Pulse | + | + | + | = | 695 |multiplexed | | | | | | | | | 696 +--------------+----+----+------+------+------+------+------+------+ 697 |Pulse marking | 1 | 1 |Pulse |Pulse | -- | + | - | = | 698 +--------------+----+----+------+------+------+------+------+------+ 699 |Zero marking | 0 | 1 |Hashed|Hashed| -- | + | - | + | 700 |hashed | |(2) |pulse |pulse | (-) | | | | 701 | | | |(step)| | | | | | 702 +--------------+----+----+------+------+------+------+------+------+ 703 |Single marking| 1 | 2 |Step |Hashed| + | + | + | + | 704 |hashed | | | |pulse | | | | | 705 +--------------+----+----+------+------+------+------+------+------+ 707 + Accurate measurement. 708 = Invalidate only if a measured packet is lost (detectable) 709 - No measurement in case of disturbance (detectable). 710 -- False measurement in case of disturbance (not detectable). 712 Figure 11: Detailed Summary of Marking Methods 714 In the context of this comparison two possible disturbances are 715 considered: out-of-order delivery, and packet drops. Generally 716 speaking, pulse based methods are sensitive to packet drops, since if 717 the marked packet is dropped no measurement is recorded in the 718 current period. Notably, a missing measurement is detectable by the 719 management system, and is not as severe as a false measurement. 720 Step-based triggers are generally resilient to out-of-order delivery 721 for LM, but are not resilient to out-of-order delivery for DM. 722 Notably, a step-based trigger may yield a false delay measurement 723 when packets are delivered out-of-order, and this inaccuracy is not 724 detectable. 726 As mentioned above, the double marking method is the most 727 straightforward approach, and is resilient to most of the 728 disturbances that were analyzed. Its obvious drawback is that it 729 requires two marking bits. 731 Several single marking methods are discussed in this memo. In this 732 case there is no clear verdict which method is the optimal one. The 733 first packet method may be simple to implement, but may present 734 erroneous delay measurements in case of dropped or reordered packets. 735 Arguably, the mean delay approach and the multiplexed approach may be 736 more difficult to implement (depending on the underlying platform), 737 but are more resilient to the disturbances that were considered here. 738 Note that the computational complexity of the mean delay approach can 739 be reduced by combining it with a hashed approach, i.e., by computing 740 the mean delay over a hash-based subset of the packets. The pulse 741 marking method requires only a single counter per flow, while the 742 other methods require two counters per flow. 744 The hash-based sampling approaches reduce the overhead to zero bits, 745 which is a significant advantage. However, the sampling period in 746 these approaches is not associated with a fixed time interval. 747 Therefore, in some cases adjacent packets may be selected for the 748 sampling, potentially causing measurement errors. Furthermore, when 749 the traffic rate is low, measurements may become signifcantly 750 infrequent. 752 It is clear from the previous table that packet loss measurement can 753 be considered resilient to both reordering and packet drops if at 754 least one bit is used with a step-based approach. Thus, since the 755 packet loss can be considered obvious, the previous table can be 756 simplified into Figure 12, where only the characteristics of delay 757 measurements are highlighted. This more compact table allows room 758 for an additional column referring to multipoint-to-multipoint 759 (Section 9) delay measurement compatibility. 761 +--------------+----+--------+------------+------------+-----------+ 762 | Marking |# of|LM |DM |DM |DM | 763 | Method |bits|on |Resilience |Resilience |Multipoint | 764 | | |All |to |to |compatible | 765 | | |Packets |Reordering |Packet drops| | 766 +--------------+----+--------+------------+------------+-----------+ 767 |Single marking| 1 | Yes | -- | - | No | 768 |- 1st packet | | | | | | 769 +--------------+----+--------+------------+------------+-----------+ 770 |Single marking| 1 | Yes | + | - | Yes | 771 |- mean delay | | | | | | 772 +--------------+----+--------+------------+------------+-----------+ 773 |Double marking| 2 | Yes | + | = | No | 774 +--------------+----+--------+------------+------------+-----------+ 775 |Single marking| 1 | Yes | + | = | No | 776 |multiplexed | | | | | | 777 +--------------+----+--------+------------+------------+-----------+ 778 |Pulse marking | 1 | No | + | = | No | 779 +--------------+----+--------+------------+------------+-----------+ 780 |Zero marking | 0 | No | + | + | Yes | 781 |hashed | | | | | | 782 | | | | | | | 783 +--------------+----+--------+------------+------------+-----------+ 784 |Single marking| 1 | Yes | + | + | Yes | 785 |hashed | | | | | | 786 +--------------+----+--------+------------+------------+-----------+ 788 + Accurate measurement. 789 = Invalidate only if a measured packet is lost (detectable) 790 - No measurement in case of disturbance (detectable). 791 -- False measurement in case of disturbance (not detectable). 793 Figure 12: Summary of Marking Methods: focus on Delay Measurement 795 In the context of delay measurement, both zero marking hashed and 796 single marking hashed are resilient to packet drops. Using double 797 marking it could also be possible to perform an accurate measurement 798 in case of packet drops, as long as the packet that is marked for DM 799 is not dropped. 801 The single marking hashed method seems the most complete approach, 802 especially because it is also compatible with multipoint-to- 803 multipoint measurements. 805 11. Alternate Marking using Reserved Values 807 As mentioned in Section 1, a marking bit is not necessarily a single 808 bit, but may be implemented by using two well-known values in one of 809 the header fields. Similarly, two-bit marking can be implemented 810 using four reserved values. 812 A notable example is MPLS Synonymous Flow Labels (SFL), as defined in 813 [I-D.ietf-mpls-rfc6374-sfl]. Two MPLS Label values can be used to 814 indicate the two colors of a given LSP: the original Label value, and 815 an SFL value. A similar approach can be applied to IPv6 using the 816 Flow Label field. 818 The following example illustrates how alternate marking can be 819 implemented using reserved values. The bit multiplexing approach of 820 Section 5.3 is applicable not only to single-bit color indicators, 821 but also to two-value indicators; instead of using a single bit that 822 is toggled between '0' and '1', two values of the indicator field, U 823 and W, can be used in the same manner, allowing both loss and delay 824 measurement to be performed using only two reserved values. Thus, 825 the multiplexing approach of Figure 6 can be illustrated more 826 generally with two values, U and W, as depicted in Figure 13. 828 A: packet with color 0 829 B: packet with color 1 831 Packets AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA 832 Time ----------------------------------------------------------> 833 | | | | | 834 | Block 1 | Block 2 | Block 3 | Block 4 | Block 5 ... 835 | | | | | 836 Color 0000000000 1111111111 0000000000 1111111111 0000000000 837 ^ ^ ^ ^ ^ 838 Packets | | | | | 839 marked for | | | | | 840 timestamping | | | | | 841 v v v v v 842 Muxed UUUUWUUUUU WWWWUWWWWW UUUUWUUUUU WWWWWUWWWW UUUWUUUUUU 843 marking 844 values 846 Figure 13: Alternate marking with two multiplexed marking values, U 847 and W. 849 12. IANA Considerations 851 This memo includes no requests from IANA. 853 13. Security Considerations 855 The security considerations of the alternate marking method are 856 discussed in [RFC8321]. The analysis of Section 10 emphasizes the 857 sensitivity of some of the alternate marking methods to packet drops 858 and to packet reordering. Thus, a malicious attacker may attempt to 859 tamper with the measurements by either selectively dropping packets, 860 or by selectively reordering specific packets. The multiplexed 861 marking method Section 5.3 that is defined in this document requires 862 slightly more stringent synchronization than the conventional marking 863 method, potentially making the method more vulnerable to attacks on 864 the time synchronization protocol. A detailed discussion about the 865 threats against time protocols and how to mitigate them is presented 866 in [RFC7384]. 868 14. References 870 14.1. Normative References 872 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 873 Requirement Levels", BCP 14, RFC 2119, 874 DOI 10.17487/RFC2119, March 1997, 875 . 877 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 878 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 879 "Alternate-Marking Method for Passive and Hybrid 880 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 881 January 2018, . 883 14.2. Informative References 885 [I-D.ietf-ippm-multipoint-alt-mark] 886 Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto, 887 "Multipoint Alternate Marking method for passive and 888 hybrid performance monitoring", draft-ietf-ippm- 889 multipoint-alt-mark-02 (work in progress), July 2019. 891 [I-D.ietf-mpls-rfc6374-sfl] 892 Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., 893 Mirsky, G., and G. Fioccola, "RFC6374 Synonymous Flow 894 Labels", draft-ietf-mpls-rfc6374-sfl-03 (work in 895 progress), December 2018. 897 [I-D.ietf-mpls-sfl-framework] 898 Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., 899 and G. Mirsky, "Synonymous Flow Label Framework", draft- 900 ietf-mpls-sfl-framework-04 (work in progress), December 901 2018. 903 [IEEE1588] 904 IEEE, "IEEE 1588 Standard for a Precision Clock 905 Synchronization Protocol for Networked Measurement and 906 Control Systems Version 2", 2008. 908 [RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., 909 Grossglauser, M., and J. Rexford, "A Framework for Packet 910 Selection and Reporting", RFC 5474, DOI 10.17487/RFC5474, 911 March 2009, . 913 [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. 914 Raspall, "Sampling and Filtering Techniques for IP Packet 915 Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, 916 . 918 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 919 "Network Time Protocol Version 4: Protocol and Algorithms 920 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 921 . 923 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 924 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 925 October 2014, . 927 Authors' Addresses 929 Tal Mizrahi 930 Huawei Network.IO Innovation Lab 931 Israel 933 Email: tal.mizrahi.phd@gmail.com 935 Carmi Arad 937 Email: carmi.arad@gmail.com 939 Giuseppe Fioccola 940 Huawei Technologies 942 Email: giuseppe.fioccola@huawei.com 943 Mauro Cociglio 944 Telecom Italia 945 Via Reiss Romoli, 274 946 Torino 10148 947 Italy 949 Email: mauro.cociglio@telecomitalia.it 951 Mach(Guoyi) Chen 952 Huawei Technologies 954 Email: mach.chen@huawei.com 956 Lianshu Zheng 957 Huawei Technologies 959 Email: vero.zheng@huawei.com 961 Greg Mirsky 962 ZTE Corp. 964 Email: gregimirsky@gmail.com