Internet DRAFT - draft-xhk-mpls-tp-throughput
draft-xhk-mpls-tp-throughput
MPLS Working Group M. Xiao, Ed.
Internet-Draft ZTE
Intended status: Standards Track F. Huang, Ed.
Expires: April 12, 2012 Alcatel-Lucent
S. Kini, Ed.
Ericsson
H. Li
China Mobile
R. Jing
China Telecom
October 10, 2011
Throughput Measurement for MPLS-based Transport Networks
draft-xhk-mpls-tp-throughput-03
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 April 12, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Xiao, et al. Expires April 12, 2012 [Page 1]
Internet-Draft Thput Measurement for MPLS-TP October 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 . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Xiao, et al. Expires April 12, 2012 [Page 2]
Internet-Draft Thput Measurement for MPLS-TP October 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. As defined in section
6.3.1 of [RFC6371], 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. It must
be noted that the OAM packet formats and procedures for throughput
measurement is actually a variation of loss measurement protocol
which is specified in [RFC6374]. The purpose of this document is to
specify the adaptation to loss measurement protocol for achieving
throughput 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
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
Xiao, et al. Expires April 12, 2012 [Page 3]
Internet-Draft Thput Measurement for MPLS-TP October 2011
OAM: Operations, Administration and Maintenance
OWTM: One-way Throughput Measurement
PHB: Per-hop Behavior
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
Xiao, et al. Expires April 12, 2012 [Page 4]
Internet-Draft Thput Measurement for MPLS-TP October 2011
takes place between the two MEPs. The control packets are defined in
section 3 and the detailed methods are described in section 4.
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 April 12, 2012 [Page 5]
Internet-Draft Thput Measurement for MPLS-TP October 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 |0xHHHH(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 0xHHHH (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 April 12, 2012 [Page 6]
Internet-Draft Thput Measurement for MPLS-TP October 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 April 12, 2012 [Page 7]
Internet-Draft Thput Measurement for MPLS-TP October 2011
0x1: Error. Indicates that the operation failed.
Total TLV Length
The total Type-Length-Value (TLV) length is the total length in
bytes 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 April 12, 2012 [Page 8]
Internet-Draft Thput Measurement for MPLS-TP October 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 Rx 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 April 12, 2012 [Page 9]
Internet-Draft Thput Measurement for MPLS-TP October 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] and specified in
[I-D.ietf-mpls-tp-li-lb].
Xiao, et al. Expires April 12, 2012 [Page 10]
Internet-Draft Thput Measurement for MPLS-TP October 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 via NMS action. 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 April 12, 2012 [Page 11]
Internet-Draft Thput Measurement for MPLS-TP October 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 April 12, 2012 [Page 12]
Internet-Draft Thput Measurement for MPLS-TP October 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 April 12, 2012 [Page 13]
Internet-Draft Thput Measurement for MPLS-TP October 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 April 12, 2012 [Page 14]
Internet-Draft Thput Measurement for MPLS-TP October 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 April 12, 2012 [Page 15]
Internet-Draft Thput Measurement for MPLS-TP October 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
[I-D.ietf-mpls-tp-li-lb]
Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M.,
and X. Dai, "MPLS Transport Profile lock Instruct and
Loopback Functions", draft-ietf-mpls-tp-li-lb-07 (work in
progress), October 2011.
[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.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011.
Xiao, et al. Expires April 12, 2012 [Page 16]
Internet-Draft Thput Measurement for MPLS-TP October 2011
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.
[RFC6371] Busi, I. and D. Allan, "Operations, Administration, and
Maintenance Framework for MPLS-Based Transport Networks",
RFC 6371, September 2011.
[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
Xiao, et al. Expires April 12, 2012 [Page 17]
Internet-Draft Thput Measurement for MPLS-TP October 2011
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
Bo Wu
ZTE Corporation
Email: wu.bo@zte.com.cn
Jian Yang
ZTE Corporation
Email: yang_jian@zte.com.cn
Xiao, et al. Expires April 12, 2012 [Page 18]
