MPLS Working Group M. Xiao, Ed. Internet-Draft ZTE Intended status: Standards Track F. Huang, Ed. Expires: September 15, 2011 Alcatel-Lucent S. Kini, Ed. Ericsson H. Li China Mobile R. Jing China Telecom March 14, 2011 Throughput Measurement for MPLS-based Transport Networks draft-xhk-mpls-tp-throughput-01 Abstract An important Operation, Administration and Maintenance requirement of the MPLS Transport Profile (MPLS-TP) is the ability to estimate/ measure the throughput (i.e. bandwidth) of an MPLS-TP connection which could be an MPLS-TP LSP, PW or Section. This document specifies the OAM packets and procedures for both one-way and two-way throughput estimation/measurement in MPLS-TP. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 15, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Xiao, et al. Expires September 15, 2011 [Page 1] Internet-Draft Thput Measurement for MPLS-TP March 2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Throughput Measurement Modes . . . . . . . . . . . . . . . 4 2.2. One-way Throughput Measurement . . . . . . . . . . . . . . 4 2.3. Two-way Throughput Measurement . . . . . . . . . . . . . . 5 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Throughput Measurement Control Packet Format . . . . . . . 5 3.2. Throughput Measurement Test Data Packet Format . . . . . . 10 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Throughput Measurement Procedures in Estimated Mode . . . 10 4.2. Throughput Measurement Procedures in Measured Mode . . . . 11 4.2.1. Transmitting a Throughput Measurement Start Request . 11 4.2.2. Receiving a Throughput Measurement Start Request . . . 12 4.2.3. Transmitting a Throughput Measurement Start Reply . . 12 4.2.4. Receiving a Throughput Measurement Start Reply . . . . 12 4.2.5. Sending and Receiving Test Traffic . . . . . . . . . . 12 4.2.6. Transmitting a Throughput Measurement Stop Request . . 13 4.2.7. Receiving a Throughput Measurement Stop Request . . . 13 4.2.8. Transmitting a Throughput Measurement Stop Reply . . . 13 4.2.9. Receiving a Throughput Measurement Stop Reply . . . . 13 4.2.10. Consequent Actions and Searching Algorithm . . . . . . 14 5. Throughput Measurement Time . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Xiao, et al. Expires September 15, 2011 [Page 2] Internet-Draft Thput Measurement for MPLS-TP March 2011 1. Introduction As required in section 2.2.5 of [RFC5860], the MPLS-TP OAM toolset MUST provide a function to enable conducting diagnostic tests on a PW, LSP or Section, this function SHOULD be performed on-demand and one example of such diagnostic test consists in estimating the available bandwidth of e.g., an LSP. To make this requirement clearer and provide more details, this sub- function of diagnostic tests is specified as "throughput estimation" in section 6.3.1 of [I-D.ietf-mpls-tp-oam-framework], throughput estimation is an on-demand out-of-service function, that allows verifying the bandwidth/throughput of an MPLS-TP transport path (LSP or PW) before it is put in-service. Throughput estimation is performed between MEPs and can be performed in one-way or two-way mode. This document specifies the OAM packets and procedures for both one- way and two-way throughput estimation/measurement in MPLS-TP. 1.1. Conventions 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]. 1.2. Abbreviations CRC: Cyclic Redundancy Check G-ACh: Generic Associated Channel DUT: Device Under Test LSP: Label Switched Path MEG: Maintenance Entity Group MEP: Maintenance Entity Group End Point MPLS-TP: MPLS Transport Profile NMS: Network Management System OAM: Operations, Administration and Maintenance PHB: Per-hop Behavior Xiao, et al. Expires September 15, 2011 [Page 3] Internet-Draft Thput Measurement for MPLS-TP March 2011 PRBS: Pseudo-Random Bit Sequence PW: PseudoWire TLV: Type Length Value 2. Overview In [RFC1242], the throughput is defined as a performance metric for network interconnection device, and it's defined by "the maximum rate at which none of the offered frames are dropped by the device". In MPLS-TP context, the definition of throughput is applied to an MPLS-TP connection which could be an MPLS-TP LSP, PW or Section. 2.1. Throughput Measurement Modes In [RFC2544], the throughput measurement procedures are specified as "send a specific number of frames at a specific rate through the DUT and then count the frames that are transmitted by the DUT. If the count of offered frames is equal to the count of received frames, the fewer frames are received than were transmitted, the rate of the offered stream is reduced and the test is rerun. The throughput is the fastest rate at which the count of test frames transmitted by the DUT is equal to the number of test frames sent to it by the test equipment". But in current practical throughput measurement scenario, usually the throughput is measured by test equipment using the binary search algorithm, in this case also more than one run of test traffic sending may be needed and the run count can be used to indicate the times of test traffic sending. If the precision of throughput measurement is not cared much, in order to take advantage of the implementary simplicity, the measurement method similar to that indicated in [RFC2544] would be used and the throughput measurement is said to operate in "estimated mode". On the other hand, if the precision of throughput measurement is cared much, in order to achieve more precision and efficiency, the measurement method newly introduced by this document would be used and the throughput measurement is said to operate in "measured mode". These methods are described in more detail in section 4. 2.2. One-way Throughput Measurement One-way throughput measurement needs to be supported for both unidirectional and bidirectional MPLS-TP connection. One-way throughput indicates the throughput for the forward direction of the connection from the initiator MEP, which initiates the process of throughput measurement and keep active in the whole process. Xiao, et al. Expires September 15, 2011 [Page 4] Internet-Draft Thput Measurement for MPLS-TP March 2011 For one-way throughput measurement in estimated mode, the initiator MEP sends test traffic and the peer MEP calculates the test data packet loss, otherwise in measured mode, the initiator MEP controls the whole process of measurement and the peer MEP acts just as a responder. Also note that for a unidirectional MPLS-TP connection (such as a unidirectional LSP) without return path, only the estimated mode should be used. 2.3. Two-way Throughput Measurement Two-way throughput measurement needs to be supported for only bidirectional MPLS-TP connection. Two-way throughput indicates both the throughput for the forward direction of the connection and the throughput for the reverse direction of the connection from the initiator MEP. For two-way throughput measurement in estimated mode, only the initiator MEP sends test traffic and the peer MEP loopbacks all received test data packets, otherwise in measured mode, both the initiator MEP and the peer MEP send test traffic, and the initiator MEP controls the whole process of measurement, just like one-way throughput measurement. Also note that in estimated mode only the minimum of available throughput of the two directions would return, otherwise in measured mode, two individual available throughputs of the two directions can be achieved. 3. Packet Format For throughput measurement in estimated mode, only the test data packets would be sent by the MEP, otherwise in measured mode, the specific packets sent by the MEP can be divided into control packets and test data packets. The throughput measurement control packets flow over the Generic Associated Channel (G-ACh) [RFC5586] of an MPLS-TP connection and perform signaling between the initiator MEP and the peer MEP, while the throughput measurement test data packets compose the test traffic which intends to emulate the real user traffic. 3.1. Throughput Measurement Control Packet Format The format of a throughput measurement control packet is shown below. Xiao, et al. Expires September 15, 2011 [Page 5] Internet-Draft Thput Measurement for MPLS-TP March 2011 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | 0xHH (Throughput Meas Control)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ Throughput Measurement Control Message ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Throughput Measurement Control Packet The Version and Reserved field are always set to 0. The Throughput Meas Control Channel Type is 0xHH (to be assigned by IANA). The format of a throughput measurement control message is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flags | Run Count | Control Code | Total TLV Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Throughput Measurement Control Message Version The Version Number is currently set to 0. Flags Each bit indicates a message control flag. Three flags are defined and listed from left to right as follow: +-+-+-+-+ |W|S|R|E| +-+-+-+-+ Xiao, et al. Expires September 15, 2011 [Page 6] Internet-Draft Thput Measurement for MPLS-TP March 2011 W-flag: This Flag represents the operational mode which could be One-way mode or Two-way mode. Set to 0 for a One-way throughput measurement; Set to 1 for a Two-way throughput measurement. S-flag: This Flag represents the message type which could be Start type or Stop type. Set to 0 for a Start message; Set to 1 for a Stop message. R-flag: This Flag represents the message direction which could be Forward direction (i.e. Request) or Reverse direction (i.e. Reply). Set to 0 for a Request message; Set to 1 for a Reply message. E bit (the fourth bit): Reserved for future use and set to 0. Run Count The Run Count is set to the number of all run times till now in one throughput measurement process. It starts from 1 and increase one after every run. Control Code According to the value of R-flag, the Control Code is set as follow. For a Request: 0x0: Request (in-band reply requested). Indicates that this request has been sent over a bidirectional connection and the reply is expected over the same connection. 0x1: Request (out-of-band reply requested). Indicates that this request has been sent over a unidirectional connection and the reply is expected over an out-of-band path. For a Reply: 0x0: Success. Indicates that the operation succeeded. 0x1: Error. Indicates that the operation failed. Total TLV Length The total TLV length is the total of all included TLVs. TLVs Xiao, et al. Expires September 15, 2011 [Page 7] Internet-Draft Thput Measurement for MPLS-TP March 2011 According to the values of W-flag, S-flag and R-flag, the TLVs are defined as follow. For Start Request/Reply message in One-way throughput measurement: No TLVs are defined. For Start Request/Reply message in Two-way throughput measurement: One TLV is defined as follow. 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 = 0 | Length = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sending Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sending Duration | Packet Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Pattern| PHB | Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All the values in this TLV are test parameters for the peer MEP to send test traffic. Sending Rate The Sending Rate in Mbps is set to the provisioned initial sending rate of test traffic for the first run, and set to the calculated sending rate of test traffic for the rerun. Sending Duration The Sending Duration in seconds is set to the provisioned sending interval of test traffic for every run. Packet Size The Packet Size in octets is set to the provisioned throughput measurement test data packet size. Packet Pattern Xiao, et al. Expires September 15, 2011 [Page 8] Internet-Draft Thput Measurement for MPLS-TP March 2011 The Packet Pattern is set to the provisioned throughput measurement test data packet pattern. According to [Y.1731], four pattern types of throughput measurement test data packets pattern types are defined as below: 0x00: Null (all-zeros) signal without CRC-32 0x01: Null (all-zeros) signal with CRC-32 0x02: PRBS (2^31-1) without CRC-32 0x03: PRBS (2^31-1) with CRC-32 0x04~0xFF: Reserved for future standardization PHB The PHB is set to the provisioned throughput measurement test data packet PHB. Reserved Reserved bits for future use and always set to 0. For Stop Request/Reply message in One-way/Two-way throughput measurement: One TLV is defined as follow. 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 = 1 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Counter | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rx Counter | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tx Counter Tx Counter is set to the number of throughput measurement test data packets sent by the local MEP (i.e. the MEP Xiao, et al. Expires September 15, 2011 [Page 9] Internet-Draft Thput Measurement for MPLS-TP March 2011 sending this control message) in this run. Rx Counter Rx Counter is set to the number of throughput measurement test data packets received by the local MEP (i.e. the MEP sending this control message) in this run. 3.2. Throughput Measurement Test Data Packet Format Whether the throughput measurement is performed in estimated mode or measured mode, the format of a throughput measurement test data packet would be just the same. In order to simplify the implementation of MPLS-TP OAM functions, the format of a throughput measurement test data packet should be aligned with the format of a data plane loopback test data packet. As indicated in section 3.1, four pattern types of throughput measurement test data packets can be constructed based on Padding field and optional CRC-32 field. 4. Operation As specified in section 6.3.1.1 of [I-D.ietf-mpls-tp-oam-framework], before throughput measurement is initiated, the diagnosed MEG should be put into a Lock status, and an MEG can be put into a Lock status either via NMS action or using the Lock Instruct OAM tool which is required by [RFC5860]. It should be noted that in estimated mode, for different test data packet size, or test data packet pattern, or test data packet PHB, or step length of sending rate, or even sending duration of test traffic, different result of throughput measurement may be obtained, so all these parameters need to be configurable for throughput measurement in estimated mode. Also note that in measured mode, for different test data packet size, or test data packet pattern, or test data packet PHB, or expected measurement resolution, or even sending duration of test traffic, different result of throughput measurement may be obtained, so all these parameters need to be configurable for throughput measurement in measured mode. Besides, optional acceptable frame loss rate would be provisioned in measured mode if needed. Also note that the set of PHB value of control packets would follow the provisioned test data packet PHB. 4.1. Throughput Measurement Procedures in Estimated Mode For one-way throughput measurement, the initiator MEP sends test traffic with the provisioned initial sending rate for the first run, and then the peer MEP will calculate test data packet loss according Xiao, et al. Expires September 15, 2011 [Page 10] Internet-Draft Thput Measurement for MPLS-TP March 2011 to Sequence-Number field of test data packet. If calculated Packet Loss (one-way) is equal to zero, then the operator will increase the sending rate with a fixed step length (e.g. 100 kb/s) manually and command the initiator MEP to send test traffic with the increased sending rate for rerun. On the analogy of this, the initiator MEP will gradually increase its sending rate until the calculated Packet Loss (one-way) is not equal to zero for a certain run, and the sending rate for the last run is the measured one-way throughput. For two-way throughput measurement, the peer MEP should be put into a Loopback status, and this can be achieved either via NMS action or using the Data Plane Loopback OAM tool which is required by [RFC5860]. The initiator MEP sends test traffic with the provisioned initial sending rate for the first run, and the peer MEP loops all received test data packets back, and then the initiator MEP itself will calculate test data packet loss by comparing the sent and received test data packets. If calculated Packet Loss (two-way) is equal to zero, then the sending rate will be increased with a fixed step length (e.g. 100kb/s) automatically and the initiator MEP will send test traffic with the increased sending rate for rerun. On the analogy of this, the initiator MEP will gradually increase its sending rate until the calculated Packet Loss (two-way) is not equal to zero for a certain run, and the sending rate for the last run is the measured two-way throughput. 4.2. Throughput Measurement Procedures in Measured Mode 4.2.1. Transmitting a Throughput Measurement Start Request After initiating a throughput measurement operation, the initiator MEP will at first transmit a throughput measurement Start Request to the peer MEP. Also note that for every rerun of sending test traffic, the initiator MEP would also transmit this message as beginning. For one-way throughput measurement, this message is intended to inform the peer MEP about the start of test traffic sending and trigger the peer MEP to start counting test data packets. For two- way throughput measurement, except for the same intention as one-way throughput measurement, this message is further intended to convey necessary test parameters to the peer MEP and trigger the peer MEP to send test traffic too, and note that for rerun only Run Count and Sending Rate in this message would be changed while other parameters retain initial values. Also note that for both one-way and two-way measurement, the initiator MEP would start counting test data packets as soon as it transmits this message. Xiao, et al. Expires September 15, 2011 [Page 11] Internet-Draft Thput Measurement for MPLS-TP March 2011 4.2.2. Receiving a Throughput Measurement Start Request Upon the reception of a throughput measurement Start Request, the peer MEP must inspect this message at first, if no unexpected field or value is found then the peer MEP should start counting test data packets. In addition, if the received W-flag indicates that this is a two-way throughput measurement, then the peer MEP should also start sending test traffic after it starts counting test data packets. 4.2.3. Transmitting a Throughput Measurement Start Reply After receiving a throughput measurement Start Request, the peer MEP must transmit a throughput measurement Start Reply to the initiator MEP. The Control Code in Start Reply Message should be set to 0x0 to reflect the successful operation at the peer MEP, or on the contrary set to 0x1 to reflect the failed operation at the peer MEP. Except the R-flag and Control Code field, other fields of Start Reply Message will be copied from the received Start Request Message. 4.2.4. Receiving a Throughput Measurement Start Reply Upon the reception of a throughput measurement Start Reply, the initiator MEP must inspect this message at first, if no unexpected field or value is found, and the received Control Code indicates successful operation at the peer MEP, then the initiator MEP should start sending test traffic. If unexpected field or value is found while inspecting this message, or the received Control Code indicates failed operation at the peer MEP, or there is no any throughput measurement Start Reply received after a while (such as 1 second), then specific error should be returned at the initiator MEP and no test traffic will be sent from the initiator MEP. 4.2.5. Sending and Receiving Test Traffic From above procedures it can be seen that for two-way throughput measurement the pair of MEPs will send test traffic asynchronously, and the peer MEP will start/stop sending test traffic some earlier than the initiator MEP, but the asynchronism has no side-effect on the measurement result because both MEPs shall start counting test data packets before they send/receive any test traffic. Also note that when the initiator MEP sends test traffic, for the first run the test parameters are all derived from the provisions, and for the rerun only the sending rate is changed and derived from the local calculation. When the peer MEP sends test traffic, for every run the test parameters are all derived from the received Start Request Message. Xiao, et al. Expires September 15, 2011 [Page 12] Internet-Draft Thput Measurement for MPLS-TP March 2011 4.2.6. Transmitting a Throughput Measurement Stop Request For every run, after the initiator MEP finish sending test traffic, it will transmit a throughput measurement Stop Request to the peer MEP. This message is intended to inform the peer MEP about the stop of test traffic sending at the initiator MEP, which trigger the peer MEP to stop counting test data packets and feed back the counters. 4.2.7. Receiving a Throughput Measurement Stop Request Upon the reception of a throughput measurement Stop Request, the peer MEP must inspect this message at first, if no unexpected field or value is found then the peer MEP should stop counting test data packets. Also note that for two-way throughput measurement, as indicated in section 4.2.5, the peer MEP has stopped sending test traffic before it receives a throughput measurement Stop Request. 4.2.8. Transmitting a Throughput Measurement Stop Reply After receiving a throughput measurement Stop Request, the peer MEP must transmit a throughput measurement Stop Reply to the initiator MEP. The Control Code in Stop Reply Message should be set to 0x0 to reflect the successful operation at the peer MEP, or on the contrary set to 0x1 to reflect the failed operation at the peer MEP. The Tx Counter and Rx Counter in Stop Reply Message are set to the test data packet counting values at the peer MEP. 4.2.9. Receiving a Throughput Measurement Stop Reply Upon the reception of a throughput measurement Stop Reply, the initiator MEP must inspect this message at first, if no unexpected field or value is found, and the received Control Code indicates successful operation at the peer MEP, then the initiator MEP should stop counting test data packets and start calculating the test data packet loss. Suppose the Tx Counter and Rx Counter locally are TxP1 and RxP1 for the initiator MEP, and in Stop Reply Message are TxP2 and RxP2 for the peer MEP. For one-way throughput measurement, the calculation formula is as follow: Packet Loss (one-way) = TxP1 - RxP2 For two-way throughput measurement, the calculation formulas are as follow: Packet Loss (forward) = TxP1 - RxP2 Xiao, et al. Expires September 15, 2011 [Page 13] Internet-Draft Thput Measurement for MPLS-TP March 2011 Packet Loss (reverse) = TxP2 - RxP1 If unexpected field or value is found while inspecting this message, or the received Control Code indicates failed operation at the peer MEP, or there is no any throughput measurement Stop Reply received after a while (such as 1 second), then specific error should be returned at the initiator MEP and no calculation for test data packet loss will be executed. 4.2.10. Consequent Actions and Searching Algorithm Procedures for one run of test traffic sending and test data packet loss calculation have been described above in details, but usually iterative reruns of the procedures are needed for a throughput measurement. Whether the rerun is needed or not is based on both the calculated test data packet loss and whether the expected measurement resolution is met. For one-way throughput measurement, if calculated Packet Loss (one-way) is equal to zero and the expected measurement resolution is met, then rerun is not needed (i.e. the one-way throughput measurement finished) and the current sending rate is the measured one-way throughput, otherwise the one-way throughput measurement proceeds. For two-way throughput measurement, if calculated Packet Loss (forward) and Packet Loss (reverse) are both equal to zero, and the expected measurement resolution for both forward and reverse directions is met, then rerun is not needed (i.e. the two-way throughput measurement finished) and the current sending rate for forward/reverse direction is the measured forward/reverse throughput, otherwise the two-way throughput measurement proceeds, and in this case the sending rates for rerun should be calculated for forward direction and reverse direction respectively. The simple and efficient binary search algorithm is applied to calculate the sending rate for the next run, which is the only changed test parameter compared with this run. How the binary search works, if packet loss is found for this run, it searches downwards for a lower rate which is halfway rate between the rate of this run and the known highest rate at which no packet loss is found; if no packet loss is found but the expected measurement resolution is not met for this run, it searches upwards for a higher rate which is halfway rate between the rate of this run and the known lowest rate at which packet loss is found; the measurement searches among higher and lower rates on the analogy of this, until it finds the rate at which no test data packet is lost and expected measurement resolution is met, and this rate is the measured throughput. How to judge whether the expected measurement resolution is met or not, if the rate difference between the two consecutive runs (i.e. this run and the previous run), expressed as a percentage, is smaller than or equal to the specified measurement resolution, it's known as that the Xiao, et al. Expires September 15, 2011 [Page 14] Internet-Draft Thput Measurement for MPLS-TP March 2011 expected measurement resolution is met, otherwise it's not met. For example, suppose to measure the throughput of a connection whose actual throughput is 70Mbps, the provisioned initial sending rate is 100Mbps and the specified measurement resolution is 0.1. Note that the initial sending rate should be higher than the actual throughput, otherwise the binary search is not applicable, and so it's often set to the maximum theoretical throughput of the measured connection. For the first run, packet loss is found, so for the second run, the sending rate will be calculated as (100+0)/2 = 50Mbps, no packet loss is found, then the resolution will be calculated as (100-50)/50 = 1, which is bigger than 0.1, the expected measurement resolution is not met, so for the third run, the sending rate will be calculated as (100+50)/2 = 75Mbps, packet loss is found, so for the fourth run, the sending rate will be calculated as (50+75)/2 = 62.5Mbps, no packet loss is found, then the resolution will be calculated as (75-62.5)/ 62.5 = 0.2, which is bigger than 0.1, the expected measurement resolution is not met, so for the fifth run, the sending rate will be calculated as (75+62.5)/2 = 68.75Mbps, no packet loss is found, then the resolution will be calculated as (68.75-62.5)/68.75 = 0.09, which is smaller than 0.1, the expected measurement resolution is met, so the measurement finished and the rate 68.75Mbps is the measured throughput. As indicated in front of this section, a threshold on the acceptable frame loss rate MAY be set before throughput measurement, in this case it's not required that absolutely no packet loss exists, and the pre-provisioned acceptable frame loss rate needs to be taken into account when judging whether the throughput is got after every run. 5. Throughput Measurement Time The throughput measurement time is about the product of sending duration for one run and number of all run times. The sending duration for one run is provisioned before the throughput measurement starts, and the number of all run times is related to several factors which include the provisioned initial sending rate, the applied searching algorithm and the specified expected measurement resolution. Obviously longer sending duration would result in more precise measured result, but then longer throughput measurement time is needed, so there should be a balance between them. On the other hand, for throughput measurement in estimated mode, the shorter step length and the shorter measurement time are mutually exclusive, similarly in measured mode, the higher measurement resolution and the shorter measurement time are mutually exclusive, and so the balance between them is also needed. Xiao, et al. Expires September 15, 2011 [Page 15] Internet-Draft Thput Measurement for MPLS-TP March 2011 6. Security Considerations To be added in a later version of this document. 7. IANA Considerations To be added in a later version of this document. 8. Acknowledgements The authors would like to thank Dave Allan, Huub van Helvoort, Curtis Villamizar and Ayal Lior for their valuable comments. The authors would also like to acknowledge the helpful inputs from Xiaobo Yi, Italo Busi and William Zhang, and discussion with Xiaohua Ma and Stephan Roullot. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic Associated Channel", RFC 5586, June 2009. [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010. 9.2. Informative References [I-D.ietf-mpls-tp-oam-framework] Allan, D., Busi, I., Niven-Jenkins, B., Fulignoli, A., Hernandez-Valencia, E., Levrau, L., Sestito, V., Sprecher, N., Helvoort, H., Vigoureux, M., Weingarten, Y., and R. Winter, "Operations, Administration and Maintenance Framework for MPLS-based Transport Networks", draft-ietf-mpls-tp-oam-framework-11 (work in progress), February 2011. [RFC1242] Bradner, S., "Benchmarking terminology for network interconnection devices", RFC 1242, July 1991. Xiao, et al. Expires September 15, 2011 [Page 16] Internet-Draft Thput Measurement for MPLS-TP March 2011 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999. [Y.1731] International Telecommunications Union - Telecommunication Standardization, "OAM functions and mechanisms for Ethernet based networks", ITU-T Recommendation Y.1731, February 2008. Authors' Addresses Min Xiao (editor) ZTE Corporation Email: xiao.min2@zte.com.cn Feng Huang (editor) Alcatel-Lucent Email: feng.f.huang@alcatel-sbell.com.cn Sriganesh Kini (editor) Ericsson Email: sriganesh.kini@ericsson.com Han Li China Mobile Email: lihan@chinamobile.com Ruiquan Jing China Telecom Email: jingrq@ctbri.com.cn Lieven Levrau Alcatel-Lucent Email: Lieven.Levrau@alcatel-lucent.com Xiao, et al. Expires September 15, 2011 [Page 17] Internet-Draft Thput Measurement for MPLS-TP March 2011 Lizhong Jin ZTE Corporation Email: lizhong.jin@zte.com.cn Bo Wu ZTE Corporation Email: wu.bo@zte.com.cn Jian Yang ZTE Corporation Email: yang_jian@zte.com.cn Xiao, et al. Expires September 15, 2011 [Page 18]