Internet DRAFT - draft-sun-ippm-twamp-flowbased
draft-sun-ippm-twamp-flowbased
IPPM L. Sun
Internet-Draft BUPT
Intended status: Informational F. Yu
Expires: August 12, 2013 Huawei Technologies
X. Gong
BUPT
February 8, 2013
TWAMP Flow-based Performance Measurement
draft-sun-ippm-twamp-flowbased-00
Abstract
This memo describes an extension to the Two-Way Active Measurement
Protocol (TWAMP). Through carrying the information of business flow,
it can measure the online performance without bringing effect to
application significantly.
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 August 12, 2013.
Copyright Notice
Copyright (c) 2013 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
include Simplified BSD License text as described in Section 4.e of
Sun, et al. Expires August 12, 2013 [Page 1]
Internet-Draft TWAMP Flow-based performance measurement February 2013
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 5
3. Flow-based Performance Measurement principles . . . . . . . . 6
4. TWAMP-Control Extension . . . . . . . . . . . . . . . . . . . 6
4.1. Connection Setup with New Feature . . . . . . . . . . . . 6
4.2. Test Session Creation: Request-TW-Session Packet Format . 7
5. Extended TWAMP-Test . . . . . . . . . . . . . . . . . . . . . 9
5.1. sender behavior . . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Packet timing . . . . . . . . . . . . . . . . . . . . 10
5.1.2. Session-sender Packet Format . . . . . . . . . . . . . 10
5.2. reflector behavior . . . . . . . . . . . . . . . . . . . . 11
5.2.1. Session-Reflector Packet Format . . . . . . . . . . . 12
6. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Exception Handling . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Packet Reordering . . . . . . . . . . . . . . . . . . . . 15
8. Use case . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative Reference . . . . . . . . . . . . . . . . . . . 17
11.2. Informative Reference . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Sun, et al. Expires August 12, 2013 [Page 2]
Internet-Draft TWAMP Flow-based performance measurement February 2013
1. Introduction
According to the existing extension of [RFC5357], the extension
context of TWAMP includes embedding a number of meaningful fields in
the padding octets of the TWAMP test packet transmitted between a
Session-Sender and a Session-Reflector [RFC5357] [RFC6038], and
redefining existing fields like in [I-D.morton-ippm-twamp-rate] or
adding new fields like in [RFC6038] in the Request-TW-Session Packet
transmitted between a Control-Client and a server. This memo
describes the implementation of Flow-based Performance Measurement
(FPM) under the architecture of TWAMP, or as an optional extension of
TWAMP. The FPM has been described individually in
[I-D.sun-ippm-flowbased-pm]. It is an end-to-end flow-based
performance measurement method, which is achieved by generating
synthetic measurement packets, injecting them to the network and
analyzing the statistics carried in the measurement packets. This
measurement method can support the online and real-time performance
measurement of a particular or one kind of applications with
negligible effect on the application.
Throughout this memo, the bits marked MBZ (Must Be Zero) MUST be set
to zero by senders and MUST be ignored by receivers. Also, the HMAC
(Hashed Message Authentication Code) MUST be calculated as defined in
Section 3.2 of [RFC4656].
1.1. Problem statement
The TWAMP protocol proposed by IPPM WG provides a simple and useful
network performance measurement method. It aims at using a safe and
effective way to measure the performance of the IP network. TWAMP
uses TWAMP-Control protocol to initiate, start, and stop test
sessions, making the measurement process with more flexibility and
security. It uses TWAMP-Test protocol for the actual network test by
injecting test packets into network, so that various properties of
the network can be measured offline effectively. However, while
TWAMP is able to achieve most network measurement situations, it does
not work well in some cases on the performance testing for real time
business.
In some cases, it needs to monitor the various time-varying
performance indexes of the IP network, the performance measurement
should be based on real service stream and reflect the real
performance of the network. For measuring the performance of the
real service stream, TWAMP has the following defects due to the limit
of measurement parameters and its framework.
Sun, et al. Expires August 12, 2013 [Page 3]
Internet-Draft TWAMP Flow-based performance measurement February 2013
o TWAMP is mainly used to measure the performance of the network.
It cannot be well applied to the real-time performance measurement
of a particular or one kind of applications.
o In the case of real time measurement of network performance, if
the test packets are sent too frequently, the network load will be
increased and application flows will be affected. Otherwise, if
the number of test packets is small, the performance of the
network cannot be reflected accurately by the measurement.
For example, for real time streaming media services such as IPTV and
video conference, packets carry QoS parameters to ensure service
quality for different application flows. Network needs to real time
monitor the performance of these application flows, in order to
adjust the allocation of resources in network according to the
monitoring results in real time, thereby ensuring the QoS
requirements of different applications. For the performance
measurement of such business discussed above, TWAMP cannot meet all
the requirements well as a result of the above defects.
For the problems discussed above, it is required to define a new
measurement framework, which is able to meet the demand for real time
measurement of application flows, and does not have much impact on
the data flow itself. At the same time, this new measurement method
will be able to meet the following goals of the IPPM measurement:
guarantee the Service Level Agreement (SLA) provided to the
customers, detect/locate the network performance defects, react in
response to performance degradation or the failures promptly, and
optimize the network resources utilization.
In the following section, we discuss the requirements of IP
performance measurement in IP mobile backhaul network.
In mobile operator's backhaul network, there must be a performance
monitoring mechanism to check the traffic status in the network.
With the status information, some strategies can be implemented on
entities. For example, eNodeB can implement online congestion
control and bandwidth adjustment strategy based on the performance
monitoring result. Hence, IPPM mechanism is required to provide a
reasonable estimate of the amount of delay, ipdv (IP Packet Delay
Variation) and packet loss in the backhaul network connecting it to
the GW.
In order to avoid adding superfluous traffic to the backhaul and
leading to the increase of the load level in the network, it is
necessary that the frequency of measurement packets generation is
kept at a minimum. Moreover, these packets should not lead to an
excessive computational overload on the eNodeB and the GW. In other
Sun, et al. Expires August 12, 2013 [Page 4]
Internet-Draft TWAMP Flow-based performance measurement February 2013
words, the process of generation of these probe packets should be
simple and must not overload the transport interface. The packets
must be small and infrequent so as to not cause un-necessary overload
on the backhaul bandwidth.
Applications or traffic in mobile backhaul network are divided into
multiple bearers with proper mobile QoS parameters (e.g. QCI). If
the mobile network would manage bearers as QoS and applications, then
the performance of backhaul is more like to be based on applications
or QoS. The currently active measurement method (e.g. TWAMP) may be
able to do flow-based measurement by specifying DSCP for the TWAMP-
test packets. But it can not well support the online measurement and
the length of test packet is changeless and not varying as the real
service packets. The average performance indexes measured by the
active measurement method may not be suitable in these cases.
A new measurement method can be applied into backhaul network, by
deploying an end-to-end performance monitor on eNodeB to assist
eNodeB to execute the congestion control and flow scheduling. Played
as sender entity, eNodeB sends out the test packets periodically to
trigger the other end (e.g. another eNodeB or an SGW) replying
acknowledgement packets, then to estimate the delay, ipdv (IP Packet
Delay Variation) and packet loss of each application flow by
collecting and calculating status information.
1.2. Requirements Language
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 [RFC2119].
2. Purpose and Scope
The purpose of this memo is to define an extended feature for TWAMP,
which is called Flow-based Performance Measurement (FPM).
The scope of the memo is limited to specifications of the following
extensions:
o The addition and redefinition some fields in the Request-TW-
Session command [RFC5357].
o The definition of new Session-Sender and Session-Reflector
behaviors.
o The definition of a structure for embedding a sequence of flow-
related fields at the beginning of the Packet Padding [RFC5357].
Sun, et al. Expires August 12, 2013 [Page 5]
Internet-Draft TWAMP Flow-based performance measurement February 2013
This feature can support the online and real-time performance
measurement of a particular or one kind of applications. Because the
test packets inserted are small and infrequent, the effect on the
application flows due to this measurement is negligible.
3. Flow-based Performance Measurement principles
In FPM, the business flow can be defined by different combinations of
source IP address (SIP), destination IP address (DIP), protocol type
(PT), DSCP, source port number (sPort) and destination port number
(dPort). Three types of combinations are suggested: (SIP, DIP, PT),
or (SIP, DIP, PT, DSCP) or (SIP, DIP, PT, sPort, dPort). The more
the combinational dimensions are, the more fine-grained can be the
monitoring of data flow.
Each test session established in TWAMP can measure a flow defined in
the way above. After the session is established, test packets can be
exchanged between the two endpoints of the flow, and the information
relative to the business flow based on which the measurement and
statistics can be done is carried in the test packets.
4. TWAMP-Control Extension
TWAMP connection establishment follows the procedure defined in
Section 3.1 of [RFC4656] and Section 3.1 of [RFC5357]. The Modes
field is employed to identify and select specific communication
capabilities in the TWAMP Control protocol [RFC5357]. In a similar
way with another extension of TWAMP, such as [RFC2680], the FPM
feature requires one new bit position (and value). Such bit position
(and value) is not defined in this memo.
4.1. Connection Setup with New Feature
The Server sets the new bit position in the Modes field of the Server
Greeting message to indicate its capabilities and willingness to
operate in the FPM mode if desired.
If the Control-Client intends to operate all test sessions invoked
with this control connection using the new mode, it MUST set the Mode
field bit corresponding the function in the Setup Response message.
With this extension, the Control- Client MAY set the Mode field bit
in the Setup Response message.
Sun, et al. Expires August 12, 2013 [Page 6]
Internet-Draft TWAMP Flow-based performance measurement February 2013
4.2. Test Session Creation: Request-TW-Session Packet Format
Comparing with the procedure of test session creation defined in
Section 3.5 of TWAMP [RFC5357], the message format of the Request-TW-
Session command has the exceptions with the message format as
described in Section 3.5 of TWAMP as follows:
Sun, et al. Expires August 12, 2013 [Page 7]
Internet-Draft TWAMP Flow-based performance measurement February 2013
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 5 |FT |MBZ| IPVN | Conf-Sender | Conf-Receiver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Schedule Slots |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Port | Receiver Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Sender Address (cont.) or MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Receiver Address (cont.) or MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SID (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Time |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timeout, (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type-P Descriptor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sun, et al. Expires August 12, 2013 [Page 8]
Internet-Draft TWAMP Flow-based performance measurement February 2013
o FT: this field occupies two bits. It indicates how a flow is
defined. 0x0 in this field is for (SIP, DIP, PT, sPort, dPort),
while 0x1 is for (SIP, DIP, PT, DSCP) and 0x2 is for (SIP, DIP,
PT). The 0X3 is not defined. In this mode, the test packets MUST
have the same sender and receiver address as the business packets.
So the SIP/DIP are the same as the value in the Sender address/
Receiver address field if the Sender Address and Receiver Address
fields are not set to 0. If they are set to 0, SIP/DIP are the
same as the IP addresses used for the Control-Client to Server
TWAMP-Control message exchange.
By this same logic, if the value of FT is 0x1, the value of the DSCP
is the same as the value in the Type-P Descriptor.
o Protocol Type: these octets composed the field of number of
packets in OWAMP [RFC4656], whereasGBP[not]in TWAMP
[RFC5357]GBP[not]it is unused and set to 0. In FPM mode, this
filed is reinterpreted as the protocol type value of the service
flow needed to be measured. It may be UDP, TCP, SCTP or other
types. The value of this field SHOULD follow the IANA types
defined in [RFC1700].
o SID: in the FPM mode, there MAY be lots of test sessions related
to different business flow between the same pair of hosts and
ports. So, it is necessary to set this field to identify the
session. However, in this mode, only last two octets are
employed, the first 14 octets MUST be zero.
o Padding length: in this mode, the test packets needn!_t include
padding field as described in section 5.1.2. so the padding length
MUST be set to 0.
o sPort and dPort: these two fields both occupy two octets. They,
which indicate source and destination port number of the business
packets respectively, are valid only when the flow is defined by
(SIP, DIP, PT, sPort, dPort).
5. Extended TWAMP-Test
5.1. sender behavior
This section describes the extensions to the behavior of the TWAMP
Session-Sender.
Sun, et al. Expires August 12, 2013 [Page 9]
Internet-Draft TWAMP Flow-based performance measurement February 2013
5.1.1. Packet timing
The send schedule is the same as in OWAMP.
5.1.2. Session-sender Packet Format
The Session-Sender packet format follows the same procedure and
guidelines as defined in TWAMP [RFC5357]GBP[not]but with some
embedding fields .
This feature allows the Session-Sender to set a few octets instead of
the TWAMP-Test Packet Padding under the unauthenticated modes or in
the MBZ fields under the authenticated and encrypted modes with flow
information, which includes the number of the packets and bytes sent
by the sender. Therefore, the placement of bits from the FPM octets
depends on the mode(s) being selected.
In this modeGBP[not]there SHOULD be no Packet Padding fields in the
test packets in order to save the network resource and avoid creating
adverse effects on the business flow.
So symmetrical size of TWAMP-Test packets in the forward and reverse
directions of transmission is not need in FPM mode.
The Session-Sender SHOULD use the following TWAMP-Test packet format
when the FPM feature is selected in conjunction with the
Unauthenticated mode:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdTxPkt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdTxByte |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Session-Sender SHOULD use the following TWAMP-Test packet format
when the FPM feature is selected in conjunction with the
authenticated and encrypted mode:
Sun, et al. Expires August 12, 2013 [Page 10]
Internet-Draft TWAMP Flow-based performance measurement February 2013
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdTxPkt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdTxByte |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MBZ (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value of SID is equal to the last two octets of SID in Request-
TW-Session command.
The value of FwdTxPkt/FwdTxByte field is the accumulation of the
number of the packets/bytes sent by the session-sender. In order to
determine the value of the fields of FwdTxPkt and FwdTxByte, the
session-sender maintains two counters, SPN and SBN, for each FPM flow
that is incremented every time a business packet is sent. When the
test packets are to be sent, the FwdTxPkt and FwdTxByte are set to
the then value of the counters respectively.
5.2. reflector behavior
The TWAMP Session-Reflector follows the procedures and guidelines in
Section 4.2 of [RFC5357], with some changes and additional functions.
When the FPM mode is selected, the behavior of the Session-Reflector
SHOULD be as follows:
The session-reflector is required to transmit a packet to the
session-sender in response to each test packet it receives.
When the session-reflector receives a test packet, it copies the
Sun, et al. Expires August 12, 2013 [Page 11]
Internet-Draft TWAMP Flow-based performance measurement February 2013
value of FwdTxPkt, FwdTxByte and SID in test packet from the session-
sender into the corresponding fields of the reflected test packet,
and sets the fields of Sender Timestamp, Receive Timestamp and other
fields as it does in TWAMP [RFC5357]. And then the reflected test
packet is reflected to the session-sender.
Note that there SHOULD be no Packet Padding field in the reflected
test packets in order to save the network resource and avoid creating
adverse effects on the business flow.
5.2.1. Session-Reflector Packet Format
When the FPM mode is selected, the Session-Reflector SHOULD use the
following TWAMP-Test Packet Format in Unauthenticated mode:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdRxPkt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdRxByte |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdTxPkt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdTxByte |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When the FPM mode is selected, the Session-Reflector SHOULD use the
Sun, et al. Expires August 12, 2013 [Page 12]
Internet-Draft TWAMP Flow-based performance measurement February 2013
following TWAMP-Test Packet Format in authenticated and encrypted
mode:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdRxPkt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdRxByte |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MBZ (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdTxPkt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdTxByte |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (12 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MBZ (6 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | |
+-+-+-+-+-+-+-+-+ +
| |
| |
| MBZ (15 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HMAC (16 octets) |
Sun, et al. Expires August 12, 2013 [Page 13]
Internet-Draft TWAMP Flow-based performance measurement February 2013
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The FwdTxPkt and FwdTxByte are copied from the corresponding test
packet from Session-Sender.
FwdRxPkt is the accumulation of the number of the packets received by
the Session-Reflector.
FwdRxByte is the accumulation of the number of bytes received by the
Session-Reflector.
In order to determine the value of the fields of FwdRxPkt and
FwdRxByte, the Session-Reflector maintains two counters, RPN and RBN,
for each FPM flow that is incremented every time a business packet is
received. When the Session-Reflector test packets are to be sent,
the FwdRxPkt and FwdRxByte are set to the then value of the counters
respectively.
Note that the Control client could start multiple measurement
engines; each engine is corresponding to an active logical path (with
a different Flow). These measurement engines operate in parallel,
and send test packets with the flow id (which is indicated by the SID
filed) of the logical path, collect the corresponding reflected test
packets, and maintain the collected statistical values.
6. Metrics
In FPM mode, most of the Metrics defined by IPPM WG can be measured,
such as the one-way delay metric for IPPM defined in [RFC2679], the
round-trip delay metric for IPPM defined in [RFC2681], the one-way
loss metric [RFC2680], the IP packet delay variation metric for IPPM
defined in [RFC3393], etc..
This section takes the one-way loss metric [RFC2680] as an example,
it can be calculated as follows.
In FPM mode, session-sender uses a counter to count the actual number
of bussiness packets sent by it. Session-reflector records whether
business packet has arrived or not, if the packet reaches the
session-reflector, business packet loss value is 0; if the packet is
lost during transmission, the business packet loss value is 1.
Session-reflector cumulates the loss value, and calculates the number
of packets actually received. The above parameters, carried by
Sun, et al. Expires August 12, 2013 [Page 14]
Internet-Draft TWAMP Flow-based performance measurement February 2013
measurement packets, are exchanged between both sides, used to
calculate packet loss and loss rate in session-sender ultimately.
In some cases the Session-sender Packet Loss or Session-reflector
test packet may be lost in transit, and then no statistics can be
obtained from this round of measurement. So the loss rate of the
packet loss rate (plr) of the mth measurement can be calculated as:
(SPN(d)-SPN(d-1))-(RPN(d)-RPN(d-1))
plrd = -------------------------------------
SPN(d)-SPN(d-1)
Where m is the sequence number of the test packet currently received
by Session-reflector, n is the sequence number of the latest test
packet received by Session-reflector, and SPN(x) and RPN(x) are the
value of FwdTxPkt and FwRxPkt in the xth test packet.
As described above, measurement packet only needs to carry statistics
information of both sides in the FPM. The measurement packet size
and the transmission frequency are relatively small, so FPM will not
cause too much impact on the original business.
7. Exception Handling
7.1. Packet Reordering
In the Session-Reflector side if the received packets are out of
order, the Session-sender test Packet may arrive earlier than the
last service packet sent before it, or later than the first service
packet sent after it. Then statistical error of packet loss will be
result in.
There are several reasons for packet reordering. When a network node
receives a fragmented IP packet, it has to reassemble the datagram
and the extra time spent on the IP fragment reassembly may cause
packet reordering; some load sharing schemes for network (e.g. ECMP,
ML-PPP) may create multipath for packets, which can also cause packet
reordering; Multi-core CPU processing and multi-threading of packets
in the sender and receiver may also lead to packet reordering.
In the simplest case that data transmits along a single path, DSCP
can be used to classify the flow in order to avoid the packet
reordering.
Note that the packet loss calculation is based on sample statistic,
and by increasing the monitoring period, the error caused by the
Sun, et al. Expires August 12, 2013 [Page 15]
Internet-Draft TWAMP Flow-based performance measurement February 2013
occasional packet reordering can be smoothed.
8. Use case
This section describes a typical scene using the FMP mode. The
wireless mobile backhaul networks based on IP, share the available
capacity between the connected eNodeBs. Compared to the traditional
SDH/ATM transport network, in IP-RAN, the data transfer speed is
unstable and data transfer is lacks of QoS guarantee and there is no
perfect testing method on packet loss, delay and ipdv (IP Packet
Delay Variation). So it is necessary for the nodes in the RAN side
to detect the network quality of the connection between RNC and NodeB
or eNodeB and SAE.
Take the eNodeB and SAE for example; in order to make sure that the
amount of generated traffic is aligned with the available capacity,
it is important that the eNodeB probes the backhaul network to
determine the actual delay, jitter and packet loss encountered by
typical packets. The proposed method in this document can be used to
detect the IP Performance of the connections between the eNB and
S-GW.
As shown in the figure 1, the Control-Client/Session-Sender is
deployed in eNodeB, and the Server/Session-Reflector is deployed in
S-GW.
________________ _________________
| | control protocol | |
| | <----------------------> | |
|Control-Client/ | Session-Sender packet | Server/ |
|Session-Sender | -----------------------> |Session-Reflector|
| | Session-Reflector packet | |
|----------------| <----------------------- |-----------------|
: eNodeB : : S-GW :
:................: :.................:
Figure 1: Example of FPM mode in backhaul network
At the eNodeB, test packets followed the format as Section 5.1.2 are
generated periodically with the source and destination IP addresses,
and DSCP class. At the S-GW, after receiving the test packets from
the eNodeB, test packets with the format described in Section
5.2.1are constructed. They are then forwarded back to the eNodeB.
We sent a similar packet of OAM, packet size and the transmission
frequency is relatively small, so TWAMP in FPM mode will not cause
Sun, et al. Expires August 12, 2013 [Page 16]
Internet-Draft TWAMP Flow-based performance measurement February 2013
too much impact on the original business between eNodeB and S-GW.
Since test packet is constructed according to the business packet,
the network path of test packet and business packet is the same
(Tunneling is used for the data transmission between eNodeB and S-GW,
the parameter statistics of FPM mode should be carried before the
tunnel. Test packet and business packet are encapsulated into a same
tunnel and they are passed in the same path). The data obtained
through FPM can represent the performance of the business flows
between the eNodeB and the S-GW accurately.
Upon receiving the test packets at the logical port the eNodeB
exactly knows the current congestion extent in transport network.
The bandwidth of the logical port is reduced if congestion is
detected according to the measurement result; otherwise, the
bandwidth is increased slowly.
9. IANA Considerations
This memo adds one mode to the IANA registry for the TWAMP Modes
Field, and describes behavior when the new mode is used. This field
is a recognized extension mechanism for TWAMP.
10. Acknowledgments
The authors gratefully acknowledge reviews and contributions from
Peter McCann and Qinglei Qi.
11. References
11.1. Normative Reference
[I-D.morton-ippm-twamp-rate]
Morton, A. and L. Ciavattone, "TWAMP Burst Rate
Measurement Features", draft-morton-ippm-twamp-rate-02
(work in progress), September 2012.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
Sun, et al. Expires August 12, 2013 [Page 17]
Internet-Draft TWAMP Flow-based performance measurement February 2013
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, September 2006.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, October 2008.
[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement
Protocol (TWAMP) Reflect Octets and Symmetrical Size
Features", RFC 6038, October 2010.
11.2. Informative Reference
[I-D.sun-ippm-flowbased-pm]
Sun, L., Yu, F., and W. Wang, "Flow-based Performance
Measurement", draft-sun-ippm-flowbased-pm-00 (work in
progress), October 2012.
Authors' Addresses
Lishun Sun
Beijing University of Posts and Telecommunications
Xitucheng road 10
Haidian District, Beijing 100876
P. R. China
Email: lishunsun@Gmail.com
Sun, et al. Expires August 12, 2013 [Page 18]
Internet-Draft TWAMP Flow-based performance measurement February 2013
Fang Yu
Huawei Technologies
Huawei Building, Q20 No.156 Beiqing Rd.Z-park
Haidian District, Beijing 100095
P. R. China
Email: grace.yufang@huawei.com
Xiangyang Gong
Beijing University of Posts and Telecommunications
Xitucheng road 10
Haidian District, Beijing 100876
P. R. China
Email: xygong@bupt.edu.cn
Sun, et al. Expires August 12, 2013 [Page 19]
