draft-ietf-ippm-alt-mark-13.txt   draft-ietf-ippm-alt-mark-14.txt 
Network Working Group G. Fioccola, Ed. Network Working Group G. Fioccola, Ed.
Internet-Draft A. Capello Internet-Draft A. Capello
Intended status: Experimental M. Cociglio Intended status: Experimental M. Cociglio
Expires: April 28, 2018 L. Castaldelli Expires: June 10, 2018 L. Castaldelli
Telecom Italia Telecom Italia
M. Chen M. Chen
L. Zheng L. Zheng
Huawei Technologies Huawei Technologies
G. Mirsky G. Mirsky
ZTE ZTE
T. Mizrahi T. Mizrahi
Marvell Marvell
October 25, 2017 December 7, 2017
Alternate Marking method for passive and hybrid performance monitoring Alternate Marking method for passive and hybrid performance monitoring
draft-ietf-ippm-alt-mark-13 draft-ietf-ippm-alt-mark-14
Abstract Abstract
This document describes a method to perform packet loss, delay and This document describes a method to perform packet loss, delay and
jitter measurements on live traffic. This method is based on jitter measurements on live traffic. This method is based on
Alternate Marking (Coloring) technique. A report is provided in Alternate Marking (Coloring) technique. A report is provided in
order to explain an example and show the method applicability. This order to explain an example and show the method applicability. This
technique can be applied in various situations as detailed in this technology can be applied in various situations as detailed in this
document and could be considered passive or hybrid depending on the document and could be considered passive or hybrid depending on the
application. application.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 April 28, 2018. This Internet-Draft will expire on June 10, 2018.
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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 . . . . . . . . . . . . . . . . . . . 5
3. Detailed description of the method . . . . . . . . . . . . . 6 3. Detailed description of the method . . . . . . . . . . . . . 6
3.1. Packet loss measurement . . . . . . . . . . . . . . . . . 6 3.1. Packet loss measurement . . . . . . . . . . . . . . . . . 6
3.1.1. Coloring the packets . . . . . . . . . . . . . . . . 11 3.1.1. Coloring the packets . . . . . . . . . . . . . . . . 11
3.1.2. Counting the packets . . . . . . . . . . . . . . . . 11 3.1.2. Counting the packets . . . . . . . . . . . . . . . . 11
3.1.3. Collecting data and calculating packet loss . . . . . 12 3.1.3. Collecting data and calculating packet loss . . . . . 12
3.2. Timing aspects . . . . . . . . . . . . . . . . . . . . . 13 3.2. Timing aspects . . . . . . . . . . . . . . . . . . . . . 13
3.3. One-way delay measurement . . . . . . . . . . . . . . . . 14 3.3. One-way delay measurement . . . . . . . . . . . . . . . . 14
3.3.1. Single marking methodology . . . . . . . . . . . . . 14 3.3.1. Single marking methodology . . . . . . . . . . . . . 14
3.3.2. Double marking methodology . . . . . . . . . . . . . 16 3.3.2. Double marking methodology . . . . . . . . . . . . . 16
3.4. Delay variation measurement . . . . . . . . . . . . . . . 17 3.4. Delay variation measurement . . . . . . . . . . . . . . . 17
4. Considerations . . . . . . . . . . . . . . . . . . . . . . . 18 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Synchronization . . . . . . . . . . . . . . . . . . . . . 18 4.1. Synchronization . . . . . . . . . . . . . . . . . . . . . 18
4.2. Data Correlation . . . . . . . . . . . . . . . . . . . . 19 4.2. Data Correlation . . . . . . . . . . . . . . . . . . . . 19
4.3. Packet Re-ordering . . . . . . . . . . . . . . . . . . . 20 4.3. Packet Re-ordering . . . . . . . . . . . . . . . . . . . 20
5. Implementation and deployment . . . . . . . . . . . . . . . . 20 5. Applications, implementation and deployment . . . . . . . . . 20
5.1. Report on the operational experiment at Telecom Italia . 21 5.1. Report on the operational experiment . . . . . . . . . . 21
5.1.1. Metric transparency . . . . . . . . . . . . . . . . . 22 5.1.1. Metric transparency . . . . . . . . . . . . . . . . . 23
5.2. IP flow performance measurement (IPFPM) . . . . . . . . . 23
5.3. OAM Passive Performance Measurement . . . . . . . . . . . 23
5.4. RFC6374 Use Case . . . . . . . . . . . . . . . . . . . . 23
5.5. Application to active performance measurement . . . . . . 24
6. Hybrid measurement . . . . . . . . . . . . . . . . . . . . . 24 6. Hybrid measurement . . . . . . . . . . . . . . . . . . . . . 24
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 24
8. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 11.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 28 11.2. Informative References . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Nowadays, most Service Providers' networks carry traffic with Nowadays, most Service Providers' networks carry traffic with
contents that are highly sensitive to packet loss [RFC7680], delay contents that are highly sensitive to packet loss [RFC7680], delay
[RFC7679], and jitter [RFC3393]. [RFC7679], 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
skipping to change at page 3, line 42 skipping to change at page 3, line 37
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.
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, easy to implement and deploy. The effort
The effort led to the method described in this document: basically, led to the method described in this document: basically, it is a
it is a passive performance monitoring technique, potentially passive performance monitoring technique, potentially applicable to
applicable to any kind of packet based traffic, including Ethernet, any kind of packet based traffic, including Ethernet, IP, and MPLS,
IP, and MPLS, both unicast and multicast. The method addresses both unicast and multicast. The method addresses primarily packet
primarily packet loss measurement, but it can be easily extended to loss measurement, but it can be easily extended to one-way delay and
one-way delay and delay variation measurements as well. 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. RFC 7799 [RFC7799] defines passive and hybrid methods of measurement.
In particular, Passive Methods of Measurement are based solely on In particular, Passive Methods of Measurement are based solely on
observations of an undisturbed and unmodified packet stream of observations of an undisturbed and unmodified packet stream of
interest; Hybrid Methods are Methods of Measurement that use a interest; Hybrid Methods are Methods of Measurement that use a
combination of Active Methods and Passive Methods. combination of Active Methods and Passive Methods.
Taking into consideration these definitions, Alternate Marking Method Taking into consideration these definitions, Alternate Marking Method
could be considered Hybrid or Passive depending on the case. In case could be considered Hybrid or Passive depending on the case. In case
the marking field is obtained by changing existing field values of the marking method is obtained by changing existing field values of
the packets (e.g. DSCP field), the technique is Hybrid. In case the the packets (e.g. DSCP field), the technique is Hybrid. In case the
marking field is dedicated, reserved and is included in the protocol marking field is dedicated, reserved and is included in the protocol
specification Alternate Marking technique can be considered as specification Alternate Marking technique can be considered as
Passive (e.g. RFC6374 Synonymous Flow Label or OAM Marking Bits in Passive (e.g. RFC6374 Synonymous Flow Label or OAM Marking Bits in
BIER Header). BIER Header).
This document is organized as follows: The advantages of the method described in this document are:
o Section 2 gives an overview of the method, including a comparison o easy implementation: it can be implemented or by using features
with different measurement strategies; already available on major routing platforms as described in
Section 5.1 or by applying an optimized implementation of the
method for both legacy and newest technologies;
o Section 3 describes the method in detail; o low computational effort: the additional load on processing is
negligible;
o Section 4 reports considerations about synchronization, data o accurate packet loss measurement: single packet loss granularity
correlation and packet re-ordering; is achieved with a passive measurement;
o Section 5 reports examples of implementation and deployment of the o potential applicability to any kind of packet/frame -based
method. Furthermore the operational experiment done at Telecom traffic: Ethernet, IP, MPLS, etc., both unicast and multicast;
Italia is described;
o Section 6 introduces Hybrid measurement aspects; o robustness: the method can tolerate out of order packets and it's
not based on "special" packets whose loss could have a negative
impact;
o Section 7 finally summarizes some concluding remarks. o flexibility: all the timestamp formats are allowed, because they
are managed out-of-band. The format (the Network Time Protocol
(NTP) RFC 5905 [RFC5905] or the IEEE 1588 Precision Time Protocol
(PTP) [IEEE-1588]) depends on the precision you want;
o Section 8 is about the compliance with RFC6390 guidelines; o no interoperability issues: the features required to experiment
and test the method (as described in Section 5.1) are available on
all current routing platforms. Both a centarlized or distributed
solution can be used to harvest data from the routers.
o Section 9 includes some security aspects; The method doesn't raise any specific need for protocol extension,
but it could be further improved by means of some extension to
existing protocols. Specifically, the use of DiffServ bits for
coloring the packets could not be a viable solution in some cases: a
standard method to color the packets for this specific application
could be beneficial.
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 production traffic
different approaches exist. The most intuitive one consists in flow, 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
simple in theory, is not simple to achieve: it requires the insertion simple in theory, is not simple to achieve: it requires the insertion
of a sequence number into each packet and the devices must be able to of a sequence number into each packet and the devices must be able to
extract the number and check it in real time. Such a task can be extract the number and check it in real time. Such a task can be
difficult to implement on live traffic: if UDP is used as the difficult to implement on live traffic: if UDP is used as the
transport protocol, the sequence number is not available; on the transport protocol, the sequence number is not available; on the
other hand, if a higher layer sequence number (e.g. in the RTP other hand, if a higher layer sequence number (e.g. in the RTP
header) is used, extracting that information from each packet and header) is used, extracting that information from each packet and
process it in real time could overload the device. process it in real time could overload the device.
An alternate approach is to count the number of packets sent on one An alternate approach is to count the number of packets sent on one
end, the number of packets received on the other end, and to compare end, the number of packets received on the other end, and to compare
the two values. This operation is much simpler to implement, but the two values. This operation is much simpler to implement, but
requires that the devices performing the measurement are in sync: in requires that the devices performing the measurement are in sync: in
order to compare two counters it is required that they refer exactly order to compare two counters it is required that they refer exactly
to the same set of packets. Since a flow is continuous and cannot be to the same set of packets. Since a flow is continuous and cannot be
stopped when a counter has to be read, it could be difficult to stopped when a counter has to be read, it can be difficult to
determine exactly when to read the counter. A possible solution to determine exactly when to read the counter. A possible solution to
overcome this problem is to virtually split the flow in consecutive overcome this problem is to virtually split the flow in consecutive
blocks by inserting periodically a delimiter so that each counter blocks by inserting periodically a delimiter so that each counter
refers exactly to the same block of packets. The delimiter could be refers exactly to the same block of packets. The delimiter could be
for example a special packet inserted artificially into the flow. for example a special packet inserted artificially into the flow.
However, delimiting the flow using specific packets has some However, delimiting the flow using specific packets has some
limitations. First, it requires generating additional packets within limitations. First, it requires generating additional packets within
the flow and requires the equipment to be able to process those the flow and requires the equipment to be able to process those
packets. In addition, the method is vulnerable to out of order packets. In addition, the method is vulnerable to out of order
reception of delimiting packets and, to a lesser extent, to their reception of delimiting packets and, to a lesser extent, to their
skipping to change at page 7, line 44 skipping to change at page 8, line 5
Block n ... Block 3 Block 2 Block 1 Block n ... Block 3 Block 2 Block 1
<---------> <---------> <---------> <---------> <---------> <---------> <---------> <---------> <---------> <--------->
Traffic flow Traffic flow
===========================================================> ===========================================================>
Color ...AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA... Color ...AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA...
===========================================================> ===========================================================>
Figure 3: Computation of link packet loss Figure 3: Computation of link packet loss
Traffic coloring could be done by R1 itself or by an upward router. Traffic coloring could be done by R1 itself or it is already done
R1 needs two counters, C(A)R1 and C(B)R1, on its egress interface: before. R1 needs two counters, C(A)R1 and C(B)R1, on its egress
C(A)R1 counts the packets with color A and C(B)R1 counts those with interface: C(A)R1 counts the packets with color A and C(B)R1 counts
color B. As long as traffic is colored A, only counter C(A)R1 will those with color B. As long as traffic is colored A, only counter
be incremented, while C(B)R1 is not incremented; vice versa, when the C(A)R1 will be incremented, while C(B)R1 is not incremented; vice
traffic is colored as B, only C(B)R1 is incremented. C(A)R1 and versa, when the traffic is colored as B, only C(B)R1 is incremented.
C(B)R1 can be used as reference values to determine the packet loss C(A)R1 and C(B)R1 can be used as reference values to determine the
from R1 to any other measurement point down the path. Router R2, packet loss from R1 to any other measurement point down the path.
similarly, will need two counters on its ingress interface, C(A)R2 Router R2, similarly, will need two counters on its ingress
and C(B)R2, to count the packets received on that interface and interface, C(A)R2 and C(B)R2, to count the packets received on that
colored with color A and B respectively. When an A block ends, it is interface and colored with color A and B respectively. When an A
possible to compare C(A)R1 and C(A)R2 and calculate the packet loss block ends, it is possible to compare C(A)R1 and C(A)R2 and calculate
within the block; similarly, when the successive B block terminates, the packet loss within the block; similarly, when the successive B
it is possible to compare C(B)R1 with C(B)R2, and so on for every block terminates, it is possible to compare C(B)R1 with C(B)R2, and
successive block. so on for every successive block.
Likewise, by using two counters on R2 egress interface it is possible Likewise, by using two counters on R2 egress interface it is possible
to count the packets sent out of R2 interface and use them as to count the packets sent out of R2 interface and use them as
reference values to calculate the packet loss from R2 to any reference values to calculate the packet loss from R2 to any
measurement point down R2. measurement point down R2.
Using a fixed timer for color switching offers a better control over Using a fixed timer for color switching offers a better control over
the method: the (time) length of the blocks can be chosen large the method: the (time) length of the blocks can be chosen large
enough to simplify the collection and the comparison of measures enough to simplify the collection and the comparison of measures
taken by different network devices. It's preferable to read the taken by different network devices. It's preferable to read the
skipping to change at page 11, line 11 skipping to change at page 11, line 11
enable the monitoring system on every path: counters on interfaces enable the monitoring system on every path: counters on interfaces
traversed by the flow will report packet count, counters on other traversed by the flow will report packet count, counters on other
interfaces will be null. interfaces will be null.
3.1.1. Coloring the packets 3.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, the flow to monitor can be
have a single coloring node because it is easier to manage and defined by a set of selection rules (e.g. headers fields) used to
doesn't rise any risk of conflict (consider the case where multiple match a subset of the packets; in this way it is possible to control
nodes color the same flow). Thus it is advantageous to color the the number of involved nodes, the path followed by the packets and
flow as close as possible to the source. In addition, coloring a the size of the flows. it is possible, in general, to have multiple
flow close to the source allows an end-to-end measure if a coloring nodes or a single coloring node that is easier to manage and
doesn't rise any risk of conflict. Coloring in multiple nodes can be
done and the requirement is that the coloring must change
periodically between the nodes according to the timing considerations
in Section 3.2; so every node, that is designated as a measurement
point along the path, should be able to identify unambiguously the
colored packets. Furthermore [I-D.fioccola-ippm-multipoint-alt-mark]
generalizes the coloring for multipoint to multipoint flow. In
addition, it can be advantageous to color the flow as close as
possible to the source because it allows an end-to-end measure if a
measurement point is enabled on the last-hop router as well. measurement point is enabled on the last-hop router as well.
Coloring in multiple nodes is also possible and the requirement is
that the coloring must change periodically according to the timing
considerations in Section 3.2; so every node, that is designated as a
measurement point along the path, should be able to identify
unambiguously the colored packets. Furthermore
[I-D.fioccola-ippm-multipoint-alt-mark] generalizes the coloring for
multipoint to multipoint flow.
For link-based measurements, all traffic needs to be colored when For 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
different links. different links.
Traffic coloring can be implemented by setting a specific bit in the Traffic coloring can be implemented by setting a specific bit in the
packet header and changing the value of that bit periodically. How packet header and changing the value of that bit periodically. How
to choose the marking field depends on the application and is out of to choose the marking field depends on the application and is out of
scope here. However some examples are reported in Section 5. scope here. However some applications are reported in Section 5.
3.1.2. Counting the packets 3.1.2. Counting the packets
For flow-based measurements, assuming that the coloring of the For flow-based measurements, assuming that the coloring of the
packets is performed only by the source node, the nodes between packets is performed only by the source nodes, the nodes between
source and destination (included) have to count the colored packets source and destination (included) have to count the colored packets
that they receive and forward: this operation can be enabled on every that they receive and forward: this operation can be enabled on every
router along the path or only on a subset, depending on which network router along the path or only on a subset, depending on which network
segment is being monitored (a single link, a particular metro area, segment is being monitored (a single link, a particular metro area,
the backbone, the whole path). Furthermore the backbone, the whole path). Since the color switches periodically
between two values, two 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 (or group of flows) being monitored and for
every interface where the monitoring is active, a couple of counters
is needed. For example, in order to monitor separately 3 flows on a
router with 4 interfaces involved, 24 counters are needed (2 counters
for each of the 3 flows on each of the 4 interfaces). Furthermore
[I-D.fioccola-ippm-multipoint-alt-mark] generalizes the counting for [I-D.fioccola-ippm-multipoint-alt-mark] generalizes the counting for
multipoint to multipoint flow. multipoint to multipoint flow.
Since the color switches periodically between two values, two
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
(or group of flows) being monitored and for every interface where the
monitoring is active, a couple of counters is needed. For example,
in order to monitor separately 3 flows on a router with 4 interfaces
involved, 24 counters are needed (2 counters for each of the 3 flows
on each of the 4 interfaces).
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.
Another important aspect to take into consideration is when to read Another important aspect to take into consideration is when to read
the counters: in order to count the exact number of packets of a the counters: in order to count the exact number of packets of a
block the routers must perform this operation when that block has block the routers must perform this operation when that block has
ended: in other words, the counter for color A must be read when the ended: in other words, the counter for color A must be read when the
current block has color B, in order to be sure that the value of the current block has color B, in order to be sure that the value of the
counter is stable. This task can be accomplished in two ways. The counter is stable. This task can be accomplished in two ways. The
skipping to change at page 20, line 38 skipping to change at page 20, line 38
the interval of each block is sufficient large. Then, it can assume the interval of each block is sufficient large. Then, it can assume
that the packets with different marker belong to the block that they that the packets with different marker belong to the block that they
are more close to. If the interval is small, it is difficult and are more close to. If the interval is small, it is difficult and
sometime impossible to determine to which block a packet belongs. sometime impossible to determine to which block a packet belongs.
To choose a proper interval is important and how to choose a proper To choose a proper interval is important and how to choose a proper
interval is out of the scope of this document. But an implementation interval is out of the scope of this document. But an implementation
SHOULD provide a way to configure the interval and allow a certain SHOULD provide a way to configure the interval and allow a certain
degree of packet re-ordering. degree of packet re-ordering.
5. Implementation and deployment 5. Applications, implementation and deployment
The methodology described in the previous sections can be applied in The methodology described in the previous sections can be applied in
various situations. Basically Alternate Marking technique could be various situations. Basically Alternate Marking technique could be
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.
Some recent alternate marking method applications are listed below:
o IP flow performance measurement (IPFPM): this application of
marking method is described in
[I-D.chen-ippm-coloring-based-ipfpm-framework]. As an example, in
this document, the last reserved bit of the Flag field of the IPv4
header is proposed to be used for marking, while a solution for
IPv6 could be to leverage the IPv6 extension header for marking.
o OAM Passive Performance Measurement: In
[I-D.ietf-bier-mpls-encapsulation] two OAM bits from Bit Index
Explicit Replication (BIER) Header are reserved for the passive
performance measurement marking method. [I-D.ietf-bier-pmmm-oam]
details the measurement for multicast service over BIER domain.
In addition, the alternate marking method could also be used in a
Service Function Chaining (SFC) domain. Lastly the application of
the marking method to Network Virtualization Overlays (NVO3)
protocols is considered by [I-D.ietf-nvo3-encap].
o RFC6374 Use Case: RFC6374 [RFC6374] uses the LM packet as the
packet accounting demarcation point. Unfortunately this gives
rise to a number of problems that may lead to significant packet
accounting errors in certain situations.
[I-D.ietf-mpls-flow-ident] discusses the desired capabilities for
MPLS flow identification in order to perform a better in-band
performance monitoring of user data packets. A method of
accomplishing identification is Synonymous Flow Labels (SFL)
introduced in [I-D.bryant-mpls-sfl-framework], while
[I-D.ietf-mpls-rfc6374-sfl] describes RFC6374 performance
measurements with SFL.
o active performance measurement:
[I-D.fioccola-ippm-alt-mark-active] describes how to extend the
existing Active Measurement Protocol, in order to implement
alternate marking methodology.
[I-D.fioccola-ippm-rfc6812-alt-mark-ext] describes an extension to
the Cisco SLA Protocol Measurement-Type UDP-Measurement.
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
The method described in this document, also called PNPM (Packet The method described in this document, also called PNPM (Packet
Network Performance Monitoring), has been invented and engineered in Network Performance Monitoring), has been invented and engineered in
Telecom Italia and it's currently being used in Telecom Italia's Telecom Italia.
network. The methodology has been applied by leveraging functions
and tools available on IP routers and it's currently being used to
monitor packet loss in some portions of Telecom Italia's network.
The application of the method to delay measurement is currently being
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 current implementation in Telecom Italia uses the flow-based It is important to highlight that the general description of the
strategy, as defined in Section 3. The link-based strategy could be methodology in this document is a consequence of the operational
experiment. The foundational elements of the technique have been
tested and the lessons learnt from the operational experiment
inspired the formalization of the Alternate Marking Method as
detailed in the previous sections.
The methodology is experimented in Telecom Italia's network and is
applied to multicast IPTV channels or other specific traffic flows
with high QoS requirements (i.e. Mobile Backhauling traffic realized
with a VPN MPLS).
This technology has been employed by leveraging functions and tools
available on IP routers and it's currently being used to monitor
packet loss in some portions of the Telecom Italia's network. The
application of the method to delay measurement has also been
evaluated in Telecom Italia's labs.
This Section describes how the experiment has been executed, in
particular 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 operational test, here described, uses the flow-based strategy,
as defined in Section 3. Instead the link-based strategy could be
applied to physical link or a logical link (e.g. Ethernet VLAN or a applied to physical link or a logical link (e.g. Ethernet VLAN or a
MPLS PW). MPLS PW).
The method is applied in Telecom Italia's network to multicast IPTV The implementation of the method leverages the available router
channels or other specific traffic flows with high QoS requirements functions, since the experiment has been done by a Service Provider
(i.e. Mobile Backhauling traffic implemented with a VPN MPLS). (as Telecom Itlaia is) on its own network. So, with current router
implementations, only QoS related fields and features offer the
The implementation of the method by a Service Provider needs to use required flexibility to set bits in the packet header. In case a
the router features. With current router implementations, only QoS Service Provider only uses the three most significant bits of the
related fields and features offer the required flexibility to set DSCP field (corresponding to IP Precedence) for QoS classification
bits in the packet header. In case a Service Provider only uses the and queuing, it is possible to use the two less significant bits of
three most significant bits of the DSCP field (corresponding to IP the DSCP field (bit 0 and bit 1) to implement the method without
Precedence) for QoS classification and queuing, it is possible to use affecting QoS policies. That is the approach used for the
the two less significant bits of the DSCP field (bit 0 and bit 1) to experiment. One of the two bits (bit 0) could be used to identify
implement the method without affecting QoS policies. One of the two flows subject to traffic monitoring (set to 1 if the flow is under
bits (bit 0) could be used to identify flows subject to traffic monitoring, otherwise it is set to 0), while the second (bit 1) can
monitoring (set to 1 if the flow is under monitoring, otherwise it is be used for coloring the traffic (switching between values 0 and 1,
set to 0), while the second (bit 1) can be used for coloring the corresponding to color A and B) and creating the blocks.
traffic (switching between values 0 and 1, corresponding to color A
and B) and creating the blocks.
In practice, coloring the traffic using the DSCP field can be The experiment considers a flow as all the packets sharing the same
implemented by configuring on the router output interface an access source IP address or the same destination IP address, depending on
list that intercepts the flow(s) to be monitored and applies to them the direction. In practice, once the flow has been defined, coloring
a policy that sets the DSCP field accordingly. Since traffic the traffic using the DSCP field can be implemented by configuring on
coloring has to be switched between the two values over time, the the router output interface an access list that intercepts the
policy needs to be modified periodically: an automatic script is used flow(s) to be monitored and applies to them a policy that sets the
to perform this task on the basis of a fixed timer. DSCP field accordingly. Since traffic coloring has to be switched
between the two values over time, the policy needs to be modified
periodically: an automatic script is used to perform this task on the
basis of a fixed timer. The automatic script is loaded on board of
the router and automatizes the basic operations that are needed to
realize the methodology.
In Telecom Italia's implementation the timer is set to 5 minutes: After the traffic is colored using the DSCP field, all the routers on
this value showed to be a good compromise between measurement the path can perform the counting. For this purpose an access-list
frequency and stability of the measurement (i.e. possibility to that matches specific DSCP values can be used to count the packets of
collect all the measures referring to the same block). the flow(s) being monitored. The same access-list can be installed
on all the routers of the path. In addition, network flow
monitoring, such as provided by IPFIX (RFC 7011 [RFC7011]), can be
used to recognize timestamps of first/last packet of a batch in order
to enable one of the alternatives to measure the delay as detailed in
Section 3.3.
If traffic is colored using the DSCP field an access-list that In the Telecom Italia's experiment the timer is set to 5 minutes, so
matches specific DSCP values can be used to count the packets of the the sequence of actions of the script is also executed every 5
flow(s) being monitored. The access-list is installed on all the minutes. This value has showed to be a good compromise between
routers of the path. In addition, network flow monitoring, such as measurement frequency and stability of the measurement (i.e.
provided by IPFIX (RFC 7011 [RFC7011]), can be used to recognize possibility to collect all the measures referring to the same block).
timestamps of first/last packet of a batch.
The counters are collected by using an automatic script that sends For this expertiment, both counters and any other data are collected
out these to a Network Management System (NMS). The NMS is by using the automatic script that sends out these to a Network
responsible for packet loss calculation, performed by comparing the Management System (NMS). The NMS is responsible for packet loss
values of counters from the routers along the flow(s) path. 5 calculation, performed by comparing the values of counters from the
minutes timer for color switching is a safe choice for reading the routers along the flow(s) path. 5 minutes timer for color switching
counters and is also coherent with the reporting window of the NMS. is a safe choice for reading the counters and is also coherent with
the reporting window of the NMS.
Note that the use of the DSCP field for marking implies that the Note that the use of the DSCP field for marking implies that the
method in this case works reliably only within a single management method in this case works reliably only within a single management
and operation domain. and operation domain.
A flow to monitor can be defined by a set of selection rules (e.g.
headers fields) used to match a subset of the packets; in this way it
is possible to control the number of involved nodes, the path
followed by the packets and the size of the flows. As an example,
the Telecom Italia experiment considers a flow as all the packets
sharing the same source IP address or the same destination IP
address, depending on the direction.
Lastly, the Telecom Italia experiment scales up to 1000 flows Lastly, the Telecom Italia experiment scales up to 1000 flows
monitored together on a single router, while an implementation on monitored together on a single router, while an implementation on
dedicated hardware scales more. dedicated hardware scales more, but it was tested only in labs for
now.
5.1.1. Metric transparency 5.1.1. Metric transparency
Since a Service Provider application is described here, the method Since a Service Provider application is described here, the method
can be applied to end-to-end services supplied to Customers. So it can be applied to end-to-end services supplied to Customers. So it
is important to highlight that the method SHOULD be transparent is important to highlight that the method MUST be transparent outside
outside the Service Provider domain. the Service Provider domain.
In Telecom Italia's implementation the source node colors the packets In Telecom Italia's implementation the source node colors the packets
with a policy that is modified periodically via an automatic script with a policy that is modified periodically via an automatic script
in order to alternate the DSCP field of the packets. The nodes in order to alternate the DSCP field of the packets. The nodes
between source and destination (included) have to count with an between source and destination (included) have to count with an
access-list the colored packets that they receive and forward. access-list the colored packets that they receive and forward.
Moreover the destination node has an important role: the colored Moreover the destination node has an important role: the colored
packets are intercepted and a policy restores and sets the DSCP field packets are intercepted and a policy restores and sets the DSCP field
of all the packets to the initial value. In this way the metric is of all the packets to the initial value. In this way the metric is
transparent because outside the section of the network under transparent because outside the section of the network under
monitoring the traffic flow is unchanged. monitoring the traffic flow is unchanged.
In such a case, thanks to this restoring technique, network elements In such a case, thanks to this restoring technique, network elements
outside the Alternate Marking monitoring domain (e.g. the two outside the Alternate Marking monitoring domain (e.g. the two
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)
This application of marking method is described in
[I-D.chen-ippm-coloring-based-ipfpm-framework]. As an example, in
this document, the last reserved bit of the Flag field of the IPv4
header is proposed to be used for marking, while a solution for IPv6
could be to leverage the IPv6 extension header for marking.
5.3. OAM Passive Performance Measurement
In [I-D.ietf-bier-mpls-encapsulation] two OAM bits from Bit Index
Explicit Replication (BIER) Header are reserved for the passive
performance measurement marking method. [I-D.ietf-bier-pmmm-oam]
details the measurement for multicast service over BIER domain.
In addition, the alternate marking method could also be used in a
Service Function Chaining (SFC) domain.
The application of the marking method to Network Virtualization
Overlays (NVO3) protocols is a work in progress (see
[I-D.ietf-nvo3-encap]).
5.4. RFC6374 Use Case
RFC6374 [RFC6374] uses the LM packet as the packet accounting
demarcation point. Unfortunately this gives rise to a number of
problems that may lead to significant packet accounting errors in
certain situations. [I-D.ietf-mpls-flow-ident] discusses the desired
capabilities for MPLS flow identification in order to perform a
better in-band performance monitoring of user data packets. A method
of accomplishing identification is Synonymous Flow Labels (SFL)
introduced in [I-D.bryant-mpls-sfl-framework], while
[I-D.ietf-mpls-rfc6374-sfl] describes RFC6374 performance
measurements with SFL.
5.5. Application to active performance measurement
[I-D.fioccola-ippm-alt-mark-active] describes how to extend the
existing Active Measurement Protocol, in order to implement alternate
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. So the application of marking and measured as specified before. So the application of marking
method can simplify also the active measurement, as explained in method can simplify also the active measurement, as explained in
[I-D.fioccola-ippm-alt-mark-active]. [I-D.fioccola-ippm-alt-mark-active].
7. Summary 7. Compliance with RFC6390 guidelines
The advantages of the method described in this document are:
o easy implementation: it can be implemented or by using features
already available on major routing platforms as described in
Section 5.1 or by applying an optimized implementation of the
method for both legacy and newest technologies;
o low computational effort: the additional load on processing is
negligible;
o accurate packet loss measurement: single packet loss granularity
is achieved with a passive measurement;
o potential applicability to any kind of packet/frame -based
traffic: Ethernet, IP, MPLS, etc., both unicast and multicast;
o robustness: the method can tolerate out of order packets and it's
not based on "special" packets whose loss could have a negative
impact;
o flexibility: all the timestamp formats are allowed, because they
are managed out-of-band. The format (the Network Time Protocol
(NTP) RFC 5905 [RFC5905] or the IEEE 1588 Precision Time Protocol
(PTP) [IEEE-1588]) depends on the precision you want;
o no interoperability issues: the features required to experiment
and test the method (as described in Section 5.1) are available on
all current routing platforms. Both a centarlized or distributed
solution can be used to harvest data from the routers.
The method doesn't raise any specific need for protocol extension,
but it could be further improved by means of some extension to
existing protocols. Specifically, the use of DiffServ bits for
coloring the packets could not be a viable solution in some cases: a
standard method to color the packets for this specific application
could be beneficial.
8. 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
already been standardized. Nevertheless, it's worth applying already been standardized. Nevertheless, it's worth applying
[RFC6390] guidelines to the present document, in order to provide a [RFC6390] guidelines to the present document, in order to provide a
skipping to change at page 26, line 17 skipping to change at page 25, line 32
provided that the traffic under measurement follows that path. In provided that the traffic under measurement follows that path. In
case of a multi-hop path, the measurements can be performed both case of a multi-hop path, the measurements can be performed both
end-to-end and hop-by-hop. end-to-end and hop-by-hop.
o Measurement Timing: the method have a constraint on the frequency o Measurement Timing: the method have a constraint on the frequency
of measurements. This is detailed in Section 3.2, where it is of measurements. This is detailed in Section 3.2, where it is
specified that the marking period and the guardband interval are specified that the marking period and the guardband interval are
strictly related each other to avoid out of order issues. That is strictly related each other to avoid out of order issues. That is
because, in order to perform a measure, the counter must be in a because, in order to perform a measure, the counter must be in a
steady state and this happens when the traffic is being colored steady state and this happens when the traffic is being colored
with the alternate color. As an example in the Telecom Italia with the alternate color. As an example in the experiment of the
application of the method the time interval is set to 5 minutes, method the time interval is set to 5 minutes, while other
while other optimized implementations can also use a marking optimized implementations can also use a marking period of a few
period of a few seconds. seconds.
o Implementation: the Telecom Italia application of the method uses o Implementation: the experiment of the method uses two encodings of
two encodings of the DSCP field to color the packets; this enables the DSCP field to color the packets; this enables the use of
the use of policy configurations on the router to color the policy configurations on the router to color the packets and
packets and accordingly configure the counter for each color. The accordingly configure the counter for each color. The path
path followed by traffic being measured should be known in advance followed by traffic being measured should be known in advance in
in order to configure the counters along the path and be able to order to configure the counters along the path and be able to
compare the correct values. compare the correct values.
o Verification: both in the Lab and in the operational network the o Verification: both in the Lab and in the operational network the
methodology has been tested and experimented for packet loss and methodology has been tested and experimented for packet loss and
delay measurements by using traffic generators together with delay measurements by using traffic generators together with
precision test instruments and network emulators. precision test instruments and network emulators.
o Use and Applications: the method can be used to measure packet o Use and Applications: the method can be used to measure packet
loss with high precision on live traffic; moreover, by combining loss with high precision on live traffic; moreover, by combining
end-to-end and per-link measurements, the method is useful to end-to-end and per-link measurements, the method is useful to
skipping to change at page 26, line 49 skipping to change at page 26, line 16
o Reporting Model: the value of the counters has to be sent to a o Reporting Model: the value of the counters has to be sent to a
centralized management system that perform the calculations; such centralized management system that perform the calculations; such
samples must contain a reference to the time interval they refer samples must contain a reference to the time interval they refer
to, so that the management system can perform the correct to, so that the management system can perform the correct
correlation; the samples have to be sent while the corresponding correlation; the samples have to be sent while the corresponding
counter is in a steady state (within a time interval), otherwise counter is in a steady state (within a time interval), otherwise
the value of the sample should be stored locally. the value of the sample should be stored locally.
o Dependencies: the values of the counters have to be correlated to o Dependencies: the values of the counters have to be correlated to
the time interval they refer to; moreover, as far the Telecom the time interval they refer to; moreover, as far the experiment
Italia application of the method is based on DSCP values, there of the method is based on DSCP values, there are significant
are significant dependencies on the usage of the DSCP field: it dependencies on the usage of the DSCP field: it must be possible
must be possible to rely on unused DSCP values without affecting to rely on unused DSCP values without affecting QoS-related
QoS-related configuration and behavior; moreover, the intermediate configuration and behavior; moreover, the intermediate nodes must
nodes must not change the value of the DSCP field not to alter the not change the value of the DSCP field not to alter the
measurement. measurement.
o Organization of Results: the method of measurement produces o Organization of Results: the method of measurement produces
singletons. singletons.
o Parameters: currently, the main parameter of the method is the o Parameters: currently, the main parameter of the method is the
time interval used to alternate the colors and read the counters. time interval used to alternate the colors and read the counters.
9. Security Considerations 8. Security Considerations
This document specifies a method to perform measurements in the This document specifies a method to perform measurements in the
context of a Service Provider's network and has not been developed to context of a Service Provider's network and has not been developed to
conduct Internet measurements, so it does not directly affect conduct Internet measurements, so it does not directly affect
Internet security nor applications which run on the Internet. Internet security nor applications which run on the Internet.
However, implementation of this method must be mindful of security However, implementation of this method must be mindful of security
and privacy concerns. and privacy concerns.
There are two types of security concerns: potential harm caused by There are two types of security concerns: potential harm caused by
the measurements and potential harm to the measurements. the measurements and potential harm to the measurements.
o Harm caused by the measurement: the measurements described in this o Harm caused by the measurement: the measurements described in this
document are passive, so there are no new packets injected into document are passive, so there are no new packets injected into
the network causing potential harm to the network itself and to the network causing potential harm to the network itself and to
data traffic. Nevertheless, the method implies modifications on data traffic. Nevertheless, the method implies modifications on
the fly to the IP header of data packets: this must be performed the fly to a header or encapsulation of the data packets: this
in a way that doesn't alter the quality of service experienced by must be performed in a way that doesn't alter the quality of
packets subject to measurements and that preserve stability and service experienced by packets subject to measurements and that
performance of routers doing the measurements. One of the main preserve stability and performance of routers doing the
security threats in OAM protocols is network reconnaissance; an measurements. One of the main security threats in OAM protocols
attacker can gather information about the network performance by is network reconnaissance; an attacker can gather information
passively eavesdropping to OAM messages. The advantage of the about the network performance by passively eavesdropping to OAM
methods described in this document is that the marking bits are messages. The advantage of the methods described in this document
the only information that is exchanged between the network is that the marking bits are the only information that is
devices. Therefore, passive eavesdropping to data plane traffic exchanged between the network devices. Therefore, passive
does not allow attackers to gain information about the network eavesdropping to data plane traffic does not allow attackers to
performance. gain information about the network performance.
o Harm to the measurement: the measurements could be harmed by o Harm to the measurement: the measurements could be harmed by
routers altering the marking of the packets, or by an attacker routers altering the marking of the packets, or by an attacker
injecting artificial traffic. Authentication techniques, such as injecting artificial traffic. Authentication techniques, such as
digital signatures, may be used where appropriate to guard against digital signatures, may be used where appropriate to guard against
injected traffic attacks. Since the measurement itself may be injected traffic attacks. Since the measurement itself may be
affected by routers (or other network devices) along the path of affected by routers (or other network devices) along the path of
IP packets intentionally altering the value of marking bits of IP packets intentionally altering the value of marking bits of
packets, as mentioned above, the mechanism specified in this packets, as mentioned above, the mechanism specified in this
document can be applied just in the context of a controlled document can be applied just in the context of a controlled
domain, and thus the routers (or other network devices) are domain, and thus the routers (or other network devices) are
locally administered and this type of attack can be avoided. In locally administered and this type of attack can be avoided. In
addition, an attacker can't gain information about network addition, an attacker can't gain information about network
performance from a single monitoring point, and must use performance from a single monitoring point, and must use
synchronized monitoring points at multiple points on the path, synchronized monitoring points at multiple points on the path,
because they have to do the same kind of measurement and because they have to do the same kind of measurement and
aggregation that Service Providers using Alternate Marking must aggregation that Service Providers using Alternate Marking must
do. do.
The privacy concerns of network measurement are limited because the The privacy concerns of network measurement are limited because the
method only relies on information contained in the IP header without method only relies on information contained in the header or
any release of user data. encapsulation without any release of user data.Although information
in the header or encapsulation is metadata that can be used to
compromise the privacy of users, the limited marking technique in
this document seems unlikely to substantially increase the existing
privacy risks from header or encapsulation metadata.It might be
theoretically possible to modulate the marking to serve as a covert
channel, but it would have a very low data rate if it is to avoid
adversely affecting the measurement systems that monitor the marking.
Delay attacks are another potential threat in the context of this Delay attacks are another potential threat in the context of this
document. Delay measurement is performed using a specific packet in document. Delay measurement is performed using a specific packet in
each block, marked by a dedicated color bit. Therefore, a man-in- each block, marked by a dedicated color bit. Therefore, a man-in-
the-middle attacker can selectively induce synthetic delay only to the-middle attacker can selectively induce synthetic delay only to
delay-colored packets, causing systematic error in the delay delay-colored packets, causing systematic error in the delay
measurements. As discussed in previous sections, the methods measurements. As discussed in previous sections, the methods
described in this document rely on an underlying time synchronization described in this document rely on an underlying time synchronization
protocol. Thus, by attacking the time protocol an attacker can protocol. Thus, by attacking the time protocol an attacker can
potentially compromise the integrity of the measurement. A detailed potentially compromise the integrity of the measurement. A detailed
discussion about the threats against time protocols and how to discussion about the threats against time protocols and how to
mitigate them is presented in RFC 7384 [RFC7384]. mitigate them is presented in RFC 7384 [RFC7384].
10. IANA Considerations 9. IANA Considerations
There are no IANA actions required. There are no IANA actions required.
11. Acknowledgements 10. 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].
The authors would like to thank Alberto Tempia Bonda, Domenico The authors would like to thank Alberto Tempia Bonda, Domenico
Laforgia, Daniele Accetta and Mario Bianchetti for their contribution Laforgia, Daniele Accetta and Mario Bianchetti for their contribution
to the definition and the implementation of the method. to the definition and the implementation of the method.
12. References The authors would also thank Spencer Dawkins, Carlos Pignataro, Brian
Haberman and Eric Vyncke for their assistance and their detailed and
precious reviews.
12.1. Normative References 11. References
11.1. Normative References
[IEEE-1588] [IEEE-1588]
IEEE 1588-2008, "IEEE Standard for a Precision Clock IEEE 1588-2008, "IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems", July 2008. Control Systems", July 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 29, line 34 skipping to change at page 29, line 14
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, [RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Loss Metric for IP Performance Metrics Ed., "A One-Way Loss Metric for IP Performance Metrics
(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
2016, <https://www.rfc-editor.org/info/rfc7680>. 2016, <https://www.rfc-editor.org/info/rfc7680>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 11.2. Informative References
[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-05 (work in progress), June bryant-mpls-sfl-framework-05 (work in progress), June
2017. 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",
skipping to change at page 30, line 21 skipping to change at page 29, line 49
[I-D.fioccola-ippm-alt-mark-active] [I-D.fioccola-ippm-alt-mark-active]
Fioccola, G., Clemm, A., Bryant, S., Cociglio, M., Fioccola, G., Clemm, A., Bryant, S., Cociglio, M.,
Chandramouli, M., and A. Capello, "Alternate Marking Chandramouli, M., and A. Capello, "Alternate Marking
Extension to Active Measurement Protocol", draft-fioccola- Extension to Active Measurement Protocol", draft-fioccola-
ippm-alt-mark-active-01 (work in progress), March 2017. ippm-alt-mark-active-01 (work in progress), March 2017.
[I-D.fioccola-ippm-multipoint-alt-mark] [I-D.fioccola-ippm-multipoint-alt-mark]
Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto, Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto,
"Multipoint Alternate Marking method for passive and "Multipoint Alternate Marking method for passive and
hybrid performance monitoring", draft-fioccola-ippm- hybrid performance monitoring", draft-fioccola-ippm-
multipoint-alt-mark-00 (work in progress), June 2017. multipoint-alt-mark-01 (work in progress), October 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-10 (work in progress), draft-ietf-bier-mpls-encapsulation-12 (work in progress),
October 2017. October 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-03 (work in progress), October 2017. pmmm-oam-03 (work in progress), October 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-05 (work in progress), July 2017. ietf-mpls-flow-ident-05 (work in progress), July 2017.
[I-D.ietf-mpls-rfc6374-sfl] [I-D.ietf-mpls-rfc6374-sfl]
Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S.,
Mirsky, G., and G. Fioccola, "RFC6374 Synonymous Flow Mirsky, G., and G. Fioccola, "RFC6374 Synonymous Flow
Labels", draft-ietf-mpls-rfc6374-sfl-00 (work in Labels", draft-ietf-mpls-rfc6374-sfl-01 (work in
progress), June 2017. progress), December 2017.
[I-D.ietf-nvo3-encap] [I-D.ietf-nvo3-encap]
Boutros, S., Ganga, I., Garg, P., Manur, R., Mizrahi, T., Boutros, S., Ganga, I., Garg, P., Manur, R., Mizrahi, T.,
Mozes, D., and E. Nordmark, "NVO3 Encapsulation Mozes, D., Nordmark, E., Smith, M., Aldrin, S., and I.
Considerations", draft-ietf-nvo3-encap-00 (work in Bagdonas, "NVO3 Encapsulation Considerations", draft-ietf-
progress), June 2017. nvo3-encap-01 (work in progress), October 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, <https://www.rfc-editor.org/info/rfc5481>. March 2009, <https://www.rfc-editor.org/info/rfc5481>.
 End of changes. 58 change blocks. 
276 lines changed or deleted 269 lines changed or added

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