<?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 contains 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 variable 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 to 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 good idea to actually use one for the template because it might have disappeared when you 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-rfcs.xml"> corresponding to a draft filename draft-mrose-writing-rfcs-nn.txt. The citation 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 draft-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 course 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. 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). -->"rfc2629-xhtml.ent"> <rfccategory="exp"xmlns:xi="http://www.w3.org/2001/XInclude" 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 section, otherwise, put inline --> <?rfc editing="no" ?> <!-- When yes, insert editing marks: editing marks consist of a string such as <29> printed in the blank line at 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 section entries. --> <?rfc tocdepth="3"?> <!-- Sets the number of levels of sections/subsections... in ToC --> <!-- Choose the options for the references. Some like symbolic tags in the references (and citations) and others prefer 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 not starting each main section on a new page but does not omit the blank lines between list 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 ***** -->number="8889" obsoletes="" updates="" submissionType="IETF" category="exp" consensus="true" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"> <front><!-- The abbreviated title is used in the page header - it is only necessary if the full title is longer than 42 characters --><title abbrev="Multipoint AM">MultipointAlternate Marking methodAlternate-Marking Method forpassivePassive andhybrid performance monitoring</title> <!-- add 'role="editor"' below for the editors if appropriate -->Hybrid Performance Monitoring</title> <seriesInfo name="RFC" value="8889"/> <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> <address> <postal> <street>Riesstrasse, 25</street> <city>Munich</city> <code>80992</code> <country>Germany</country> </postal> <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> </author> <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> <address> <postal> <street>Via Reiss Romoli, 274</street> <city>Torino</city> <code>10148</code> <country>Italy</country> </postal> <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> </author> <author fullname="Amedeo Sapio" initials="A." surname="Sapio"><!-- abbrev not needed but can be used for the header if the full organization name is too long --> <organization>Politecnico di Torino</organization><organization>Intel Corporation</organization> <address> <postal><street>Corso Duca degli Abruzzi, 24</street> <city>Torino</city> <code>10129</code> <country>Italy</country><street>4750 Patrick Henry Dr.</street> <city>Santa Clara</city> <region>CA</region> <code>95054</code> <country>USA</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> --><email>amedeo.sapio@intel.com</email> </address> </author> <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> <address> <postal> <street>Corso Duca degli Abruzzi, 24</street> <city>Torino</city> <code>10129</code> <country>Italy</country> </postal> <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> </author> <dateyear="2020"/> <!-- month="March" is no longer necessary note also, day="30" is optional --> <!-- WARNING: If the month and year are the current ones, xml2rfc will fill in the day for you. If only the year is specified, xml2rfc will fill in the current day 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! -->year="2020" month="August" /> <area/> <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 HTML output files in a meta tag but they have no effect on text or nroff output. --><abstract> <t>TheAlternate MarkingAlternate-Marking method, as presented in RFC 8321, can only be appliedonlyto point-to-pointflowsflows, because it assumes that all the packets of the flow measured on one node are measured again by a single second node. This document generalizes and expands this methodology to measure any kind of unicastflows,flow whose packets can follow several different paths in thenetwork,network -- in widertermsterms, a multipoint-to-multipoint network. For thisreasonreason, the technique here described is calledMultipoint"Multipoint AlternateMarking.</t>Marking".</t> </abstract> </front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>TheAlternate MarkingAlternate-Marking method, as described in <xreftarget="RFC8321">RFCtarget="RFC8321" format="default">RFC 8321</xref>, is applicable to a point-to-point path. The extension proposed in this document applies to the most general case of multipoint-to-multipoint path and enables flexible and adaptive performance measurements in a managed network.</t> <t>TheAlternate MarkingAlternate-Marking methodology described in <xreftarget="RFC8321">RFCtarget="RFC8321" format="default">RFC 8321</xref> allows the synchronization of the measurements in different points 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 about the applicability of theAlternate MarkingAlternate-Marking methodology are describedbothin <xreftarget="RFC8321">RFCtarget="RFC8321" format="default">RFC 8321</xref>andwhile implementation details can be found in the paper "AM-PM: Efficient Network Telemetry using Alternate Marking" <xreftarget="IEEE-Network-PNPM"/>.</t>target="IEEE-Network-PNPM" format="default"/>.</t> <t>There are some applications of theAlternate MarkingAlternate-Marking method where there are a lot of monitored flows and nodes. Multipoint Alternate Marking aims to reduce 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 monitoredflows,theflows, 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) andonthe granularity (for each service, each customer). So if both n and m are highvaluesvalues, the packet counters increase alotlot, and Multipoint Alternate Marking offers a tool to control these parameters.</t> <t>The approach presented in this document is applied only to unicast flows and not to multicast. Broadcast,Unknown-unicast,Unknown Unicast, and Multicast (BUM) traffic is not considered here, because traffic replication is not covered by the MultipointAlternate MarkingAlternate-Marking method.FurthermoreFurthermore, it can be applicable to anycastflowsflows, and Equal-CostMultiPathMultipath (ECMP) paths can also be easily monitored with this technique.</t> <t>In short, <xreftarget="RFC8321">RFCtarget="RFC8321" format="default">RFC 8321</xref> applies to point-to-point unicast flows and BUMtraffictraffic, while this document and its ClusteredAlternate MarkingAlternate-Marking method is valid for multipoint-to-multipoint unicast flows,anycastanycast, and ECMP flows.</t><t>The Alternate Marking<t>Therefore,the Alternate-Marking method canthereforebe extended to any kind ofmultipoint to multipointmultipoint-to-multipoint paths, and thenetwork clusteringnetwork-clustering approach presented in this document is the formalization of how to implement this property and allow a flexible and optimized performance 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 perform the needed degree of detail. In somecircumstancescircumstances, it is possible to monitor aMultipoint Networkmultipoint network byanalysinganalyzing theNetwork Clustering,network clustering, without examining in depth. In case of problems (packet loss is measured or the delay is toohigh)high), the filtering criteria could be specified more in order to perform a detailed analysis by using a different combination of clusters up to a per-flow measurement as described in <xreftarget="RFC8321">RFCtarget="RFC8321" format="default">RFC 8321</xref>.</t> <t>This approach fits very well with theClosed LoopClosed-Loop Network andSoftware DefinedSoftware-Defined Network (SDN)paradigmparadigm, where the SDNOrchestratororchestrator and the SDNControllerscontrollers are the brains of the network and can manage flow control to the switches and routers and, in the same way, can calibrate the performance measurements depending on the desired accuracy. An SDNController Applicationcontroller application can orchestrate howaccurateaccurately the network performance monitoring issetupset up by applying the Multipoint Alternate Marking as described in this document.</t> <t>It is important to underline that, as an extension of <xreftarget="RFC8321">RFCtarget="RFC8321" format="default">RFC 8321</xref>, this is a methodologydraft,document, so the mechanism that can be used to transmit the counters and the timestamps is out of scopeherehere, and the implementation is open. Several options arepossible, e.g. <xref target="I-D.zhou-ippm-enhanced-alternate-marking"/>.</t> <t>Note that, as forpossible -- e.g., see "Enhanced Alternate Marking Method" <xreftarget="RFC8321">RFC 8321</xref>,target="I-D.zhou-ippm-enhanced-alternate-marking" format="default"/>.</t> <t> Note that the fragmented packets case can be managed withthisthe Alternate-Marking methodology only if fragmentation happens outside the portion of themonitored network.</t>network that is monitored. This is always true for both <xref target="RFC8321" format="default">RFC 8321</xref> and Multipoint Alternate Marking, as explained here. </t> </section> <sectiontitle="Terminology">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">RFC 8321</xref>).<xref target="RFC8321" format="default"/>. It is to be remembered that <xreftarget="RFC8321">RFCtarget="RFC8321" format="default">RFC 8321</xref> is valid for point-to-point unicast flows and BUM traffic.</t> <t>The important new terms that need to be explained are listedbelow:<list> <t>Multipointbelow:</t> <dl> <dt>Multipoint AlternateMarking: ExtensionMarking:</dt><dd>Extension to <xreftarget="RFC8321">RFCtarget="RFC8321" format="default">RFC 8321</xref>, valid for multipoint-to-multipoint unicast flows,anycastanycast, and ECMP flows. It can also be referred to as Clustered AlternateMarking;</t> <t>Flow definition: TheMarking.</dd> <dt>Flow definition:</dt><dd>The concept of flow is generalized in this document. The identification fields are selected without any constraints and, in general, the flow can be a multipoint-to-multipoint flow, as a result ofaggregate point-to-point flows;</t> <t>Monitoring Network: it is identifiedaggregate point-to-point flows.</dd> <dt>Monitoring network:</dt><dd>Identified with the nodes of the network that are the measurement points (MPs) and the links that are the connections between MPs. TheMonitoring Networkmonitoring network graph depends on the flow definition, so it can represent a specific flow or thetheentire network topology as aggregate of all theflows;</t> <t>Cluster: smallestflows.</dd> <dt>Cluster:</dt><dd>Smallest identifiable subnetwork of the entireMonitoring Networkmonitoring network graph that still satisfies the condition that the number of packets thatgoesgo in is the same as the number thatgoes out;</t> <t>Multipoint metrics: packetgo out.</dd> <dt>Multipoint metrics:</dt><dd>Packet loss,delaydelay, and delay variation are extended to the case of multipoint flows. It is possible to compute these metrics on the basis of multipoint pathsbasisin order to associate the measurements to a cluster,toa combination ofclustersclusters, ortothe entire monitored network. For delay and delay variation, it is also possible to define the metrics on asingle packet basissingle-packet basis, and it means that the multipoint path is used to easily couple packets between input and output nodes of a multipointpath.</t> </list></t>path.</dd> </dl> <t>The next section highlights the correlation with the terms used in <xreftarget="RFC5644">RFCtarget="RFC5644" format="default">RFC 5644</xref>.</t> <sectiontitle="Correlationnumbered="true" toc="default"> <name>Correlation withRFC5644">RFC 5644</name> <t><xreftarget="RFC5644">RFCtarget="RFC5644" format="default">RFC 5644</xref> is limited to active measurements using a single source packet orstream, andstream. Its scope is also limited to observations of corresponding packets along the path(spatial),(spatial metric) and at one or more destinations(one-to-group), or both.</t>(one-to-group) along the path.</t> <t>Instead, the scope of this memo is to define multiparty metrics for passive and hybrid measurements in a group-to-group topology with multiple sources and destinations.</t> <t><xreftarget="RFC5644">RFCtarget="RFC5644" format="default">RFC 5644</xref> introduces metric names that can be reusedalsohere but have to be extended and rephrased to be applied to theAlternate MarkingAlternate-Marking schema:</t><t><list style="letters"> <t>the<ol spacing="normal" type="a"> <li>the multiparty metrics are not only one-to-group metrics but can be also group-to-groupmetrics;</t> <t>themetrics;</li> <li>the spatial metrics, used for measuring the performance of segments of a source to destination path, are applied here to group-to-group segments (calledClusters).</t> </list></t>clusters).</li> </ol> </section> </section> <sectiontitle="Flow classification"> <t>Annumbered="true" toc="default"> <name>Flow Classification</name> <t>A unicast flow is identified by all the packets having a set of common characteristics. This definition is inspired by <xreftarget="RFC7011">RFCtarget="RFC7011" format="default">RFC 7011</xref>.</t> <t>As an example, by considering a flow as all the packets sharing the same 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 connection, but a point-to-multipoint or multipoint-to-point connection.</t> <t>Ingeneralgeneral, a flow can be defined by a set of selection rules used to match a subset of the packets processed by the network device. These rules specify a set oflayer-3Layer 3 andlayer-4 headersLayer 4 header fields(Identification Fields)(identification fields) and the relative values that must be found in matching packets.</t> <t>The choice of the identification fields directly affects the type of paths that the flow would follow in the network. In fact, it is possible to relate a set of identification fields with the pattern of the resulting graphs, as listed inFigure 1.</t><xref target="Flows" />.</t> <t>A TCP 5-tuple usually identifies flows following either a single path or a point-to-point multipath (in the case of load balancing). On the contrary, 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 destination address. In the case where a selection rule and its reverse are used for bidirectional measurements, they can correspond to a point-to-multipoint in one direction and a multipoint-to-point in the opposite direction.</t> <t>So the flows to be monitored are selected into the monitoring points using packet selection rules,thatwhich can also change the pattern of the monitored network.</t> <t>Note that, morein general,generally, the flow can be defined at different levels based on theencapsulation consideredpotential encapsulation, and additional conditions that are not in the packet header can also be included as part of matching criteria.</t> <t>TheAlternate MarkingAlternate-Marking method is applicable only to a single path (and partially to a one-to-one multipath), so the extension proposed in this document is suitable also for the most general case of multipoint-to-multipoint, which embraces all the other patterns ofFigure 1.</t><xref target="Flows" />.</t> <figureanchor="Flows" title="Flow classification"> <artwork><![CDATA[anchor="Flows"> <name>Flow Classification</name> <artwork name="" type="" align="left" alt=""><![CDATA[ point-to-point single path +------+ +------+ +------+ ---<> R1 <>----<> R2 <>----<> R3 <>--- +------+ +------+ +------+ point-to-point multipath +------+ <> R2 <> / +------+ \ / \ +------+ / \ +------+ ---<> R1 <> <> R4 <>--- +------+ \ / +------+ \ / \ +------+ / <> R3 <> +------+ point-to-multipoint +------+ <> R4 <>--- / +------+ +------+ / <> R2 <> / +------+ \ +------+ / \ +------+ ---<> R1 <> <> R5 <>--- +------+ \ +------+ \ +------+ <> R3 <> +------+ \ \ +------+ <> R6 <>--- +------+ multipoint-to-point +------+ ---<> R1 <> +------+ \ \ +------+ <> R4 <> / +------+ \ +------+ / \ +------+ ---<> R2 <> <> R6 <>--- +------+ / +------+ +------+ / <> R5 <> / +------+ +------+ / ---<> R3 <> +------+ multipoint-to-multipoint +------+ +------+ ---<> R1 <> <> R6 <>--- +------+ \ / +------+ \ +------+ / <> R4 <> +------+ \ +------+ \ +------+ ---<> R2 <> <> R7 <>--- +------+ \ / +------+ \ +------+ / <> R5 <> / +------+ \ +------+ / \ +------+ ---<> R3 <> <> R8 <>--- +------+ +------+ ]]></artwork> </figure> <t>The case of unicast flow is considered inthe previous figure. Anyway the<xref target="Flows"/>. The anycast flow is also inscopescope, because there is no replication and only a single node from the anycast group receives the traffic, so it can be viewed as a special case of unicast flow. Furthermore, an ECMP flow is in scope by definition, since it is a point-to-multipoint unicast flow.</t> </section> <sectiontitle="Multipointnumbered="true" toc="default"> <name>Multipoint PerformanceMeasurement">Measurement</name> <t>ByUsingusing theAlternate Marking methodAlternate-Marking method, only point-to-point paths can be monitored. To have an IP (TCP/UDP) flow that follows a point-to-pointpathpath, we have to define, with a specific value, 5 identification fields (IP Source, IP Destination, Transport Protocol, Source Port, Destination Port).</t> <t>Multipoint Alternate Marking enables the performance measurement for multipoint flows selected by identification fields without any constraints (even the entire network production traffic). It is also possible to use multiple marking points for the same monitored flow.</t> <sectiontitle="Monitoring Network">numbered="true" toc="default"> <name>Monitoring Network</name> <t>TheMonitoring Networkmonitoring network is deduced from theProduction Network,production network by identifying the nodes of the graph that are the measurement points, and the links that are the connections between measurement points.</t> <t>There are some techniques that can help with the building of the monitoring network (as anexample it is possible to mentionexample, see <xreftarget="I-D.ietf-ippm-route"/>).target="I-D.ietf-ippm-route" format="default"/>). Ingeneralgeneral, there are different options: the monitoring network can be obtained by considering all the possible paths for the traffic oralso byperiodically checking the traffic (e.g. daily, weekly, monthly) andupdateupdating the graph as appropriate, 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 theAlternate MarkingAlternate-Marking method: the monitored interfaces and links are identified. Only the measurement points and links where the traffic has flowed have to be represented in the graph.</t><t>The following figure<t><xref target="monitored-graph"/> shows a simple example of aMonitoring Networkmonitoring network graph:</t> <figureanchor="monitored-graph" title="Monitoringanchor="monitored-graph"> <name>Monitoring NetworkGraph"> <artwork><![CDATA[Graph</name> <artwork name="" type="" align="left" alt=""><![CDATA[ +------+ <> R6 <>--- / +------+ +------+ +------+ / <> R2 <>---<> R4 <> / +------+ \ +------+ \ / \ \ +------+ +------+ / +------+ \ +------+ <> R7 <>--- ---<> R1 <>---<> R3 <>---<> R5 <> +------+ +------+ \ +------+ \ +------+ \ \ \ \ +------+ \ \ <> R8 <>--- \ \ +------+ \ \ \ \ +------+ \ <> R9 <>--- \ +------+ \ \ +------+ <> R10 <>--- +------+ ]]></artwork> </figure> <t>Each monitoring point is characterized by the packet counter that refers only to a marking period of the monitored flow.</t> <t>The same isapplicablealso applicable for thedelaydelay, but it will be described in the following sections.</t> </section> </section> <sectiontitle="Multipointnumbered="true" toc="default"> <name>Multipoint PacketLoss">Loss</name> <t>Since all the packets of the considered flow leaving the network have previously entered the network, the number of packets counted by all the input nodes is always greater than, or equalthanto, the number of packets counted by all the output nodes.Non-initialNoninitial fragments are not considered here.</t> <t>The assumption is the use of theAlternate MarkingAlternate-Marking method.And inIn the case of no packet loss occurring in the marking period, if all 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 ingress interfaces equals the number on egress interfaces for the monitored flow. In this circumstance, if no packet loss occurs, the intermediate measurement pointshaveonly have the taskto splitof splitting the measurement.</t> <t>It is possible to define the Network Packet Loss of one monitored flow for a singleperiod: «Inperiod. In a packet network, the number of lost packets is the number of packets counted by the input nodes minus the number of packets counted by the outputnodes».nodes. This is true for every packet flow in each marking period.</t> <t>TheMonitored Network Packet Lossmonitored network packet loss with n input nodes and m output nodes is given by:</t> <t>PL = (PI1 + PI2 +...+ PIn) - (PO1 + PO2 +...+ POm)</t> <t>where:</t> <t>PL is theNetwork Packet Lossnetwork packet loss (number of lost packets)</t> <t>PIi is theNumbernumber of packets flowed through the i-thInputinput node in this period</t> <t>POj is theNumbernumber of packets flowed through the j-thOutputoutput node in this period</t> <t>The equation is applied on a per-time-interval basis andon ana per-flowbasis:<list> <t>Thebasis:</t> <ul empty="true" spacing="normal"> <li>The reference interval is theAlternate Marking periodAlternate-Marking period, as defined in <xreftarget="RFC8321">RFC 8321</xref>.</t> <t>Thetarget="RFC8321" format="default">RFC 8321</xref>.</li> <li>The flow definition is generalizedhere, indeed,here. Indeed, as described before, a multipoint packet flow isconsideredconsidered, and the identification fields can be selected without anyconstraints.</t> </list></t>constraints.</li> </ul> </section> <sectiontitle="Network Clustering">numbered="true" toc="default"> <name>Network Clustering</name> <t>The previousEquationequation can determine the number of packets lost globally in the monitored network, exploiting only the data provided by the counters in the input and output nodes.</t> <t>Inadditionaddition, it is also possible to leverage the data provided by the other counters in the network to converge on the smallest identifiable subnetworks where the losses occur. These subnetworks are namedClusters.</t>"clusters".</t> <t>AClustercluster graph is a subnetwork of the entireMonitoring Networkmonitoring network graph that still satisfies the packet loss equation (introduced in the previoussection)section), where PL in this case is the number of packets lost in theCluster.cluster. As for the entireMonitoring Networkmonitoring network graph, theClustercluster is defined on a per-flow basis.</t> <t>For thisreasonreason, aClustercluster should contain all the arcs emanating from its input nodes and all the arcs terminating at its output nodes. This ensures that we can count all the packets (and only those) exiting an input node again at the output node, whatever path they follow.</t> <t>In a completely monitored unidirectional network (a network where every network interface is monitored), each network device corresponds to aClustercluster, and each physical link corresponds to twoClustersclusters (one for each device).</t> <t>Clusters can have different sizes depending onflow filteringthe flow-filtering criteria adopted.</t> <t>Moreover, sometimesClustersclusters can be optionally simplified. Forexampleexample, when two monitored interfaces are divided by a single router (one is the inputinterface andinterface, the other is the outputinterfaceinterface, and the router has only these two interfaces), instead of counting exactly twice, upon entering and leaving, it is possible to consider a single measurementpoint (inpoint. In thiscasecase, we do not careofabout the internal packet loss of therouter).</t>router.</t> <t>It is worth highlighting that it might also be convenient to defineClustersclusters based on the topological informationandso that they are applicable to all the possible flows in the monitored network.</t> <sectiontitle="Algorithmnumbered="true" toc="default"> <name>Algorithm forCluster partition">Clusters Partition</name> <t>A simple algorithm can be applied in order to split our monitoring network intoClusters.clusters. This can be done for each direction separately. TheClusterclusters partition is based on theMonitoring Network Graph thatmonitoring 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-stepalgorithm:<list style="symbols"> <t>Groupalgorithm:</t> <ol spacing="normal"> <li>Group the links where there is the same startingnode;</t> <t>Joinnode;</li> <li>Join the grouped links with at least one ending node incommon.</t> </list></t>common.</li> </ol> <t>Considering that the links are unidirectional, the first step impliesto listlisting all the links asconnectionconnections between two nodes andto groupgrouping the different links if they have the same starting node. Note that it is possible to start from anylinklink, and the procedureworks anyway.will work. Following this classification, the second step impliestoeventuallyjoinjoining 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 together and belong to the same set. After the application of the two steps of the algorithm, each one of the composed sets oflinkslinks, together with the endpointnodesnodes, constitutes aCluster.</t>cluster.</t> <t>In our monitoring network graphexampleexample, it is possible to identify theClustersclusters partition by applying this two-step algorithm.</t> <t>The first step identifies the followinggroups:<list style="numbers"> <t>Groupgroups:</t> <ol spacing="normal" type="1"> <li>Group 1: (R1-R2), (R1-R3),(R1-R10)</t> <t>Group(R1-R10)</li> <li>Group 2: (R2-R4),(R2-R5)</t> <t>Group(R2-R5)</li> <li>Group 3: (R3-R5),(R3-R9)</t> <t>Group(R3-R9)</li> <li>Group 4: (R4-R6),(R4-R7)</t> <t>Group(R4-R7)</li> <li>Group 5:(R5-R8)</t> </list></t>(R5-R8)</li> </ol> <t>And then, the second step builds theClustersclusters partition (inparticularparticular, we can underline thatGroupGroups 2 andGroup3 connect together, since R5 is incommon):<list style="numbers"> <t>Clustercommon):</t> <ol spacing="normal" type="1"> <li>Cluster 1: (R1-R2), (R1-R3),(R1-R10)</t> <t>Cluster(R1-R10)</li> <li>Cluster 2: (R2-R4), (R2-R5), (R3-R5),(R3-R9)</t> <t>Cluster(R3-R9)</li> <li>Cluster 3: (R4-R6),(R4-R7)</t> <t>Cluster(R4-R7)</li> <li>Cluster 4:(R5-R8)</t> </list></t>(R5-R8)</li> </ol> <t>The flow direction here considered is from left to right. For the oppositedirectiondirection, the sameway ofreasoning can beapplied and,applied, and in this example, you get the sameClustersclusters partition.</t> <t>In theendend, the following 4Clustersclusters are obtained:</t> <figureanchor="clusters" title="Clusters example"> <artwork><![CDATA[anchor="clusters"> <name>Clusters Example</name> <artwork name="" type="" align="left" alt=""><![CDATA[ Cluster 1 +------+ <> R2 <>--- / +------+ / +------+ / +------+ ---<> R1 <>---<> R3 <>--- +------+ \ +------+ \ \ \ \ \ \ \ \ \ +------+ <> R10 <>--- +------+ Cluster 2 +------+ +------+ ---<> R2 <>---<> R4 <>--- +------+ \ +------+ \ +------+ \ +------+ ---<> R3 <>---<> R5 <>--- +------+ \ +------+ \ \ \ \ \ +------+ <> R9 <>--- +------+ Cluster 3 +------+ <> R6 <>--- / +------+ +------+ / ---<> R4 <> +------+ \ \ +------+ <> R7 <>--- +------+ Cluster 4 +------+ ---<> R5 <> +------+ \ \ +------+ <> R8 <>--- +------+ ]]></artwork> </figure> <t>There areClustersclusters with more than2two nodesand two-nodes Clusters.as well as two-node clusters. In thetwo-nodes Clusterstwo-node clusters, the loss is on the link (Cluster 4). Inmore-than-2-nodes Clustersmore-than-two-node clusters, the loss is on theClustercluster, but we cannot know in which link (Cluster 1, 2, or 3).</t> <t>In thiswayway, the calculation of packet loss can be made onClustera cluster basis. Note that the packet counters for each marking period permitto calculatecalculating the packet rate onClustera cluster basis, so Committed Information Rate (CIR) and Excess Information Rate (EIR) could also be deduced onClustera cluster basis.</t> <t>Obviously, by combining someClustersclusters in a new connected subnetwork (calledSuper Cluster)a "super cluster"), thePacket Loss Rulepacket-loss rule is still true.</t> <t>In this way, in a very largenetworknetwork, there is no need to configure detailed filter criteria to inspect the traffic. You can check a multipoint network and, in case of problems,you cango deep with a step-by-step cluster analysis, but only for the cluster or combination of clusters where the problem happens.</t> <t>In summary, oncedefinedaflow,flow is defined, the algorithm to build theCluster Partitionclusters partition is based on topological information; therefore, it considers all the possible links and nodes crossed by the given flow, even if there is no traffic.It is based on topological information.So, if the flow does not enter or traverse all the nodes, the counters have anon-zerononzero value for the involvednodes, whilenodes and a zero value for the other nodes withouttraffic, but,traffic; but in theendend, all the formulas are still valid.</t> <t>The algorithm described above is anIterativeiterative clustering algorithm, but it is also possible to apply aRecursiverecursive clustering algorithm by using the node-node adjacency matrix representation(<xref target="IEEE-ACM-ToN-MPNPM"/>).</t><xref target="IEEE-ACM-ToN-MPNPM" format="default"/>.</t> <t>The complete and mathematical analysis of the possibleAlgorithmsalgorithms forClusterclusters partition, including the considerations in terms of efficiency and a comparison between the different methods, is in the paper <xreftarget="IEEE-ACM-ToN-MPNPM"/>.</t>target="IEEE-ACM-ToN-MPNPM" format="default"/>.</t> </section> </section> <sectiontitle="Timing Aspects">numbered="true" toc="default"> <name>Timing Aspects</name> <t>It is important to consider the timing aspects, sinceout of orderout-of-order packets happen and have to be handled aswellwell, as described in <xreftarget="RFC8321">RFCtarget="RFC8321" format="default">RFC 8321</xref>.But,However, in amulti-source situationmultisource situation, an additional issue has to be considered. With multipoint path, the egress nodes will receive alternate marked packets in random order from different ingress nodes, and this must not affect the measurement.</t> <t>So, if weanalyseanalyze a multipoint-to-multipoint path with more than one marking node, it is important to recognize the reference measurement interval. Ingeneralgeneral, the measurement interval for describing the results is the interval of the marking node that is more aligned with the start of the measurement, as reported inthe following figure.</t><xref target="measint" />.</t> <t>Note that the mark switching approach based on a fixed timer is considered in this document.</t> <figureanchor="measint" title="Measurement Interval"> <artwork><![CDATA[anchor="measint"> <name>Measurement Interval</name> <artwork name="" type="" align="left" alt=""><![CDATA[ time -> start stop T(R1) |-------------| T(R2) |-------------| T(R3) |------------| ]]></artwork> </figure> <t>Inthe figure<xref target="measint"/>, it is assumed that the node with the earliest clock (R1) identifies the right starting and endingtimetimes of the measurement, but it is just anassumptionassumption, and other possibilities could occur. So, in this case, T(R1) is the measurementintervalinterval, and its recognition is essential in order tobe compatible andmakecomparisoncomparisons with other active/passive/hybrid Packet Loss metrics.</t> <t>When we expand to multipoint-to-multipoint flows, we have to consider that all source nodes mark thetraffictraffic, and this adds more complexity.</t> <t>Regarding the timing aspects of the methodology, <xreftarget="RFC8321">RFCtarget="RFC8321" format="default">RFC 8321</xref> already describes two contributions that are taken into account: the clock error between network devices and the network delay between measurement points.</t> <t>But we should now consider an additional contribution. Since all source nodes mark the traffic, the source measurement intervals can be of different lengths and with differentoffsetsoffsets, and this mismatch m can be added to d, as shown infigure.</t><xref target="mtiming"/>.</t> <figureanchor="mtiming" title="Timinganchor="mtiming"> <name>Timing Aspects for Multipointpaths"> <artwork><![CDATA[Paths</name> <artwork name="" type="" align="left" alt=""><![CDATA[ ...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB... |<======================================>| | L | ...=========>|<==================><==================>|<==========... | L/2 L/2 | |<=><===>| |<===><=>| m d | | d m |<====================>| available counting interval ]]></artwork> </figure> <t>So the misalignment between the marking source routers gives an additionalconstraintconstraint, and the value of m is added to d(that(which already includes clock error and network delay).</t> <t>Thus, three different possible contributions are considered: clock error between network devices, network delay between measurementpointspoints, and the misalignment between the marking source routers.</t> <t>In the end, the condition that must be satisfied to enable the method to function properly is that the available counting interval must be>> 0, and that means:</t> <t>L - 2m - 2d>> 0.</t> <t>This formula needs to be verified for each measurement point on the multipoint path, where m is misalignment between the marking source routers, while d, already introduced in <xreftarget="RFC8321">RFCtarget="RFC8321" format="default">RFC 8321</xref>, takes into account clock error and network delay between network nodes. Therefore, the mismatch between measurement intervals must satisfy this condition.</t> <t>Note that the timing considerations are valid for both packet loss and delay measurements.</t> </section> <sectiontitle="Multipointnumbered="true" toc="default"> <name>Multipoint Delay and DelayVariation">Variation</name> <t>The same line of reasoning can be applied toDelaydelay andDelay Variation.delay variation. Similarly to the delay measurements defined in <xreftarget="RFC8321">RFCtarget="RFC8321" format="default">RFC 8321</xref>, the marking batches anchor the samples to a particularperiodperiod, and this is the time reference that can be used. It is important to highlight that both delay anddelay variationdelay-variation measurements make sense in a multipoint path. TheDelay Variationdelay variation is calculated by considering the same packets selected for measuring theDelay.</t>delay.</t> <t>In general, it is possible to perform delay anddelay variationdelay-variation measurements on the basis of multipoint pathsbasisoronsinglepackets basis:<list style="symbols"> <t>Delaypackets:</t> <ul spacing="normal"> <li>Delay measurements on the basis of multipoint pathsbasis meansmean that the delay value is representative of an entire multipoint path(e.g.(e.g., the whole multipoint network, aclustercluster, or a combination ofclusters).</t> <t>Delayclusters).</li> <li>Delay measurements on asingle packetsingle-packet basismeansmean that you can use a multipoint path just to easily couple packets between input and output nodes of a multipoint path, asit isdescribed in the followingsections.</t> </list></t>sections.</li> </ul> <sectiontitle="Delay measurementsnumbered="true" toc="default"> <name>Delay Measurements onmultipoint paths basis">a Multipoint-Paths Basis</name> <sectiontitle="Single Marking measurement">numbered="true" toc="default"> <name>Single-Marking Measurement</name> <t>Mean delay and meandelay variationdelay-variation measurements can also be generalized to the case of multipoint flows. It is possible to compute the average one-way delay ofpackets,packets in one block,inaclustercluster, orinthe entire monitored network.</t> <t>The average latency can be measured as the difference between the weighted averages of the mean timestamps of the sets of output and input nodes. This means that, in the calculation, it is possible to weigh the timestamps by considering the number of packets for each endpoints.</t> </section> </section> <sectiontitle="Delay measurementsnumbered="true" toc="default"> <name>Delay Measurements onsingle packets basis">a Single-Packet Basis</name> <sectiontitle="Singlenumbered="true" toc="default"> <name>Single- andDouble Marking measurement">Double-Marking Measurement</name> <t>Delay anddelay variationdelay-variation measurements relative to only one picked packet per period (both single and double marked) can be performed in theMultipoint scenariomultipoint scenario, with somelimitations:<list style="hanging"> <t>Singlelimitations:</t> <ul empty="true" spacing="normal"> <li>Single marking based on the first/last packet of the interval would not work, because it would not be possible to agree on the first packet of theinterval.</t> <t>Doubleinterval.</li> <li>Double marking or multiplexed marking would work, but each measurement would only give information about the delay of a single path. However, by repeating the measurement multiple times, it is possible to get information about all the paths in the multipoint flow. This can be done in the case of a point-to-multipointpathpath, but it is more difficult to achieve in the case of a multipoint-to-multipoint path because of the multiple sourcerouters.</t> </list></t>routers.</li> </ul> <t>If we would perform a delay measurement for more than one picked packet in the same markingperiod and, especially,period, and especially if we want to get delay measurements on a multipoint-to-multipoint basis,both single and double markingneither the single- nor the double-marking methodare notis useful in theMultipointmultipoint scenario, since they would not be representative of the entire flow. The packets can follow different paths with various delays, and in general it can be very difficult to recognize marked packets in a multipoint-to-multipointpathpath, especially in the case when there is more than one per period.</t> <t>A desirable option is to monitor simultaneously all the paths of a multipoint path in the same markingperiod and,period; for this purpose, hashing can beusedused, as reported in the nextSection.</t>section.</t> </section> <sectiontitle="Hashing selection method"> <t><xref target="RFC5474">RFC 5474</xref>numbered="true" toc="default"> <name>Hashing Selection Method</name> <t>RFCs <xref target="RFC5474" sectionFormat="bare">5474</xref> and <xreftarget="RFC5475">RFC 5475</xref>target="RFC5475" sectionFormat="bare">5475</xref> introduce sampling and filtering techniques for IPPacket Selection.</t>packet selection.</t> <t>The hash-based selection methodologies for delay measurement can work in a multipoint-to-multipoint path and can be usedbotheither coupled to mean delay orstand alone.</t>stand-alone.</t> <t><xreftarget="I-D.mizrahi-ippm-compact-alternate-marking"/>target="I-D.mizrahi-ippm-compact-alternate-marking" format="default"/> introduces how to use theHashhash method(<xref target="RFC5474">RFC 5474</xref>(RFCs <xref target="RFC5474" sectionFormat="bare">5474</xref> and <xreftarget="RFC5475">RFC 5475</xref>)target="RFC5475" sectionFormat="bare">5475</xref>) combined withAlternate Markingthe Alternate-Marking method for point-to-point flows. It is also called Mixed Hashed Marking: the coupling of a marking method and hashing technique is veryusefuluseful, because the marking batches anchor the samples selected withhashinghashing, and this simplifies the correlation of the hashing packets along the path.</t> <t>It is possible to use abasic hashbasic-hash or adynamic hashdynamic-hash method. One of the challenges of the basic approach is that the frequency of the sampled packets may vary considerably. For thisreasonreason, the dynamic approach has been introduced for point-to-pointflowflows in order to have the desired and almost fixed number of samples for each measurement period. Using the hash-based sampling, the number of samples may vary a lot because it depends on the packet rate that is variable. The dynamic approach helps to have an almost fixed number of 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 create periods, so that hash-based samples are divided into batches,allowing to anchorwhich allows anchoring the selected samples to their period.MoreoverMoreover, in the dynamic hash-based sampling, by dynamically adapting the length of the hash value, the number of samples is bounded in each marking period. This can be realized by choosing the maximum number of samples (NMAX) to be caught in a marking period. The algorithm starts with only a few hash bits,that permit to selectwhich permits selecting a greater percentage of packets(e.g.(e.g., with 0bitbits of hash all the packets are sampled, 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 is added. As a consequence, the sampling proceeds at half of the originalraterate, and also the packets already selected that do not match the new hash are discarded. This step can be repeated iteratively. It is assumed that each sample includes the timestamp (used for delay measurement) and the hash value, allowing the management system to match the samples received from the two measurement points. The dynamic process statistically converges at the end of a markingperiodperiod, 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 number of sampled packets per sampling period.</t> <t>In a multipointenvironmentenvironment, thebehaviourbehavior is similar to apoint-to pointpoint-to-point flow. In particular, in the context of a multipoint-to-multipoint flow, the dynamic hash could be the solutionto performfor performing delay measurements on specific packets andto overcomeovercoming thesinglesingle- anddouble markingdouble-marking limitations.</t> <t>The management system receives thesamplessamples, including the timestamps and the hashvaluevalue, from all the MPs, and this happensbothfor both point-to-point andformultipoint-to-multipoint flows.ThenThen, the longest hash used by the MPs is deduced andit isapplied to couple timestampsoffrom either the same packets of 2 MPs of a point-to-pointpathpath, orofthe input and output MPs of aClustercluster (or aSuper Clustersuper cluster or the entire network). But some considerations are needed: if there isn't packetlossloss, the set of input samples is always equal to the set of output samples. In the case of packetlossloss, the set of output samples can be a subset of inputsamplessamples, but the method still works because, at the end, it is easy to couple the input and output timestamps of each caught packet using the hash (inparticularparticular, the“unused"unused part of thehash”hash" that should be different for each packet).</t> <t>Therefore, the basic hash is logically similar to thedouble markingdouble-marking method, and in the case of a point-to-pointpath double markingpath, double-marking andbasic hashbasic-hash selection are equivalent. The dynamic approach scales the number of measurements perinterval, and itinterval. It would seem that double marking would also work well if we reduced the interval length, but this can be done only for a point-to-point path and not for a multipoint path, where we cannot couple the picked packets in a multipointpaths.path. So, in general, if we want to get delay measurements onmultipoint-to-multipoint paththe basis of a multipoint-to-multipoint path, and want to select more than one packet per period, double marking cannot be used because we could not be able to couple the picked packets between input and output nodes. On the otherhandhand, we can do that by using hashing selection.</t> </section> </section> </section> <sectiontitle="A Closed Loop Performance Management approach">numbered="true" toc="default"> <name>A Closed-Loop Performance-Management Approach</name> <t>The MultipointAlternate MarkingAlternate-Marking framework that is introduced in this document adds flexibility to Performance Management(PM)(PM), because it can reduce the order of magnitude of the packet counters. This allows an SDNOrchestratororchestrator to supervise,controlcontrol, and manage PM in large networks.</t> <t>The monitoring network can be considered as a whole orcan besplitin Clusters,into clusters that are the smallest subnetworks (group-to-group segments), maintaining thepacket losspacket-loss property for each subnetwork.TheyThe clusters can also be combined innewnew, connected subnetworks at differentlevelslevels, depending on the detail we want to achieve.</t> <t>An SDNControllercontroller or a Network Management System (NMS) can calibratePerformance Measurementsperformance measurements, since they are aware of the network topology. They can start without examining in depth. In case of necessity (packet loss is measured or the delay is too high), the filtering criteria could be immediately reconfigured in order to perform a partition of the network by usingClustersclusters and/or different combinations ofClusters.clusters. In thiswayway, the problem can be localized in a specificClustercluster orina single combination ofClustersclusters, and a more detailed analysis can be performedstep-by-stepstep by step by successive approximation up to a point-to-point flow detailed analysis. This is theso called Closed Loop.</t>so-called "closed loop".</t> <t>This approach can be calledNetwork Zooming"network zooming" and can be performed in two different ways:</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> <t>TheNetwork Zoomingnetwork-zooming approach implies thatthesome filters or rules are changed and that therefore there is a transient time to wait once the new network configuration takeseffect and iteffect. This time can be determined by the Network Orchestrator/Controller, based on the network conditions.</t> <t>For example, if theNetwork Zoomingnetwork zooming identifies the performance problem for the traffic coming from a specific source, we need to recognize the marked signal from this specific source node and its relative path. For thispurposepurpose, we can activate all the available measurement points andspecifybetter specify the flow filter criteria(i.e.(i.e., 5-tuple). As an alternative, it can be enough to select packets from the specific source for delaymeasurements, andmeasurements; in thiscasecase, it is possible to apply the hashingtechniquetechnique, as mentioned in the previous sections.</t> <t><xreftarget="I-D.song-opsawg-ifit-framework"/>target="I-D.song-opsawg-ifit-framework" format="default"/> defines an architecture where the centralized Data Collector and Network Management can apply the intelligent and flexibleAlternate MarkingAlternate-Marking algorithm as previously described.</t> <t>As for <xreftarget="RFC8321">RFCtarget="RFC8321" format="default">RFC 8321</xref>, it is possible to classify the traffic and mark a portion of the total traffic. For eachperiodperiod, the packet rate and bandwidth are calculated from the number of packets. In thiswayway, theNetwork Orchestratornetwork orchestrator becomes aware if the traffic rateovercomessurpasses limits. Inadditionaddition, more precision can be obtained by reducing the markingperiod, indeedperiod; indeed, some implementations use a marking period of 1 secandor less.</t> <t>Inadditionaddition, an SDNControllercontroller could also collect the measurement history.</t> <t>It is important to mention that the Multipoint Alternate Marking framework also helps Traffic Visualization.IndeedIndeed, this methodology is very usefulto identifyfor identifying which path orwhichcluster is crossed by the flow.</t> </section> <sectiontitle="Examplesnumbered="true" toc="default"> <name>Examples ofapplication">Application</name> <t>There are application fields where it may be useful to take into consideration the Multipoint Alternate Marking:</t><t><list style="symbols"> <t>VPN: The<dl> <dt>VPN:</dt><dd>The IP traffic is selected onIP sourcean IP-source basis in both directions. At the endpoint WANinterfaceinterface, all the output traffic is counted in a single flow. The input traffic is composedbyof all the other flows aggregated for source address. So, by considering nend-points,endpoints, the monitored flows are n (each flow with 1 ingress point and (n-1) egress points) instead of n*(n-1) flows (each flow, with 1 ingress point and 1 egresspoint);</t> <t>Mobile Backhaul: LTEpoint).</dd> <dt>Mobile Backhaul:</dt><dd>LTE traffic is selected, in the Up direction, by the EnodeB source address and, in the Down direction, by the EnodeB destinationaddressaddress, because the packets are sent from the Mobile Packet Core to the EnodeB. So the monitored flow is only one per EnodeB in bothdirections;</t> <t>Overdirections.</dd> <dt>Over The Top (OTT)services: Theservices:</dt><dd>The traffic is selected, in the Downdirectiondirection, by the source addresses of the packets sent by OTTServers.servers. In the opposite direction(Up)(Up), it is selected by the destination IP addresses of the sameServers.servers. So the monitoring is based on a single flow per OTTServersserver in bothdirections.</t> <t>Enterprise SD-WAN: SD-WANdirections.</dd> <dt>Enterprise SD-WAN:</dt><dd>SD-WAN allowsto connectconnecting remote branch offices toData Centersdata centers andbuildbuilding higher-performance WANs. A centralized controller is used to set policies and prioritize traffic. The SD-WAN takes into account these policies and the availability of network bandwidth to route traffic. This helps ensure that application performance meetsservice level agreementsService Level Agreements (SLAs). This methodology can also help the path selection for the WAN connection based onper Clusterper-cluster andper flowper-flow performance.</t> </list></t></dd> </dl> <t>Note that the preceding list is just an example anditis not exhaustive. More applications are possible.</t> </section> <sectiontitle="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>This document specifies a methodto performof performing measurements that does not directly affect Internet securitynoror applications that run on the Internet. However, implementation of this method must be mindful of security and privacy concerns, as explained in <xreftarget="RFC8321">RFCtarget="RFC8321" format="default">RFC 8321</xref>.</t> </section> <sectionanchor="Acknowledgements" title="Acknowledgements"> <t>The authors would like to thank Al Morton, Tal Mizrahi, Rachel Huang for the precious contribution.</t> </section> <!-- Possibly a 'Contributors' section ... --> <sectionanchor="IANA"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>Thismemo makesdocument has norequests of IANA.</t>IANA actions.</t> </section> </middle><!-- *****BACK MATTER ***** --><back><!-- References split to informative and normative --> <references title="Normative References"> <?rfc include='reference.RFC.5644'?> <?rfc include='reference.RFC.8321'?> <?rfc include='reference.RFC.5474'?> <?rfc include='reference.RFC.5475'?><displayreference target="I-D.mizrahi-ippm-compact-alternate-marking" to="ALTERNATE-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"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5644.xml"/> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8321.xml"/> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5474.xml"/> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5475.xml"/> </references><references title="Informative References"> <!-- A reference written by by an organization not a persoN. --><references> <name>Informative References</name> <referenceanchor='IEEE-ACM-ToN-MPNPM'>anchor="IEEE-ACM-ToN-MPNPM"> <front> <title>Multipoint Passive Monitoring in Packet Networks</title><author> <organization>IEEE/ACM TRANSACTION ON NETWORKING</organization><author surname="Cociglio" initials="M"> <organization /> </author><date year='2019'<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> <seriesInfoname='DOI' value='10.1109/TNET.2019.2950157'/>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> <referenceanchor='IEEE-Network-PNPM'>anchor="IEEE-Network-PNPM"> <front> <title>AM-PM: Efficient Network Telemetry using Alternate Marking</title><author> <organization>IEEE Network</organization><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> <dateyear='2019' />year="2019" month="July"/> </front> <seriesInfoname='DOI' value='10.1109/MNET.2019.1800152'/>name="IEEE Network" value="vol. 33, no. 4"/> <seriesInfo name="pp." value="155-161"/> <seriesInfo name="DOI" value="10.1109/MNET.2019.1800152"/> </reference><?rfc include='reference.I-D.mizrahi-ippm-compact-alternate-marking'?> <?rfc include='reference.I-D.zhou-ippm-enhanced-alternate-marking'?> <?rfc include='reference.I-D.song-opsawg-ifit-framework'?> <?rfc include='reference.I-D.ietf-ippm-route'?> <?rfc include='reference.RFC.7011'?><!-- [rfced] [I-D.mizrahi-ippm-compact-alternate-marking] IESG state Expired --> <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="https://www.rfc-editor.org/refs/bibxml3/reference.I-D.mizrahi-ippm-compact-alternate-marking.xml"/> <!-- [rfced] [I-D.zhou-ippm-enhanced-alternate-marking] IESG state I-D Exists --> <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" /> <!-- [rfced] [I-D.song-opsawg-ifit-framework] IESG state I-D Exists --> <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"/> <!-- [rfced] [I-D.ietf-ippm-route] IESG state Approved-announcement to be sent --> <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://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7011.xml"/> </references> </references> <section anchor="Acknowledgements" numbered="false" toc="default"> <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>