draft-ietf-ippm-alt-mark-04.txt   draft-ietf-ippm-alt-mark-05.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: September 2, 2017 L. Castaldelli Expires: December 28, 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.
ZTE ZTE
T. Mizrahi, Ed. T. Mizrahi, Ed.
Marvell Marvell
March 1, 2017 June 26, 2017
Alternate Marking method for passive performance monitoring Alternate Marking method for passive and hybrid performance monitoring
draft-ietf-ippm-alt-mark-04 draft-ietf-ippm-alt-mark-05
Abstract Abstract
This document describes a passive method to perform packet loss, This document describes a method to perform packet loss, delay and
delay and jitter measurements on live traffic. This method is based jitter measurements on live traffic. This method is based on
on Alternate Marking (Coloring) technique. A report on the Alternate Marking (Coloring) technique. A report on the operational
operational experiment done at Telecom Italia is explained in order experiment done at Telecom Italia is explained in order to give an
to give an example and show the method applicability. This technique example and show the method applicability. This technique can be
can be applied in various situations as detailed in this document. applied in various situations as detailed in this document and could
be considered passive or hybrid depending on the application.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 2, 2017. This Internet-Draft will expire on December 28, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 . . . . . . . . . . . . . 5 3. Detailed description of the method . . . . . . . . . . . . . 6
3.1. Packet loss measurement . . . . . . . . . . . . . . . . . 5 3.1. Packet loss measurement . . . . . . . . . . . . . . . . . 6
3.1.1. Timing aspects . . . . . . . . . . . . . . . . . . . 9 3.2. Timing aspects . . . . . . . . . . . . . . . . . . . . . 10
3.2. One-way delay measurement . . . . . . . . . . . . . . . . 10 3.3. One-way delay measurement . . . . . . . . . . . . . . . . 11
3.2.1. Single marking methodology . . . . . . . . . . . . . 10 3.3.1. Single marking methodology . . . . . . . . . . . . . 11
3.2.2. Double marking methodology . . . . . . . . . . . . . 12 3.3.2. Double marking methodology . . . . . . . . . . . . . 13
3.3. Delay variation measurement . . . . . . . . . . . . . . . 14 3.4. Delay variation measurement . . . . . . . . . . . . . . . 14
4. Considerations . . . . . . . . . . . . . . . . . . . . . . . 14 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Synchronization . . . . . . . . . . . . . . . . . . . . . 14 4.1. Synchronization . . . . . . . . . . . . . . . . . . . . . 15
4.2. Data Correlation . . . . . . . . . . . . . . . . . . . . 15 4.2. Data Correlation . . . . . . . . . . . . . . . . . . . . 15
4.3. Packet Re-ordering . . . . . . . . . . . . . . . . . . . 16 4.3. Packet Re-ordering . . . . . . . . . . . . . . . . . . . 16
5. Implementation and deployment . . . . . . . . . . . . . . . . 16 5. Implementation and deployment . . . . . . . . . . . . . . . . 17
5.1. Report on the operational experiment at Telecom Italia . 17 5.1. Report on the operational experiment at Telecom Italia . 17
5.1.1. Coloring the packets . . . . . . . . . . . . . . . . 18 5.1.1. Coloring the packets . . . . . . . . . . . . . . . . 19
5.1.2. Counting the packets . . . . . . . . . . . . . . . . 19 5.1.2. Counting the packets . . . . . . . . . . . . . . . . 20
5.1.3. Collecting data and calculating packet loss . . . . . 20 5.1.3. Collecting data and calculating packet loss . . . . . 21
5.1.4. Metric transparency . . . . . . . . . . . . . . . . . 21 5.1.4. Metric transparency . . . . . . . . . . . . . . . . . 22
5.2. IP flow performance measurement (IPFPM) . . . . . . . . . 21 5.2. IP flow performance measurement (IPFPM) . . . . . . . . . 22
5.3. Performance Measurement Marking Method in BIER Domain . . 21 5.3. OAM Passive Performance Measurement . . . . . . . . . . . 22
5.4. Overlay OAM Passive Performance Measurement . . . . . . . 21 5.4. RFC6374 Use Case . . . . . . . . . . . . . . . . . . . . 22
5.5. RFC6374 Use Case . . . . . . . . . . . . . . . . . . . . 22 5.5. Application to active performance measurement . . . . . . 23
5.6. Application to active performance measurement . . . . . . 22 6. Hybrid measurement . . . . . . . . . . . . . . . . . . . . . 23
6. Hybrid measurement . . . . . . . . . . . . . . . . . . . . . 22 7. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 23
7. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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 contents that are highly sensitive to packet loss [RFC2680], 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(SDOs):: [RFC7276] provides a good overview of existing Organizations(SDOs): [RFC7276] provides a good overview of existing
OAM mechanisms defined in IETF, ITU-T and IEEE. Considering IETF, a OAM mechanisms defined in IETF, ITU-T and IEEE. Considering IETF, a
lot 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 this measure network performance; however, the methods developed in this
WG mainly refer to focus on active measurement techniques. More WG mainly refer to focus on active measurement techniques. More
recently, the MPLS WG has defined mechanisms for measuring packet recently, the MPLS WG has defined mechanisms for measuring packet
loss, one-way and two-way delay, and delay variation in MPLS loss, one-way and two-way delay, and delay variation in MPLS
networks[RFC6374], but their applicability to passive measurements networks[RFC6374], but their applicability to passive measurements
has some limitations, especially for pure connection-less networks. has some limitations, especially for pure connection-less networks.
skipping to change at page 4, line 5 skipping to change at page 3, line 50
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. one-way delay and delay variation measurements as well.
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.
RFC 7799 [RFC7799] defines passive and hybrid methods of measurement.
In particular, Passive Methods of Measurement are based solely on
observations of an undisturbed and unmodified packet stream of
interest; Hybrid Methods are Methods of Measurement that use a
combination of Active Methods and Passive Methods.
Taking into consideration these definitions, Alternate Marking Method
could be considered Hybrid or Passive depending on the case. In case
the marking field is obtained by changing existing field values of
the packets (e.g. DSCP field), the technique is Hybrid. In case the
marking field is dedicated, reserved and is included in the protocol
specification Alternate Marking technique can be considered as
Passive (e.g. RFC6374 Synonymous Flow Label or OAM Marking Bits in
BIER Header).
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;
o Section 5 reports examples of implementation and deployment of the o Section 5 reports examples of implementation and deployment of the
method. Furthermore the operational experiment done at Telecom method. Furthermore the operational experiment done at Telecom
Italia is described; Italia is described;
o Section 6 introduces Hybrid measurement aspects;
o Section 7 is about the Compliance with RFC6390 guidelines;
o Section 8 includes some security aspects; o Section 8 includes some security aspects;
o Section 9 finally summarizes some concluding remarks. o Section 9 finally summarizes some concluding remarks.
2. Overview of the method 2. Overview of the method
In order to perform packet loss measurements on a live traffic flow, In order to perform packet loss measurements on a live traffic flow,
different approaches exist. The most intuitive one consists in different approaches exist. The most intuitive one consists in
numbering the packets, so that each router that receives the flow can numbering the packets, so that each router that receives the flow can
immediately detect a packet missing. This approach, though very immediately detect a packet missing. This approach, though very
skipping to change at page 8, line 33 skipping to change at page 9, line 18
| 1 | 375 | 0 | 375 | 0 | 0 | | 1 | 375 | 0 | 375 | 0 | 0 |
| | | | | | | | | | | | | |
| 2 | 0 | 388 | 0 | 388 | 0 | | 2 | 0 | 388 | 0 | 388 | 0 |
| | | | | | | | | | | | | |
| 3 | 382 | 0 | 381 | 0 | 1 | | 3 | 382 | 0 | 381 | 0 | 1 |
| | | | | | | | | | | | | |
| 4 | 0 | 377 | 0 | 374 | 3 | | 4 | 0 | 377 | 0 | 374 | 3 |
| | | | | | | | | | | | | |
| ... | ... | ... | ... | ... | ... | | ... | ... | ... | ... | ... | ... |
| | | | | | | | | | | | | |
| n | 0 | 387 | 0 | 387 | 0 | | 2n | 0 | 387 | 0 | 387 | 0 |
| | | | | | | | | | | | | |
| n+1 | 379 | 0 | 377 | 0 | 2 | | 2n+1 | 379 | 0 | 377 | 0 | 2 |
+-------+--------+--------+--------+--------+------+ +-------+--------+--------+--------+--------+------+
Table 1: Evaluation of counters for packet loss measurements Table 1: Evaluation of counters for packet loss measurements
During an A block (blocks 1, 3 and n+1), all the packets are During an A block (blocks 1, 3 and 2n+1), all the packets are
A-colored, therefore the C(A) counters are incremented to the number A-colored, therefore the C(A) counters are incremented to the number
seen on the interface, while C(B) counters are zero. Vice versa, seen on the interface, while C(B) counters are zero. Vice versa,
during a B block (blocks 2, 4 and n), all the packets are B-colored: during a B block (blocks 2, 4 and 2n), all the packets are B-colored:
C(A) counters are zero, while C(B) counters are incremented. C(A) counters are zero, while C(B) counters are incremented.
When a block ends (because of color switching) the relative counters When a block ends (because of color switching) the relative counters
stop incrementing and it is possible to read them, compare the values stop incrementing and it is possible to read them, compare the values
measured on router R1 and R2 and calculate the packet loss within measured on router R1 and R2 and calculate the packet loss within
that block. that block.
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
skipping to change at page 9, line 16 skipping to change at page 10, line 5
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.
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 3.2. Timing aspects
This document introduces two color switching method: one is based on This document introduces two color switching method: one is based on
fixed number of packet, the other is based on fixed timer. But the fixed number of packet, the other is based on fixed timer. But the
method based on fixed timer is preferable because is more method based on fixed timer is preferable because is more
deterministic, and will be considered in the rest of the dcoument. deterministic, and will be considered in the rest of the dcoument.
By considering the clock error between network devices R1 and R2, By considering the clock error between network devices R1 and R2,
they must be synchronized to the same clock reference with an 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 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 block. So each colored packet can be assigned to the right batch by
skipping to change at page 9, line 40 skipping to change at page 10, line 29
In practice, there are also out of order at batch boundaries, In practice, there are also out of order at batch boundaries,
strictly related to the delay between measurement points. This means strictly related to the delay between measurement points. This means
that, without considering clock error, we wait L/2 after color that, without considering clock error, we wait L/2 after color
switching to be sure to take a still counter. switching to be sure to take a still counter.
In summary we need to take into account two contributions: clock In summary we need to take into account two contributions: clock
error between network devices and the interval we need to wait to error between network devices and the interval we need to wait to
avoid out of order because of network delay. avoid out of order because of network delay.
The following figure eplains both issues. The following figure explains both issues.
...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB... ...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB...
|<======================================>| |<======================================>|
| L | | L |
...=========>|<==================><==================>|<==========... ...=========>|<==================><==================>|<==========...
| L/2 L/2 | | L/2 L/2 |
|<===>| |<===>| |<===>| |<===>|
d | | d d | | d
|<==========================>| |<==========================>|
available counting interval available counting interval
skipping to change at page 10, line 36 skipping to change at page 11, line 15
delay between the network devices, and D_min is a lower bound on the delay between the network devices, and D_min is a lower bound on the
delay. delay.
The available counting interval is L - 2d that must be > 0. The available counting interval is L - 2d that must be > 0.
The condition that must be satisfied and is a requirement on the The condition that must be satisfied and is a requirement on the
synchronization accuracy is: synchronization accuracy is:
d < L/2. d < L/2.
3.2. One-way delay measurement 3.3. 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.3.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 2, 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
skipping to change at page 11, line 41 skipping to change at page 12, line 21
| 1 | 12.483 | - | 15.591 | - | 3.108 | | 1 | 12.483 | - | 15.591 | - | 3.108 |
| | | | | | | | | | | | | |
| 2 | - | 6.263 | - | 9.288 | 3.025 | | 2 | - | 6.263 | - | 9.288 | 3.025 |
| | | | | | | | | | | | | |
| 3 | 27.556 | - | 30.512 | - | 2.956 | | 3 | 27.556 | - | 30.512 | - | 2.956 |
| | | | | | | | | | | | | |
| | - | 18.113 | - | 21.269 | 3.156 | | | - | 18.113 | - | 21.269 | 3.156 |
| | | | | | | | | | | | | |
| ... | ... | ... | ... | ... | ... | | ... | ... | ... | ... | ... | ... |
| | | | | | | | | | | | | |
| n | 77.463 | - | 80.501 | - | 3.038 | | 2n | 77.463 | - | 80.501 | - | 3.038 |
| | | | | | | | | | | | | |
| n+1 | - | 24.333 | - | 27.433 | 3.100 | | 2n+1 | - | 24.333 | - | 27.433 | 3.100 |
+-------+---------+---------+---------+---------+-------------+ +-------+---------+---------+---------+---------+-------------+
Table 2: Evaluation of timestamps for delay measurements Table 2: Evaluation of timestamps for delay measurements
The first row shows timestamps taken on R1 and R2 respectively and The first row shows timestamps taken on R1 and R2 respectively and
referring to the first packet of block 1 (which is A-colored). Delay referring to the first packet of block 1 (which is A-colored). Delay
can be computed as a difference between the timestamp on R2 and the can be computed as a difference between the timestamp on R2 and the
timestamp on R1. Similarly, the second row shows timestamps (in timestamp on R1. Similarly, the second row shows timestamps (in
milliseconds) taken on R1 and R2 and referring to the first packet of milliseconds) taken on R1 and R2 and referring to the first packet of
block 2 (which is B-colored). Comparing timestamps taken on block 2 (which is B-colored). Comparing timestamps taken on
skipping to change at page 12, line 20 skipping to change at page 13, line 5
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.1.1. Mean delay 3.3.1.1. 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 mean delay. The mean delay is calculated is based on the concept of mean delay. The mean delay is calculated
by considering the average arrival time of the packets within a by considering the average arrival time of the packets within a
single block. The network device locally stores a timestamp for each single block. The network device locally stores a timestamp for each
packet received within a single block: summing all the timestamps and packet received within a single block: summing all the timestamps and
dividing by the total number of packets received, the average arrival dividing by the total number of packets received, the average arrival
time for that block of packets can be calculated. By subtracting the time for that block of packets can be calculated. By subtracting the
average arrival times of two adjacent devices it is possible to average arrival times of two adjacent devices it is possible to
calculate the mean delay between those nodes. This method is robust calculate the mean delay between those nodes. When computing the
to out of order packets and also to packet loss (only a small error mean delay, measurement error could be augmented by accumulating
is introduced). Moreover, it greatly reduces the number of measurement error of a lot of packets. This method is robust to out
timestamps (only one per block for each network device) that have to of order packets and also to packet loss (only a small error is
be collected by the management system. On the other hand, it only introduced). Moreover, it greatly reduces the number of timestamps
gives one measure for the duration of the block (f.i. 5 minutes), and (only one per block for each network device) that have to be
it doesn't give the minimum, maximum and median delay values (RFC collected by the management system. On the other hand, it only gives
6703 [RFC6703]). This limitation could be overcome by reducing the one measure for the duration of the block (f.i. 5 minutes), and it
doesn't give the minimum, maximum and median delay values (RFC 6703
[RFC6703]). This limitation could be overcome by reducing the
duration of the block (f.i. from 5 minutes to a few seconds), that duration of the block (f.i. from 5 minutes to a few seconds), that
implicates an highly optimized implementation of the method. implicates an highly optimized implementation of the method.
By summing the mean 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 mean delay (round-trip delay). also possible to measure the two-way mean delay (round-trip delay).
3.2.2. Double marking methodology 3.3.2. 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 mean delay. But the limitation of mean delay is that it concept of mean delay. But the limitation of mean delay is that it
doesn't give information about the delay values distribution for the doesn't give information about the delay values distribution for the
duration of the block. Additionally it may be useful to have not duration of the block. Additionally it may be useful to have not
only the mean delay but also the minimum, maximum and median delay only the mean delay but also the minimum, maximum and median delay
values and, in wider terms, to know more about the statistic values and, in wider terms, to know more about the statistic
distribution of delay values. So in order to have more information distribution of delay values. So in order to have more information
skipping to change at page 14, line 5 skipping to change at page 14, line 39
marking method, where a subset of batch packets are selected for marking method, where a subset of batch packets are selected for
extensive delay calculation by using a second marking. In this way extensive delay calculation by using a second marking. In this way
it is possible to perform a detailed analysis on these double marked it is possible to perform a detailed analysis on these double marked
packets. Please note that there are classic algorithms for median packets. Please note that there are classic algorithms for median
and variance calculation, but are out of the scope of this document. and variance calculation, but are out of the scope of this document.
The comparison between the mean delay for the entire batch and the The comparison between the mean delay for the entire batch and the
mean delay on these double marked packets gives an useful information mean delay on these double marked packets gives an useful information
since it is possible to understand if the double marking measurements since it is possible to understand if the double marking measurements
are actually representative of the delay trends. are actually representative of the delay trends.
3.3. Delay variation measurement 3.4. 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. We refer to the definition in RFC 3393 [RFC3393]. arrival jitter. We refer to the definition in RFC 3393 [RFC3393].
The alternation of colors, for single marking method, can be used as The alternation of colors, for single marking method, can be used as
a time reference to measure delay variations. In case of double a time reference to measure delay variations. In case of double
marking, the time reference is given by the second marked packets. marking, the time reference is given by the second marked packets.
Considering the example depicted in Figure 2, R1 stores a timestamp Considering the example depicted in Figure 2, R1 stores a timestamp
TS(A)R1 whenever it sends the first packet of a block and R2 stores a 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. timestamp TS(B)R2 whenever it receives the first packet of a block.
skipping to change at page 17, line 50 skipping to change at page 18, line 38
instantiated for each single flow, or for the set as a whole, instantiated for each single flow, or for the set as a whole,
depending on the desired granularity. A relevant problem with depending on the desired granularity. A relevant problem with
this approach is the necessity to know in advance the path this approach is the necessity to know in advance the path
followed by flows that are subject to measurement. Path rerouting followed by flows that are subject to measurement. Path rerouting
and traffic load-balancing increase the issue complexity, and traffic load-balancing increase the issue complexity,
especially for unicast traffic. The problem is easier to solve especially for unicast traffic. The problem is easier to solve
for multicast traffic where load balancing is seldom used, for multicast traffic where load balancing is seldom used,
especially for IPTV traffic where static joins are frequently used especially for IPTV traffic where static joins are frequently used
to force traffic forwarding and replication. Another application to force traffic forwarding and replication. Another application
is on Mobile Backhauling, implemented with a VPN MPLS in Telecom is on Mobile Backhauling, implemented with a VPN MPLS in Telecom
Italia's network; in this case the problem with unicast traffic is Italia's network; where the monitoring is between the Provider
overcome by monitoring just the two Provider Edge nodes of the VPN Edge nodes of the VPN MPLS.
MPLS.
o link-based: measurements are performed on all the traffic on a o link-based: measurements are performed on all the traffic on a
link by link basis. The link could be a physical link or a link by link basis. The link could be a physical link or a
logical link (for instance an Ethernet VLAN or a MPLS PW). logical link (for instance an Ethernet VLAN or a MPLS PW).
Counters could be instantiated for the traffic as a whole or for Counters could be instantiated for the traffic as a whole or for
each traffic class (in case it is desired to monitor each class each traffic class (in case it is desired to monitor each class
separately), but in the second case a couple of counters is needed separately), but in the second case a couple of counters is needed
for each class. for each class.
The current implementation in Telecom Italia uses the first strategy. The current implementation in Telecom Italia uses the first strategy.
skipping to change at page 18, line 48 skipping to change at page 19, line 36
5.1.1. Coloring the packets 5.1.1. Coloring the packets
The coloring operation is fundamental in order to create packet The coloring operation is fundamental in order to create packet
blocks. This implies choosing where to activate the coloring and how blocks. This implies choosing where to activate the coloring and how
to color the packets. to color the packets.
In case of flow-based measurements, it is desirable, in general, to In case of flow-based measurements, it is desirable, in general, to
have a single coloring node because it is easier to manage and have a single coloring node because it is easier to manage and
doesn't rise any risk of conflict (consider the case where two nodes doesn't rise any risk of conflict (consider the case where two nodes
color the same flow). Thus it is necessary to color the flow as color the same flow). Thus it is advantageous to color the flow as
close as possible to the source. In addition, coloring a flow close close as possible to the source. In addition, coloring a flow close
to the source allows an end-to-end measure if a measurement point is 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 enabled on the last-hop router as well. The only requirement is that
the coloring must change periodically and every node along the path the coloring must change periodically and every node along the path
must be able to identify unambiguously the colored packets. For must be able to identify unambiguously the colored packets. For
link-based measurements, all traffic needs to be colored when link-based measurements, all traffic needs to be colored when
transmitted on the link. If the traffic had already been colored, transmitted on the link. If the traffic had already been colored,
then it has to be re-colored because the color must be consistent on then it has to be re-colored because the color must be consistent on
the link. This means that each hop along the path must (re-)color the link. This means that each hop along the path must (re-)color
the traffic; the color is not required to be consistent along the traffic; the color is not required to be consistent along
skipping to change at page 19, line 32 skipping to change at page 20, line 21
1 if the flow is under monitoring, otherwise it is set to 0), while 1 if the flow is under monitoring, otherwise it is set to 0), while
the second (bit 1) can be used for coloring the traffic (switching the second (bit 1) can be used for coloring the traffic (switching
between values 0 and 1, corresponding to color A and B) and creating between values 0 and 1, corresponding to color A and B) and creating
the blocks. the blocks.
In practice, coloring the traffic using the DSCP field can be In practice, coloring the traffic using the DSCP field can be
implemented by configuring on the router output interface an access implemented by configuring on the router output interface an access
list that intercepts the flow(s) to be monitored and applies to them list that intercepts the flow(s) to be monitored and applies to them
a policy that sets the DSCP field accordingly. Since traffic a policy that sets the DSCP field accordingly. Since traffic
coloring has to be switched between the two values over time, the coloring has to be switched between the two values over time, the
policy needs to be modified periodically: an automatic script ca be policy needs to be modified periodically: an automatic script can be
used perform this task on the basis of a fixed timer. In Telecom used perform this task on the basis of a fixed timer. In Telecom
Italia's implementation this timer is set to 5 minutes: this value Italia's implementation this timer is set to 5 minutes: this value
showed to be a good compromise between measurement frequency and showed to be a good compromise between measurement frequency and
stability of the measurement (i.e. possibility to collect all the stability of the measurement (i.e. possibility to collect all the
measures referring to the same block). measures referring to the same block).
5.1.2. Counting the packets 5.1.2. Counting the packets
Assuming that the coloring of the packets is performed only by the Assuming that the coloring of the packets is performed only by the
source node, the nodes between source and destination (included) have source node, the nodes between source and destination (included) have
to count the colored packets that they receive and forward: this to count the colored packets that they receive and forward: this
operation can be enabled on every router along the path or only on a operation can be enabled on every router along the path or only on a
subset, depending on which network segment is being monitored (a subset, depending on which network segment is being monitored (a
single link, a particular metro area, the backbone, the whole path). single link, a particular metro area, the backbone, the whole path).
Since the color switches periodically between two values, two Since the color switches periodically between two values, two
counters (one for each value) are needed: one counter for packets counters (one for each value) are needed: one counter for packets
with color A and one counter for packets with color B. For each flow with color A and one counter for packets with color B. For each flow
(or group of flows) being monitored and for every interface where the (or group of flows) being monitored and for every interface where the
monitoring is active, a couple od counters is needed. For example, monitoring is active, a couple of counters is needed. For example,
in order to monitor separately 3 flows on a router with 4 interfaces 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 involved, 24 counters are needed (2 counters for each of the 3 flows
on each of the 4 interfaces). If traffic is colored using the DSCP on each of the 4 interfaces). If traffic is colored using the DSCP
field, as in Telecom Italia's implementation, an access-list that field, as in Telecom Italia's implementation, an access-list that
matches specific DSCP values can be used to count the packets of the matches specific DSCP values can be used to count the packets of the
flow(s) being monitored. flow(s) being monitored.
In case of link-based measurements the behaviour is similar except In case of link-based measurements the behaviour is similar except
that coloring and counting operations are performed on a link by link that coloring and counting operations are performed on a link by link
basis at each endpoint of the link. basis at each endpoint of the link.
skipping to change at page 21, line 40 skipping to change at page 22, line 31
Provider Edge nodes of the Mobile Backhauling VPN MPLS) are totally Provider Edge nodes of the Mobile Backhauling VPN MPLS) are totally
anaware that packets were marked. So this restoring technique makes anaware that packets were marked. So this restoring technique makes
Alternate Marking completely transparent outside its monitoring Alternate Marking completely transparent outside its monitoring
domain. domain.
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. OAM Passive Performance Measurement
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.ietf-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 [I-D.mirsky-sfc-pmamm] describes how the alternate marking method can
be used as the passive performance measurement method in a Service
The Overlay OAM Design Team is considering the preliminary OAM Function Chaining (SFC) domain.
requirements from NVO3, BIER, and SFC. Marking Method is the
preferred passive method to measure performance.
[I-D.ooamdt-rtgwg-ooam-requirement] and The application of the marking method to Network Virtualization
[I-D.ooamdt-rtgwg-oam-gap-analysis] explain in deep this item. Overlays (NVO3) protocols is a work in progress.
5.5. RFC6374 Use Case 5.4. RFC6374 Use Case
RFC6374 [RFC6374] uses the LM packet as the packet accounting RFC6374 [RFC6374] uses the LM packet as the packet accounting
demarcation point. Unfortunately this gives rise to a number of demarcation point. Unfortunately this gives rise to a number of
problems that may lead to significant packet accounting errors in problems that may lead to significant packet accounting errors in
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.ietf-mpls-rfc6374-sfl] describes RFC6374 performance
measurements with SFL. measurements with SFL.
5.6. Application to active performance measurement 5.5. Application to active performance measurement
[I-D.fioccola-ippm-alt-mark-active] describes how to extend the [I-D.fioccola-ippm-alt-mark-active] describes how to extend the
existing Active Measurement Protocol, in order to implement alternate existing Active Measurement Protocol, in order to implement alternate
marking methodology. [I-D.fioccola-ippm-rfc6812-alt-mark-ext] marking methodology. [I-D.fioccola-ippm-rfc6812-alt-mark-ext]
describes an extension to the Cisco SLA Protocol Measurement-Type describes an extension to the Cisco SLA Protocol Measurement-Type
UDP-Measurement. 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
skipping to change at page 26, line 29 skipping to change at page 27, line 17
10. IANA Considerations 10. IANA Considerations
There are no IANA actions required. There are no IANA actions required.
11. Acknowledgements 11. Acknowledgements
The previous IETF drafts about this technique were: The previous IETF drafts about this technique were:
[I-D.cociglio-mboned-multicast-pm] and [I-D.tempia-opsawg-p3m]. [I-D.cociglio-mboned-multicast-pm] and [I-D.tempia-opsawg-p3m].
There are some references to this methodology in other IETF works 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] (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-mpls-rfc6374-sfl], [I-D.ietf-bier-mpls-encapsulation],
[I-D.ietf-bier-pmmm-oam] [I-D.ietf-bier-pmmm-oam]
[I-D.chen-ippm-coloring-based-ipfpm-framework]). [I-D.chen-ippm-coloring-based-ipfpm-framework]).
In addition the authors would like to thank Domenico Laforgia, In addition the authors would like to thank Alberto Tempia Bonda,
Daniele Accetta and Mario Bianchetti for their contribution to the Domenico Laforgia, Daniele Accetta and Mario Bianchetti for their
definition and the implementation of the method. 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 27, line 12 skipping to change at page 27, line 45
DOI 10.17487/RFC2680, September 1999, DOI 10.17487/RFC2680, September 1999,
<http://www.rfc-editor.org/info/rfc2680>. <http://www.rfc-editor.org/info/rfc2680>.
[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]
Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S.,
Mirsky, G., and G. Fioccola, "RFC6374 Synonymous Flow
Labels", draft-bryant-mpls-rfc6374-sfl-03 (work in
progress), October 2016.
[I-D.bryant-mpls-sfl-framework] [I-D.bryant-mpls-sfl-framework]
Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S.,
and G. Mirsky, "Synonymous Flow Label Framework", draft- and G. Mirsky, "Synonymous Flow Label Framework", draft-
bryant-mpls-sfl-framework-02 (work in progress), October bryant-mpls-sfl-framework-04 (work in progress), April
2016. 2017.
[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] [I-D.fioccola-ippm-alt-mark-active]
Fioccola, G., Clemm, A., Cociglio, M., Chandramouli, M., Fioccola, G., Clemm, A., Bryant, S., Cociglio, M.,
and A. Capello, "Alternate Marking Extension to Active Chandramouli, M., and A. Capello, "Alternate Marking
Measurement Protocol", draft-fioccola-ippm-alt-mark- Extension to Active Measurement Protocol", draft-fioccola-
active-00 (work in progress), July 2016. ippm-alt-mark-active-01 (work in progress), March 2017.
[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., Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J.,
Aldrin, S., and I. Meilik, "Encapsulation for Bit Index Aldrin, S., and I. Meilik, "Encapsulation for Bit Index
Explicit Replication in MPLS and non-MPLS Networks", Explicit Replication in MPLS and non-MPLS Networks",
draft-ietf-bier-mpls-encapsulation-06 (work in progress), draft-ietf-bier-mpls-encapsulation-07 (work in progress),
December 2016. June 2017.
[I-D.ietf-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-ietf-bier- Index Explicit Replication (BIER) Layer", draft-ietf-bier-
pmmm-oam-01 (work in progress), January 2017. pmmm-oam-01 (work in progress), January 2017.
[I-D.ietf-mpls-flow-ident] [I-D.ietf-mpls-flow-ident]
Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. Bryant, S., Pignataro, C., Chen, M., Li, Z., and G.
Mirsky, "MPLS Flow Identification Considerations", draft- Mirsky, "MPLS Flow Identification Considerations", draft-
ietf-mpls-flow-ident-04 (work in progress), February 2017. ietf-mpls-flow-ident-04 (work in progress), February 2017.
[I-D.ooamdt-rtgwg-oam-gap-analysis] [I-D.ietf-mpls-rfc6374-sfl]
Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N., Kumar, Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S.,
D., Chen, M., Yizhou, L., Mozes, D., Networks, J., and I. Mirsky, G., and G. Fioccola, "RFC6374 Synonymous Flow
Bagdonas, "Operations, Administration and Maintenance Labels", draft-ietf-mpls-rfc6374-sfl-00 (work in
(OAM) for Overlay Networks: Gap Analysis", draft-ooamdt- progress), June 2017.
rtgwg-oam-gap-analysis-02 (work in progress), July 2016.
[I-D.ooamdt-rtgwg-ooam-requirement] [I-D.mirsky-sfc-pmamm]
Kumar, N., Pignataro, C., Kumar, D., Mirsky, G., Chen, M., Mirsky, G. and G. Fioccola, "Performance Measurement (PM)
Nordmark, E., Networks, J., and D. Mozes, "Overlay OAM with Alternate Marking Method in Service Function Chaining
Requirements", draft-ooamdt-rtgwg-ooam-requirement-02 (SFC) Domain", draft-mirsky-sfc-pmamm-00 (work in
(work in progress), January 2017. progress), April 2017.
[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.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,
March 2009, <http://www.rfc-editor.org/info/rfc5481>. March 2009, <http://www.rfc-editor.org/info/rfc5481>.
skipping to change at page 29, line 25 skipping to change at page 29, line 46
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
Weingarten, "An Overview of Operations, Administration, Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Tools", RFC 7276, and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014, DOI 10.17487/RFC7276, June 2014,
<http://www.rfc-editor.org/info/rfc7276>. <http://www.rfc-editor.org/info/rfc7276>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <http://www.rfc-editor.org/info/rfc7384>. October 2014, <http://www.rfc-editor.org/info/rfc7384>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <http://www.rfc-editor.org/info/rfc7799>.
Authors' Addresses Authors' Addresses
Giuseppe Fioccola (editor) Giuseppe Fioccola (editor)
Telecom Italia Telecom Italia
Via Reiss Romoli, 274 Via Reiss Romoli, 274
Torino 10148 Torino 10148
Italy Italy
Email: giuseppe.fioccola@telecomitalia.it Email: giuseppe.fioccola@telecomitalia.it
 End of changes. 46 change blocks. 
109 lines changed or deleted 123 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/