draft-ietf-ippm-alt-mark-02.txt   draft-ietf-ippm-alt-mark-03.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: May 1, 2017 L. Castaldelli Expires: August 12, 2017 L. Castaldelli
Telecom Italia Telecom Italia
M. Chen, Ed. M. Chen, Ed.
L. Zheng, Ed. L. Zheng, Ed.
Huawei Technologies Huawei Technologies
G. Mirsky, Ed. G. Mirsky, Ed.
Ericsson ZTE
T. Mizrahi, Ed. T. Mizrahi, Ed.
Marvell Marvell
October 28, 2016 February 8, 2017
Alternate Marking method for passive performance monitoring Alternate Marking method for passive performance monitoring
draft-ietf-ippm-alt-mark-02 draft-ietf-ippm-alt-mark-03
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 44 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 May 1, 2017. This Internet-Draft will expire on August 12, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview of the method . . . . . . . . . . . . . . . . . . . 4 2. Overview of the method . . . . . . . . . . . . . . . . . . . 4
3. Detailed description of the method . . . . . . . . . . . . . 5 3. Detailed description of the method . . . . . . . . . . . . . 5
3.1. Packet loss measurement . . . . . . . . . . . . . . . . . 5 3.1. Packet loss measurement . . . . . . . . . . . . . . . . . 5
3.1.1. Timing aspects . . . . . . . . . . . . . . . . . . . 9 3.1.1. Timing aspects . . . . . . . . . . . . . . . . . . . 9
3.2. One-way delay measurement . . . . . . . . . . . . . . . . 10 3.2. One-way delay measurement . . . . . . . . . . . . . . . . 10
3.2.1. Single marking methodology . . . . . . . . . . . . . 10 3.2.1. Single marking methodology . . . . . . . . . . . . . 10
3.2.2. Mean delay . . . . . . . . . . . . . . . . . . . . . 12 3.2.2. Double marking methodology . . . . . . . . . . . . . 12
3.2.3. Double marking methodology . . . . . . . . . . . . . 12 3.3. Delay variation measurement . . . . . . . . . . . . . . . 14
3.3. Delay variation measurement . . . . . . . . . . . . . . . 13
4. Considerations . . . . . . . . . . . . . . . . . . . . . . . 14 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Synchronization . . . . . . . . . . . . . . . . . . . . . 14 4.1. Synchronization . . . . . . . . . . . . . . . . . . . . . 14
4.2. Data Correlation . . . . . . . . . . . . . . . . . . . . 14 4.2. Data Correlation . . . . . . . . . . . . . . . . . . . . 15
4.3. Packet Re-ordering . . . . . . . . . . . . . . . . . . . 15 4.3. Packet Re-ordering . . . . . . . . . . . . . . . . . . . 16
5. Implementation and deployment . . . . . . . . . . . . . . . . 16 5. Implementation and deployment . . . . . . . . . . . . . . . . 16
5.1. Report on the operational experiment at Telecom Italia . 16 5.1. Report on the operational experiment at Telecom Italia . 17
5.1.1. Coloring the packets . . . . . . . . . . . . . . . . 18 5.1.1. Coloring the packets . . . . . . . . . . . . . . . . 18
5.1.2. Counting the packets . . . . . . . . . . . . . . . . 19 5.1.2. Counting the packets . . . . . . . . . . . . . . . . 19
5.1.3. Collecting data and calculating packet loss . . . . . 20 5.1.3. Collecting data and calculating packet loss . . . . . 20
5.1.4. Metric transparency . . . . . . . . . . . . . . . . . 20 5.1.4. Metric transparency . . . . . . . . . . . . . . . . . 21
5.2. IP flow performance measurement (IPFPM) . . . . . . . . . 21 5.2. IP flow performance measurement (IPFPM) . . . . . . . . . 21
5.3. Performance Measurement Marking Method in BIER Domain . . 21 5.3. Performance Measurement Marking Method in BIER Domain . . 21
5.4. Overlay OAM Passive Performance Measurement . . . . . . . 21 5.4. Overlay OAM Passive Performance Measurement . . . . . . . 21
5.5. RFC6374 Use Case . . . . . . . . . . . . . . . . . . . . 21 5.5. RFC6374 Use Case . . . . . . . . . . . . . . . . . . . . 22
5.6. Application to active performance measurement . . . . . . 22 5.6. Application to active performance measurement . . . . . . 22
6. Hybrid measurement . . . . . . . . . . . . . . . . . . . . . 22 6. Hybrid measurement . . . . . . . . . . . . . . . . . . . . . 22
7. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 22 7. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 26 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 26 12.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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
skipping to change at page 12, line 20 skipping to change at page 12, line 20
For the sake of simplicity, in the above example a single measurement For the sake of simplicity, in the above example a single measurement
is provided within a block, taking into account only the first packet is provided within a block, taking into account only the first packet
of each block. The number of measurements can be easily increased by of each block. The number of measurements can be easily increased by
considering multiple packets in the block: for instance, a timestamp considering multiple packets in the block: for instance, a timestamp
could be taken every N packets, thus generating multiple delay could be taken every N packets, thus generating multiple delay
measurements. Taking this to the limit, in principle the delay could measurements. Taking this to the limit, in principle the delay could
be measured for each packet, by taking and comparing the be measured for each packet, by taking and comparing the
corresponding timestamps (possible but impractical from an corresponding timestamps (possible but impractical from an
implementation point of view). implementation point of view).
3.2.2. Mean delay 3.2.1.1. Mean delay
As mentioned before, the method previously exposed for measuring the As mentioned before, the method previously exposed for measuring the
delay is sensitive to out of order reception of packets. In order to delay is sensitive to out of order reception of packets. In order to
overcome this problem, a different approach has been considered: it overcome this problem, a different approach has been considered: it
is based on the concept of mean delay. The mean delay is calculated is based on the concept of mean delay. The mean delay is calculated
by considering the average arrival time of the packets within a by considering the average arrival time of the packets within a
single block. The network device locally stores a timestamp for each single block. The network device locally stores a timestamp for each
packet received within a single block: summing all the timestamps and packet received within a single block: summing all the timestamps and
dividing by the total number of packets received, the average arrival dividing by the total number of packets received, the average arrival
time for that block of packets can be calculated. By subtracting the time for that block of packets can be calculated. By subtracting the
skipping to change at page 12, line 44 skipping to change at page 12, line 44
is introduced). Moreover, it greatly reduces the number of is introduced). Moreover, it greatly reduces the number of
timestamps (only one per block for each network device) that have to timestamps (only one per block for each network device) that have to
be collected by the management system. On the other hand, it only be collected by the management system. On the other hand, it only
gives one measure for the duration of the block (f.i. 5 minutes), and gives one measure for the duration of the block (f.i. 5 minutes), and
it doesn't give the minimum, maximum and median delay values (RFC it doesn't give the minimum, maximum and median delay values (RFC
6703 [RFC6703]). This limitation could be overcome by reducing the 6703 [RFC6703]). This limitation could be overcome by reducing the
duration of the block (f.i. from 5 minutes to a few seconds), that duration of the block (f.i. from 5 minutes to a few seconds), that
implicates an highly optimized implementation of the method. implicates an highly optimized implementation of the method.
By summing the mean delays of the two directions of a path, it is By summing the mean delays of the two directions of a path, it is
also possible to measure the two-way delay (round-trip delay). also possible to measure the two-way mean delay (round-trip delay).
3.2.3. Double marking methodology 3.2.2. Double marking methodology
The Single marking methodology for one-way delay measurement is The Single marking methodology for one-way delay measurement is
sensitive to out of order reception of packets. The first approach sensitive to out of order reception of packets. The first approach
to overcome this problem is described before and is based on the to overcome this problem is described before and is based on the
concept of mean delay. But the limitation of mean delay is that it concept of mean delay. But the limitation of mean delay is that it
doesn't give information about the delay values distribution for the doesn't give information about the delay values distribution for the
duration of the block. Additionally it may be useful to have not duration of the block. Additionally it may be useful to have not
only the mean delay but also the minimum and maximum delay values only the mean delay but also the minimum and maximum delay values
and, in wider terms, to know more about the statistic distribution of and, in wider terms, to know more about the statistic distribution of
delay values. So in order to have more information about the delay delay values. So in order to have more information about the delay
skipping to change at page 13, line 31 skipping to change at page 13, line 31
easily increased by changing the frequency of the second marking. easily increased by changing the frequency of the second marking.
But the frequency of the second marking must be not too high in order But the frequency of the second marking must be not too high in order
to avoid out of order issues. Between packets with the second to avoid out of order issues. Between packets with the second
marking there should be a security time gap (e.g. this gap could be, marking there should be a security time gap (e.g. this gap could be,
at the minimum, the mean network delay calculated with the previous at the minimum, the mean network delay calculated with the previous
methodology) to avoid out of order issues and also to have a number methodology) to avoid out of order issues and also to have a number
of measurement packets that is rate independent. If a second marking of measurement packets that is rate independent. If a second marking
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 batch and is a
simple computation to be performed for single marking method. In
some cases mean delay measure could not be enough when more delay
extent data are needed (e.g. minimum, maximum, variance and median
delay values for each block). To overcome this drawback the idea is
to couple the mean delay measure for the entire batch with double
marking method, where a subset of batch packets are selected for
extensive delay calculation by using a second marking. In this way
it is possible to measure the minimum, the maximum, the variance and
the median in order to perform a detailed analysis on these double
marked packets. Please note that there are classic algorithms for
median and variance calculation, but are out of the scope of this
document. The comparison between the mean delay for the entire batch
and the mean delay on these double marked packets gives an useful
information since it is possible to understand if the double marking
measurements are actually representative of the delay trends.
3.3. Delay variation measurement 3.3. Delay variation measurement
Similarly to one-way delay measurement (both for single marking and Similarly to one-way delay measurement (both for single marking and
double marking), the method can also be used to measure the inter- double marking), the method can also be used to measure the inter-
arrival jitter. We refer to the definition in RFC 3393 [RFC3393]. arrival jitter. We refer to the definition in RFC 3393 [RFC3393].
The alternation of colors, for single marking method, can be used as The alternation of colors, for single marking method, can be used as
a time reference to measure delay variations. In case of double a time reference to measure delay variations. In case of double
marking, the time reference is given by the second marked packets. marking, the time reference is given by the second marked packets.
Considering the example depicted in Figure 2, R1 stores a timestamp Considering the example depicted in Figure 2, R1 stores a timestamp
TS(A)R1 whenever it sends the first packet of a block and R2 stores a TS(A)R1 whenever it sends the first packet of a block and R2 stores a
skipping to change at page 26, line 44 skipping to change at page 27, line 13
<http://www.rfc-editor.org/info/rfc2680>. <http://www.rfc-editor.org/info/rfc2680>.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393, Metric for IP Performance Metrics (IPPM)", RFC 3393,
DOI 10.17487/RFC3393, November 2002, DOI 10.17487/RFC3393, November 2002,
<http://www.rfc-editor.org/info/rfc3393>. <http://www.rfc-editor.org/info/rfc3393>.
12.2. Informative References 12.2. Informative References
[I-D.bryant-mpls-rfc6374-sfl] [I-D.bryant-mpls-rfc6374-sfl]
Bryant, S., Swallow, G., Sivabalan, S., Mirsky, G., Chen, Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S.,
M., and Z. Li, "RFC6374 Synonymous Flow Labels", draft- Mirsky, G., and G. Fioccola, "RFC6374 Synonymous Flow
bryant-mpls-rfc6374-sfl-01 (work in progress), August Labels", draft-bryant-mpls-rfc6374-sfl-03 (work in
2016. progress), October 2016.
[I-D.bryant-mpls-sfl-framework] [I-D.bryant-mpls-sfl-framework]
Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S.,
and G. Mirsky, "Synonymous Flow Label Framework", draft- and G. Mirsky, "Synonymous Flow Label Framework", draft-
bryant-mpls-sfl-framework-02 (work in progress), October bryant-mpls-sfl-framework-02 (work in progress), October
2016. 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",
skipping to change at page 27, line 38 skipping to change at page 28, line 8
[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 Networks", draft-ietf-bier- Explicit Replication in MPLS and non-MPLS Networks",
mpls-encapsulation-05 (work in progress), July 2016. draft-ietf-bier-mpls-encapsulation-06 (work in progress),
December 2016.
[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-00 (work in progress), July 2016. pmmm-oam-01 (work in progress), January 2017.
[I-D.ietf-mpls-flow-ident] [I-D.ietf-mpls-flow-ident]
Bryant, S., Chen, M., Li, Z., Pignataro, C., 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-02 (work in progress), August 2016. ietf-mpls-flow-ident-03 (work in progress), January 2017.
[I-D.ooamdt-rtgwg-oam-gap-analysis] [I-D.ooamdt-rtgwg-oam-gap-analysis]
Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N., Kumar, Mirsky, G., Nordmark, E., Pignataro, C., Kumar, N., Kumar,
D., Chen, M., Yizhou, L., Mozes, D., Networks, J., and I. D., Chen, M., Yizhou, L., Mozes, D., Networks, J., and I.
Bagdonas, "Operations, Administration and Maintenance Bagdonas, "Operations, Administration and Maintenance
(OAM) for Overlay Networks: Gap Analysis", draft-ooamdt- (OAM) for Overlay Networks: Gap Analysis", draft-ooamdt-
rtgwg-oam-gap-analysis-02 (work in progress), July 2016. rtgwg-oam-gap-analysis-02 (work in progress), July 2016.
[I-D.ooamdt-rtgwg-ooam-requirement] [I-D.ooamdt-rtgwg-ooam-requirement]
Kumar, N., Pignataro, C., Kumar, D., Mirsky, G., Chen, M., Kumar, N., Pignataro, C., Kumar, D., Mirsky, G., Chen, M.,
Nordmark, E., Networks, J., and D. Mozes, "Overlay OAM Nordmark, E., Networks, J., and D. Mozes, "Overlay OAM
Requirements", draft-ooamdt-rtgwg-ooam-requirement-01 Requirements", draft-ooamdt-rtgwg-ooam-requirement-02
(work in progress), July 2016. (work in progress), January 2017.
[I-D.tempia-opsawg-p3m] [I-D.tempia-opsawg-p3m]
Capello, A., Cociglio, M., Castaldelli, L., and A. Bonda, Capello, A., Cociglio, M., Castaldelli, L., and A. Bonda,
"A packet based method for passive performance "A packet based method for passive performance
monitoring", draft-tempia-opsawg-p3m-04 (work in monitoring", draft-tempia-opsawg-p3m-04 (work in
progress), February 2014. progress), February 2014.
[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,
skipping to change at page 30, line 4 skipping to change at page 30, line 21
Mach(Guoyi) Chen (editor) Mach(Guoyi) Chen (editor)
Huawei Technologies Huawei Technologies
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
Lianshu Zheng (editor) Lianshu Zheng (editor)
Huawei Technologies Huawei Technologies
Email: vero.zheng@huawei.com Email: vero.zheng@huawei.com
Greg Mirsky (editor) Greg Mirsky (editor)
Ericsson ZTE
USA USA
Email: gregory.mirsky@ericsson.com Email: gregimirsky@gmail.com
Tal Mizrahi (editor) Tal Mizrahi (editor)
Marvell Marvell
6 Hamada st. 6 Hamada st.
Yokneam Yokneam
Israel Israel
Email: talmi@marvell.com Email: talmi@marvell.com
 End of changes. 25 change blocks. 
31 lines changed or deleted 49 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/