draft-ietf-ippm-alt-mark-08.txt   draft-ietf-ippm-alt-mark-09.txt 
Network Working Group G. Fioccola, Ed. Network Working Group G. Fioccola, Ed.
Internet-Draft A. Capello, Ed. Internet-Draft A. Capello, Ed.
Intended status: Experimental M. Cociglio Intended status: Experimental M. Cociglio
Expires: March 9, 2018 L. Castaldelli Expires: March 11, 2018 L. Castaldelli
Telecom Italia Telecom Italia
M. Chen, Ed. M. Chen, Ed.
L. Zheng, Ed. L. Zheng, Ed.
Huawei Technologies Huawei Technologies
G. Mirsky, Ed. G. Mirsky, Ed.
ZTE ZTE
T. Mizrahi, Ed. T. Mizrahi, Ed.
Marvell Marvell
September 5, 2017 September 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-08 draft-ietf-ippm-alt-mark-09
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 on the operational Alternate Marking (Coloring) technique. A report is provided in
experiment done at Telecom Italia is explained in order to give an order to explain an example and show the method applicability. This
example and show the method applicability. This technique can be technique can be applied in various situations as detailed in this
applied in various situations as detailed in this document and could document and could be considered passive or hybrid depending on the
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.
Status of This Memo Status of This Memo
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 March 9, 2018. This Internet-Draft will expire on March 11, 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
skipping to change at page 2, line 44 skipping to change at page 2, line 44
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 . . . . . . . . . . . . . . . . . . . . 18 4.2. Data Correlation . . . . . . . . . . . . . . . . . . . . 18
4.3. Packet Re-ordering . . . . . . . . . . . . . . . . . . . 19 4.3. Packet Re-ordering . . . . . . . . . . . . . . . . . . . 19
5. Implementation and deployment . . . . . . . . . . . . . . . . 20 5. Implementation and deployment . . . . . . . . . . . . . . . . 20
5.1. Report on the operational experiment at Telecom Italia . 20 5.1. Report on the operational experiment at Telecom Italia . 20
5.1.1. Metric transparency . . . . . . . . . . . . . . . . . 21 5.1.1. Metric transparency . . . . . . . . . . . . . . . . . 22
5.2. IP flow performance measurement (IPFPM) . . . . . . . . . 22 5.2. IP flow performance measurement (IPFPM) . . . . . . . . . 22
5.3. OAM Passive Performance Measurement . . . . . . . . . . . 22 5.3. OAM Passive Performance Measurement . . . . . . . . . . . 22
5.4. RFC6374 Use Case . . . . . . . . . . . . . . . . . . . . 22 5.4. RFC6374 Use Case . . . . . . . . . . . . . . . . . . . . 23
5.5. Application to active performance measurement . . . . . . 23 5.5. Application to active performance measurement . . . . . . 23
6. Hybrid measurement . . . . . . . . . . . . . . . . . . . . . 23 6. Hybrid measurement . . . . . . . . . . . . . . . . . . . . . 23
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 24 8. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
Nowadays, most of the traffic in Service Providers' networks carries 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
perceived by their customers. On the other hand, performance perceived by their customers. On the other hand, performance
monitoring provides useful information for improving network monitoring provides useful information for improving network
management (e.g. isolation of network problems, troubleshooting, management (e.g. isolation of network problems, troubleshooting,
etc.). etc.).
skipping to change at page 5, line 32 skipping to change at page 5, line 32
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
loss. loss.
The method proposed in this document follows the second approach, but The method proposed in this document follows the second approach, but
it doesn't use additional packets to virtually split the flow in it doesn't use additional packets to virtually split the flow in
blocks. Instead, it "colors" the packets so that the packets blocks. Instead, it "marks" the packets so that the packets
belonging to the same block will have the same color, whilst belonging to the same block will have the same color, whilst
consecutive blocks will have different colors. Each change of color consecutive blocks will have different colors. Each change of color
represents a sort of auto-synchronization signal that guarantees the represents a sort of auto-synchronization signal that guarantees the
consistency of measurements taken by different devices along the consistency of measurements taken by different devices along the path
path. (see also [I-D.cociglio-mboned-multicast-pm] and
[I-D.tempia-opsawg-p3m], where this technique was introduced).
Figure 1 represents a very simple network and shows how the method Figure 1 represents a very simple network and shows how the method
can be used to measure packet loss on different network segments: by can be used to measure packet loss on different network segments: by
enabling the measurement on several interfaces along the path, it is enabling the measurement on several interfaces along the path, it is
possible to perform link monitoring, node monitoring or end-to-end possible to perform link monitoring, node monitoring or end-to-end
monitoring. The method is flexible enough to measure packet loss on monitoring. The method is flexible enough to measure packet loss on
any segment of the network and can be used to isolate the faulty any segment of the network and can be used to isolate the faulty
element. element.
Traffic flow Traffic flow
skipping to change at page 14, line 37 skipping to change at page 14, line 37
receiving side, recording TS(A1)R2, TS(B2)R2 and so on. Since the receiving side, recording TS(A1)R2, TS(B2)R2 and so on. Since the
timestamps refer to specific packets (the first packet of each block) timestamps refer to specific packets (the first packet of each block)
we are sure that timestamps compared to compute delay refer to the we are sure that timestamps compared to compute delay refer to the
same packets. By comparing TS(A1)R1 with TS(A1)R2 (and similarly same packets. By comparing TS(A1)R1 with TS(A1)R2 (and similarly
TS(B2)R1 with TS(B2)R2 and so on) it is possible to measure the delay TS(B2)R1 with TS(B2)R2 and so on) it is possible to measure the delay
between R1 and R2. In order to have more measurements, it is between R1 and R2. In order to have more measurements, it is
possible to take and store more timestamps, referring to other possible to take and store more timestamps, referring to other
packets within each block. packets within each block.
In order to coherently compare timestamps collected on different In order to coherently compare timestamps collected on different
routers, the network nodes must be in sync. Furthermore, a routers, the clocks on the network nodes must be in sync.
measurement is valid only if no packet loss occurs and if packet Furthermore, a measurement is valid only if no packet loss occurs and
misordering can be avoided, otherwise the first packet of a block on if packet misordering can be avoided, otherwise the first packet of a
R1 could be different from the first packet of the same block on R2 block on R1 could be different from the first packet of the same
(f.i. if that packet is lost between R1 and R2 or it arrives after block on R2 (f.i. if that packet is lost between R1 and R2 or it
the next one). arrives after the next one).
The following table shows how timestamps can be used to calculate the The following table shows how timestamps can be used to calculate the
delay between R1 and R2. The first column lists the sequence of delay between R1 and R2. The first column lists the sequence of
blocks while other columns contain the timestamp referring to the blocks while other columns contain the timestamp referring to the
first packet of each block on R1 and R2. The delay is computed as a first packet of each block on R1 and R2. The delay is computed as a
difference between timestamps. For the sake of simplicity, all the difference between timestamps. For the sake of simplicity, all the
values are expressed in milliseconds. values are expressed in milliseconds.
+-------+---------+---------+---------+---------+-------------+ +-------+---------+---------+---------+---------+-------------+
| Block | TS(A)R1 | TS(B)R1 | TS(A)R2 | TS(B)R2 | Delay R1-R2 | | Block | TS(A)R1 | TS(B)R1 | TS(A)R2 | TS(B)R2 | Delay R1-R2 |
skipping to change at page 20, line 5 skipping to change at page 20, line 5
be affected by packet re-ordering. Take a look at the following be affected by packet re-ordering. Take a look at the following
example: example:
Block : 1 | 2 | 3 | 4 | 5 |... Block : 1 | 2 | 3 | 4 | 5 |...
--------|---------|---------|---------|---------|---------|--- --------|---------|---------|---------|---------|---------|---
Node R1 : AAAAAAA | BBBBBBB | AAAAAAA | BBBBBBB | AAAAAAA |... Node R1 : AAAAAAA | BBBBBBB | AAAAAAA | BBBBBBB | AAAAAAA |...
Node R2 : AAAAABB | AABBBBA | AAABAAA | BBBBBBA | ABAAABA |... Node R2 : AAAAABB | AABBBBA | AAABAAA | BBBBBBA | ABAAABA |...
Figure 5: Packet Reordering Figure 5: Packet Reordering
In the following paragraphs an example of data correlation mechanism In Figure 5 the packet stream for Node R1 isn't being reordered, and
is explained and could be use independently of the adopted solutions. can be safely assigned to interval blocks, but the packet stream for
Node R2 is being reordered, so, looking at 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.
Most of the packet re-ordering occur at the edge of adjacent blocks, In general there is the need to assign packets with the marker of "B"
and they are easy to handle if the interval of each block is or "A" to the right interval blocks. Most of the packet re-ordering
sufficient large. Then, it can assume that the packets with occur at the edge of adjacent blocks, and they are easy to handle if
different marker belong to the block that they are more close to. If the interval of each block is sufficient large. Then, it can assume
the interval is small, it is difficult and sometime impossible to that the packets with different marker belong to the block that they
determine to which block a packet belongs. See above example, the are more close to. If the interval is small, it is difficult and
packet with the marker of "B" in block 3, there is no safe way to sometime impossible to determine to which block a packet belongs.
tell whether the packet belongs to block 2 or block 4.
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. 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
skipping to change at page 21, line 28 skipping to change at page 21, line 30
monitoring (set to 1 if the flow is under monitoring, otherwise it is monitoring (set to 1 if the flow is under monitoring, otherwise it is
set to 0), while the second (bit 1) can be used for coloring the set to 0), while the second (bit 1) can be used for coloring the
traffic (switching between values 0 and 1, corresponding to color A traffic (switching between values 0 and 1, corresponding to color A
and B) and creating the blocks. and B) and creating the blocks.
In practice, coloring the traffic using the DSCP field can be In practice, coloring the traffic using the DSCP field can be
implemented by configuring on the router output interface an access implemented by configuring on the router output interface an access
list that intercepts the flow(s) to be monitored and applies to them list that intercepts the flow(s) to be monitored and applies to them
a policy that sets the DSCP field accordingly. Since traffic a policy that sets the DSCP field accordingly. Since traffic
coloring has to be switched between the two values over time, the coloring has to be switched between the two values over time, the
policy needs to be modified periodically: an automatic script can be policy needs to be modified periodically: an automatic script is used
used perform this task on the basis of a fixed timer. In Telecom to perform this task on the basis of a fixed timer.
Italia's implementation this timer is set to 5 minutes: this value
showed to be a good compromise between measurement frequency and In Telecom Italia's implementation the timer is set to 5 minutes:
stability of the measurement (i.e. possibility to collect all the this value showed to be a good compromise between measurement
measures referring to the same block). frequency and stability of the measurement (i.e. possibility to
collect all the measures referring to the same block).
If traffic is colored using the DSCP field an access-list that If traffic is colored using the DSCP field an access-list that
matches specific DSCP values can be used to count the packets of the matches specific DSCP values can be used to count the packets of the
flow(s) being monitored. Also, a 5 minutes timer for color switching flow(s) being monitored. The access-list is installed on all the
is a safe choice for reading the counters. routers of the path. Also, a 5 minutes timer for color switching is
a safe choice for reading the counters.
The counters are collected by using an automatic script that sends
out these to a Network Management System (NMS). The NMS is
responsible for packet loss calculation, performed by comparing the
values of counters from the routers along the flow(s) path.
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 SHOULD be transparent
outside the Service Provider domain. outside 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
 End of changes. 16 change blocks. 
40 lines changed or deleted 50 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/