Internet DRAFT - draft-sun-tsvwg-flowbased-pm
draft-sun-tsvwg-flowbased-pm
TSVWG Lishun. Sun
Internet-Draft Wendong. Wang
Intended status: Informational BUPT
Expires: December 31, 2012 Fang. Yu
Huawei Technologies
June 29, 2012
Flow-based Performance Measurement
draft-sun-tsvwg-flowbased-pm-00
Abstract
The performance measurements of service flow are becoming significant
important for administrators monitoring the fitness of the network.
This memo defines an end-to-end application-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.
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 December 31, 2012.
Copyright Notice
Copyright (c) 2012 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
Sun, et al. Expires December 31, 2012 [Page 1]
Internet-Draft Flow-based Performance Measurement June 2012
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3
2.1. Conventions Used in This Document . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Protocol overview . . . . . . . . . . . . . . . . . . . . 4
3.3. Logical Model . . . . . . . . . . . . . . . . . . . . . . 5
4. Measurement Process . . . . . . . . . . . . . . . . . . . . . 6
4.1. Connection Activation . . . . . . . . . . . . . . . . . . 6
4.2. Measurement Process . . . . . . . . . . . . . . . . . . . 8
4.3. Connection Deactivation . . . . . . . . . . . . . . . . . 10
5. Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Delay Calculation . . . . . . . . . . . . . . . . . . . . 11
5.2. Jitter Calculation . . . . . . . . . . . . . . . . . . . . 12
5.3. Loss Calculation . . . . . . . . . . . . . . . . . . . . . 12
6. Exception Handling . . . . . . . . . . . . . . . . . . . . . . 13
6.1. FM/BR Packet Loss . . . . . . . . . . . . . . . . . . . . 13
6.2. Packet Mis-ordering . . . . . . . . . . . . . . . . . . . 13
7. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative Reference . . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Sun, et al. Expires December 31, 2012 [Page 2]
Internet-Draft Flow-based Performance Measurement June 2012
1. Introduction
The IETF IP Performance Metrics (IPPM) working group has defined a
series of standard metrics that can be applied to the quality,
performance and reliability of Internet data delivery services.
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. The average performance indexes measured
by the active measurement method may not be suitable in these cases.
This memo proposes an IP performance measurement method which can
support on-the-spot measurement, that is, measurement is performed
online when service is running. This method is an end-to-end flow-
based method which can obtain measurement data simply and accurately.
It injects the OAM packets to the network which are used to carry
some parameters related to service flow and some statistic
information. The OAM packets are processed using the same method as
its corresponding service flow, so the measurements can reflect the
network status suffered by the service flow more accurately.
This IP performance measurement method can monitor the real time
change of service and reflect the running situation of actual IP
service. It can play an important role in the fault diagnosis and
statistics of the service in IP transmission network.
2. Conventions and Terminology
2.1. Conventions Used in This Document
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.2. Terminology
PM:performance monitoring
FM:Forward Monitoring
BR:Backward Reporting
3. Overview
Sun, et al. Expires December 31, 2012 [Page 3]
Internet-Draft Flow-based Performance Measurement June 2012
3.1. Motivation
It is required to provide a reasonable estimation measurement of
delay, jitter and packet loss in IP network (such as backhaul
network). The above parameters are functions of time, and are
stochastic in nature. Therefore, the mechanism is required to
provide statistical condition estimations of the IP link status.
Moreover, since measurement injects some OAM packets to the network,
it is necessary that the frequency of packet generation is kept at a
minimum. Moreover, these packets should not lead to an excessive
computational overload on the measure device. In other words, the
process of generation of these measurement packets should be simple
and must not overload the transport interface. The packets must be
small and infrequent so as not to cause unnecessary overload on the
network bandwidth or influence the service running on the network.
3.2. Protocol overview
Firstly we make some statement for this method. We define a
measurement method that can be used in some scene. The method
proposed here involves three steps#: connection activation#,
measurement process and connection deactivation.
Two types of logical entities are defined, the PM Initiator and the
PM Responder.
Firstly the PM Initiator sends a request to the PM Responder to set
up the PM connection activation. The PM Responder responds with an
ACK packet including some parameters based on the request. When the
PM Initiator receives the ACK, it will prepare for starting the
measurement process.
During the measurement process, the PM Initiator periodically
generates Forward Monitor (FM) packets with the source and
destination IP addresses, and other classification information (for
example DSCP class) of the service packets , which are sent to the PM
Responder. The generation and transmission of FM packets can be
periodical with a specific time interval, or a certain number of
traffic packets should be sent between two contiguous FM packets.
The PM Responder receives the FM packets and sends Backward
Reporting(BR)packets which is constructed according to the FM
packets.
The path performance such as the delay, jitter and loss rate etc. are
calculates by the PM Initiator according to the information in the BR
packets.
Sun, et al. Expires December 31, 2012 [Page 4]
Internet-Draft Flow-based Performance Measurement June 2012
The FM packets have the same source and destination IP addresses,
even the same DSCP class in some cases with the data packets. So
they are carried through the transport network just most like the
data packets, and delay, jitter and packet loss encountered by them
resembles the performance as seen by the packets of the actual
traffic flows. The FM and BR packets used in this method are small
enough to produce influence to actual service flow as little as
possible.
3.3. Logical Model
The role and definition of the logical entities and measurement
packets in this method are defined as follows.
This method is an end-to-end measurement, so two logical entities are
defined.
o PM Initiator: PM Initiator serves as the sending endpoint, and
charges for generating and sending the request to initiate a PM
connection. It could also send FM packets to collect measurement
data and generate statistical report.
o PM Responder: PM Responder serves as the receiving endpoint, and
charges for responding the request of initiating a link. It could
also send back a BR packet to the sending endpoint once it
receives the FM package from the PM Initiator.
One possible scenario of relationships between these roles is shown
below.
+---------------+ +----------------+
| |-------------------->| |
| PM Initiator |<--------------------| PM Responder |
+---------------+ +----------------+
Figure 1: One possible relationship between PM Initiator and PM
Responder
There are six types of packets in total, which include four types of
control packets and two types of measurement packets.
Note that a new port number is introduced to be assigned by the IANA.
The assigned port number is used as the destination port number of
the control packets and measurement packets#, and the source port
number can be random.
Control packet:
Sun, et al. Expires December 31, 2012 [Page 5]
Internet-Draft Flow-based Performance Measurement June 2012
o ACT: It is sent from the PM Initiator to a specific UDP port on PM
Responder, carries parameters used in negotiation process when
initiating a PM connection.
o ACT-ACK: It is a response for ACT sent by the PM Responder to the
PM Initiator.
o DEA: It is sent by the PM Initiator to the PM Responder for
disconnecting the PM connection.
o DEA-ACK: It is a response for DEA sent by the PM Responder to the
PM Initiator.
Measurement packet:
o FM (Forward Monitoring): It is sent by the PM Initiator. The
format of FM packet payload as defined by this document will be
shown blow. FM packet header is constructed in accordance with
the data packet except the destination port.
o BR (Backward Reporting): It is sent by the PM Responder. The
format of BR packet payload as defined by this document will be
shown blow. It is a response for FM.
4. Measurement Process
4.1. Connection Activation
In the PM connection activation process, both the PM Initiator and
the PM Responder are assigned a Flow ID for a defined flow (the Flow
ID is unique in a connection between the PM Initiator and the PM
Responder). It should specify how to define the Flow corresponding
to the measurement instance. 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.
Before starting the measurement, a connection should be established.
When the PM Initiator wants to start the measurement process, it
enables the measurement capabilities to the PM Responder by sending
ACT packet to the specific UDP port on the PM Responder. When the PM
Responder receives the ACT, it enables its measurement function and
responses to the Sender with ACT-ACK packet. The connection
activation process is finished after the PM Initiator receiving the
Sun, et al. Expires December 31, 2012 [Page 6]
Internet-Draft Flow-based Performance Measurement June 2012
ACT-ACK packet from the PM Responder, then the PM Initiator can send
FM packet after one cycle. The definition of flow, FlowID, and the
sending period of FM packets must be consulted by two ends during the
connection activation process.
The format of ACT packet is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Periods | FlowType | PT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SIP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DIP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sPort | dPort |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sFlowId | DSCP | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ver and Type existed in all packets in this memo indicate the version
and type of packet. Type in this packets MUST be 0X1 indicates that
this is an ACT packet.
Periods defined by PM Initiator indicates the sending period of FM
packets.
FlowType indicates how a flow is defined.0x0 in this filed is for
(SIP, DIP, PT, sPort, dPort), while 0x1 is for (SIP, DIP, PT, DSCP)
and 0x2 is for (SIP, DIP, PT). The other values are not defined.
PT is the protocol type value of the service flow needed to be
measured. It may be UDP, TCP, SCTP or other types.
SIP is the source IP address of the service flow, and DIP is the
destination IP address of the service flow. SPort and DPort which
are valid only when the flow is defined by (SIP, DIP, PT, sPort,
dPort) indicate source/destination port number of the ACT packets.
If the FlowType is not defined by (SIP, DIP, PT, sPort, dPort), this
filed is 0xFF.
sFlowId is the flow id defined by the PM Initiator.
DSCP is valid only when the flow is defined by (SIP, DIP, PT, DSCP).
It indicates the value of the DSCP filed in IP header of service
flow.
Sun, et al. Expires December 31, 2012 [Page 7]
Internet-Draft Flow-based Performance Measurement June 2012
Reserved is reserved for extensions in future and MUST be set to 0x0
currently.
The format of ACT-ACK packet is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Periods | dFlowId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sFlowId | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type of 0X2 indicates ACT-ACK.
dFlowId is copied from the sFlowId field of the ACT packets.
sFlowId is the flow id defined by the PM Responder.
4.2. Measurement Process
When the connection is established successfully, the PM Initiator
sends FM packets according to the given time-interval, and the PM
Responder responses by sending BR packets after receiving FM packets
from the PM Initiator. The destination port number in the FM packet
header must be set as the specific number.
The format of FM packet is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | SN | dFlowId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdTxPkt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdTxByte |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type of 0X3 indicates FM.
SN is the sequence number of the flow, which distinguishes the
Sun, et al. Expires December 31, 2012 [Page 8]
Internet-Draft Flow-based Performance Measurement June 2012
different FM packets and indicates the correspondence between FM
packets and BR packets. Each PM flow should maintain a set of
sequence numbers (SN).
dFlowId is the flow id of the PM Responder, which is copied from
sFlowId in ACT-ACK.
FwdTxPkt is the accumulation of the number of the packets sent by the
PM Initiator. FwdTxByte is the accumulation of the number of bytes
sent by the PM Initiator.In order to determine the value of the
fields of FwdTxPkt and FwdTxByte, the PM Initiator maintains two
counters, SPN and SBN, for each PM flow that is incremented every
time a traffic packet is sent.When the FM packets are to be sent, the
FwdTxPkt and FwdTxByte are set to the then value of the counters
respectively.
T1 is the timestamp when the PM Initiator sends FM packets. There is
no requirement for synchronization between the PM Initiator and the
PM Responder.
The format of BR packet is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | SN | dFlowId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdTxPkt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdTxByte |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdRxPkt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FwdRxByte |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type of 0X4 indicates BR.
SN is copied from the SN field of the corresponding FM packet.
Sun, et al. Expires December 31, 2012 [Page 9]
Internet-Draft Flow-based Performance Measurement June 2012
dFlowId is the flow id of the PM Initiator, which is copied from
sFlowId in ACT.
The FwdTxPkt and FwdTxByte are copied from the corresponding FM
packet. FwdRxPkt is the accumulation of the number of the packets
received by the PM Responder. FwdRxByte is the accumulation of the
number of bytes received by the PM Responder. In order to determine
the value of the fields of FwdRxPkt and FwdRxByte, the PM Responder
maintains two counters, RPN and RBN, for each PM flow that is
incremented every time a traffic packet is received. When the BR
packets are to be sent, the FwdRxPkt and FwdRxByte are set to the
then value of the counters respectively.
T1 is copied from the T1 field of the FM packets, T2 is the timestamp
when the PM Responder receives the FM packets, and T3 is the
timestamp when the PM Responder sends the BR packets.
When the PM Responder receives a FM packet, it copies the value of
FwdTxPkt, FwdTxByte and T1 in FM packet into the corresponding fields
of the BR packet, and sets the fields of T3, FwdRxPkt and FwdRxByte
and sends the BR packet.
Note that the PM Initiator 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 FM packets with the flow id of the logical path, collect the
corresponding BR packets, and maintain the collected statistical
values.
4.3. Connection Deactivation
When the PM Initiator wants to stop the measurement, it sends
Connection Deactivation request packet called DEA to the PM
Responder. The PM Responder sends DEA-ACK packets back to the PM
Initiator after it receives the DEA packets.
The format of DEA packet is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Reserved | dFlowId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type of 0X5 indicates DEA.
dFlowId is the flow id defined by the PM Responder, which is copied
Sun, et al. Expires December 31, 2012 [Page 10]
Internet-Draft Flow-based Performance Measurement June 2012
from sFlowId in ACT-ACK.
The format of DEA-ACK packet is defined as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Type | Reserved | dFlowId |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type of 0X6 indicates DEA-ACK.
dFlowId is the flow id defined by the PM Initiator, which is copied
from sFlowId in ACT. .
5. Statistics
5.1. Delay Calculation
In order to determine the delay sample for a given FM and BR packets,
we assume that the paths are symmetric; that is the delay would be
same for FM and BR packets. Therefore, the traffic delay is
calculated as:
(T4-T1)-(T3-T2)
Td = ---------------
2
Where td is the one-way delay for the dth BR received, t4 is the time
that the PM Initiator received the dth BR packet, t3 is the time that
the PM Initiator sent the dth FM packet. t2 is the time that the PM
Responder received dth FM packet, and t1 is the time that PM
Responder sent the dth BR packet(dth is a SN of a flow).
Let's assume that during the current reporting interval D, N BR
packets were received at the PM Initiator, the delay reported to the
network management entity is determined as
1 M+N-1
TD = --- * sum td
N d=M
Where TD is the delay metric reported corresponding to the interval D
to the network management entity.
Sun, et al. Expires December 31, 2012 [Page 11]
Internet-Draft Flow-based Performance Measurement June 2012
5.2. Jitter Calculation
Jitter is defined as the Packet Delay Variation, and is not
calculated for each arriving BR packet. Instead, td values are
considered over several seconds, and the associated jitter value is
calculated. Let's consider that N consecutive delay values were used
to determine the dth jitter value, jp as:
________________________
| 1 M+N-1 2
jp = |--- * sum ( TD - Td )
/\| N d=M
jp is the variance of delay
Note that hence calculated jitter value needs to be aggregated over
the reporting interval. Let's assume that during the current
reporting interval D, N such jitter calculations were made at the PM
Initiator, therefore the jitter reported to the network management
entity is determined as:
1 N
jD = --- * sum jp
N p=1
5.3. Loss Calculation
When the dth BR packet is received at the PM Initiator, the loss rate
plr based on the dth BR packet and (d-1)th BR packet is calculated
as:
(SPN(d)-SPN(d-1))-(RPN(d)-RPN(d-1))
plrd = -------------------------------------
SPN(d)-SPN(d-1)
(SPN(d)-SPN(d-1))indicates the number of service packets sent by the
PM Initiator during dth measurement, and (RPN(d)-RPN(d-1)) indicates
the actual number of service packets received by the PM Responder
during dth measurement.
The loss rate needs to be aggregated over the reporting interval.
Let's assume that N BR packets were received during the dth reporting
interval. Therefore, the packet loss rate for that interval can be
calculated as:
Sun, et al. Expires December 31, 2012 [Page 12]
Internet-Draft Flow-based Performance Measurement June 2012
1 N
PLRd = --- * sum plrd
N d=1
6. Exception Handling
6.1. FM/BR Packet Loss
In some cases the FM or BR packet may be lost in transit, then no
statistics can be obtained from this round of measurement. So the
loss rate of the mth measurement can be calculated as:
(SPN(m)-SPN(n))-(RPN(m)-RPN(d-n))
plrm = -------------------------------------
SPN(m)-SPN(n)
where m is the SN of the BR packet currently received and n is the SN
of the latest BR received.
6.2. Packet Mis-ordering
In the receive side if the received packets are out of order, the FM
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. Note that the
packet loss calculation is based on sample statistic, so the
occasional packet mis-ordering may make less impact on the packet
loss statistic. And the mis-ordering can be solved by some private
method which is out-of-scope of this document.
7. Use Case
This section describes a typical scene using the measurement method.
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 jitter.
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,
Sun, et al. Expires December 31, 2012 [Page 13]
Internet-Draft Flow-based Performance Measurement June 2012
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.
At the eNodeB, FM OAM packets are generated periodically with the
source and destination IP addresses, and DSCP class. At the S-GW,
after receiving the FM packets, BR packets are constructed. They are
then forwarded back to the eNodeB. Upon receiving the BR packets at
the logical port 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.
8. Security Considerations
To be defined.
9. IANA Considerations
The destination port number of the newly defined packets for
measurement needs to be assigned by the IANA.
10. Acknowledgments
The authors gratefully acknowledge reviews and contributions from
Peter McCann and Anthony Chan.
11. References
11.1. Normative Reference
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330,
May 1998.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
Sun, et al. Expires December 31, 2012 [Page 14]
Internet-Draft Flow-based Performance Measurement June 2012
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", September 2006.
Authors' Addresses
Lishun Sun
Beijing University of Posts and Telecommunications
Xitucheng road 10
Haidian District, Beijing 100876
P. R. China
Email: lishunsun@Gmail.com
Wendong Wang
Beijing University of Posts and Telecommunications
Xitucheng road 10
Haidian District, Beijing 100876
P. R. China
Email: wdwang@bupt.edu.cn
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
Sun, et al. Expires December 31, 2012 [Page 15]
