idnits 2.17.00 (12 Aug 2021) /tmp/idnits53270/draft-ietf-mpls-loss-delay-03.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 899 has weird spacing: '...) Field meas...' == Line 1140 has weird spacing: '...) Field meas...' -- The document date (June 1, 2011) is 4007 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 1496 -- Looks like a reference, but probably isn't: '2' on line 1496 -- Looks like a reference, but probably isn't: '3' on line 372 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1588' == Outdated reference: draft-ietf-mpls-tp-loss-delay-profile has been published as RFC 6375 -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 6 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: December 3, 2011 June 1, 2011 7 Packet Loss and Delay Measurement for MPLS Networks 8 draft-ietf-mpls-loss-delay-03 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 December 3, 2011. 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 . . . . . . . . . . . . . . . . . 5 64 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 65 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.1. Basic Bidirectional Measurement . . . . . . . . . . . . . 6 67 2.2. Packet Loss Measurement . . . . . . . . . . . . . . . . . 7 68 2.3. Throughput Measurement . . . . . . . . . . . . . . . . . . 9 69 2.4. Delay Measurement . . . . . . . . . . . . . . . . . . . . 10 70 2.5. Delay Variation Measurement . . . . . . . . . . . . . . . 11 71 2.6. Unidirectional Measurement . . . . . . . . . . . . . . . . 12 72 2.7. Dyadic Measurement . . . . . . . . . . . . . . . . . . . . 12 73 2.8. Loopback Measurement . . . . . . . . . . . . . . . . . . . 13 74 2.9. Measurement Considerations . . . . . . . . . . . . . . . . 13 75 2.9.1. Types of Channels . . . . . . . . . . . . . . . . . . 13 76 2.9.2. Quality of Service . . . . . . . . . . . . . . . . . . 13 77 2.9.3. Measurement Point Location . . . . . . . . . . . . . . 14 78 2.9.4. Equal Cost Multipath . . . . . . . . . . . . . . . . . 14 79 2.9.5. Intermediate Nodes . . . . . . . . . . . . . . . . . . 14 80 2.9.6. Different Transmit and Receive Interfaces . . . . . . 15 81 2.9.7. External Post-Processing . . . . . . . . . . . . . . . 15 82 2.9.8. Loss Measurement Modes . . . . . . . . . . . . . . . . 16 83 2.9.9. Loss Measurement Scope . . . . . . . . . . . . . . . . 17 84 2.9.10. Delay Measurement Accuracy . . . . . . . . . . . . . . 17 85 2.9.11. Delay Measurement Timestamp Format . . . . . . . . . . 17 86 3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 18 87 3.1. Loss Measurement Message Format . . . . . . . . . . . . . 19 88 3.2. Delay Measurement Message Format . . . . . . . . . . . . . 24 89 3.3. Combined Loss/Delay Measurement Message Format . . . . . . 26 90 3.4. Timestamp Field Formats . . . . . . . . . . . . . . . . . 27 91 3.5. TLV Objects . . . . . . . . . . . . . . . . . . . . . . . 28 92 3.5.1. Padding . . . . . . . . . . . . . . . . . . . . . . . 29 93 3.5.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 30 94 3.5.3. Loopback Request . . . . . . . . . . . . . . . . . . . 30 95 3.5.4. Session Query Interval . . . . . . . . . . . . . . . . 31 96 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 32 97 4.1. Operational Overview . . . . . . . . . . . . . . . . . . . 32 98 4.2. Loss Measurement Procedures . . . . . . . . . . . . . . . 33 99 4.2.1. Initiating a Loss Measurement Operation . . . . . . . 33 100 4.2.2. Transmitting a Loss Measurement Query . . . . . . . . 33 101 4.2.3. Receiving a Loss Measurement Query . . . . . . . . . . 34 102 4.2.4. Transmitting a Loss Measurement Response . . . . . . . 34 103 4.2.5. Receiving a Loss Measurement Response . . . . . . . . 35 104 4.2.6. Loss Calculation . . . . . . . . . . . . . . . . . . . 35 105 4.2.7. Quality of Service . . . . . . . . . . . . . . . . . . 36 106 4.2.8. G-ACh Packets . . . . . . . . . . . . . . . . . . . . 36 107 4.2.9. Test Messages . . . . . . . . . . . . . . . . . . . . 36 108 4.2.10. Message Loss and Packet Misorder Conditions . . . . . 37 109 4.3. Delay Measurement Procedures . . . . . . . . . . . . . . . 38 110 4.3.1. Transmitting a Delay Measurement Query . . . . . . . . 38 111 4.3.2. Receiving a Delay Measurement Query . . . . . . . . . 38 112 4.3.3. Transmitting a Delay Measurement Response . . . . . . 39 113 4.3.4. Receiving a Delay Measurement Response . . . . . . . . 40 114 4.3.5. Timestamp Format Negotiation . . . . . . . . . . . . . 40 115 4.3.6. Quality of Service . . . . . . . . . . . . . . . . . . 41 116 4.4. Combined Loss/Delay Measurement Procedures . . . . . . . . 41 117 5. Implementation Disclosure Requirements . . . . . . . . . . . . 41 118 6. Congestion Considerations . . . . . . . . . . . . . . . . . . 42 119 7. Security Considerations . . . . . . . . . . . . . . . . . . . 43 120 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 121 8.1. Allocation of PW Associated Channel Types . . . . . . . . 44 122 8.2. Creation of Measurement Timestamp Type Registry . . . . . 45 123 8.3. Creation of MPLS Loss/Delay Measurement Control Code 124 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 45 125 8.4. Creation of MPLS Loss/Delay Measurement TLV Object 126 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 46 127 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 128 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 129 10.1. Normative References . . . . . . . . . . . . . . . . . . . 47 130 10.2. Informative References . . . . . . . . . . . . . . . . . . 48 131 Appendix A. Default Timestamp Format Rationale . . . . . . . . . 49 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 134 1. Introduction 136 Many service provider service level agreements (SLAs) depend on the 137 ability to measure and monitor performance metrics for packet loss 138 and one-way and two-way delay, as well as related metrics such as 139 delay variation and channel throughput. This measurement capability 140 also provides operators with greater visibility into the performance 141 characteristics of their networks, thereby facilitating planning, 142 troubleshooting, and evaluation. This document specifies protocol 143 mechanisms to enable the efficient and accurate measurement of these 144 performance metrics in MPLS networks. 146 This document specifies two closely-related protocols, one for packet 147 loss measurement (LM) and one for packet delay measurement (DM). 148 These protocols have the following characteristics and capabilities: 150 o The LM and DM protocols are intended to be simple and to support 151 efficient hardware processing. 153 o The LM and DM protocols operate over the MPLS Generic Associated 154 Channel (G-ACh) [RFC5586] and support measurement of loss, delay, 155 and related metrics over Label Switched Paths (LSPs), pseudowires, 156 and MPLS sections (links). 158 o The LM and DM protocols are applicable to the LSPs, pseudowires, 159 and sections of networks based on the MPLS Transport Profile 160 (MPLS-TP), because the MPLS-TP is based on a standard MPLS data 161 plane. The MPLS-TP is defined and described in [RFC5921], and 162 MPLS-TP LSPs, pseudowires, and sections are discussed in detail in 163 [RFC5960]. A profile describing the minimal functional subset of 164 the LM and DM protocols in the MPLS-TP context is provided in 165 [I-D.ietf-mpls-tp-loss-delay-profile]. 167 o The LM and DM protocols can be used both for continuous/proactive 168 and selective/on-demand measurement. 170 o The LM and DM protocols use a simple query/response model for 171 bidirectional measurement that allows a single node - the querier 172 - to measure the loss or delay in both directions. 174 o The LM and DM protocols use query messages for unidirectional loss 175 and delay measurement. The measurement can either be carried out 176 at the downstream node(s) or at the querier if an out-of-band 177 return path is available. 179 o The LM and DM protocols do not require that the transmit and 180 receive interfaces be the same when performing bidirectional 181 measurement. 183 o The DM protocol is stateless. 185 o The LM protocol is "almost" stateless: loss is computed as a delta 186 between successive messages, and thus the data associated with the 187 last message received must be retained. 189 o The LM protocol can perform two distinct kinds of loss 190 measurement: it can measure the loss of specially generated test 191 messages in order to infer the approximate data-plane loss level 192 (inferred measurement); or it can directly measure data-plane 193 packet loss (direct measurement). Direct measurement provides 194 perfect loss accounting, but may require specialized hardware 195 support and is only applicable to some LSP types. Inferred 196 measurement provides only approximate loss accounting but is 197 generally applicable. 199 The direct LM method is also known as "frame-based" in the context 200 of Ethernet transport networks [Y.1731]. Inferred LM is a 201 generalization of the "synthetic" measurement approach currently 202 in development for Ethernet networks, in the sense that it allows 203 test messages to be decoupled from measurement messages. 205 o The LM protocol supports measurement in terms of both packet 206 counts and octet counts. 208 o The LM protocol supports both 32-bit and 64-bit counters. 210 o The LM protocol can be used to measure channel throughput as well 211 as packet loss. 213 o The DM protocol supports multiple timestamp formats, and provides 214 a simple means for the two endpoints of a bidirectional connection 215 to agree on a preferred format. This procedure reduces to a 216 triviality for implementations supporting only a single timestamp 217 format. 219 o The DM protocol supports varying the measurement message size in 220 order to measure delays associated with different packet sizes. 222 1.1. Applicability and Scope 224 This document specifies measurement procedures and protocol messages 225 that are intended to be applicable in a wide variety of 226 circumstances, and amenable to implementation by a wide range of 227 hardware- and software-based measurement systems. As such, it does 228 not attempt to mandate measurement quality levels or analyze specific 229 end-user applications. 231 Although the procedures in this document are presented in the context 232 of MPLS, they have no essential dependence on MPLS and generalize 233 easily to other types of packet networks. Such generalizations are, 234 however, outside the scope of this document. 236 1.2. Terminology 238 Term Definition 239 ----- ------------------------------------------- 240 ACH Associated Channel Header 241 DM Delay Measurement 242 ECMP Equal Cost Multipath 243 G-ACh Generic Associated Channel 244 LM Loss Measurement 245 LSE Label Stack Entry 246 LSP Label Switched Path 247 NTP Network Time Protocol 248 OAM Operations, Administration, and Maintenance 249 PTP Precision Time Protocol 250 TC Traffic Class 252 2. Overview 254 This section begins with a summary of the basic methods used for the 255 bidirectional measurement of packet loss and delay. These 256 measurement methods are then described in detail. Finally a list of 257 practical considerations are discussed that may come into play to 258 inform or modify these simple procedures. This section is limited to 259 theoretical discussion; for protocol specifics the reader is referred 260 to Section 3 and Section 4. 262 2.1. Basic Bidirectional Measurement 264 The following figure shows the reference scenario. 266 T1 T2 267 +-------+/ Query \+-------+ 268 | | - - - - - - - - ->| | 269 | A |===================| B | 270 | |<- - - - - - - - - | | 271 +-------+\ Response /+-------+ 272 T4 T3 274 Figure 1 276 The figure shows a bidirectional channel between two nodes, A and B, 277 and illustrates the temporal reference points T1-T4 associated with a 278 measurement operation that takes place at A. The operation consists 279 of A sending a query message to B, and B sending back a response. 280 Each reference point indicates the point in time at which either the 281 query or the response message is transmitted or received over the 282 channel. 284 In this situation, A can arrange to measure the packet loss over the 285 channel in the forward and reverse directions by sending Loss 286 Measurement (LM) query messages to B each of which contains the count 287 of packets transmitted prior to time T1 over the channel to B 288 (A_TxP). When the message reaches B, it appends two values and 289 reflects the message back to A: the count of packets received prior 290 to time T2 over the channel from A (B_RxP), and the count of packets 291 transmitted prior to time T3 over the channel to A (B_TxP). When the 292 response reaches A, it appends a fourth value, the count of packets 293 received prior to time T4 over the channel from B (A_RxP). 295 These four counter values enable A to compute the desired loss 296 statistics. Because the transmit count at A and the receive count at 297 B (and vice versa) may not be synchronized at the time of the first 298 message, and to limit the effects of counter wrap, the loss is 299 computed in the form of a delta between messages. 301 To measure at A the delay over the channel to B, a Delay Measurement 302 (DM) query message is sent from A to B containing a timestamp 303 recording the instant at which it is transmitted, i.e. T1. When the 304 message reaches B, a timestamp is added recording the instant at 305 which it is received (T2). The message can now be reflected from B 306 to A, with B adding its transmit timestamp (T3) and A adding its 307 receive timestamp (T4). These four timestamps enable A to compute 308 the one-way delay in each direction, as well as the two-way delay for 309 the channel. The one-way delay computations require that the clocks 310 of A and B be synchronized; mechanisms for clock synchronization are 311 outside the scope of this document. 313 2.2. Packet Loss Measurement 315 Suppose a bidirectional channel exists between the nodes A and B. The 316 objective is to measure at A the following two quantities associated 317 with the channel: 319 A_TxLoss (transmit loss): the number of packets transmitted by A 320 over the channel but not received at B; 322 A_RxLoss (receive loss): the number of packets transmitted by B 323 over the channel but not received at A. 325 This is accomplished by initiating a Loss Measurement (LM) operation 326 at A, which consists of transmission of a sequence of LM query 327 messages (LM[1], LM[2], ...) over the channel at a specified rate, 328 such as one every 100 milliseconds. Each message LM[n] contains the 329 following value: 331 A_TxP[n]: the total count of packets transmitted by A over the 332 channel prior to the time this message is transmitted. 334 When such a message is received at B, the following value is recorded 335 in the message: 337 B_RxP[n]: the total count of packets received by B over the 338 channel at the time this message is received (excluding the 339 message itself). 341 At this point, B transmits the message back to A, recording within it 342 the following value: 344 B_TxP[n]: the total count of packets transmitted by B over the 345 channel prior to the time this response is transmitted. 347 When the message response is received back at A, the following value 348 is recorded in the message: 350 A_RxP[n]: the total count of packets received by A over the 351 channel at the time this response is received (excluding the 352 message itself). 354 The transmit loss A_TxLoss[n-1,n] and receive loss A_RxLoss[n-1,n] 355 within the measurement interval marked by the messages LM[n-1] and 356 LM[n] are computed by A as follows: 358 A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1]) 359 A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1]) 361 where the arithmetic is modulo the counter size. 363 (Strictly speaking, it is not necessary that the fourth count, 364 A_RxP[n], actually be written in the message, but this is convenient 365 for some implementations and useful if the message is to be forwarded 366 on to an external measurement system.) 368 The derived values 370 A_TxLoss = A_TxLoss[1,2] + A_TxLoss[2,3] + ... 372 A_RxLoss = A_RxLoss[1,2] + A_RxLoss[2,3] + ... 374 are updated each time a response to an LM message is received and 375 processed, and represent the total transmit and receive loss over the 376 channel since the LM operation was initiated. 378 When computing the values A_TxLoss[n-1,n] and A_RxLoss[n-1,n] the 379 possibility of counter wrap must be taken into account. Consider for 380 example the values of the A_TxP counter at sequence numbers n-1 and 381 n. Clearly if A_TxP[n] is allowed to wrap to 0 and then beyond to a 382 value equal to or greater than A_TxP[n-1], the computation of an 383 unambiguous A_TxLoss[n-1,n] value will be impossible. Therefore the 384 LM message rate MUST be sufficiently high, given the counter size and 385 the speed and minimum packet size of the underlying channel, that 386 this condition cannot arise. For example, a 32-bit counter for a 100 387 Gbps link with a minimum packet size of 64 bytes can wrap in 2^32 / 388 (10^11/(64*8)) = ~22 seconds, which is therefore an upper bound on 389 the LM message interval under such conditions. This bound will be 390 referred to as the MaxLMInterval of the channel. It is clear that 391 the MaxLMInterval will be a more restrictive constraint in the case 392 of direct LM and for smaller counter sizes. 394 The loss measurement approach described in this section has the 395 characteristic of being stateless at B and "almost" stateless at A. 396 Specifically, A must retain the data associated with the last LM 397 response received, in order to use it to compute loss when the next 398 response arrives. This data MAY be discarded, and MUST NOT be used 399 as a basis for measurement, if MaxLMInterval elapses before the next 400 response arrives, because in this case an unambiguous measurement 401 cannot be made. 403 The foregoing discussion has assumed the counted objects are packets, 404 but this need not be the case. In particular, octets may be counted 405 instead. This will, of course, reduce the MaxLMInterval 406 proportionately. 408 In addition to absolute aggregate loss counts, the individual loss 409 counts yield additional metrics such as the average loss rate over 410 any multiple of the measurement interval. An accurate loss rate can 411 be determined over time even in the presence of anomalies affecting 412 individual measurements, such as those due to packet misordering 413 (Section 4.2.10). 415 2.3. Throughput Measurement 417 If LM query messages contain a timestamp recording their time of 418 transmission, this data can be combined with the packet or octet 419 counts to yield measurements of the throughput offered and delivered 420 over the channel during the interval. Just as for loss measurement, 421 the interval counts can be accumulated to arrive at the throughput of 422 the channel since the start of the measurement operation, or used to 423 derive related metrics such as the average throughput rate. This 424 procedure also enables out-of-service throughput testing when 425 combined with a simple packet generator. 427 2.4. Delay Measurement 429 Suppose a bidirectional channel exists between the nodes A and B. The 430 objective is to measure at A one or more of the following quantities 431 associated with the channel: 433 o The one-way delay associated with the forward (A to B) direction 434 of the channel; 436 o The one-way delay associated with the reverse (B to A) direction 437 of the channel; 439 o The two-way delay (A to B to A) associated with the channel. 441 The one-way delay metric for packet networks is described in 442 [RFC2679]. In the case of two-way delay, there are actually two 443 possible metrics of interest. The "two-way channel delay" is the sum 444 of the one-way delays in each direction and reflects the delay of the 445 channel itself, irrespective of processing delays within the remote 446 endpoint B. The "round-trip delay" is described in [RFC2681] and 447 includes in addition any delay associated with remote endpoint 448 processing. 450 Measurement of the one-way delay quantities requires that the clocks 451 of A and B be synchronized, whereas the two-way delay metrics can be 452 measured directly even when this is not the case (provided A and B 453 have stable clocks). 455 A measurement is accomplished by sending a Delay Measurement (DM) 456 query message over the channel to B which contains the following 457 timestamp: 459 T1: the time the DM query message is transmitted from A. 461 When the message arrives at B, the following timestamp is recorded in 462 the message: 464 T2: the time the DM query message is received at B. 466 At this point B transmits the message back to A, recording within it 467 the following timestamp: 469 T3: the time the DM response message is transmitted from B. 471 When the message arrives back at A, the following timestamp is 472 recorded in the message: 474 T4: the time the DM response message is received back at A. 476 (Strictly speaking, it is not necessary that the fourth timestamp, 477 T4, actually be written in the message, but this is convenient for 478 some implementations and useful if the message is to be forwarded on 479 to an external measurement system.) 481 At this point, A can compute the two-way channel delay associated 482 with the channel as 484 two-way channel delay = (T4 - T1) - (T3 - T2) 486 and the round-trip delay as 488 round-trip delay = T4 - T1. 490 If the clocks of A and B are known at A to be synchronized, then both 491 one-way delay values, as well as the two-way channel delay, can be 492 computed at A as 494 forward one-way delay = T2 - T1 496 reverse one-way delay = T4 - T3 498 two-way channel delay = forward delay + reverse delay. 500 2.5. Delay Variation Measurement 502 Packet Delay Variation (PDV) [RFC3393] is another performance metric 503 important in some applications. The PDV of a pair of packets within 504 a stream of packets is defined for a selected pair of packets in the 505 stream going from measurement point 1 to measurement point 2. The 506 PDV is the difference between the one-way delay of the selected 507 packets. 509 A PDV measurement can therefore be derived from successive delay 510 measurements obtained through the procedures in Section 2.4. An 511 important point regarding PDV measurement, however, is that it can be 512 carried out based on one-way delay measurements even when the clocks 513 of the two systems involved in those measurements are not 514 synchronized. 516 2.6. Unidirectional Measurement 518 In the case that the channel from A to (B1, ..., Bk) is 519 unidirectional, i.e. is a unidirectional LSP, LM and DM measurements 520 can be carried out at B1, ..., Bk instead of at A. 522 For LM this is accomplished by initiating an LM operation at A and 523 carrying out the same procedures as for bidirectional channels, 524 except that no responses from B1, ..., Bk to A are generated. 525 Instead, each terminal node B uses the A_TxP and B_RxP values in the 526 LM messages it receives to compute the receive loss associated with 527 the channel in essentially the same way as described previously, i.e. 529 B_RxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1]) 531 For DM, of course, only the forward one-way delay can be measured and 532 the clock synchronization requirement applies. 534 Alternatively, if an out-of-band channel from a terminal node B back 535 to A is available, the LM and DM message responses can be 536 communicated to A via this channel so that the measurements can be 537 carried out at A. 539 2.7. Dyadic Measurement 541 The basic procedures for bidirectional measurement assume that the 542 measurement process is conducted by and for the querier node A. It is 543 possible instead, with only minor variation of these procedures, to 544 conduct a dyadic or "dual-ended" measurement process in which both 545 nodes A and B perform loss or delay measurement based on the same 546 message flow. This is achieved by stipulating that A copy the third 547 and fourth counter or timestamp values from a response message into 548 the third and fourth slots of the next query, which are otherwise 549 unused, thereby providing B with equivalent information to that 550 learned by A. 552 The dyadic procedure has the advantage of halving the number of 553 messages required for both A and B to perform a given kind of 554 measurement, but comes at the expense of each node's ability to 555 control its own measurement process independently, and introduces 556 additional operational complexity into the measurement protocols. 557 The quantity of measurement traffic is also expected to be low 558 relative to that of user traffic, particularly when 64-bit counters 559 are used for LM. Consequently this document does not specify a 560 dyadic operational mode. It is however still possible, and may be 561 useful, for A to perform the extra copy, thereby providing additional 562 information to B even when its participation in the measurement 563 process is passive. 565 2.8. Loopback Measurement 567 Some bidirectional channels may be placed into a loopback state such 568 that messages are looped back to the sender without modification. In 569 this situation, LM and DM procedures can be used to carry out 570 measurements associated with the circular path. This is done by 571 generating "queries" with the Response flag set to 1. 573 For LM, the loss computation in this case is: 575 A_Loss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1]) 577 For DM, the round-trip delay is computed. In this case, however, the 578 remote endpoint processing time component reflects only the time 579 required to loop the message from channel input to channel output. 581 2.9. Measurement Considerations 583 A number of additional considerations apply in practice to the 584 measurement methods summarized above. 586 2.9.1. Types of Channels 588 There are several types of channels in MPLS networks over which loss 589 and delay measurement may be conducted. The channel type may 590 restrict the kinds of measurement that can be performed. In all 591 cases, LM and DM messages flow over the MPLS Generic Associated 592 Channel (G-ACh), which is described in detail in [RFC5586]. 594 Broadly, a channel in an MPLS network may be either a link, a Label 595 Switched Path (LSP) [RFC3031], or a pseudowire [RFC3985]. Links are 596 bidirectional and are also referred to as MPLS sections; see 597 [RFC5586] and [RFC5960]. Pseudowires are bidirectional. Label 598 Switched Paths may be either unidirectional or bidirectional. 600 The LM and DM protocols discussed in this document are initiated from 601 a single node, the querier. A query message may be received either 602 by a single node or by multiple nodes, depending on the nature of the 603 channel. In the latter case these protocols provide point-to- 604 multipoint measurement capabilities. 606 2.9.2. Quality of Service 608 Quality of Service (QoS) capabilities, in the form of the 609 Differentiated Services architecture, apply to MPLS as specified in 610 [RFC3270] and [RFC5462]. Different classes of traffic are 611 distinguished by the three-bit Traffic Class (TC) field of an MPLS 612 Label Stack Entry (LSE). Delay measurement therefore applies on a 613 per-traffic-class basis, and the TC values of LSEs above the G-ACh 614 Label (GAL) that precedes a DM message are significant. Packet loss 615 can be measured with respect either to the channel as a whole or to a 616 specific traffic class. 618 2.9.3. Measurement Point Location 620 The location of the measurement points for loss and delay within the 621 sending and receiving nodes is implementation-dependent but directly 622 affects the nature of the measurements. For example, a sending 623 implementation may or may not consider a packet to be "lost", for LM 624 purposes, that was discarded prior to transmission for queuing- 625 related reasons; conversely, a receiving implementation may or may 626 not consider a packet to be "lost", for LM purposes, if it was 627 physically received but discarded during receive-path processing. 628 The location of delay measurement points similarly determines what, 629 precisely, is being measured. The principal consideration here is 630 that the behavior of an implementation in these respects MUST be made 631 clear to the user. 633 2.9.4. Equal Cost Multipath 635 Equal Cost Multipath (ECMP) is the behavior of distributing packets 636 across multiple alternate paths toward a destination. The use of 637 ECMP in MPLS networks is described in BCP 128 [RFC4928]. The typical 638 result of ECMP being performed on an LSP which is subject to delay 639 measurement will be that only the delay of one of the available paths 640 is and can be measured. 642 The effects of ECMP on loss measurement will depend on the LM mode. 643 In the case of direct LM, the measurement will account for any 644 packets lost between the sender and the receiver, regardless of how 645 many paths exist between them. However, the presence of ECMP 646 increases the likelihood of misordering both of LM messages relative 647 to data packets, and of the LM messages themselves. Such 648 misorderings tend to create unmeasurable intervals and thus degrade 649 the accuracy of loss measurement. The effects of ECMP are similar 650 for inferred LM, with the additional caveat that, unless the test 651 packets are specially constructed so as to probe all available paths, 652 the loss characteristics of one or more of the alternate paths cannot 653 be accounted for. 655 2.9.5. Intermediate Nodes 657 In the case of an LSP, it may be desirable to measure the loss or 658 delay to or from an intermediate node as well as between LSP 659 endpoints. This can be done in principle by setting the Time to Live 660 (TTL) field in the outer LSE appropriately when targeting a 661 measurement message to an intermediate node. This procedure may 662 fail, however, if hardware-assisted measurement is in use, because 663 the processing of the packet by the intermediate node occurs only as 664 the result of TTL expiry, and the handling of TTL expiry may occur at 665 a later processing stage in the implementation than the hardware- 666 assisted measurement function. Often the motivation for conducting 667 measurements to intermediate nodes is an attempt to localize a 668 problem that has been detected on the LSP. In this case, if 669 intermediate nodes are not capable of performing hardware-assisted 670 measurement, a less accurate - but usually sufficient - software- 671 based measurement can be conducted instead. 673 2.9.6. Different Transmit and Receive Interfaces 675 The overview of the bidirectional measurement process presented in 676 Section 2 is also applicable when the transmit and receive interfaces 677 at A or B differ from one another. Some additional considerations, 678 however, do apply in this case: 680 o If different clocks are associated with transmit and receive 681 processing, these clocks must be synchronized in order to compute 682 the two-way delay. 684 o The DM protocol specified in this document requires that the 685 timestamp formats used by the interfaces that receive a DM query 686 and transmit a DM response agree. 688 o The LM protocol specified in this document supports both 32-bit 689 and 64-bit counter sizes, but the use of 32-bit counters at any of 690 the up to four interfaces involved in an LM operation will result 691 in 32-bit LM calculations for both directions of the channel. 693 2.9.7. External Post-Processing 695 In some circumstances it may be desirable to carry out the final 696 measurement computation at an external post-processing device 697 dedicated to the purpose. This can be achieved in supporting 698 implementations by, for example, configuring the querier, in the case 699 of a bidirectional measurement session, to forward each response it 700 receives to the post-processor via any convenient protocol. The 701 unidirectional case can be handled similarly through configuration of 702 the receiver, or by including an instruction in query messages for 703 the receiver to respond out-of-band to the appropriate return 704 address. 706 Post-processing devices may have the ability to store measurement 707 data for an extended period and to generate a variety of useful 708 statistics from them. External post-processing also allows the 709 measurement process to be completely stateless at the querier and 710 responder. 712 2.9.8. Loss Measurement Modes 714 The summary of loss measurement at the beginning of Section 2 above 715 made reference to the "count of packets" transmitted and received 716 over a channel. If the counted packets are the packets flowing over 717 the channel in the data plane, the loss measurement is said to 718 operate in "direct mode". If, on the other hand, the counted packets 719 are selected control packets from which the approximate loss 720 characteristics of the channel are being inferred, the loss 721 measurement is said to operate in "inferred mode". 723 Direct LM has the advantage of being able to provide perfect loss 724 accounting when it is available. There are, however, several 725 constraints associated with direct LM. 727 For accurate direct LM to occur, packets must not be sent between the 728 time the transmit count for an outbound LM message is determined and 729 the time the message is actually transmitted. Similarly, packets 730 must not be received and processed between the time an LM message is 731 received and the time the receive count for the message is 732 determined. If these "synchronization conditions" do not hold, the 733 LM message counters will not reflect the true state of the data 734 plane, with the result that, for example, the receive count of B may 735 be greater than the transmit count of A, and attempts to compute loss 736 by taking the difference will yield an invalid result. This 737 requirement for synchronization between LM message counters and the 738 data plane may require special support from hardware-based forwarding 739 implementations. 741 A limitation of direct LM is that it may be difficult or impossible 742 to apply in cases where the channel is an LSP and the LSP label at 743 the receiver is either nonexistent or fails to identify a unique 744 sending node. The first case happens when Penultimate Hop Popping 745 (PHP) is used on the LSP, and the second case generally holds for 746 LSPs based on the Label Distribution Protocol (LDP) [RFC5036] as 747 opposed to, for example, those based on Traffic Engineering 748 extensions to the Resource Reservation Protocol (RSVP-TE) [RFC3209]. 749 These conditions may make it infeasible for the receiver to identify 750 the data-plane packets associated with a particular source and LSP in 751 order to count them, or to infer the source and LSP context 752 associated with an LM message. Direct LM is also vulnerable to 753 disruption in the event that the ingress or egress interface 754 associated with an LSP changes during the LSP's lifetime. 756 Inferred LM works in the same manner as direct LM except that the 757 counted packets are special control packets, called test messages, 758 generated by the sender. Test messages may be either packets 759 explicitly constructed and used for LM or packets with a different 760 primary purpose, such as those associated with a Bidirectional 761 Forwarding Detection (BFD) [RFC5884] session. 763 The synchronization conditions discussed above for direct LM also 764 apply to inferred LM, the only difference being that the required 765 synchronization is now between the LM counters and the test message 766 generation process. Protocol and application designers MUST take 767 these synchronization requirements into account when developing tools 768 for inferred LM, and make their behavior in this regard clear to the 769 user. 771 Inferred LM provides only an approximate view of the loss level 772 associated with a channel, but is typically applicable even in cases 773 where direct LM is not. 775 2.9.9. Loss Measurement Scope 777 In the case of direct LM, where data-plane packets are counted, there 778 are different possibilities for which kinds of packets are included 779 in the count and which are excluded. The set of packets counted for 780 LM is called the loss measurement scope. As noted above, one factor 781 affecting the LM scope is whether all data packets are counted or 782 only those belonging to a particular traffic class. Another is 783 whether various "auxiliary" flows associated with a data channel are 784 counted, such as packets flowing over the G-ACh. Implementations 785 MUST make their supported LM scopes clear to the user, and care must 786 be taken to ensure that the scopes of the channel endpoints agree. 788 2.9.10. Delay Measurement Accuracy 790 The delay measurement procedures described in this document are 791 designed to facilitate hardware-assisted measurement and to function 792 in the same way whether or not such hardware assistance is used. The 793 main difference in the two cases is one of measurement accuracy. 794 Implementations MUST make their delay measurement accuracy levels 795 clear to the user. 797 2.9.11. Delay Measurement Timestamp Format 799 There are two significant timestamp formats in common use: the 800 timestamp format of the Network Time Protocol (NTP), described in 801 [RFC5905], and the timestamp format used in the IEEE 1588 Precision 802 Time Protocol (PTP) [IEEE1588]. 804 The NTP format has the advantages of wide use and long deployment in 805 the Internet, and was specifically designed to make the computation 806 of timestamp differences as simple and efficient as possible. On the 807 other hand, there is also now a significant deployment of equipment 808 designed to support the PTP format. 810 The approach taken in this document is therefore to include in DM 811 messages fields which identify the timestamp formats used by the two 812 devices involved in a DM operation. This implies that a node 813 attempting to carry out a DM operation may be faced with the problem 814 of computing with and possibly reconciling different timestamp 815 formats. To ensure interoperability it is necessary that support of 816 at least one timestamp format is mandatory. This specification 817 requires the support of the IEEE 1588 PTP format. Timestamp format 818 support requirements are discussed in detail in Section 3.4. 820 3. Message Formats 822 Loss Measurement and Delay Measurement messages flow over the MPLS 823 Generic Associated Channel (G-ACh) [RFC5586]. Thus, a packet 824 containing an LM or DM message contains an MPLS label stack, with the 825 G-ACh Label (GAL) at the bottom of the stack. The GAL is followed by 826 an Associated Channel Header (ACH) which identifies the message type, 827 and the message body follows the ACH. 829 This document defines the following ACH Channel Types: 831 MPLS Direct Packet Loss Measurement (DLM) 832 MPLS Inferred Packet Loss Measurement (ILM) 833 MPLS Packet Delay Measurement (DM) 834 MPLS Direct Packet Loss and Delay Measurement (DLM+DM) 835 MPLS Inferred Packet Loss and Delay Measurement (ILM+DM) 837 The message formats for direct and inferred LM are identical. The 838 formats of the DLM+DM and ILM+DM messages are also identical. 840 For these channel types, the ACH SHALL NOT be followed by the ACH TLV 841 Header defined in [RFC5586]. 843 The fixed-format portion of a message MAY be followed by a block of 844 Type-Length-Value (TLV) fields. The TLV block provides an extensible 845 way of attaching subsidiary information to LM and DM messages. 846 Several such TLV fields are defined below. 848 All integer values for fields defined in this document SHALL be 849 encoded in network byte order. 851 3.1. Loss Measurement Message Format 853 The format of a Loss Measurement message, which follows the 854 Associated Channel Header (ACH), is as follows: 856 0 1 2 3 857 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 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 |Version| Flags | Control Code | Message Length | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | DFlags| OTF | Reserved | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Session Identifier | DS | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Origin Timestamp | 866 | | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Counter 1 | 869 | | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 . . 872 . . 873 . . 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Counter 4 | 876 | | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 ~ TLV Block ~ 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 Figure 2: Loss Measurement Message Format 883 Reserved fields MUST be set to 0 and ignored upon receipt. The 884 possible values for the remaining fields are as follows. 886 Field Meaning 887 --------------------- ----------------------------------------------- 888 Version Protocol version 889 Flags Message control flags 890 Control Code Code identifying the query or response type 891 Message Length Total length of this message in bytes 892 Data Format Flags Flags specifying the format of message data 893 (DFlags) 894 Origin Timestamp Format of the Origin Timestamp field 895 Format (OTF) 896 Reserved Reserved for future specification 897 Session Identifier Set arbitrarily by the querier 898 Differentiated Differentiated Services Code Point (DSCP) being 899 Services (DS) Field measured 901 Origin Timestamp 64-bit field for query message transmission 902 timestamp 903 Counter 1-4 64-bit fields for LM counter values 904 TLV Block Optional block of Type-Length-Value fields 906 The possible values for these fields are as follows. 908 Version: Currently set to 0. 910 Flags: The format of the Flags field is shown below. 912 +-+-+-+-+ 913 |R|T|0|0| 914 +-+-+-+-+ 916 Loss Measurement Message Flags 918 The meanings of the flag bits are: 920 R: Query/Response indicator. Set to 0 for a Query and 1 for a 921 Response. 923 T: Traffic-class-specific measurement indicator. Set to 1 when 924 the measurement operation is scoped to packets of a particular 925 traffic class (DSCP value), and 0 otherwise. When set to 1, the 926 DS field of the message indicates the measured traffic class. 928 0: Set to 0. 930 Control Code: Set as follows according to whether the message is a 931 Query or a Response as identified by the R flag. 933 For a Query: 935 0x0: In-band Response Requested. Indicates that this query has 936 been sent over a bidirectional channel and the response is 937 expected over the same channel. 939 0x1: Out-of-band Response Requested. Indicates that the 940 response should be sent via an out-of-band channel. 942 0x2: No Response Requested. Indicates that no response to the 943 query should be sent. This mode can be used, for example, if 944 all nodes involved are being controlled by a Network Management 945 System. 947 For a Response: 949 Codes 0x0-0xF are reserved for non-error responses. Error 950 response codes imply that the response does not contain valid 951 measurement data. 953 0x1: Success. Indicates that the operation was successful. 955 0x2: Notification - Data Format Invalid. Indicates that the 956 query was processed but the format of the data fields in this 957 response may be inconsistent. Consequently these data fields 958 MUST NOT be used for measurement. 960 0x3: Notification - Initialization In Progress. Indicates that 961 the query was processed but this response does not contain 962 valid measurement data because the responder's initialization 963 process has not completed. 965 0x4: Notification - Data Reset Occurred. Indicates that the 966 query was processed but a reset has recently occurred which may 967 render the data in this response inconsistent relative to 968 earlier responses. 970 0x5: Notification - Resource Temporarily Unavailable. 971 Indicates that the query was processed but resources were 972 unavailable to complete the requested measurement, and that 973 consequently this response does not contain valid measurement 974 data. 976 0x10: Error - Unspecified Error. Indicates that the operation 977 failed for an unspecified reason. 979 0x11: Error - Unsupported Version. Indicates that the 980 operation failed because the protocol version supplied in the 981 query message is not supported. 983 0x12: Error - Unsupported Control Code. Indicates that the 984 operation failed because the Control Code requested an 985 operation that is not available for this channel. 987 0x13: Error - Unsupported Data Format. Indicates that the 988 operation failed because the data format specified in the query 989 is not supported. 991 0x14: Error - Authentication Failure. Indicates that the 992 operation failed because the authentication data supplied in 993 the query was missing or incorrect. 995 0x15: Error - Invalid Destination Node Identifier. Indicates 996 that the operation failed because the Destination Node 997 Identifier supplied in the query is not an identifier of this 998 node. 1000 0x16: Error - Connection Mismatch. Indicates that the 1001 operation failed because the channel identifier supplied in the 1002 query did not match the channel over which the query was 1003 received. 1005 0x17: Error - Unsupported Mandatory TLV Object. Indicates that 1006 the operation failed because a TLV Object received in the query 1007 and marked as mandatory is not supported. 1009 0x18: Error - Unsupported Query Interval. Indicates that the 1010 operation failed because the query message rate exceeded the 1011 configured threshold. 1013 0x19: Error - Administrative Block. Indicates that the 1014 operation failed because it has been administratively 1015 disallowed. 1017 0x1A: Error - Resource Unavailable. Indicates that the 1018 operation failed because node resources were not available. 1020 0x1B: Error - Resource Released. Indicates that the operation 1021 failed because node resources for this measurement session were 1022 administratively released. 1024 0x1C: Error - Invalid Message. Indicates that the operation 1025 failed because the received query message was malformed. 1027 0x1D: Error - Protocol Error. Indicates that the operation 1028 failed because a protocol error was found in the received query 1029 message. 1031 Message Length: Set to the total length of this message in bytes, 1032 including the Version, Flags, Control Code, and Message Length 1033 fields. 1035 DFlags: The format of the DFlags field is shown below. 1037 +-+-+-+-+ 1038 |X|B|0|0| 1039 +-+-+-+-+ 1041 Loss Measurement Message Flags 1043 The meanings of the DFlags bits are: 1045 X: Extended counter format indicator. Indicates the use of 1046 extended (64-bit) counter values. Initialized to 1 upon creation 1047 (and prior to transmission) of an LM Query and copied from an LM 1048 Query to an LM response. Set to 0 when the LM message is 1049 transmitted or received over an interface that writes 32-bit 1050 counter values. 1052 B: Octet (byte) count. When set to 1, indicates that the Counter 1053 1-4 fields represent octet counts. When set to 0, indicates that 1054 the Counter 1-4 fields represent packet counts. 1056 0: Set to 0. 1058 Origin Timestamp Format: The format of the Origin Timestamp field, as 1059 specified in Section 3.4. 1061 Session Identifier: Set arbitrarily in a query and copied in the 1062 response, if any. This field uniquely identifies a measurement 1063 operation (also called a session) that consists of a sequence of 1064 messages. All messages in the sequence have the same Session 1065 Identifier. 1067 DS: When the T flag is set to 1, this field is set to the DSCP value 1068 [RFC3260] that corresponds to the traffic class being measured. For 1069 MPLS, where the traffic class of a channel is identified by the 1070 three-bit Traffic Class in the channel's LSE [RFC5462], this field 1071 SHOULD be set to the Class Selector Codepoint [RFC2474] that 1072 corresponds to that Traffic Class. When the T flag is set to 0, the 1073 value of this field is arbitrary, and the field can be considered 1074 part of the Session Identifier. 1076 Origin Timestamp: Timestamp recording the transmit time of the query 1077 message. 1079 Counter 1-4: Referring to Section 2.2, when a query is sent from A, 1080 Counter 1 is set to A_TxP and the other counter fields are set to 0. 1081 When the query is received at B, Counter 2 is set to B_RxP. At this 1082 point, B copies Counter 1 to Counter 3 and Counter 2 to Counter 4, 1083 and re-initializes Counter 1 and Counter 2 to 0. When B transmits 1084 the response, Counter 1 is set to B_TxP. When the response is 1085 received at A, Counter 2 is set to A_RxP. 1087 The mapping of counter types such as A_TxP to the counter fields 1-4 1088 is designed to ensure that transmit counter values are always written 1089 at the same fixed offset in the packet, and likewise for receive 1090 counters. This property may be important for hardware processing. 1092 When a 32-bit counter value is written to one of the counter fields, 1093 that value SHALL be written to the low-order 32 bits of the field; 1094 the high-order 32 bits of the field MUST, in this case, be set to 0. 1096 TLV Block: Zero or more TLV fields. 1098 3.2. Delay Measurement Message Format 1100 The format of a Delay Measurement message, which follows the 1101 Associated Channel Header (ACH), is as follows: 1103 0 1 2 3 1104 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 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 |Version| Flags | Control Code | Message Length | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | QTF | RTF | RPTF | Reserved | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | Session Identifier | DS | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | Timestamp 1 | 1113 | | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 . . 1116 . . 1117 . . 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 | Timestamp 4 | 1120 | | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 ~ TLV Block ~ 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 Figure 3: Delay Measurement Message Format 1126 The meanings of the fields are summarized in the following table. 1128 Field Meaning 1129 --------------------- ----------------------------------------------- 1130 Version Protocol version 1131 Flags Message control flags 1132 Control Code Code identifying the query or response type 1133 Message Length Total length of this message in bytes 1134 QTF Querier timestamp format 1135 RTF Responder timestamp format 1136 RPTF Responder's preferred timestamp format 1137 Reserved Reserved for future specification 1138 Session Identifier Set arbitrarily by the querier 1139 Differentiated Differentiated Services Code Point (DSCP) being 1140 Services (DS) Field measured 1142 Timestamp 1-4 64-bit timestamp values 1143 TLV Block Optional block of Type-Length-Value fields 1145 Reserved fields MUST be set to 0 and ignored upon receipt. The 1146 possible values for the remaining fields are as follows. 1148 Version: Currently set to 0. 1150 Flags: As specified in Section 3.1. The T flag in a DM message is 1151 set to 1. 1153 Control Code: As specified in Section 3.1. 1155 Message Length: Set to the total length of this message in bytes, 1156 including the Version, Flags, Control Code, and Message Length 1157 fields. 1159 Querier Timestamp Format: The format of the timestamp values written 1160 by the querier, as specified in Section 3.4. 1162 Responder Timestamp Format: The format of the timestamp values 1163 written by the responder, as specified in Section 3.4. 1165 Responder's Preferred Timestamp Format: The timestamp format 1166 preferred by the responder, as specified in Section 3.4. 1168 Session Identifier: As specified in Section 3.1. 1170 DS: As specified in Section 3.1. 1172 Timestamp 1-4: Referring to Section 2.4, when a query is sent from A, 1173 Timestamp 1 is set to T1 and the other timestamp fields are set to 0. 1174 When the query is received at B, Timestamp 2 is set to T2. At this 1175 point, B copies Timestamp 1 to Timestamp 3 and Timestamp 2 to 1176 Timestamp 4, and re-initializes Timestamp 1 and Timestamp 2 to 0. 1177 When B transmits the response, Timestamp 1 is set to T3. When the 1178 response is received at A, Timestamp 2 is set to T4. The actual 1179 formats of the timestamp fields written by A and B are indicated by 1180 the Querier Timestamp Format and Responder Timestamp Format fields 1181 respectively. 1183 The mapping of timestamps to the timestamp fields 1-4 is designed to 1184 ensure that transmit timestamps are always written at the same fixed 1185 offset in the packet, and likewise for receive timestamps. This 1186 property is important for hardware processing. 1188 TLV Block: Zero or more TLV fields. 1190 3.3. Combined Loss/Delay Measurement Message Format 1192 The format of a combined Loss and Delay Measurement message, which 1193 follows the Associated Channel Header (ACH), is as follows: 1195 0 1 2 3 1196 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 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 |Version| Flags | Control Code | Message Length | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | DFlags| QTF | RTF | RPTF | Reserved | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | Session Identifier | DS | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | Timestamp 1 | 1205 | | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 . . 1208 . . 1209 . . 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 | Timestamp 4 | 1212 | | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 | Counter 1 | 1215 | | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 . . 1218 . . 1219 . . 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | Counter 4 | 1222 | | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 ~ TLV Block ~ 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 Figure 4: Loss/Delay Measurement Message Format 1229 The fields of this message have the same meanings as the 1230 corresponding fields in the LM and DM message formats, except that 1231 the roles of the OTF and Origin Timestamp fields for LM are here 1232 played by the QTF and Timestamp 1 fields, respectively. 1234 3.4. Timestamp Field Formats 1236 The following timestamp format field values are specified in this 1237 document: 1239 0: Null timestamp format. This value is a placeholder indicating 1240 that the timestamp field does not contain a meaningful timestamp. 1242 1: Sequence number. This value indicates that the timestamp field 1243 is to be viewed as a simple 64-bit sequence number. This provides 1244 a simple solution for applications that do not require a real 1245 absolute timestamp, but only an indication of message ordering; an 1246 example is LM exception detection. 1248 2: Network Time Protocol version 4 64-bit timestamp format 1249 [RFC5905]. This format consists of a 32-bit seconds field 1250 followed by a 32-bit fractional seconds field, so that it can be 1251 regarded as a fixed-point 64-bit quantity. 1253 3: Low-order 64 bits of the IEEE 1588-2008 (1588v2) Precision Time 1254 Protocol timestamp format [IEEE1588]. This truncated format 1255 consists of a 32-bit seconds field followed by a 32-bit 1256 nanoseconds field, and is the same as the IEEE 1588v1 timestamp 1257 format. 1259 Timestamp formats of n < 64 bits in size SHALL be encoded in the 64- 1260 bit timestamp fields specified in this document using the n high- 1261 order bits of the field. The remaining 64 - n low-order bits in the 1262 field SHOULD be set to 0 and MUST be ignored when reading the field. 1264 To ensure that it is possible to find an interoperable mode between 1265 implementations it is necessary to select one timestamp format as the 1266 default. The timestamp format chosen as the default is the truncated 1267 IEEE 1588 PTP format (format code 3 in the list above); this format 1268 MUST be supported. The rationale for this choice is discussed in 1269 Appendix A. Implementations SHOULD also be capable of reading 1270 timestamps written in NTPv4 64-bit format and reconciling them 1271 internally with PTP timestamps for measurement purposes. Support for 1272 other timestamp formats is OPTIONAL. 1274 The implementation MUST make clear which timestamp formats it 1275 supports and the extent of its support for computation with and 1276 reconciliation of different formats for measurement purposes. 1278 3.5. TLV Objects 1280 The TLV Block in LM and DM messages consists of zero or more objects 1281 with the following format: 1283 0 1 2 3 1284 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 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 | Type | Length | Value ~ 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 TLV Format 1291 The Type and Length fields are each 8 bits long, and the Length field 1292 indicates the size in bytes of the Value field, which can therefore 1293 be up to 255 bytes long. 1295 The Type space is divided into Mandatory and Optional subspaces: 1297 Type Range Semantics 1298 -------------- --------- 1299 0-127 Mandatory 1300 128-255 Optional 1302 Upon receipt of a query message including an unrecognized mandatory 1303 TLV object, the recipient MUST respond with an Unsupported Mandatory 1304 TLV Object error code. 1306 The types defined are as follows: 1308 Type Definition 1309 -------------- --------------------------------- 1310 Mandatory 1311 0 Padding - copy in response 1312 1 Return Address 1313 2 Session Query Interval 1314 3 Loopback Request 1315 4-126 Unallocated 1316 127 Experimental use 1318 Optional 1319 128 Padding - do not copy in response 1320 129 Destination Address 1321 130 Source Address 1322 131-254 Unallocated 1323 255 Experimental use 1325 3.5.1. Padding 1327 The two padding objects permit the augmentation of packet size; this 1328 is mainly useful for delay measurement. The type of padding 1329 indicates whether the padding supplied by the querier is to be copied 1330 to, or omitted from, the response. Asymmetrical padding may be 1331 useful when responses are delivered out-of-band or when different 1332 maximum transmission unit sizes apply to the two components of a 1333 bidirectional channel. 1335 More than one padding object MAY be present, in which case they MUST 1336 be contiguous. The Value field of a padding object is arbitrary. 1338 3.5.2. Addressing 1340 The addressing objects have the following format: 1342 0 1 2 3 1343 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 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | Type | Length | Address Family | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 ~ Address ~ 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 Addressing Object Format 1352 The Address Family field indicates the type of the address, and SHALL 1353 be set to one of the assigned values in the IANA Address Family 1354 Numbers registry. 1356 The Source and Destination address objects indicate the addresses of 1357 the sender and the intended recipient of the message, respectively. 1358 The Source Address of a query message SHOULD be used as the 1359 destination for an out-of-band response unless some other out-of-band 1360 response mechanism has been configured, and unless a Return Address 1361 object is present, in which case the Return Address specifies the 1362 target of the response. The Return Address object MUST NOT appear in 1363 a response. 1365 3.5.3. Loopback Request 1367 The Loopback Request object, when included in a query, indicates a 1368 request that the query message be returned to the sender unmodified. 1369 This object has a Length of 0. 1371 Upon receiving the reflected query message back from the responder, 1372 the querier MUST NOT retransmit the message. Information that 1373 uniquely identifies the original query source, such as a Source 1374 Address object, can be included to enable the querier to 1375 differentiate one of its own loopback queries from a loopback query 1376 initiated by the far end. 1378 This object may be useful, for example, when the querier is 1379 interested only in the round-trip delay metric. In this case no 1380 support for delay measurement is required at the responder at all, 1381 other than the ability to recognize a DM query that includes this 1382 object and return it unmodified. 1384 3.5.4. Session Query Interval 1386 The Value field of the Session Query Interval object is a 32-bit 1387 unsigned integer that specifies a time interval in milliseconds: 1389 0 1 2 3 1390 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 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | Type | Length | Session Query > 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 < Interval (ms) | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1397 Session Query Interval Object Format 1399 This time interval indicates the interval between successive query 1400 messages in a specific measurement session. The purpose of the 1401 Session Query Interval (SQI) object is to enable the querier and 1402 responder of a measurement session to agree on a query rate. The 1403 procedures for handling this object SHALL be as follows: 1405 1. The querier notifies the responder that it wishes to be informed 1406 of the responder's minimum query interval for this session by 1407 including the SQI object in its query messages, with a Value of 1408 0. 1410 2. When the responder receives a query that includes an SQI object 1411 with a Value of 0, the responder includes an SQI object in the 1412 response with the Value set to the minimum query interval it 1413 supports for this session. 1415 3. When the querier receives a response that includes an SQI object, 1416 it selects a query interval for the session that is greater than 1417 or equal to the Value specified in the SQI object and adjusts its 1418 query transmission rate accordingly, including in each subsequent 1419 query an SQI object with a Value equal to the selected query 1420 interval. Once a response to one of these subsequent queries has 1421 been received, the querier infers that the responder has been 1422 apprised of the selected query interval and MAY then stop 1423 including the SQI object in queries associated with this session. 1425 Similar procedures allow the query rate to be changed during the 1426 course of the session by either the querier or the responder. For 1427 example, to inform the querier of a change in the minimum supported 1428 query interval, the responder begins including a corresponding SQI 1429 object in its responses, and the querier adjusts its query rate if 1430 necessary and includes a corresponding SQI object in its queries 1431 until a response is received. 1433 Shorter query intervals (i.e. higher query rates) provide finer 1434 measurement granularity at the expense of additional load on 1435 measurement endpoints and the network; see Section 6 for further 1436 discussion. 1438 4. Operation 1440 4.1. Operational Overview 1442 A loss or delay measurement operation, also called a session, is 1443 controlled by the querier and consists of a sequence of query 1444 messages associated with a particular channel and a common set of 1445 measurement parameters. If the session parameters include a response 1446 request, then the receiving node or nodes will (under normal 1447 conditions) generate a response message for each query message 1448 received, and these responses are also considered part of the 1449 session. All query and response messages in a session carry a common 1450 session identifier. 1452 Measurement sessions are initiated at the discretion of the network 1453 operator and are terminated either at the operator's request or as 1454 the result of an error condition. A session may be as brief as a 1455 single message exchange, for example when a DM query is used by the 1456 operator to "ping" a remote node, or may extend throughout the 1457 lifetime of the channel. 1459 When a session is initiated for which responses are requested, the 1460 querier SHOULD initialize a timer, called the SessionResponseTimeout, 1461 that indicates how long the querier will wait for a response before 1462 abandoning the session and notifying the user that a timeout has 1463 occurred. This timer persists for the lifetime of the session and is 1464 reset each time a response message for the session is received. 1466 When a query message is received that requests a response, a variety 1467 of exceptional conditions may arise that prevent the responder from 1468 generating a response that contains valid measurement data. Such 1469 conditions fall broadly into two classes: transient exceptions from 1470 which recovery is possible, and fatal exceptions that require 1471 termination of the session. When an exception arises, the responder 1472 SHOULD generate a response with an appropriate Notification or Error 1473 control code according as the exception is, respectively, transient 1474 or fatal. When the querier receives an Error response, the session 1475 MUST be terminated and the user informed. 1477 A common example of a transient exception occurs when a new session 1478 is initiated and the responder requires a period of time to become 1479 ready before it can begin providing useful responses. The response 1480 control code corresponding to this situation is Notification - 1481 Initialization In Progress. Typical examples of fatal exceptions are 1482 cases where the querier has requested a type of measurement that the 1483 responder does not support, or where a query message is malformed. 1485 When initiating a session the querier SHOULD employ the Session Query 1486 Interval mechanism (Section 3.5.4) to establish a mutually agreeable 1487 query rate with the responder. Responders SHOULD employ rate- 1488 limiting mechanisms to guard against the possibility of receiving an 1489 excessive quantity of query messages. 1491 4.2. Loss Measurement Procedures 1493 4.2.1. Initiating a Loss Measurement Operation 1495 An LM operation for a particular channel consists of sending a 1496 sequence (LM[1], LM[2], ...) of LM query messages over the channel at 1497 a specific rate and processing the responses received, if any. As 1498 described in Section 2.2, the packet loss associated with the channel 1499 during the operation is computed as a delta between successive 1500 messages; these deltas can be accumulated to obtain a running total 1501 of the packet loss for the channel, or used to derive related metrics 1502 such as the average loss rate. 1504 The query message transmission rate MUST be sufficiently high, given 1505 the LM message counter size (which can be either 32 or 64 bits) and 1506 the speed and minimum packet size of the underlying channel, that the 1507 ambiguity condition noted in Section 2.2 cannot arise. The 1508 implementation SHOULD assume, in evaluating this rate, that the 1509 counter size is 32 bits unless explicitly configured otherwise, or 1510 unless (in the case of a bidirectional channel) all local and remote 1511 interfaces involved in the LM operation are known to be 64-bit- 1512 capable, which can be inferred from the value of the X flag in an LM 1513 response. 1515 4.2.2. Transmitting a Loss Measurement Query 1517 When transmitting an LM Query over a channel, the Version field MUST 1518 be set to 0. The R flag MUST be set to 0. The T flag SHALL be set 1519 to 1 if, and only if, the measurement is specific to a particular 1520 traffic class, in which case the DS field SHALL identify that traffic 1521 class. 1523 The X flag MUST be set to 1 if the transmitting interface writes 64- 1524 bit LM counters, and otherwise MUST be set to 0 to indicate that 32- 1525 bit counters are written. The B flag SHALL be set to 1 to indicate 1526 that the counter fields contain octet counts, or to 0 to indicate 1527 packet counts. 1529 The Control Code field MUST be set to one of the values for Query 1530 messages listed in Section 3.1; if the channel is unidirectional, 1531 this field MUST NOT be set to 0x0 (Query: in-band response 1532 requested). 1534 The Session Identifier field can be set arbitrarily. 1536 The Origin Timestamp field SHOULD be set to the time at which this 1537 message is transmitted, and the Origin Timestamp Format field MUST be 1538 set to indicate its format, according to Section 3.4. 1540 The Counter 1 field SHOULD be set to the total count of units 1541 (packets or octets, according to the B flag) transmitted over the 1542 channel prior to this LM Query, or to 0 if this is the beginning of a 1543 measurement session for which counter data is not yet available. The 1544 Counter 2 field MUST be set to 0. If a response was previously 1545 received in this measurement session, the Counter 1 and Counter 2 1546 fields of the most recent such response MAY be copied to the Counter 1547 3 and Counter 4 fields, respectively, of this query; otherwise, the 1548 Counter 3 and Counter 4 fields MUST be set to 0. 1550 4.2.3. Receiving a Loss Measurement Query 1552 Upon receipt of an LM Query message, the Counter 2 field SHOULD be 1553 set to the total count of units (packets or octets, according to the 1554 B flag) received over the channel prior to this LM Query. If the 1555 receiving interface writes 32-bit LM counters, the X flag MUST be set 1556 to 0. 1558 At this point the LM Query message must be inspected. If the Control 1559 Code field is set to 0x2 (no response requested), an LM Response 1560 message MUST NOT be transmitted. If the Control Code field is set to 1561 0x0 (in-band response requested) or 0x1 (out-of-band response 1562 requested), then an in-band or out-of-band response, respectively, 1563 SHOULD be transmitted unless this has been prevented by an 1564 administrative, security or congestion control mechanism. 1566 In the case of a fatal exception that prevents the requested 1567 measurement from being made, the error SHOULD be reported, either via 1568 a response if one was requested or else as a notification to the 1569 user. 1571 4.2.4. Transmitting a Loss Measurement Response 1573 When constructing a Response to an LM Query, the Version field MUST 1574 be set to 0. The R flag MUST be set to 1. The value of the T flag 1575 MUST be copied from the LM Query. 1577 The X flag MUST be set to 0 if the transmitting interface writes 32- 1578 bit LM counters; otherwise its value MUST be copied from the LM 1579 Query. The B flag MUST be copied from the LM Query. 1581 The Session Identifier, Origin Timestamp, and Origin Timestamp Format 1582 fields MUST be copied from the LM Query. The Counter 1 and Counter 2 1583 fields from the LM Query MUST be copied to the Counter 3 and Counter 1584 4 fields, respectively, of the LM Response. 1586 The Control Code field MUST be set to one of the values for Response 1587 messages listed in Section 3.1. The value 0x10 (Unspecified Error) 1588 SHOULD NOT be used if one of the other more specific error codes is 1589 applicable. 1591 If the response is transmitted in-band, the Counter 1 field SHOULD be 1592 set to the total count of units transmitted over the channel prior to 1593 this LM Response. If the response is transmitted out-of-band, the 1594 Counter 1 field MUST be set to 0. In either case, the Counter 2 1595 field MUST be set to 0. 1597 4.2.5. Receiving a Loss Measurement Response 1599 Upon in-band receipt of an LM Response message, the Counter 2 field 1600 is set to the total count of units received over the channel prior to 1601 this LM Response. If the receiving interface writes 32-bit LM 1602 counters, the X flag is set to 0. (Since the life of the LM message 1603 in the network has ended at this point, it is up to the receiver 1604 whether these final modifications are made to the packet. If the 1605 message is to be forwarded on for external post-processing 1606 (Section 2.9.7) then these modifications MUST be made.) 1608 Upon out-of-band receipt of an LM Response message, the Counter 1 and 1609 Counter 2 fields MUST NOT be used for purposes of loss measurement. 1611 If the Control Code in an LM Response is anything other than 0x1 1612 (Success), the counter values in the response MUST NOT be used for 1613 purposes of loss measurement. If the Control Code indicates an error 1614 condition, or if the response message is invalid, the LM operation 1615 MUST be terminated and an appropriate notification to the user 1616 generated. 1618 4.2.6. Loss Calculation 1620 Calculation of packet loss is carried out according to the procedures 1621 in Section 2.2. The X flag in an LM message informs the device 1622 performing the calculation whether to perform 32-bit or 64-bit 1623 arithmetic. If the flag value is equal to 1, all interfaces involved 1624 in the LM operation have written 64-bit counter values, and 64-bit 1625 arithmetic can be used. If the flag value is equal to 0, at least 1626 one interface involved in the operation has written a 32-bit counter 1627 value, and 32-bit arithmetic is carried out using the low-order 32 1628 bits of each counter value. 1630 Note that the semantics of the X flag allow all devices to 1631 interoperate regardless of their counter size support. Thus, an 1632 implementation MUST NOT generate an error response based on the value 1633 of this flag. 1635 4.2.7. Quality of Service 1637 The TC field of the LSE corresponding to the channel (e.g. LSP) 1638 being measured SHOULD be set to a traffic class equal to or better 1639 than the best TC within the measurement scope to minimize the chance 1640 of out-of-order conditions. 1642 4.2.8. G-ACh Packets 1644 By default, direct LM MUST exclude packets transmitted and received 1645 over the Generic Associated Channel (G-ACh). An implementation MAY 1646 provide the means to alter the direct LM scope to include some or all 1647 G-ACh messages. Care must be taken when altering the LM scope to 1648 ensure that both endpoints are in agreement. 1650 4.2.9. Test Messages 1652 In the case of inferred LM, the packets counted for LM consist of 1653 test messages generated for this purpose, or of some other class of 1654 packets deemed to provide a good proxy for data packets flowing over 1655 the channel. The specification of test protocols and proxy packets 1656 is outside the scope of this document, but some guidelines are 1657 discussed below. 1659 An identifier common to both the test or proxy messages and the LM 1660 messages may be required to make correlation possible. The combined 1661 value of the Session Identifier and DS fields SHOULD be used for this 1662 purpose when possible. That is, test messages in this case will 1663 include a 32-bit field which can carry the value of the combined 1664 Session Identifier + DS field present in LM messages. When TC- 1665 specific LM is conducted, the DS field of the LSE in the label stack 1666 of a test message corresponding to the channel (e.g. LSP) over which 1667 the message is sent MUST correspond to the DS value in the associated 1668 LM messages. 1670 A separate test message protocol SHOULD include a timeout value in 1671 its messages that informs the responder when to discard any state 1672 associated with a specific test. 1674 4.2.10. Message Loss and Packet Misorder Conditions 1676 Because an LM operation consists of a message sequence with state 1677 maintained from one message to the next, LM is subject to the effects 1678 of lost messages and misordered packets in a way that DM is not. 1679 Because this state exists only on the querier, the handling of these 1680 conditions is, strictly speaking, a local matter. This section, 1681 however, presents recommended procedures for handling such 1682 conditions. Note that in the absence of ECMP, packet misordering 1683 within a traffic class is a relatively rare event. 1685 The first kind of anomaly that may occur is that one or more LM 1686 messages may be lost in transit. The effect of such loss is that 1687 when an LM Response is next received at the querier, an unambiguous 1688 interpretation of the counter values it contains may be impossible, 1689 for the reasons described at the end of Section 2.2. Whether this is 1690 so depends on the number of messages lost and the other variables 1691 mentioned in that section, such as the LM message rate and the 1692 channel parameters. 1694 Another possibility is that LM messages are misordered in transit, so 1695 that for instance the response to LM[n] is received prior to the 1696 response to LM[n-1]. A typical implementation will discard the late 1697 response to LM[n-1], so that the effect is the same as the case of a 1698 lost message. 1700 Finally, LM is subject to the possibility that data packets are 1701 misordered relative to LM messages. This condition can result, for 1702 example, in a transmit count of 100 and a corresponding receive count 1703 of 101. The effect here is that the A_TxLoss[n-1,n] value (for 1704 example) for a given measurement interval will appear to be extremely 1705 (if not impossibly) large. The other case, where an LM message 1706 arrives earlier than some of the packets, simply results in those 1707 packets being counted as lost. 1709 An implementation SHOULD identify a threshold value that indicates 1710 the upper bound of lost packets measured in a single computation 1711 beyond which the interval is considered unmeasurable. This is called 1712 the MaxLMIntervalLoss threshold. It is clear that this threshold 1713 should be no higher than the maximum number of packets (or bytes) the 1714 channel is capable of transmitting over the interval, but it may be 1715 lower. Upon encountering an unmeasurable interval, the LM state 1716 (i.e. data values from the last LM message received) SHOULD be 1717 discarded. 1719 With regard to lost LM messages, the MaxLMInterval (see Section 2.2) 1720 indicates the maximum amount of time that can elapse before the LM 1721 state is discarded. If some messages are lost, but a message is 1722 subsequently received within MaxLMInterval, its timestamp or sequence 1723 number will quantify the loss, and it MAY still be used for 1724 measurement, although the measurement interval will in this case be 1725 longer than usual. 1727 If an LM message is received that has a timestamp less than or equal 1728 to the timestamp of the last LM message received, this indicates that 1729 an exception has occurred, and the current interval SHOULD be 1730 considered unmeasurable unless the implementation has some other way 1731 of handling this condition. 1733 4.3. Delay Measurement Procedures 1735 4.3.1. Transmitting a Delay Measurement Query 1737 When transmitting a DM Query over a channel, the Version and Reserved 1738 fields MUST be set to 0. The R flag MUST be set to 0, the T flag 1739 MUST be set to 1, and the remaining flag bits MUST be set to 0. 1741 The Control Code field MUST be set to one of the values for Query 1742 messages listed in Section 3.1; if the channel is unidirectional, 1743 this field MUST NOT be set to 0x0 (Query: in-band response 1744 requested). 1746 The Querier Timestamp Format field MUST be set to the timestamp 1747 format used by the querier when writing timestamp fields in this 1748 message; the possible values for this field are listed in 1749 Section 3.4. The Responder Timestamp Format and Responder's 1750 Preferred Timestamp Format fields MUST be set to 0. 1752 The Session Identifier field can be set arbitrarily. The DS field 1753 MUST be set to the traffic class being measured. 1755 The Timestamp 1 field SHOULD be set to the time at which this DM 1756 Query is transmitted, in the format indicated by the Querier 1757 Timestamp Format field. The Timestamp 2 field MUST be set to 0. If 1758 a response was previously received in this measurement session, the 1759 Timestamp 1 and Timestamp 2 fields of the most recent such response 1760 MAY be copied to the Timestamp 3 and Timestamp 4 fields, 1761 respectively, of this query; otherwise, the Timestamp 3 and Timestamp 1762 4 fields MUST be set to 0. 1764 4.3.2. Receiving a Delay Measurement Query 1766 Upon receipt of a DM Query message, the Timestamp 2 field SHOULD be 1767 set to the time at which this DM Query is received. 1769 At this point the DM Query message must be inspected. If the Control 1770 Code field is set to 0x2 (no response requested), a DM Response 1771 message MUST NOT be transmitted. If the Control Code field is set to 1772 0x0 (in-band response requested) or 0x1 (out-of-band response 1773 requested), then an in-band or out-of-band response, respectively, 1774 SHOULD be transmitted unless this has been prevented by an 1775 administrative, security or congestion control mechanism. 1777 In the case of a fatal exception that prevents the requested 1778 measurement from being made, the error SHOULD be reported, either via 1779 a response if one was requested or else as a notification to the 1780 user. 1782 4.3.3. Transmitting a Delay Measurement Response 1784 When constructing a Response to a DM Query, the Version and Reserved 1785 fields MUST be set to 0. The R flag MUST be set to 1, the T flag 1786 MUST be set to 1, and the remaining flag bits MUST be set to 0. 1788 The Session Identifier and Querier Timestamp Format (QTF) fields MUST 1789 be copied from the DM Query. The Timestamp 1 and Timestamp 2 fields 1790 from the DM Query MUST be copied to the Timestamp 3 and Timestamp 4 1791 fields, respectively, of the DM Response. 1793 The Responder Timestamp Format (RTF) field MUST be set to the 1794 timestamp format used by the responder when writing timestamp fields 1795 in this message, i.e. Timestamp 4 and (if applicable) Timestamp 1; 1796 the possible values for this field are listed in Section 3.4. 1797 Furthermore, the RTF field MUST be set equal either to the QTF or the 1798 RPTF field. See Section 4.3.5 for guidelines on selection of the 1799 value for this field. 1801 The Responder's Preferred Timestamp Format (RPTF) field MUST be set 1802 to one of the values listed in Section 3.4 and SHOULD be set to 1803 indicate the timestamp format with which the responder can provide 1804 the best accuracy for purposes of delay measurement. 1806 The Control Code field MUST be set to one of the values for Response 1807 messages listed in Section 3.1. The value 0x10 (Unspecified Error) 1808 SHOULD NOT be used if one of the other more specific error codes is 1809 applicable. 1811 If the response is transmitted in-band, the Timestamp 1 field SHOULD 1812 be set to the time at which this DM Response is transmitted. If the 1813 response is transmitted out-of-band, the Timestamp 1 field MUST be 1814 set to 0. In either case, the Timestamp 2 field MUST be set to 0. 1816 If the response is transmitted in-band and the Control Code in the 1817 message is 0x1 (Success), then the Timestamp 1 and Timestamp 4 fields 1818 MUST have the same format, which will be the format indicated in the 1819 Responder Timestamp Format field. 1821 4.3.4. Receiving a Delay Measurement Response 1823 Upon in-band receipt of a DM Response message, the Timestamp 2 field 1824 is set to the time at which this DM Response is received. (Since the 1825 life of the DM message in the network has ended at this point, it is 1826 up to the receiver whether this final modification is made to the 1827 packet. If the message is to be forwarded on for external post- 1828 processing (Section 2.9.7) then these modifications MUST be made.) 1830 Upon out-of-band receipt of a DM Response message, the Timestamp 1 1831 and Timestamp 2 fields MUST NOT be used for purposes of delay 1832 measurement. 1834 If the Control Code in a DM Response is anything other than 0x1 1835 (Success), the timestamp values in the response MUST NOT be used for 1836 purposes of delay measurement. If the Control Code indicates an 1837 error condition, or if the response message is invalid, the DM 1838 operation MUST be terminated and an appropriate notification to the 1839 user generated. 1841 4.3.5. Timestamp Format Negotiation 1843 In case either the querier or the responder in a DM transaction is 1844 capable of supporting multiple timestamp formats, it is desirable to 1845 determine the optimal format for purposes of delay measurement on a 1846 particular channel. The procedures for making this determination 1847 SHALL be as follows. 1849 Upon sending an initial DM Query over a channel, the querier sets the 1850 Querier Timestamp Format (QTF) field to its preferred timestamp 1851 format. 1853 Upon receiving any DM Query message, the responder determines whether 1854 it is capable of writing timestamps in the format specified by the 1855 QTF field. If so, the Responder Timestamp Format (RTF) field is set 1856 equal to the QTF field. If not, the RTF field is set equal to the 1857 Responder's Preferred Timestamp Format (RPTF) field. 1859 The process of changing from one timestamp format to another at the 1860 responder may result in the Timestamp 1 and Timestamp 4 fields in an 1861 in-band DM Response having different formats. If this is the case, 1862 the Control Code in the response MUST NOT be set to 0x1 (Success). 1863 Unless an error condition has occurred, the Control Code MUST be set 1864 to 0x2 (Notification - Data Format Invalid). 1866 Upon receiving a DM Response, the querier knows from the RTF field in 1867 the message whether the responder is capable of supporting its 1868 preferred timestamp format: if it is, the RTF will be equal to the 1869 QTF. The querier also knows the responder's preferred timestamp 1870 format from the RPTF field. The querier can then decide whether to 1871 retain its current QTF or to change it and repeat the negotiation 1872 procedures. 1874 4.3.5.1. Single-Format Procedures 1876 When an implementation supports only one timestamp format, the 1877 procedures above reduce to the following simple behavior: 1879 o All DM Queries are transmitted with the same QTF; 1881 o All DM Responses are transmitted with the same RTF, and the RPTF 1882 is always set equal to the RTF; 1884 o All DM Responses received with RTF not equal to QTF are discarded; 1886 o On a unidirectional channel, all DM Queries received with QTF not 1887 equal to the supported format are discarded. 1889 4.3.6. Quality of Service 1891 The TC field of the LSE corresponding to the channel (e.g. LSP) 1892 being measured MUST be set to the value that corresponds to the DS 1893 field in the DM message. 1895 4.4. Combined Loss/Delay Measurement Procedures 1897 The combined LM/DM message defined in Section 3.3 allows loss and 1898 delay measurement to be carried out simultaneously. This message 1899 SHOULD be treated as an LM message which happens to carry additional 1900 timestamp data, with the timestamp fields processed as per delay 1901 measurement procedures. 1903 5. Implementation Disclosure Requirements 1905 This section summarizes the requirements placed on implementations 1906 for capabilities disclosure. The purpose of these requirements is to 1907 ensure that end users have a clear understanding of implementation 1908 capabilities and characteristics that have a direct impact on how 1909 loss and delay measurement mechanisms function in specific 1910 situations. Implementations are REQUIRED to state: 1912 o METRICS: Which of the following metrics are supported: packet 1913 loss, packet throughput, octet loss, octet throughput, average 1914 loss rate, one-way delay, round-trip delay, two-way channel delay, 1915 packet delay variation. 1917 o MP-LOCATION: The location of loss and delay measurement points 1918 with respect to other stages of packet processing, such as 1919 queuing. 1921 o CHANNEL-TYPES: The types of channels for which LM and DM are 1922 supported, including LSP types, pseudowires, and sections (links). 1924 o QUERY-RATE: The minimum supported query intervals for LM and DM 1925 sessions, both in the querier and responder roles. 1927 o LOOP: Whether loopback measurement (Section 2.8) is supported. 1929 o LM-TYPES: Whether direct or inferred LM is supported, and for the 1930 latter, which test protocols or proxy message types are supported. 1932 o LM-COUNTERS: Whether 64-bit counters are supported. 1934 o LM-ACCURACY: The expected measurement accuracy levels for the 1935 supported forms of LM, and the expected impact of exception 1936 conditions such as lost and misordered messages. 1938 o LM-SYNC: The implementation's behavior in regard to the 1939 synchronization conditions discussed in Section 2.9.8. 1941 o LM-SCOPE: The supported LM scopes (Section 2.9.9 and 1942 Section 4.2.8). 1944 o DM-ACCURACY: The expected measurement accuracy levels for the 1945 supported forms of DM. 1947 o DM-TS-FORMATS: The supported timestamp formats and the extent of 1948 support for computation with and reconciliation of different 1949 formats. 1951 6. Congestion Considerations 1953 An MPLS network may be traffic-engineered in such a way that the 1954 bandwidth required both for client traffic and for control, 1955 management and OAM traffic is always available. The following 1956 congestion considerations therefore apply only when this is not the 1957 case. 1959 The proactive generation of Loss Measurement and Delay Measurement 1960 messages for purposes of monitoring the performance of an MPLS 1961 channel naturally results in a degree of additional load placed on 1962 both the network and the terminal nodes of the channel. When 1963 configuring such monitoring, operators should be mindful of the 1964 overhead involved and should choose transmit rates that do not stress 1965 network resources unduly; such choices must be informed by the 1966 deployment context. In case of slower links or lower-speed devices, 1967 for example, lower Loss Measurement message rates can be chosen, up 1968 to the limits noted at the end of Section 2.2. 1970 In general, lower measurement message rates place less load on the 1971 network at the expense of reduced granularity. For delay measurement 1972 this reduced granularity translates to a greater possibility that the 1973 delay associated with a channel temporarily exceeds the expected 1974 threshold without detection. For loss measurement, it translates to 1975 a larger gap in loss information in case of exceptional circumstances 1976 such as lost LM messages or misordered packets. 1978 When carrying out a sustained measurement operation such as an LM 1979 operation or continuous pro-active DM operation, the querier SHOULD 1980 take note of the number of lost measurement messages (queries for 1981 which a response is never received) and set a corresponding 1982 Measurement Message Loss Threshold. If this threshold is exceeded, 1983 the measurement operation SHOULD be suspended so as not to exacerbate 1984 the possible congestion condition. This suspension SHOULD be 1985 accompanied by an appropriate notification to the user so that the 1986 condition can be investigated and corrected. 1988 From the receiver perspective, the main consideration is the 1989 possibility of receiving an excessive quantity of measurement 1990 messages. An implementation SHOULD employ a mechanism such as rate- 1991 limiting to guard against the effects of this case. 1993 7. Security Considerations 1995 This document describes procedures for the measurement of performance 1996 metrics over a pre-existing MPLS path (a pseudowire, LSP, or 1997 section). As such it assumes that a node involved in a measurement 1998 operation has previously verified the integrity of the path and the 1999 identity of the far end using existing MPLS mechanisms such as 2000 Bidirectional Forwarding Detection (BFD) [RFC5884]; tools, 2001 techniques, and considerations for securing MPLS paths are discussed 2002 in detail in [RFC5920]. 2004 When such mechanisms are not available, and where security of the 2005 measurement operation is a concern, reception of Generic Associated 2006 Channel messages with the Channel Types specified in this document 2007 SHOULD be disabled. Implementations MUST provide the ability to 2008 disable these protocols on a per-Channel-Type basis. 2010 Even when the identity of the far end has been verified, the 2011 measurement protocols remain vulnerable to injection and man-in-the- 2012 middle attacks. The impact of such an attack would be to compromise 2013 the quality of performance measurements on the affected path. An 2014 attacker positioned to disrupt these measurements is, however, 2015 capable of causing much greater damage by disrupting far more 2016 critical elements of the network such as the network control plane or 2017 user traffic flows. A disruption of the measurement protocols would 2018 at worst interfere with the monitoring of the performance aspects of 2019 the service level agreement associated with the path; the existence 2020 of such a disruption would imply that a much more serious breach of 2021 basic path integrity had already occurred. 2023 Such attacks can be mitigated if desired by performing basic 2024 validation and sanity checks, at the querier, of the counter or 2025 timestamp fields in received measurement response messages. The 2026 minimal state associated with these protocols also limits the extent 2027 of measurement disruption that can be caused by a corrupt or invalid 2028 message to a single query/response cycle. 2030 Users concerned with the security of out-of-band responses over IP 2031 networks SHOULD employ suitable security mechanisms such as IPsec 2032 [RFC4301] to protect the integrity of the return path. 2034 8. IANA Considerations 2036 This document makes the following requests of IANA: 2038 o Allocation of Channel Types in the PW Associated Channel Type 2039 registry 2041 o Creation of a Measurement Timestamp Type registry 2043 o Creation of an MPLS Loss/Delay Measurement Control Code registry 2045 o Creation of an MPLS Loss/Delay Measurement Type-Length-Value (TLV) 2046 Object registry 2048 8.1. Allocation of PW Associated Channel Types 2050 As per the IANA considerations in [RFC5586], IANA is requested to 2051 allocate the following Channel Types in the PW Associated Channel 2052 Type registry: 2054 Value Description TLV Follows Reference 2055 ----- -------------------------------------- ----------- ------------ 2056 TBD MPLS Direct Packet Loss Measurement No (this draft) 2057 (DLM) 2058 TBD MPLS Inferred Packet Loss Measurement No (this draft) 2059 (ILM) 2060 TBD MPLS Packet Delay Measurement (DM) No (this draft) 2061 TBD MPLS Direct Packet Loss and Delay No (this draft) 2062 Measurement (DLM+DM) 2063 TBD MPLS Inferred Packet Loss and Delay No (this draft) 2064 Measurement (ILM+DM) 2066 The values marked TBD are to be allocated by IANA as appropriate. 2068 8.2. Creation of Measurement Timestamp Type Registry 2070 IANA is requested to create a new Measurement Timestamp Type 2071 registry, with format and initial allocations as follows: 2073 Type Description Size in bits Reference 2074 ---- -------------------------------------- ------------ ------------ 2075 0 Null Timestamp 64 (this draft) 2076 1 Sequence Number 64 (this draft) 2077 2 Network Time Protocol version 4 64-bit 64 (this draft) 2078 Timestamp 2079 3 Truncated IEEE 1588v2 PTP Timestamp 64 (this draft) 2081 The range of the Type field is 0-15. 2083 The allocation policy for this registry is IETF Review. 2085 8.3. Creation of MPLS Loss/Delay Measurement Control Code Registry 2087 IANA is requested to create a new MPLS Loss/Delay Measurement Control 2088 Code registry. This registry is divided into two separate parts, one 2089 for Query Codes and the other for Response Codes, with formats and 2090 initial allocations as follows: 2092 Query Codes 2094 Code Description Reference 2095 ---- ------------------------------ ------------ 2096 0x0 In-band Response Requested (this draft) 2097 0x1 Out-of-band Response Requested (this draft) 2098 0x2 No Response Requested (this draft) 2099 Response Codes 2101 Code Description Reference 2102 ---- ----------------------------------- ------------ 2103 0x0 Reserved (this draft) 2104 0x1 Success (this draft) 2105 0x2 Data Format Invalid (this draft) 2106 0x3 Initialization In Progress (this draft) 2107 0x4 Data Reset Occurred (this draft) 2108 0x5 Resource Temporarily Unavailable (this draft) 2109 0x10 Unspecified Error (this draft) 2110 0x11 Unsupported Version (this draft) 2111 0x12 Unsupported Control Code (this draft) 2112 0x13 Unsupported Data Format (this draft) 2113 0x14 Authentication Failure (this draft) 2114 0x15 Invalid Destination Node Identifier (this draft) 2115 0x16 Connection Mismatch (this draft) 2116 0x17 Unsupported Mandatory TLV Object (this draft) 2117 0x18 Unsupported Query Interval (this draft) 2118 0x19 Administrative Block (this draft) 2119 0x1A Resource Unavailable (this draft) 2120 0x1B Resource Released (this draft) 2121 0x1C Invalid Message (this draft) 2122 0x1D Protocol Error (this draft) 2124 IANA is also requested to indicate that the values 0x0 - 0xF in the 2125 Response Code section are reserved for non-error response codes. 2127 The range of the Code field is 0 - 255. 2129 The allocation policy for this registry is IETF Review. 2131 8.4. Creation of MPLS Loss/Delay Measurement TLV Object Registry 2133 IANA is requested to create a new MPLS Loss/Delay Measurement TLV 2134 Object registry, with format and initial allocations as follows: 2136 Type Description Reference 2137 ---- --------------------------------- ------------ 2138 0 Padding - copy in response (this draft) 2139 1 Return Address (this draft) 2140 2 Session Query Interval (this draft) 2141 3 Loopback Request (this draft) 2142 127 Experimental use (this draft) 2143 128 Padding - do not copy in response (this draft) 2144 129 Destination Address (this draft) 2145 130 Source Address (this draft) 2146 255 Experimental use (this draft) 2148 IANA is also requested to indicate that Types 0-127 are classified as 2149 Mandatory, and that Types 128-255 are classified as Optional. 2151 The range of the Type field is 0 - 255. 2153 The allocation policy for this registry is IETF Review, except for 2154 the ranges marked "Implementation-specific usage", for which the 2155 policy is Private Use. 2157 9. Acknowledgments 2159 The authors wish to thank the many participants of the MPLS working 2160 group who provided detailed review and feedback on this document. 2161 The authors offer special thanks to Alexander Vainshtein, Loa 2162 Andersson, and Hiroyuki Takagi for many helpful thoughts and 2163 discussions, to Linda Dunbar for the idea of using LM messages for 2164 throughput measurement, and to Ben Niven-Jenkins, Marc Lasserre, and 2165 Ben Mack-Crane for their valuable comments. 2167 10. References 2169 10.1. Normative References 2171 [IEEE1588] 2172 IEEE, "1588-2008 IEEE Standard for a Precision Clock 2173 Synchronization Protocol for Networked Measurement and 2174 Control Systems", March 2008. 2176 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2177 Requirement Levels", BCP 14, RFC 2119, March 1997. 2179 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2180 "Definition of the Differentiated Services Field (DS 2181 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2182 December 1998. 2184 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2185 Label Switching Architecture", RFC 3031, January 2001. 2187 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 2188 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 2189 Protocol Label Switching (MPLS) Support of Differentiated 2190 Services", RFC 3270, May 2002. 2192 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 2193 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 2194 Class" Field", RFC 5462, February 2009. 2196 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 2197 Associated Channel", RFC 5586, June 2009. 2199 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 2200 Time Protocol Version 4: Protocol and Algorithms 2201 Specification", RFC 5905, June 2010. 2203 10.2. Informative References 2205 [I-D.ietf-mpls-tp-loss-delay-profile] 2206 Frost, D. and S. Bryant, "A Packet Loss and Delay 2207 Measurement Profile for MPLS-based Transport Networks", 2208 draft-ietf-mpls-tp-loss-delay-profile-03 (work in 2209 progress), April 2011. 2211 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2212 Delay Metric for IPPM", RFC 2679, September 1999. 2214 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 2215 Delay Metric for IPPM", RFC 2681, September 1999. 2217 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2218 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2219 Tunnels", RFC 3209, December 2001. 2221 [RFC3260] Grossman, D., "New Terminology and Clarifications for 2222 Diffserv", RFC 3260, April 2002. 2224 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 2225 Metric for IP Performance Metrics (IPPM)", RFC 3393, 2226 November 2002. 2228 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 2229 Edge (PWE3) Architecture", RFC 3985, March 2005. 2231 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2232 Internet Protocol", RFC 4301, December 2005. 2234 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 2235 Cost Multipath Treatment in MPLS Networks", BCP 128, 2236 RFC 4928, June 2007. 2238 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 2239 Specification", RFC 5036, October 2007. 2241 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 2242 "Bidirectional Forwarding Detection (BFD) for MPLS Label 2243 Switched Paths (LSPs)", RFC 5884, June 2010. 2245 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 2246 Networks", RFC 5920, July 2010. 2248 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 2249 Berger, "A Framework for MPLS in Transport Networks", 2250 RFC 5921, July 2010. 2252 [RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport 2253 Profile Data Plane Architecture", RFC 5960, August 2010. 2255 [Y.1731] ITU-T Recommendation Y.1731, "OAM Functions and Mechanisms 2256 for Ethernet based Networks", February 2008. 2258 Appendix A. Default Timestamp Format Rationale 2260 This document initially proposed the Network Time Protocol (NTP) 2261 timestamp format as the mandatory default, as this is the normal 2262 default timestamp in IETF protocols and thus would seem the "natural" 2263 choice. However a number of considerations have led instead to the 2264 specification of the truncated IEEE 1588 Precision Time Protocol 2265 (PTP) timestamp as the default. NTP has not gained traction in 2266 industry as the protocol of choice for high quality timing 2267 infrastructure, whilst IEEE 1588 PTP has become the de facto time 2268 transfer protocol in networks which are specially engineered to 2269 provide high accuracy time distribution service. The PTP timestamp 2270 format is also the ITU-T format of choice for packet transport 2271 networks, which may rely on MPLS protocols. Applications such as 2272 one-way delay measurement need the best time service available, and 2273 converting between the NTP and PTP timestamp formats is not a trivial 2274 transformation, particularly when it is required that this be done in 2275 real time without loss of accuracy. 2277 The truncated IEEE 1588 PTP format specified in this document is 2278 considered to provide a more than adequate wrap time and greater time 2279 resolution than it is expected will be needed for the operational 2280 lifetime of this protocol. By truncating the timestamp at both the 2281 high and low order bits, the protocol achieves a worthwhile reduction 2282 in system resources. 2284 Authors' Addresses 2286 Dan Frost 2287 Cisco Systems 2289 Email: danfrost@cisco.com 2291 Stewart Bryant 2292 Cisco Systems 2294 Email: stbryant@cisco.com