rfc9341xml2.original.xml   rfc9341.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- A set of on-line citation libraries are maintained on the xml2rfc web site.
The next line defines an entity named RFC2629, which contains the necessary
XML
for the reference element, and is used much later in the file. This XML co
ntains an
anchor (also RFC2629) which can be used to cross-reference this item in the
text.
You can also use local file names instead of a URI. The environment variab
le
XML_LIBRARY provides a search path of directories to look at to locate a
relative path name for the file. There has to be one entity for each item t
o be
referenced. -->
<!ENTITY RFC2234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2234.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2629.xml">
<!ENTITY RFC4234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4234.xml">
<!ENTITY RFC5575 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5575.xml">
<!-- There is also a library of current Internet Draft citations. It isn't a go
od idea to
actually use one for the template because it might have disappeared when yo
u come to test
this template. This is the form of the entity definition
&lt;!ENTITY I-D.mrose-writing-rfcs SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.mrose-writing-rfc
s.xml">
corresponding to a draft filename draft-mrose-writing-rfcs-nn.txt. The cita
tion will be
to the most recent draft in the sequence, and is updated roughly hourly on
the web site.
For working group drafts, the same principle applies: file name starts draf
t-ietf-wgname-..
and entity file is reference.I-D.ietf-wgname-... The corresponding entity
name is
I-D.ietf-wgname-... (I-D.mrose-writing-rfcs for the other example). Of cou
rse this doesn't
change when the draft version changes.
-->
<!-- Fudge for XMLmind which doesn't have this built in -->
<!ENTITY nbsp "&#160;">
]>
<!-- Extra statement used by XSLT processors to control the output style. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Processing Instructions can be placed here but if you are editing
with XMLmind (and maybe other XML editors) they are better placed
after the rfc element start tag as shown below. -->
<!-- Information about the document.
category values: std, bcp, info, exp, and historic
For Internet-Drafts, specify attribute "ipr".
(ipr values are: full3667, noModification3667, noDerivatives3667),
Also for Internet-Drafts, can specify values for
attributes "docName" and, if relevant, "iprExtract". Note
that the value for iprExtract is the anchor attribute
value of a section (such as a MIB specification) that can be
extracted for separate publication, and is only
useful whenhe value of "ipr" is not "full3667". -->
<!-- TODO: verify which attributes are specified only
by the RFC editor. It appears that attributes
"number", "obsoletes", "updates", and "seriesNo"
are specified by the RFC editor (and not by
the document author). -->
<rfc
category="std"
ipr="trust200902"
docName="draft-ietf-ippm-rfc8321bis-04"
obsoletes="8321" >
<!-- Processing Instructions- PIs (for a complete list and description,
see file http://xml.resource.org/authoring/README.html and below... --
>
<!-- Some of the more generally applicable PIs that most I-Ds might want to
use -->
<!-- Try to enforce the ID-nits conventions and DTD validity --> <!-- [CS] updated by Chris 10/03/22 -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?> <!-- Controls display of <cref> elements -->
<?rfc inline="no" ?> <!-- When no, put comments at end in comments sectio
n,
otherwise, put inline -->
<?rfc editing="no" ?> <!-- When yes, insert editing marks: editing marks c
onsist of a
string such as <29> printed in the blank line a
t the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists
on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?> <!-- If "yes" eliminates blank lines before main sect
ion entries. -->
<?rfc tocdepth="3"?> <!-- Sets the number of levels of sections/subsection
s... in ToC -->
<!-- Choose the options for the references. <!DOCTYPE rfc [
Some like symbolic tags in the references (and citations) and others pr <!ENTITY nbsp "&#160;">
efer <!ENTITY zwsp "&#8203;">
numbers. The RFC Editor always uses symbolic tags. <!ENTITY nbhy "&#8209;">
The tags used are the anchor attributes of the references. --> <!ENTITY wj "&#8288;">
<?rfc symrefs="yes"?> ]>
<?rfc sortrefs="yes" ?> <!-- If "yes", causes the references to be sorted in
order of tags.
This doesn't have any effect unless symrefs is
"yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by no <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" submissionType="I
t starting each ETF" consensus="true" ipr="trust200902" docName="draft-ietf-ippm-rfc8321bis-04"
main section on a new page but does not omit the blank lines between li number="9341" obsoletes="8321" updates="" xml:lang="en" tocInclude="true" tocDep
st items. th="3" symRefs="true" sortRefs="true" version="3">
If subcompact is also "yes" the blank lines between list items are also
omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- ***** FRONT MATTER ***** -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary
if the
full title is longer than 42 characters -->
<title abbrev="AltMark">Alternate-Marking Method</title> <title abbrev="AltMark">Alternate-Marking Method</title>
<seriesInfo name="RFC" value="9341"/>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Giuseppe Fioccola" initials="G." role="editor" surname= "Fioccola"> <author fullname="Giuseppe Fioccola" initials="G." role="editor" surname= "Fioccola">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>Riesstrasse, 25</street> <street>Riesstrasse, 25</street>
<city>Munich</city> <city>Munich</city>
<code>80992</code> <code>80992</code>
<region/> <region/>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>giuseppe.fioccola@huawei.com</email> <email>giuseppe.fioccola@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Mauro Cociglio" initials="M." surname="Cociglio"> <author fullname="Mauro Cociglio" initials="M." surname="Cociglio">
<organization>Telecom Italia</organization> <organization>Telecom Italia</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city/>
<city></city> <code/>
<country/>
<code></code>
<country></country>
</postal> </postal>
<email>mauro.cociglio@outlook.com</email> <email>mauro.cociglio@outlook.com</email>
</address> </address>
</author> </author>
<author fullname="Greg Mirsky" initials="G." surname="Mirsky"> <author fullname="Greg Mirsky" initials="G." surname="Mirsky">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<region/> <region/>
<code/> <code/>
<country/>
<country></country>
</postal> </postal>
<email>gregimirsky@gmail.com</email> <email>gregimirsky@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Tal Mizrahi" initials="T." surname="Mizrahi"> <author fullname="Tal Mizrahi" initials="T." surname="Mizrahi">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city/>
<city></city> <country/>
<country></country>
</postal> </postal>
<email>tal.mizrahi.phd@gmail.com</email> <email>tal.mizrahi.phd@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Tianran Zhou" initials="T." surname="Zhou"> <author fullname="Tianran Zhou" initials="T." surname="Zhou">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>156 Beiqing Rd.</street> <street>156 Beiqing Rd.</street>
<city>Beijing</city> <city>Beijing</city>
<code>100095</code> <code>100095</code>
<region/> <region/>
<country>China</country> <country>China</country>
</postal> </postal>
<email>zhoutianran@huawei.com</email> <email>zhoutianran@huawei.com</email>
</address> </address>
</author> </author>
<date year="2022" month="December" />
<date year="2022"/> <!-- month="March" is no longer necessary <area>tsv</area>
note also, day="30" is optional --> <workgroup>ippm</workgroup>
<!-- WARNING: If the month and year are the current ones, xml2rfc will fill <keyword>Performance</keyword>
in the day for <keyword>Measurement</keyword>
you. If only the year is specified, xml2rfc will fill in the current da <keyword>Monitoring</keyword>
y and month <keyword>Passive</keyword>
irrespective of the day. This silliness should be fixed in v1.31. --> <keyword>Hybrid</keyword>
<keyword>Loss</keyword>
<!-- Meta-data Declarations --> <keyword>Delay</keyword>
<keyword>Delay Variation</keyword>
<!-- Notice the use of &amp; as an escape for & which would otherwise
start an entity declaration, whereas we want a literal &. -->
<area></area>
<!-- WG name at the upperleft corner of the doc,
IETF fine for individual submissions. You can also
omit this element in which case in defaults to "Network Working Group"
-
a hangover from the ancient history of the IETF! -->
<workgroup></workgroup>
<!-- The DTD allows multiple area and workgroup elements but only the first
one has any
effect on output. -->
<!-- You can add <keyword/> elements here. They will be incorporated into H
TML output
files in a meta tag but they have no effect on text or nroff output. --
>
<abstract> <abstract>
<t>This document describes the Alternate-Marking technique to perform <t>This document describes the Alternate-Marking technique to perform
packet loss, delay, and jitter measurements on live traffic. packet loss, delay, and jitter measurements on live traffic.
This technology can be applied in various situations and for different protocols. This technology can be applied in various situations and for different protocols.
According to the classification defined in RFC 7799, it could be consid ered According to the classification defined in RFC 7799, it could be consid ered
Passive or Hybrid depending on the application. This document obsoletes RFC 8321.</t> Passive or Hybrid depending on the application. This document obsoletes RFC 8321.</t>
</abstract> </abstract>
</front>
</front> <middle>
<section anchor="intro" numbered="true" toc="default">
<middle> <name>Introduction</name>
<section anchor="intro" title="Introduction">
<t>Most Service Providers' networks carry traffic with contents <t>Most Service Providers' networks carry traffic with contents
that are highly sensitive to packet loss <xref target="RFC7680"></xref> that are highly sensitive to packet loss <xref target="RFC7680" format=
, "default"/>,
delay <xref target="RFC7679"></xref>, and jitter <xref target="RFC3393" delay <xref target="RFC7679" format="default"/>, and jitter <xref targe
></xref>.</t> t="RFC3393" format="default"/>.</t>
<t>Methodologies and tools are therefore needed to monitor and accurately measure <t>Methodologies and tools are therefore needed to monitor and accurately measure
network performance, in order to constantly control the quality of expe rience network performance, in order to constantly control the quality of expe rience
perceived by the end customers. Performance monitoring also provides usefu l information for perceived by the end customers. Performance monitoring also provides usefu l information for
improving network management (e.g., isolation of network problems, trou bleshooting, etc.).</t> improving network management (e.g., isolation of network problems, trou bleshooting, etc.).</t>
<t><xref target="RFC7799" format="default"/> defines Active, Passive, and
<t><xref target="RFC7799">RFC 7799</xref> defines Active, Passive and H Hybrid Methods of Measurement.
ybrid Methods of Measurement.
In particular, Active Methods of Measurement depend on a dedicated meas urement packet stream; In particular, Active Methods of Measurement depend on a dedicated meas urement packet stream;
Passive Methods of Measurement are based solely on observations of an u ndisturbed and unmodified Passive Methods of Measurement are based solely on observations of an u ndisturbed and unmodified
packet stream of interest; Hybrid Methods are Methods of Measurement th at use a combination of packet stream of interest; Hybrid Methods are Methods of Measurement th at use a combination of
Active Methods and Passive Methods.</t> Active Methods and Passive Methods.</t>
<t>This document proposes a performance monitoring technique, called Al <t>This document proposes a performance monitoring technique, called the "
ternate-Marking Method, Alternate-Marking Method",
which is potentially applicable to any kind of packet-based traffic, in which is potentially applicable to any kind of packet-based traffic, bo
cluding Ethernet, IP, and MPLS, th point-to-point unicast and multicast, including Ethernet, IP, and MPLS. The m
both unicast and multicast. The method addresses primarily packet loss ethod primarily addresses packet-loss measurement, but it can be easily
measurement, but it can be easily
extended to one-way or two-way delay and delay variation measurements a s well.</t> extended to one-way or two-way delay and delay variation measurements a s well.</t>
<t>The Alternate-Marking methodology, described in this document, allows t
<t>The Alternate-Marking methodology, described in this document, allow he synchronization of the measurements
s the synchronization of the measurements
at different points by dividing the packet flow into batches. So it is possible to get coherent counters and timestamps at different points by dividing the packet flow into batches. So it is possible to get coherent counters and timestamps
in every marking period and therefore measure the performance metrics f in every marking period and therefore measure the Performance Metrics f
or the monitored flow.</t> or the monitored flow.</t>
<t>The method has been explicitly designed for Passive or Hybrid measureme
<t>The method has been explicitly designed for Passive or Hybrid measureme nts as stated in <xref target="RFC8321" format="default"/>.
nts as stated in <xref target="RFC8321"></xref>. But, according to the definitions of <xref target="RFC7799" format="def
But, according to the definitions of <xref target="RFC7799">RFC 7799</x ault"/>, the Alternate-Marking Method can be classified
ref>, the Alternate-Marking Method can be classified as Hybrid Type I. Indeed, Alternate Marking can be implemented by using
as Hybrid Type I. Indeed, the Alternate-Marking can be implemented by u reserved bits in the protocol header, and
sing reserved bits in the protocol header and
the change in value of these marking bits at the domain edges (and not along the path) is formally considered a the change in value of these marking bits at the domain edges (and not along the path) is formally considered a
modification of the stream of interest.</t> modification of the stream of interest.</t>
<t>It is worth mentioning that this is a methodology document, so the m echanism that can be used to transmit <t>It is worth mentioning that this is a methodology document, so the m echanism that can be used to transmit
the counters and the timestamps is out of scope here. Additional detail s about the applicability of the Alternate-Marking the counters and the timestamps is out of scope here. Additional detail s about the applicability of the Alternate-Marking
methodology are described in <xref target="IEEE-Network-PNPM"/>.</t> methodology are described in <xref target="IEEE-NETWORK-PNPM" format="d
efault"/>.</t>
<section title="Summary of Changes from RFC 8321"> <section numbered="true" toc="default">
<t>This document defines the Alternate-Marking Method, addressing <name>Summary of Changes from RFC 8321</name>
ambiguities and building on its experimental phase that was based on
the original specification <xref target="RFC8321"></xref>.</t>
<t>The relevant changes are:<list style="symbols">
<t>Added the recommendations about the methods to employ in case
one or two flag bits
are available for marking (<xref target="finding"></xref>).</t>
<t>Changed the structure to improve the readability.</t>
<t>Removed the wording about the initial experiments of the metho
d and considerations
that no longer apply.</t>
<t>Extended the description of detailed aspects of the methodology, e.g.
synchronization,
timing, packet fragmentation, marked and unmarked traffic handlin
g.</t>
</list></t>
<t>It is important to note that all the changes are totally backward co <t>This document defines the Alternate-Marking Method, addressing
mpatible with <xref target="RFC8321"></xref>
and no new additional technique has been introduced in this document co
mpared to <xref target="RFC8321"></xref>.</t>
</section> ambiguities and building on its experimental phase that was based on
the original specification <xref target="RFC8321" format="default"/>.</
t>
<t>The relevant changes are:</t>
<ul spacing="normal">
<li>Added the recommendations about the methods to employ in case one
or two flag bits
are available for marking (<xref target="finding" format="default
"/>).</li>
<li>Changed the structure to improve the readability.</li>
<li>Removed the wording about the initial experiments of the method an
d considerations
that no longer apply.</li>
<li>Extended the description of detailed aspects of the methodology, e
.g., synchronization,
timing, packet fragmentation, and marked and unmarked traffic han
dling.</li>
</ul>
<t>It is important to note that all the changes are totally backward com
patible with <xref target="RFC8321" format="default"/>
and no new additional technique has been introduced in this document co
mpared to <xref target="RFC8321" format="default"/>.</t>
</section>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<section title="Requirements Language"> <t>
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"MAY", and "OPTIONAL" in this document are to be interpreted as NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
described in BCP 14 <xref target="RFC2119" /> <xref target="RFC8174" /> wh RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
en, and only when, they "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
appear in all capitals, as shown here.</t> be interpreted as
</section> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section>
<section anchor="brief" title="Overview of the Method"> <section anchor="brief" numbered="true" toc="default">
<t>In order to perform packet loss measurements on a production traffic fl <name>Overview of the Method</name>
ow, <t>In order to perform packet-loss measurements on a production traffic fl
ow,
different approaches exist. The most intuitive one consists in numbering different approaches exist. The most intuitive one consists in numbering
the packets so that each router that receives the flow can immediately the packets so that each router that receives the flow can immediately
detect a packet that is missing. This approach, though very simple in theo ry, is detect a packet that is missing. This approach, though very simple in theo ry, is
not simple to achieve: it requires the insertion of a sequence number not simple to achieve: it requires the insertion of a sequence number
into each packet, and the devices must be able to extract the number and into each packet, and the devices must be able to extract the number and
check it in real time. Such a task can be difficult to implement on live check it in real time. Such a task can be difficult to implement on live
traffic: if UDP is used as the transport protocol, the sequence number traffic: if UDP is used as the transport protocol, the sequence number
is not available; on the other hand, if a higher-layer sequence number is not available; on the other hand, if a higher-layer sequence number
(e.g., in the RTP header) is used, extracting that information from each (e.g., in the RTP header) is used, extracting that information from each
packet and processing it in real time could overload the device.</t> packet and processing it in real time could overload the device.</t>
skipping to change at line 332 skipping to change at line 196
to read the counter. A possible solution to overcome this problem is to to read the counter. A possible solution to overcome this problem is to
virtually split the flow in consecutive blocks by periodically virtually split the flow in consecutive blocks by periodically
inserting a delimiter so that each counter refers exactly to the same bloc k of inserting a delimiter so that each counter refers exactly to the same bloc k of
packets. The delimiter could be, for example, a special packet inserted packets. The delimiter could be, for example, a special packet inserted
artificially into the flow. However, delimiting the flow using specific artificially into the flow. However, delimiting the flow using specific
packets has some limitations. First, it requires generating additional packets has some limitations. First, it requires generating additional
packets within the flow and requires the equipment to be able to process packets within the flow and requires the equipment to be able to process
those packets. In addition, the method is vulnerable to out-of-order those packets. In addition, the method is vulnerable to out-of-order
reception of delimiting packets and, to a lesser extent, to their reception of delimiting packets and, to a lesser extent, to their
loss.</t> loss.</t>
<t>The method proposed in this document follows the second approach, but <t>The method proposed in this document follows the second approach, but
it doesn't use additional packets to virtually split the flow in blocks. it doesn't use additional packets to virtually split the flow in blocks.
Instead, it "marks" the packets so that the packets belonging to the Instead, it "marks" the packets so that the packets belonging to the
same block will have the same notional "color", whilst consecutive blocks same block will have the same notional "color", whilst consecutive blocks
will have different colors. Each change of color represents a sort of will have different colors. Each change of color represents a sort of
auto-synchronization signal that enhances the consistency of auto-synchronization signal that enhances the consistency of
measurements taken by different devices along the path.</t> measurements taken by different devices along the path.</t>
<t><xref target="Measurements" format="default"/> represents a very simple
<t><xref target="Measurements"></xref> represents a very simple network an network and shows
d shows
how the method can be used to measure packet loss on different network segments: by how the method can be used to measure packet loss on different network segments: by
enabling the measurement on several interfaces along the path, it is enabling the measurement on several interfaces along the path, it is
possible to perform link monitoring, node monitoring, or end-to-end possible to perform link monitoring, node monitoring, or end-to-end
monitoring. The method is flexible enough to measure packet loss on any monitoring. The method is flexible enough to measure packet loss on any
segment of the network and can be used to isolate the faulty segment of the network and can be used to isolate the faulty
element.</t> element.</t>
<figure anchor="Measurements">
<figure anchor="Measurements" title="Available Measurements"> <name>Available Measurements</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Traffic Flow Traffic Flow
========================================================> ========================================================>
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
---<> R1 <>-----<> R2 <>-----<> R3 <>-----<> R4 <>--- ---<> R1 <>-----<> R2 <>-----<> R3 <>-----<> R4 <>---
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
. . . . . . . . . . . .
. . . . . . . . . . . .
. <------> <-------> . . <------> <-------> .
. Node Packet Loss Link Packet Loss . . Node Packet Loss Link Packet Loss .
. . . .
<---------------------------------------------------> <--------------------------------------------------->
End-to-End Packet Loss End-to-End Packet Loss
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="detailed" toc="include" numbered="true">
<section anchor="detailed" title="Detailed Description of the Method" <name>Detailed Description of the Method</name>
toc="include">
<t>This section describes, in detail, how the method operates. A special e mphasis <t>This section describes, in detail, how the method operates. A special e mphasis
is given to the measurement of packet loss, which represents the core is given to the measurement of packet loss, which represents the core
application of the method, but applicability to delay and jitter application of the method, but applicability to delay and jitter
measurements is also considered.</t> measurements is also considered.</t>
<section anchor="ploss" numbered="true" toc="default">
<section anchor="ploss" title="Packet Loss Measurement"> <name>Packet-Loss Measurement</name>
<t>The basic idea is to virtually split traffic flows into consecutive <t>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 if different network devices along the path, it is possible to measure if
packet loss occurred in any single block between any two points.</t> packet loss occurred in any single block between any two points.</t>
<t>As discussed in the previous section, a simple way to create the <t>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 alternate consecutive blocks will have different packets belonging to alternate 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:<list style="sy block depends on the criterion used to create the blocks:</t>
mbols"> <ul spacing="normal">
<li>if the color is switched after a fixed number of packets, then eac
<t>if the color is switched after a fixed number of packets, then h block
each block will contain the same number of packets (except for any losses); and </l
will contain the same number of packets (except for any losses); and </t i>
> <li>if the color is switched according to a fixed timer, then the numb
er
<t>if the color is switched according to a fixed timer, then the number
of packets may be different in each block depending on the packet of packets may be different in each block depending on the packet
rate.</t> rate.</li>
</list></t> </ul>
<t>The use of a fixed timer for the creation of blocks is <bcp14>REQUIRE
<t>The use of a fixed timer for the creation of blocks is REQUIRE D</bcp14> when implementing
D when implementing
this specification. this specification.
The switching after a fixed number of packets is an additional po ssibility, but The switching after a fixed number of packets is an additional po ssibility, but
its detailed specification is out of scope. An example of applica tion is in its detailed specification is out of scope. An example of applica tion is in
<xref target="I-D.ietf-ippm-explicit-flow-measurements" format="d efault"/>.</t> <xref target="I-D.ietf-ippm-explicit-flow-measurements" format="d efault"/>.</t>
<t>The following figure shows how a flow appears when it is split into t raffic blocks <t>The following figure shows how a flow appears when it is split into t raffic blocks
with colored packets.</t> with colored packets.</t>
<figure anchor="coloring">
<figure anchor="coloring" title="Traffic Coloring"> <name>Traffic Coloring</name>
<artwork><![CDATA[A: packet with A coloring <artwork name="" type="" align="left" alt=""><![CDATA[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
-------------------------------------------------------------------> ------------------------------------------------------------------->
... | Block 5 | Block 4 | Block 3 | Block 2 | Block 1 ... | Block 5 | Block 4 | Block 3 | Block 2 | Block 1
| | | | | | | | | |
]]></artwork> ]]></artwork>
</figure> </figure>
<t><xref target="FIG_simple_network"></xref> shows how the method can <t><xref target="FIG_simple_network" format="default"/> shows how the me thod can
be used to measure link packet loss between two adjacent nodes.</t> be used to measure link packet loss between two adjacent nodes.</t>
<t>Referring to the figure, let's assume we want to monitor the packet <t>Referring to the figure, let's assume we want to monitor the packet
loss on the link between two routers: router R1 and router R2. loss on the link between two routers: router R1 and router R2.
According to the method, the traffic is colored alternatively with According to the method, the traffic is colored alternatively with
two different colors: A and B. Whenever the color changes, the two different colors: A and B. Whenever the color changes, the
transition generates a sort of square-wave signal, as depicted in the transition generates a sort of square-wave signal, as depicted in the
following figure.</t> following figure.</t>
<figure anchor="FIG_simple_network">
<figure anchor="FIG_simple_network" title="Computation of Link Packet Lo <name>Computation of Link Packet Loss</name>
ss"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
Color A ----------+ +-----------+ +---------- Color A ----------+ +-----------+ +----------
| | | | | | | |
Color B +-----------+ +-----------+ Color B +-----------+ +-----------+
Block n ... Block 3 Block 2 Block 1 Block n ... Block 3 Block 2 Block 1
<---------> <---------> <---------> <---------> <---------> <---------> <---------> <---------> <---------> <--------->
Traffic Flow Traffic Flow
===========================================================> ===========================================================>
Color ...AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA... Color ...AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA...
===========================================================> ===========================================================>
skipping to change at line 445 skipping to change at line 300
Color A ----------+ +-----------+ +---------- Color A ----------+ +-----------+ +----------
| | | | | | | |
Color B +-----------+ +-----------+ Color B +-----------+ +-----------+
Block n ... Block 3 Block 2 Block 1 Block n ... Block 3 Block 2 Block 1
<---------> <---------> <---------> <---------> <---------> <---------> <---------> <---------> <---------> <--------->
Traffic Flow Traffic Flow
===========================================================> ===========================================================>
Color ...AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA... Color ...AAAAAAAAAAA BBBBBBBBBBB AAAAAAAAAAA BBBBBBBBBBB AAAAAAA...
===========================================================> ===========================================================>
]]></artwork> ]]></artwork>
</figure> </figure>
<t/>
<t></t>
<t>Traffic coloring can be done by R1 itself if the traffic is not alrea dy colored. <t>Traffic coloring can be done by R1 itself if the traffic is not alrea dy colored.
R1 needs two counters, C(A)R1 and C(B)R1, on its egress R1 needs two counters, C(A)R1 and C(B)R1, on its egress
interface: C(A)R1 counts the packets with color A and C(B)R1 counts interface: C(A)R1 counts the packets with color A and C(B)R1 counts
those with color B. As long as traffic is colored as A, only counter those with color B. As long as traffic is colored as A, only counter
C(A)R1 will be incremented, while C(B)R1 is not incremented; C(A)R1 will be incremented, while C(B)R1 is not incremented;
conversely, when the traffic is colored as B, only C(B)R1 is conversely, when the traffic is colored as B, only C(B)R1 is
incremented. C(A)R1 and C(B)R1 can be used as reference values to incremented. C(A)R1 and C(B)R1 can be used as reference values to
determine the packet loss from R1 to any other measurement point down determine the packet loss from R1 to any other measurement point down
the path. Router R2, similarly, will need two counters on its ingress the path. Router R2, similarly, will need two counters on its ingress
interface, C(A)R2 and C(B)R2, to count the packets received on that inte rface and colored interface, C(A)R2 and C(B)R2, to count the packets received on that inte rface and colored
skipping to change at line 465 skipping to change at line 318
conversely, when the traffic is colored as B, only C(B)R1 is conversely, when the traffic is colored as B, only C(B)R1 is
incremented. C(A)R1 and C(B)R1 can be used as reference values to incremented. C(A)R1 and C(B)R1 can be used as reference values to
determine the packet loss from R1 to any other measurement point down determine the packet loss from R1 to any other measurement point down
the path. Router R2, similarly, will need two counters on its ingress the path. Router R2, similarly, will need two counters on its ingress
interface, C(A)R2 and C(B)R2, to count the packets received on that inte rface and colored interface, C(A)R2 and C(B)R2, to count the packets received on that inte rface and colored
with A and B, respectively. When an A 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 so block terminates, it is possible to compare C(B)R1 with C(B)R2, and so
on, for every successive block.</t> on, for every successive block.</t>
<t>Likewise, by using two counters on the R2 egress interface, it is <t>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 them as 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 reference values to calculate the packet loss from R2 to any
measurement point downstream from R2.</t> measurement point downstream from R2.</t>
<t>The length of the blocks can be chosen large enough to simplify <t>The length of the blocks can be chosen large enough to simplify
the collection and the comparison of measures taken by different the collection and the comparison of measures taken by different
network devices. It's preferable to read the value of the counter s network devices. It's preferable to read the value of the counter s
not immediately after the color switch: some packets could arrive not immediately after the color switch: some packets could arrive
out of order and increment the counter associated with the out of order and increment the counter associated with the
previous block (color), so it is worth waiting for some time. previous block (color), so it is worth waiting for some time.
A safe choice is to wait L/2 time units (where L is the duration 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 counter of for each block) after the color switch, to read the counter of
the previous color (<xref target="sync-timing"/>). the previous color (<xref target="sync-timing" format="default"/> ).
The drawback is that the longer the duration of the block, the le ss The drawback is that the longer the duration of the block, the le ss
frequently the measurement can be taken.</t> frequently the measurement can be taken.</t>
<t>Two different strategies that can be used when implementing the metho d are:</t>
<t>Two different strategies that can be used when implementing th <dl>
e method:<list style="symbols"> <dt>flow-based:
</dt>
<dd>the flow-based strategy is used when well-defined traffic flows
need to be monitored. According to this strategy, only the specified
flow is colored. Counters for packet-loss measurements can be
instantiated for each single flow, or for the set as a whole,
depending on the desired granularity. With this approach, it is
necessary to know in advance the path followed by flows that are
subject to measurement. Path rerouting and traffic load balancing
need to be taken into account.
</dd>
<t>flow-based: the flow-based strategy is used when well defined <dt>link-based:
traffic flows need to be monitored. According to this strategy, </dt>
only the specified flow is colored. Counters for packet loss me <dd>measurements are performed on all the traffic on a link-by-link
asurements basis. The link could be a physical link or a logical link. Counters
can be instantiated for each single flow, or for the set as a w could be instantiated for the traffic as a whole or for each traffic
hole, class (in case it is desired to monitor each class separately), but
depending on the desired granularity. With this approach, there in the second case, two counters are needed for each class.
is the necessity </dd>
to know in advance the path followed by flows that are subject
to measurement.
Path rerouting and traffic load-balancing need to be taken into
account.</t>
<t>link-based: measurements are performed on all the traffic on a </dl>
link-by-link basis. The link could be a physical link or 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 each class
separately),
but in the second case, two counters are needed for each class.
</t>
</list></t>
<t>The flow-based strategy is REQUIRED when implementing this spe cification. <t>The flow-based strategy is <bcp14>REQUIRED</bcp14> when implementing this spe cification.
It requires the identification of the flow to be monitored and th e discovery It requires the identification of the flow to be monitored and th e discovery
of the path followed by the selected flow. It is possible to moni tor a single flow of the path followed by the selected flow. It is possible to moni tor a single flow
or multiple flows grouped together, but in this case, measurement is consistent or multiple flows grouped together, but in this case, measurement is consistent
only if all the flows in the group follow the same path. only if all the flows in the group follow the same path.
Moreover, if a measurement is performed by grouping many flows, it is no t Moreover, if a measurement is performed by grouping many flows, it is no t
possible to determine exactly which flow was affected by packet l oss. possible to determine exactly which flow was affected by packet l oss.
In order to have measures per single flow, it is necessary to con figure In order to have measures per single flow, it is necessary to con figure
counters for each specific flow. Once the flow(s) to be monitored has counters for each specific flow. Once the flow(s) to be monitored has
been identified, it is necessary to configure the monitoring on t he proper nodes. been identified, it is necessary to configure the monitoring on t he proper nodes.
Configuring the monitoring means configuring the rule to intercept the Configuring the monitoring means configuring the rule to intercept the
skipping to change at line 522 skipping to change at line 381
an end-to-end monitoring, it is sufficient to enable the monitoring on an end-to-end monitoring, it is sufficient to enable the monitoring on
the first- and last-hop routers of the path: the mechanism is the first- and last-hop routers of the path: the mechanism is
completely transparent to intermediate nodes and independent of the completely transparent to intermediate nodes and independent of the
path followed by traffic flows. On the contrary, to monitor the flow on path followed by traffic flows. On the contrary, to monitor the flow on
a hop-by-hop basis along its whole path, it is necessary to enable the a hop-by-hop basis along its whole path, it is necessary to enable the
monitoring on every node from the source to the destination. In case the monitoring on every node from the source to the destination. In case the
exact path followed by the flow is not known a priori (i.e., the flow ha s exact path followed by the flow is not known a priori (i.e., the flow ha s
multiple paths to reach the destination), it is necessary to enable the multiple paths to reach the destination), it is necessary to enable the
monitoring on every path: counters on interfaces traversed by the flow monitoring on every path: counters on interfaces traversed by the flow
will report packet count, whereas counters on other interfaces wi ll be null.</t> will report packet count, whereas counters on other interfaces wi ll be null.</t>
</section>
</section> <section anchor="one-way_delay" numbered="true" toc="default">
<name>One-Way Delay Measurement</name>
<section anchor="one-way_delay" title="One-Way Delay Measurement"> <t>The same principle used to measure packet loss can be applied also to
<t>The same principle used to measure packet loss can be applied also
to
one-way delay measurement. There are two methodologies, as described her einafter.</t> one-way delay measurement. There are two methodologies, as described her einafter.</t>
<t>Note that, for all the one-way delay alternatives described in the ne
<t>Note that, for all the one-way delay alternatives described in xt sections,
the next sections,
by summing the one-way delays of the two directions of a path, it is always possible to measure by summing the one-way delays of the two directions of a path, it is always possible to measure
the two-way delay (round-trip "virtual" delay). The Network Time the two-way delay (round-trip "virtual" delay). The Network Time
Protocol (NTP) <xref target="RFC5905"></xref> Protocol (NTP) <xref target="RFC5905" format="default"/>
or the IEEE 1588 Precision Time Protocol (As discussed in the pre or the IEEE 1588 Precision Time Protocol (PTP) <xref target="IEEE
vious section, ) <xref target="IEEE-1588"/> can be used -1588" format="default"/> (as discussed in the previous section) can be used
for the timestamp formats depending on the needed precision.</t> for the timestamp formats depending on the needed precision.</t>
<section anchor="single-marking" numbered="true" toc="default">
<section anchor="single-marking" title="Single-Marking Methodolog <name>Single-Marking Methodology</name>
y"> <t>The alternation of colors can be used as a time reference to calcul
<t>The alternation of colors can be used as a time reference to calculat ate
e
the delay. Whenever the color changes (which means that a new block has the delay. Whenever the color changes (which means that a new block has
started), a network device can store the timestamp of the first p acket of started), a network device can store the timestamp of the first p acket of
the new block; that timestamp can be compared with the timestamp of the the new block; that timestamp can be compared with the timestamp of the
same packet on a second router to compute packet delay. same packet on a second router to compute packet delay.
When looking at <xref target="coloring"></xref>, R1 stores the ti mestamp TS(A1)R1 When looking at <xref target="coloring" format="default"/>, R1 st ores the timestamp TS(A1)R1
when it sends the first packet of block 1 (A-colored), the timest amp when it sends the first packet of block 1 (A-colored), the timest amp
TS(B2)R1 when it sends the first packet of block 2 (B-colored), a nd TS(B2)R1 when it sends the first packet of block 2 (B-colored), a nd
so on for every other block. so on for every other block.
R2 performs the same operation on the receiving side, recording T S(A1)R2, R2 performs the same operation on the receiving side, recording T S(A1)R2,
TS(B2)R2, and so on. Since the timestamps refer to specific packe ts (the first TS(B2)R2, and so on. Since the timestamps refer to specific packe ts (the first
packet of each block), in the case where no packet loss or misordering e xists, packet of each block), in the case where no packet loss or misordering e xists,
we would be sure that timestamps compared to compute delay refer to the same packets. we would be sure that timestamps compared to compute delay refer to the same packets.
By comparing TS(A1)R1 with TS(A1)R2 (and similarly TS(B2)R1 with TS(B2)R2, and so on), By comparing TS(A1)R1 with TS(A1)R2 (and similarly TS(B2)R1 with TS(B2)R2, and so on),
it is possible to measure the delay between R1 and R2. it is possible to measure the delay between R1 and R2.
In order to have more measurements, it is possible to take and st ore more timestamps, In order to have more measurements, it is possible to take and st ore more timestamps,
referring to other packets within each block. referring to other packets within each block.
The number of measurements could be increased by considering mult iple packets The number of measurements could be increased by considering mult iple packets
in the block: for instance, a timestamp could be taken every N pa ckets, thus in the block; for instance, a timestamp could be taken every N pa ckets, thus
generating multiple delay measurements. Taking this to the limit , in principle, generating multiple delay measurements. Taking this to the limit , in principle,
the delay could be measured for each packet by taking and compari ng the the delay could be measured for each packet by taking and compari ng the
corresponding timestamps (possible but impractical from an implem entation point of view).</t> corresponding timestamps (possible but impractical from an implem entation point of view).</t>
<t>In order to coherently compare timestamps collected on different
<t>In order to coherently compare timestamps collected on different routers, the clocks on the network nodes <bcp14>MUST</bcp14> be in sync
routers, the clocks on the network nodes MUST be in sync (<xref target=" (<xref target="sync-timing" format="default"/>).
sync-timing"/>).
Furthermore, a measurement is valid only if no packet loss occurs and if packet misordering Furthermore, a measurement is valid only if no packet loss occurs and if packet misordering
can be avoided; otherwise, the first packet of a block on R1 coul d be can be avoided; otherwise, the first packet of a block on R1 coul d be
different from the first packet of the same block on R2 (for instance, i f that different from the first packet of the same block on R2 (for instance, i f that
packet is lost between R1 and R2 or it arrives after the next packet is lost between R1 and R2 or it arrives after the next
one). Since packet misordering is generally undetectable it is not possi one). Since packet misordering is generally undetectable, it is not poss
ble ible
to check whether the first packet on R1 is the same on R2 and thi to check whether the first packet on R1 is the same on R2, and th
s is part of is is part of
the intrinsic error in this measurement.</t> the intrinsic error in this measurement.</t>
<section anchor="meand" numbered="true" toc="default">
<section anchor="meand" title="Mean Delay"> <name>Mean Delay</name>
<t>The method previously exposed for measuring the delay is sensitive <t>The method previously exposed for measuring the delay is sensitiv
e
to out-of-order reception of packets. In order to overcome this problem, to out-of-order reception of packets. In order to overcome this problem,
an approach based on the concept of mean delay can be considere d. The mean an approach based on the concept of mean delay can be considere d. The mean
delay is calculated by considering the average arrival time of the delay is calculated by considering the average arrival time of the
packets within a single block. The network device locally stores a packets within a single block. The network device locally stores a
timestamp for each packet received within a single block: summing timestamp for each packet received within a single block: summing
all the timestamps and dividing by the total number of packets all the timestamps and dividing by the total number of packets
received, the average arrival time for that block of packets can be received, the average arrival time for that block of packets can be
calculated. By subtracting the average arrival times of two adjacent calculated. By subtracting the average arrival times of two adjacent
devices, it is possible to calculate the mean delay between those devices, it is possible to calculate the mean delay between those
nodes. nodes.
This method greatly reduces the number of timestamps that have to be collected This method greatly reduces the number of timestamps that have to be collected
(only one per block for each network device) and it is robust t o out&nbhy;of&nbhy;order (only one per block for each network device), and it is robust to out-of-order
packets with only a small error introduced in case of packet lo ss. packets with only a small error introduced in case of packet lo ss.
But, when computing the mean delay, the measurement error could be augmented by accumulating But, when computing the mean delay, the measurement error could be augmented by accumulating
the measurement error of a lot of packets. Additionally, it onl y gives one measure the measurement error of a lot of packets. Additionally, it onl y gives one measure
for the duration of the block, and it doesn't give the minimum, maximum, and median for the duration of the block, and it doesn't give the minimum, maximum, and median
delay values <xref target="RFC6703"></xref>. delay values <xref target="RFC6703" format="default"/>.
This limitation could be overcome by reducing the duration of t he block This limitation could be overcome by reducing the duration of t he block
(for instance, from minutes to seconds), which implies a highly (for instance, from minutes to seconds), which implies a highly
optimized implementation of the method. For this reason, the me an delay calculation may optimized implementation of the method. For this reason, the me an delay calculation may
not be so viable in some cases.</t> not be so viable in some cases.</t>
</section>
</section> </section>
</section> <section anchor="double-marking" numbered="true" toc="default">
<name>Double-Marking Methodology</name>
<section anchor="double-marking" title="Double-Marking Methodolog
y">
<t>As mentioned above, the Single-Marking methodology for one-way dela y measurement <t>As mentioned above, the Single-Marking methodology for one-way dela y measurement
has some limitations, since it is sensitive to out-of-order rec eption of packets and has some limitations, since it is sensitive to out-of-order rec eption of packets, and
even the mean delay calculation is limited because it doesn't g ive information about even the mean delay calculation is limited because it doesn't g ive information about
the delay value's distribution for the duration of the block. A ctually, it may be useful the delay value's distribution for the duration of the block. A ctually, it may be useful
to have not only the mean delay but also the minimum, maximum, and median delay values to have not only the mean delay but also the minimum, maximum, and median delay values
and, in wider terms, to know more about the statistical distrib ution of delay values. and, in wider terms, to know more about the statistical distrib ution of delay values.
So, in order to have more information about the delay and to overcome So, in order to have more information about the delay and to overcome
out-of-order issues, a different approach can be introduced and it is based on out-of-order issues, a different approach can be introduced, an d it is based on
a Double-Marking methodology.</t> a Double-Marking methodology.</t>
<t>Basically, the idea is to use the first marking to create the alter nate <t>Basically, the idea is to use the first marking to create the alter nate
flow and, within this colored flow, a second marking to select the packets flow and, within this colored flow, a second marking to select the packets
for measuring delay/jitter. The first marking is needed for packet los s and for measuring delay/jitter. The first marking is needed for packet los s and
may be used for mean delay measurement. The second marking crea tes a new set of may be used for mean delay measurement. The second marking crea tes a new set of
marked packets that are fully identified over the network, so t hat a network device marked packets that are fully identified over the network so th at a network device
can store the timestamps of these packets. These timestamps can be compared can store the timestamps of these packets. These timestamps can be compared
with the timestamps of the same packets on the next node to com pute packet with the timestamps of the same packets on the next node to com pute packet
delay values for each packet. The number of measurements can be easily delay values for each packet. The number of measurements can be easily
increased by changing the frequency of the second marking. increased by changing the frequency of the second marking.
But the frequency of the second marking must not be too high in order to But the frequency of the second marking must not be too high i n order to
avoid out-of-order issues. Between packets with the second mark ing, there avoid out-of-order issues. Between packets with the second mark ing, there
should be an adequate time gap to avoid out-of-order issues and also to have should be an adequate time gap to avoid out-of-order issues and also to have
a number of measurement packets that are rate independent. This gap may be, a number of measurement packets that are rate independent. This gap may be,
at the minimum, the mean network delay calculated with the prev ious methodology. at the minimum, the mean network delay calculated with the prev ious methodology.
Therefore, it is possible to choose a proper time gap to guaran tee a fixed number Therefore, it is possible to choose a proper time gap to guaran tee a fixed number
of double-marked packets uniformly spaced in each block. of double-marked packets uniformly spaced in each block.
If packets with the second marking are lost, it is easy to reco gnize the loss If packets with the second marking are lost, it is easy to reco gnize the loss
since the number of double-marked packets is known for each blo ck. since the number of double-marked packets is known for each blo ck.
Based on the spacing between these packets, it can also be poss ible to understand Based on the spacing between these packets, it can also be poss ible to understand
which packet of the second marking sequence has been lost and p erform the measurements which packet of the second marking sequence has been lost and p erform the measurements
only for the remaining packets. But, this may be complicated if only for the remaining packets. But this may be complicated if
more packets more packets
are lost. In this case an implementation may simply discard the are lost. In this case, an implementation may simply discard th
delay measurements e delay measurements
for the corrupted block and proceed with the next block.</t> for the corrupted block and proceed with the next block.</t>
<t>An efficient and robust mode is to select a single packet with the
<t>An efficient and robust mode is to select a single packet wi second marking
th the second marking for each block; in this way, there is no time gap to consider b
for each block, in this way there is no time gap to consider be etween the double-marked packets
tween the double-marked packets
to avoid their reorder. In addition, it is also easier to ident ify the only double-marked packet to avoid their reorder. In addition, it is also easier to ident ify the only double-marked packet
in each block and skip the delay measurement for the block if i t is lost.</t> in each block and skip the delay measurement for the block if i t is lost.</t>
<t>The Double-Marking methodology can also be used to get more statist
<t>The Double-Marking methodology can also be used to get more ics
statistics
of delay extent data, e.g., percentiles, variance, and median d elay values. of delay extent data, e.g., percentiles, variance, and median d elay values.
Indeed, a subset of batch packets is selected for extensive del ay calculation by using the second marking Indeed, a subset of batch packets is selected for extensive del ay calculation by using the second marking,
and it is possible to perform a detailed analysis on these doub le-marked packets. and it is possible to perform a detailed analysis on these doub le-marked packets.
It is worth noting that there are classic algorithms for median and variance calculation, It is worth noting that there are classic algorithms for median and variance calculation,
but they are out of the scope of this document. but they are out of the scope of this document.
The conventional range (maximum-minimum) should be avoided for several reasons, The conventional range (maximum-minimum) should be avoided for several reasons,
including stability of the maximum delay due to the influence b y outliers. including stability of the maximum delay due to the influence b y outliers.
In this regard, <xref target="RFC5481">RFC 5481</xref>, Section 6.5 highlights how the 99.9th percentile In this regard, <xref target="RFC5481" format="default" section Format="of" section="6.5"/> highlights how the 99.9th percentile
of delay and delay variation is more helpful to performance pla nners.</t> of delay and delay variation is more helpful to performance pla nners.</t>
</section> </section>
</section>
</section> <section numbered="true" toc="default">
<name>Delay Variation Measurement</name>
<section title="Delay Variation Measurement">
<t>Similar to one-way delay measurement (both for Single Marking <t>Similar to one-way delay measurement (both for Single Marking
and Double Marking), the method can also be used to measure the and Double Marking), the method can also be used to measure the
inter-arrival jitter. We refer to the definition in <xref target= "RFC3393">RFC 3393</xref>. inter-arrival jitter. We refer to the definition in <xref target= "RFC3393" format="default"/>.
The alternation of colors, for a Single-Marking Method, can be us ed as a time reference The alternation of colors, for a Single-Marking Method, can be us ed as a time reference
to measure delay variations. In case of Double Marking, the time reference is given by to measure delay variations. In case of Double Marking, the time reference is given by
the second-marked packets. the second-marked packets.
Considering the example depicted in <xref target="coloring"></xre f>, R1 stores the timestamp Considering the example depicted in <xref target="coloring" forma t="default"/>, R1 stores the timestamp
TS(A)R1 whenever it sends the first packet of a block, and R2 sto res the timestamp TS(B)R2 TS(A)R1 whenever it sends the first packet of a block, and R2 sto res the timestamp TS(B)R2
whenever it receives the first packet of a block. The inter-arriv al jitter can be whenever it receives the first packet of a block. The inter-arriv al jitter can be
easily derived from one-way delay measurement, by evaluating the delay easily derived from one-way delay measurement, by evaluating the delay
variation of consecutive samples.</t> variation of consecutive samples.</t>
<t>The concept of mean delay can also be applied to delay variation, <t>The concept of mean delay can also be applied to delay variation,
by evaluating the average variation of the interval between conse cutive by evaluating the average variation of the interval between conse cutive
packets of the flow from R1 to R2.</t> packets of the flow from R1 to R2.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Alternate-Marking Functions"> <name>Alternate-Marking Functions</name>
<section title="Marking the Packets"> <section numbered="true" toc="default">
<name>Marking the Packets</name>
<t>The coloring operation is fundamental in order to create packet <t>The coloring operation is fundamental in order to create packet
blocks and marked packets. This implies choosing where to activate blocks and marked packets. This implies choosing where to activate
the coloring and how to color the packets.</t> the coloring and how to color the packets.</t>
<t>In case of flow-based measurements, the flow to monitor can be define d <t>In case of flow-based measurements, the flow to monitor can be define d
by a set of selection rules (e.g., header fields) used to match a subset of 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 the number of nodes involved, the packets; in this way, it is possible to control the number of nodes involved,
the path followed by the packets, and the size of the flows. It is possible, in general, the path followed by the packets, and 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 to have multiple 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 be do ne, and the doesn't raise any risk of conflict. Coloring in multiple nodes can be do ne, and the
requirement is that the coloring must change periodically between the nodes according requirement is that the coloring must change periodically between the nodes according
to the timing considerations in <xref target="sync-timing"/>; so every node that is to the timing considerations in <xref target="sync-timing" format ="default"/>; so every node that is
designated as a measurement point along the path should be able t o identify designated as a measurement point along the path should be able t o identify
unambiguously the colored packets. Furthermore, <xref target="I-D .ietf-ippm-rfc8889bis" format="default"/> unambiguously the colored packets. Furthermore, <xref target="RFC 9342" format="default"/>
generalizes the coloring for multipoint-to-multipoint flow. generalizes the coloring for multipoint-to-multipoint flow.
In addition, it can be advantageous to color the flow as close as possible to the source because In addition, it can be advantageous to color the flow as close as possible to the source because
it allows an end-to-end measure if a measurement point is enabled on the last-hop router as well.</t> it allows an end-to-end measure if a measurement point is enabled on the last-hop router as well.</t>
<t>For link-based measurements, all traffic needs to be colored when tra
<t>For link-based measurements, all traffic needs to be colored w nsmitted
hen transmitted
on the link. If the traffic had already been colored, then it has to be re-colored on the link. If the traffic had already been colored, then it has to be re-colored
because the color must be consistent on the link. This means that each because the color must be consistent on the link. This means that each
hop along the path must (re-)color the traffic; the color is not required hop along the path must (re-)color the traffic; the color is not required
to be consistent along different links.</t> to be consistent along different links.</t>
<t>Traffic coloring can be implemented by setting specific flags in <t>Traffic coloring can be implemented by setting specific flags in
the packet header and changing the value of that bit periodically. the packet header and changing the value of that bit periodically.
How to choose the marking field depends on the application and is How to choose the marking field depends on the application and is
out of scope here.</t> out of scope here.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Counting and Timestamping Packets"> <name>Counting and Timestamping Packets</name>
<t>For flow-based measurements, assuming that the coloring of the packet s is <t>For flow-based measurements, assuming that the coloring of the packet s is
performed only by the source nodes, the nodes between source and destination performed only by the source nodes, the nodes between source and destination
(inclusive) have to count and timestamp the colored packets that they receive and forward: (inclusive) have to count and timestamp the colored packets that they receive and forward:
this operation can be enabled on every router along the path or o nly on a this operation can be enabled on every router along the path or o nly on a
subset, depending on which network segment is being monitored (a single link, subset, depending on which network segment is being monitored (a single link,
a particular metro area, the backbone, or the whole path). Since the color switches a particular metro area, the backbone, or the whole path). Since the color switches
periodically between two values, two counters (one for each value ) are needed periodically between two values, two counters (one for each value ) are needed
for each flow and for every interface being monitored. The number of timestamps for each flow and for every interface being monitored. The number of timestamps
to be stored depends on the method for delay measurement that is applied. to be stored depends on the method for delay measurement that is applied.
Furthermore, <xref target="I-D.ietf-ippm-rfc8889bis" format="defa ult"/> Furthermore, <xref target="RFC9342" format="default"/>
generalizes the counting for multipoint-to-multipoint flow.</t> generalizes the counting for multipoint-to-multipoint flow.</t>
<t>In case of link-based measurements, the behavior is similar except <t>In case of link-based measurements, the behavior is similar except
that coloring, counting and timestamping operations are performed on a l ink-by-link that coloring, counting, and timestamping operations are performed on a link-by-link
basis at each endpoint of the link.</t> basis at each endpoint of the link.</t>
<t>Another important consideration is when to read the counters or when <t>Another important consideration is when to read the counters or when
to select the packets to be double-marked for delay measurement. to select the packets to be double-marked for delay measurement.
It involves timing aspects to consider that are further described in <xref target="sync-timing"/>.</t> It involves timing aspects to consider that are further described in <xref target="sync-timing" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Data Collection and Correlation"> <name>Data Collection and Correlation</name>
<t>The nodes enabled to perform performance monitoring collect the <t>The nodes enabled to perform performance monitoring collect the
value of the counters and timestamps, but they are not able to directly use value of the counters and timestamps, but they are not able to directly use
this information to measure packet loss and delay, because they o nly have their this information to measure packet loss and delay, because they o nly have their
own samples.</t> own samples.</t>
<t>Data collection enables the transmission of the counters and timestam ps <t>Data collection enables the transmission of the counters and timestam ps
as soon as it has been read. Data correlation is the mechanism to compare as soon as it has been read. Data correlation is the mechanism to compare
counters and timestamps for packet loss, delay, and delay variati on calculation.</t> counters and timestamps for packet loss, delay, and delay variati on calculation.</t>
<t>There are two main possibilities to perform both data collection and
<t>There are two main possibilities to perform both data collection a correlation
nd correlation depending on the Alternate-Marking application and use case:</t>
depending on the Alternate-Marking application and use case:<list style=" <ul spacing="normal">
symbols"> <li>Use of a centralized solution using the Network Management System
(NMS) to correlate data.
<t>Use of a centralized solution using Network Management System (NMS)
to correlate data.
This can be done in Push Mode or Polling Mode. In the first case, each router periodically This can be done in Push Mode or Polling Mode. In the first case, each router periodically
sends the information to the NMS; in the latter case, it is the NMS that periodically polls sends the information to the NMS; in the latter case, it is the NMS that periodically polls
routers to collect information.</t> routers to collect information.</li>
<li>Definition of a protocol-based distributed solution to exchange va
<t>Definition of a protocol-based distributed solution to exchange valu lues of counters and timestamps
es of counters and timestamps
between the endpoints. This can be done by introducing a new protoco l or by extending the existing protocols between the endpoints. This can be done by introducing a new protoco l or by extending the existing protocols
(e.g., the Two-Way Active Measurement Protocol (TWAMP) as defined in <x (e.g., the Two-Way Active Measurement Protocol (TWAMP) as defined in <x
ref target="RFC5357">RFC 5357</xref> ref target="RFC5357" format="default"/>
or the One-Way Active Measurement Protocol (OWAMP) as defined in <xref or the One-Way Active Measurement Protocol (OWAMP) as defined in <xref
target="RFC4656">RFC 4656</xref>) target="RFC4656" format="default"/>)
in order to communicate the counters and timestamps between nodes.</ in order to communicate the counters and timestamps between nodes.</
t> li>
</list></t> </ul>
<t>In the following paragraphs, an example data correlation mechanism is <t>In the following paragraphs, an example data correlation mechanism is
explained and could be used independently of the adopted solutions.</t> explained and could be used independently of the adopted solutions.</t>
<t>When data is collected on the upstream and downstream nodes, e.g., <t>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 no des delay measurement, and is periodically reported to or pulled by other no des
or an NMS, a certain data correlation mechanism SHOULD be in use to or an NMS, a certain data correlation mechanism <bcp14>SHOULD</bcp14> be in use to
help the nodes or NMS tell whether any two or more packet counts 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 timestamps are are related to the same block of markers or if any two timestamps are
related to the same marked packet.</t> related to the same marked packet.</t>
<t>The Alternate-Marking Method described in this document literally <t>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. An implementation MAY use a Block Number (BN) for data correlati blocks. An implementation <bcp14>MAY</bcp14> use a Block Number (BN) for
on. data correlation.
The BN MUST be assigned to each measurement block and associated The BN <bcp14>MUST</bcp14> be assigned to each measurement block
with each and associated with each
packet count and timestamp reported to or pulled by other nodes o r NMSs. packet count and timestamp reported to or pulled by other nodes o r NMSs.
When the nodes or NMS see, for example, the same BNs associated w ith When the nodes or NMS see, for example, the same BNs associated w ith
two packet counts from an upstream and a downstream node, respectively, it two packet counts from an upstream and a downstream node, respectively, it
considers that these two packet counts correspond to the same considers that these two packet counts correspond to the same
block. The assumption of this BN mechanism is that the measurement nodes block. The assumption of this BN mechanism is that the measurement nodes
are time synchronized. This requires the measurement nodes to hav e a certain time are time synchronized. This requires the measurement nodes to hav e a certain time
synchronization capability (e.g., the NTP <xref target="RFC5905"></xref> synchronization capability (e.g., the NTP <xref target="RFC5905" format=
or the IEEE 1588 PTP <xref target="IEEE-1588"/>).</t> "default"/>
or the IEEE 1588 PTP <xref target="IEEE-1588" format="default"/>)
.</t>
</section> </section>
</section> </section>
<section anchor="sync-timing" numbered="true" toc="default">
<section anchor="sync-timing" title="Synchronization and Timing"> <name>Synchronization and Timing</name>
<t>Color switching is the reference for all the network devices acting as
<t>Color switching is the reference for all the network devices acting as measurement points,
measurement points,
and the only requirement to be achieved is that they have to recognize th e right batch along the path and the only requirement to be achieved is that they have to recognize th e right batch along the path
in order to get the related information of counters and timestamps.</t> in order to get the related information of counters and timestamps.</t>
<t>In general, clocks in network devices are not accurate and for this rea
<t>In general, clocks in network devices are not accurate and for this re son,
ason,
there is a clock error between the measurement points R1 and R2. And, to implement the methodology, there is a clock error between the measurement points R1 and R2. And, to implement the methodology,
they must be synchronized to the same clock reference with an adequate ac curacy they must be synchronized to the same clock reference with an adequate ac curacy
in order to guarantee that all network devices consistently match the mar king bit to the correct block. in order to guarantee that all network devices consistently match the mar king bit to the correct block.
Additionally, in practice, besides clock errors, packet reordering is als o common Additionally, in practice, besides clock errors, packet reordering is als o common
in a packet network due to equal-cost multipath (ECMP). In particular, th e delay between in a packet network due to equal-cost multipath (ECMP). In particular, th e delay between
measurement points is the main cause of out of order because each packet measurement points is the main cause of out-of-order packets because each
can be delayed differently. packet can be delayed differently.
If the block is sufficiently large, packet reordering occurs only at the If the block is sufficiently large, packet reordering occurs only at the
edge of adjacent blocks and edge of adjacent blocks, and
it can be easy to assign reordered packets to the right interval blocks.< /t> it can be easy to assign reordered packets to the right interval blocks.< /t>
<t>In summary, we need to take into account two contributions: clock error
<t>In summary, we need to take into account two contributions: clock erro between network
r between network
devices and the interval we need to wait to avoid packets being out of or der because of network delay.</t> devices and the interval we need to wait to avoid packets being out of or der because of network delay.</t>
<t>The following figure explains both issues:</t>
<t>The following figure explains both issues.</t> <figure anchor="timing">
<name>Timing Aspects</name>
<figure anchor="timing" title="Timing Aspects"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
...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
]]></artwork> ]]></artwork>
</figure> </figure>
<t>where L is the time duration of each block.</t>
<t>Where L is the time duration of each block.</t> <t>It is assumed that all network devices are synchronized to a common ref
erence time
<t>It is assumed that all network devices are synchronized to a common re
ference time
with an accuracy of +/- A/2. Thus, the difference between the clock value s with an accuracy of +/- A/2. Thus, the difference between the clock value s
of any two network devices is bounded by A.</t> of any two network devices is bounded by A.</t>
<t>The network delay between the network devices can be represented as a normal distribution <t>The network delay between the network devices can be represented as a normal distribution
and 99.7% of the samples are within 3 standard deviation of the average.< and 99.7% of the samples are within 3 standard deviations of the average.
/t> </t>
<t>The guard band d is given by:</t>
<t>The guard band d is given by:</t> <artwork><![CDATA[
d = A + D_avg + 3*D_stddev,
<t>d = A + D_avg + 3*D_stddev,</t> ]]></artwork>
<t>where A is the clock accuracy, D_avg is the average value of the networ
<t>where A is the clock accuracy, D_avg is the average value of the netwo k delay between
rk delay between the network devices, and D_stddev is the standard deviation of the delay.<
the network devices, and D_stddev is the standard deviation of the delay. /t>
</t> <t>The available counting interval is L - 2d, which must be &gt; 0.</t>
<t>The condition that <bcp14>MUST</bcp14> be satisfied and is a requiremen
<t>The available counting interval is L - 2d that must be &gt; 0.</t> t on the synchronization accuracy is:</t>
<artwork><![CDATA[
<t>The condition that MUST be satisfied and is a requirement on the synch d < L/2.
ronization accuracy is:</t> ]]></artwork>
<t>This is the fundamental rule for deciding when to read the counters and
<t>d &lt; L/2.</t> when to select the packets
to be double-marked; indeed, packet counters and double-marked packets <b
<t>This is the fundamental rule for deciding when to read the counters an cp14>MUST</bcp14> respectively be
d when to select the packets
to be double-marked, indeed packet counter and double-marked packets MUST
respectively be
taken and chosen within the available counting interval that is not affec ted by error factors.</t> taken and chosen within the available counting interval that is not affec ted by error factors.</t>
<t>If the time duration L of each block is not so small, the synchronizati
<t>If the time duration L of each block is not so small, the synchronizat on requirement could be satisfied
ion requirement could be satisfied
even with a relatively inaccurate synchronization method.</t> even with a relatively inaccurate synchronization method.</t>
</section>
</section> <section anchor="fragmentation" numbered="true" toc="default">
<name>Packet Fragmentation</name>
<section anchor="fragmentation" title="Packet Fragmentation"> <t>Fragmentation can be managed with the Alternate-Marking Method using th
e following guidance:</t>
<t>Fragmentation can be managed with the Alternate-Marking Method using t <ul empty="true" spacing="normal">
he following guidance:<list> <li>Marking nodes <bcp14>MUST</bcp14> mark all fragments if there are fl
ag bits to use
<t>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
(i.e. it is in the specific encapsulation), as if they were separate p packets.</li>
ackets.</t> <li>Nodes that fragment packets within the measurement domain <bcp14>SHO
ULD</bcp14>, if they have the capability to do so,
<t>Nodes that fragment packets within the measurement domain SHOULD, i
f they have the capability to do so,
ensure that only one resulting fragment carries the marking bit(s) of the original packet. ensure that only one resulting fragment carries the marking bit(s) of the original packet.
Failure to do so can introduce errors into the measurement.</t> Failure to do so can introduce errors into the measurement.</li>
<li>Measurement points <bcp14>SHOULD</bcp14> simply ignore unmarked frag
<t>Measurement points SHOULD simply ignore unmarked fragments and coun ments and count
t
marked fragments as full packets. However, if resources allow, measure ment marked fragments as full packets. However, if resources allow, measure ment
points MAY make note of both marked and unmarked initial fragments and points <bcp14>MAY</bcp14> make note of both marked and unmarked initia
only increment the corresponding counter if (a) other fragments are al l fragments and
so marked, only increment the corresponding counter if (a) other fragments are al
or (b) it observes all other fragments and they are unmarked.</t> so marked
or (b) it observes all other fragments and they are unmarked.</li>
</list></t> </ul>
<t>The proposed approach allows the marking node to mark all the fragments
<t>The proposed approach allows the marking node to mark all the fragment except in the case
s except in the case of fragmentation within the network domain; in that event, it is suggeste
of fragmentation within the network domain, in that event it is suggested d to mark only the first fragment.</t>
to mark only the first fragment.</t> </section>
<section anchor="finding" numbered="true" toc="default">
</section> <name>Recommendations for Deployment</name>
<t>The methodology described in the previous sections can be applied to
<section anchor="finding" title="Recommendations for Deployment">
<t>The methodology described in the previous sections can be applied to
various performance measurement problems. various performance measurement problems.
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 alter nately in this way, packets are batched by the sender, and each batch is alter nately
marked such that it can be easily recognized by the receiver. marked such that it can be easily recognized by the receiver.
<xref target="RFC8321"></xref> reports experimental examples and <xref target="RFC8321" format="default"/> reports experimental examples
<xref target="IEEE-Network-PNPM"/> also includes some information about , and
<xref target="IEEE-NETWORK-PNPM" format="default"/> also includes some
information about
the deployment experience.</t> the deployment experience.</t>
<t>Either one or two flag bits might be available for marking in different
deployments:</t>
<t>Either one or two flag bits might be available for marking in differ <dl>
ent <dt>One flag:
deployments:<list> </dt>
<t>One flag: packet loss measurement MUST be done as described in <xre
f target="ploss"></xref>,
while delay measurement MUST be done according to the single-marking m
ethod described in <xref target="single-marking"></xref>.
Mean delay (<xref target="meand"></xref>) MAY also be used but it coul
d imply more computational load.</t>
<t>Two flags: packet loss measurement MUST be done as described in <xr
ef target="ploss"></xref>,
while delay measurement MUST be done according to double-marking metho
d <xref target="double-marking"></xref>.
In this case single-marking MAY also be used in combination with doubl
e-marking and the two approaches provide
slightly different pieces of information that can be combined to have
a more robust data set.</t>
</list></t>
<t>There are some operational guidelines to consider for the purpose of <dd>packet-loss measurement <bcp14>MUST</bcp14> be done as described
deciding to follow the recommendations above in <xref target="ploss" format="default"/>, while delay measurement
and use one or two flags.<list> <bcp14>MUST</bcp14> be done according to the Single-Marking Method
described in <xref target="single-marking" format="default"/>. Mean
delay (<xref target="meand" format="default"/>) <bcp14>MAY</bcp14>
also be used but it could imply more computational load.
</dd>
<t>The Alternate-Marking method utilizes specific flags in the packet <dt>Two flags:
header, so an important factor is the number of flags available </dt>
for the implementation. Indeed, if there is only one flag available th
ere is no other way, while if two flags are available
the option with two flags is certainly more complete.</t>
<t>The duration of the Alternate-Marking period affects the frequency <dd>packet-loss measurement <bcp14>MUST</bcp14> be done as described
of the measurement and this is a parameter that can be in <xref target="ploss" format="default"/>, while delay measurement
decided on the basis of the required temporal sampling. But it cannot <bcp14>MUST</bcp14> be done according to the Double-Marking Method as des
be freely chosen, as explained in <xref target="sync-timing"/>.</t> cribed in <xref
target="double-marking" format="default"/>. In this case,
Single Marking <bcp14>MAY</bcp14> also be used in combination with
Double Marking, and the two approaches provide slightly different
pieces of information that can be combined to have a more robust data
set.
</dd>
</dl>
<t>The Alternate-Marking methodologies enable packet loss, delay and d <t>There are some operational guidelines to consider for the purpose of de
elay variation calculation, but in accordance with ciding to follow the recommendations above
the method used (e.g. single-marking or double-marking), there is diff and to use one or two flags.</t>
erent kind of information that can be derived. <ul empty="false" spacing="normal">
<li>The Alternate-Marking Method utilizes specific flags in the packet h
eader, so an important factor is the number of flags available
for the implementation. Indeed, if there is only one flag available, t
hen there is no other way; if two flags are available,
then the option with two flags is certainly more complete.</li>
<li>The duration of the Alternate-Marking period affects the frequency o
f the measurement, and this is a parameter that can be
decided on the basis of the required temporal sampling. But it cannot
be freely chosen, as explained in <xref target="sync-timing" format="default"/>.
</li>
<li>The Alternate-Marking methodologies enable packet loss, delay, and d
elay variation calculation, but in accordance with
the method used (e.g., Single Marking or Double Marking), there is a d
ifferent kind of information that can be derived.
For example, to get more statistics of extent data, the option with tw o flags is desirable. For this reason, the type of data For example, to get more statistics of extent data, the option with tw o flags is desirable. For this reason, the type of data
needed in the specific scenario is an additional element to take into needed in the specific scenario is an additional element to take into
account.</t> account.</li>
<li>The Alternate-Marking Methods imply different computational load dep
<t>The Alternate-Marking methods imply different computational load de ending on the method employed. Therefore, the available
pending on the method employed. Therefore, the available
computational resources on the measurement points can also influence t he choice. As an example, mean delay calculation may computational resources on the measurement points can also influence t he choice. As an example, mean delay calculation may
require more processing and it may not be the best option to minimize require more processing, and it may not be the best option to minimize
the computational load.</t> the computational load.</li>
</ul>
</list></t> <t>The experiment with Alternate-Marking methodologies confirmed the benef
its already described in <xref target="RFC8321" format="default"/>.</t>
<t>The experiment with Alternate-Marking methodologies confirmed the be <t>A deployment of the Alternate-Marking Method should also take into acco
nefits already described in <xref target="RFC8321"></xref>.</t> unt how to handle and recognize
marked and unmarked traffic. Since Alternate Marking normally employs a
<t>A deployment of the Alternate-Marking Method should also take into a marking field that is dedicated, reserved, and
ccount how to handle and recognize
marked and unmarked traffic. Since Alternate-Marking normally employs a
marking field which is dedicated, reserved, and
included in a protocol extension, the measurement points can learn whet her the measurement is activated or not by checking included in a protocol extension, the measurement points can learn whet her the measurement is activated or not by checking
if the specific extension is included or not within the packets.</t> if the specific extension is included or not within the packets.</t>
<t>It is worth mentioning some related work; in particular, <xref target="
<t>It is worth mentioning some related work: in particular <xref target IEEE-NETWORK-PNPM" format="default"/>
="IEEE-Network-PNPM"/> explains the Alternate-Marking Method together with new mechanisms base
explains the Alternate-Marking method together with new mechanisms base d on hashing techniques.</t>
d on hashing techniques.</t> <section numbered="true" toc="default">
<name>Controlled Domain Requirement</name>
<section title="Controlled Domain requirement"> <t>The Alternate-Marking Method is an example of a solution limited to a
controlled domain
<t>The Alternate-Marking Method is an example of a solution limit <xref target="RFC8799" format="default"/>.</t>
ed to a controlled domain <t>A controlled domain is a managed network that selects, monitors, and
<xref target="RFC8799"></xref>.</t> controls access by enforcing
policies at the domain boundaries in order to discard undesired e
<t>A controlled domain is a managed network that selects, monitor xternal packets
s, and controls access by enforcing entering the domain and to check internal packets leaving the dom
policies at the domain boundaries, in order to discard undesired ain. It does not necessarily mean that
external packets
entering the domain and check internal packets leaving the domain
. It does not necessarily mean that
a controlled domain is a single administrative domain or a single organization. A controlled domain a controlled domain is a single administrative domain or a single organization. A controlled domain
can correspond to a single administrative domain or multiple admi nistrative domains under a defined can correspond to a single administrative domain or multiple admi nistrative domains under a defined
network management. It must be possible to control the domain bou network management. It must be possible to control the domain bou
ndaries, and use specific precautions ndaries and use specific precautions
to ensure authentication, encryption and integrity protection if to ensure authentication, encryption, and integrity protection if
traffic traverses the Internet.</t> traffic traverses the Internet.</t>
<t>For security reasons, the Alternate-Marking Method <bcp14>MUST</bcp14
<t>For security reasons, the Alternate-Marking Method MUST only b > only be applied to controlled domains.</t>
e applied to controlled domains.</t> </section>
</section> </section>
<section numbered="true" toc="default">
</section> <name>Compliance with Guidelines from RFC 6390</name>
<section title="Compliance with Guidelines from RFC 6390"> <t><xref target="RFC6390" format="default"/>
<t>RFC 6390 <xref target="RFC6390"></xref>
defines a framework and a process for developing Performance Metr ics defines a framework and a process for developing Performance Metr ics
for protocols above and below the IP layer (such as IP-based appl ications for protocols above and below the IP layer (such as IP-based appl ications
that operate over reliable or datagram transport protocols).</t> that operate over reliable or datagram transport protocols).</t>
<t>This document doesn't aim to propose a new Performance Metric but rathe
<t>This document doesn't aim to propose a new Performance Metric but rat r a
her a
new Method of Measurement for a few Performance Metrics that have new Method of Measurement for a few Performance Metrics that have
already been standardized. Nevertheless, it's worth applying already been standardized. Nevertheless, it's worth applying
guidelines from <xref target="RFC6390"></xref> to the present documen t, guidelines from <xref target="RFC6390" format="default"/> to the pres ent document,
in order to provide a more complete and coherent description of t he in order to provide a more complete and coherent description of t he
proposed method. proposed method.
The mechanisms described in this document use a combination of the The mechanisms described in this document use a combination of the
Performance Metric Definition template defined in Section 5.4 of Performance Metric Definition template defined in <xref target="R
<xref target="RFC6390"></xref> FC6390" sectionFormat="of" section="5.4" format="default"/>
and the Dependencies laid out in Section 5.5 of that document. and the Dependencies laid out in Section <xref target="RFC6390"
<list style="symbols"> section="5.5" sectionFormat="bare"/> of that document.
</t>
<t>Metric Name / Metric Description: as already stated, this <ul spacing="normal">
document <li>Metric Name / Metric Description: as already stated, this document
doesn't propose any new Performance Metrics. On the contrary, it doesn't propose any new Performance Metrics. On the contrary, it
describes a novel method for measuring packet loss describes a novel method for measuring packet loss
<xref target="RFC7680"></xref>. The same concept, with sm all <xref target="RFC7680" format="default"/>. The same conce pt, with small
differences, can also be used to measure delay differences, can also be used to measure delay
<xref target="RFC7679"></xref> and jitter <xref target="RFC7679" format="default"/> and jitter
<xref target="RFC3393"></xref>. <xref target="RFC3393" format="default"/>.
The document mainly describes the applicability to packet The document mainly describes the applicability to packet
loss -loss
measurement.</t> measurement.</li>
<li>Method of Measurement or Calculation: according to the method
<t>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 ma rking method The steady state is an intrinsic characteristic of the ma rking method
counters because the alternation of color makes the count er associated counters because the alternation of color makes the count er associated
with a color inactive for the duration of a marking perio with a color inactive for the duration of a marking perio
d.</t> d.</li>
<li>Units of Measurement: the method calculates and reports the exact
<t>Units of Measurement: the method calculates and report
s 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.</t> destination node.</li>
<li>Measurement Point(s) with Potential Measurement Domain: the measurem
<t>Measurement Point(s) with Potential Measurement Domain ent can be performed between
: the measurement can be performed between
adjacent nodes, on a per-link basis, or along a multi-hop path, adjacent nodes, on a per-link basis, or along a multi-hop path,
provided that the traffic under measurement follows that path. In provided that the traffic under measurement follows that path. In
case of a multi-hop path, the measurements can be performed both case of a multi-hop path, the measurements can be performed both
end-to-end and hop-by-hop.</t> end to end and hop by hop.</li>
<li>Measurement Timing: the method has a constraint on the frequency
<t>Measurement Timing: the method has a constraint on the of measurements. This is detailed in <xref target="sync-timing" form
frequency at="default"/>, where it is specified that
of measurements. This is detailed in <xref target="sync-timing"/>, w
here it is specified that
the marking period and the guard band interval are strict ly related to each other the marking period and the guard band interval are strict ly related to each other
to avoid out-of-order issues. That is because, in order t o perform a measurement, to avoid out-of-order issues. That is because, in order t o perform a measurement,
the counter must be in a steady state, and this happens w hen the traffic is being the counter must be in a steady state, and this happens w hen the traffic is being
colored with the alternate color.</t> colored with the alternate color.</li>
<li>Implementation: the method uses one or two marking bits to color the
<t>Implementation: the method uses one or two marking bit packets;
s to color the packets;
this enables the use of policy configurations on the rout er to color the packets this enables the use of policy configurations on the rout er to color the packets
and accordingly configure the counter for each color. The path and accordingly configure the counter for each color. The path
followed by traffic being measured should be known in advance in followed by traffic being measured should be known in advance in
order to configure the counters along the path and be able to order to configure the counters along the path and be able to
compare the correct values.</t> compare the correct values.</li>
<li>Verification: the methodology has been tested and deployed experimen
<t>Verification: the methodology has been tested and depl tally
oyed experimentally
in both lab and operational network scenarios performing packet loss and delay measurements in both lab and operational network scenarios performing packet loss and delay measurements
on traffic patterns created by traffic generators togethe r with precision test instruments on traffic patterns created by traffic generators togethe r with precision test instruments
and network emulators.</t> and network emulators.</li>
<li>Use and Applications: the method can be used to measure packet
<t>Use and Applications: the method can be used to measur
e packet
loss with high precision on live traffic; moreover, by combining loss with high precision on live traffic; moreover, by combining
end-to-end and per-link measurements, the method is usefu l to pinpoint end-to-end and per-link measurements, the method is usefu l to pinpoint
the single link that is experiencing loss events.</t> the single link that is experiencing loss events.</li>
<li>Reporting Model: the value of the counters has to be sent to a
<t>Reporting Model: the value of the counters has to be s
ent to a
centralized management system that performs the calculations; such centralized management system that performs the calculations; such
samples must contain a reference to the time interval they refer samples must contain a reference to the time interval they refer
to, so that the management system can perform the correct to so that the management system can perform the correct
correlation; the samples have to be sent while the corresponding correlation. The samples have to be sent while the corresponding
counter is in a steady state (within a time interval); otherwise, counter is in a steady state (within a time interval); otherwise,
the value of the sample should be stored locally.</t> the value of the sample should be stored locally.</li>
<li>Dependencies: the values of the counters have to be correlated to
<t>Dependencies: the values of the counters have to be co the time interval they refer to.</li>
rrelated to <li>Organization of Results: the Method of Measurement produces
the time interval they refer to.</t> singletons, according to the definition of <xref target="RFC2330" fo
rmat="default"/>.</li>
<t>Organization of Results: the Method of Measurement pro <li>Parameters: the main parameters of the method are the information ab
duces out
singletons, according to the definition of <xref target="RFC2330"></
xref>.</t>
<t>Parameters: the main parameters of the method are the
information about
the flow or the link to be measured, the time interval ch osen to alternate the the flow or the link to be measured, the time interval ch osen to alternate the
colors and to read the counters and the type of method se colors and to read the counters, and the type of method s
lected for packet loss elected for packet-loss
and delay measurements.</t> and delay measurements.</li>
</list></t> </ul>
</section>
</section> <section numbered="true" toc="default">
<name>IANA Considerations</name>
<section title="IANA Considerations">
<t>This document has no IANA actions.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="seccons" numbered="true" toc="default">
<section anchor="seccons" title="Security Considerations"> <name>Security Considerations</name>
<t>This document specifies a method to perform measurements that does not <t>This document specifies a method to perform measurements that does not
directly affect Internet security nor applications that run on the Inte rnet. directly affect Internet security nor applications that run on the Inte rnet.
However, implementation of this method must be mindful of security and privacy However, implementation of this method must be mindful of security and privacy
concerns.</t> concerns.</t>
<t>There are two types of security concerns: potential harm caused by <t>There are two types of security concerns: potential harm caused by
the measurements and potential harm to the measurements. the measurements and potential harm to the measurements.
<list style="symbols"> </t>
<ul spacing="normal">
<t>Harm caused by the measurement: the measurements described in this d <li>Harm caused by the measurement: the measurements described in this d
ocument ocument
are Passive, so there are no new packets injected into the network causing are Passive, so there are no new packets injected into the network causing
potential harm to the network itself and to data traffic. Nevertheless, potential harm to the network itself and to data traffic. Nevertheless,
the method implies modifications on the fly to a header or encapsulation the method implies modifications on the fly to a header or encapsulation
of the data packets: this must be performed in a way that doesn't alter the quality of the data packets: this must be performed in a way that doesn't alter the quality
of service experienced by packets subject to measurements and that of service experienced by packets subject to measurements and that
preserves stability and performance of routers doing the measurements. preserves stability and performance of routers doing the measurements.
One of the main security threats in OAM protocols is network reconnaiss ance; One of the main security threats in Operations, Administration, and Mai ntenance (OAM) protocols is network reconnaissance;
an attacker can gather information about the network performance by pas sively an attacker can gather information about the network performance by pas sively
eavesdropping on OAM messages. The advantage of the methods described i n eavesdropping on OAM messages. The advantage of the methods described i n
this document is that the marking bits are the only information that is exchanged this document is that the marking bits are the only information that is exchanged
between the network devices. Therefore, Passive eavesdropping on data-p between the network devices. Therefore, Passive eavesdropping on data p
lane traffic lane traffic
does not allow attackers to gain information about the network performa does not allow attackers to gain information about the network performa
nce.</t> nce.</li>
<li>Harm to the Measurement: the measurements could be harmed by routers
<t>Harm to the Measurement: the measurements could be harmed by routers altering
altering
the marking of the packets or by an attacker injecting artificial the marking of the packets or by an attacker injecting artificial
traffic. Authentication techniques, such as digital signatures, may be traffic. Authentication techniques, such as digital signatures, may be
used where appropriate to guard against injected traffic attacks. used where appropriate to guard against injected traffic attacks.
Since the measurement itself may be affected by routers (or other Since the measurement itself may be affected by routers (or other
network devices) along the path of IP packets intentionally altering the network devices) along the path of IP packets intentionally altering the
value of marking bits of packets, as mentioned above, the mechanism specif ied value of marking bits of packets, as mentioned above, the mechanism specif ied
in this document can be applied just in the context of a controlled dom ain; in this document can be applied just in the context of a controlled dom ain;
thus, the routers (or other network devices) are locally administered thus, the routers (or other network devices) are locally administered,
and this type of attack can be avoided.</t> and this type of attack can be avoided.</li>
</ul>
</list></t>
<t>An attacker that does not belong to the controlled domain can malicious ly send marked packets. <t>An attacker that does not belong to the controlled domain can malicious ly send marked packets.
But if Alternate-Marking is not supported in the controlled domain, no However, no problems occur if Alternate Marking is not supported in the
problem happens. controlled domain.
While if Alternate-Marking is supported in the controlled domain, it is If Alternate Marking is supported in the controlled domain, it is necessary to k
also necessary to avoid that eep the
the measurements are affected and external marked packets must be check measurements from being affected; therefore, externally marked packets
ed.</t> must be checked to see if they are marked and eventually filtered or cleared.
</t>
<t>The precondition for the application of the Alternate-Marking is that i <t>The precondition for the application of the Alternate-Marking Method is
t MUST be applied in specific that it <bcp14>MUST</bcp14> be applied in specific
controlled domains, thus confining the potential attack vectors within the network domain. controlled domains, thus confining the potential attack vectors within the network domain.
A limited administrative domain provides the network administrator with A limited administrative domain provides the network administrator with
the means to select, monitor and the means to select, monitor, and
control the access to the network, making it a trusted domain. In this control the access to the network, making it a trusted domain. In this
regard it is expected to enforce policies regard, it is expected to enforce policies
at the domain boundaries to filter both external marked packets entering t he domain and internal marked packets at the domain boundaries to filter both external marked packets entering t he domain and internal marked packets
leaving the domain. Therefore, the trusted domain is unlikely subject t o hijacking of packets since marked packets leaving the domain. Therefore, the trusted domain is unlikely subject t o the hijacking of packets since marked packets
are processed and used only within the controlled domain. But despite t hat, leakages may happen for are processed and used only within the controlled domain. But despite t hat, leakages may happen for
different reasons, such as a failure or a fault. In this case, nodes ou tside the domain are expected to different reasons, such as a failure or a fault. In this case, nodes ou tside the domain are expected to
ignore marked packets since they are not configured to handle it and sh ould not process it.</t> ignore marked packets since they are not configured to handle it and sh ould not process it.</t>
<t>It might be theoretically possible to modulate the marking to serve as a covert channel to be used by an <t>It might be theoretically possible to modulate the marking to serve as a covert channel to be used by an
on-path observer. This may affect both the data and management plane, b ut, here too, the application to a on-path observer. This may affect both the data and management plane, b ut, here too, the application to a
controlled domain helps to reduce the effects.</t> controlled domain helps to reduce the effects.</t>
<t>It is worth highlighting that an attacker can't gain information about
<t>It is worth highlighting that an attacker can't gain information abo network performance
ut network performance from a single monitoring point; they must use synchronized monitoring p
from a single monitoring point; it must use synchronized monitoring poi oints at multiple points on the path
nts at multiple points on the path,
because they have to do the same kind of measurement and aggregation th at Service Providers using because they have to do the same kind of measurement and aggregation th at Service Providers using
Alternate-Marking must do.</t> Alternate Marking must do.</t>
<t>Attacks on the data collection and reporting of the statistics between
<t>Attacks on the data collection and reporting of the statistics betwe the monitoring points and the NMS can interfere with the proper
en
the monitoring points and the network management system can interfere w
ith the proper
functioning of the system. Hence, the channels used to report back flow st atistics functioning of the system. Hence, the channels used to report back flow st atistics
MUST be secured.</t> <bcp14>MUST</bcp14> be secured.</t>
<t>The privacy concerns of network measurement are limited because the <t>The privacy concerns of network measurement are limited because the
method only relies on information contained in the header or encapsulation without method only relies on information contained in the header or encapsulation without
any release of user data. Although information in the header or encapsu lation is metadata that any release of user data. Although information in the header or encapsu lation is metadata that
can be used to compromise the privacy of users, the limited marking tec hnique in this document can be used to compromise the privacy of users, the limited marking tec hnique in this document
seems unlikely to substantially increase the existing privacy risks fro m header seems unlikely to substantially increase the existing privacy risks fro m header
or encapsulation metadata. It might be theoretically possible to modula te the marking to serve or encapsulation metadata. It might be theoretically possible to modula te the marking to serve
as a covert channel, but it would have a very low data rate if it is to avoid adversely affecting as a covert channel, but it would have a very low data rate if it is to avoid adversely affecting
the measurement systems that monitor the marking.</t> the measurement systems that monitor the marking.</t>
<t>Delay attacks are another potential threat in the context of this docum ent. <t>Delay attacks are another potential threat in the context of this docum ent.
Delay measurement is performed using a specific packet in each block, m arked by Delay measurement is performed using a specific packet in each block, m arked by
a dedicated color bit. Therefore, an on-path attacker can selectively a dedicated color bit. Therefore, an on-path attacker can selectively
induce synthetic delay only to delay-colored packets, causing systemati c error in induce synthetic delay only to delay-colored packets, causing systemati c error in
the delay measurements. As discussed in previous sections, the methods described the delay measurements. As discussed in previous sections, the methods described
in this document rely on an underlying time synchronization protocol. T hus, by in this document rely on an underlying time synchronization protocol. T hus, by
attacking the time protocol, an attacker can potentially compromise the integrity attacking the time protocol, an attacker can potentially compromise the integrity
of the measurement. A detailed discussion about the threats against tim e protocols of the measurement. A detailed discussion about the threats against tim e protocols
and how to mitigate them is presented in <xref target="RFC7384">RFC 738 and how to mitigate them is presented in <xref target="RFC7384" format=
4</xref>.</t> "default"/>.</t>
</section>
<section anchor="Contributors" title="Contributors">
<t>Xiao Min<vspace blankLines="0" /> ZTE Corp.<vspace
blankLines="0" /> Email: xiao.min2@zte.com.cn</t>
<t>Mach(Guoyi) Chen<vspace blankLines="0" /> Huawei Technologies<vspace
blankLines="0" /> Email: mach.chen@huawei.com</t>
<t>Alessandro Capello<vspace blankLines="0" /> Telecom Italia<vspace
blankLines="0" /> Email: alessandro.capello@telecomitalia.it</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Alberto Tempia Bonda, Luca Castaldelli
and Lianshu Zheng for their contribution to the experimentation of the
method.</t>
<t>The authors would also thank Martin Duke and Tommy Pauly
for their assistance and their detailed and precious reviews.</t>
</section> </section>
<!-- Possibly a 'Contributors' section ... -->
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split to informative and normative -->
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.8174'?> <displayreference target="I-D.ietf-ippm-explicit-flow-measurements" to="EXPLICIT
-FLOW-MEASUREMENTS"/>
<?rfc include='reference.RFC.3393'?>
<?rfc include='reference.RFC.7679'?>
<?rfc include='reference.RFC.7680'?> <references>
<name>References</name>
<references>
<name>Normative References</name>
</references> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3393.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7679.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7680.xml"
/>
<references title="Informative References"> </references>
<!-- A reference written by by an organization not a persoN. --> <references>
<name>Informative References</name>
<?rfc include='reference.RFC.5905'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8321.xml"
/>
<reference anchor="IEEE-1588"> <reference anchor="IEEE-1588">
<front> <front>
<title>IEEE Standard for a Precision Clock Synchronization Protocol for <title>IEEE Standard for a Precision Clock Synchronization Protocol
for
Networked Measurement and Control Systems</title> Networked Measurement and Control Systems</title>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date /> <date month="July" year="2008"/>
</front> </front>
<seriesInfo name="IEEE" value="Std 1588-2008"/> <seriesInfo name="IEEE" value="Std 1588-2008"/>
</reference> <seriesInfo name="DOI" value="10.1109/IEEESTD.2008.4579760"/>
</reference>
<?rfc include='reference.RFC.8321'?>
<?rfc include='reference.I-D.ietf-ippm-rfc8889bis'?>
<?rfc include='reference.I-D.ietf-ippm-explicit-flow-measurements'?>
<?rfc include='reference.RFC.7384'?>
<?rfc include='reference.RFC.8799'?>
<?rfc include='reference.RFC.5357'?>
<?rfc include='reference.RFC.4656'?>
<?rfc include='reference.RFC.5481'?>
<?rfc include='reference.RFC.7799'?>
<?rfc include='reference.RFC.6703'?>
<?rfc include='reference.RFC.6390'?>
<?rfc include='reference.RFC.2330'?>
<reference anchor='IEEE-Network-PNPM'>
<front>
<title>AM-PM: Efficient Network Telemetry using Alternate Marking</title>
<author>
<organization>IEEE Network</organization>
</author>
<date year='2019' />
</front>
<seriesInfo name='DOI' value='10.1109/MNET.2019.1800152'/>
</reference>
</references>
<section title="Changes Log">
<t>Changes from RFC 8321 in draft-fioccola-rfc8321bis-00 include:<list style
="symbols">
<t>Minor editorial changes</t>
<t>Replacement of the section on "Applications, Implementation, and Deploy
ment"
with "Finding of the Alternate Marking Implementations and Deployments"
</t>
<t>Moved advantages and benefits of the method from "Introduction" to t
he
new section on "Finding of the Alternate Marking Implementations and De
ployments"</t>
<t>Removed section on "Hybrid Measurement"</t>
</list></t>
<t>Changes in draft-fioccola-rfc8321bis-01 include:<list style="symbols">
<t>Considerations on the reference: [IEEE-Network-PNPM]</t>
<t>Clarified that the method based on a fixed timer is specified in thi
s document while
the method based on a fixed number of packets is only mentioned but not
detailed.</t>
<t>Explanation of the intrinsic error in section 3.3.1 on "Single-Marki
ng Methodology"</t>
<t>Deleted some parts in section 4 "Considerations" that no longer appl
y</t>
<t>New section on "Packet Fragmentation"</t>
</list></t>
<t>Changes in draft-fioccola-rfc8321bis-02 include:<list style="symbols">
<t>Considerations on how to handle unmarked traffic in section 5 on "Re
sults of the Alternate Marking Experiment"</t>
<t>Minor rewording in section 4.4 on "Packet Fragmentation"</t>
</list></t>
<t>Changes in draft-fioccola-rfc8321bis-03 include:<list style="symbols">
<t>Deleted numeric examples in sections on "Packet Loss Measurement" an
d on "Single-Marking Methodology"</t>
<t>New section on "Alternate Marking Functions"</t>
<t>Moved sections 3.1.1 on "Coloring the Packets", 3.1.2 on "Counting t
he Packets" and
3.1.3 on "Collecting Data and Calculating Packet Loss" into the new sec
tion on "Alternate Marking Functions"</t>
<t>Renamed sections 4.1 as "Marking the Packets", 4.2 as "Counting and
Timestamping Packets" and
4.3 as "Data Collection and Correlation"</t>
<t>Merged old section on "Data Correlation" with section 4.3 on "Data C
ollection and Correlation"</t>
<t>Moved and renamed section on "Timing Aspects" as "Synchronization an
d Timing"</t>
<t>Merged old section on "Synchronization" with section on "Synchroniza
tion and Timing"</t>
<t>Merged old section on "Packet Reordering" with section on "Synchroni
zation and Timing"</t>
</list></t>
<t>Changes in draft-fioccola-rfc8321bis-04/draft-ietf-ippm-rfc8321bis-00
include:<list style="symbols">
<t>Revised "Introduction" section</t>
<t>Revised sections 4.2 "Counting and Timestamping Packets" and 4.3 on <!-- [I-D.ietf-ippm-rfc8889bis] in EDIT state as of 11/23/22; companion documen
"Data Collection and Correlation"</t> t RFC YYY1 -->
<reference anchor='RFC9342' target='https://www.rfc-editor.org/info/rfc9342'>
<front>
<title>Clustered Alternate-Marking Method</title>
<author initials="G." surname="Fioccola" fullname="Giuseppe Fioccola" role="edit
or">
<organization>Huawei Technologies</organization>
</author>
<author initials="M." surname="Cociglio" fullname="Mauro Cociglio">
<organization>Telecom Italia</organization>
</author>
<author initials="A." surname="Sapio" fullname="Amedeo Sapio">
<organization>Intel Corporation</organization>
</author>
<author initials="R." surname="Sisto" fullname="Riccardo Sisto">
<organization>Politecnico di Torino</organization>
</author>
<author initials="T." surname="Zhou" fullname="Tianran Zhou">
<organization>Huawei Technologies</organization>
</author>
<date month="December" year="2022"/>
</front>
<seriesInfo name="RFC" value="9342"/>
<seriesInfo name="DOI" value="10.17487/RFC9342"/>
</reference>
<t>Revised section 5 on "Synchronization and Timing"</t> <!-- [I-D.ietf-ippm-explicit-flow-measurements] IESG state I-D Exists as of 11/
23/22-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-ip
pm-explicit-flow-measurements.xml"/>
</list></t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7384.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8799.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5357.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4656.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5481.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6703.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6390.xml"
/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2330.xml"
/>
<t>Changes in draft-ietf-ippm-rfc8321bis-01 include:<list style="symbols" <reference anchor="IEEE-NETWORK-PNPM" quoteTitle="true"
> target="https://doi.org/10.1109/MNET.2019.1800152">
<front>
<title>AM-PM: Efficient Network Telemetry using Alternate Marking</t
itle>
<author surname="Mizrahi" initials="T">
<organization showOnFrontPage="true"/>
</author>
<author surname="Navon" initials="G">
<organization showOnFrontPage="true"/>
</author>
<author surname="Fioccola" initials="G">
<organization showOnFrontPage="true"/>
</author>
<author surname="Cociglio" initials="M">
<organization showOnFrontPage="true"/>
</author>
<author surname="Chen" initials="M">
<organization showOnFrontPage="true"/>
</author>
<author surname="Mirsky" initials="G">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="July"/>
</front>
<seriesInfo name="IEEE Network" value="Vol. 33, Issue 4"/>
<seriesInfo name="DOI" value="10.1109/MNET.2019.1800152"/>
</reference>
</references>
</references>
<t>New section on "Summary of Changes from RFC 8321"</t> <section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Alberto Tempia Bonda
"/>, <contact fullname="Luca Castaldelli"/>,
and <contact fullname="Lianshu Zheng"/> for their contribution to the e
xperimentation of the method.</t>
<t>The authors would also like to thank <contact fullname="Martin Duke"/>
and <contact fullname="Tommy Pauly"/>
for their assistance and their detailed and precious reviews.</t>
</section>
<t>Revised sections on "Single-Marking Methodology" and "Double-Marking <section anchor="Contributors" numbered="false" toc="default">
Methodology"</t> <name>Contributors</name>
</list></t> <author fullname="Xiao Min">
<organization>ZTE Corp.</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>xiao.min2@zte.com.cn</email>
</address>
</author>
<t>Changes in draft-ietf-ippm-rfc8321bis-02 include:<list style="symbols" <author fullname="Mach(Guoyi) Chen">
> <organization>Huawei Technologies</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>mach.chen@huawei.com</email>
</address>
</author>
<t>Revised section on "Double-Marking Methodology"</t> <author fullname="Alessandro Capello">
<organization>Telecom Italia</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>alessandro.capello@telecomitalia.it</email>
</address>
</author>
<t>Revised references</t> </section>
</list></t> <!-- [rfced] Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.
<t>Changes in draft-ietf-ippm-rfc8321bis-03 include:<list style="symbols" - Single-Marking Method vs. Single-Marking method
> Note: We made this term consistent by capitalizing "method"
per RFC 8321 (also updated 1 instance in RFC-to-be 9342).
Please let us know if any further changes are needed.
<t>Comments addressed from Last Call review</t> FYI, these terms appear as follows. If any further updates are needed to the ca
se,
please let us know.
<t>Renamed section 7 as "Recommendations for Deployment"</t> - Alternate-Marking Method (per 8321)
- Alternate-Marking methodology
- Alternate Marking (no hyphen when not followed by a noun)
- Single-Marking Method
- Single-Marking methodology
- Single Marking (per 8321)
- Double Marking
-->
</list></t> <!-- [rfced] Please review the "Inclusive Language" portion of the online
</section> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Note that our script did not flag
any words in particular, but this should still be reviewed as a best practice.
-->
</back> </back>
</rfc> </rfc>
 End of changes. 206 change blocks. 
939 lines changed or deleted 693 lines changed or added

This html diff was produced by rfcdiff 1.48.