RFC 8316

Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations

📅 published February 2018, from ietf

Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations 🦋

okay bestie, this one is RFC 8316 💖 It's an Informational doc from the IRTF (the research side of the Internet, not a standard 💅). It was published in February 2018 and has the ISSN 2070-1721. It's a product of the IRTF Network Management Research Group (NMRG).

The authors are J. Nobre (University of Vale do Rio dos Sinos), L. Granville (Federal University of Rio Grande do Sul), A. Clemm (Huawei), and A. Gonzalez Prieto (VMware) 🧚. The header has no Obsoletes or Updates line, so this RFC doesn't replace or update any earlier RFCs. Totally standalone 🌸

Abstract ✨

ngl this one is a whole vibe 🔥 It describes an experimental use case where autonomic networking watches over Service Level Agreements (SLAs). The goal is catching SLA violations in a distributed way, so no single boss box does all the work 👑

The clever part is how it handles active measurement probes. The system optimizes and dynamically adapts where those probes get deployed, so it's as likely as possible to catch service-level violations while staying inside a set resource budget for active measurements. And the big flex? All of this optimizing and adapting should happen without any outside guidance or intervention. Self-driving network energy 🤖💅

This document is a product of the IRTF Network Management Research Group (NMRG). It's published purely for informational purposes 🌈

Status of This Memo 💜

Okay, the status stuff, bestie 📝 This document is not an Internet Standards Track spec. It's published for informational purposes only 🎀

It's an IRTF product. The IRTF shares results of Internet-related research and development, and those results might not be suitable for deployment 😭 This RFC reflects the consensus of the Network Management Research Group of the IRTF. Documents the IRSG approves for publication are not candidates for any level of Internet Standard. For the details, check Section 2 of RFC 7841 🙈

Want the current status, any errata, or a way to send feedback? Head to https://www.rfc-editor.org/info/rfc8316 🦋

Legal stuff, but make it cute 💅 The copyright line reads:

Copyright (c) 2018 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can read at https://trustee.ietf.org/license-info, as they stand on the publication date. Please read those carefully, bestie, because they spell out your rights and restrictions for this document 🫶

Table of Contents 🌸

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Definitions and Acronyms  . . . . . . . . . . . . . . . . . .   5
   3.  Current Approaches  . . . . . . . . . . . . . . . . . . . . .   6
   4.  Use Case Description  . . . . . . . . . . . . . . . . . . . .   7
   5.  A Distributed Autonomic Solution  . . . . . . . . . . . . . .   8
   6.  Intended User Experience  . . . . . . . . . . . . . . . . . .  10
   7.  Implementation Considerations . . . . . . . . . . . . . . . .  11
     7.1.  Device-Based Self-Knowledge and Decisions . . . . . . . .  11
     7.2.  Interaction with Other Devices  . . . . . . . . . . . . .  11
   8.  Comparison with Current Solutions . . . . . . . . . . . . . .  12
   9.  Related IETF Work . . . . . . . . . . . . . . . . . . . . . .  12
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  13
   12. Informative References  . . . . . . . . . . . . . . . . . . .  13
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1. Introduction ✨

Okay so the Internet has been absolutely blowing up lately 🌈. It's way bigger, faster, and more accessible than it used to be, and the apps running on top of it are getting seriously demanding. Think real-time interactive video or financial trading, where latency, loss, and jitter all have to be on point or everything falls apart 😭.

Performance demands lead to Service Level Objectives (SLOs) that must be met 💅. Those SLOs live inside Service Level Agreements (SLAs), which are basically a contract between the provider and the consumer of a service. An SLO is a service-level guarantee the consumer can expect to receive, and they often have to pay for it too. The provider, meanwhile, has to make sure that guarantee and its SLOs actually get met. You can find some examples of SLO-related clauses in [RFC7297] 📜.

Breaking SLOs can cost a lot of money, and it hits two groups. First, the user gets hurt when the agreed service levels don't show up. A brokerage's stock orders can lose money if they can't go through in time. An online store can lose customers if the site feels sluggish. An online game can be unfair to its players, and those frustrated players just leave 🎮💔. Either way, when a provider fails to deliver the promised guarantees, users can take a real financial hit. Second, the provider takes a loss when it can't meet the promised SLOs. That can mean penalties under the SLA and even losing future revenue because customers are less happy, which honestly is often the bigger problem 😬. So SLOs are a top priority for providers. To keep them from being violated, service levels have to be watched continuously at the network infrastructure layer, so you know when to take mitigating actions. That's why service-level measurements have to happen 📊.

