< draft-fioccola-rfc8321bis-00.txt   draft-fioccola-rfc8321bis-01.txt >
Network Working Group G. Fioccola, Ed. Network Working Group G. Fioccola, Ed.
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Obsoletes: 8321 (if approved) M. Cociglio Obsoletes: 8321 (if approved) M. Cociglio
Intended status: Standards Track Telecom Italia Intended status: Standards Track Telecom Italia
Expires: May 23, 2022 G. Mirsky Expires: June 12, 2022 G. Mirsky
Ericsson Ericsson
T. Mizrahi T. Mizrahi
T. Zhou
Huawei Technologies Huawei Technologies
November 19, 2021 December 9, 2021
Alternate-Marking Method Alternate-Marking Method
draft-fioccola-rfc8321bis-00 draft-fioccola-rfc8321bis-01
Abstract Abstract
This document describes a method based on an Alternate-Marking This document describes the Alternate-Marking technique to perform
technique to perform packet loss, delay, and jitter measurements on packet loss, delay, and jitter measurements on live traffic. This
live traffic. This technology can be applied in various situations technology can be applied in various situations and for different
and for different protocols. It could be considered Passive or protocols. It could be considered Passive or Hybrid depending on the
Hybrid depending on the application. This document obsoletes application. This document obsoletes [RFC8321].
[RFC8321].
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 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 May 23, 2022. This Internet-Draft will expire on June 12, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 23 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
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. Coloring the Packets . . . . . . . . . . . . . . . . 10 3.1.1. Coloring the Packets . . . . . . . . . . . . . . . . 10
3.1.2. Counting the Packets . . . . . . . . . . . . . . . . 10 3.1.2. Counting the Packets . . . . . . . . . . . . . . . . 10
3.1.3. Collecting Data and Calculating Packet Loss . . . . . 11 3.1.3. Collecting Data and Calculating Packet Loss . . . . . 11
3.2. Timing Aspects . . . . . . . . . . . . . . . . . . . . . 12 3.2. Timing Aspects . . . . . . . . . . . . . . . . . . . . . 12
3.3. One-Way Delay Measurement . . . . . . . . . . . . . . . . 13 3.3. One-Way Delay Measurement . . . . . . . . . . . . . . . . 13
3.3.1. Single-Marking Methodology . . . . . . . . . . . . . 13 3.3.1. Single-Marking Methodology . . . . . . . . . . . . . 14
3.3.2. Double-Marking Methodology . . . . . . . . . . . . . 15 3.3.2. Double-Marking Methodology . . . . . . . . . . . . . 16
3.4. Delay Variation Measurement . . . . . . . . . . . . . . . 17 3.4. Delay Variation Measurement . . . . . . . . . . . . . . . 17
4. Considerations . . . . . . . . . . . . . . . . . . . . . . . 17 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Synchronization . . . . . . . . . . . . . . . . . . . . . 17 4.1. Synchronization . . . . . . . . . . . . . . . . . . . . . 17
4.2. Data Correlation . . . . . . . . . . . . . . . . . . . . 18 4.2. Data Correlation . . . . . . . . . . . . . . . . . . . . 18
4.3. Packet Reordering . . . . . . . . . . . . . . . . . . . . 19 4.3. Packet Reordering . . . . . . . . . . . . . . . . . . . . 19
5. Results of the Alternate Marking Experiment . . . . . . . . . 19 4.4. Packet Fragmentation . . . . . . . . . . . . . . . . . . 20
5.1. Controlled Domain requirement . . . . . . . . . . . . . . 21 5. Results of the Alternate Marking Experiment . . . . . . . . . 20
6. Compliance with Guidelines from RFC 6390 . . . . . . . . . . 21 5.1. Controlled Domain requirement . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6. Compliance with Guidelines from RFC 6390 . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References . . . . . . . . . . . . . . . . . . 25 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.2. Informative References . . . . . . . . . . . . . . . . . 25 11.1. Normative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Changes Log . . . . . . . . . . . . . . . . . . . . 27 11.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Changes Log . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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 performance with an adequate tools to monitor and measure network performance 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. Performance monitoring also provides
monitoring provides useful information for improving network useful information for improving network management (e.g., isolation
management (e.g., isolation of network problems, troubleshooting, of network problems, troubleshooting, etc.).
etc.).
A lot of work related to Operations, Administration, and Maintenance A lot of work related to Operations, Administration, and Maintenance
(OAM), which also includes performance monitoring techniques, has (OAM), which also includes performance monitoring techniques, has
been done by Standards Developing Organizations (SDOs): [RFC7276] been done by Standards Developing Organizations (SDOs): [RFC7276]
provides a good overview of existing OAM mechanisms defined in the provides a good overview of existing OAM mechanisms defined in the
IETF, ITU-T, and IEEE. In the IETF, a lot of work has been done on IETF, ITU-T, and IEEE. In the IETF, a lot of work has been done on
fault detection and connectivity verification, while a minor effort fault detection and connectivity verification, while a minor effort
has been thus far dedicated to performance monitoring. The IPPM WG has been thus far dedicated to performance monitoring. The IPPM WG
has defined standard metrics to measure network performance; however, has defined standard metrics to measure network performance; however,
the methods developed in this WG mainly refer to focus on Active the methods developed in this WG mainly refer to focus on Active
measurement techniques. More recently, the MPLS WG has defined measurement techniques. More recently, the MPLS WG has defined
mechanisms for measuring packet loss, one-way and two-way delay, and mechanisms for measuring packet loss, one-way and two-way delay, and
delay variation in MPLS networks [RFC6374], but their applicability delay variation in MPLS networks [RFC6374], but their applicability
to Passive measurements has some limitations, especially for pure to Passive measurements has some limitations, especially for pure
connection-less networks. connection-less networks.
The lack of adequate tools to measure packet loss with the desired The lack of adequate tools to measure packet loss with the desired
accuracy drove an effort to design a new method for the performance accuracy drove an effort to design a new method for the performance
monitoring of live traffic, which is easy to implement and deploy. monitoring of live traffic, which is easy to implement and deploy.
The effort led to the method described in this document and in the The effort led to the method described in this document: basically,
paper [IEEE-Network-PNPM]: basically, it is a Passive performance it is a Passive performance monitoring technique, potentially
monitoring technique, potentially applicable to any kind of packet- applicable to any kind of packet-based traffic, including Ethernet,
based traffic, including Ethernet, IP, and MPLS, both unicast and IP, and MPLS, both unicast and multicast. The method addresses
multicast. The method addresses primarily packet loss measurement, primarily packet loss measurement, but it can be easily extended to
but it can be easily extended to one-way or two-way delay and delay one-way or two-way delay and delay variation measurements as well.
variation measurements as well.
The method has been explicitly designed for Passive measurements, but The method has been explicitly designed for Passive measurements, but
it can also be used with Active probes. Passive measurements are it can also be used with Active probes. Passive measurements are
usually more easily understood by customers and provide much better usually more easily understood by customers and provide much better
accuracy, especially for packet loss measurements. accuracy, especially for packet loss measurements.
RFC 7799 [RFC7799] defines Passive and Hybrid Methods of Measurement. RFC 7799 [RFC7799] defines Passive and Hybrid Methods of Measurement.
In particular, Passive Methods of Measurement are based solely on In particular, Passive Methods of Measurement are based solely on
observations of an undisturbed and unmodified packet stream of observations of an undisturbed and unmodified packet stream of
interest; Hybrid Methods are Methods of Measurement that use a interest; Hybrid Methods are Methods of Measurement that use a
skipping to change at page 5, line 47 skipping to change at page 5, line 44
represents the core application of the method, but applicability to represents the core application of the method, but applicability to
delay and jitter measurements is also considered. delay and jitter measurements is also considered.
3.1. Packet Loss Measurement 3.1. Packet Loss Measurement
The basic idea is to virtually split traffic flows into consecutive The basic idea is to virtually split traffic flows into consecutive
blocks: each block represents a measurable entity unambiguously blocks: each block represents a measurable entity unambiguously
recognizable by all network devices along the path. By counting the recognizable by all network devices along the path. By counting the
number of packets in each block and comparing the values measured by number of packets in each block and comparing the values measured by
different network devices along the path, it is possible to measure different network devices along the path, it is possible to measure
packet loss occurred in any single block between any two points. if packet loss occurred in any single block between any two points.
As discussed in the previous section, a simple way to create the As discussed in the previous section, a simple way to create the
blocks is to "color" the traffic (two colors are sufficient), so that blocks is to "color" the traffic (two colors are sufficient), so that
packets belonging to different consecutive blocks will have different packets belonging to different consecutive blocks will have different
colors. Whenever the color changes, the previous block terminates colors. Whenever the color changes, the previous block terminates
and the new one begins. Hence, all the packets belonging to the same and the new one begins. Hence, all the packets belonging to the same
block will have the same color and packets of different consecutive block will have the same color and packets of different consecutive
blocks will have different colors. The number of packets in each blocks will have different colors. The number of packets in each
block depends on the criterion used to create the blocks: block depends on the criterion used to create the blocks:
o if the color is switched after a fixed number of packets, then o if the color is switched after a fixed number of packets, then
each block will contain the same number of packets (except for any each block will contain the same number of packets (except for any
losses); and losses); and
o if the color is switched according to a fixed timer, then the o if the color is switched according to a fixed timer, then the
number of packets may be different in each block depending on the number of packets may be different in each block depending on the
packet rate. packet rate.
The rest of the document assumes that the blocks are created
according to a fixed timer. The switching after a fixed number of
packets is an additional possibility but its detailed specification
is out of scope.
The following figure shows how a flow looks like when it is split in The following figure shows how a flow looks like when it is split in
traffic blocks with colored packets. traffic blocks with colored packets.
A: packet with A coloring A: packet with A coloring
B: packet with B coloring B: packet with B coloring
| | | | | | | | | |
| | Traffic Flow | | | | Traffic Flow | |
-------------------------------------------------------------------> ------------------------------------------------------------------->
BBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA BBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA
skipping to change at page 9, line 32 skipping to change at page 9, line 32
measurement. Path rerouting and traffic load-balancing increase measurement. Path rerouting and traffic load-balancing increase
the issue complexity, especially for unicast traffic. The problem the issue complexity, especially for unicast traffic. The problem
is easier to solve for multicast traffic, where load-balancing is is easier to solve for multicast traffic, where load-balancing is
seldom used and static joins are frequently used to force traffic seldom used and static joins are frequently used to force traffic
forwarding and replication. forwarding and replication.
o link-based: measurements are performed on all the traffic on a o link-based: measurements are performed on all the traffic on a
link-by-link basis. The link could be a physical link or a link-by-link basis. The link could be a physical link or a
logical link. Counters could be instantiated for the traffic as a logical link. Counters could be instantiated for the traffic as a
whole or for each traffic class (in case it is desired to monitor whole or for each traffic class (in case it is desired to monitor
each class separately), but in the second case, a couple of each class separately), but in the second case, two counters are
counters are needed for each class. needed for each class.
As mentioned, the flow-based measurement requires the identification As mentioned, the flow-based measurement requires the identification
of the flow to be monitored and the discovery of the path followed by of the flow to be monitored and the discovery of the path followed by
the selected flow. It is possible to monitor a single flow or the selected flow. It is possible to monitor a single flow or
multiple flows grouped together, but in this case, measurement is multiple flows grouped together, but in this case, measurement is
consistent only if all the flows in the group follow the same path. consistent only if all the flows in the group follow the same path.
Moreover, if a measurement is performed by grouping many flows, it is Moreover, if a measurement is performed by grouping many flows, it is
not possible to determine exactly which flow was affected by packet not possible to determine exactly which flow was affected by packet
loss. In order to have measures per single flow, it is necessary to loss. In order to have measures per single flow, it is necessary to
configure counters for each specific flow. Once the flow(s) to be configure counters for each specific flow. Once the flow(s) to be
skipping to change at page 10, line 29 skipping to change at page 10, line 29
defined by a set of selection rules (e.g., header fields) used to defined by a set of selection rules (e.g., header fields) used to
match a subset of the packets; in this way, it is possible to control 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 number of involved nodes, the path followed by the packets, and
the size of the flows. It is possible, in general, to have multiple the size of the flows. It is possible, in general, to have multiple
coloring nodes or a single coloring node that is easier to manage and coloring nodes or a single coloring node that is easier to manage and
doesn't raise any risk of conflict. Coloring in multiple nodes can doesn't raise any risk of conflict. Coloring in multiple nodes can
be done, and the requirement is that the coloring must change be done, and the requirement is that the coloring must change
periodically between the nodes according to the timing considerations periodically between the nodes according to the timing considerations
in Section 3.2; so every node that is designated as a measurement in Section 3.2; so every node that is designated as a measurement
point along the path should be able to identify unambiguously the point along the path should be able to identify unambiguously the
colored packets. Furthermore, [RFC8889] generalizes the coloring for colored packets. Furthermore, [I-D.fioccola-rfc8889bis] generalizes
multipoint-to-multipoint flow. In addition, it can be advantageous the coloring for multipoint-to-multipoint flow. In addition, it can
to color the flow as close as possible to the source because it be advantageous to color the flow as close as possible to the source
allows an end-to-end measure if a measurement point is enabled on the because it allows an end-to-end measure if a measurement point is
last-hop router as well. enabled on the last-hop router as well.
For link-based measurements, all traffic needs to be colored when For link-based measurements, all traffic needs to be colored when
transmitted on the link. If the traffic had already been colored, 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 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 link. This means that each hop along the path must (re-)color
the traffic; the color is not required to be consistent along the traffic; the color is not required to be consistent along
different links. 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 applications are reported in Section 5. scope here.
3.1.2. Counting the Packets 3.1.2. Counting the Packets
For flow-based measurements, assuming that the coloring of the For flow-based measurements, assuming that the coloring of the
packets is performed only by the source nodes, the nodes between packets is performed only by the source nodes, the nodes between
source and destination (included) have to count the colored packets source and destination (included) have to count the colored packets
that they receive and forward: this operation can be enabled on every that they receive and forward: this operation can be enabled on every
router along the path or only on a subset, depending on which network router along the path or only on a subset, depending on which network
segment is being monitored (a single link, a particular metro area, segment is being monitored (a single link, a particular metro area,
the backbone, or the whole path). Since the color switches the backbone, or the whole path). Since the color switches
periodically between two values, two counters (one for each value) periodically between two values, two counters (one for each value)
are needed: one counter for packets with color A and one counter for are needed: one counter for packets with color A and one counter for
packets with color B. For each flow (or group of flows) being packets with color B. For each flow (or group of flows) being
monitored and for every interface where the monitoring is Active, a monitored and for every interface where the monitoring is Active, two
couple of counters are needed. For example, in order to separately counters are needed. For example, in order to separately monitor
monitor three flows on a router with four interfaces involved, 24 three flows on a router with four interfaces involved, 24 counters
counters are needed (two counters for each of the three flows on each are needed (two counters for each of the three flows on each of the
of the four interfaces). Furthermore, [RFC8889] generalizes the four interfaces). Furthermore, [I-D.fioccola-rfc8889bis] generalizes
counting for multipoint-to-multipoint flow. the counting for multipoint-to-multipoint flow.
In case of link-based measurements, the behavior is similar except In case of link-based measurements, the behavior is similar except
that coloring and counting operations are performed on a link-by-link that coloring and counting operations are performed on a link-by-link
basis at each endpoint of the link. basis at each endpoint of the link.
Another important aspect to take into consideration is when to read Another important aspect to take into consideration is when to read
the counters: in order to count the exact number of packets of a the counters: in order to count the exact number of packets of a
block, the routers must perform this operation when that block has block, the routers must perform this operation when that block has
ended; in other words, the counter for color A must be read when the ended; in other words, the counter for color A must be read when the
current block has color B, in order to be sure that the value of the current block has color B, in order to be sure that the value of the
skipping to change at page 12, line 22 skipping to change at page 12, line 22
It would also be possible to use a protocol to exchange values of It would also be possible to use a protocol to exchange values of
counters between the two endpoints in order to let them perform the counters between the two endpoints in order to let them perform the
packet loss calculation for each traffic direction. packet loss calculation for each traffic direction.
3.2. Timing Aspects 3.2. Timing Aspects
This document introduces two color-switching methods: one is based on This document introduces two color-switching methods: one is based on
a fixed number of packets, and the other is based on a fixed timer. a fixed number of packets, and the other is based on a fixed timer.
But the method based on a fixed timer is preferable because it is But the method based on a fixed timer is preferable because it is
more deterministic, and it will be considered in the rest of the more deterministic, and it is considered in the document.
document.
In general, clocks in network devices are not accurate and for this In general, clocks in network devices are not accurate and for this
reason, there is a clock error between the measurement points R1 and reason, there is a clock error between the measurement points R1 and
R2. But, to implement the methodology, they must be synchronized to R2. But, to implement the methodology, they must be synchronized to
the same clock reference with an accuracy of +/- L/2 time units, the same clock reference with an accuracy of +/- L/2 time units,
where L is the fixed time duration of the block. So each colored where L is the fixed time duration of the block. So each colored
packet can be assigned to the right batch by each router. This is packet can be assigned to the right batch by each router. This is
because the minimum time distance between two packets of the same because the minimum time distance between two packets of the same
color but that belong to different batches is L time units. color but that belong to different batches is L time units.
skipping to change at page 13, line 21 skipping to change at page 13, line 21
d | | d d | | d
|<==========================>| |<==========================>|
available counting interval available counting interval
Figure 5: Timing Aspects Figure 5: Timing Aspects
It is assumed that all network devices are synchronized to a common It is assumed that all network devices are synchronized to a common
reference time with an accuracy of +/- A/2. Thus, the difference reference time with an accuracy of +/- A/2. Thus, the difference
between the clock values of any two network devices is bounded by A. between the clock values of any two network devices is bounded by A.
The network delay between the network devices can be represented as a
data set and 99.7% of the samples are within 3 standard deviation of
the average.
The guard band d is given by: The guard band d is given by:
d = A + D_max - D_min, d = A + D_avg + 3*D_stddev,
where A is the clock accuracy, D_max is an upper bound on the network where A is the clock accuracy, D_avg is the average value of the
delay between the network devices, and D_min is a lower bound on the network delay between the network devices, and D_stddev is the
delay. standard deviation of the delay.
The available counting interval is L - 2d that must be > 0. The available counting interval is L - 2d that must be > 0.
The condition that must be satisfied and is a requirement on the The condition that must be satisfied and is a requirement on the
synchronization accuracy is: synchronization accuracy is:
d < L/2. d < L/2.
3.3. One-Way Delay Measurement 3.3. One-Way Delay Measurement
skipping to change at page 14, line 24 skipping to change at page 14, line 31
measure the delay between R1 and R2. In order to have more measure the delay between R1 and R2. In order to have more
measurements, it is possible to take and store more timestamps, measurements, it is possible to take and store more timestamps,
referring to other packets within each block. referring to other packets within each block.
In order to coherently compare timestamps collected on different In order to coherently compare timestamps collected on different
routers, the clocks on the network nodes must be in sync. routers, the clocks on the network nodes must be in sync.
Furthermore, a measurement is valid only if no packet loss occurs and Furthermore, a measurement is valid only if no packet loss occurs and
if packet misordering can be avoided; otherwise, the first packet of if packet misordering can be avoided; otherwise, the first packet of
a block on R1 could be different from the first packet of the same a block on R1 could be different from the first packet of the same
block on R2 (for instance, if that packet is lost between R1 and R2 block on R2 (for instance, if that packet is lost between R1 and R2
or it arrives after the next one). or it arrives after the next one). Since packet misordering is
generally undetectable it is not possible to check whether the first
packet on R1 is the same on R2 and this is part of the intrinsic
error in this measurement.
The following table shows how timestamps can be used to calculate the The following table shows how timestamps can be used to calculate the
delay between R1 and R2. The first column lists the sequence of delay between R1 and R2. The first column lists the sequence of
blocks, while other columns contain the timestamp referring to the blocks, while other columns contain the timestamp referring to the
first packet of each block on R1 and R2. The delay is computed as a first packet of each block on R1 and R2. The delay is computed as a
difference between timestamps. For the sake of simplicity, all the difference between timestamps. For the sake of simplicity, all the
values are expressed in milliseconds. values are expressed in milliseconds.
+-------+---------+---------+---------+---------+-------------+ +-------+---------+---------+---------+---------+-------------+
| Block | TS(A)R1 | TS(B)R1 | TS(A)R2 | TS(B)R2 | Delay R1-R2 | | Block | TS(A)R1 | TS(B)R1 | TS(A)R2 | TS(B)R2 | Delay R1-R2 |
skipping to change at page 15, line 41 skipping to change at page 16, line 12
calculate the mean delay between those nodes. When computing the calculate the mean delay between those nodes. When computing the
mean delay, the measurement error could be augmented by accumulating mean delay, the measurement error could be augmented by accumulating
the measurement error of a lot of packets. This method is robust to the measurement error of a lot of packets. This method is robust to
out-of-order packets and also to packet loss (only a small error is out-of-order packets and also to packet loss (only a small error is
introduced). Moreover, it greatly reduces the number of timestamps introduced). Moreover, it greatly reduces the number of timestamps
(only one per block for each network device) that have to be (only one per block for each network device) that have to be
collected by the management system. On the other hand, it only gives collected by the management system. On the other hand, it only gives
one measure for the duration of the block, and it doesn't give the one measure for the duration of the block, and it doesn't give the
minimum, maximum, and median delay values [RFC6703]. This limitation minimum, maximum, and median delay values [RFC6703]. This limitation
could be overcome by reducing the duration of the block (for could be overcome by reducing the duration of the block (for
instance, from 5 minutes to a few seconds), which implicates a highly instance, from 5 minutes to a few seconds), which implies a highly
optimized implementation of the method. optimized implementation of the method.
3.3.2. Double-Marking Methodology 3.3.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 has been described before and is based on to overcome this problem has been described before and is based on
the concept of mean delay. But the limitation of mean delay is that the concept of mean delay. But the limitation of mean delay is that
it doesn't give information about the delay value's distribution for it doesn't give information about the delay value's distribution for
the duration of the block. Additionally, it may be useful to have the duration of the block. Additionally, it may be useful to have
skipping to change at page 17, line 39 skipping to change at page 18, line 9
The Alternate-Marking technique does not require a strong The Alternate-Marking technique does not require a strong
synchronization, especially for packet loss and two-way delay synchronization, especially for packet loss and two-way delay
measurement. Only one-way delay measurement requires network devices measurement. Only one-way delay measurement requires network devices
to have synchronized clocks. to have synchronized clocks.
Color switching is the reference for all the network devices, and the Color switching is the reference for all the network devices, and the
only requirement to be achieved is that all network devices have to only requirement to be achieved is that all network devices have to
recognize the right batch along the path. recognize the right batch along the path.
If the length of the measurement period is L time units, then all Section 3.2 specifies the level of synchronization accuracy so that
network devices must be synchronized to the same clock reference with all network devices consistently match the color bit to the correct
an accuracy of +/- L/2 time units (without considering network block.
delay). This level of accuracy guarantees that all network devices
consistently match the color bit to the correct block. For example,
if the color is toggled every second (L = 1 second), then clocks must
be synchronized with an accuracy of +/- 0.5 second to a common time
reference.
This synchronization requirement can be satisfied even with a This synchronization requirement can be satisfied even with a
relatively inaccurate synchronization method. This is true for relatively inaccurate synchronization method. This is true for
packet loss and two-way delay measurement, but not for one-way delay packet loss and two-way delay measurement, but not for one-way delay
measurement, where clock synchronization must be accurate. measurement, where clock synchronization must be accurate.
Therefore, a system that uses only packet loss and two-way delay Therefore, a system that uses only packet loss and two-way delay
measurement does not require synchronization. This is because the measurement does not require synchronization. This is because the
value of the clocks of network devices does not affect the value of the clocks of network devices does not affect the
computation of the two-way delay measurement. computation of the two-way delay measurement.
skipping to change at page 19, line 8 skipping to change at page 19, line 21
When the nodes or NMS see, for example, the same BNs associated with When the nodes or NMS see, for example, the same BNs associated with
two packet counts from an upstream and a downstream node, two packet counts from an upstream and a downstream node,
respectively, it considers that these two packet counts correspond to respectively, it considers that these two packet counts correspond to
the same block, i.e., these two packet counts belong to the same the same block, i.e., these two packet counts belong to the same
block of markers from the upstream and downstream nodes. The block of markers from the upstream and downstream nodes. The
assumption of this BN mechanism is that the measurement nodes are assumption of this BN mechanism is that the measurement nodes are
time synchronized. This requires the measurement nodes to have a time synchronized. This requires the measurement nodes to have a
certain time synchronization capability (e.g., the Network Time certain time synchronization capability (e.g., the Network Time
Protocol (NTP) [RFC5905] or the IEEE 1588 Precision Time Protocol Protocol (NTP) [RFC5905] or the IEEE 1588 Precision Time Protocol
(PTP) [IEEE-1588]). Synchronization aspects are further discussed in (PTP) [IEEE-1588]). Synchronization aspects are further discussed in
Section 4.1. Section 3.2.
4.3. Packet Reordering 4.3. Packet Reordering
Due to ECMP, packet reordering is very common in an IP network. The Due to ECMP, packet reordering is very common in an IP network. The
accuracy of a marking-based PM, especially packet loss measurement, accuracy of a marking-based PM, especially packet loss measurement,
may be affected by packet reordering. Take a look at the following may be affected by packet reordering. 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 19, line 39 skipping to change at page 20, line 5
In general, there is the need to assign packets with the marker of In general, there is the need to assign packets with the marker of
"B" or "A" to the right interval blocks. Most of the packet "B" or "A" to the right interval blocks. Most of the packet
reordering occurs at the edge of adjacent blocks, and they are easy reordering occurs at the edge of adjacent blocks, and they are easy
to handle if the interval of each block is sufficiently large. Then, to handle if the interval of each block is sufficiently large. Then,
it can be assumed that the packets with different markers belong to it can be assumed that the packets with different markers belong to
the block that they are closer to. If the interval is small, it is the block that they are closer to. If the interval is small, it is
difficult and sometimes impossible to determine to which block a difficult and sometimes impossible to determine to which block a
packet belongs. packet belongs.
To choose a proper interval is important, and how to choose a proper Section 3.2 provides a guidance on how to choose a proper interval
interval is out of the scope of this document. But an implementation and mitigate packet reordering issues.
SHOULD provide a way to configure the interval and allow a certain
degree of packet reordering. 4.4. Packet Fragmentation
Fragmentation can be managed with the Alternate-Marking Method and in
particular it is possible to give the following guidance:
Marking nodes MUST mark all fragments if there are flag bits to
use (i.e. it is in the specific encapsulation), as if they were
separate packets.
Nodes that fragment packets within the measurement domain MUST NOT
replicate marks, but SHOULD mark the first fragment if they have
the capability to do so.
Measurement points MAY simply ignore unmarked fragments and count
marked fragments as full packets. However, if resources allow,
measurement points MAY make note of both marked and unmarked
initial fragments and only increment the corresponding counter if
(a) other fragments are also marked, or (b) it observes all other
fragments and they are unmarked.
The proposed approach allows the marking node to mark all the
fragments except in the case of fragmentation within the network
domain, in that event it is suggested to mark only the first
fragment. In addition it could be possible to take the counters
properly in order to keep track of both marked and unmarked
fragments.
5. Results of the Alternate Marking Experiment 5. Results of the Alternate Marking Experiment
The methodology described in the previous sections can be applied to The methodology described in the previous sections can be applied to
various performance measurement problems, as explained in [RFC8321]. various performance measurement problems, as explained in [RFC8321].
The only requirement is to select and mark the flow to be monitored; The only requirement is to select and mark the flow to be monitored;
in this way, packets are batched by the sender, and each batch is in this way, packets are batched by the sender, and each batch is
alternately marked such that it can be easily recognized by the alternately marked such that it can be easily recognized by the
receiver. receiver.
skipping to change at page 21, line 5 skipping to change at page 21, line 42
o flexibility: all the timestamp formats are allowed, because they o flexibility: all the timestamp formats are allowed, because they
are managed out of band. The format (the Network Time Protocol are managed out of band. The format (the Network Time Protocol
(NTP) [RFC5905] or the IEEE 1588 Precision Time Protocol (PTP) (NTP) [RFC5905] or the IEEE 1588 Precision Time Protocol (PTP)
[IEEE-1588]) depends on the precision you want; and [IEEE-1588]) depends on the precision you want; and
o no interoperability issues: the features required are available on o no interoperability issues: the features required are available on
all current routing platforms. Both a centralized or distributed all current routing platforms. Both a centralized or distributed
solution can be used to harvest data from the routers. solution can be used to harvest data from the routers.
Note that [I-D.zhou-ippm-enhanced-alternate-marking] extends the It is worth mentioning some related work: in particular
Alternate Marking Data Fields, to provide enhanced capabilities and [IEEE-Network-PNPM] explains the Alternate-Marking method together
allow advanced functionalities. with new mechanisms based on hashing techniques as also further
described in [I-D.mizrahi-ippm-marking]; while
[I-D.zhou-ippm-enhanced-alternate-marking] extends the Alternate-
Marking Data Fields, to provide enhanced capabilities and allow
advanced functionalities.
5.1. Controlled Domain requirement 5.1. Controlled Domain requirement
The Alternate Marking Method is an example of a solution limited to a The Alternate Marking Method is an example of a solution limited to a
controlled domain [RFC8799]. controlled domain [RFC8799].
A controlled domain is a managed network that selects, monitors, and A controlled domain is a managed network that selects, monitors, and
controls access by enforcing policies at the domain boundaries, in controls access by enforcing policies at the domain boundaries, in
order to discard undesired external packets entering the domain and order to discard undesired external packets entering the domain and
check internal packets leaving the domain. It does not necessarily check internal packets leaving the domain. It does not necessarily
skipping to change at page 24, line 19 skipping to change at page 25, line 15
packets, as mentioned above, the mechanism specified in this packets, as mentioned above, the mechanism specified in this
document can be applied just in the context of a controlled document can be applied just in the context of a controlled
domain; thus, the routers (or other network devices) are locally domain; thus, the routers (or other network devices) are locally
administered and this type of attack can be avoided. In addition, administered and this type of attack can be avoided. In addition,
an attacker can't gain information about network performance from an attacker can't gain information about network performance from
a single monitoring point; it must use synchronized monitoring a single monitoring point; it must use synchronized monitoring
points at multiple points on the path, because they have to do the points at multiple points on the path, because they have to do the
same kind of measurement and aggregation that Service Providers same kind of measurement and aggregation that Service Providers
using Alternate Marking must do. using Alternate Marking must do.
Attacks on the data collection and reporting of the statistics
between the monitoring points and the network management system can
interfere with the proper functioning of the system. Hence, the
channels used to report back flow statistics MUST be secured.
The privacy concerns of network measurement are limited because the The privacy concerns of network measurement are limited because the
method only relies on information contained in the header or method only relies on information contained in the header or
encapsulation without any release of user data. Although information encapsulation without any release of user data. Although information
in the header or encapsulation is metadata that can be used to in the header or encapsulation is metadata that can be used to
compromise the privacy of users, the limited marking technique in compromise the privacy of users, the limited marking technique in
this document seems unlikely to substantially increase the existing this document seems unlikely to substantially increase the existing
privacy risks from header or encapsulation metadata. It might be privacy risks from header or encapsulation metadata. It might be
theoretically possible to modulate the marking to serve as a covert theoretically possible to modulate the marking to serve as a covert
channel, but it would have a very low data rate if it is to avoid channel, but it would have a very low data rate if it is to avoid
adversely affecting the measurement systems that monitor the marking. adversely affecting the measurement systems that monitor the marking.
skipping to change at page 24, line 44 skipping to change at page 25, line 45
only to delay-colored packets, causing systematic error in the delay only to delay-colored packets, causing systematic error in the delay
measurements. As discussed in previous sections, the methods measurements. As discussed in previous sections, the methods
described in this document rely on an underlying time synchronization described in this document rely on an underlying time synchronization
protocol. Thus, by attacking the time protocol, an attacker can protocol. Thus, by attacking the time protocol, an attacker can
potentially compromise the integrity of the measurement. A detailed potentially compromise the integrity of the measurement. A detailed
discussion about the threats against time protocols and how to discussion about the threats against time protocols and how to
mitigate them is presented in RFC 7384 [RFC7384]. mitigate them is presented in RFC 7384 [RFC7384].
9. Contributors 9. Contributors
Tianran Zhou
Huawei Technologies
Email: zhoutianran@huawei.com
Xiao Min Xiao Min
ZTE Corp. ZTE Corp.
Email: xiao.min2@zte.com.cn Email: xiao.min2@zte.com.cn
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Alessandro Capello, Luca Castaldelli, The authors would like to thank Alessandro Capello, Luca Castaldelli,
Mach Chen and Lianshu Zheng for their contribution to the definition Mach Chen and Lianshu Zheng for their contribution to the definition
and the implementation of the method. and the implementation of the method.
skipping to change at page 25, line 28 skipping to change at page 26, line 28
[IEEE-1588] [IEEE-1588]
IEEE, "IEEE Standard for a Precision Clock Synchronization IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems", Protocol for Networked Measurement and Control Systems",
IEEE Std 1588-2008. IEEE Std 1588-2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
DOI 10.17487/RFC3393, November 2002,
<https://www.rfc-editor.org/info/rfc3393>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 11.2. Informative References
[I-D.fioccola-rfc8889bis]
Fioccola, G., Cociglio, M., Sapio, A., and R. Sisto,
"Multipoint Alternate-Marking Method", draft-fioccola-
rfc8889bis-00 (work in progress), November 2021.
[I-D.mizrahi-ippm-marking]
Mizrahi, T., Fioccola, G., Cociglio, M., Chen, M., and G.
Mirsky, "Marking Methods for Performance Measurement",
draft-mizrahi-ippm-marking-00 (work in progress), October
2021.
[I-D.zhou-ippm-enhanced-alternate-marking] [I-D.zhou-ippm-enhanced-alternate-marking]
Zhou, T., Fioccola, G., Liu, Y., Lee, S., Cociglio, M., Zhou, T., Fioccola, G., Liu, Y., Lee, S., Cociglio, M.,
and W. Li, "Enhanced Alternate Marking Method", draft- and W. Li, "Enhanced Alternate Marking Method", draft-
zhou-ippm-enhanced-alternate-marking-07 (work in zhou-ippm-enhanced-alternate-marking-07 (work in
progress), July 2021. progress), July 2021.
[IEEE-Network-PNPM] [IEEE-Network-PNPM]
IEEE Network, "AM-PM: Efficient Network Telemetry using IEEE Network, "AM-PM: Efficient Network Telemetry using
Alternate Marking", DOI 10.1109/MNET.2019.1800152, 2019. Alternate Marking", DOI 10.1109/MNET.2019.1800152, 2019.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
DOI 10.17487/RFC3393, November 2002,
<https://www.rfc-editor.org/info/rfc3393>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<https://www.rfc-editor.org/info/rfc4656>. <https://www.rfc-editor.org/info/rfc4656>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008, RFC 5357, DOI 10.17487/RFC5357, October 2008,
<https://www.rfc-editor.org/info/rfc5357>. <https://www.rfc-editor.org/info/rfc5357>.
skipping to change at page 27, line 19 skipping to change at page 28, line 39
[RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
"Alternate-Marking Method for Passive and Hybrid "Alternate-Marking Method for Passive and Hybrid
Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
January 2018, <https://www.rfc-editor.org/info/rfc8321>. January 2018, <https://www.rfc-editor.org/info/rfc8321>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/info/rfc8799>. <https://www.rfc-editor.org/info/rfc8799>.
[RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto,
"Multipoint Alternate-Marking Method for Passive and
Hybrid Performance Monitoring", RFC 8889,
DOI 10.17487/RFC8889, August 2020,
<https://www.rfc-editor.org/info/rfc8889>.
Appendix A. Changes Log Appendix A. Changes Log
Changes from RFC 8321 include: Changes from RFC 8321 include:
o Minor editorial changes o Minor editorial changes
o Replacement of the section on "Applications, Implementation, and o Replacement of the section on "Applications, Implementation, and
Deployment" with "Finding of the Alternate Marking Implementations Deployment" with "Finding of the Alternate Marking Implementations
and Deployments" and Deployments"
o Moved advantages and benefits of the method from "Introduction" to o Moved advantages and benefits of the method from "Introduction" to
the new section on "Finding of the Alternate Marking the new section on "Finding of the Alternate Marking
Implementations and Deployments" Implementations and Deployments"
o Removed section on "Hybrid Measurement" o Removed section on "Hybrid Measurement"
Changes in v-(01) include:
o Considerations on the reference: [IEEE-Network-PNPM]
o Clarified that the method based on a fixed timer is specified in
this document while the method based on a fixed number of packets
is only mentioned but not detailed.
o Explanation of the the intrinsic error in section 3.3.1 on
"Single-Marking Methodology"
o Deleted some parts in section 4 "Considerations" that no longer
apply
o New section on "Packet Fragmentation"
Authors' Addresses Authors' Addresses
Giuseppe Fioccola (editor) Giuseppe Fioccola (editor)
Huawei Technologies Huawei Technologies
Riesstrasse, 25 Riesstrasse, 25
Munich 80992 Munich 80992
Germany Germany
Email: giuseppe.fioccola@huawei.com Email: giuseppe.fioccola@huawei.com
Mauro Cociglio Mauro Cociglio
Telecom Italia Telecom Italia
Via Reiss Romoli, 274 Via Reiss Romoli, 274
Torino 10148 Torino 10148
Italy Italy
Email: mauro.cociglio@telecomitalia.it Email: mauro.cociglio@telecomitalia.it
Greg Mirsky Greg Mirsky
Ericsson Ericsson
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com
Tal Mizrahi Tal Mizrahi
Huawei Technologies Huawei Technologies
Email: tal.mizrahi.phd@gmail.com Email: tal.mizrahi.phd@gmail.com
Tianran Zhou
Huawei Technologies
156 Beiqing Rd.
Beijing 100095
China
Email: zhoutianran@huawei.com
 End of changes. 35 change blocks. 
89 lines changed or deleted 146 lines changed or added

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