rfc9343xml2.original.xml   rfc9343.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc [
<!-- A set of on-line citation libraries are maintained on the xml2rfc web site. <!ENTITY nbsp "&#160;">
The next line defines an entity named RFC2629, which contains the necessary <!ENTITY zwsp "&#8203;">
XML <!ENTITY nbhy "&#8209;">
for the reference element, and is used much later in the file. This XML co <!ENTITY wj "&#8288;">
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. --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902"
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> docName="draft-ietf-6man-ipv6-alt-mark-17" number="9343" obsoletes="" updates="
" submissionType="IETF" consensus="true" xml:lang="en" tocInclude="true" tocDept
<!-- Processing Instructions can be placed here but if you are editing h="3" symRefs="true" sortRefs="true" version="3">
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-6man-ipv6-alt-mark-17" >
<!-- 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 -->
<?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.
Some like symbolic tags in the references (and citations) and others pr
efer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?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
t starting each
main section on a new page but does not omit the blank lines between li
st items.
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="IPv6 AMM">IPv6 Application of the Alternate Marking Method</t
itle>
<!-- add 'role="editor"' below for the editors if appropriate --> <title abbrev="IPv6 Application of the Alternate-Marking Method">IPv6 Applic
ation of the Alternate-Marking Method</title>
<seriesInfo name="RFC" value="9343"/>
<author fullname="Giuseppe Fioccola" initials="G." surname="Fioccola"> <author fullname="Giuseppe Fioccola" initials="G." surname="Fioccola">
<organization>Huawei</organization> <organization>Huawei</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="Tianran Zhou" initials="T." surname="Zhou"> <author fullname="Tianran Zhou" initials="T." surname="Zhou">
<organization>Huawei</organization> <organization>Huawei</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>
<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>
<region/> <region/>
<code/>
<code></code> <country/>
<country></country>
</postal> </postal>
<email>mauro.cociglio@outlook.com</email> <email>mauro.cociglio@outlook.com</email>
</address> </address>
</author> </author>
<author fullname="Fengwei Qin" initials="F." surname="Qin"> <author fullname="Fengwei Qin" initials="F." surname="Qin">
<organization>China Mobile</organization> <organization>China Mobile</organization>
<address> <address>
<postal> <postal>
<street>32 Xuanwumenxi Ave.</street> <street>32 Xuanwumenxi Ave.</street>
<city>Beijing</city> <city>Beijing</city>
<region/> <region/>
<code>100032</code> <code>100032</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>qinfengwei@chinamobile.com</email> <email>qinfengwei@chinamobile.com</email>
</address> </address>
</author> </author>
<author fullname="Ran Pang" initials="R." surname="Pang"> <author fullname="Ran Pang" initials="R." surname="Pang">
<organization>China Unicom</organization> <organization>China Unicom</organization>
<address> <address>
<postal> <postal>
<street>9 Shouti South Rd.</street> <street>9 Shouti South Rd.</street>
<city>Beijing</city> <city>Beijing</city>
<region/> <region/>
<code>100089</code> <code>100089</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>pangran@chinaunicom.cn</email> <email>pangran@chinaunicom.cn</email>
</address> </address>
</author> </author>
<date month="December" year="2022"/>
<date year="2022"/> <!-- month="March" is no longer necessary
note also, day="30" is optional -->
<!-- WARNING: If the month and year are the current ones, xml2rfc will fill
in the day for
you. If only the year is specified, xml2rfc will fill in the current da
y and month
irrespective of the day. This silliness should be fixed in v1.31. -->
<!-- Meta-data Declarations -->
<!-- Notice the use of &amp; as an escape for & which would otherwise
start an entity declaration, whereas we want a literal &. -->
<area>Internet</area> <area>Internet</area>
<workgroup>6MAN</workgroup>
<!-- WG name at the upperleft corner of the doc, <keyword>Extension</keyword>
IETF fine for individual submissions. You can also <keyword>Header</keyword>
omit this element in which case in defaults to "Network Working Group" <keyword>Option</keyword>
- <keyword>Destination</keyword>
a hangover from the ancient history of the IETF! --> <keyword>Hop-By-Hop</keyword>
<keyword>Performance</keyword>
<workgroup>6MAN Working Group</workgroup> <keyword>Measurement</keyword>
<keyword>Monitoring</keyword>
<!-- The DTD allows multiple area and workgroup elements but only the first <keyword>Passive</keyword>
one has any <keyword>Hybrid</keyword>
effect on output. --> <keyword>Loss</keyword>
<!-- You can add <keyword/> elements here. They will be incorporated into H <keyword>Delay</keyword>
TML output <keyword>Delay Variation</keyword>
files in a meta tag but they have no effect on text or nroff output. -- <keyword>Multipoint</keyword>
> <keyword>Cluster</keyword>
<keyword>Closed-Loop</keyword>
<abstract> <abstract>
<t>This document describes how the Alternate-Marking Method can be used
<t>This document describes how the Alternate Marking Method can be used
as a passive performance measurement tool in an IPv6 domain. It defines an as a passive performance measurement tool in an IPv6 domain. It defines an
Extension Header Option to encode Alternate Marking information in Extension Header Option to encode Alternate-Marking information in
both the Hop-by-Hop Options Header and Destination Options Header.</t> both the Hop-by-Hop Options Header and Destination Options Header.</t>
</abstract> </abstract>
</front>
</front> <middle>
<section numbered="true" toc="default">
<middle> <name>Introduction</name>
<section title="Introduction"> <t><xref target="RFC9341" format="default"/> and <xref target="RFC9342" fo
rmat="default"/>
<t><xref target="I-D.ietf-ippm-rfc8321bis"/> and <xref target="I-
D.ietf-ippm-rfc8889bis"/>
describe a passive performance measurement method, which can be u sed to measure packet loss, describe a passive performance measurement method, which can be u sed to measure packet loss,
latency and jitter on live traffic. Since this method is based on latency, and jitter on live traffic. Since this method is based o
marking consecutive n marking consecutive
batches of packets, the method is often referred to as the Altern batches of packets, the method is often referred to as the Altern
ate Marking Method.</t> ate-Marking Method.</t>
<t>This document defines how the Alternate-Marking Method can be used to m
<t>This document defines how the Alternate Marking Method can be easure
used to measure performance metrics in IPv6. The rationale is to apply the Altern
performance metrics in IPv6. The rationale is to apply the Altern ate-Marking methodology to IPv6 and
ate Marking methodology to IPv6 and therefore allow detailed packet loss, delay, and delay variation
therefore allow detailed packet loss, delay and delay variation m measurements both hop by hop and end to end
easurements both hop-by-hop and end-to-end
to exactly locate the issues in an IPv6 network.</t> to exactly locate the issues in an IPv6 network.</t>
<t>The Alternate Marking is an on-path telemetry technique and co nsists of synchronizing the measurements <t>Alternate Marking is an on-path telemetry technique and consis ts of synchronizing the measurements
in different points of a network by switching the value of a mark ing bit and therefore dividing the packet flow in different points of a network by switching the value of a mark ing bit and therefore dividing the packet flow
into batches. Each batch represents a measurable entity recogniza ble by all network nodes along the path. into batches. Each batch represents a measurable entity recogniza ble by all network nodes along the path.
By counting the number of packets in each batch and comparing the values measured by different nodes, By counting the number of packets in each batch and comparing the values measured by different nodes,
it is possible to precisely measure the packet loss. Similarly, t he alternation of the values it is possible to precisely measure the packet loss. Similarly, t he alternation of the values
of the marking bits can be used as a time reference to calculate the delay and delay variation. of the marking bits can be used as a time reference to calculate the delay and delay variation.
The Alternate Marking operation is further described in <xref tar get="operation"/>.</t> The Alternate-Marking operation is further described in <xref tar get="operation" format="default"/>.</t>
<t>This document introduces a TLV (type-length-value) that can be encoded in the Options Headers <t>This document introduces a TLV (type-length-value) that can be encoded in the Options Headers
(Hop-by-Hop or Destination), according to <xref target="RFC8200"> (Hop-by-Hop or Destination), according to <xref target="RFC8200"
</xref>, for the purpose of the format="default"/>, for the purpose of the
Alternate Marking Method application in an IPv6 domain.</t> Alternate-Marking Method application in an IPv6 domain.</t>
<t>The Alternate-Marking Method <bcp14>MUST</bcp14> be applied to IPv6 onl
<t>The Alternate Marking Method MUST be applied to IPv6 only in a y in a controlled environment, as further described
controlled environment, as further described in <xref target="ctrldmn" format="default"/>. <xref target="RFC87
in <xref target="ctrldmn"/>. <xref target="RFC8799"></xref> provi 99" format="default"/> provides further discussion of network behaviors
des further discussion of network behaviors
that can be applied only within limited domains.</t> that can be applied only within limited domains.</t>
<t>The threat model for the application of the Alternate-Marking Method in
an IPv6 domain is reported in
<xref target="security" format="default"/>.</t>
<section numbered="true" toc="default">
<name>Terminology</name>
<t>This document uses the terms related to the Alternate-Marking Method
as defined in <xref target="RFC9341" format="default"/> and <xref
target="RFC9342" format="default"/>.</t>
</section>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t>The threat model for the application of the Alternate Marking <t>
Method in an IPv6 domain is reported in The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
<xref target="security"/>.</t> IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
<section title="Terminology"> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
<t>This document uses the terms related to the Alternate Marking Method be interpreted as
as defined in <xref target="I-D.ietf-ippm-rfc8321bis"/> and <xref described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
target="I-D.ietf-ippm-rfc8889bis"/>.</t> when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section title="Requirements Language">
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;,
&quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
&quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;,
&quot;NOT RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&
quot;
in this document are to be interpreted as described in BCP 14
<xref target="RFC2119"></xref> <xref target="RFC8174"></xref>
when, and only when, they appear in all capitals, as shown here.<
/t>
</section>
</section>
</section> </section>
<section numbered="true" toc="default">
<name>Alternate-Marking Application to IPv6</name>
<section title="Alternate Marking application to IPv6"> <t>The Alternate-Marking Method requires a marking field. Several alternat
<t>The Alternate Marking Method requires a marking field. Several altern ives
atives could be considered such as IPv6 Extension Headers, IPv6 Address,
could be considered such as IPv6 Extension Headers, IPv6 Address and Flow Label.
and Flow Label.
But, it is necessary to analyze the drawbacks for all the availab le possibilities, But, it is necessary to analyze the drawbacks for all the availab le possibilities,
more specifically:<list> more specifically:</t>
<ul empty="false" spacing="normal">
<t>Reusing existing Extension Header for Alternate Marking lead <li>reusing an existing Extension Header for Alternate Marking leads to
s to a a
non-optimized implementation;</t> non-optimized implementation;</li>
<li>using the IPv6 destination address to encode the Alternate-Marking p
<t>Using the IPv6 destination address to encode the Alternate Marki rocessing
ng processing is very expensive; and</li>
is very expensive;</t> <li>using the IPv6 Flow Label for Alternate Marking conflicts with the u
tilization
<t>Using the IPv6 Flow Label for Alternate Marking conflicts wi of the Flow Label for load distribution purposes <xref target="RFC6438" f
th the utilization ormat="default"/>.</li>
of the Flow Label for load distribution purpose (<xref target="
RFC6438"></xref>).</t>
</list></t>
<t>In the end, a Hop-by-Hop or a Destination Option is the best c
hoice.</t>
<t>The approach for the Alternate Marking application to IPv6 spe
cified in this memo
is compliant with <xref target="RFC8200"></xref>. It involves the
following operations:<list style="symbols">
<t>The source node is the only one that writes the Option Heade </ul>
r to mark alternately <t>In the end, a Hop-by-Hop or a Destination Option is the best choice.</t
the flow (for both Hop-by-Hop and Destination Option). The inte >
rmediate nodes and destination node <t>The approach for the Alternate-Marking application to IPv6 specified in
MUST only read the marking values of the option without modifyi this memo
ng the Option Header.</t> is compliant with <xref target="RFC8200" format="default"/>. It i
nvolves the following operations:</t>
<ul spacing="normal">
<li>The source node is the only one that writes the Options Header to ma
rk alternately
the flow (for both the Hop-by-Hop and Destination Option). The
intermediate nodes and destination node
<bcp14>MUST</bcp14> only read the marking values of the Option without mo
difying the Options Header.</li>
<t>In case of Hop-by-Hop Option Header carrying Alternate Marki <li>In case of a Hop-by-Hop Options Header carrying Alternate-Marking bi
ng bits, it is not ts, the Options Header is not
inserted or deleted, but can be read by any node along the path inserted or deleted on the path, but it can be read by any node
. The intermediate nodes along the path. The intermediate nodes
may be configured to support this Option or not and the measure may be configured to support this Option or not, and the measur
ment can be done only for ement can be done only for
the nodes configured to read the Option. As further discussed i the nodes configured to read the Option. As further discussed i
n <xref target="use"/>, n <xref target="use" format="default"/>,
the presence of the hop-by-hop option should not affect the tra the presence of the Hop-by-Hop Option should not affect the tra
ffic throughput both on nodes ffic throughput both on nodes
that do not recognize this option and on the nodes that support that do not recognize this Option and on the nodes that support
it. However, it is worth it. However, it is worth
mentioning that there is a difference between theory and practi mentioning that there is a difference between theory and practi
ce. Indeed, in a real implementation ce. Indeed, in a real implementation,
it can happen that packets with hop-by-hop option could also be it is possible for packets with a Hop-by-Hop Option to be skipp
skipped or processed in the slow path. ed or processed in the slow path.
While some proposals are trying to address this problem and mak e Hop-by-Hop Options more practical While some proposals are trying to address this problem and mak e Hop-by-Hop Options more practical
(<xref target="I-D.ietf-v6ops-hbh"/>, <xref target="I-D.ietf-6m (see <xref target="I-D.ietf-v6ops-hbh" format="default"/> and <
an-hbh-processing"/>), these aspects xref target="I-D.ietf-6man-hbh-processing" format="default"/>), these aspects
are out of the scope for this document.</t> are out of the scope for this document.</li>
<li>In case of a Destination Options Header carrying Alternate-Marking b
<t>In case of Destination Option Header carrying Alternate Mark its, it is not
ing bits, it is not
processed, inserted, or deleted by any node along the path unti l the packet reaches processed, inserted, or deleted by any node along the path unti l the packet reaches
the destination node. Note that, if there is also a Routing Hea der (RH), any visited the destination node. Note that, if there is also a Routing Hea der (RH), any visited
destination in the route list can process the Option Header.</t destination in the route list can process the Options Header.</
> li>
</list></t> </ul>
<t>A Hop-by-Hop Options Header is also useful to signal to routers on the
<t>Hop-by-Hop Option Header is also useful to signal to routers o path to process the
n the path to process the Alternate Marking. However, as said, routers will only examine this Option
Alternate Marking. However, as said, routers will only examine th if properly configured.</t>
is option if properly configured.</t>
<t>The optimization of both implementation and scaling of the Alt <t>The optimization of both implementation and the scaling of the Alternat
ernate Marking Method is e-Marking Method is
also considered and a way to identify flows is required. The also considered, and a way to identify flows is required. The Flo
Flow Monitoring Identification field w Monitoring Identification
(FlowMonID), as introduced in <xref target="flowmonid"/>, goes in (FlowMonID) field, as introduced in <xref target="flowmonid" form
this direction and it is used to identify at="default"/>, goes in this direction, and it is used to identify
a monitored flow.</t> a monitored flow.</t>
<t>The FlowMonID is different from the Flow Label field of the IPv6 header
<t>The FlowMonID is different from the Flow Label field of the IP <xref target="RFC6437" format="default"/>.
v6 Header (<xref target="RFC6437"></xref>).
The Flow Label field in the IPv6 header is used by a source to la bel sequences of packets to be treated The Flow Label field in the IPv6 header is used by a source to la bel sequences of packets to be treated
in the network as a single flow and, as reported in <xref target= in the network as a single flow and, as reported in <xref target=
"RFC6438"></xref>, it can be used "RFC6438" format="default"/>, it can be used
for load-balancing/equal cost multi-path (LB/ECMP). The reuse of for load balancing (LB) and equal-cost multipath (ECMP). The reus
Flow Label field for identifying monitored flows e of the Flow Label field for identifying monitored flows
is not considered because it may change the application intent an d forwarding behavior. Also, the Flow Label is not considered because it may change the application intent an d forwarding behavior. Also, the Flow Label
may be changed en route and this may also invalidate the integrit y of the measurement. Those reasons make the definition may be changed en route, and this may also invalidate the integri ty of the measurement. Those reasons make the definition
of the FlowMonID necessary for IPv6. Indeed, the FlowMonID is des igned and only used to identify the monitored flow. of the FlowMonID necessary for IPv6. Indeed, the FlowMonID is des igned and only used to identify the monitored flow.
Flow Label and FlowMonID within the same packet are totally disjo int, have different scope, Flow Label and FlowMonID within the same packet are totally disjo int, have different scopes,
are used to identify flows based on different criteria, and are i ntended for different use cases.</t> are used to identify flows based on different criteria, and are i ntended for different use cases.</t>
<t>The rationale for the FlowMonID is further discussed in <xref target="f
<t>The rationale for the FlowMonID is further discussed in <xref targ lowmonid" format="default"/>. This 20-bit field
et="flowmonid"/>. This 20 bit field
allows easy and flexible identification of the monitored flow and enables improved measurement correlation allows easy and flexible identification of the monitored flow and enables improved measurement correlation
and finer granularity since it can be used in combination with th and finer granularity since it can be used in combination with th
e traditional TCP/IP 5-tuple to identify a flow. e conventional TCP/IP 5-tuple to identify a flow.
An important point that will be discussed in <xref target="flowmo An important point that will be discussed in <xref target="flowmo
nid"/> is the uniqueness of the FlowMonID nid" format="default"/> is the uniqueness of the FlowMonID
and how to allow disambiguation of the FlowMonID in case of colli sion.</t> and how to allow disambiguation of the FlowMonID in case of colli sion.</t>
<t>The following section highlights an important requirement for the appli
cation of the Alternate Marking to IPv6.
The concept of the controlled domain is explained and is considered an e
ssential precondition, as also highlighted
in <xref target="security" format="default"/>.</t>
<section anchor="ctrldmn" numbered="true" toc="default">
<name>Controlled Domain</name>
<t>The following section highlights an important requirement for <t>IPv6 has much more flexibility than IPv4 and innovative applications h
the application of the Alternate Marking to IPv6. ave been proposed, but
The concept of the controlled domain is explained and it is considered a
n essential precondition, as also highlighted
in <xref target="security"/>.</t>
<section anchor="ctrldmn" title="Controlled Domain">
<t>IPv6 has much more flexibility than IPv4 and innovative applic
ations have been proposed, but
for security and compatibility reasons, some of these applications are l imited to a controlled environment. for security and compatibility reasons, some of these applications are l imited to a controlled environment.
This is also the case of the Alternate Marking application to IPv This is also the case of the Alternate-Marking application to IPv
6 as assumed hereinafter. 6 as assumed hereinafter.
In this regard, <xref target="RFC8799"></xref> reports further ex In this regard, <xref target="RFC8799" format="default"/> reports
amples of specific limited domain solutions.</t> further examples of specific limited domain solutions.</t>
<t>The IPv6 application of the Alternate-Marking Method <bcp14>MUST</bcp
<t>The IPv6 application of the Alternate Marking Method MUST be d 14> be deployed in a controlled domain.
eployed in a controlled domain.
It is not common that the user traffic originates and terminates within the controlled domain, as also noted in It is not common that the user traffic originates and terminates within the controlled domain, as also noted in
<xref target="altmarkmeasdmn"/>. For this reason, it will typical <xref target="altmarkmeasdmn" format="default"/>. For this reason
ly only be applicable in an overlay network, , it will typically only be applicable in an overlay network,
where user traffic is encapsulated at one domain border, decapsul where user traffic is encapsulated at one domain border and decap
ated at the other domain border and the encapsulation sulated at the other domain border, and the encapsulation
incorporates the relevant extension header for Alternate Marking. incorporates the relevant extension header for Alternate Marking.
This requirement also implies that an implementation MUST filter packets that carry Alternate Marking This requirement also implies that an implementation <bcp14>MUST< /bcp14> filter packets that carry Alternate-Marking
data and are entering or leaving the controlled domain.</t> data and are entering or leaving the controlled domain.</t>
<t>A controlled domain is a managed network where it is required to sele
<t>A controlled domain is a managed network where it is required ct, monitor, and control the access to the network
to select, monitor and control the access to the network
by enforcing policies at the domain boundaries in order to discar d undesired external packets entering the domain by enforcing policies at the domain boundaries in order to discar d undesired external packets entering the domain
and check the internal packets leaving the domain. It does not ne cessarily mean that a controlled domain is a single administrative domain and check the internal packets leaving the domain. It does not ne cessarily mean that a controlled domain is a single administrative domain
or a single organization. A controlled domain can correspond to a single administrative domain or can be composed by or a single organization. A controlled domain can correspond to a single administrative domain or can be composed by
multiple administrative domains under a defined network managemen multiple administrative domains under a defined network managemen
t. Indeed, some scenarios may imply that the Alternate Marking Method t. Indeed, some scenarios may imply that the Alternate-Marking Method
involves more than one domain, but in these cases, it is RECOMMEN involves more than one domain, but in these cases, it is <bcp14>R
DED that the multiple domains create a whole controlled domain ECOMMENDED</bcp14> that the multiple domains create a whole controlled domain
while traversing the external domain by employing IPsec <xref tar while traversing the external domain by employing IPsec <xref tar
get="RFC4301"></xref> authentication and encryption or get="RFC4301" format="default"/> authentication and encryption or
other VPN technology that provides full packet confidentiality an d integrity protection. In a few words, it must be possible other VPN technology that provides full packet confidentiality an d integrity protection. In a few words, it must be possible
to control the domain boundaries and eventually use specific prec to control the domain boundaries and eventually use specific prec
autions if the traffic traverse the Internet.</t> autions if the traffic traverses the Internet.</t>
<t>The security considerations reported in <xref target="security" forma
<t>The security considerations reported in <xref target="security t="default"/> also highlight this requirement.</t>
"/> also highlight this requirement.</t> <section anchor="altmarkmeasdmn" numbered="true" toc="default">
<name>Alternate-Marking Measurement Domain</name>
<section anchor="altmarkmeasdmn" title="Alternate Marking Measure <t>The Alternate-Marking measurement domain can overlap with the contr
ment Domain"> olled domain or may be a subset
of the controlled domain. The typical scenarios for the applicati
<t>The Alternate Marking measurement domain can overlap with the on of the Alternate-Marking Method
controlled domain or may be a subset depend on the controlled domain boundaries; in particular:</t>
of the controlled domain. The typical scenarios for the applicati
on of the Alternate Marking Method
depend on the controlled domain boundaries, in particular:<list>
<t>the user equipment can be the starting or ending node, only <ul empty="false" spacing="normal">
in case it is fully managed and if it belongs
to the controlled domain. In this case the user generated IPv6
packets contain the Alternate Marking data.
But, in practice, this is not common due to the fact that the u
ser equipment cannot be totally secured in the majority of cases.</t>
<t>the CPE (Customer Premises Equipment) or the PE (Provider Edge) <li>The user equipment can be the starting or ending node only when/i
routers are most likely to be the starting or f it is fully managed and belongs
to the controlled domain. In this case, the user-generated IPv6
packets contain the Alternate-Marking data.
But, in practice, this is not common due to the fact that the u
ser equipment cannot be totally secured in the majority of cases.</li>
<li>The Customer Premises Equipment (CPE) or the Provider Edge (PE)
routers are most likely to be the starting or
ending nodes since they can be border routers of the controlled domain. For instance, the CPE, which connects the user's premises ending nodes since they can be border routers of the controlled domain. For instance, the CPE, which connects the user's premises
with the service provider's network, belongs to a controlled do main only if it is managed by the service provider and with the service provider's network, belongs to a controlled do main only if it is managed by the service provider and
if additional security measures are taken to keep it trustworth y. if additional security measures are taken to keep it trustworth y.
Typically the CPE or the PE can encapsulate a received packet i Typically, the CPE or the PE can encapsulate a received packet
n an outer IPv6 header which contains the Alternate Marking data. in an outer IPv6 header, which contains the Alternate-Marking data.
They can also be able to filter and drop packets from outside o They are also able to filter and drop packets from outside of t
f the domain with inconsistent fields he domain with inconsistent fields
to make effective the relevant security rules at the domain bou to make effective the relevant security rules at the domain bou
ndaries, for example a simple security check ndaries; for example, a simple security check
can be to insert the Alternate Marking data if and only if the can be to insert the Alternate-Marking data if and only if the
destination is within the controlled domain.</t> destination is within the controlled domain.</li>
</ul>
</list></t> </section>
</section>
</section> </section>
</section>
</section>
<section title="Definition of the AltMark Option">
<t>The definition of a TLV for the Options Extension Headers, <section numbered="true" toc="default">
carrying the data fields dedicated to the Alternate Marking method, <name>Definition of the AltMark Option</name>
<t>The definition of a TLV for the Extension Header Option,
carrying the data fields dedicated to the Alternate-Marking Method,
is reported below.</t> is reported below.</t>
<section numbered="true" toc="default">
<section title="Data Fields Format"> <name>Data Fields Format</name>
<t>The following figure shows the data fields format for enhanced <t>The following figure shows the data fields format for enhanced
Alternate Marking TLV (AltMark). This AltMark data can be encapsulated in Alternate-Marking TLV (AltMark). This AltMark data can be encapsulated in
the IPv6 Options Headers the IPv6 Options Headers
(Hop-by-Hop or Destination Option). (Hop-by-Hop or Destination Option).
<figure> </t>
<artwork name="AltMark: TLV for Alternate Marking"><![CDATA[ <artwork name="AltMark: TLV for Alternate Marking" type="" align="left"
alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len | | Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FlowMonID |L|D| Reserved | | FlowMonID |L|D| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <t>
where:</t>
<t><list style="symbols"> Where:</t>
<t>Option Type: 8-bit identifier of the type of Option that needs t
o
be allocated. Unrecognized Types MUST be ignored on processing.
For Hop-by-Hop Options Header or Destination Options Header,
<xref target="RFC8200"></xref> defines how to encode the three
high-order bits of
the Option Type field. The two high-order bits specify the acti
on that must be taken if the
processing IPv6 node does not recognize the Option Type; for Al
tMark
these two bits MUST be set to 00 (skip over this Option and con
tinue processing the header).
The third-highest-order bit specifies whether the Option Data c
an change en route
to the packet's final destination; for AltMark the value of thi
s bit MUST be set to 0
(Option Data does not change en route). In this way, since the
three high-order bits of the
AltMark Option are set to 000, it means that nodes can simply s
kip this Option if they do not recognize
and that the data of this Option do not change en route, indeed
the source is the only one that can write it.</t>
<t>Opt Data Len: 4. It is the length of the Option Data Fields <dl>
of this Option in bytes.</t> <dt>Option Type:
</dt>
<dd>8-bit identifier of the type of Option that needs to be
allocated. Unrecognized Types <bcp14>MUST</bcp14> be ignored
on processing. For the Hop-by-Hop Options Header or Destinatio
n
Options Header, <xref target="RFC8200" format="default"/>
defines how to encode the three high-order bits of the
Option Type field. The two high-order bits specify the
action that must be taken if the processing IPv6 node does
not recognize the Option Type; for AltMark, these two bits
<bcp14>MUST</bcp14> be set to 00 (skip over this Option and
continue processing the header). The third-highest-order
bit specifies whether the Option Data can change en route to
the packet's final destination; for AltMark, the value of
this bit <bcp14>MUST</bcp14> be set to 0 (Option Data does
not change en route). In this way, since the three
high-order bits of the AltMark Option are set to 000, it
means that nodes can simply skip this Option if they do not
recognize it and that the data of this Option does not change e
n
route; indeed the source is the only one that can write it.
</dd>
<t>FlowMonID: 20-bit unsigned integer. The FlowMon identifier is descr <dt>Opt Data Len:
ibed in <xref target="flowmonid"/>. </dt>
As further discussed below, it has been picked as 20 bits since <dd>4. It is the length of the Option Data Fields of this
it is a reasonable value and a good compromise in relation Option in bytes.
to the chance of collision. It MUST be set pseudo randomly by t </dd>
he source node or by a centralized controller.</t>
<t>L: Loss flag for Packet Loss Measurement as described in <xref targ <dt>FlowMonID:
et="loss"/>;</t> </dt>
<dd>20-bit unsigned integer. The FlowMon identifier is
described in <xref target="flowmonid" format="default"/>.
As further discussed below, it has been picked as 20 bits
since it is a reasonable value and a good compromise in
relation to the chance of collision. It <bcp14>MUST</bcp14>
be set pseudo-randomly by the source node or by a
centralized controller.
</dd>
<t>D: Delay flag for Single Packet Delay Measurement as described in < <dt>L:
xref target="delay"/>;</t> </dt>
<dd>Loss flag for Packet Loss Measurement as described in
<xref target="loss" format="default"/>.
</dd>
<t>Reserved: is reserved for future use. These bits MUST be set to <dt>D:
zero on transmission and ignored on receipt.</t> </dt>
</list></t> <dd>Delay flag for Single Packet Delay Measurement as
described in <xref target="delay" format="default"/>.
</dd>
</section> <dt>Reserved:
</dt>
<dd>Reserved for future use. These bits
<bcp14>MUST</bcp14> be set to zero on transmission and
ignored on receipt.
</dd>
</dl>
</section>
</section> </section>
<section anchor="use" title="Use of the AltMark Option"> <section anchor="use" numbered="true" toc="default">
<t>The AltMark Option is the best way to implement the Alternate Markin <name>Use of the AltMark Option</name>
g method and it is carried <t>The AltMark Option is the best way to implement the Alternate-Marking M
by the Hop-by-Hop Options header and the Destination Options header. ethod, and it is carried
In case of Destination Option, it is processed only by the source and d by the Hop-by-Hop Options Header and the Destination Options Header.
estination nodes: the source node inserts In case of Destination Option, it is processed only by the source and d
estination nodes: the source node inserts it
and the destination node processes it. and the destination node processes it.
While, in case of Hop-by-Hop Option, it may be examined by any node alo ng the path, if explicitly configured to do so.</t> In case of the Hop-by-Hop Option, it may be examined by any node along the path if explicitly configured to do so.</t>
<t>It is important to highlight that the Option Layout can be used both <t>It is important to highlight that the Option Layout can be used both
as Destination Option and as as the Destination Option and as the
Hop-by-Hop Option depending on the Use Cases and it is based on the cho Hop-by-Hop Option depending on the use cases, and it is based on the ch
sen type of performance measurement. osen type of performance measurement.
In general, it is needed to perform both end to end and hop by hop meas In general, it is needed to perform both end-to-end and hop-by-hop meas
urements, and the Alternate Marking urements, and the Alternate-Marking
methodology allows, by definition, both performance measurements. In ma methodology allows, by definition, both performance measurements.
ny cases the end-to-end measurement In many cases, the end-to-end measurement
is not enough and it is required the hop-by-hop measurement, so the mos may not be enough, and the hop-by-hop measurement is required. To meet
t complete choice can be this need, the most complete choice is the
the Hop-by-Hop Options Header.</t> Hop-by-Hop Options Header.</t>
<t>IPv6, as specified in <xref target="RFC8200"></xref>, allows nodes t <t>IPv6, as specified in <xref target="RFC8200" format="default"/>, allows
o optionally process nodes to optionally process
Hop-by-Hop headers. Specifically the Hop-by-Hop Options header is not i Hop-by-Hop headers. Specifically, the Hop-by-Hop Options Header is not
nserted or deleted, but may inserted or deleted, but it may
be examined or processed by any node along a packet's delivery path, until the packet reaches the node be examined or processed by any node along a packet's delivery path, until the packet reaches the node
(or each of the set of nodes, in the case of multicast) identified in t he Destination (or each of the set of nodes in the case of multicast) identified in th e Destination
Address field of the IPv6 header. Also, it is expected that nodes along a packet's delivery path Address field of the IPv6 header. Also, it is expected that nodes along a packet's delivery path
only examine and process the Hop-by-Hop Options header if explicitly co only examine and process the Hop-by-Hop Options Header if explicitly co
nfigured to do so.</t> nfigured to do so.</t>
<t>Another scenario is the presence of a Routing Header.
<t>Another scenario that can be mentioned is the presence of a Routing Both Hop-by-Hop Options and Destination Options Headers can be used whe
Header. n a Routing Header is present.
Both Hop-by-Hop Options and Destination Options headers can be used whe
n a Routing Header is present.
Depending on where the Destination Options are situated in the header c hain (before or after the Routing Header if any), Depending on where the Destination Options are situated in the header c hain (before or after the Routing Header if any),
Destination Options headers can be processed by either intermediate rou Destination Options Headers can be processed by either intermediate rou
ters specified in the Routing Header, or by the destination node. ters specified in the Routing Header or the destination node.
As an example, a type of Routing Header, referred as Segment Routing He As an example, a type of Routing Header, referred to as a Segment Routi
ader (SRH), has been defined in <xref target="RFC8754"></xref> ng Header (SRH), has been defined in <xref target="RFC8754" format="default"/>
for Segment Routing over IPv6 dataplane (SRv6), and more details about for the Segment Routing over IPv6 (SRv6) data place, and more details a
the SRv6 application can be found in bout the SRv6 application can be found in
<xref target="I-D.fz-spring-srv6-alt-mark"/>.</t> <xref target="I-D.fz-spring-srv6-alt-mark" format="default"/>.</t>
<t>In summary, using these tools, it is possible to control on which nodes
<t>In summary, using these tools, it is possible to control on which no measurement occurs:</t>
des measurement occurs:<list style="symbols"> <ul spacing="normal">
<li>Destination Option not preceding a Routing Header =&gt; measurement
<t>Destination Option not preceding a Routing Header => measurement only by node in Destination Address</li>
only by node in Destination Address.</t> <li>Hop-by-Hop Option =&gt; every router on the path with feature
enabled</li>
<t>Hop-by-Hop Option => every router on the path with feature <li>Destination Option preceding a Routing Header =&gt; every destinatio
enabled.</t> n
node in the route list</li>
<t>Destination Option preceding a Routing Header => every destination </ul>
node in the route list.</t> <t>In general, Hop-by-Hop and Destination Options are the most suitable wa
</list></t> ys
<t>In general, Hop-by-Hop and Destination Options are the most suitable
ways
to implement Alternate Marking.</t> to implement Alternate Marking.</t>
<t>It is worth mentioning that Hop-by-Hop Options are not strongly reco <t>It is worth mentioning that Hop-by-Hop Options are not strongly reco
mmended in <xref target="RFC7045"></xref> mmended in <xref target="RFC7045" format="default"/>
and <xref target="RFC8200"></xref>, unless there is a clear justificati and <xref target="RFC8200" format="default"/>, unless there is a clear
on to standardize it, because nodes may be justification to standardize it, because nodes may be
configured to ignore the Options Header, drop or assign packets contain configured to ignore the Options Header or drop or assign packets conta
ing an Options Header to a slow processing path. ining an Options Header to a slow processing path.
In case of the AltMark data fields described in this document, the moti In case of the AltMark Data Fields described in this document, the moti
vation to standardize a Hop-by-Hop Option vation to standardize a Hop-by-Hop Option
is that it is needed for OAM (Operations, Administration, and Maintenan is that it is needed for Operations, Administration, and Maintenance (O
ce). An intermediate node can read it or not, but AM). An intermediate node can read it or not, but
this does not affect the packet behavior. The source node is the only o this does not affect the packet behavior. The source node is the only o
ne that writes the Hop-by-Hop Option to mark alternately ne that writes the Hop-by-Hop Option to alternately mark
the flow, so, the performance measurement can be done for those nodes c the flow; therefore, the performance measurement can be done for those
onfigured to read this Option, nodes configured to read this Option,
while the others are simply not considered for the metrics.</t> while the others are simply not considered for the metrics.</t>
<t>The Hop-by-Hop Option defined in this document is designed to take a dvantage of the property of how Hop-by-Hop <t>The Hop-by-Hop Option defined in this document is designed to take a dvantage of the property of how Hop-by-Hop
options are processed. Nodes that do not support this Option would be e Options are processed. Nodes that do not support this Option would be e
xpected to ignore it if encountered, xpected to ignore it if encountered,
according to the procedures of <xref target="RFC8200"></xref>. This can according to the procedures of <xref target="RFC8200" format="default"/
mean that, in this case, the performance measurement >. This can mean that, in this case, the performance measurement
does not account for all links and nodes along a path. The definition o f the Hop-by-Hop Options in this document is also does not account for all links and nodes along a path. The definition o f the Hop-by-Hop Options in this document is also
designed to minimize throughput impact both on nodes that do not recogn designed to minimize throughput impact both on nodes that do not recogn
ize the Option and on node that support it. ize the Option and on nodes that support it.
Indeed, the three high-order bits of the Options Header defined in this Indeed, the three high-order bits of the Options Header defined in this
draft are 000 and, in theory, as per document are 000 and, in theory, as per
<xref target="RFC8200"></xref> and <xref target="I-D.ietf-6man-hbh-proc <xref target="RFC8200" format="default"/> and <xref target="I-D.ietf-6m
essing"/>, this means "skip if do not recognize and an-hbh-processing" format="default"/>, this means "skip if not recognized and da
data do not change en route". <xref target="RFC8200"></xref> also menti ta does not change en route". <xref target="RFC8200" format="default"/> also men
ons that the nodes only examine and process the tions that the nodes only examine and process the Hop-by-Hop Options Header if e
Hop-by-Hop Options header if explicitly configured to do so. For these xplicitly configured to do so. For these reasons, this Hop-by-Hop Option should
reasons, this Hop-by-Hop Option should not affect the throughput. not affect the throughput.
However, in practice, it is important to be aware that the things may b However, in practice, it is important to be aware that things may be di
e different in the implementation and it can happen that packets fferent in the implementation, and it can happen that packets
with Hop-by-Hop are forced onto the slow path, but this is a general is with Hop by Hop are forced onto the slow path, but this is a general is
sue, as also explained in <xref target="I-D.ietf-6man-hbh-processing"/>. sue, as also explained in <xref target="I-D.ietf-6man-hbh-processing" format="de
fault"/>.
It is also worth mentioning that the application to a controlled domain should avoid the risk of arbitrary nodes dropping packets It is also worth mentioning that the application to a controlled domain should avoid the risk of arbitrary nodes dropping packets
with Hop-by-Hop Options.</t> with Hop-by-Hop Options.</t>
</section> </section>
<section anchor="operation" title="Alternate Marking Method Operation"> <section anchor="operation" numbered="true" toc="default">
<name>Alternate-Marking Method Operation</name>
<t>This section describes how the method operates. <xref target="I-D.iet <t>This section describes how the method operates. <xref target="RFC9341"
f-ippm-rfc8321bis"/> format="default"/>
introduces several applicable methods which are reported below, a introduces several applicable methods, which are reported below,
nd an additional field is introduced and an additional field is introduced
to facilitate the deployment and improve the scalability.</t> to facilitate the deployment and improve the scalability.</t>
<section anchor="loss" numbered="true" toc="default">
<section anchor="loss" title="Packet Loss Measurement"> <name>Packet Loss Measurement</name>
<t>The measurement of the packet loss is really straightforward in compa
<t>The measurement of the packet loss is really straightforward i rison to the existing mechanisms,
n comparison to the existing mechanisms, as detailed in <xref target="RFC9341" format="default"/>.
as detailed in <xref target="I-D.ietf-ippm-rfc8321bis"/>.
The packets of the flow are grouped into batches, and all the pac kets within a batch are marked by setting The packets of the flow are grouped into batches, and all the pac kets within a batch are marked by setting
the L bit (Loss flag) to a same value. The source node can switch the value of the L bit between 0 and 1 the L bit (Loss flag) to a same value. The source node can switch the value of the L bit between 0 and 1
after a fixed number of packets or according to a fixed timer, an d this depends on the after a fixed number of packets or according to a fixed timer, an d this depends on the
implementation. The source node is the only one that marks the pa ckets to create the batches, while implementation. The source node is the only one that marks the pa ckets to create the batches, while
the intermediate nodes only read the marking values and identify the packet batches. the intermediate nodes only read the marking values and identify the packet batches.
By counting the number of packets in each batch and comparing the values measured by By counting the number of packets in each batch and comparing the values measured by
different network nodes along the path, it is possible to measure the packet loss occurred different network nodes along the path, it is possible to measure the packet loss that occurred
in any single batch between any two nodes. Each batch represents a measurable entity in any single batch between any two nodes. Each batch represents a measurable entity
recognizable by all network nodes along the path.</t> recognizable by all network nodes along the path.</t>
<t>Both fixed number of packets and a fixed timer can be used by the sou
rce node to create packet batches.
But, as also explained in <xref target="RFC9341" format="default"
/>, the timer-based batches are preferable because
they are more deterministic than the counter-based batches.
<t>Both fixed number of packets and fixed timer can be used by the sourc Unlike the timer-based batches, there is no definitive rule
e node to create packet batches. for counter-based batches, which are not considered in <xref target="RFC9341"/>.
But, as also explained in <xref target="I-D.ietf-ippm-rfc8321bis"
/>, the timer-based batches are preferable because Using a fixed timer for the switching offers
they are more deterministic than the counter-based batches. There better control over the method; indeed, the length of the batches
is no definitive rule for counter-based can be chosen large enough to simplify
batches, differently from timer-based batches. Using a fixed time the collection and the comparison of the measures taken by differ
r for the switching offers ent network nodes. In the implementation,
better control over the method, indeed the length of the batches
can be chosen large enough to simplify
the collection and the comparison of the measures taken by differ
ent network nodes. In the implementation
the counters can be sent out by each node to the controller that is responsible for the calculation. the counters can be sent out by each node to the controller that is responsible for the calculation.
It is also possible to exchange this information by using other o It is also possible to exchange this information by using other o
n-path techniques. But this is out of scope n-path techniques, but this is out of scope
for this document.</t> for this document.</t>
<t>Packets with different L values may get swapped at batch bound aries, and in this case, <t>Packets with different L values may get swapped at batch boundaries, and in this case,
it is required that each marked packet can be assigned to the rig ht batch by each router. it is required that each marked packet can be assigned to the rig ht batch by each router.
It is important to mention that for the application of this metho It is important to mention that for the application of this metho
d there are two elements d, there are two elements
to consider: the clock error between network nodes and the networ to consider: the clock error between network nodes and the networ
k delay. These can create k delay.
offsets between the batches and out-of-order of the packets. The These can create
mathematical formula offsets between the batches and out-of-order packets.
on timing aspects, explained in section 5 of <xref target="I-D.ie The mathematical formula
tf-ippm-rfc8321bis"/>, must be satisfied on timing aspects, explained in <xref sectionFormat="of" section
and it takes into considerations the different causes of reorderi ="5" target="RFC9341" format="default"/>, must be satisfied,
ng such as clock error and network delay. and it takes into consideration the different causes of reorderin
The assumption is to define the available counting interval where g such as clock error and network delay.
to get stable counters and to avoid these issues. The assumption is to define the available counting interval to ge
t stable counters and to avoid these issues.
Specifically, if the effects of network delay are ignored, the co ndition to implement the methodology is that Specifically, if the effects of network delay are ignored, the co ndition to implement the methodology is that
the clocks in different nodes MUST be synchronized to the same cl the clocks in different nodes <bcp14>MUST</bcp14> be synchronized
ock reference with an accuracy of +/- B/2 time units, to the same clock reference with an accuracy of +/- B/2 time units,
where B is the fixed time duration of the batch. In this way each where B is the fixed time duration of the batch. In this way, eac
marked packet can be assigned to the right batch by each node. h marked packet can be assigned to the right batch by each node.
Usually the counters can be taken in the middle of the batch peri Usually, the counters can be taken in the middle of the batch per
od to be sure to read quiescent counters. iod to be sure to read quiescent counters.
In a few words this implies that the length of the batches MUST b In a few words, this implies that the length of the batches <bcp1
e chosen large enough so that the method 4>MUST</bcp14> be chosen large enough so that the method
is not affected by those factors. The length of the batches can b e determined based on the specific deployment scenario.</t> is not affected by those factors. The length of the batches can b e determined based on the specific deployment scenario.</t>
<figure anchor="Lbit">
<figure anchor="Lbit" title="Packet Loss Measurement and Single-Marking <name>Packet Loss Measurement and Single-Marking Methodology Using L B
Methodology using L bit"> it</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
L bit=1 ----------+ +-----------+ +---------- L bit=1 ----------+ +-----------+ +----------
| | | | | | | |
L bit=0 +-----------+ +-----------+ L bit=0 +-----------+ +-----------+
Batch n ... Batch 3 Batch 2 Batch 1 Batch n ... Batch 3 Batch 2 Batch 1
<---------> <---------> <---------> <---------> <---------> <---------> <---------> <---------> <---------> <--------->
Traffic Flow Traffic Flow
===========================================================> ===========================================================>
L bit ...1111111111 0000000000 11111111111 00000000000 111111111... L bit ...1111111111 0000000000 11111111111 00000000000 111111111...
===========================================================> ===========================================================>
skipping to change at line 600 skipping to change at line 479
L bit=1 ----------+ +-----------+ +---------- L bit=1 ----------+ +-----------+ +----------
| | | | | | | |
L bit=0 +-----------+ +-----------+ L bit=0 +-----------+ +-----------+
Batch n ... Batch 3 Batch 2 Batch 1 Batch n ... Batch 3 Batch 2 Batch 1
<---------> <---------> <---------> <---------> <---------> <---------> <---------> <---------> <---------> <--------->
Traffic Flow Traffic Flow
===========================================================> ===========================================================>
L bit ...1111111111 0000000000 11111111111 00000000000 111111111... L bit ...1111111111 0000000000 11111111111 00000000000 111111111...
===========================================================> ===========================================================>
]]></artwork> ]]></artwork>
</figure> </figure>
<t>It is worth mentioning that the duration of the batches is considered
<t>It is worth mentioning that the duration of the batches is considered stable over time in the previous figure.
stable over time in the previous figure.
In theory, it is possible to change the length of batches over time an d among different flows for more flexibility. In theory, it is possible to change the length of batches over time an d among different flows for more flexibility.
But, in practice, it could complicate the correlation of the informati on.</t> But, in practice, it could complicate the correlation of the informati on.</t>
</section>
</section> <section anchor="delay" numbered="true" toc="default">
<name>Packet Delay Measurement</name>
<section anchor="delay" title="Packet Delay Measurement"> <t>The same principle used to measure packet loss can also be applied to
one-way delay measurement. Delay metrics <bcp14>MAY</bcp14> be ca
<t>The same principle used to measure packet loss can be applied lculated using the following two
also to possibilities:</t>
one-way delay measurement. Delay metrics MAY be calculated using <dl>
the two <dt>Single-Marking Methodology:</dt> <dd>This approach uses onl
possibilities:<list style="numbers"> y the L bit to calculate both packet loss
and delay. In this case, the D flag <bcp14>MUST</bcp14> be set to
<t>Single-Marking Methodology: This approach uses only the L bit zero on transmit and ignored by the
to calculate both packet loss
and delay. In this case, the D flag MUST be set to zero on transm
it and ignored by the
monitoring points. The alternation of the values of the L bit can be used as a time reference to calculate monitoring points. The alternation of the values of the L bit can be used as a time reference to calculate
the delay. Whenever the L bit changes and a new batch starts, a n etwork node can store the timestamp the delay. Whenever the L bit changes and a new batch starts, a n etwork node can store the timestamp
of the first packet of the new batch, that timestamp can be compa of the first packet of the new batch; that timestamp can be compa
red with the timestamp of the red with the timestamp of the
first packet of the same batch on a second node to compute packet first packet of the same batch on a second node to compute packet
delay. But this measurement delay. But, this measurement
is accurate only if no packet loss occurs and if there is no pack et reordering at the edges is accurate only if no packet loss occurs and if there is no pack et reordering at the edges
of the batches. A different approach can also be considered and i t is based on the concept of the of the batches. A different approach can also be considered, and it is based on the concept of the
mean delay. The mean delay for each batch is calculated by consi dering the average arrival time mean delay. The mean delay for each batch is calculated by consi dering the average arrival time
of the packets for the relative batch. There are limitations also in this case indeed, each node needs of the packets for the relative batch. There are limitations also in this case indeed; each node needs
to collect all the timestamps and calculate the average timestamp for each batch. In addition, the to collect all the timestamps and calculate the average timestamp for each batch. In addition, the
information is limited to a mean value.</t> information is limited to a mean value.</dd>
<t>Double-Marking Methodology: This approach is more complete and <dt>Double-Marking Methodology:</dt> <dd>This approach is more complet
uses the L bit only to calculate e and uses the L bit only to calculate
packet loss and the D bit (Delay flag) is fully dedicated to dela packet loss, and the D bit (Delay flag) is fully dedicated to del
y measurements. The idea is to use ay measurements. The idea is to use
the first marking with the L bit to create the alternate flow and , within the batches identified by the L bit, the first marking with the L bit to create the alternate flow and , within the batches identified by the L bit,
a second marking is used to select the packets for measuring dela y. The D bit creates a new set of marked packets a second marking is used to select the packets for measuring dela y. The D bit creates a new set of marked packets
that are fully identified over the network, so that a network nod e can store the timestamps of these packets; that are fully identified over the network so that a network node can store the timestamps of these packets;
these timestamps can be compared with the timestamps of the same packets on a second node to compute packet these timestamps can be compared with the timestamps of the same packets on a second node to compute packet
delay values for each packet. The most efficient and robust mode is to select a single double-marked packet delay values for each packet. The most efficient and robust mode is to select a single double-marked packet
for each batch, in this way there is no time gap to consider betw for each batch; in this way, there is no time gap to consider bet
een the double-marked packets to avoid their reorder. ween the double-marked packets to avoid their reorder.
Regarding the rule for the selection of the packet to be double-m Regarding the rule for the selection of the packet to be double-m
arked, the same considerations in <xref target="loss"/> arked, the same considerations in <xref target="loss" format="default"/>
apply also here and the double-marked packet can be chosen within also apply here, and the double-marked packet can be chosen withi
the available counting interval that n the available counting interval that
is not affected by factors such as clock errors. is not affected by factors such as clock errors.
If a double-marked packet is lost, the delay measurement for the considered batch is simply discarded, If a double-marked packet is lost, the delay measurement for the considered batch is simply discarded,
but this is not a big problem because it is easy to recognize the problematic batch and skip the measurement but this is not a big problem because it is easy to recognize the problematic batch and skip the measurement
just for that one. So in order to have more information about the just for that one. So in order to have more information about the
delay and to overcome out-of-order issues delay and to overcome out-of-order issues,
this method is preferred.</t> this method is preferred.</dd>
</dl>
</list></t> <t>In summary, the approach with Double Marking is better than the appro
ach with Single Marking. Moreover,
<t>In summary the approach with double marking is better than the the two approaches provide slightly different pieces of informati
approach with single marking. Moreover, on, and the data consumer can combine them
the two approaches provide slightly different pieces of informati
on and the data consumer can combine them
to have a more robust data set.</t> to have a more robust data set.</t>
<t>Similar to what is said in <xref target="loss" format="default"/> for
<t>Similar to what said in <xref target="loss"/> for the packet c the packet counters, in the implementation, the timestamps can be
ounters, in the implementation the timestamps can be sent out to the controller that is responsible for the calculatio
sent out to the controller that is responsible for the calculatio n or exchanged using other on-path techniques.
n or could also be exchanged using other on-path techniques. But, this is out of scope for this document.</t>
But this is out of scope for this document.</t> <figure anchor="Dbit">
<name>Double-Marking Methodology Using L Bit and D Bit</name>
<figure anchor="Dbit" title="Double-Marking Methodology using L b <artwork name="" type="" align="left" alt=""><![CDATA[
it and D bit">
<artwork><![CDATA[
L bit=1 ----------+ +-----------+ +---------- L bit=1 ----------+ +-----------+ +----------
| | | | | | | |
L bit=0 +-----------+ +-----------+ L bit=0 +-----------+ +-----------+
D bit=1 + + + + + D bit=1 + + + + +
| | | | | | | | | |
D bit=0 ------+----------+----------+----------+------------+----- D bit=0 ------+----------+----------+----------+------------+-----
Traffic Flow Traffic Flow
===========================================================> ===========================================================>
skipping to change at line 672 skipping to change at line 543
D bit=1 + + + + + D bit=1 + + + + +
| | | | | | | | | |
D bit=0 ------+----------+----------+----------+------------+----- D bit=0 ------+----------+----------+----------+------------+-----
Traffic Flow Traffic Flow
===========================================================> ===========================================================>
L bit ...1111111111 0000000000 11111111111 00000000000 111111111... L bit ...1111111111 0000000000 11111111111 00000000000 111111111...
D bit ...0000010000 0000010000 00000100000 00001000000 000001000... D bit ...0000010000 0000010000 00000100000 00001000000 000001000...
===========================================================> ===========================================================>
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Likewise, to packet delay measurement (both for Single Marking and Do
<t>Likewise to packet delay measurement (both for Single Marking uble Marking), the method can also be used
and Double Marking), the method can also be used
to measure the inter-arrival jitter.</t> to measure the inter-arrival jitter.</t>
</section>
</section> <section anchor="flowmonid" numbered="true" toc="default">
<name>Flow Monitoring Identification</name>
<section anchor="flowmonid" title="Flow Monitoring Identification <t>The Flow Monitoring Identification (FlowMonID) identifies the flow to
"> be measured and
is required for some general reasons:</t>
<t>The Flow Monitoring Identification (FlowMonID) identifies the flow <ul spacing="normal">
to be measured and <li>First, it helps to reduce the per-node configuration. Otherwise, e
is required for some general reasons:<list> ach node needs to
configure an access control list (ACL) for each of the monitored flow
<t>First, it helps to reduce the per node configuration. Otherwis s.
e, each node needs to Moreover, using a flow identifier allows a flexible granularity f
configure an access-control list (ACL) for each of the monitored flow or the flow definition;
s. indeed, it can be used together with other identifiers (e.g., 5-t
Moreover, using a flow identifier allows a flexible granularity f uple).</li>
or the flow definition, <li>Second, it simplifies the counters handling. Hardware processing o
indeed, it can be used together with other identifiers (e.g. 5-tu f flow tuples (and ACL matching)
ple).</t> is challenging and often incurs into performance issues, especial
ly in tunnel interfaces.</li>
<t>Second, it simplifies the counters handling. Hardware processing o <li>Third, it eases the data export encapsulation and correlation for
f flow tuples (and ACL matching) the collectors.</li>
is challenging and often incurs into performance issues, especial </ul>
ly in tunnel interfaces.</t> <t>The FlowMonID <bcp14>MUST</bcp14> only be used as a monitored flow id
entifier in order to determine a monitored flow
<t>Third, it eases the data export encapsulation and correlation
for the collectors.</t>
</list></t>
<t>The FlowMonID MUST only be used as a monitored flow identifier
in order to determine a monitored flow
within the measurement domain. This entails not only an easy iden tification but improved correlation as well.</t> within the measurement domain. This entails not only an easy iden tification but improved correlation as well.</t>
<t>The FlowMonID allocation procedure can be stateful or stateless. In c
<t>The FlowMonID allocation procedure can be stateful or stateles ase of a stateful approach, it is required that
s. In case of a stateful approach, it is required that
the FlowMonID historic information can be stored and tracked in o rder to assign unique values within the domain. the FlowMonID historic information can be stored and tracked in o rder to assign unique values within the domain.
This may imply a complex procedure and it is considered out of sc This may imply a complex procedure, and it is considered out of s
ope for this document. cope for this document.
The stateless approach is described hereinafter where FlowMonID v The stateless approach is described hereinafter where FlowMonID v
alues are pseudo randomly generated.</t> alues are pseudo-randomly generated.</t>
<t>The value of 20 bits has been selected for the FlowMonID since it is
<t>The value of 20 bits has been selected for the FlowMonID since a good compromise and implies a low rate
it is a good compromise and implies a low rate
of ambiguous FlowMonIDs that can be considered acceptable in most of the applications. The disambiguation issue of ambiguous FlowMonIDs that can be considered acceptable in most of the applications. The disambiguation issue
can be solved by tagging the pseudo randomly generated FlowMonID can be solved by tagging the pseudo-randomly generated FlowMonID
with additional flow information. with additional flow information.
In particular, it is RECOMMENDED to consider the 3-tuple FlowMonI In particular, it is <bcp14>RECOMMENDED</bcp14> to consider the 3
D, source and destination addresses:<list style="symbols"> -tuple FlowMonID, source, and destination addresses:</t>
<ul spacing="normal">
<t>If the 20 bit FlowMonID is set independently and pseudo rand <li>If the 20-bit FlowMonID is set independently and pseudo-randomly in
omly in a distributed way there is a chance of collision. a distributed way, there is a chance of collision.
Indeed, by using the well-known birthday problem in probability Indeed, by using the well-known birthday problem in probability
theory, if the 20 bit FlowMonID theory, if the 20-bit FlowMonID
is set independently and pseudo randomly without any additional is set independently and pseudo-randomly without any additional
input entropy, there is a 50% chance of collision input entropy, there is a 50% chance of collision
for 1206 flows. So, for more entropy, FlowMonID is combined wit h source and destination addresses. for 1206 flows. So, for more entropy, FlowMonID is combined wit h source and destination addresses.
Since there is a 1% chance of collision for 145 flows, it is po ssible to monitor 145 concurrent flows per host pairs Since there is a 1% chance of collision for 145 flows, it is po ssible to monitor 145 concurrent flows per host pairs
with a 1% chance of collision.</t> with a 1% chance of collision.</li>
<li>If the 20-bit FlowMonID is set pseudo-randomly but in a centralize
<t>If the 20 bits FlowMonID is set pseudo randomly but in a cen d way, the controller can instruct the nodes properly
tralized way, the controller can instruct the nodes properly
in order to guarantee the uniqueness of the FlowMonID. With 20 bits, the number of combinations is 1048576, and the controller in order to guarantee the uniqueness of the FlowMonID. With 20 bits, the number of combinations is 1048576, and the controller
should ensure that all the FlowMonID values are used without an y collision. Therefore, by considering source and destination addresses should ensure that all the FlowMonID values are used without an y collision. Therefore, by considering source and destination addresses
together with the FlowMonID, it can be possible to monitor 1048 together with the FlowMonID, it is possible to monitor 1048576
576 concurrent flows per host pairs.</t> concurrent flows per host pairs.</li>
</list></t> </ul>
<t>A consistent approach <bcp14>MUST</bcp14> be used in the Alternate-Ma
<t>A consistent approach MUST be used in the Alternate Marking de rking deployment to avoid the mixture of different ways of identifying.
ployment to avoid the mixture of different ways of identifying. All the nodes along the path and involved in the measurement <bcp
All the nodes along the path and involved into the measurement SH 14>SHOULD</bcp14> use the same mode for identification.
OULD use the same mode for identification. As mentioned, it is <bcp14>RECOMMENDED</bcp14> to use the FlowMon
As mentioned, it is RECOMMENDED to use the FlowMonID for identifi ID for identification purposes in combination with source and destination addres
cation purpose in combination with source and destination addresses ses
to identify a flow. By considering source and destination address to identify a flow. By considering source and destination address
es together with the FlowMonID it can be possible to monitor es together with the FlowMonID, it is possible to monitor
145 concurrent flows per host pairs with a 1% chance of collision 145 concurrent flows per host pairs with a 1% chance of collision
in case of pseudo randomly generated FlowMonID, or in case of pseudo-randomly generated FlowMonID, or
1048576 concurrent flows per host pairs in case of centralized co 1048576 concurrent flows per host pairs in case of a centralized
ntroller. It is worth mentioning that controller. It is worth mentioning that
the solution with the centralized control allows finer granularit y and therefore adds even more flexibility to the flow identification.</t> the solution with the centralized control allows finer granularit y and therefore adds even more flexibility to the flow identification.</t>
<t>The FlowMonID field is set at the source node, which is the ingress p oint of the measurement domain, and <t>The FlowMonID field is set at the source node, which is the ingress p oint of the measurement domain, and
can be set in two ways:<list style="letters"> can be set in two ways:</t>
<ul spacing="normal"><li>It can be algorithmically generated by the sour
<t>It can be algorithmically generated by the source node, that c ce node, which can set it pseudo-randomly with some
an set it pseudo-randomly with some
chance of collision. This approach cannot guarantee the uniquenes s of FlowMonID since conflicts and collisions are possible. chance of collision. This approach cannot guarantee the uniquenes s of FlowMonID since conflicts and collisions are possible.
But, considering the recommendation to use FlowMonID with source But, considering the recommendation to use FlowMonID with source
and destination addresses the conflict probability is reduced due to and destination addresses, the conflict probability is reduced due to
the FlowMonID space available for each endpoint pair (i.e. 145 fl the FlowMonID space available for each endpoint pair (i.e., 145 f
ows with 1% chance of collision).</t> lows with 1% chance of collision).</li>
<li>It can be assigned by the central controller. Since the controller
<t>It can be assigned by the central controller. Since the contro knows the network topology,
ller knows the network topology,
it can allocate the value properly to avoid or minimize ambiguity and guarantee the uniqueness. In this regard, it can allocate the value properly to avoid or minimize ambiguity and guarantee the uniqueness. In this regard,
the controller can verify that there is no ambiguity between diff erent pseudo-randomly generated FlowMonIDs on the same path. the controller can verify that there is no ambiguity between diff erent pseudo-randomly generated FlowMonIDs on the same path.
The conflict probability is really small given that the FlowMonID is coupled with source and destination addresses The conflict probability is really small given that the FlowMonID is coupled with source and destination addresses,
and up to 1048576 flows can be monitored for each endpoint pair. When al l values in the FlowMonID space are consumed, and up to 1048576 flows can be monitored for each endpoint pair. When al l values in the FlowMonID space are consumed,
the centralized controller can keep track and reassign the values the centralized controller can keep track and reassign the values
that are not used any more by old flows.</t> that are not used any more by old flows.</li>
</ul>
</list></t> <t>If the FlowMonID is set by the source node, the intermediate nodes ca
n read the FlowMonIDs from the packets in flight
<t>If the FlowMonID is set by the source node, the intermediate n and act accordingly. If the FlowMonID is set by the controller, b
odes can read the FlowMonIDs from the packets in flight oth possibilities are feasible for the intermediate nodes,
and act accordingly. While, if the FlowMonID is set by the contro
ller, both possibilities are feasible for the intermediate nodes
which can learn by reading the packets or can be instructed by the contr oller.</t> which can learn by reading the packets or can be instructed by the contr oller.</t>
<t>The FlowMonID setting by the source node may seem faster and more sca
lable than the FlowMonID setting by the controller. But,
it is supposed that the controller does not slow the process sinc
e it can enable the Alternate-Marking Method and its parameters (like FlowMonID)
together with the flow instantiation, as further described in <xr
ef target="I-D.ietf-idr-sr-policy-ifit" format="default"/> and <xref target="I-D
.ietf-pce-pcep-ifit" format="default"/>.</t>
</section>
<t>The FlowMonID setting by the source node may seem faster and m <section numbered="true" toc="default">
ore scalable than the FlowMonID setting by the controller. But, <name>Multipoint and Clustered Alternate Marking</name>
it is supposed that the controller does not slow the process sinc <t>The Alternate-Marking Method can be extended to any kind of multipoin
e it can enable Alternate Marking method and its parameters (like FlowMonID) t-to-multipoint paths.
together with the flow instantiation, as further described in <xr <xref target="RFC9341" format="default"/> only applies to point-t
ef target="I-D.ietf-idr-sr-policy-ifit"/> and <xref target="I-D.chen-pce-pcep-if o-point unicast flows,
it"/>.</t> while the Clustered Alternate-Marking Method, introduced in <xref
target="RFC9342" format="default"/>,
</section> is valid for multipoint-to-multipoint unicast flows, anycast, and
ECMP flows.</t>
<section title="Multipoint and Clustered Alternate Marking">
<t>The Alternate Marking method can be extended to any kind of mu
ltipoint to multipoint paths.
<xref target="I-D.ietf-ippm-rfc8321bis"/> only applies to point-t
o-point unicast flows,
while the Multipoint Alternate Marking Clustered method, introduc
ed in <xref target="I-D.ietf-ippm-rfc8889bis"/>,
is valid for multipoint-to-multipoint unicast flows, anycast and
ECMP flows.</t>
<t><xref target="I-D.ietf-ippm-rfc8889bis"/> describes the networ k clustering approach which <t><xref target="RFC9342" format="default"/> describes the networ k clustering approach, which
allows a flexible and optimized performance measurement. allows a flexible and optimized performance measurement.
A Cluster is the smallest identifiable non-trivial subnetwork of A cluster is the smallest identifiable non-trivial subnetwork of
the entire Network graph the entire network graph
that still satisfies the condition that the number of packets tha that still satisfies the condition that the number of packets tha
t goes in is the same that goes out. t goes in is the same number that goes out.
With network clustering, it is possible to use the partition of t With network clustering, it is possible to partition the network
he network into clusters into clusters
at different levels in order to perform the needed degree of deta il.</t> at different levels in order to perform the needed degree of deta il.</t>
<t>For Multipoint Alternate Marking, FlowMonID can identify in general
<t>For Multipoint Alternate Marking, FlowMonID can identify in ge
neral
a multipoint-to-multipoint flow and not only a point-to-point flo w.</t> a multipoint-to-multipoint flow and not only a point-to-point flo w.</t>
</section>
<section numbered="true" toc="default">
<name>Data Collection and Calculation</name>
</section> <t>The nodes enabled to perform performance monitoring collect the value
<section title="Data Collection and Calculation">
<t>The nodes enabled to perform performance monitoring collect th
e value
of the packet counters and timestamps. There are several alternat ives to implement of the packet counters and timestamps. There are several alternat ives to implement
Data Collection and Calculation, but this is not specified in thi data collection and calculation, but this is not specified in thi
s document.</t> s document.</t>
<t>There are documents on the control plane mechanisms of Alternate Mark
<t>There are documents on the control plane mechanisms of Alterna ing, e.g.,
te Marking, e.g. <xref target="I-D.ietf-idr-sr-policy-ifit" format="default"/> and
<xref target="I-D.ietf-idr-sr-policy-ifit"/>, <xref target="I-D.c <xref target="I-D.ietf-pce-pcep-ifit" format="default"/>.</t>
hen-pce-pcep-ifit"/>.</t> </section>
</section>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
<section anchor="security" title="Security Considerations"> <t>This document aims to apply a method to the performance measurements th
<t>This document aims to apply a method to perform measurements t at does
hat does
not directly affect Internet security nor applications that run o n not directly affect Internet security nor applications that run o n
the Internet. However, implementation of this method must be mind ful the Internet. However, implementation of this method must be mind ful
of security and privacy concerns.</t> of security and privacy concerns.</t>
<t>There are two types of security concerns:
<t>There are two types of security concerns:
potential harm caused by the measurements and potential harm to t he measurements.</t> potential harm caused by the measurements and potential harm to t he measurements.</t>
<dl>
<dt>Harm caused by the measurement:
</dt>
<dd>Alternate Marking implies the insertion of an Options Header to the IPv6
packets by the source node, but this must be performed in a way that does not
alter the quality of service experienced by the packets and that preserves
stability and performance of routers doing the measurements. As already
discussed in <xref target="use" format="default"/>, the design of the AltMark
Option has been chosen with throughput in mind, such that it can be
implemented without affecting the user experience.
</dd>
<t>Harm caused by the measurement: Alternate Marking implies the inse <dt>Harm to the measurement:
rtion of an Option Header </dt>
to the IPv6 packets by the source node, but this must be performe <dd>Alternate-Marking measurements could be harmed by routers altering the
d in a way that does not alter fields of the AltMark Option (e.g., marking of the packets or FlowMonID) or by a
the quality of service experienced by the packets and that preser malicious attacker adding the AltMark Option to the packets in order to consume
ves stability and performance the resources of network devices and entities involved. As described above,
of routers doing the measurements. As already discussed in <xref the source node is the only one that writes the Options Header while the
target="use"/>, the design of the intermediate nodes and destination node only read it without modifying the
AltMark Option has been chosen with throughput in mind, such that Options Header. But, for example, an on-path attacker can modify the flags,
it can be implemented whether intentionally or accidentally, or deliberately insert an Option to the
without affecting the user experience.</t> packet flow or delete the Option from the packet flow. The consequent effect
could be to give the appearance of loss or delay or to invalidate the measuremen
t
by modifying Option identifiers, such as FlowMonID. The malicious implication
can be to cause actions from the network administrator where an intervention
is not necessary or to hide real issues in the network. Since the measurement
itself may be affected by network nodes intentionally altering the bits of the
AltMark Option or injecting Options Headers as a means for Denial of Service
(DoS), the Alternate Marking <bcp14>MUST</bcp14> be applied in the context of
a controlled domain, where the network nodes are locally administered and this
type of attack can be avoided. For this reason, the implementation of the
method is not done on the end node if it is not fully managed and does not
belong to the controlled domain. Packets generated outside the controlled
domain may consume router resources by maliciously using the Hop-by-Hop Option,
but
this can be mitigated by filtering these packets at the controlled domain
boundary. This can be done because if the end node does not belong to the
controlled domain, it is not supposed to add the AltMark Hop-by-Hop Option, and
it
can be easily recognized.
</dd>
<t>Harm to the measurement: Alternate Marking measurements could </dl>
be harmed by
routers altering the fields of the AltMark Option (e.g. marking o
f the packets, FlowMonID)
or by a malicious attacker adding AltMark Option to the packets i
n order to consume the resources of
network devices and entities involved. As described above, the so
urce node is the only one that writes
the Option Header while the intermediate nodes and destination no
de only read it without modifying the
Option Header. But, for example, an on-path attacker can modify t
he flags, whether intentionally or accidentally,
or deliberately insert an option to the packet flow or delete the
option from the packet flow. The consequent
effect could be to give the appearance of loss or delay or invali
date the measurement by modifying option identifiers,
such as FlowMonID. The malicious implication can be to cause acti
ons from the network administrator where an intervention
is not necessary or to hide real issues in the network.
Since the measurement itself may be affected by network nodes int
entionally altering the bits of the AltMark Option
or injecting Options headers as a means for Denial of Service (Do
S), the Alternate Marking MUST be applied
in the context of a controlled domain, where the network nodes ar
e locally administered and this type of attack
can be avoided. For this reason, the implementation of the method
is not done on the end node if it is not fully managed
and does not belong to the controlled domain. Packets generated o
utside the controlled domain may consume
router resources by maliciously using the HbH Option, but this ca
n be mitigated by filtering these packets at the controlled
domain boundary. This can be done because, if the end node does n
ot belong to the controlled domain, it is not supposed
to add the AltMark HbH Option, and it can be easily recognized.</
t>
<t>An attacker that does not belong to the controlled domain can <t>An attacker that does not belong to the controlled domain can maliciously sen
maliciously send packets with AltMark Option. d packets with the AltMark Option.
But if Alternate Marking is not supported in the controlled domai But, if Alternate Marking is not supported in the controlled doma
n, no problem happens because the AltMark Option is treated in, no problem happens because the AltMark Option is treated
as any other unrecognized option and will not be considered by th as any other unrecognized Option and will not be considered by th
e nodes since they are not configured to deal with it, so e nodes since they are not configured to deal with it; so,
the only effect is the increased packet size (by 48 bits). the only effect is the increased packet size (by 48 bits).
While if Alternate Marking is supported in the controlled domain, If Alternate Marking is supported in the controlled domain, it is
it is also necessary to avoid that the measurements are affected necessary to keep the measurements from being affected,
and external packets with AltMark Option MUST be filtered. and external packets with the AltMark Option <bcp14>MUST</bcp14>
As any other Hop-by-Hop Options or Destination Options, it is pos be filtered.
sible to filter AltMark Options entering or leaving the domain As any other Hop-by-Hop Options or Destination Options, it is pos
e.g. by using ACL extensions for filtering.</t> sible to filter AltMark Options entering or leaving the domain,
e.g., by using ACL extensions for filtering.</t>
<t>The flow identifier (FlowMonID), together with the two marking
bits (L and D), comprises the AltMark Option.
<t>The flow identifier (FlowMonID), together with the two marking As explained in <xref target="flowmonid" format="default"/>, ther
bit (L and D), comprises the AltMark Option. e is a chance of collision if the FlowMonID
As explained in <xref target="flowmonid"/>, there is a chance of is set pseudo-randomly, but there is a solution for this issue. I
collision if the FlowMonID n general, this may not be a problem, and a low rate of
is set pseudo randomly but that there is a solution for this issu ambiguous FlowMonIDs can be acceptable since this does not cause
e. In general this may not be a problem and a low rate of significant harm to the operators or
ambiguous FlowMonIDs can be acceptable, since this does not cause their clients, and this harm may not justify the complications of
significant harm to the operators or avoiding it. But, for large scale measurements,
their clients and this harm may not justify the complications of a big number of flows could be monitored and the probability of a
avoiding it. But, for large scale measurements, collision is higher; thus, the disambiguation
a big number of flows could be monitored and the probability of a
collision is higher, thus the disambiguation
of the FlowMonID field can be considered.</t> of the FlowMonID field can be considered.</t>
<t>The privacy concerns also need to be analyzed even if the method only r
<t>The privacy concerns also need to be analyzed even if the meth elies on information contained
od only relies on information contained in the Options Header without any release of user data. Indeed, f
in the Option Header without any release of user data. Indeed, fr rom a confidentiality perspective,
om a confidentiality perspective, although the AltMark Option does not contain user data, the metad
although AltMark Option does not contain user data, the metadata ata can be used for network reconnaissance
can be used for network reconnaissance
to compromise the privacy of users by allowing attackers to colle ct information about network performance and network paths. to compromise the privacy of users by allowing attackers to colle ct information about network performance and network paths.
AltMark Option contains two kinds of metadata: the marking bits ( L and D bits) and the flow identifier (FlowMonID).<list> The AltMark Option contains two kinds of metadata: the marking bi ts (L and D) and the flow identifier (FlowMonID).</t>
<t>The marking bits are the small information that is exchange <ul spacing="normal">
d between the network nodes. Therefore, due to this intrinsic <li>The marking bits are the small information that is exchanged between
characteristic, network reconnaissance through passive eavesdr the network nodes. Therefore, due to this intrinsic
opping on data-plane traffic is difficult. characteristic, network reconnaissance through passive eavesdr
opping on data plane traffic is difficult.
Indeed, an attacker cannot gain information about network perf ormance from a single monitoring point. The only way for an attacker Indeed, an attacker cannot gain information about network perf ormance from a single monitoring point. The only way for an attacker
can be to eavesdrop on multiple monitoring points at the same time, because they have to do the same kind of calculation can be to eavesdrop on multiple monitoring points at the same time, because they have to do the same kind of calculation
and aggregation as Alternate Marking requires.</t> and aggregation as Alternate Marking requires.</li>
<li>The FlowMonID field is used in the AltMark Option as the identifier
<t>The FlowMonID field is used in the AltMark Option as the id of the monitored flow. It represents more sensitive information
entifier of the monitored flow. It represents a more sensitive information
for network reconnaissance and may allow a flow tracking type of attack because an attacker could collect information for network reconnaissance and may allow a flow tracking type of attack because an attacker could collect information
about network paths.</t> about network paths.</li>
</ul>
</list></t> <t>Furthermore, in a pervasive surveillance attack, the information that c
an be derived over time is more.
<t>Furthermore, in a pervasive surveillance attack, the informati
on that can be derived over time is more.
But, as further described hereinafter, the application of the Alt ernate Marking to a controlled domain But, as further described hereinafter, the application of the Alt ernate Marking to a controlled domain
helps to mitigate all the above aspects of privacy concerns.</t> helps to mitigate all the above aspects of privacy concerns.</t>
<t>At the management plane, attacks can be set up by misconfiguring or by
<t>At the management plane, attacks can be set up by misconfiguri maliciously configuring the AltMark Option.
ng or by maliciously configuring AltMark Option. Thus, AltMark Option configuration <bcp14>MUST</bcp14> be secured
Thus, AltMark Option configuration MUST be secured in a way that in a way that authenticates authorized users and verifies the
authenticates authorized users and verifies the integrity of configuration procedures. Solutions to ensure the in
integrity of configuration procedures. Solutions to ensure the in tegrity of the AltMark Option are outside the
tegrity of AltMark Option are outside the
scope of this document. Also, attacks on the reporting of the sta tistics between the monitoring points and the scope of this document. Also, attacks on the reporting of the sta tistics between the monitoring points and the
network management system (e.g. centralized controller) can inter network management system (e.g., centralized controller) can interfere w
fere with the proper functioning of the system. ith the proper functioning of the system.
Hence, the channels used to report back flow statistics MUST be s Hence, the channels used to report back flow statistics <bcp14>MU
ecured.</t> ST</bcp14> be secured.</t>
<t>As stated above, the precondition for the application of the Alternate
<t>As stated above, the precondition for the application of the Alternate Marking is that it <bcp14>MUST</bcp14> be applied
Marking is that it MUST be applied
in specific controlled domains, thus confining the potential atta ck vectors within the network domain. in specific controlled domains, thus confining the potential atta ck vectors within the network domain.
A limited administrative domain provides the network administrato A limited administrative domain provides the network administrato
r with the means to select, monitor and r with the means to select, monitor, and
control the access to the network, making it a trusted domain. In control the access to the network, making it a trusted domain. In
this regard it is expected to enforce policies this regard, it is expected to enforce policies
at the domain boundaries to filter both external packets with AltMark Op at the domain boundaries to filter both external packets with the AltMar
tion entering the domain and k Option entering the domain and
internal packets with AltMark Option leaving the domain. Therefor internal packets with the AltMark Option leaving the domain. Ther
e, the trusted domain is unlikely subject efore, the trusted domain is unlikely subject
to hijacking of packets since packets with AltMark Option are pro to the hijacking of packets since packets with AltMark Option are
cessed and used only within the controlled domain.</t> processed and used only within the controlled domain.</t>
<t>As stated, the application to a controlled domain ensures control over
<t>As stated, the application to a controlled domain ensures the the packets entering and leaving the domain,
control over the packets entering and leaving the domain, but despite that, leakages may happen for different reasons such
but despite that, leakages may happen for different reasons, such as a failure or a fault. In this case, nodes
as a failure or a fault. In this case, nodes outside the domain are expected to ignore packets with the AltMar
outside the domain are expected to ignore packets with AltMark Op k Option since they are not configured to handle it and
tion since they are not configured to handle it and
should not process it.</t> should not process it.</t>
<t>Additionally, note that the AltMark Option is carried by the Options He
<t>Additionally, it is to be noted that the AltMark Option is car ader
ried by the Options Header and it will have some impact on the packet sizes for the monitore
and it will have some impact on the packet sizes for the monitore d flow and on the path MTU
d flow and on the path MTU, since some packets might exceed the MTU. However, the relative sm
since some packets might exceed the MTU. However, the relative sm all size (48 bits in total)
all size (48 bit in total) of these Options Headers and its application to a controlled doma
of these Option Headers and its application to a controlled domai in help to mitigate the problem.</t>
n help to mitigate the problem.</t> <t>It is worth mentioning that the security concerns may change based on t
he specific deployment scenario
<t>It is worth mentioning that the security concerns may change based on and related threat analysis, which can lead to specific security solutio
the specific deployment scenario ns that are beyond the scope of this document.
and related threat analysis, which can lead to specific security solu As an example, the AltMark Option can be used as a Hop-by-Hop or
tions that are beyond the scope of this document. Destination Option and, in case of a Destination Option,
As an example, the AltMark Option can be used as Hop-by-Hop or De
stination Option and, in case of Destination Option,
multiple administrative domains may be traversed by the AltMark O ption that is not confined to a single administrative domain. multiple administrative domains may be traversed by the AltMark O ption that is not confined to a single administrative domain.
In this case, the user, aware of the kind of risks, may still wan In this case, the user, who is aware of the kind of risks, may st
t to use Alternate Marking for telemetry and test purposes but ill want to use Alternate Marking for telemetry and test purposes, but
the controlled domain must be composed by more than one administrative d the controlled domain must be composed by more than one administrative d
omains. To this end, the inter-domain links need omain. To this end, the inter-domain links need
to be secured (e.g., by IPsec, VPNs) in order to avoid external t to be secured (e.g., by IPsec or VPNs) in order to avoid external
hreats and realize the whole controlled domain.</t> threats and realize the whole controlled domain.</t>
<t>It might be theoretically possible to modulate the marking or the other
<t>It might be theoretically possible to modulate the marking or fields of the AltMark Option to serve as a covert channel
the other fields of the AltMark Option to serve as a covert channel
to be used by an on-path observer. This may affect both the data and management plane, but, here too, the application to a to be used by an on-path observer. This may affect both the data and management plane, but, here too, the application to a
controlled domain helps to reduce the effects.</t> controlled domain helps to reduce the effects.</t>
<t>The Alternate-Marking application described in this document relies on
<t>The Alternate Marking application described in this document r a time synchronization
elies on a time synchronization
protocol. Thus, by attacking the time protocol, an attacker can p otentially compromise the integrity protocol. Thus, by attacking the time protocol, an attacker can p otentially compromise the integrity
of the measurement. A detailed discussion about the threats again st time protocols and of the measurement. A detailed discussion about the threats again st time protocols and
how to mitigate them is presented in <xref target="RFC7384"/>. Ne how to mitigate them is presented in <xref target="RFC7384" forma
twork Time Security (NTS), t="default"/>. Network Time Security (NTS),
described in <xref target="RFC8915"/>, is a mechanism that can be described in <xref target="RFC8915" format="default"/>, is a mech
employed. Also, the time, anism that can be employed. Also, the time,
which is distributed to the network nodes through the time protoc which is distributed to the network nodes through the time protoc
ol, is centrally taken from an external accurate time source, ol, is centrally taken from an external accurate time source
such as an atomic clock or a GPS clock. By attacking the time sou such as an atomic clock or a GPS clock. By attacking the time sou
rce it can be possible to compromise the integrity rce, it is possible to compromise the integrity
of the measurement as well. There are security measures that can of the measurement as well. There are security measures that can
be taken to mitigate the GPS spoofing attacks and a be taken to mitigate the GPS spoofing attacks, and a
network administrator should certainly employ solutions to secure the network domain.</t> network administrator should certainly employ solutions to secure the network domain.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="IANA" title="IANA Considerations"> <t>IANA has allocated the Option Type in
<t>The Option Type should be assigned in IANA's the "Destination Options and Hop-by-Hop Options" subregistry of t
"Destination Options and Hop-by-Hop Options" registry.</t> he
"Internet Protocol Version 6 (IPv6) Parameters" registry (<eref
<t>This draft requests the following IPv6 Option Type assignment brackets="angle" target="https://www.iana.org/assignments/ipv6-parameters/"/>) a
from s follows:</t>
the Destination Options and Hop-by-Hop Options sub-registry of
Internet Protocol Version 6 (IPv6) Parameters (https://www.iana.o
rg/assignments/ipv6-parameters/).</t>
<t><figure>
<artwork><![CDATA[
Hex Value Binary Value Description Reference
act chg rest
----------------------------------------------------------------
TBD 00 0 tbd AltMark [This draft]
]]></artwork>
</figure></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Bob Hinden, Ole Troan, Martin Duke, L
ars Eggert, Roman Danyliw,
Alvaro Retana, Eric Vyncke, Warren Kumari, Benjamin Kaduk, Stewar
t Bryant, Christopher Wood,
Yoshifumi Nishida, Tom Herbert, Stefano Previdi, Brian Carpenter,
Greg Mirsky, Ron Bonica
for the precious comments and suggestions.</t>
</section>
<!-- Possibly a 'Contributors' section ... --> <table anchor="table_1">
<name>Destination Options and Hop-by-Hop Options Registry</name>
<thead>
<tr>
<th>Hex Value</th>
<th rowspan="1" colspan="3">Binary Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
<tr>
<th></th>
<th>act</th>
<th>chg</th>
<th>rest</th>
<th></th>
<th></th>
</tr>
</thead>
<tbody>
<tr>
<td>0x12</td>
<td>00</td>
<td>0</td>
<td>10010</td>
<td>AltMark</td>
<td>RFC 9343</td>
</tr>
</tbody>
</table>
</section>
</middle> </middle>
<!-- *****BACK MATTER ***** -->
<back> <back>
<!-- References split to informative and normative -->
<references title="Normative References">
<?rfc include='reference.RFC.2119'?> <displayreference target="I-D.ietf-pce-pcep-ifit" to="PCEP-IFIT"/>
<displayreference target="I-D.fz-spring-srv6-alt-mark" to="SRv6-AMM"/>
<displayreference target="I-D.ietf-6man-hbh-processing" to="HBH-OPTIONS-PROCES
SING"/>
<displayreference target="I-D.ietf-idr-sr-policy-ifit" to="BGP-SR-POLICY-IFIT"
/>
<displayreference target="I-D.ietf-v6ops-hbh" to="PROC-HBH-OPT-HEADER"/>
<?rfc include='reference.RFC.8174'?> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
200.xml"/>
<?rfc include='reference.RFC.8200'?> <!-- draft-ietf-ippm-rfc8321bis-03: In AUTH48-DONE; Cluster 446 document.
-->
<reference anchor="RFC9341" target="https://www.rfc-editor.org/info/rfc9341">
<front>
<title>Alternate-Marking Method</title>
<author initials='G' surname='Fioccola' fullname='Giuseppe Fioccola' role="edito
r">
<organization/>
</author>
<?rfc include='reference.I-D.ietf-ippm-rfc8321bis'?> <author initials='M' surname='Cociglio' fullname='Mauro Cociglio'>
<organization/>
</author>
<?rfc include='reference.I-D.ietf-ippm-rfc8889bis'?> <author initials='G' surname='Mirsky' fullname='Greg Mirsky'>
<organization/>
</author>
</references> <author initials='T' surname='Mizrahi' fullname='Tal Mizrahi'>
<organization/>
</author>
<references title="Informative References"> <author initials='T' surname='Zhou' fullname='Tianran Zhou'>
<!-- A reference written by by an organization not a persoN. --> <organization/>
</author>
<?rfc include='reference.RFC.7045'?> <date month='December' year='2022'/>
</front>
<seriesInfo name="RFC" value="9341"/>
<seriesInfo name="DOI" value="10.17487/RFC9341"/>
</reference>
<?rfc include='reference.RFC.8754'?> <!-- draft-ietf-ippm-rfc8889bis-04: in AUTH48-DONE; Cluster 446 document
-->
<reference anchor="RFC9342" target="https://www.rfc-editor.org/info/rfc9342">
<front>
<title>Clustered Alternate-Marking Method</title>
<?rfc include='reference.RFC.6437'?> <author initials='G' surname='Fioccola' fullname='Giuseppe Fioccola' role="edito
r">
<organization/>
</author>
<?rfc include='reference.RFC.6438'?> <author initials='M' surname='Cociglio' fullname='Mauro Cociglio'>
<organization/>
</author>
<?rfc include='reference.RFC.7384'?> <author initials='A' surname='Sapio' fullname='Amedeo Sapio'>
<organization/>
</author>
<?rfc include='reference.RFC.8915'?> <author initials='R' surname='Sisto' fullname='Riccardo Sisto'>
<organization/>
</author>
<?rfc include='reference.RFC.8799'?> <author initials='T' surname='Zhou' fullname='Tianran Zhou'>
<organization/>
</author>
<date month='December' year='2022'/>
</front>
<seriesInfo name="RFC" value="9342"/>
<seriesInfo name="DOI" value="10.17487/RFC9342"/>
</reference>
<?rfc include='reference.RFC.4301'?> </references>
<references>
<name>Informative References</name>
<?rfc include='reference.I-D.fz-spring-srv6-alt-mark'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7045.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8754.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6437.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6438.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7384.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8915.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8799.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.4301.xml"/>
<?rfc include='reference.I-D.ietf-idr-sr-policy-ifit'?> <!--draft-fz-spring-srv6-alt-mark; I-D exists as of 12/14/22-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-fz-sprin
g-srv6-alt-mark.xml"/>
<?rfc include='reference.I-D.chen-pce-pcep-ifit'?> <!--draft-ietf-idr-sr-policy-ifit; I-D exists as of 12/14/22 -->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-id
r-sr-policy-ifit.xml"/>
<?rfc include='reference.I-D.ietf-v6ops-hbh'?> <!--draft-chen-pce-pcep-ifit; Expired. Replaced by draft-ietf-pce-pcep-if
it; I-D exists as of 12/14/22-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-pc
e-pcep-ifit.xml"/>
<?rfc include='reference.I-D.ietf-6man-hbh-processing'?> <!--draft-ietf-v6ops-hbh; I-D exists as of 12/14/22-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-v6
ops-hbh.xml"/>
<!--draft-ietf-6man-hbh-processing; I-D exists as of 12/14/22-->
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-6m
an-hbh-processing.xml"/>
</references>
</references> </references>
</back> <section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Bob Hinden"/>, <cont
act fullname="Ole Troan"/>, <contact fullname="Martin Duke"/>, <contact fullname
="Lars Eggert"/>, <contact fullname="Roman Danyliw"/>,
<contact fullname="Alvaro Retana"/>, <contact fullname="Eric Vync
ke"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Benjamin Kaduk"/>
, <contact fullname="Stewart Bryant"/>, <contact fullname="C. A. Wood"/>,
<contact fullname="Yoshifumi Nishida"/>, <contact fullname="Tom H
erbert"/>, <contact fullname="Stefano Previdi"/>, <contact fullname="Brian Carpe
nter"/>, <contact fullname="Greg Mirsky"/>, and <contact fullname="Ron Bonica"/>
for their valuable comments and suggestions.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 192 change blocks. 
1028 lines changed or deleted 911 lines changed or added

This html diff was produced by rfcdiff 1.48.