Network measurements can be done with active or passive techniques 🔍. With passive measurements, you just watch production traffic, and the measurement process doesn't create any monitoring traffic of its own. Basically, you check on the network without bugging it 🦋. The IP Flow Information Export (IPFIX) work produced several documents about how to export flow record data, which is data collected by passive measurement mechanisms and usually applied to flows of production traffic (for example, [RFC7011]). You can also collect real data traffic, not just summarized flow records, using time-stamped packets, possibly sampled (for example, per [RFC5474]). That's another way to measure and infer service levels 💜.

Active measurements are the more intrusive ones, because they inject synthetic test traffic into the network to measure service levels, instead of just observing what's already there 💉. The IP Performance Metrics (IPPM) Working Group wrote documents about active mechanisms like the One-Way Active Measurement Protocol (OWAMP) [RFC4656], the Two-Way Active Measurement Protocol (TWAMP) [RFC5357], and the Cisco Service-Level Assurance Protocol [RFC6812]. Then there are some mechanisms that don't fit neatly in either bucket, like the Performance and Diagnostic Metrics (PDM) Destination Option techniques [RFC8250] 🤷‍♀️.

Active measurements give you a ton of control over what you measure and how. They don't need to look at production traffic, so they're usually more accurate and more private than passive ones. Encrypted traffic and rules that limit payload inspection aren't a problem for them at all 🔐✨. They can also catch end-to-end performance problems in a really fine-grained way, like simulating the exact traffic that has to be handled for specific SLOs. That's why active measurements are often the go-to for SLA monitoring 👑. Measurement probes have to be hosted in network devices, and measurement sessions have to be activated to compute the current network metrics. For examples of those metrics, see [RFC4148], though note that [RFC4148] was obsoleted by [RFC6248] 📚. Activation should be dynamic too, so it can keep up with changing network conditions, like new routes being added or new customer demands showing up 🔄.

The downside is that active measurements are expensive in terms of network resources 💸. Usually a probe generates synthetic test traffic and sends it to a responder. The responder has to timestamp the test traffic it receives and reflect it back to the probe. The probe then processes the returned packets along with the timestamp information to compute service levels. So active measurements burn a lot of CPU cycles and device memory on both generating and processing that traffic, and the synthetic traffic adds load to the network too. That means active measurements end up competing with other functions, including routing and switching 🥵.

How many resources the active sessions use, and how much traffic they generate, mostly depends on how many network destinations you're measuring. (The amount of traffic per measurement also matters, since it affects accuracy.) More destinations means more resources and more traffic. So if you want better monitoring coverage, you need more sessions, and that eats up even more resources. If you skip that and only observe a small subset of network flows, your coverage can end up really thin 🕸️.

Also, some end-to-end service levels can be figured out by adding up the service levels observed across different path segments, but not all of them 🧩. For example, the end-to-end delay or packet loss from a node A to a node C routed via a node B can often be computed by simply adding up the delays (or losses) from A to B and from B to C. That means you can break a big set of end-to-end measurements down into a much smaller set of segment measurements. End-to-end jitter and mean opinion scores don't break down that easily, though. For better accuracy, they have to be measured end-to-end 🎯.

So deciding where to place measurement probes is a big management job 🧠. The goal is to get the most out of service-level monitoring while keeping measurement overhead limited. Specifically, you want to maximize the number of service-level violations you detect with a limited number of resources 💪.

The use case and solution approach in this document tackle a real, practical problem 🙌. They're meant to be a starting point for more experiments, which can lead to solutions that are ready for wider deployment. This document reflects the consensus of the IRTF's Network Management Research Group (NMRG). It was discussed extensively and got three separate in-depth reviews 🫶.

2. Definitions and Acronyms

  • Active Measurements: Techniques to measure service levels that involve generating and observing synthetic test traffic
  • Passive Measurements: Techniques used to measure service levels based on observation of production traffic
  • Autonomic Network: A network containing exclusively autonomic nodes, requiring no configuration, and deriving all required information through self-knowledge, discovery, or intent.
  • Autonomic Service Agent (ASA): An agent implemented on an autonomic node that implements an autonomic function, either in part (in the case of a distributed function, as in the context of this document) or whole
  • Measurement Session: A communications association between a probe and a responder used to send and reflect synthetic test traffic for active measurements
  • Probe: The source of synthetic test traffic in an active measurement
  • Responder: The destination for synthetic test traffic in an active measurement
  • SLA: Service Level Agreement
  • SLO: Service Level Objective
  • P2P: Peer-to-Peer

