MPLS Working Group M. Xiao Internet-Draft L. Jin Intended status: Standards Track B. Wu Expires: October 14, 2010 J. Yang ZTE Corporation April 12, 2010 Throughput Estimation for MPLS Transport Profile draft-xiao-mpls-tp-throughput-estimation-00 Abstract An important Operation, Administration and Maintenance requirement of the MPLS Transport Profile (MPLS-TP) is the ability to estimate the throughput (i.e. bandwidth) for an MPLS-TP connection which could be an MPLS-TP PW, LSP or Section. This document specifies OAM packets (include test packets) and protocol mechanisms to facilitate the efficient and precise measurement of throughput. 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 October 14, 2010. Copyright Notice Copyright (c) 2010 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. Code Components extracted from this document must Xiao, et al. Expires October 14, 2010 [Page 1] Internet-Draft Thput Estimation for MPLS-TP April 2010 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. Two-way Throughput Measurement . . . . . . . . . . . . . . 4 2.2. One-way Throughput Measurement . . . . . . . . . . . . . . 5 2.3. Unidirectional Connections . . . . . . . . . . . . . . . . 5 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Throughput Measurement Indication Packet Format . . . . . 5 3.2. Throughput Measurement Test Packet Format . . . . . . . . 10 4. Throughput Measurement Procedures . . . . . . . . . . . . . . 11 4.1. Transmitting a Throughput Measurement Start Request . . . 11 4.2. Receiving a Throughput Measurement Start Request . . . . . 11 4.3. Transmitting a Throughput Measurement Start Reply . . . . 12 4.4. Receiving a Throughput Measurement Start Reply . . . . . . 12 4.5. Sending and Receiving Test Traffic . . . . . . . . . . . . 12 4.6. Transmitting a Throughput Measurement Stop Request . . . . 13 4.7. Receiving a Throughput Measurement Stop Request . . . . . 13 4.8. Transmitting a Throughput Measurement Stop Reply . . . . . 13 4.9. Receiving a Throughput Measurement Stop Reply . . . . . . 13 4.10. Consequent Actions and Searching Algorithm . . . . . . . . 14 5. Throughput Measurement Time . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Security 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 October 14, 2010 [Page 2] Internet-Draft Thput Estimation for MPLS-TP April 2010 1. Introduction As defined in [I-D.ietf-mpls-tp-oam-requirements], 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 bandwidth of e.g., an LSP. To make this requirement more clear and provide more details, this sub-function of diagnostic tests is specified as "throughput estimation" in [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 packet format (include test packet format) and the procedures for both one-way and two-way throughput estimation/measurement. 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 ACH: Associated Channel Header CRC: Cyclic Redundancy Check G-ACh: Generic Associated Channel DUT: Device Under Test ICC: ITU Carrier Code LSP: Label Switched Path MEG: Maintenance Entity Group MEP: Maintenance Entity Group End Point MPLS-TP: MPLS Transport Profile NMS: Network Management System Xiao, et al. Expires October 14, 2010 [Page 3] Internet-Draft Thput Estimation for MPLS-TP April 2010 OAM: Operations, Administration and Maintenance PHB: Per-hop Behavior PRBS: Pseudo-Random Bit Sequence PW: PseudoWire TLV: Type Length Value 2. Overview In [RFC1242], the throughput is specified 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 concept of throughput is not just for a particular device, but extended to apply to an MPLS-TP connection which could be a PW, LSP or Section. In [RFC2544], corresponding to [RFC1242], 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 more efficient binary search algorithm. It should also be noted that for different test packet size, or test packet pattern, or test 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. 2.1. Two-way Throughput Measurement For a bidirectional MPLS-TP connection, two-way throughput measurement needs to be supported. Two-way throughput should include the throughput for the forward direction of the connection and the throughput for the reverse direction of the connection. In order to simplify the implementation and facilitate the results collection, all computational overhead and procedures control will be taken by the initiator MEP of throughput measurement, and the peer MEP will act just as a responder. Also note that both the initiator MEP and Xiao, et al. Expires October 14, 2010 [Page 4] Internet-Draft Thput Estimation for MPLS-TP April 2010 the peer MEP need to send test traffic for two-way throughput measurement. 2.2. One-way Throughput Measurement For a bidirectional MPLS-TP connection, one-way throughput measurement also needs to be supported. One-way throughput only indicates the throughput for the forward direction of the connection. Similar to two-way throughput measurement, the initiator MEP controls the whole process of throughput measurement and the peer MEP will act just as a responder. Also note that only the initiator MEP needs to send test traffic for one-way throughput measurement. 2.3. Unidirectional Connections For a unidirectional MPLS-TP connection without return path, such as a unidirectional LSP, only one-way throughput measurement needs to be supported. In this case, the procedures of throughput measurement are some different with that for bidirectional connection. The procedures are not as automatic as that for bidirectional connection, and manual provision of test parameters is needed for every run of sending test traffic. Also the peer MEP instead of the initiator MEP will act as calculator for packet loss after every run. 3. Packet Format For throughput measurement the OAM packets can be divided into indication packets and test packets, and both of them flow over the Generic Associated Channel (G-ACh) [RFC5586] of an MPLS-TP connection. The indication packets perform signaling between the initiator MEP and the peer MEP of throughput measurement, while the test packets compose the test traffic which is sent by the initiator MEP (for one-way measurement) or both the initiator MEP and the peer MEP (for two-way measurement). 3.1. Throughput Measurement Indication Packet Format The format of a throughput measurement indication packet is shown below. Xiao, et al. Expires October 14, 2010 [Page 5] Internet-Draft Thput Estimation for MPLS-TP April 2010 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 (Thput Meas Indication) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ACH TLV Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ Zero or more ACH TLVs ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ Throughput Measurement Indication Message ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Throughput Measurement Indication Packet The Version and Reserved field are always set to 0. The Thput Meas Indication Channel Type is 0xHH (to be assigned by IANA). The ACH TLVs may include (but are not limited to) the IF_ID, Global-ID, ICC, and Authentication TLVs. The format of a throughput measurement indication 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 Indication Message Version The Version Number is currently set to 0. Xiao, et al. Expires October 14, 2010 [Page 6] Internet-Draft Thput Estimation for MPLS-TP April 2010 Flags Each bit indicates a message control flag. Three flags are defined and listed from left to right as follow: One-way/Two-way Flag: This Flag represents the operational mode of throughput measurement. Set to 0 for a One-way throughput measurement; Set to 1 for a Two-way throughput measurement. Start/Stop Flag: This Flag represents the message type. Set to 0 for a Start message; Set to 1 for a Stop message. Request/Reply Flag: This Flag represents the message type. Set to 0 for a Request message; Set to 1 for a Reply message. 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 in one throughput measurement process. Control Code According to the value of Request/Reply 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 the reply is expected over an out-of-band path. 0x2: Request (no reply requested). Indicates that no reply is expected. For a Reply: 0x0: Success. Indicates that the operation succeeded. 0x1: Error. Indicates that the operation failed. Total TLV Length Xiao, et al. Expires October 14, 2010 [Page 7] Internet-Draft Thput Estimation for MPLS-TP April 2010 The total TLV length is the total of all included TLVs. TLVs According to the values of One-way/Two-way flag, Start/Stop flag and Request/Reply flag, the TLVs are defined as follow. For Start Request/Reply message in One-way throughput measurement: No TLVs are defined at this time. 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 for the first run, and set to the calculated sending rate for rerun. Sending Duration The Sending Duration in seconds is set to the provisioned interval of sending test traffic for every run. Xiao, et al. Expires October 14, 2010 [Page 8] Internet-Draft Thput Estimation for MPLS-TP April 2010 Packet Size The Packet Size in octets is set to the provisioned test packet size. Packet Pattern The Packet Pattern is set to the provisioned test packet pattern. As specified in [Y.1731], four test packet pattern types are defined as below: 0x0: Null (all-zeros) signal without CRC-32 0x1: Null (all-zeros) signal with CRC-32 0x2: PRBS (2^31-1) without CRC-32 0x3: PRBS (2^31-1) with CRC-32 PHB The PHB is set to the provisioned test packet PHB. Reserved Reserved bits for future use and always set to 0. For Stop message regardless of Request/Reply and One-way/Two-way flags: 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 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Xiao, et al. Expires October 14, 2010 [Page 9] Internet-Draft Thput Estimation for MPLS-TP April 2010 Tx Counter Tx Counter is set to the number of test packets sent by the local MEP (i.e. MEP sending this indication message) over the connection for this run. Rx Counter Rx Counter is set to the number of test packets received by the local MEP (i.e. MEP sending this indication message) over the connection for this run. 3.2. Throughput Measurement Test Packet Format The format of a throughput measurement test packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|Version| Reserved | 0xHH (Thput Meas Test) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ Padding ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC-32 (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Throughput Measurement Test Packet The Version and Reserved field are always set to 0. The Thput Meas Test Channel Type is 0xHH (to be assigned by IANA). Sequence Number is incremented for successive test packets. The length and value of padding, and whether to include optional CRC-32 are determined by test packet size and packet pattern, which have been specified in section 3.1 and can be either provisioned manually or indicated by Request Start Message sent from the initiator MEP. Note that except for throughput measurement, the defined test packet can also be used for "Data Plane Loopback" sub-function of diagnostic Xiao, et al. Expires October 14, 2010 [Page 10] Internet-Draft Thput Estimation for MPLS-TP April 2010 tests which is specified in [I-D.ietf-mpls-tp-oam-framework]. 4. Throughput Measurement Procedures As specified in [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. In addition, the test parameters for sending test traffic need to be provisioned before initiating a throughput measurement at the initiator MEP, and they include initial sending rate, sending duration, test packet size, test packet Pattern and test packet PHB. Also note that the expected measurement resolution needs to be specified before throughput measurement procedures start. 4.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 must 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 at the initiator MEP and trigger the peer MEP to start test packets counting. For two-way throughput measurement, except for the same intention as one-way throughput measurement, this message is also intended to convey necessary test parameters to the peer MEP and trigger the test traffic sending at the peer MEP, and for rerun only Run Count and Sending Rate in the message need to be changed while other parameters retain initial values. Furthermore, for both one- way and two-way measurement, the initiator MEP should start test packet counting as soon as it transmit this message. Specifically if the connection is unidirectional, then the Control Code in the message must not be set to 0x0 (in-band reply requested), moreover if no return path exists the Control Code in the message must be set to 0x2 (no reply requested). 4.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 test packet counting. In addition, if the received One-way/Two-way flag indicates that this is a two-way throughput measurement, then the peer MEP also need to prepare for sending test traffic using the Xiao, et al. Expires October 14, 2010 [Page 11] Internet-Draft Thput Estimation for MPLS-TP April 2010 received test parameters. Specifically if the received One-way/Two-way flag indicates that this is a one-way throughput measurement, and the received Control Code is set to 0x2 (no reply requested) which means the connection is unidirectional without return path, then the peer MEP won't transmit Start Reply. 4.3. Transmitting a Throughput Measurement Start Reply When the Control Code in a received Start Request is set to 0x0 (in- band reply requested) or 0x1 (out-of-band reply requested), 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 Request/Reply flag and Control Code field, other fields of Start Reply Message will be copied from the received Start Request Message. 4.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. 4.5. Sending and Receiving Test Traffic For a bidirectional MPLS-TP connection or a unidirectional MPLS-TP connection with return path, the initiator MEP must send test traffic after receiving the Start Reply in which Control Code indicates success. For a unidirectional MPLS-TP connection without return path, the initiator MEP must send test traffic after transmitting the Start Request in which Control code is set to 0x2 (no reply requested). For one-way throughput measurement, only the initiator MEP must send test traffic. For two-way throughput measurement, both the initiator MEP and the peer MEP must send test traffic, and the peer MEP must send test traffic after transmitting the Start Reply in which Control Code is set to 0x0 (success). For two-way throughput measurement it's possible that a pair of MEPs sends test traffic asynchronously, and in this case the peer MEP will send test traffic some earlier than the initiator MEP, but the asynchronism has no effect on the measurement result. Xiao, et al. Expires October 14, 2010 [Page 12] Internet-Draft Thput Estimation for MPLS-TP April 2010 When the initiator MEP sends test traffic the test parameters are all derived from the provisioned test parameters for the first run, and for rerun only the sending rate is changed and derived from the local calculation. When the peer MEP sends test traffic the test parameters are all derived from the received Start Request Message and no provision is needed at the peer MEP. 4.6. Transmitting a Throughput Measurement Stop Request For every run, after the initiator MEP finished 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, and trigger the peer MEP to stop test packet counting and feed back the counters. Specifically if the connection is unidirectional, then the Control Code in the message must not be set to 0x0 (in-band reply requested), moreover if no return path exists the Control Code in the message must be set to 0x2 (no reply requested). 4.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 test packet counting. Specifically if the received One-way/Two-way flag indicates that this is a one-way throughput measurement, and the received Control Code is set to 0x2 (no reply requested) which means the connection is unidirectional without return path, then the peer MEP won't transmit Stop Reply and it will use the received Tx Counter to calculate test packet loss directly. 4.8. Transmitting a Throughput Measurement Stop Reply When the Control Code in a received Stop Request is set to 0x0 (in- band reply requested) or 0x1 (out-of-band reply requested), 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 are set to the test packet counting values at the peer MEP. 4.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 Xiao, et al. Expires October 14, 2010 [Page 13] Internet-Draft Thput Estimation for MPLS-TP April 2010 field or value is found, and the received Control Code indicates successful operation at the peer MEP, then the initiator MEP should start calculating the test packet loss. Suppose the Tx Counter and Rx Counter for the initiator MEP are TxP1 and RxP1, and for the peer MEP are TxP2 and RxP2. For two-way throughput measurement, the calculation formulas are as follow: Packet Loss (forward) = TxP1 - RxP2 Packet Loss (reverse) = TxP2 - RxP1 For one-way throughput measurement, the calculation formula is as follow: Packet Loss (one-way) = TxP1 - RxP2 4.10. Consequent Actions and Searching Algorithm Procedures for one run of test traffic sending and test 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 the calculated results of test packet loss and the expected measurement resolution. 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 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 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 RECOMMENDED 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 Xiao, et al. Expires October 14, 2010 [Page 14] Internet-Draft Thput Estimation for MPLS-TP April 2010 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 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 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. Other algorithms than the binary search algorithm could also be used to search throughput in practice, e.g. increasing or decreasing the sending rate in a fixed step from a specified initial sending rate until the test packet loss appears or disappears. 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. It's obvious that longer sending duration is provisioned, then longer throughput measurement time is needed, but Xiao, et al. Expires October 14, 2010 [Page 15] Internet-Draft Thput Estimation for MPLS-TP April 2010 it should be noted that longer sending duration can result in more precise measured throughput, so there should be a balance between them. Also obviously the expectations for shorter throughput measurement time and higher throughput measurement resolution are mutually exclusive, so the balance between them is needed too. 6. IANA Considerations To be added in a later version of this document. 7. Security Considerations To be added in a later version of this document. 8. Acknowledgements To be added in a later version of this document. 9. References 9.1. Normative References [I-D.ietf-mpls-tp-oam-requirements] Vigoureux, M. and D. Ward, "Requirements for OAM in MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements-06 (work in progress), March 2010. [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. 9.2. Informative References [I-D.ietf-mpls-tp-oam-framework] Allan, D., Busi, I., and B. Niven-Jenkins, "MPLS-TP OAM Framework", draft-ietf-mpls-tp-oam-framework-05 (work in progress), March 2010. [RFC1242] Bradner, S., "Benchmarking terminology for network interconnection devices", RFC 1242, July 1991. Xiao, et al. Expires October 14, 2010 [Page 16] Internet-Draft Thput Estimation for MPLS-TP April 2010 [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 Y.1731, February 2008. Authors' Addresses Min Xiao ZTE Corporation Email: xiao.min2@zte.com.cn 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 October 14, 2010 [Page 17]