draft-ietf-ippm-alt-mark-12.txt   draft-ietf-ippm-alt-mark-13.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: April 6, 2018 L. Castaldelli Expires: April 28, 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
October 3, 2017 October 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-12 draft-ietf-ippm-alt-mark-13
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 April 6, 2018. This Internet-Draft will expire on April 28, 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 33 skipping to change at page 2, line 33
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 . . . . . . . . . . . . . 6 3. Detailed description of the method . . . . . . . . . . . . . 6
3.1. Packet loss measurement . . . . . . . . . . . . . . . . . 6 3.1. Packet loss measurement . . . . . . . . . . . . . . . . . 6
3.1.1. Coloring the packets . . . . . . . . . . . . . . . . 11 3.1.1. Coloring the packets . . . . . . . . . . . . . . . . 11
3.1.2. Counting the packets . . . . . . . . . . . . . . . . 11 3.1.2. Counting the packets . . . . . . . . . . . . . . . . 11
3.1.3. Collecting data and calculating packet loss . . . . . 12 3.1.3. Collecting data and calculating packet loss . . . . . 12
3.2. Timing aspects . . . . . . . . . . . . . . . . . . . . . 12 3.2. Timing aspects . . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . . 19
4.3. Packet Re-ordering . . . . . . . . . . . . . . . . . . . 19 4.3. Packet Re-ordering . . . . . . . . . . . . . . . . . . . 20
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 . 21
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) . . . . . . . . . 23
5.3. OAM Passive Performance Measurement . . . . . . . . . . . 23 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 . . . . . . 24
6. Hybrid measurement . . . . . . . . . . . . . . . . . . . . . 23 6. Hybrid measurement . . . . . . . . . . . . . . . . . . . . . 24
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 24 8. Compliance with RFC6390 guidelines . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
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 11, line 13 skipping to change at page 11, line 13
interfaces will be null. interfaces will be null.
3.1.1. Coloring the packets 3.1.1. Coloring the packets
The coloring operation is fundamental in order to create packet The coloring operation is fundamental in order to create packet
blocks. This implies choosing where to activate the coloring and how blocks. This implies choosing where to activate the coloring and how
to color the packets. to color the packets.
In case of flow-based measurements, it is desirable, in general, to In case of flow-based measurements, it is desirable, in general, to
have a single coloring node because it is easier to manage and have a single coloring node because it is easier to manage and
doesn't rise any risk of conflict (consider the case where two nodes doesn't rise any risk of conflict (consider the case where multiple
color the same flow). Thus it is advantageous to color the flow as nodes color the same flow). Thus it is advantageous to color the
close as possible to the source. In addition, coloring a flow close flow as close as possible to the source. In addition, coloring a
to the source allows an end-to-end measure if a measurement point is flow close to the source allows an end-to-end measure if a
enabled on the last-hop router as well. The only requirement is that measurement point is enabled on the last-hop router as well.
the coloring must change periodically and every node, that is Coloring in multiple nodes is also possible and the requirement is
designated as a measurement point along the path, should be able to that the coloring must change periodically according to the timing
identify unambiguously the colored packets. For link-based considerations in Section 3.2; so every node, that is designated as a
measurements, all traffic needs to be colored when transmitted on the measurement point along the path, should be able to identify
link. If the traffic had already been colored, then it has to be re- unambiguously the colored packets. Furthermore
colored because the color must be consistent on the link. This means [I-D.fioccola-ippm-multipoint-alt-mark] generalizes the coloring for
that each hop along the path must (re-)color the traffic; the color multipoint to multipoint flow.
is not required to be consistent along different links.
For link-based measurements, all traffic needs to be colored when
transmitted on the link. If the traffic had already been colored,
then it has to be re-colored because the color must be consistent on
the link. This means that each hop along the path must (re-)color
the traffic; the color 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. However some examples are reported in Section 5. 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 For flow-based measurements, assuming that the coloring of the
source node, the nodes between source and destination (included) have packets is performed only by the source node, the nodes between
to count the colored packets that they receive and forward: this source and destination (included) have to count the colored packets
operation can be enabled on every router along the path or only on a that they receive and forward: this operation can be enabled on every
subset, depending on which network segment is being monitored (a router along the path or only on a subset, depending on which network
single link, a particular metro area, the backbone, the whole path). segment is being monitored (a single link, a particular metro area,
the backbone, the whole path). Furthermore
[I-D.fioccola-ippm-multipoint-alt-mark] generalizes the counting for
multipoint to multipoint flow.
Since the color switches periodically between two values, two Since the color switches periodically between two values, two
counters (one for each value) are needed: one counter for packets counters (one for each value) are needed: one counter for packets
with color A and one counter for packets with color B. For each flow with color A and one counter for packets with color B. For each flow
(or group of flows) being monitored and for every interface where the (or group of flows) being monitored and for every interface where the
monitoring is active, a couple of counters is needed. For example, monitoring is active, a couple of counters is needed. For example,
in order to monitor separately 3 flows on a router with 4 interfaces in order to monitor separately 3 flows on a router with 4 interfaces
involved, 24 counters are needed (2 counters for each of the 3 flows involved, 24 counters are needed (2 counters for each of the 3 flows
on each of the 4 interfaces). on each of the 4 interfaces).
skipping to change at page 12, line 42 skipping to change at page 13, line 5
single packet) and also where packets were lost. single packet) and also where packets were lost.
The value of the counters needs to be transmitted to the NMS as soon The value of the counters needs to be transmitted to the NMS as soon
as it has been read. This can be accomplished by using SNMP or FTP as it has been read. This can be accomplished by using SNMP or FTP
and can be done in Push Mode or Polling Mode. In the first case, and can be done in Push Mode or Polling Mode. In the first case,
each router periodically sends the information to the NMS, in the each router periodically sends the information to the NMS, in the
latter case it is the NMS that periodically polls routers to collect latter case it is the NMS that periodically polls routers to collect
information. In any case, the NMS has to collect all the relevant information. In any case, the NMS has to collect all the relevant
values from all the routers within one cycle of the timer. values from all the routers within one cycle of the timer.
If link-based measurement is used, it would be possible to use a it would be also possible to use a protocol to exchange values of
protocol to exchange values of counters between the two endpoints in counters between the two endpoints in order to let them perform the
order to let them perform the packet loss calculation for each packet loss calculation for each traffic direction.
traffic direction. A similar approach could be also applied to a
flow-based measurement. A possible approach for the performance measurement architecture is
explained in [I-D.chen-ippm-coloring-based-ipfpm-framework], while
[I-D.chen-ippm-ipfpm-report] introduces new information elements of
IPFIX (RFC 7011 [RFC7011]).
3.2. Timing aspects 3.2. Timing aspects
This document introduces two color switching method: one is based on This document introduces two color switching method: one is based on
fixed number of packet, the other is based on fixed timer. But the fixed number of packet, the other is based on fixed timer. But the
method based on fixed timer is preferable because is more method based on fixed timer is preferable because is more
deterministic, and will be considered in the rest of the dcoument. deterministic, and will be considered in the rest of the dcoument.
By considering the clock error between network devices R1 and R2, By considering the clock error between network devices R1 and R2,
they must be synchronized to the same clock reference with an they must be synchronized to the same clock reference with an
skipping to change at page 21, line 41 skipping to change at page 22, line 10
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. In addition, NetFlow can be used to recognize routers of the path. In addition, network flow monitoring, such as
provided by IPFIX (RFC 7011 [RFC7011]), can be used to recognize
timestamps of first/last packet of a batch. 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. 5 values of counters from the routers along the flow(s) path. 5
minutes timer for color switching is a safe choice for reading the minutes timer for color switching is a safe choice for reading the
counters and is also coherent with the reporting window of the NMS. counters and is also coherent with the reporting window of the NMS.
Note that the use of the DSCP field for marking implies that the
method in this case works reliably only within a single management
and operation domain.
A flow to monitor can be defined by a set of selection rules (e.g. 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 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 is possible to control the number of involved nodes, the path
followed by the packets and the size of the flows. As an example, followed by the packets and the size of the flows. As an example,
the Telecom Italia experiment considers a flow as all the packets the Telecom Italia experiment considers a flow as all the packets
sharing the same source IP address or the same destination IP sharing the same source IP address or the same destination IP
address, depending on the direction. address, depending on the direction.
Lastly, the Telecom Italia experiment scales up to 1000 flows Lastly, the Telecom Italia experiment scales up to 1000 flows
monitored together on a single router, while an implementation on monitored together on a single router, while an implementation on
skipping to change at page 22, line 48 skipping to change at page 23, line 20
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]. As an example, in [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 this document, the last reserved bit of the Flag field of the IPv4
header is proposed to be used for marking. header is proposed to be used for marking, while a solution for IPv6
could be to leverage the IPv6 extension header 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 29, line 28 skipping to change at page 29, line 48
and G. Mirsky, "Synonymous Flow Label Framework", draft- and G. Mirsky, "Synonymous Flow Label Framework", draft-
bryant-mpls-sfl-framework-05 (work in progress), June 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.chen-ippm-ipfpm-report]
Chen, M., Zheng, L., and G. Mirsky, "IP Flow Performance
Measurement Report", draft-chen-ippm-ipfpm-report-01 (work
in progress), April 2016.
[I-D.cociglio-mboned-multicast-pm] [I-D.cociglio-mboned-multicast-pm]
Cociglio, M., Capello, A., Bonda, A., and L. Castaldelli, Cociglio, M., Capello, A., Bonda, A., and L. Castaldelli,
"A method for IP multicast performance monitoring", draft- "A method for IP multicast performance monitoring", draft-
cociglio-mboned-multicast-pm-01 (work in progress), cociglio-mboned-multicast-pm-01 (work in progress),
October 2010. October 2010.
[I-D.fioccola-ippm-alt-mark-active] [I-D.fioccola-ippm-alt-mark-active]
Fioccola, G., Clemm, A., Bryant, S., Cociglio, M., Fioccola, G., Clemm, A., Bryant, S., Cociglio, M.,
Chandramouli, M., and A. Capello, "Alternate Marking Chandramouli, M., and A. Capello, "Alternate Marking
Extension to Active Measurement Protocol", draft-fioccola- Extension to Active Measurement Protocol", draft-fioccola-
ippm-alt-mark-active-01 (work in progress), March 2017. ippm-alt-mark-active-01 (work in progress), March 2017.
[I-D.fioccola-ippm-multipoint-alt-mark]
Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto,
"Multipoint Alternate Marking method for passive and
hybrid performance monitoring", draft-fioccola-ippm-
multipoint-alt-mark-00 (work in progress), June 2017.
[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-09 (work in progress), draft-ietf-bier-mpls-encapsulation-10 (work in progress),
September 2017. October 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-03 (work in progress), October 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-05 (work in progress), July 2017. ietf-mpls-flow-ident-05 (work in progress), July 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
skipping to change at page 31, line 5 skipping to change at page 31, line 36
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New [RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development", BCP 170, RFC 6390, Performance Metric Development", BCP 170, RFC 6390,
DOI 10.17487/RFC6390, October 2011, DOI 10.17487/RFC6390, October 2011,
<https://www.rfc-editor.org/info/rfc6390>. <https://www.rfc-editor.org/info/rfc6390>.
[RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting [RFC6703] Morton, A., Ramachandran, G., and G. Maguluri, "Reporting
IP Network Performance Metrics: Different Points of View", IP Network Performance Metrics: Different Points of View",
RFC 6703, DOI 10.17487/RFC6703, August 2012, RFC 6703, DOI 10.17487/RFC6703, August 2012,
<https://www.rfc-editor.org/info/rfc6703>. <https://www.rfc-editor.org/info/rfc6703>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>.
[RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
Weingarten, "An Overview of Operations, Administration, Weingarten, "An Overview of Operations, Administration,
and Maintenance (OAM) Tools", RFC 7276, and Maintenance (OAM) Tools", RFC 7276,
DOI 10.17487/RFC7276, June 2014, DOI 10.17487/RFC7276, June 2014,
<https://www.rfc-editor.org/info/rfc7276>. <https://www.rfc-editor.org/info/rfc7276>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>. October 2014, <https://www.rfc-editor.org/info/rfc7384>.
 End of changes. 22 change blocks. 
43 lines changed or deleted 78 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/