(Note: The definitions for "Autonomic Network" and "Autonomic Service Agent" are borrowed from [RFC7575]). 🦋

3. Current Approaches

Okay so, for active measurement solutions to actually be deployable, the sessions have to be spread out along the network. Right now, the best practice is to rely entirely on the human administrator's expertise to figure out the best place to activate those sessions 🧑‍💻. It goes in steps. First, you have to collect traffic information so you can get a grip on the traffic matrix. Then the admin uses that info to pick the best destinations for measurement sessions. After that, they activate sessions on the chosen subset of destinations, while keeping the available resources in mind 📋.

This doesn't scale, though, because it's labor intensive and easy to mess up. The admin has to figure out which sessions to turn on for the critical flows that need measuring, and that's a lot to juggle by hand 😵‍💫. It's even worse in networks where the most critical flows change fast, because the most important destinations keep shifting. Modern cloud environments are a good example of that 🌩️. Fast reactions are needed to reconfigure sessions, and admins just aren't quick enough to work out and activate the new set of required sessions every time traffic patterns change. Finally, current active measurement practice usually covers only a fraction of the network flows that should be observed. That invariably leads to the damaging result of undetected SLA violations 💀.

4. Use Case Description ✨

okay so bestie, picture this 🔍 a service-level provider needs to keep an eye on the network so they can catch service-level violations using active service-level measurements, and they want to do it with minimal human intervention 🫶 the goal is to run measurements super effectively so they catch as many violations as possible. the tea is that they have a bounded resource budget 💅 that means a cap on how many measurements can run at once from any one network device, and maybe a cap on the total measurement traffic on the network too. but even though only so many measurements can run at one time, a device can switch up which destinations it measures over time 🦋 so the move is to eventually cover every destination with a reasonable amount of "sampling," even though continuous coverage of any one destination isn't happening. the solution has to be dynamic and able to handle network conditions that keep changing 🌈 and it should also be embeddable inside the network devices that control how active measurement mechanisms get deployed. literally so main character 👑

the whole vibe is doing this smart so the network stays broadly covered and the odds of catching violations are as high as possible ✨ to boost those odds, it makes sense to focus resources on destinations that are more likely to violate, and spend less on destinations that are probably behaving 💖 there are a few things you can use for this. past measurements matter, because destinations sitting close to a service-level threshold need more attention than ones way farther from it 🎀 you can also mix in passive measurements like flow data 🌸 to spot which destinations are popular and critical right now. and observations from other parts of the network help too 🧚 on top of that, devices can coordinate their measurements so they don't all hit the same destination at the same time, and they can share results that might be useful for placing probes later 🍓

ngl static solutions are going to have severe limitations 💀 and humans can't be in the loop for continuous, dynamic reconfigurations of measurement probes either 😭 so you need an automated solution, or ideally an autonomic one, so measurements get orchestrated automatically and reconfigured dynamically from inside the network itself 🔥 the way to pull this off is an autonomic solution that's distributed, using ASAs implemented on nodes in the network 💜

5. A Distributed Autonomic Solution 🦋

okay so Autonomic Networking (AN) [RFC7575] can really help with detection by activating measurement sessions efficiently 🫶 there's a whole approach for this, plus a detailed assessment confirming it's viable, written up in [P2PBNM-Nobre-2012] 📚 the problem AN has to solve in this use case is how to steer the activation of measurement sessions with a complete solution that sets every parameter needed for activation to run efficiently, reliably, and securely 🔐 and it has to do all this with no required human intervention beyond setting overall policy 💅

when a node first comes online, it has zero clue which measurements are more critical than others 🙈 without info about past measurements or from measurement peers, it might kick off with an initial set of sessions, maybe randomly seeding some starter measurements and perhaps going round-robin for later rounds 🌀 but as measurements come in, the node picks up more and more info it can use to refine how it picks targets going forward ✨ for one, it can take note of which targets returned results really close to service-level thresholds 👀 those targets may need closer scrutiny than the rest. second, it can use what its measurement peers observe to figure out which targets are more critical, and to make sure overall coverage is actually proper 🧩 so you don't end up with every node accidentally measuring the same targets while other targets never get measured at all 💀

