idnits 2.17.1 draft-mizrahi-ippm-multiplexed-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 5, 2017) is 2610 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-ippm-alt-mark-04 == Outdated reference: A later version (-04) exists of draft-bryant-mpls-rfc6374-sfl-03 == Outdated reference: A later version (-05) exists of draft-bryant-mpls-sfl-framework-02 Summary: 0 errors (**), 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 Marvell 4 Intended status: Informational G. Fioccola 5 Expires: September 6, 2017 Telecom Italia 6 M. Chen 7 L. Zheng 8 Huawei Technologies 9 G. Mirsky 10 March 5, 2017 12 Passive Performance Monitoring using a Multiplexed Marking Field 13 draft-mizrahi-ippm-multiplexed-alternate-marking-01 15 Abstract 17 This memo introduces a marking method that uses a single marking bit, 18 or two marking values, and allows accurate loss and delay 19 measurement. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 6, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 58 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Alternate Marking using a Multiplexed Marking Bit . . . . . . 4 60 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. Timing and Synchronization Aspects . . . . . . . . . . . 5 62 4. Alternate Marking using Two Multiplexed Marking Values . . . 7 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 7.2. Informative References . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 Alternate marking, defined in [I-D.ietf-ippm-alt-mark], is a method 73 for measuring packet loss, packet delay, and packet delay variation. 74 Typical delay measurement protocols require the two measurement 75 points (MPs) to exchange timestamped test packets. In contrast, the 76 alternate marking method does not require control packets to be 77 exchanged. Instead, every data packet carries a color indicator, 78 which divides the traffic into consecutive blocks of packets. 80 The color indicator may either be a single-bit binary indication, or 81 a two reserved values of a larger field, such as an IPv6 Flow Label 82 or an MPLS Label. Throughout the rest of the document it is assumed 83 that the color indication is a single-bit field, unless specified 84 otherwise. The color value is toggled periodically, as illustrated 85 in Figure 1. 87 A: packet with color 0 88 B: packet with color 1 90 Packets AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA 91 Time ----------------------------------------------------------> 92 | | | | | 93 | Block 1 | Block 2 | Block 3 | Block 4 | Block 5 ... 94 | | | | | 95 Color 0000000000 1111111111 0000000000 1111111111 0000000000 97 Figure 1: Alternate marking: packets are monitored on a per-color 98 basis. 100 Alternate marking is used between two MPs, the initiating MP, and the 101 monitoring MP. The initiating MP incorporates the marking field into 102 en-route packets, allowing the monitoring MP to use the marking field 103 in order to bind each packet to the corresponding block. 105 Each of the MPs maintains two counters, one per color. At the end of 106 each block the counter values can be collected by a central 107 management system, and analyzed; the packet loss can be computed by 108 comparing the counter values of the two MPs. 110 When using alternate marking delay measurement can be performed in 111 one of three ways (as per [I-D.ietf-ippm-alt-mark]): 113 o Single marking: the first packet of each block is used by both MPs 114 as a reference for delay measurement. The timestamp of this 115 packet is measured by the two measurement points, and can be 116 collected by the mangement system from each of the measurement 117 points, which can compute the path delay by comparing the two 118 timestamps. The drawback of this approach is that it is not 119 accurate when packets arrive out-of-order, as the two measurement 120 may have a different view of which packet was the first in the 121 block. 123 o Average delay: each of the MPs computes the average packet 124 timestamp of each block. The management system can then compute 125 the delay by comparing the average times of the two MPs. The 126 drawback of this approach is that it may be computationally heavy, 127 or difficult to implement at the data plane. 129 o Double marking: each packet uses two marking bits. One bit is 130 used as a color indicator, and one is used as a timestamping 131 indicator. This method resolves the drawbacks raised for the two 132 previous methods, at the expense of an extra bit in the packet 133 header. 135 The double marking method allows for accurate measurement without 136 incurring expensive computational load. However, in some cases 137 allocating two bits for passive measurement is not possible. For 138 example, if alternate marking is implemented over IPv4, allocating 2 139 marking bits in the IPv4 header is challenging, as every bit in the 140 20-octet header is costly; one of the possible approaches discussed 141 in [I-D.ietf-ippm-alt-mark] is reserve one or two bits from the DSCP 142 field for remarking. In this case every marking bit comes at the 143 expense of reducing the DSCP range by a factor of two. 145 This memo extends the marking method of [I-D.ietf-ippm-alt-mark]. 146 The method introduced in this document uses a single marking bit in 147 the packet header, while providing the advantages of the double 148 marking method. In a nutshell, the color indicator and the timestamp 149 indicator are multiplexed into a single bit. There is an underlying 150 assumption that the two MPs that take part in the measurement are 151 time-synchronized. 153 2. Terminology 155 2.1. Requirements Language 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119 [RFC2119]. 161 2.2. Abbreviations 163 MP Measurement Point 165 MPLS Multiprotocol Label Switching 167 DSCP Differentiated Services Code Point 169 LSP Label Switched Path 171 SFL Synonymous Flow Label [I-D.bryant-mpls-sfl-framework] 173 3. Alternate Marking using a Multiplexed Marking Bit 175 3.1. Overview 177 This section introduces a method that uses a single marking bit that 178 serves two purposes: a color indicator, and a timestamp indicator. 179 The double marking method that was discussed in the previous section 180 uses two 1-bit values: a color indicator C, and a timestamp indicator 181 T. The multiplexed marking bit, denoted by M, is an exclusive or 182 between these two values: M = C XOR T. 184 An example of the use of the multiplexed marking bit is depicted in 185 Figure 2. The example considers two routers, R1 and R2, that use the 186 multiplexed bit method to measure traffic from R1 to R2. In each 187 block R1 designates one of the packets for delay measurement. In 188 each of these designated packets the value of the multiplexed bit is 189 reversed compared to the other packets in the same block, allowing R2 190 to distinguish the designated packets from the other packets. 192 A: packet with color 0 193 B: packet with color 1 195 Packets AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA 196 Time ----------------------------------------------------------> 197 | | | | | 198 | Block 1 | Block 2 | Block 3 | Block 4 | Block 5 ... 199 | | | | | 200 Color 0000000000 1111111111 0000000000 1111111111 0000000000 201 ^ ^ ^ ^ ^ 202 Packets | | | | | 203 marked for | | | | | 204 timestamping | | | | | 205 v v v v v 206 Muxed bit 0000100000 1111011111 0000100000 1111101111 0001000000 208 Figure 2: Alternate marking with multiplexed bit. 210 3.2. Timing and Synchronization Aspects 212 It is assumed that all MPs are synchronized to a common reference 213 time with an accuracy of +/- A/2. Thus, the difference between the 214 clock values of any two MPs is bounded by A. Clocks can be 215 synchronized for example using NTP [RFC5905], PTP [IEEE1588], or by 216 other means. The common reference time is used for dividing the time 217 domain into equal-sized measurement periods, such that all packets 218 forwarded during a measurement period have the same color, and 219 consecutive periods have alternating colors. 221 The single marking bit incorporates two multiplexed values. From the 222 monitoring MP's perspective, the two values are Time-Division 223 Multiplexed (TDM), as depicted in Figure 3. It is assumed that the 224 start time of every measurement period is known to both the 225 initiating MP and the monitoring MP. If the measurement period is L, 226 then during the first and the last L/4 time units of each block the 227 marking bit is interpreted by the monitoring MP as a color indicator. 228 During the middle part of the block, the marking bit is interpreted 229 as a timestamp indicator; if the value of this bit is different than 230 the color value, the corresponding packet is used as a reference for 231 delay measurement. 233 +--- Beginning of measurement period 234 | 235 v 237 ...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB... 238 |<======================================>| 239 | L | 240 <========>|<========><==================><========>|<========> 241 L/4 L/4 L/2 L/4 L/4 243 <===================><==================><===================> 244 Detect color Detect timestamping Detect color 245 change indication change 247 Figure 3: Multiplexed marking field interpretation at the receiving 248 measurement point. 250 In order to prevent ambiguity in the receiver's interpretation of the 251 marking field, the initiating MP is permitted to set the timestamp 252 indication only during a specific interval, as depicted in Figure 4. 253 Since the receiver is willing to receive the timestamp indication 254 during the middle L/2 time units of the block, the sender refrains 255 from sending the timestamp indication during a guardband interval of 256 d time units at the beginning and end of the L/2-period. 258 +--- Beginning of measurement period 259 | 260 v 262 ...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB... 263 |<======================================>| 264 | L | 265 <========>|<========>|<================>|<========>| 266 L/4 L/4 | L/2 | L/4 267 <=>|<=> <=>|<=> 268 d d d d 269 <==========> 270 permissible 271 timestamping 272 indication 273 interval 275 Figure 4: A time domain view. 277 The guardband d is given by d = A + D_max - D_min, where A is the 278 clock accuracy, D_max is an upper bound on the network delay between 279 the MPs, and D_min is a lower bound on the delay. It is 280 straightforward from Figure 4 that d < L/4 must be satisfied. The 281 latter implies a minimal requirement on the synchronization accuracy. 283 All MPs must be synchronized to the same reference time with an 284 accuracy of +/- L/8. Depending on the system topology, in some 285 systems the accuracy requirement will be even more stringent, subject 286 to d < L/4. Note that the accuracy requirement of the conventional 287 alternate marking method [I-D.ietf-ippm-alt-mark] is +/- L/2, while 288 the multiplexed marking method requires an accuracy of +/- L/8. 290 Note that we assume that the middle L/2-period is designated as the 291 timestamp indication period, allowing a sufficiently long guardband 292 between the transitions. However, a system may be configured to use 293 a longer timestamp indication period or a shorter one, if it is 294 guaranteed that the synchronization accuracy meets the guardband 295 requirements (i.e., the constraints on d). 297 4. Alternate Marking using Two Multiplexed Marking Values 299 As mentioned above, the color indicator is not necessarily a single 300 bit, but may be implemented by using two well-known values in one of 301 the header fields. For example, as defined in 302 [I-D.bryant-mpls-rfc6374-sfl], two MPLS Label values can be used to 303 indicate the two colors of a given LSP: the original Label value, and 304 a Synonymous Flow Label (SFL) value. 306 The bit multiplexing approach of Section 3 is applicable not only to 307 single-bit color indicators, but also to two-value indicators; 308 instead of using a single bit that is toggled between '0' and '1', 309 two values of the indicator field, U and W, can be used in the same 310 manner, allowing both loss and delay measurement to be performed 311 using only two reserved values. Thus, the multiplexing approach of 312 Figure 2 can be illustrated more generally with two values, U and W, 313 as depicted in Figure 5. 315 A: packet with color 0 316 B: packet with color 1 318 Packets AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA BBBBBBBBBB AAAAAAAAAA 319 Time ----------------------------------------------------------> 320 | | | | | 321 | Block 1 | Block 2 | Block 3 | Block 4 | Block 5 ... 322 | | | | | 323 Color 0000000000 1111111111 0000000000 1111111111 0000000000 324 ^ ^ ^ ^ ^ 325 Packets | | | | | 326 marked for | | | | | 327 timestamping | | | | | 328 v v v v v 329 Muxed UUUUWUUUUU WWWWUWWWWW UUUUWUUUUU WWWWWUWWWW UUUWUUUUUU 330 marking 331 values 333 Figure 5: Alternate marking with two multiplexed marking values, U 334 and W. 336 5. IANA Considerations 338 This memo includes no requests from IANA. 340 6. Security Considerations 342 The security considerations of the alternate marking method are 343 discussed in [I-D.ietf-ippm-alt-mark]. Specifically, the method that 344 is defined in this document requires slightly more stringent 345 synchronization than the conventional marking method, potentially 346 making the method more vulnerable to attacks on the time 347 synchronization protocol. A detailed discussion about the threats 348 against time protocols and how to mitigate them is presented in 349 [RFC7384]. 351 7. References 353 7.1. Normative References 355 [I-D.ietf-ippm-alt-mark] 356 Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., 357 Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 358 "Alternate Marking method for passive performance 359 monitoring", draft-ietf-ippm-alt-mark-04 (work in 360 progress), March 2017. 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, 364 DOI 10.17487/RFC2119, March 1997, 365 . 367 7.2. Informative References 369 [I-D.bryant-mpls-rfc6374-sfl] 370 Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., 371 Mirsky, G., and G. Fioccola, "RFC6374 Synonymous Flow 372 Labels", draft-bryant-mpls-rfc6374-sfl-03 (work in 373 progress), October 2016. 375 [I-D.bryant-mpls-sfl-framework] 376 Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., 377 and G. Mirsky, "Synonymous Flow Label Framework", draft- 378 bryant-mpls-sfl-framework-02 (work in progress), October 379 2016. 381 [IEEE1588] 382 IEEE, "IEEE 1588 Standard for a Precision Clock 383 Synchronization Protocol for Networked Measurement and 384 Control Systems Version 2", 2008. 386 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 387 "Network Time Protocol Version 4: Protocol and Algorithms 388 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 389 . 391 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 392 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 393 October 2014, . 395 Authors' Addresses 397 Tal Mizrahi 398 Marvell 399 6 Hamada st. 400 Yokneam 401 Israel 403 Email: talmi@marvell.com 404 Giuseppe Fioccola 405 Telecom Italia 406 Via Reiss Romoli, 274 407 Torino 10148 408 Italy 410 Email: giuseppe.fioccola@telecomitalia.it 412 Mach(Guoyi) Chen 413 Huawei Technologies 415 Email: mach.chen@huawei.com 417 Lianshu Zheng 418 Huawei Technologies 420 Email: vero.zheng@huawei.com 422 Greg Mirsky 423 USA 425 Email: gregimirsky@gmail.com