Bidirectional Forwarding Detection Xinchun.Guo Internet Draft Mach. Chen Category: Standards Track Huawei Technologies Co.,Ltd Expires: April 2009 October 27, 2008 BFD Extensions in Support of Performance Measurement draft-guo-bfd-pm-extension-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 April 27, 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. Guo, et al. Expires April 27, 2009 [Page 1] Internet-Draft BFD extensions for PM October 2008 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. Motivations.................................................3 3. Extensions to BFD...........................................4 3.1. Packet Loss TLV.........................................5 3.2. Packet Delay TLV........................................7 4. Theory of Operation.........................................8 4.1. Packet Loss Measurement.................................8 4.2. Packet Delay Measurement...............................13 4.3. Packet Delay variation Measurement.....................16 5. Security Considerations.....................................16 6. IANA Considerations........................................16 7. Acknowledgments............................................17 8. References.................................................17 8.1. Normative References...................................17 8.2. Informative References.................................17 Authors' Addresses............................................18 Intellectual Property Statement................................18 Disclaimer of Validity........................................19 Copyright Statement...........................................19 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. 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. Guo, et al. Expires April 27, 2009 [Page 2] Internet-Draft BFD extensions for PM October 2008 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 using in Performance Measurement. 2. Motivations Currently, more and more new real-time services (e.g. Voice, Video, Multimedia etc.) are provided based on IP/MPLS network, 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 for users to know that they are served as Services Level Agreements (SLAs) stated on the contract. The requirements of Performance Measurement are stated in [Y.1541], [Y.1710], [RFC 4377], [MPLS-TP-OAM-REQ] and other documents. Packet loss, delay and delay variation are the most typical performance metrics. By measuring these metrics of the correlative paths in a network, service providers could detect the performance degradation as soon as possible and take actions pre-actively. A feasible OAM tool with Performance Measurement could also be used for assisting in failure location when a failure occurs in a large and complex network. The requirements of Performance Measurement could be 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 dual-ended and single-ended mode, and - for dual-ended, it SHOULD support pro-active measurement that refers to the measuring actions which are carried out continuously to permit proactive reporting of performance results, and support Near-End and Far-End as well; Guo, et al. Expires April 27, 2009 [Page 3] Internet-Draft BFD extensions for PM October 2008 - for single-ended, it SHOULD support on-demand measurement that refers to the measuring actions which are initiated via manual intervention for a limited time to carry out diagnostics, as well as Near-End and Far- End mode; oFor packet delay and delay variation, - it SHOULD support on-demand mode, and - it SHOULD support one-way and two-way mode, Currently, there are some private implements and they are almost impossible to inter-operate each other, so a universal and standard mechanism is desired. In this document, BFD is proposed for Performance Measurement, that because BFD has the following characteristics which could satisfy the requirements of Performance Measurement as above: BFD is a simple ''hello'' like protocol, for its lower-overhead and efficient in failure detection, it is widely deployed. BFD could detect failures in 10s milliseconds. If BFD is used for Performance Measurement, it could improve the efficient and accuracy of Performance Measurement. 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. So, BFD is applicable to be used for Performance Measurement. The detailed definitions and procedures are discussed in the following sections. 3. 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 Guo, et al. Expires April 27, 2009 [Page 4] Internet-Draft BFD extensions for PM October 2008 control packet for packet loss, delay and delay variation measurement. Currently, the Optional Section is defined only for Authentication function. In case of Performance Measurement TLVs defined in this document could be carried in the Optional Section, this document proposes to change the special A bit to a common O (Optional Section present) bit. Then, if the Optional Section needs to be included in the BFD control packet, the O bit SHOULD be set and indicate that there are some optional data SHOULD be processed. Such changes will not bring essential impact to the processing of the existing Authentication function, because the process of Authentication TLVs is the same as the [BFD] defined other than the semantic of the ''old'' A bit. 3.1. Packet Loss TLV To perform packet loss measurement of a specific path, whatever each of the two ends calculates the ratio of packet loss, it gets to know the number of not only sent packet at the sender, but received packet at the receiver in a certain measure period. And there is another big issue that the receiver has to be aware of the right time when to start and stop counting for a specific measurement. In this document, the Packet Loss TLV is defined for a sender to notify the receiver when to start and stop counting, with such mechanism, time synchronization is not necessary. And some essential statistic information (e.g. the number of transmitted, the number of received) for ratio calculation of packet loss are carried in the Packet Loss TLV, which could be used by each of the two ends of a specific path to calculates the loss ratio. The format of the Packet Loss TLV is as follows: Guo, et al. Expires April 27, 2009 [Page 5] Bidirectional Forwarding Detection Xinchun.Guo Internet Draft Mach. Chen Category: Standards Track Huawei Technologies Co.,Ltd Expires: April 2009 October 27, 2008 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TxPacCount_l | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RxPacCount_l | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TxPacCount_f | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Packet Lost TLV The Packet Loss TLV is TLV type 6 (which needs to be confirmed by IANA see Section 6), 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. Guo, et al. Expires April 27, 2009 [Page 6] Internet-Draft BFD extensions for PM October 2008 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. 3.2. Packet Delay TLV The Packet Delay TLV is defined for packet delay and delay variation measurement. The Packet Delay TLV is TLV type 7 (which needs to be confirmed by IANA see Section 6), and is 12 bytes 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. Guo, et al. Expires April 27, 2009 [Page 7] Internet-Draft BFD extensions for PM October 2008 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. 4. 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. 4.1. Packet Loss Measurement In this document, BFD control packets are used to carry the counter values that are the numbers of packets transmitted and received for a specific measurement between the two systems for packet loss measurement. Packet loss measurement is independent on clock/time synchronization of the two systems. It is by sending BFD control packets with PLM TLV carrying statistics of the transmitted and/or received packets to each other, depends on the real situation, 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. 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. Guo, et al. Expires April 27, 2009 [Page 8] Internet-Draft BFD extensions for PM October 2008 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 sending from the other ends, and on the contrary, Far-end PLM means that the node performs packet loss calculation for the packets sending 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. 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 sending 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 Guo, et al. Expires April 27, 2009 [Page 9] Internet-Draft BFD extensions for PM October 2008 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 mantains the numbers of the received packets, as well the parameter TxPacCount_l from the received PLM packet. Using the parameters this time and the previous, B node can perform near-end packet loss measurement. Presuming that Tn1 and Tn2 are the time of A node sending two different PLM packets, and TTn1 and TTn2 are correspondingly the time of the two PLM packets received by the B node. The formula is as follow. The calculation interval is based on the sending interval of PLM packets, it can be set 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 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 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, A will send periodic BFD PLM packet with the TxPacCount_l and sequence parameters set to node B. The difference is that, the B node SHOULD also send periodic BFD PLM packets to A, with parameters RxPacCount_l and TxPacCount_f that specify the value of local Guo, et al. Expires April 27, 2009 [Page 10] Internet-Draft BFD extensions for PM October 2008 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 form B node, 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 will perform far-end packet loss calculation. Tn1 and Tn2 specify the time of two difference PLM packets sending form A, and TTn1 and TTn2 are the corresponding time of 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 +-+-+ +-+-+ | 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 Guo, et al. Expires April 27, 2009 [Page 11] Internet-Draft BFD extensions for PM October 2008 with the PLM TLV to its peer, 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 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]| Guo, et al. Expires April 27, 2009 [Page 12] Internet-Draft BFD extensions for PM October 2008 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% 4.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 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. Guo, et al. Expires April 27, 2009 [Page 13] Internet-Draft BFD extensions for PM October 2008 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 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 Guo, et al. Expires April 27, 2009 [Page 14] Internet-Draft BFD extensions for PM October 2008 +-+-+ +-+-+ | 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 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 Guo, et al. Expires April 27, 2009 [Page 15] Internet-Draft BFD extensions for PM October 2008 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. 4.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] 5. Security Considerations Security considerations discussed in [BFD], [BFD-MHOP] and [RFC4379] apply to this document. 6. IANA Considerations IANA is requested to assign two new TLVs for Performance Measurement. The following numbers are suggested. Value Meaning 6 Packet loss TLV 7 Packet delay TLV Guo, et al. Expires April 27, 2009 [Page 16] Internet-Draft BFD extensions for PM October 2008 7. Acknowledgments The authors would like to thank Jian Li and Wei Cao for their comments and help for preparing this document. 8. References 8.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. 8.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}. [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} Guo, et al. Expires April 27, 2009 [Page 17] Internet-Draft BFD extensions for PM October 2008 [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 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this Guo, et al. Expires April 27, 2009 [Page 18] Internet-Draft BFD extensions for PM October 2008 specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Guo, et al. Expires April 27, 2009 [Page 19]