Network working group X. Guo Internet Draft M. Chen Category: Standards Track K.Chan Created: March 10, 2009 Huawei Technologies Co.,Ltd Expires: September 2009 BFD Extensions in Support of Performance Measurement draft-guo-bfd-pm-extension-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 15, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Guo, Chen and Chan. Expires September 10, 2009 [Page 1] Internet-Draft BFD extensions for PM March 2009 Abstract This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to support Performance Measurement for IP/MPLS network. Specifically, it defines BFD extensions for measuring packet loss, delay and delay variation for arbitrary paths between systems. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Table of Contents 1. Introduction................................................2 2. Abbreviation................................................3 3. Terminology.................................................3 4. Motivations.................................................4 5. Extensions to BFD...........................................6 5.1. Packet Loss TLV.........................................8 5.2. Packet Delay TLV........................................9 6. Theory of Operation........................................11 6.1. Packet Loss Measurement................................11 6.2. Packet Delay Measurement...............................16 6.3. Packet Delay variation Measurement.....................19 7. Security Considerations.....................................19 8. IANA Considerations........................................19 9. Acknowledgments............................................20 10. References................................................20 10.1. Normative References..................................20 10.2. Informative References................................20 Authors' Addresses............................................21 1. Introduction The Bidirectional Forwarding Detection protocol [BFD] provides a mechanism for liveness detection of arbitrary paths between systems. It is intended to provide low-overhead, short-duration detection of failures in the path between adjacent forwarding engines, including the interfaces, data link(s), and to the extent possible the forwarding engines themselves. Guo, Chen, and Chan. Expires September 10, 2009 [Page 2] Internet-Draft BFD extensions for PM March 2009 BFD could be used in many scenarios for failure detection, which includes one-hop [BFD-1HOP], multi-hop [BFD-MULTI], MPLS LSP [BFD- MPLS], PW VCCV [BFD-VCCV] failure detection. And according to different requirements and situations, BFD provides several combinations of one of those two operating modes (Asynchronous mode and Demand mode) and an additional function (Echo Function) for selection. BFD is designed for failure detection, and so far, most of the applications of BFD are for liveness detection. Based on the mechanisms and functions provided by BFD, BFD could be used for Performance Measurement of arbitrary paths between systems. In this document, the performance is specified to packet loss, packet delay and packet delay variation. This document describes methods and BFD extensions for Performance Measurement. 2. Abbreviation PM: Performance Measurement PLM: Packet Loss Measurement PDM: Packet Delay Measurement PDVM: Packet Delay Variation Measurement 3. Terminology Proactive OAM: Proactive OAM refers to OAM actions which are carried out continuously to permit proactive reporting of fault and/or performance results. On-demand OAM: On-demand OAM refers to OAM actions which are initiated via manual intervention for a limited time to carry out diagnostics. On-demand OAM can result in singular or periodic OAM actions during the diagnostics time interval. Dual-ended packet loss: Each end sends periodic Dual-ended PLM packets to its peer end to facilitate packet loss measurements at the peer end. Dual-ended PLM is used as proactive PM. Single-ended packet loss: The active node sends Single-ended PLM request massage to the passive node and receives PLM reply packet to carry out packet loss measurements. And the PLM reply packet is sent by the passive when receiving PLM request massage form the active. Single-ended PLM is used for on-demand PM. Guo, Chen, and Chan. Expires September 10, 2009 [Page 3] Internet-Draft BFD extensions for PM March 2009 Near-End packet loss: Near-end packet loss refers to packet loss associated with ingress data packets, and packet loss measurement is performed on the egress node. Far-end packet loss: Far-end packet loss refers to packet loss associated with egress data packets, and packet loss measurement is performed on the egress node. One-way packet delay: is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of that packet by the destination node. Two-way packet delay: is the time elapsed from the start of transmission of the first bit of the packet by a source node until the reception of the last bit of the loop-backed packet by the same source node, when the loopback is performed at the packet's destination node. 4. Motivations Currently, more and more new real-time services (e.g. Voice, Video, Multimedia etc.) are provided using IP/MPLS networks, these new applications have diverse Quality of Service (QoS) requirements that are significantly different from the traditional best-effort service. With the rapid growth of the network and new applications, it brings a serious challenge to IP/MPLS network for performance management and monitoring, which is crucial for IP/MPLS service provider to provide guaranteed services, as well as assure the users that they received the service according to the Services Level Agreements (SLAs) they negotiated with their service provider. The requirements of Performance Measurement are stated in [Y.1541], [Y.1710], [RFC 4377], [MPLS-TP-OAM-REQ] and other documents. The requirements of Performance Measurement could be simply summed up as follows: o Performance Measurement SHOULD at least include packet loss, packet delay and packet delay variation. o For packet loss measurement, - it SHOULD support bidirectional point-to-point paths and unidirectional point-to-point and point-to-multipoint paths, and Guo, Chen, and Chan. Expires September 10, 2009 [Page 4] Internet-Draft BFD extensions for PM March 2009 - it SHOULD support proactive and on-demand mode, and for proactive, it SHOULD support both dual-ended and single-ended modes; for on-demand, it SHOULD support single-ended mode; for both of proactive and on-demand, they SHOULD Near-End and Far-End; o For packet delay and delay variation, - it SHOULD support on-demand mode, and - it SHOULD support both one-way and two-way modes, Packet loss, delay and delay variation are the most typical performance metrics. By measuring these metrics of the specific paths in a network, service providers could detect the performance degradation as soon as possible and take actions proactively. And an OAM tool with Performance Measurement could also be used for assisting in failure location when a failure occurs in a large and complex network. That is, a set of performance monitoring tools are desired for network operators and service providers. But the fact is that there are no feasible standards and universal implementation for IP/MPLS performance measurement. In this document, BFD is proposed for performance measurement, because BFD has the following characteristics which could satisfy the requirements of Performance Measurement indicated above: o BFD is originally designed for OAM and currently is used for failure detection, it is reasonable if BFD is used for performance measurement without adding much more complexity to BFD. BFD [BFD-BASE] has already defined TLV (Type-Length-Value) mechanism for Authentication purpose, two more new TLVs are proposed by this document for performance measurement, with minimum added complexity to BFD. o Normally, BFD is implemented in the data path (line cards), so it's very easy for BFD to get the forwarding statistic information (e.g., received/transmitted packet numbers of a specific path) timely, hence if BFD is used for performance measurement, it will increase the accuracy of performance measurement. Guo, Chen, and Chan. Expires September 10, 2009 [Page 5] Internet-Draft BFD extensions for PM March 2009 o BFD protocol is very simple, for its low-overhead and efficiency in failure detection, it is implemented by most of the vendors on their devices and it is widely deployed in the networks. If BFD is used for performance measurement, many existing mechanisms (e.g., session establishment, parameter negotiation, control packet formats) of BFD could be reused for performance measurement. Hence there is no need to define a new protocol. o BFD is applicable to IP and MPLS, and point-to-point and point- to-multipoint paths as well. So BFD with performance measurement extensions is also applicable to IP and MPLS, and point-to-point and point-to-multipoint path. o BFD defines two operating modes, which are referred to as Asynchronous and Demand mode. These two modes could be exactly used to fulfill the requirements of Performance Measurement, which are required to support proactive and on-demand, one-way and two-way, as well as single-ended and dual-ended. o BFD protocol support more than one authentication mechanism to allow the receiving system to determine the validity of the received packet. All OAM massages need Authentication mechanism which is suggested by [MPLS-TP-OAM-REQ]. Performance measurement as one of OAM tools also needs authentication for security consideration. If BFD be used for performance measurement, the authentication mechanisms of BFD MAY be reused, and it no need to redefined a new set. So, BFD is applicable to be used for Performance Measurement. The detailed definitions and procedures are discussed in the following sections. 5. Extensions to BFD The BFD control packet is consisted of a Mandatory section and an Optional Authentication Section, which is defined in [BFD]. The Authentication Section is actually a Type-Length-Value (TLV) structure that is indicated by the A (Authentication present) bit whether the Authentication Section exists. There are five Authentication TLVs that are defined in [BFD] and each of them is identified by the Auth Type. In this document, two new TLVs, which are referred to as Packet Loss TLV and Packet Delay TLV, are added to the ''Optional'' Section of BFD control packet for packet loss, delay and delay variation Guo, Chen, and Chan. Expires September 10, 2009 [Page 6] Internet-Draft BFD extensions for PM March 2009 measurement. Based on the reality of the current definition and usage of BFD header, there is no more free fields and flags that could be used to indicate whether these new TLVs exists, hence the receiver can not correctly intercept and interpret the BFD control packet with performance measurement purpose. So, there are two solutions proposed in this document: o Change the semantic of the A (Authentication Section presents) bit: Currently, the Optional Section is defined only for carrying Authentication TLVs. The Performance Measurement TLVs defined in this document could be carried in the Optional Section, it just needs to change the special A bit to a common O (Optional Section presents) bit, if the O bit is set in a received BFD control packet, it indicates that the Optional Section is present. Then how to process the TLVs carried in the Optional Section is based on the type a specific TLV. Since there are several Authentication types defined in [BFD], presumably, the process of the Authentication TLVs is most like this: the receiver is indicated whether the Optional Section exists by checking the A bit, then steps into a specific Authentication procedure based on the TLV type. So changing the semantic of A bit to O bit will not bring much impact to the processing of the existing Authentication procedure, implementations using current definitions may be not impacted by the change at all. o Version 2 BFD: In order not to impact the current BFD implements and provide better backward compatibility, it may be a good idea to define a new version of BFD. The Mandatory Section of the new version BFD Control packet is defined as follows: Guo, Chen, and Chan. Expires September 10, 2009 [Page 7] Internet-Draft BFD extensions for PM March 2009 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers | Diag |Sta|P|F|C|O|D|M| Detect Mult | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Your Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Desired Min TX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min Echo RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Compared to version 1, the version number is updated to 2, the A bit is changed to O bit. [Discussion: IMHO, there is a bit of waste that the ''Detect Mult'' field is assigned 8 bits, actually, 6 bits is enough, hence there could be reserved two more bits for use by any other future defined functions.] 5.1. Packet Loss TLV The Packet Loss TLV is defined for packet loss measurement, by carrying some essential statistic information (e.g., the number of transmitted packets, the number of received packet), which could be used by each of the two ends of a specific path to perform packet loss ratio calculation. The format of the Packet Loss TLV is as follows: 0 1 2 3 Guo, Chen, and Chan. Expires September 10, 2009 [Page 8] Internet-Draft BFD extensions for PM March 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TxPacCount_l | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RxPacCount_l | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TxPacCount_f | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Packet Lost TLV The Packet Loss TLV is TLV type TBD, and is 12 bytes in length, the value of length includes the Type and Length field. 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. The TxPacCount_l contains the local counter of the transmitted packets from the beginning of this measurement to the time when sending this BFD PLM packet. The RxPacCount_l contains the local counter of the received packets from the beginning of this measurement to the time when received a BFD PLM packet. The TxPacCount_f is copied from the TxPacCount_l of the last received BFD PLM packet when needs to reply a received BFD PLM packet with the statistic information back to initiator of this measurement for packet loss ratio calculation. The detailed procedures on how to use the Packet Loss TLV in different scenarios for packet loss measurement are described in Section 4 of this document. 5.2. Packet Delay TLV The Packet Delay TLV is defined for packet delay and delay variation measurement. The Packet Delay TLV is TLV type TBD, and is 12 bytes Guo, Chen, and Chan. Expires September 10, 2009 [Page 9] Internet-Draft BFD extensions for PM March 2009 in length, the value of length includes the Type and Length field. The format of the Packet Delay TLV is as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sequence | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TxTimeStamp_a | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RxTimeStamp_p | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TxTimeStamp_p | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Packet Delay TLV 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. TxTimeStamp_a specifies the time stamp of the Active_End when transmitting a BFD Packet Delay Measurement (PDM) request packet. RxTimeStamp_p specifies the time stamp of the Passive_End when receiving a BFD PDM request packet. TxTimeStamp_p specifies the time stamp of the passive end when transmitting the BFD PDM reply packet to a previous BFD PDM request packet. Active_End is the node that initiates the measurement, Passive_End is the node that will not initiate a measurement and just act to, if needed, the Active_End when received a PDM request packet. The detailed procedures on how to use the Packet Delay TLV in different scenarios for packet delay and delay variation measurement are described in Section 4 of this document. Guo, Chen, and Chan. Expires September 10, 2009 [Page 10] Internet-Draft BFD extensions for PM March 2009 6. Theory of Operation BFD defines two different operating modes, which are known as Asynchronous mode and Demand mode. With asynchronous mode, the systems periodically send BFD Control packets to one another, and each system judges and declares the session down independently if a number of those packets in a row are not received. The Asynchronous mode may be used to achieve a pro- active Performance Measurement that can be carried out continuously to permit proactive reporting of performance results. For demand mode, once a BFD session is established, the two systems will stop sending BFD Control packets, except when the system feels the need to verify connectivity explicitly. Demand mode may operate independently in each direction, or simultaneously. The BFD demand mode may be used to support an on-demand Performance Measurement mechanism. 6.1. Packet Loss Measurement To perform packet loss measurement of a specific path, two things need to be done: 1)whatever each of the two ends will calculate the ratio of packet loss, it gets to know the number of not only the transmitted packets at the sender, but the received packets at the receiver in a certain measurement period, 2)and the receiver gets to be aware of the right time when to start counting and when to calculate the number of received packets for a specific measurement period as well. In this document, the Packet Loss TLV is defined for the two ends of a specific path to exchange statistic information of the transmitted and/or received packets for the certain measurement periods, which could be used for each of the two ends to perform packet loss calculation. Since this draft intends to use a PLM packet where TxPacCount_l is set to zero to notify the receiver to start counting, and subsequent PLM packets are used to notify the receiver when to count the number of received packets from the beginning of counting time to the time when received the last PLM packet. So, with such mechanism, time synchronization is not necessary. Depending on the scenario, the operators could choose any side of the two systems for packet loss ratio calculation, which results in several measurement modes/methods as described below for selection. Guo, Chen, and Chan. Expires September 10, 2009 [Page 11] Internet-Draft BFD extensions for PM March 2009 Near-end PLM is to measure the loss of packet sending from the far end, and on the contrary, the for-end PLM is to measure the loss of packet sending by this self end. For the difference of operation, Packet loss measurement may be performed in two modes, dual-ended PLM and single-ended PLM. 4.1.1 Dual-ended PLM +-+-+ +-+-+ | A | | B | +-+-+ +-+-+ Start T1|---BFD PLM Packet --->|TT1 | | | | T2|---BFD PLM Packet --->|TT2 First Calculation | | | . | | . | | . | | | Tn|---BFD PLM Packet --->|TTn Nth Calculation | | | | | | Figure 3: Dual-ended near-end Packet lost measurement Dual-ended PLM is the mode that each end independently sends periodic BFD PLM packets to the other end, the end who receives the PLM packets will perform packet loss ratio calculation. Dual-ended PLM can be used as a pro-active measurement mode. For dual-ended PLM, it is expected to support two measurements that are referred to as Near-end and Far-end. Near-end PLM is intended to measure the packet loss sent from the other ends, and on the contrary, Far-end PLM means that the node performs packet loss calculation for the packets sent by itself. Figure 3 describes the flow of Near-end packet loss measurement, where A is the node who initiates the packet loss measurement and B is the node who is responsible for packet loss ratio calculation, and vice versa. Guo, Chen, and Chan. Expires September 10, 2009 [Page 12] Internet-Draft BFD extensions for PM March 2009 When dual-ended PLM is enabled, if node B is configured to support near-end PLM, A will send periodic BFD PLM packet to B, and start counting the transmitted packets. The BFD PLM packets carry the PLM TLV, in which the parameters TxPacCount_l and sequence will be included. For near-end measurement, the other two parameters, RxPacCount_l and TxPacCount_f, are not needed and should be ignored on receipt, the two fields MUST be set to zero when transmitting. When received a PLM packet, node B will read and record the value of Local Received Packet Counter (LRPC), which contains the numbers of the received packets, as well the parameter TxPacCount_l from the received PLM packet. By using the statistic information carried/ in the PLM packet and LRPC this time and the previous, node B can perform near-end packet loss measurement. Given that Tn1 and Tn2 are the time of node A sending two different PLM packets, and TTn1 and TTn2 are correspondingly the time of the two PLM packets received by node B. With the formula as follows, node B could calculate the numbers of loss packets. The calculation interval is based on the sending interval of PLM packets, it can be set to any reasonable value as requirements (e.g., it could be set to 100ms). The sequence could be used for loss detection of PLM packets. Packet Loss [near-end]=|TxPacCount_l[Tn2] - TxPacCount_l[Tn1]|- |RxPacCountl[TTn2]- RxPacCountl[TTn1]| +-+-+ +-+-+ | A | | B | +-+-+ +-+-+ Start T1|---BFD PLM Packet --->|TT1 |<---BFD PLM Packet ---| | | T2|---BFD PLM Packet --->|TT2 First Calculation|<---BFD PLM Packet ---| | . | | . | | . | Tn|---BFD PLM Packet --->|TTn Tn Nth Calculation|<---BFD PLM Packet ---| | | | | Figure 4: Dual-ended far-end Packet lost measurement Guo, Chen, and Chan. Expires September 10, 2009 [Page 13] Internet-Draft BFD extensions for PM March 2009 Figure 4 describes the flow of far-end packet loss measurement. Node A sends PLM packets to node B and performs the calculation of packet loss when received for these packets sending by itself. When dual-ended PLM is enabled, and A is configured to support far- ended PLM measurement, the same as near-ended PLM, node A will send periodic BFD PLM packet with the TxPacCount_l and sequence parameters set to node B. The difference is that, node B SHOULD also send periodic BFD PLM packets to node A, with parameters RxPacCount_l and TxPacCount_f that specify the value of local received packet counter (LRPC) and the value of TxPacCount_l which is carried in a previous PLM packet received from node A. The same as near-end packet loss measurement, when received a PLM packet from node B, node A will record the parameters from the PLM packet and read the value of LRPC, then using parameters of this time and the previous, node A can perform far-end packet loss calculation. Tn1 and Tn2 specify the time of two difference PLM packets sending from node A, and TTn1 and TTn2 are the corresponding time of node B received these two packets. The formula of calculation is as follow. Packet Loss [far-end]=|TxPacCount_f[Tn2] -TxPacCount_f[Tn1]| - |RxPacCount_l[TTn2] - RxPacCount_l[TTn1]| Near-end and Far-end could be enabled at the same time in one node. 4.1.2 Single-ended PLM Guo, Chen, and Chan. Expires September 10, 2009 [Page 14] Internet-Draft BFD extensions for PM March 2009 +-+-+ +-+-+ | A | | B | +-+-+ +-+-+ Active T1|---BFD PLM Request--->|TT1 Passive |<---BFD PLM Reply ----| | | T2|---BFD PLM Request--->|TT2 First Calculation |<---BFD PLM Reply ----| | . | | . | | . | | | Tn|---BFD PLM Request--->|TTn Nth Calculation |<---BFD PLM Reply ----| | | | | Figure 5: Single-ended Packet loss measurement Single-ended means that the side touches off the measurement and will perform the packet loss calculation by itself, which implies that the other side should send the packets statistics of the measurement back to the initiator. Single-ended PLM can be used as an on-demand measurement mode. Once this mode is enabled, the active system sends BFD PLM request packet with the PLM TLV to the passive node, and receives the BFD PLM reply packet from the peer, then performs packet loss calculation. BFD demand mode is applicable for being used to support Single-ended PLM. The flow of single-ended Packet Loss Measurement is described as Figure 5. Node A is the active system which by sending the BFD PLM request packet to node B to initiate a specific packet loss measurement. Node B is the passive node that will send PLM reply packet back to node A when received a PLM request packet. The same as Dual-ended packet loss measurement, Single-ended PLM is also expected to support Near-end and Far-end measurement. When Single-ended PLM is enabled on node A, it will initiate a specific measurement by sending BFD PLM request packets to node B. For Far- end PLM, the TxPacCount_l containing the number of transmitted packets MUST be included in the PLM TLV. When a specific measurement started, the node starts to count the transmitted and received Guo, Chen, and Chan. Expires September 10, 2009 [Page 15] Internet-Draft BFD extensions for PM March 2009 packets. When received a PLM request packet, node B will send A the PLM reply packet with the PLM TLV containing the three counters TxPacCount_l, RxPacCount_l and TxPacCount_f, and the sequence copied from a previous PLM request packet. TxPacCount_f is identical to TxPacCount_l of the last received PLM request packet. When doing Near-end PLM, TxPacCount_l MUST be included in the PLM TLV and the other two counter are not necessary and should be set to zero. For Far-end PLM, RxPacCount_l and TxPacCount_f MUST be included and the other counter TxPacCount_l is not necessary and should be set to zero. When Near-end and Far-end PLM are expected to be supported at the same time, the three counters MUST be included. When node A receives a PLM reply packet,it will read and record the counters from the PLM reply packet, as well the value of local packet reception counter. Based on the counters from any twice records which may be continuous or not, node A can perform packet loss calculation of the period. Tn1 and Tn2 specify the time of two difference PLM request packets sending from A, and TTn1 and TTn2 are the corresponding time of B received these two packets. The formulas of Near-end and Far-end are as follows. Packet Loss [near-end]=|TxPacCount_l[Tn2] -TxPacCount_l[Tn1]| - |RxPacCountl[TTn2] - RxPacCountl[TTn1]| Packet Loss [far-end]=|TxPacCount_f[Tn2] -TxPacCount_f[Tn1]| - |RxPacCount_l[TTn2] - RxPacCount_l[TTn1]| The formulas below are for packet loss ratio: Packet Loss Ratio[near-end] = (Packet Loss[near-end] /(|TxPacCount_l[Tn2] -TxPacCount_l[Tn1]|)) *100% Packet Loss Ratio[far-end] = (Packet Loss[far-end] /(|TxPacCount_f[Tn2] -TxPacCount_f[Tn1]|)) *100% 6.2. Packet Delay Measurement Packet delay measurement can be used for on-demand Performance Measurement. In this document, BFD control packets with PDM TLV containing the timestamps of sending and receiving PDM packet between the two systems are used to perform packet delay and delay variation measurement. Packet delay measurement is performed by Guo, Chen, and Chan. Expires September 10, 2009 [Page 16] Internet-Draft BFD extensions for PM March 2009 sending periodic BFD PDM packets from one system to another, and two modes that are referred to as one-way and two-way delay measurement are defined to be applied for different situations. 4.2.1 One-way PDM +-+-+ +-+-+ | A | | B | +-+-+ +-+-+ Start T1|---BFD PDM Packet --->|TT1 | | | | T2|---BFD PDM Packet --->|TT2 First Calculation | | | . | | . | | . | | | Tn|---BFD PDM Packet --->|TTn Nth Calculation | | | | | | Figure 6: One-Way Packet Delay measurement In one-way mode, one system sends BFD PDM packet carrying the local timestamp to facilitate packet delay measurement on the other end. Both BFD demand mode or asynchronous mode are applicable for one-way delay measurement. Figure 6 describes the flow of One-way PDM. When One-way packet delay measurement is enabled, the active node A will transmit BFD PDM packets with the PDM TLV, in which the TxTimeStamp_a and sequence MUST be included. When received a PDM packet, according to the TxTimeStamp_a from the received PDM packet and the local timestamp, node B could perform packet delay calculation. The formula is as follows. Packet Delay [one-way] = RxTime_a - TxTimeStamp_a RxTime_a is the local timestamp of node B when receiving the PDM packet. If the time difference Delta_t of the two ends is already known, the calculation formula could be as follows. Packet Delay [one-way] = RxTime_a - TxTimeStamp_a + Delta_t Guo, Chen, and Chan. Expires September 10, 2009 [Page 17] Internet-Draft BFD extensions for PM March 2009 For one-way PDM being dependent on the synchronization of clock/time between the two systems, the synchronization of clock/time is desired. 4.2.1 Two-way PDM +-+-+ +-+-+ | A | | B | +-+-+ +-+-+ Start T1 |---BFD PDM Request--->|TT1 T1'|<---BFD PDM Reply ----|TT1' | | T2 |---BFD PDM Packet --->|TT2 First Calculation T2'|<---BFD PDM Reply ----|TT2' | . | | . | | . | | | Tn |---BFD PDM Packet --->|TTn Nth Calculation Tn'|<---BFD PDM Reply ----|TTn' | | | | Figure 7: Two-way Packet Delay measurement Two-way PDM is a request-reply mode, which one system as the active end initiates the PDM request packet, the other system acts as passive end will send back a PDM reply packet when received the PDM request packet. Then the active end will perform two-way packet delay calculation. For the characters of this mode, BFD demand mode is preferred. Figure 7 describes the operation flow. When two-way PDM is enabled, node A as the active end will send BFD PDM request packets with Packet Delay TLV to the other end, node B. The same as the one-way mode, the local timestamp TxTimeStamp_a and sequence MUST be included. When node B received a BFD PDM request packet, it will reply by sending a PDM reply packet with PDM TLV containing the timestamp and sequence copied from of the received PDM request packet. Once received the PDM reply packet, node A will perform packet delay calculation. The formula is as follows. Packet Delay [two-way] = RxTime_a - TxTimeStamp_a Guo, Chen, and Chan. Expires September 10, 2009 [Page 18] Internet-Draft BFD extensions for PM March 2009 RxTime_a is the timestamp of the active end receiving the PDM reply packet from the passive end. The other two additional timestamps in the packet delay TLV, RxTimeStamp_p and TxTimeStamp_p, stand for the timestamps that the passive end receiving the PDM request packet and sending the PDM reply packet to the active end respectively, which could be used to perform more precise two-way packet delay measurement. As an option, if operator wants to take into account the processing time at the node B, the two additional timestamps should be included in the PDM reply packet by the passive end. Formula for calculation is bellow. Packet Delay [two-way] = (RxTime_a - TxTimeStamp_a) - (TxTimeStamp_p-RxTimeStamp_p) Two-way PDM is relaxed for synchronization of clock. So if the clocks are not practical to be synchronized between the two ends, which may be a common scenario, two-way delay measurement mode could be used. 6.3. Packet Delay variation Measurement Packet delay variation measurement is based on the difference of subsequent packet delay measurement. The Packet Delay Variation is relaxed for synchronization of clock and could be calculated by the formulas below. Frame Delay Variation[one-way] = Frame Delay2 [one-way] - Frame Delay1 [one-way] Frame Delay Variation[two-way] = Frame Delay2 [two-way] - Frame Delay1 [two-way] 7. Security Considerations Security considerations discussed in [BFD], [BFD-MHOP] and [RFC4379] apply to this document. 8. IANA Considerations IANA is requested to assign two new TLVs for Performance Measurement. The following numbers are suggested. Value Meaning 6 Packet loss TLV Guo, Chen, and Chan. Expires September 10, 2009 [Page 19] Internet-Draft BFD extensions for PM March 2009 7 Packet delay TLV 9. Acknowledgments The authors would like to thank Jian Li and Wei Cao for their comments and help for preparing this document. 10. References 10.1. Normative References [RFC 4377] Nadeau, T., et al., ''Operations and Management (OAM) Requirements for Multi-Protocol Label Switched (MPLS) Networks'', RFC 4377, February 2006. [RFC 4378] D. Allan, Ed., T. Nadeau, Ed.,'' A Framework for Multi- Protocol Label Switching (MPLS) Operations and Management (OAM)'', RFC 4378, February 2006. [Y.1710] ITU-T Recommendation Y.1710, "Requirements for OAM Functionality for MPLS Networks". November, 2002. [Y.1731] ITU-T Y.1731 OAM functions and mechanisms for Ethernet based networks. May, 2006. [Y.1373/G.8114] ITU-T Recommendation Y.1373/G.8114, ''Operation & maintenance mechanism for T-MPLS layer networks'', [Y.1541] Network Performance Objectives for IP-Based Services. [Y.Sup4] ITU-T Supplement Y.Sup4 (2008), Transport Requirements for T-MPLS OAM and considerations for the application of IETF MPLS Technology. 10.2. Informative References [BFD] Katz, D., et al., " Bidirectional Forwarding Detection ", draft-ietf-bfd-base-08.txt, {work in progress}. [BFD-VCCV] Nadeau, T., Pignataro, C., et al., " Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) ", draft-ietf- pwe3-vccv-bfd-02, {work in progress}. Guo, Chen, and Chan. Expires September 10, 2009 [Page 20] Internet-Draft BFD extensions for PM March 2009 [MPLS-TP-OAM-REQ] Vigoureux, M., Wardet, D., Betts, M., " Requirements for OAM in MPLS Transport Networks ", draft- vigoureux-mpls-tp-oam-requirements-00.txt, {work in progress} [BFD-1HOP] Katz, D., Ward, D.,'' BFD for IPv4 and IPv6 (Single Hop)'', draft-ietf-bfd-v4v6-1hop-08.txt, {work in progress}. [BFD-MULTI] Katz, D., Ward, D.,'' BFD for Multihop Paths'', draft- ietf-bfd-multihop-06.txt, {work in progress}. [BFD-MPLS] Aggarwal, R., et al., ''BFD For MPLS LSPs '', draft-ietf- bfd-mpls-07.txt, {work in progress} Authors' Addresses Xinchun Guo Huawei Technologies Co.,Ltd KuiKe Building, No.9 Xinxi Rd., Hai-Dian District Beijing, 100085 P.R. China Email: guoxinchun@huawei.com Mach(Guoyi) Chen Huawei Technologies Co.,Ltd KuiKe Building, No.9 Xinxi Rd., Hai-Dian District Beijing, 100085 P.R. China Email: mach@huawei.com Kwok Ho Chan Huawei Technologies 125 Nagog Park Acton, MA 01720 USA Email: khchan@huawei.com Guo, Chen, and Chan. Expires September 10, 2009 [Page 21]