we're advocating for embedding P2P technology in network devices 🌸 so they can use autonomic control loops to make decisions about measurement sessions 🔁

specifically, we're advocating for network devices to run an autonomic function that monitors service levels for SLO violations 🚨 and decides which measurement sessions to set up at any given moment, based on current and past observations from the node itself and from other peer nodes 🧠

when the device does all this locally and autonomically, it can change which measurements it conducts super quickly based on local observations 🏃‍♀️💨 and it takes local resource availability into account too 🎀 this makes the solution more robust, and it reacts more dynamically to rapidly changing service levels than a solution that has to rely on central coordination 💖 that said, to optimize decisions about which measurements to conduct, a node still needs to talk to other nodes 🫂 that way it can factor in other nodes' observations alongside its own.

for example, remote destinations whose service levels are on the verge of violating stated objectives may need closer monitoring than remote destinations that are comfortably within a range of tolerance 👀 a distributed autonomic solution also lets nodes coordinate their probing decisions to collectively achieve the best possible measurement coverage 🤝 and since resources for monitoring, exchanging measurement data, and coordinating with other nodes are limited, a node may want to figure out which other nodes have observations that are similar to and correlated with its own 🧐 that helps it prioritize which nodes to coordinate and exchange data with 💅 all of this needs a P2P overlay 🕸️

a P2P overlay is essential for a few reasons:

  • it makes it possible for nodes (or more specifically, the ASAs deployed on those nodes) to autonomically set up measurement sessions without relying on a central management system or controller to do the configuration work for measurement probes and responders 🙌
  • it makes data exchange between nodes possible, so they can share measurement results and refine their strategy based not just on their own observations, but also on observations from their peers 🔄
  • it lets nodes coordinate their measurements to get the best possible test coverage, and to avoid measurements that have a very low likelihood of detecting service-level violations 🎯

the P2P overlay's provisioning should be transparent for the network administrator 🫶 and an Autonomic Control Plane such as the one defined in [ACP] is an ideal candidate for the overlay to run on 🌈

an autonomic solution for the distributed detection of SLA violations brings several benefits 💜 first up, efficiency 🔋 this solution should optimize resource consumption and avoid resource starvation on network devices. a device that's "self-aware" of its available resources can adjust measurement activities rapidly as needed, without needing a separate control loop that involves resource monitoring by an external system 🧘‍♀️ second, putting the logic about where to conduct measurements inside the node enables rapid control loops, so devices can react instantly to observations and adjust their strategy ⚡ for example, a device could decide to change the amount of synthetic test traffic it sends during the measurement itself, depending on results observed so far in this and other concurrent measurement sessions 🎛️ as a result, the solution could cut down the time it takes to detect SLA violations ⏱️ adaptivity features of an autonomic loop could capture network dynamics faster than a human administrator, or even a central controller 🚀 and finally, the solution could help reduce the workload of human administrators 🥹

so yeah, these factors combine to maximize the likelihood of SLA violations being detected while staying inside a given resource budget ✨ it allows a continuous measurement strategy that takes past measurement results into account, along with other measures like link utilization or flow data, results shared between network devices, and future measurement activities coordinated among nodes 🧩 put together, this can produce efficient measurement decisions that hit a golden balance between broad network coverage and honing in on service-level "hot spots" 🔥🏆

6. Intended User Experience 🎀

the autonomic solution shouldn't need any human intervention in the distributed detection of SLA violations 🙅‍♀️ because the solution is autonomic, humans won't have to plan which measurements to conduct in the network 😌 which is honestly a super labor-intensive task that needs detailed analysis of traffic matrices and network topologies, and it isn't easy to adjust dynamically 😩 and they won't have to configure measurement probes and responders either 💖

that said, a human admin still gets to interact with the solution in a couple of ways 👑 first, the admin will definitely be notified, and gets reports, about the service-level violations that get observed 📬 second, an admin can set policies about how closely to monitor the network for service-level violations and how many resources to spend 🎚️ for example, an admin might set a resource budget that gets assigned to network devices for measurement operations 💰 with that budget, the number of SLO violations detected will be maximized 📈 or, an admin can set a target for the percentage of SLO violations that must be detected, meaning a target for the ratio between the number of detected SLO violations and the total number of SLO violations actually occurring (some of which might go undetected) 🧐 in that case, the solution will aim to minimize the resources spent, meaning the amount of test traffic and number of measurement sessions, that are needed to hit that target 🌸

  1. Implementation Considerations 💅✨

