MPLS Working Group M. Xiao, Ed. Internet-Draft ZTE Intended status: Standards Track F. Huang, Ed. Expires: September 30, 2011 Alcatel-Lucent S. Kini, Ed. Ericsson H. Li China Mobile R. Jing China Telecom March 29, 2011 Throughput Measurement for MPLS-based Transport Networks draft-xhk-mpls-tp-throughput-02 Abstract An important Operation, Administration and Maintenance (OAM) requirement of the MPLS Transport Profile (MPLS-TP) is the ability to measure the throughput (i.e. bandwidth) of an MPLS-TP connection which could be an MPLS-TP PseudoWire (PW), Label Switched Path (LSP) or Section. This document specifies the OAM packet formats and procedures for both one-way and two-way throughput 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 30, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Xiao, et al. Expires September 30, 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 . . . . . . . . . . . . . . 5 2.3. Two-way Throughput Measurement . . . . . . . . . . . . . . 5 3. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Throughput Measurement Control Packet Format . . . . . . . 6 3.2. Throughput Measurement Test Data Packet Format . . . . . . 10 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Throughput Measurement Procedures in Estimated Mode . . . 11 4.2. Throughput Measurement Procedures in Measured Mode . . . . 11 4.2.1. Transmitting a Throughput Measurement Start Request . 12 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 . . . . . . . . . . 13 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 . . . . 14 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 30, 2011 [Page 2] Internet-Draft Thput Measurement for MPLS-TP March 2011 1. Introduction Requirements for OAM in MPLS-TP Networks (section 2.2.5) [RFC5860] specifies that the OAM toolset must provide a function to enable conducting diagnostic tests on a PseudoWire (PW), Label Switched Path (LSP) or Section. According to [RFC5860], this function should be performed on-demand. An example of such a diagnostic test would be measuring the available bandwidth of an LSP. The above required sub-function of diagnostic tests is specified as "throughput measurement" in this document. Throughput measurement is an on-demand out-of-service function. Throughput measurement is performed between two Maintenance Entity Group End Points (MEPs) in one-way or two-way mode. This document specifies the OAM packet formats and procedures for both one-way and two-way throughput 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 OWTM: One-way Throughput Measurement PHB: Per-hop Behavior Xiao, et al. Expires September 30, 2011 [Page 3] Internet-Draft Thput Measurement for MPLS-TP March 2011 PRBS: Pseudo-Random Bit Sequence PW: PseudoWire TLV: Type Length Value TWTM: Two-way Throughput Measurement 2. Overview In [RFC1242], the throughput is defined as a performance metric for a network interconnection device. It is defined as "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 PW, LSP or Section. 2.1. Throughput Measurement Modes As per [RFC2544], the throughput measurement procedure is specified as sending a specific number of frames at a specific rate through the Device Under Test (DUT) and then counting 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 that 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 by the test equipment. But in many practical throughput measurement scenarios, usually the throughput is measured by test equipment using the binary search algorithm. In this case, multiple sets of test traffic ('run') are sent in one process of throughput measurement. In this document, the 'run count' indicates how many sets of test traffic are sent. If the implementation simplicity is chosen over the precision of throughput measurement, the measurement method described in [RFC2544] should be used. This is also called 'estimated mode'. The measurement methods described in this document are for measuring throughput with precision and efficiency; this method is referred to as 'measured mode'. In estimated mode, the measurement process is controlled by the operator and no control packet exchange takes place between the two MEPs. In measured mode, the control packet exchange takes place between the two MEPs. The control packets are defined in section 3 and the detailed methods are described in section 4. Xiao, et al. Expires September 30, 2011 [Page 4] Internet-Draft Thput Measurement for MPLS-TP March 2011 2.2. One-way Throughput Measurement One-way throughput measurement (OWTM) SHOULD 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 stays active throughout the whole process. Estimated mode: The initiator MEP sends test traffic and the peer MEP calculates the test data packet loss. Measured mode: The initiator MEP controls the whole process of measurement and the peer MEP acts as a responder. 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 (TWTM) SHOULD be supported for only bidirectional MPLS-TP connection. Two-way throughput indicates both the throughputs for the forward and the reverse direction of the connection from the initiator MEP. Estimated mode: Only the initiator MEP sends test traffic and the peer MEP loopbacks all received test data packets. Only the minimum of avaiable throughput of the two directions are considered. Measured mode: Both the initiator MEP and the peer MEP send test traffic, and the initiator MEP controls the whole process of measurement. In this case, the two individual available throughputs of the two directions are considered. 3. Packet Format For throughput measurement in estimated mode, only the test data packets would be sent by the MEP. For throughput measurement in measured mode, the specific packets sent by the MEP can be divided into control packets and test data packets. The 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. The test data packets compose the test traffic which emulates the real user traffic. Xiao, et al. Expires September 30, 2011 [Page 5] Internet-Draft Thput Measurement for MPLS-TP March 2011 3.1. Throughput Measurement Control Packet Format The format of a throughput measurement control 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 (Throughput Meas Control)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ Throughput Measurement Control Message ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Throughput Measurement Control Packet Format 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 Format 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 follows: Xiao, et al. Expires September 30, 2011 [Page 6] Internet-Draft Thput Measurement for MPLS-TP March 2011 +-+-+-+-+ |W|S|R|E| +-+-+-+-+ Figure 3: Throughput Measurement Control Message Flags W-flag: This Flag represents the operational mode which could be One-way mode or Two-way mode. Set to 0 for OWTM; Set to 1 for TWTM. 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. Xiao, et al. Expires September 30, 2011 [Page 7] Internet-Draft Thput Measurement for MPLS-TP March 2011 0x1: Error. Indicates that the operation failed. Total TLV Length The total Type-Length-Value (TLV) length is the total of all included TLVs. TLVs According to the values of W-flag, S-flag and R-flag, the TLVs are defined as follow. For Start Request/Reply message in OWTM: No TLVs are defined. For Start Request/Reply message in TWTM only: One TLV is defined to convey test parameters for the peer MEP to send test traffic. The format of this TWTM Start Message TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0 | Length = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sending Rate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sending Duration | Packet Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Pattern| PHB | Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: TWTM Start Message TLV Format 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 Xiao, et al. Expires September 30, 2011 [Page 8] Internet-Draft Thput Measurement for MPLS-TP March 2011 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 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 Per-hop Behavior (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 messages in both OWTM and TWTM: One TLV is defined to convey Tx and Tx counters for the initiator MEP to calculate test data packet loss. The format of this Stop Message TLV is shown below. Xiao, et al. Expires September 30, 2011 [Page 9] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Counter | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rx Counter | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Stop Message TLV Format Tx Counter Tx Counter is set to the number of throughput measurement test data packets sent by the local MEP (i.e. the MEP 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 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 1, throughput measurement is an on-demand out-of-service function. Before throughput measurement is initiated, the diagnosed Maintenance Entity Group (MEG) SHOULD be put into a Lock status, and an MEG can be put into a Lock status either via Network Management System (NMS) action or using the Lock Instruct OAM tool which is required in [RFC5860]. Xiao, et al. Expires September 30, 2011 [Page 10] Internet-Draft Thput Measurement for MPLS-TP March 2011 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. Thus all these parameters SHOULD be configurable for throughput measurement in the 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. They SHOULD be configurable for throughput measurement in the 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 OWTM, 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 to Sequence-Number field of the test data packet. If the 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 a test traffic with the increased sending rate for rerun. Thus 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 TWTM, 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 in [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. Thus 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 Xiao, et al. Expires September 30, 2011 [Page 11] Internet-Draft Thput Measurement for MPLS-TP March 2011 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 at the start of every rerun of sending test traffic, the initiator MEP would also transmit this message. For OWTM, 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 TWTM, this message is further intended to convey necessary test parameters to the peer MEP and trigger the peer MEP to send test traffic. Run Count and Sending Rate in this message would be changed for the rerun. 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. 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 TWTM, 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. 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 an 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 throughput measurement Start Reply received after a while (e.g. 1 second), then an implementation dependent specific error should be returned at the initiator MEP. In this case, no test traffic will be sent from the Xiao, et al. Expires September 30, 2011 [Page 12] Internet-Draft Thput Measurement for MPLS-TP March 2011 initiator MEP. 4.2.5. Sending and Receiving Test Traffic From the above procedures it can be seen that for TWTM, the pair of MEPs will send test traffic asynchronously, and the peer MEP will start/stop sending test traffic some time earlier than the initiator MEP. This asynchronous behavior 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 initial configuration. For the reruns, 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. 4.2.6. Transmitting a Throughput Measurement Stop Request For every run, after the initiator MEP finishes sending test traffic, it transmits a throughput measurement Stop Request to the peer MEP. This message is to inform the peer MEP to stop the test traffic from the initiator MEP. It triggers 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 TWTM, as indicated in section 4.2.5, the peer MEP stops 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 transmits 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. On the contrary set to 0x1 to reflect the failed operation at the peer MEP. The Tx Counter and Rx Counter in the Stop Reply Message are set to the test data packet count at the peer MEP. Xiao, et al. Expires September 30, 2011 [Page 13] Internet-Draft Thput Measurement for MPLS-TP March 2011 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 OWTM, the calculation formula is as follows: Packet Loss (one-way) = TxP1 - RxP2 For TWTM, the calculation formulas are as follows: Packet Loss (forward) = TxP1 - RxP2 Packet Loss (reverse) = TxP2 - RxP1 If an 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 throughput measurement Stop Reply received after a while (e.g. 1 second), then an implementation dependent specific error should be returned at the initiator MEP. In this case, 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 depends on the calculated test data packet loss and the expected measurement resolution. For OWTM, if calculated Packet Loss (one-way) is equal to zero and the expected measurement resolution is met, then rerun is not needed. Thus the current sending rate is the measured one-way throughput. For TWTM, 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. Thus the current sending rate for forward/reverse direction is the measured forward/reverse throughput. The standard 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. For example, suppose to measure the throughput of a connection whose actual throughput is 70Mbps, the Xiao, et al. Expires September 30, 2011 [Page 14] Internet-Draft Thput Measurement for MPLS-TP March 2011 provisioned initial sending rate is 100Mbps and the specified measurement resolution is 0.1. Note that the initial sending rate MUST be no less 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 if shorter throughput measurement time is required, 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 - so the balance between them is also needed. Xiao, et al. Expires September 30, 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 An ACH Channel Type value for the throughput measurement control packet will be requested for IANA assignment. 8. Acknowledgements The authors would like to thank Loa Andersson, Dave Allan, Samita Chakrabarti, 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 [RFC1242] Bradner, S., "Benchmarking terminology for network interconnection devices", RFC 1242, July 1991. [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. Xiao, et al. Expires September 30, 2011 [Page 16] Internet-Draft Thput Measurement for MPLS-TP March 2011 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 Lizhong Jin ZTE Corporation Email: lizhong.jin@zte.com.cn Xiao, et al. Expires September 30, 2011 [Page 17] Internet-Draft Thput Measurement for MPLS-TP March 2011 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 30, 2011 [Page 18]