idnits 2.17.1 draft-ietf-mpls-loss-delay-04.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 == Line 935 has weird spacing: '...) Field meas...' == Line 1181 has weird spacing: '...) Field meas...' -- The document date (July 19, 2011) is 4659 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1538 -- Looks like a reference, but probably isn't: '2' on line 1538 -- Looks like a reference, but probably isn't: '3' on line 378 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1588' == Outdated reference: A later version (-04) exists of draft-ietf-mpls-tp-loss-delay-profile-03 -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 2680 (Obsoleted by RFC 7680) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS D. Frost 3 Internet-Draft S. Bryant 4 Intended status: Standards Track Cisco Systems 5 Expires: January 20, 2012 July 19, 2011 7 Packet Loss and Delay Measurement for MPLS Networks 8 draft-ietf-mpls-loss-delay-04 10 Abstract 12 Many service provider service level agreements (SLAs) depend on the 13 ability to measure and monitor performance metrics for packet loss 14 and one-way and two-way delay, as well as related metrics such as 15 delay variation and channel throughput. This measurement capability 16 also provides operators with greater visibility into the performance 17 characteristics of their networks, thereby facilitating planning, 18 troubleshooting, and evaluation. This document specifies protocol 19 mechanisms to enable the efficient and accurate measurement of these 20 performance metrics in MPLS networks. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 20, 2012. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1. Applicability and Scope . . . . . . . . . . . . . . . . . 6 64 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 65 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.1. Basic Bidirectional Measurement . . . . . . . . . . . . . 6 67 2.2. Packet Loss Measurement . . . . . . . . . . . . . . . . . 8 68 2.3. Throughput Measurement . . . . . . . . . . . . . . . . . . 10 69 2.4. Delay Measurement . . . . . . . . . . . . . . . . . . . . 10 70 2.5. Delay Variation Measurement . . . . . . . . . . . . . . . 12 71 2.6. Unidirectional Measurement . . . . . . . . . . . . . . . . 12 72 2.7. Dyadic Measurement . . . . . . . . . . . . . . . . . . . . 13 73 2.8. Loopback Measurement . . . . . . . . . . . . . . . . . . . 13 74 2.9. Measurement Considerations . . . . . . . . . . . . . . . . 14 75 2.9.1. Types of Channels . . . . . . . . . . . . . . . . . . 14 76 2.9.2. Quality of Service . . . . . . . . . . . . . . . . . . 14 77 2.9.3. Measurement Point Location . . . . . . . . . . . . . . 14 78 2.9.4. Equal Cost Multipath . . . . . . . . . . . . . . . . . 15 79 2.9.5. Intermediate Nodes . . . . . . . . . . . . . . . . . . 15 80 2.9.6. Different Transmit and Receive Interfaces . . . . . . 15 81 2.9.7. External Post-Processing . . . . . . . . . . . . . . . 16 82 2.9.8. Loss Measurement Modes . . . . . . . . . . . . . . . . 16 83 2.9.9. Loss Measurement Scope . . . . . . . . . . . . . . . . 18 84 2.9.10. Delay Measurement Accuracy . . . . . . . . . . . . . . 18 85 2.9.11. Delay Measurement Timestamp Format . . . . . . . . . . 18 86 3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 19 87 3.1. Loss Measurement Message Format . . . . . . . . . . . . . 19 88 3.2. Delay Measurement Message Format . . . . . . . . . . . . . 25 89 3.3. Combined Loss/Delay Measurement Message Format . . . . . . 27 90 3.4. Timestamp Field Formats . . . . . . . . . . . . . . . . . 28 91 3.5. TLV Objects . . . . . . . . . . . . . . . . . . . . . . . 29 92 3.5.1. Padding . . . . . . . . . . . . . . . . . . . . . . . 30 93 3.5.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 31 94 3.5.3. Loopback Request . . . . . . . . . . . . . . . . . . . 31 95 3.5.4. Session Query Interval . . . . . . . . . . . . . . . . 32 96 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 33 97 4.1. Operational Overview . . . . . . . . . . . . . . . . . . . 33 98 4.2. Loss Measurement Procedures . . . . . . . . . . . . . . . 34 99 4.2.1. Initiating a Loss Measurement Operation . . . . . . . 34 100 4.2.2. Transmitting a Loss Measurement Query . . . . . . . . 34 101 4.2.3. Receiving a Loss Measurement Query . . . . . . . . . . 35 102 4.2.4. Transmitting a Loss Measurement Response . . . . . . . 35 103 4.2.5. Receiving a Loss Measurement Response . . . . . . . . 36 104 4.2.6. Loss Calculation . . . . . . . . . . . . . . . . . . . 36 105 4.2.7. Quality of Service . . . . . . . . . . . . . . . . . . 37 106 4.2.8. G-ACh Packets . . . . . . . . . . . . . . . . . . . . 37 107 4.2.9. Test Messages . . . . . . . . . . . . . . . . . . . . 37 108 4.2.10. Message Loss and Packet Misorder Conditions . . . . . 38 109 4.3. Delay Measurement Procedures . . . . . . . . . . . . . . . 39 110 4.3.1. Transmitting a Delay Measurement Query . . . . . . . . 39 111 4.3.2. Receiving a Delay Measurement Query . . . . . . . . . 39 112 4.3.3. Transmitting a Delay Measurement Response . . . . . . 40 113 4.3.4. Receiving a Delay Measurement Response . . . . . . . . 41 114 4.3.5. Timestamp Format Negotiation . . . . . . . . . . . . . 41 115 4.3.6. Quality of Service . . . . . . . . . . . . . . . . . . 42 116 4.4. Combined Loss/Delay Measurement Procedures . . . . . . . . 42 117 5. Implementation Disclosure Requirements . . . . . . . . . . . . 42 118 6. Congestion Considerations . . . . . . . . . . . . . . . . . . 43 119 7. Manageability Considerations . . . . . . . . . . . . . . . . . 44 120 8. Security Considerations . . . . . . . . . . . . . . . . . . . 45 121 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 122 9.1. Allocation of PW Associated Channel Types . . . . . . . . 46 123 9.2. Creation of Measurement Timestamp Type Registry . . . . . 47 124 9.3. Creation of MPLS Loss/Delay Measurement Control Code 125 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 47 126 9.4. Creation of MPLS Loss/Delay Measurement TLV Object 127 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 48 128 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 129 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 130 11.1. Normative References . . . . . . . . . . . . . . . . . . . 49 131 11.2. Informative References . . . . . . . . . . . . . . . . . . 50 132 Appendix A. Default Timestamp Format Rationale . . . . . . . . . 51 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 135 1. Introduction 137 Many service provider service level agreements (SLAs) depend on the 138 ability to measure and monitor performance metrics for packet loss 139 and one-way and two-way delay, as well as related metrics such as 140 delay variation and channel throughput. This measurement capability 141 also provides operators with greater visibility into the performance 142 characteristics of their networks, thereby facilitating planning, 143 troubleshooting, and evaluation. This document specifies protocol 144 mechanisms to enable the efficient and accurate measurement of these 145 performance metrics in MPLS networks. 147 This document specifies two closely-related protocols, one for packet 148 loss measurement (LM) and one for packet delay measurement (DM). 149 These protocols have the following characteristics and capabilities: 151 o The LM and DM protocols are intended to be simple and to support 152 efficient hardware processing. 154 o The LM and DM protocols operate over the MPLS Generic Associated 155 Channel (G-ACh) [RFC5586] and support measurement of loss, delay, 156 and related metrics over Label Switched Paths (LSPs), pseudowires, 157 and MPLS sections (links). 159 o The LM and DM protocols are applicable to the LSPs, pseudowires, 160 and sections of networks based on the MPLS Transport Profile 161 (MPLS-TP), because the MPLS-TP is based on a standard MPLS data 162 plane. The MPLS-TP is defined and described in [RFC5921], and 163 MPLS-TP LSPs, pseudowires, and sections are discussed in detail in 164 [RFC5960]. A profile describing the minimal functional subset of 165 the LM and DM protocols in the MPLS-TP context is provided in 166 [I-D.ietf-mpls-tp-loss-delay-profile]. 168 o The LM and DM protocols can be used both for continuous/proactive 169 and selective/on-demand measurement. 171 o The LM and DM protocols use a simple query/response model for 172 bidirectional measurement that allows a single node - the querier 173 - to measure the loss or delay in both directions. 175 o The LM and DM protocols use query messages for unidirectional loss 176 and delay measurement. The measurement can either be carried out 177 at the downstream node(s) or at the querier if an out-of-band 178 return path is available. 180 o The LM and DM protocols do not require that the transmit and 181 receive interfaces be the same when performing bidirectional 182 measurement. 184 o The DM protocol is stateless. 186 o The LM protocol is "almost" stateless: loss is computed as a delta 187 between successive messages, and thus the data associated with the 188 last message received must be retained. 190 o The LM protocol can perform two distinct kinds of loss 191 measurement: it can measure the loss of specially generated test 192 messages in order to infer the approximate data-plane loss level 193 (inferred measurement); or it can directly measure data-plane 194 packet loss (direct measurement). Direct measurement provides 195 perfect loss accounting, but may require specialized hardware 196 support and is only applicable to some LSP types. Inferred 197 measurement provides only approximate loss accounting but is 198 generally applicable. 200 The direct LM method is also known as "frame-based" in the context 201 of Ethernet transport networks [Y.1731]. Inferred LM is a 202 generalization of the "synthetic" measurement approach currently 203 in development for Ethernet networks, in the sense that it allows 204 test messages to be decoupled from measurement messages. 206 o The LM protocol supports measurement in terms of both packet 207 counts and octet counts. 209 o The LM protocol supports both 32-bit and 64-bit counters. 211 o The LM protocol can be used to measure channel throughput as well 212 as packet loss. 214 o The DM protocol supports multiple timestamp formats, and provides 215 a simple means for the two endpoints of a bidirectional connection 216 to agree on a preferred format. This procedure reduces to a 217 triviality for implementations supporting only a single timestamp 218 format. 220 o The DM protocol supports varying the measurement message size in 221 order to measure delays associated with different packet sizes. 223 The One-Way Active Measurement Protocol (OWAMP) [RFC4656] and Two-Way 224 Active Measurement Protocol (TWAMP) [RFC5357] provide capabilities 225 for the measurement of various performance metrics in IP networks. 226 These protocols are not streamlined for hardware processing and rely 227 on IP and TCP, as well as elements of the Network Time Protocol 228 (NTP), which may not be available or optimized in some network 229 environments; they also lack support for IEEE 1588 timestamps and 230 direct-mode LM, which in some environments may be required. The 231 protocols defined in this document thus are similar in some respects 232 to, but also differ from, these IP-based protocols. 234 1.1. Applicability and Scope 236 This document specifies measurement procedures and protocol messages 237 that are intended to be applicable in a wide variety of 238 circumstances, and amenable to implementation by a wide range of 239 hardware- and software-based measurement systems. As such, it does 240 not attempt to mandate measurement quality levels or analyze specific 241 end-user applications. 243 1.2. Terminology 245 Term Definition 246 ----- ------------------------------------------- 247 ACH Associated Channel Header 248 DM Delay Measurement 249 ECMP Equal Cost Multipath 250 G-ACh Generic Associated Channel 251 LM Loss Measurement 252 LSE Label Stack Entry 253 LSP Label Switched Path 254 NTP Network Time Protocol 255 OAM Operations, Administration, and Maintenance 256 PTP Precision Time Protocol 257 TC Traffic Class 259 2. Overview 261 This section begins with a summary of the basic methods used for the 262 bidirectional measurement of packet loss and delay. These 263 measurement methods are then described in detail. Finally a list of 264 practical considerations are discussed that may come into play to 265 inform or modify these simple procedures. This section is limited to 266 theoretical discussion; for protocol specifics the reader is referred 267 to Section 3 and Section 4. 269 2.1. Basic Bidirectional Measurement 271 The following figure shows the reference scenario. 273 T1 T2 274 +-------+/ Query \+-------+ 275 | | - - - - - - - - ->| | 276 | A |===================| B | 277 | |<- - - - - - - - - | | 278 +-------+\ Response /+-------+ 279 T4 T3 281 Figure 1 283 The figure shows a bidirectional channel between two nodes, A and B, 284 and illustrates the temporal reference points T1-T4 associated with a 285 measurement operation that takes place at A. The operation consists 286 of A sending a query message to B, and B sending back a response. 287 Each reference point indicates the point in time at which either the 288 query or the response message is transmitted or received over the 289 channel. 291 In this situation, A can arrange to measure the packet loss over the 292 channel in the forward and reverse directions by sending Loss 293 Measurement (LM) query messages to B each of which contains the count 294 of packets transmitted prior to time T1 over the channel to B 295 (A_TxP). When the message reaches B, it appends two values and 296 reflects the message back to A: the count of packets received prior 297 to time T2 over the channel from A (B_RxP), and the count of packets 298 transmitted prior to time T3 over the channel to A (B_TxP). When the 299 response reaches A, it appends a fourth value, the count of packets 300 received prior to time T4 over the channel from B (A_RxP). 302 These four counter values enable A to compute the desired loss 303 statistics. Because the transmit count at A and the receive count at 304 B (and vice versa) may not be synchronized at the time of the first 305 message, and to limit the effects of counter wrap, the loss is 306 computed in the form of a delta between messages. 308 To measure at A the delay over the channel to B, a Delay Measurement 309 (DM) query message is sent from A to B containing a timestamp 310 recording the instant at which it is transmitted, i.e. T1. When the 311 message reaches B, a timestamp is added recording the instant at 312 which it is received (T2). The message can now be reflected from B 313 to A, with B adding its transmit timestamp (T3) and A adding its 314 receive timestamp (T4). These four timestamps enable A to compute 315 the one-way delay in each direction, as well as the two-way delay for 316 the channel. The one-way delay computations require that the clocks 317 of A and B be synchronized; mechanisms for clock synchronization are 318 outside the scope of this document. 320 2.2. Packet Loss Measurement 322 Suppose a bidirectional channel exists between the nodes A and B. The 323 objective is to measure at A the following two quantities associated 324 with the channel: 326 A_TxLoss (transmit loss): the number of packets transmitted by A 327 over the channel but not received at B; 329 A_RxLoss (receive loss): the number of packets transmitted by B 330 over the channel but not received at A. 332 This is accomplished by initiating a Loss Measurement (LM) operation 333 at A, which consists of transmission of a sequence of LM query 334 messages (LM[1], LM[2], ...) over the channel at a specified rate, 335 such as one every 100 milliseconds. Each message LM[n] contains the 336 following value: 338 A_TxP[n]: the total count of packets transmitted by A over the 339 channel prior to the time this message is transmitted. 341 When such a message is received at B, the following value is recorded 342 in the message: 344 B_RxP[n]: the total count of packets received by B over the 345 channel at the time this message is received (excluding the 346 message itself). 348 At this point, B transmits the message back to A, recording within it 349 the following value: 351 B_TxP[n]: the total count of packets transmitted by B over the 352 channel prior to the time this response is transmitted. 354 When the message response is received back at A, the following value 355 is recorded in the message: 357 A_RxP[n]: the total count of packets received by A over the 358 channel at the time this response is received (excluding the 359 message itself). 361 The transmit loss A_TxLoss[n-1,n] and receive loss A_RxLoss[n-1,n] 362 within the measurement interval marked by the messages LM[n-1] and 363 LM[n] are computed by A as follows: 365 A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1]) 366 A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1]) 367 where the arithmetic is modulo the counter size. 369 (Strictly speaking, it is not necessary that the fourth count, 370 A_RxP[n], actually be written in the message, but this is convenient 371 for some implementations and useful if the message is to be forwarded 372 on to an external measurement system.) 374 The derived values 376 A_TxLoss = A_TxLoss[1,2] + A_TxLoss[2,3] + ... 378 A_RxLoss = A_RxLoss[1,2] + A_RxLoss[2,3] + ... 380 are updated each time a response to an LM message is received and 381 processed, and represent the total transmit and receive loss over the 382 channel since the LM operation was initiated. 384 When computing the values A_TxLoss[n-1,n] and A_RxLoss[n-1,n] the 385 possibility of counter wrap must be taken into account. Consider for 386 example the values of the A_TxP counter at sequence numbers n-1 and 387 n. Clearly if A_TxP[n] is allowed to wrap to 0 and then beyond to a 388 value equal to or greater than A_TxP[n-1], the computation of an 389 unambiguous A_TxLoss[n-1,n] value will be impossible. Therefore the 390 LM message rate MUST be sufficiently high, given the counter size and 391 the speed and minimum packet size of the underlying channel, that 392 this condition cannot arise. For example, a 32-bit counter for a 100 393 Gbps link with a minimum packet size of 64 bytes can wrap in 2^32 / 394 (10^11/(64*8)) = ~22 seconds, which is therefore an upper bound on 395 the LM message interval under such conditions. This bound will be 396 referred to as the MaxLMInterval of the channel. It is clear that 397 the MaxLMInterval will be a more restrictive constraint in the case 398 of direct LM and for smaller counter sizes. 400 The loss measurement approach described in this section has the 401 characteristic of being stateless at B and "almost" stateless at A. 402 Specifically, A must retain the data associated with the last LM 403 response received, in order to use it to compute loss when the next 404 response arrives. This data MAY be discarded, and MUST NOT be used 405 as a basis for measurement, if MaxLMInterval elapses before the next 406 response arrives, because in this case an unambiguous measurement 407 cannot be made. 409 The foregoing discussion has assumed the counted objects are packets, 410 but this need not be the case. In particular, octets may be counted 411 instead. This will, of course, reduce the MaxLMInterval accordingly. 413 In addition to absolute aggregate loss counts, the individual loss 414 counts yield additional metrics such as the average loss rate over 415 any multiple of the measurement interval. An accurate loss rate can 416 be determined over time even in the presence of anomalies affecting 417 individual measurements, such as those due to packet misordering 418 (Section 4.2.10). 420 Note that an approach for conducting packet loss measurement in IP 421 networks is documented in [RFC2680]. This approach differs from the 422 one described here, for example by requiring clock synchronization 423 between the measurement points and lacking support for direct-mode 424 LM. 426 2.3. Throughput Measurement 428 If LM query messages contain a timestamp recording their time of 429 transmission, this data can be combined with the packet or octet 430 counts to yield measurements of the throughput offered and delivered 431 over the channel during the interval in terms of the counted units. 433 For a bidirectional channel, for example, given any two LM response 434 messages (separated in time by not more than the MaxLMInterval), the 435 difference between the counter values tells the querier the number of 436 units successfully transmitted and received in the interval between 437 the timestamps. Absolute offered throughput is the number of data 438 units transmitted and absolute delivered throughput is the number of 439 data units received. Throughput rate is the number of data units 440 sent or received per unit time. 442 Just as for loss measurement, the interval counts can be accumulated 443 to arrive at the absolute throughput of the channel since the start 444 of the measurement operation, or used to derive related metrics such 445 as the throughput rate. This procedure also enables out-of-service 446 throughput testing when combined with a simple packet generator. 448 2.4. Delay Measurement 450 Suppose a bidirectional channel exists between the nodes A and B. The 451 objective is to measure at A one or more of the following quantities 452 associated with the channel: 454 o The one-way delay associated with the forward (A to B) direction 455 of the channel; 457 o The one-way delay associated with the reverse (B to A) direction 458 of the channel; 460 o The two-way delay (A to B to A) associated with the channel. 462 The one-way delay metric for packet networks is described in 464 [RFC2679]. In the case of two-way delay, there are actually two 465 possible metrics of interest. The "two-way channel delay" is the sum 466 of the one-way delays in each direction and reflects the delay of the 467 channel itself, irrespective of processing delays within the remote 468 endpoint B. The "round-trip delay" is described in [RFC2681] and 469 includes in addition any delay associated with remote endpoint 470 processing. 472 Measurement of the one-way delay quantities requires that the clocks 473 of A and B be synchronized, whereas the two-way delay metrics can be 474 measured directly even when this is not the case (provided A and B 475 have stable clocks). 477 A measurement is accomplished by sending a Delay Measurement (DM) 478 query message over the channel to B which contains the following 479 timestamp: 481 T1: the time the DM query message is transmitted from A. 483 When the message arrives at B, the following timestamp is recorded in 484 the message: 486 T2: the time the DM query message is received at B. 488 At this point B transmits the message back to A, recording within it 489 the following timestamp: 491 T3: the time the DM response message is transmitted from B. 493 When the message arrives back at A, the following timestamp is 494 recorded in the message: 496 T4: the time the DM response message is received back at A. 498 (Strictly speaking, it is not necessary that the fourth timestamp, 499 T4, actually be written in the message, but this is convenient for 500 some implementations and useful if the message is to be forwarded on 501 to an external measurement system.) 503 At this point, A can compute the two-way channel delay associated 504 with the channel as 506 two-way channel delay = (T4 - T1) - (T3 - T2) 508 and the round-trip delay as 510 round-trip delay = T4 - T1. 512 If the clocks of A and B are known at A to be synchronized, then both 513 one-way delay values, as well as the two-way channel delay, can be 514 computed at A as 516 forward one-way delay = T2 - T1 518 reverse one-way delay = T4 - T3 520 two-way channel delay = forward delay + reverse delay. 522 Note that this formula for the two-way channel delay reduces to the 523 one previously given, and clock synchronization is not required to 524 compute this metric. 526 2.5. Delay Variation Measurement 528 Inter-Packet Delay Variation (IPDV) and Packet Delay Variation (PDV) 529 [RFC5481] are performance metrics derived from one-way delay 530 measurement and are important in some applications. IPDV represents 531 the difference between the one-way delays of successive packets in a 532 stream. PDV, given a measurement test interval, represents the 533 difference between the one-way delay of a packet in the interval and 534 that of the packet in the interval with the minimum delay. 536 IPDV and PDV measurements can therefore be derived from delay 537 measurements obtained through the procedures in Section 2.4. An 538 important point regarding delay variation measurement, however, is 539 that it can be carried out based on one-way delay measurements even 540 when the clocks of the two systems involved in those measurements are 541 not synchronized with one another. 543 2.6. Unidirectional Measurement 545 In the case that the channel from A to (B1, ..., Bk) (where B2, ..., 546 Bk refer to the point-to-multipoint case) is unidirectional, i.e. is 547 a unidirectional LSP, LM and DM measurements can be carried out at 548 B1, ..., Bk instead of at A. 550 For LM this is accomplished by initiating an LM operation at A and 551 carrying out the same procedures as for bidirectional channels, 552 except that no responses from B1, ..., Bk to A are generated. 553 Instead, each terminal node B uses the A_TxP and B_RxP values in the 554 LM messages it receives to compute the receive loss associated with 555 the channel in essentially the same way as described previously, i.e. 557 B_RxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1]) 559 For DM, of course, only the forward one-way delay can be measured and 560 the clock synchronization requirement applies. 562 Alternatively, if an out-of-band channel from a terminal node B back 563 to A is available, the LM and DM message responses can be 564 communicated to A via this channel so that the measurements can be 565 carried out at A. 567 2.7. Dyadic Measurement 569 The basic procedures for bidirectional measurement assume that the 570 measurement process is conducted by and for the querier node A. It is 571 possible instead, with only minor variation of these procedures, to 572 conduct a dyadic or "dual-ended" measurement process in which both 573 nodes A and B perform loss or delay measurement based on the same 574 message flow. This is achieved by stipulating that A copy the third 575 and fourth counter or timestamp values from a response message into 576 the third and fourth slots of the next query, which are otherwise 577 unused, thereby providing B with equivalent information to that 578 learned by A. 580 The dyadic procedure has the advantage of halving the number of 581 messages required for both A and B to perform a given kind of 582 measurement, but comes at the expense of each node's ability to 583 control its own measurement process independently, and introduces 584 additional operational complexity into the measurement protocols. 585 The quantity of measurement traffic is also expected to be low 586 relative to that of user traffic, particularly when 64-bit counters 587 are used for LM. Consequently this document does not specify a 588 dyadic operational mode. It is however still possible, and may be 589 useful, for A to perform the extra copy, thereby providing additional 590 information to B even when its participation in the measurement 591 process is passive. 593 2.8. Loopback Measurement 595 Some bidirectional channels may be placed into a loopback state such 596 that messages are looped back to the sender without modification. In 597 this situation, LM and DM procedures can be used to carry out 598 measurements associated with the circular path. This is done by 599 generating "queries" with the Response flag set to 1. 601 For LM, the loss computation in this case is: 603 A_Loss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1]) 605 For DM, the round-trip delay is computed. In this case, however, the 606 remote endpoint processing time component reflects only the time 607 required to loop the message from channel input to channel output. 609 2.9. Measurement Considerations 611 A number of additional considerations apply in practice to the 612 measurement methods summarized above. 614 2.9.1. Types of Channels 616 There are several types of channels in MPLS networks over which loss 617 and delay measurement may be conducted. The channel type may 618 restrict the kinds of measurement that can be performed. In all 619 cases, LM and DM messages flow over the MPLS Generic Associated 620 Channel (G-ACh), which is described in detail in [RFC5586]. 622 Broadly, a channel in an MPLS network may be either a link, a Label 623 Switched Path (LSP) [RFC3031], or a pseudowire [RFC3985]. Links are 624 bidirectional and are also referred to as MPLS sections; see 625 [RFC5586] and [RFC5960]. Pseudowires are bidirectional. Label 626 Switched Paths may be either unidirectional or bidirectional. 628 The LM and DM protocols discussed in this document are initiated from 629 a single node, the querier. A query message may be received either 630 by a single node or by multiple nodes, depending on the nature of the 631 channel. In the latter case these protocols provide point-to- 632 multipoint measurement capabilities. 634 2.9.2. Quality of Service 636 Quality of Service (QoS) capabilities, in the form of the 637 Differentiated Services architecture, apply to MPLS as specified in 638 [RFC3270] and [RFC5462]. Different classes of traffic are 639 distinguished by the three-bit Traffic Class (TC) field of an MPLS 640 Label Stack Entry (LSE). Delay measurement therefore applies on a 641 per-traffic-class basis, and the TC values of LSEs above the G-ACh 642 Label (GAL) that precedes a DM message are significant. Packet loss 643 can be measured with respect either to the channel as a whole or to a 644 specific traffic class. 646 2.9.3. Measurement Point Location 648 The location of the measurement points for loss and delay within the 649 sending and receiving nodes is implementation-dependent but directly 650 affects the nature of the measurements. For example, a sending 651 implementation may or may not consider a packet to be "lost", for LM 652 purposes, that was discarded prior to transmission for queuing- 653 related reasons; conversely, a receiving implementation may or may 654 not consider a packet to be "lost", for LM purposes, if it was 655 physically received but discarded during receive-path processing. 656 The location of delay measurement points similarly determines what, 657 precisely, is being measured. The principal consideration here is 658 that the behavior of an implementation in these respects MUST be made 659 clear to the user. 661 2.9.4. Equal Cost Multipath 663 Equal Cost Multipath (ECMP) is the behavior of distributing packets 664 across multiple alternate paths toward a destination. The use of 665 ECMP in MPLS networks is described in BCP 128 [RFC4928]. The typical 666 result of ECMP being performed on an LSP which is subject to delay 667 measurement will be that only the delay of one of the available paths 668 is and can be measured. 670 The effects of ECMP on loss measurement will depend on the LM mode. 671 In the case of direct LM, the measurement will account for any 672 packets lost between the sender and the receiver, regardless of how 673 many paths exist between them. However, the presence of ECMP 674 increases the likelihood of misordering both of LM messages relative 675 to data packets, and of the LM messages themselves. Such 676 misorderings tend to create unmeasurable intervals and thus degrade 677 the accuracy of loss measurement. The effects of ECMP are similar 678 for inferred LM, with the additional caveat that, unless the test 679 packets are specially constructed so as to probe all available paths, 680 the loss characteristics of one or more of the alternate paths cannot 681 be accounted for. 683 2.9.5. Intermediate Nodes 685 In the case of an LSP, it may be desirable to measure the loss or 686 delay to or from an intermediate node as well as between LSP 687 endpoints. This can be done in principle by setting the Time to Live 688 (TTL) field in the outer LSE appropriately when targeting a 689 measurement message to an intermediate node. This procedure may 690 fail, however, if hardware-assisted measurement is in use, because 691 the processing of the packet by the intermediate node occurs only as 692 the result of TTL expiry, and the handling of TTL expiry may occur at 693 a later processing stage in the implementation than the hardware- 694 assisted measurement function. Often the motivation for conducting 695 measurements to intermediate nodes is an attempt to localize a 696 problem that has been detected on the LSP. In this case, if 697 intermediate nodes are not capable of performing hardware-assisted 698 measurement, a less accurate - but usually sufficient - software- 699 based measurement can be conducted instead. 701 2.9.6. Different Transmit and Receive Interfaces 703 The overview of the bidirectional measurement process presented in 704 Section 2 is also applicable when the transmit and receive interfaces 705 at A or B differ from one another. Some additional considerations, 706 however, do apply in this case: 708 o If different clocks are associated with transmit and receive 709 processing, these clocks must be synchronized in order to compute 710 the two-way delay. 712 o The DM protocol specified in this document requires that the 713 timestamp formats used by the interfaces that receive a DM query 714 and transmit a DM response agree. 716 o The LM protocol specified in this document supports both 32-bit 717 and 64-bit counter sizes, but the use of 32-bit counters at any of 718 the up to four interfaces involved in an LM operation will result 719 in 32-bit LM calculations for both directions of the channel. 721 2.9.7. External Post-Processing 723 In some circumstances it may be desirable to carry out the final 724 measurement computation at an external post-processing device 725 dedicated to the purpose. This can be achieved in supporting 726 implementations by, for example, configuring the querier, in the case 727 of a bidirectional measurement session, to forward each response it 728 receives to the post-processor via any convenient protocol. The 729 unidirectional case can be handled similarly through configuration of 730 the receiver, or by including an instruction in query messages for 731 the receiver to respond out-of-band to the appropriate return 732 address. 734 Post-processing devices may have the ability to store measurement 735 data for an extended period and to generate a variety of useful 736 statistics from them. External post-processing also allows the 737 measurement process to be completely stateless at the querier and 738 responder. 740 2.9.8. Loss Measurement Modes 742 The summary of loss measurement at the beginning of Section 2 above 743 made reference to the "count of packets" transmitted and received 744 over a channel. If the counted packets are the packets flowing over 745 the channel in the data plane, the loss measurement is said to 746 operate in "direct mode". If, on the other hand, the counted packets 747 are selected control packets from which the approximate loss 748 characteristics of the channel are being inferred, the loss 749 measurement is said to operate in "inferred mode". 751 Direct LM has the advantage of being able to provide perfect loss 752 accounting when it is available. There are, however, several 753 constraints associated with direct LM. 755 For accurate direct LM to occur, packets must not be sent between the 756 time the transmit count for an outbound LM message is determined and 757 the time the message is actually transmitted. Similarly, packets 758 must not be received and processed between the time an LM message is 759 received and the time the receive count for the message is 760 determined. If these "synchronization conditions" do not hold, the 761 LM message counters will not reflect the true state of the data 762 plane, with the result that, for example, the receive count of B may 763 be greater than the transmit count of A, and attempts to compute loss 764 by taking the difference will yield an invalid result. This 765 requirement for synchronization between LM message counters and the 766 data plane may require special support from hardware-based forwarding 767 implementations. 769 A limitation of direct LM is that it may be difficult or impossible 770 to apply in cases where the channel is an LSP and the LSP label at 771 the receiver is either nonexistent or fails to identify a unique 772 sending node. The first case happens when Penultimate Hop Popping 773 (PHP) is used on the LSP, and the second case generally holds for 774 LSPs based on the Label Distribution Protocol (LDP) [RFC5036] as 775 opposed to, for example, those based on Traffic Engineering 776 extensions to the Resource Reservation Protocol (RSVP-TE) [RFC3209]. 777 These conditions may make it infeasible for the receiver to identify 778 the data-plane packets associated with a particular source and LSP in 779 order to count them, or to infer the source and LSP context 780 associated with an LM message. Direct LM is also vulnerable to 781 disruption in the event that the ingress or egress interface 782 associated with an LSP changes during the LSP's lifetime. 784 Inferred LM works in the same manner as direct LM except that the 785 counted packets are special control packets, called test messages, 786 generated by the sender. Test messages may be either packets 787 explicitly constructed and used for LM or packets with a different 788 primary purpose, such as those associated with a Bidirectional 789 Forwarding Detection (BFD) [RFC5884] session. 791 The synchronization conditions discussed above for direct LM also 792 apply to inferred LM, the only difference being that the required 793 synchronization is now between the LM counters and the test message 794 generation process. Protocol and application designers MUST take 795 these synchronization requirements into account when developing tools 796 for inferred LM, and make their behavior in this regard clear to the 797 user. 799 Inferred LM provides only an approximate view of the loss level 800 associated with a channel, but is typically applicable even in cases 801 where direct LM is not. 803 2.9.9. Loss Measurement Scope 805 In the case of direct LM, where data-plane packets are counted, there 806 are different possibilities for which kinds of packets are included 807 in the count and which are excluded. The set of packets counted for 808 LM is called the loss measurement scope. As noted above, one factor 809 affecting the LM scope is whether all data packets are counted or 810 only those belonging to a particular traffic class. Another is 811 whether various "auxiliary" flows associated with a data channel are 812 counted, such as packets flowing over the G-ACh. Implementations 813 MUST make their supported LM scopes clear to the user, and care must 814 be taken to ensure that the scopes of the channel endpoints agree. 816 2.9.10. Delay Measurement Accuracy 818 The delay measurement procedures described in this document are 819 designed to facilitate hardware-assisted measurement and to function 820 in the same way whether or not such hardware assistance is used. The 821 measurement accuracy will be determined by how closely the transmit 822 and receive timestamps correspond to actual packet departure and 823 arrival times. 825 As noted in Section 2.4, measurement of one-way delay requires clock 826 synchronization between the devices involved, while two-way delay 827 measurement does not involve direct comparison between non-local 828 timestamps and thus has no synchronization requirement. The 829 measurement accuracy will be limited by the quality of the local 830 clock and, in the case of one-way delay measurement, by the quality 831 of the synchonization. 833 2.9.11. Delay Measurement Timestamp Format 835 There are two significant timestamp formats in common use: the 836 timestamp format of the Network Time Protocol (NTP), described in 837 [RFC5905], and the timestamp format used in the IEEE 1588 Precision 838 Time Protocol (PTP) [IEEE1588]. 840 The NTP format has the advantages of wide use and long deployment in 841 the Internet, and was specifically designed to make the computation 842 of timestamp differences as simple and efficient as possible. On the 843 other hand, there is also now a significant deployment of equipment 844 designed to support the PTP format. 846 The approach taken in this document is therefore to include in DM 847 messages fields which identify the timestamp formats used by the two 848 devices involved in a DM operation. This implies that a node 849 attempting to carry out a DM operation may be faced with the problem 850 of computing with and possibly reconciling different timestamp 851 formats. To ensure interoperability it is necessary that support of 852 at least one timestamp format is mandatory. This specification 853 requires the support of the IEEE 1588 PTP format. Timestamp format 854 support requirements are discussed in detail in Section 3.4. 856 3. Message Formats 858 Loss Measurement and Delay Measurement messages flow over the MPLS 859 Generic Associated Channel (G-ACh) [RFC5586]. Thus, a packet 860 containing an LM or DM message contains an MPLS label stack, with the 861 G-ACh Label (GAL) at the bottom of the stack. The GAL is followed by 862 an Associated Channel Header (ACH) which identifies the message type, 863 and the message body follows the ACH. 865 This document defines the following ACH Channel Types: 867 MPLS Direct Packet Loss Measurement (DLM) 868 MPLS Inferred Packet Loss Measurement (ILM) 869 MPLS Packet Delay Measurement (DM) 870 MPLS Direct Packet Loss and Delay Measurement (DLM+DM) 871 MPLS Inferred Packet Loss and Delay Measurement (ILM+DM) 873 The message formats for direct and inferred LM are identical. The 874 formats of the DLM+DM and ILM+DM messages are also identical. 876 For these channel types, the ACH SHALL NOT be followed by the ACH TLV 877 Header defined in [RFC5586]. 879 The fixed-format portion of a message MAY be followed by a block of 880 Type-Length-Value (TLV) fields. The TLV block provides an extensible 881 way of attaching subsidiary information to LM and DM messages. 882 Several such TLV fields are defined below. 884 All integer values for fields defined in this document SHALL be 885 encoded in network byte order. 887 3.1. Loss Measurement Message Format 889 The format of a Loss Measurement message, which follows the 890 Associated Channel Header (ACH), is as follows: 892 0 1 2 3 893 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 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 |Version| Flags | Control Code | Message Length | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | DFlags| OTF | Reserved | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Session Identifier | DS | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Origin Timestamp | 902 | | 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Counter 1 | 905 | | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 . . 908 . . 909 . . 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Counter 4 | 912 | | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 ~ TLV Block ~ 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 Figure 2: Loss Measurement Message Format 919 Reserved fields MUST be set to 0 and ignored upon receipt. The 920 possible values for the remaining fields are as follows. 922 Field Meaning 923 --------------------- ----------------------------------------------- 924 Version Protocol version 925 Flags Message control flags 926 Control Code Code identifying the query or response type 927 Message Length Total length of this message in bytes 928 Data Format Flags Flags specifying the format of message data 929 (DFlags) 930 Origin Timestamp Format of the Origin Timestamp field 931 Format (OTF) 932 Reserved Reserved for future specification 933 Session Identifier Set arbitrarily by the querier 934 Differentiated Differentiated Services Code Point (DSCP) being 935 Services (DS) Field measured 937 Origin Timestamp 64-bit field for query message transmission 938 timestamp 939 Counter 1-4 64-bit fields for LM counter values 940 TLV Block Optional block of Type-Length-Value fields 942 The possible values for these fields are as follows. 944 Version: Currently set to 0. 946 Flags: The format of the Flags field is shown below. 948 +-+-+-+-+ 949 |R|T|0|0| 950 +-+-+-+-+ 952 Loss Measurement Message Flags 954 The meanings of the flag bits are: 956 R: Query/Response indicator. Set to 0 for a Query and 1 for a 957 Response. 959 T: Traffic-class-specific measurement indicator. Set to 1 when 960 the measurement operation is scoped to packets of a particular 961 traffic class (DSCP value), and 0 otherwise. When set to 1, the 962 DS field of the message indicates the measured traffic class. 964 0: Set to 0. 966 Control Code: Set as follows according to whether the message is a 967 Query or a Response as identified by the R flag. 969 For a Query: 971 0x0: In-band Response Requested. Indicates that this query has 972 been sent over a bidirectional channel and the response is 973 expected over the same channel. 975 0x1: Out-of-band Response Requested. Indicates that the 976 response should be sent via an out-of-band channel. 978 0x2: No Response Requested. Indicates that no response to the 979 query should be sent. This mode can be used, for example, if 980 all nodes involved are being controlled by a Network Management 981 System. 983 For a Response: 985 Codes 0x0-0xF are reserved for non-error responses. Error 986 response codes imply that the response does not contain valid 987 measurement data. 989 0x1: Success. Indicates that the operation was successful. 991 0x2: Notification - Data Format Invalid. Indicates that the 992 query was processed but the format of the data fields in this 993 response may be inconsistent. Consequently these data fields 994 MUST NOT be used for measurement. 996 0x3: Notification - Initialization In Progress. Indicates that 997 the query was processed but this response does not contain 998 valid measurement data because the responder's initialization 999 process has not completed. 1001 0x4: Notification - Data Reset Occurred. Indicates that the 1002 query was processed but a reset has recently occurred which may 1003 render the data in this response inconsistent relative to 1004 earlier responses. 1006 0x5: Notification - Resource Temporarily Unavailable. 1007 Indicates that the query was processed but resources were 1008 unavailable to complete the requested measurement, and that 1009 consequently this response does not contain valid measurement 1010 data. 1012 0x10: Error - Unspecified Error. Indicates that the operation 1013 failed for an unspecified reason. 1015 0x11: Error - Unsupported Version. Indicates that the 1016 operation failed because the protocol version supplied in the 1017 query message is not supported. 1019 0x12: Error - Unsupported Control Code. Indicates that the 1020 operation failed because the Control Code requested an 1021 operation that is not available for this channel. 1023 0x13: Error - Unsupported Data Format. Indicates that the 1024 operation failed because the data format specified in the query 1025 is not supported. 1027 0x14: Error - Authentication Failure. Indicates that the 1028 operation failed because the authentication data supplied in 1029 the query was missing or incorrect. 1031 0x15: Error - Invalid Destination Node Identifier. Indicates 1032 that the operation failed because the Destination Node 1033 Identifier supplied in the query is not an identifier of this 1034 node. 1036 0x16: Error - Connection Mismatch. Indicates that the 1037 operation failed because the channel identifier supplied in the 1038 query did not match the channel over which the query was 1039 received. 1041 0x17: Error - Unsupported Mandatory TLV Object. Indicates that 1042 the operation failed because a TLV Object received in the query 1043 and marked as mandatory is not supported. 1045 0x18: Error - Unsupported Query Interval. Indicates that the 1046 operation failed because the query message rate exceeded the 1047 configured threshold. 1049 0x19: Error - Administrative Block. Indicates that the 1050 operation failed because it has been administratively 1051 disallowed. 1053 0x1A: Error - Resource Unavailable. Indicates that the 1054 operation failed because node resources were not available. 1056 0x1B: Error - Resource Released. Indicates that the operation 1057 failed because node resources for this measurement session were 1058 administratively released. 1060 0x1C: Error - Invalid Message. Indicates that the operation 1061 failed because the received query message was malformed. 1063 0x1D: Error - Protocol Error. Indicates that the operation 1064 failed because a protocol error was found in the received query 1065 message. 1067 Message Length: Set to the total length of this message in bytes, 1068 including the Version, Flags, Control Code, and Message Length 1069 fields. 1071 DFlags: The format of the DFlags field is shown below. 1073 +-+-+-+-+ 1074 |X|B|0|0| 1075 +-+-+-+-+ 1077 Loss Measurement Message Flags 1079 The meanings of the DFlags bits are: 1081 X: Extended counter format indicator. Indicates the use of 1082 extended (64-bit) counter values. Initialized to 1 upon creation 1083 (and prior to transmission) of an LM Query and copied from an LM 1084 Query to an LM response. Set to 0 when the LM message is 1085 transmitted or received over an interface that writes 32-bit 1086 counter values. 1088 B: Octet (byte) count. When set to 1, indicates that the Counter 1089 1-4 fields represent octet counts. The octet count applies to all 1090 packets within the LM scope (Section 2.9.9), and the octet count 1091 of a packet sent or received over a channel includes the total 1092 length of that packet (but excludes headers, labels or framing of 1093 the channel itself). When set to 0, indicates that the Counter 1094 1-4 fields represent packet counts. 1096 0: Set to 0. 1098 Origin Timestamp Format: The format of the Origin Timestamp field, as 1099 specified in Section 3.4. 1101 Session Identifier: Set arbitrarily in a query and copied in the 1102 response, if any. This field uniquely identifies a measurement 1103 operation (also called a session) that consists of a sequence of 1104 messages. All messages in the sequence have the same Session 1105 Identifier. 1107 DS: When the T flag is set to 1, this field is set to the DSCP value 1108 [RFC3260] that corresponds to the traffic class being measured. For 1109 MPLS, where the traffic class of a channel is identified by the 1110 three-bit Traffic Class in the channel's LSE [RFC5462], this field 1111 SHOULD be set to the Class Selector Codepoint [RFC2474] that 1112 corresponds to that Traffic Class. When the T flag is set to 0, the 1113 value of this field is arbitrary, and the field can be considered 1114 part of the Session Identifier. 1116 Origin Timestamp: Timestamp recording the transmit time of the query 1117 message. 1119 Counter 1-4: Referring to Section 2.2, when a query is sent from A, 1120 Counter 1 is set to A_TxP and the other counter fields are set to 0. 1121 When the query is received at B, Counter 2 is set to B_RxP. At this 1122 point, B copies Counter 1 to Counter 3 and Counter 2 to Counter 4, 1123 and re-initializes Counter 1 and Counter 2 to 0. When B transmits 1124 the response, Counter 1 is set to B_TxP. When the response is 1125 received at A, Counter 2 is set to A_RxP. 1127 The mapping of counter types such as A_TxP to the counter fields 1-4 1128 is designed to ensure that transmit counter values are always written 1129 at the same fixed offset in the packet, and likewise for receive 1130 counters. This property may be important for hardware processing. 1132 When a 32-bit counter value is written to one of the counter fields, 1133 that value SHALL be written to the low-order 32 bits of the field; 1134 the high-order 32 bits of the field MUST, in this case, be set to 0. 1136 TLV Block: Zero or more TLV fields. 1138 3.2. Delay Measurement Message Format 1140 The format of a Delay Measurement message, which follows the 1141 Associated Channel Header (ACH), is as follows: 1143 0 1 2 3 1144 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 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 |Version| Flags | Control Code | Message Length | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | QTF | RTF | RPTF | Reserved | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | Session Identifier | DS | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | Timestamp 1 | 1153 | | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 . . 1156 . . 1157 . . 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | Timestamp 4 | 1160 | | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 ~ TLV Block ~ 1163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 Figure 3: Delay Measurement Message Format 1167 The meanings of the fields are summarized in the following table. 1169 Field Meaning 1170 --------------------- ----------------------------------------------- 1171 Version Protocol version 1172 Flags Message control flags 1173 Control Code Code identifying the query or response type 1174 Message Length Total length of this message in bytes 1175 QTF Querier timestamp format 1176 RTF Responder timestamp format 1177 RPTF Responder's preferred timestamp format 1178 Reserved Reserved for future specification 1179 Session Identifier Set arbitrarily by the querier 1180 Differentiated Differentiated Services Code Point (DSCP) being 1181 Services (DS) Field measured 1183 Timestamp 1-4 64-bit timestamp values 1184 TLV Block Optional block of Type-Length-Value fields 1186 Reserved fields MUST be set to 0 and ignored upon receipt. The 1187 possible values for the remaining fields are as follows. 1189 Version: Currently set to 0. 1191 Flags: As specified in Section 3.1. The T flag in a DM message is 1192 set to 1. 1194 Control Code: As specified in Section 3.1. 1196 Message Length: Set to the total length of this message in bytes, 1197 including the Version, Flags, Control Code, and Message Length 1198 fields. 1200 Querier Timestamp Format: The format of the timestamp values written 1201 by the querier, as specified in Section 3.4. 1203 Responder Timestamp Format: The format of the timestamp values 1204 written by the responder, as specified in Section 3.4. 1206 Responder's Preferred Timestamp Format: The timestamp format 1207 preferred by the responder, as specified in Section 3.4. 1209 Session Identifier: As specified in Section 3.1. 1211 DS: As specified in Section 3.1. 1213 Timestamp 1-4: Referring to Section 2.4, when a query is sent from A, 1214 Timestamp 1 is set to T1 and the other timestamp fields are set to 0. 1216 When the query is received at B, Timestamp 2 is set to T2. At this 1217 point, B copies Timestamp 1 to Timestamp 3 and Timestamp 2 to 1218 Timestamp 4, and re-initializes Timestamp 1 and Timestamp 2 to 0. 1219 When B transmits the response, Timestamp 1 is set to T3. When the 1220 response is received at A, Timestamp 2 is set to T4. The actual 1221 formats of the timestamp fields written by A and B are indicated by 1222 the Querier Timestamp Format and Responder Timestamp Format fields 1223 respectively. 1225 The mapping of timestamps to the timestamp fields 1-4 is designed to 1226 ensure that transmit timestamps are always written at the same fixed 1227 offset in the packet, and likewise for receive timestamps. This 1228 property is important for hardware processing. 1230 TLV Block: Zero or more TLV fields. 1232 3.3. Combined Loss/Delay Measurement Message Format 1234 The format of a combined Loss and Delay Measurement message, which 1235 follows the Associated Channel Header (ACH), is as follows: 1237 0 1 2 3 1238 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 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 |Version| Flags | Control Code | Message Length | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | DFlags| QTF | RTF | RPTF | Reserved | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | Session Identifier | DS | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | Timestamp 1 | 1247 | | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 . . 1250 . . 1251 . . 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | Timestamp 4 | 1254 | | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | Counter 1 | 1257 | | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 . . 1260 . . 1261 . . 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Counter 4 | 1264 | | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 ~ TLV Block ~ 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 Figure 4: Loss/Delay Measurement Message Format 1271 The fields of this message have the same meanings as the 1272 corresponding fields in the LM and DM message formats, except that 1273 the roles of the OTF and Origin Timestamp fields for LM are here 1274 played by the QTF and Timestamp 1 fields, respectively. 1276 3.4. Timestamp Field Formats 1278 The following timestamp format field values are specified in this 1279 document: 1281 0: Null timestamp format. This value is a placeholder indicating 1282 that the timestamp field does not contain a meaningful timestamp. 1284 1: Sequence number. This value indicates that the timestamp field 1285 is to be viewed as a simple 64-bit sequence number. This provides 1286 a simple solution for applications that do not require a real 1287 absolute timestamp, but only an indication of message ordering; an 1288 example is LM exception detection. 1290 2: Network Time Protocol version 4 64-bit timestamp format 1291 [RFC5905]. This format consists of a 32-bit seconds field 1292 followed by a 32-bit fractional seconds field, so that it can be 1293 regarded as a fixed-point 64-bit quantity. 1295 3: Low-order 64 bits of the IEEE 1588-2008 (1588v2) Precision Time 1296 Protocol timestamp format [IEEE1588]. This truncated format 1297 consists of a 32-bit seconds field followed by a 32-bit 1298 nanoseconds field, and is the same as the IEEE 1588v1 timestamp 1299 format. 1301 Timestamp formats of n < 64 bits in size SHALL be encoded in the 64- 1302 bit timestamp fields specified in this document using the n high- 1303 order bits of the field. The remaining 64 - n low-order bits in the 1304 field SHOULD be set to 0 and MUST be ignored when reading the field. 1306 To ensure that it is possible to find an interoperable mode between 1307 implementations it is necessary to select one timestamp format as the 1308 default. The timestamp format chosen as the default is the truncated 1309 IEEE 1588 PTP format (format code 3 in the list above); this format 1310 MUST be supported. The rationale for this choice is discussed in 1311 Appendix A. Implementations SHOULD also be capable of reading 1312 timestamps written in NTPv4 64-bit format and reconciling them 1313 internally with PTP timestamps for measurement purposes. Support for 1314 other timestamp formats is OPTIONAL. 1316 The implementation MUST make clear which timestamp formats it 1317 supports and the extent of its support for computation with and 1318 reconciliation of different formats for measurement purposes. 1320 3.5. TLV Objects 1322 The TLV Block in LM and DM messages consists of zero or more objects 1323 with the following format: 1325 0 1 2 3 1326 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 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 | Type | Length | Value ~ 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 TLV Format 1333 The Type and Length fields are each 8 bits long, and the Length field 1334 indicates the size in bytes of the Value field, which can therefore 1335 be up to 255 bytes long. 1337 The Type space is divided into Mandatory and Optional subspaces: 1339 Type Range Semantics 1340 -------------- --------- 1341 0-127 Mandatory 1342 128-255 Optional 1344 Upon receipt of a query message including an unrecognized mandatory 1345 TLV object, the recipient MUST respond with an Unsupported Mandatory 1346 TLV Object error code. 1348 The types defined are as follows: 1350 Type Definition 1351 -------------- --------------------------------- 1352 Mandatory 1353 0 Padding - copy in response 1354 1 Return Address 1355 2 Session Query Interval 1356 3 Loopback Request 1357 4-126 Unallocated 1358 127 Experimental use 1360 Optional 1361 128 Padding - do not copy in response 1362 129 Destination Address 1363 130 Source Address 1364 131-254 Unallocated 1365 255 Experimental use 1367 3.5.1. Padding 1369 The two padding objects permit the augmentation of packet size; this 1370 is mainly useful for delay measurement. The type of padding 1371 indicates whether the padding supplied by the querier is to be copied 1372 to, or omitted from, the response. Asymmetrical padding may be 1373 useful when responses are delivered out-of-band or when different 1374 maximum transmission unit sizes apply to the two components of a 1375 bidirectional channel. 1377 More than one padding object MAY be present, in which case they MUST 1378 be contiguous. The Value field of a padding object is arbitrary. 1380 3.5.2. Addressing 1382 The addressing objects have the following format: 1384 0 1 2 3 1385 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 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 | Type | Length | Address Family | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 ~ Address ~ 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 Addressing Object Format 1394 The Address Family field indicates the type of the address, and SHALL 1395 be set to one of the assigned values in the IANA Address Family 1396 Numbers registry. 1398 The Source and Destination address objects indicate the addresses of 1399 the sender and the intended recipient of the message, respectively. 1400 The Source Address of a query message SHOULD be used as the 1401 destination for an out-of-band response unless some other out-of-band 1402 response mechanism has been configured, and unless a Return Address 1403 object is present, in which case the Return Address specifies the 1404 target of the response. The Return Address object MUST NOT appear in 1405 a response. 1407 3.5.3. Loopback Request 1409 The Loopback Request object, when included in a query, indicates a 1410 request that the query message be returned to the sender unmodified. 1411 This object has a Length of 0. 1413 Upon receiving the reflected query message back from the responder, 1414 the querier MUST NOT retransmit the message. Information that 1415 uniquely identifies the original query source, such as a Source 1416 Address object, can be included to enable the querier to 1417 differentiate one of its own loopback queries from a loopback query 1418 initiated by the far end. 1420 This object may be useful, for example, when the querier is 1421 interested only in the round-trip delay metric. In this case no 1422 support for delay measurement is required at the responder at all, 1423 other than the ability to recognize a DM query that includes this 1424 object and return it unmodified. 1426 3.5.4. Session Query Interval 1428 The Value field of the Session Query Interval object is a 32-bit 1429 unsigned integer that specifies a time interval in milliseconds: 1431 0 1 2 3 1432 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 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 | Type | Length | Session Query > 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 < Interval (ms) | 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 Session Query Interval Object Format 1441 This time interval indicates the interval between successive query 1442 messages in a specific measurement session. The purpose of the 1443 Session Query Interval (SQI) object is to enable the querier and 1444 responder of a measurement session to agree on a query rate. The 1445 procedures for handling this object SHALL be as follows: 1447 1. The querier notifies the responder that it wishes to be informed 1448 of the responder's minimum query interval for this session by 1449 including the SQI object in its query messages, with a Value of 1450 0. 1452 2. When the responder receives a query that includes an SQI object 1453 with a Value of 0, the responder includes an SQI object in the 1454 response with the Value set to the minimum query interval it 1455 supports for this session. 1457 3. When the querier receives a response that includes an SQI object, 1458 it selects a query interval for the session that is greater than 1459 or equal to the Value specified in the SQI object and adjusts its 1460 query transmission rate accordingly, including in each subsequent 1461 query an SQI object with a Value equal to the selected query 1462 interval. Once a response to one of these subsequent queries has 1463 been received, the querier infers that the responder has been 1464 apprised of the selected query interval and MAY then stop 1465 including the SQI object in queries associated with this session. 1467 Similar procedures allow the query rate to be changed during the 1468 course of the session by either the querier or the responder. For 1469 example, to inform the querier of a change in the minimum supported 1470 query interval, the responder begins including a corresponding SQI 1471 object in its responses, and the querier adjusts its query rate if 1472 necessary and includes a corresponding SQI object in its queries 1473 until a response is received. 1475 Shorter query intervals (i.e. higher query rates) provide finer 1476 measurement granularity at the expense of additional load on 1477 measurement endpoints and the network; see Section 6 for further 1478 discussion. 1480 4. Operation 1482 4.1. Operational Overview 1484 A loss or delay measurement operation, also called a session, is 1485 controlled by the querier and consists of a sequence of query 1486 messages associated with a particular channel and a common set of 1487 measurement parameters. If the session parameters include a response 1488 request, then the receiving node or nodes will (under normal 1489 conditions) generate a response message for each query message 1490 received, and these responses are also considered part of the 1491 session. All query and response messages in a session carry a common 1492 session identifier. 1494 Measurement sessions are initiated at the discretion of the network 1495 operator and are terminated either at the operator's request or as 1496 the result of an error condition. A session may be as brief as a 1497 single message exchange, for example when a DM query is used by the 1498 operator to "ping" a remote node, or may extend throughout the 1499 lifetime of the channel. 1501 When a session is initiated for which responses are requested, the 1502 querier SHOULD initialize a timer, called the SessionResponseTimeout, 1503 that indicates how long the querier will wait for a response before 1504 abandoning the session and notifying the user that a timeout has 1505 occurred. This timer persists for the lifetime of the session and is 1506 reset each time a response message for the session is received. 1508 When a query message is received that requests a response, a variety 1509 of exceptional conditions may arise that prevent the responder from 1510 generating a response that contains valid measurement data. Such 1511 conditions fall broadly into two classes: transient exceptions from 1512 which recovery is possible, and fatal exceptions that require 1513 termination of the session. When an exception arises, the responder 1514 SHOULD generate a response with an appropriate Notification or Error 1515 control code according as the exception is, respectively, transient 1516 or fatal. When the querier receives an Error response, the session 1517 MUST be terminated and the user informed. 1519 A common example of a transient exception occurs when a new session 1520 is initiated and the responder requires a period of time to become 1521 ready before it can begin providing useful responses. The response 1522 control code corresponding to this situation is Notification - 1523 Initialization In Progress. Typical examples of fatal exceptions are 1524 cases where the querier has requested a type of measurement that the 1525 responder does not support, or where a query message is malformed. 1527 When initiating a session the querier SHOULD employ the Session Query 1528 Interval mechanism (Section 3.5.4) to establish a mutually agreeable 1529 query rate with the responder. Responders SHOULD employ rate- 1530 limiting mechanisms to guard against the possibility of receiving an 1531 excessive quantity of query messages. 1533 4.2. Loss Measurement Procedures 1535 4.2.1. Initiating a Loss Measurement Operation 1537 An LM operation for a particular channel consists of sending a 1538 sequence (LM[1], LM[2], ...) of LM query messages over the channel at 1539 a specific rate and processing the responses received, if any. As 1540 described in Section 2.2, the packet loss associated with the channel 1541 during the operation is computed as a delta between successive 1542 messages; these deltas can be accumulated to obtain a running total 1543 of the packet loss for the channel, or used to derive related metrics 1544 such as the average loss rate. 1546 The query message transmission rate MUST be sufficiently high, given 1547 the LM message counter size (which can be either 32 or 64 bits) and 1548 the speed and minimum packet size of the underlying channel, that the 1549 ambiguity condition noted in Section 2.2 cannot arise. The 1550 implementation SHOULD assume, in evaluating this rate, that the 1551 counter size is 32 bits unless explicitly configured otherwise, or 1552 unless (in the case of a bidirectional channel) all local and remote 1553 interfaces involved in the LM operation are known to be 64-bit- 1554 capable, which can be inferred from the value of the X flag in an LM 1555 response. 1557 4.2.2. Transmitting a Loss Measurement Query 1559 When transmitting an LM Query, the Version field MUST be set to 0. 1560 The R flag MUST be set to 0. The T flag SHALL be set to 1 if, and 1561 only if, the measurement is specific to a particular traffic class, 1562 in which case the DS field SHALL identify that traffic class. 1564 The X flag MUST be set to 1 if the transmitting interface writes 64- 1565 bit LM counters, and otherwise MUST be set to 0 to indicate that 32- 1566 bit counters are written. The B flag SHALL be set to 1 to indicate 1567 that the counter fields contain octet counts, or to 0 to indicate 1568 packet counts. 1570 The Control Code field MUST be set to one of the values for Query 1571 messages listed in Section 3.1; if the channel is unidirectional, 1572 this field MUST NOT be set to 0x0 (Query: in-band response 1573 requested). 1575 The Session Identifier field can be set arbitrarily. 1577 The Origin Timestamp field SHALL be set to the time at which this 1578 message is transmitted, and the Origin Timestamp Format field MUST be 1579 set to indicate its format, according to Section 3.4. 1581 The Counter 1 field SHOULD be set to the total count of units 1582 (packets or octets, according to the B flag) transmitted over the 1583 channel prior to this LM Query, or to 0 if this is the beginning of a 1584 measurement session for which counter data is not yet available. The 1585 Counter 2 field MUST be set to 0. If a response was previously 1586 received in this measurement session, the Counter 1 and Counter 2 1587 fields of the most recent such response MAY be copied to the Counter 1588 3 and Counter 4 fields, respectively, of this query; otherwise, the 1589 Counter 3 and Counter 4 fields MUST be set to 0. 1591 4.2.3. Receiving a Loss Measurement Query 1593 Upon receipt of an LM Query message, the Counter 2 field SHOULD be 1594 set to the total count of units (packets or octets, according to the 1595 B flag) received over the channel prior to this LM Query. If the 1596 receiving interface writes 32-bit LM counters, the X flag MUST be set 1597 to 0. 1599 At this point the LM Query message must be inspected. If the Control 1600 Code field is set to 0x2 (no response requested), an LM Response 1601 message MUST NOT be transmitted. If the Control Code field is set to 1602 0x0 (in-band response requested) or 0x1 (out-of-band response 1603 requested), then an in-band or out-of-band response, respectively, 1604 SHOULD be transmitted unless this has been prevented by an 1605 administrative, security or congestion control mechanism. 1607 In the case of a fatal exception that prevents the requested 1608 measurement from being made, the error SHOULD be reported, either via 1609 a response if one was requested or else as a notification to the 1610 user. 1612 4.2.4. Transmitting a Loss Measurement Response 1614 When constructing a Response to an LM Query, the Version field MUST 1615 be set to 0. The R flag MUST be set to 1. The value of the T flag 1616 MUST be copied from the LM Query. 1618 The X flag MUST be set to 0 if the transmitting interface writes 32- 1619 bit LM counters; otherwise its value MUST be copied from the LM 1620 Query. The B flag MUST be copied from the LM Query. 1622 The Session Identifier, Origin Timestamp, and Origin Timestamp Format 1623 fields MUST be copied from the LM Query. The Counter 1 and Counter 2 1624 fields from the LM Query MUST be copied to the Counter 3 and Counter 1625 4 fields, respectively, of the LM Response. 1627 The Control Code field MUST be set to one of the values for Response 1628 messages listed in Section 3.1. The value 0x10 (Unspecified Error) 1629 SHOULD NOT be used if one of the other more specific error codes is 1630 applicable. 1632 If the response is transmitted in-band, the Counter 1 field SHOULD be 1633 set to the total count of units transmitted over the channel prior to 1634 this LM Response. If the response is transmitted out-of-band, the 1635 Counter 1 field MUST be set to 0. In either case, the Counter 2 1636 field MUST be set to 0. 1638 4.2.5. Receiving a Loss Measurement Response 1640 Upon in-band receipt of an LM Response message, the Counter 2 field 1641 is set to the total count of units received over the channel prior to 1642 this LM Response. If the receiving interface writes 32-bit LM 1643 counters, the X flag is set to 0. (Since the life of the LM message 1644 in the network has ended at this point, it is up to the receiver 1645 whether these final modifications are made to the packet. If the 1646 message is to be forwarded on for external post-processing 1647 (Section 2.9.7) then these modifications MUST be made.) 1649 Upon out-of-band receipt of an LM Response message, the Counter 1 and 1650 Counter 2 fields MUST NOT be used for purposes of loss measurement. 1652 If the Control Code in an LM Response is anything other than 0x1 1653 (Success), the counter values in the response MUST NOT be used for 1654 purposes of loss measurement. If the Control Code indicates an error 1655 condition, or if the response message is invalid, the LM operation 1656 MUST be terminated and an appropriate notification to the user 1657 generated. 1659 4.2.6. Loss Calculation 1661 Calculation of packet loss is carried out according to the procedures 1662 in Section 2.2. The X flag in an LM message informs the device 1663 performing the calculation whether to perform 32-bit or 64-bit 1664 arithmetic. If the flag value is equal to 1, all interfaces involved 1665 in the LM operation have written 64-bit counter values, and 64-bit 1666 arithmetic can be used. If the flag value is equal to 0, at least 1667 one interface involved in the operation has written a 32-bit counter 1668 value, and 32-bit arithmetic is carried out using the low-order 32 1669 bits of each counter value. 1671 Note that the semantics of the X flag allow all devices to 1672 interoperate regardless of their counter size support. Thus, an 1673 implementation MUST NOT generate an error response based on the value 1674 of this flag. 1676 4.2.7. Quality of Service 1678 The TC field of the LSE corresponding to the channel (e.g. LSP) 1679 being measured SHOULD be set to a traffic class equal to or better 1680 than the best TC within the measurement scope to minimize the chance 1681 of out-of-order conditions. 1683 4.2.8. G-ACh Packets 1685 By default, direct LM MUST exclude packets transmitted and received 1686 over the Generic Associated Channel (G-ACh). An implementation MAY 1687 provide the means to alter the direct LM scope to include some or all 1688 G-ACh messages. Care must be taken when altering the LM scope to 1689 ensure that both endpoints are in agreement. 1691 4.2.9. Test Messages 1693 In the case of inferred LM, the packets counted for LM consist of 1694 test messages generated for this purpose, or of some other class of 1695 packets deemed to provide a good proxy for data packets flowing over 1696 the channel. The specification of test protocols and proxy packets 1697 is outside the scope of this document, but some guidelines are 1698 discussed below. 1700 An identifier common to both the test or proxy messages and the LM 1701 messages may be required to make correlation possible. The combined 1702 value of the Session Identifier and DS fields SHOULD be used for this 1703 purpose when possible. That is, test messages in this case will 1704 include a 32-bit field which can carry the value of the combined 1705 Session Identifier + DS field present in LM messages. When TC- 1706 specific LM is conducted, the DS field of the LSE in the label stack 1707 of a test message corresponding to the channel (e.g. LSP) over which 1708 the message is sent MUST correspond to the DS value in the associated 1709 LM messages. 1711 A separate test message protocol SHOULD include a timeout value in 1712 its messages that informs the responder when to discard any state 1713 associated with a specific test. 1715 4.2.10. Message Loss and Packet Misorder Conditions 1717 Because an LM operation consists of a message sequence with state 1718 maintained from one message to the next, LM is subject to the effects 1719 of lost messages and misordered packets in a way that DM is not. 1720 Because this state exists only on the querier, the handling of these 1721 conditions is, strictly speaking, a local matter. This section, 1722 however, presents recommended procedures for handling such 1723 conditions. Note that in the absence of ECMP, packet misordering 1724 within a traffic class is a relatively rare event. 1726 The first kind of anomaly that may occur is that one or more LM 1727 messages may be lost in transit. The effect of such loss is that 1728 when an LM Response is next received at the querier, an unambiguous 1729 interpretation of the counter values it contains may be impossible, 1730 for the reasons described at the end of Section 2.2. Whether this is 1731 so depends on the number of messages lost and the other variables 1732 mentioned in that section, such as the LM message rate and the 1733 channel parameters. 1735 Another possibility is that LM messages are misordered in transit, so 1736 that for instance the response to LM[n] is received prior to the 1737 response to LM[n-1]. A typical implementation will discard the late 1738 response to LM[n-1], so that the effect is the same as the case of a 1739 lost message. 1741 Finally, LM is subject to the possibility that data packets are 1742 misordered relative to LM messages. This condition can result, for 1743 example, in a transmit count of 100 and a corresponding receive count 1744 of 101. The effect here is that the A_TxLoss[n-1,n] value (for 1745 example) for a given measurement interval will appear to be extremely 1746 (if not impossibly) large. The other case, where an LM message 1747 arrives earlier than some of the packets, simply results in those 1748 packets being counted as lost. 1750 An implementation SHOULD identify a threshold value that indicates 1751 the upper bound of lost packets measured in a single computation 1752 beyond which the interval is considered unmeasurable. This is called 1753 the MaxLMIntervalLoss threshold. It is clear that this threshold 1754 should be no higher than the maximum number of packets (or bytes) the 1755 channel is capable of transmitting over the interval, but it may be 1756 lower. Upon encountering an unmeasurable interval, the LM state 1757 (i.e. data values from the last LM message received) SHOULD be 1758 discarded. 1760 With regard to lost LM messages, the MaxLMInterval (see Section 2.2) 1761 indicates the maximum amount of time that can elapse before the LM 1762 state is discarded. If some messages are lost, but a message is 1763 subsequently received within MaxLMInterval, its timestamp or sequence 1764 number will quantify the loss, and it MAY still be used for 1765 measurement, although the measurement interval will in this case be 1766 longer than usual. 1768 If an LM message is received that has a timestamp less than or equal 1769 to the timestamp of the last LM message received, this indicates that 1770 an exception has occurred, and the current interval SHOULD be 1771 considered unmeasurable unless the implementation has some other way 1772 of handling this condition. 1774 4.3. Delay Measurement Procedures 1776 4.3.1. Transmitting a Delay Measurement Query 1778 When transmitting a DM Query, the Version and Reserved fields MUST be 1779 set to 0. The R flag MUST be set to 0, the T flag MUST be set to 1, 1780 and the remaining flag bits MUST be set to 0. 1782 The Control Code field MUST be set to one of the values for Query 1783 messages listed in Section 3.1; if the channel is unidirectional, 1784 this field MUST NOT be set to 0x0 (Query: in-band response 1785 requested). 1787 The Querier Timestamp Format field MUST be set to the timestamp 1788 format used by the querier when writing timestamp fields in this 1789 message; the possible values for this field are listed in 1790 Section 3.4. The Responder Timestamp Format and Responder's 1791 Preferred Timestamp Format fields MUST be set to 0. 1793 The Session Identifier field can be set arbitrarily. The DS field 1794 MUST be set to the traffic class being measured. 1796 The Timestamp 1 field SHOULD be set to the time at which this DM 1797 Query is transmitted, in the format indicated by the Querier 1798 Timestamp Format field. The Timestamp 2 field MUST be set to 0. If 1799 a response was previously received in this measurement session, the 1800 Timestamp 1 and Timestamp 2 fields of the most recent such response 1801 MAY be copied to the Timestamp 3 and Timestamp 4 fields, 1802 respectively, of this query; otherwise, the Timestamp 3 and Timestamp 1803 4 fields MUST be set to 0. 1805 4.3.2. Receiving a Delay Measurement Query 1807 Upon receipt of a DM Query message, the Timestamp 2 field SHOULD be 1808 set to the time at which this DM Query is received. 1810 At this point the DM Query message must be inspected. If the Control 1811 Code field is set to 0x2 (no response requested), a DM Response 1812 message MUST NOT be transmitted. If the Control Code field is set to 1813 0x0 (in-band response requested) or 0x1 (out-of-band response 1814 requested), then an in-band or out-of-band response, respectively, 1815 SHOULD be transmitted unless this has been prevented by an 1816 administrative, security or congestion control mechanism. 1818 In the case of a fatal exception that prevents the requested 1819 measurement from being made, the error SHOULD be reported, either via 1820 a response if one was requested or else as a notification to the 1821 user. 1823 4.3.3. Transmitting a Delay Measurement Response 1825 When constructing a Response to a DM Query, the Version and Reserved 1826 fields MUST be set to 0. The R flag MUST be set to 1, the T flag 1827 MUST be set to 1, and the remaining flag bits MUST be set to 0. 1829 The Session Identifier and Querier Timestamp Format (QTF) fields MUST 1830 be copied from the DM Query. The Timestamp 1 and Timestamp 2 fields 1831 from the DM Query MUST be copied to the Timestamp 3 and Timestamp 4 1832 fields, respectively, of the DM Response. 1834 The Responder Timestamp Format (RTF) field MUST be set to the 1835 timestamp format used by the responder when writing timestamp fields 1836 in this message, i.e. Timestamp 4 and (if applicable) Timestamp 1; 1837 the possible values for this field are listed in Section 3.4. 1838 Furthermore, the RTF field MUST be set equal either to the QTF or the 1839 RPTF field. See Section 4.3.5 for guidelines on selection of the 1840 value for this field. 1842 The Responder's Preferred Timestamp Format (RPTF) field MUST be set 1843 to one of the values listed in Section 3.4 and SHOULD be set to 1844 indicate the timestamp format with which the responder can provide 1845 the best accuracy for purposes of delay measurement. 1847 The Control Code field MUST be set to one of the values for Response 1848 messages listed in Section 3.1. The value 0x10 (Unspecified Error) 1849 SHOULD NOT be used if one of the other more specific error codes is 1850 applicable. 1852 If the response is transmitted in-band, the Timestamp 1 field SHOULD 1853 be set to the time at which this DM Response is transmitted. If the 1854 response is transmitted out-of-band, the Timestamp 1 field MUST be 1855 set to 0. In either case, the Timestamp 2 field MUST be set to 0. 1857 If the response is transmitted in-band and the Control Code in the 1858 message is 0x1 (Success), then the Timestamp 1 and Timestamp 4 fields 1859 MUST have the same format, which will be the format indicated in the 1860 Responder Timestamp Format field. 1862 4.3.4. Receiving a Delay Measurement Response 1864 Upon in-band receipt of a DM Response message, the Timestamp 2 field 1865 is set to the time at which this DM Response is received. (Since the 1866 life of the DM message in the network has ended at this point, it is 1867 up to the receiver whether this final modification is made to the 1868 packet. If the message is to be forwarded on for external post- 1869 processing (Section 2.9.7) then these modifications MUST be made.) 1871 Upon out-of-band receipt of a DM Response message, the Timestamp 1 1872 and Timestamp 2 fields MUST NOT be used for purposes of delay 1873 measurement. 1875 If the Control Code in a DM Response is anything other than 0x1 1876 (Success), the timestamp values in the response MUST NOT be used for 1877 purposes of delay measurement. If the Control Code indicates an 1878 error condition, or if the response message is invalid, the DM 1879 operation MUST be terminated and an appropriate notification to the 1880 user generated. 1882 4.3.5. Timestamp Format Negotiation 1884 In case either the querier or the responder in a DM transaction is 1885 capable of supporting multiple timestamp formats, it is desirable to 1886 determine the optimal format for purposes of delay measurement on a 1887 particular channel. The procedures for making this determination 1888 SHALL be as follows. 1890 Upon sending an initial DM Query over a channel, the querier sets the 1891 Querier Timestamp Format (QTF) field to its preferred timestamp 1892 format. 1894 Upon receiving any DM Query message, the responder determines whether 1895 it is capable of writing timestamps in the format specified by the 1896 QTF field. If so, the Responder Timestamp Format (RTF) field is set 1897 equal to the QTF field. If not, the RTF field is set equal to the 1898 Responder's Preferred Timestamp Format (RPTF) field. 1900 The process of changing from one timestamp format to another at the 1901 responder may result in the Timestamp 1 and Timestamp 4 fields in an 1902 in-band DM Response having different formats. If this is the case, 1903 the Control Code in the response MUST NOT be set to 0x1 (Success). 1904 Unless an error condition has occurred, the Control Code MUST be set 1905 to 0x2 (Notification - Data Format Invalid). 1907 Upon receiving a DM Response, the querier knows from the RTF field in 1908 the message whether the responder is capable of supporting its 1909 preferred timestamp format: if it is, the RTF will be equal to the 1910 QTF. The querier also knows the responder's preferred timestamp 1911 format from the RPTF field. The querier can then decide whether to 1912 retain its current QTF or to change it and repeat the negotiation 1913 procedures. 1915 4.3.5.1. Single-Format Procedures 1917 When an implementation supports only one timestamp format, the 1918 procedures above reduce to the following simple behavior: 1920 o All DM Queries are transmitted with the same QTF; 1922 o All DM Responses are transmitted with the same RTF, and the RPTF 1923 is always set equal to the RTF; 1925 o All DM Responses received with RTF not equal to QTF are discarded; 1927 o On a unidirectional channel, all DM Queries received with QTF not 1928 equal to the supported format are discarded. 1930 4.3.6. Quality of Service 1932 The TC field of the LSE corresponding to the channel (e.g. LSP) 1933 being measured MUST be set to the value that corresponds to the DS 1934 field in the DM message. 1936 4.4. Combined Loss/Delay Measurement Procedures 1938 The combined LM/DM message defined in Section 3.3 allows loss and 1939 delay measurement to be carried out simultaneously. This message 1940 SHOULD be treated as an LM message which happens to carry additional 1941 timestamp data, with the timestamp fields processed as per delay 1942 measurement procedures. 1944 5. Implementation Disclosure Requirements 1946 This section summarizes the requirements placed on implementations 1947 for capabilities disclosure. The purpose of these requirements is to 1948 ensure that end users have a clear understanding of implementation 1949 capabilities and characteristics that have a direct impact on how 1950 loss and delay measurement mechanisms function in specific 1951 situations. Implementations are REQUIRED to state: 1953 o METRICS: Which of the following metrics are supported: packet 1954 loss, packet throughput, octet loss, octet throughput, average 1955 loss rate, one-way delay, round-trip delay, two-way channel delay, 1956 packet delay variation. 1958 o MP-LOCATION: The location of loss and delay measurement points 1959 with respect to other stages of packet processing, such as 1960 queuing. 1962 o CHANNEL-TYPES: The types of channels for which LM and DM are 1963 supported, including LSP types, pseudowires, and sections (links). 1965 o QUERY-RATE: The minimum supported query intervals for LM and DM 1966 sessions, both in the querier and responder roles. 1968 o LOOP: Whether loopback measurement (Section 2.8) is supported. 1970 o LM-TYPES: Whether direct or inferred LM is supported, and for the 1971 latter, which test protocols or proxy message types are supported. 1973 o LM-COUNTERS: Whether 64-bit counters are supported. 1975 o LM-ACCURACY: The expected measurement accuracy levels for the 1976 supported forms of LM, and the expected impact of exception 1977 conditions such as lost and misordered messages. 1979 o LM-SYNC: The implementation's behavior in regard to the 1980 synchronization conditions discussed in Section 2.9.8. 1982 o LM-SCOPE: The supported LM scopes (Section 2.9.9 and 1983 Section 4.2.8). 1985 o DM-ACCURACY: The expected measurement accuracy levels for the 1986 supported forms of DM. 1988 o DM-TS-FORMATS: The supported timestamp formats and the extent of 1989 support for computation with and reconciliation of different 1990 formats. 1992 6. Congestion Considerations 1994 An MPLS network may be traffic-engineered in such a way that the 1995 bandwidth required both for client traffic and for control, 1996 management and OAM traffic is always available. The following 1997 congestion considerations therefore apply only when this is not the 1998 case. 2000 The proactive generation of Loss Measurement and Delay Measurement 2001 messages for purposes of monitoring the performance of an MPLS 2002 channel naturally results in a degree of additional load placed on 2003 both the network and the terminal nodes of the channel. When 2004 configuring such monitoring, operators should be mindful of the 2005 overhead involved and should choose transmit rates that do not stress 2006 network resources unduly; such choices must be informed by the 2007 deployment context. In case of slower links or lower-speed devices, 2008 for example, lower Loss Measurement message rates can be chosen, up 2009 to the limits noted at the end of Section 2.2. 2011 In general, lower measurement message rates place less load on the 2012 network at the expense of reduced granularity. For delay measurement 2013 this reduced granularity translates to a greater possibility that the 2014 delay associated with a channel temporarily exceeds the expected 2015 threshold without detection. For loss measurement, it translates to 2016 a larger gap in loss information in case of exceptional circumstances 2017 such as lost LM messages or misordered packets. 2019 When carrying out a sustained measurement operation such as an LM 2020 operation or continuous pro-active DM operation, the querier SHOULD 2021 take note of the number of lost measurement messages (queries for 2022 which a response is never received) and set a corresponding 2023 Measurement Message Loss Threshold. If this threshold is exceeded, 2024 the measurement operation SHOULD be suspended so as not to exacerbate 2025 the possible congestion condition. This suspension SHOULD be 2026 accompanied by an appropriate notification to the user so that the 2027 condition can be investigated and corrected. 2029 From the receiver perspective, the main consideration is the 2030 possibility of receiving an excessive quantity of measurement 2031 messages. An implementation SHOULD employ a mechanism such as rate- 2032 limiting to guard against the effects of this case. 2034 7. Manageability Considerations 2036 The measurement protocols described in this document are intended to 2037 serve as infrastructure to support a wide range of higher-level 2038 monitoring and diagnostic applications, from simple command-line 2039 diagnostic tools to comprehensive network performance monitoring and 2040 analysis packages. The specific mechanisms and considerations for 2041 protocol configuration, initialization and reporting thus depend on 2042 the nature of the application. 2044 In the case of on-demand diagnostics, the diagnostic application may 2045 provide parameters such as the measurement type, the channel, the 2046 query rate, and the test duration when initiating the diagnostic; 2047 results and exception conditions are then reported directly to the 2048 application. The system may discard the statistics accumulated 2049 during the test after the results have been reported, or retain them 2050 to provide a historical measurement record. 2052 Alternatively, measurement configuration may be supplied as part of 2053 the channel configuration itself in order to support continuous 2054 monitoring of the channel's performance characteristics. In this 2055 case the configuration will typically include quality thresholds 2056 depending on the service-level agreement, the crossing of which will 2057 trigger warnings or alarms, and result reporting and exception 2058 notification will be integrated into the system-wide network 2059 management and reporting framework. 2061 8. Security Considerations 2063 This document describes procedures for the measurement of performance 2064 metrics over a pre-existing MPLS path (a pseudowire, LSP, or 2065 section). As such it assumes that a node involved in a measurement 2066 operation has previously verified the integrity of the path and the 2067 identity of the far end using existing MPLS mechanisms such as 2068 Bidirectional Forwarding Detection (BFD) [RFC5884]; tools, 2069 techniques, and considerations for securing MPLS paths are discussed 2070 in detail in [RFC5920]. 2072 When such mechanisms are not available, and where security of the 2073 measurement operation is a concern, reception of Generic Associated 2074 Channel messages with the Channel Types specified in this document 2075 SHOULD be disabled. Implementations MUST provide the ability to 2076 disable these protocols on a per-Channel-Type basis. 2078 Even when the identity of the far end has been verified, the 2079 measurement protocols remain vulnerable to injection and man-in-the- 2080 middle attacks. The impact of such an attack would be to compromise 2081 the quality of performance measurements on the affected path. An 2082 attacker positioned to disrupt these measurements is, however, 2083 capable of causing much greater damage by disrupting far more 2084 critical elements of the network such as the network control plane or 2085 user traffic flows. A disruption of the measurement protocols would 2086 at worst interfere with the monitoring of the performance aspects of 2087 the service level agreement associated with the path; the existence 2088 of such a disruption would imply that a much more serious breach of 2089 basic path integrity had already occurred. 2091 Such attacks can be mitigated if desired by performing basic 2092 validation and sanity checks, at the querier, of the counter or 2093 timestamp fields in received measurement response messages. The 2094 minimal state associated with these protocols also limits the extent 2095 of measurement disruption that can be caused by a corrupt or invalid 2096 message to a single query/response cycle. 2098 Cryptographic mechanisms capable of signing or encrypting the 2099 contents of the measurement packets without degrading the measurement 2100 performance are not currently available. In light of the preceding 2101 discussion, the absence of such cryptographic mechanisms does not 2102 raise significant security issues. 2104 Users concerned with the security of out-of-band responses over IP 2105 networks SHOULD employ suitable security mechanisms such as IPsec 2106 [RFC4301] to protect the integrity of the return path. 2108 9. IANA Considerations 2110 This document makes the following requests of IANA: 2112 o Allocation of Channel Types in the PW Associated Channel Type 2113 registry 2115 o Creation of a Measurement Timestamp Type registry 2117 o Creation of an MPLS Loss/Delay Measurement Control Code registry 2119 o Creation of an MPLS Loss/Delay Measurement Type-Length-Value (TLV) 2120 Object registry 2122 9.1. Allocation of PW Associated Channel Types 2124 As per the IANA considerations in [RFC5586], IANA is requested to 2125 allocate the following Channel Types in the PW Associated Channel 2126 Type registry: 2128 Value Description TLV Follows Reference 2129 ----- -------------------------------------- ----------- ------------ 2130 TBD MPLS Direct Packet Loss Measurement No (this draft) 2131 (DLM) 2132 TBD MPLS Inferred Packet Loss Measurement No (this draft) 2133 (ILM) 2134 TBD MPLS Packet Delay Measurement (DM) No (this draft) 2135 TBD MPLS Direct Packet Loss and Delay No (this draft) 2136 Measurement (DLM+DM) 2137 TBD MPLS Inferred Packet Loss and Delay No (this draft) 2138 Measurement (ILM+DM) 2140 The values marked TBD are to be allocated by IANA as appropriate. 2142 9.2. Creation of Measurement Timestamp Type Registry 2144 IANA is requested to create a new Measurement Timestamp Type 2145 registry, with format and initial allocations as follows: 2147 Type Description Size in bits Reference 2148 ---- -------------------------------------- ------------ ------------ 2149 0 Null Timestamp 64 (this draft) 2150 1 Sequence Number 64 (this draft) 2151 2 Network Time Protocol version 4 64-bit 64 (this draft) 2152 Timestamp 2153 3 Truncated IEEE 1588v2 PTP Timestamp 64 (this draft) 2155 The range of the Type field is 0-15. 2157 The allocation policy for this registry is IETF Review. 2159 9.3. Creation of MPLS Loss/Delay Measurement Control Code Registry 2161 IANA is requested to create a new MPLS Loss/Delay Measurement Control 2162 Code registry. This registry is divided into two separate parts, one 2163 for Query Codes and the other for Response Codes, with formats and 2164 initial allocations as follows: 2166 Query Codes 2168 Code Description Reference 2169 ---- ------------------------------ ------------ 2170 0x0 In-band Response Requested (this draft) 2171 0x1 Out-of-band Response Requested (this draft) 2172 0x2 No Response Requested (this draft) 2173 Response Codes 2175 Code Description Reference 2176 ---- ----------------------------------- ------------ 2177 0x0 Reserved (this draft) 2178 0x1 Success (this draft) 2179 0x2 Data Format Invalid (this draft) 2180 0x3 Initialization In Progress (this draft) 2181 0x4 Data Reset Occurred (this draft) 2182 0x5 Resource Temporarily Unavailable (this draft) 2183 0x10 Unspecified Error (this draft) 2184 0x11 Unsupported Version (this draft) 2185 0x12 Unsupported Control Code (this draft) 2186 0x13 Unsupported Data Format (this draft) 2187 0x14 Authentication Failure (this draft) 2188 0x15 Invalid Destination Node Identifier (this draft) 2189 0x16 Connection Mismatch (this draft) 2190 0x17 Unsupported Mandatory TLV Object (this draft) 2191 0x18 Unsupported Query Interval (this draft) 2192 0x19 Administrative Block (this draft) 2193 0x1A Resource Unavailable (this draft) 2194 0x1B Resource Released (this draft) 2195 0x1C Invalid Message (this draft) 2196 0x1D Protocol Error (this draft) 2198 IANA is also requested to indicate that the values 0x0 - 0xF in the 2199 Response Code section are reserved for non-error response codes. 2201 The range of the Code field is 0 - 255. 2203 The allocation policy for this registry is IETF Review. 2205 9.4. Creation of MPLS Loss/Delay Measurement TLV Object Registry 2207 IANA is requested to create a new MPLS Loss/Delay Measurement TLV 2208 Object registry, with format and initial allocations as follows: 2210 Type Description Reference 2211 ---- --------------------------------- ------------ 2212 0 Padding - copy in response (this draft) 2213 1 Return Address (this draft) 2214 2 Session Query Interval (this draft) 2215 3 Loopback Request (this draft) 2216 127 Experimental use (this draft) 2217 128 Padding - do not copy in response (this draft) 2218 129 Destination Address (this draft) 2219 130 Source Address (this draft) 2220 255 Experimental use (this draft) 2222 IANA is also requested to indicate that Types 0-127 are classified as 2223 Mandatory, and that Types 128-255 are classified as Optional. 2225 The range of the Type field is 0 - 255. 2227 The allocation policy for this registry is IETF Review. 2229 10. Acknowledgments 2231 The authors wish to thank the many participants of the MPLS working 2232 group who provided detailed review and feedback on this document. 2233 The authors offer special thanks to Alexander Vainshtein, Loa 2234 Andersson, and Hiroyuki Takagi for many helpful thoughts and 2235 discussions, to Linda Dunbar for the idea of using LM messages for 2236 throughput measurement, and to Ben Niven-Jenkins, Marc Lasserre, and 2237 Ben Mack-Crane for their valuable comments. 2239 11. References 2241 11.1. Normative References 2243 [IEEE1588] 2244 IEEE, "1588-2008 IEEE Standard for a Precision Clock 2245 Synchronization Protocol for Networked Measurement and 2246 Control Systems", March 2008. 2248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2249 Requirement Levels", BCP 14, RFC 2119, March 1997. 2251 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2252 "Definition of the Differentiated Services Field (DS 2253 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2254 December 1998. 2256 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2257 Label Switching Architecture", RFC 3031, January 2001. 2259 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 2260 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 2261 Protocol Label Switching (MPLS) Support of Differentiated 2262 Services", RFC 3270, May 2002. 2264 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 2265 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 2266 Class" Field", RFC 5462, February 2009. 2268 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 2269 Associated Channel", RFC 5586, June 2009. 2271 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 2272 Time Protocol Version 4: Protocol and Algorithms 2273 Specification", RFC 5905, June 2010. 2275 11.2. Informative References 2277 [I-D.ietf-mpls-tp-loss-delay-profile] 2278 Frost, D. and S. Bryant, "A Packet Loss and Delay 2279 Measurement Profile for MPLS-based Transport Networks", 2280 draft-ietf-mpls-tp-loss-delay-profile-03 (work in 2281 progress), April 2011. 2283 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2284 Delay Metric for IPPM", RFC 2679, September 1999. 2286 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2287 Packet Loss Metric for IPPM", RFC 2680, September 1999. 2289 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 2290 Delay Metric for IPPM", RFC 2681, September 1999. 2292 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2293 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2294 Tunnels", RFC 3209, December 2001. 2296 [RFC3260] Grossman, D., "New Terminology and Clarifications for 2297 Diffserv", RFC 3260, April 2002. 2299 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 2300 Edge (PWE3) Architecture", RFC 3985, March 2005. 2302 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2303 Internet Protocol", RFC 4301, December 2005. 2305 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 2306 Zekauskas, "A One-way Active Measurement Protocol 2307 (OWAMP)", RFC 4656, September 2006. 2309 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 2310 Cost Multipath Treatment in MPLS Networks", BCP 128, 2311 RFC 4928, June 2007. 2313 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 2314 Specification", RFC 5036, October 2007. 2316 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 2317 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 2318 RFC 5357, October 2008. 2320 [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation 2321 Applicability Statement", RFC 5481, March 2009. 2323 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 2324 "Bidirectional Forwarding Detection (BFD) for MPLS Label 2325 Switched Paths (LSPs)", RFC 5884, June 2010. 2327 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 2328 Networks", RFC 5920, July 2010. 2330 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 2331 Berger, "A Framework for MPLS in Transport Networks", 2332 RFC 5921, July 2010. 2334 [RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport 2335 Profile Data Plane Architecture", RFC 5960, August 2010. 2337 [Y.1731] ITU-T Recommendation Y.1731, "OAM Functions and Mechanisms 2338 for Ethernet based Networks", February 2008. 2340 Appendix A. Default Timestamp Format Rationale 2342 This document initially proposed the Network Time Protocol (NTP) 2343 timestamp format as the mandatory default, as this is the normal 2344 default timestamp in IETF protocols and thus would seem the "natural" 2345 choice. However a number of considerations have led instead to the 2346 specification of the truncated IEEE 1588 Precision Time Protocol 2347 (PTP) timestamp as the default. NTP has not gained traction in 2348 industry as the protocol of choice for high quality timing 2349 infrastructure, whilst IEEE 1588 PTP has become the de facto time 2350 transfer protocol in networks which are specially engineered to 2351 provide high accuracy time distribution service. The PTP timestamp 2352 format is also the ITU-T format of choice for packet transport 2353 networks, which may rely on MPLS protocols. Applications such as 2354 one-way delay measurement need the best time service available, and 2355 converting between the NTP and PTP timestamp formats is not a trivial 2356 transformation, particularly when it is required that this be done in 2357 real time without loss of accuracy. 2359 The truncated IEEE 1588 PTP format specified in this document is 2360 considered to provide a more than adequate wrap time and greater time 2361 resolution than it is expected will be needed for the operational 2362 lifetime of this protocol. By truncating the timestamp at both the 2363 high and low order bits, the protocol achieves a worthwhile reduction 2364 in system resources. 2366 Authors' Addresses 2368 Dan Frost 2369 Cisco Systems 2371 Email: danfrost@cisco.com 2373 Stewart Bryant 2374 Cisco Systems 2376 Email: stbryant@cisco.com