idnits 2.17.00 (12 Aug 2021) /tmp/idnits46960/draft-fioccola-ippm-alt-mark-active-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-ippm-alt-mark], [RFC4656], [RFC6374], [RFC5357]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 1888 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3270' is mentioned on line 449, but not defined == 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-03 == Outdated reference: draft-ietf-ippm-alt-mark has been published as RFC 8321 == Outdated reference: draft-ietf-mpls-flow-ident has been published as RFC 8372 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Fioccola 3 Internet-Draft Telecom Italia 4 Intended status: Informational A. Clemm 5 Expires: September 14, 2017 S. Bryant 6 Huawei 7 M. Cociglio 8 Telecom Italia 9 M. Chandramouli 10 Cisco Systems 11 A. Capello 12 Telecom Italia 13 March 13, 2017 15 Alternate Marking Extension to Active Measurement Protocol 16 draft-fioccola-ippm-alt-mark-active-01 18 Abstract 20 This document describes how to extend the existing Active Measurement 21 Protocol, in order to implement alternate marking methodology 22 detailed in [I-D.ietf-ippm-alt-mark]. The extension for Two-Way 23 Active Measurement Protocol (TWAMP) RFC 5357 [RFC5357] and One-way 24 Active Measurement Protocol (OWAMP) RFC 4656 [RFC4656] will be 25 considered. RFC6374 [RFC6374] Use Case is also reported. This 26 proposal defines a simplified mechanism with benefits to the metric 27 precision and computational load. Hybrid measurements are also 28 enabled. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on September 14, 2017. 53 Copyright Notice 55 Copyright (c) 2017 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Description of the method . . . . . . . . . . . . . . . . . . 3 72 2.1. Packet loss measurement . . . . . . . . . . . . . . . . . 4 73 2.2. Delay measurement . . . . . . . . . . . . . . . . . . . . 5 74 2.3. Delay variation measurement . . . . . . . . . . . . . . . 6 75 3. Hybrid measurement . . . . . . . . . . . . . . . . . . . . . 6 76 4. Protocol Extension overview . . . . . . . . . . . . . . . . . 7 77 4.1. Control Phase . . . . . . . . . . . . . . . . . . . . . . 8 78 4.2. Test Phase . . . . . . . . . . . . . . . . . . . . . . . 8 79 4.3. Calculation Phase . . . . . . . . . . . . . . . . . . . . 9 80 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 5.1. Extension of TWAMP/OWAMP Control Protocol . . . . . . . . 10 82 5.2. Extension of TWAMP/OWAMP Test Protocol . . . . . . . . . 10 83 6. RFC6374 Use Case . . . . . . . . . . . . . . . . . . . . . . 10 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 89 10.2. Informative References . . . . . . . . . . . . . . . . . 12 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 92 1. Introduction 94 The Two-Way Active Measurement Protocol (TWAMP), specified in RFC 95 5357 [RFC5357] adds two-way or round-trip measurement capabilities to 96 the One-way Active Measurement Protocol (OWAMP) specified in RFC 4656 97 [RFC4656]. OWAMP can be used bi-directionally to measure one-way 98 metrics in both directions between two network elements. The TWAMP 99 measurement architecture is usually comprised of two hosts with 100 specific roles, and this allows for some protocol simplifications, 101 making it an attractive alternative in some circumstances. Another 102 example is Cisco's Service-Level Assurance Protocol (Cisco's SLA 103 Protocol) RFC 6812 [RFC6812], a Performance Measurement protocol that 104 has been widely deployed. Details are explained in 105 [I-D.fioccola-ippm-rfc6812-alt-mark-ext]. 107 One technique for passive performance measurements is described in 108 [I-D.ietf-ippm-alt-mark]. This technique involves marking production 109 flows as they traverse the network, then analyzing flow data 110 associated with those marked flows. Passive measurements are very 111 accurate in that they measure actual production traffic. However, 112 there are scenarios in which passive measurements are not an option. 113 For example, there may be no suitable flows currently occurring 114 between pairs of nodes to be measured, or traffic may be tunneled and 115 not be accessible to marking. Furthermore active measurements permit 116 a precise control of the monitored traffic than passive measurements. 117 So in such cases, active measurements using synthetic test traffic 118 need to be considered. 120 This document specifies how to implement active measurement with the 121 same techniqe described in [I-D.ietf-ippm-alt-mark]. Instead of time 122 stamping test traffic, test traffic is marked and measurements occur 123 by analyzing resulting flow data. There are some key aspects of the 124 mechanism described in this document to be considered: 126 o Improve metric precision: the packet timestamp can be take in an 127 more efficient way because it is not inserted within the Test 128 packet. 130 o Reduce computational load: no sequence numbers and no timestamps 131 within the Test packets. 133 o Enable hybrid measurements thanks to the Alternate Marking. 135 2. Description of the method 137 In order to perform packet loss, delay and jitter measurements on a 138 traffic flow, different approaches exist. The method proposed 139 consists in counting and timestamping the packets sent from one end, 140 the packets received on the other end, and compare the two values. 141 Therefore the devices performing the measurement have to refer 142 exactly to the same set of packets. So the flow is virtually spit in 143 consecutive blocks by coloring the packets so that the packets 144 belonging to the same block will have the same color, whilst 145 consecutive blocks will have different colors. Each change of color 146 represents a sort of auto-synchronization signal that guarantees the 147 consistency of measurements taken by different devices along the 148 path. 150 This approach, called Alternate Marking method, is efficient both for 151 passive performance monitoring and for active performance monitoring. 152 In this document we describe the implementation for Active 153 Measurement. 155 +----------------+ +-------------------+ 156 | | | | 157 | Session-Sender | | Session-Reflector | 158 | |========================>| | 159 | |<========================| | 160 +----------------+ Traffic flow +-------------------+ 161 . . 162 . . 163 <-----------------------> 164 End-to-End Packet loss, Delay and Jitter 166 Figure 1: Available measurements 168 Previous Figure represents two end points (Session-Sender and 169 Session-Reflector) that exchange two equal data flows in both 170 direction. The data flows start and end together. Packets are 171 colored and the color changes every marking interval. The method can 172 be used to measure packet loss, delay and jitter. 174 2.1. Packet loss measurement 176 The basic idea is to virtually split traffic flows into consecutive 177 blocks: each block represents a measurable entity unambiguously 178 recognizable by all network devices along the path. By counting the 179 number of packets in each block and comparing the values measured by 180 Sender and Reflector, it is possible to measure packet loss occurred 181 in any single block between the two end points. 183 A simple way to create the blocks is to "color" the traffic (two 184 colors are sufficient) so that packets belonging to different 185 consecutive blocks will have different colors. Whenever the color 186 changes, the previous block terminates and the new one begins. The 187 number of packets in each block depends on the criterion used to 188 create the blocks: if the color is switched after a fixed number of 189 packets, then each block will contain the same number of packets 190 (except for any losses); but if the color is switched according to a 191 fixed timer, then the number of packets may be different in each 192 block depending on the packet rate. 194 2.2. Delay measurement 196 The same principle used to measure packet loss can be applied also to 197 one-way delay measurement. There are two alternatives, shown below: 199 o Delay for each packet: For active measurement two alternate 200 marking data flows are generated in both direction, so the 201 alternation of colors can be used as a time reference to calculate 202 the delay. Whenever the color changes (that means that a new 203 block has started) an end point can store the timestamps of all 204 packets of the new block. The timestamps can be compared with the 205 timestamps of the same packets on the other end point to compute 206 packet delay. This method for measuring the delay is sensitive to 207 out of order reception of packets. In order to overcome this 208 problem between packets there should be a security time gap to 209 avoid out of order issues. If the packet rate exchanged between 210 the two end points is adequate each end points can store all the 211 timestamp of the block and the packet delay can be computed for 212 all the packets of the block, included minimum, maximum, mean and 213 median delay values. 215 o Mean delay: A different approach, based on the concept of mean 216 delay, can be take in account for active measurement. The mean 217 delay is calculated by considering the average arrival time of the 218 packets within a single block. The network device locally stores 219 a timestamp for each packet received within a single block: 220 summing all the timestamps and dividing by the total number of 221 packets received, the average arrival time for that block of 222 packets can be calculated. By subtracting the average arrival 223 times of the two end points it is possible to calculate the mean 224 delay. This method is robust to out of order packets and also to 225 packet loss (only a small error is introduced). Moreover, it 226 greatly reduces the number of timestamps (only one per block for 227 each end point) that have to be collected and transmitted for the 228 calculation. On the other hand, it only gives one measure for the 229 duration of the block, and it doesn't give the minimum, maximum 230 and median delay values. RFC 6703 [RFC6703] recommends to report 231 both median and mean delay in order to obtain additional 232 information about the distribution. But the same procedure of the 233 mean delay is not applicable to median delay because the median is 234 not a linear operator. So the mean delay could be considered as a 235 light measurement because the calculation is achieved by 236 exchanging only the average timestamp for each colored block 237 (without exchanging all the timestamps). For this reason the mean 238 delay is not the main technique, but a secondary option in case we 239 have to save computational resources. 241 By summing the one-way delay measurements of the two directions of a 242 path, it is also possible to measure the two-way delay (round-trip 243 delay). 245 In brief, there are three choices to compute delay for active 246 measurement: 248 o The two end points could store all packets timestamps in both 249 directions. At the end of the period all timestamps are 250 exchanged. In this way, delay is calculated for each packet. 252 o The two end points calculate only the average timestamp that is 253 exchanged at the end of the period. In this way only the mean 254 delay is calculated. 256 o The two end points sent packets with a specified and shared 257 traffic profile and each end point could make its own calculation 258 (data are not exchanged so it is not so accurate, but it depends 259 on hardware and software capabilities). 261 Note: How data and timestamps are exchanged is outside the scope of 262 this document. 264 2.3. Delay variation measurement 266 Similarly to one-way delay measurement, the method can also be used 267 to measure the inter-arrival jitter. The alternation of colors can 268 be used as a time reference to measure delay variations. The inter- 269 arrival jitter can be easily derived from one-way delay measurement, 270 by evaluating the delay variation of consecutive samples. 272 The concept of mean delay can also be applied to delay variation, by 273 evaluating the variation of average interval between consecutive 274 packets of the flow. 276 3. Hybrid measurement 278 In order to have both end to end measurements and intermediate 279 measurements (hybrid measurements) Sender and Reflector exchanges 280 traffic flows and apply alternate marking over these flows. In the 281 intermediate points artificial traffic is managed in the same way as 282 real traffic and measured as specified before. 284 4. Protocol Extension overview 286 The Alternate Marking extension to Active Measurement Protocol like 287 OWAMP or TWAMP, consists of three distinct phases, Control Phase, 288 Test Phase and Calculation Phase. 290 The Control Phase is the first phase of message exchanges and forms 291 the base protocol. This phase establishes the identity of the Sender 292 and provides information for the Test Phase. 294 The Test Phase forms the second phase and is comprised of an exchange 295 of two equal alternate marking data flows between Sender and 296 Reflector. Sender and Reflector generate test traffic and apply 297 marking, no traffic is reflected and no timestamping is added to 298 packets. 300 The Calculation Phase is introduced "ad hoc" for Alternate Marking 301 implementation because it does not exist in other Active Measurement 302 Protocol. After test execution there are some alternatives to 303 compute packet loss, delay and delay variation: 305 o Local assessment: Sender initiates a Calculation Request message 306 and Reflector sends back a Calculation Response message. Sender 307 and Reflector, upon receipt test traffic, create data structure 308 with timestamped records then computes service level metrics from 309 that data structure. Let's call this data structure the test 310 receipt. 312 o Central assessment: A "central" entity (e.g. a controller) 313 compares the test receipt collected by the Reflector with data 314 structure obtained from the Sender, then computes the service 315 levels by means of comparing. 317 o Local assessment with reference recording: Both sender and 318 receiver play out the same test traffic. Assessment is done 319 locally not by computing metrics over the test receipt, but by 320 "overlaying" the original with the one that was received and 321 computing the delta. 323 The number and frequency with which messages are sent SHOULD be 324 controlled by configuration on the Sender element, along with the 325 waiting time for a Control Response. 327 The following sequence diagram depicts the message exchanges: 329 +-+-+-+-+-+-+-+ Control Request +-+-+-+-+-+-+-+ 330 | | | | 331 | Sender | | Reflector | 332 | | | | 333 | | | | 334 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 335 | | 336 | Control Phase | 337 |<-------------------------------------------->| 338 | | 339 | | 340 | Test Phase | 341 |<============================================>| 342 | | 343 | | 344 | Calculation Phase | 345 |<-------------------------------------------->| 346 | | 348 To utilize existing Active Measurement Protocol, some extensions are 349 needed. The Sender indicates that alternate marking techniques are 350 to be used and that traffic is going to be marked. Likewise, it can 351 indicate to the Reflector to not simply reflect the marked traffic, 352 but to generate a separate stream of marked test traffic back to the 353 sender. The marking pattern will be conveyed (including the markings 354 to be used and duration of the marking intervals). The 355 implementation of measurements involves analyzing the marked traffic 356 as needed. Conveying of results of the analysis of observed traffic 357 occurs through separate means, not specified here. 359 4.1. Control Phase 361 The Control Phase consists of agreement between Sender and Reflector. 362 Only an extension to the exixting procols is needed. Please refer to 363 the guidelines defined in Section 3 of OWAMP RFC 4656 [RFC4656] TWAMP 364 RFC 5357 [RFC5357] or RFC 6812 [RFC6812]. 366 4.2. Test Phase 368 Upon successing the Control Phase, the second phase of the protocol, 369 the Test Phase, is initiated. In the Test Phase the Sender sends a 370 stream of measurement messages. The measurement message stream 371 consists of packets/frames that are spaced a configured number of 372 milliseconds. 374 The Measurement messages is simplified in comparison to OWAMP RFC 375 4656 [RFC4656] TWAMP RFC 5357 [RFC5357] or RFC 6812 [RFC6812]. In 376 particular the fields that can be removed are: Sender Timestamp, 377 Receive Timestamp, Sequence Number. 379 The format of the Measurement messages is the same for the exchange 380 in both directions, that is when sent from the Sender to the 381 Reflector and from the Reflector to the Sender. 383 Note: Marking field can be chosen in two ways for OWAMP RFC 4656 384 [RFC4656] and TWAMP RFC 5357 [RFC5357]: marking Packet Padding or MBZ 385 fields. 387 Note: Marking field can be chosen for RFC 6812 [RFC6812] in two ways: 388 marking UDP payload or marking IPv4 header. 390 Note: No timestamp, No sequence number. The two data flows are 391 indipendent. 393 4.3. Calculation Phase 395 As mentioned above, the Calculation Phase is introduced "ad hoc" for 396 Alternate Marking implementation because it does not exist in OWAMP 397 RFC 4656 [RFC4656] TWAMP RFC 5357 [RFC5357] or RFC 6812 [RFC6812]. 398 After test execution there are some alternatives to compute packet 399 loss, delay and delay variation: 401 o Local assessment: Sender initiates a Calculation Request message 402 and Reflector sends back a Calculation Response message. Sender 403 and Reflector, upon receipt test traffic, create data structure 404 with timestamped records then computes service level metrics from 405 that data structure. Let's call this data structure the test 406 receipt). 408 o Central assessment: A "central" entity (e.g. a controller) 409 compares the test receipt collected by the Reflector with data 410 structure obtained from the Sender, then computes the service 411 levels by means of comparing. 413 o Local assessment with reference recording: Both sender and 414 receiver play out the same test traffic. Assessment is done 415 locally not by computing metrics over the test receipt, but by 416 "overlaying" the original with the one that was received and 417 computing the delta. 419 5. Open Issues 420 5.1. Extension of TWAMP/OWAMP Control Protocol 422 to be added 424 5.2. Extension of TWAMP/OWAMP Test Protocol 426 to be added 428 6. RFC6374 Use Case 430 RFC6374 [RFC6374] uses the LM packet as the packet accounting 431 demarcation point. Unfortunately this gives rise to a number of 432 problems that may lead to significant packet accounting errors in 433 certain situations. [I-D.ietf-mpls-flow-ident] discusses the desired 434 capabilities for MPLS flow identification in order to perform a 435 better in-band performance monitoring of user data packets. A method 436 of accomplishing identification is Synonymous Flow Labels (SFL) 437 introduced in [I-D.bryant-mpls-sfl-framework]. 439 [I-D.bryant-mpls-rfc6374-sfl] describes RFC6374 packet loss 440 measurement with SFL and is based on alternate marking methodology 441 for passive performance monitoring as described in the companion 442 document [I-D.ietf-ippm-alt-mark]. 444 [I-D.bryant-mpls-rfc6374-sfl] describes also a valuable use case 445 about the application of alternate marking on existing Active 446 Measurement Protocol. RFC6374 [RFC6374] describes how to measure the 447 packet delay by measuring the transit time of an RFC6374 packet over 448 an LSP. The main motivation to use Marking method is that if label 449 inferred scheduling is used [RFC3270] then the SFL would be REQUIRED 450 to ensure that the RFC6374 packet, which was being used as a proxy 451 for a data service packet, experienced a representative delay. 453 7. IANA Considerations 455 IANA Considerations to be added. 457 8. Security Considerations 459 Security Considerations to be added. 461 9. Acknowledgements 463 Mauro Cociglio and Giuseppe Fioccola worked in part on the Leone 464 research project, which received funding from the European Union 465 Seventh Framework Programme [FP7/2007-2013] under grant agreement 466 number 317647. 468 10. References 470 10.1. Normative References 472 [I-D.bryant-mpls-rfc6374-sfl] 473 Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., 474 Mirsky, G., and G. Fioccola, "RFC6374 Synonymous Flow 475 Labels", draft-bryant-mpls-rfc6374-sfl-03 (work in 476 progress), October 2016. 478 [I-D.bryant-mpls-sfl-framework] 479 Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., 480 and G. Mirsky, "Synonymous Flow Label Framework", draft- 481 bryant-mpls-sfl-framework-03 (work in progress), March 482 2017. 484 [I-D.fioccola-ippm-rfc6812-alt-mark-ext] 485 Fioccola, G., Clemm, A., Cociglio, M., Chandramouli, M., 486 and A. Capello, "Alternate Marking Extension to Cisco SLA 487 Protocol RFC6812", draft-fioccola-ippm-rfc6812-alt-mark- 488 ext-01 (work in progress), March 2016. 490 [I-D.ietf-ippm-alt-mark] 491 Fioccola, G., Capello, A., Cociglio, M., Castaldelli, L., 492 Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 493 "Alternate Marking method for passive performance 494 monitoring", draft-ietf-ippm-alt-mark-04 (work in 495 progress), March 2017. 497 [I-D.ietf-mpls-flow-ident] 498 Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. 499 Mirsky, "MPLS Flow Identification Considerations", draft- 500 ietf-mpls-flow-ident-04 (work in progress), February 2017. 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, 504 DOI 10.17487/RFC2119, March 1997, 505 . 507 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 508 Zekauskas, "A One-way Active Measurement Protocol 509 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 510 . 512 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 513 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 514 RFC 5357, DOI 10.17487/RFC5357, October 2008, 515 . 517 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 518 Measurement for MPLS Networks", RFC 6374, 519 DOI 10.17487/RFC6374, September 2011, 520 . 522 [RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, 523 S., and E. Yedavalli, "Cisco Service-Level Assurance 524 Protocol", RFC 6812, DOI 10.17487/RFC6812, January 2013, 525 . 527 10.2. Informative References 529 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 530 IP Network Performance Metrics: Different Points of View", 531 RFC 6703, DOI 10.17487/RFC6703, August 2012, 532 . 534 Authors' Addresses 536 Giuseppe Fioccola 537 Telecom Italia 538 Via Reiss Romoli, 274 539 Torino 10148 540 Italy 542 Email: giuseppe.fioccola@telecomitalia.it 544 Alexander Clemm 545 Huawei 546 USA 548 Email: alexander.clemm@huawei.com 550 Stewart Bryant 551 Huawei 553 Email: stewart.bryant@gmail.com 555 Mauro Cociglio 556 Telecom Italia 557 Via Reiss Romoli, 274 558 Torino 10148 559 Italy 561 Email: mauro.cociglio@telecomitalia.it 562 Mouli Chandramouli 563 Cisco Systems 565 Email: moulchan@cisco.com 567 Alessandro Capello 568 Telecom Italia 569 Via Reiss Romoli, 274 570 Torino 10148 571 Italy 573 Email: alessandro.capello@telecomitalia.it