idnits 2.17.1 draft-fioccola-ippm-alt-mark-active-00.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], [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 (July 7, 2016) is 2842 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-00 Summary: 1 error (**), 0 flaws (~~), 2 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: January 8, 2017 Cisco Systems 6 M. Cociglio 7 Telecom Italia 8 M. Chandramouli 9 Cisco Systems 10 A. Capello 11 Telecom Italia 12 July 7, 2016 14 Alternate Marking Extension to Active Measurement Protocol 15 draft-fioccola-ippm-alt-mark-active-00 17 Abstract 19 This document describes how to extend the existing Active Measurement 20 Protocol, in order to implement alternate marking methodology 21 detailed in [I-D.ietf-ippm-alt-mark]. The extension for Two-Way 22 Active Measurement Protocol (TWAMP) RFC 5357 [RFC5357] and One-way 23 Active Measurement Protocol (OWAMP) RFC 4656 [RFC4656] will be 24 considered. This proposal defines a simplified mechanism with 25 benefits to the metric precision and computational load. Hybrid 26 measurements are also enabled. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 8, 2017. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Description of the method . . . . . . . . . . . . . . . . . . 3 69 2.1. Packet loss measurement . . . . . . . . . . . . . . . . . 4 70 2.2. Delay measurement . . . . . . . . . . . . . . . . . . . . 5 71 2.3. Delay variation measurement . . . . . . . . . . . . . . . 6 72 3. Hybrid measurement . . . . . . . . . . . . . . . . . . . . . 6 73 4. Protocol Extension overview . . . . . . . . . . . . . . . . . 6 74 4.1. Control Phase . . . . . . . . . . . . . . . . . . . . . . 8 75 4.2. Test Phase . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.3. Calculation Phase . . . . . . . . . . . . . . . . . . . . 9 77 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 5.1. Extension of TWAMP/OWAMP Control Protocol . . . . . . . . 10 79 5.2. Extension of TWAMP/OWAMP Test Protocol . . . . . . . . . 10 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 85 9.2. Informative References . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Introduction 90 The Two-Way Active Measurement Protocol (TWAMP), specified in RFC 91 5357 [RFC5357] adds two-way or round-trip measurement capabilities to 92 the One-way Active Measurement Protocol (OWAMP) specified in RFC 4656 93 [RFC4656]. OWAMP can be used bi-directionally to measure one-way 94 metrics in both directions between two network elements. The TWAMP 95 measurement architecture is usually comprised of two hosts with 96 specific roles, and this allows for some protocol simplifications, 97 making it an attractive alternative in some circumstances. Another 98 example is Cisco's Service-Level Assurance Protocol (Cisco's SLA 99 Protocol) RFC 6812 [RFC6812], a Performance Measurement protocol that 100 has been widely deployed. Details are explained in 101 [I-D.fioccola-ippm-rfc6812-alt-mark-ext]. 103 One technique for passive performance measurements is described in 104 [I-D.ietf-ippm-alt-mark]. This technique involves marking production 105 flows as they traverse the network, then analyzing flow data 106 associated with those marked flows. Passive measurements are very 107 accurate in that they measure actual production traffic. However, 108 there are scenarios in which passive measurements are not an option. 109 For example, there may be no suitable flows currently occurring 110 between pairs of nodes to be measured, or traffic may be tunneled and 111 not be accessible to marking. Furthermore active measurements permit 112 a precise control of the monitored traffic than passive measurements. 113 So in such cases, active measurements using synthetic test traffic 114 need to be considered. 116 This document specifies how to implement active measurement with the 117 same techniqe described in [I-D.ietf-ippm-alt-mark]. Instead of time 118 stamping test traffic, test traffic is marked and measurements occur 119 by analyzing resulting flow data. There are some key aspects of the 120 mechanism described in this document to be considered: 122 o Improve metric precision: the packet timestamp can be take in an 123 more efficient way because it is not inserted within the Test 124 packet. 126 o Reduce computational load: no sequence numbers and no timestamps 127 within the Test packets. 129 o Enable hybrid measurements thanks to the Alternate Marking. 131 2. Description of the method 133 In order to perform packet loss, delay and jitter measurements on a 134 traffic flow, different approaches exist. The method proposed 135 consists in counting and timestamping the packets sent from one end, 136 the packets received on the other end, and compare the two values. 137 Therefore the devices performing the measurement have to refer 138 exactly to the same set of packets. So the flow is virtually spit in 139 consecutive blocks by coloring the packets so that the packets 140 belonging to the same block will have the same color, whilst 141 consecutive blocks will have different colors. Each change of color 142 represents a sort of auto-synchronization signal that guarantees the 143 consistency of measurements taken by different devices along the 144 path. 146 This approach, called Alternate Marking method, is efficient both for 147 passive performance monitoring and for active performance monitoring. 148 In this document we describe the implementation for Active 149 Measurement. 151 +----------------+ +-------------------+ 152 | | | | 153 | Session-Sender | | Session-Reflector | 154 | |========================>| | 155 | |<========================| | 156 +----------------+ Traffic flow +-------------------+ 157 . . 158 . . 159 <-----------------------> 160 End-to-End Packet loss, Delay and Jitter 162 Figure 1: Available measurements 164 Previous Figure represents two end points (Session-Sender and 165 Session-Reflector) that exchange two equal data flows in both 166 direction. The data flows start and end together. Packets are 167 colored and the color changes every marking interval. The method can 168 be used to measure packet loss, delay and jitter. 170 2.1. Packet loss measurement 172 The basic idea is to virtually split traffic flows into consecutive 173 blocks: each block represents a measurable entity unambiguously 174 recognizable by all network devices along the path. By counting the 175 number of packets in each block and comparing the values measured by 176 Sender and Reflector, it is possible to measure packet loss occurred 177 in any single block between the two end points. 179 A simple way to create the blocks is to "color" the traffic (two 180 colors are sufficient) so that packets belonging to different 181 consecutive blocks will have different colors. Whenever the color 182 changes, the previous block terminates and the new one begins. The 183 number of packets in each block depends on the criterion used to 184 create the blocks: if the color is switched after a fixed number of 185 packets, then each block will contain the same number of packets 186 (except for any losses); but if the color is switched according to a 187 fixed timer, then the number of packets may be different in each 188 block depending on the packet rate. 190 2.2. Delay measurement 192 The same principle used to measure packet loss can be applied also to 193 one-way delay measurement. There are two alternatives, shown below: 195 o Delay for each packet: For active measurement two alternate 196 marking data flows are generated in both direction, so the 197 alternation of colors can be used as a time reference to calculate 198 the delay. Whenever the color changes (that means that a new 199 block has started) an end point can store the timestamps of all 200 packets of the new block. The timestamps can be compared with the 201 timestamps of the same packets on the other end point to compute 202 packet delay. This method for measuring the delay is sensitive to 203 out of order reception of packets. In order to overcome this 204 problem between packets there should be a security time gap to 205 avoid out of order issues. If the packet rate exchanged between 206 the two end points is adequate each end points can store all the 207 timestamp of the block and the packet delay can be computed for 208 all the packets of the block, included minimum, maximum, average 209 and median delay values. 211 o Average delay: A different approach, based on the concept of 212 average delay, can be take in account for active measurement. The 213 average delay is calculated by considering the average arrival 214 time of the packets within a single block. The network device 215 locally stores a timestamp for each packet received within a 216 single block: summing all the timestamps and dividing by the total 217 number of packets received, the average arrival time for that 218 block of packets can be calculated. By subtracting the average 219 arrival times of the two end points it is possible to calculate 220 the average delay. This method is robust to out of order packets 221 and also to packet loss (only a small error is introduced). 222 Moreover, it greatly reduces the number of timestamps (only one 223 per block for each end point) that have to be collected and 224 transmitted for the calculation. On the other hand, it only gives 225 one measure for the duration of the block, and it doesn't give the 226 minimum, maximum and median delay values. RFC 6703 [RFC6703] 227 recommends to report both median and average delay in order to 228 obtain additional information about the distribution. But the 229 same procedure of the average delay is not applicable to median 230 delay because the median is not a linear operator. So the average 231 delay could be considered as a light measurement because the 232 calculation is achieved by exchanging only the average timestamp 233 for each colored block (without exchanging all the timestamps). 234 For this reason the average delay is not the main technique, but a 235 secondary option in case we have to save computational resources. 237 By summing the one-way delay measurements of the two directions of a 238 path, it is also possible to measure the two-way delay (round-trip 239 delay). 241 In brief, there are three choices to compute delay for active 242 measurement: 244 o The two end points could store all packets timestamps in both 245 directions. At the end of the period all timestamps are 246 exchanged. In this way, delay is calculated for each packet. 248 o The two end points calculate only the average timestamp that is 249 exchanged at the end of the period. In this way only the average 250 delay is calculated. 252 o The two end points sent packets with a specified and shared 253 traffic profile and each end point could make its own calculation 254 (data are not exchanged so it is not so accurate, but it depends 255 on hardware and software capabilities). 257 Note: How data and timestamps are exchanged is outside the scope of 258 this document. 260 2.3. Delay variation measurement 262 Similarly to one-way delay measurement, the method can also be used 263 to measure the inter-arrival jitter. The alternation of colors can 264 be used as a time reference to measure delay variations. The inter- 265 arrival jitter can be easily derived from one-way delay measurement, 266 by evaluating the delay variation of consecutive samples. 268 The concept of average delay can also be applied to delay variation, 269 by evaluating the variation of average interval between consecutive 270 packets of the flow. 272 3. Hybrid measurement 274 In order to have both end to end measurements and intermediate 275 measurements (hybrid measurements) Sender and Reflector exchanges 276 traffic flows and apply alternate marking over these flows. In the 277 intermediate points artificial traffic is managed in the same way as 278 real traffic and measured as specified before. 280 4. Protocol Extension overview 282 The Alternate Marking extension to Active Measurement Protocol like 283 OWAMP or TWAMP, consists of three distinct phases, Control Phase, 284 Test Phase and Calculation Phase. 286 The Control Phase is the first phase of message exchanges and forms 287 the base protocol. This phase establishes the identity of the Sender 288 and provides information for the Test Phase. 290 The Test Phase forms the second phase and is comprised of an exchange 291 of two equal alternate marking data flows between Sender and 292 Reflector. Sender and Reflector generate test traffic and apply 293 marking, no traffic is reflected and no timestamping is added to 294 packets. 296 The Calculation Phase is introduced "ad hoc" for Alternate Marking 297 implementation because it does not exist in other Active Measurement 298 Protocol. After test execution there are some alternatives to 299 compute packet loss, delay and delay variation: 301 o Local assessment: Sender initiates a Calculation Request message 302 and Reflector sends back a Calculation Response message. Sender 303 and Reflector, upon receipt test traffic, create data structure 304 with timestamped records then computes service level metrics from 305 that data structure. Let's call this data structure the test 306 receipt. 308 o Central assessment: A "central" entity (e.g. a controller) 309 compares the test receipt collected by the Reflector with data 310 structure obtained from the Sender, then computes the service 311 levels by means of comparing. 313 o Local assessment with reference recording: Both sender and 314 receiver play out the same test traffic. Assessment is done 315 locally not by computing metrics over the test receipt, but by 316 "overlaying" the original with the one that was received and 317 computing the delta. 319 The number and frequency with which messages are sent SHOULD be 320 controlled by configuration on the Sender element, along with the 321 waiting time for a Control Response. 323 The following sequence diagram depicts the message exchanges: 325 +-+-+-+-+-+-+-+ Control Request +-+-+-+-+-+-+-+ 326 | | | | 327 | Sender | | Reflector | 328 | | | | 329 | | | | 330 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 331 | | 332 | Control Phase | 333 |<-------------------------------------------->| 334 | | 335 | | 336 | Test Phase | 337 |<============================================>| 338 | | 339 | | 340 | Calculation Phase | 341 |<-------------------------------------------->| 342 | | 344 To utilize existing Active Measurement Protocol, some extensions are 345 needed. The Sender indicates that alternate marking techniques are 346 to be used and that traffic is going to be marked. Likewise, it can 347 indicate to the Reflector to not simply reflect the marked traffic, 348 but to generate a separate stream of marked test traffic back to the 349 sender. The marking pattern will be conveyed (including the markings 350 to be used and duration of the marking intervals). The 351 implementation of measurements involves analyzing the marked traffic 352 as needed. Conveying of results of the analysis of observed traffic 353 occurs through separate means, not specified here. 355 4.1. Control Phase 357 The Control Phase consists of agreement between Sender and Reflector. 358 Only an extension to the exixting procols is needed. Please refer to 359 the guidelines defined in Section 3 of OWAMP RFC 4656 [RFC4656] TWAMP 360 RFC 5357 [RFC5357] or RFC 6812 [RFC6812]. 362 4.2. Test Phase 364 Upon successing the Control Phase, the second phase of the protocol, 365 the Test Phase, is initiated. In the Test Phase the Sender sends a 366 stream of measurement messages. The measurement message stream 367 consists of packets/frames that are spaced a configured number of 368 milliseconds. 370 The Measurement messages is simplified in comparison to OWAMP RFC 371 4656 [RFC4656] TWAMP RFC 5357 [RFC5357] or RFC 6812 [RFC6812]. In 372 particular the fields that can be removed are: Sender Timestamp, 373 Receive Timestamp, Sequence Number. 375 The format of the Measurement messages is the same for the exchange 376 in both directions, that is when sent from the Sender to the 377 Reflector and from the Reflector to the Sender. 379 Note: Marking field can be chosen in two ways for OWAMP RFC 4656 380 [RFC4656] and TWAMP RFC 5357 [RFC5357]: marking Packet Padding or MBZ 381 fields. 383 Note: Marking field can be chosen for RFC 6812 [RFC6812] in two ways: 384 marking UDP payload or marking IPv4 header. 386 Note: No timestamp, No sequence number. The two data flows are 387 indipendent. 389 4.3. Calculation Phase 391 As mentioned above, the Calculation Phase is introduced "ad hoc" for 392 Alternate Marking implementation because it does not exist in OWAMP 393 RFC 4656 [RFC4656] TWAMP RFC 5357 [RFC5357] or RFC 6812 [RFC6812]. 394 After test execution there are some alternatives to compute packet 395 loss, delay and delay variation: 397 o Local assessment: Sender initiates a Calculation Request message 398 and Reflector sends back a Calculation Response message. Sender 399 and Reflector, upon receipt test traffic, create data structure 400 with timestamped records then computes service level metrics from 401 that data structure. Let's call this data structure the test 402 receipt). 404 o Central assessment: A "central" entity (e.g. a controller) 405 compares the test receipt collected by the Reflector with data 406 structure obtained from the Sender, then computes the service 407 levels by means of comparing. 409 o Local assessment with reference recording: Both sender and 410 receiver play out the same test traffic. Assessment is done 411 locally not by computing metrics over the test receipt, but by 412 "overlaying" the original with the one that was received and 413 computing the delta. 415 5. Open Issues 416 5.1. Extension of TWAMP/OWAMP Control Protocol 418 to be added 420 5.2. Extension of TWAMP/OWAMP Test Protocol 422 to be added 424 6. IANA Considerations 426 IANA Considerations to be added. 428 7. Security Considerations 430 Security Considerations to be added. 432 8. Acknowledgements 434 Mauro Cociglio and Giuseppe Fioccola worked in part on the Leone 435 research project, which received funding from the European Union 436 Seventh Framework Programme [FP7/2007-2013] under grant agreement 437 number 317647. 439 9. References 441 9.1. Normative References 443 [I-D.fioccola-ippm-rfc6812-alt-mark-ext] 444 Fioccola, G., Clemm, A., Cociglio, M., Chandramouli, M., 445 and A. Capello, "Alternate Marking Extension to Cisco SLA 446 Protocol RFC6812", draft-fioccola-ippm-rfc6812-alt-mark- 447 ext-01 (work in progress), March 2016. 449 [I-D.ietf-ippm-alt-mark] 450 Capello, A., Cociglio, M., Fioccola, G., Castaldelli, L., 451 and A. Bonda, "Alternate Marking method for passive 452 performance monitoring", draft-ietf-ippm-alt-mark-00 (work 453 in progress), June 2016. 455 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 456 Requirement Levels", BCP 14, RFC 2119, 457 DOI 10.17487/RFC2119, March 1997, 458 . 460 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 461 Zekauskas, "A One-way Active Measurement Protocol 462 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 463 . 465 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 466 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 467 RFC 5357, DOI 10.17487/RFC5357, October 2008, 468 . 470 [RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, 471 S., and E. Yedavalli, "Cisco Service-Level Assurance 472 Protocol", RFC 6812, DOI 10.17487/RFC6812, January 2013, 473 . 475 9.2. Informative References 477 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 478 IP Network Performance Metrics: Different Points of View", 479 RFC 6703, DOI 10.17487/RFC6703, August 2012, 480 . 482 Authors' Addresses 484 Giuseppe Fioccola 485 Telecom Italia 486 Via Reiss Romoli, 274 487 Torino 10148 488 Italy 490 Email: giuseppe.fioccola@telecomitalia.it 492 Alexander Clemm 493 Cisco Systems 494 170 West Tasman Drive 495 San Jose 95134 496 USA 498 Phone: 1-408-526-4000 499 Email: alex@cisco.com 501 Mauro Cociglio 502 Telecom Italia 503 Via Reiss Romoli, 274 504 Torino 10148 505 Italy 507 Email: mauro.cociglio@telecomitalia.it 508 Mouli Chandramouli 509 Cisco Systems 511 Email: moulchan@cisco.com 513 Alessandro Capello 514 Telecom Italia 515 Via Reiss Romoli, 274 516 Torino 10148 517 Italy 519 Email: alessandro.capello@telecomitalia.it