draft-ietf-ippm-alt-mark-00.txt   draft-ietf-ippm-alt-mark-01.txt 
Network Working Group A. Capello Network Working Group G. Fioccola, Ed.
Internet-Draft M. Cociglio Internet-Draft A. Capello, Ed.
Intended status: Experimental G. Fioccola Intended status: Experimental M. Cociglio
Expires: December 12, 2016 L. Castaldelli Expires: January 8, 2017 L. Castaldelli
Telecom Italia Telecom Italia
A. Tempia Bonda M. Chen, Ed.
June 10, 2016 L. Zheng, Ed.
Huawei Technologies
G. Mirsky, Ed.
Ericsson
T. Mizrahi, Ed.
Marvell
July 7, 2016
Alternate Marking method for passive performance monitoring Alternate Marking method for passive performance monitoring
draft-ietf-ippm-alt-mark-00 draft-ietf-ippm-alt-mark-01
Abstract Abstract
This document describes a passive method to perform packet loss, This document describes a passive method to perform packet loss,
delay and jitter measurements on live traffic. This method is based delay and jitter measurements on live traffic. This method is based
on Alternate Marking (Coloring) technique. A report on the on Alternate Marking (Coloring) technique. A report on the
operational experiment done at Telecom Italia is explained in order operational experiment done at Telecom Italia is explained in order
to give an example and show the method applicability. This technique to give an example and show the method applicability. This technique
can be applied in various situations as detailed in this document. can be applied in various situations as detailed in this document.
skipping to change at page 1, line 38 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 12, 2016. This Internet-Draft will expire on January 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 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.2. One-way delay measurement . . . . . . . . . . . . . . . . 9 3.2. One-way delay measurement . . . . . . . . . . . . . . . . 10
3.2.1. Single marking methodology . . . . . . . . . . . . . 9 3.2.1. Single marking methodology . . . . . . . . . . . . . 10
3.2.2. Average delay . . . . . . . . . . . . . . . . . . . . 11 3.2.2. Average delay . . . . . . . . . . . . . . . . . . . . 11
3.2.3. Double marking methodology . . . . . . . . . . . . . 11 3.2.3. Double marking methodology . . . . . . . . . . . . . 12
3.3. Delay variation measurement . . . . . . . . . . . . . . . 12 3.3. Delay variation measurement . . . . . . . . . . . . . . . 13
4. Implementation and deployment . . . . . . . . . . . . . . . . 12 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Report on the operational experiment at Telecom Italia . 13 4.1. Synchronization . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Coloring the packets . . . . . . . . . . . . . . . . 14 4.2. Data Correlation . . . . . . . . . . . . . . . . . . . . 14
4.1.2. Counting the packets . . . . . . . . . . . . . . . . 15 4.3. Packet Re-ordering . . . . . . . . . . . . . . . . . . . 15
4.1.3. Collecting data and calculating packet loss . . . . . 16 5. Implementation and deployment . . . . . . . . . . . . . . . . 15
4.1.4. Metric transparency . . . . . . . . . . . . . . . . . 17 5.1. Report on the operational experiment at Telecom Italia . 15
4.2. IP flow performance measurement (IPFPM) . . . . . . . . . 17 5.1.1. Coloring the packets . . . . . . . . . . . . . . . . 17
4.3. Performance Measurement Marking Method in BIER Domain . . 17 5.1.2. Counting the packets . . . . . . . . . . . . . . . . 18
4.4. RFC6374 Use Case . . . . . . . . . . . . . . . . . . . . 17 5.1.3. Collecting data and calculating packet loss . . . . . 19
4.5. Application to active performance measurement . . . . . . 18 5.1.4. Metric transparency . . . . . . . . . . . . . . . . . 20
5. Hybrid measurement . . . . . . . . . . . . . . . . . . . . . 18 5.2. IP flow performance measurement (IPFPM) . . . . . . . . . 20
6. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 18 5.3. Performance Measurement Marking Method in BIER Domain . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5.4. Overlay OAM Passive Performance Measurement . . . . . . . 20
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.5. RFC6374 Use Case . . . . . . . . . . . . . . . . . . . . 21
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 5.6. Application to active performance measurement . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 6. Hybrid measurement . . . . . . . . . . . . . . . . . . . . . 21
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . 22 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Nowadays, most of the traffic in Service Providers' networks carries Nowadays, most of the traffic in Service Providers' networks carries
real time content. These contents are highly sensitive to packet real time content. These contents are highly sensitive to packet
loss [RFC2680], while interactive contents are sensitive to delay loss [RFC2680], while interactive contents are sensitive to delay
[RFC2679], and jitter [RFC3393]. [RFC2679], and jitter [RFC3393].
In view of this scenario, Service Providers need methodologies and In view of this scenario, Service Providers need methodologies and
tools to monitor and measure network performances with an adequate tools to monitor and measure network performances with an adequate
skipping to change at page 4, line 15 skipping to change at page 4, line 28
[I-D.mirsky-bier-pmmm-oam] [I-D.mirsky-bier-pmmm-oam]
[I-D.chen-ippm-coloring-based-ipfpm-framework]). [I-D.chen-ippm-coloring-based-ipfpm-framework]).
This document is organized as follows: This document is organized as follows:
o Section 2 gives an overview of the method, including a comparison o Section 2 gives an overview of the method, including a comparison
with different measurement strategies; with different measurement strategies;
o Section 3 describes the method in detail; o Section 3 describes the method in detail;
o Section 4 reports examples of implementation and deployment of the o Section 4 reports considerations about synchronization, data
correlation and packet re-ordering;
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 5 includes some considerations about security aspects; o Section 8 includes some security aspects;
o Section 6 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
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
skipping to change at page 12, line 36 skipping to change at page 13, line 25
depicted in Figure 4, R1 stores a timestamp TS(A)R1 whenever it sends depicted in Figure 4, R1 stores a timestamp TS(A)R1 whenever it sends
the first packet of a block and R2 stores a timestamp TS(B)R2 the first packet of a block and R2 stores a timestamp TS(B)R2
whenever it receives the first packet of a block. The inter-arrival whenever it receives the first packet of a block. The inter-arrival
jitter can be easily derived from one-way delay measurement, by jitter can be easily derived from one-way delay measurement, by
evaluating the delay variation of consecutive samples. evaluating the delay variation of consecutive samples.
The concept of average delay can also be applied to delay variation, The concept of average delay can also be applied to delay variation,
by evaluating the variation of average interval between consecutive by evaluating the variation of average interval between consecutive
packets of the flow from R1 to R2. packets of the flow from R1 to R2.
4. Implementation and deployment 4. Considerations
This section highlights some considerations about the methodology.
4.1. Synchronization
There are two mechanisms in Alternate Marking technique that require
network devices to have synchronized clocks: packet loss and one-way
delay measurement.
If the length of the measurement period is L time units, then all
network devices must be synchronized to the same clock reference with
an accuracy of +/- L/2 time units. This level of accuracy guarantees
that all network devices consistently match the color bit to the
correct block. For example, if the color is toggeled every second (L
= 1 second), then clocks must be synchronized with an accuracy of +/-
0.5 second to a common time reference.
The synchronization requirement can be satisfied even with a
relatively inaccurate synchronization method.
Notably, two-way delay measurement does not require the network
devices to be time synchronized. Therefore, a system that uses only
two-way delay measurement does not require synchronization. This is
because the value of the clocks of network devices does not affect
the computation of the two-way delay measurement, and synchronization
is not required.
4.2. Data Correlation
Data Correlation could be performed in several ways depending on the
the alternate marking application and use case.
o A possibility is to use a centralized solution using Network
Management System (NMS) to correlate data;
o Another possibility is to define a protocol based distributed
solution, by defining a new protocol or by extending the existing
protocols (e.g. RFC6374, TWAMP, OWAMP) in order to communicate
the counters and timestamps between nodes.
In the following paragraphs an example data correlation mechanism is
explained and could be use independently of the adopted solutions.
When data is collected on the upstream and downstream node, e.g.,
packet counts for packet loss measurement or timestamps for packet
delay measurement, and periodically reported to or pulled by other
nodes or NMS, a certain data correlation mechanism SHOULD be in use
to help the nodes or NMS to tell whether any two or more packet
counts are related to the same block of markers, or any two
timestamps are related to the same marked packet.
The alternate marking method described in this document literally
split the packets of the measured flow into different measurement
blocks, in addition a Block Number could be assigned to each of such
measurement block. The BN is generated each time a node reads the
data (packet counts or timestamps), and is associated with each
packet count and timestamp reported to or pulled by other nodes or
NMS. The value of BN could be calculated as the modulo of the local
time (when the data are read) and the interval of the marking time
period.
When the nodes or NMS see, for example, same BNs associated with two
packet counts from an upstream and a downstream node respectively, it
considers that these two packet counts corresponding to the same
block, i.e. that these two packet counts belong to the same block of
markers from the upstream and downstream node. The assumption of
this BN mechanism is that the measurement nodes are time
synchronized. This requires the measurement nodes to have a certain
time synchronization capability (e.g., the Network Time Protocol
(NTP) [RFC5905], or the IEEE 1588 Precision Time Protocol (PTP)
[IEEE1588]). Synchronization aspects are further discussed in
Section 4.
4.3. Packet Re-ordering
Due to ECMP, packet re-ordering is very common in IP network. The
accuracy of marking based PM, especially packet loss measurement, may
be affected by packet re-ordering. Take a look at the following
example:
Block : 1 | 2 | 3 | 4 | 5 |...
--------|---------|---------|---------|---------|---------|---
Node R1 : AAAAAAA | BBBBBBB | AAAAAAA | BBBBBBB | AAAAAAA |...
Node R2 : AAAAABB | AABBBBA | AAABAAA | BBBBBBA | ABAAABA |...
Figure 4: Packet Reordering
In the following paragraphs an example data correlation mechanism is
explained and could be use independently of the adopted solutions.
Most of the packet re-ordering occur at the edge of adjacent blocks,
and they are easy to handle if the interval of each block is
sufficient large. Then, it can assume 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 sometime impossible to
determine to which block a packet belongs. See above example, the
packet with the marker of "B" in block 3, there is no safe way to
tell whether the packet belongs to block 2 or block 4.
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
SHOULD provide a way to configure the interval and allow a certain
degree of packet re-ordering.
5. 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.
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.
4.1. Report on the operational experiment at Telecom Italia 5.1. Report on the operational experiment at Telecom Italia
The methodology has been applied in Telecom Italia by leveraging The methodology has been applied in Telecom Italia by leveraging
functions and tools available on IP routers and it's currently being functions and tools available on IP routers and it's currently being
used to monitor packet loss in some portions of Telecom Italia's used to monitor packet loss in some portions of Telecom Italia's
network. The application of the method to delay measurement is network. The application of the method to delay measurement is
currently being evaluated in Telecom Italia's labs. This section currently being evaluated in Telecom Italia's labs. This section
describes how the features currently available on existing routing describes how the features currently available on existing routing
platforms can be used to apply the method, in order to give an platforms can be used to apply the method, in order to give an
example of implementation and deployment. example of implementation and deployment.
skipping to change at page 14, line 36 skipping to change at page 17, line 31
path: the mechanism is completely transparent to intermediate nodes path: the mechanism is completely transparent to intermediate nodes
and independent from the path followed by traffic flows. On the and independent from the path followed by traffic flows. On the
contrary, to monitor the flow on a hop-by-hop basis along its whole contrary, to monitor the flow on a hop-by-hop basis along its whole
path it is necessary to enable the monitoring on every node from the path it is necessary to enable the monitoring on every node from the
source to the destination. In case the exact path followed by the source to the destination. In case the exact path followed by the
flow is not known a priori (i.e. the flow has multiple paths to reach flow is not known a priori (i.e. the flow has multiple paths to reach
the destination) it is necessary to enable the monitoring system on the destination) it is necessary to enable the monitoring system on
every path: counters on interfaces traversed by the flow will report every path: counters on interfaces traversed by the flow will report
packet count, counters on other interfaces will be null. packet count, counters on other interfaces will be null.
4.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 necessary 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
skipping to change at page 15, line 37 skipping to change at page 18, line 32
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 ca 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).
4.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
skipping to change at page 16, line 34 skipping to change at page 19, line 29
Alternatively, if the coloring operation is performed on the basis of Alternatively, if the coloring operation is performed on the basis of
a fixed timer, it is possible to configure the reading of the a fixed timer, it is possible to configure the reading of the
counters according to that timer: for example, if each block is 5 counters according to that timer: for example, if each block is 5
minutes long, reading the counter for color A every 5 minute in the minutes long, reading the counter for color A every 5 minute in the
middle of the subsequent block (with color B) is a safe choice. A middle of the subsequent block (with color B) is a safe choice. A
sufficient margin should be considered between the end of a block and sufficient margin should be considered between the end of a block and
the reading of the counter, in order to take into account any out-of- the reading of the counter, in order to take into account any out-of-
order packets. The choice of a 5 minutes timer for colore switching order packets. The choice of a 5 minutes timer for colore switching
was also inspired by these considerations. was also inspired by these considerations.
4.1.3. Collecting data and calculating packet loss 5.1.3. Collecting data and calculating packet loss
The nodes enabled to perform performance monitoring collect the value The nodes enabled to perform performance monitoring collect the value
of the counters, but they are not able to directly use this of the counters, but they are not able to directly use this
information to measure packet loss, because they only have their own information to measure packet loss, because they only have their own
samples. For this reason, an external Network Management System samples. For this reason, an external Network Management System
(NMS) is required to collect and elaborate data and to perform packet (NMS) is required to collect and elaborate data and to perform packet
loss calculation. The NMS compares the values of counters from loss calculation. The NMS compares the values of counters from
different nodes and can calculate if some packets were lost (even a different nodes and can calculate if some packets were lost (even a
single packet) and also where packets were lost. single packet) and also where packets were lost.
skipping to change at page 17, line 13 skipping to change at page 20, line 7
information. In any case, the NMS has to collect all the relevant information. In any case, the NMS has to collect all the relevant
values from all the routers within one cycle of the timer (5 values from all the routers within one cycle of the timer (5
minutes). minutes).
If link-based measurement is used, it would be possible to use a If link-based measurement is used, it would be possible to use a
protocol to exchange values of counters between the two endpoints in protocol to exchange values of counters between the two endpoints in
order to let them perform the packet loss calculation for each order to let them perform the packet loss calculation for each
traffic direction. A similar approach could be complicated if traffic direction. A similar approach could be complicated if
applied to a flow-based measurement. applied to a flow-based measurement.
4.1.4. Metric transparency 5.1.4. Metric transparency
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.
4.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].
4.3. Performance Measurement Marking Method in BIER Domain 5.3. Performance Measurement Marking Method in BIER Domain
In [I-D.ietf-bier-mpls-encapsulation] two OAM bits from Bit Index In [I-D.ietf-bier-mpls-encapsulation] two OAM bits from Bit Index
Explicit Replication (BIER) Header are reserved for the passive Explicit Replication (BIER) Header are reserved for the passive
performance measurement marking method. [I-D.mirsky-bier-pmmm-oam] performance measurement marking method. [I-D.mirsky-bier-pmmm-oam]
details the measurement for multicast service over BIER domain. details the measurement for multicast service over BIER domain.
4.4. RFC6374 Use Case 5.4. Overlay OAM Passive Performance Measurement
The Overlay OAM Design Team is considering the preliminary OAM
requirements from NVO3, BIER, and SFC. Marking Method is the
preferred passive method to measure performance.
[I-D.ooamdt-rtgwg-ooam-requirement] and
[I-D.ooamdt-rtgwg-oam-gap-analysis] explain in deep this item.
5.5. 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.bryant-mpls-rfc6374-sfl] describes RFC6374 performance
measurements with SFL. measurements with SFL.
4.5. Application to active performance measurement 5.6. Application to active performance measurement
[I-D.fioccola-ippm-rfc6812-alt-mark-ext] describes an extension to [I-D.fioccola-ippm-rfc6812-alt-mark-ext] describes an extension to
the Cisco SLA Protocol Measurement-Type UDP-Measurement, in order to the Cisco SLA Protocol Measurement-Type UDP-Measurement, in order to
implement alternate marking methodology. implement alternate marking methodology.
5. Hybrid measurement 6. Hybrid measurement
The method has been explicitly designed for passive measurements but The method has been explicitly designed for passive measurements but
it can also be used with active measurements. In order to have both it can also be used with active measurements. In order to have both
end to end measurements and intermediate measurements (hybrid end to end measurements and intermediate measurements (hybrid
measurements) two end points can exchanges artificial traffic flows measurements) two end points can exchanges artificial traffic flows
and apply alternate marking over these flows. In the intermediate and apply alternate marking over these flows. In the intermediate
points artificial traffic is managed in the same way as real traffic points artificial traffic is managed in the same way as real traffic
and measured as specified before. and measured as specified before.
6. Compliance with RFC6390 guidelines 7. Compliance with RFC6390 guidelines
RFC6390 [RFC6390] defines a framework and a process for developing RFC6390 [RFC6390] defines a framework and a process for developing
Performance Metrics for protocols above and below the IP layer (such Performance Metrics for protocols above and below the IP layer (such
as IP-based applications that operate over reliable or datagram as IP-based applications that operate over reliable or datagram
transport protocols). transport protocols).
This document doesn't aim to propose a new Performance Metric but a This document doesn't aim to propose a new Performance Metric but a
new method of measurement for a few Performance Metrics that have new method of measurement for a few Performance Metrics that have
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 20, line 13 skipping to change at page 23, line 20
QoS-related configuration and behavior; moreover, the intermediate QoS-related configuration and behavior; moreover, the intermediate
nodes must not change the value of the DSCP field not to alter the nodes must 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.
7. 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. For what the measurements and potential harm to the measurements. For what
concerns the first point, the measurements described in this document concerns the first point, the measurements described in this document
are passive, so there are no packets injected into the network are passive, so there are no packets injected into the network
causing potential harm to the network itself and to data traffic. causing potential harm to the network itself and to data traffic.
Nevertheless, the method implies modifications on the fly to the IP Nevertheless, the method implies modifications on the fly to the IP
header of data packets: this must be performed in a way that doesn't header of data packets: this must be performed in a way that doesn't
alter the quality of service experienced by packets subject to alter the quality of service experienced by packets subject to
measurements and that preserve stability and performance of routers measurements and that preserve stability and performance of routers
doing the measurements. The measurements themselves could be harmed doing the measurements. The measurements themselves could be harmed
by routers altering the coloring of the packets, or by an attacker by 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. injected traffic attacks.
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 IP header without
any release of user data. any release of user data.
8. Conclusions The measurement itself may be affected by routers (or other network
devices) along the path of IP packets intentionally altering the
value of marking bits of packets. As mentioned above, the mechanism
specified in this document is just in the context of one Service
Provider's network, and thus the routers (or other network devices)
are locally administered and this type of attack can be avoided.
One of the main security threats in OAM protocols is network
reconnaissance; an attacker can gather information about the network
performance by passively eavesdropping to OAM messages. The
advantage of the methods described in this document is that the
marking bits are the only information that is exchanged between the
network devices. Therefore, passive eavesdropping to data plane
traffic does not allow attackers to gain information about the
network performance.
Delay attacks are another potential threat in the context of this
document. Delay measurement is performed using a specific packet in
each block, marked by a dedicated color bit. Therefore, a man-in-
the-middle attacker can selectively induce synthetic delay only to
delay-colored packets, causing systematic error in the delay
measurements. As discussed in previous sections, the methods
described in this document rely on an underlying time synchronization
protocol. Thus, by attacking the time protocol an attacker can
potentially compromise the integrity of the measurement. A detailed
discussion about the threats against time protocols and how to
mitigate them is presented in RFC 7384 [RFC7384].
9. Conclusions
The advantages of the method described in this document are: The advantages of the method described in this document are:
o easy implementation: it can be implemented using features already o easy implementation: it can be implemented using features already
available on major routing platforms; available on major routing platforms;
o low computational effort: the additional load on processing is o low computational effort: the additional load on processing is
negligible; negligible;
o accurate packet loss measurement: single packet loss granularity o accurate packet loss measurement: single packet loss granularity
skipping to change at page 21, line 25 skipping to change at page 25, line 12
o no interoperability issues: the features required to implement the o no interoperability issues: the features required to implement the
method are available on all current routing platforms. method are available on all current routing platforms.
The method doesn't raise any specific need for standardization, but The method doesn't raise any specific need for standardization, but
it could be further improved by means of some extension to existing it could be further improved by means of some extension to existing
protocols. Specifically, the use of DiffServ bits for coloring the protocols. Specifically, the use of DiffServ bits for coloring the
packets could not be a viable solution in some cases: a standard packets could not be a viable solution in some cases: a standard
method to color the packets for this specific application could be method to color the packets for this specific application could be
beneficial. beneficial.
9. IANA Considerations 10. IANA Considerations
There are no IANA actions required. There are no IANA actions required.
10. Acknowledgements 11. Acknowledgements
The authors would like to thank Domenico Laforgia, Daniele Accetta The authors would like to thank Domenico Laforgia, Daniele Accetta
and Mario Bianchetti for their contribution to the definition and the and Mario Bianchetti for their contribution to the definition and the
implementation of the method. implementation of the method.
11. References 12. References
11.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
Packet Loss Metric for IPPM", RFC 2680, Packet Loss Metric for IPPM", RFC 2680,
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>.
11.2. Informative References 12.2. Informative References
[I-D.bryant-mpls-rfc6374-sfl] [I-D.bryant-mpls-rfc6374-sfl]
Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen, Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen,
M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft- M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft-
bryant-mpls-rfc6374-sfl-00 (work in progress), October bryant-mpls-rfc6374-sfl-00 (work in progress), October
2015. 2015.
[I-D.bryant-mpls-sfl-framework] [I-D.bryant-mpls-sfl-framework]
Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen, Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen,
M., and Z. Li, "Synonymous Flow Label Framework", draft- M., and Z. Li, "Synonymous Flow Label Framework", draft-
bryant-mpls-sfl-framework-00 (work in progress), October bryant-mpls-sfl-framework-01 (work in progress), June
2015. 2016.
[I-D.chen-ippm-coloring-based-ipfpm-framework] [I-D.chen-ippm-coloring-based-ipfpm-framework]
Chen, M., Zheng, L., Mirsky, G., Fioccola, G., and T. Chen, M., Zheng, L., Mirsky, G., Fioccola, G., and T.
Mizrahi, "IP Flow Performance Measurement Framework", Mizrahi, "IP Flow Performance Measurement Framework",
draft-chen-ippm-coloring-based-ipfpm-framework-06 (work in draft-chen-ippm-coloring-based-ipfpm-framework-06 (work in
progress), March 2016. progress), March 2016.
[I-D.cociglio-mboned-multicast-pm] [I-D.cociglio-mboned-multicast-pm]
Cociglio, M., Capello, A., Bonda, A., and L. Castaldelli, Cociglio, M., Capello, A., Bonda, A., and L. Castaldelli,
"A method for IP multicast performance monitoring", draft- "A method for IP multicast performance monitoring", draft-
skipping to change at page 22, line 46 skipping to change at page 26, line 32
[I-D.ietf-bier-mpls-encapsulation] [I-D.ietf-bier-mpls-encapsulation]
Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and
S. Aldrin, "Encapsulation for Bit Index Explicit S. Aldrin, "Encapsulation for Bit Index Explicit
Replication in MPLS Networks", draft-ietf-bier-mpls- Replication in MPLS Networks", draft-ietf-bier-mpls-
encapsulation-04 (work in progress), April 2016. encapsulation-04 (work in progress), April 2016.
[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-00 (work in progress), December 2015. ietf-mpls-flow-ident-01 (work in progress), June 2016.
[I-D.mirsky-bier-pmmm-oam] [I-D.mirsky-bier-pmmm-oam]
Mirsky, G., Zheng, L., Chen, M., and G. Fioccola, Mirsky, G., Zheng, L., Chen, M., and G. Fioccola,
"Performance Measurement (PM) with Marking Method in Bit "Performance Measurement (PM) with Marking Method in Bit
Index Explicit Replication (BIER) Layer", draft-mirsky- Index Explicit Replication (BIER) Layer", draft-mirsky-
bier-pmmm-oam-01 (work in progress), March 2016. bier-pmmm-oam-01 (work in progress), March 2016.
[I-D.ooamdt-rtgwg-oam-gap-analysis]
Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N., Kumar,
D., Chen, M., Mozes, D., and J. Networks, "Operations,
Administration and Maintenance (OAM) for Overlay Networks:
Gap Analysis", draft-ooamdt-rtgwg-oam-gap-analysis-01
(work in progress), March 2016.
[I-D.ooamdt-rtgwg-ooam-requirement]
Kumar, N., Pignataro, C., Kumar, D., Mirsky, G., Chen, M.,
Nordmark, E., Networks, J., and D. Mozes, "Overlay OAM
Requirements", draft-ooamdt-rtgwg-ooam-requirement-00
(work in progress), March 2016.
[I-D.tempia-opsawg-p3m] [I-D.tempia-opsawg-p3m]
Capello, A., Cociglio, M., Castaldelli, L., and A. Bonda, Capello, A., Cociglio, M., Castaldelli, L., and A. Bonda,
"A packet based method for passive performance "A packet based method for passive performance
monitoring", draft-tempia-opsawg-p3m-04 (work in monitoring", draft-tempia-opsawg-p3m-04 (work in
progress), February 2014. progress), February 2014.
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011, DOI 10.17487/RFC6374, September 2011,
<http://www.rfc-editor.org/info/rfc6374>. <http://www.rfc-editor.org/info/rfc6374>.
skipping to change at page 23, line 32 skipping to change at page 27, line 32
IP Network Performance Metrics: Different Points of View", IP Network Performance Metrics: Different Points of View",
RFC 6703, DOI 10.17487/RFC6703, August 2012, RFC 6703, DOI 10.17487/RFC6703, August 2012,
<http://www.rfc-editor.org/info/rfc6703>. <http://www.rfc-editor.org/info/rfc6703>.
[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
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <http://www.rfc-editor.org/info/rfc7384>.
Authors' Addresses Authors' Addresses
Alessandro Capello Giuseppe Fioccola (editor)
Telecom Italia Telecom Italia
Via Reiss Romoli, 274 Via Reiss Romoli, 274
Torino 10148 Torino 10148
Italy Italy
Email: alessandro.capello@telecomitalia.it Email: giuseppe.fioccola@telecomitalia.it
Alessandro Capello (editor)
Mauro Cociglio
Telecom Italia Telecom Italia
Via Reiss Romoli, 274 Via Reiss Romoli, 274
Torino 10148 Torino 10148
Italy Italy
Email: mauro.cociglio@telecomitalia.it Email: alessandro.capello@telecomitalia.it
Giuseppe Fioccola
Mauro Cociglio
Telecom Italia Telecom Italia
Via Reiss Romoli, 274 Via Reiss Romoli, 274
Torino 10148 Torino 10148
Italy Italy
Email: giuseppe.fioccola@telecomitalia.it Email: mauro.cociglio@telecomitalia.it
Luca Castaldelli Luca Castaldelli
Telecom Italia Telecom Italia
Via Reiss Romoli, 274 Via Reiss Romoli, 274
Torino 10148 Torino 10148
Italy Italy
Email: luca.castaldelli@telecomitalia.it Email: luca.castaldelli@telecomitalia.it
Alberto Tempia Bonda Mach(Guoyi) Chen (editor)
Huawei Technologies
Email: alberto.tempia@gmail.com Email: mach.chen@huawei.com
Lianshu Zheng (editor)
Huawei Technologies
Email: vero.zheng@huawei.com
Greg Mirsky (editor)
Ericsson
USA
Email: gregory.mirsky@ericsson.com
Tal Mizrahi (editor)
Marvell
6 Hamada st.
Yokneam
Israel
Email: talmi@marvell.com
 End of changes. 40 change blocks. 
69 lines changed or deleted 242 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/