draft-ietf-ippm-alt-mark-01.txt   draft-ietf-ippm-alt-mark-02.txt 
Network Working Group G. Fioccola, Ed. Network Working Group G. Fioccola, Ed.
Internet-Draft A. Capello, Ed. Internet-Draft A. Capello, Ed.
Intended status: Experimental M. Cociglio Intended status: Experimental M. Cociglio
Expires: January 8, 2017 L. Castaldelli Expires: May 1, 2017 L. Castaldelli
Telecom Italia Telecom Italia
M. Chen, Ed. M. Chen, Ed.
L. Zheng, Ed. L. Zheng, Ed.
Huawei Technologies Huawei Technologies
G. Mirsky, Ed. G. Mirsky, Ed.
Ericsson Ericsson
T. Mizrahi, Ed. T. Mizrahi, Ed.
Marvell Marvell
July 7, 2016 October 28, 2016
Alternate Marking method for passive performance monitoring Alternate Marking method for passive performance monitoring
draft-ietf-ippm-alt-mark-01 draft-ietf-ippm-alt-mark-02
Abstract Abstract
This document describes a passive method to perform packet loss, This document describes a passive method to perform packet loss,
delay and jitter measurements on live traffic. This method is based delay and jitter measurements on live traffic. This method is based
on Alternate Marking (Coloring) technique. A report on the on Alternate Marking (Coloring) technique. A report on the
operational experiment done at Telecom Italia is explained in order operational experiment done at Telecom Italia is explained in order
to give an example and show the method applicability. This technique to give an example and show the method applicability. This technique
can be applied in various situations as detailed in this document. can be applied in various situations as detailed in this document.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 8, 2017. This Internet-Draft will expire on May 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of the method . . . . . . . . . . . . . . . . . . . 4 2. Overview of the method . . . . . . . . . . . . . . . . . . . 4
3. Detailed description of the method . . . . . . . . . . . . . 6 3. Detailed description of the method . . . . . . . . . . . . . 5
3.1. Packet loss measurement . . . . . . . . . . . . . . . . . 6 3.1. Packet loss measurement . . . . . . . . . . . . . . . . . 5
3.1.1. Timing aspects . . . . . . . . . . . . . . . . . . . 9
3.2. One-way delay measurement . . . . . . . . . . . . . . . . 10 3.2. One-way delay measurement . . . . . . . . . . . . . . . . 10
3.2.1. Single marking methodology . . . . . . . . . . . . . 10 3.2.1. Single marking methodology . . . . . . . . . . . . . 10
3.2.2. Average delay . . . . . . . . . . . . . . . . . . . . 11 3.2.2. Mean delay . . . . . . . . . . . . . . . . . . . . . 12
3.2.3. Double marking methodology . . . . . . . . . . . . . 12 3.2.3. Double marking methodology . . . . . . . . . . . . . 12
3.3. Delay variation measurement . . . . . . . . . . . . . . . 13 3.3. Delay variation measurement . . . . . . . . . . . . . . . 13
4. Considerations . . . . . . . . . . . . . . . . . . . . . . . 13 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Synchronization . . . . . . . . . . . . . . . . . . . . . 13 4.1. Synchronization . . . . . . . . . . . . . . . . . . . . . 14
4.2. Data Correlation . . . . . . . . . . . . . . . . . . . . 14 4.2. Data Correlation . . . . . . . . . . . . . . . . . . . . 14
4.3. Packet Re-ordering . . . . . . . . . . . . . . . . . . . 15 4.3. Packet Re-ordering . . . . . . . . . . . . . . . . . . . 15
5. Implementation and deployment . . . . . . . . . . . . . . . . 15 5. Implementation and deployment . . . . . . . . . . . . . . . . 16
5.1. Report on the operational experiment at Telecom Italia . 15 5.1. Report on the operational experiment at Telecom Italia . 16
5.1.1. Coloring the packets . . . . . . . . . . . . . . . . 17 5.1.1. Coloring the packets . . . . . . . . . . . . . . . . 18
5.1.2. Counting the packets . . . . . . . . . . . . . . . . 18 5.1.2. Counting the packets . . . . . . . . . . . . . . . . 19
5.1.3. Collecting data and calculating packet loss . . . . . 19 5.1.3. Collecting data and calculating packet loss . . . . . 20
5.1.4. Metric transparency . . . . . . . . . . . . . . . . . 20 5.1.4. Metric transparency . . . . . . . . . . . . . . . . . 20
5.2. IP flow performance measurement (IPFPM) . . . . . . . . . 20 5.2. IP flow performance measurement (IPFPM) . . . . . . . . . 21
5.3. Performance Measurement Marking Method in BIER Domain . . 20 5.3. Performance Measurement Marking Method in BIER Domain . . 21
5.4. Overlay OAM Passive Performance Measurement . . . . . . . 20 5.4. Overlay OAM Passive Performance Measurement . . . . . . . 21
5.5. RFC6374 Use Case . . . . . . . . . . . . . . . . . . . . 21 5.5. RFC6374 Use Case . . . . . . . . . . . . . . . . . . . . 21
5.6. Application to active performance measurement . . . . . . 21 5.6. Application to active performance measurement . . . . . . 22
6. Hybrid measurement . . . . . . . . . . . . . . . . . . . . . 21 6. Hybrid measurement . . . . . . . . . . . . . . . . . . . . . 22
7. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 21 7. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 25 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 25 12.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Nowadays, most of the traffic in Service Providers' networks carries Nowadays, most of the traffic in Service Providers' networks carries
real time content. These contents are highly sensitive to packet real time content. These contents are highly sensitive to packet
loss [RFC2680], while interactive contents are sensitive to delay loss [RFC2680], while interactive contents are sensitive to delay
[RFC2679], and jitter [RFC3393]. [RFC2679], and jitter [RFC3393].
In view of this scenario, Service Providers need methodologies and In view of this scenario, Service Providers need methodologies and
tools to monitor and measure network performances with an adequate tools to monitor and measure network performances with an adequate
accuracy, in order to constantly control the quality of experience accuracy, in order to constantly control the quality of experience
perceived by their customers. On the other hand, performance perceived by their customers. On the other hand, performance
monitoring provides useful information for improving network monitoring provides useful information for improving network
management (e.g. isolation of network problems, troubleshooting, management (e.g. isolation of network problems, troubleshooting,
etc.). etc.).
A lot of work related to OAM, that includes also performance A lot of work related to OAM, that includes also performance
monitoring techniques, has been done by Standards Developing monitoring techniques, has been done by Standards Developing
Organizations: [RFC7276] provides a good overview of existing OAM Organizations(SDOs):: [RFC7276] provides a good overview of existing
mechanisms defined in IETF, ITU-T and IEEE. Considering IETF, a lot OAM mechanisms defined in IETF, ITU-T and IEEE. Considering IETF, a
of work has been done on fault detection and connectivity lot of work has been done on fault detection and connectivity
verification, while a minor effort has been dedicated so far to verification, while a minor effort has been dedicated so far to
performance monitoring. The IPPM WG has defined standard metrics to performance monitoring. The IPPM WG has defined standard metrics to
measure network performance; however, the methods developed in the WG measure network performance; however, the methods developed in this
mainly refer to active measurement techniques. More recently, the WG mainly refer to focus on active measurement techniques. More
MPLS WG has defined mechanisms for measuring packet loss, one-way and recently, the MPLS WG has defined mechanisms for measuring packet
two-way delay, and delay variation in MPLS networks[RFC6374], but loss, one-way and two-way delay, and delay variation in MPLS
their applicability to passive measurements has some limitations, networks[RFC6374], but their applicability to passive measurements
especially for pure connection-less networks. has some limitations, especially for pure connection-less networks.
The lack of adequate tools to measure packet loss with the desired The lack of adequate tools to measure packet loss with the desired
accuracy drove an effort to design a new method for the performance accuracy drove an effort to design a new method for the performance
monitoring of live traffic, possibly easy to implement and deploy. monitoring of live traffic, possibly easy to implement and deploy.
The effort led to the method described in this document: basically, The effort led to the method described in this document: basically,
it is a passive performance monitoring technique, potentially it is a passive performance monitoring technique, potentially
applicable to any kind of packet based traffic, including Ethernet, applicable to any kind of packet based traffic, including Ethernet,
IP, and MPLS, both unicast and multicast. The method addresses IP, and MPLS, both unicast and multicast. The method addresses
primarily packet loss measurement, but it can be easily extended to primarily packet loss measurement, but it can be easily extended to
one-way delay and delay variation measurements as well. It doesn't one-way delay and delay variation measurements as well.
require any protocol extension or interaction with existing
protocols, thus avoiding any interoperability issue. Even if the
method doesn't raise any specific need for standardization, it 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 this document.
The method has been explicitly designed for passive measurements but The method has been explicitly designed for passive measurements but
it can also be used with active probes. Passive measurements are it can also be used with active probes. Passive measurements are
usually more easily understood by customers and provide a much better usually more easily understood by customers and provide a much better
accuracy, especially for packet loss measurements. accuracy, especially for packet loss measurements.
The method described in this document, also called PNPM (Packet
Network Performance Monitoring), has been invented and engineered in
Telecom Italia and it's currently being used in Telecom Italia's
network. The previous IETF drafts about this technique were:
[I-D.cociglio-mboned-multicast-pm] and [I-D.tempia-opsawg-p3m].
There are some references to this methodology in other IETF works
(e.g. [I-D.ietf-mpls-flow-ident], [I-D.bryant-mpls-sfl-framework]
[I-D.bryant-mpls-rfc6374-sfl], [I-D.ietf-bier-mpls-encapsulation],
[I-D.mirsky-bier-pmmm-oam]
[I-D.chen-ippm-coloring-based-ipfpm-framework]).
This document is organized as follows: This document is organized as follows:
o Section 2 gives an overview of the method, including a comparison o Section 2 gives an overview of the method, including a comparison
with different measurement strategies; with different measurement strategies;
o Section 3 describes the method in detail; o Section 3 describes the method in detail;
o Section 4 reports considerations about synchronization, data o Section 4 reports considerations about synchronization, data
correlation and packet re-ordering; correlation and packet re-ordering;
skipping to change at page 9, line 46 skipping to change at page 9, line 12
For example, looking at the table above, during the first block For example, looking at the table above, during the first block
(A-colored), C(A)R1 and C(A)R2 have the same value (375), which (A-colored), C(A)R1 and C(A)R2 have the same value (375), which
corresponds to the exact number of packets of the first block (no corresponds to the exact number of packets of the first block (no
loss). Also during the second block (B-colored) R1 and R2 counters loss). Also during the second block (B-colored) R1 and R2 counters
have the same value (388), which corresponds to the number of packets have the same value (388), which corresponds to the number of packets
of the second block (no loss). During blocks three and four, R1 and of the second block (no loss). During blocks three and four, R1 and
R2 counters are different, meaning that some packets have been lost: R2 counters are different, meaning that some packets have been lost:
in the example, one single packet (382-381) was lost during block in the example, one single packet (382-381) was lost during block
three and three packets (377-374) were lost during block four. three and three packets (377-374) were lost during block four.
R1 and R2 require a clock error less than +/-L/2 time units, where L
is the time duration of the block. In this way each colored packet
can be assigned to the right block by each router. This is because
the minimum time distance between two packets of the same color but
belonging to different blocks is L time units.
The method applied to R1 and R2 can be extended to any other router The method applied to R1 and R2 can be extended to any other router
and applied to more complex networks, as far as the measurement is and applied to more complex networks, as far as the measurement is
enabled on the path followed by the traffic flow(s) being observed. enabled on the path followed by the traffic flow(s) being observed.
3.1.1. Timing aspects
This document introduces two color switching method: one is based on
fixed number of packet, the other is based on fixed timer. But the
method based on fixed timer is preferable because is more
deterministic, and will be considered in the rest of the dcoument.
By considering the clock error between network devices R1 and R2,
they must be synchronized to the same clock reference with an
accuracy of +/- L/2 time units, where L is the time duration of the
block. So each colored packet can be assigned to the right batch by
each router. This is because the minimum time distance between two
packets of the same color but belonging to different batches is L
time units.
In practice, there are also out of order at batch boundaries,
strictly related to the delay between measurement points. This means
that, without considering clock error, we wait L/2 after color
switching to be sure to take a still counter.
In summary we need to take into account two contributions: clock
error between network devices and the interval we need to wait to
avoid out of order because of network delay.
The following figure eplains both issues.
...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB...
|<======================================>|
| L |
...=========>|<==================><==================>|<==========...
| L/2 L/2 |
|<===>| |<===>|
d | | d
|<==========================>|
available counting interval
Figure 4: Timing aspects
It is assumed that all network devices are synchronized to a common
reference time with an accuracy of +/- A/2. Thus, the difference
between the clock values of any two network devices is bounded by A.
The guardband d is given by:
d = A + D_max - D_min,
where A is the clock accuracy, D_max is an upper bound on the network
delay between the network devices, and D_min is a lower bound on the
delay.
The available counting interval is L - 2d that must be > 0.
The condition that must be satisfied and is a requirement on the
synchronization accuracy is:
d < L/2.
3.2. One-way delay measurement 3.2. One-way delay measurement
The same principle used to measure packet loss can be applied also to The same principle used to measure packet loss can be applied also to
one-way delay measurement. There are three alternatives, as one-way delay measurement. There are three alternatives, as
described hereinafter. described hereinafter.
3.2.1. Single marking methodology 3.2.1. Single marking methodology
The alternation of colors can be used as a time reference to The alternation of colors can be used as a time reference to
calculate the delay. Whenever the color changes (that means that a calculate the delay. Whenever the color changes (that means that a
new block has started) a network device can store the timestamp of new block has started) a network device can store the timestamp of
the first packet of the new block; that timestamp can be compared 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 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 packet delay. Considering Figure 2, R1 stores a timestamp TS(A1)R1
when it sends the first packet of block 1 (A-colored), a timestamp when it sends the first packet of block 1 (A-colored), a timestamp
TS(B2)R1 when it sends the first packet of block 2 (B-colored) and so TS(B2)R1 when it sends the first packet of block 2 (B-colored) and so
on for every other block. R2 performs the same operation on the on for every other block. R2 performs the same operation on the
receiving side, recording TS(A1)R2, TS(B2)R2 and so on. Since the receiving side, recording TS(A1)R2, TS(B2)R2 and so on. Since the
timestamps refer to specific packets (the first packet of each block) timestamps refer to specific packets (the first packet of each block)
we are sure that timestamps compared to compute delay refer to the 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 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 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 is between R1 and R2. In order to have more measurements, it is
possible to take and store more timestamps, referring to other possible to take and store more timestamps, referring to other
skipping to change at page 11, line 45 skipping to change at page 12, line 20
For the sake of simplicity, in the above example a single measurement For the sake of simplicity, in the above example a single measurement
is provided within a block, taking into account only the first packet is provided within a block, taking into account only the first packet
of each block. The number of measurements can be easily increased by of each block. The number of measurements can be easily increased by
considering multiple packets in the block: for instance, a timestamp considering multiple packets in the block: for instance, a timestamp
could be taken every N packets, thus generating multiple delay could be taken every N packets, thus generating multiple delay
measurements. Taking this to the limit, in principle the delay could measurements. Taking this to the limit, in principle the delay could
be measured for each packet, by taking and comparing the be measured for each packet, by taking and comparing the
corresponding timestamps (possible but impractical from an corresponding timestamps (possible but impractical from an
implementation point of view). implementation point of view).
3.2.2. Average delay 3.2.2. Mean delay
As mentioned before, the method previously exposed for measuring the As mentioned before, the method previously exposed for measuring the
delay is sensitive to out of order reception of packets. In order to delay is sensitive to out of order reception of packets. In order to
overcome this problem, a different approach has been considered: it overcome this problem, a different approach has been considered: it
is based on the concept of average delay. The average delay is is based on the concept of mean delay. The mean delay is calculated
calculated by considering the average arrival time of the packets by considering the average arrival time of the packets within a
within a single block. The network device locally stores a timestamp single block. The network device locally stores a timestamp for each
for each packet received within a single block: summing all the packet received within a single block: summing all the timestamps and
timestamps and dividing by the total number of packets received, the dividing by the total number of packets received, the average arrival
average arrival time for that block of packets can be calculated. By time for that block of packets can be calculated. By subtracting the
subtracting the average arrival times of two adjacent devices it is average arrival times of two adjacent devices it is possible to
possible to calculate the average delay between those nodes. This calculate the mean delay between those nodes. This method is robust
method is robust to out of order packets and also to packet loss to out of order packets and also to packet loss (only a small error
(only a small error is introduced). Moreover, it greatly reduces the is introduced). Moreover, it greatly reduces the number of
number of timestamps (only one per block for each network device) timestamps (only one per block for each network device) that have to
that have to be collected by the management system. On the other be collected by the management system. On the other hand, it only
hand, it only gives one measure for the duration of the block (f.i. 5 gives one measure for the duration of the block (f.i. 5 minutes), and
minutes), and it doesn't give the minimum, maximum and median delay it doesn't give the minimum, maximum and median delay values (RFC
values (RFC 6703 [RFC6703]). This limitation could be overcome by 6703 [RFC6703]). This limitation could be overcome by reducing the
reducing the duration of the block (f.i. from 5 minutes to a few duration of the block (f.i. from 5 minutes to a few seconds), that
seconds) by means of an highly optimized implementation of the implicates an highly optimized implementation of the method.
method.
By summing the average delays of the two directions of a path, it is By summing the mean delays of the two directions of a path, it is
also possible to measure the two-way delay (round-trip delay). also possible to measure the two-way delay (round-trip delay).
3.2.3. Double marking methodology 3.2.3. Double marking methodology
The Single marking methodology for one-way delay measurement is The Single marking methodology for one-way delay measurement is
sensitive to out of order reception of packets. The first approach sensitive to out of order reception of packets. The first approach
to overcome this problem is described before and is based on the to overcome this problem is described before and is based on the
concept of average delay. But the limitation of average delay is concept of mean delay. But the limitation of mean delay is that it
that it doesn't give information about the delay values distribution doesn't give information about the delay values distribution for the
for the duration of the block. Additionally it may be useful to have duration of the block. Additionally it may be useful to have not
not only the average delay but also the minimum and maximum delay only the mean delay but also the minimum and maximum delay values
values and, in wider terms, to know more about the statistic and, in wider terms, to know more about the statistic distribution of
distribution of delay values. So in order to have more information delay values. So in order to have more information about the delay
about the delay and to overcome out of order issues, a different and to overcome out of order issues, a different approach can be
approach can be introduced: it is based on double marking introduced: it is based on double marking methodology.
methodology.
Basically, the idea is to use the first marking to create the Basically, the idea is to use the first marking to create the
alternate flow and, within this colored flow, a second marking to alternate flow and, within this colored flow, a second marking to
select the packets for measuring delay/jitter. The first marking is select the packets for measuring delay/jitter. The first marking is
needed for packet loss and average delay measurement. The second needed for packet loss and mean delay measurement. The second
marking creates a new set of marked packets that are fully identified marking creates a new set of marked packets that are fully identified
over the network, so that a network device can store the timestamps over the network, so that a network device can store the timestamps
of these packets; these timestamps can be compared with the of these packets; these timestamps can be compared with the
timestamps of the same packets on a second router to compute packet timestamps of the same packets on a second router to compute packet
delay values for each packet. The number of measurements can be delay values for each packet. The number of measurements can be
easily increased by changing the frequency of the second marking. easily increased by changing the frequency of the second marking.
But the frequency of the second marking must be not too high in order But the frequency of the second marking must be not too high in order
to avoid out of order issues. Between packets with the second to avoid out of order issues. Between packets with the second
marking there should be a security time gap (e.g. this gap could be, marking there should be a security time gap (e.g. this gap could be,
at the minimum, the average network delay calculated with the at the minimum, the mean network delay calculated with the previous
previous methodology) to avoid out of order issues and also to have a methodology) to avoid out of order issues and also to have a number
number of measurement packets that is rate independent. If a second of measurement packets that is rate independent. If a second marking
marking packet is lost, the delay measurement for the considered packet is lost, the delay measurement for the considered block is
block is corrupted and should be discarded. corrupted and should be discarded.
3.3. Delay variation measurement 3.3. Delay variation measurement
Similarly to one-way delay measurement (both for single marking and Similarly to one-way delay measurement (both for single marking and
double marking), the method can also be used to measure the inter- double marking), the method can also be used to measure the inter-
arrival jitter. The alternation of colors can be used as a time arrival jitter. We refer to the definition in RFC 3393 [RFC3393].
reference to measure delay variations. Considering the example The alternation of colors, for single marking method, can be used as
depicted in Figure 4, R1 stores a timestamp TS(A)R1 whenever it sends a time reference to measure delay variations. In case of double
the first packet of a block and R2 stores a timestamp TS(B)R2 marking, the time reference is given by the second marked packets.
whenever it receives the first packet of a block. The inter-arrival Considering the example depicted in Figure 2, R1 stores a timestamp
jitter can be easily derived from one-way delay measurement, by TS(A)R1 whenever it sends the first packet of a block and R2 stores a
evaluating the delay variation of consecutive samples. 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, by evaluating the delay variation of consecutive
samples.
The concept of average delay can also be applied to delay variation, The concept of mean delay can also be applied to delay variation, by
by evaluating the variation of average interval between consecutive evaluating the average variation of the interval between consecutive
packets of the flow from R1 to R2. packets of the flow from R1 to R2.
4. Considerations 4. Considerations
This section highlights some considerations about the methodology. This section highlights some considerations about the methodology.
4.1. Synchronization 4.1. Synchronization
There are two mechanisms in Alternate Marking technique that require The Alternate Marking technique does not require a strong
network devices to have synchronized clocks: packet loss and one-way synchronization, especially for packet loss and two-way delay
delay measurement. measurement. Only one-way delay measurement requires network devices
to have synchronized clocks.
The color switching is the reference for all the network devices, and
the only requirement to be achieved is that all network devices have
to recognize the right batch along the path.
If the length of the measurement period is L time units, then all If the length of the measurement period is L time units, then all
network devices must be synchronized to the same clock reference with network devices must be synchronized to the same clock reference with
an accuracy of +/- L/2 time units. This level of accuracy guarantees an accuracy of +/- L/2 time units (without considering network
that all network devices consistently match the color bit to the delay). This level of accuracy guarantees that all network devices
correct block. For example, if the color is toggeled every second (L consistently match the color bit to the correct block. For example,
= 1 second), then clocks must be synchronized with an accuracy of +/- if the color is toggeled every second (L = 1 second), then clocks
0.5 second to a common time reference. must be synchronized with an accuracy of +/- 0.5 second to a common
time reference.
The synchronization requirement can be satisfied even with a This synchronization requirement can be satisfied even with a
relatively inaccurate synchronization method. relatively inaccurate synchronization method. This is true for
packet loss and two-way delay measurement, instead, for one-way delay
measurement clock synchronization must be accurate.
Notably, two-way delay measurement does not require the network Therefore, a system that uses only packet loss and two-way delay
devices to be time synchronized. Therefore, a system that uses only measurement does not require synchronization. This is because the
two-way delay measurement does not require synchronization. This is value of the clocks of network devices does not affect the
because the value of the clocks of network devices does not affect computation of the two-way delay measurement.
the computation of the two-way delay measurement, and synchronization
is not required.
4.2. Data Correlation 4.2. Data Correlation
Data Correlation could be performed in several ways depending on the Data Correlation is the mechanism to compare counters and timestamps
the alternate marking application and use case. for packet loss, delay and delay variation calculation. It could be
performed in several ways depending on the alternate marking
application and use case.
o A possibility is to use a centralized solution using Network o A possibility is to use a centralized solution using Network
Management System (NMS) to correlate data; Management System (NMS) to correlate data;
o Another possibility is to define a protocol based distributed o Another possibility is to define a protocol based distributed
solution, by defining a new protocol or by extending the existing solution, by defining a new protocol or by extending the existing
protocols (e.g. RFC6374, TWAMP, OWAMP) in order to communicate protocols (e.g. RFC6374, TWAMP, OWAMP) in order to communicate
the counters and timestamps between nodes. the counters and timestamps between nodes.
In the following paragraphs an example data correlation mechanism is In the following paragraphs an example data correlation mechanism is
skipping to change at page 15, line 17 skipping to change at page 15, line 50
Due to ECMP, packet re-ordering is very common in IP network. The Due to ECMP, packet re-ordering is very common in IP network. The
accuracy of marking based PM, especially packet loss measurement, may accuracy of marking based PM, especially packet loss measurement, may
be affected by packet re-ordering. Take a look at the following be affected by packet re-ordering. Take a look at the following
example: example:
Block : 1 | 2 | 3 | 4 | 5 |... Block : 1 | 2 | 3 | 4 | 5 |...
--------|---------|---------|---------|---------|---------|--- --------|---------|---------|---------|---------|---------|---
Node R1 : AAAAAAA | BBBBBBB | AAAAAAA | BBBBBBB | AAAAAAA |... Node R1 : AAAAAAA | BBBBBBB | AAAAAAA | BBBBBBB | AAAAAAA |...
Node R2 : AAAAABB | AABBBBA | AAABAAA | BBBBBBA | ABAAABA |... Node R2 : AAAAABB | AABBBBA | AAABAAA | BBBBBBA | ABAAABA |...
Figure 4: Packet Reordering Figure 5: Packet Reordering
In the following paragraphs an example data correlation mechanism is In the following paragraphs an example of data correlation mechanism
explained and could be use independently of the adopted solutions. is explained and could be use independently of the adopted solutions.
Most of the packet re-ordering occur at the edge of adjacent blocks, Most of the packet re-ordering occur at the edge of adjacent blocks,
and they are easy to handle if the interval of each block is and they are easy to handle if the interval of each block is
sufficient large. Then, it can assume that the packets with sufficient large. Then, it can assume that the packets with
different marker belong to the block that they are more close to. If different marker belong to the block that they are more close to. If
the interval is small, it is difficult and sometime impossible to the interval is small, it is difficult and sometime impossible to
determine to which block a packet belongs. See above example, the determine to which block a packet belongs. See above example, the
packet with the marker of "B" in block 3, there is no safe way to packet with the marker of "B" in block 3, there is no safe way to
tell whether the packet belongs to block 2 or block 4. tell whether the packet belongs to block 2 or block 4.
skipping to change at page 15, line 50 skipping to change at page 16, line 36
used in many cases for performance measurement. The only requirement used in many cases for performance measurement. The only requirement
is to select and mark the flow to be monitored; in this way packets is to select and mark the flow to be monitored; in this way packets
are batched by the sender and each batch is alternately marked such are batched by the sender and each batch is alternately marked such
that can be easily recognized by the receiver. that can be easily recognized by the receiver.
An example of implementation and deployment is explained in the next An example of implementation and deployment is explained in the next
section, just to clarify how the method can work. section, just to clarify how the method can work.
5.1. Report on the operational experiment at Telecom Italia 5.1. Report on the operational experiment at Telecom Italia
The methodology has been applied in Telecom Italia by leveraging The method described in this document, also called PNPM (Packet
functions and tools available on IP routers and it's currently being Network Performance Monitoring), has been invented and engineered in
used to monitor packet loss in some portions of Telecom Italia's Telecom Italia and it's currently being used in Telecom Italia's
network. The application of the method to delay measurement is network. The methodology has been applied by leveraging functions
currently being evaluated in Telecom Italia's labs. This section and tools available on IP routers and it's currently being used to
describes how the features currently available on existing routing monitor packet loss in some portions of Telecom Italia's network.
platforms can be used to apply the method, in order to give an The application of the method to delay measurement is currently being
example of implementation and deployment. evaluated in Telecom Italia's labs. This section describes how the
features currently available on existing routing platforms can be
used to apply the method, in order to give an example of
implementation and deployment.
The fundamental steps for this implementation of the method can be The fundamental steps for this implementation of the method can be
summarized in the following items: summarized in the following items:
o coloring the packets; o coloring the packets;
o counting the packets; o counting the packets;
o collecting data and calculating the packet loss. o collecting data and calculating the packet loss.
o metric transparency. o metric transparency.
Before going deeper into the implementation details, it's worth Before going deeper into the implementation details, it's worth
mentioning two different strategies that can be used when mentioning two different strategies that can be used when
implementing the method: implementing the method:
skipping to change at page 20, line 37 skipping to change at page 21, line 27
5.2. IP flow performance measurement (IPFPM) 5.2. IP flow performance measurement (IPFPM)
This application of marking method is described in This application of marking method is described in
[I-D.chen-ippm-coloring-based-ipfpm-framework]. [I-D.chen-ippm-coloring-based-ipfpm-framework].
5.3. Performance Measurement Marking Method in BIER Domain 5.3. Performance Measurement Marking Method in BIER Domain
In [I-D.ietf-bier-mpls-encapsulation] two OAM bits from Bit Index In [I-D.ietf-bier-mpls-encapsulation] two OAM bits from Bit Index
Explicit Replication (BIER) Header are reserved for the passive Explicit Replication (BIER) Header are reserved for the passive
performance measurement marking method. [I-D.mirsky-bier-pmmm-oam] performance measurement marking method. [I-D.ietf-bier-pmmm-oam]
details the measurement for multicast service over BIER domain. details the measurement for multicast service over BIER domain.
5.4. Overlay OAM Passive Performance Measurement 5.4. Overlay OAM Passive Performance Measurement
The Overlay OAM Design Team is considering the preliminary OAM The Overlay OAM Design Team is considering the preliminary OAM
requirements from NVO3, BIER, and SFC. Marking Method is the requirements from NVO3, BIER, and SFC. Marking Method is the
preferred passive method to measure performance. preferred passive method to measure performance.
[I-D.ooamdt-rtgwg-ooam-requirement] and [I-D.ooamdt-rtgwg-ooam-requirement] and
[I-D.ooamdt-rtgwg-oam-gap-analysis] explain in deep this item. [I-D.ooamdt-rtgwg-oam-gap-analysis] explain in deep this item.
skipping to change at page 21, line 20 skipping to change at page 22, line 7
certain situations. [I-D.ietf-mpls-flow-ident] discusses the desired certain situations. [I-D.ietf-mpls-flow-ident] discusses the desired
capabilities for MPLS flow identification in order to perform a capabilities for MPLS flow identification in order to perform a
better in-band performance monitoring of user data packets. A method better in-band performance monitoring of user data packets. A method
of accomplishing identification is Synonymous Flow Labels (SFL) of accomplishing identification is Synonymous Flow Labels (SFL)
introduced in [I-D.bryant-mpls-sfl-framework], while introduced in [I-D.bryant-mpls-sfl-framework], while
[I-D.bryant-mpls-rfc6374-sfl] describes RFC6374 performance [I-D.bryant-mpls-rfc6374-sfl] describes RFC6374 performance
measurements with SFL. measurements with SFL.
5.6. Application to active performance measurement 5.6. Application to active performance measurement
[I-D.fioccola-ippm-rfc6812-alt-mark-ext] describes an extension to [I-D.fioccola-ippm-alt-mark-active] describes how to extend the
the Cisco SLA Protocol Measurement-Type UDP-Measurement, in order to existing Active Measurement Protocol, in order to implement alternate
implement alternate marking methodology. marking methodology. [I-D.fioccola-ippm-rfc6812-alt-mark-ext]
describes an extension to the Cisco SLA Protocol Measurement-Type
UDP-Measurement.
6. Hybrid measurement 6. Hybrid measurement
The method has been explicitly designed for passive measurements but The method has been explicitly designed for passive measurements but
it can also be used with active measurements. In order to have both it can also be used with active measurements. In order to have both
end to end measurements and intermediate measurements (hybrid end to end measurements and intermediate measurements (hybrid
measurements) two end points can exchanges artificial traffic flows measurements) two end points can exchanges artificial traffic flows
and apply alternate marking over these flows. In the intermediate and apply alternate marking over these flows. In the intermediate
points artificial traffic is managed in the same way as real traffic points artificial traffic is managed in the same way as real traffic
and measured as specified before. and measured as specified before. So the application of marking
method can simplify also the active measurement, as explained in
[I-D.fioccola-ippm-alt-mark-active].
7. Compliance with RFC6390 guidelines 7. Compliance with RFC6390 guidelines
RFC6390 [RFC6390] defines a framework and a process for developing RFC6390 [RFC6390] defines a framework and a process for developing
Performance Metrics for protocols above and below the IP layer (such Performance Metrics for protocols above and below the IP layer (such
as IP-based applications that operate over reliable or datagram as IP-based applications that operate over reliable or datagram
transport protocols). transport protocols).
This document doesn't aim to propose a new Performance Metric but a This document doesn't aim to propose a new Performance Metric but a
new method of measurement for a few Performance Metrics that have new method of measurement for a few Performance Metrics that have
skipping to change at page 25, line 5 skipping to change at page 25, line 42
o potential applicability to any kind of packet/frame -based o potential applicability to any kind of packet/frame -based
traffic: Ethernet, IP, MPLS, etc., both unicast and multicast; traffic: Ethernet, IP, MPLS, etc., both unicast and multicast;
o robustness: the method can tolerate out of order packets and it's o robustness: the method can tolerate out of order packets and it's
not based on "special" packets whose loss could have a negative not based on "special" packets whose loss could have a negative
impact; impact;
o no interoperability issues: the features required to implement the o no interoperability issues: the features required to implement the
method are available on all current routing platforms. method are available on all current routing platforms.
The method doesn't raise any specific need for standardization, but The method doesn't raise any specific need for protocol extension,
it could be further improved by means of some extension to existing but it could be further improved by means of some extension to
protocols. Specifically, the use of DiffServ bits for coloring the existing protocols. Specifically, the use of DiffServ bits for
packets could not be a viable solution in some cases: a standard coloring the packets could not be a viable solution in some cases: a
method to color the packets for this specific application could be standard method to color the packets for this specific application
beneficial. could be beneficial.
10. IANA Considerations 10. IANA Considerations
There are no IANA actions required. There are no IANA actions required.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Domenico Laforgia, Daniele Accetta The previous IETF drafts about this technique were:
and Mario Bianchetti for their contribution to the definition and the [I-D.cociglio-mboned-multicast-pm] and [I-D.tempia-opsawg-p3m].
implementation of the method. There are some references to this methodology in other IETF works
(e.g. [I-D.ietf-mpls-flow-ident], [I-D.bryant-mpls-sfl-framework]
[I-D.bryant-mpls-rfc6374-sfl], [I-D.ietf-bier-mpls-encapsulation],
[I-D.ietf-bier-pmmm-oam]
[I-D.chen-ippm-coloring-based-ipfpm-framework]).
In addition 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.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679,
September 1999, <http://www.rfc-editor.org/info/rfc2679>. September 1999, <http://www.rfc-editor.org/info/rfc2679>.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
skipping to change at page 25, line 45 skipping to change at page 26, line 46
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393, Metric for IP Performance Metrics (IPPM)", RFC 3393,
DOI 10.17487/RFC3393, November 2002, DOI 10.17487/RFC3393, November 2002,
<http://www.rfc-editor.org/info/rfc3393>. <http://www.rfc-editor.org/info/rfc3393>.
12.2. Informative References 12.2. Informative References
[I-D.bryant-mpls-rfc6374-sfl] [I-D.bryant-mpls-rfc6374-sfl]
Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen, Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen,
M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft- M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft-
bryant-mpls-rfc6374-sfl-00 (work in progress), October bryant-mpls-rfc6374-sfl-01 (work in progress), August
2015. 2016.
[I-D.bryant-mpls-sfl-framework] [I-D.bryant-mpls-sfl-framework]
Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen, Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S.,
M., and Z. Li, "Synonymous Flow Label Framework", draft- and G. Mirsky, "Synonymous Flow Label Framework", draft-
bryant-mpls-sfl-framework-01 (work in progress), June bryant-mpls-sfl-framework-02 (work in progress), October
2016. 2016.
[I-D.chen-ippm-coloring-based-ipfpm-framework] [I-D.chen-ippm-coloring-based-ipfpm-framework]
Chen, M., Zheng, L., Mirsky, G., Fioccola, G., and T. Chen, M., Zheng, L., Mirsky, G., Fioccola, G., and T.
Mizrahi, "IP Flow Performance Measurement Framework", Mizrahi, "IP Flow Performance Measurement Framework",
draft-chen-ippm-coloring-based-ipfpm-framework-06 (work in draft-chen-ippm-coloring-based-ipfpm-framework-06 (work in
progress), March 2016. progress), March 2016.
[I-D.cociglio-mboned-multicast-pm] [I-D.cociglio-mboned-multicast-pm]
Cociglio, M., Capello, A., Bonda, A., and L. Castaldelli, Cociglio, M., Capello, A., Bonda, A., and L. Castaldelli,
"A method for IP multicast performance monitoring", draft- "A method for IP multicast performance monitoring", draft-
cociglio-mboned-multicast-pm-01 (work in progress), cociglio-mboned-multicast-pm-01 (work in progress),
October 2010. October 2010.
[I-D.fioccola-ippm-alt-mark-active]
Fioccola, G., Clemm, A., Cociglio, M., Chandramouli, M.,
and A. Capello, "Alternate Marking Extension to Active
Measurement Protocol", draft-fioccola-ippm-alt-mark-
active-00 (work in progress), July 2016.
[I-D.fioccola-ippm-rfc6812-alt-mark-ext] [I-D.fioccola-ippm-rfc6812-alt-mark-ext]
Fioccola, G., Clemm, A., Cociglio, M., Chandramouli, M., Fioccola, G., Clemm, A., Cociglio, M., Chandramouli, M.,
and A. Capello, "Alternate Marking Extension to Cisco SLA and A. Capello, "Alternate Marking Extension to Cisco SLA
Protocol RFC6812", draft-fioccola-ippm-rfc6812-alt-mark- Protocol RFC6812", draft-fioccola-ippm-rfc6812-alt-mark-
ext-01 (work in progress), March 2016. ext-01 (work in progress), March 2016.
[I-D.ietf-bier-mpls-encapsulation] [I-D.ietf-bier-mpls-encapsulation]
Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J.,
S. Aldrin, "Encapsulation for Bit Index Explicit Aldrin, S., and I. Meilik, "Encapsulation for Bit Index
Replication in MPLS Networks", draft-ietf-bier-mpls- Explicit Replication in MPLS Networks", draft-ietf-bier-
encapsulation-04 (work in progress), April 2016. mpls-encapsulation-05 (work in progress), July 2016.
[I-D.ietf-mpls-flow-ident]
Bryant, S., Pignataro, C., Chen, M., Li, Z., and G.
Mirsky, "MPLS Flow Identification Considerations", draft-
ietf-mpls-flow-ident-01 (work in progress), June 2016.
[I-D.mirsky-bier-pmmm-oam] [I-D.ietf-bier-pmmm-oam]
Mirsky, G., Zheng, L., Chen, M., and G. Fioccola, Mirsky, G., Zheng, L., Chen, M., and G. Fioccola,
"Performance Measurement (PM) with Marking Method in Bit "Performance Measurement (PM) with Marking Method in Bit
Index Explicit Replication (BIER) Layer", draft-mirsky- Index Explicit Replication (BIER) Layer", draft-ietf-bier-
bier-pmmm-oam-01 (work in progress), March 2016. pmmm-oam-00 (work in progress), July 2016.
[I-D.ietf-mpls-flow-ident]
Bryant, S., Chen, M., Li, Z., Pignataro, C., and G.
Mirsky, "MPLS Flow Identification Considerations", draft-
ietf-mpls-flow-ident-02 (work in progress), August 2016.
[I-D.ooamdt-rtgwg-oam-gap-analysis] [I-D.ooamdt-rtgwg-oam-gap-analysis]
Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N., Kumar, Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N., Kumar,
D., Chen, M., Mozes, D., and J. Networks, "Operations, D., Chen, M., Yizhou, L., Mozes, D., Networks, J., and I.
Administration and Maintenance (OAM) for Overlay Networks: Bagdonas, "Operations, Administration and Maintenance
Gap Analysis", draft-ooamdt-rtgwg-oam-gap-analysis-01 (OAM) for Overlay Networks: Gap Analysis", draft-ooamdt-
(work in progress), March 2016. rtgwg-oam-gap-analysis-02 (work in progress), July 2016.
[I-D.ooamdt-rtgwg-ooam-requirement] [I-D.ooamdt-rtgwg-ooam-requirement]
Kumar, N., Pignataro, C., Kumar, D., Mirsky, G., Chen, M., Kumar, N., Pignataro, C., Kumar, D., Mirsky, G., Chen, M.,
Nordmark, E., Networks, J., and D. Mozes, "Overlay OAM Nordmark, E., Networks, J., and D. Mozes, "Overlay OAM
Requirements", draft-ooamdt-rtgwg-ooam-requirement-00 Requirements", draft-ooamdt-rtgwg-ooam-requirement-01
(work in progress), March 2016. (work in progress), July 2016.
[I-D.tempia-opsawg-p3m] [I-D.tempia-opsawg-p3m]
Capello, A., Cociglio, M., Castaldelli, L., and A. Bonda, Capello, A., Cociglio, M., Castaldelli, L., and A. Bonda,
"A packet based method for passive performance "A packet based method for passive performance
monitoring", draft-tempia-opsawg-p3m-04 (work in monitoring", draft-tempia-opsawg-p3m-04 (work in
progress), February 2014. progress), February 2014.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011, DOI 10.17487/RFC6374, September 2011,
 End of changes. 47 change blocks. 
173 lines changed or deleted 237 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/