< draft-fioccola-rfc8321bis-03.txt   draft-fioccola-rfc8321bis-04.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: August 27, 2022 G. Mirsky Expires: October 7, 2022 G. Mirsky
Ericsson Ericsson
T. Mizrahi T. Mizrahi
T. Zhou T. Zhou
Huawei Technologies Huawei Technologies
X. Min April 5, 2022
ZTE Corp.
February 23, 2022
Alternate-Marking Method Alternate-Marking Method
draft-fioccola-rfc8321bis-03 draft-fioccola-rfc8321bis-04
Abstract Abstract
This document describes the Alternate-Marking technique to perform This document describes the Alternate-Marking technique to perform
packet loss, delay, and jitter measurements on live traffic. This packet loss, delay, and jitter measurements on live traffic. This
technology can be applied in various situations and for different technology can be applied in various situations and for different
protocols. It could be considered Passive or Hybrid depending on the protocols. It could be considered Passive or Hybrid depending on the
application. This document obsoletes [RFC8321]. application. This document obsoletes [RFC8321].
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 40
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 August 27, 2022. This Internet-Draft will expire on October 7, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Overview of the Method . . . . . . . . . . . . . . . . . . . 4 2. Overview of the Method . . . . . . . . . . . . . . . . . . . 4
3. Detailed Description of the Method . . . . . . . . . . . . . 5 3. Detailed Description of the Method . . . . . . . . . . . . . 5
3.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 5 3.1. Packet Loss Measurement . . . . . . . . . . . . . . . . . 5
3.2. One-Way Delay Measurement . . . . . . . . . . . . . . . . 9 3.2. One-Way Delay Measurement . . . . . . . . . . . . . . . . 9
3.2.1. Single-Marking Methodology . . . . . . . . . . . . . 9 3.2.1. Single-Marking Methodology . . . . . . . . . . . . . 9
3.2.2. Double-Marking Methodology . . . . . . . . . . . . . 10 3.2.2. Double-Marking Methodology . . . . . . . . . . . . . 10
3.3. Delay Variation Measurement . . . . . . . . . . . . . . . 11 3.3. Delay Variation Measurement . . . . . . . . . . . . . . . 11
4. Alternate Marking Functions . . . . . . . . . . . . . . . . . 12 4. Alternate Marking Functions . . . . . . . . . . . . . . . . . 12
4.1. Marking the Packets . . . . . . . . . . . . . . . . . . . 12 4.1. Marking the Packets . . . . . . . . . . . . . . . . . . . 12
4.2. Counting and Timestamping Packets . . . . . . . . . . . . 13 4.2. Counting and Timestamping Packets . . . . . . . . . . . . 12
4.3. Data Collection and Correlation . . . . . . . . . . . . . 14 4.3. Data Collection and Correlation . . . . . . . . . . . . . 13
5. Synchronization and Timing . . . . . . . . . . . . . . . . . 15 5. Synchronization and Timing . . . . . . . . . . . . . . . . . 14
6. Packet Fragmentation . . . . . . . . . . . . . . . . . . . . 17 6. Packet Fragmentation . . . . . . . . . . . . . . . . . . . . 16
7. Results of the Alternate Marking Experiment . . . . . . . . . 17 7. Results of the Alternate Marking Experiment . . . . . . . . . 16
7.1. Controlled Domain requirement . . . . . . . . . . . . . . 19 7.1. Controlled Domain requirement . . . . . . . . . . . . . . 18
8. Compliance with Guidelines from RFC 6390 . . . . . . . . . . 19 8. Compliance with Guidelines from RFC 6390 . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 22
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . 23 13.1. Normative References . . . . . . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . 24 13.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Changes Log . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Changes Log . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Nowadays, most Service Providers' networks carry traffic with Most Service Providers' networks carry traffic with contents that are
contents that are highly sensitive to packet loss [RFC7680], delay highly sensitive to packet loss [RFC7680], delay [RFC7679], and
[RFC7679], and jitter [RFC3393]. jitter [RFC3393].
In view of this scenario, Service Providers need methodologies and Service Providers need methodologies and tools to monitor and
tools to monitor and measure network performance with an adequate accurately measure network performance, in order to constantly
accuracy, in order to constantly control the quality of experience control the quality of experience perceived by their customers.
perceived by their customers. Performance monitoring also provides Performance monitoring also provides useful information for improving
useful information for improving network management (e.g., isolation network management (e.g., isolation of network problems,
of network problems, troubleshooting, etc.). troubleshooting, etc.).
A lot of work related to Operations, Administration, and Maintenance RFC 7799 [RFC7799] defines Passive and Hybrid Methods of Measurement.
(OAM), which also includes performance monitoring techniques, has In particular, Passive Methods of Measurement are based solely on
been done by Standards Developing Organizations (SDOs): [RFC7276] observations of an undisturbed and unmodified packet stream of
provides a good overview of existing OAM mechanisms defined in the interest; Hybrid Methods are Methods of Measurement that use a
IETF, ITU-T, and IEEE. In the IETF, a lot of work has been done on combination of Active Methods and Passive Methods.
fault detection and connectivity verification, while a minor effort
has been thus far dedicated to performance monitoring. The IPPM WG
has defined standard metrics to measure network performance; however,
the methods developed in this WG mainly refer to focus on Active
measurement techniques. More recently, the MPLS WG has defined
mechanisms for measuring packet loss, one-way and two-way delay, and
delay variation in MPLS networks [RFC6374], but their applicability
to Passive measurements has some limitations, especially for pure
connection-less networks.
The lack of adequate tools to measure packet loss with the desired [RFC7276] provides a good overview of existing Operations,
accuracy drove an effort to design a new method for the performance Administration, and Maintenance (OAM) mechanisms defined in the IETF,
monitoring of live traffic, which is easy to implement and deploy. ITU-T, and IEEE. In the IETF, a lot of work has been done on fault
The effort led to the method described in this document: basically, detection and connectivity verification, while little has been thus
it is a Passive performance monitoring technique, potentially far dedicated to performance monitoring. The IETF has defined
applicable to any kind of packet-based traffic, including Ethernet, standard metrics to measure network performance; however, its methods
IP, and MPLS, both unicast and multicast. The method addresses mainly focus on Active measurement techniques.For example, [RFC6374]
primarily packet loss measurement, but it can be easily extended to defines mechanisms for measuring packet loss, one-way and two-way
one-way or two-way delay and delay variation measurements as well. delay, and delay variation in MPLS networks, but its applicability to
Passive measurements has some limitations, especially for connection-
less networks.
This document proposes a Passive performance monitoring technique,
potentially applicable to any kind of packet-based traffic, including
Ethernet, IP, and MPLS, both unicast and multicast. The method
addresses primarily packet loss measurement, but it can be easily
extended to one-way or two-way delay and delay 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. Therefore, the Alternate-Marking Method could be considered Hybrid or
In particular, Passive Methods of Measurement are based solely on Passive, depending on the case. In the case where the marking method
observations of an undisturbed and unmodified packet stream of is obtained by changing existing field values of the packets the
interest; Hybrid Methods are Methods of Measurement that use a technique is Hybrid. In the case where the marking field is
combination of Active Methods and Passive Methods. dedicated, reserved, and included in the protocol specification, the
Alternate-Marking technique can be considered as Passive.
Taking into consideration these definitions, the Alternate-Marking
Method could be considered Hybrid or Passive, depending on the case.
In the case where the marking method is obtained by changing existing
field values of the packets the technique is Hybrid. In the case
where the marking field is dedicated, reserved, and included in the
protocol specification, the Alternate-Marking technique can be
considered as Passive.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Overview of the Method 2. Overview of the Method
skipping to change at page 7, line 37 skipping to change at page 7, line 37
ingress interface, C(A)R2 and C(B)R2, to count the packets received ingress interface, C(A)R2 and C(B)R2, to count the packets received
on that interface and colored with A and B, respectively. When an A on that interface and colored with A and B, respectively. When an A
block ends, it is possible to compare C(A)R1 and C(A)R2 and calculate block ends, it is possible to compare C(A)R1 and C(A)R2 and calculate
the packet loss within the block; similarly, when the successive B the packet loss within the block; similarly, when the successive B
block terminates, it is possible to compare C(B)R1 with C(B)R2, and block terminates, it is possible to compare C(B)R1 with C(B)R2, and
so on, for every successive block. so on, for every successive block.
Likewise, by using two counters on the R2 egress interface, it is Likewise, by using two counters on the R2 egress interface, it is
possible to count the packets sent out of the R2 interface and use possible to count the packets sent out of the R2 interface and use
them as reference values to calculate the packet loss from R2 to any them as reference values to calculate the packet loss from R2 to any
measurement point down R2. measurement point downstream from R2.
Using a fixed timer for color switching offers better control over Using a fixed timer for color switching offers better control over
the method: the (time) length of the blocks can be chosen large the method: the (time) length of the blocks can be chosen large
enough to simplify the collection and the comparison of measures enough to simplify the collection and the comparison of measures
taken by different network devices. It's preferable to read the taken by different network devices. It's preferable to read the
value of the counters not immediately after the color switch: some value of the counters not immediately after the color switch: some
packets could arrive out of order and increment the counter packets could arrive out of order and increment the counter
associated with the previous block (color), so it is worth waiting associated with the previous block (color), so it is worth waiting
for some time. A safe choice is to wait L/2 time units (where L is for some time. A safe choice is to wait L/2 time units (where L is
the duration for each block) after the color switch, to read the the duration for each block) after the color switch, to read the
still counter of the previous color, so the possibility of reading a counter of the previous color. The drawback is that the longer the
running counter instead of a still one is minimized. The drawback is duration of the block, the less frequently the measurement can be
that the longer the duration of the block, the less frequent the taken.
measurement can be taken.
The timer-based batches is preferable because it is more
deterministic that the counter-based batches and it will be
considered hereafter.
It's worth mentioning two different strategies that can be used when Two different strategies that can be used when implementing the
implementing the method: method:
o flow-based: the flow-based strategy is used when only a limited o flow-based: the flow-based strategy is used when only a limited
number of traffic flows need to be monitored. According to this number of traffic flows need to be monitored. According to this
strategy, only a subset of the flows is colored. Counters for strategy, only a subset of the flows is colored. Counters for
packet loss measurements can be instantiated for each single flow, packet loss measurements can be instantiated for each single flow,
or for the set as a whole, depending on the desired granularity. or for the set as a whole, depending on the desired granularity.
A relevant problem with this approach is the necessity to know in A relevant problem with this approach is the necessity to know in
advance the path followed by flows that are subject to advance the path followed by flows that are subject to
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
skipping to change at page 13, line 15 skipping to change at page 13, line 7
4.2. Counting and Timestamping Packets 4.2. Counting and Timestamping 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 and timestamp the source and destination (included) have to count and timestamp the
colored packets that they receive and forward: this operation can be colored packets that they receive and forward: this operation can be
enabled on every router along the path or only on a subset, depending enabled on every router along the path or only on a subset, depending
on which network segment is being monitored (a single link, a on which network segment is being monitored (a single link, a
particular metro area, the backbone, or the whole path). Since the particular metro area, the backbone, or the whole path). Since the
color switches periodically between two values, two counters (one for color switches periodically between two values, two counters (one for
each value) are needed: one counter for packets with color A and one each value) are needed for each flow and for every interface being
counter for packets with color B. For each flow (or group of flows) monitored. The number of timestamps to be stored depends on the
being monitored and for every interface where the monitoring is method for delay measurement that is applied. Furthermore,
Active, two counters are needed. For example, in order to separately [I-D.fioccola-rfc8889bis] generalizes the counting for multipoint-to-
monitor three flows on a router with four interfaces involved, 24 multipoint flow.
counters are needed (two counters for each of the three flows on each
of the four interfaces). The number of timestamps to be stored
depends on the method for delay measurement that is applied.
Furthermore, [I-D.fioccola-rfc8889bis] generalizes 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, counting and timestamping operations are performed on that coloring, counting and timestamping operations are performed on
a link-by-link basis at each endpoint of the link. a link-by-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 or when to select the packets to be double-marked for
block, the routers must perform this operation when that block has delay measurement. It involves timing aspects to consider that are
ended; in other words, the counter for color A must be read when the further described in Section 5.
current block has color B, in order to be sure that the value of the
counter is stable. This task can be accomplished in two ways. The
general approach suggests reading the counters periodically, many
times during a block duration, and comparing these successive
readings: when the counter stops incrementing, it means that the
current block has ended, and its value can be elaborated safely.
Alternatively, if the coloring operation is performed on the basis of
a fixed timer, it is possible to configure the reading of the
counters according to that timer: for example, reading the counter
for color A every period in the middle of the subsequent block with
color B is a safe choice. A sufficient margin should be considered
between the end of a block and the reading of the counter, in order
to take into account any out-of-order packets. Regarding the
selection of the packet to be double-marked for delay measurement,
the same considerations for packet loss measurement apply also here
and it is reasonable to choose the double-marked packet in the middle
of the block. The timing aspects are further described in Section 5.
4.3. Data Collection and Correlation 4.3. Data Collection and Correlation
The nodes enabled to perform performance monitoring collect the value The nodes enabled to perform performance monitoring collect the value
of the counters and timestamps, but they are not able to directly use of the counters and timestamps, but they are not able to directly use
this information to measure packet loss and delay, because they only this information to measure packet loss and delay, because they only
have their own samples. have their own samples.
Data collection enables the transmission of the counters and Data collection enables the transmission of the counters and
timestamps as soon as it has been read. While, data correlation is timestamps as soon as it has been read. While, data correlation is
skipping to change at page 14, line 50 skipping to change at page 14, line 20
When data is collected on the upstream and downstream nodes, e.g., When data is collected on the upstream and downstream nodes, e.g.,
packet counts for packet loss measurement or timestamps for packet packet counts for packet loss measurement or timestamps for packet
delay measurement, and is periodically reported to or pulled by other delay measurement, and is periodically reported to or pulled by other
nodes or an NMS, a certain data correlation mechanism SHOULD be in nodes or an NMS, a certain data correlation mechanism SHOULD be in
use to help the nodes or NMS tell whether any two or more packet use to help the nodes or NMS tell whether any two or more packet
counts are related to the same block of markers or if any two counts are related to the same block of markers or if any two
timestamps are related to the same marked packet. timestamps are related to the same marked packet.
The Alternate-Marking Method described in this document literally The Alternate-Marking Method described in this document literally
splits the packets of the measured flow into different measurement splits the packets of the measured flow into different measurement
blocks; in addition, a Block Number (BN) could be assigned to each blocks. An implementation MAY use a Block Number (BN) for data
such measurement block. The BN is generated each time a node reads correlation. The BN MAY be assigned to each measurement block and
the data (packet counts or timestamps) and is associated with each associated with each packet count and timestamp reported to or pulled
packet count and timestamp reported to or pulled by other nodes or by other nodes or NMSs. When the nodes or NMS see, for example, the
NMSs. The value of a BN could be calculated as the modulo of the same BNs associated with two packet counts from an upstream and a
local time (when the data are read) and the interval of the marking downstream node, respectively, it considers that these two packet
time period. counts correspond to the same block. The assumption of this BN
mechanism is that the measurement nodes are time synchronized. This
When the nodes or NMS see, for example, the same BNs associated with requires the measurement nodes to have a certain time synchronization
two packet counts from an upstream and a downstream node, capability (e.g., the Network Time Protocol (NTP) [RFC5905] or the
respectively, it considers that these two packet counts correspond to IEEE 1588 Precision Time Protocol (PTP) [IEEE-1588]).
the same block, i.e., these two packet counts belong to the same
block of markers from the upstream and downstream nodes. The
assumption of this BN mechanism is that the measurement nodes are
time synchronized. This requires the measurement nodes to have a
certain time synchronization capability (e.g., the Network Time
Protocol (NTP) [RFC5905] or the IEEE 1588 Precision Time Protocol
(PTP) [IEEE-1588]).
5. Synchronization and Timing 5. Synchronization and Timing
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 is considered in the document. more deterministic, and it is considered in the document.
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.
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. And, 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 adequate accuracy in order to
where L is the fixed time duration of the block. So each colored guarantee that all network devices consistently match the marking bit
packet can be assigned to the right batch by each router. This is to the correct block. Additionally, in practice, besides clock
because the minimum time distance between two packets of the same errors, packet reordering is also very common in a packet network due
color but that belong to different batches is L time units. This to equal-cost multipath (ECMP). In particular, the delay between
level of accuracy guarantees that all network devices consistently measurement points is the main cause of out of order because each
match the marking bit to the correct block. packet can be delayed differently. If the block is sufficiently
large, packet reordering occurs only at the edge of adjacent blocks
If the value of L is not too small, this synchronization requirement and it can be easy to assign reordered packets to the right interval
could be satisfied even with a relatively inaccurate synchronization blocks.
method. This is true for packet loss and two-way delay measurement,
but not for one-way delay measurement, where clock synchronization
must be accurate. Therefore, a system that uses only packet loss and
two-way delay measurement does not require a very precise
synchronization. This is because the value of the clocks of network
devices does not affect the computation of the two-way delay
measurement.
But, in practice, besides clock errors, packet reordering is also
very common in a packet network due to equal-cost multipath (ECMP).
In particular, the delay between measurement points is the main cause
of out of order because each packet can be delayed differently. For
this reason, the accuracy of the Alternate-Marking Method, especially
for packet loss measurement, is affected by packet reordering.
If the time duration L of each block is too small, it may be
difficult to determine to which block the reordered packets belong.
However, if the value of L is sufficiently large, packet reordering
occurs only at the edge of adjacent blocks and it becomes easy to
assign reordered packets to the right interval blocks. This means
that, without considering clock error, we can wait L/2 after color
switching to be sure to take a still counter and mitigate the
reordering issues.
In summary, we need to take into account two contributions: clock In summary, we need to take into account two contributions: clock
error between network devices and the interval we need to wait to error between network devices and the interval we need to wait to
avoid packets being out of order because of network delay. avoid packets being out of order because of network delay.
The following figure explains both issues. The following figure explains both issues.
...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB... ...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB...
|<======================================>| |<======================================>|
| L | | L |
...=========>|<==================><==================>|<==========... ...=========>|<==================><==================>|<==========...
| L/2 L/2 | | L/2 L/2 |
|<===>| |<===>| |<===>| |<===>|
d | | d d | | d
|<==========================>| |<==========================>|
available counting interval available counting interval
Figure 4: Timing Aspects Figure 4: Timing Aspects
Where L is the time duration of each block.
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 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 data set and 99.7% of the samples are within 3 standard deviation of
the average. the average.
The guard band d is given by: The guard band d is given by:
skipping to change at page 17, line 4 skipping to change at page 15, line 40
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 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 data set and 99.7% of the samples are within 3 standard deviation of
the average. the average.
The guard band d is given by: The guard band d is given by:
d = A + D_avg + 3*D_stddev, d = A + D_avg + 3*D_stddev,
where A is the clock accuracy, D_avg is the average value of the where A is the clock accuracy, D_avg is the average value of the
network delay between the network devices, and D_stddev is the network delay between the network devices, and D_stddev is the
standard deviation of 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.
It is worth mentioning that, if the time duration L of each block is
not so small, the synchronization requirement could be satisfied even
with a relatively inaccurate synchronization method. This is true
for packet loss and two-way delay measurement, but not for one-way
delay measurement, where clock synchronization must be accurate.
Therefore, a system that uses only packet loss and two-way delay
measurement may not require a very precise synchronization. This is
because the value of the clocks of network devices does not affect
the computation of the two-way delay measurement.
6. Packet Fragmentation 6. Packet Fragmentation
Fragmentation can be managed with the Alternate-Marking Method and in Fragmentation can be managed with the Alternate-Marking Method and in
particular it is possible to give the following guidance: particular it is possible to give the following guidance:
Marking nodes MUST mark all fragments if there are flag bits to 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 use (i.e. it is in the specific encapsulation), as if they were
separate packets. separate packets.
Nodes that fragment packets within the measurement domain SHOULD, Nodes that fragment packets within the measurement domain SHOULD,
skipping to change at page 17, line 40 skipping to change at page 16, line 40
Measurement points MAY simply ignore unmarked fragments and count Measurement points MAY simply ignore unmarked fragments and count
marked fragments as full packets. However, if resources allow, marked fragments as full packets. However, if resources allow,
measurement points MAY make note of both marked and unmarked measurement points MAY make note of both marked and unmarked
initial fragments and only increment the corresponding counter if initial fragments and only increment the corresponding counter if
(a) other fragments are also marked, or (b) it observes all other (a) other fragments are also marked, or (b) it observes all other
fragments and they are unmarked. fragments and they are unmarked.
The proposed approach allows the marking node to mark all the The proposed approach allows the marking node to mark all the
fragments except in the case of fragmentation within the network fragments except in the case of fragmentation within the network
domain, in that event it is suggested to mark only the first domain, in that event it is suggested to mark only the first
fragment. In addition it could be possible to take the counters fragment.
properly in order to keep track of both marked and unmarked
fragments.
7. Results of the Alternate Marking Experiment 7. 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 20, line 23 skipping to change at page 19, line 21
delay [RFC7679] 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.
The steady state is an intrinsic characteristic of the marking The steady state is an intrinsic characteristic of the marking
method counters because the alternation of color makes the method counters because the alternation of color makes the counter
counters associated with each color still one at a time for the associated with a color inactive for the duration of a marking
duration of a marking period. period.
o Units of Measurement: the method calculates and reports the exact o Units of Measurement: the method calculates and reports the exact
number of packets sent by the source node and not received by the number of packets sent by the source node and not received by the
destination node. destination node.
o Measurement Point(s) with Potential Measurement Domain: the o Measurement Point(s) with Potential Measurement Domain: the
measurement can be performed between adjacent nodes, on a per-link measurement can be performed between adjacent nodes, on a per-link
basis, or along a multi-hop path, provided that the traffic under basis, or along a multi-hop path, provided that the traffic under
measurement follows that path. In case of a multi-hop path, the measurement follows that path. In case of a multi-hop path, the
measurements can be performed both end-to-end and hop-by-hop. measurements can be performed both end-to-end and hop-by-hop.
skipping to change at page 22, line 26 skipping to change at page 21, line 24
o Harm to the Measurement: the measurements could be harmed by o Harm to the Measurement: the measurements could be harmed by
routers altering the marking of the packets or by an attacker routers altering the marking of the packets or by an attacker
injecting artificial traffic. Authentication techniques, such as injecting artificial traffic. Authentication techniques, such as
digital signatures, may be used where appropriate to guard against digital signatures, may be used where appropriate to guard against
injected traffic attacks. Since the measurement itself may be injected traffic attacks. Since the measurement itself may be
affected by routers (or other network devices) along the path of affected by routers (or other network devices) along the path of
IP packets intentionally altering the value of marking bits of IP packets intentionally altering the value of marking bits of
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.
an attacker can't gain information about network performance from
a single monitoring point; it must use synchronized monitoring It is worth highlighting that an attacker can't gain information
points at multiple points on the path, because they have to do the about network performance from a single monitoring point; it must use
same kind of measurement and aggregation that Service Providers synchronized monitoring points at multiple points on the path,
using Alternate Marking must do. because they have to do the same kind of measurement and aggregation
that Service Providers using Alternate Marking must do.
Attacks on the data collection and reporting of the statistics Attacks on the data collection and reporting of the statistics
between the monitoring points and the network management system can between the monitoring points and the network management system can
interfere with the proper functioning of the system. Hence, the interfere with the proper functioning of the system. Hence, the
channels used to report back flow statistics MUST be secured. 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
skipping to change at page 23, line 15 skipping to change at page 22, line 14
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].
11. Contributors 11. Contributors
Xiao Min
ZTE Corp.
Email: xiao.min2@zte.com.cn
Mach(Guoyi) Chen Mach(Guoyi) Chen
Huawei Technologies Huawei Technologies
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
Alessandro Capello Alessandro Capello
Telecom Italia Telecom Italia
Email: alessandro.capello@telecomitalia.it Email: alessandro.capello@telecomitalia.it
12. Acknowledgements 12. Acknowledgements
skipping to change at page 24, line 14 skipping to change at page 23, line 19
[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>.
13.2. Informative References 13.2. Informative References
[I-D.fioccola-rfc8889bis] [I-D.fioccola-rfc8889bis]
Fioccola, G., Cociglio, M., Sapio, A., Sisto, R., and T. Fioccola, G., Cociglio, M., Sapio, A., Sisto, R., and T.
Zhou, "Multipoint Alternate-Marking Method", draft- Zhou, "Multipoint Alternate-Marking Method", draft-
fioccola-rfc8889bis-02 (work in progress), February 2022. fioccola-rfc8889bis-03 (work in progress), February 2022.
[I-D.mizrahi-ippm-marking] [I-D.mizrahi-ippm-marking]
Mizrahi, T., Fioccola, G., Cociglio, M., Chen, M., and G. Mizrahi, T., Fioccola, G., Cociglio, M., Chen, M., and G.
Mirsky, "Marking Methods for Performance Measurement", Mirsky, "Marking Methods for Performance Measurement",
draft-mizrahi-ippm-marking-00 (work in progress), October draft-mizrahi-ippm-marking-00 (work in progress), October
2021. 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., Cociglio, M., Lee, S.,
and W. Li, "Enhanced Alternate Marking Method", draft- and W. Li, "Enhanced Alternate Marking Method", draft-
zhou-ippm-enhanced-alternate-marking-08 (work in zhou-ippm-enhanced-alternate-marking-09 (work in
progress), January 2022. progress), February 2022.
[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 [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,
<https://www.rfc-editor.org/info/rfc3393>. <https://www.rfc-editor.org/info/rfc3393>.
skipping to change at page 27, line 4 skipping to change at page 26, line 6
"Results of the Alternate Marking Experiment" "Results of the Alternate Marking Experiment"
o Minor rewording in section 4.4 on "Packet Fragmentation" o Minor rewording in section 4.4 on "Packet Fragmentation"
Changes in v-(03) include: Changes in v-(03) include:
o Deleted numeric examples in sections on "Packet Loss Measurement" o Deleted numeric examples in sections on "Packet Loss Measurement"
and on "Single-Marking Methodology" and on "Single-Marking Methodology"
o New section on "Alternate Marking Functions" o New section on "Alternate Marking Functions"
o Moved sections 3.1.1 on "Coloring the Packets", 3.1.2 on "Counting o Moved sections 3.1.1 on "Coloring the Packets", 3.1.2 on "Counting
the Packets" and 3.1.3 on "Collecting Data and Calculating Packet the Packets" and 3.1.3 on "Collecting Data and Calculating Packet
Loss" into the new section on "Alternate Marking Functions" Loss" into the new section on "Alternate Marking Functions"
o Renamed sections 4.1 as "Marking the Packets", 4.2 as "Counting o Renamed sections 4.1 as "Marking the Packets", 4.2 as "Counting
and Timestamping Packets" and 4.3 as "Data Collection and and Timestamping Packets" and 4.3 as "Data Collection and
Correlation" Correlation"
o Merged old section on "Data Correlation" with section 4.3 on "Data o Merged old section on "Data Correlation" with section 4.3 on "Data
Collection and Correlation" Collection and Correlation"
o Moved and renamed section on "Timing Aspects" as "Synchronization o Moved and renamed section on "Timing Aspects" as "Synchronization
and Timing" and Timing"
o Merged old section on "Synchronization" with section on o Merged old section on "Synchronization" with section on
"Synchronization and Timing" "Synchronization and Timing"
o Merged old section on "Packet Reordering" with section on o Merged old section on "Packet Reordering" with section on
"Synchronization and Timing" "Synchronization and Timing"
Changes in v-(04) include:
o Revised "Introduction" section
o Revised sections 4.2 "Counting and Timestamping Packets" and 4.3
on "Data Collection and Correlation"
o Revised section 5 on "Synchronization and Timing"
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
skipping to change at page 28, line 4 skipping to change at page 27, line 16
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 Tianran Zhou
Huawei Technologies Huawei Technologies
156 Beiqing Rd. 156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: zhoutianran@huawei.com Email: zhoutianran@huawei.com
Xiao Min
ZTE Corp.
Email: xiao.min2@zte.com.cn
 End of changes. 33 change blocks. 
178 lines changed or deleted 138 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/