rfc8889xml2.original.xml | rfc8889.xml | |||
---|---|---|---|---|
<?xml version="1.0" encoding="UTF-8"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ | ||||
<!-- A set of on-line citation libraries are maintained on the xml2rfc web site. | ||||
The next line defines an entity named RFC2629, which contains the necessary | ||||
XML | ||||
for the reference element, and is used much later in the file. This XML co | ||||
ntains an | ||||
anchor (also RFC2629) which can be used to cross-reference this item in the | ||||
text. | ||||
You can also use local file names instead of a URI. The environment variab | ||||
le | ||||
XML_LIBRARY provides a search path of directories to look at to locate a | ||||
relative path name for the file. There has to be one entity for each item t | ||||
o be | ||||
referenced. --> | ||||
<!ENTITY RFC2234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC | ||||
.2234.xml"> | ||||
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC | ||||
.2629.xml"> | ||||
<!ENTITY RFC4234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC | ||||
.4234.xml"> | ||||
<!ENTITY RFC5575 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC | ||||
.5575.xml"> | ||||
<!-- There is also a library of current Internet Draft citations. It isn't a go | ||||
od idea to | ||||
actually use one for the template because it might have disappeared when yo | ||||
u come to test | ||||
this template. This is the form of the entity definition | ||||
<!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 " "> | ||||
]> | ||||
<!-- Extra statement used by XSLT processors to control the output style. --> | ||||
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> | ||||
<!-- Processing Instructions can be placed here but if you are editing | ||||
with XMLmind (and maybe other XML editors) they are better placed | ||||
after the rfc element start tag as shown below. --> | ||||
<!-- Information about the document. | <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> | |||
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="exp" | ||||
ipr="trust200902" | ||||
docName="draft-ietf-ippm-multipoint-alt-mark-09" > | ||||
<!-- 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 ***** --> | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" | |||
docName="draft-ietf-ippm-multipoint-alt-mark-09" number="8889" | ||||
obsoletes="" updates="" submissionType="IETF" category="exp" | ||||
consensus="true" xml:lang="en" tocInclude="true" tocDepth="3" | ||||
symRefs="true" sortRefs="true" version="3"> | ||||
<front> | <front> | |||
<!-- The abbreviated title is used in the page header - it is only necessary | <title abbrev="Multipoint AM">Multipoint Alternate-Marking Method for | |||
if the | Passive and Hybrid Performance Monitoring</title> | |||
full title is longer than 42 characters --> | <seriesInfo name="RFC" value="8889"/> | |||
<title abbrev="Multipoint AM">Multipoint Alternate Marking method for passiv | <author role="editor" fullname="Giuseppe Fioccola" initials="G." surname= | |||
e and hybrid performance monitoring</title> | "Fioccola"> | |||
<!-- add 'role="editor"' below for the editors if appropriate --> | ||||
<author | ||||
role="editor" | ||||
fullname="Giuseppe Fioccola" | ||||
initials="G." | ||||
surname="Fioccola"> | ||||
<!-- abbrev not needed but can be used for the header | ||||
if the full organization name is too long --> | ||||
<organization>Huawei Technologies</organization> | <organization>Huawei Technologies</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>Riesstrasse, 25</street> | <street>Riesstrasse, 25</street> | |||
<city>Munich</city> | <city>Munich</city> | |||
<code>80992</code> | <code>80992</code> | |||
<country>Germany</country> | <country>Germany</country> | |||
</postal> | </postal> | |||
<email>giuseppe.fioccola@huawei.com</email> | <email>giuseppe.fioccola@huawei.com</email> | |||
<!-- | ||||
If I had a phone, fax machine, and a URI, I could add the following: | ||||
<phone>+1-408-555-1234</phone> | ||||
<facsimile>+1-555-911-9111</facsimile> | ||||
<uri>http://www.example.com/</uri> | ||||
--> | ||||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Mauro Cociglio" initials="M." surname="Cociglio"> | ||||
<author | ||||
fullname="Mauro Cociglio" | ||||
initials="M." | ||||
surname="Cociglio"> | ||||
<!-- abbrev not needed but can be used for the header | ||||
if the full organization name is too long --> | ||||
<organization>Telecom Italia</organization> | <organization>Telecom Italia</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>Via Reiss Romoli, 274</street> | <street>Via Reiss Romoli, 274</street> | |||
<city>Torino</city> | <city>Torino</city> | |||
<code>10148</code> | <code>10148</code> | |||
<country>Italy</country> | <country>Italy</country> | |||
</postal> | </postal> | |||
<email>mauro.cociglio@telecomitalia.it</email> | <email>mauro.cociglio@telecomitalia.it</email> | |||
<!-- | ||||
If I had a phone, fax machine, and a URI, I could add the following: | ||||
<phone>+1-408-555-1234</phone> | ||||
<facsimile>+1-555-911-9111</facsimile> | ||||
<uri>http://www.example.com/</uri> | ||||
--> | ||||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Amedeo Sapio" initials="A." surname="Sapio"> | ||||
<author | <organization>Intel Corporation</organization> | |||
fullname="Amedeo Sapio" | <address> | |||
initials="A." | <postal> | |||
surname="Sapio"> | <street>4750 Patrick Henry Dr.</street> | |||
<!-- abbrev not needed but can be used for the header | <city>Santa Clara</city> | |||
if the full organization name is too long --> | <region>CA</region> | |||
<organization>Politecnico di Torino</organization> | <code>95054</code> | |||
<address> | <country>USA</country> | |||
<postal> | </postal> | |||
<street>Corso Duca degli Abruzzi, 24</street> | <email>amedeo.sapio@intel.com</email> | |||
<city>Torino</city> | ||||
<code>10129</code> | ||||
<country>Italy</country> | ||||
</postal> | ||||
<email>amedeo.sapio@polito.it</email> | ||||
<!-- | ||||
If I had a phone, fax machine, and a URI, I could add the following: | ||||
<phone>+1-408-555-1234</phone> | ||||
<facsimile>+1-555-911-9111</facsimile> | ||||
<uri>http://www.example.com/</uri> | ||||
--> | ||||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Riccardo Sisto" initials="R." surname="Sisto"> | ||||
<author | ||||
fullname="Riccardo Sisto" | ||||
initials="R." | ||||
surname="Sisto"> | ||||
<!-- abbrev not needed but can be used for the header | ||||
if the full organization name is too long --> | ||||
<organization>Politecnico di Torino</organization> | <organization>Politecnico di Torino</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>Corso Duca degli Abruzzi, 24</street> | <street>Corso Duca degli Abruzzi, 24</street> | |||
<city>Torino</city> | <city>Torino</city> | |||
<code>10129</code> | <code>10129</code> | |||
<country>Italy</country> | <country>Italy</country> | |||
</postal> | </postal> | |||
<email>riccardo.sisto@polito.it</email> | <email>riccardo.sisto@polito.it</email> | |||
<!-- | ||||
If I had a phone, fax machine, and a URI, I could add the following: | ||||
<phone>+1-408-555-1234</phone> | ||||
<facsimile>+1-555-911-9111</facsimile> | ||||
<uri>http://www.example.com/</uri> | ||||
--> | ||||
</address> | </address> | |||
</author> | </author> | |||
<date year="2020" month="August" /> | ||||
<date year="2020"/> <!-- month="March" is no longer necessary | <area/> | |||
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 & as an escape for & which would otherwise | ||||
start an entity declaration, whereas we want a literal &. --> | ||||
<area></area> | ||||
<!-- WG name at the upperleft corner of the doc, | ||||
IETF fine for individual submissions. You can also | ||||
omit this element in which case in defaults to "Network Working Group" | ||||
- | ||||
a hangover from the ancient history of the IETF! --> | ||||
<workgroup>IPPM Working Group</workgroup> | <workgroup>IPPM Working Group</workgroup> | |||
<!-- The DTD allows multiple area and workgroup elements but only the first | ||||
one has any | ||||
effect on output. --> | ||||
<!-- You can add <keyword/> elements here. They will be incorporated into H | ||||
TML output | ||||
files in a meta tag but they have no effect on text or nroff output. -- | ||||
> | ||||
<abstract> | <abstract> | |||
<t>The Alternate Marking method, as presented in RFC 8321, | <t>The Alternate-Marking method, as presented in RFC 8321, | |||
can be applied only to point-to-point flows because it assumes th | can only be applied to point-to-point flows, because it assumes t | |||
at all the packets | hat all the packets | |||
of the flow measured on one node are measured again by a single s econd node. | of the flow measured on one node are measured again by a single s econd node. | |||
This document generalizes and expands this methodology to measure any kind of | This document generalizes and expands this methodology to measure any kind of | |||
unicast flows, whose packets can follow several different paths i | unicast flow whose packets can follow several different paths in | |||
n the | the | |||
network, in wider terms a multipoint-to-multipoint network. For | network -- in wider terms, a multipoint-to-multipoint network. F | |||
this reason | or this reason, | |||
the technique here described is called Multipoint Alternate Marki | the technique here described is called "Multipoint Alternate Mark | |||
ng.</t> | ing".</t> | |||
</abstract> | </abstract> | |||
</front> | ||||
<middle> | ||||
<section numbered="true" toc="default"> | ||||
<name>Introduction</name> | ||||
<t>The Alternate-Marking method, as described in <xref target="RFC8321" fo | ||||
rmat="default">RFC 8321</xref>, is applicable to a point-to-point path. | ||||
The extension proposed in this document applies to the most general case o | ||||
f multipoint-to-multipoint path | ||||
and enables flexible and adaptive performance measurements in a managed ne | ||||
twork.</t> | ||||
<t>The Alternate-Marking methodology described in <xref target="RFC8321" f | ||||
ormat="default">RFC 8321</xref> | ||||
allows the synchronization of the measurements in different points by divi | ||||
ding the packet flow | ||||
into batches. So it is possible to get coherent counters and show what is | ||||
happening in every | ||||
marking period for each monitored flow. The monitoring parameters are the | ||||
packet counter and timestamps | ||||
of a flow for each marking period. Note that additional details about the | ||||
applicability of the | ||||
Alternate-Marking methodology are described in <xref | ||||
target="RFC8321" format="default">RFC 8321</xref> while implementation det | ||||
ails can be found in the | ||||
paper "AM-PM: Efficient Network Telemetry using Alternate Marking" <xref | ||||
target="IEEE-Network-PNPM" format="default"/>.</t> | ||||
<t>There are some applications of the Alternate-Marking method where there | ||||
are a lot of | ||||
monitored flows and nodes. Multipoint Alternate Marking aims to reduce the | ||||
se values and | ||||
makes the performance monitoring more flexible in case a detailed analysis | ||||
is not needed. | ||||
For instance, by considering n measurement points and m monitored flows, | ||||
the order of magnitude | ||||
of the packet counters for each time interval is n*m*2 (1 per color). The | ||||
number of | ||||
measurement points and monitored flows may vary and depends on the portion | ||||
of the network | ||||
we are monitoring (core network, metro network, access network) and the gr | ||||
anularity | ||||
(for each service, each customer). So if both n and m are high values, the | ||||
packet counters | ||||
increase a lot, and Multipoint Alternate Marking offers a tool to control | ||||
these parameters.</t> | ||||
<t>The approach presented in this document is applied only to unicast flow | ||||
s and not to multicast. | ||||
Broadcast, Unknown Unicast, and Multicast (BUM) traffic is not | ||||
considered here, because traffic replication | ||||
is not covered by the Multipoint Alternate-Marking method. Furthermore, | ||||
it can be applicable to anycast flows, and Equal-Cost Multipath (ECMP) | ||||
paths can also be easily monitored with this technique.</t> | ||||
<t>In short, <xref target="RFC8321" format="default">RFC 8321</xref> | ||||
applies to point-to-point unicast flows and BUM traffic, while this | ||||
document and its Clustered Alternate-Marking method is valid for | ||||
multipoint-to-multipoint | ||||
unicast flows, anycast, and ECMP flows.</t> | ||||
<t>Therefore,the Alternate-Marking method can be extended to any kind of | ||||
multipoint-to-multipoint paths, | ||||
and the network-clustering approach presented in this document is the form | ||||
alization of how to | ||||
implement this property and allow a flexible and optimized performance mea | ||||
surement support | ||||
for network management in every situation.</t> | ||||
<t>Without network clustering, it is possible to apply Alternate Marking o | ||||
nly for all | ||||
the network or per single flow. Instead, with network clustering, it is po | ||||
ssible to use the partition | ||||
of the network into clusters at different levels in order to perform the n | ||||
eeded degree of detail. | ||||
In some circumstances, it is possible to monitor a multipoint network by a | ||||
nalyzing the network clustering, | ||||
without examining in depth. In case of problems (packet loss is measured o | ||||
r the delay is too high), | ||||
the filtering criteria could be specified more in order to perform a detai | ||||
led analysis by using a | ||||
different combination of clusters up to a per-flow measurement as describe | ||||
d in <xref target="RFC8321" format="default">RFC 8321</xref>.</t> | ||||
<t>This approach fits very well with the Closed-Loop Network and Software- | ||||
Defined Network (SDN) paradigm, | ||||
where the SDN orchestrator and the SDN controllers are the brains of the n | ||||
etwork and can manage flow control | ||||
to the switches and routers and, in the same way, can calibrate the perfor | ||||
mance measurements | ||||
depending on the desired accuracy. An SDN controller application can orche | ||||
strate how accurately the network | ||||
performance monitoring is set up by applying the Multipoint Alternate Mark | ||||
ing as described in this document.</t> | ||||
<t>It is important to underline that, as an extension of <xref target="RFC | ||||
8321" format="default">RFC 8321</xref>, this is a methodology document, | ||||
so the mechanism that can be used to transmit the counters and the timesta | ||||
mps is out of scope here, and the implementation | ||||
is open. Several options are possible -- e.g., see "Enhanced Alternate Mar | ||||
king Method" <xref target="I-D.zhou-ippm-enhanced-alternate-marking" format="def | ||||
ault"/>.</t> | ||||
</front> | <t> | |||
Note that the fragmented packets case can be managed with the | ||||
<middle> | Alternate-Marking methodology only if fragmentation happens outside | |||
<section title="Introduction"> | the portion of the network that is monitored. This is always true for both <xref | |||
<t>The Alternate Marking method, as described in <xref target="RFC8321"> | target="RFC8321" format="default">RFC 8321</xref> and Multipoint Alternate Mark | |||
RFC 8321</xref>, is applicable to a point-to-point path. | ing, as explained here. | |||
The extension proposed in this document applies to the most gener | </t> | |||
al case of multipoint-to-multipoint path | ||||
and enables flexible and adaptive performance measurements in a m | ||||
anaged network.</t> | ||||
<t>The Alternate Marking methodology described in <xref target="R | ||||
FC8321">RFC 8321</xref> | ||||
allows the synchronization of the measurements in different point | ||||
s by dividing the packet flow | ||||
into batches. So it is possible to get coherent counters and show | ||||
what is happening in every | ||||
marking period for each monitored flow. The monitoring parameters | ||||
are the packet counter and timestamps | ||||
of a flow for each marking period. Note that additional details a | ||||
bout the applicability of the | ||||
Alternate Marking methodology are described both in <xref target= | ||||
"RFC8321">RFC 8321</xref> and | ||||
in the paper <xref target="IEEE-Network-PNPM"/>.</t> | ||||
<t>There are some applications of the Alternate Marking method wh | ||||
ere there are a lot of | ||||
monitored flows and nodes. Multipoint Alternate Marking aims to r | ||||
educe these values and | ||||
makes the performance monitoring more flexible in case a detailed | ||||
analysis is not needed. | ||||
For instance, by considering n measurement points and m monitored | ||||
flows,the order of magnitude | ||||
of the packet counters for each time interval is n*m*2 (1 per col | ||||
or). The number of | ||||
measurement points and monitored flows may vary and depends on th | ||||
e portion of the network | ||||
we are monitoring (core network, metro network, access network) a | ||||
nd on the granularity | ||||
(for each service, each customer). So if both n and m are high va | ||||
lues the packet counters | ||||
increase a lot and Multipoint Alternate Marking offers a tool to | ||||
control these parameters.</t> | ||||
<t>The approach presented in this document is applied only to uni | ||||
cast flows and not to multicast. | ||||
Broadcast, Unknown-unicast, and Multicast (BUM) traffic is not co | ||||
nsidered here, because traffic replication | ||||
is not covered by the Multipoint Alternate Marking method. Furthe | ||||
rmore it can be applicable to anycast | ||||
flows and Equal-Cost MultiPath (ECMP) paths can also be easily mo | ||||
nitored with this technique.</t> | ||||
<t>In short, <xref target="RFC8321">RFC 8321</xref> applies to po | ||||
int-to-point unicast flows and BUM | ||||
traffic while this document and its Clustered Alternate Marking m | ||||
ethod is valid for multipoint-to-multipoint | ||||
unicast flows, anycast and ECMP flows.</t> | ||||
<t>The Alternate Marking method can therefore be extended to any | ||||
kind of multipoint to multipoint paths, | ||||
and the network clustering approach presented in this document is | ||||
the formalization of how to | ||||
implement this property and allow a flexible and optimized perfor | ||||
mance measurement support | ||||
for network management in every situation.</t> | ||||
<t>Without network clustering, it is possible to apply Alternate | ||||
Marking only for all | ||||
the network or per single flow. Instead, with network clustering, | ||||
it is possible to use the partition | ||||
of the network into clusters at different levels in order to perf | ||||
orm the needed degree of detail. | ||||
In some circumstances it is possible to monitor a Multipoint Netw | ||||
ork by analysing the Network Clustering, | ||||
without examining in depth. In case of problems (packet loss is m | ||||
easured or the delay is too high) | ||||
the filtering criteria could be specified more in order to perfor | ||||
m a detailed analysis by using a | ||||
different combination of clusters up to a per-flow measurement as | ||||
described in <xref target="RFC8321">RFC 8321</xref>.</t> | ||||
<t>This approach fits very well with the Closed Loop Network and | ||||
Software Defined Network (SDN) paradigm | ||||
where the SDN Orchestrator and the SDN Controllers are the brains | ||||
of the network and can manage flow control | ||||
to the switches and routers and, in the same way, can calibrate t | ||||
he performance measurements | ||||
depending on the desired accuracy. An SDN Controller Application | ||||
can orchestrate how accurate the network | ||||
performance monitoring is setup by applying the Multipoint Altern | ||||
ate Marking as described in this document.</t> | ||||
<t>It is important to underline that, as extension of <xref targe | ||||
t="RFC8321">RFC 8321</xref>, this is a methodology draft, | ||||
so the mechanism that can be used to transmit the counters and th | ||||
e timestamps is out of scope here and the implementation | ||||
is open. Several options are possible, e.g. <xref target="I-D.zho | ||||
u-ippm-enhanced-alternate-marking"/>.</t> | ||||
<t>Note that, as for <xref target="RFC8321">RFC 8321</xref>, the | ||||
fragmented packets case can be managed with this methodology | ||||
if fragmentation happens outside the portion of the monitored net | ||||
work.</t> | ||||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<name>Terminology</name> | ||||
<t>The definitions of the basic terms are identical to those found in | ||||
Alternate Marking <xref target="RFC8321" format="default"/>. | ||||
It is to be remembered that <xref target="RFC8321" format="default">RFC 8 | ||||
321</xref> is valid for point-to-point unicast flows and BUM traffic.</t> | ||||
<t>The important new terms that need to be explained are listed below:</t> | ||||
<section title="Terminology"> | <dl> | |||
<dt>Multipoint Alternate Marking:</dt><dd>Extension to <xref target="RFC8321" | ||||
<t>The definitions of the basic terms are identical to those found in Alt | format="default">RFC 8321</xref>, valid for multipoint-to-multipoint | |||
ernate Marking (<xref target="RFC8321">RFC 8321</xref>). | unicast flows, anycast, and ECMP flows. It can also be referred to as Clustere | |||
It is to be remembered that <xref target="RFC8321">RFC 8321</xref> is val | d | |||
id for point-to-point unicast flows and BUM traffic.</t> | Alternate Marking.</dd> | |||
<dt>Flow definition:</dt><dd>The concept of flow is generalized in this | ||||
<t>The important new terms that need to be explained are listed below:<li | document. The identification fields are selected without any constraints | |||
st> | and, in general, the flow can be a multipoint-to-multipoint flow, as a | |||
result of aggregate point-to-point flows.</dd> | ||||
<t>Multipoint Alternate Marking: Extension to <xref target="RFC8321">RFC | <dt>Monitoring network:</dt><dd>Identified with the nodes of the | |||
8321</xref>, valid for multipoint-to-multipoint | network that are the measurement points (MPs) and | |||
unicast flows, anycast and ECMP flows. It can also be referred as Cluster | the links that are the connections between MPs. The monitoring network graph | |||
ed Alternate Marking;</t> | depends on the flow definition, so it can represent a specific flow or the | |||
entire network topology as aggregate of all the flows.</dd> | ||||
<t>Flow definition: The concept of flow is generalized in this document. | <dt>Cluster:</dt><dd>Smallest identifiable subnetwork of the entire | |||
The identification fields are selected without any constraints | monitoring network graph that still satisfies the condition that the number | |||
and, in general, the flow can be a multipoint-to-multipoint flow, as a re | of packets that go in is the same as the number that go out.</dd> | |||
sult of aggregate point-to-point flows;</t> | <dt>Multipoint metrics:</dt><dd>Packet loss, delay, and delay variation are | |||
extended to the case of multipoint flows. | ||||
<t>Monitoring Network: it is identified with the nodes of the network tha | It is possible to compute these metrics on the basis of multipoint paths in or | |||
t are the measurement points (MPs) and | der | |||
the links that are the connections between MPs. The Monitoring Network gr | to associate the measurements to a cluster, a combination of clusters, or | |||
aph depends on the flow definition, so it can | the entire monitored network. For delay and delay variation, | |||
represent a specific flow or the the entire network topology as aggregate | it is also possible to define the metrics on a single-packet basis, and it | |||
of all the flows;</t> | means that the multipoint path is used to easily couple packets between | |||
input and output nodes of a multipoint path.</dd> | ||||
<t>Cluster: smallest identifiable subnetwork of the entire Monitoring Net | </dl> | |||
work graph that still | ||||
satisfies the condition that the number of packets that goes in is the sa | ||||
me that goes out;</t> | ||||
<t>Multipoint metrics: packet loss, delay and delay variation are extende | ||||
d to the case of multipoint flows. | ||||
It is possible to compute these metrics on multipoint paths basis in orde | ||||
r to associate the measurements | ||||
to a cluster, to a combination of clusters or to the entire monitored net | ||||
work. For delay and delay variation, | ||||
it is also possible to define the metrics on a single packet basis and it | ||||
means that the multipoint path is used | ||||
to easily couple packets between input and output nodes of a multipoint p | ||||
ath.</t> | ||||
</list></t> | ||||
<t>The next section highlights the correlation with the terms used in <xr | ||||
ef target="RFC5644">RFC 5644</xref>.</t> | ||||
<section title="Correlation with RFC5644"> | ||||
<t><xref target="RFC5644">RFC 5644</xref> is limited to active measureme | ||||
nts | ||||
using a single source packet or stream, and observations of corresponding p | ||||
ackets along the | ||||
path (spatial), at one or more destinations (one-to-group), or both.</t> | ||||
<t>Instead, the scope of this memo is to define multiparty metrics for p | <t>The next section highlights the correlation with the terms used in | |||
assive and hybrid | <xref target="RFC5644" format="default">RFC 5644</xref>.</t> | |||
<section numbered="true" toc="default"> | ||||
<name>Correlation with RFC 5644</name> | ||||
<t><xref target="RFC5644" format="default">RFC 5644</xref> is limited to | ||||
active measurements | ||||
using a single source packet or stream. Its scope is also limited to observ | ||||
ations of corresponding packets along the | ||||
path (spatial metric) and at one or more destinations (one-to-group) along | ||||
the path.</t> | ||||
<t>Instead, the scope of this memo is to define multiparty metrics for p | ||||
assive and hybrid | ||||
measurements in a group-to-group topology with multiple sources and dest inations.</t> | measurements in a group-to-group topology with multiple sources and dest inations.</t> | |||
<t><xref target="RFC5644" format="default">RFC 5644</xref> introduces | ||||
<t><xref target="RFC5644">RFC 5644</xref> introduces metric names that c | metric names that can be reused here | |||
an be reused also here | but have to be extended and rephrased to be applied to the Alternate-Mar | |||
but have to be extended and rephrased to be applied to the Alternate Mar | king schema:</t> | |||
king schema:</t> | <ol spacing="normal" type="a"> | |||
<t><list style="letters"> | <li>the multiparty metrics are not only one-to-group metrics but can b | |||
<t>the multiparty metrics are not only one-to-group metrics but can be also | e also group-to-group | |||
group-to-group | metrics;</li> | |||
metrics;</t> | <li>the spatial metrics, used for measuring the performance of segment | |||
<t>the spatial metrics, used for measuring the performance of segments of a | s of a source to destination path, | |||
source to destination path, | are applied here to group-to-group segments (called clusters).</li> | |||
are applied here to group-to-group segments (called Clusters).</t> | </ol> | |||
</list></t> | </section> | |||
</section> | ||||
</section> | <section numbered="true" toc="default"> | |||
</section> | <name>Flow Classification</name> | |||
<t>A unicast flow is identified by all the packets having a set of common | ||||
<section title="Flow classification"> | characteristics. | |||
<t>An unicast flow is identified by all the packets having a set | This definition is inspired by <xref target="RFC7011" format="def | |||
of common characteristics. | ault">RFC 7011</xref>.</t> | |||
This definition is inspired by <xref target="RFC7011">RFC 7011</x | <t>As an example, by considering a flow as all the packets sharing the sam | |||
ref>.</t> | e | |||
<t>As an example, by considering a flow as all the packets sharin | ||||
g the same | ||||
source IP address or the same destination IP address, it is easy to understand | source IP address or the same destination IP address, it is easy to understand | |||
that the resulting pattern will not be a point-to-point connectio n, | that the resulting pattern will not be a point-to-point connectio n, | |||
but a point-to-multipoint or multipoint-to-point connection.</t> | but a point-to-multipoint or multipoint-to-point connection.</t> | |||
<t>In general, a flow can be defined by a set of selection rules used to m | ||||
<t>In general a flow can be defined by a set of selection rules u | atch | |||
sed to match | ||||
a subset of the packets processed by the network device. These ru les | a subset of the packets processed by the network device. These ru les | |||
specify a set of layer-3 and layer-4 headers fields (Identificati on Fields) | specify a set of Layer 3 and Layer 4 header fields (identificatio n fields) | |||
and the relative values that must be found in matching packets.</ t> | and the relative values that must be found in matching packets.</ t> | |||
<t>The choice of the identification fields directly affects the type of | ||||
<t>The choice of the identification fields directly affects the t | ||||
ype of | ||||
paths that the flow would follow in the network. In fact, it is | paths that the flow would follow in the network. In fact, it is | |||
possible to relate a set of identification fields with the patter n | possible to relate a set of identification fields with the patter n | |||
of the resulting graphs, as listed in Figure 1.</t> | of the resulting graphs, as listed in <xref target="Flows" />.</t | |||
> | ||||
<t>A TCP 5-tuple usually identifies flows following either a sing | <t>A TCP 5-tuple usually identifies flows following either a single path | |||
le path | or a point-to-point multipath (in the case of load balancing). On | |||
or a point-to-point multipath (in case of load balancing). On the | the contrary, | |||
contrary, | ||||
a single source address selects aggregate flows following a point -to-multipoint, | a single source address selects aggregate flows following a point -to-multipoint, | |||
while a multipoint-to-point can be the result of a matching on a single | while a multipoint-to-point can be the result of a matching on a single | |||
destination address. | destination address. | |||
In case a selection rule and its reverse are used for bidirection al measurements, | In the case where a selection rule and its reverse are used for b idirectional measurements, | |||
they can correspond to a point-to-multipoint in one direction | they can correspond to a point-to-multipoint in one direction | |||
and a multipoint-to-point in the opposite direction.</t> | and a multipoint-to-point in the opposite direction.</t> | |||
<t>So the flows to be monitored are selected into the monitoring points | ||||
<t>So the flows to be monitored are selected into the monitoring | using packet selection rules, which can also change the pattern o | |||
points | f the monitored | |||
using packet selection rules, that can also change the pattern of | ||||
the monitored | ||||
network.</t> | network.</t> | |||
<t>Note that, more in general, the flow can be defined at differe | <t>Note that, more generally, the flow can be defined at different levels | |||
nt levels based | based | |||
on the encapsulation considered and additional conditions that ar | on the potential encapsulation, and additional conditions that ar | |||
e not in the packet header | e not in the packet header | |||
can also be included as part of matching criteria.</t> | can also be included as part of matching criteria.</t> | |||
<t>The Alternate-Marking method is applicable only to a single path (and | ||||
<t>The Alternate Marking method is applicable only to a single pa | ||||
th (and | ||||
partially to a one-to-one multipath), so the extension proposed i n | partially to a one-to-one multipath), so the extension proposed i n | |||
this document is suitable also for the most general case of multi point-to-multipoint, | this document is suitable also for the most general case of multi point-to-multipoint, | |||
which embraces all the other patterns of Figure 1.</t> | which embraces all the other patterns of <xref target="Flows" />. | |||
</t> | ||||
<figure anchor="Flows" title="Flow classification"> | <figure anchor="Flows"> | |||
<artwork><![CDATA[ | <name>Flow Classification</name> | |||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
point-to-point single path | point-to-point single path | |||
+------+ +------+ +------+ | +------+ +------+ +------+ | |||
---<> R1 <>----<> R2 <>----<> R3 <>--- | ---<> R1 <>----<> R2 <>----<> R3 <>--- | |||
+------+ +------+ +------+ | +------+ +------+ +------+ | |||
point-to-point multipath | point-to-point multipath | |||
+------+ | +------+ | |||
<> R2 <> | <> R2 <> | |||
/ +------+ \ | / +------+ \ | |||
skipping to change at line 459 ¶ | skipping to change at line 302 ¶ | |||
+------+ \ | +------+ \ | |||
+------+ \ +------+ | +------+ \ +------+ | |||
---<> R2 <> <> R7 <>--- | ---<> R2 <> <> R7 <>--- | |||
+------+ \ / +------+ | +------+ \ / +------+ | |||
\ +------+ / | \ +------+ / | |||
<> R5 <> | <> R5 <> | |||
/ +------+ \ | / +------+ \ | |||
+------+ / \ +------+ | +------+ / \ +------+ | |||
---<> R3 <> <> R8 <>--- | ---<> R3 <> <> R8 <>--- | |||
+------+ +------+ | +------+ +------+ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t>The case of unicast flow is considered in <xref target="Flows"/>. The a | ||||
<t>The case of unicast flow is considered in the previous figure. | nycast flow | |||
Anyway the anycast flow | is also in scope, because there is no replication and only a single node | |||
is also in scope because there is no replication and only a singl | from the anycast group | |||
e node from the anycast group | receives the traffic, so it can be viewed as a special case of unicast flo | |||
receives the traffic, so it can be viewed as a special case of un | w. Furthermore, an | |||
icast flow. Furthermore, an | ECMP flow is in scope by definition, since it is a point-to-multipoint uni | |||
ECMP flow is in scope by definition, since it is a point-to-multi | cast flow.</t> | |||
point unicast flow.</t> | ||||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<section title="Multipoint Performance Measurement"> | <name>Multipoint Performance Measurement</name> | |||
<t>By Using the Alternate Marking method only point-to-point paths can b | <t>By using the Alternate-Marking method, only point-to-point paths can be | |||
e monitored. | monitored. | |||
To have an IP (TCP/UDP) flow that follows a point-to-point path we have t | To have an IP (TCP/UDP) flow that follows a point-to-point path, we have | |||
o define, | to define, | |||
with a specific value, 5 identification fields (IP Source, IP Destination , | with a specific value, 5 identification fields (IP Source, IP Destination , | |||
Transport Protocol, Source Port, Destination Port).</t> | Transport Protocol, Source Port, Destination Port).</t> | |||
<t>Multipoint Alternate Marking enables the performance measurement for mu | ||||
<t>Multipoint Alternate Marking enables the performance measurement for m | ltipoint flows | |||
ultipoint flows | ||||
selected by identification fields without any constraints (even the entir e network production traffic). | selected by identification fields without any constraints (even the entir e network production traffic). | |||
It is also possible to use multiple marking points for the same monitored flow.</t> | It is also possible to use multiple marking points for the same monitored flow.</t> | |||
<section numbered="true" toc="default"> | ||||
<section title="Monitoring Network"> | <name>Monitoring Network</name> | |||
<t>The Monitoring Network is deduced from the Production Network, by iden | <t>The monitoring network is deduced from the production network by iden | |||
tifying | tifying | |||
the nodes of the graph that are the measurement points, and the links tha t are the | the nodes of the graph that are the measurement points, and the links tha t are the | |||
connections between measurement points.</t> | connections between measurement points.</t> | |||
<t>There are some techniques that can help with the building of the moni | ||||
<t>There are some techniques that can help with the building of the monit | toring network (as an example, | |||
oring network (as an example | see <xref target="I-D.ietf-ippm-route" format="default"/>). In general, t | |||
it is possible to mention <xref target="I-D.ietf-ippm-route"/>). In gener | here are different options: | |||
al there are different options: | the monitoring network can be obtained by considering all the possible | |||
the monitoring network can be obtained by considering all the possible paths | paths for the traffic or periodically checking the traffic (e.g. daily, | |||
for the traffic or also | weekly, monthly) and updating the graph as appropriate, | |||
by periodically checking the traffic (e.g. daily, weekly, monthly) and updat | ||||
e the graph as appropriate, | ||||
but this is up to the Network Management System (NMS) configuration.</t> | but this is up to the Network Management System (NMS) configuration.</t> | |||
<t>So a graph model of the monitoring network can be built according to | ||||
<t>So a graph model of the monitoring network can be built according to t | the Alternate-Marking | |||
he Alternate Marking | ||||
method: the monitored interfaces and links are identified. Only the measu rement points and links | method: the monitored interfaces and links are identified. Only the measu rement points and links | |||
where the traffic has flowed have to be represented in the graph.</t> | where the traffic has flowed have to be represented in the graph.</t> | |||
<t><xref target="monitored-graph"/> shows a simple example of a | ||||
<t>The following figure shows a simple example of a Monitoring Network gr | monitoring network graph:</t> | |||
aph:</t> | <figure anchor="monitored-graph"> | |||
<name>Monitoring Network Graph</name> | ||||
<figure anchor="monitored-graph" title="Monitoring Network Graph"> | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
<artwork><![CDATA[ | ||||
+------+ | +------+ | |||
<> R6 <>--- | <> R6 <>--- | |||
/ +------+ | / +------+ | |||
+------+ +------+ / | +------+ +------+ / | |||
<> R2 <>---<> R4 <> | <> R2 <>---<> R4 <> | |||
/ +------+ \ +------+ \ | / +------+ \ +------+ \ | |||
/ \ \ +------+ | / \ \ +------+ | |||
+------+ / +------+ \ +------+ <> R7 <>--- | +------+ / +------+ \ +------+ <> R7 <>--- | |||
---<> R1 <>---<> R3 <>---<> R5 <> +------+ | ---<> R1 <>---<> R3 <>---<> R5 <> +------+ | |||
+------+ \ +------+ \ +------+ \ | +------+ \ +------+ \ +------+ \ | |||
skipping to change at line 521 ¶ | skipping to change at line 359 ¶ | |||
\ \ <> R8 <>--- | \ \ <> R8 <>--- | |||
\ \ +------+ | \ \ +------+ | |||
\ \ | \ \ | |||
\ \ +------+ | \ \ +------+ | |||
\ <> R9 <>--- | \ <> R9 <>--- | |||
\ +------+ | \ +------+ | |||
\ | \ | |||
\ +------+ | \ +------+ | |||
<> R10 <>--- | <> R10 <>--- | |||
+------+ | +------+ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t>Each monitoring point is characterized by the packet counter | ||||
<t>Each monitoring point is characterized by the packet counter | ||||
that refers only to a marking period of the monitored flow.</t> | that refers only to a marking period of the monitored flow.</t> | |||
<t>The same is also applicable for the delay, but it will be described | ||||
<t>The same is applicable also for the delay but it will be described | ||||
in the following sections.</t> | in the following sections.</t> | |||
</section> | ||||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
</section> | <name>Multipoint Packet Loss</name> | |||
<t>Since all the packets of the considered flow leaving the | ||||
<section title="Multipoint Packet Loss"> | ||||
<t>Since all the packets of the considered flow leaving the | ||||
network have previously entered the network, the number of | network have previously entered the network, the number of | |||
packets counted by all the input nodes is always greater | packets counted by all the input nodes is always greater than, | |||
or equal than the number of packets counted by all the | or equal to, the number of packets counted by all the | |||
output nodes. Non-initial fragments are not considered here.</t> | output nodes. Noninitial fragments are not considered here.</t> | |||
<t>The assumption is the use of the Alternate-Marking method. In the case | ||||
<t>The assumption is the use of the Alternate Marking method. And | of | |||
in case of no packet loss occurring in the marking period, if all | no packet loss occurring in the marking period, if all | |||
the input and output points of the network domain to be monitored are | the input and output points of the network domain to be monitored are | |||
measurement points, the sum of the number of packets on all the | measurement points, the sum of the number of packets on all the | |||
ingress interfaces equals the number on egress interfaces for the | ingress interfaces equals the number on egress interfaces for the | |||
monitored flow. In this circumstance, if no packet loss occurs, | monitored flow. In this circumstance, if no packet loss occurs, | |||
the intermediate measurement points have only the task to split | the intermediate measurement points only have the task of splitting | |||
the measurement.</t> | the measurement.</t> | |||
<t>It is possible to define the Network Packet Loss of one monitored flow | ||||
<t>It is possible to define the Network Packet Loss of one monitored flow | for a single period. In a packet network, the number of lost packets is t | |||
for a single period: «In a packet network, the number of lost packets is | he | |||
the | ||||
number of packets counted by the input nodes minus the number of packets | number of packets counted by the input nodes minus the number of packets | |||
counted by the output nodes». This is true for every packet flow | counted by the output nodes. This is true for every packet flow | |||
in each marking period.</t> | in each marking period.</t> | |||
<t>The monitored network packet loss with n input nodes and m output nodes | ||||
<t>The Monitored Network Packet Loss with n input nodes and m output node | ||||
s | ||||
is given by:</t> | is given by:</t> | |||
<t>PL = (PI1 + PI2 +...+ PIn) - (PO1 + PO2 +...+ POm)</t> | ||||
<t>PL = (PI1 + PI2 +...+ PIn) - (PO1 + PO2 +...+ POm)</t> | <t>where:</t> | |||
<t>PL is the network packet loss (number of lost packets)</t> | ||||
<t>where:</t> | <t>PIi is the number of packets flowed through the i-th input node in this | |||
<t>PL is the Network Packet Loss (number of lost packets)</t> | period</t> | |||
<t>PIi is the Number of packets flowed through the i-th Input node in thi | <t>POj is the number of packets flowed through the j-th output node in | |||
s period</t> | this period</t> | |||
<t>POj is the Number of packets flowed through the j-th Output node in th | <t>The equation is applied on a per-time-interval basis and a per-flow bas | |||
is period</t> | is:</t> | |||
<ul empty="true" spacing="normal"> | ||||
<t>The equation is applied on a per-time-interval basis and on an per-flow b | <li>The reference interval is the Alternate-Marking period, as defined | |||
asis:<list> | in <xref target="RFC8321" format="default">RFC 8321</xref>.</li> | |||
<li>The flow definition is generalized here. Indeed, as described before | ||||
<t>The reference interval is the Alternate Marking period as defined in < | , a multipoint packet flow | |||
xref target="RFC8321">RFC 8321</xref>.</t> | is considered, and the identification fields can be selected without any | |||
constraints.</li> | ||||
<t>The flow definition is generalized here, indeed, as described before, | </ul> | |||
a multipoint packet flow | ||||
is considered and the identification fields can be selected without any c | ||||
onstraints.</t> | ||||
</list></t> | ||||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<section title="Network Clustering"> | <name>Network Clustering</name> | |||
<t>The previous Equation can determine the number of packets lost | <t>The previous equation can determine the number of packets lost | |||
globally in the monitored network, exploiting only the data provided | globally in the monitored network, exploiting only the data provided | |||
by the counters in the input and output nodes.</t> | by the counters in the input and output nodes.</t> | |||
<t>In addition, it is also possible to leverage the data provided by the o | ||||
<t>In addition it is also possible to leverage the data provided by the o | ther counters | |||
ther counters | ||||
in the network to converge on the smallest identifiable subnetworks where the losses occur. | in the network to converge on the smallest identifiable subnetworks where the losses occur. | |||
These subnetworks are named Clusters.</t> | These subnetworks are named "clusters".</t> | |||
<t>A cluster graph is a subnetwork of the entire monitoring network graph | ||||
<t>A Cluster graph is a subnetwork of the entire Monitoring Network graph | that still | |||
that still | satisfies the packet loss equation (introduced in the previous section), | |||
satisfies the packet loss equation (introduced in the previous section) w | where PL in this case | |||
here PL in this case | is the number of packets lost in the cluster. As for the entire monitorin | |||
is the number of packets lost in the Cluster. As for the entire Monitorin | g network graph, the cluster | |||
g Network graph, the Cluster | ||||
is defined on a per-flow basis.</t> | is defined on a per-flow basis.</t> | |||
<t>For this reason, a cluster should contain all the arcs emanating from i | ||||
<t>For this reason a Cluster should contain all the arcs emanating from i | ts input nodes | |||
ts input nodes | ||||
and all the arcs terminating at its output nodes. This ensures that we ca n | and all the arcs terminating at its output nodes. This ensures that we ca n | |||
count all the packets (and only those) exiting an input node | count all the packets (and only those) exiting an input node | |||
again at the output node, whatever path they follow.</t> | again at the output node, whatever path they follow.</t> | |||
<t>In a completely monitored unidirectional network (a network where every | ||||
<t>In a completely monitored unidirectional network (a network where ever | ||||
y | ||||
network interface is monitored), each network device corresponds | network interface is monitored), each network device corresponds | |||
to a Cluster and each physical link corresponds to two | to a cluster, and each physical link corresponds to two | |||
Clusters (one for each device).</t> | clusters (one for each device).</t> | |||
<t>Clusters can have different sizes depending on the flow-filtering crite | ||||
<t>Clusters can have different sizes depending on flow filtering criteria | ria adopted.</t> | |||
adopted.</t> | <t>Moreover, sometimes clusters can be optionally simplified. For example, | |||
when two monitored interfaces | ||||
<t>Moreover, sometimes Clusters can be optionally simplified. For example | are divided by a single router (one is the input interface, the other is | |||
when two monitored interfaces | the output interface, | |||
are divided by a single router (one is the input interface and the other | ||||
is the output interface | ||||
and the router has only these two interfaces), instead of counting exactl y twice, upon entering and leaving, | and the router has only these two interfaces), instead of counting exactl y twice, upon entering and leaving, | |||
it is possible to consider a single measurement point (in this case we do | it is possible to consider a single measurement point. In this case, | |||
not care of the internal packet loss | we do not care about the internal packet loss of the router.</t> | |||
of the router).</t> | ||||
<t>It is worth highlighting that it might also be convenient to define Cl | ||||
usters based on the topological | ||||
information and applicable to all the possible flows in the monitored net | ||||
work.</t> | ||||
<section title="Algorithm for Cluster partition"> | ||||
<t>A simple algorithm can be applied in order to split our monitoring net | ||||
work into Clusters. | ||||
This can be done for each direction separately. The Cluster partition is | ||||
based on the Monitoring Network Graph | ||||
that can be valid for a specific flow or can also be general and valid fo | ||||
r the entire network topology.</t> | ||||
<t>It is a two-step algorithm:<list style="symbols"> | ||||
<t>Group the links where there is the same starting node;</t> | ||||
<t>Join the grouped links with at least one ending node in common.</t> | ||||
</list></t> | ||||
<t>Considering that the links are unidirectional, the first step implies | <t>It is worth highlighting that it might also be convenient to define clu | |||
to list all the links as connection | sters based on the topological | |||
between two nodes and to group the different links if they have the same | information so that they are applicable to all the possible flows in the | |||
starting node. | monitored network.</t> | |||
Note that it is possible to start from any link and the procedure works | <section numbered="true" toc="default"> | |||
anyway. Following this classification, | <name>Algorithm for Clusters Partition</name> | |||
the second step implies to eventually join the groups classified in the | <t>A simple algorithm can be applied in order to split our monitoring ne | |||
first step by looking at the ending nodes. | twork into clusters. | |||
This can be done for each direction separately. The clusters partition | ||||
is based on the monitoring network graph, which can be valid for a | ||||
specific flow or can also be general and valid for the entire network | ||||
topology.</t> | ||||
<t>It is a two-step algorithm:</t> | ||||
<ol spacing="normal"> | ||||
<li>Group the links where there is the same starting node;</li> | ||||
<li>Join the grouped links with at least one ending node in common.</l | ||||
i> | ||||
</ol> | ||||
<t>Considering that the links are unidirectional, the first step | ||||
implies listing all the links as connections between two nodes and | ||||
grouping the different links if they have the same starting node. | ||||
Note that it is possible to start from any link, and the procedure | ||||
will work. Following this classification, | ||||
the second step implies eventually joining the groups classified in the | ||||
first step by looking at the ending nodes. | ||||
If different groups have at least one common ending node, they are put t ogether and belong to the same set. | If different groups have at least one common ending node, they are put t ogether and belong to the same set. | |||
After the application of the two steps of the algorithm, each one of the | After the application of the two steps of the algorithm, each one of the | |||
composed sets of links | composed sets of links, | |||
together with the endpoint nodes constitutes a Cluster.</t> | together with the endpoint nodes, constitutes a cluster.</t> | |||
<t>In our monitoring network graph example, it is possible to identify t | ||||
<t>In our monitoring network graph example it is possible to identify the | he clusters partition | |||
Clusters partition | ||||
by applying this two-step algorithm.</t> | by applying this two-step algorithm.</t> | |||
<t>The first step identifies the following groups:</t> | ||||
<t>The first step identifies the following groups:<list style="numbers"> | <ol spacing="normal" type="1"> | |||
<t>Group 1: (R1-R2), (R1-R3), (R1-R10)</t> | <li>Group 1: (R1-R2), (R1-R3), (R1-R10)</li> | |||
<t>Group 2: (R2-R4), (R2-R5)</t> | <li>Group 2: (R2-R4), (R2-R5)</li> | |||
<t>Group 3: (R3-R5), (R3-R9)</t> | <li>Group 3: (R3-R5), (R3-R9)</li> | |||
<t>Group 4: (R4-R6), (R4-R7)</t> | <li>Group 4: (R4-R6), (R4-R7)</li> | |||
<t>Group 5: (R5-R8)</t> | <li>Group 5: (R5-R8)</li> | |||
</list></t> | </ol> | |||
<t>And then, the second step builds the clusters partition (in particula | ||||
<t>And then, the second step builds the Clusters partition (in particular | r, | |||
we can underline that Group 2 and Group 3 connect together, since R5 is i | we can underline that Groups 2 and 3 connect together, since R5 is in | |||
n | common):</t> | |||
common):<list style="numbers"> | <ol spacing="normal" type="1"> | |||
<t>Cluster 1: (R1-R2), (R1-R3), (R1-R10)</t> | <li>Cluster 1: (R1-R2), (R1-R3), (R1-R10)</li> | |||
<t>Cluster 2: (R2-R4), (R2-R5), (R3-R5), (R3-R9)</t> | <li>Cluster 2: (R2-R4), (R2-R5), (R3-R5), (R3-R9)</li> | |||
<t>Cluster 3: (R4-R6), (R4-R7)</t> | <li>Cluster 3: (R4-R6), (R4-R7)</li> | |||
<t>Cluster 4: (R5-R8)</t> | <li>Cluster 4: (R5-R8)</li> | |||
</list></t> | </ol> | |||
<t>The flow direction here considered is from left to right. For the opp | ||||
<t>The flow direction here considered is from left to right. For the opposit | osite direction, | |||
e direction | the same reasoning can be applied, and in this example, you get the | |||
the same way of reasoning can be applied and, in this example, you get th | same clusters partition.</t> | |||
e same Clusters partition.</t> | <t>In the end, the following 4 clusters are obtained:</t> | |||
<figure anchor="clusters"> | ||||
<t>In the end the following 4 Clusters are obtained:</t> | <name>Clusters Example</name> | |||
<artwork name="" type="" align="left" alt=""><![CDATA[ | ||||
<figure anchor="clusters" title="Clusters example"> | ||||
<artwork><![CDATA[ | ||||
Cluster 1 | Cluster 1 | |||
+------+ | +------+ | |||
<> R2 <>--- | <> R2 <>--- | |||
/ +------+ | / +------+ | |||
/ | / | |||
+------+ / +------+ | +------+ / +------+ | |||
---<> R1 <>---<> R3 <>--- | ---<> R1 <>---<> R3 <>--- | |||
+------+ \ +------+ | +------+ \ +------+ | |||
\ | \ | |||
\ | \ | |||
skipping to change at line 713 ¶ | skipping to change at line 533 ¶ | |||
<> R7 <>--- | <> R7 <>--- | |||
+------+ | +------+ | |||
Cluster 4 | Cluster 4 | |||
+------+ | +------+ | |||
---<> R5 <> | ---<> R5 <> | |||
+------+ \ | +------+ \ | |||
\ +------+ | \ +------+ | |||
<> R8 <>--- | <> R8 <>--- | |||
+------+ | +------+ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t>There are clusters with more than two nodes as well as two-node clust | ||||
<t>There are Clusters with more than 2 nodes and two-nodes Cluste | ers. | |||
rs. | In the two-node clusters, the loss is on the link (Cluster 4). | |||
In the two-nodes Clusters the loss is on the link (Cluster 4). | In more-than-two-node clusters, the loss is on the cluster, but | |||
In more-than-2-nodes Clusters the loss is on the Cluster but | we cannot know in which link (Cluster 1, 2, or 3).</t> | |||
we cannot know in which link (Cluster 1, 2, 3).</t> | <t>In this way, the calculation of packet loss can be made on a cluster | |||
basis. | ||||
<t>In this way the calculation of packet loss can be made on Clus | Note that the packet counters for each marking period permit calc | |||
ter basis. | ulating the packet rate | |||
Note that the packet counters for each marking period permit to c | on a cluster basis, so Committed Information Rate (CIR) and Exces | |||
alculate the packet rate | s Information Rate (EIR) | |||
on Cluster basis, so Committed Information Rate (CIR) and Excess | could also be deduced on a cluster basis.</t> | |||
Information Rate (EIR) | <t>Obviously, by combining some clusters in a new connected subnetwork | |||
could also be deduced on Cluster basis.</t> | (called a "super cluster"), the packet-loss rule is still true.</ | |||
t> | ||||
<t>Obviously, by combining some Clusters in a new connected subne | <t>In this way, in a very large network, there is no need to configure d | |||
twork | etailed | |||
(called Super Cluster) the Packet Loss Rule is still true.</t> | ||||
<t>In this way, in a very large network there is no need to confi | ||||
gure detailed | ||||
filter criteria to inspect the traffic. You can check a multipoin t network and, | filter criteria to inspect the traffic. You can check a multipoin t network and, | |||
in case of problems, you can go deep with a step-by-step cluster analysis, | in case of problems, go deep with a step-by-step cluster analysis , | |||
but only for the cluster or combination of clusters where the pro blem happens.</t> | but only for the cluster or combination of clusters where the pro blem happens.</t> | |||
<t>In summary, once defined a flow, the algorithm to build the Cl | <t>In summary, once a flow is defined, the algorithm to build the cluste | |||
uster Partition | rs partition | |||
considers all the possible links and nodes crossed by the given f | is based on topological information; therefore, it considers all | |||
low, even if | the possible links and nodes crossed by the given flow, even if | |||
there is no traffic. It is based on topological information. So, | there is no traffic. So, if the flow does not | |||
if the flow does not | enter or traverse all the nodes, the counters have a nonzero | |||
enter or traverse all the nodes, the counters have a non-zero val | value for the involved nodes and a zero value for the other | |||
ue for the involved nodes, | nodes without traffic; but in the end, all the formulas | |||
while a zero value for the other nodes without traffic, but, in t | ||||
he end all the formulas | ||||
are still valid.</t> | are still valid.</t> | |||
<t>The algorithm described above is an iterative clustering algorithm, b | ||||
ut it is also | ||||
possible to apply a recursive clustering algorithm by using the n | ||||
ode-node adjacency | ||||
matrix representation <xref target="IEEE-ACM-ToN-MPNPM" format="d | ||||
efault"/>.</t> | ||||
<t>The algorithm described above is an Iterative clustering algor | <t>The complete and mathematical analysis of the possible algorithms for | |||
ithm, but it is also | clusters | |||
possible to apply a Recursive clustering algorithm by using the n | ||||
ode-node adjacency | ||||
matrix representation (<xref target="IEEE-ACM-ToN-MPNPM"/>).</t> | ||||
<t>The complete and mathematical analysis of the possible Algorit | ||||
hms for Cluster | ||||
partition, including the considerations in terms of efficiency an d a comparison | partition, including the considerations in terms of efficiency an d a comparison | |||
between the different methods, is in the paper <xref target="IEEE | between the different methods, is in the paper <xref | |||
-ACM-ToN-MPNPM"/>.</t> | target="IEEE-ACM-ToN-MPNPM" format="default"/>.</t> | |||
</section> | ||||
</section> | ||||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<section title="Timing Aspects"> | <name>Timing Aspects</name> | |||
<t>It is important to consider the timing aspects, since out-of-order pack | ||||
<t>It is important to consider the timing aspects, since out of order pa | ets happen and have | |||
ckets happen and have | to be handled as well, as described in <xref target="RFC8321" | |||
to be handled as well as described in <xref target="RFC8321">RFC 8321</x | format="default">RFC 8321</xref>. However, in a | |||
ref>. But, in a | multisource situation, an additional issue has to be considered. With mu | |||
multi-source situation an additional issue has to be considered. With mu | ltipoint path, | |||
ltipoint path, | ||||
the egress nodes will receive alternate marked packets in random order f rom different ingress nodes, | the egress nodes will receive alternate marked packets in random order f rom different ingress nodes, | |||
and this must not affect the measurement.</t> | and this must not affect the measurement.</t> | |||
<t>So, if we analyze a multipoint-to-multipoint path with more than one ma | ||||
<t>So, if we analyse a multipoint-to-multipoint path with more than one | rking node, | |||
marking node, | it is important to recognize the reference measurement interval. In general | |||
it is important to recognize the reference measurement interval. In general | , the measurement | |||
the measurement | ||||
interval for describing the results is the interval of the marking node that is more aligned with | interval for describing the results is the interval of the marking node that is more aligned with | |||
the start of the measurement, as reported in the following figure.</t> | the start of the measurement, as reported in <xref target="measint" />.< | |||
/t> | ||||
<t>Note that the mark switching approach based on a fixed timer is consi | <t>Note that the mark switching approach based on a fixed timer is conside | |||
dered in this document.</t> | red in this document.</t> | |||
<figure anchor="measint"> | ||||
<figure anchor="measint" title="Measurement Interval"> | <name>Measurement Interval</name> | |||
<artwork><![CDATA[ | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
time -> start stop | time -> start stop | |||
T(R1) |-------------| | T(R1) |-------------| | |||
T(R2) |-------------| | T(R2) |-------------| | |||
T(R3) |------------| | T(R3) |------------| | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t>In the figure it is assumed that the node with the earliest clock (R1) | ||||
identifies the right | ||||
starting and ending time of the measurement, but it is just an assumption | ||||
and other possibilities | ||||
could occur. So, in this case, T(R1) is the measurement interval and its | ||||
recognition is essential | ||||
in order to be compatible and make comparison with other active/passive/h | ||||
ybrid Packet Loss metrics.</t> | ||||
<t>When we expand to multipoint-to-multipoint flows, we have to consider | ||||
that | ||||
all source nodes mark the traffic and this adds more complexity.</t> | ||||
<t>Regarding the timing aspects of the methodology, <xref target="RFC8321 | <t>In <xref target="measint"/>, it is assumed that the node with the | |||
">RFC 8321</xref> already | earliest clock (R1) identifies the right | |||
starting and ending times of the measurement, but it is just an assumptio | ||||
n, and other possibilities | ||||
could occur. So, in this case, T(R1) is the measurement interval, and its | ||||
recognition is essential | ||||
in order to make comparisons with other active/passive/hybrid Packet Loss | ||||
metrics.</t> | ||||
<t>When we expand to multipoint-to-multipoint flows, we have to consider t | ||||
hat | ||||
all source nodes mark the traffic, and this adds more complexity.</t> | ||||
<t>Regarding the timing aspects of the methodology, <xref target="RFC8321" | ||||
format="default">RFC 8321</xref> already | ||||
describes two contributions that are taken into account: the clock error between network devices and | describes two contributions that are taken into account: the clock error between network devices and | |||
the network delay between measurement points.</t> | the network delay between measurement points.</t> | |||
<t>But we should now consider an additional contribution. Since all source | ||||
<t>But we should now consider an additional contribution. Since all sourc | nodes mark the traffic, | |||
e nodes mark the traffic, | the source measurement intervals can be of different lengths and with dif | |||
the source measurement intervals can be of different lengths and with dif | ferent offsets, and this | |||
ferent offsets and this | mismatch m can be added to d, as shown in <xref target="mtiming"/>.</t> | |||
mismatch m can be added to d, as shown in figure.</t> | <figure anchor="mtiming"> | |||
<name>Timing Aspects for Multipoint Paths</name> | ||||
<figure anchor="mtiming" title="Timing Aspects for Multipoint paths"> | <artwork name="" type="" align="left" alt=""><![CDATA[ | |||
<artwork><![CDATA[ | ||||
...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB... | ...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB... | |||
|<======================================>| | |<======================================>| | |||
| L | | | L | | |||
...=========>|<==================><==================>|<==========... | ...=========>|<==================><==================>|<==========... | |||
| L/2 L/2 | | | L/2 L/2 | | |||
|<=><===>| |<===><=>| | |<=><===>| |<===><=>| | |||
m d | | d m | m d | | d m | |||
|<====================>| | |<====================>| | |||
available counting interval | available counting interval | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t>So the misalignment between the marking source routers gives an additio | ||||
<t>So the misalignment between the marking source routers gives an additi | nal constraint, | |||
onal constraint | and the value of m is added to d (which already includes clock error and | |||
and the value of m is added to d (that already includes clock error and n | network delay).</t> | |||
etwork delay).</t> | <t>Thus, three different possible contributions are considered: clock erro | |||
r between network devices, | ||||
<t>Thus, three different possible contributions are considered: clock err | network delay between measurement points, and the misalignment between th | |||
or between network devices, | e marking source routers.</t> | |||
network delay between measurement points and the misalignment between the | <t>In the end, the condition that must be satisfied to enable the method t | |||
marking source routers.</t> | o function properly is that the | |||
available counting interval must be > 0, and that means:</t> | ||||
<t>In the end, the condition that must be satisfied to enable the method to | <t>L - 2m - 2d > 0.</t> | |||
function properly is that the | <t>This formula needs to be verified for each measurement point on the mul | |||
available counting interval must be > 0, and that means:</t> | tipoint path, where m is misalignment | |||
between the marking source routers, while d, already introduced in <xref | ||||
<t>L - 2m - 2d > 0.</t> | target="RFC8321" format="default">RFC 8321</xref>, | |||
<t>This formula needs to be verified for each measurement point on the mu | ||||
ltipoint path, where m is misalignment | ||||
between the marking source routers, while d, already introduced in <xref | ||||
target="RFC8321">RFC 8321</xref>, | ||||
takes into account clock error and network delay between network nodes. T herefore, the mismatch between | takes into account clock error and network delay between network nodes. T herefore, the mismatch between | |||
measurement intervals must satisfy this condition.</t> | measurement intervals must satisfy this condition.</t> | |||
<t>Note that the timing considerations are valid for both packet loss and | ||||
<t>Note that the timing considerations are valid for both packet loss and | delay measurements.</t> | |||
delay measurements.</t> | ||||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<section title="Multipoint Delay and Delay Variation"> | <name>Multipoint Delay and Delay Variation</name> | |||
<t>The same line of reasoning can be applied to Delay and Delay V | <t>The same line of reasoning can be applied to delay and delay variation. | |||
ariation. | Similarly to the delay measurements defined in <xref target="RFC8321" form | |||
Similarly to the delay measurements defined in <xref target="RFC8 | at="default">RFC 8321</xref>, | |||
321">RFC 8321</xref>, | the marking batches anchor the samples to a particular period, and this is | |||
the marking batches anchor the samples to a particular period and | the | |||
this is the | time reference that can be used. | |||
time reference that can be used. | It is important to highlight that both delay and delay-variation measureme | |||
It is important to highlight that both delay and delay variation | nts | |||
measurements | make sense in a multipoint path. The delay variation is calculated by cons | |||
make sense in a multipoint path. The Delay Variation is calculate | idering | |||
d by considering | the same packets selected for measuring the delay.</t> | |||
the same packets selected for measuring the Delay.</t> | <t>In general, it is possible to perform delay and delay-variation measure | |||
ments | ||||
<t>In general, it is possible to perform delay and delay variatio | on the basis of multipoint paths or single packets:</t> | |||
n measurements | <ul spacing="normal"> | |||
on multipoint paths basis or on single packets basis:<list style= | <li>Delay measurements on the basis of multipoint paths mean that the de | |||
"symbols"> | lay value is representative | |||
of an entire multipoint path (e.g., the whole multipoint network, a clust | ||||
<t>Delay measurements on multipoint paths basis means that the de | er, or a combination | |||
lay value is representative | of clusters).</li> | |||
of an entire multipoint path (e.g. whole multipoint network, a cl | <li>Delay measurements on a single-packet basis mean that you can use | |||
uster or a combination | a multipoint path just | |||
of clusters).</t> | to easily couple packets between input and output nodes of a multipoint p | |||
ath, as | ||||
<t>Delay measurements on a single packet basis means that you can | described in the following sections.</li> | |||
use multipoint path just | </ul> | |||
to easily couple packets between input and output nodes of a mult | <section numbered="true" toc="default"> | |||
ipoint path, as it is | <name>Delay Measurements on a Multipoint-Paths Basis</name> | |||
described in the following sections.</t> | <section numbered="true" toc="default"> | |||
</list></t> | <name>Single-Marking Measurement</name> | |||
<t>Mean delay and mean delay-variation measurements can also be genera | ||||
<section title="Delay measurements on multipoint paths basis"> | lized | |||
<section title="Single Marking measurement"> | ||||
<t>Mean delay and mean delay variation measurements can also be g | ||||
eneralized | ||||
to the case of multipoint flows. It is possible to compute the av erage | to the case of multipoint flows. It is possible to compute the av erage | |||
one-way delay of packets, in one block, in a cluster or in the en tire | one-way delay of packets in one block, a cluster, or the entire | |||
monitored network.</t> | monitored network.</t> | |||
<t>The average latency can be measured as the difference | ||||
<t>The average latency can be measured as the difference | ||||
between the weighted averages of the mean timestamps of the | between the weighted averages of the mean timestamps of the | |||
sets of output and input nodes. This means that, in the calculati on, | sets of output and input nodes. This means that, in the calculati on, | |||
it is possible to weigh the timestamps by considering the number of packets | it is possible to weigh the timestamps by considering the number of packets | |||
for each endpoints.</t> | for each endpoints.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<section title="Delay measurements on single packets basis"> | <name>Delay Measurements on a Single-Packet Basis</name> | |||
<section title="Single and Double Marking measurement"> | <section numbered="true" toc="default"> | |||
<t>Delay and delay variation measurements relative to only one pi | <name>Single- and Double-Marking Measurement</name> | |||
cked packet per period (both single | <t>Delay and delay-variation measurements relative to only one picked | |||
and double marked) can be performed in the Multipoint scenario wi | packet per period (both single | |||
th some limitations:<list style="hanging"> | and double marked) can be performed in the multipoint scenario, w | |||
<t>Single marking based on the first/last packet of the interval | ith some limitations:</t> | |||
would not work, because | ||||
it would not be possible to agree on the first packet of the inte | ||||
rval.</t> | ||||
<t>Double marking or multiplexed marking would work, but each mea | <ul empty="true" spacing="normal"> | |||
surement would only | <li>Single marking based on the first/last packet of the interval wo | |||
uld not work, because | ||||
it would not be possible to agree on the first packet of the inte | ||||
rval.</li> | ||||
<li>Double marking or multiplexed marking would work, but each measu | ||||
rement would only | ||||
give information about the delay of a single path. However, by re peating the measurement | give information about the delay of a single path. However, by re peating the measurement | |||
multiple times, it is possible to get information about all the p aths in the multipoint flow. | multiple times, it is possible to get information about all the p aths in the multipoint flow. | |||
This can be done in case of point-to-multipoint path but it is mo | This can be done in the case of a point-to-multipoint path, but | |||
re difficult to achieve in case of | it is more difficult to achieve in the case of a | |||
multipoint-to-multipoint path because of the multiple source rout | multipoint-to-multipoint path because of the multiple source rout | |||
ers.</t> | ers.</li> | |||
</list></t> | </ul> | |||
<t>If we would perform a delay measurement for more than one | ||||
<t>If we would perform a delay measurement for more than one pick | picked packet in the same marking period, and especially if | |||
ed packet in the same marking period | we want to get delay measurements on a | |||
and, especially, if we want to get delay measurements on multipoi | multipoint-to-multipoint basis, neither the single- nor the | |||
nt-to-multipoint basis, | double-marking method is useful in the multipoint scenario, | |||
both single and double marking method are not useful in the Multi | since they would not be representative of the entire | |||
point scenario, since | flow. The packets can follow different paths with various | |||
they would not be representative of the entire flow. The packets | delays, and in general it can be very difficult to recognize | |||
can follow different paths | marked packets in a multipoint-to-multipoint path, | |||
with various delays, and in general it can be very difficult to r | especially in the case when there is more than one per | |||
ecognize marked packets | period.</t> | |||
in a multipoint-to-multipoint path especially in the case when th | <t>A desirable option is to monitor simultaneously all the paths of a | |||
ere is more than one per period.</t> | multipoint path | |||
in the same marking period; for this purpose, hashing can be used | ||||
<t>A desirable option is to monitor simultaneously all the paths | , as reported in the next section.</t> | |||
of a multipoint path | </section> | |||
in the same marking period and, for this purpose, hashing can be | <section numbered="true" toc="default"> | |||
used as reported in the next Section.</t> | <name>Hashing Selection Method</name> | |||
<t>RFCs <xref target="RFC5474" sectionFormat="bare">5474</xref> and | ||||
</section> | <xref target="RFC5475" sectionFormat="bare">5475</xref> | |||
introduce sampling and filtering techniques for IP packet selecti | ||||
<section title="Hashing selection method"> | on.</t> | |||
<t><xref target="RFC5474">RFC 5474</xref> and <xref target="RFC54 | <t>The hash-based selection methodologies for delay measurement can wo | |||
75">RFC 5475</xref> | rk in a | |||
introduce sampling and filtering techniques for IP Packet Selecti | multipoint-to-multipoint path and can be used either coupled | |||
on.</t> | to mean delay or stand-alone.</t> | |||
<t><xref target="I-D.mizrahi-ippm-compact-alternate-marking" format="d | ||||
<t>The hash-based selection methodologies for delay measurement c | efault"/> introduces how | |||
an work in a | to use the hash method (RFCs <xref target="RFC5474" | |||
multipoint-to-multipoint path and can be used both coupled to mea | sectionFormat="bare">5474</xref> and <xref target="RFC5475" | |||
n delay or stand alone.</t> | sectionFormat="bare">5475</xref>) | |||
combined with the Alternate-Marking method for point-to-point flo | ||||
<t><xref target="I-D.mizrahi-ippm-compact-alternate-marking"/> introd | ws. | |||
uces how | It is also called Mixed Hashed Marking: the coupling of a marking method | |||
to use the Hash method (<xref target="RFC5474">RFC 5474</xref> an | and hashing | |||
d <xref target="RFC5475">RFC 5475</xref>) | technique is very useful, because the marking batches anchor the | |||
combined with Alternate Marking method for point-to-point flows. | samples selected | |||
It is also called Mixed Hashed Marking: the coupling of marking method a | with hashing, and this simplifies the correlation of the hashing | |||
nd hashing | packets along the path.</t> | |||
technique is very useful because the marking batches anchor the s | <t>It is possible to use a basic-hash or a dynamic-hash method. | |||
amples selected | One of the challenges of the basic approach is that the frequency | |||
with hashing and this simplifies the correlation of the hashing p | of the sampled packets may vary considerably. | |||
ackets along the path.</t> | ||||
<t>It is possible to use a basic hash or a dynamic hash method. | For this | |||
One of the challenges of the basic approach is that the frequency | reason, the dynamic approach has been introduced for | |||
of | point-to-point flows in order to have the desired and | |||
the sampled packets may vary considerably. For this reason the dy | almost fixed number of samples for each measurement | |||
namic | period. Using the hash-based sampling, the number of | |||
approach has been introduced for point-to-point flow in order to | samples may vary a lot because it depends on the | |||
have | packet rate that is variable. The dynamic | |||
the desired and almost fixed number of samples for each measureme | approach helps to have an almost fixed number of | |||
nt period. | samples for each marking period, and this is a better | |||
option for making regular measurements over time. | ||||
In the hash-based sampling, Alternate Marking is used to | In the hash-based sampling, Alternate Marking is used to | |||
create periods, so that hash-based samples are divided into batch | create periods, so that hash-based samples are divided into batch | |||
es, | es, which | |||
allowing to anchor the selected samples to their period. Moreove | allows anchoring the selected samples to their period. | |||
r in the dynamic | Moreover, in the dynamic | |||
hash-based sampling, by dynamically adapting the length of the ha sh value, | hash-based sampling, by dynamically adapting the length of the ha sh value, | |||
the number of samples is bounded in each marking period. | the number of samples is bounded in each marking period. | |||
This can be realized by choosing the maximum number of samples | This can be realized by choosing the maximum number of samples | |||
(NMAX) to be caught in a marking period. The algorithm starts | (NMAX) to be caught in a marking period. The algorithm starts | |||
with only few hash bits, that permit to select a greater percenta | with only a few hash bits, which permits selecting a greater perc | |||
ge | entage | |||
of packets (e.g. with 0 bit of hash all the packets are sampled, | of packets (e.g., with 0 bits of hash all the packets are sampled | |||
, | ||||
with 1 bit of hash half of the packets are sampled, and so on). | with 1 bit of hash half of the packets are sampled, and so on). | |||
When the number of selected packets reaches NMAX, a hashing bit i s | When the number of selected packets reaches NMAX, a hashing bit i s | |||
added. As a consequence, the sampling proceeds at half of the | added. As a consequence, the sampling proceeds at half of the | |||
original rate and also the packets already selected that do not m atch | original rate, and also the packets already selected that do not match | |||
the new hash are discarded. This step can be repeated iterativel y. | the new hash are discarded. This step can be repeated iterativel y. | |||
It is assumed that each sample includes the timestamp (used for d elay measurement) and | It is assumed that each sample includes the timestamp (used for d elay measurement) and | |||
the hash value, allowing the management system to match the sampl es received | the hash value, allowing the management system to match the sampl es received | |||
from the two measurement points. | from the two measurement points. | |||
The dynamic process statistically converges at the end of a marki ng | The dynamic process statistically converges at the end of a marki ng | |||
period and the final number of selected samples is between NMAX/2 and NMAX. | period, and the final number of selected samples is between NMAX/ 2 and NMAX. | |||
Therefore, the dynamic approach paces the sampling rate, allowing to bound the | Therefore, the dynamic approach paces the sampling rate, allowing to bound the | |||
number of sampled packets per sampling period.</t> | number of sampled packets per sampling period.</t> | |||
<t>In a multipoint environment, the behavior is similar to a point-to- | ||||
<t>In a multipoint environment the behaviour is similar to a poin | point | |||
t-to point | ||||
flow. In particular, in the context of a multipoint-to-multipoint flow, the | flow. In particular, in the context of a multipoint-to-multipoint flow, the | |||
dynamic hash could be the solution to perform delay measurements | dynamic hash could be the solution for performing delay | |||
on specific packets | measurements on specific packets | |||
and to overcome the single and double marking limitations.</t> | and overcoming the single- and double-marking limitations.</t> | |||
<t>The management system receives the samples, including the timestamp | ||||
<t>The management system receives the samples including the times | s and | |||
tamps and | the hash value, from all the MPs, and this happens for both point | |||
the hash value from all the MPs, and this happens both for point- | -to-point | |||
to-point | and multipoint-to-multipoint flows. Then, the longest hash used | |||
and for multipoint-to-multipoint flows. Then the longest hash use | by the MPs is deduced and applied to couple timestamps from eithe | |||
d by MPs is deduced | r the same packets of | |||
and it is applied to couple timestamps of the same packets of 2 M | 2 MPs of a point-to-point path, or the input and output MPs of a | |||
Ps of a point-to-point path | cluster (or a super cluster or the entire network). | |||
or of input and output MPs of a Cluster (or a Super Cluster or th | But some considerations are needed: if there isn't packet loss, t | |||
e entire network). | he set of input samples | |||
But some considerations are needed: if there isn't packet loss th | is always equal to the set of output samples. In the case of pac | |||
e set of input samples | ket loss, the set of | |||
is always equal to the set of output samples. In case of packet | output samples can be a subset of input samples, but the | |||
loss the set of | method still works because, at the end, | |||
output samples can be a subset of input samples but the method st | ||||
ill works because, at the end, | ||||
it is easy to couple the input and output timestamps of each caug ht packet using the hash | it is easy to couple the input and output timestamps of each caug ht packet using the hash | |||
(in particular the “unused part of the hash” that should be diffe | (in particular, the "unused part of the hash" that should be diff | |||
rent for each packet).</t> | erent for each packet).</t> | |||
<t>Therefore, the basic hash is logically similar to the double-markin | ||||
<t>Therefore, the basic hash is logically similar to the double m | g method, and | |||
arking method, and | in the case of a point-to-point path, double-marking and basic-ha | |||
in case of point-to-point path double marking and basic hash sele | sh selection are equivalent. | |||
ction are equivalent. | The dynamic approach scales the number of measurements per | |||
The dynamic approach scales the number of measurements per interv | interval. It would seem | |||
al, and it would seem | ||||
that double marking would also work well if we reduced the interv al length, but | that double marking would also work well if we reduced the interv al length, but | |||
this can be done only for point-to-point path and not for multipo | this can be done only for a point-to-point path and not for a mul | |||
int path, where we | tipoint path, where we | |||
cannot couple the picked packets in a multipoint paths. | cannot couple the picked packets in a multipoint path. | |||
So, in general, if we want to get delay measurements on multipoin | So, in general, if we want to get delay measurements on the | |||
t-to-multipoint path | basis of a multipoint-to-multipoint path, and want to select more | |||
basis and want to select more than one packet per period, double | than one packet per period, double marking cannot be used | |||
marking cannot be used | ||||
because we could not be able to couple the picked packets between input and output nodes. | because we could not be able to couple the picked packets between input and output nodes. | |||
On the other hand we can do that by using hashing selection.</t> | On the other hand, we can do that by using hashing selection.</t> | |||
</section> | ||||
</section> | </section> | |||
</section> | ||||
</section> | <section numbered="true" toc="default"> | |||
<name>A Closed-Loop Performance-Management Approach</name> | ||||
</section> | <t>The Multipoint Alternate-Marking framework that is introduced in this d | |||
ocument adds flexibility | ||||
<section title="A Closed Loop Performance Management approach"> | to Performance Management (PM), because it can reduce the order of magnit | |||
ude of the packet counters. | ||||
<t>The Multipoint Alternate Marking framework that is introduced in this | This allows an SDN orchestrator to supervise, control, and manage PM in l | |||
document adds flexibility | arge networks.</t> | |||
to Performance Management (PM) because it can reduce the order of magnitu | ||||
de of the packet counters. | ||||
This allows an SDN Orchestrator to supervise, control and manage PM in la | ||||
rge networks.</t> | ||||
<t>The monitoring network can be considered as a whole or can be split in | ||||
Clusters, that are the | ||||
smallest subnetworks (group-to-group segments), maintaining the packet lo | ||||
ss property for each subnetwork. | ||||
They can also be combined in new connected subnetworks at different level | ||||
s depending on the detail we want | ||||
to achieve.</t> | ||||
<t>An SDN Controller or a Network Management System (NMS) can calibrate P | <t>The monitoring network can be considered as a whole or split into clust | |||
erformance Measurements | ers that are the | |||
smallest subnetworks (group-to-group segments), maintaining the | ||||
packet-loss property for each subnetwork. The clusters can also be | ||||
combined in new, connected subnetworks at different levels, depending on | ||||
the detail we want to achieve.</t> | ||||
<t>An SDN controller or a Network Management System (NMS) can calibrate pe | ||||
rformance measurements, | ||||
since they are aware of the network topology. They can start without exam ining in depth. In case of necessity | since they are aware of the network topology. They can start without exam ining in depth. In case of necessity | |||
(packet loss is measured or the delay is too high), the filtering criteri a could be immediately reconfigured | (packet loss is measured or the delay is too high), the filtering criteri a could be immediately reconfigured | |||
in order to perform a partition of the network by using Clusters and/or d | in order to perform a partition of the network by using clusters and/or d | |||
ifferent combinations of Clusters. | ifferent combinations of clusters. | |||
In this way the problem can be localized in a specific Cluster or in a si | In this way, the problem can be localized in a specific cluster or a sing | |||
ngle combination of Clusters | le combination of clusters, | |||
and a more detailed analysis can be performed step-by-step by successive | and a more detailed analysis can be performed step by step by successive | |||
approximation up to | approximation up to | |||
a point-to-point flow detailed analysis. This is the so called Closed Loo | a point-to-point flow detailed analysis. This is the so-called "closed lo | |||
p.</t> | op".</t> | |||
<t>This approach can be called "network zooming" and can be performed in t | ||||
<t>This approach can be called Network Zooming and can be performed in tw | wo different ways:</t> | |||
o different ways:</t> | <t>1) change the traffic filter and select more detailed flows;</t> | |||
<t>1) change the traffic filter and select more detailed flows;</t> | <t>2) activate new measurement points by defining more specified clusters. | |||
<t>2) activate new measurement points by defining more specified clusters | </t> | |||
.</t> | <t>The network-zooming approach implies that some filters or rules are cha | |||
nged and that therefore there is a | ||||
<t>The Network Zooming approach implies that the some filters or rules ar | transient time to wait once the new network configuration takes effect. T | |||
e changed and there is a | his time can be determined | |||
transient time to wait once the new network configuration takes effect an | ||||
d it can be determined | ||||
by the Network Orchestrator/Controller, based on the network conditions.< /t> | by the Network Orchestrator/Controller, based on the network conditions.< /t> | |||
<t>For example, if the Network Zooming identifies the performance problem for the traffic coming from | <t>For example, if the network zooming identifies the performance problem for the traffic coming from | |||
a specific source, we need to recognize the marked signal from this speci fic source node and its relative path. | a specific source, we need to recognize the marked signal from this speci fic source node and its relative path. | |||
For this purpose we can activate all the available measurement points and | For this purpose, we can activate all the available measurement points | |||
specify better the flow filter criteria | and better specify the flow filter criteria | |||
(i.e. 5-tuple). As an alternative, it can be enough to select packets fro | (i.e., 5-tuple). As an alternative, it can be enough to select packets | |||
m the specific source for delay measurements, | from the specific source for delay measurements; | |||
and in this case it is possible to apply the hashing technique as mention | in this case, it is possible to apply the hashing technique, as mentioned | |||
ed in the previous sections.</t> | in the previous sections.</t> | |||
<t><xref target="I-D.song-opsawg-ifit-framework" format="default"/> define | ||||
<t><xref target="I-D.song-opsawg-ifit-framework"/> defines an architectur | s an architecture where the centralized | |||
e where the centralized | Data Collector and Network Management can apply the intelligent and flexi | |||
Data Collector and Network Management can apply the intelligent and flexi | ble Alternate-Marking algorithm | |||
ble Alternate Marking algorithm | ||||
as previously described.</t> | as previously described.</t> | |||
<t>As for <xref target="RFC8321" format="default">RFC 8321</xref>, it is p | ||||
<t>As for <xref target="RFC8321">RFC 8321</xref>, it is possible to class | ossible to classify the traffic and mark a portion of | |||
ify the traffic and mark a portion of | the total traffic. For each period, the packet rate and bandwidth are cal | |||
the total traffic. For each period the packet rate and bandwidth are calc | culated from the number of packets. | |||
ulated from the number of packets. | In this way, the network orchestrator becomes aware if the traffic rate s | |||
In this way the Network Orchestrator becomes aware if the traffic rate ov | urpasses limits. | |||
ercomes limits. | In addition, more precision can be obtained by reducing the marking perio | |||
In addition more precision can be obtained by reducing the marking period | d; indeed, some implementations use | |||
, indeed some implementations use | a marking period of 1 sec or less.</t> | |||
a marking period of 1 sec and less.</t> | <t>In addition, an SDN controller could also collect the measurement histo | |||
ry.</t> | ||||
<t>In addition an SDN Controller could also collect the measurement histo | <t>It is important to mention that the Multipoint Alternate Marking framew | |||
ry.</t> | ork also helps Traffic Visualization. | |||
Indeed, this methodology is very useful for identifying which path or clu | ||||
<t>It is important to mention that the Multipoint Alternate Marking framewor | ster is crossed by the flow.</t> | |||
k also helps Traffic Visualization. | </section> | |||
Indeed this methodology is very useful to identify which path or which cl | <section numbered="true" toc="default"> | |||
uster is crossed by the flow.</t> | <name>Examples of Application</name> | |||
<t>There are application fields where it may be useful to take into | ||||
</section> | ||||
<section title="Examples of application"> | ||||
<t>There are application fields where it may be useful to take into | ||||
consideration the Multipoint Alternate Marking:</t> | consideration the Multipoint Alternate Marking:</t> | |||
<dl> | ||||
<t><list style="symbols"> | <dt>VPN:</dt><dd>The IP traffic is selected on an IP-source basis in bot | |||
<t>VPN: The IP traffic is selected on IP source basis in both | h | |||
directions. At the endpoint WAN interface all the output traffic | directions. At the endpoint WAN interface, all the output traffic | |||
is counted in a single flow. The input traffic is composed by all | is counted in a single flow. The input traffic is composed of all | |||
the other flows aggregated for source address. So, by considering | the other flows aggregated for source address. So, by considering | |||
n end-points, the monitored flows are n (each flow with 1 ingress | n endpoints, the monitored flows are n (each flow with 1 ingress | |||
point and (n-1) egress points) instead of n*(n-1) flows (each | point and (n-1) egress points) instead of n*(n-1) flows (each | |||
flow, with 1 ingress point and 1 egress point);</t> | flow, with 1 ingress point and 1 egress point).</dd> | |||
<t>Mobile Backhaul: LTE traffic is selected, in the Up direction, by | <dt>Mobile Backhaul:</dt><dd>LTE traffic is selected, in the Up directio | |||
the EnodeB source address and, in Down direction, by the EnodeB | n, by | |||
destination address because the packets are sent from the Mobile | the EnodeB source address and, in the Down direction, by the EnodeB | |||
Packet Core to the EnodeB. So the monitored flow is only one per | destination address, because the packets are sent from the Mobile | |||
EnodeB in both directions;</t> | Packet Core to the EnodeB. So the monitored flow is only one per | |||
<t>Over The Top (OTT) services: The traffic is selected, in the Down dire | EnodeB in both directions.</dd> | |||
ction | <dt>Over The Top (OTT) services:</dt><dd>The traffic is selected, in the | |||
by the source addresses of the packets sent by OTT Servers. In | Down direction, | |||
the opposite direction (Up) by the destination IP addresses of the | by the source addresses of the packets sent by OTT servers. In | |||
same Servers. So the monitoring is based on a single flow per OTT | the opposite direction (Up), it is selected by the destination IP addresse | |||
Servers in both directions.</t> | s of the | |||
<t>Enterprise SD-WAN: SD-WAN allows to connect remote branch offices to | same servers. So the monitoring is based on a single flow per OTT | |||
Data Centers and build higher-performance WANs. A centralized controlle | server in both directions.</dd> | |||
r | <dt>Enterprise SD-WAN:</dt><dd>SD-WAN allows connecting remote branch of | |||
fices to | ||||
data centers and building higher-performance WANs. A centralized contro | ||||
ller | ||||
is used to set policies and prioritize traffic. The SD-WAN takes into a ccount | is used to set policies and prioritize traffic. The SD-WAN takes into a ccount | |||
these policies and the availability of network bandwidth to route traff ic. | these policies and the availability of network bandwidth to route traff ic. | |||
This helps ensure that application performance meets service level agre ements (SLAs). | This helps ensure that application performance meets Service Level Agre ements (SLAs). | |||
This methodology can also help the path selection for the WAN connectio n based on | This methodology can also help the path selection for the WAN connectio n based on | |||
per Cluster and per flow performance. | per-cluster and per-flow performance. | |||
</t> | </dd> | |||
</list></t> | </dl> | |||
<t>Note that the preceding list is just an example and is not exhaustive. | ||||
<t>Note that the list is just an example and it is not exhaustive. More a | More applications | |||
pplications | ||||
are possible.</t> | are possible.</t> | |||
</section> | ||||
<section title="Security Considerations"> | ||||
<t>This document specifies a method to perform measurements that | ||||
does not | ||||
directly affect Internet security nor applications that run on th | ||||
e Internet. | ||||
However, implementation of this method must be mindful of securit | ||||
y | ||||
and privacy concerns, as explained in <xref target="RFC8321">RFC | ||||
8321</xref>.</t> | ||||
</section> | </section> | |||
<section numbered="true" toc="default"> | ||||
<section anchor="Acknowledgements" title="Acknowledgements"> | <name>Security Considerations</name> | |||
<t>The authors would like to thank Al Morton, Tal Mizrahi, Rachel Huang | <t>This document specifies a method of performing measurements that does n | |||
for the precious | ot | |||
contribution.</t> | directly affect Internet security or applications that run on the Internet | |||
. | ||||
However, implementation of this method must be mindful of security | ||||
and privacy concerns, as explained in <xref target="RFC8321" format="defau | ||||
lt">RFC 8321</xref>.</t> | ||||
</section> | </section> | |||
<!-- Possibly a 'Contributors' section ... --> | <section anchor="IANA" numbered="true" toc="default"> | |||
<name>IANA Considerations</name> | ||||
<section anchor="IANA" title="IANA Considerations"> | <t>This document has no IANA actions.</t> | |||
<t>This memo makes no requests of IANA.</t> | ||||
</section> | </section> | |||
</middle> | ||||
</middle> | ||||
<!-- *****BACK MATTER ***** --> | ||||
<back> | <back> | |||
<!-- References split to informative and normative --> | ||||
<references title="Normative References"> | ||||
<?rfc include='reference.RFC.5644'?> | <displayreference target="I-D.mizrahi-ippm-compact-alternate-marking" to="ALTERN | |||
ATE-MARKING"/> | ||||
<displayreference target="I-D.zhou-ippm-enhanced-alternate-marking" to="ENHANCED | ||||
-ALTERNATE-MARKING"/> | ||||
<displayreference target="I-D.song-opsawg-ifit-framework" to="IFIT-FRAMEWORK"/> | ||||
<displayreference target="I-D.ietf-ippm-route" to="ROUTE-ASSESSMENT"/> | ||||
<?rfc include='reference.RFC.8321'?> | <references> | |||
<name>References</name> | ||||
<references> | ||||
<name>Normative References</name> | ||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml | ||||
2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5644.xml"/> | ||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml | ||||
2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8321.xml"/> | ||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml | ||||
2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5474.xml"/> | ||||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml | ||||
2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5475.xml"/> | ||||
</references> | ||||
<references> | ||||
<name>Informative References</name> | ||||
<?rfc include='reference.RFC.5474'?> | <reference anchor="IEEE-ACM-ToN-MPNPM"> | |||
<front> | ||||
<title>Multipoint Passive Monitoring in Packet Networks</title> | ||||
<author surname="Cociglio" initials="M"> | ||||
<organization /> | ||||
</author> | ||||
<author surname="Fioccola" initials="G"> | ||||
<organization /> | ||||
</author> | ||||
<author surname="Marchetto" initials="G"> | ||||
<organization /> | ||||
</author> | ||||
<author surname="Sapio" initials="A"> | ||||
<organization /> | ||||
</author> | ||||
<author surname="Sisto" initials="R"> | ||||
<organization /> | ||||
</author> | ||||
<date year="2019" month="December"/> | ||||
</front> | ||||
<seriesInfo name="IEEE/ACM Transactions on Networking" | ||||
value="vol. 27, no. 6"/> | ||||
<seriesInfo name="pp." value="2377-2390"/> | ||||
<seriesInfo name="DOI" value="10.1109/TNET.2019.2950157"/> | ||||
</reference> | ||||
<?rfc include='reference.RFC.5475'?> | <reference anchor="IEEE-Network-PNPM"> | |||
<front> | ||||
<title>AM-PM: Efficient Network Telemetry using Alternate Marking</t | ||||
itle> | ||||
<author surname="Mizrahi" initials="T"> | ||||
<organization/> | ||||
</author> | ||||
<author surname="Navon" initials="G"> | ||||
<organization/> | ||||
</author> | ||||
<author surname="Fioccola" initials="G"> | ||||
<organization/> | ||||
</author> | ||||
<author surname="Cociglio" initials="M"> | ||||
<organization/> | ||||
</author> | ||||
<author surname="Chen" initials="M"> | ||||
<organization/> | ||||
</author> | ||||
<author surname="Mirsky" initials="G"> | ||||
<organization/> | ||||
</author> | ||||
<date year="2019" month="July"/> | ||||
</front> | ||||
<seriesInfo name="IEEE Network" value="vol. 33, no. 4"/> | ||||
<seriesInfo name="pp." value="155-161"/> | ||||
<seriesInfo name="DOI" value="10.1109/MNET.2019.1800152"/> | ||||
</reference> | ||||
</references> | <!-- [rfced] [I-D.mizrahi-ippm-compact-alternate-marking] IESG state Expired - -> | |||
<references title="Informative References"> | <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://www | |||
<!-- A reference written by by an organization not a persoN. --> | .rfc-editor.org/refs/bibxml3/reference.I-D.mizrahi-ippm-compact-alternate-markin | |||
<reference anchor='IEEE-ACM-ToN-MPNPM'> | g.xml"/> | |||
<front> | ||||
<title>Multipoint Passive Monitoring in Packet Networks</title> | ||||
<author> | ||||
<organization>IEEE/ACM TRANSACTION ON NETWORKING</organization> | ||||
</author> | ||||
<date year='2019' /> | ||||
</front> | ||||
<seriesInfo name='DOI' value='10.1109/TNET.2019.2950157'/> | ||||
</reference> | ||||
<reference anchor='IEEE-Network-PNPM'> | <!-- [rfced] [I-D.zhou-ippm-enhanced-alternate-marking] IESG state I-D Exists -- | |||
<front> | > | |||
<title>AM-PM: Efficient Network Telemetry using Alternate Marking</title> | ||||
<author> | ||||
<organization>IEEE Network</organization> | ||||
</author> | ||||
<date year='2019' /> | ||||
</front> | ||||
<seriesInfo name='DOI' value='10.1109/MNET.2019.1800152'/> | ||||
</reference> | ||||
<?rfc include='reference.I-D.mizrahi-ippm-compact-alternate-marking'?> | <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://www .rfc-editor.org/refs/bibxml3/reference.I-D.zhou-ippm-enhanced-alternate-marking. xml" /> | |||
<?rfc include='reference.I-D.zhou-ippm-enhanced-alternate-marking'?> | <!-- [rfced] [I-D.song-opsawg-ifit-framework] IESG state I-D Exists --> | |||
<?rfc include='reference.I-D.song-opsawg-ifit-framework'?> | <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://www .rfc-editor.org/refs/bibxml3/reference.I-D.song-opsawg-ifit-framework.xml"/> | |||
<?rfc include='reference.I-D.ietf-ippm-route'?> | <!-- [rfced] [I-D.ietf-ippm-route] IESG state Approved-announcement to be sent - -> | |||
<?rfc include='reference.RFC.7011'?> | <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://www .rfc-editor.org/refs/bibxml3/reference.I-D.ietf-ippm-route.xml"/> | |||
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml | ||||
2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7011.xml"/> | ||||
</references> | ||||
</references> | </references> | |||
<section anchor="Acknowledgements" numbered="false" toc="default"> | ||||
</back> | <name>Acknowledgements</name> | |||
<t>The authors would like to thank <contact fullname="Al Morton" />, | ||||
<contact fullname="Tal Mizrahi"/>, and <contact fullname="Rachel Huang"/> | ||||
for the precious contributions.</t> | ||||
</section> | ||||
</back> | ||||
</rfc> | </rfc> | |||
End of changes. 123 change blocks. | ||||
1106 lines changed or deleted | 857 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |