draft-ietf-ippm-alt-mark-10.txt   draft-ietf-ippm-alt-mark-11.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: March 15, 2018 L. Castaldelli Expires: April 5, 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
September 11, 2017 October 2, 2017
Alternate Marking method for passive and hybrid performance monitoring Alternate Marking method for passive and hybrid performance monitoring
draft-ietf-ippm-alt-mark-10 draft-ietf-ippm-alt-mark-11
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 technique 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.
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 15, 2018. This Internet-Draft will expire on April 5, 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 46 skipping to change at page 2, line 46
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 . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . 23
5.4. RFC6374 Use Case . . . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 24 8. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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 4, line 38 skipping to change at page 4, line 38
o Section 4 reports considerations about synchronization, data o Section 4 reports considerations about synchronization, data
correlation and packet re-ordering; correlation and packet re-ordering;
o Section 5 reports examples of implementation and deployment of the o Section 5 reports examples of implementation and deployment of the
method. Furthermore the operational experiment done at Telecom method. Furthermore the operational experiment done at Telecom
Italia is described; Italia is described;
o Section 6 introduces Hybrid measurement aspects; o Section 6 introduces Hybrid measurement aspects;
o Section 7 is about the Compliance with RFC6390 guidelines; o Section 7 finally summarizes some concluding remarks.
o Section 8 includes some security aspects; o Section 8 is about the compliance with RFC6390 guidelines;
o Section 9 finally summarizes some concluding remarks. o Section 9 includes some security aspects;
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 11, line 18 skipping to change at page 11, line 18
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 advantageous to color the flow as color the same flow). Thus it is advantageous to color the flow as
close as possible to the source. In addition, coloring a flow close close as possible to the source. In addition, coloring a flow close
to the source allows an end-to-end measure if a measurement point is to the source allows an end-to-end measure if a measurement point is
enabled on the last-hop router as well. The only requirement is that enabled on the last-hop router as well. The only requirement is that
the coloring must change periodically and every node along the path the coloring must change periodically and every node, that is
must be able to identify unambiguously the colored packets. For designated as a measurement point along the path, should be able to
link-based measurements, all traffic needs to be colored when identify unambiguously the colored packets. For link-based
transmitted on the link. If the traffic had already been colored, measurements, all traffic needs to be colored when transmitted on the
then it has to be re-colored because the color must be consistent on link. If the traffic had already been colored, then it has to be re-
the link. This means that each hop along the path must (re-)color colored because the color must be consistent on the link. This means
the traffic; the color is not required to be consistent along that each hop along the path must (re-)color the traffic; the color
different links. is not required to be consistent along 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. scope here. However some examples are reported in Section 5.
3.1.2. Counting the packets 3.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).
skipping to change at page 17, line 17 skipping to change at page 17, line 17
packet is lost, the delay measurement for the considered block is packet is lost, the delay measurement for the considered block is
corrupted and should be discarded. corrupted and should be discarded.
Mean delay is calculated on all the packets of a sample and is a Mean delay is calculated on all the packets of a sample and is a
simple computation to be performed for single marking method. In simple computation to be performed for single marking method. In
some cases the mean delay measure is not sufficient to characterize some cases the mean delay measure is not sufficient to characterize
the sample, and more statistics of delay extent data are needed, e.g. the sample, and more statistics of delay extent data are needed, e.g.
percentiles, variance and median delay values. The conventional percentiles, variance and median delay values. The conventional
range (maximum-minimum) should be avoided for several reasons, range (maximum-minimum) should be avoided for several reasons,
including stability of the maximum delay due to the influence by including stability of the maximum delay due to the influence by
outliers. RFC 5481 [RFC5481] section 6.5 highlights how the 99.9th outliers. RFC 5481 [RFC5481] Section 6.5 highlights how the 99.9th
percentile of delay and delay variation is more helpful to percentile of delay and delay variation is more helpful to
performance planners. To overcome this drawback the idea is to performance planners. To overcome this drawback the idea is to
couple the mean delay measure for the entire batch with double couple the mean delay measure for the entire batch with double
marking method, where a subset of batch packets are selected for marking method, where a subset of batch packets are selected for
extensive delay calculation by using a second marking. In this way extensive delay calculation by using a second marking. In this way
it is possible to perform a detailed analysis on these double marked it is possible to perform a detailed analysis on these double marked
packets. Please note that there are classic algorithms for median packets. Please note that there are classic algorithms for median
and variance calculation, but are out of the scope of this document. and variance calculation, but are out of the scope of this document.
The comparison between the mean delay for the entire batch and the The comparison between the mean delay for the entire batch and the
mean delay on these double marked packets gives an useful information mean delay on these double marked packets gives an useful information
skipping to change at page 20, line 51 skipping to change at page 20, line 51
network. The methodology has been applied by leveraging functions network. The methodology has been applied by leveraging functions
and tools available on IP routers and it's currently being used to and tools available on IP routers and it's currently being used to
monitor packet loss in some portions of Telecom Italia's network. monitor packet loss in some portions of Telecom Italia's network.
The application of the method to delay measurement is currently being The application of the method to delay measurement is currently being
evaluated in Telecom Italia's labs. This section describes how the evaluated in Telecom Italia's labs. This section describes how the
features currently available on existing routing platforms can be features currently available on existing routing platforms can be
used to apply the method, in order to give an example of used to apply the method, in order to give an example of
implementation and deployment. implementation and deployment.
The current implementation in Telecom Italia uses the flow-based The current implementation in Telecom Italia uses the flow-based
strategy, as defined in section 3. The link-based strategy could be strategy, as defined in Section 3. 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 method is applied in Telecom Italia's network to multicast IPTV
channels or other specific traffic flows with high QoS requirements channels or other specific traffic flows with high QoS requirements
(i.e. Mobile Backhauling traffic implemented with a VPN MPLS). (i.e. Mobile Backhauling traffic implemented with a VPN MPLS).
The implementation of the method by a Service Provider needs to use The implementation of the method by a Service Provider needs to use
the router features. With current router implementations, only QoS the router features. With current router implementations, only QoS
related fields and features offer the required flexibility to set related fields and features offer the required flexibility to set
skipping to change at page 21, line 41 skipping to change at page 21, line 41
to perform this task on the basis of a fixed timer. to perform this task on the basis of a fixed timer.
In Telecom Italia's implementation the timer is set to 5 minutes: In Telecom Italia's implementation the timer is set to 5 minutes:
this value showed to be a good compromise between measurement this value showed to be a good compromise between measurement
frequency and stability of the measurement (i.e. possibility to frequency and stability of the measurement (i.e. possibility to
collect all the measures referring to the same block). 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. The access-list is installed on all the flow(s) being monitored. The access-list is installed on all the
routers of the path. Also, a 5 minutes timer for color switching is routers of the path. In addition, NetFlow can be used to recognize
a safe choice for reading the counters. timestamps of first/last packet of a batch.
The counters are collected by using an automatic script that sends The counters are collected by using an automatic script that sends
out these to a Network Management System (NMS). The NMS is out these to a Network Management System (NMS). The NMS is
responsible for packet loss calculation, performed by comparing the responsible for packet loss calculation, performed by comparing the
values of counters from the routers along the flow(s) path. values of counters from the routers along the flow(s) path. 5
minutes timer for color switching is a safe choice for reading the
counters and is also coherent with the reporting window of the NMS.
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
monitored together on a single router, while an implementation on
dedicated hardware scales more.
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
skipping to change at page 22, line 34 skipping to change at page 22, line 46
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) 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]. 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.
5.3. OAM Passive Performance Measurement 5.3. OAM Passive Performance Measurement
In [I-D.ietf-bier-mpls-encapsulation] two OAM bits from Bit Index In [I-D.ietf-bier-mpls-encapsulation] two OAM bits from Bit Index
Explicit Replication (BIER) Header are reserved for the passive Explicit Replication (BIER) Header are reserved for the passive
performance measurement marking method. [I-D.ietf-bier-pmmm-oam] performance measurement marking method. [I-D.ietf-bier-pmmm-oam]
details the measurement for multicast service over BIER domain. details the measurement for multicast service over BIER domain.
In addition, the alternate marking method could also be used in a In addition, the alternate marking method could also be used in a
Service Function Chaining (SFC) domain. Service Function Chaining (SFC) domain.
skipping to change at page 23, line 42 skipping to change at page 24, line 9
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. Summary
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 or by using features
available on major routing platforms; 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 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
is achieved with a passive measurement; is achieved with a passive measurement;
o potential applicability to any kind of packet/frame -based o potential applicability to any kind of packet/frame -based
traffic: Ethernet, IP, MPLS, etc., both unicast and multicast; traffic: Ethernet, IP, MPLS, etc., both unicast and multicast;
o robustness: the method can tolerate out of order packets and it's o robustness: the method can tolerate out of order packets and it's
not based on "special" packets whose loss could have a negative not based on "special" packets whose loss could have a negative
impact; impact;
o no interoperability issues: the features required to implement the o flexibility: all the timestamp formats are allowed, because they
method are available on all current routing platforms. 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, The method doesn't raise any specific need for protocol extension,
but it could be further improved by means of some extension to but it could be further improved by means of some extension to
existing protocols. Specifically, the use of DiffServ bits for existing protocols. Specifically, the use of DiffServ bits for
coloring the packets could not be a viable solution in some cases: a coloring the packets could not be a viable solution in some cases: a
standard method to color the packets for this specific application standard method to color the packets for this specific application
could be beneficial. could be beneficial.
8. Compliance with RFC6390 guidelines 8. Compliance with RFC6390 guidelines
skipping to change at page 29, line 15 skipping to change at page 29, line 41
[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-07 (work in progress), draft-ietf-bier-mpls-encapsulation-09 (work in progress),
June 2017. September 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-02 (work in progress), July 2017. pmmm-oam-02 (work in progress), July 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-
 End of changes. 20 change blocks. 
35 lines changed or deleted 60 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/