draft-ietf-ippm-alt-mark-05.txt   draft-ietf-ippm-alt-mark-06.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: December 28, 2017 L. Castaldelli Expires: January 26, 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
June 26, 2017 July 25, 2017
Alternate Marking method for passive and hybrid performance monitoring Alternate Marking method for passive and hybrid performance monitoring
draft-ietf-ippm-alt-mark-05 draft-ietf-ippm-alt-mark-06
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 on the operational
experiment done at Telecom Italia is explained in order to give an experiment done at Telecom Italia is explained in order to give an
example and show the method applicability. This technique can be example and show the method applicability. This technique can be
applied in various situations as detailed in this document and could applied in various situations as detailed in this document and could
be considered passive or hybrid depending on the application. be considered passive or hybrid depending on the application.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 28, 2017. This Internet-Draft will expire on January 26, 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
(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
skipping to change at page 3, line 4 skipping to change at page 3, line 9
5.4. RFC6374 Use Case . . . . . . . . . . . . . . . . . . . . 22 5.4. RFC6374 Use Case . . . . . . . . . . . . . . . . . . . . 22
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. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 23 7. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 27 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 of the traffic in Service Providers' networks carries
contents that are highly sensitive to packet loss [RFC2680], delay contents that are highly sensitive to packet loss [RFC7680], delay
[RFC2679], 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.).
A lot of work related to OAM, that includes also performance A lot of work related to OAM, that includes also performance
skipping to change at page 16, line 42 skipping to change at page 16, line 42
period. period.
When the nodes or NMS see, for example, same BNs associated with two When the nodes or NMS see, for example, same BNs associated with two
packet counts from an upstream and a downstream node respectively, it packet counts from an upstream and a downstream node respectively, it
considers that these two packet counts corresponding to the same considers that these two packet counts corresponding to the same
block, i.e. that these two packet counts belong to the same block of block, i.e. that these two packet counts belong to the same block of
markers from the upstream and downstream node. The assumption of markers from the upstream and downstream node. The assumption of
this BN mechanism is that the measurement nodes are time this BN mechanism is that the measurement nodes are time
synchronized. This requires the measurement nodes to have a certain synchronized. This requires the measurement nodes to have a certain
time synchronization capability (e.g., the Network Time Protocol time synchronization capability (e.g., the Network Time Protocol
(NTP) [RFC5905], or the IEEE 1588 Precision Time Protocol (PTP) (NTP) RFC 5905 [RFC5905], or the IEEE 1588 Precision Time Protocol
[IEEE1588]). Synchronization aspects are further discussed in (PTP) [IEEE-1588]). Synchronization aspects are further discussed in
Section 4. Section 4.
4.3. Packet Re-ordering 4.3. Packet Re-ordering
Due to ECMP, packet re-ordering is very common in IP network. The Due to ECMP, packet re-ordering is very common in IP network. The
accuracy of marking based PM, especially packet loss measurement, may accuracy of marking based PM, especially packet loss measurement, may
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 |...
skipping to change at page 22, line 38 skipping to change at page 22, line 38
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].
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.
[I-D.mirsky-sfc-pmamm] describes how the alternate marking method can In addition, the alternate marking method could also be used in a
be used as the passive performance measurement method in a Service Service Function Chaining (SFC) domain.
Function Chaining (SFC) domain.
The application of the marking method to Network Virtualization The application of the marking method to Network Virtualization
Overlays (NVO3) protocols is a work in progress. Overlays (NVO3) protocols is a work in progress (see
[I-D.ietf-nvo3-encap]).
5.4. RFC6374 Use Case 5.4. 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)
skipping to change at page 23, line 46 skipping to change at page 23, line 46
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
more complete and coherent description of the proposed method. We more complete and coherent description of the proposed method. We
used a subset of the Performance Metric Definition template defined used a subset of the Performance Metric Definition template defined
by [RFC6390]. by [RFC6390].
o Metric name and description: as already stated, this document o Metric name and description: as already stated, this document
doesn't propose any new Performance Metric. On the contrary, it doesn't propose any new Performance Metric. On the contrary, it
describes a novel method for measuring packet loss [RFC2680]. The describes a novel method for measuring packet loss [RFC7680]. The
same concept, with small differences, can also be used to measure same concept, with small differences, can also be used to measure
delay [RFC2679], and jitter [RFC3393]. The document mainly delay [RFC7679], and jitter [RFC3393]. The document mainly
describes the applicability to packet loss measurement. describes the applicability to packet loss measurement.
o Method of Measurement or Calculation: according to the method o Method of Measurement or Calculation: according to the method
described in the previous sections, the number of packets lost is described in the previous sections, the number of packets lost is
calculated by subtracting the value of the counter on the source calculated by subtracting the value of the counter on the source
node from the value of the counter on the destination node. Both node from the value of the counter on the destination node. Both
counters must refer to the same color. The calculation is counters must refer to the same color. The calculation is
performed when the value of the counters is in a steady state. performed when the value of the counters is in a steady state.
o Units of Measurement: the method calculates and reports the exact o Units of Measurement: the method calculates and reports the exact
skipping to change at page 27, line 18 skipping to change at page 27, line 18
There are no IANA actions required. There are no IANA actions required.
11. Acknowledgements 11. Acknowledgements
The previous IETF drafts about this technique were: The previous IETF drafts about this technique were:
[I-D.cociglio-mboned-multicast-pm] and [I-D.tempia-opsawg-p3m]. [I-D.cociglio-mboned-multicast-pm] and [I-D.tempia-opsawg-p3m].
There are some references to this methodology in other IETF works There are some references to this methodology in other IETF works
(e.g. [I-D.ietf-mpls-flow-ident], [I-D.bryant-mpls-sfl-framework] (e.g. [I-D.ietf-mpls-flow-ident], [I-D.bryant-mpls-sfl-framework]
[I-D.ietf-mpls-rfc6374-sfl], [I-D.ietf-bier-mpls-encapsulation], [I-D.ietf-mpls-rfc6374-sfl], [I-D.ietf-bier-mpls-encapsulation],
[I-D.ietf-bier-pmmm-oam] [I-D.ietf-bier-pmmm-oam], [I-D.mirsky-sfc-pmamm],
[I-D.chen-ippm-coloring-based-ipfpm-framework]). [I-D.chen-ippm-coloring-based-ipfpm-framework]).
In addition the authors would like to thank Alberto Tempia Bonda, In addition the authors would like to thank Alberto Tempia Bonda,
Domenico Laforgia, Daniele Accetta and Mario Bianchetti for their Domenico Laforgia, Daniele Accetta and Mario Bianchetti for their
contribution to the definition and the implementation of the method. contribution to the definition and the implementation of the method.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [IEEE-1588]
Delay Metric for IPPM", RFC 2679, DOI 10.17487/RFC2679, IEEE 1588-2008, "IEEE Standard for a Precision Clock
September 1999, <http://www.rfc-editor.org/info/rfc2679>. Synchronization Protocol for Networked Measurement and
Control Systems", July 2008.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Packet Loss Metric for IPPM", RFC 2680, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2680, September 1999, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2680>. <http://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<http://www.rfc-editor.org/info/rfc5905>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Delay Metric for IP Performance Metrics
(IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
2016, <http://www.rfc-editor.org/info/rfc7679>.
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Loss Metric for IP Performance Metrics
(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
2016, <http://www.rfc-editor.org/info/rfc7680>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <http://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 12.2. Informative References
[I-D.bryant-mpls-sfl-framework] [I-D.bryant-mpls-sfl-framework]
Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S.,
and G. Mirsky, "Synonymous Flow Label Framework", draft- and G. Mirsky, "Synonymous Flow Label Framework", draft-
bryant-mpls-sfl-framework-04 (work in progress), April bryant-mpls-sfl-framework-05 (work in progress), June
2017. 2017.
[I-D.chen-ippm-coloring-based-ipfpm-framework] [I-D.chen-ippm-coloring-based-ipfpm-framework]
Chen, M., Zheng, L., Mirsky, G., Fioccola, G., and T. Chen, M., Zheng, L., Mirsky, G., Fioccola, G., and T.
Mizrahi, "IP Flow Performance Measurement Framework", Mizrahi, "IP Flow Performance Measurement Framework",
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,
skipping to change at page 28, line 40 skipping to change at page 29, line 16
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-07 (work in progress),
June 2017. June 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-01 (work in progress), January 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-
ietf-mpls-flow-ident-04 (work in progress), February 2017. ietf-mpls-flow-ident-04 (work in progress), February 2017.
[I-D.ietf-mpls-rfc6374-sfl] [I-D.ietf-mpls-rfc6374-sfl]
Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S., Bryant, S., Chen, M., Li, Z., Swallow, G., Sivabalan, S.,
Mirsky, G., and G. Fioccola, "RFC6374 Synonymous Flow Mirsky, G., and G. Fioccola, "RFC6374 Synonymous Flow
Labels", draft-ietf-mpls-rfc6374-sfl-00 (work in Labels", draft-ietf-mpls-rfc6374-sfl-00 (work in
progress), June 2017. progress), June 2017.
[I-D.ietf-nvo3-encap]
Boutros, S., Ganga, I., Garg, P., Manur, R., Mizrahi, T.,
Mozes, D., and E. Nordmark, "NVO3 Encapsulation
Considerations", draft-ietf-nvo3-encap-00 (work in
progress), June 2017.
[I-D.mirsky-sfc-pmamm] [I-D.mirsky-sfc-pmamm]
Mirsky, G. and G. Fioccola, "Performance Measurement (PM) Mirsky, G., Fioccola, G., and T. Mizrahi, "Performance
with Alternate Marking Method in Service Function Chaining Measurement (PM) with Alternate Marking Method in Service
(SFC) Domain", draft-mirsky-sfc-pmamm-00 (work in Function Chaining (SFC) Domain", draft-mirsky-sfc-pmamm-01
progress), April 2017. (work in progress), June 2017.
[I-D.tempia-opsawg-p3m] [I-D.tempia-opsawg-p3m]
Capello, A., Cociglio, M., Castaldelli, L., and A. Bonda, Capello, A., Cociglio, M., Castaldelli, L., and A. Bonda,
"A packet based method for passive performance "A packet based method for passive performance
monitoring", draft-tempia-opsawg-p3m-04 (work in monitoring", draft-tempia-opsawg-p3m-04 (work in
progress), February 2014. progress), February 2014.
[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation
Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, Applicability Statement", RFC 5481, DOI 10.17487/RFC5481,
March 2009, <http://www.rfc-editor.org/info/rfc5481>. March 2009, <http://www.rfc-editor.org/info/rfc5481>.
 End of changes. 20 change blocks. 
29 lines changed or deleted 63 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/