idnits 2.17.1 draft-frost-mpls-loss-delay-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 8, 2010) is 4881 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 1231 -- Looks like a reference, but probably isn't: '2' on line 1231 -- Looks like a reference, but probably isn't: '3' on line 328 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1588' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS D. Frost, Ed. 3 Internet-Draft S. Bryant, Ed. 4 Intended status: Standards Track Cisco Systems 5 Expires: June 11, 2011 December 8, 2010 7 Packet Loss and Delay Measurement for MPLS Networks 8 draft-frost-mpls-loss-delay-00 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 capability, in 16 addition, provides operators with greater visibility into the 17 performance characteristics of their networks, thereby facilitating 18 planning, troubleshooting, and evaluation. This document specifies 19 protocol mechanisms to enable the efficient and accurate measurement 20 of these 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 June 11, 2011. 45 Copyright Notice 47 Copyright (c) 2010 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 64 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 7 66 2.2. Throughput Measurement . . . . . . . . . . . . . . . . . . 9 67 2.3. Delay Measurement . . . . . . . . . . . . . . . . . . . . 9 68 2.4. Delay Variation Measurement . . . . . . . . . . . . . . . 11 69 2.5. Unidirectional Measurement . . . . . . . . . . . . . . . . 11 70 2.6. Loopback Measurement . . . . . . . . . . . . . . . . . . . 12 71 2.7. Measurement Considerations . . . . . . . . . . . . . . . . 12 72 2.7.1. Types of Channels . . . . . . . . . . . . . . . . . . 12 73 2.7.2. Quality of Service . . . . . . . . . . . . . . . . . . 12 74 2.7.3. Equal Cost Multipath . . . . . . . . . . . . . . . . . 13 75 2.7.4. Intermediate Nodes . . . . . . . . . . . . . . . . . . 13 76 2.7.5. Distributed Systems . . . . . . . . . . . . . . . . . 14 77 2.7.6. Loss Measurement Modes . . . . . . . . . . . . . . . . 14 78 2.7.7. Loss Measurement Scope . . . . . . . . . . . . . . . . 16 79 2.7.8. Delay Measurement Accuracy . . . . . . . . . . . . . . 16 80 2.7.9. Delay Measurement Timestamp Format . . . . . . . . . . 16 81 3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 17 82 3.1. Loss Measurement Message Format . . . . . . . . . . . . . 17 83 3.2. Delay Measurement Message Format . . . . . . . . . . . . . 22 84 3.3. Combined Loss/Delay Measurement Message Format . . . . . . 24 85 3.4. Timestamp Field Formats . . . . . . . . . . . . . . . . . 25 86 3.5. TLV Objects . . . . . . . . . . . . . . . . . . . . . . . 26 87 3.5.1. Padding . . . . . . . . . . . . . . . . . . . . . . . 27 88 3.5.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 27 89 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 28 90 4.1. Loss Measurement Procedures . . . . . . . . . . . . . . . 28 91 4.1.1. Initiating a Loss Measurement Operation . . . . . . . 28 92 4.1.2. Transmitting a Loss Measurement Query . . . . . . . . 29 93 4.1.3. Receiving a Loss Measurement Query . . . . . . . . . . 29 94 4.1.4. Transmitting a Loss Measurement Response . . . . . . . 30 95 4.1.5. Receiving a Loss Measurement Response . . . . . . . . 30 96 4.1.6. Loss Calculation . . . . . . . . . . . . . . . . . . . 31 97 4.1.7. Quality of Service . . . . . . . . . . . . . . . . . . 31 98 4.1.8. G-ACh Packets . . . . . . . . . . . . . . . . . . . . 31 99 4.1.9. Test Messages . . . . . . . . . . . . . . . . . . . . 31 100 4.1.10. Message Loss and Packet Misorder Conditions . . . . . 32 101 4.2. Delay Measurement Procedures . . . . . . . . . . . . . . . 33 102 4.2.1. Transmitting a Delay Measurement Query . . . . . . . . 33 103 4.2.2. Receiving a Delay Measurement Query . . . . . . . . . 33 104 4.2.3. Transmitting a Delay Measurement Response . . . . . . 34 105 4.2.4. Receiving a Delay Measurement Response . . . . . . . . 34 106 4.2.5. Timestamp Format Negotiation . . . . . . . . . . . . . 35 107 4.2.6. Quality of Service . . . . . . . . . . . . . . . . . . 36 108 4.3. Combined Loss/Delay Measurement Procedures . . . . . . . . 36 109 5. Congestion Considerations . . . . . . . . . . . . . . . . . . 36 110 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 111 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 112 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 113 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 114 9.1. Normative References . . . . . . . . . . . . . . . . . . . 38 115 9.2. Informative References . . . . . . . . . . . . . . . . . . 38 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 118 1. Introduction 120 Many service provider service level agreements (SLAs) depend on the 121 ability to measure and monitor performance metrics for packet loss 122 and one-way and two-way delay, as well as related metrics such as 123 delay variation and channel throughput. This capability, in 124 addition, provides operators with greater visibility into the 125 performance characteristics of their networks, thereby facilitating 126 planning, troubleshooting, and evaluation. This document specifies 127 protocol mechanisms to enable the efficient and accurate measurement 128 of these performance metrics in MPLS networks. 130 This document specifies two closely-related protocols, one for packet 131 loss measurement (LM) and one for packet delay measurement (DM). 132 These protocols have the following characteristics and capabilities: 134 o The LM and DM protocols are intended to be simple and to support 135 efficient hardware processing. 137 o The LM and DM protocols operate over the MPLS Generic Associated 138 Channel (G-ACh) [RFC5586] and support measurement of loss and 139 delay over Label Switched Paths (LSPs), pseudowires, and MPLS 140 sections (links). 142 o The LM and DM protocols are applicable to the LSPs, pseudowires, 143 and sections of networks based on the MPLS Transport Profile 144 (MPLS-TP), because the MPLS-TP is based on a standard MPLS data 145 plane. The MPLS-TP is defined and described in [RFC5921], and 146 MPLS-TP LSPs, pseudowires, and sections are discussed in detail in 147 [RFC5960]. 149 o The LM and DM protocols can be used for both continuous/proactive 150 and selective/on-demand measurement. 152 o The LM and DM protocols use a simple query/response model for 153 bidirectional measurement that allows a single node - the querier 154 - to measure the loss or delay in both directions. 156 o The LM and DM protocols use query messages for unidirectional loss 157 and delay measurement. The measurement can either be carried out 158 at the downstream node(s) or at the querier if an out-of-band 159 return path is available. 161 o The LM and DM protocols do not require that the transmit and 162 receive interfaces be the same when performing bidirectional 163 measurement. 165 o The DM protocol is stateless. 167 o The LM protocol is "almost" stateless: loss is computed as a delta 168 between successive messages, and thus the data associated with the 169 last message received must be retained. 171 o The LM protocol can perform two distinct kinds of loss 172 measurement: it can measure the loss of specially generated test 173 packets in order to infer the approximate data-plane loss level 174 (inferred measurement); or it can directly measure data-plane 175 packet loss (direct measurement). Direct measurement provides 176 perfect loss accounting, but may require specialized hardware 177 support and is only applicable to some LSP types. Inferred 178 measurement provides only approximate loss accounting but is 179 generally applicable. 181 o The LM protocol supports both 32-bit and 64-bit packet counters. 183 o The LM protocol supports measurement in terms of both packet 184 counts and octet counts. 186 o The LM protocol can be used to measure channel throughput as well 187 as packet loss. 189 o The DM protocol supports multiple timestamp formats, and provides 190 a simple means for the two endpoints of a bidirectional connection 191 to agree on a preferred format. This procedure reduces to a 192 triviality for implementations supporting only a single timestamp 193 format. 195 o The DM protocol supports varying the measurement message size in 196 order to measure delays associated with different packet sizes. 198 1.1. Terminology 200 Term Definition 201 ------- ------------------------------------------- 202 ACH Associated Channel Header 203 DM Delay Measurement 204 G-ACh Generic Associated Channel 205 LM Loss Measurement 206 LSE Label Stack Entry 207 LSP Label Switched Path 208 LSR Label Switching Router 209 MPLS-TP MPLS Transport Profile 210 NTP Network Time Protocol 211 OAM Operations, Administration, and Maintenance 212 PTP Precision Time Protocol 213 PW Pseudowire 214 TC Traffic Class 216 2. Overview 218 This section begins with a summary of the basic methods used for the 219 bidirectional measurement of packet loss and delay. These 220 measurement methods are then described in detail. Finally a list of 221 practical considerations are discussed that may come into play to 222 inform or modify these simple procedures. 224 The following figure shows the reference scenario. 226 T1 T2 227 +-------+/ Query \+-------+ 228 | | - - - - - - - - ->| | 229 | A |===================| B | 230 | |<- - - - - - - - - | | 231 +-------+\ Response /+-------+ 232 T4 T3 234 Figure 1 236 The figure shows a bidirectional channel between two nodes, A and B, 237 and illustrates the temporal reference points T1-T4 associated with a 238 measurement operation that takes place at A. The operation consists 239 of A sending a query message to B, and B sending back a response. 240 Each reference point indicates the point in time at which either the 241 query or the response message is transmitted or received over the 242 channel. 244 In this situation, A can arrange to measure the packet loss over the 245 channel in the forward and reverse directions by sending Loss 246 Measurement (LM) query messages to B each of which contains the count 247 of packets transmitted prior to time T1 over the channel to B 248 (A_TxP). When the message reaches B, it appends two values and 249 reflects the message back to A: the count of packets received prior 250 to time T2 over the channel from A (B_RxP), and the count of packets 251 transmitted prior to time T3 over the channel to A (B_TxP). When the 252 response reaches A, it appends a fourth value, the count of packets 253 received prior to time T4 over the channel from B (A_RxP). 255 These four counter values enable A to compute the desired loss 256 statistics. Because the transmit count at A and the receive count at 257 B (and vice versa) may not be synchronized at the time of the first 258 message, and to limit the effects of counter wrap, the loss is 259 computed in the form of a delta between messages. 261 To measure at A the delay over the channel to B, a Delay Measurement 262 (DM) query message is sent from A to B containing a timestamp 263 recording the instant at which it is transmitted, i.e. T1. When the 264 message reaches B, a timestamp is added recording the instant at 265 which it is received (T2). The message can now be reflected from B 266 to A, with B adding its transmit timestamp (T3) and A adding its 267 receive timestamp (T4). These four timestamps enable A to compute 268 the one-way delay in each direction, as well as the two-way delay for 269 the channel. The one-way delay computations require that the clocks 270 of A and B be synchronized; mechanisms for clock synchronization are 271 outside the scope of this document. 273 2.1. Packet Loss Measurement 275 Suppose a bidirectional channel exists between the nodes A and B. The 276 objective is to measure at A the following two quantities associated 277 with the channel: 279 A_TxLoss (transmit loss): the number of packets transmitted by A 280 over the channel but not received at B; 282 A_RxLoss (receive loss): the number of packets transmitted by B 283 over the channel but not received at A. 285 This is accomplished by initiating a Loss Measurement (LM) operation 286 at A, which consists of transmission of a sequence of LM query 287 messages (LM[1], LM[2], ...) over the channel at a specified rate, 288 such as one every 100 milliseconds. Each message LM[n] contains the 289 following value: 291 A_TxP[n]: the total count of packets transmitted by A over the 292 channel prior to the time this message is transmitted. 294 When such a message is received at B, the following value is recorded 295 in the message: 297 B_RxP[n]: the total count of packets received by B over the 298 channel at the time this message is received (excluding the 299 message itself). 301 At this point, B inserts an appropriate response code into the 302 message and transmits it back to A, recording within it the following 303 value: 305 B_TxP[n]: the total count of packets transmitted by B over the 306 channel prior to the time this response is transmitted. 308 When the message response is received back at A, the following value 309 is recorded in the message: 311 A_RxP[n]: the total count of packets received by A over the 312 channel at the time this response is received (excluding the 313 message itself). 315 The transmit loss A_TxLoss[n-1,n] and receive loss A_RxLoss[n-1,n] 316 within the measurement interval marked by the messages LM[n-1] and 317 LM[n] are computed by A as follows: 319 A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1]) 320 A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1]) 322 where the arithmetic is modulo the counter size. 324 The derived values 326 A_TxLoss = A_TxLoss[1,2] + A_TxLoss[2,3] + ... 328 A_RxLoss = A_RxLoss[1,2] + A_RxLoss[2,3] + ... 330 are updated each time a response to an LM message is received and 331 processed, and represent the total transmit and receive loss over the 332 channel since the LM operation was initiated. 334 When computing the values A_TxLoss[n-1,n] and A_RxLoss[n-1,n] the 335 possibility of counter wrap must be taken into account. Consider for 336 example the values of the A_TxP counter at sequence numbers n-1 and 337 n. Clearly if A_TxP[n] is allowed to wrap to 0 and then beyond to a 338 value equal to or greater than A_TxP[n-1], the computation of an 339 unambiguous A_TxLoss[n-1,n] value will be impossible. Therefore the 340 LM message rate MUST be sufficiently high, given the counter size and 341 the speed and minimum packet size of the underlying channel, that 342 this condition cannot arise. For example, a 32-bit counter for a 100 343 Gbps link with a minimum packet size of 64 bytes can wrap in 2^32 / 344 (10^11/(64*8)) = ~22 seconds, which is therefore an upper bound on 345 the LM message interval under such conditions. This bound will be 346 referred to as the MaxLMInterval of the channel. It is clear that 347 the MaxLMInterval will be a more restrictive constraint in the case 348 of direct LM and for smaller counter sizes. 350 The loss measurement approach described in this section has the 351 characteristic of being stateless at B and "almost" stateless at A. 352 Specifically, A must retain the data associated with the last LM 353 response received, in order to use it to compute loss when the next 354 response arrives. This data MAY be discarded, and MUST NOT be used 355 as a basis for measurement, if MaxLMInterval elapses before the next 356 response arrives, because in this case an unambiguous measurement 357 cannot be made. 359 The foregoing discussion has assumed the counted objects are packets, 360 but this need not be the case. In particular, octets may be counted 361 instead. This will, of course, reduce the MaxLMInterval 362 proportionately. 364 2.2. Throughput Measurement 366 If LM query messages contain a timestamp recording their time of 367 transmission, this data can be combined with the packet or octet 368 counts to yield a measurement of the throughput sustained over the 369 channel during the interval. This metric can be called the delivered 370 throughput. As for loss measurement, the interval counts can be 371 accumulated to arrive at the delivered throughput of the channel 372 since the start of the measurement operation. This procedure also 373 enables out-of-service throughput testing when combined with a simple 374 packet generator. 376 2.3. Delay Measurement 378 Suppose a bidirectional channel exists between the nodes A and B. The 379 objective is to measure at A one or more of the following quantities 380 associated with the channel: 382 o The one-way delay associated with the forward (A to B) direction 383 of the channel; 385 o The one-way delay associated with the reverse (B to A) direction 386 of the channel; 388 o The two-way delay (A to B to A) associated with the channel. 390 In the case of two-way delay, there are actually two possible metrics 391 of interest. The "strict" two-way delay is the sum of the one-way 392 delays in each direction and reflects the two-way delay of the 393 channel itself, irrespective of processing delays within the remote 394 endpoint B. The "loose" two-way delay includes in addition any delay 395 associated with remote endpoint processing. 397 Measurement of the one-way delay quantities requires that the clocks 398 of A and B be synchronized, whereas the two-way delay can be measured 399 directly even when this is not the case (provided A and B have stable 400 clocks). 402 The measurement is accomplished by sending a Delay Measurement (DM) 403 query message over the channel to B which contains the following 404 timestamp: 406 T1: the time the DM query message is transmitted from A. 408 When the message arrives at B, the following timestamp is recorded in 409 the message: 411 T2: the time the DM query message is received at B. 413 At this point B inserts an appropriate response code into the message 414 and transmits it back to A, recording within it the following 415 timestamp: 417 T3: the time the DM response message is transmitted from B. 419 When the message arrives back at A, the following timestamp is 420 recorded in the message: 422 T4: the time the DM response message is received back at A. 424 At this point, A can compute the strict two-way delay associated with 425 the channel as 427 strict two-way delay = (T4 - T1) - (T3 - T2) 429 and the loose two-way delay as 431 loose two-way delay = T4 - T1. 433 If the clocks of A and B are known at A to be synchronized, then both 434 one-way delay values, as well as the strict two-way delay, can be 435 computed at A as 436 forward one-way delay = T2 - T1 438 reverse one-way delay = T4 - T3 440 strict two-way delay = forward delay + reverse delay. 442 2.4. Delay Variation Measurement 444 Packet Delay Variation (PDV) [RFC3393] is another performance metric 445 important in some applications. The PDV of a pair of packets within 446 a stream of packets is defined for a selected pair of packets in the 447 stream going from measurement point 1 to measurement point 2. The 448 PDV is the difference between the one-way delay of the selected 449 packets. 451 A PDV measurement can therefore be derived from successive delay 452 measurements obtained through the procedures in Section 2.3. An 453 important point regarding PDV measurement, however, is that it can be 454 carried out based on one-way delay measurements even when the clocks 455 of the two systems involved in those measurements are not 456 synchronized. 458 2.5. Unidirectional Measurement 460 In the case that the channel from A to (B1, ..., Bk) is 461 unidirectional, i.e. is a unidirectional LSP, LM and DM measurements 462 can be carried out at B1, ..., Bk instead of at A. 464 For LM this is accomplished by initiating an LM operation at A and 465 carrying out the same procedures as for bidirectional channels, 466 except that no responses from B1, ..., Bk to A are generated. 467 Instead, each terminal node B uses the A_TxP and B_RxP values in the 468 LM messages it receives to compute the receive loss associated with 469 the channel in essentially the same way as described previously, i.e. 471 B_RxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1]) 473 For DM, of course, only the forward one-way delay can be measured and 474 the clock synchronization requirement applies. 476 Alternatively, if an out-of-band channel from a terminal node B back 477 to A is available, the LM and DM message responses can be 478 communicated to A via this channel so that the measurements can be 479 carried out at A. 481 2.6. Loopback Measurement 483 Some bidirectional channels may be placed into a loopback state such 484 that query messages are looped back to the querier without 485 modification. In this situation, LM and DM procedures can be used to 486 carry out measurements associated with the circular path. 488 For LM, the loss computation in this case is: 490 A_Loss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1]) 492 For DM, the loose two-way delay is computed. In this case, however, 493 the remote endpoint processing time component reflects only the time 494 required to loop the message from channel input to channel output. 496 Query messages must include some form of source identifier in order 497 for looped-back queries to be differentiated from queries initiated 498 by the far end. 500 2.7. Measurement Considerations 502 A number of additional considerations apply in practice to the 503 measurement methods summarized above. 505 2.7.1. Types of Channels 507 There are several types of channels in MPLS networks over which loss 508 and delay measurement may be conducted. The channel type may 509 restrict the kinds of measurement that can be performed. In all 510 cases, LM and DM messages flow over the MPLS Generic Associated 511 Channel (G-ACh), which is described in detail in [RFC5586]. 513 Broadly, a channel in an MPLS network may be either a link, a Label 514 Switched Path (LSP) [RFC3031], or a pseudowire [RFC3985]. Links are 515 bidirectional and are also referred to as MPLS sections; see 516 [RFC5586] and [RFC5960]. Pseudowires are bidirectional. Label 517 Switched Paths may be either unidirectional or bidirectional. 519 The LM and DM protocols discussed in this document are initiated from 520 a single node, the querier. A query message may be received either 521 by a single node or by multiple nodes, depending on the nature of the 522 channel. In the latter case these protocols provide point-to- 523 multipoint measurement capabilities. 525 2.7.2. Quality of Service 527 Quality of Service (QoS) capabilities, in the form of the 528 Differentiated Services architecture, apply to MPLS as specified in 530 [RFC3270] and [RFC5462]. Different classes of traffic are 531 distinguished by the three-bit Traffic Class (TC) field of an MPLS 532 Label Stack Entry (LSE). Delay measurement therefore applies on a 533 per-traffic-class basis, and the TC values of LSEs above the G-ACh 534 Label (GAL) that precedes a DM message are significant. Packet loss 535 can be measured with respect either to the channel as a whole or to a 536 specific traffic class. 538 Another aspect of packet processing which often arises in the context 539 of QoS concerns the location of the measurement points for loss and 540 delay within the sending and receiving nodes, which is 541 implementation-dependent. For example, a sending implementation may 542 or may not consider a packet to be "lost", for LM purposes, that was 543 discarded prior to transmission for queuing-related reasons; 544 conversely, a receiving implementation may or may not consider a 545 packet to be "lost", for LM purposes, if it was physically received 546 but discarded during receive-path processing. The location of delay 547 measurement points similarly impacts what, precisely, is being 548 measured. The principal consideration here is that the behavior of 549 an implementation in these respects SHOULD be made clear to the user. 551 2.7.3. Equal Cost Multipath 553 Equal Cost Multipath (ECMP) is the behavior of distributing packets 554 across multiple alternate paths toward a destination. The use of 555 ECMP in MPLS networks is described in BCP 128 [RFC4928]. The typical 556 result of ECMP being performed on an LSP which is subject to delay 557 measurement will be that only the delay of one of the available paths 558 is and can be measured. 560 The effects of ECMP on loss measurement will depend on the LM mode. 561 In the case of direct LM, the measurement will account for any 562 packets lost between the sender and the receiver, regardless of how 563 many paths exist between them. However, the presence of ECMP 564 increases the likelihood of misordering both of LM messages relative 565 to data packets, and of the LM messages themselves. Such 566 misorderings tend to create unmeasurable intervals and thus degrade 567 the accuracy of loss measurement. The effects of ECMP are similar 568 for inferred LM, with the additional caveat that, unless the test 569 packets are specially constructed so as to probe all available paths, 570 the loss characteristics of one or more of the alternate paths cannot 571 be accounted for. 573 2.7.4. Intermediate Nodes 575 In the case of an LSP, it may be desirable to measure the loss or 576 delay to or from an intermediate node as well as between LSP 577 endpoints. This can be done in principle by setting the Time to Live 578 (TTL) field in the outer LSE appropriately when targeting a 579 measurement message to an intermediate node. This procedure may 580 fail, however, if hardware-assisted measurement is in use, because 581 the processing of the packet by the intermediate node occurs only as 582 the result of TTL expiry, and the handling of TTL expiry may occur at 583 a later processing stage in the implementation than the hardware- 584 assisted measurement function. Often the motivation for conducting 585 measurements to intermediate nodes is an attempt to localize a 586 problem that has been detected on the LSP. In this case, if 587 intermediate nodes are not capable of performing hardware-assisted 588 measurement, a less accurate - but usually sufficient - software- 589 based measurement can be conducted instead. 591 2.7.5. Distributed Systems 593 The overview of the bidirectional measurement process presented in 594 Section 2 is also applicable when the transmit and receive interfaces 595 at A or B differ from one another. Some additional considerations, 596 however, do apply in this case: 598 o If different clocks are associated with transmit and receive 599 processing, these clocks must be synchronized in order to compute 600 the two-way delay. 602 o The DM protocol specified in this document requires that the 603 timestamp formats used by the interfaces that receive a DM query 604 and transmit a DM response agree. 606 o The LM protocol specified in this document supports both 32-bit 607 and 64-bit counter sizes, but the use of 32-bit counters at any of 608 the up to four interfaces involved in an LM operation will result 609 in 32-bit LM calculations for both directions of the channel. 611 [Editor's note: The last two restrictions could be relaxed if 612 desired, at the expense of some additional protocol complexity.] 614 2.7.6. Loss Measurement Modes 616 The summary of loss measurement at the beginning of Section 2 above 617 made reference to the "count of packets" transmitted and received 618 over a channel. If the counted packets are the packets flowing over 619 the channel in the data plane, the loss measurement is said to 620 operate in "direct mode". If, on the other hand, the counted packets 621 are selected control packets from which the approximate loss 622 characteristics of the channel are being inferred, the loss 623 measurement is said to operate in "inferred mode". 625 Direct LM has the advantage of being able to provide perfect loss 626 accounting when it is available. There are, however, several 627 limitations associated with direct LM. 629 For accurate direct LM to occur, packets must not be sent between the 630 time the transmit count for an outbound LM message is determined and 631 the time the message is actually transmitted. Similarly, packets 632 must not be received and processed between the time an LM message is 633 received and the time the receive count for the message is 634 determined. If these "synchronization conditions" do not hold, the 635 LM message counters will not reflect the true state of the data 636 plane, with the result that, for example, the receive count of B may 637 be greater than the transmit count of A, and attempts to compute loss 638 by taking the difference will yield an invalid result. This 639 requirement for synchronization between LM message counters and the 640 data plane may require special support from hardware-based forwarding 641 implementations. 643 Another limitation of direct LM is that it may be difficult or 644 impossible to apply in cases where the channel is an LSP and the LSP 645 label at the receiver is either nonexistent or fails to identify a 646 unique sending node. The first case happens when Penultimate Hop 647 Popping (PHP) is used on the LSP, and the second case generally holds 648 for LSPs based on the Label Distribution Protocol (LDP) [RFC5036] as 649 opposed to, for example, those based on Traffic Engineering 650 extensions to the Resource Reservation Protocol (RSVP-TE) [RFC3209]. 651 These conditions may make it infeasible for the receiver to identify 652 the data-plane packets associated with a particular source and LSP in 653 order to count them, or to infer the source and LSP context 654 associated with an LM message. 656 Inferred LM works in the same manner as direct LM except that the 657 counted packets are special control packets, called test messages, 658 generated by the sender. Test messages may be either packets 659 explicitly constructed and used for LM or packets with a different 660 primary purpose, such as those associated with a Bidirectional 661 Forwarding Detection (BFD) [RFC5884] session. 663 The synchronization conditions discussed above for direct LM also 664 apply to inferred LM, the only difference being that the required 665 synchronization is now between the LM counters and the test message 666 generation process. Protocol and application designers MUST take 667 these synchronization requirements into account when developing tools 668 for inferred LM, and make their behavior in this regard clear to the 669 user. 671 Inferred LM provides only an approximate view of the loss level 672 associated with a channel, but is typically applicable even in cases 673 where direct LM is not. 675 2.7.7. Loss Measurement Scope 677 In the case of direct LM, where data-plane packets are counted, there 678 are different possibilities for which kinds of packets are included 679 in the count and which are excluded. The set of packets counted for 680 LM is called the loss measurement scope. As noted above, one factor 681 affecting the LM scope is whether all data packets are counted or 682 only those belonging to a particular traffic class. Another is 683 whether various "auxiliary" flows associated with a data channel are 684 counted, such as packets flowing over the G-ACh. Implementations 685 SHOULD make their supported LM scopes clear to the user, and care 686 must be taken to ensure that the scopes of the channel endpoints 687 agree. 689 2.7.8. Delay Measurement Accuracy 691 The delay measurement procedures described in this document are 692 designed to facilitate hardware-assisted measurement and to function 693 in the same way whether or not such hardware assistance is used. The 694 main difference in the two cases is one of measurement accuracy. 695 Implementations SHOULD make their delay measurement accuracy levels 696 clear to the user. 698 2.7.9. Delay Measurement Timestamp Format 700 There are two significant timestamp formats in common use: the 701 timestamp format of the Internet standard Network Time Protocol 702 (NTP), described in [RFC5905], and the timestamp format used in the 703 IEEE 1588 Precision Time Protocol (PTP) [IEEE1588]. 705 The NTP format has the advantages of wide use and long deployment in 706 the Internet, and was specifically designed to make the computation 707 of timestamp differences as simple and efficient as possible. On the 708 other hand, there is also now a significant deployment of equipment 709 designed to support the PTP format. 711 The approach taken in this document is therefore to include in DM 712 messages fields which identify the timestamp formats used by the two 713 devices involved in a DM operation. This implies that a node 714 attempting to carry out a DM operation may be faced with the problem 715 of computing with and possibly reconciling different timestamp 716 formats. Support for multiple timestamp formats is OPTIONAL. An 717 implementation SHOULD, however, make clear which timestamp formats it 718 supports and the extent of its support for computation with and 719 reconciliation of different formats for purposes of delay 720 measurement. 722 In recognition of the wide deployment, particularly in hardware-based 723 timing implementations, of IEEE 1588 PTP, the PTP timestamp format is 724 the default format used in DM messages. This format MUST be 725 supported. 727 3. Message Formats 729 Loss Measurement and Delay Measurement messages flow over the MPLS 730 Generic Associated Channel (G-ACh) [RFC5586]. Thus, a packet 731 containing an LM or DM message contains an MPLS label stack, with the 732 G-ACh Label (GAL) at the bottom of the stack. The GAL is followed by 733 an Associated Channel Header (ACH) which identifies the message type, 734 and the message body follows the ACH. 736 This document defines the following ACH Channel Types: 738 MPLS Direct Packet Loss Measurement (DLM) 739 MPLS Inferred Packet Loss Measurement (ILM) 740 MPLS Packet Delay Measurement (DM) 741 MPLS Direct Packet Loss and Delay Measurement (DLM+DM) 742 MPLS Inferred Packet Loss and Delay Measurement (ILM+DM) 744 The message formats for direct and inferred LM are identical, as are 745 the formats for the DLM+DM and ILM+DM messages. 747 For these channel types, the ACH SHALL NOT be followed by the ACH TLV 748 Header defined in [RFC5586]. 750 The fixed-format portion of a message MAY be followed by a block of 751 Type-Length-Value (TLV) fields. The TLV block provides an extensible 752 way of attaching subsidiary information to LM and DM messages. 753 Several such TLV fields are defined below. 755 3.1. Loss Measurement Message Format 757 The format of a Loss Measurement message, which follows the 758 Associated Channel Header (ACH), is as follows: 760 0 1 2 3 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 |Version| Flags | Control Code | Message Length | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | DFlags| OTF | Reserved | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Session Identifier | TC | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Origin Timestamp | 770 | | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Counter 1 | 773 | | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 . . 776 . . 777 . . 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Counter 4 | 780 | | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 ~ TLV Block ~ 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 Figure 2: Loss Measurement Message Format 787 Reserved fields MUST be set to 0 and ignored upon receipt. The 788 possible values for the remaining fields are as follows. 790 Field Meaning 791 ------------------------- ------------------------------------------- 792 Version Protocol version 793 Flags Message control flags 794 Control Code Code identifying the query or response type 795 Message Length Total length of this message in bytes 796 Data Format Flags Flags specifying the format of message data 797 (DFlags) 798 Origin Timestamp Format Format of the Origin Timestamp field 799 (OTF) 800 Reserved Reserved for future specification 801 Session Identifier Set arbitrarily by the querier 802 Traffic Class (TC) TC being measured 803 Origin Timestamp Query message transmission timestamp 804 Counter 1-4 Packet counter values in network byte order 805 TLV Block Optional block of Type-Length-Value fields 807 The possible values for these fields are as follows. 809 Version: Currently set to 0. 811 Flags: The format of the Flags field is shown below. 813 +-+-+-+-+ 814 | Flags | 815 +-+-+-+-+ 817 +-+-+-+-+ 818 |R|T|0|0| 819 +-+-+-+-+ 821 Loss Measurement Message Flags 823 The meanings of the flag bits are: 825 R: Query/Response indicator. Set to 0 for a Query and 1 for a 826 Response. 828 T: Traffic-class-specific measurement indicator. Set to 1 when 829 the measurement operation is scoped to packets of a particular 830 traffic class, and 0 otherwise. When set to 1, the TC field of 831 the message indicates the measured traffic class. 833 0: Set to 0. 835 Control Code: Set as follows according to whether the message is a 836 Query or a Response as identified by the R flag. 838 For a Query: 840 0x0: In-band Response Requested. Indicates that this query has 841 been sent over a bidirectional channel and the response is 842 expected over the same channel. 844 0x1: Out-of-band Response Requested. Indicates that the 845 response should be sent via an out-of-band channel. 847 0x2: No Response Requested. Indicates that no response to the 848 query should be sent. 850 For a Response: 852 Codes 0x0-0xF are reserved for non-error responses. 854 0x1: Success. Indicates that the operation was successful. 856 0x2: Notification - Data Format Invalid. Indicates that the 857 query was processed but the format of the data fields in this 858 response may be inconsistent. Consequently these data fields 859 MUST NOT be used for measurement. 861 0x3: Notification - Initialization In Progress. Indicates that 862 the query was processed but this response does not contain 863 valid measurement data because the responder's initialization 864 process has not completed. 866 0x4: Notification - Data Reset Occurred. Indicates that the 867 query was processed but a reset has recently occurred which may 868 render the data in this response inconsistent relative to 869 earlier responses. 871 0x10: Error - Unspecified Error. Indicates that the operation 872 failed for an unspecified reason. 874 0x11: Error - Unsupported Version. Indicates that the 875 operation failed because the protocol version supplied in the 876 query message is not supported. 878 0x12: Error - Unsupported Control Code. Indicates that the 879 operation failed because the Control Code requested an 880 operation that is not available for this channel. 882 0x13: Error - Unsupported Data Format. Indicates that the 883 operation failed because the data format specified in the query 884 is not supported. 886 0x14: Error - Authentication Failure. Indicates that the 887 operation failed because the authentication data supplied in 888 the query was missing or incorrect. 890 0x15: Error - Invalid Destination Node Identifier. Indicates 891 that the operation failed because the Destination Node 892 Identifier supplied in the query is not an identifier of this 893 node. 895 0x16: Error - Connection Mismatch. Indicates that the 896 operation failed because the channel identifier supplied in the 897 query did not match the channel over which the query was 898 received. 900 0x17: Error - Unsupported Mandatory TLV Object. Indicates that 901 the operation failed because a TLV Object received in the query 902 and marked as mandatory is not supported. 904 0x18: Error - Query Rate Exceeded. Indicates that the 905 operation failed because the query message rate exceeded the 906 configured threshold. 908 0x19: Error - Administrative Block. Indicates that the 909 operation failed because it has been administratively 910 disallowed. 912 0x1A: Error - Temporary Resource Exhaustion. Indicates that 913 the operation failed because node resources were not available. 915 Message Length: Set to the total length of this message in bytes. 917 DFlags: The format of the DFlags field is shown below. 919 +-+-+-+-+ 920 | DFlags| 921 +-+-+-+-+ 923 +-+-+-+-+ 924 |X|B|0|0| 925 +-+-+-+-+ 927 Loss Measurement Message Flags 929 The meanings of the DFlags bits are: 931 X: Extended counter format indicator. Indicates the use of 932 extended (64-bit) counter values. Initialized to 1 upon creation 933 (and prior to transmission) of an LM Query and copied from an LM 934 Query to an LM response. Set to 0 when the LM message is 935 transmitted or received over an interface that writes 32-bit 936 counter values. 938 B: Octet (byte) count. When set to 1, indicates that the Counter 939 1-4 fields represent octet counts. When set to 0, indicates that 940 the Counter 1-4 fields represent packet counts. 942 0: Set to 0. 944 Origin Timestamp Format: The format of the Origin Timestamp field, as 945 specified in Section 3.4. 947 Session Identifier: Set arbitrarily in a query and copied in the 948 response, if any. 950 TC: When the T flag is set to 1, this field is set to the TC being 951 measured. When the T flag is set to 0, the value of this field is 952 arbitrary, and the field can be considered part of the Session 953 Identifier. 955 Origin Timestamp: Timestamp recording the transmit time of the query 956 message. 958 Counter 1-4: Referring to Section 2.1, when a query is sent from A, 959 Counter 1 is set to A_TxP and the other counter fields are set to 0. 960 When the query is received at B, Counter 2 is set to B_RxP. At this 961 point, B copies Counter 1 to Counter 3 and Counter 2 to Counter 4, 962 and re-initializes Counter 1 and Counter 2 to 0. When B transmits 963 the response, Counter 1 is set to B_TxP. When the response is 964 received at A, Counter 2 is set to A_RxP. 966 The mapping of counter types such as A_TxP to the counter fields 1-4 967 is designed to ensure that transmit counter values are always written 968 at the same fixed offset in the packet, and likewise for receive 969 counters. This property is important for hardware processing. 971 All counter values MUST be in network byte order. When a 32-bit 972 counter value is written to one of the counter fields, that value 973 SHALL be written to the low-order 32 bits of the field; the high- 974 order 32 bits of the field MUST, in this case, be set to 0. 976 TLV Block: Zero or more TLV fields. 978 3.2. Delay Measurement Message Format 980 The format of a Delay Measurement message, which follows the 981 Associated Channel Header (ACH), is as follows: 983 0 1 2 3 984 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 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 |Version| Flags | Control Code | Message Length | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | QTF | RTF | RPTF | Reserved | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | Session Identifier | TC | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Timestamp 1 | 993 | | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 . . 996 . . 997 . . 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | Timestamp 4 | 1000 | | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 ~ TLV Block ~ 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 Figure 3: Delay Measurement Message Format 1007 The meanings of the fields are summarized in the following table. 1009 Field Meaning 1010 --------------------- ------------------------------------------- 1011 Version Protocol version 1012 Flags Message control flags 1013 Control Code Code identifying the query or response type 1014 Message Length Total length of this message in bytes 1015 QTF Querier timestamp format 1016 RTF Responder timestamp format 1017 RPTF Responder's preferred timestamp format 1018 Reserved Reserved for future specification 1019 Session Identifier Set arbitrarily by the querier 1020 Traffic Class (TC) TC being measured 1021 Timestamp 1-4 64-bit timestamp values 1022 TLV Block Optional block of Type-Length-Value fields 1024 Reserved fields MUST be set to 0 and ignored upon receipt. The 1025 possible values for the remaining fields are as follows. 1027 Version: Currently set to 0. 1029 Flags: As specified in Section 3.1, except for the X flag, which is 1030 set to 0, and the T flag, which is set to 1. 1032 Control Code: As specified in Section 3.1. 1034 Message Length: Set to the total length of this message in bytes. 1036 Querier Timestamp Format: The format of the timestamp values written 1037 by the querier, as specified in Section 3.4. 1039 Responder Timestamp Format: The format of the timestamp values 1040 written by the responder, as specified in Section 3.4. 1042 Responder's Preferred Timestamp Format: The timestamp format 1043 preferred by the responder, as specified in Section 3.4. 1045 Session Identifier: As specified in Section 3.1. 1047 TC: Set to the TC being measured. 1049 Timestamp 1-4: Referring to Section 2.3, when a query is sent from A, 1050 Timestamp 1 is set to T1 and the other timestamp fields are set to 0. 1051 When the query is received at B, Timestamp 2 is set to T2. At this 1052 point, B copies Timestamp 1 to Timestamp 3 and Timestamp 2 to 1053 Timestamp 4, and re-initializes Timestamp 1 and Timestamp 2 to 0. 1054 When B transmits the response, Timestamp 1 is set to T3. When the 1055 response is received at A, Timestamp 2 is set to T4. The actual 1056 formats of the timestamp fields written by A and B are indicated by 1057 the Querier Timestamp Format and Responder Timestamp Format fields 1058 respectively. 1060 The mapping of timestamps to the timestamp fields 1-4 is designed to 1061 ensure that transmit timestamps are always written at the same fixed 1062 offset in the packet, and likewise for receive timestamps. This 1063 property is important for hardware processing. 1065 TLV Block: Zero or more TLV fields. 1067 3.3. Combined Loss/Delay Measurement Message Format 1069 The format of a combined Loss and Delay Measurement message, which 1070 follows the Associated Channel Header (ACH), is as follows: 1072 0 1 2 3 1073 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 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 |Version| Flags | Control Code | Message Length | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | DFlags| QTF | RTF | RPTF | Reserved | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | Session Identifier | TC | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | Timestamp 1 | 1082 | | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 . . 1085 . . 1086 . . 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | Timestamp 4 | 1089 | | 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | Counter 1 | 1092 | | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 . . 1095 . . 1096 . . 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | Counter 4 | 1099 | | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 ~ TLV Block ~ 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 Figure 4: Loss/Delay Measurement Message Format 1106 The LM/DM message fields have the same meanings as the corresponding 1107 fields in the LM and DM message formats. 1109 3.4. Timestamp Field Formats 1111 The following timestamp format field values are specified in this 1112 document: 1114 0x0: Null timestamp format. This value is a placeholder 1115 indicating that the timestamp field does not contain a meaningful 1116 timestamp. 1118 0x1: Sequence number. This value indicates that the timestamp 1119 field is to be viewed as a simple 64-bit sequence number. 1121 0x2: Network Time Protocol version 4 64-bit timestamp format 1122 [RFC5905]. This format consists of a 32-bit seconds field 1123 followed by a 32-bit fractional seconds field, so that it can be 1124 regarded as a fixed-point 64-bit quantity. 1126 0x3: IEEE 1588-2002 (1588v1) Precision Time Protocol timestamp 1127 format [IEEE1588]. This format consists of a 32-bit seconds field 1128 followed by a 32-bit nanoseconds field. 1130 In recognition of the wide deployment, particularly in hardware-based 1131 timing implementations, of IEEE 1588 PTP, the PTP timestamp format is 1132 the default format used in Delay Measurement messages. This format 1133 MUST be supported. Support for other timestamp formats is OPTIONAL. 1135 Timestamp formats of n < 64 bits in size SHALL be encoded in the 64- 1136 bit timestamp fields specified in this document using the n high- 1137 order bits of the field. The remaining 64 - n low-order bits in the 1138 field SHOULD be set to 0 and MUST be ignored when reading the field. 1140 3.5. TLV Objects 1142 The TLV Block in LM and DM messages consists of zero or more objects 1143 with the following format: 1145 0 1 2 3 1146 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 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | Type | Length | Value ~ 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 TLV Format 1153 The Type and Length fields are each 8 bits long, and the Length field 1154 indicates the size in bytes of the Value field, which can therefore 1155 be up to 255 bytes long. 1157 The Type space is divided into Mandatory and Optional subspaces: 1159 Type Range Semantics 1160 -------------- --------- 1161 0-127 Mandatory 1162 128-255 Optional 1164 Upon receipt of a query message including an unrecognized mandatory 1165 TLV object, the recipient MUST discard the message or respond with an 1166 appropriate error code. 1168 The types defined are as follows: 1170 Type Definition 1171 -------------- --------------------------------- 1172 Mandatory 1173 0 Padding - copy in response 1174 1 Return Address 1175 2-119 Reserved 1176 120-127 Vendor-specific usage 1178 Optional 1179 128 Padding - do not copy in response 1180 129 Destination Address 1181 130 Source Address 1182 131-247 Reserved 1183 248-255 Vendor-specific usage 1185 3.5.1. Padding 1187 The two padding objects permit the augmentation of packet size; this 1188 is mainly useful for delay measurement. The type of padding 1189 indicates whether the padding supplied by the querier is to be copied 1190 to, or omitted from, the response. More than one padding object MAY 1191 be present, in which case they SHOULD be continguous. Padding 1192 objects SHOULD occur at the end of the TLV Block. The Value field of 1193 a padding object is arbitrary. 1195 3.5.2. Addressing 1197 The addressing objects have the following format: 1199 0 1 2 3 1200 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 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | Type | Length | AType | Reserved | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 ~ Address ~ 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 Addressing Object Format 1209 The AType (Address Type) field indicates the type of the address. 1210 Address types defined are: 1212 Type Definition 1213 ------- -------------------- 1214 0 IP version 4 address 1215 1 IP version 6 address 1217 The Source and Destination address objects indicate the addresses of 1218 the sender and the intended recipient of the message, respectively. 1219 The Source Address SHOULD be used as the destination for out-of-band 1220 responses unless some other out-of-band response mechanism has been 1221 configured, and unless a Return Address object is present, in which 1222 case the Return Address specifies the target of the response. 1224 4. Operation 1226 4.1. Loss Measurement Procedures 1228 4.1.1. Initiating a Loss Measurement Operation 1230 An LM operation for a particular channel consists of sending a 1231 sequence (LM[1], LM[2], ...) of LM query messages over the channel at 1232 a specific rate and processing the responses received, if any. As 1233 described in Section 2.1, the packet loss associated with the channel 1234 during the operation is computed as a delta between successive 1235 messages; these deltas can be accumulated to obtain a running total 1236 of the packet loss for the channel. 1238 The query message transmission rate MUST be sufficiently high, given 1239 the LM message counter size (which can be either 32 or 64 bits) and 1240 the speed and minimum packet size of the underlying channel, that the 1241 ambiguity condition noted in Section 2.1 cannot arise. The 1242 implementation SHOULD assume, in evaluating this rate, that the 1243 counter size is 32 bits unless explicitly configured otherwise, or 1244 unless (in the case of a bidirectional channel) all local and remote 1245 interfaces involved in the LM operation are known to be 64-bit- 1246 capable, which can be inferred from the value of the X flag in an LM 1247 response. 1249 When initiating an LM operation, the far end may require a period of 1250 time to become ready for the requested measurement operation. During 1251 this period, LM queries MAY simply be discarded, and the querier 1252 expecting a response SHOULD be prepared for this situation, for 1253 example by setting a timer to differentiate between an acceptable 1254 initialization delay and a permanent unavailability condition at the 1255 far end. Alternatively, the receiver MAY respond, possibly in a 1256 rate-limited manner, to queries received during this period with an 1257 appropriate notification code. 1259 4.1.2. Transmitting a Loss Measurement Query 1261 When transmitting an LM Query over a channel, the Version field MUST 1262 be set to 0. The R flag MUST be set to 0. The T flag SHALL be set 1263 to 1 if, and only if, the measurement is specific to a particular 1264 traffic class, in which case the TC field SHALL identify that traffic 1265 class. 1267 The X flag MUST be set to 1 if the transmitting interface writes 64- 1268 bit LM counters, and otherwise MUST be set to 0 to indicate that 32- 1269 bit counters are written. The B flag SHALL be set to 1 to indicate 1270 that the counter fields contain octet counts, or to 0 to indicate 1271 packet counts. 1273 The Control Code field MUST be set to one of the values for Query 1274 messages listed in Section 3.1; if the channel is unidirectional, 1275 this field MUST NOT be set to 0x0 (Query: in-band response 1276 requested). 1278 The Session Identifier field can be set arbitrarily. 1280 The Origin Timestamp field SHOULD be set to the time at which this 1281 message is transmitted, and the Origin Timestamp Format field MUST be 1282 set to indicate its format, according to Section 3.4. 1284 The Counter 1 field SHOULD be set to the total count of units 1285 (packets or octets, according to the B flag) transmitted over the 1286 channel prior to this LM Query. The remaining Counter fields MUST be 1287 set to 0. 1289 4.1.3. Receiving a Loss Measurement Query 1291 Upon receipt of an LM Query message, the Counter 2 field SHOULD be 1292 set to the total count of units (packets or octets, according to the 1293 B flag) received over the channel prior to this LM Query. If the 1294 receiving interface writes 32-bit LM counters, the X flag MUST be set 1295 to 0. 1297 At this point the LM Query message must be inspected. If the Control 1298 Code field is set to 0x2 (no response requested), an LM Response 1299 message MUST NOT be transmitted. If the Control Code field is set to 1300 0x0 (in-band response requested) or 0x1 (out-of-band response 1301 requested), then an in-band or out-of-band response, respectively, 1302 SHOULD be transmitted unless this has been prevented by an 1303 administrative, security or congestion control mechanism. 1305 4.1.4. Transmitting a Loss Measurement Response 1307 When constructing a Response to an LM Query, the Version field MUST 1308 be set to 0. The R flag MUST be set to 1. The value of the T flag 1309 MUST be copied from the LM Query, and if the value of the T flag is 1310 1, the value of the TC field MUST also be copied. 1312 The X flag MUST be set to 0 if the transmitting interface writes 32- 1313 bit LM counters; otherwise its value MUST be copied from the LM 1314 Query. The B flag MUST be copied from the LM Query. 1316 The Session Identifier, Origin Timestamp, and Origin Timestamp Format 1317 fields MUST be copied from the LM Query. The Counter 1 and Counter 2 1318 fields from the LM Query MUST be copied to the Counter 3 and Counter 1319 4 fields, respectively, of the LM Response. 1321 The Control Code field MUST be set to one of the values for Response 1322 messages listed in Section 3.1. The value 0x10 (Unspecified Error) 1323 SHOULD NOT be used if one of the other more specific error codes is 1324 applicable. 1326 If the response is transmitted in-band, the Counter 1 field SHOULD be 1327 set to the total count of units transmitted over the channel prior to 1328 this LM Response. If the response is transmitted out-of-band, the 1329 Counter 1 field MUST be set to 0. In either case, the Counter 2 1330 field MUST be set to 0. 1332 4.1.5. Receiving a Loss Measurement Response 1334 Upon in-band receipt of an LM Response message, the Counter 2 field 1335 SHOULD be set to the total count of units received over the channel 1336 prior to this LM Response. If the receiving interface writes 32-bit 1337 LM counters, the X flag MUST be set to 0. 1339 Upon out-of-band receipt of an LM Response message, the Counter 1 and 1340 Counter 2 fields MUST NOT be used for purposes of loss measurement. 1342 If the Control Code in an LM Response is anything other than 0x1 1343 (Success), the counter values in the response MUST NOT be used for 1344 purposes of loss measurement. When the Control Code indicates an 1345 error condition, the LM operation SHOULD be suspended and an 1346 appropriate notification to the user generated. If a temporary error 1347 condition is indicated, the LM operation MAY be restarted 1348 automatically. 1350 4.1.6. Loss Calculation 1352 Calculation of packet loss is carried out according to the procedures 1353 in Section 2.1. The X flag in an LM message informs the device 1354 performing the calculation whether to perform 32-bit or 64-bit 1355 arithmetic. If the flag value is equal to 1, all interfaces involved 1356 in the LM operation have written 64-bit counter values, and 64-bit 1357 arithmetic can be used. If the flag value is equal to 0, at least 1358 one interface involved in the operation has written a 32-bit counter 1359 value, and 32-bit arithmetic is carried out using the low-order 32 1360 bits of each counter value. 1362 Note that the semantics of the X flag allow all devices to 1363 interoperate regardless of their counter size support. Thus, an 1364 implementation MUST NOT generate an error response based on the value 1365 of this flag. 1367 4.1.7. Quality of Service 1369 The TC field of the LSE corresponding to the channel (e.g. LSP) 1370 being measured SHOULD be set to a traffic class equal to or better 1371 than the best TC within the measurement scope to minimize the chance 1372 of out-of-order conditions. 1374 4.1.8. G-ACh Packets 1376 By default, direct LM MUST exclude packets transmitted and received 1377 over the Generic Associated Channel (G-ACh). An implementation MAY 1378 provide the means to alter the direct LM scope to include some or all 1379 G-ACh messages. Care must be taken when altering the LM scope to 1380 ensure that both endpoints are in agreement. 1382 4.1.9. Test Messages 1384 In the case of inferred LM, the packets counted for LM consist of 1385 test messages generated for this purpose, or of some other class of 1386 packets deemed to provide a good proxy for data packets flowing over 1387 the channel. The specification of test protocols and proxy packets 1388 is outside the scope of this document. 1390 An identifier common to both the test or proxy messages and the LM 1391 messages may be required to make correlation possible. The combined 1392 value of the Session Identifier and TC fields SHOULD be used for this 1393 purpose when possible. That is, test messages in this case will 1394 include a 32-bit field which can carry the value of the combined 1395 Session Identifier + TC field present in LM messages. When TC- 1396 specific LM is conducted, the TC field of the LSE in the label stack 1397 of a test message corresponding to the channel (e.g. LSP) over which 1398 the message is sent MUST equal the TC value in the associated LM 1399 messages. 1401 4.1.10. Message Loss and Packet Misorder Conditions 1403 Because an LM operation consists of a message sequence with state 1404 maintained from one message to the next, LM is subject to the effects 1405 of lost messages and misordered packets in a way that DM is not. 1406 Because this state exists only on the querier, the handling of these 1407 conditions is, strictly speaking, a local matter. This section, 1408 however, presents recommended procedures for handling such 1409 conditions. 1411 The first kind of anomaly that may occur is that one or more LM 1412 messages may be lost in transit. The effect of such loss is that 1413 when an LM Response is next received at the querier, an unambiguous 1414 interpretation of the counter values it contains may be impossible, 1415 for the reasons described at the end of Section 2.1. Whether this is 1416 so depends on the number of messages lost and the other variables 1417 mentioned in that section, such as the LM message rate and the 1418 channel parameters. 1420 Another possibility is that LM messages are misordered in transit, so 1421 that for instance the response to LM[n] is received prior to the 1422 response to LM[n-1]. A typical implementation will discard the late 1423 response to LM[n-1], so that the effect is the same as the case of a 1424 lost message. 1426 Finally, LM is subject to the possibility that data packets are 1427 misordered relative to LM messages. This condition can result, for 1428 example, in a transmit count of 100 and a corresponding receive count 1429 of 101. The effect here is that the A_TxLoss[n-1,n] value (for 1430 example) for a given measurement interval will appear to be extremely 1431 (if not impossibly) large. The other case, where an LM message 1432 arrives earlier than some of the packets, simply results in those 1433 packets being counted as lost, which is usually what is desired. 1435 An implementation SHOULD identify a threshold value that indicates 1436 the upper bound of lost packets measured in a single computation 1437 beyond which the interval is considered unmeasurable. This is called 1438 the MaxLMIntervalLoss threshold. It is clear that this threshold 1439 should be no higher than the maximum number of packets (or bytes) the 1440 channel is capable of transmitting over the interval, but it may be 1441 lower. Upon encountering an unmeasurable interval, the LM state 1442 (i.e. data values from the last LM message received) SHOULD be 1443 discarded. 1445 With regard to lost LM messages, the MaxLMInterval (see Section 2.1) 1446 indicates the maximum amount of time that can elapse before the LM 1447 state is discarded. If some messages are lost, but a message is 1448 subsequently received within MaxLMInterval, its timestamp or sequence 1449 number will quantify the loss, and it MAY still be used for 1450 measurement, although the measurement interval will in this case be 1451 longer than usual. 1453 If an LM message is received that has a timestamp less than or equal 1454 to the timestamp of the last LM message received, this indicates that 1455 an exception has occurred, and the current interval SHOULD be 1456 considered unmeasurable unless the implementation has some other way 1457 of handling this condition. 1459 4.2. Delay Measurement Procedures 1461 4.2.1. Transmitting a Delay Measurement Query 1463 When transmitting a DM Query over a channel, the Version and Reserved 1464 fields MUST be set to 0. The R flag MUST be set to 0, the T flag 1465 MUST be set to 1, and the remaining flag bits MUST be set to 0. 1467 The Control Code field MUST be set to one of the values for Query 1468 messages listed in Section 3.1; if the channel is unidirectional, 1469 this field MUST NOT be set to 0x0 (Query: in-band response 1470 requested). 1472 The Querier Timestamp Format field MUST be set to the timestamp 1473 format used by the querier when writing timestamp fields in this 1474 message; the possible values for this field are listed in 1475 Section 3.4. The Responder Timestamp Format and Responder's 1476 Preferred Timestamp Format fields MUST be set to 0. 1478 The Session Identifier field can be set arbitrarily. The TC field 1479 MUST be set to the traffic class being measured. 1481 The Timestamp 1 field SHOULD be set to the time at which this DM 1482 Query is transmitted, in the format indicated by the Querier 1483 Timestamp Format field. The other timestamp fields MUST be set to 0. 1485 4.2.2. Receiving a Delay Measurement Query 1487 Upon receipt of a DM Query message, the Timestamp 2 field SHOULD be 1488 set to the time at which this DM Query is received. 1490 At this point the DM Query message must be inspected. If the Control 1491 Code field is set to 0x2 (no response requested), a DM Response 1492 message MUST NOT be transmitted. If the Control Code field is set to 1493 0x0 (in-band response requested) or 0x1 (out-of-band response 1494 requested), then an in-band or out-of-band response, respectively, 1495 SHOULD be transmitted unless this has been prevented by an 1496 administrative, security or congestion control mechanism. 1498 4.2.3. Transmitting a Delay Measurement Response 1500 When constructing a Response to a DM Query, the Version and Reserved 1501 fields MUST be set to 0. The R flag MUST be set to 1, the T flag 1502 MUST be set to 1, and the remaining flag bits MUST be set to 0. 1504 The Session Identifier, TC, and Querier Timestamp Format (QTF) fields 1505 MUST be copied from the DM Query. The Timestamp 1 and Timestamp 2 1506 fields from the DM Query MUST be copied to the Timestamp 3 and 1507 Timestamp 4 fields, respectively, of the DM Response. 1509 The Responder Timestamp Format (RTF) field MUST be set to the 1510 timestamp format used by the responder when writing timestamp fields 1511 in this message, i.e. Timestamp 4 and (if applicable) Timestamp 1; 1512 the possible values for this field are listed in Section 3.4. 1513 Furthermore, the RTF field MUST be set equal either to the QTF or the 1514 RPTF field. See Section 4.2.5 for guidelines on selection of the 1515 value for this field. 1517 The Responder's Preferred Timestamp Format (RPTF) field MUST be set 1518 to one of the values listed in Section 3.4 and SHOULD be set to 1519 indicate the timestamp format with which the responder can provide 1520 the best accuracy for purposes of delay measurement. 1522 The Control Code field MUST be set to one of the values for Response 1523 messages listed in Section 3.1. The value 0x10 (Unspecified Error) 1524 SHOULD NOT be used if one of the other more specific error codes is 1525 applicable. 1527 If the response is transmitted in-band, the Timestamp 1 field SHOULD 1528 be set to the time at which this DM Response is transmitted. If the 1529 response is transmitted out-of-band, the Timestamp 1 field MUST be 1530 set to 0. In either case, the Timestamp 2 field MUST be set to 0. 1532 If the response is transmitted in-band and the Control Code in the 1533 message is 0x1 (Success), then the Timestamp 1 and Timestamp 4 fields 1534 MUST have the same format, which will be the format indicated in the 1535 Responder Timestamp Format field. 1537 4.2.4. Receiving a Delay Measurement Response 1539 Upon in-band receipt of a DM Response message, the Timestamp 2 field 1540 SHOULD be set to the time at which this DM Response is received. 1542 Upon out-of-band receipt of a DM Response message, the Timestamp 1 1543 and Timestamp 2 fields MUST NOT be used for purposes of delay 1544 measurement. 1546 If the Control Code in a DM Response is anything other than 0x1 1547 (Success), the timestamp values in the response MUST NOT be used for 1548 purposes of delay measurement. When the Control Code indicates an 1549 error condition, an appropriate notification to the user SHOULD be 1550 generated. 1552 4.2.5. Timestamp Format Negotiation 1554 In case either the querier or the responder in a DM transaction is 1555 capable of supporting multiple timestamp formats, it is desirable to 1556 determine the optimal format for purposes of delay measurement on a 1557 particular channel. The procedures for making this determination 1558 SHALL be as follows. 1560 Upon sending an initial DM Query over a channel, the querier sets the 1561 Querier Timestamp Format (QTF) field to its preferred timestamp 1562 format. 1564 Upon receiving any DM Query message, the responder determines whether 1565 it is capable of writing timestamps in the format specified by the 1566 QTF field. If so, the Responder Timestamp Format (RTF) field is set 1567 equal to the QTF field. If not, the RTF field is set equal to the 1568 Responder's Preferred Timestamp Format (RPTF) field. 1570 The process of changing from one timestamp format to another at the 1571 responder may result in the Timestamp 1 and Timestamp 4 fields in an 1572 in-band DM Response having different formats. If this is the case, 1573 the Control Code in the response MUST NOT be set to 0x1 (Success). 1574 Unless an error condition has occurred, the Control Code MUST be set 1575 to 0x2 (Notification - Data Format Invalid). 1577 Upon receiving a DM Response, the querier knows from the RTF field in 1578 the message whether the responder is capable of supporting its 1579 preferred timestamp format: if it is, the RTF will be equal to the 1580 QTF. The querier also knows the responder's preferred timestamp 1581 format from the RPTF field. The querier can then decide whether to 1582 retain its current QTF or to change it and repeat the negotiation 1583 procedures. 1585 4.2.5.1. Single-Format Procedures 1587 When an implementation supports only one timestamp format, the 1588 procedures above reduce to the following simple behavior: 1590 o All DM Queries are transmitted with the same QTF; 1592 o All DM Responses are transmitted with the same RTF, and the RPTF 1593 is always set equal to the RTF; 1595 o All DM Responses received with RTF not equal to QTF are discarded; 1597 o On a unidirectional channel, all DM Queries received with QTF not 1598 equal to the supported format are discarded. 1600 4.2.6. Quality of Service 1602 The TC field of the LSE corresponding to the channel (e.g. LSP) 1603 being measured MUST be set equal to the value of the TC field in the 1604 DM message. 1606 4.3. Combined Loss/Delay Measurement Procedures 1608 The combined LM/DM message defined in Section 3.3 allows loss and 1609 delay measurement to be carried out simultaneously. This message 1610 SHOULD be treated as an LM message which happens to carry additional 1611 timestamp data, with the timestamp fields processed as per delay 1612 measurement procedures. 1614 5. Congestion Considerations 1616 An MPLS network may be traffic-engineered in such a way that the 1617 bandwidth required both for client traffic and for control, 1618 management and OAM traffic is always available. The following 1619 congestion considerations therefore apply only when this is not the 1620 case. 1622 The proactive generation of Loss Measurement and Delay Measurement 1623 messages for purposes of monitoring the performance of an MPLS 1624 channel naturally results in a degree of additional load placed on 1625 both the network and the terminal nodes of the channel. When 1626 configuring such monitoring, operators should be mindful of the 1627 overhead involved and should choose transmit rates that do not stress 1628 network resources unduly; such choices must be informed by the 1629 deployment context. In case of slower links or lower-speed devices, 1630 for example, lower Loss Measurement message rates can be chosen, up 1631 to the limits noted at the end of Section 2.1. 1633 In general, lower measurement message rates place less load on the 1634 network at the expense of reduced granularity. For delay measurement 1635 this reduced granularity translates to a greater possibility that the 1636 delay associated with a channel temporarily exceeds the expected 1637 threshold without detection. For loss measurement, it translates to 1638 a larger gap in loss information in case of exceptional circumstances 1639 such as lost LM messages or misordered packets. 1641 When carrying out a sustained measurement operation such as an LM 1642 operation or continuous pro-active DM operation, the querier SHOULD 1643 take note of the number of lost measurement messages (queries for 1644 which a response is never received) and set a corresponding 1645 Measurement Message Loss Threshold. If this threshold is exceeded, 1646 the measurement operation SHOULD be suspended so as not to exacerbate 1647 the possible congestion condition. This suspension SHOULD be 1648 accompanied by an appropriate notification to the user so that the 1649 condition can be investigated and corrected. 1651 From the receiver perspective, the main consideration is the 1652 possibility of receiving an excessive quantity of measurement 1653 messages. An implementation SHOULD employ a mechanism such as rate- 1654 limiting to guard against the effects of this case. Authentication 1655 procedures can also be used to ensure that only queries from 1656 authorized devices are processed. 1658 6. Security Considerations 1660 There are three main types of security considerations associated with 1661 the exchange of performance monitoring messages such as those 1662 described in this document: the possibility of a malicious or 1663 misconfigured device generating an excessive quantity of messages, 1664 causing service impairment; the possibility of unauthorized 1665 alteration of messages in transit; and the possibility of an 1666 unauthorized device learning the data contained in or implied by such 1667 messages. 1669 The first consideration is discussed in Section 5. If reception or 1670 alteration of performance-related data by unauthorized devices is an 1671 operational concern, authentication and/or encryption procedures 1672 should be used to ensure message integrity and confidentiality. Such 1673 procedures are outside the scope of this document, but have general 1674 applicability to OAM protocols in MPLS-TP networks. 1676 7. IANA Considerations 1678 A future version of this document will detail IANA considerations 1679 for: 1681 o ACH Channel Types for LM and DM messages 1682 o Timestamp format registry 1684 o LM and DM Control Codes 1686 o TLV Objects 1688 8. Acknowledgments 1690 The authors wish to thank the many participants of the MPLS working 1691 group who provided detailed review and feedback on this document. 1692 The authors offer special thanks to Alexander Vainshtein, Loa 1693 Andersson, and Hiroyuki Takagi for many helpful thoughts and 1694 discussions, and to Linda Dunbar for the idea of using LM messages 1695 for throughput measurement. 1697 9. References 1699 9.1. Normative References 1701 [IEEE1588] 1702 IEEE, "1588-2008 IEEE Standard for a Precision Clock 1703 Synchronization Protocol for Networked Measurement and 1704 Control Systems", March 2008. 1706 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1707 Requirement Levels", BCP 14, RFC 2119, March 1997. 1709 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1710 Label Switching Architecture", RFC 3031, January 2001. 1712 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 1713 Associated Channel", RFC 5586, June 2009. 1715 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1716 Time Protocol Version 4: Protocol and Algorithms 1717 Specification", RFC 5905, June 2010. 1719 9.2. Informative References 1721 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1722 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1723 Tunnels", RFC 3209, December 2001. 1725 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 1726 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 1727 Protocol Label Switching (MPLS) Support of Differentiated 1728 Services", RFC 3270, May 2002. 1730 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1731 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1732 November 2002. 1734 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 1735 Edge (PWE3) Architecture", RFC 3985, March 2005. 1737 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 1738 Cost Multipath Treatment in MPLS Networks", BCP 128, 1739 RFC 4928, June 2007. 1741 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1742 Specification", RFC 5036, October 2007. 1744 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 1745 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 1746 Class" Field", RFC 5462, February 2009. 1748 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 1749 "Bidirectional Forwarding Detection (BFD) for MPLS Label 1750 Switched Paths (LSPs)", RFC 5884, June 2010. 1752 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 1753 Berger, "A Framework for MPLS in Transport Networks", 1754 RFC 5921, July 2010. 1756 [RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport 1757 Profile Data Plane Architecture", RFC 5960, August 2010. 1759 Authors' Addresses 1761 Dan Frost (editor) 1762 Cisco Systems 1764 Email: danfrost@cisco.com 1766 Stewart Bryant (editor) 1767 Cisco Systems 1769 Email: stbryant@cisco.com