idnits 2.17.1 draft-frost-mpls-tp-loss-delay-02.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 (June 29, 2010) is 5049 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 875 -- Looks like a reference, but probably isn't: '2' on line 875 -- Looks like a reference, but probably isn't: '3' on line 417 -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 2030 (Obsoleted by RFC 4330) -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 2680 (Obsoleted by RFC 7680) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 8 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: December 31, 2010 June 29, 2010 7 Packet Loss and Delay Measurement for the MPLS Transport Profile 8 draft-frost-mpls-tp-loss-delay-02 10 Abstract 12 An essential Operations, Administration and Maintenance requirement 13 of the MPLS Transport Profile (MPLS-TP) is the ability to monitor 14 performance metrics for packet loss and one-way and two-way delay for 15 MPLS-TP pseudowires, Label Switched Paths, and Sections. This 16 document specifies protocol mechanisms to facilitate the efficient 17 and accurate measurement of these performance metrics. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 31, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Review of Requirements . . . . . . . . . . . . . . . . . . 4 61 1.1.1. Requirements for Packet Loss Measurement . . . . . . . 4 62 1.1.2. Requirements for Delay Measurement . . . . . . . . . . 4 63 1.2. Protocol Summary . . . . . . . . . . . . . . . . . . . . . 5 64 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 65 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 2.1. Implementation Considerations . . . . . . . . . . . . . . 8 67 2.2. Packet Loss Measurement . . . . . . . . . . . . . . . . . 9 68 2.3. Delay Measurement . . . . . . . . . . . . . . . . . . . . 11 69 2.3.1. Timestamp Format . . . . . . . . . . . . . . . . . . . 12 70 2.4. Delay Variation Measurement . . . . . . . . . . . . . . . 13 71 2.5. Unidirectional Connections . . . . . . . . . . . . . . . . 13 72 2.6. Distributed Systems . . . . . . . . . . . . . . . . . . . 14 73 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 14 74 3.1. Loss Measurement Message Format . . . . . . . . . . . . . 15 75 3.2. Delay Measurement Message Format . . . . . . . . . . . . . 17 76 3.3. Timestamp Field Formats . . . . . . . . . . . . . . . . . 19 77 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 4.1. Loss Measurement Procedures . . . . . . . . . . . . . . . 20 79 4.1.1. Initiating a Loss Measurement Operation . . . . . . . 20 80 4.1.2. Transmitting a Loss Measurement Query . . . . . . . . 20 81 4.1.3. Receiving a Loss Measurement Query . . . . . . . . . . 21 82 4.1.4. Transmitting a Loss Measurement Response . . . . . . . 21 83 4.1.5. Receiving a Loss Measurement Response . . . . . . . . 22 84 4.1.6. Loss Calculation . . . . . . . . . . . . . . . . . . . 22 85 4.1.7. Message Loss and Packet Misorder Conditions . . . . . 22 86 4.2. Delay Measurement Procedures . . . . . . . . . . . . . . . 23 87 4.2.1. Transmitting a Delay Measurement Query . . . . . . . . 23 88 4.2.2. Receiving a Delay Measurement Query . . . . . . . . . 24 89 4.2.3. Transmitting a Delay Measurement Response . . . . . . 24 90 4.2.4. Receiving a Delay Measurement Response . . . . . . . . 25 91 4.2.5. Timestamp Format Negotiation . . . . . . . . . . . . . 25 92 5. Packet Profiles and Quality of Service . . . . . . . . . . . . 26 93 5.1. Quality of Service . . . . . . . . . . . . . . . . . . . . 27 94 5.2. Loss Measurement of OAM Messages . . . . . . . . . . . . . 27 95 6. Congestion Considerations . . . . . . . . . . . . . . . . . . 27 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 97 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 99 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 100 9.2. Informative References . . . . . . . . . . . . . . . . . . 29 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 103 1. Introduction 105 The MPLS Transport Profile (MPLS-TP) [I-D.ietf-mpls-tp-framework] 106 comprises the set of protocol functions that meet the requirements 107 [RFC5654] for the application of MPLS to the construction and 108 operation of packet-switched transport networks. 110 RFC 5860 [RFC5860] specifies Operations, Administration and 111 Maintenance (OAM) definitions and requirements for the measurement of 112 packet loss and one-way and two-way delay for MPLS-TP pseudowires 113 (PWs), Label Switched Paths (LSPs), and Sections. For convenience 114 these definitions and requirements are summarized in the following 115 subsections. 117 1.1. Review of Requirements 119 1.1.1. Requirements for Packet Loss Measurement 121 The MPLS-TP OAM toolset must provide a function to enable the 122 quantification of packet loss ratio over a PW, LSP or Section. 124 The loss of a packet is defined in [RFC2680] (Section 2.4). This 125 definition is used here. 127 Packet loss ratio is defined here to be the ratio of the number of 128 user packets lost to the total number of user packets sent during a 129 defined time interval. 131 This function may either be performed pro-actively or on-demand. 133 This function should be performed between End Points of PWs, LSPs and 134 Sections. 136 It should be possible to rely on user traffic to perform this 137 function. 139 The protocol solution(s) developed to perform this function must 140 apply to point-to-point co-routed bidirectional LSPs, point-to-point 141 associated bidirectional LSPs, point-to-point unidirectional LSPs and 142 point-to-multipoint (unidirectional) LSPs. 144 1.1.2. Requirements for Delay Measurement 146 The MPLS-TP OAM toolset must provide a function to enable the 147 quantification of the one-way, and if appropriate, the two-way, delay 148 of a PW, LSP or Section. 150 o The one-way delay is defined in [RFC2679] to be the time elapsed 151 from the start of transmission of the first bit of a packet by an 152 End Point until the reception of the last bit of that packet by 153 the other End Point. 155 o The two-way delay is defined in [RFC2681] to be the time elapsed 156 from the start of transmission of the first bit of a packet by an 157 End Point until the reception of the last bit of that packet by 158 the same End Point. 160 Two-way delay may be quantified using data traffic loopback at the 161 remote End Point of the PW, LSP or Section. 163 Accurate quantification of one-way delay may require clock 164 synchronization, the means for which are outside the scope of this 165 document. 167 This function should be performed on-demand and may be performed pro- 168 actively. 170 This function should be performed between End Points of PWs, LSPs and 171 Sections. 173 In addition to point-to-point co-routed bidirectional LSPs, the 174 protocol solution(s) developed to perform this function must also 175 apply to point-to-point associated bidirectional LSPs, point-to-point 176 unidirectional LSPs and point-to-multipoint (unidirectional) LSPs, 177 but only to enable the quantification of the one-way delay. 179 1.2. Protocol Summary 181 This document specifies two closely-related protocols, one for packet 182 loss measurement (LM) and one for packet delay measurement (DM). 183 These protocols have the following characteristics and capabilities: 185 o The LM and DM protocols are designed to be simple and to support 186 efficient hardware processing. 188 o The LM and DM protocols support measurement of loss and delay over 189 MPLS-TP pseudowires and sections, over associated and co-routed 190 bidirectional point-to-point MPLS-TP LSPs, and over unidirectional 191 point-to-point and point-to-multipoint MPLS-TP LSPs. 193 o The LM and DM protocols support pro-active and on-demand modes of 194 operation. 196 o The LM and DM protocols use a simple query/response model over 197 bidirectional connections that allows a single node - the querier 198 - to measure the loss or delay of both directions of the 199 connection. 201 o The LM and DM protocols use query messages to measure the loss or 202 delay of a unidirectional connection. The measurement can either 203 be carried out at the downstream node(s) or at the querier if an 204 out-of-band return path is available. 206 o The LM and DM protocols do not require that the transmit and 207 receive interfaces be the same at an endpoint of a bidirectional 208 connection. 210 o The DM protocol is stateless. 212 o The LM protocol is "almost" stateless: loss is computed as a delta 213 between successive messages, and thus the data associated with the 214 last message received must be retained. 216 o The LM protocol provides perfect loss measurement if the necessary 217 implementation support is available. 219 o The LM protocol supports both 32-bit and 64-bit packet counters. 221 o The DM protocol supports multiple timestamp formats, and provides 222 a simple means for the two endpoints of a bidirectional connection 223 to agree on a preferred format. This procedure reduces to a 224 triviality for implementations supporting only a single timestamp 225 format. 227 o The DM protocol supports varying the measurement message size in 228 order to measure delays associated with different packet sizes. 230 1.3. Terminology 232 Term Definition 233 ------- ------------------------------------------ 234 ACH Associated Channel Header 235 DM Delay Measurement 236 G-ACh Generic Associated Channel 237 LM Loss Measurement 238 LSE Label Stack Entry 239 LSP Label Switched Path 240 LSR Label Switching Router 241 MPLS-TP MPLS Transport Profile 242 NTP Network Time Protocol 243 OAM Operations, Administration and Maintenance 244 PTP Precision Time Protocol 245 PW Pseudowire 246 TC Traffic Class 248 2. Overview 250 The basic procedures for measuring loss and delay over a 251 bidirectional connection are conceptually simple. The following 252 figure shows the reference scenario. 254 T1 T2 255 +-------+/ Query \+-------+ 256 | | - - - - - - - - ->| | 257 | A |===================| B | 258 | |<- - - - - - - - - | | 259 +-------+\ Response /+-------+ 260 T4 T3 262 Figure 1 264 The figure shows a bidirectional connection between two nodes, A and 265 B, and illustrates the temporal reference points T1-T4 associated 266 with a measurement operation that takes place at A. The operation 267 consists of A sending a query message to B, and B sending back a 268 response. Each reference point indicates the point in time at which 269 either the query or the response message is transmitted or received 270 over the connection. 272 In this situation, A can arrange to measure the packet loss over the 273 connection in the forward and reverse directions by sending Loss 274 Measurement (LM) query messages to B each of which contains the count 275 of packets transmitted prior to time T1 over the connection to B 276 (A_TxP). When the message reaches B, it appends two values and 277 reflects the message back to A: the count of packets received prior 278 to time T2 over the connection from A (B_RxP), and the count of 279 packets transmitted prior to time T3 over the connection to A 280 (B_TxP). When the response reaches A, it appends a fourth value, the 281 count of packets received prior to time T4 over the connection from B 282 (A_RxP). 284 These four counter values enable A to compute the desired loss 285 statistics. Because the transmit count at A and the receive count at 286 B (and vice versa) may not be synchronized at the time of the first 287 message, and to limit the effects of counter wrap, the loss is 288 computed in the form of a delta between messages. 290 To measure at A the delay over the connection to B, a Delay 291 Measurement (DM) query message is sent from A to B containing a 292 timestamp recording the instant at which it is transmitted, i.e. T1. 293 When the message reaches B, a timestamp is added recording the 294 instant at which it is received (T2). The message can now be 295 reflected from B to A, with B adding its transmit timestamp (T3) and 296 A adding its receive timestamp (T4). These four timestamps enable A 297 to compute the one-way delay in each direction, as well as the two- 298 way delay for the connection. The one-way delay computations require 299 that the clocks of A and B be synchronized; mechanisms for clock 300 synchronization are outside the scope of this document. 302 In the case of a unidirectional connection rooted at A, the first 303 half of each of the above procedures can be carried out to measure 304 the forward one-way loss and delay associated with the connection. 305 At this point the measurement can either take place at the terminal 306 node(s) of the connection rather than at A, or an out-of-band channel 307 can be used, if available, to communicate the data back to A. 309 In the context of MPLS-TP, LM and DM messages flow over the Generic 310 Associated Channel (G-ACh) [RFC5586] of an MPLS-TP pseudowire, LSP, 311 or Section. The term "connection" is used in this document to mean 312 "pseudowire, LSP, or Section". Although this document often speaks 313 of "measuring the loss or delay associated with a connection" for 314 simplicity, LM and DM actually occur with respect to a particular 315 class of packets flowing over a connection. This is discussed in 316 more detail in Section 5. 318 2.1. Implementation Considerations 320 The challenge in carrying out the above procedures lies with the 321 implementation. For accurate loss measurement to occur, packets must 322 not be sent between the time the transmit count for an outbound LM 323 message is determined and the time the message is actually 324 transmitted. Similarly, packets must not be received and processed 325 between the time an LM message is received and the time the receive 326 count for the message is determined. For accurate delay measurement, 327 timestamps must be recorded in DM messages at a point in time as 328 close as possible to when the message is actually transmitted or 329 received over the connection. 331 These accuracy requirements imply that a hardware-based forwarding 332 implementation may require hardware support for the processing of LM 333 and DM messages. An important consideration of the LM/DM protocol 334 and message format is therefore support for efficient hardware 335 processing. 337 In situations where such accuracy is not required, or the necessary 338 level of support is not available, an implementation MAY still 339 generate and respond to LM and DM messages but SHOULD make its 340 accuracy limitations clear to the user. In general the DM procedures 341 described in this document remain viable under these conditions, but 342 the procedures for LM may be inadequate. 344 The LM procedures described in this document have the advantage of 345 providing perfect packet loss accounting if the necessary 346 implementation support is available. This is a desirable capability 347 in an LM protocol for MPLS-TP given that loss levels for typical 348 MPLS-TP connections are expected to be quite low, and that even small 349 amounts of loss on such connections may be unacceptable. This 350 capability, however, may well come at the expense of more costly 351 hardware, and in some environments this cost may be prohibitive. 352 Thus it is desirable to define an additional set of LM procedures for 353 MPLS-TP that support deployments in which perfect loss accounting is 354 not required. Such alternative procedures rely on the generation of 355 either existing or new MPLS-TP OAM message types, which are subjected 356 to loss accounting as a proxy for user traffic in order to infer 357 approximate loss levels of the latter. This alternative approach to 358 LM is for further study and will be described in a companion 359 document. 361 2.2. Packet Loss Measurement 363 Suppose a bidirectional connection such as an MPLS-TP pseudowire, 364 bidirectional LSP, or Section exists between the LSRs A and B. The 365 objective is to measure at A the following two quantities associated 366 with the connection: 368 A_TxLoss (transmit loss): the number of packets transmitted by A 369 over the connection but not received at B; 371 A_RxLoss (receive loss): the number of packets transmitted by B 372 over the connection but not received at A. 374 This is accomplished by initiating a Loss Measurement (LM) operation 375 at A, which consists of transmission of a sequence of LM query 376 messages (LM[1], LM[2], ...) over the connection at a specified rate, 377 such as one every 100 milliseconds. Each message LM[n] contains the 378 following value: 380 A_TxP[n]: the total count of packets transmitted by A over the 381 connection prior to the time this message is transmitted. 383 When such a message is received at B, the following value is recorded 384 in the message: 386 B_RxP[n]: the total count of packets received by B over the 387 connection at the time this message is received (excluding the 388 message itself). 390 At this point, B inserts an appropriate response code into the 391 message and transmits it back to A, recording within it the following 392 value: 394 B_TxP[n]: the total count of packets transmitted by B over the 395 connection prior to the time this response is transmitted. 397 When the message response is received back at A, the following value 398 is recorded in the message: 400 A_RxP[n]: the total count of packets received by A over the 401 connection at the time this response is received (excluding the 402 message itself). 404 The transmit loss A_TxLoss[n-1,n] and receive loss A_RxLoss[n-1,n] 405 within the measurement interval marked by the messages LM[n-1] and 406 LM[n] are computed by A as follows: 408 A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1]) 409 A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1]) 411 where the arithmetic is modulo the counter size. 413 The derived values 415 A_TxLoss = A_TxLoss[1,2] + A_TxLoss[2,3] + ... 417 A_RxLoss = A_RxLoss[1,2] + A_RxLoss[2,3] + ... 419 are updated each time a response to an LM message is received and 420 processed, and represent the total transmit and receive loss over the 421 connection since the LM operation was initiated. 423 When computing the values A_TxLoss[n-1,n] and A_RxLoss[n-1,n] the 424 possibility of counter wrap must be taken into account. Consider for 425 example the values of the A_TxP counter at times n-1 and n. Clearly 426 if A_TxP[n] is allowed to wrap to 0 and then beyond to a value equal 427 to or greater than A_TxP[n-1], the computation of an unambiguous 428 A_TxLoss[n-1,n] value will be impossible. Therefore the LM message 429 rate MUST be sufficiently high, given the counter size and the speed 430 and minimum packet size of the underlying connection, that this 431 condition cannot arise. For example, a 32-bit counter for a 100 Gbps 432 link with a minimum packet size of 64 bytes can wrap in 2^32 / 433 (10^11/(64*8)) = ~22 seconds, which is therefore an upper bound on 434 the LM message interval under such conditions. 436 2.3. Delay Measurement 438 Suppose a bidirectional connection such as an MPLS-TP pseudowire, 439 bidirectional LSP, or Section exists between the LSRs A and B. The 440 objective is to measure at A one or more of the following quantities 441 associated with the connection: 443 o The one-way delay associated with the forward (A to B) direction 444 of the connection; 446 o The one-way delay associated with the reverse (B to A) direction 447 of the connection; 449 o The two-way delay (A to B to A) associated with the connection. 451 In the case of two-way delay, there are actually two possible metrics 452 of interest. The "strict" two-way delay is the sum of the one-way 453 delays in each direction and reflects the two-way delay of the 454 connection itself, irrespective of processing delays within the 455 remote endpoint B. The "loose" two-way delay is the definition of 456 two-way delay stated in Section 1.1.2 and includes in addition any 457 delay associated with remote endpoint processing. 459 Measurement of the one-way delay quantities requires that the clocks 460 of A and B be synchronized, whereas the two-way delay can be measured 461 directly even when this is not the case (provided A and B have stable 462 clocks). 464 The measurement is accomplished by sending a Delay Measurement (DM) 465 query message over the connection to B which contains the following 466 timestamp: 468 T1: the time the DM query message is transmitted from A. 470 When the message arrives at B, the following timestamp is recorded in 471 the message: 473 T2: the time the DM query message is received at B. 475 At this point B inserts an appropriate response code into the message 476 and transmits it back to A, recording within it the following 477 timestamp: 479 T3: the time the DM response message is transmitted from B. 481 When the message arrives back at A, the following timestamp is 482 recorded in the message: 484 T4: the time the DM response message is received back at A. 486 At this point, A can compute the strict two-way delay associated with 487 the connection as 489 strict two-way delay = (T4 - T1) - (T3 - T2) 491 and the loose two-way delay as 493 loose two-way delay = T4 - T1. 495 If the clocks of A and B are known at A to be synchronized, then both 496 one-way delay values, as well as the strict two-way delay, can be 497 computed at A as 499 forward one-way delay = T2 - T1 501 reverse one-way delay = T4 - T3 503 strict two-way delay = forward delay + reverse delay. 505 2.3.1. Timestamp Format 507 There are two significant timestamp formats in common use: the 508 timestamp format of the Internet standard Network Time Protocol 509 (NTP), described in [RFC1305] and [RFC2030], and the timestamp format 510 used in the IEEE 1588 Precision Time Protocol (PTP) [IEEE1588]. 512 [Editor's note: There are actually two PTP timestamp formats: the 513 1588v1 format consists of a 32-bit seconds field and a 32-bit 514 nanoseconds field; in 1588v2 the seconds field was extended to 48 515 bits.] 517 The NTP format has the advantages of wide use and long deployment in 518 the Internet, and was specifically designed to make the computation 519 of timestamp differences as simple and efficient as possible. On the 520 other hand, there is also now a significant deployment of equipment 521 designed to support the PTP format. 523 The approach taken in this document is therefore to include in DM 524 messages fields which identify the timestamp formats used by the two 525 devices involved in a DM operation. This implies that an LSR 526 attempting to carry out a DM operation may be faced with the problem 527 of computing with and possibly reconciling different timestamp 528 formats. Support for multiple timestamp formats is OPTIONAL. An 529 implementation SHOULD, however, make clear which timestamp formats it 530 supports and the extent of its support for computation with and 531 reconciliation of different formats for purposes of delay 532 measurement. 534 In recognition of the wide deployment, particularly in hardware-based 535 timing implementations, of IEEE 1588 PTP, the PTP timestamp format is 536 the default format used in DM messages. This format MUST be 537 supported. 539 2.4. Delay Variation Measurement 541 Packet Delay Variation [RFC3393] is another performance metric 542 important in some applications. The PDV of a pair of packets within 543 a stream of packets is defined for a selected pair of packets in the 544 stream going from measurement point MP1 to measurement point MP2. 545 The PDV is the difference between the one-way delay of the selected 546 packets. 548 A PDV measurement can therefore be derived from successive delay 549 measurements obtained through the procedures in Section 2.3. An 550 important point regarding PDV measurement, however, is that it can be 551 carried out based on one-way delay measurements even when the clocks 552 of the two systems involved in those measurements are not 553 synchronized. 555 2.5. Unidirectional Connections 557 In the case that the connection from A to (B1, ..., Bk) is 558 unidirectional, i.e. is a unidirectional LSP, LM and DM measurements 559 can be carried out at B1, ..., Bk instead of at A. 561 For LM this is accomplished by initiating an LM operation at A and 562 carrying out the same procedures as for bidirectional connections, 563 except that no responses from B1, ..., Bk to A are generated. 564 Instead, each terminal node B uses the A_TxP and B_RxP values in the 565 LM messages it receives to compute the receive loss associated with 566 the connection in essentially the same way as described previously, 567 i.e. 569 B_RxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1]) 571 For DM, of course, only the forward one-way delay can be measured and 572 the clock synchronization requirement applies. 574 Alternatively, if an out-of-band connection from a terminal node B 575 back to A is available, the LM and DM message responses can be 576 communicated to A via this connection so that the measurements can be 577 carried out at A. 579 2.6. Distributed Systems 581 The overview of the bidirectional measurement process presented in 582 Section 2 is also applicable when the transmit and receive interfaces 583 at A or B differ from one another, as may occur when the connection 584 is an MPLS-TP LSP that is not co-routed. Some additional 585 considerations, however, do apply in this case: 587 o If the transmit and receive interfaces reside on different line 588 cards, the clocks of those line cards must be synchronized in 589 order to compute the two-way delay. 591 o The DM protocol specified in this document requires that the 592 timestamp formats used by the interfaces that receive a DM query 593 and transmit a DM response agree. 595 o The LM protocol specified in this document supports both 32-bit 596 and 64-bit counter sizes, but the use of 32-bit counters at any of 597 the up to four interfaces involved in an LM operation will result 598 in 32-bit LM calculations for both directions of the connection. 600 [Editor's note: The last two restrictions could be relaxed if 601 desired, at the expense of some additional protocol complexity.] 603 3. Packet Format 605 Loss Measurement and Delay Measurement messages flow over the Generic 606 Associated Channel (G-ACh) [RFC5586] of an MPLS-TP connection 607 (pseudowire, LSP or Section). 609 [Editor's note: The question of ACH TLV usage and the manner of 610 supporting metadata such as authentication keys and node identifiers 611 is deliberately omitted. These issues will be addressed in a future 612 version of the document.] 614 3.1. Loss Measurement Message Format 616 The format of a Loss Measurement message, beginning with the 617 Associated Channel Header (ACH), is as follows: 619 0 1 2 3 620 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 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 |0 0 0 1|Version| Reserved | 0xHH (MPLS-TP Loss) | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 |Version| Flags | Control Code | Session Identifier | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Sequence Number | 627 | | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Counter 1 | 630 | | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 . . 633 . . 634 . . 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Counter 4 | 637 | | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 Figure 2: Loss Measurement Message Format 642 The meanings of the fields following the ACH are summarized in the 643 following table. 645 Field Meaning 646 --------------------- ----------------------------------------------- 647 Version Protocol version 648 Flags Message control flags 649 Control Code Code identifying the query or response type 650 Session Identifier Set arbitrarily by the querier 651 Sequence Number 64-bit sequence number, incremented for each 652 message 653 Counter 1-4 Packet counter values in network byte order 655 The possible values for these fields are as follows. 657 Version: Currently set to 0. 659 Flags: Each bit represents a message control flag. The flags, listed 660 in left-to-right (most- to least-significant-bit) order, are: 662 Q/R: Set to 0 for a Query and 1 for a Response. 664 X: Extended data format. Indicates support for extended (64-bit) 665 counter values. Initialized to 1 upon creation (and prior to 666 transmission) of an LM Query and copied from an LM Query to an LM 667 response. Set to 0 when the LM message is transmitted or received 668 over an interface that writes 32-bit counter values. 670 Remaining bits: Reserved for future specification and set to 0. 672 Control Code: Set as follows according to whether the message is a 673 Query or a Response as identified by the Q/R flag. 675 For a Query: 677 0x0: Query (in-band response requested). Indicates that this 678 query has been sent over a bidirectional connection and the 679 response is expected over the same connection. 681 0x1: Query (out-of-band response requested). Indicates that 682 the response should be sent via an out-of-band channel. 684 0x2: Query (no response requested). Indicates that no response 685 to the query should be sent. 687 For a Response: 689 0x1: Success. Indicates that the operation was successful. 691 0x8: Notification - Data Format Invalid. Indicates that the 692 query was processed but the format of the data fields in this 693 response may be inconsistent. Consequently these data fields 694 MUST NOT be used for measurement. 696 0x10: Error - Unspecified Error. Indicates that the operation 697 failed for an unspecified reason. 699 0x11: Error - Unsupported Version. Indicates that the 700 operation failed because the protocol version supplied in the 701 query message is not supported. 703 0x12: Error - Unsupported Control Code. Indicates that the 704 operation failed because the Control Code requested an 705 operation that is not available for this connection. 707 0x13: Error - Authentication Failure. Indicates that the 708 operation failed because the authentication data supplied in 709 the query was missing or incorrect. 711 0x14: Error - Invalid Source Node Identifier. Indicates that 712 the operation failed because the Source Node Identifier 713 supplied in the query is not expected. 715 0x15: Error - Invalid Destination Node Identifier. Indicates 716 that the operation failed because the Destination Node 717 Identifier supplied in the query is not the identifier of this 718 node. 720 0x16: Error - Connection Mismatch. Indicates that the 721 operation failed because the connection identifier supplied in 722 the query did not match the connection over which the query was 723 received. 725 0x17: Error - Query Rate Exceeded. Indicates that the 726 operation failed because the rate of query messages exceeded 727 the configured threshold. 729 0x18: Error - Administrative Block. Indicates that the 730 operation failed because it has been administratively 731 disallowed. 733 0x19: Error - Temporary Resource Exhaustion. Indicates that 734 the operation failed because node resources were not available. 736 Session Identifier: Set arbitrarily in a query and copied in the 737 response, if any. 739 Counter 1-4: Referring to Section 2.2, when a query is sent from A, 740 Counter 1 is set to A_TxP and the other counter fields are set to 0. 741 When the query is received at B, Counter 2 is set to B_RxP. At this 742 point, B copies Counter 1 to Counter 3 and Counter 2 to Counter 4, 743 and re-initializes Counter 1 and Counter 2 to 0. When B transmits 744 the response, Counter 1 is set to B_TxP. When the response is 745 received at A, Counter 2 is set to A_RxP. All counter values MUST be 746 in network byte order. 748 When a 32-bit counter value is written to one of the counter fields, 749 that value SHALL be written to the low-order 32 bits of the field; 750 the high-order 32 bits of the field MUST, in this case, be set to 0. 752 3.2. Delay Measurement Message Format 754 The format of a Delay Measurement message, beginning with the 755 Associated Channel Header (ACH), is as follows: 757 0 1 2 3 758 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 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 |0 0 0 1|Version| Reserved | 0xHH (MPLS-TP Delay) | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 |Version| Flags | Control Code | Session Identifier | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Message Length | QTF | RTF | RPTF | Resv | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Timestamp 1 | 767 | | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 . . 770 . . 771 . . 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Timestamp 4 | 774 | | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 ~ Padding ~ 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 Figure 3: Delay Measurement Message Format 781 The meanings of the fields following the ACH are summarized in the 782 following table. 784 Field Meaning 785 --------------------- ------------------------------------------- 786 Version Protocol version 787 Flags Message control flags 788 Control Code Code identifying the query or response type 789 Session Identifier Set arbitrarily by the querier 790 Message Length Total length of this message in bytes 791 QTF Querier timestamp format 792 RTF Responder timestamp format 793 RPTF Responder's preferred timestamp format 794 Resv (Reserved) Reserved for future specification 795 Timestamp 1-4 64-bit timestamp values 796 Padding Optional padding 798 The possible values for these fields are as follows. 800 Version: Currently set to 0. 802 Flags: As specified in Section 3.1. 804 Control Code: As specified in Section 3.1. 806 Session Identifier: Set arbitrarily in a query and copied in the 807 response, if any. 809 Message Length: Set to the total length of this message, excluding 810 the ACH, in bytes. 812 Querier Timestamp Format: The format of the timestamp values written 813 by the querier, as specified in Section 3.3. 815 Responder Timestamp Format: The format of the timestamp values 816 written by the responder, as specified in Section 3.3. 818 Responder's Preferred Timestamp Format: The timestamp format 819 preferred by the responder, as specified in Section 3.3. 821 Resv (Reserved): Currently set to 0. 823 Timestamp 1-4: Referring to Section 2.3, when a query is sent from A, 824 Timestamp 1 is set to T1 and the other timestamp fields are set to 0. 825 When the query is received at B, Timestamp 2 is set to T2. At this 826 point, B copies Timestamp 1 to Timestamp 3 and Timestamp 2 to 827 Timestamp 4, and re-initializes Timestamp 1 and Timestamp 2 to 0. 828 When B transmits the response, Timestamp 1 is set to T3. When the 829 response is received at A, Timestamp 2 is set to T4. The actual 830 formats of the timestamp fields written by A and B are indicated by 831 the Querier Timestamp Format and Responder Timestamp Format fields 832 respectively. 834 Padding: One or more octets of padding may optionally follow the 835 Timestamp 4 field in a query, in order to allow for delay measurement 836 based on packets of a particular size. The value of the first octet 837 of padding provides information about the padding. If in a Query the 838 first bit of the first pad octet is 1, the padding SHALL be copied to 839 the response, assuming one was requested. If this bit is 0, the 840 response MUST NOT include padding. The remaining bits in the first 841 pad octet are reserved and SHALL be set to 0. The values of the 842 remaining pad octets, if present, are arbitrary. 844 3.3. Timestamp Field Formats 846 The following timestamp format field values are specified in this 847 document: 849 0x0: Network Time Protocol version 4 timestamp format [RFC2030]. 850 This format consists of a 32-bit seconds field followed by a 32- 851 bit fractional seconds field, so that it can be regarded as a 852 fixed-point 64-bit quantity. 854 0x2: IEEE 1588-2002 (1588v1) Precision Time Protocol timestamp 855 format [IEEE1588]. This format consists of a 32-bit seconds field 856 followed by a 32-bit nanoseconds field. 858 In recognition of the wide deployment, particularly in hardware-based 859 timing implementations, of IEEE 1588 PTP, the PTP timestamp format is 860 the default format used in Delay Measurement messages. This format 861 MUST be supported. Support for other timestamp formats is OPTIONAL. 863 Timestamp formats of n < 64 bits in size SHALL be encoded in the 64- 864 bit timestamp fields specified in this document using the n high- 865 order bits of the field. The remaining 64 - n low-order bits in the 866 field SHOULD be set to 0 and MUST be ignored when reading the field. 868 4. Operation 870 4.1. Loss Measurement Procedures 872 4.1.1. Initiating a Loss Measurement Operation 874 An LM operation for a particular MPLS-TP connection consists of 875 sending a sequence (LM[1], LM[2], ...) of LM query messages over the 876 connection at a specific rate and processing the responses received, 877 if any. As described in Section 2.2, the packet loss associated with 878 the connection during the operation is computed as a delta between 879 successive messages; these deltas can be accumulated to obtain a 880 running total of the packet loss for the connection. 882 The query message transmission rate MUST be sufficiently high, given 883 the LM message counter size (which can be either 32 or 64 bits) and 884 the speed and minimum packet size of the underlying connection, that 885 the ambiguity condition noted in Section 2.2 cannot arise. The 886 implementation SHOULD assume, in evaluating this rate, that the 887 counter size is 32 bits unless explicitly configured otherwise, or 888 unless (in the case of a bidirectional connection) all local and 889 remote interfaces involved in the LM operation are known to be 64- 890 bit-capable, which can be inferred from the value of the X flag in an 891 LM response. 893 4.1.2. Transmitting a Loss Measurement Query 895 When transmitting an LM Query over an MPLS-TP connection, the Version 896 and Reserved fields MUST be set to 0. The Q/R flag MUST be set to 0. 897 The X flag MUST be set to 1 if the transmitting interface writes 64- 898 bit LM counters, and otherwise MUST be set to 0 to indicate that 32- 899 bit counters are written. The remaining flag bits MUST be set to 0. 901 The Control Code field MUST be set to one of the values for Query 902 messages listed in Section 3.1; if the connection is unidirectional, 903 this field MUST NOT be set to 0x0 (Query: in-band response 904 requested). 906 The Session Identifier field can be set arbitrarily. 908 The Sequence Number field MUST be set to 0 for the first message sent 909 after device initialization or explicit reset, and incremented by 1 910 for each subsequent message sent. 912 The Counter 1 field SHOULD be set to the total count of packets 913 transmitted over the connection prior to this LM Query. The 914 remaining Counter fields MUST be set to 0. 916 4.1.3. Receiving a Loss Measurement Query 918 Upon receipt of an LM Query message, the Counter 2 field SHOULD be 919 set to the total count of packets received over the connection prior 920 to this LM Query. If the receiving interface writes 32-bit LM 921 counters, the X flag MUST be set to 0. 923 At this point the LM Query message must be inspected. If the Control 924 Code field is set to 0x2 (no response requested), an LM Response 925 message MUST NOT be transmitted. If the Control Code field is set to 926 0x0 (in-band response requested) or 0x1 (out-of-band response 927 requested), then an in-band or out-of-band response, respectively, 928 SHOULD be transmitted unless this has been prevented by an 929 administrative, security or congestion control mechanism. 931 4.1.4. Transmitting a Loss Measurement Response 933 When constructing a Response to an LM Query, the Version and Reserved 934 fields MUST be set to 0. The Q/R flag MUST be set to 1. The the X 935 flag MUST be set to 0 if the transmitting interface writes 32-bit LM 936 counters; otherwise its value MUST be copied from the LM Query. The 937 remaining flag bits MUST be set to 0. 939 The Session Identifier and Sequence Number fields MUST be copied from 940 the LM Query. The Counter 1 and Counter 2 fields from the LM Query 941 MUST be copied to the Counter 3 and Counter 4 fields, respectively, 942 of the LM Response. 944 The Control Code field MUST be set to one of the values for Response 945 messages listed in Section 3.1. The value 0x10 (Unspecified Error) 946 SHOULD NOT be used if one of the other more specific error codes is 947 applicable. 949 If the response is transmitted in-band, the Counter 1 field SHOULD be 950 set to the total count of packets transmitted over the connection 951 prior to this LM Response. If the response is transmitted out-of- 952 band, the Counter 1 field MUST be set to 0. In either case, the 953 Counter 2 field MUST be set to 0. 955 4.1.5. Receiving a Loss Measurement Response 957 Upon in-band receipt of an LM Response message, the Counter 2 field 958 SHOULD be set to the total count of packets received over the 959 connection prior to this LM Response. If the receiving interface 960 writes 32-bit LM counters, the X flag MUST be set to 0. 962 Upon out-of-band receipt of an LM Response message, the Counter 1 and 963 Counter 2 fields MUST NOT be used for purposes of loss measurement. 965 If the Control Code in an LM Response is anything other than 0x1 966 (Success), the counter values in the response MUST NOT be used for 967 purposes of loss measurement. When the Control Code indicates an 968 error condition, the LM operation SHOULD be suspended and an 969 appropriate notification to the user generated. If a temporary error 970 condition is indicated, the LM operation MAY be restarted 971 automatically. 973 4.1.6. Loss Calculation 975 Calculation of packet loss is carried out according to the procedures 976 in Section 2.2. The X flag in an LM message informs the device 977 performing the calculation whether to perform 32-bit or 64-bit 978 arithmetic. If the flag value is equal to 1, all interfaces involved 979 in the LM operation have written 64-bit counter values, and 64-bit 980 arithmetic can be used. If the flag value is equal to 0, at least 981 one interface involved in the operation has written a 32-bit counter 982 value, and 32-bit arithmetic is carried out using the low-order 32 983 bits of each counter value. 985 4.1.7. Message Loss and Packet Misorder Conditions 987 Because an LM operation consists of a message sequence with state 988 maintained from one message to the next, LM is subject to the effects 989 of lost messages and misordered packets in a way that DM is not. 990 Because this state exists only on the querier, the handling of these 991 conditions is, strictly speaking, a local matter. This section, 992 however, presents RECOMMENDED procedures for handling such 993 conditions. 995 The first kind of anomaly that may occur is that one or more LM 996 messages may be lost in transit. The effect of such loss is that 997 when an LM Response is next received at the querier, an unambiguous 998 interpretation of the counter values it contains may be impossible, 999 for the reasons described at the end of Section 2.2. Whether this is 1000 so depends on the number of messages lost and the other variables 1001 mentioned in that section, such as the LM message rate and the 1002 connection parameters. 1004 Another possibility is that LM messages are misordered in transit, so 1005 that for instance the response to LM[n] is received prior to the 1006 response to LM[n-1]. A typical implementation will discard the late 1007 response to LM[n-1], so that the effect is the same as the case of a 1008 lost message. 1010 Finally, LM is subject to the possibility that data packets are 1011 misordered relative to LM messages. This condition can result, for 1012 example, in a transmit count of 100 and a corresponding receive count 1013 of 101. The effect here is that the A_TxLoss[n-1,n] value (for 1014 example) for a given measurement interval will appear to be extremely 1015 (if not impossibly) large. The other case, where an LM message 1016 arrives earlier than some of the packets, simply results in those 1017 packets being counted as lost, which is usually what is desired. 1019 [Editor's note: Text to be added here about handling the above 1020 conditions with sequence numbers and thresholds.] 1022 4.2. Delay Measurement Procedures 1024 4.2.1. Transmitting a Delay Measurement Query 1026 When transmitting a DM Query over an MPLS-TP connection, the Version 1027 and Reserved fields MUST be set to 0. The Q/R flag MUST be set to 0 1028 and the remaining flag bits MUST be set to 0. 1030 The Control Code field MUST be set to one of the values for Query 1031 messages listed in Section 3.1; if the connection is unidirectional, 1032 this field MUST NOT be set to 0x0 (Query: in-band response 1033 requested). 1035 The Session Identifier field can be set arbitrarily. 1037 The Querier Timestamp Format field MUST be set to the timestamp 1038 format used by the querier when writing timestamp fields in this 1039 message; the possible values for this field are listed in 1040 Section 3.3. The Responder Timestamp Format and Responder's 1041 Preferred Timestamp Format fields MUST be set to 0. 1043 The Timestamp 1 field SHOULD be set to the time at which this DM 1044 Query is transmitted, in the format indicated by the Querier 1045 Timestamp Format field. The other timestamp fields MUST be set to 0. 1047 One or more pad octets MAY follow the Timestamp 4 field, as described 1048 in Section 3.2. 1050 4.2.2. Receiving a Delay Measurement Query 1052 Upon receipt of a DM Query message, the Timestamp 2 field SHOULD be 1053 set to the time at which this DM Query is received. 1055 At this point the DM Query message must be inspected. If the Control 1056 Code field is set to 0x2 (no response requested), a DM Response 1057 message MUST NOT be transmitted. If the Control Code field is set to 1058 0x0 (in-band response requested) or 0x1 (out-of-band response 1059 requested), then an in-band or out-of-band response, respectively, 1060 SHOULD be transmitted unless this has been prevented by an 1061 administrative, security or congestion control mechanism. 1063 4.2.3. Transmitting a Delay Measurement Response 1065 When constructing a Response to a DM Query, the Version and Reserved 1066 fields MUST be set to 0. The Q/R flag MUST be set to 1 and the 1067 remaining flag bits MUST be set to 0. 1069 The Session Identifier and Querier Timestamp Format (QTF) fields MUST 1070 be copied from the DM Query. The Timestamp 1 and Timestamp 2 fields 1071 from the DM Query MUST be copied to the Timestamp 3 and Timestamp 4 1072 fields, respectively, of the DM Response. 1074 The Responder Timestamp Format (RTF) field MUST be set to the 1075 timestamp format used by the responder when writing timestamp fields 1076 in this message, i.e. Timestamp 4 and (if applicable) Timestamp 1; 1077 the possible values for this field are listed in Section 3.3. 1078 Furthermore, the RTF field MUST be set equal either to the QTF or the 1079 RPTF field. See Section 4.2.5 for guidelines on selection of the 1080 value for this field. 1082 The Responder's Preferred Timestamp Format (RPTF) field MUST be set 1083 to one of the values listed in Section 3.3 and SHOULD be set to 1084 indicate the timestamp format with which the responder can provide 1085 the best accuracy for purposes of delay measurement. 1087 The Control Code field MUST be set to one of the values for Response 1088 messages listed in Section 3.1. The value 0x10 (Unspecified Error) 1089 SHOULD NOT be used if one of the other more specific error codes is 1090 applicable. 1092 If the response is transmitted in-band, the Timestamp 1 field SHOULD 1093 be set to the time at which this DM Response is transmitted. If the 1094 response is transmitted out-of-band, the Timestamp 1 field MUST be 1095 set to 0. In either case, the Timestamp 2 field MUST be set to 0. 1097 If the response is transmitted in-band and the Control Code in the 1098 message is 0x1 (Success), then the Timestamp 1 and Timestamp 4 fields 1099 MUST have the same format, which will be the format indicated in the 1100 Responder Timestamp Format field. 1102 Padding SHALL be included in the response if, and only if, padding 1103 was present in the DM Query and the first bit of the first octet of 1104 that padding was set to 1, in which case the response padding MUST be 1105 identical to the query padding. 1107 4.2.4. Receiving a Delay Measurement Response 1109 Upon in-band receipt of a DM Response message, the Timestamp 2 field 1110 SHOULD be set to the time at which this DM Response is received. 1112 Upon out-of-band receipt of a DM Response message, the Timestamp 1 1113 and Timestamp 2 fields MUST NOT be used for purposes of delay 1114 measurement. 1116 If the Control Code in a DM Response is anything other than 0x1 1117 (Success), the timestamp values in the response MUST NOT be used for 1118 purposes of delay measurement. When the Control Code indicates an 1119 error condition, an appropriate notification to the user SHOULD be 1120 generated. 1122 4.2.5. Timestamp Format Negotiation 1124 In case either the querier or the responder in a DM transaction is 1125 capable of supporting multiple timestamp formats, it is desirable to 1126 determine the optimal format for purposes of delay measurement on a 1127 particular connection. The procedures for making this determination 1128 SHALL be as follows. 1130 Upon sending an initial DM Query over a connection, the querier sets 1131 the Querier Timestamp Format (QTF) field to its preferred timestamp 1132 format. 1134 Upon receiving any DM Query message, the responder determines whether 1135 it is capable of writing timestamps in the format specified by the 1136 QTF field. If so, the Responder Timestamp Format (RTF) field is set 1137 equal to the QTF field. If not, the RTF field is set equal to the 1138 Responder's Preferred Timestamp Format (RPTF) field. 1140 The process of changing from one timestamp format to another at the 1141 responder may result in the Timestamp 1 and Timestamp 4 fields in an 1142 in-band DM Response having different formats. If this is the case, 1143 the Control Code in the response MUST NOT be set to 0x1 (Success). 1144 Unless an error condition has occurred, the Control Code MUST be set 1145 to 0x2 (Notification - Data Format Invalid). 1147 Upon receiving a DM Response, the querier knows from the RTF field in 1148 the message whether the responder is capable of supporting its 1149 preferred timestamp format: if it is, the RTF will be equal to the 1150 QTF. The querier also knows the responder's preferred timestamp 1151 format from the RPTF field. The querier can then decide whether to 1152 retain its current QTF or to change it and repeat the negotiation 1153 procedures. 1155 4.2.5.1. Single-Format Procedures 1157 When an implementation supports only one timestamp format, the 1158 procedures above reduce to the following simple behavior: 1160 o All DM Queries are transmitted with the same QTF; 1162 o All DM Responses are transmitted with the same RTF, and the RPTF 1163 is always set equal to the RTF; 1165 o All DM Responses received with RTF not equal to QTF are discarded; 1167 o On a unidirectional connection, all DM Queries received with QTF 1168 not equal to the supported format are discarded. 1170 5. Packet Profiles and Quality of Service 1172 Although this document has referred, for simplicity, to measuring the 1173 packet loss or delay associated with a connection, it is more precise 1174 to say that these measurement operations occur with respect to a 1175 specific class of packets transiting the connection. Such a class is 1176 referred to as a "packet profile". 1178 Care must be taken to ensure that the endpoints of an LM or DM 1179 operation agree on the packet profile. For DM this reduces to 1180 ensuring that query and response messages are assigned to the same 1181 traffic class, while for LM it requires that the LM counters at each 1182 endpoint count the same kinds of packets. 1184 This document considers two aspects of packet profile support 1185 pertinent to loss and delay measurement: 1187 o Quality of Service 1189 o Loss Measurement of OAM Messages 1191 5.1. Quality of Service 1193 For connections that support multiple traffic classes, such as those 1194 that employ the Traffic Class (TC) field [RFC5462] in the MPLS Label 1195 Stack Entry (LSE) for Differentiated Services [RFC3270], the 1196 implementation MUST provide the capability to perform delay 1197 measurement on a per-traffic-class basis, by assigning the DM 1198 messages themselves to the corresponding class. 1200 For connections that support multiple traffic classes, the 1201 implementation SHOULD provide the capability to perform loss 1202 measurement on a per-traffic-class basis, and MAY provide the more 1203 general capability to perform loss measurement on a subset of the 1204 traffic classes supported by the connection, by restricting the LM 1205 packet profile (i.e. the class of packets counted by the LM counters) 1206 accordingly. LM messages themselves SHOULD be assigned to a traffic 1207 class equal to or better than the best traffic class within the LM 1208 packet profile. 1210 5.2. Loss Measurement of OAM Messages 1212 By default the LM packet profile MUST include packets transmitted and 1213 received over the Generic Associated Channel (G-ACh) associated with 1214 a connection. An implementation MAY provide the means to alter the 1215 LM packet profile to exclude some or all G-ACh messages. 1217 6. Congestion Considerations 1219 An MPLS-TP network may be traffic-engineered in such a way that the 1220 bandwidth required both for client traffic and for control, 1221 management and OAM traffic is always available. The following 1222 congestion considerations therefore apply only when this is not the 1223 case. 1225 The proactive generation of Loss Measurement and Delay Measurement 1226 messages for purposes of monitoring the performance of an MPLS-TP 1227 connection naturally results in a degree of additional load placed on 1228 both the network and the terminal nodes of the connection. When 1229 configuring such monitoring, operators should be mindful of the 1230 overhead involved and should choose transmit rates that do not stress 1231 network resources unduly; such choices must be informed by the 1232 deployment context. In case of slower links or lower-speed devices, 1233 for example, lower Loss Measurement message rates can be chosen, up 1234 to the limits noted at the end of Section 2.2. 1236 In general, lower measurement message rates place less load on the 1237 network at the expense of reduced granularity. For delay measurement 1238 this reduced granularity translates to a greater possibility that the 1239 delay associated with a connection temporarily exceeds the expected 1240 threshold without detection. For loss measurement, it translates to 1241 a larger gap in loss information in case of exceptional circumstances 1242 such as lost LM messages or misordered packets. 1244 When carrying out a sustained measurement operation such as an LM 1245 operation or continuous pro-active DM operation, the querier SHOULD 1246 take note of the number of lost measurement messages (queries for 1247 which a response is never received) and set a corresponding 1248 Measurement Message Loss Threshold. If this threshold is exceeded, 1249 the measurement operation SHOULD be suspended so as not to exacerbate 1250 the possible congestion condition. This suspension SHOULD be 1251 accompanied by an appropriate notification to the user so that the 1252 condition can be investigated and corrected. 1254 From the receiver perspective, the main consideration is the 1255 possibility of receiving an excessive quantity of measurement 1256 messages. An implementation SHOULD employ a mechanism such as rate- 1257 limiting to guard against the effects of this case. Authentication 1258 procedures can also be used to ensure that only queries from 1259 authorized devices are processed. 1261 7. Security Considerations 1263 There are two main types of security considerations associated with 1264 the exchange of performance monitoring messages such as those 1265 described in this document: the possibility of a malicious or 1266 misconfigured device generating an excessive quantity of messages, 1267 causing service impairment; and the possibility of an unauthorized 1268 device learning the data contained in or implied by such messages. 1270 The first consideration is discussed in Section 6. If reception of 1271 performance-related data by unauthorized devices is an operational 1272 concern, message authentication procedures such as those described in 1273 [xref] should be used to ensure that only queries from authorized 1274 devices are processed. 1276 8. IANA Considerations 1278 A future version of this document will detail IANA considerations 1279 for: 1281 o ACH Channel Types for LM and DM messages 1283 o Timestamp format registry 1285 o LM and DM Control Codes 1287 9. References 1289 9.1. Normative References 1291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1292 Requirement Levels", BCP 14, RFC 2119, March 1997. 1294 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 1295 Associated Channel", RFC 5586, June 2009. 1297 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 1298 and S. Ueno, "Requirements of an MPLS Transport Profile", 1299 RFC 5654, September 2009. 1301 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 1302 Operations, Administration, and Maintenance (OAM) in MPLS 1303 Transport Networks", RFC 5860, May 2010. 1305 9.2. Informative References 1307 [I-D.ietf-mpls-tp-framework] 1308 Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 1309 Berger, "A Framework for MPLS in Transport Networks", 1310 draft-ietf-mpls-tp-framework-12 (work in progress), 1311 May 2010. 1313 [IEEE1588] 1314 IEEE, "1588-2008 IEEE Standard for a Precision Clock 1315 Synchronization Protocol for Networked Measurement and 1316 Control Systems", March 2008. 1318 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1319 Specification, Implementation", RFC 1305, March 1992. 1321 [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 1322 for IPv4, IPv6 and OSI", RFC 2030, October 1996. 1324 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1325 Delay Metric for IPPM", RFC 2679, September 1999. 1327 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1328 Packet Loss Metric for IPPM", RFC 2680, September 1999. 1330 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1331 Delay Metric for IPPM", RFC 2681, September 1999. 1333 [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, 1334 P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi- 1335 Protocol Label Switching (MPLS) Support of Differentiated 1336 Services", RFC 3270, May 2002. 1338 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1339 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1340 November 2002. 1342 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 1343 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 1344 Class" Field", RFC 5462, February 2009. 1346 Authors' Addresses 1348 Dan Frost (editor) 1349 Cisco Systems 1351 Email: danfrost@cisco.com 1353 Stewart Bryant (editor) 1354 Cisco Systems 1356 Email: stbryant@cisco.com