idnits 2.17.1 draft-fioccola-ippm-rfc6812-alt-mark-ext-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 ([RFC6812], [I-D.tempia-ippm-p3m]), 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 21, 2016) is 2955 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3579' is defined on line 736, but no explicit reference was found in the text == Unused Reference: 'RFC4868' is defined on line 747, but no explicit reference was found in the text == Unused Reference: 'RFC5357' is defined on line 752, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-tempia-ippm-p3m-02 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 G. Fioccola 3 Internet-Draft Telecom Italia 4 Intended status: Informational A. Clemm 5 Expires: September 22, 2016 Cisco Systems 6 M. Cociglio 7 Telecom Italia 8 M. Chandramouli 9 Cisco Systems 10 A. Capello 11 Telecom Italia 12 March 21, 2016 14 Alternate Marking Extension to Cisco SLA Protocol RFC6812 15 draft-fioccola-ippm-rfc6812-alt-mark-ext-01 17 Abstract 19 Cisco's Service-Level Assurance Protocol (Cisco's SLA Protocol) RFC 20 6812 [RFC6812] is a Performance Measurement protocol that has been 21 widely deployed. The protocol is used to measure service-level 22 parameters such as network latency, delay variation, and packet/frame 23 loss. This document describes an extension to the Cisco SLA Protocol 24 Measurement-Type UDP-Measurement, in order to implement alternate 25 marking methodology detailed in [I-D.tempia-ippm-p3m]. The extension 26 is used to measure service level parameters by marking test traffic. 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 September 22, 2016. 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 . . . . . . . . . . . . . . . . . . . . 4 71 2.3. Delay variation measurement . . . . . . . . . . . . . . . 6 72 3. Hybrid measurement . . . . . . . . . . . . . . . . . . . . . 6 73 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.1. Control Phase . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1.1. Control Request . . . . . . . . . . . . . . . . . . . 9 76 4.1.1.1. Command Header . . . . . . . . . . . . . . . . . 9 77 4.1.1.2. CSLDs . . . . . . . . . . . . . . . . . . . . . . 9 78 4.1.2. Control Response Message . . . . . . . . . . . . . . 13 79 4.2. Measurement Phase . . . . . . . . . . . . . . . . . . . . 13 80 4.3. Calculation Phase . . . . . . . . . . . . . . . . . . . . 15 81 5. Implementation notes . . . . . . . . . . . . . . . . . . . . 15 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 84 8. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 88 10.2. Informative References . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 93 Cisco SLA Protocol involves a system sending synthetic test traffic, 94 which is reflected by a responder back to the sender. In the course, 95 both sender and responder add a set of time stamps to the packet. 97 The packet is first time stamped when it is sent. A second time 98 stamp is added by responder when it is received, and third time stamp 99 when packet is sent back. A fourth time stamp is added when the 100 sender receives the reflected packet. Based on time stamps and other 101 information, the sender computes performance metrics such as loss, 102 delay, and jitter. 104 One technique for passive performance measurements is described in 105 [I-D.tempia-ippm-p3m]. This technique involves marking production 106 flows as they traverse the network, then analyzing flow data 107 associated with those marked flows. Passive measurements are very 108 accurate in that they measure actual production traffic. However, 109 there are scenarios in which passive measurements are not an option. 110 For example, there may be no suitable flows currently occurring 111 between pairs of nodes to be measured, or traffic may be tunneled and 112 not be accessible to marking. In such cases, active measurements 113 using synthetic test traffic need to be considered. 115 This document specifies an extension to Cisco SLA Protocol which 116 allows to use Cisco SLA Protocol to generate synthetic traffic, but 117 allows subjecting test traffic to the same techniqe described in 118 [I-D.tempia-ippm-p3m]. Instead of time stamping test traffic, test 119 traffic is marked and measurements occur by analyzing resulting flow 120 data. 122 2. Description of the method 124 In order to perform packet loss, delay and jitter measurements on a 125 traffic flow, different approaches exist. The method proposed 126 consists in counting and timestamping the packets sent from one end, 127 the packets received on the other end, and compare the two values. 128 Therefore the devices performing the measurement have to refer 129 exactly to the same set of packets. So the flow is virtually spit in 130 consecutive blocks by coloring the packets so that the packets 131 belonging to the same block will have the same color, whilst 132 consecutive blocks will have different colors. Each change of color 133 represents a sort of auto-synchronization signal that guarantees the 134 consistency of measurements taken by different devices along the 135 path. 137 This approach, called Alternate Marking method, is efficient both for 138 passive performance monitoring and for active performance monitoring. 139 In this document we describe the implementation for Active 140 Measurement. 142 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 143 | | | | 144 | Sender | | Responder | 145 | |===============================>| | 146 | |<===============================| | 147 +-+-+-+-+-+-+-+ Traffic flow +-+-+-+-+-+-+-+ 148 . . 149 . . 150 <------------------------------> 151 End-to-End Packet loss, Delay and Jitter 153 Figure 1: Available measurements 155 Previous Figure represents two end points (Sender and Responder) that 156 exchange two equal data flows in both direction. The data flows 157 start and end together. Packets are colored and the color changes 158 every marking interval. The method can be used to measure packet 159 loss, delay and jitter. 161 2.1. Packet loss measurement 163 The basic idea is to virtually split traffic flows into consecutive 164 blocks: each block represents a measurable entity unambiguously 165 recognizable by all network devices along the path. By counting the 166 number of packets in each block and comparing the values measured by 167 Sender and Responder, it is possible to measure packet loss occurred 168 in any single block between the two end points. 170 A simple way to create the blocks is to "color" the traffic (two 171 colors are sufficient) so that packets belonging to different 172 consecutive blocks will have different colors. Whenever the color 173 changes, the previous block terminates and the new one begins. The 174 number of packets in each block depends on the criterion used to 175 create the blocks: if the color is switched after a fixed number of 176 packets, then each block will contain the same number of packets 177 (except for any losses); but if the color is switched according to a 178 fixed timer, then the number of packets may be different in each 179 block depending on the packet rate. 181 2.2. Delay measurement 183 The same principle used to measure packet loss can be applied also to 184 one-way delay measurement. There are two alternatives, shown below: 186 o Delay for each packet: For active measurement two alternate 187 marking data flows are generated in both direction, so the 188 alternation of colors can be used as a time reference to calculate 189 the delay. Whenever the color changes (that means that a new 190 block has started) an end point can store the timestamps of all 191 packets of the new block. The timestamps can be compared with the 192 timestamps of the same packets on the other end point to compute 193 packet delay. This method for measuring the delay is sensitive to 194 out of order reception of packets. In order to overcome this 195 problem between packets there should be a security time gap to 196 avoid out of order issues. If the packet rate exchanged between 197 the two end points is adequate each end points can store all the 198 timestamp of the block and the packet delay can be computed for 199 all the packets of the block, included minimum, maximum, average 200 and median delay values. 202 o Average delay: A different approach, based on the concept of 203 average delay, can be take in account for active measurement. The 204 average delay is calculated by considering the average arrival 205 time of the packets within a single block. The network device 206 locally stores a timestamp for each packet received within a 207 single block: summing all the timestamps and dividing by the total 208 number of packets received, the average arrival time for that 209 block of packets can be calculated. By subtracting the average 210 arrival times of the two end points it is possible to calculate 211 the average delay. This method is robust to out of order packets 212 and also to packet loss (only a small error is introduced). 213 Moreover, it greatly reduces the number of timestamps (only one 214 per block for each end point) that have to be collected and 215 transmitted for the calculation. On the other hand, it only gives 216 one measure for the duration of the block, and it doesn't give the 217 minimum, maximum and median delay values. RFC 6703 [RFC6703] 218 recommends to report both median and average delay in order to 219 obtain additional information about the distribution. But the 220 same procedure of the average delay is not applicable to median 221 delay because the median is not a linear operator. So the average 222 delay could be considered as a light measurement because the 223 calculation is achieved by exchanging only the average timestamp 224 for each colored block (without exchanging all the timestamps). 225 For this reason the average delay is not the main technique, but a 226 secondary option in case we have to save computational resources. 228 By summing the one-way delay measurements of the two directions of a 229 path, it is also possible to measure the two-way delay (round-trip 230 delay). 232 In brief, there are three choices to compute delay for active 233 measurement: 235 o The two end points could store all packets timestamps in both 236 directions. At the end of the period all timestamps are 237 exchanged. In this way, delay is calculated for each packet. 239 o The two end points calculate only the average timestamp that is 240 exchanged at the end of the period. In this way only the average 241 delay is calculated. 243 o The two end points sent packets with a specified and shared 244 traffic profile and each end point could make its own calculation 245 (data are not exchanged so it is not so accurate, but it depends 246 on hardware and software capabilities). 248 Note: How data and timestamps are exchanged is outside the scope of 249 this document. 251 2.3. Delay variation measurement 253 Similarly to one-way delay measurement, the method can also be used 254 to measure the inter-arrival jitter. The alternation of colors can 255 be used as a time reference to measure delay variations. The inter- 256 arrival jitter can be easily derived from one-way delay measurement, 257 by evaluating the delay variation of consecutive samples. 259 The concept of average delay can also be applied to delay variation, 260 by evaluating the variation of average interval between consecutive 261 packets of the flow. 263 3. Hybrid measurement 265 In order to have both end to end measurements and intermediate 266 measurements (hybrid measurements) Sender and Responder exchanges 267 traffic flows and apply alternate marking over these flows. In the 268 intermediate points artificial traffic is managed in the same way as 269 real traffic and measured as specified before. 271 4. Protocol 273 The Alternate Marking extension to Cisco Service Level Assurance 274 Protocol consists of three distinct phases, Control Phase, 275 Measurement Phase and Calculation Phase. 277 The Control Phase is the first phase of message exchanges and forms 278 the base protocol. This phase establishes the identity of the Sender 279 and provides information for the Measurement Phase. A single message 280 pair of Control Request and Control Response marks this phase. The 281 Sender initiates a Control Request message that is acknowledged by 282 the Responder with a Control Response message. The Control Request 283 may be sent multiple times if a Control Response has not been 284 received; the number of times the message is retried is configurable 285 on the Sender element. 287 The Measurement Phase forms the second phase and is comprised of an 288 exchange of two equal alternate marking data flows between Sender and 289 Responder. Sender and Responder generate test traffic and apply 290 marking, not traffic is reflected and no timestamping is added to 291 packets. 293 The Calculation Phase is introduced "ad hoc" for Alternate Marking 294 implementation because it does not exist in Cisco Service Level 295 Assurance Protocol described in RFC 6812 [RFC6812]. After test 296 execution there are some alternatives to compute packet loss, delay 297 and delay variation: 299 o Local assessment: Sender initiates a Calculation Request message 300 and Responder sends back a Calculation Response message. Sender 301 and Responder, upon receipt test traffic, create data structure 302 with timestamped records then computes service level metrics from 303 that data structure. Let's call this data structure the test 304 receipt. 306 o Central assessment: A "central" entity (e.g. a controller) 307 compares the test receipt collected by the Responder with data 308 structure obtained from the Sender, then computes the service 309 levels by means of comparing. 311 o Local assessment with reference recording: Both sender and 312 receiver play out the same test traffic. Assessment is done 313 locally not by computing metrics over the test receipt, but by 314 "overlaying" the original with the one that was received and 315 computing the delta. 317 The number and frequency with which messages are sent SHOULD be 318 controlled by configuration on the Sender element, along with the 319 waiting time for a Control Response. 321 The following sequence diagram depicts the message exchanges: 323 +-+-+-+-+-+-+-+ Control Request +-+-+-+-+-+-+-+ 324 | | | | 325 | Sender | | Responder | 326 | | | | 327 | | | | 328 +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ 329 | | 330 | Control Request | 331 | -------------------------------------------->| 332 | | 333 | Control Response | 334 |<---------------------------------------------| 335 | | 336 | | 337 | Measurement Phase | 338 |<============================================>| 339 | | 340 | | 341 | Calculation Phase | 342 |<-------------------------------------------->| 343 | | 345 To utilize Cisco SLA Protocol, some extensions are needed. As part 346 of the Control Request, the Sender needs to indicate that it will 347 send test traffic to be analyzed. However, it indicates that 348 alternate marking techniques are to be used and that traffic is going 349 to be marked. Likewise, it can indicate to the Responder to not 350 simply reflect the marked traffic, but to generate a separate stream 351 of marked test traffic back to the sender. The marking pattern will 352 be conveyed (including the alternate markings to be used and duration 353 of the marking intervals). The implementation of measurements 354 involves analyzing the marked traffic as needed. Conveying of 355 results of the analysis of observed traffic occurs through separate 356 means, not specified here. 358 4.1. Control Phase 360 The Control Phase, as described in RFC 6812 [RFC6812] section 3.1, 361 begins with the Sender sending a Control-Request message to the 362 Responder. The Responder replies by sending a Control-Response with 363 an appropriate Status indicating Success when the Sender identity is 364 verified and the requested UDP port was successfully opened. In all 365 other cases, a non-zero Status is returned in the Command-Header 366 Status field. 368 4.1.1. Control Request 370 The Control Request message, as described in RFC 6812 [RFC6812] 371 section 3.1.1, consists of a Command Header followed by one or more 372 Command, Status, Length and Data sections (henceforth known as CSLD). 373 At the minimum, there SHOULD be at the least two CSLD sections, one 374 of which is the authentication CSLD section and the other carries 375 information for the Measurement Phase simulation type. 377 4.1.1.1. Command Header 379 The Command Header is the first section of the Control Request 380 message and is described in RFC 6812 [RFC6812] section 3.1.1.1. 382 4.1.1.2. CSLDs 384 The two CSLDs to be included, in order, along with the Command Header 385 are: 387 o The Authentication CSLD 389 o A Measurement Type CSLD 391 In this revision of the protocol, an additional Measurement Type CSLD 392 has been defined, the Alternate Marking Measurement Type CSLD. In 393 RFC 6812 [RFC6812] section 3.1.1.2 is described the UDP-Measurement 394 CSLD. 396 4.1.1.2.1. Authentication CSLD 398 The Authentication CSLD provides the message authentication and 399 verifies the requester knows the shared-secret. The format for the 400 Authentication CSLD is detailed in RFC 6812 [RFC6812] section 401 3.1.1.2.1. 403 4.1.1.2.2. Alternate Marking Measurement CSLD 405 The Alternate Marking Measurement CSLD indicates the Measurement Type 406 to be used during the Measurement Phase and specifies the addresses 407 and UDP port to be opened as well as the duration the port has to be 408 kept open for the measurement phase. The format of the CSLD is as 409 follows: 411 0 1 2 3 412 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Command | Status | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Command length | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Address Type | Role | Reserved | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Session Identifier | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | | 423 + + 424 | Control Source Address | 425 + + 426 | | 427 + + 428 | | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | | 431 + + 432 | | 433 + + 434 | Control Destination Address | 435 + + 436 | | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | | 439 + + 440 | | 441 + + 442 | Measurement Source Address | 443 + + 444 | | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | | 447 + + 448 | | 449 + + 450 | Measurement Destination Address | 451 + + 452 | | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Control Source Port | Reserved | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Measurement Source Port | Measurement Destination Port | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Measurement Starting Time | 459 + + 460 | | 461 + + 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Traffic profile | Traffic ToS | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Marking mode |Assessment mode| Marking Period | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Duration | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 The new fields that have been added to RFC 6812 [RFC6812] section 471 3.1.1.2.2 are: Measurement Starting time, Traffic Profile, Traffic 472 TOS, Marking mode, Assesment mode, Marking period. They are 473 described below. 475 The unchanged fields are detailed in RFC 6812 [RFC6812] section 476 3.1.1.2.2: 478 So the new fields in the Alternate Marking Measurement CSLD have the 479 following meaning: 481 +-------------+-----------+-----------------------------------------+ 482 | Field | Size | Definition | 483 | | (bits) | | 484 +-------------+-----------+-----------------------------------------+ 485 | Command | 16 | Indicates that the CSLD is to simulate | 486 | | | UDP alternate marking traffic | 487 | | | measurements. | 488 | --------- | --------- | -------------------------- | 489 | Measurement | 64 | Carries the timestamp when the | 490 | Starting | | Measurement Phase will start | 491 | Time | | | 492 | --------- | --------- | -------------------------- | 493 | Traffic | 16 | Indicates a fixed profile with an | 494 | Profile | | assigned value (defined outside this | 495 | | | document), to establish size, number of | 496 | | | packets, milliseconds between packets | 497 | | | that are generated in both directions. | 498 | --------- | --------- | -------------------------- | 499 | Traffic ToS | 16 | Indicates the Type of Service of the | 500 | | | generated test frames: but if the | 501 | | | marking field is the ToS field, the two | 502 | | | marking ToS values are the first and | 503 | | | the last 8 bits; otherwise if the | 504 | | | marking field is different, the first 8 | 505 | | | bits are zero and the last 8 bits | 506 | | | indicates the ToS of all the generated | 507 | | | frames. | 508 | --------- | --------- | -------------------------- | 509 | Marking | 8 | Indicates one of the alternatives for | 510 | mode | | Marking Field: marking IPv4 header | 511 | | | (Type of Service Field or the last | 512 | | | reserved bit of the Flag field) or | 513 | | | marking UDP payload (Measurement Type | 514 | | | or Data). | 515 | --------- | --------- | -------------------------- | 516 | Assessment | 8 | Indicates one of the three alternatives | 517 | mode | | for the Calculation Phase: 1 - Local | 518 | | | assessment, 2 - Central assessment, 3 - | 519 | | | Local assessment with reference | 520 | | | recording. | 521 | --------- | --------- | -------------------------- | 522 | Marking | 16 | Indicates the duration in seconds of | 523 | Period | | the Alternate Marking period | 524 +-------------+-----------+-----------------------------------------+ 526 Note: The source addresses are only indicative of identity of the 527 originator and cannot be used as destination for responses in a NAT 528 environment. 530 Note: In case of Local assessment with reference recording, Sender 531 and Responder exchanges the refernce reconding before the Measurement 532 Phase. 534 Note: All timestamps have the format as described in RFC 5905 535 [RFC5905] and is as follows: the first 32 bits represent the unsigned 536 integer number of seconds elapsed since 0h on 1 January 1900; the 537 next 32 bits represent the fractional part of a second thereof. The 538 timestamp definition is also similar to RFC 4656 [RFC4656] 540 In addition, the timestamp format used can be as described for the 541 low-order 64 bits of the IEEE 1588-2008 (1588v2) Precision Time 542 Protocol timestamp format [IEEE1588]. This truncated format consists 543 of a 32-bit seconds field followed by a 32-bit nanoseconds field, and 544 is the same as the IEEE 1588v1 timestamp format. This timestamp 545 definition is similar to the default timestamp as specified in RFC 546 6374 [RFC6374] 548 Implementations MUST use only one of the two formats. The chosen 549 format is negotiated out-of-band between the endpoints. 551 4.1.2. Control Response Message 553 In response to the Control Request Message the network element 554 designated the Responder sends back a Control Response Message that 555 reflects the Command Header with an updated Status field and includes 556 the two CSLD sections that also carry updated Status fields. Hence, 557 the format is identical to the Control Request message as described 558 above. The supported values of the Status fields are the same 559 described in RFC 6812 [RFC6812] section 3.1.2. 561 4.2. Measurement Phase 563 Upon receiving the Control Response message with the Status set to 564 Success, the second phase of the protocol, the Measurement Phase, is 565 initiated. In all other cases when the Status is not success no 566 measurement traffic is initiated. In the Measurement Phase the 567 Sender sends a stream of measurement messages. The measurement 568 message stream consists of packets/frames that are spaced a 569 configured number of milliseconds. 571 The Measurement messages as defined by this document for Alternate 572 Marking UDP Measurements is as shown below and is simplified in 573 comparison to RFC 6812 [RFC6812] section 3.2. In particular the 574 fields that have been removed from RFC 6812 [RFC6812] section 3.2 575 are: Sender Send Time, Responder Receive Time, Responder Send Time, 576 Sender Receive Time, Sender Clock Offset, Responder Clock Offset, 577 Sender Sequence No. and Responder Sequence No. 579 The format of the Measurement messages is the same for the exchange 580 in both directions, that is when sent from the Sender to the 581 Responder and from the Responder to the Sender. 583 Note: Marking field can be chosen in two ways: marking UDP payload or 584 marking IPv4 header. Marking IPv4 header (Type of Service Field or 585 the last reserved bit of the Flag field) is useful so in this way the 586 active measurement could use the same functions of passive 587 measurement. 589 0 1 2 3 590 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Measurement Type | Reserved | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | | 595 . . 596 . Data . 597 . . 598 | | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 The fields for the UDP Measurement message have the following 602 meaning: 604 +-------------+-----------+-----------------------------------------+ 605 | Field | Size | Description | 606 | | (bits) | | 607 +-------------+-----------+-----------------------------------------+ 608 | Measurement | 16 | Carries the type of measurement being | 609 | Type | | performed (This field can include | 610 | | | Marking: at least two values); 1 - | 611 | | | Reserved, 2 - Reserved, 3 - UDP | 612 | --------- | --------- | -------------------------- | 613 | Reserved | 16 | Reserved field and MUST be set to 0 | 614 | --------- | --------- | -------------------------- | 615 | Data | 32 bit | This field is used to pad up to the | 616 | | aligned | configured request data size. The | 617 | | | minimum requested data size SHOULD be | 618 | | | 512 bytes and this field will be of | 619 | | | length 512 minus the length of the | 620 | | | previous fields. This field can include | 621 | | | Marking | 622 +-------------+-----------+-----------------------------------------+ 624 Note: No timestamp, No sequence number. The two data flows are 625 indipendent. 627 4.3. Calculation Phase 629 As mentioned above, the Calculation Phase is introduced "ad hoc" for 630 Alternate Marking implementation because it does not exist in Cisco 631 Service Level Assurance Protocol described in RFC 6812 [RFC6812]. 632 After test execution there are some alternatives to compute packet 633 loss, delay and delay variation: 635 o Local assessment: Sender initiates a Calculation Request message 636 and Responder sends back a Calculation Response message. Sender 637 and Responder, upon receipt test traffic, create data structure 638 with timestamped records then computes service level metrics from 639 that data structure. Let's call this data structure the test 640 receipt). 642 o Central assessment: A "central" entity (e.g. a controller) 643 compares the test receipt collected by the Responder with data 644 structure obtained from the Sender, then computes the service 645 levels by means of comparing. 647 o Local assessment with reference recording: Both sender and 648 receiver play out the same test traffic. Assessment is done 649 locally not by computing metrics over the test receipt, but by 650 "overlaying" the original with the one that was received and 651 computing the delta. 653 5. Implementation notes 655 Implementation notes are detailed in RFC 6812 [RFC6812] section 4. 657 6. IANA Considerations 659 IANA needs to reserve a new value for Alternate Marking CSLD Command 660 Registry. The available values for future extensions are detailed in 661 RFC 6812 [RFC6812] section 6. 663 7. Security Considerations 665 Security Considerations are detailed in RFC 6812 [RFC6812] section 7. 667 8. Terminology 668 +-------------+-----------------------------------------------------+ 669 | Term | Description | 670 +-------------+-----------------------------------------------------+ 671 | Control | A phase during which Control Request and Control | 672 | Phase | Response is exchanged. | 673 | --------- | -------------------------- | 674 | L2 | OSI Data Link Layer | 675 | --------- | -------------------------- | 676 | L3 | OSI Network Layer | 677 | --------- | -------------------------- | 678 | Measurement | Active measurement phase that is marked by a | 679 | Phase | sequence of Measurement Request and Measurement | 680 | | Response exchanges. | 681 | --------- | -------------------------- | 682 | Metric | A particular characteristic of the network data | 683 | | traffic, for example latency, jitter, packet/frame | 684 | | loss | 685 | --------- | -------------------------- | 686 | Responder | A network element that responds to a message | 687 | --------- | -------------------------- | 688 | RTP | Real-time Transport Protocol | 689 | --------- | -------------------------- | 690 | Sender | A network element that is the initiator of a | 691 | | message exchange | 692 | --------- | -------------------------- | 693 | Service | This is the level of service that is agreed upon | 694 | Level | between the Provider and the Customer | 695 | --------- | -------------------------- | 696 | UDP | User Datagram Protocol | 697 +-------------+-----------------------------------------------------+ 699 9. Acknowledgements 701 Thanks to Luca Castaldelli, Francesco Burgio and Stefano Righetti 702 from Telecom Italia for their contribution to the prototype 703 implementation of the method. 705 Mauro Cociglio and Giuseppe Fioccola worked in part on the Leone 706 research project, which received funding from the European Union 707 Seventh Framework Programme [FP7/2007-2013] under grant agreement 708 number 317647. 710 10. References 711 10.1. Normative References 713 [I-D.tempia-ippm-p3m] 714 Capello, A., Cociglio, M., Fioccola, G., Castaldelli, L., 715 and A. Bonda, "A packet based method for passive 716 performance monitoring", draft-tempia-ippm-p3m-02 (work in 717 progress), October 2015. 719 [IEEE1588] 720 IEEE, "1588-2008 Standard for a Precision Clock 721 Synchronization Protocol for Networked Measurement and 722 Control Systems", March 2008. 724 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 725 Requirement Levels", BCP 14, RFC 2119, 726 DOI 10.17487/RFC2119, March 1997, 727 . 729 [RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, 730 S., and E. Yedavalli, "Cisco Service-Level Assurance 731 Protocol", RFC 6812, DOI 10.17487/RFC6812, January 2013, 732 . 734 10.2. Informative References 736 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 737 Dial In User Service) Support For Extensible 738 Authentication Protocol (EAP)", RFC 3579, 739 DOI 10.17487/RFC3579, September 2003, 740 . 742 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 743 Zekauskas, "A One-way Active Measurement Protocol 744 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 745 . 747 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 748 384, and HMAC-SHA-512 with IPsec", RFC 4868, 749 DOI 10.17487/RFC4868, May 2007, 750 . 752 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 753 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 754 RFC 5357, DOI 10.17487/RFC5357, October 2008, 755 . 757 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 758 "Network Time Protocol Version 4: Protocol and Algorithms 759 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 760 . 762 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 763 Measurement for MPLS Networks", RFC 6374, 764 DOI 10.17487/RFC6374, September 2011, 765 . 767 [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting 768 IP Network Performance Metrics: Different Points of View", 769 RFC 6703, DOI 10.17487/RFC6703, August 2012, 770 . 772 Authors' Addresses 774 Giuseppe Fioccola 775 Telecom Italia 776 Via Reiss Romoli, 274 777 Torino 10148 778 Italy 780 Email: giuseppe.fioccola@telecomitalia.it 782 Alexander Clemm 783 Cisco Systems 784 170 West Tasman Drive 785 San Jose 95134 786 USA 788 Phone: 1-408-526-4000 789 Email: alex@cisco.com 791 Mauro Cociglio 792 Telecom Italia 793 Via Reiss Romoli, 274 794 Torino 10148 795 Italy 797 Email: mauro.cociglio@telecomitalia.it 798 Mouli Chandramouli 799 Cisco Systems 801 Email: moulchan@cisco.com 803 Alessandro Capello 804 Telecom Italia 805 Via Reiss Romoli, 274 806 Torino 10148 807 Italy 809 Email: alessandro.capello@telecomitalia.it