The active measurement model assumes that a typical infrastructure will have multiple network segments, multiple Autonomous Systems (ASes), and a reasonably large number of routers. It also considers that multiple SLOs can be in place at a given time. Since interoperability in a heterogeneous network is a goal, features found on different active measurement mechanisms (e.g., OWAMP, TWAMP, and Cisco Service Level Assurance Protocol) and device programmability interfaces (such as Juniper's Junos API or Cisco's Embedded Event Manager) could be used for the implementation. The autonomic solution should include and/or reference specific algorithms, protocols, metrics, and technologies for the implementation of distributed detection of SLA violations as a whole. 🧚

Finally, it should be noted that there are multiple deployment scenarios, including deployment scenarios that involve physical devices hosting autonomic functions or virtualized infrastructure hosting the same. Co-deployment in conjunction with Virtual Network Functions (VNFs) is a possibility for further study. 🌈

7.1. Device-Based Self-Knowledge and Decisions 🧠

Each device has self-knowledge about the local SLA monitoring. This could be in the form of historical measurement data and SLOs. Besides that, the devices would have algorithms that could decide which probes should be activated at a given time. The choice of which algorithm is better for a specific situation would be also autonomic. 💖

7.2. Interaction with Other Devices 🤝

Network devices should share information about service-level measurement results. This information can speed up the detection of SLA violations and increase the number of detected SLA violations. For example, if one device detects that a remote destination is in danger of violating an SLO, other devices may conduct additional measurements to the same destination or other destinations in its proximity. For any given network device, the exchange of data may be more important with some devices (for example, devices in the same network neighborhood or devices that are "correlated" by some other means) than with others. Defining the network devices that exchange measurement data (i.e., management peers) creates a new topology. Different approaches could be used to define this topology (e.g., correlated peers [P2PBNM-Nobre-2012]). To bootstrap peer selection, each device should use its known neighbors (e.g., FIB and RIB tables) as initial seeds to identify possible peers. It should be noted that a solution will benefit if topology information and network discovery functions are provided by the underlying autonomic framework. A solution will need to be able to discover measurement peers as well as measurement targets, specifically measurement targets that support active measurement responders and that will be able to respond to measurement requests and reflect measurement traffic as needed. 🦋

8. Comparison with Current Solutions 🔍

There is no standardized solution for distributed autonomic detection of SLA violations. Current solutions are restricted to ad hoc scripts running on a per-node fashion to automate some administrator actions. There are some proposals for passive probe activation (e.g., DECON [DECON] and CSAMP [CSAMP]), but these do not focus on autonomic features. 🙈

This section discusses related IETF work and is provided for reference. This section is not exhaustive; rather, it provides an overview of the various initiatives and how they relate to autonomic distributed detection of SLA violations. 🎀

  1. LMAP: The Large-Scale Measurement of Broadband Performance Working Group standardizes the LMAP measurement system for performance management of broadband access devices. The autonomic solution could be relevant to LMAP because it deploys measurement probes and could be used for screening for SLA violations. Besides that, a solution to decrease the workload of human administrators in service providers is probably highly desirable. 👑
  2. IPFIX: IP Flow Information Export (IPFIX) Working Group (now concluded) aimed to standardize IP flows (i.e., netflows). IPFIX uses measurement probes (i.e., metering exporters) to gather flow data. In this context, the autonomic solution for the activation of active measurement probes could possibly be extended to also address passive measurement probes. Besides that, flow information could be used in making decisions regarding probe activation. 🌸
  3. ALTO: The Application-Layer Traffic Optimization Working Group aims to provide topological information at a higher abstraction layer, which can be based upon network policy, and with application-relevant service functions located in it. Their work could be leveraged to define the topology for network devices that exchange measurement data. ⭐

10. IANA Considerations 🧾

This document has no IANA actions. 🫶

11. Security Considerations 🚨

