One document matched: draft-tempia-opsawg-p3m-02.txt
Differences from draft-tempia-opsawg-p3m-01.txt
Opsawg A. Tempia Bonda
Internet-Draft A. Capello
Intended status: Experimental M. Cociglio
Expires: January 17, 2013 L. Castaldelli
Telecom Italia
July 16, 2012
A packet based method for passive performance monitoring
draft-tempia-opsawg-p3m-02.txt
Abstract
This document describes a method to achieve performance measurements
of live traffic, applicable to any packet based traffic stream,
including L2, L3, MPLS traffic, unicast and multicast. The method
can be easily implemented using tools and features already available
on existing routing platforms without any protocol extension and, for
this reason, it does not raise any interoperability issue. However,
the method could be further improved by means of some extension to
existing protocols, but this aspect is left for further study and it
is out of the scope of the document.
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 January 17, 2013.
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
Tempia Bonda, et al. Expires January 17, 2013 [Page 1]
Internet-Draft Method for passive performance monitoring July 2012
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
2. Overview of the method . . . . . . . . . . . . . . . . . . . . 4
3. Detailed description of the method . . . . . . . . . . . . . . 6
3.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. One-way Delay . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Delay variation . . . . . . . . . . . . . . . . . . . . . 11
4. Implementation strategies . . . . . . . . . . . . . . . . . . 12
4.1. Flow-based performance monitoring . . . . . . . . . . . . 12
4.2. Link-based performance monitoring . . . . . . . . . . . . 12
5. Implementation hints . . . . . . . . . . . . . . . . . . . . . 13
5.1. Traffic colouring . . . . . . . . . . . . . . . . . . . . 13
5.2. Packet counting . . . . . . . . . . . . . . . . . . . . . 13
5.3. Data collection . . . . . . . . . . . . . . . . . . . . . 13
6. Deployment considerations . . . . . . . . . . . . . . . . . . 15
6.1. Flow Identification . . . . . . . . . . . . . . . . . . . 15
6.2. Flow Colouring . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Monitoring Nodes . . . . . . . . . . . . . . . . . . . . . 16
6.4. Management System . . . . . . . . . . . . . . . . . . . . 17
6.5. Scalability . . . . . . . . . . . . . . . . . . . . . . . 17
6.6. Interoperability . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Tempia Bonda, et al. Expires January 17, 2013 [Page 2]
Internet-Draft Method for passive performance monitoring July 2012
1. Introduction
The increasing deployment in Service Providers' networks of
applications highly sensitive to packet loss [RFC2680], delay
[RFC2679], and jitter [RFC3393]demands for mechanisms able to monitor
and measure network performances.
Service Level Agreements (SLA) verification asks Service Providers to
be able to measure the quality of experience perceived by customers
and the performance of the network in light of the agreed
requirements. On the other hand, performance monitoring provides
useful information on the network itself, simplifying the
troubleshooting and the isolation of network problems.
This document describes a method to achieve accurate performance
monitoring of live traffic. The method can be applied to any kind of
packet based traffic, including Ethernet, IP, and MPLS, both unicast
and multicast. It doesn't require any protocol extension or
interaction with existing protocols, thus avoiding any
interoperability issue.
The method has been explicitly designed for passive measurements but
can also be used with active probes. Passive measurements are
usually more easily understood by customers and give Service
Providers more insights into network behaviour.
There is a lot of work related to OAM and
[I-D.ietf-opsawg-oam-overview] provides a good overview of existing
OAM mechanisms defined in IETF, ITU-T and IEEE. In IETF, in
particular, a lot of work has been done on fault detection and
connectivity verification, while a minor effort has been dedicated so
far to performance monitoring. IPPM WG has defined standard metrics
to measure network performance; however, the methods developed in the
WG refer to active measurement techniques. More recently, the MPLS
WG has defined mechanisms for measuring packet loss, one-way and two-
way delay, and delay variation in MPLS networks[RFC6374].
Tempia Bonda, et al. Expires January 17, 2013 [Page 3]
Internet-Draft Method for passive performance monitoring July 2012
2. Overview of the method
The method addresses primarily packet loss measurement, but it can be
easily extended to one-way delay and delay variation measurements as
well.
In order to perform packet loss measurements of a live traffic flow
it is possible to follow several approaches. The most intuitive one
consists in numbering the packets so that each router receiving the
flow can immediately detect a missing packet. Such approach, though
very simple in theory, is not simple to achieve: it requires to
insert a sequence number in each packet and to have an equipment able
to extract the number and check it in real time. A similar task can
be difficult to implement on live traffic: if UDP is used as the
transport protocol, the sequence number is not available; on the
other hand, if a higher layer sequence number (e.g. in the RTP
header) is used, extracting the information from the RTP header of
each packet and process it in real time could overload the equipment.
An alternative approach is to count the number of packets sent on one
end, the number of packets received on the other end, and to compare
the two values. This operation is much simpler to implement than
numbering each packet, but requires a kind of synchronization between
the devices performing the measurement: in order to compare two
counters it is required that they refer exactly to the same set of
packets. Since a flow is continuous and cannot be stopped when a
counter has to be read, it could be difficult to determine exactly
when to read the counter. A possible solution to overcome this
problem is to virtually split the flow in consecutive blocks by
inserting periodically a delimiter so that each counter refers
exactly to the same block of packets. The delimiter could be f.i. a
special packet inserted into the flow.
Compared to numbering the packets, the second approach is easier to
implement; however, delimiting the flow using specific packets can
have some limitations. First it requires to generate additional
packets within the flow and requires the equipment to be able to
process those packets. In addition, the method is vulnerable to
delimiting packets losses: if a delimiting packet is lost, the
contiguous blocks are affected and the related measurement is wrong.
The method proposed in this document follows the second approach
described, but doesn't use additional packets to virtually split the
flow in blocks. Instead, it "colours" the packets so that packets
belonging to different consecutive blocks will have different
colours. Each network device manages a packet counter for each block
and by comparing the values of counters at different network devices
it is possible to measure packet loss. Each colour change represents
Tempia Bonda, et al. Expires January 17, 2013 [Page 4]
Internet-Draft Method for passive performance monitoring July 2012
a sort of auto-synchronization mechanism that guarantees the
consistency of measurements (the value of the counters) taken by
different devices along the path.
The advantages of the method are:
o easy implementation: it can be implemented using features already
available on major routing platforms;
o low computational effort;
o accurate packet loss measurement (single packet loss granularity);
o applicability to any kind of traffic (Ethernet, IP, MPLS, unicast,
multicast);
o no interoperability issues.
Figure 1 represents a very simple network and shows how the method
can be used to measure packet loss on different network segments: by
enabling the measurement on several interfaces along the path, it is
possible to perform link monitoring, node monitoring or end-to-end
monitoring. The method is flexible enough to measure packet loss on
any segment of the network.
Traffic flow
========================================================>
+------+ +------+ +------+ +------+
---<> R1 <>-----<> R2 <>-----<> R3 <>-----<> R4 <>---
+------+ +------+ +------+ +------+
. . . . . .
. . . . . .
. <------> <-------> .
. Node Packet Loss Link Packet Loss .
. .
<--------------------------------------------------->
End-to-End Packet loss
Figure 1: Available measurements
Tempia Bonda, et al. Expires January 17, 2013 [Page 5]
Internet-Draft Method for passive performance monitoring July 2012
3. Detailed description of the method
This section describes in detail how the method can be used to
achieve performance monitoring of live traffic in a packet-switched
network.
3.1. Packet Loss
The basic idea is to virtually split traffic flows into consecutive
blocks; each block represents a measurable entity unambiguously
recognizable by all network devices along the path. By counting the
number of packets in each block and comparing the values measured by
different network devices along the path, it is possible to measure
packet loss occurred in any single block between any two points.
The following figure shows how blocks are created by inserting
delimiters into the flow.
| | | | |
| | Traffic flow | |
========|===========|===========|===========|===========|==========>
... | Block 5 | Block 4 | Block 3 | Block 2 | Block 1
| | | | |
Figure 2: Traffic delimitation points
A simple way to create the blocks is to "colour" the traffic (two
colours are sufficient) so that packets belonging to different
consecutive blocks will have different colours. Whenever the colour
changes the previous block terminates and the new one begins. Hence
all the packets belonging to the same block will have the same colour
and packets of different consecutive blocks will have different
colours. The number of packets in each block depends on the
criterion used to create the blocks: if the colour is switched after
a fixed number of packets, then each block will contain the same
number of packets (except for any losses); but if the colour is
switched according to a fixed timer, then the number of packets may
be different in each block depending on the packet rate.
The following figure shows how a flow looks like when it is split in
traffic blocks with coloured packets.
Tempia Bonda, et al. Expires January 17, 2013 [Page 6]
Internet-Draft Method for passive performance monitoring July 2012
A: packet with A colouring
B: packet with B colouring
| | | | |
| | Traffic flow | |
------------------------------------------------------------------->
BBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA
------------------------------------------------------------------->
... | Block 5 | Block 4 | Block 3 | Block 2 | Block 1
| | | | |
Figure 3: Traffic colouring
Figure 4 shows how the method can be used to measure link packet loss
between two adjacent nodes.
Referring to the figure, let's assume we want to monitor the packet
loss on the link between two routers: router R1 and router R2.
According to the method here described, traffic is coloured
alternatively with two different colours, A and B. Whenever the
colour changes, the transition generates a sort of square-wave
signal, as depicted in the following figure.
Colour A ----------+ +-----------+ +----------
| | | |
Colour B +-----------+ +-----------+
Block n ... Block 3 Block 2 Block 1
<---------> <---------> <---------> <---------> <--------->
Traffic flow
===========================================================>
Colour ... AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA...
===========================================================>
Figure 4: Application of the method to compute link packet loss
Traffic colouring could be done by R1 itself or by an upward router.
R1 needs two counters, C(A)R1 and C(B)R1, on its egress interface in
order to count the packets sent out of the interface and coloured
respectively with colour A and B. As long as traffic is coloured A,
only counter C(A)R1 will be incremented while C(B)R1 is still;
viceversa, when the traffic is coloured as B, only C(B)R1 is
incremented while C(A)R1 is still. C(A)R1 and C(B)R1 can be used as
reference values to determine the packet loss from R1 to any other
measurement point down the path. Router R2, similarly, will need two
counters on its ingress interface, C(A)R2 and C(B)R2, to count the
Tempia Bonda, et al. Expires January 17, 2013 [Page 7]
Internet-Draft Method for passive performance monitoring July 2012
packets received on that interface and coloured with colour A and B
respectively. When an A block terminates it is possible to compare
C(A)R1 and C(A)R2 and calculate the packet loss within the block;
similarly, when the successive B block terminates, it is possible to
compare C(B)R1 with C(B)R2, and so on for every successive block.
Likewise, by using two counters on R2 egress interface it is possible
to count the packets sent out of R2 interface and use them as
reference values to calculate the packet loss from R2 to any
measurement point down R2.
Using a fixed timer for colour switching offers a better control over
the method: the (time) length of the blocks can be chosen large
enough to simplify the collection and the comparison of measures
taken by different network devices. It's preferable to start the
comparison between the counters not immediately after the colour
switch: some packets could arrive out of order and increment the
counter associated to the previous block (colour), so it is worth
waiting for few seconds. The drawback is that the longer the
duration of the block, the less frequent the measurement can be
taken, but usually performance monitoring doesn't need to be
performed at very high rates.
The method doesn't require any synchronization in the network, as the
traffic flow implicitly carries the synchronization in the
alternation of colours. In addition, splitting the flow into blocks,
the method is able not only to detect any packet loss, but also to
provide information about when the packet loss has occurred and in
which point of the network.
The following table shows how the counters can be used to calculate
the packet loss between R1 and R2. The first column lists the
sequence of traffic blocks while the other columns contain the
counters of A-coloured packets and B-coloured packets for R1 and R2.
In this example, we assume that the values of the counters are reset
to zero whenever a block ends and its associated counter has been
read: with this assumption, the table shows only relative values,
that is the exact number of packets of each colour within each block.
If the values of the counters were not reset, the table would contain
cumulative values, but the relative values could be determined simply
by difference from the value of the previous block of the same
colour.
The colour is switched on the basis of a fixed timer (not shown in
the table), so the number of packets in each block is different.
Tempia Bonda, et al. Expires January 17, 2013 [Page 8]
Internet-Draft Method for passive performance monitoring July 2012
+-------+--------+--------+--------+--------+------+
| Block | C(A)R1 | C(B)R1 | C(A)R2 | C(B)R2 | Loss |
+-------+--------+--------+--------+--------+------+
| 1 | 375 | 0 | 375 | 0 | 0 |
| | | | | | |
| 2 | 0 | 388 | 0 | 388 | 0 |
| | | | | | |
| 3 | 382 | 0 | 381 | 0 | 1 |
| | | | | | |
| 4 | 0 | 377 | 0 | 374 | 3 |
| | | | | | |
| ... | ... | ... | ... | ... | ... |
| | | | | | |
| n | 0 | 387 | 0 | 387 | 0 |
| | | | | | |
| n+1 | 379 | 0 | 377 | 0 | 2 |
+-------+--------+--------+--------+--------+------+
Table 1: Evaluation of counters for packet loss measurements
During an A block (blocks 1, 3 and n+1), all the packets are
A-coloured, therefore C(A) counters indicate the number of packets of
that block, while C(B) counters are zero. Viceversa, during a B
block (blocks 2, 4 and n), all the packets are B-coloured: C(A)
counters are zero, while C(B) counters indicate the number of packets
of that block.
When a block terminates (because the colouring has switched to the
other colour) the relative counters stop incrementing and it is
possible to read them, compare the values measured on router R1 and
R2 and calculate the packet loss within that block.
For example, looking at the table above, during the first block
(A-coloured) C(A)R1 and C(A)R2 have the same value (375), which
corresponds to the exact number of packets of the first block. Also
during the second block (B-coloured) R1 and R2 counters have the same
value (388), which corresponds to the number of packets of the second
block. During blocks three and four, R1 and R2 counters are
different, meaning that some packets have been lost: in the example,
one single packet (382-381) was lost during block three and three
packets (377-374) were lost during block four.
The method here described for R1 and R2 can be extended to any router
and applied to more complex networks, as far as the measurement is
enabled on the path followed by the traffic flow(s) being analyzed.
Tempia Bonda, et al. Expires January 17, 2013 [Page 9]
Internet-Draft Method for passive performance monitoring July 2012
3.2. One-way Delay
The principle used to measure packet loss can be applied to one-way
delay measurement as well because the alternations of colours can be
used as time references to calculate the delay (again a sort of auto
synchronization). Whenever the colour changes (that means that a new
block has started) a network device can store the timestamp of the
first packet of the new block; that timestamp can be compared with
the timestamp of the same packet on a second router to compute packet
delay. Considering Figure 4, R1 stores a timestamp TS(A1)R1 when it
sends the first packet of block 1 (A-coloured), a timestamp TS(B2)R1
when it sends the first packet of block 2 (B-coloured) and so on for
every other block. R2 performs the same operation, recording
TS(A1)R2, TS(B2)R2 and so on. Since timestamps refer to specific
packets (the first packet of each block) we are sure that timestamps
compared to compute delay refer to the same packets. By comparing
TS(A1)R1 with TS(A1)R2 (and similarly TS(B2)R1 with TS(B2)R2 and so
on) it is possible to measure the delay between R1 and R2. In order
to have more measurements it may also be possible to take more
timestamps, not only referring to the first packet of each block, but
also its subsequent packets. How timestamps are recorded when a
particular packet is sent or received depends on the implementation
and is out of the scope of this document.
In order to coherently compare timestamps collected on different
routers, synchronization is required in the network. Furthermore, a
measurement is valid only if no packet loss occurs and if packet
misordering can be avoided, otherwise the first packet of a block on
R1 could be different from the first packet of the same block on R2
(f.i. if that packet is lost between R1 and R2 or it arrives after
the next one).
The following table shows how timestamps can be used to calculate the
delay between R1 and R2. The first column lists the sequence of
traffic blocks while other columns contain the timestamp referring to
the first packet of each block on R1 and R2. Delay is computed as a
difference between timestamps. For sake of simplicity hours, minutes
and seconds are omitted from timestamps and all the values are
expressed in milliseconds.
Tempia Bonda, et al. Expires January 17, 2013 [Page 10]
Internet-Draft Method for passive performance monitoring July 2012
+-------+---------+---------+---------+---------+-------------+
| Block | TS(A)R1 | TS(B)R1 | TS(A)R2 | TS(B)R2 | Delay R1-R2 |
+-------+---------+---------+---------+---------+-------------+
| 1 | 12.483 | - | 15.591 | - | 3.108 |
| | | | | | |
| 2 | - | 6.263 | - | 9.288 | 3.025 |
| | | | | | |
| 3 | 27.556 | - | 30.512 | - | 2.956 |
| | | | | | |
| | - | 18.113 | - | 21.269 | 3.156 |
| | | | | | |
| ... | ... | ... | ... | ... | ... |
| | | | | | |
| n | 77.463 | - | 80.501 | - | 3.038 |
| | | | | | |
| n+1 | - | 24.333 | - | 27.433 | 3.100 |
+-------+---------+---------+---------+---------+-------------+
Table 2: Evaluation of timestamps for delay measurements
The first row shows timestamps (in milliseconds) taken on R1 and R2
respectively and referring to the first packet of block 1 (which is
A-coloured). Delay can be computed as a difference between the
timestamp on R1 and the timestamp on R2. Similarly, the second row
shows timestamps (in milliseconds) taken on R1 and R2 and referring
to the first packet of block 2 (which is B-coloured). Comparing
timestamps taken on different nodes in the network and referring to
the same packets (identified using the alternation of colours) it is
possible to measure delay on different network segments.
3.3. Delay variation
Similarly to one-way delay measurement, the method can be used to
measure the inter-arrival jitter. The alternation of colours can be
used as a time reference to record timestamps and measure delay
variations. Considering the example depicted in Figure 4, R1 stores
a timestamp TS(A)R1 whenever it sends the first packet of a block and
R2 stores a timestamp TS(B)R2 whenever it receives the first packet
of a block. The inter-arrival jitter can be easily derived from one-
way delay measurement. For example, it is possible to evaluate the
jitter calculating the delay variation on two consecutive samples.
Tempia Bonda, et al. Expires January 17, 2013 [Page 11]
Internet-Draft Method for passive performance monitoring July 2012
4. Implementation strategies
The methodology described in the previous sections can be applied to
different scenarios adopting different strategies. Specifically, it
can be used in two basic ways:
o flow-based: performance measurement is applied to specific flows
for service monitoring purpose and can be end-to-end;
o link-based: performance measurement is applied to a particular
link (physical or logical) and monitors all the flows of the link.
4.1. Flow-based performance monitoring
The flow-based strategy is used when only a limited number of traffic
flows need to be monitored. This could be the case, for example, of
IPTV channels or other specific applications traffic with high QoS
requirements.
According to this strategy, only a subset of the flows is coloured.
Counters for packet loss measurements can be instantiated for each
single flow, or for the set as a whole, depending on the desired
granularity.
A relevant problem with this approach is the necessity to know in
advance the path followed by flows that are subject to measurement.
Path rerouting and traffic load-balancing increase the issue
complexity, especially for unicast traffic. The problem is easier to
solve for multicast traffic where load balancing is seldom used,
especially for IPTV traffic where static joins are frequently used to
force traffic forwarding and replication.
4.2. Link-based performance monitoring
The link-based strategy is similar to performance monitoring tools
usually used in transport networks, where the goal is to monitor the
network behaviour as a whole, without distinguishing among different
services.
Measurements are performed on all the traffic on a link. The link
could be a physical link or a logical link (for instance an Ethernet
VLAN or a MPLS PW). Counters could be instantiated for the traffic
as a whole or for each traffic class (in case it is desired to
monitor each class separately), but in the second case a couple of
counters is needed for each class.
Tempia Bonda, et al. Expires January 17, 2013 [Page 12]
Internet-Draft Method for passive performance monitoring July 2012
5. Implementation hints
This section describes, as an example, a practical implementation of
the method using basic features already available on major routing
platforms.
5.1. Traffic colouring
Traffic colouring can be implemented by setting a specific bit in the
packet header and changing the value of that bit periodically. With
current implementations, only QoS related fields and features offer
flexibility in setting bits and configuring policies. For example,
in case a Service Provider only uses the three most significant bits
of the DSCP field (corresponding to IP Precedence) for QoS
classification and queuing, it is possible to use the two less
significant bits of the DSCP field (bit 0 and bit 1) to implement the
method without affecting QoS policies. One of the two bits (bit 0)
could be used to identify flows subject to traffic monitoring (and
therefore it is always set to 1 on these flows), while the other (bit
1) would be used for colouring the traffic (switching between values
0 and 1) and creating the blocks.
In practice, colouring traffic using the DSCP field can be
implemented easily by configuring on the router interface an access
list that intercepts the flow(s) to be monitored (or all the traffic,
according to the link-based approach) and a policy that sets the DSCP
field accordingly. Since traffic colouring must change over time, it
is necessary to modify the policy periodically: an automatic script
could easily perform this task.
5.2. Packet counting
If traffic is coloured using the DSCP field, an access list that
matches specific DSCP values can be used to count the packets of the
flow being monitored. The access list can also be configured to
match different flow properties (such as source or destination
address) besides the DSCP value, hence monitoring just a subset of
the coloured traffic. An important feature of this approach, in
fact, is that colouring and counting are two decoupled operations: it
is possible to colour all the traffic, but monitor just one or few
flows.
5.3. Data collection
In order to properly elaborate packet counters it is necessary to
correlate values coming from different nodes. If we cannot use any
specific protocol to exchange this information among routers, it is
possible to use an external system. Its task is to collect data
Tempia Bonda, et al. Expires January 17, 2013 [Page 13]
Internet-Draft Method for passive performance monitoring July 2012
(counter values) from the network and do correlations to calculate
packet loss. This operation can be done for instance by transferring
data to the external system via FTP/TFTP or by reading the related
MIBs (if available) via SNMP.
Tempia Bonda, et al. Expires January 17, 2013 [Page 14]
Internet-Draft Method for passive performance monitoring July 2012
6. Deployment considerations
This section describes some aspects that should be taken into account
when the method is deployed in a real network.
6.1. Flow Identification
In the previous section it was outlined that flow-based measurements
require the identification of the flow to be monitored and the
discovery of the path followed by the selected flow. It is possible
to monitor a single flow or multiple flows grouped together, but in
this case measurement is consistent only if all the flows in the
group follow the same path. Moreover, a Service Provider should be
aware that, if a measurement is performed by grouping many flows, it
is not possible to determine exactly which flow was affected by
packets loss. In order to have measures per single flow it is
necessary to configure counters for each specific flow.
Once the flow(s) to be monitored have been identified, it is
necessary to configure the monitoring on the proper nodes.
Configuring the monitoring means configuring the policy to intercept
the traffic and configuring the counters to count the packets. To
have just an end-to-end monitoring, it is sufficient to enable the
monitoring on the first and the last hop routers of the path: the
mechanism is completely transparent to intermediate nodes and
independent from the path followed by traffic flows. On the
contrary, to monitor the flow on a hop-by-hop basis along its whole
path it is necessary to enable the monitoring on every node from the
source to the destination. In case the exact path followed by the
flow is not known a priori (i.e. the flow has multiple paths to reach
the destination) it is necessary to enable the monitoring system on
every path: counters on interfaces traversed by the flow will report
packet count, counters on other interfaces will be null.
In case the link-based strategy is used, flow identification is not
necessary because all the traffic has to be coloured and measured.
6.2. Flow Colouring
In both strategies, flow-based and link-based, the fundamental
operation is to colour the flow in order to create packet blocks.
This implies choosing where to activate the colouring and how to
colour the packets.
In case of flow-based measurements, it is desirable, in general, to
have a single colouring node because it is easier to manage and
doesn't rise any risk of conflict (consider the case where two nodes
colour the same flow). Thus it is necessary to colour the flow as
Tempia Bonda, et al. Expires January 17, 2013 [Page 15]
Internet-Draft Method for passive performance monitoring July 2012
close as possible to the source. In addition, colouring a flow close
to the source allows an end-to-end measure if a measurement point is
enabled on the last-hop router as well. The only requirement is that
the colouring must change periodically and every node along the path
must be able to identify unambiguously the coloured packets.
For link-based measurements, all traffic needs to be coloured when
transmitted on the link. If the traffic had already been coloured,
then it has to be re-coloured because the colour must be consistent
on the link. This means that each hop along the path must
(re-)colour the traffic; the colour is not required to be consistent
along different links.
6.3. Monitoring Nodes
In the previous section it was outlined that, in case of flow-based
measurement, the operation of colouring the packets to be monitored
can be accomplished by a single node. All the intermediate nodes are
not required to perform any particular operation except counting the
coloured packets that they receive and forward: this operation can be
enabled on every router along the path or only on a subset, depending
on which network segment is being monitored (a single link, a
particular metro area, the backbone, the whole path).
Since colours change periodically between two values, two counters
(one for each value) are needed for a single flow being monitored:
one counter for packets with colour A and one counter for packets
with colour B.
In case of link-based measurements the behaviour is similar except
that colouring and counting operations are performed on a link by
link basis at each endpoint of the link.
Another important aspect to take into consideration is when to read
counters: in order to count the exact number of packets of a block
the routers must perform this operation when a block has terminated.
The task can be performed in two ways. The most general approach
suggests to read counters periodically, many times during a block,
and to compare successive readings: when the counter stops
incrementing means that the relative block has finished and its value
can be elaborated. Alternatively, if colouring is performed on the
basis of a fixed timer, it is possible to configure the reading of
the counters according to that timer (f.i. if each block is 5 minutes
long it is possible to read counters every 5 minute in the middle of
the subsequent block to overcome eventual time shifts from the router
that colours the traffic). A sufficient margin should be considered
between the end of a block and the reading of the counter, in order
to take into account any out-of-order packets.
Tempia Bonda, et al. Expires January 17, 2013 [Page 16]
Internet-Draft Method for passive performance monitoring July 2012
6.4. Management System
Nodes enabled to perform performance monitoring collect the value of
the counters, but they are not able to directly use this information
to measure packet loss, because they only have local information and
lack a global view of the network. For this reason, an external
Network Management System (NMS) is required to collect and elaborate
data and to perform packet loss calculation. The NMS compares the
values of counters from different nodes and can calculate if some
packets were lost (even a single packet) and also where packets were
lost.
Information collected by the routers (counter values) needs to be
transferred to the NMS periodically. This can be accomplished f.i.
via FTP or TFTP and can be done in Push Mode or Polling Mode. In the
first case, each router periodically sends the information to the
NMS, in the latter case it is the NMS that periodically polls routers
to collect information.
If link-based measurement is used, it would be possible to use a
protocol to exchange values of counters between the two endpoints in
order to let them perform the packet loss calculation for each
traffic direction. A similar approach could be complicated if
applied to a flow-based measurement.
6.5. Scalability
The colouring can be easily performed on a single flow as well as on
the entire traffic. Regarding the counting, what is needed are two
counters for each flow (or group of flows) being monitored and for
every interface where the monitoring system is activated. For
example, in order to monitor separately 3 flows on a router with 4
interfaces involved, 24 counters are needed (2 counters for each of
the 3 flows on each of the 4 interfaces).
6.6. Interoperability
The method described in this document doesn't raise any
interoperability issue, since it doesn't require any new protocol or
any kind of interaction among nodes. Traffic colouring can be
performed by a single node, while the counting of packets is done
locally by each router, and the correlation between counters can be
done by an external NMS which collects and correlates the data coming
from the network.
The only requirement is that every node should be able to identify
coloured flows, but, as explained in Section 5, this can be
accomplished by using simple functionalities that doesn't have any
Tempia Bonda, et al. Expires January 17, 2013 [Page 17]
Internet-Draft Method for passive performance monitoring July 2012
interoperability issue and are already available on major routing
platforms.
Tempia Bonda, et al. Expires January 17, 2013 [Page 18]
Internet-Draft Method for passive performance monitoring July 2012
7. Security Considerations
This document specifies a method to perform measurements in the
context of a Service Provider's network and has not been developed to
conduct Internet measurements, so it does not directly affect
Internet security nor applications which run on the Internet.
However, implementation of this method must be mindful of security
and privacy concerns.
There are two types of security concerns: potential harm caused by
the measurements and potential harm to the measurements. For what
concerns the first point, the measurements described in this document
are passive, so there are no packets injected into the network
causing potential harm to the network itself and to data traffic.
Nevertheless, the method implies modifications on the fly to the IP
header of data packets: this must be performed in a way that doesn't
alter the quality of service experienced by packets subject to
measurements and that preserve stability and performance of routers
doing the measurements. The measurements themselves could be harmed
by routers altering the colouring of the packets, or by an attacker
injecting artificial traffic. Authentication techniques, such as
digital signatures, may be used where appropriate to guard against
injected traffic attacks.
The privacy concerns of network measurement are limited because the
method only relies on information contained in the IP header without
any release of user data.
Tempia Bonda, et al. Expires January 17, 2013 [Page 19]
Internet-Draft Method for passive performance monitoring July 2012
8. IANA Considerations
There are no IANA actions required.
Tempia Bonda, et al. Expires January 17, 2013 [Page 20]
Internet-Draft Method for passive performance monitoring July 2012
9. Acknowledgements
The authors would like to thank Domenico Laforgia, Daniele Accetta
and Mario Bianchetti for their contribution to the definition and the
implementation of the method.
Tempia Bonda, et al. Expires January 17, 2013 [Page 21]
Internet-Draft Method for passive performance monitoring July 2012
10. References
10.1. Normative References
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Packet Loss Metric for IPPM", RFC 2680, September 1999.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002.
10.2. Informative References
[I-D.ietf-opsawg-oam-overview]
Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Mechanisms",
draft-ietf-opsawg-oam-overview-06 (work in progress),
March 2012.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, September 2011.
Tempia Bonda, et al. Expires January 17, 2013 [Page 22]
Internet-Draft Method for passive performance monitoring July 2012
Authors' Addresses
Alberto Tempia Bonda
Telecom Italia
Via Reiss Romoli, 274
Torino 10148
Italy
Email: alberto.tempiabonda@telecomitalia.it
Alessandro Capello
Telecom Italia
Via Reiss Romoli, 274
Torino 10148
Italy
Email: alessandro.capello@telecomitalia.it
Mauro Cociglio
Telecom Italia
Via Reiss Romoli, 274
Torino 10148
Italy
Email: mauro.cociglio@telecomitalia.it
Luca Castaldelli
Telecom Italia
Via Reiss Romoli, 274
Torino 10148
Italy
Email: luca.castaldelli@telecomitalia.it
Tempia Bonda, et al. Expires January 17, 2013 [Page 23]
| PAFTECH AB 2003-2026 | 2026-04-23 15:13:55 |