[Search] [txt|xml|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12           Informational
          13 rfc8316                                                    
Network Management Research Group                               J. Nobre
Internet-Draft                       University of Vale do Rio dos Sinos
Intended status: Informational                              L. Granville
Expires: December 10, 2017       Federal University of Rio Grande do Sul
                                                                A. Clemm
                                                      A. Gonzalez Prieto
                                                            June 8, 2017

     Autonomic Networking Use Case for Distributed Detection of SLA


   This document describes a use case for autonomic networking
   concerning monitoring of Service Level Agreements (SLAs).  The use
   case aims to detect violations of SLAs in distributed fashion,
   striving to optimize the autonomic deployment of active measurement
   probes in a way that maximizes the likelihood of detecting service
   level violations without any outside guidance or intervention.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 10, 2017.

Copyright Notice

   Copyright (c) 2017 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
   (http://trustee.ietf.org/license-info) in effect on the date of

Nobre, et al.           Expires December 10, 2017               [Page 1]

Internet-Draft   AN Use Case Detection of SLA Violations       June 2017

   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

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

1.  Introduction

   The Internet has been growing dramatically in terms of size,
   capacity, and accessibility in the last years.  Communication
   requirements of distributed services and applications running on top
   of the Internet have become increasingly demanding.  Some examples
   are real-time interactive video or financial trading.  Providing such
   services involves stringent requirements in terms of acceptable
   latency, loss, or jitter.

   Performance requirements lead to the articulation of Service Level
   Objectives (SLOs) which must be met.  Those SLOs are part of Service
   Level Agreements (SLAs) that define a contract between the provider
   and the consumer of a service.  SLOs, in effect, constitute a service
   level guarantee that the consumer of the service can expect to
   receive (and often has to pay for).  Likewise, the provider of a
   service needs to ensure that the service level guarantee and
   associated SLOs are met.  Some examples of clauses that relate to
   service level objectives can be found in [RFC7297]).

   Violations of SLOs can be associated with significant financial loss,
   which can by divided into two categories.  For one, there is the loss

Nobre, et al.           Expires December 10, 2017               [Page 2]

Internet-Draft   AN Use Case Detection of SLA Violations       June 2017

   that can be incurred by the user of a service when the agreed service
   levels are not provided.  For example, a financial brokerage's stock
   orders might suffer losses when it is unable to execute stock
   transactions in a timely manner.  An electronic retailer may lose
   customers when their online presence is perceived by customers as
   sluggish.  An online gaming provider may not be able to provide fair
   access to online players, resulting in frustrated players who are
   lost as customers.  In each case, the failure of a service provider
   to meet promised service level guarantees can have a substantial
   financial impact on users of the service.  By the same token, there
   is the loss that is incurred by the provider of a service who is
   unable to meet promised service level objectives.  Those losses can
   take several forms, such as penalties for not meeting the service
   and, in many cases more important, loss of revenue due to reduced
   customer satisfaction.  Hence, service level objectives are a key
   concern for the service provider.  In order to ensure that SLOs are
   not being violated, service levels need to be continuously monitored
   at the network infrastructure layer in order to know, for example,
   when mitigating actions need to be taken.  To that end, service level
   measurements must take place.

   Network measurements can be performed using active or passive
   measurement techniques.  In passive measurements, production traffic
   is observed, and no monitoring traffic is created by the measurement
   process itself.  That is, network conditions are checked in a non
   intrusive way.  In the context of IP Flow Information EXport (IPFIX)
   WG, several documents were produced to define passive measurement
   mechanisms (e.g., flow records specification [RFC3954]).  Active
   measurements, on the other hand, are intrusive in the sense that it
   involves injecting synthetic test traffic into the network to measure
   network service levels.  The IP Performance Metrics (IPPM) WG
   produced documents that describe active measurement mechanisms, such
   as: One-Way Active Measurement Protocol (OWAMP) [RFC4656], Two-Way
   Active Measurement Protocol (TWAMP) [RFC5357], and Cisco Service
   Level Assurance Protocol (SLA) [RFC6812].  In addition, there are
   some mechanisms that do not fit into either active or passive
   categories, such as Performance and Diagnostic Metrics Destination
   Option (PDM) techniques [draft-ietf-ippm-6man-pdm-option].

   Active measurement mechanisms offer a high level of control of what
   and how to measure.  They do not require inspecting production
   traffic.  Because of this, active measurements usually offer better
   accuracy and privacy than passive measurement mechanisms.  Traffic
   encryption and regulations that limit the amount of payload
   inspection that can occur are non-issues.  Furthermore, active
   measurement mechanisms are able to detect end-to-end network
   performance problems in a fine-grained way (e.g., simulating the
   traffic that must be handled considering specific Service Level

Nobre, et al.           Expires December 10, 2017               [Page 3]

Internet-Draft   AN Use Case Detection of SLA Violations       June 2017

   Objectives - SLOs).  As a result, active measurements are often
   preferred over passive measurement for SLA monitoring.  Measurement
   probes must be hosted in network devices and measurement sessions
   must be activated to compute the current network metrics (e.g.,
   considering those described in [RFC4148]).  This activation should be
   dynamic in order to follow changes in network conditions, such as
   those related with routes being added or new customer demands.

   While offering many advantages, active measurements are expensive in
   terms of network resource consumption.  Active measurements generally
   involve measurement probes that generate synthetic test traffic that
   is directed at a responder.  The responder needs to timestamp test
   traffic it receives and reflect it back to the originating
   measurement probe.  The measurement probe subsequently processes the
   returned packets along with time stamping information in order to
   compute service levels.  Accordingly, active measurements consume
   substantial CPU cycles as well as memory of network devices to
   generate and process test traffic.  In addition, synthetic traffic
   increases network load.  Active measurements thus compete for
   resources with other functions, including routing and switching.

   The resources required and traffic generated by the active
   measurement sessions are to a large part a function of the number of
   measured network destinations.  (In addition, the amount of traffic
   generated for each measurement plays a role, which in turn influences
   the accuracy of the measurement.)  The more destinations are being
   measured, the larger the amount of resources consumed and traffic
   needed to perform the measurements.  Thus, to have a better
   monitoring coverage it is necessary to deploy more sessions which
   consequently increases consumed resources.  Otherwise, enabling the
   observation of just a small subset of all network flows can lead to
   an insufficient coverage.

   Furthermore, while some end-to-end service levels can be determined
   by adding up the service levels observed across different path
   segments, the same is not true for all service levels.  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 simply by adding delays (or loss)
   from A to B, and B to C.  This allows to decompose a large set of
   end-to-end measurements into a much smaller set of segment
   measurements.  However, end-to-end jitter and (for example) Mean
   Opinion Scores cannot be decomposed as easily and, for higher
   accuracy, must be measured end-to-end.

   Hence, the decision how to place measurement probes becomes an
   important management activity.  The goal is to obtain maximum
   benefits of service level monitoring with a limited amount of
   measurement overhead.  Specifically, the goal is to maximize the

Nobre, et al.           Expires December 10, 2017               [Page 4]

Internet-Draft   AN Use Case Detection of SLA Violations       June 2017

   number of service level violations that are detected with a limited
   amount of resources.

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

   AN: Autonomic Network; a network containing exclusively autonomic
   nodes, requiring no configuration and deriving all required
   inofrmaiton through self-knowledge, discovery, or intent.

   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

   SLA: Service Level Agreement

   SLO: Service Level Objective

   P2P: Peer-to-Peer

3.  Current Approaches

   The current best practice in feasible deployments of active
   measurement solutions to distribute the available measurement
   sessions along the network consists in relying entirely on the human
   administrator expertise to infer which would be the best location to
   activate such sessions.  This is done through several steps.  First,
   it is necessary to collect traffic information in order to grasp the
   traffic matrix.  Then, the administrator uses this information to
   infer which are the best destinations for measurement sessions.
   After that, the administrator activates sessions on the chosen subset
   of destinations considering the available resources.  This practice,
   however, does not scale well because it is still labor intensive and
   error-prone for the administrator to determine which sessions should
   be activated given the set of critical flows that needs to be
   measured.  Even worse, this practice completely fails in networks
   whose critical flows are too short in time and dynamic in terms of
   traversing network path, like in modern cloud environments.  That is

Nobre, et al.           Expires December 10, 2017               [Page 5]

Internet-Draft   AN Use Case Detection of SLA Violations       June 2017

   so because fast reactions are necessary to reconfigure the sessions
   and administrators are not just enough in computing and activating
   the new set of required sessions every time the network traffic
   pattern changes.  Finally, the current active measurements practice
   usually covers only a fraction of the network flows that should be
   observed, which invariably leads to the damaging consequence of
   undetected SLA violations.

4.  Use Case Description

   The use case involves a service level provider who needs to monitor
   the network to detect service level violations using active service
   level measurements, and wants to be able to do so with minimal human
   intervention.  The goal is to conduct the measurements in an
   effective manner maximizing the percentage of detected service level
   violations.  The service level provider has a bounded resource budget
   with regards to measurements that can be performed, specifically,
   with regards to the number of measurements that can be conducted
   concurrently from any one network device, and possibly with regards
   to the total amount of measurement traffic on the network.  However,
   while at any one point in time the number of measurements conducted
   is limited, it is possible for a device to change which destinations
   to measure over time.  This can be exploited to achieve a balance of
   eventually covering all possible destinations using a reasonable
   amount of "sampling" where measurement coverage of a destination
   cannot be continuous.  The solution needs to be dynamic and be able
   to cope with network conditions which may change over time.  The
   solution should also be embeddable inside network devices that
   control the deployment of active measurement mechanisms.

   The goal is to conduct the measurements in a smart manner that
   ensures that the network is broadly covered and the likelihood of
   detecting service level violations is maximized.  In order to
   maximize that likelihood, it is reasonable to focus measurement
   resources on destinations that are more likely to incur a violation,
   while spending less resources on destinations that are more likely to
   be in compliance.  In order to do so, there are various aspects that
   can be exploited, including past measurements (destinations close to
   a service level threshold requiring more focus than destinations
   further from it), complementation with passive measurements such as
   flow data (to identify network destinations that are currently
   popular and critical), an observations from other parts of the
   network.  In addition, measurements can be coordinated among
   different network devices to avoid hitting the same destination at
   the same time and to be able to share results that may be useful in
   future probe placement.

Nobre, et al.           Expires December 10, 2017               [Page 6]

Internet-Draft   AN Use Case Detection of SLA Violations       June 2017

   Clearly, static solutions will have severe limitations.  At the same
   time, human administrators cannot be in the loop for continuous
   dynamic measurement probe reconfigurations.  Accordingly, an
   automated or, ideally, autonomic solution is needed in which network
   measurements are automatically orchestrated and dynamically
   reconfigured from within the network.

5.  A Distributed Autonomic Solution

   The use of Autonomic Networking (AN) [RFC7575] can help such
   detection through an efficient activation of measurement sessions
   [P2PBNM-Nobre-2012].  The problem to be solved by AN in the present
   use case is how to steer the process of Measurement Session
   activation by a complete solution that sets all necessary parameters
   for this activation to operate efficiently, reliably and securely,
   with no required human intervention other than setting overall

   We advocate for embedding Peer-to-Peer (P2P) technology in network
   devices in order to conduct the Measurement Session activation
   decisions using autonomic control loops.  Specifically, we advocate
   for network devices to implement an autonomic function to monitor
   service levels for violations of service level objectives,
   determining which Measurement Sessions to set up at any given point
   in time based on current and past observations of the node, and of
   other peer nodes.  By performing these functions locally and
   autonomically on the device itself, which measurements to conduct can
   be modified quickly based on local observations while taking local
   resource availability into account.  This allows a solution to be
   more robust and react more dynamically to rapidly changing service
   levels than a solution that has to rely on central coordination.
   However, in order to optimize decisions which measurements to
   conduct, a node will need to communicate with other nodes.  This
   allows a node to take into account other nodes' observations in
   addition to its own in its decisions.  For example, remote
   destinations whose observed service levels are on the verge of
   violating stated objectives may require closer monitoring than remote
   destinations that are comfortably within a range of tolerance.  It
   also allows nodes to coordinate their probing decisions to
   collectively achieve the best possible measurement coverage.  This
   requires the use of a P2P overlay.

   A P2P overlay is important for several reasons:

   o  It makes it possible for nodes in the network to autonomically set
      up Measurement Sessions, without having to rely on central
      management system or controller to perform configuration

Nobre, et al.           Expires December 10, 2017               [Page 7]

Internet-Draft   AN Use Case Detection of SLA Violations       June 2017

      operations associated with configuring measurement probes and

   o  It facilitates the exchange of data between different nodes to
      share measurement results so that each node can refine its
      measurement strategy based not just its own observations, but
      observations from its peers.

   o  It allows nodes to coordinate their measurements to obtain the
      best possible test coverage and avoid measurements that have a
      very low likelihood of detecting service level violations.

   The provisioning of the P2P overlay should be transparent for the
   network administrator.  An Autonomic Control Plane such as defined in
   [I-D.anima-autonomic-control-plane] provides an ideal candidate for
   the P2P overlay to run on.

   An autonomic solution for the distributed detection of SLA violations
   provide several benefits.  First, efficiency: this solution should
   optimize the resource consumption and avoid resource starvation on
   the network devices.  A device that is "self-aware" of its available
   resources will be able to adjust measurement activities rapidly as
   needed, without requiring a separate control loop involving resource
   monitoring by an external system.  Secondly, placing logic where to
   conduct measurements in the node enables rapid control loops in which
   devices are able to react instantly to observations and adjust their
   measurement strategy.  For example, a device could decide to adjust
   the amount of synthetic test traffic being sent during the
   measurement itself depending on results observed so far on this and
   on other concurrent measurement sessions.  As a result, the solution
   could decrease the time necessary to detect SLA violations.
   Adaptivity features of an autonomic loop could capture faster the
   network dynamics than an human administrator and even a central
   controller.  Finally, the solution could help to reduce the workload
   of human administrator, or, at least, to avoid their need to perform
   operational tasks.

   In practice, these factors combine to maximize the likelihood of SLA
   violations being detected while operating within a given resource
   budget, allowing to conduct a continuous measurement strategy that
   takes into account past measurement results, observations of other
   measures such as link utilization or flow data, sharing of
   measurement results between network devices, and coordinating future
   measurement activities among nodes.  Combined this can result in
   efficient measurement decisions that achieve a golden balance between
   broad network coverage and honing in on service level "hot spots".

Nobre, et al.           Expires December 10, 2017               [Page 8]

Internet-Draft   AN Use Case Detection of SLA Violations       June 2017

6.  Intended User Experience

   The autonomic solution should not require any human intervention in
   the distributed detection of SLA violations.  By virtue of the
   solution being autonomic, human users will not have to plan which
   measurements to conduct in a network, often a very labor intensive
   task today that requires detailed analysis of traffic matrices and
   network topologies and is not prone to easy dynamic adjustment.
   Likewise, they will not have to configure measurement probes and

   There are some ways in which a human administrator may still interact
   with the solution.  For one, the human administrator will of course
   be notified and obtain reports about service level violations that
   are observed.  Second, a human administrator may set a policies
   regarding how closely to monitor the network for service level
   violations and how many resources to spend.  For example, an
   administrator may set a resource budget that is assigned to network
   devices for measurement operations.  With that given budget, the
   number of SLO violations that are detected will be maximized.
   Alternatively, an administrator may set a target for the percentage
   of SLO violations that must be detected, i.e. a target for the ratio
   between the number of detected SLO violations, and the number of
   total SLO violations that are actually occurring (some of which might
   go undetected).  In that case, the solution will aim to minimize the
   resources spent (i.e. the amount of test traffic and Measurement
   Sessions) that are required to achieve that target.

7.  Implementation Considerations

   The active measurement model assumes that a typical infrastructure
   will have multiple network segments and Autonomous Systems (ASs), 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 heterogenous network is a goal, features found
   on different active measurement mechanisms (e.g.  OWAMP, TWAMP, and
   IPSLA) and device programability 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.

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

Nobre, et al.           Expires December 10, 2017               [Page 9]

Internet-Draft   AN Use Case Detection of SLA Violations       June 2017

   which probes should be activated in a given time.  The choice of
   which algorithm is better for a specific situation would be also

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.  The definition of 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 endpoints neighbors
   (e.g., FIB and RIB tables) as the initial seed to get possible peers.

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's actions.  There are some proposals for passive probe
   activation (e.g., DECON and CSAMP), but without the focus on
   autonomic features.  It is also mentioning a proposal from Barford et
   al. to detect and localize links which cause anomalies along a
   network path.

9.  Related IETF Work

   The following paragraphs discuss related IETF work and are 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 aims at the standards for performance management.
       Since their mechanisms also consist in deploying measurement
       probes the autonomic solution could be relevant for LMAP
       specially considering SLA violation screening.  Besides that, a
       solution to decrease the workload of human administrators in
       service providers is probably highly desirable.

Nobre, et al.           Expires December 10, 2017              [Page 10]

Internet-Draft   AN Use Case Detection of SLA Violations       June 2017

   2.  [IPFIX]: IP Flow Information EXport (IPFIX) aims at the process
       of standardization of 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 be possibly extended to
       address also passive measurement probes.  Besides that, flow
       information could be used in the decision making of probe

   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 for the definition of the topology regarding
       the network devices which exchange measurement data.

10.  Acknowledgements

   We wish to acknowledge the helpful contributions, comments, and
   suggestions that were received from Mohamed Boucadair, Bruno Klauser,
   Eric Voit, and Hanlin Fang.

11.  IANA Considerations

   This memo includes no request to IANA.

12.  Security Considerations

   Security of the 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 allows that would increase
   the likelihood that violations of service level objectives would go

   Likewise, 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 was 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, as well as
   reporting misleading results.

Nobre, et al.           Expires December 10, 2017              [Page 11]

Internet-Draft   AN Use Case Detection of SLA Violations       June 2017

13.  Informative References

              Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
              S., and K. Watsen, "draft-ietf-anima-bootstrapping-
              keyinfra", draft-ietf-anima-bootstrapping-keyinfra-06
              (work in progress), May 2017.

              Elkins, N., Hamilton, R., and M. Ackermann, "draft-ietf-
              ippm-6man-pdm-option", draft-ietf-ippm-6man-pdm-option-11
              (work in progress), June 2017.

              Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic
              Control Plane", draft-ietf-anima-autonomic-control-
              plane-06 (work in progress), March 2017.

              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)", 2012,

   [RFC3954]  Claise, B., Ed., "Cisco Systems NetFlow Services Export
              Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004,

   [RFC4148]  Stephan, E., "IP Performance Metrics (IPPM) Metrics
              Registry", BCP 108, RFC 4148, DOI 10.17487/RFC4148, August
              2005, <http://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,

   [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,

   [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,

Nobre, et al.           Expires December 10, 2017              [Page 12]

Internet-Draft   AN Use Case Detection of SLA Violations       June 2017

   [RFC7297]  Boucadair, M., Jacquenet, C., and N. Wang, "IP
              Connectivity Provisioning Profile (CPP)", RFC 7297,
              DOI 10.17487/RFC7297, July 2014,

   [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,

Authors' Addresses

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

   Email: jcnobre@unisinos.br

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

   Email: granville@inf.ufrgs.br

   Alexander Clemm
   Santa Clara, California

   Email: ludwig@clemm.org

   Alberto Gonzalez Prieto
   Santa Clara, California

   Email: albertgo.gonzalezprieto@yahoo.com

Nobre, et al.           Expires December 10, 2017              [Page 13]