The security of this solution hinges on the security of the network underlay, i.e., the Autonomic Control Plane. If the Autonomic Control Plane were to be compromised, an attacker could undermine the effectiveness of measurement coordination by reporting fraudulent measurement results to peers. This would cause measurement probes to be deployed in an ineffective manner that would increase the likelihood that violations of SLOs go undetected. 😭

Likewise, the security of the solution hinges on the security of the deployment mechanism for autonomic functions (in this case, the autonomic function that conducts the service-level measurements). If an attacker were able to hijack an autonomic function, it could try to exhaust or exceed the resources that should be spent on autonomic measurements in order to deplete network resources, including network bandwidth due to higher-than-necessary volumes of synthetic test traffic generated by measurement probes. Again, it could also lead to reporting of misleading results; among other things, this could result in non-optimal selection of measurement targets and, in turn, an increase in the likelihood that service-level violations go undetected. 💀

Bestie, this part is dead serious. Hijacked autonomic functions and forged results can quietly make SLA violations invisible, so the underlay and deployment mechanisms need real protection. 🔥

12. Informative References 📖

[ACP] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An Autonomic Control Plane (ACP)", Work in Progress, draft-ietf-anima-autonomic-control-plane-13, December 2017.

[CSAMP] Sekar, V., Reiter, M., Willinger, W., Zhang, H., Kompella, R., and D. Andersen, "CSAMP: A System for Network-Wide Flow Monitoring", NSDI USENIX Symposium Networked Systems Design and Implementation, April 2008.

[DECON] di Pietro, A., Huici, F., Costantini, D., and S. Niccolini, "DECON: Decentralized Coordination for Large- Scale Flow Monitoring", IEEE INFOCOM Workshops, DOI 10.1109/INFCOMW.2010.5466642, March 2010.

[P2PBNM-Nobre-2012] Nobre, J., Granville, L., Clemm, A., and A. Gonzalez Prieto, "Decentralized Detection of SLA Violations Using P2P Technology, 8th International Conference Network and Service Management (CNSM)", 8th International Conference on Network and Service Management (CNSM), 2012, <http://ieeexplore.ieee.org/xpls/ abs_all.jsp?arnumber=6379997>.

[RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August 2005, <https://www.rfc-editor.org/info/rfc4148>.

[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.

[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.

[RFC5474] Duffield, N., Ed., Chiou, D., Claise, B., Greenberg, A., Grossglauser, M., and J. Rexford, "A Framework for Packet Selection and Reporting", RFC 5474, DOI 10.17487/RFC5474, March 2009, <https://www.rfc-editor.org/info/rfc5474>.

[RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics Are Obsolete", RFC 6248, DOI 10.17487/RFC6248, April 2011, <https://www.rfc-editor.org/info/rfc6248>.

[RFC6812] Chiba, M., Clemm, A., Medley, S., Salowey, J., Thombare, S., and E. Yedavalli, "Cisco Service-Level Assurance Protocol", RFC 6812, DOI 10.17487/RFC6812, January 2013, <https://www.rfc-editor.org/info/rfc6812>.

[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/info/rfc7011>.

[RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10.17487/RFC7297, July 2014, <https://www.rfc-editor.org/info/rfc7297>.

[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking: Definitions and Design Goals", RFC 7575, DOI 10.17487/RFC7575, June 2015, <https://www.rfc-editor.org/info/rfc7575>.

[RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, <https://www.rfc-editor.org/info/rfc8250>.

Acknowledgements 🫶🌈

We wish to acknowledge the helpful contributions, comments, and suggestions that were received from Mohamed Boucadair, Brian Carpenter, Hanlin Fang, Bruno Klauser, Diego Lopez, Vincent Roca, and Eric Voit. In addition, we thank Diego Lopez, Vincent Roca, and Brian Carpenter for their detailed reviews. 💜

Authors' Addresses 🌟

Jeferson Campos Nobre University of Vale do Rio dos Sinos Porto Alegre Brazil

Email: jcnobre@unisinos.br

Lisandro Zambenedetti Granvile Federal University of Rio Grande do Sul Porto Alegre Brazil

Email: granville@inf.ufrgs.br

Alexander Clemm Huawei USA - Futurewei Technologies Inc. Santa Clara, California United States of America

Email: ludwig@clemm.org, alexander.clemm@huawei.com

Alberto Gonzalez Prieto VMware Palo Alto, California United States of America

Email: agonzalezpri@vmware.com

📦 where this page comes from