idnits 2.17.1 draft-guo-bfd-pm-extension-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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Sequence field specifies the sequence number of a BFD Packet Loss Measurement (PLM) packet. It is generated by the end who initiates the measurement, the middle nodes and other side MUST not change the sequence number when propagate or reply the PLM packet. The sequence number could be used for loss detection of PLM packets or for the initiator to make sure the received PLM packet is a response of a previous PLM packet sent by itself. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Sequence field specifies the sequence number of a BFD Packet Delay Measurement (PDM) packet. It is generated by the end who initiates the measurement, the middle nodes and other side MUST not change the sequence number when propagate or reply the PDM packet. The sequence number could be used for PDM packets loss detection or for the initiator to make sure the received PDM packet is a response of a previous PDM packet sent by itself. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 59, but not defined == Missing Reference: 'BFD-BASE' is mentioned on line 217, but not defined == Missing Reference: 'Tn2' is mentioned on line 668, but not defined == Missing Reference: 'Tn1' is mentioned on line 668, but not defined == Missing Reference: 'TTn2' is mentioned on line 660, but not defined == Missing Reference: 'TTn1' is mentioned on line 660, but not defined == Missing Reference: 'BFD-MHOP' is mentioned on line 800, but not defined == Missing Reference: 'RFC4379' is mentioned on line 800, but not defined ** Obsolete undefined reference: RFC 4379 (Obsoleted by RFC 8029) == Unused Reference: 'RFC 4378' is defined on line 826, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4377 ** Downref: Normative reference to an Informational RFC: RFC 4378 == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-08 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-vccv-bfd-02 == Outdated reference: A later version (-01) exists of draft-vigoureux-mpls-tp-oam-requirements-00 == Outdated reference: A later version (-11) exists of draft-ietf-bfd-v4v6-1hop-08 == Outdated reference: A later version (-09) exists of draft-ietf-bfd-multihop-06 Summary: 4 errors (**), 0 flaws (~~), 17 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group X. Guo 2 Internet Draft M. Chen 3 Category: Standards Track K.Chan 4 Created: March 10, 2009 Huawei Technologies Co.,Ltd 5 Expires: September 2009 7 BFD Extensions in Support of Performance Measurement 9 draft-guo-bfd-pm-extension-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 15, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. 46 Abstract 48 This document describes extensions to the Bidirectional Forwarding 49 Detection (BFD) protocol to support Performance Measurement for 50 IP/MPLS network. Specifically, it defines BFD extensions for 51 measuring packet loss, delay and delay variation for arbitrary paths 52 between systems. 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC-2119 [RFC2119]. 60 Table of Contents 62 1. Introduction................................................2 63 2. Abbreviation................................................3 64 3. Terminology.................................................3 65 4. Motivations.................................................4 66 5. Extensions to BFD...........................................6 67 5.1. Packet Loss TLV.........................................8 68 5.2. Packet Delay TLV........................................9 69 6. Theory of Operation........................................11 70 6.1. Packet Loss Measurement................................11 71 6.2. Packet Delay Measurement...............................16 72 6.3. Packet Delay variation Measurement.....................19 73 7. Security Considerations.....................................19 74 8. IANA Considerations........................................19 75 9. Acknowledgments............................................20 76 10. References................................................20 77 10.1. Normative References..................................20 78 10.2. Informative References................................20 79 Authors' Addresses............................................21 81 1. Introduction 83 The Bidirectional Forwarding Detection protocol [BFD] provides a 84 mechanism for liveness detection of arbitrary paths between systems. 85 It is intended to provide low-overhead, short-duration detection of 86 failures in the path between adjacent forwarding engines, including 87 the interfaces, data link(s), and to the extent possible the 88 forwarding engines themselves. 90 BFD could be used in many scenarios for failure detection, which 91 includes one-hop [BFD-1HOP], multi-hop [BFD-MULTI], MPLS LSP [BFD- 92 MPLS], PW VCCV [BFD-VCCV] failure detection. And according to 93 different requirements and situations, BFD provides several 94 combinations of one of those two operating modes (Asynchronous mode 95 and Demand mode) and an additional function (Echo Function) for 96 selection. 98 BFD is designed for failure detection, and so far, most of the 99 applications of BFD are for liveness detection. Based on the 100 mechanisms and functions provided by BFD, BFD could be used for 101 Performance Measurement of arbitrary paths between systems. In this 102 document, the performance is specified to packet loss, packet delay 103 and packet delay variation. This document describes methods and BFD 104 extensions for Performance Measurement. 106 2. Abbreviation 108 PM: Performance Measurement 110 PLM: Packet Loss Measurement 112 PDM: Packet Delay Measurement 114 PDVM: Packet Delay Variation Measurement 116 3. Terminology 118 Proactive OAM: Proactive OAM refers to OAM actions which are carried 119 out continuously to permit proactive reporting of fault and/or 120 performance results. 122 On-demand OAM: On-demand OAM refers to OAM actions which are 123 initiated via manual intervention for a limited time to carry out 124 diagnostics. On-demand OAM can result in singular or periodic OAM 125 actions during the diagnostics time interval. 127 Dual-ended packet loss: Each end sends periodic Dual-ended PLM 128 packets to its peer end to facilitate packet loss measurements at 129 the peer end. Dual-ended PLM is used as proactive PM. 131 Single-ended packet loss: The active node sends Single-ended PLM 132 request massage to the passive node and receives PLM reply packet to 133 carry out packet loss measurements. And the PLM reply packet is sent 134 by the passive when receiving PLM request massage form the active. 135 Single-ended PLM is used for on-demand PM. 137 Near-End packet loss: Near-end packet loss refers to packet loss 138 associated with ingress data packets, and packet loss measurement is 139 performed on the egress node. 141 Far-end packet loss: Far-end packet loss refers to packet loss 142 associated with egress data packets, and packet loss measurement is 143 performed on the egress node. 145 One-way packet delay: is the time elapsed from the start of 146 transmission of the first bit of the packet by a source node until 147 the reception of the last bit of that packet by the destination 148 node. 150 Two-way packet delay: is the time elapsed from the start of 151 transmission of the first bit of the packet by a source node until 152 the reception of the last bit of the loop-backed packet by the 153 same source node, when the loopback is performed at the packet's 154 destination node. 156 4. Motivations 158 Currently, more and more new real-time services (e.g. Voice, Video, 159 Multimedia etc.) are provided using IP/MPLS networks, these new 160 applications have diverse Quality of Service (QoS) requirements that 161 are significantly different from the traditional best-effort service. 162 With the rapid growth of the network and new applications, it brings 163 a serious challenge to IP/MPLS network for performance management 164 and monitoring, which is crucial for IP/MPLS service provider to 165 provide guaranteed services, as well as assure the users that they 166 received the service according to the Services Level Agreements 167 (SLAs) they negotiated with their service provider. 169 The requirements of Performance Measurement are stated in [Y.1541], 170 [Y.1710], [RFC 4377], [MPLS-TP-OAM-REQ] and other documents. The 171 requirements of Performance Measurement could be simply summed up as 172 follows: 174 o Performance Measurement SHOULD at least include packet loss, 175 packet delay and packet delay variation. 177 o For packet loss measurement, 179 - it SHOULD support bidirectional point-to-point paths and 180 unidirectional point-to-point and point-to-multipoint 181 paths, and 183 - it SHOULD support proactive and on-demand mode, and 185 for proactive, it SHOULD support both dual-ended 186 and single-ended modes; 188 for on-demand, it SHOULD support single-ended mode; 190 for both of proactive and on-demand, they SHOULD 191 Near-End and Far-End; 193 o For packet delay and delay variation, 195 - it SHOULD support on-demand mode, and 197 - it SHOULD support both one-way and two-way modes, 199 Packet loss, delay and delay variation are the most typical 200 performance metrics. By measuring these metrics of the specific 201 paths in a network, service providers could detect the performance 202 degradation as soon as possible and take actions proactively. And an 203 OAM tool with Performance Measurement could also be used for 204 assisting in failure location when a failure occurs in a large and 205 complex network. That is, a set of performance monitoring tools are 206 desired for network operators and service providers. But the fact is 207 that there are no feasible standards and universal implementation 208 for IP/MPLS performance measurement. 210 In this document, BFD is proposed for performance measurement, 211 because BFD has the following characteristics which could satisfy 212 the requirements of Performance Measurement indicated above: 214 o BFD is originally designed for OAM and currently is used for 215 failure detection, it is reasonable if BFD is used for 216 performance measurement without adding much more complexity to 217 BFD. BFD [BFD-BASE] has already defined TLV (Type-Length-Value) 218 mechanism for Authentication purpose, two more new TLVs are 219 proposed by this document for performance measurement, with 220 minimum added complexity to BFD. 222 o Normally, BFD is implemented in the data path (line cards), so 223 it's very easy for BFD to get the forwarding statistic 224 information (e.g., received/transmitted packet numbers of a 225 specific path) timely, hence if BFD is used for performance 226 measurement, it will increase the accuracy of performance 227 measurement. 229 o BFD protocol is very simple, for its low-overhead and 230 efficiency in failure detection, it is implemented by most of 231 the vendors on their devices and it is widely deployed in the 232 networks. If BFD is used for performance measurement, many 233 existing mechanisms (e.g., session establishment, parameter 234 negotiation, control packet formats) of BFD could be reused for 235 performance measurement. Hence there is no need to define a new 236 protocol. 238 o BFD is applicable to IP and MPLS, and point-to-point and point- 239 to-multipoint paths as well. So BFD with performance 240 measurement extensions is also applicable to IP and MPLS, and 241 point-to-point and point-to-multipoint path. 243 o BFD defines two operating modes, which are referred to as 244 Asynchronous and Demand mode. These two modes could be exactly 245 used to fulfill the requirements of Performance Measurement, 246 which are required to support proactive and on-demand, one-way 247 and two-way, as well as single-ended and dual-ended. 249 o BFD protocol support more than one authentication mechanism to 250 allow the receiving system to determine the validity of the 251 received packet. All OAM massages need Authentication mechanism 252 which is suggested by [MPLS-TP-OAM-REQ]. Performance 253 measurement as one of OAM tools also needs authentication for 254 security consideration. If BFD be used for performance 255 measurement, the authentication mechanisms of BFD MAY be reused, 256 and it no need to redefined a new set. 258 So, BFD is applicable to be used for Performance Measurement. The 259 detailed definitions and procedures are discussed in the following 260 sections. 262 5. Extensions to BFD 264 The BFD control packet is consisted of a Mandatory section and an 265 Optional Authentication Section, which is defined in [BFD]. The 266 Authentication Section is actually a Type-Length-Value (TLV) 267 structure that is indicated by the A (Authentication present) bit 268 whether the Authentication Section exists. There are five 269 Authentication TLVs that are defined in [BFD] and each of them is 270 identified by the Auth Type. 272 In this document, two new TLVs, which are referred to as Packet Loss 273 TLV and Packet Delay TLV, are added to the ''Optional'' Section of BFD 274 control packet for packet loss, delay and delay variation 275 measurement. Based on the reality of the current definition and 276 usage of BFD header, there is no more free fields and flags that 277 could be used to indicate whether these new TLVs exists, hence the 278 receiver can not correctly intercept and interpret the BFD control 279 packet with performance measurement purpose. So, there are two 280 solutions proposed in this document: 282 o Change the semantic of the A (Authentication Section presents) 283 bit: 285 Currently, the Optional Section is defined only for carrying 286 Authentication TLVs. The Performance Measurement TLVs defined 287 in this document could be carried in the Optional Section, it 288 just needs to change the special A bit to a common O (Optional 289 Section presents) bit, if the O bit is set in a received BFD 290 control packet, it indicates that the Optional Section is 291 present. Then how to process the TLVs carried in the Optional 292 Section is based on the type a specific TLV. 294 Since there are several Authentication types defined in [BFD], 295 presumably, the process of the Authentication TLVs is most like 296 this: the receiver is indicated whether the Optional Section 297 exists by checking the A bit, then steps into a specific 298 Authentication procedure based on the TLV type. So changing the 299 semantic of A bit to O bit will not bring much impact to the 300 processing of the existing Authentication procedure, 301 implementations using current definitions may be not impacted 302 by the change at all. 304 o Version 2 BFD: 306 In order not to impact the current BFD implements and provide 307 better backward compatibility, it may be a good idea to define a 308 new version of BFD. The Mandatory Section of the new version BFD 309 Control packet is defined as follows: 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 |Vers | Diag |Sta|P|F|C|O|D|M| Detect Mult | Length | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | My Discriminator | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Your Discriminator | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Desired Min TX Interval | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Required Min RX Interval | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Required Min Echo RX Interval | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Compared to version 1, the version number is updated to 2, the A 328 bit is changed to O bit. 330 [Discussion: IMHO, there is a bit of waste that the ''Detect Mult'' 331 field is assigned 8 bits, actually, 6 bits is enough, hence there 332 could be reserved two more bits for use by any other future 333 defined functions.] 335 5.1. Packet Loss TLV 337 The Packet Loss TLV is defined for packet loss measurement, by 338 carrying some essential statistic information (e.g., the number of 339 transmitted packets, the number of received packet), which could be 340 used by each of the two ends of a specific path to perform packet 341 loss ratio calculation. The format of the Packet Loss TLV is as 342 follows: 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Type | Length | Sequence | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | TxPacCount_l | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | RxPacCount_l | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | TxPacCount_f | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 Figure 1: Packet Lost TLV 358 The Packet Loss TLV is TLV type TBD, and is 12 bytes in length, the 359 value of length includes the Type and Length field. 361 The Sequence field specifies the sequence number of a BFD Packet 362 Loss Measurement (PLM) packet. It is generated by the end who 363 initiates the measurement, the middle nodes and other side MUST not 364 change the sequence number when propagate or reply the PLM packet. 365 The sequence number could be used for loss detection of PLM packets 366 or for the initiator to make sure the received PLM packet is a 367 response of a previous PLM packet sent by itself. 369 The TxPacCount_l contains the local counter of the transmitted 370 packets from the beginning of this measurement to the time when 371 sending this BFD PLM packet. 373 The RxPacCount_l contains the local counter of the received packets 374 from the beginning of this measurement to the time when received a 375 BFD PLM packet. 377 The TxPacCount_f is copied from the TxPacCount_l of the last 378 received BFD PLM packet when needs to reply a received BFD PLM 379 packet with the statistic information back to initiator of this 380 measurement for packet loss ratio calculation. 382 The detailed procedures on how to use the Packet Loss TLV in 383 different scenarios for packet loss measurement are described in 384 Section 4 of this document. 386 5.2. Packet Delay TLV 388 The Packet Delay TLV is defined for packet delay and delay variation 389 measurement. The Packet Delay TLV is TLV type TBD, and is 12 bytes 390 in length, the value of length includes the Type and Length field. 391 The format of the Packet Delay TLV is as follows: 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Type | Length | Sequence | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | TxTimeStamp_a | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | RxTimeStamp_p | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | TxTimeStamp_p | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Figure 2: Packet Delay TLV 407 The Sequence field specifies the sequence number of a BFD Packet 408 Delay Measurement (PDM) packet. It is generated by the end who 409 initiates the measurement, the middle nodes and other side MUST not 410 change the sequence number when propagate or reply the PDM packet. 411 The sequence number could be used for PDM packets loss detection or 412 for the initiator to make sure the received PDM packet is a response 413 of a previous PDM packet sent by itself. 415 TxTimeStamp_a specifies the time stamp of the Active_End when 416 transmitting a BFD Packet Delay Measurement (PDM) request packet. 418 RxTimeStamp_p specifies the time stamp of the Passive_End when 419 receiving a BFD PDM request packet. 421 TxTimeStamp_p specifies the time stamp of the passive end when 422 transmitting the BFD PDM reply packet to a previous BFD PDM request 423 packet. 425 Active_End is the node that initiates the measurement, Passive_End 426 is the node that will not initiate a measurement and just act to, if 427 needed, the Active_End when received a PDM request packet. 429 The detailed procedures on how to use the Packet Delay TLV in 430 different scenarios for packet delay and delay variation measurement 431 are described in Section 4 of this document. 433 6. Theory of Operation 435 BFD defines two different operating modes, which are known as 436 Asynchronous mode and Demand mode. 438 With asynchronous mode, the systems periodically send BFD Control 439 packets to one another, and each system judges and declares the 440 session down independently if a number of those packets in a row are 441 not received. The Asynchronous mode may be used to achieve a pro- 442 active Performance Measurement that can be carried out continuously 443 to permit proactive reporting of performance results. 445 For demand mode, once a BFD session is established, the two systems 446 will stop sending BFD Control packets, except when the system feels 447 the need to verify connectivity explicitly. Demand mode may operate 448 independently in each direction, or simultaneously. The BFD demand 449 mode may be used to support an on-demand Performance Measurement 450 mechanism. 452 6.1. Packet Loss Measurement 454 To perform packet loss measurement of a specific path, two things 455 need to be done: 1)whatever each of the two ends will calculate the 456 ratio of packet loss, it gets to know the number of not only the 457 transmitted packets at the sender, but the received packets at the 458 receiver in a certain measurement period, 2)and the receiver gets to 459 be aware of the right time when to start counting and when to 460 calculate the number of received packets for a specific measurement 461 period as well. 463 In this document, the Packet Loss TLV is defined for the two ends of 464 a specific path to exchange statistic information of the transmitted 465 and/or received packets for the certain measurement periods, which 466 could be used for each of the two ends to perform packet loss 467 calculation. 469 Since this draft intends to use a PLM packet where TxPacCount_l is 470 set to zero to notify the receiver to start counting, and subsequent 471 PLM packets are used to notify the receiver when to count the number 472 of received packets from the beginning of counting time to the time 473 when received the last PLM packet. So, with such mechanism, time 474 synchronization is not necessary. 476 Depending on the scenario, the operators could choose any side of 477 the two systems for packet loss ratio calculation, which results in 478 several measurement modes/methods as described below for selection. 480 Near-end PLM is to measure the loss of packet sending from the far 481 end, and on the contrary, the for-end PLM is to measure the loss of 482 packet sending by this self end. 484 For the difference of operation, Packet loss measurement may be 485 performed in two modes, dual-ended PLM and single-ended PLM. 487 4.1.1 Dual-ended PLM 489 +-+-+ +-+-+ 490 | A | | B | 491 +-+-+ +-+-+ 492 Start T1|---BFD PLM Packet --->|TT1 493 | | 494 | | 495 T2|---BFD PLM Packet --->|TT2 First Calculation 496 | | 497 | . | 498 | . | 499 | . | 500 | | 501 Tn|---BFD PLM Packet --->|TTn Nth Calculation 502 | | 503 | | 504 | | 506 Figure 3: Dual-ended near-end Packet lost measurement 508 Dual-ended PLM is the mode that each end independently sends 509 periodic BFD PLM packets to the other end, the end who receives the 510 PLM packets will perform packet loss ratio calculation. Dual-ended 511 PLM can be used as a pro-active measurement mode. For dual-ended PLM, 512 it is expected to support two measurements that are referred to as 513 Near-end and Far-end. Near-end PLM is intended to measure the packet 514 loss sent from the other ends, and on the contrary, Far-end PLM 515 means that the node performs packet loss calculation for the packets 516 sent by itself. 518 Figure 3 describes the flow of Near-end packet loss measurement, 519 where A is the node who initiates the packet loss measurement and B 520 is the node who is responsible for packet loss ratio calculation, 521 and vice versa. 523 When dual-ended PLM is enabled, if node B is configured to support 524 near-end PLM, A will send periodic BFD PLM packet to B, and start 525 counting the transmitted packets. The BFD PLM packets carry the PLM 526 TLV, in which the parameters TxPacCount_l and sequence will be 527 included. For near-end measurement, the other two parameters, 528 RxPacCount_l and TxPacCount_f, are not needed and should be ignored 529 on receipt, the two fields MUST be set to zero when transmitting. 530 When received a PLM packet, node B will read and record the value of 531 Local Received Packet Counter (LRPC), which contains the numbers of 532 the received packets, as well the parameter TxPacCount_l from the 533 received PLM packet. By using the statistic information carried/ in 534 the PLM packet and LRPC this time and the previous, node B can 535 perform near-end packet loss measurement. Given that Tn1 and Tn2 are 536 the time of node A sending two different PLM packets, and TTn1 and 537 TTn2 are correspondingly the time of the two PLM packets received by 538 node B. With the formula as follows, node B could calculate the 539 numbers of loss packets. The calculation interval is based on the 540 sending interval of PLM packets, it can be set to any reasonable 541 value as requirements (e.g., it could be set to 100ms). The sequence 542 could be used for loss detection of PLM packets. 544 Packet Loss [near-end]=|TxPacCount_l[Tn2] - TxPacCount_l[Tn1]|- 545 |RxPacCountl[TTn2]- RxPacCountl[TTn1]| 547 +-+-+ +-+-+ 548 | A | | B | 549 +-+-+ +-+-+ 550 Start T1|---BFD PLM Packet --->|TT1 551 |<---BFD PLM Packet ---| 552 | | 553 T2|---BFD PLM Packet --->|TT2 554 First Calculation|<---BFD PLM Packet ---| 555 | . | 556 | . | 557 | . | 558 Tn|---BFD PLM Packet --->|TTn 559 Tn Nth Calculation|<---BFD PLM Packet ---| 560 | | 561 | | 562 Figure 4: Dual-ended far-end Packet lost measurement 564 Figure 4 describes the flow of far-end packet loss measurement. Node 565 A sends PLM packets to node B and performs the calculation of packet 566 loss when received for these packets sending by itself. 568 When dual-ended PLM is enabled, and A is configured to support far- 569 ended PLM measurement, the same as near-ended PLM, node A will send 570 periodic BFD PLM packet with the TxPacCount_l and sequence 571 parameters set to node B. The difference is that, node B SHOULD also 572 send periodic BFD PLM packets to node A, with parameters 573 RxPacCount_l and TxPacCount_f that specify the value of local 574 received packet counter (LRPC) and the value of TxPacCount_l which 575 is carried in a previous PLM packet received from node A. The same 576 as near-end packet loss measurement, when received a PLM packet from 577 node B, node A will record the parameters from the PLM packet and 578 read the value of LRPC, then using parameters of this time and the 579 previous, node A can perform far-end packet loss calculation. Tn1 580 and Tn2 specify the time of two difference PLM packets sending from 581 node A, and TTn1 and TTn2 are the corresponding time of node B 582 received these two packets. The formula of calculation is as follow. 584 Packet Loss [far-end]=|TxPacCount_f[Tn2] -TxPacCount_f[Tn1]| - 585 |RxPacCount_l[TTn2] - RxPacCount_l[TTn1]| 587 Near-end and Far-end could be enabled at the same time in one node. 589 4.1.2 Single-ended PLM 590 +-+-+ +-+-+ 591 | A | | B | 592 +-+-+ +-+-+ 593 Active T1|---BFD PLM Request--->|TT1 Passive 594 |<---BFD PLM Reply ----| 595 | | 596 T2|---BFD PLM Request--->|TT2 597 First Calculation |<---BFD PLM Reply ----| 598 | . | 599 | . | 600 | . | 601 | | 602 Tn|---BFD PLM Request--->|TTn 603 Nth Calculation |<---BFD PLM Reply ----| 604 | | 605 | | 607 Figure 5: Single-ended Packet loss measurement 609 Single-ended means that the side touches off the measurement and 610 will perform the packet loss calculation by itself, which implies 611 that the other side should send the packets statistics of the 612 measurement back to the initiator. 614 Single-ended PLM can be used as an on-demand measurement mode. Once 615 this mode is enabled, the active system sends BFD PLM request packet 616 with the PLM TLV to the passive node, and receives the BFD PLM reply 617 packet from the peer, then performs packet loss calculation. BFD 618 demand mode is applicable for being used to support Single-ended PLM. 620 The flow of single-ended Packet Loss Measurement is described as 621 Figure 5. Node A is the active system which by sending the BFD PLM 622 request packet to node B to initiate a specific packet loss 623 measurement. Node B is the passive node that will send PLM reply 624 packet back to node A when received a PLM request packet. 626 The same as Dual-ended packet loss measurement, Single-ended PLM is 627 also expected to support Near-end and Far-end measurement. When 628 Single-ended PLM is enabled on node A, it will initiate a specific 629 measurement by sending BFD PLM request packets to node B. For Far- 630 end PLM, the TxPacCount_l containing the number of transmitted 631 packets MUST be included in the PLM TLV. When a specific measurement 632 started, the node starts to count the transmitted and received 633 packets. When received a PLM request packet, node B will send A the 634 PLM reply packet with the PLM TLV containing the three counters 635 TxPacCount_l, RxPacCount_l and TxPacCount_f, and the sequence copied 636 from a previous PLM request packet. TxPacCount_f is identical to 637 TxPacCount_l of the last received PLM request packet. When doing 638 Near-end PLM, TxPacCount_l MUST be included in the PLM TLV and the 639 other two counter are not necessary and should be set to zero. For 640 Far-end PLM, RxPacCount_l and TxPacCount_f MUST be included and the 641 other counter TxPacCount_l is not necessary and should be set to 642 zero. When Near-end and Far-end PLM are expected to be supported at 643 the same time, the three counters MUST be included. When node A 644 receives a PLM reply packet,it will read and record the counters 645 from the PLM reply packet, as well the value of local packet 646 reception counter. Based on the counters from any twice records 647 which may be continuous or not, node A can perform packet loss 648 calculation of the period. 650 Tn1 and Tn2 specify the time of two difference PLM request packets 651 sending from A, and TTn1 and TTn2 are the corresponding time of B 652 received these two packets. 654 The formulas of Near-end and Far-end are as follows. 656 Packet Loss [near-end]=|TxPacCount_l[Tn2] -TxPacCount_l[Tn1]| - 657 |RxPacCountl[TTn2] - RxPacCountl[TTn1]| 659 Packet Loss [far-end]=|TxPacCount_f[Tn2] -TxPacCount_f[Tn1]| - 660 |RxPacCount_l[TTn2] - RxPacCount_l[TTn1]| 662 The formulas below are for packet loss ratio: 664 Packet Loss Ratio[near-end] = (Packet Loss[near-end] 665 /(|TxPacCount_l[Tn2] -TxPacCount_l[Tn1]|)) *100% 667 Packet Loss Ratio[far-end] = (Packet Loss[far-end] 668 /(|TxPacCount_f[Tn2] -TxPacCount_f[Tn1]|)) *100% 670 6.2. Packet Delay Measurement 672 Packet delay measurement can be used for on-demand Performance 673 Measurement. In this document, BFD control packets with PDM TLV 674 containing the timestamps of sending and receiving PDM packet 675 between the two systems are used to perform packet delay and delay 676 variation measurement. Packet delay measurement is performed by 677 sending periodic BFD PDM packets from one system to another, and two 678 modes that are referred to as one-way and two-way delay measurement 679 are defined to be applied for different situations. 681 4.2.1 One-way PDM 683 +-+-+ +-+-+ 684 | A | | B | 685 +-+-+ +-+-+ 686 Start T1|---BFD PDM Packet --->|TT1 687 | | 688 | | 689 T2|---BFD PDM Packet --->|TT2 First Calculation 690 | | 691 | . | 692 | . | 693 | . | 694 | | 695 Tn|---BFD PDM Packet --->|TTn Nth Calculation 696 | | 697 | | 698 | | 700 Figure 6: One-Way Packet Delay measurement 702 In one-way mode, one system sends BFD PDM packet carrying the local 703 timestamp to facilitate packet delay measurement on the other end. 704 Both BFD demand mode or asynchronous mode are applicable for one-way 705 delay measurement. Figure 6 describes the flow of One-way PDM. 707 When One-way packet delay measurement is enabled, the active node A 708 will transmit BFD PDM packets with the PDM TLV, in which the 709 TxTimeStamp_a and sequence MUST be included. When received a PDM 710 packet, according to the TxTimeStamp_a from the received PDM packet 711 and the local timestamp, node B could perform packet delay 712 calculation. The formula is as follows. 714 Packet Delay [one-way] = RxTime_a - TxTimeStamp_a 716 RxTime_a is the local timestamp of node B when receiving the PDM 717 packet. If the time difference Delta_t of the two ends is already 718 known, the calculation formula could be as follows. 720 Packet Delay [one-way] = RxTime_a - TxTimeStamp_a + Delta_t 721 For one-way PDM being dependent on the synchronization of clock/time 722 between the two systems, the synchronization of clock/time is 723 desired. 725 4.2.1 Two-way PDM 727 +-+-+ +-+-+ 728 | A | | B | 729 +-+-+ +-+-+ 730 Start T1 |---BFD PDM Request--->|TT1 731 T1'|<---BFD PDM Reply ----|TT1' 732 | | 733 T2 |---BFD PDM Packet --->|TT2 734 First Calculation T2'|<---BFD PDM Reply ----|TT2' 735 | . | 736 | . | 737 | . | 738 | | 739 Tn |---BFD PDM Packet --->|TTn 740 Nth Calculation Tn'|<---BFD PDM Reply ----|TTn' 741 | | 742 | | 744 Figure 7: Two-way Packet Delay measurement 746 Two-way PDM is a request-reply mode, which one system as the active 747 end initiates the PDM request packet, the other system acts as 748 passive end will send back a PDM reply packet when received the PDM 749 request packet. Then the active end will perform two-way packet 750 delay calculation. For the characters of this mode, BFD demand mode 751 is preferred. Figure 7 describes the operation flow. 753 When two-way PDM is enabled, node A as the active end will send BFD 754 PDM request packets with Packet Delay TLV to the other end, node B. 755 The same as the one-way mode, the local timestamp TxTimeStamp_a and 756 sequence MUST be included. When node B received a BFD PDM request 757 packet, it will reply by sending a PDM reply packet with PDM TLV 758 containing the timestamp and sequence copied from of the received 759 PDM request packet. 761 Once received the PDM reply packet, node A will perform packet delay 762 calculation. The formula is as follows. 764 Packet Delay [two-way] = RxTime_a - TxTimeStamp_a 765 RxTime_a is the timestamp of the active end receiving the PDM reply 766 packet from the passive end. 768 The other two additional timestamps in the packet delay TLV, 769 RxTimeStamp_p and TxTimeStamp_p, stand for the timestamps that the 770 passive end receiving the PDM request packet and sending the PDM 771 reply packet to the active end respectively, which could be used to 772 perform more precise two-way packet delay measurement. As an option, 773 if operator wants to take into account the processing time at the 774 node B, the two additional timestamps should be included in the PDM 775 reply packet by the passive end. Formula for calculation is bellow. 777 Packet Delay [two-way] = (RxTime_a - TxTimeStamp_a) - 778 (TxTimeStamp_p-RxTimeStamp_p) 780 Two-way PDM is relaxed for synchronization of clock. So if the 781 clocks are not practical to be synchronized between the two ends, 782 which may be a common scenario, two-way delay measurement mode could 783 be used. 785 6.3. Packet Delay variation Measurement 787 Packet delay variation measurement is based on the difference of 788 subsequent packet delay measurement. The Packet Delay Variation is 789 relaxed for synchronization of clock and could be calculated by the 790 formulas below. 792 Frame Delay Variation[one-way] = Frame Delay2 [one-way] - Frame 793 Delay1 [one-way] 795 Frame Delay Variation[two-way] = Frame Delay2 [two-way] - Frame 796 Delay1 [two-way] 798 7. Security Considerations 800 Security considerations discussed in [BFD], [BFD-MHOP] and [RFC4379] 801 apply to this document. 803 8. IANA Considerations 805 IANA is requested to assign two new TLVs for Performance Measurement. 806 The following numbers are suggested. 808 Value Meaning 810 6 Packet loss TLV 811 7 Packet delay TLV 813 9. Acknowledgments 815 The authors would like to thank Jian Li and Wei Cao for their 816 comments and help for preparing this document. 818 10. References 820 10.1. Normative References 822 [RFC 4377] Nadeau, T., et al., ''Operations and Management (OAM) 823 Requirements for Multi-Protocol Label Switched (MPLS) 824 Networks'', RFC 4377, February 2006. 826 [RFC 4378] D. Allan, Ed., T. Nadeau, Ed.,'' A Framework for Multi- 827 Protocol Label Switching (MPLS) Operations and Management 828 (OAM)'', RFC 4378, February 2006. 830 [Y.1710] ITU-T Recommendation Y.1710, "Requirements for OAM 831 Functionality for MPLS Networks". November, 2002. 833 [Y.1731] ITU-T Y.1731 OAM functions and mechanisms for Ethernet 834 based networks. May, 2006. 836 [Y.1373/G.8114] ITU-T Recommendation Y.1373/G.8114, ''Operation & 837 maintenance mechanism for T-MPLS layer networks'', 839 [Y.1541] Network Performance Objectives for IP-Based Services. 841 [Y.Sup4] ITU-T Supplement Y.Sup4 (2008), Transport Requirements for 842 T-MPLS OAM and considerations for the application of IETF 843 MPLS Technology. 845 10.2. Informative References 847 [BFD] Katz, D., et al., " Bidirectional Forwarding Detection ", 848 draft-ietf-bfd-base-08.txt, {work in progress}. 850 [BFD-VCCV] Nadeau, T., Pignataro, C., et al., " Bidirectional 851 Forwarding Detection (BFD) for the Pseudowire Virtual 852 Circuit Connectivity Verification (VCCV) ", draft-ietf- 853 pwe3-vccv-bfd-02, {work in progress}. 855 [MPLS-TP-OAM-REQ] Vigoureux, M., Wardet, D., Betts, M., " 856 Requirements for OAM in MPLS Transport Networks ", draft- 857 vigoureux-mpls-tp-oam-requirements-00.txt, {work in 858 progress} 860 [BFD-1HOP] Katz, D., Ward, D.,'' BFD for IPv4 and IPv6 (Single Hop)'', 861 draft-ietf-bfd-v4v6-1hop-08.txt, {work in progress}. 863 [BFD-MULTI] Katz, D., Ward, D.,'' BFD for Multihop Paths'', draft- 864 ietf-bfd-multihop-06.txt, {work in progress}. 866 [BFD-MPLS] Aggarwal, R., et al., ''BFD For MPLS LSPs '', draft-ietf- 867 bfd-mpls-07.txt, {work in progress} 869 Authors' Addresses 871 Xinchun Guo 872 Huawei Technologies Co.,Ltd 873 KuiKe Building, No.9 Xinxi Rd., 874 Hai-Dian District 875 Beijing, 100085 876 P.R. China 878 Email: guoxinchun@huawei.com 880 Mach(Guoyi) Chen 881 Huawei Technologies Co.,Ltd 882 KuiKe Building, No.9 Xinxi Rd., 883 Hai-Dian District 884 Beijing, 100085 885 P.R. China 887 Email: mach@huawei.com 889 Kwok Ho Chan 890 Huawei Technologies 891 125 Nagog Park 892 Acton, MA 01720 893 USA 895 Email: khchan@huawei.com