<?xml version="1.0"encoding="utf-8"?>encoding="UTF-8"?> <!-- xml2rfc v2v3 conversion 3.6.0 --> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-ietf-ippm-pam-09" number="9544" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" consensus="true" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"><!-- xml2rfc v2v3 conversion 3.6.0 --> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?><front> <titleabbrev="Framework of PAM">Precisionabbrev="PAMs for Services Governed by SLOs">Precision Availability Metrics (PAMs) for Services Governed by Service Level Objectives (SLOs)</title> <seriesInfoname="Internet-Draft" value="draft-ietf-ippm-pam-09"/>name="RFC" value="9544"/> <author fullname="Greg Mirsky" initials="G." surname="Mirsky"> <organization>Ericsson</organization> <address> <postal> <street/> <city/> <code/> <country/> </postal> <email>gregimirsky@gmail.com</email> </address> </author> <author fullname="Joel Halpern" initials="J." surname="Halpern"> <organization>Ericsson</organization> <address> <postal> <street/> <city/> <code/> <country/> </postal> <email>joel.halpern@ericsson.com</email> </address> </author> <author fullname="Xiao Min" initials="X." surname="Min"> <organization>ZTE Corp.</organization> <address> <postal> <street/> <city/> <code/> <country/> </postal> <email>xiao.min2@zte.com.cn</email> </address> </author> <author fullname="Alexander Clemm" initials="A." surname="Clemm"><organization>Futurewei</organization><organization></organization> <address> <postal><street>2330 Central Expressway</street> <city>Santa Clara</city> <code>CA 95050</code> <country>USA</country><street/> <city/> <code/> <country/> </postal> <email>ludwig@clemm.org</email> </address> </author> <author fullname="John Strassner" initials="J." surname="Strassner"> <organization>Futurewei</organization> <address> <postal> <street>2330 Central Expressway</street> <city>Santa Clara</city><code>CA 95050</code> <country>USA</country><region>CA</region> <code>95050</code> <country>United States of America</country> </postal> <email>strazpdj@gmail.com</email> </address> </author> <author fullname="Jerome Francois" initials="J." surname="Francois"> <organization>Inria and University of Luxembourg</organization> <address> <postal> <street>615 Rue du Jardin Botanique</street> <city>Villers-les-Nancy</city> <code>54600</code> <country>France</country> </postal> <email>jerome.francois@inria.fr</email> </address> </author> <dateyear="2023"/> <area>Transport</area> <workgroup>Network Working Group</workgroup> <keyword>Internet-Draft</keyword>year="2024" month="February"/> <area>TSV</area> <workgroup>ippm</workgroup> <keyword>IPPM</keyword> <keyword>PerformanceMeasurement </keyword>Measurement</keyword> <abstract> <t> This document defines a set of metrics for networking services with performance requirements expressed as Service Level Objectives(SLO).(SLOs). These metrics, referred to asPrecision"Precision Availability Metrics(PAM),(PAMs)", are useful for defining and monitoring SLOs. For example,PAMPAMs can be used by providers and/or customers of an RFCXXXX9543 Network Slice Service to assess whether the service is provided in compliance with its defined SLOs. </t><t>Note to the RFC Editor: Please update "RFC XXXX Network Slice" with the RFC number assigned to draft-ietf-teas-ietf-network-slices.</t></abstract> </front> <middle> <section anchor="intro" numbered="true" toc="default"> <name>Introduction</name> <t> Service providers and users often need to assess the quality with which network services are being delivered. In particular, in cases whereservice levelservice-level guarantees are documented (including their companion metrology) as part of a contract established between the customer and the service provider, and Service Level Objectives (SLOs) are defined, it is essential to provide means to verify that what has been delivered complies with what has been possibly negotiated and (contractually) defined between the customer and the service provider.<!-- Examples of Service Level Indicators (SLIs) include packet latency and packet loss ratio. -->Examples of SLOs<!-- associated with such SLIs -->wouldwould be target values for the maximum packet delay (one-way and/or round-trip) or maximum packet loss ratio that would be deemed acceptable. </t> <t> More generally, SLOs can be used to characterize the ability of a particular set of nodes to communicate according to certain measurable expectations. Those expectations can include but are not limited to aspects such as latency, delay variation, loss, capacity/throughput, ordering, and fragmentation. Whatever SLO parameters are chosen and whichever wayservice levelservice-level parameters are being measured,precision availability metricsPrecision Availability Metrics indicate whether or not a given service has been available according to expectations at all times. </t> <t> Several metrics (often documented in the IANARegistry of Performance Metrics"Performance Metrics" registry <xref target="IANA-PM-Registry"/> according to <xref target="RFC8911"/> and <xreftarget="RFC8912"/>),target="RFC8912"/>) can be used to characterize the service quality, expressing the perceived quality of delivered networking services versus their SLOs. Of concern is not so much the absolute service level (for example, actual latency experienced) but whether the service is provided in compliance with the negotiated and eventually contracted service levels. For instance, this may include whether the experienced packet delay falls within an acceptable range that has been contracted for the service. The specific quality of service depends on the SLO or a set thereof for a given service that is in effect.<!-- Different groups of applications set forth requirements for varying sets of service levels with different target values. Such applications range from Augmented Reality/Virtual Reality to mission-critical controlling industrial processes. --> A non-complianceNon-compliance to an SLO might result in the degradation of the quality of experience for gamers or even jeopardize the safety of a large geographical area.<!-- However, as those applications represent clear business opportunities, they demand dependable technical solutions. --></t> <t> The same service level may be deemed acceptable for one application, while unacceptable for another, depending on the needs of the application.HenceHence, it is not sufficient to measure service levels per se overtime, but to assesstime; the quality of the service being contextually provided (e.g., with the applicable SLO inmind).mind) must be also assessed. However, at this point, there are no standard metrics that can be used to account for the quality with which services are delivered relative to theirSLOs, andSLOs or to determine whether their SLOs are being met at all times. Such metrics and the instrumentation to support them are essential for various purposes, including monitoring (to ensure that networking services are performing according to their objectives) as well as accounting (to maintain a record of service levels delivered, which is important for the monetization of such services as well as for the triaging of problems). </t> <t> The current state-of-the-art of metricsincludes,include, for example, interfacemetrics, usefulmetrics that can be used to obtain statistical data on traffic volume and behavior that can be observed at an interface <xref target="RFC2863"/>and<xref target="RFC8343"/>. However, they are agnostic of actual service levels and not specific to distinct flows. Flow records <xref target="RFC7011"/>and<xref target="RFC7012"/> maintain statistics about flows, including flow volume and flow duration, but again, they contain very little information about service levels, let alone whether the service levels delivered meet their respective targets, i.e., their associated SLOs. </t> <t> This specification introduces a new set of metrics, Precision Availability Metrics(PAM),(PAMs), aimed at capturing service levels for a flow, specifically the degree to which the flow complies with the SLOs that are in effect.PAMPAMs can be used to assess whether a service is provided in compliance with its defined SLOs. This information can be used in multiple ways, for example, to optimize service delivery, take timely counteractions in the event of service degradation, or account for the quality of services being delivered. </t> <t> Availability is discussed inSection 3.4 of<xreftarget="RFC7297"/>.target="RFC7297" sectionFormat="of" section="3.4"/>. In this document, the term "availability" reflects that a service that is characterized by its SLOs is considered unavailable whenever those SLOs are violated, even if basic connectivity is still working. "Precision" refers to services whose service levels are governed by SLOs and must be delivered precisely according to the associated quality and performance requirements. It should be noted that precision refers to what is being assessed, not the mechanism used to measure it. In other words, it does not refer to the precision of the mechanism with which actual service levels are measured. Furthermore, the precision, with respect to the delivery of an SLO, particularly applies when a metric value approaches the specified threshold levels in the SLO. </t> <t> The specification and implementation of methods that provide for accurate measurements are separate topics independent of the definition of the metrics in which the results of such measurements would be expressed. Likewise, Service Level Expectations (SLEs), as defined inSection 5.1 of<xreftarget="I-D.ietf-teas-ietf-network-slices"/>,target="RFC9543" sectionFormat="of" section="5.1"/>, are outside the scope of this document.<!--, because it is in the nature of SLEs that they define parts of the SLA that are not easily measured.--> </t> <!-- <t> [Ed.note: It should be noted that at this point, the set of metrics proposed here is intended as a "starter set" that is intended to spark further discussion. Other metrics are certainly conceivable; we expect that the list of metrics will evolve as part of the Working Group discussions.]</t>--></section> <section numbered="true" toc="default"><name>Conventions and Terminology</name><name>Conventions</name> <section numbered="true" toc="default"> <name>Terminology</name> <t> In this document, SLA and SLO are used as defined in <xref target="RFC3198"/>. The reader may refer toSection 5.1 of<xreftarget="I-D.ietf-teas-ietf-network-slices"/>target="RFC9543" sectionFormat="of" section="5.1"/> for an applicability example of these concepts in the context of RFCXXXX9543 Network Slice Services. </t><t>Note to the RFC Editor: Please update "RFC XXXX Network Slice" with the RFC number assigned to <xref target="I-D.ietf-teas-ietf-network-slices"/>.</t></section> <section numbered="true" toc="default"> <name>Acronyms</name><t>PAM Precision<dl indent="7" newline="false" spacing="normal"> <dt>IPFIX</dt><dd>IP Flow Information Export</dd> <dt>PAM </dt><dd>Precision AvailabilityMetric</t> <t>OAM Operations, Administration, and Maintenance</t> <t>SLA ServiceMetric</dd> <dt>SLA </dt><dd>Service LevelAgreement</t> <t>SLE ServiceAgreement</dd> <dt>SLE </dt><dd>Service LevelExpectations</t> <!-- <t>SLI ServiceExpectation</dd> <dt>SLO </dt><dd>Service LevelIndicator</t> --> <t>SLO Service Level Objective</t> <t>VIObjective</dd> <dt>SVI </dt><dd>Severely ViolatedInterval</t> <t>VIRInterval</dd> <dt>SVIR </dt><dd>Severely Violated IntervalRatio</t> <t>VPCRatio</dd> <dt>SVPC </dt><dd>Severely Violated Packets Count</t> <t>SVI Severely Violated Interval</t> <t>SVIR Severely Violated</dd> <dt>VFI </dt><dd>Violation-Free Interval</dd> <dt>VI </dt><dd>Violated Interval</dd> <dt>VIR </dt><dd>Violated IntervalRatio</t> <t>SVPC Severely ViolatedRatio</dd> <dt>VPC </dt><dd>Violated Packets Count</t> <t>VFI Violation-Free Interval</t> </section> <!-- <section numbered="true" toc="default"> <name>Requirements Language</name> <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> when, and only when, they appear in all capitals, as shown here. </t></dd> </dl> </section>--></section> <section anchor="ep-metrics-section" numbered="true" toc="default"> <name>Precision Availability Metrics</name> <section anchor="preliminaries" numbered="true" toc="default"> <name>Introducing Violated Intervals</name> <t> When analyzing the availability metrics of a service between two measurement points, a time interval as the unit ofPAMPAMs needs to be selected. In <xref target="ITU.G.826" format="default"/>, a time interval of one second is used. That is reasonable, but some services may require different granularity (e.g., decamillisecond). For that reason, the time interval inPAMPAMs is viewed as a variableparameterparameter, though constant for a particular measurement session. Furthermore, for the purpose ofPAM,PAMs, each time interval is classifiedeitheras either Violated Interval (VI), Severely Violated Interval (SVI), or Violation-Free Interval (VFI). These are defined as follows: </t> <ul spacing="normal"> <li>VI is a time interval during which at least one of the performance parameters degraded below its configurable optimallevelthreshold.</li> <li>SVI is a time interval during which at least one of the performance parameters degraded below its configurable critical threshold.</li> <li>Consequently, VFI is a time interval during which all performance parameters are at or better than their respective pre-defined optimallevels. <!-- In such a case, the service is in compliance with its specification. --></li>levels.</li> </ul> <t> The monitoring of performance parameters to determine the quality of an interval is performed between the elements of the network that arereferred to foridentified in the SLO corresponding to the performance parameter. Mechanismsoffor setting levels of a threshold of an SLO are outside the scope of this document. </t> <t> Fromthese definitions,the definitions above, a set of basic metrics can be defined that count thenumbersnumber of time intervals that fall into each category: </t> <ul spacing="normal"> <li>VIcount.count </li> <li>SVIcount.count </li> <li>VFIcount.count </li> </ul> <t> These count metrics are essential in calculating respective ratios (see <xref target="derived-ep-metrics-section"/>) that can be used to assess the instability of a service. </t> <t> Beyond accounting for violated intervals, it is sometimes beneficial to maintain counts of packets for which a performance threshold is violated. For example, this allows for distinguishing between cases in which violated intervals are caused by isolated violation occurrences (suchas,as a sporadic issue that may be caused by a temporary spike in a queue depth along the packet's path) or by broad violations across multiple packets (such as a problem with slow route convergence across the network or more foundational issues such as insufficient network resources). Maintaining such counts and comparing them with the overall amount of traffic alsofacilitatesfacilitate assessing compliance with statistical SLOs (see <xref target="statistical-slo-section"/>). For these reasons, the following additional metrics are defined: </t> <ul spacing="normal"><li>VPC: Violated packets count<li>VPC (Violated Packets Count) </li><li>SVPC: Severely violated packets count<li>SVPC (Severely Violated Packets Count) </li> </ul> </section> <section anchor="derived-ep-metrics-section" numbered="true" toc="default"> <name>Derived Precision Availability Metrics</name> <t> A set of metrics can be created based onPAMPAMs as introduced in<xref target="ep-metrics-section"/>.this document. In this document, these metrics are referred to as "derivedPAM".PAMs". Some of these metrics are modeled after Mean Time Between Failure (MTBF)metrics -metrics; a "failure" in this contextreferringrefers to a failure to deliver a service according to its SLO. </t> <ul spacing="normal"> <li> Time since the last violated interval (e.g., since last violatedms,ms or since last violated second).(ThisThis parameter is suitable for monitoring the current compliance status of the service, e.g., for trendinganalysis.)analysis. </li> <li> Number of packets since the last violated packet.(ThisThis parameter is suitable for the monitoring of the current compliance status of theservice.)service. </li> <li> Mean time between VIs (e.g., between violatedmilliseconds,milliseconds or between violatedseconds)seconds). This parameter is the arithmetic mean of time between consecutive VIs. </li> <li> Mean packets betweenVIsVIs. This parameter is the arithmetic mean of the number of SLO-compliant packets between consecutive VIs.(AnotherIt is another variation of"MTBF"MTBF in a servicesetting.)setting. </li> </ul> <t>An analogous set of metrics can be produced for SVI:</t> <ul spacing="normal"> <li> Time since the last SVI (e.g., since last violatedms,ms or since last violated second).(ThisThis parameter is suitable for the monitoring of the current compliance status of theservice.)service. </li> <li> Number of packets since the last severely violated packet.(ThisThis parameter is suitable for the monitoring of the current compliance status of theservice.)service. </li> <li> Mean time between SVIs (e.g., between severely violatedmilliseconds,milliseconds or between severely violatedseconds)seconds). This parameter is the arithmetic mean of time between consecutive SVIs. </li> <li> Mean packets betweenSVIsSVIs. This parameter is the arithmetic mean of the number of SLO-compliant packets between consecutive SVIs.(AnotherIt is another variation of "MTBF" in a servicesetting.)setting. </li> </ul> <t> To indicate a historic degree of precision availability, additional derived PAMs can be defined as follows: </t> <ul spacing="normal"> <li> Violated Interval Ratio (VIR) is the ratio of the summed numbers of VIs and SVIs to the total number of time unit intervals in a time of the availability periods during a fixed measurement session. </li> <li> Severely Violated Interval Ratio (SVIR) is the ratio of SVIs to the total number of time unit intervals in a time of the availability periods during a fixed measurement session. </li> </ul> </section> <section anchor="policy-section" numbered="true" toc="default"> <name>PAM Configuration Settings and Service Availability</name> <t> It might be useful for a service provider to determine the current condition of the service for which PAMs are maintained. To facilitate this, it is conceivable to complementPAMPAMs with a state model. Such a state model can be used to indicate whether a service is currently considered as available or unavailable depending on the network's recent ability to provide service without incurring intervals during which violations occur. It is conceivable to define such a state model in which transitions occur per some predefined PAM settings. </t> <t> While the definition of a service state model is outside the scope of this document,the followingthis section provides some considerations for how such a state model and accompanying configuration settings could be defined. </t> <t>For example, a state model could be defined by a Finite State Machine featuring twostates,states: "available" and "unavailable". The initial state could be "available". A service could subsequently be deemed as "unavailable" based on the number of successive interval violations that have been experienced up to the particular observation time moment. To return to a state of "available", a number of intervals without violations would need to be observed. </t> <t> The number of successive intervals with violations, as well as the number of successive intervals that are free of violations, required for a state to transition to another state is defined by a configuration setting. Specifically, the following configuration parameters are defined: </t><ul<dl newline="false" spacing="normal"><li>Unavailability threshold: The<dt>Unavailability threshold:</dt><dd>The number of successive intervals during which a violation occurs to transition to an unavailable state.</li> <li>Availability threshold: The</dd> <dt>Availability threshold:</dt><dd>The number of successive intervals during which no violations must occur to allow transition to an available state from a previously unavailable state.</li> </ul></dd> </dl> <t> Additional configuration parameters could be defined to account for the severity of violations. Likewise, it is conceivable to define configuration settings that also take VIR and SVIR into account. </t> </section> </section> <section anchor="statistical-slo-section" numbered="true" toc="default"> <name>Statistical SLO</name> <t> It should be noted that certain SLAs may be statistical, requiring the service levels of packets in a flow to adhere to specific distributions. For example, an SLA might state that any given SLO applies to at least a certain percentage of packets, allowing for a certain level of, for example, packet loss and/or exceeding packet delay threshold to take place. Each such event, in that case, does not necessarily constitute an SLO violation. However, it is still useful to maintain those statistics, as the number of out-of-SLO packets still matters when looked at in proportion to the total number of packets. </t> <t> Along that vein, an SLA might establish a multi-tiered SLO of, say, end-to-end latency (from the lowest to highest tier) as follows: </t> <ul spacing="normal"> <li>not to exceed 30 ms for any packet;</li><li>to not<li>not to exceed 25 ms for 99.999% ofpackets;</li> <li>to notpackets; and</li> <li>not to exceed 20 ms for 99% of packets.</li> </ul> <t> In that case, any individual packet with a latency greater than 20 ms latency and lower than 30 ms cannot be considered an SLO violation in itself, but compliance with the SLO may need to be assessed after the fact. </t> <t> To support statistical SLOs more directly requires additional metrics, for example, metrics that represent histograms forservice levelservice-level parameters with buckets corresponding to individualservice level objectives.SLOs. Although the definition of histogram metrics is outside the scope of this document and could be considered for future work (see <xreftarget="for-discussion"/>,target="for-discussion"/>), for the example just given, a histogram for a particular flow could be maintained with four buckets: one containing the count of packets within 20 ms, a second with a count of packets between 20 and 25 ms (or simply all within 25 ms), a third with a count of packets between 25 and 30 ms (or merely all packets within 30ms,ms), and a fourth with a count of anything beyond (or simply a total count). Of course, the number of buckets and the boundaries between those buckets should correspond to the needs of the SLA associated with the application, i.e., to the specific guarantees and SLOs that were provided. </t> </section> <section anchor="other" numbered="true" toc="default"> <name>Other Expected PAM Benefits </name> <t>PAM providesPAMs provide several benefits with other, more conventional performance metrics. WithoutPAM,PAMs, it would be possible to conduct ongoing measurements of servicelevels andlevels, maintain atime-seriestime series ofservice levelservice-level records, and then assess compliance with specific SLOs after the fact. However, doing so would require the collection of vast amounts of data that would need to be generated, exported, transmitted, collected, and stored. In addition, extensivepostprocessingpost-processing would be required to compare that data against SLOs and analyze its compliance. Being able to perform these tasks at scale and inreal-timereal time would present significant additional challenges. </t> <t> AddingPAMPAMs allows for a more compact expression ofservice levelservice-level compliance. In that sense,PAM doesPAMs do not simply represent raw data but expresses actionable information. In conjunction with proper instrumentation,PAMPAMs can thus help avoid expensivepostprocessing.post-processing. </t> </section> <section anchor="for-discussion" numbered="true" toc="default"> <name>Extensions and Future Work</name><!-- <li>Terminology - "Errored" vs. "Violated". The key metrics defined in this draft refer to intervals during which violations of objectives for service level parameters occur as "violated". The term "errored" was chosen in continuity with the concept of "errored seconds", often used in transmission systems. However, "violated" may be a more accurate term, as the metrics defined here are not "errors" in an absolute sense, but relative to a set of defined objectives. </li> --><t> The following is a list of items that are outside the scope of thisspecification,specification butwhichwill be useful extensions and opportunities for future work: </t> <ul spacing="normal"> <li>A YANG data model will allowPAMPAMs to be incorporated into monitoring applications based on theYANG/NETCONF/RESTCONF framework.YANG, NETCONF, and RESTCONF frameworks. In addition, a YANG data model will enable the configuration and retrieval of PAM-related settings. </li> <li>A set of IPFIX Information Elements will allowPAMPAMs to be associated with flow records and exported as part of flow data, for example, for processing by accounting applications that assess compliance of delivered services with quality guarantees. </li> <li>Additional second-order metrics, such as "longest disruption of service time" (measuring consecutive time units with SVIs), can be defined and would be deemed useful by some users. At the same time, such metrics can be computed in a straightforward manner and will be application specific in manycases be application-specific.cases. For this reason,furthersuch metrics are omitted here in order to not overburden this specification. </li><li>The definition of the metrics that<li>Metrics can be defined to represent histograms forservice levelservice-level parameters with buckets corresponding to individualservice level objectives,</li>SLOs.</li> </ul> </section> <section anchor="iana-consider" numbered="true" toc="default"> <name>IANA Considerations</name> <t>This document has no IANA actions.</t> </section> <section anchor="security" numbered="true" toc="default"> <name>Security Considerations</name> <t> Instrumentation for metrics that are used to assess compliance with SLOsconstituteconstitutes an attractive target for an attacker. By interfering with the maintenance of such metrics, services could be falsely identified as complying (when they are not) orvice-versavice versa (i.e., flagged as being non-compliant when indeed they are). While this document does not specify how networks should be instrumented to maintain the identified metrics, such instrumentation needs to be adequately secured to ensure accurate measurements and prohibit tampering with metrics being kept. </t> <t> Where metrics are being defined relative to an SLO, the configuration of those SLOs needs to be adequately secured. Likewise, where SLOs can be adjusted, the correlation between any metric instance and a particular SLO must be unambiguous. The same service levels that constitute SLO violations for one flowthatand should be maintained as part of the "violated time units" and relatedmetrics,metrics may be compliant for another flow. In cases when it is impossible to tie together SLOs andPAM,PAMs, itwill beis preferable to merely maintain statistics about service levels delivered (for example, overall histograms of end-to-end latency) without assessing whichconstitutesconstitute violations. </t> <t> By the same token,wherethe definition of what constitutes a "severe" or a "significant" violation depends on configuration settings or context. The configuration of such settings or context needs to be specially secured. Also, the configuration must be bound to the metrics being maintained. Thus, it will be clear which configuration setting was in effect when those metrics were being assessed. An attacker that can tamper with such configuration settings will render the corresponding metrics useless (in the best case) or misleading (in the worst case). </t> </section><section numbered="true" toc="default"> <name>Acknowledgments</name> <t> The authors greatly appreciate review and comments by Bjørn Ivar Teigen and Christian Jacquenet. </t> </section></middle> <back> <references><name>References</name> <!-- <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <?rfc include="reference.RFC.8126"?> <?rfc include="reference.RFC.4656"?> <?rfc include="reference.RFC.6038"?> </references> --> <references><name>Informative References</name><!-- <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/><xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8762.xml"/> --> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2863.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8343.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2863.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7011.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8343.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7012.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7011.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7297.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7012.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3198.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7297.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8911.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3198.xml"/> <xi:includehref="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8912.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8911.xml"/> <xi:includehref="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-teas-ietf-network-slices.xml"/>href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8912.xml"/> <!--<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-mmm-rtgwg-integrated-oam.xml"/>[I-D.ietf-teas-ietf-network-slices] in EDIT state as of 12/18/23; companion document RFC9543 --> <reference anchor="RFC9543" target="https://www.rfc-editor.org/info/rfc9543"> <front> <title>A Framework for Network Slices in Networks Built from IETF Technologies</title> <author initials="A." surname="Farrel" fullname="Adrian Farrel" role="editor"> <organization>Old Dog Consulting</organization> </author> <author initials="J." surname="Drake" fullname="John Drake" role="editor"> <organization>Juniper Networks</organization> </author> <author initials="R." surname="Rokui" fullname="Reza Rokui"> <organization>Ciena</organization> </author> <author initials="S." surname="Homma" fullname="Shunsuke Homma"> <organization>NTT</organization> </author> <author initials="K." surname="Makhijani" fullname="Kiran Makhijani"> <organization>Futurewei</organization> </author> <author initials="L." surname="Contreras" fullname="Luis M. Contreras"> <organization>Telefonica</organization> </author> <author initials="J." surname="Tantsura" fullname="Jeff Tantsura"> <organization>Nvidia</organization> </author> <date month="February" year="2024"/> </front> <seriesInfo name="RFC" value="9543"/> <seriesInfo name="DOI" value="10.17487/RFC9543"/> </reference> <reference anchor="ITU.G.826"> <front> <title>End-to-end error performance parameters and objectives for international, constant bit-rate digital paths and connections</title> <author> <organization>ITU-T</organization> </author> <date month="December" year="2002"/> </front> <seriesInfo name="ITU-T" value="G.826"/> </reference> <reference anchor="IANA-PM-Registry"target="https://www.iana.org/assignments/performance-metrics/performance-metrics.xhtml">target="https://www.iana.org/assignments/performance-metrics"> <front><title>IANA Registry of Performance<title>Performance Metrics</title> <author> <organization>IANA</organization> </author><date month="March" year="2020"/></front> </reference> </references></references><section numbered="false" toc="default"> <name>Acknowledgments</name> <t> The authors greatly appreciate review and comments by <contact fullname="Bjørn Ivar Teigen"/> and <contact fullname="Christian Jacquenet"/>. </t> </section> <section anchor="contr-sec" numbered="false" toc="default"><name>Contributors' Addresses</name><name>Contributors</name> <contact fullname="Liuyan Han" initials="L." surname="Han"> <organization>China Mobile</organization> <address> <postal> <street>32 XuanWuMenXi Street</street> <city>Beijing</city> <code>100053</code> <country>China</country> </postal> <email>hanliuyan@chinamobile.com</email> </address> </contact> <contact fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> <organization>Orange</organization> <address> <postal> <street>35000 Rennes</street> <city/> <code/> <country>France</country> </postal> <email>mohamed.boucadair@orange.com</email> </address> </contact> <contact fullname="Adrian Farrel" initials="A." surname="Farrel"> <organization>Old Dog Consulting</organization> <address> <postal> <street/> <city/> <code/> <country>United Kingdom</country> </postal> <email>adrian@olddog.co.uk</email> </address> </contact> </section> </back> </rfc>