idnits 2.17.1 draft-ietf-mpls-loss-delay-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 810 has weird spacing: '...) Field meas...' == Line 1025 has weird spacing: '...) Field meas...' -- The document date (February 4, 2011) is 4829 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 1262 -- Looks like a reference, but probably isn't: '2' on line 1262 -- Looks like a reference, but probably isn't: '3' on line 334 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1588' -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) Summary: 0 errors (**), 0 flaws (~~), 3 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: August 8, 2011 February 4, 2011 7 Packet Loss and Delay Measurement for MPLS Networks 8 draft-ietf-mpls-loss-delay-01 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 August 8, 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. 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. Different Transmit and Receive Interfaces . . . . . . 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 3.5.3. Session Query Interval . . . . . . . . . . . . . . . . 28 90 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 28 91 4.1. Loss Measurement Procedures . . . . . . . . . . . . . . . 28 92 4.1.1. Initiating a Loss Measurement Operation . . . . . . . 28 93 4.1.2. Transmitting a Loss Measurement Query . . . . . . . . 29 94 4.1.3. Receiving a Loss Measurement Query . . . . . . . . . . 30 95 4.1.4. Transmitting a Loss Measurement Response . . . . . . . 30 96 4.1.5. Receiving a Loss Measurement Response . . . . . . . . 31 97 4.1.6. Loss Calculation . . . . . . . . . . . . . . . . . . . 31 98 4.1.7. Quality of Service . . . . . . . . . . . . . . . . . . 31 99 4.1.8. G-ACh Packets . . . . . . . . . . . . . . . . . . . . 31 100 4.1.9. Test Messages . . . . . . . . . . . . . . . . . . . . 32 101 4.1.10. Message Loss and Packet Misorder Conditions . . . . . 32 102 4.2. Delay Measurement Procedures . . . . . . . . . . . . . . . 33 103 4.2.1. Transmitting a Delay Measurement Query . . . . . . . . 33 104 4.2.2. Receiving a Delay Measurement Query . . . . . . . . . 34 105 4.2.3. Transmitting a Delay Measurement Response . . . . . . 34 106 4.2.4. Receiving a Delay Measurement Response . . . . . . . . 35 107 4.2.5. Timestamp Format Negotiation . . . . . . . . . . . . . 35 108 4.2.6. Quality of Service . . . . . . . . . . . . . . . . . . 36 109 4.3. Combined Loss/Delay Measurement Procedures . . . . . . . . 36 110 5. Congestion Considerations . . . . . . . . . . . . . . . . . . 36 111 6. Security Considerations . . . . . . . . . . . . . . . . . . . 37 112 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 113 7.1. Allocation of PW Associated Channel Types . . . . . . . . 38 114 7.2. Creation of Measurement Timestamp Type Registry . . . . . 39 115 7.3. Creation of MPLS Loss/Delay Measurement Control Code 116 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 39 117 7.4. Creation of MPLS Loss/Delay Measurement TLV Object 118 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 40 119 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 120 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 121 9.1. Normative References . . . . . . . . . . . . . . . . . . . 41 122 9.2. Informative References . . . . . . . . . . . . . . . . . . 42 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 125 1. Introduction 127 Many service provider service level agreements (SLAs) depend on the 128 ability to measure and monitor performance metrics for packet loss 129 and one-way and two-way delay, as well as related metrics such as 130 delay variation and channel throughput. This measurement capability 131 also provides operators with greater visibility into the performance 132 characteristics of their networks, thereby facilitating planning, 133 troubleshooting, and evaluation. This document specifies protocol 134 mechanisms to enable the efficient and accurate measurement of these 135 performance metrics in MPLS networks. 137 This document specifies two closely-related protocols, one for packet 138 loss measurement (LM) and one for packet delay measurement (DM). 139 These protocols have the following characteristics and capabilities: 141 o The LM and DM protocols are intended to be simple and to support 142 efficient hardware processing. 144 o The LM and DM protocols operate over the MPLS Generic Associated 145 Channel (G-ACh) [RFC5586] and support measurement of loss, delay, 146 and related metrics over Label Switched Paths (LSPs), pseudowires, 147 and MPLS sections (links). 149 o The LM and DM protocols are applicable to the LSPs, pseudowires, 150 and sections of networks based on the MPLS Transport Profile 151 (MPLS-TP), because the MPLS-TP is based on a standard MPLS data 152 plane. The MPLS-TP is defined and described in [RFC5921], and 153 MPLS-TP LSPs, pseudowires, and sections are discussed in detail in 154 [RFC5960]. 156 o The LM and DM protocols can be used for both continuous/proactive 157 and selective/on-demand measurement. 159 o The LM and DM protocols use a simple query/response model for 160 bidirectional measurement that allows a single node - the querier 161 - to measure the loss or delay in both directions. 163 o The LM and DM protocols use query messages for unidirectional loss 164 and delay measurement. The measurement can either be carried out 165 at the downstream node(s) or at the querier if an out-of-band 166 return path is available. 168 o The LM and DM protocols do not require that the transmit and 169 receive interfaces be the same when performing bidirectional 170 measurement. 172 o The DM protocol is stateless. 174 o The LM protocol is "almost" stateless: loss is computed as a delta 175 between successive messages, and thus the data associated with the 176 last message received must be retained. 178 o The LM protocol can perform two distinct kinds of loss 179 measurement: it can measure the loss of specially generated test 180 packets in order to infer the approximate data-plane loss level 181 (inferred measurement); or it can directly measure data-plane 182 packet loss (direct measurement). Direct measurement provides 183 perfect loss accounting, but may require specialized hardware 184 support and is only applicable to some LSP types. Inferred 185 measurement provides only approximate loss accounting but is 186 generally applicable. 188 o The LM protocol supports both 32-bit and 64-bit packet counters. 190 o The LM protocol supports measurement in terms of both packet 191 counts and octet counts. 193 o The LM protocol can be used to measure channel throughput as well 194 as packet loss. 196 o The DM protocol supports multiple timestamp formats, and provides 197 a simple means for the two endpoints of a bidirectional connection 198 to agree on a preferred format. This procedure reduces to a 199 triviality for implementations supporting only a single timestamp 200 format. 202 o The DM protocol supports varying the measurement message size in 203 order to measure delays associated with different packet sizes. 205 1.1. Terminology 207 Term Definition 208 ----- ------------------------------------------- 209 ACH Associated Channel Header 210 DM Delay Measurement 211 G-ACh Generic Associated Channel 212 LM Loss Measurement 213 LSE Label Stack Entry 214 LSP Label Switched Path 215 LSR Label Switching Router 216 NTP Network Time Protocol 217 OAM Operations, Administration, and Maintenance 218 PTP Precision Time Protocol 219 PW Pseudowire 220 TC Traffic Class 222 2. Overview 224 This section begins with a summary of the basic methods used for the 225 bidirectional measurement of packet loss and delay. These 226 measurement methods are then described in detail. Finally a list of 227 practical considerations are discussed that may come into play to 228 inform or modify these simple procedures. 230 The following figure shows the reference scenario. 232 T1 T2 233 +-------+/ Query \+-------+ 234 | | - - - - - - - - ->| | 235 | A |===================| B | 236 | |<- - - - - - - - - | | 237 +-------+\ Response /+-------+ 238 T4 T3 240 Figure 1 242 The figure shows a bidirectional channel between two nodes, A and B, 243 and illustrates the temporal reference points T1-T4 associated with a 244 measurement operation that takes place at A. The operation consists 245 of A sending a query message to B, and B sending back a response. 246 Each reference point indicates the point in time at which either the 247 query or the response message is transmitted or received over the 248 channel. 250 In this situation, A can arrange to measure the packet loss over the 251 channel in the forward and reverse directions by sending Loss 252 Measurement (LM) query messages to B each of which contains the count 253 of packets transmitted prior to time T1 over the channel to B 254 (A_TxP). When the message reaches B, it appends two values and 255 reflects the message back to A: the count of packets received prior 256 to time T2 over the channel from A (B_RxP), and the count of packets 257 transmitted prior to time T3 over the channel to A (B_TxP). When the 258 response reaches A, it appends a fourth value, the count of packets 259 received prior to time T4 over the channel from B (A_RxP). 261 These four counter values enable A to compute the desired loss 262 statistics. Because the transmit count at A and the receive count at 263 B (and vice versa) may not be synchronized at the time of the first 264 message, and to limit the effects of counter wrap, the loss is 265 computed in the form of a delta between messages. 267 To measure at A the delay over the channel to B, a Delay Measurement 268 (DM) query message is sent from A to B containing a timestamp 269 recording the instant at which it is transmitted, i.e. T1. When the 270 message reaches B, a timestamp is added recording the instant at 271 which it is received (T2). The message can now be reflected from B 272 to A, with B adding its transmit timestamp (T3) and A adding its 273 receive timestamp (T4). These four timestamps enable A to compute 274 the one-way delay in each direction, as well as the two-way delay for 275 the channel. The one-way delay computations require that the clocks 276 of A and B be synchronized; mechanisms for clock synchronization are 277 outside the scope of this document. 279 2.1. Packet Loss Measurement 281 Suppose a bidirectional channel exists between the nodes A and B. The 282 objective is to measure at A the following two quantities associated 283 with the channel: 285 A_TxLoss (transmit loss): the number of packets transmitted by A 286 over the channel but not received at B; 288 A_RxLoss (receive loss): the number of packets transmitted by B 289 over the channel but not received at A. 291 This is accomplished by initiating a Loss Measurement (LM) operation 292 at A, which consists of transmission of a sequence of LM query 293 messages (LM[1], LM[2], ...) over the channel at a specified rate, 294 such as one every 100 milliseconds. Each message LM[n] contains the 295 following value: 297 A_TxP[n]: the total count of packets transmitted by A over the 298 channel prior to the time this message is transmitted. 300 When such a message is received at B, the following value is recorded 301 in the message: 303 B_RxP[n]: the total count of packets received by B over the 304 channel at the time this message is received (excluding the 305 message itself). 307 At this point, B inserts an appropriate response code into the 308 message and transmits it back to A, recording within it the following 309 value: 311 B_TxP[n]: the total count of packets transmitted by B over the 312 channel prior to the time this response is transmitted. 314 When the message response is received back at A, the following value 315 is recorded in the message: 317 A_RxP[n]: the total count of packets received by A over the 318 channel at the time this response is received (excluding the 319 message itself). 321 The transmit loss A_TxLoss[n-1,n] and receive loss A_RxLoss[n-1,n] 322 within the measurement interval marked by the messages LM[n-1] and 323 LM[n] are computed by A as follows: 325 A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1]) 326 A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1]) 328 where the arithmetic is modulo the counter size. 330 The derived values 332 A_TxLoss = A_TxLoss[1,2] + A_TxLoss[2,3] + ... 334 A_RxLoss = A_RxLoss[1,2] + A_RxLoss[2,3] + ... 336 are updated each time a response to an LM message is received and 337 processed, and represent the total transmit and receive loss over the 338 channel since the LM operation was initiated. 340 When computing the values A_TxLoss[n-1,n] and A_RxLoss[n-1,n] the 341 possibility of counter wrap must be taken into account. Consider for 342 example the values of the A_TxP counter at sequence numbers n-1 and 343 n. Clearly if A_TxP[n] is allowed to wrap to 0 and then beyond to a 344 value equal to or greater than A_TxP[n-1], the computation of an 345 unambiguous A_TxLoss[n-1,n] value will be impossible. Therefore the 346 LM message rate MUST be sufficiently high, given the counter size and 347 the speed and minimum packet size of the underlying channel, that 348 this condition cannot arise. For example, a 32-bit counter for a 100 349 Gbps link with a minimum packet size of 64 bytes can wrap in 2^32 / 350 (10^11/(64*8)) = ~22 seconds, which is therefore an upper bound on 351 the LM message interval under such conditions. This bound will be 352 referred to as the MaxLMInterval of the channel. It is clear that 353 the MaxLMInterval will be a more restrictive constraint in the case 354 of direct LM and for smaller counter sizes. 356 The loss measurement approach described in this section has the 357 characteristic of being stateless at B and "almost" stateless at A. 358 Specifically, A must retain the data associated with the last LM 359 response received, in order to use it to compute loss when the next 360 response arrives. This data MAY be discarded, and MUST NOT be used 361 as a basis for measurement, if MaxLMInterval elapses before the next 362 response arrives, because in this case an unambiguous measurement 363 cannot be made. 365 The foregoing discussion has assumed the counted objects are packets, 366 but this need not be the case. In particular, octets may be counted 367 instead. This will, of course, reduce the MaxLMInterval 368 proportionately. 370 2.2. Throughput Measurement 372 If LM query messages contain a timestamp recording their time of 373 transmission, this data can be combined with the packet or octet 374 counts to yield a measurement of the throughput sustained over the 375 channel during the interval. This metric can be called the delivered 376 throughput. As for loss measurement, the interval counts can be 377 accumulated to arrive at the delivered throughput of the channel 378 since the start of the measurement operation. This procedure also 379 enables out-of-service throughput testing when combined with a simple 380 packet generator. 382 2.3. Delay Measurement 384 Suppose a bidirectional channel exists between the nodes A and B. The 385 objective is to measure at A one or more of the following quantities 386 associated with the channel: 388 o The one-way delay associated with the forward (A to B) direction 389 of the channel; 391 o The one-way delay associated with the reverse (B to A) direction 392 of the channel; 394 o The two-way delay (A to B to A) associated with the channel. 396 The one-way delay metric for packet networks is described in 397 [RFC2679]. Measurement of the one-way delay quantities requires that 398 the clocks of A and B be synchronized, whereas the two-way delay can 399 be measured directly even when this is not the case (provided A and B 400 have stable clocks). 402 In the case of two-way delay, there are actually two possible metrics 403 of interest. The "two-way channel delay" is the sum of the one-way 404 delays in each direction and reflects the delay of the channel 405 itself, irrespective of processing delays within the remote endpoint 406 B. The "round-trip delay" is described in [RFC2681] and includes in 407 addition any delay associated with remote endpoint processing. 409 A measurement is accomplished by sending a Delay Measurement (DM) 410 query message over the channel to B which contains the following 411 timestamp: 413 T1: the time the DM query message is transmitted from A. 415 When the message arrives at B, the following timestamp is recorded in 416 the message: 418 T2: the time the DM query message is received at B. 420 At this point B inserts an appropriate response code into the message 421 and transmits it back to A, recording within it the following 422 timestamp: 424 T3: the time the DM response message is transmitted from B. 426 When the message arrives back at A, the following timestamp is 427 recorded in the message: 429 T4: the time the DM response message is received back at A. 431 At this point, A can compute the two-way channel delay associated 432 with the channel as 434 two-way channel delay = (T4 - T1) - (T3 - T2) 436 and the round-trip delay as 438 round-trip delay = T4 - T1. 440 If the clocks of A and B are known at A to be synchronized, then both 441 one-way delay values, as well as the two-way channel delay, can be 442 computed at A as 443 forward one-way delay = T2 - T1 445 reverse one-way delay = T4 - T3 447 two-way channel delay = forward delay + reverse delay. 449 2.4. Delay Variation Measurement 451 Packet Delay Variation (PDV) [RFC3393] is another performance metric 452 important in some applications. The PDV of a pair of packets within 453 a stream of packets is defined for a selected pair of packets in the 454 stream going from measurement point 1 to measurement point 2. The 455 PDV is the difference between the one-way delay of the selected 456 packets. 458 A PDV measurement can therefore be derived from successive delay 459 measurements obtained through the procedures in Section 2.3. An 460 important point regarding PDV measurement, however, is that it can be 461 carried out based on one-way delay measurements even when the clocks 462 of the two systems involved in those measurements are not 463 synchronized. 465 2.5. Unidirectional Measurement 467 In the case that the channel from A to (B1, ..., Bk) is 468 unidirectional, i.e. is a unidirectional LSP, LM and DM measurements 469 can be carried out at B1, ..., Bk instead of at A. 471 For LM this is accomplished by initiating an LM operation at A and 472 carrying out the same procedures as for bidirectional channels, 473 except that no responses from B1, ..., Bk to A are generated. 474 Instead, each terminal node B uses the A_TxP and B_RxP values in the 475 LM messages it receives to compute the receive loss associated with 476 the channel in essentially the same way as described previously, i.e. 478 B_RxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1]) 480 For DM, of course, only the forward one-way delay can be measured and 481 the clock synchronization requirement applies. 483 Alternatively, if an out-of-band channel from a terminal node B back 484 to A is available, the LM and DM message responses can be 485 communicated to A via this channel so that the measurements can be 486 carried out at A. 488 2.6. Loopback Measurement 490 Some bidirectional channels may be placed into a loopback state such 491 that query messages are looped back to the querier without 492 modification. In this situation, LM and DM procedures can be used to 493 carry out measurements associated with the circular path. 495 For LM, the loss computation in this case is: 497 A_Loss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1]) 499 For DM, the round-trip delay is computed. In this case, however, the 500 remote endpoint processing time component reflects only the time 501 required to loop the message from channel input to channel output. 503 Query messages must include some form of source identifier in order 504 for looped-back queries to be differentiated from queries initiated 505 by the far end. 507 2.7. Measurement Considerations 509 A number of additional considerations apply in practice to the 510 measurement methods summarized above. 512 2.7.1. Types of Channels 514 There are several types of channels in MPLS networks over which loss 515 and delay measurement may be conducted. The channel type may 516 restrict the kinds of measurement that can be performed. In all 517 cases, LM and DM messages flow over the MPLS Generic Associated 518 Channel (G-ACh), which is described in detail in [RFC5586]. 520 Broadly, a channel in an MPLS network may be either a link, a Label 521 Switched Path (LSP) [RFC3031], or a pseudowire [RFC3985]. Links are 522 bidirectional and are also referred to as MPLS sections; see 523 [RFC5586] and [RFC5960]. Pseudowires are bidirectional. Label 524 Switched Paths may be either unidirectional or bidirectional. 526 The LM and DM protocols discussed in this document are initiated from 527 a single node, the querier. A query message may be received either 528 by a single node or by multiple nodes, depending on the nature of the 529 channel. In the latter case these protocols provide point-to- 530 multipoint measurement capabilities. 532 2.7.2. Quality of Service 534 Quality of Service (QoS) capabilities, in the form of the 535 Differentiated Services architecture, apply to MPLS as specified in 537 [RFC3270] and [RFC5462]. Different classes of traffic are 538 distinguished by the three-bit Traffic Class (TC) field of an MPLS 539 Label Stack Entry (LSE). Delay measurement therefore applies on a 540 per-traffic-class basis, and the TC values of LSEs above the G-ACh 541 Label (GAL) that precedes a DM message are significant. Packet loss 542 can be measured with respect either to the channel as a whole or to a 543 specific traffic class. 545 Another aspect of packet processing which often arises in the context 546 of QoS concerns the location of the measurement points for loss and 547 delay within the sending and receiving nodes, which is 548 implementation-dependent. For example, a sending implementation may 549 or may not consider a packet to be "lost", for LM purposes, that was 550 discarded prior to transmission for queuing-related reasons; 551 conversely, a receiving implementation may or may not consider a 552 packet to be "lost", for LM purposes, if it was physically received 553 but discarded during receive-path processing. The location of delay 554 measurement points similarly impacts what, precisely, is being 555 measured. The principal consideration here is that the behavior of 556 an implementation in these respects SHOULD be made clear to the user. 558 2.7.3. Equal Cost Multipath 560 Equal Cost Multipath (ECMP) is the behavior of distributing packets 561 across multiple alternate paths toward a destination. The use of 562 ECMP in MPLS networks is described in BCP 128 [RFC4928]. The typical 563 result of ECMP being performed on an LSP which is subject to delay 564 measurement will be that only the delay of one of the available paths 565 is and can be measured. 567 The effects of ECMP on loss measurement will depend on the LM mode. 568 In the case of direct LM, the measurement will account for any 569 packets lost between the sender and the receiver, regardless of how 570 many paths exist between them. However, the presence of ECMP 571 increases the likelihood of misordering both of LM messages relative 572 to data packets, and of the LM messages themselves. Such 573 misorderings tend to create unmeasurable intervals and thus degrade 574 the accuracy of loss measurement. The effects of ECMP are similar 575 for inferred LM, with the additional caveat that, unless the test 576 packets are specially constructed so as to probe all available paths, 577 the loss characteristics of one or more of the alternate paths cannot 578 be accounted for. 580 2.7.4. Intermediate Nodes 582 In the case of an LSP, it may be desirable to measure the loss or 583 delay to or from an intermediate node as well as between LSP 584 endpoints. This can be done in principle by setting the Time to Live 585 (TTL) field in the outer LSE appropriately when targeting a 586 measurement message to an intermediate node. This procedure may 587 fail, however, if hardware-assisted measurement is in use, because 588 the processing of the packet by the intermediate node occurs only as 589 the result of TTL expiry, and the handling of TTL expiry may occur at 590 a later processing stage in the implementation than the hardware- 591 assisted measurement function. Often the motivation for conducting 592 measurements to intermediate nodes is an attempt to localize a 593 problem that has been detected on the LSP. In this case, if 594 intermediate nodes are not capable of performing hardware-assisted 595 measurement, a less accurate - but usually sufficient - software- 596 based measurement can be conducted instead. 598 2.7.5. Different Transmit and Receive Interfaces 600 The overview of the bidirectional measurement process presented in 601 Section 2 is also applicable when the transmit and receive interfaces 602 at A or B differ from one another. Some additional considerations, 603 however, do apply in this case: 605 o If different clocks are associated with transmit and receive 606 processing, these clocks must be synchronized in order to compute 607 the two-way delay. 609 o The DM protocol specified in this document requires that the 610 timestamp formats used by the interfaces that receive a DM query 611 and transmit a DM response agree. 613 o The LM protocol specified in this document supports both 32-bit 614 and 64-bit counter sizes, but the use of 32-bit counters at any of 615 the up to four interfaces involved in an LM operation will result 616 in 32-bit LM calculations for both directions of the channel. 618 [Editor's note: The last two restrictions could be relaxed if 619 desired, at the expense of some additional protocol complexity.] 621 2.7.6. Loss Measurement Modes 623 The summary of loss measurement at the beginning of Section 2 above 624 made reference to the "count of packets" transmitted and received 625 over a channel. If the counted packets are the packets flowing over 626 the channel in the data plane, the loss measurement is said to 627 operate in "direct mode". If, on the other hand, the counted packets 628 are selected control packets from which the approximate loss 629 characteristics of the channel are being inferred, the loss 630 measurement is said to operate in "inferred mode". 632 Direct LM has the advantage of being able to provide perfect loss 633 accounting when it is available. There are, however, several 634 limitations associated with direct LM. 636 For accurate direct LM to occur, packets must not be sent between the 637 time the transmit count for an outbound LM message is determined and 638 the time the message is actually transmitted. Similarly, packets 639 must not be received and processed between the time an LM message is 640 received and the time the receive count for the message is 641 determined. If these "synchronization conditions" do not hold, the 642 LM message counters will not reflect the true state of the data 643 plane, with the result that, for example, the receive count of B may 644 be greater than the transmit count of A, and attempts to compute loss 645 by taking the difference will yield an invalid result. This 646 requirement for synchronization between LM message counters and the 647 data plane may require special support from hardware-based forwarding 648 implementations. 650 Another limitation of direct LM is that it may be difficult or 651 impossible to apply in cases where the channel is an LSP and the LSP 652 label at the receiver is either nonexistent or fails to identify a 653 unique sending node. The first case happens when Penultimate Hop 654 Popping (PHP) is used on the LSP, and the second case generally holds 655 for LSPs based on the Label Distribution Protocol (LDP) [RFC5036] as 656 opposed to, for example, those based on Traffic Engineering 657 extensions to the Resource Reservation Protocol (RSVP-TE) [RFC3209]. 658 These conditions may make it infeasible for the receiver to identify 659 the data-plane packets associated with a particular source and LSP in 660 order to count them, or to infer the source and LSP context 661 associated with an LM message. 663 Inferred LM works in the same manner as direct LM except that the 664 counted packets are special control packets, called test messages, 665 generated by the sender. Test messages may be either packets 666 explicitly constructed and used for LM or packets with a different 667 primary purpose, such as those associated with a Bidirectional 668 Forwarding Detection (BFD) [RFC5884] session. 670 The synchronization conditions discussed above for direct LM also 671 apply to inferred LM, the only difference being that the required 672 synchronization is now between the LM counters and the test message 673 generation process. Protocol and application designers MUST take 674 these synchronization requirements into account when developing tools 675 for inferred LM, and make their behavior in this regard clear to the 676 user. 678 Inferred LM provides only an approximate view of the loss level 679 associated with a channel, but is typically applicable even in cases 680 where direct LM is not. 682 2.7.7. Loss Measurement Scope 684 In the case of direct LM, where data-plane packets are counted, there 685 are different possibilities for which kinds of packets are included 686 in the count and which are excluded. The set of packets counted for 687 LM is called the loss measurement scope. As noted above, one factor 688 affecting the LM scope is whether all data packets are counted or 689 only those belonging to a particular traffic class. Another is 690 whether various "auxiliary" flows associated with a data channel are 691 counted, such as packets flowing over the G-ACh. Implementations 692 SHOULD make their supported LM scopes clear to the user, and care 693 must be taken to ensure that the scopes of the channel endpoints 694 agree. 696 2.7.8. Delay Measurement Accuracy 698 The delay measurement procedures described in this document are 699 designed to facilitate hardware-assisted measurement and to function 700 in the same way whether or not such hardware assistance is used. The 701 main difference in the two cases is one of measurement accuracy. 702 Implementations SHOULD make their delay measurement accuracy levels 703 clear to the user. 705 2.7.9. Delay Measurement Timestamp Format 707 There are two significant timestamp formats in common use: the 708 timestamp format of the Internet standard Network Time Protocol 709 (NTP), described in [RFC5905], and the timestamp format used in the 710 IEEE 1588 Precision Time Protocol (PTP) [IEEE1588]. 712 The NTP format has the advantages of wide use and long deployment in 713 the Internet, and was specifically designed to make the computation 714 of timestamp differences as simple and efficient as possible. On the 715 other hand, there is also now a significant deployment of equipment 716 designed to support the PTP format. 718 The approach taken in this document is therefore to include in DM 719 messages fields which identify the timestamp formats used by the two 720 devices involved in a DM operation. This implies that a node 721 attempting to carry out a DM operation may be faced with the problem 722 of computing with and possibly reconciling different timestamp 723 formats. Support for multiple timestamp formats is OPTIONAL. An 724 implementation SHOULD, however, make clear which timestamp formats it 725 supports and the extent of its support for computation with and 726 reconciliation of different formats for purposes of delay 727 measurement. 729 In recognition of the wide deployment, particularly in hardware-based 730 timing implementations, of IEEE 1588 PTP, the PTP timestamp format is 731 the default format used in DM messages. This format MUST be 732 supported. 734 3. Message Formats 736 Loss Measurement and Delay Measurement messages flow over the MPLS 737 Generic Associated Channel (G-ACh) [RFC5586]. Thus, a packet 738 containing an LM or DM message contains an MPLS label stack, with the 739 G-ACh Label (GAL) at the bottom of the stack. The GAL is followed by 740 an Associated Channel Header (ACH) which identifies the message type, 741 and the message body follows the ACH. 743 This document defines the following ACH Channel Types: 745 MPLS Direct Packet Loss Measurement (DLM) 746 MPLS Inferred Packet Loss Measurement (ILM) 747 MPLS Packet Delay Measurement (DM) 748 MPLS Direct Packet Loss and Delay Measurement (DLM+DM) 749 MPLS Inferred Packet Loss and Delay Measurement (ILM+DM) 751 The message formats for direct and inferred LM are identical, as are 752 the formats for the DLM+DM and ILM+DM messages. 754 For these channel types, the ACH SHALL NOT be followed by the ACH TLV 755 Header defined in [RFC5586]. 757 The fixed-format portion of a message MAY be followed by a block of 758 Type-Length-Value (TLV) fields. The TLV block provides an extensible 759 way of attaching subsidiary information to LM and DM messages. 760 Several such TLV fields are defined below. 762 3.1. Loss Measurement Message Format 764 The format of a Loss Measurement message, which follows the 765 Associated Channel Header (ACH), is as follows: 767 0 1 2 3 768 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 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 |Version| Flags | Control Code | Message Length | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | DFlags| OTF | Reserved | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Session Identifier | DS | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Origin Timestamp | 777 | | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Counter 1 | 780 | | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 . . 783 . . 784 . . 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Counter 4 | 787 | | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 ~ TLV Block ~ 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 Figure 2: Loss Measurement Message Format 794 Reserved fields MUST be set to 0 and ignored upon receipt. The 795 possible values for the remaining fields are as follows. 797 Field Meaning 798 --------------------- ----------------------------------------------- 799 Version Protocol version 800 Flags Message control flags 801 Control Code Code identifying the query or response type 802 Message Length Total length of this message in bytes 803 Data Format Flags Flags specifying the format of message data 804 (DFlags) 805 Origin Timestamp Format of the Origin Timestamp field 806 Format (OTF) 807 Reserved Reserved for future specification 808 Session Identifier Set arbitrarily by the querier 809 Differentiated Differentiated Services Code Point (DSCP) being 810 Services (DS) Field measured 812 Origin Timestamp Query message transmission timestamp 813 Counter 1-4 Packet counter values in network byte order 814 TLV Block Optional block of Type-Length-Value fields 815 The possible values for these fields are as follows. 817 Version: Currently set to 0. 819 Flags: The format of the Flags field is shown below. 821 +-+-+-+-+ 822 |R|T|0|0| 823 +-+-+-+-+ 825 Loss Measurement Message Flags 827 The meanings of the flag bits are: 829 R: Query/Response indicator. Set to 0 for a Query and 1 for a 830 Response. 832 T: Traffic-class-specific measurement indicator. Set to 1 when 833 the measurement operation is scoped to packets of a particular 834 traffic class (DSCP value), and 0 otherwise. When set to 1, the 835 DS field of the message indicates the measured traffic class. 837 0: Set to 0. 839 Control Code: Set as follows according to whether the message is a 840 Query or a Response as identified by the R flag. 842 For a Query: 844 0x0: In-band Response Requested. Indicates that this query has 845 been sent over a bidirectional channel and the response is 846 expected over the same channel. 848 0x1: Out-of-band Response Requested. Indicates that the 849 response should be sent via an out-of-band channel. 851 0x2: No Response Requested. Indicates that no response to the 852 query should be sent. 854 For a Response: 856 Codes 0x0-0xF are reserved for non-error responses. 858 0x1: Success. Indicates that the operation was successful. 860 0x2: Notification - Data Format Invalid. Indicates that the 861 query was processed but the format of the data fields in this 862 response may be inconsistent. Consequently these data fields 863 MUST NOT be used for measurement. 865 0x3: Notification - Initialization In Progress. Indicates that 866 the query was processed but this response does not contain 867 valid measurement data because the responder's initialization 868 process has not completed. 870 0x4: Notification - Data Reset Occurred. Indicates that the 871 query was processed but a reset has recently occurred which may 872 render the data in this response inconsistent relative to 873 earlier responses. 875 0x10: Error - Unspecified Error. Indicates that the operation 876 failed for an unspecified reason. 878 0x11: Error - Unsupported Version. Indicates that the 879 operation failed because the protocol version supplied in the 880 query message is not supported. 882 0x12: Error - Unsupported Control Code. Indicates that the 883 operation failed because the Control Code requested an 884 operation that is not available for this channel. 886 0x13: Error - Unsupported Data Format. Indicates that the 887 operation failed because the data format specified in the query 888 is not supported. 890 0x14: Error - Authentication Failure. Indicates that the 891 operation failed because the authentication data supplied in 892 the query was missing or incorrect. 894 0x15: Error - Invalid Destination Node Identifier. Indicates 895 that the operation failed because the Destination Node 896 Identifier supplied in the query is not an identifier of this 897 node. 899 0x16: Error - Connection Mismatch. Indicates that the 900 operation failed because the channel identifier supplied in the 901 query did not match the channel over which the query was 902 received. 904 0x17: Error - Unsupported Mandatory TLV Object. Indicates that 905 the operation failed because a TLV Object received in the query 906 and marked as mandatory is not supported. 908 0x18: Error - Unsupported Query Interval. Indicates that the 909 operation failed because the query message rate exceeded the 910 configured threshold. 912 0x19: Error - Administrative Block. Indicates that the 913 operation failed because it has been administratively 914 disallowed. 916 0x1A: Error - Temporary Resource Exhaustion. Indicates that 917 the operation failed because node resources were not available. 919 Message Length: Set to the total length of this message in bytes. 921 DFlags: The format of the DFlags field is shown below. 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 DS: When the T flag is set to 1, this field is set to the DSCP value 951 [RFC3260] that corresponds to the traffic class being measured. For 952 MPLS, where the traffic class of a channel is identified by the 953 three-bit Traffic Class in the channel's LSE [RFC5462], this field 954 SHOULD be set to the Class Selector Codepoint [RFC2474] that 955 corresponds to that Traffic Class. When the T flag is set to 0, the 956 value of this field is arbitrary, and the field can be considered 957 part of the Session Identifier. 959 Origin Timestamp: Timestamp recording the transmit time of the query 960 message. 962 Counter 1-4: Referring to Section 2.1, when a query is sent from A, 963 Counter 1 is set to A_TxP and the other counter fields are set to 0. 964 When the query is received at B, Counter 2 is set to B_RxP. At this 965 point, B copies Counter 1 to Counter 3 and Counter 2 to Counter 4, 966 and re-initializes Counter 1 and Counter 2 to 0. When B transmits 967 the response, Counter 1 is set to B_TxP. When the response is 968 received at A, Counter 2 is set to A_RxP. 970 The mapping of counter types such as A_TxP to the counter fields 1-4 971 is designed to ensure that transmit counter values are always written 972 at the same fixed offset in the packet, and likewise for receive 973 counters. This property is important for hardware processing. 975 All counter values MUST be in network byte order. When a 32-bit 976 counter value is written to one of the counter fields, that value 977 SHALL be written to the low-order 32 bits of the field; the high- 978 order 32 bits of the field MUST, in this case, be set to 0. 980 TLV Block: Zero or more TLV fields. 982 3.2. Delay Measurement Message Format 984 The format of a Delay Measurement message, which follows the 985 Associated Channel Header (ACH), is as follows: 987 0 1 2 3 988 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 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 |Version| Flags | Control Code | Message Length | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | QTF | RTF | RPTF | Reserved | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Session Identifier | DS | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Timestamp 1 | 997 | | 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 . . 1000 . . 1001 . . 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | Timestamp 4 | 1004 | | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 ~ TLV Block ~ 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 Figure 3: Delay Measurement Message Format 1011 The meanings of the fields are summarized in the following table. 1013 Field Meaning 1014 --------------------- ----------------------------------------------- 1015 Version Protocol version 1016 Flags Message control flags 1017 Control Code Code identifying the query or response type 1018 Message Length Total length of this message in bytes 1019 QTF Querier timestamp format 1020 RTF Responder timestamp format 1021 RPTF Responder's preferred timestamp format 1022 Reserved Reserved for future specification 1023 Session Identifier Set arbitrarily by the querier 1024 Differentiated Differentiated Services Code Point (DSCP) being 1025 Services (DS) Field measured 1027 Timestamp 1-4 64-bit timestamp values 1028 TLV Block Optional block of Type-Length-Value fields 1030 Reserved fields MUST be set to 0 and ignored upon receipt. The 1031 possible values for the remaining fields are as follows. 1033 Version: Currently set to 0. 1035 Flags: As specified in Section 3.1, except for the X flag, which is 1036 set to 0, and the T flag, which is set to 1. 1038 Control Code: As specified in Section 3.1. 1040 Message Length: Set to the total length of this message in bytes. 1042 Querier Timestamp Format: The format of the timestamp values written 1043 by the querier, as specified in Section 3.4. 1045 Responder Timestamp Format: The format of the timestamp values 1046 written by the responder, as specified in Section 3.4. 1048 Responder's Preferred Timestamp Format: The timestamp format 1049 preferred by the responder, as specified in Section 3.4. 1051 Session Identifier: As specified in Section 3.1. 1053 DS: As specified in Section 3.1. 1055 Timestamp 1-4: Referring to Section 2.3, when a query is sent from A, 1056 Timestamp 1 is set to T1 and the other timestamp fields are set to 0. 1057 When the query is received at B, Timestamp 2 is set to T2. At this 1058 point, B copies Timestamp 1 to Timestamp 3 and Timestamp 2 to 1059 Timestamp 4, and re-initializes Timestamp 1 and Timestamp 2 to 0. 1060 When B transmits the response, Timestamp 1 is set to T3. When the 1061 response is received at A, Timestamp 2 is set to T4. The actual 1062 formats of the timestamp fields written by A and B are indicated by 1063 the Querier Timestamp Format and Responder Timestamp Format fields 1064 respectively. 1066 The mapping of timestamps to the timestamp fields 1-4 is designed to 1067 ensure that transmit timestamps are always written at the same fixed 1068 offset in the packet, and likewise for receive timestamps. This 1069 property is important for hardware processing. 1071 TLV Block: Zero or more TLV fields. 1073 3.3. Combined Loss/Delay Measurement Message Format 1075 The format of a combined Loss and Delay Measurement message, which 1076 follows the Associated Channel Header (ACH), is as follows: 1078 0 1 2 3 1079 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 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 |Version| Flags | Control Code | Message Length | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | DFlags| QTF | RTF | RPTF | Reserved | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Session Identifier | DS | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | Timestamp 1 | 1088 | | 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 . . 1091 . . 1092 . . 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | Timestamp 4 | 1095 | | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Counter 1 | 1098 | | 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 . . 1101 . . 1102 . . 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | Counter 4 | 1105 | | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 ~ TLV Block ~ 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 Figure 4: Loss/Delay Measurement Message Format 1112 The LM/DM message fields have the same meanings as the corresponding 1113 fields in the LM and DM message formats. 1115 3.4. Timestamp Field Formats 1117 The following timestamp format field values are specified in this 1118 document: 1120 0: Null timestamp format. This value is a placeholder indicating 1121 that the timestamp field does not contain a meaningful timestamp. 1123 1: Sequence number. This value indicates that the timestamp field 1124 is to be viewed as a simple 64-bit sequence number. 1126 2: Network Time Protocol version 4 64-bit timestamp format 1127 [RFC5905]. This format consists of a 32-bit seconds field 1128 followed by a 32-bit fractional seconds field, so that it can be 1129 regarded as a fixed-point 64-bit quantity. 1131 3: IEEE 1588-2002 (1588v1) Precision Time Protocol timestamp 1132 format [IEEE1588]. This format consists of a 32-bit seconds field 1133 followed by a 32-bit nanoseconds field. 1135 In recognition of the wide deployment, particularly in hardware-based 1136 timing implementations, of IEEE 1588 PTP, the PTP timestamp format is 1137 the default format used in Delay Measurement messages. This format 1138 MUST be supported. Support for other timestamp formats is OPTIONAL. 1140 Timestamp formats of n < 64 bits in size SHALL be encoded in the 64- 1141 bit timestamp fields specified in this document using the n high- 1142 order bits of the field. The remaining 64 - n low-order bits in the 1143 field SHOULD be set to 0 and MUST be ignored when reading the field. 1145 3.5. TLV Objects 1147 The TLV Block in LM and DM messages consists of zero or more objects 1148 with the following format: 1150 0 1 2 3 1151 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 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Type | Length | Value ~ 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 TLV Format 1158 The Type and Length fields are each 8 bits long, and the Length field 1159 indicates the size in bytes of the Value field, which can therefore 1160 be up to 255 bytes long. 1162 The Type space is divided into Mandatory and Optional subspaces: 1164 Type Range Semantics 1165 -------------- --------- 1166 0-127 Mandatory 1167 128-255 Optional 1169 Upon receipt of a query message including an unrecognized mandatory 1170 TLV object, the recipient MUST discard the message or respond with an 1171 appropriate error code. 1173 The types defined are as follows: 1175 Type Definition 1176 -------------- --------------------------------- 1177 Mandatory 1178 0 Padding - copy in response 1179 1 Return Address 1180 2 Session Query Interval 1181 3-119 Reserved 1182 120-127 Implementation-specific usage 1184 Optional 1185 128 Padding - do not copy in response 1186 129 Destination Address 1187 130 Source Address 1188 131-247 Reserved 1189 248-255 Implementation-specific usage 1191 3.5.1. Padding 1193 The two padding objects permit the augmentation of packet size; this 1194 is mainly useful for delay measurement. The type of padding 1195 indicates whether the padding supplied by the querier is to be copied 1196 to, or omitted from, the response. More than one padding object MAY 1197 be present, in which case they SHOULD be continguous. Padding 1198 objects SHOULD occur at the end of the TLV Block. The Value field of 1199 a padding object is arbitrary. 1201 3.5.2. Addressing 1203 The addressing objects have the following format: 1205 0 1 2 3 1206 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 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 | Type | Length | Address Family | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 ~ Address ~ 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 Addressing Object Format 1215 The Address Family field indicates the type of the address, and SHALL 1216 be set to one of the assigned values in the IANA Address Family 1217 Numbers registry. 1219 The Source and Destination address objects indicate the addresses of 1220 the sender and the intended recipient of the message, respectively. 1222 The Source Address of a query message SHOULD be used as the 1223 destination for an out-of-band response unless some other out-of-band 1224 response mechanism has been configured, and unless a Return Address 1225 object is present, in which case the Return Address specifies the 1226 target of the response. The Return Address object MUST NOT appear in 1227 a response. 1229 3.5.3. Session Query Interval 1231 The Value field of the Session Query Interval object is a 32-bit 1232 unsigned positive (nonzero) integer in network byte order that 1233 specifies a time interval in milliseconds. When attached to a query 1234 message, this time interval indicates the interval between successive 1235 query messages in this measurement session. When attached to a 1236 response, this time interval indicates the minimum query interval 1237 supported by the responder for the measurement type indicated by the 1238 query. 1240 When initiating a new measurement session, the querier SHOULD include 1241 this object to inform the responder of the rate at which it intends 1242 to send query messages in this session. Upon receiving a non-error 1243 response, the querier MAY then stop including this object in 1244 subsequent messages in the session for as long as its query 1245 transmission rate remains the same. When a query is received with a 1246 Session Query Interval that is too low for the receiver to support, 1247 the receiver SHOULD include this object when it generates an error 1248 response. 1250 Lower query intervals (i.e. higher query rates) provide finer 1251 measurement granularity at the expense of additional load on 1252 measurement endpoints and the network; see Section 5 for further 1253 discussion. 1255 4. Operation 1257 4.1. Loss Measurement Procedures 1259 4.1.1. Initiating a Loss Measurement Operation 1261 An LM operation for a particular channel consists of sending a 1262 sequence (LM[1], LM[2], ...) of LM query messages over the channel at 1263 a specific rate and processing the responses received, if any. As 1264 described in Section 2.1, the packet loss associated with the channel 1265 during the operation is computed as a delta between successive 1266 messages; these deltas can be accumulated to obtain a running total 1267 of the packet loss for the channel. 1269 The query message transmission rate MUST be sufficiently high, given 1270 the LM message counter size (which can be either 32 or 64 bits) and 1271 the speed and minimum packet size of the underlying channel, that the 1272 ambiguity condition noted in Section 2.1 cannot arise. The 1273 implementation SHOULD assume, in evaluating this rate, that the 1274 counter size is 32 bits unless explicitly configured otherwise, or 1275 unless (in the case of a bidirectional channel) all local and remote 1276 interfaces involved in the LM operation are known to be 64-bit- 1277 capable, which can be inferred from the value of the X flag in an LM 1278 response. 1280 When initiating an LM operation, the far end may require a period of 1281 time to become ready for the requested measurement operation. During 1282 this period, LM queries MAY simply be discarded, and the querier 1283 expecting a response SHOULD be prepared for this situation, for 1284 example by setting a timer to differentiate between an acceptable 1285 initialization delay and a permanent unavailability condition at the 1286 far end. Alternatively, the receiver MAY respond, possibly in a 1287 rate-limited manner, to queries received during this period with an 1288 appropriate notification code. 1290 4.1.2. Transmitting a Loss Measurement Query 1292 When transmitting an LM Query over a channel, the Version field MUST 1293 be set to 0. The R flag MUST be set to 0. The T flag SHALL be set 1294 to 1 if, and only if, the measurement is specific to a particular 1295 traffic class, in which case the DS field SHALL identify that traffic 1296 class. 1298 The X flag MUST be set to 1 if the transmitting interface writes 64- 1299 bit LM counters, and otherwise MUST be set to 0 to indicate that 32- 1300 bit counters are written. The B flag SHALL be set to 1 to indicate 1301 that the counter fields contain octet counts, or to 0 to indicate 1302 packet counts. 1304 The Control Code field MUST be set to one of the values for Query 1305 messages listed in Section 3.1; if the channel is unidirectional, 1306 this field MUST NOT be set to 0x0 (Query: in-band response 1307 requested). 1309 The Session Identifier field can be set arbitrarily. 1311 The Origin Timestamp field SHOULD be set to the time at which this 1312 message is transmitted, and the Origin Timestamp Format field MUST be 1313 set to indicate its format, according to Section 3.4. 1315 The Counter 1 field SHOULD be set to the total count of units 1316 (packets or octets, according to the B flag) transmitted over the 1317 channel prior to this LM Query. The remaining Counter fields MUST be 1318 set to 0. 1320 4.1.3. Receiving a Loss Measurement Query 1322 Upon receipt of an LM Query message, the Counter 2 field SHOULD be 1323 set to the total count of units (packets or octets, according to the 1324 B flag) received over the channel prior to this LM Query. If the 1325 receiving interface writes 32-bit LM counters, the X flag MUST be set 1326 to 0. 1328 At this point the LM Query message must be inspected. If the Control 1329 Code field is set to 0x2 (no response requested), an LM Response 1330 message MUST NOT be transmitted. If the Control Code field is set to 1331 0x0 (in-band response requested) or 0x1 (out-of-band response 1332 requested), then an in-band or out-of-band response, respectively, 1333 SHOULD be transmitted unless this has been prevented by an 1334 administrative, security or congestion control mechanism. 1336 4.1.4. Transmitting a Loss Measurement Response 1338 When constructing a Response to an LM Query, the Version field MUST 1339 be set to 0. The R flag MUST be set to 1. The value of the T flag 1340 MUST be copied from the LM Query. 1342 The X flag MUST be set to 0 if the transmitting interface writes 32- 1343 bit LM counters; otherwise its value MUST be copied from the LM 1344 Query. The B flag MUST be copied from the LM Query. 1346 The Session Identifier, Origin Timestamp, and Origin Timestamp Format 1347 fields MUST be copied from the LM Query. The Counter 1 and Counter 2 1348 fields from the LM Query MUST be copied to the Counter 3 and Counter 1349 4 fields, respectively, of the LM Response. 1351 The Control Code field MUST be set to one of the values for Response 1352 messages listed in Section 3.1. The value 0x10 (Unspecified Error) 1353 SHOULD NOT be used if one of the other more specific error codes is 1354 applicable. 1356 If the response is transmitted in-band, the Counter 1 field SHOULD be 1357 set to the total count of units transmitted over the channel prior to 1358 this LM Response. If the response is transmitted out-of-band, the 1359 Counter 1 field MUST be set to 0. In either case, the Counter 2 1360 field MUST be set to 0. 1362 4.1.5. Receiving a Loss Measurement Response 1364 Upon in-band receipt of an LM Response message, the Counter 2 field 1365 SHOULD be set to the total count of units received over the channel 1366 prior to this LM Response. If the receiving interface writes 32-bit 1367 LM counters, the X flag MUST be set to 0. 1369 Upon out-of-band receipt of an LM Response message, the Counter 1 and 1370 Counter 2 fields MUST NOT be used for purposes of loss measurement. 1372 If the Control Code in an LM Response is anything other than 0x1 1373 (Success), the counter values in the response MUST NOT be used for 1374 purposes of loss measurement. When the Control Code indicates an 1375 error condition, the LM operation SHOULD be suspended and an 1376 appropriate notification to the user generated. If a temporary error 1377 condition is indicated, the LM operation MAY be restarted 1378 automatically. 1380 4.1.6. Loss Calculation 1382 Calculation of packet loss is carried out according to the procedures 1383 in Section 2.1. The X flag in an LM message informs the device 1384 performing the calculation whether to perform 32-bit or 64-bit 1385 arithmetic. If the flag value is equal to 1, all interfaces involved 1386 in the LM operation have written 64-bit counter values, and 64-bit 1387 arithmetic can be used. If the flag value is equal to 0, at least 1388 one interface involved in the operation has written a 32-bit counter 1389 value, and 32-bit arithmetic is carried out using the low-order 32 1390 bits of each counter value. 1392 Note that the semantics of the X flag allow all devices to 1393 interoperate regardless of their counter size support. Thus, an 1394 implementation MUST NOT generate an error response based on the value 1395 of this flag. 1397 4.1.7. Quality of Service 1399 The TC field of the LSE corresponding to the channel (e.g. LSP) 1400 being measured SHOULD be set to a traffic class equal to or better 1401 than the best TC within the measurement scope to minimize the chance 1402 of out-of-order conditions. 1404 4.1.8. G-ACh Packets 1406 By default, direct LM MUST exclude packets transmitted and received 1407 over the Generic Associated Channel (G-ACh). An implementation MAY 1408 provide the means to alter the direct LM scope to include some or all 1409 G-ACh messages. Care must be taken when altering the LM scope to 1410 ensure that both endpoints are in agreement. 1412 4.1.9. Test Messages 1414 In the case of inferred LM, the packets counted for LM consist of 1415 test messages generated for this purpose, or of some other class of 1416 packets deemed to provide a good proxy for data packets flowing over 1417 the channel. The specification of test protocols and proxy packets 1418 is outside the scope of this document. 1420 An identifier common to both the test or proxy messages and the LM 1421 messages may be required to make correlation possible. The combined 1422 value of the Session Identifier and DS fields SHOULD be used for this 1423 purpose when possible. That is, test messages in this case will 1424 include a 32-bit field which can carry the value of the combined 1425 Session Identifier + DS field present in LM messages. When TC- 1426 specific LM is conducted, the DS field of the LSE in the label stack 1427 of a test message corresponding to the channel (e.g. LSP) over which 1428 the message is sent MUST correspond to the DS value in the associated 1429 LM messages. 1431 4.1.10. Message Loss and Packet Misorder Conditions 1433 Because an LM operation consists of a message sequence with state 1434 maintained from one message to the next, LM is subject to the effects 1435 of lost messages and misordered packets in a way that DM is not. 1436 Because this state exists only on the querier, the handling of these 1437 conditions is, strictly speaking, a local matter. This section, 1438 however, presents recommended procedures for handling such 1439 conditions. 1441 The first kind of anomaly that may occur is that one or more LM 1442 messages may be lost in transit. The effect of such loss is that 1443 when an LM Response is next received at the querier, an unambiguous 1444 interpretation of the counter values it contains may be impossible, 1445 for the reasons described at the end of Section 2.1. Whether this is 1446 so depends on the number of messages lost and the other variables 1447 mentioned in that section, such as the LM message rate and the 1448 channel parameters. 1450 Another possibility is that LM messages are misordered in transit, so 1451 that for instance the response to LM[n] is received prior to the 1452 response to LM[n-1]. A typical implementation will discard the late 1453 response to LM[n-1], so that the effect is the same as the case of a 1454 lost message. 1456 Finally, LM is subject to the possibility that data packets are 1457 misordered relative to LM messages. This condition can result, for 1458 example, in a transmit count of 100 and a corresponding receive count 1459 of 101. The effect here is that the A_TxLoss[n-1,n] value (for 1460 example) for a given measurement interval will appear to be extremely 1461 (if not impossibly) large. The other case, where an LM message 1462 arrives earlier than some of the packets, simply results in those 1463 packets being counted as lost, which is usually what is desired. 1465 An implementation SHOULD identify a threshold value that indicates 1466 the upper bound of lost packets measured in a single computation 1467 beyond which the interval is considered unmeasurable. This is called 1468 the MaxLMIntervalLoss threshold. It is clear that this threshold 1469 should be no higher than the maximum number of packets (or bytes) the 1470 channel is capable of transmitting over the interval, but it may be 1471 lower. Upon encountering an unmeasurable interval, the LM state 1472 (i.e. data values from the last LM message received) SHOULD be 1473 discarded. 1475 With regard to lost LM messages, the MaxLMInterval (see Section 2.1) 1476 indicates the maximum amount of time that can elapse before the LM 1477 state is discarded. If some messages are lost, but a message is 1478 subsequently received within MaxLMInterval, its timestamp or sequence 1479 number will quantify the loss, and it MAY still be used for 1480 measurement, although the measurement interval will in this case be 1481 longer than usual. 1483 If an LM message is received that has a timestamp less than or equal 1484 to the timestamp of the last LM message received, this indicates that 1485 an exception has occurred, and the current interval SHOULD be 1486 considered unmeasurable unless the implementation has some other way 1487 of handling this condition. 1489 4.2. Delay Measurement Procedures 1491 4.2.1. Transmitting a Delay Measurement Query 1493 When transmitting a DM Query over a channel, the Version and Reserved 1494 fields MUST be set to 0. The R flag MUST be set to 0, the T flag 1495 MUST be set to 1, and the remaining flag bits MUST be set to 0. 1497 The Control Code field MUST be set to one of the values for Query 1498 messages listed in Section 3.1; if the channel is unidirectional, 1499 this field MUST NOT be set to 0x0 (Query: in-band response 1500 requested). 1502 The Querier Timestamp Format field MUST be set to the timestamp 1503 format used by the querier when writing timestamp fields in this 1504 message; the possible values for this field are listed in 1505 Section 3.4. The Responder Timestamp Format and Responder's 1506 Preferred Timestamp Format fields MUST be set to 0. 1508 The Session Identifier field can be set arbitrarily. The DS field 1509 MUST be set to the traffic class being measured. 1511 The Timestamp 1 field SHOULD be set to the time at which this DM 1512 Query is transmitted, in the format indicated by the Querier 1513 Timestamp Format field. The other timestamp fields MUST be set to 0. 1515 4.2.2. Receiving a Delay Measurement Query 1517 Upon receipt of a DM Query message, the Timestamp 2 field SHOULD be 1518 set to the time at which this DM Query is received. 1520 At this point the DM Query message must be inspected. If the Control 1521 Code field is set to 0x2 (no response requested), a DM Response 1522 message MUST NOT be transmitted. If the Control Code field is set to 1523 0x0 (in-band response requested) or 0x1 (out-of-band response 1524 requested), then an in-band or out-of-band response, respectively, 1525 SHOULD be transmitted unless this has been prevented by an 1526 administrative, security or congestion control mechanism. 1528 4.2.3. Transmitting a Delay Measurement Response 1530 When constructing a Response to a DM Query, the Version and Reserved 1531 fields MUST be set to 0. The R flag MUST be set to 1, the T flag 1532 MUST be set to 1, and the remaining flag bits MUST be set to 0. 1534 The Session Identifier and Querier Timestamp Format (QTF) fields MUST 1535 be copied from the DM Query. The Timestamp 1 and Timestamp 2 fields 1536 from the DM Query MUST be copied to the Timestamp 3 and Timestamp 4 1537 fields, respectively, of the DM Response. 1539 The Responder Timestamp Format (RTF) field MUST be set to the 1540 timestamp format used by the responder when writing timestamp fields 1541 in this message, i.e. Timestamp 4 and (if applicable) Timestamp 1; 1542 the possible values for this field are listed in Section 3.4. 1543 Furthermore, the RTF field MUST be set equal either to the QTF or the 1544 RPTF field. See Section 4.2.5 for guidelines on selection of the 1545 value for this field. 1547 The Responder's Preferred Timestamp Format (RPTF) field MUST be set 1548 to one of the values listed in Section 3.4 and SHOULD be set to 1549 indicate the timestamp format with which the responder can provide 1550 the best accuracy for purposes of delay measurement. 1552 The Control Code field MUST be set to one of the values for Response 1553 messages listed in Section 3.1. The value 0x10 (Unspecified Error) 1554 SHOULD NOT be used if one of the other more specific error codes is 1555 applicable. 1557 If the response is transmitted in-band, the Timestamp 1 field SHOULD 1558 be set to the time at which this DM Response is transmitted. If the 1559 response is transmitted out-of-band, the Timestamp 1 field MUST be 1560 set to 0. In either case, the Timestamp 2 field MUST be set to 0. 1562 If the response is transmitted in-band and the Control Code in the 1563 message is 0x1 (Success), then the Timestamp 1 and Timestamp 4 fields 1564 MUST have the same format, which will be the format indicated in the 1565 Responder Timestamp Format field. 1567 4.2.4. Receiving a Delay Measurement Response 1569 Upon in-band receipt of a DM Response message, the Timestamp 2 field 1570 SHOULD be set to the time at which this DM Response is received. 1572 Upon out-of-band receipt of a DM Response message, the Timestamp 1 1573 and Timestamp 2 fields MUST NOT be used for purposes of delay 1574 measurement. 1576 If the Control Code in a DM Response is anything other than 0x1 1577 (Success), the timestamp values in the response MUST NOT be used for 1578 purposes of delay measurement. When the Control Code indicates an 1579 error condition, an appropriate notification to the user SHOULD be 1580 generated. 1582 4.2.5. Timestamp Format Negotiation 1584 In case either the querier or the responder in a DM transaction is 1585 capable of supporting multiple timestamp formats, it is desirable to 1586 determine the optimal format for purposes of delay measurement on a 1587 particular channel. The procedures for making this determination 1588 SHALL be as follows. 1590 Upon sending an initial DM Query over a channel, the querier sets the 1591 Querier Timestamp Format (QTF) field to its preferred timestamp 1592 format. 1594 Upon receiving any DM Query message, the responder determines whether 1595 it is capable of writing timestamps in the format specified by the 1596 QTF field. If so, the Responder Timestamp Format (RTF) field is set 1597 equal to the QTF field. If not, the RTF field is set equal to the 1598 Responder's Preferred Timestamp Format (RPTF) field. 1600 The process of changing from one timestamp format to another at the 1601 responder may result in the Timestamp 1 and Timestamp 4 fields in an 1602 in-band DM Response having different formats. If this is the case, 1603 the Control Code in the response MUST NOT be set to 0x1 (Success). 1604 Unless an error condition has occurred, the Control Code MUST be set 1605 to 0x2 (Notification - Data Format Invalid). 1607 Upon receiving a DM Response, the querier knows from the RTF field in 1608 the message whether the responder is capable of supporting its 1609 preferred timestamp format: if it is, the RTF will be equal to the 1610 QTF. The querier also knows the responder's preferred timestamp 1611 format from the RPTF field. The querier can then decide whether to 1612 retain its current QTF or to change it and repeat the negotiation 1613 procedures. 1615 4.2.5.1. Single-Format Procedures 1617 When an implementation supports only one timestamp format, the 1618 procedures above reduce to the following simple behavior: 1620 o All DM Queries are transmitted with the same QTF; 1622 o All DM Responses are transmitted with the same RTF, and the RPTF 1623 is always set equal to the RTF; 1625 o All DM Responses received with RTF not equal to QTF are discarded; 1627 o On a unidirectional channel, all DM Queries received with QTF not 1628 equal to the supported format are discarded. 1630 4.2.6. Quality of Service 1632 The TC field of the LSE corresponding to the channel (e.g. LSP) 1633 being measured MUST be set to the value that corresponds to the DS 1634 field in the DM message. 1636 4.3. Combined Loss/Delay Measurement Procedures 1638 The combined LM/DM message defined in Section 3.3 allows loss and 1639 delay measurement to be carried out simultaneously. This message 1640 SHOULD be treated as an LM message which happens to carry additional 1641 timestamp data, with the timestamp fields processed as per delay 1642 measurement procedures. 1644 5. Congestion Considerations 1646 An MPLS network may be traffic-engineered in such a way that the 1647 bandwidth required both for client traffic and for control, 1648 management and OAM traffic is always available. The following 1649 congestion considerations therefore apply only when this is not the 1650 case. 1652 The proactive generation of Loss Measurement and Delay Measurement 1653 messages for purposes of monitoring the performance of an MPLS 1654 channel naturally results in a degree of additional load placed on 1655 both the network and the terminal nodes of the channel. When 1656 configuring such monitoring, operators should be mindful of the 1657 overhead involved and should choose transmit rates that do not stress 1658 network resources unduly; such choices must be informed by the 1659 deployment context. In case of slower links or lower-speed devices, 1660 for example, lower Loss Measurement message rates can be chosen, up 1661 to the limits noted at the end of Section 2.1. 1663 In general, lower measurement message rates place less load on the 1664 network at the expense of reduced granularity. For delay measurement 1665 this reduced granularity translates to a greater possibility that the 1666 delay associated with a channel temporarily exceeds the expected 1667 threshold without detection. For loss measurement, it translates to 1668 a larger gap in loss information in case of exceptional circumstances 1669 such as lost LM messages or misordered packets. 1671 When carrying out a sustained measurement operation such as an LM 1672 operation or continuous pro-active DM operation, the querier SHOULD 1673 take note of the number of lost measurement messages (queries for 1674 which a response is never received) and set a corresponding 1675 Measurement Message Loss Threshold. If this threshold is exceeded, 1676 the measurement operation SHOULD be suspended so as not to exacerbate 1677 the possible congestion condition. This suspension SHOULD be 1678 accompanied by an appropriate notification to the user so that the 1679 condition can be investigated and corrected. 1681 From the receiver perspective, the main consideration is the 1682 possibility of receiving an excessive quantity of measurement 1683 messages. An implementation SHOULD employ a mechanism such as rate- 1684 limiting to guard against the effects of this case. Authentication 1685 procedures can also be used to ensure that only queries from 1686 authorized devices are processed. 1688 6. Security Considerations 1690 There are three main types of security considerations associated with 1691 the exchange of performance monitoring messages such as those 1692 described in this document: the possibility of a malicious or 1693 misconfigured device generating an excessive quantity of messages, 1694 causing service impairment; the possibility of unauthorized 1695 alteration of messages in transit; and the possibility of an 1696 unauthorized device learning the data contained in or implied by such 1697 messages. 1699 The first consideration is discussed in Section 5. If reception or 1700 alteration of performance-related data by unauthorized devices is an 1701 operational concern, authentication and/or encryption procedures 1702 should be used to ensure message integrity and confidentiality. Such 1703 procedures are outside the scope of this document, but have general 1704 applicability to OAM protocols in MPLS networks. 1706 7. IANA Considerations 1708 This document makes the following requests of IANA: 1710 o Allocation of Channel Types in the PW Associated Channel Type 1711 registry 1713 o Creation of a Measurement Timestamp Type registry 1715 o Creation of an MPLS Loss/Delay Measurement Control Code registry 1717 o Creation of an MPLS Loss/Delay Measurement Type-Length-Value (TLV) 1718 Object registry 1720 7.1. Allocation of PW Associated Channel Types 1722 As per the IANA considerations in [RFC5586], IANA is requested to 1723 allocate the following Channel Types in the PW Associated Channel 1724 Type registry: 1726 Value Description TLV Follows Reference 1727 ----- -------------------------------------- ----------- ------------ 1728 TBD MPLS Direct Packet Loss Measurement No (this draft) 1729 (DLM) 1730 TBD MPLS Inferred Packet Loss Measurement No (this draft) 1731 (ILM) 1732 TBD MPLS Packet Delay Measurement (DM) No (this draft) 1733 TBD MPLS Direct Packet Loss and Delay No (this draft) 1734 Measurement (DLM+DM) 1735 TBD MPLS Inferred Packet Loss and Delay No (this draft) 1736 Measurement (ILM+DM) 1738 The values marked TBD are to be allocated by IANA as appropriate. 1740 7.2. Creation of Measurement Timestamp Type Registry 1742 IANA is requested to create a new Measurement Timestamp Type 1743 registry, with format and initial allocations as follows: 1745 Type Description Size in bits Reference 1746 ---- -------------------------------------- ------------ ------------ 1747 0 Null Timestamp 64 (this draft) 1748 1 Sequence Number 64 (this draft) 1749 2 Network Time Protocol version 4 64-bit 64 (this draft) 1750 Timestamp 1751 3 IEEE 1588 version 1 Timestamp 64 (this draft) 1753 The range of the Type field is 0-15. 1755 7.3. Creation of MPLS Loss/Delay Measurement Control Code Registry 1757 IANA is requested to create a new MPLS Loss/Delay Measurement Control 1758 Code registry. This registry is divided into two separate parts, one 1759 for Query Codes and the other for Response Codes, with formats and 1760 initial allocations as follows: 1762 Query Codes 1764 Code Description Reference 1765 ---- ------------------------------ ------------ 1766 0x0 In-band Response Requested (this draft) 1767 0x1 Out-of-band Response Requested (this draft) 1768 0x2 No Response Requested (this draft) 1769 Response Codes 1771 Code Description Reference 1772 ---- ----------------------------------- ------------ 1773 0x1 Success (this draft) 1774 0x2 Data Format Invalid (this draft) 1775 0x3 Initialization In Progress (this draft) 1776 0x4 Data Reset Occurred (this draft) 1777 0x10 Unspecified Error (this draft) 1778 0x11 Unsupported Version (this draft) 1779 0x12 Unsupported Control Code (this draft) 1780 0x13 Unsupported Data Format (this draft) 1781 0x14 Authentication Failure (this draft) 1782 0x15 Invalid Destination Node Identifier (this draft) 1783 0x16 Connection Mismatch (this draft) 1784 0x17 Unsupported Mandatory TLV Object (this draft) 1785 0x18 Unsupported Query Interval (this draft) 1786 0x19 Administrative Block (this draft) 1787 0x1A Temporary Resource Exhaustion (this draft) 1789 IANA is also requested to indicate that the values 0x0 - 0xF in the 1790 Response Code section are reserved for non-error response codes. 1792 The range of the Code field is 0 - 255. 1794 7.4. Creation of MPLS Loss/Delay Measurement TLV Object Registry 1796 IANA is requested to create a new MPLS Loss/Delay Measurement TLV 1797 Object registry, with format and initial allocations as follows: 1799 Type Description Reference 1800 ------- --------------------------------- ------------ 1801 0 Padding - copy in response (this draft) 1802 1 Return Address (this draft) 1803 2 Session Query Interval (this draft) 1804 120-127 Implementation-specific usage (this draft) 1805 128 Padding - do not copy in response (this draft) 1806 129 Destination Address (this draft) 1807 130 Source Address (this draft) 1808 248-255 Implementation-specific usage (this draft) 1810 IANA is also requested to indicate that Types 0-127 are classified as 1811 Mandatory, and that Types 128-255 are classified as Optional. 1813 The range of the Type field is 0 - 255. 1815 8. Acknowledgments 1817 The authors wish to thank the many participants of the MPLS working 1818 group who provided detailed review and feedback on this document. 1819 The authors offer special thanks to Alexander Vainshtein, Loa 1820 Andersson, and Hiroyuki Takagi for many helpful thoughts and 1821 discussions, and to Linda Dunbar for the idea of using LM messages 1822 for throughput measurement. 1824 9. References 1826 9.1. Normative References 1828 [IEEE1588] 1829 IEEE, "1588-2008 IEEE Standard for a Precision Clock 1830 Synchronization Protocol for Networked Measurement and 1831 Control Systems", March 2008. 1833 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1834 Requirement Levels", BCP 14, RFC 2119, March 1997. 1836 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1837 "Definition of the Differentiated Services Field (DS 1838 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1839 December 1998. 1841 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1842 Label Switching Architecture", RFC 3031, January 2001. 1844 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 1845 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 1846 Protocol Label Switching (MPLS) Support of Differentiated 1847 Services", RFC 3270, May 2002. 1849 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 1850 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 1851 Class" Field", RFC 5462, February 2009. 1853 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 1854 Associated Channel", RFC 5586, June 2009. 1856 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1857 Time Protocol Version 4: Protocol and Algorithms 1858 Specification", RFC 5905, June 2010. 1860 9.2. Informative References 1862 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1863 Delay Metric for IPPM", RFC 2679, September 1999. 1865 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1866 Delay Metric for IPPM", RFC 2681, September 1999. 1868 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1869 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1870 Tunnels", RFC 3209, December 2001. 1872 [RFC3260] Grossman, D., "New Terminology and Clarifications for 1873 Diffserv", RFC 3260, April 2002. 1875 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1876 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1877 November 2002. 1879 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 1880 Edge (PWE3) Architecture", RFC 3985, March 2005. 1882 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 1883 Cost Multipath Treatment in MPLS Networks", BCP 128, 1884 RFC 4928, June 2007. 1886 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1887 Specification", RFC 5036, October 2007. 1889 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 1890 "Bidirectional Forwarding Detection (BFD) for MPLS Label 1891 Switched Paths (LSPs)", RFC 5884, June 2010. 1893 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 1894 Berger, "A Framework for MPLS in Transport Networks", 1895 RFC 5921, July 2010. 1897 [RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport 1898 Profile Data Plane Architecture", RFC 5960, August 2010. 1900 Authors' Addresses 1902 Dan Frost 1903 Cisco Systems 1905 Email: danfrost@cisco.com 1906 Stewart Bryant 1907 Cisco Systems 1909 Email: stbryant@cisco.com