[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

ANIMA                                                       J. Strassner
Internet-Draft                                       Huawei Technologies
Intended status: Informational
Expires: April 16, 2016
                                                        October 16, 2015

            The Use of Control Loops in Autonomic Networking
                 draft-strassner-anima-control-loops-00

Abstract

   This document describes how control loops are used in Autonomic
   Networking. Control loops provide a generic mechanism to enable
   the Autonomic System to adapt (on its own) to various factors
   that can change the goals that the Autonomic System is trying to
   achieve, or how those goals are achieved. For example, as user
   needs, business goals, and the Autonomic Network Infrastructure
   (ANI) itself changes, self-adaptation enables the ANI to change the
   services and resources it makes available to adapt to these changes.

   Control loops operate to continuously observe and collect data
   that enables the Autonomic Management System system to understand
   changes to the behavior of the system being managed, and then
   provide actions to move the state of the system being managed
   toward a common goal. Self-adaptive systems move decision-making
   from static, pre-defined commands to dynamic processes computed at
   runtime.

   This document defines the requirements for an autonomic control
   loop, describes different types of control loops, and explains how
   control loops are used in an Autonomic System.


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), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Strassner, et al.         Expires April 16, 2016                [Page 1]


Internet-Draft            Autonomic Control Loop Usage          Oct 2015


   This Internet-Draft will expire on October 26, 2015.

Copyright Notice

   Copyright (c) 2015 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
   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 ................................................. 3
   2.  Conventions Used in This Document ............................ 4
   3.  Terminology .................................................. 4
      3.1. Acronyms ................................................. 4
   3.2.  Definitions ................................................ 4
      3.2.1.  Control Loop .......................................... 4
      3.2.2.  Control Loop, Open .................................... 4
      3.2.3.  Control Loop, Closed .................................. 5
      3.2.4.  Control Loop, Proportional ............................ 5
      3.2.5.  Control Loop, Proportional-Derivative ................. 5
      3.2.6.  Control Loop, Proportional-Integral-Derivative (PID) .. 5
      3.2.7.  Control Loop, Cascade ................................. 5
      3.2.8.  Control System ........................................ 5
   4.  Requirements for Control Loops in Autonomic Networks ......... 5
      4.1.  Mandatory Autonomic Control Loop Requirements ........... 6
         4.1.1.  Observe and Collect Data ........................... 6
         4.1.2.  Orient Data ........................................ 6
         4.1.3.  Analyze Data ....................................... 7
         4.1.4.  Plan Actions Based on Oriented Data ................ 7
         4.1.5.  Decide Which Plan(s) to Execute .................... 7
         4.1.6.  Execute the Plan(s) ................................ 7
         4.1.7.  Detect and Resolve Conflicts ....................... 8
      4.2.  Optional Autonomic Control Loop Requirements (SHOULD) ... 8
         4.2.1.  Observe and Collect Data From External Systems ..... 9
         4.2.2.  Orient Data from External Systems .................. 9
         4.2.3.  Execute One or More Machine Learning Algorithms .... 9
         4.2.4.  Register Control Loop Capabilities ................ 10
         4.2.5.  Register Control Loop Requirements ................ 10



Strassner, et al.         Expires April 16, 2016                [Page 2]


Internet-Draft            Autonomic Control Loop Usage          Oct 2015

Table of Contents (continued)

   4.3.  Optional Autonomic Control Loop Requirements (MAY) ........ 10
         4.3.1.  Use of A Single Information Model ................. 11
         4.3.2.  Use of Ontologies ................................. 11
         4.3.3.  Collaborate With Other Control Loops .............. 11
   5.  Control Loop Usage in Autonomic Networks .................... 12
      5.1.   Autonomic Management .................................. 12
      5.2.  Policy and Context ..................................... 13
      5.3  Types of Policies ....................................... 14
         5.3.1.  Policies Organized by Actors ...................... 14
         5.3.2.  Policies Organized by Technology .................. 15
      5.4.  Policy Conflicts ....................................... 15
         5.4.1.  Policy Conflicts Caused by Technology ............. 15
         5.4.2.  Policy Conflicts Caused by Different Actors ....... 16
      5.5.  Control Loops .......................................... 16
         5.5.1.  Types of Control .................................. 16
         5.5.2.  Types of Control Loops ............................ 17
         5.5.3.  Management of an Autonomic Control Loop ........... 18
   6.  Security Considerations ..................................... 18
   7. IANA Considerations .......................................... 18
   8. Acknowledgements ............................................. 18
   9. References ................................................... 18
   Authors' Addresses .............................................. 19




1.  Introduction

   The document "Autonomic Networking - Definitions and Design Goals"
   [RFC7575] explains the fundamental concepts behind Autonomic
   Networking. In section 1, it says: "The fundamental concept
   involves eliminating external systems from a system's control loops
   and closing of control loops within the Autonomic System itself,
   with the goal of providing the system with self-management
   capabilities...". In section 5, it also describes a high-level
   reference model [draft-behringer-anima-reference-model]. This
   document defines a portion of that reference model that describes
   how control loops are used in Autonomic Systems to self-adapt to
   various changes to achieve self-management.

   Control loops provide a generic mechanism to enable the Autonomic
   System to adapt (on its own) to various factors that can change the
   goals that the Autonomic System is trying to achieve, and/or how
   those goals are achieved. Such factors include changing user needs,
   business goals, and changes to the underlying Autonomic Network
   Infrastructure (ANI).




Strassner, et al.         Expires April 16, 2016                [Page 3]


Internet-Draft            Autonomic Control Loop Usage          Oct 2015


   As discussed in [RFC7575], the goal of this work is not to focus
   exclusively on fully autonomic nodes or networks.  In reality, most
   networks will run with some autonomic functions, while the rest of
   the network will not. The reference model defined in
   [draft-behringer-anima-reference-model] allows for this hybrid
   approach.

   This is a living document, and will evolve with the technical
   solutions developed in the ANIMA WG.


2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in [RFC2119]. In
   this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to
   be interpreted as carrying [RFC2119] significance.


3.  Terminology

   This section defines acronyms, terms, and symbology used in the
   rest of this document.

3.1. Acronyms

   ANI        Autonomic Network Infrastructure
   CLI        Command Line Interface
   OAM&P      Operations, Administration, Management, and Provisioning
   PID        Proportional-Integral-Derivative (a type of controller)


3.2.  Definitions

   This section defines the terminology that is used in this document.

3.2.1.  Control Loop

   A control loop is a type of control system that manages the
   behavior of the devices and systems that it is governing.

3.2.2.  Control Loop, Open

   A control loop whose output is generated based only on the input(s)
   it receives.




Strassner, et al.         Expires April 16, 2016                [Page 4]


Internet-Draft            Autonomic Control Loop Usage          Oct 2015


3.2.3.  Control Loop, Closed

   A control loop whose output is a function of the current output and
   a set of corrections made to that output based on feedback.

3.2.4.  Control Loop, Proportional

   A type of control algorithm that generates a stronger response
   when the system is farther away from its goal state. In other words,
   the response of the control algorithm is proportion to the amount of
   error received.

3.2.5.  Control Loop, Proportional-Derivative

   A type of control algorithm that uses the rate-of-change of the
   error with time. In other words, it uses the error when the system
   is far away from the goal state, and then corrects for the momentum
   of the system as it gets closer to the goal state.

3.2.6.  Control Loop, Proportional-Integral-Derivative (PID)

   A type of control algorithm that adds an integral action to a
   proportional derivative controller. The integral term eliminates
   long-term steady-state errors. By integrating the error over time,
   the controller can drive the system closer to the goal state.

3.2.7.  Control Loop, Cascade

   A type of controller where multiple controllers (usually PID) are
   used to provide fine-grained control. The simplest type of cascade
   control is two PIDs, where one PID controls the

3.2.8.  Control System

   A control system consists of systems and processes that
   collectively govern the output of the system.



4.  Requirements for Control Loops in Autonomic Networks

   The following subsections define the requirements that Autonomic
   Control Loops MUST, SHOULD, and MAY provide.








Strassner, et al.         Expires April 16, 2016                [Page 5]


Internet-Draft            Autonomic Control Loop Usage          Oct 2015


4.1.  Mandatory Autonomic Control Loop Requirements

   An autonomic control loop MUST be able to perform the following
   functions as part of its operation:

     o Observe and collect data from the system being managed

     o Orient these data, so that their meaning and significance can
       be understood in the proper context

     o Analyze the collected data through filtering, correlation,
       and other mechanisms to define a model of past, current, and
       future states

     o Plan different actions based on inferring trends, determining
       root causes, and similar processes

     o Decide which plan(s) to execute, and when

     o Execute the plan(s), and then repeat these steps

     o Detect and resolve any conflicts between different goals
       that the Autonomic System is given

   These seven requirements are further explained in the following
   subsections.

4.1.1.  Observe and Collect Data

   Control loops begin with input data. An autonomic control loop
   MUST be able to observe and collect data, as instructed by an
   Autonomic Management System. Without the proper input data, the
   control loop will be ineffective at best, and likely useless.
   However, many data in their raw form are not easy to understand
   by an Autonomic System, and may not be compatible with other data
   that have been collected by the Autonomic System. Hence, this stage
   is a mostly passive ability to collect data that is meaningful for
   the management process, and relies heavily on the next
   (orientation) step.

4.1.2.  Orient Data

   The orientation of data ensures that those data are taken in the
   correct context. This enables their meaning, as well as their
   relative importance, to be properly assigned. Autonomic control
   loops MUST orient data.

   Orientation of data was the second step in Boyd's OODA loop
   [Boyd95]. OODA stands for Observe, Orient, Decide, and Act. The
   FOCALE [Strassner07] control loops are an extension of OODA.

Strassner, et al.         Expires April 16, 2016                [Page 6]


Internet-Draft            Autonomic Control Loop Usage          Oct 2015


   The orientation step of OODA is critical, as it determines how
   observations, decisions, and actions are performed. This mimics
   human behavior, since most people react according to how they
   perceive the world, as opposed to how the world really is.

   In FOCALE, the orient step is a model-based translation of
   received data to normalize those data into a common form, where
   they can each contribute to the overall perception of the System
   that is being managed. For example, data from a variety of sensors
   (e.g., pressure, visual, thermal, etc.) can be fitted into an
   overall model that also includes performance of IP services,
   device interfaces, and other entities. Without this normalization
   of applicable device information, the overall context of the
   system is not known. This in turn increases the risk of the wrong
   decision being made.

4.1.3.  Analyze Data

   The analysis of data is critical for enabling the control loop to
   operate properly. Autonomic control loops MUST be able to analyze
   data, after they have been oriented, in order to determine the set
   of critical properties that the control loop is operating against.

   For example, the analysis might derive the current state of the
   system being managed; this can then be compared to the desired
   state of the system to define an error function that can be fed
   back into the control loop. As another example, one or more
   attributes could be monitored to determine whether the system is
   operating as planned or not; again, an error function is then
   defined that can be fed back into the control loop. This step is
   part of the Orient function in OODA, but is separate in FOCALE.

4.1.4.  Plan Actions Based on Oriented Data

   Once the analysis is done, the Autonomic System then understands
   if its current behavior needs to be modified or changed. This
   takes the form of one or more plans. An autonomic control loop
   MUST be able to generate one or more plans to govern the behavior
   of the system being managed. There can be many different ways to
   solve a problem; a plan is built for each way to enable them to
   be compared and contrasted.

4.1.5.  Decide Which Plan(s) to Execute

   Given a set of plans generated by the control loop, a control
   loop MUST be able to choose which plan, or set of plans, to
   execute. If multiple plans are to be executed, then the autonomic
   control loop MUST define the order (if any) of execution of each
   control loop.


Strassner, et al.         Expires April 16, 2016                [Page 7]


Internet-Draft            Autonomic Control Loop Usage          Oct 2015


   In FOCALE, each plan is evaluated with respect to the current
   context. This enables context to optimize which plan, or set of
   plans, are best suited to achieving the goal(s) in managing the
   behavior of the system. Note that this forms another very
   important loop in FOCALE: context selects policies. As context
   changes, a new working set of policies are selected. Hence, the
   behavior of the Autonomic System adapts to changing context.

4.1.7.  Detect and Resolve Conflicts

   Autonomic systems typically use policy rules to either help in
   making decisions, or to provide actions to take as part of the
   control loop. An Autonomic System MUST be able to detect, and
   then resolve, conflicts. Both MAPE [Kephart03] and FOCALE
   [Strassner07] provide several examples of this behavior.


4.2.  Optional Autonomic Control Loop Requirements (SHOULD)

   An autonomic control loop SHOULD be able to perform the following
   functions as part of its operation:

     o Observe and collect data from other devices and/or systems that
       can influence the behavior of the system being managed

     o Orient data from other devices and/or systems that can
       influence the behavior of the system being managed, so that
       their meaning and significance can be understood in the
       proper context

     o Execute one or more machine learning algorithms that can learn
       from and make predictions on monitored data. This enables more
       efficient adaptivity. It also enables "shortcuts" to be built
       that enable one or more functional blocks of the control loop
       to be skipped because the Autonomic System already recognizes
       what needs to be corrected in the system.

     o Register the capabilities that this control loop can govern
       with a collection of other Autonomic Systems that it may
       exchange information and control with

     o Register the requirements that this control loop needs in
       order to accomplish its tasks

   These five requirements are further explained in the following
   subsections.





Strassner, et al.         Expires April 16, 2016                [Page 8]


Internet-Draft            Autonomic Control Loop Usage          Oct 2015


4.2.1.  Observe and Collect Data From External Systems

   Autonomic Systems are context-aware. This means that the context
   of the Autonomic System helps determine what actions (if any)
   should be taken at any given time. Therefore, Autonomic Systems
   SHOULD take into account data that directly and indirectly affect
   the goals of the Autonomic System. This includes data that affect
   the Autonomic System itself and/or data that affect the system
   that is being governed by the Autonomic System.

   Data that directly affects the Autonomic System are data that
   belong to the Autonomic System, and/or the system being governed
   by the Autonomic System. Data that indirectly affects the Autonomic
   System are data that belong to systems that are neither the
   Autonomic System nor the system that the Autonomic System is
   managing.

4.2.2.  Orient Data from External Systems

   All data, regardless of whether it directly or indirectly affects
   the Autonomic System, SHOULD be oriented so that a common frame of
   reference is built to consider the relative importance of observed
   and collected data. This orientation places ensures that data are
   compared and analyzed in the correct context. This enables their
   meaning, as well as their relative importance, to be properly
   assigned. Autonomic control loops SHOULD orient external data.

4.2.3.  Execute One or More Machine Learning Algorithms

   Machine learning refers to algorithms that can learn from, and
   make predictions about, data. Machine learning algorithms use a
   model, built from a set of exemplar data, to make predictions and
   decisions. More formally, [Mitchell97] defines machine learning as:
   "A computer program is said to learn from experience E with respect
   to some class of tasks T and performance measure P, if its
   performance at tasks in T, as measured by P, improves with
   experience E."

   Machine learning provides the ability for the Autonomic System to
   learn from its environment, without burdening the developer to
   program an explicit set of steps to do so. As such, it is well-
   suited for providing the basis for learning from the environment
   in order to adapt the services and resources that it offers in
   order to maintain, protect, or better fulfil its goals.







Strassner, et al.         Expires April 16, 2016                [Page 9]


Internet-Draft            Autonomic Control Loop Usage          Oct 2015


4.2.4.  Register Control Loop Capabilities

   Autonomic systems provide a number of functional capabilities.
   Sometimes, a control loop of one Autonomic System may have
   excess processing available that could be used by other control
   loops of the same or different Autonomic Systems. Therefore, an
   autonomic control loop SHOULD register the functional capabilities
   that it provides, so that other autonomic control loops can
   request the use of one or more of those functional capabilities.
   Note that the use of models and/or ontologies greatly simplifies
   this task, as models and ontologies provide a common vocabulary,
   complete with meanings, that are shared by all autonomic elements
   in an Autonomic System.

4.2.5.  Register Control Loop Requirements

   Autonomic systems provide a number of functional capabilities.
   Sometimes, a control loop can benefit from other resources (that
   are part of other Autonomic Networks) that available to perform
   one or more of the functions required by the control loop.

   This may be because the control loop has run out of resources from
   its own autonomic elements, or it may be because other autonomic
   elements can supply more powerful, or robust, versions of the
   functions that a control loop needs compared to the functions
   provided by its own autonomic elements. In order for this to occur,
   an autonomic control loop SHOULD register its requirements. This
   enables other autonomic elements to provide resources and/or
   services to the autonomic control loop, as needed.


4.3.  Optional Autonomic Control Loop Requirements (MAY)

   An autonomic control loop MAY be able to perform the following
   functions as part of its operation:

     o Use a single information model to help normalize observed
       and collected data.

     o Use one or more ontologies to define semantics for data. If
       models define facts, then ontologies conceptually define the
       semantics for those facts. This is critical in enabling the
       Autonomic System to reason and learn.

     o Collaborate with other control loops of other Autonomic
       Systems, so that autonomic control can be extended beyond
       the confines of any one system to a collection of Autonomic
       Systems



Strassner, et al.         Expires April 16, 2016               [Page 10]


Internet-Draft            Autonomic Control Loop Usage          Oct 2015

   These three requirements are further explained in the following
   subsections.

4.3.1.  Use of A Single Information Model

   Autonomic Systems MAY use an information model to define common
   concepts used by all systems that are interacting with each other.

   The advantage of using an information model is that it defines a
   set of concepts in a technology-neutral format. This is important,
   because most management systems use a variety of different data
   models (e.g., directories, relational databases, in-memory
   databases, and others). Each of these data models structures and
   organizes data differently, and has very different ways of
   performing basic operations (e.g., create, read, update, and
   delete) on those data using very different protocols. Hence, if
   a data object is updated in one data model, how can the system
   reliably update other instances of that data object if the
   protocol, representation, data type, and other elements of the
   data object are different?

   The role of an information model is to define common concepts
   once; this enables a set of mappings between the information
   model and each data model to be defined, so that data coherency
   is maintained in each data model.

4.3.2.  Use of Ontologies

   Autonomic Systems MAY use a set of ontologies for defining the
   meaning associated with different facts collected by the
   Autonomic System. Facts can be derived from models as well as
   from the ontologies themselves.

   Information and data models are important. However, neither
   type of model can typically support reasoning, because neither
   type of model defines formal semantics for the data. Ontologies
   use a formal mathematical model for defining semantics (e.g.,
   description logic or first order logic). Hence, one can build
   a multi-graph, where different model elements are linked together
   using semantic edges defined by ontologies.

   This is an important step towards both orienting data as well as
   harmonizing data in general. Without understanding the associated
   semantics of data, it is difficult (if not impossible) to ensure
   that the operation of the control loop will be correct.

4.3.3.  Collaborate With Other Control Loops

   Autonomic Systems MAY collaborate with other Autonomic Systems.
   This enables multiple Autonomic Systems to support each other, and
   work together to achieve goals that are mutually beneficial.

Strassner, et al.         Expires April 16, 2016               [Page 11]


Internet-Draft            Autonomic Control Loop Usage          Oct 2015


5.  Control Loop Usage in Autonomic Networks

   Autonomic systems use closed control loops. They may use one or
   multiple control loops to manage behavior; examples of these are
   the MAPE-K loop [MAPE] and FOCALE [FOCALE] control loops,
   respectively.

   Control loops operate to continuously observe and collect data
   that enables the autonomic management system to understand changes
   to the behavior of the system being managed, and then provide
   actions to move the state of the system being managed toward a
   common goal. Self-adaptive systems move decision-making from
   static, pre-defined commands to dynamic processes computed at
   runtime.

   Ideally, Autonomic Management will co-exist with traditional, or
   on-autonomic, management methods. This is because autonomic
   management will either be introduced in a greenfield environment
   (where it is the "only" management method), or more likely, in a
   hybrid environment that includes legacy systems and devices that
   are not capable of Autonomic Management.

5.1.   Autonomic Management

   In a hybrid environment, autonomic control loops are used to
   manage individual autonomic functions. In some hybrid environments
   (e.g., where a number of autonomic nodes are collaborating to
   provide a collective response to the system) and in many
   greenfield environments, autonomic control loops are used to
   manage not only functions, but processes and behaviors.

   There are two types of behavior that are implied by the autonomic
   system coexisting with traditional systems: (1) autonomic methods
   can be used to manage legacy elements using traditional mechanisms
   (e.g., CLI, SNMP), and (2) autonomic methods can use a proxy to
   translate their management mechanisms into one or more forms that
   legacy elements can understand.

   In principle, both of these approaches could be used by autonomic
   systems to manage autonomic elements; in practice, most autonomic
   systems will use autonomic mechanisms to manage autonomic elements,
   due to increased efficiency and expressivity.

   Note that in either case, the basic control loop does NOT change.
   This is because the purpose of the control loop is to achieve its
   goals. Hence, it doesn't matter if new and/or legacy protocols
   are used, as long as the tasks can be accomplished.




Strassner, et al.         Expires April 16, 2016               [Page 12]


Internet-Draft            Autonomic Control Loop Usage          Oct 2015


5.2.  Policy and Context

   Policies can be used with control loops to guide the operation of
   the control loop. FOCALE is one example of this approach, and is
   shown in simplified form in Figure 1.

                   Feedback
                    Policy
      +---------+   Results   +---------+
      | Context |<------------| Policy  |
      | Manager |------------>| Manager |
      +---------+   Selects   +---------+
          / \       Policies     |  / \
           |                     |   |
           |    Defines Behavior |   | Feedback Results
           |                     |   |
           |                    \ /  |
           |                 +-----------+
           | Context         | Autonomic |
           |  Data           |  Manager  |
           |                 +-----------+
           |                     |  / \
           |              Adjust |   |
   +--------------+              |   | Feedback Results
   |              |             \ /  |
   | +---------+  | Input   +----------------------------+
   | | System  |  |  Data  \|                            |
   | |  Being  |--+-------- | +----------+    +-------+  |
   | | Managed |  |   / \  /| | Observe, |   \| Plan, |--+-------+
   | +---------+  |    |    | |  Orient, |--- |Decide,|--+---+   |
   |              |    |    | | Compare, |   /|  Act  |  |   |   |
   |  System      |    |    | | Analyze  |    +-------+  |   |   |
   |              |    |    | +----------+               |   |   |
   +--------------+    |    |                            |   |   |
         / \           |    |   +------------------+     |   |   |
          |            |    |   | Machine Learning |     |   |   |
          |            |    |   +------------------+     |   |   |
          |            |    |                            |   |   |
          |            |    |    Control Loop Elements   |   |   |
          |            |    +----------------------------+   |   |
          |            |                                     |   |
          |            +-------------------------------------+   |
          |               Current State = Desired State          |
          |                                                      |
          +------------------------------------------------------+
                        Current State != Desired State

    Figure 1.  Simplified View of the FOCALE Autonomic Architecture



Strassner, et al.         Expires April 16, 2016               [Page 13]


Internet-Draft            Autonomic Control Loop Usage          Oct 2015


   In FOCALE, Context is computed from information obtained and/or
   observed from the system being managed, along with other factors
   (e.g., business rules). This context information is used to
   determine the context that the system being managed is in. This
   context selects a working set of policies that are applicable for
   that context. The Policy Manager executes its policies, which
   define the behavior to be implemented by the Autonomic Manager.
   The Autonomic Manager then adjusts the set of control loop
   elements according to policy.

   In the above simple example, if the current state equals the
   desired state, then no adjustment is necessary, so the control
   loop continues monitoring input data. In contrast, if the current
   states does not equal the desired state, then the control loop
   computes one or more plans, decides which plan(s) to execute, and
   then monitors the execution of the plan(s) to ensure that the
   expected outcomes occurred.

   Machine learning algorithms monitor all of the operations of the
   control loop, building up a knowledge base that can correlate
   types of scenarios to solutions. It also records the efficacy of
   the remediations determined by the control loop processing.


5.3  Types of Policies

   The previous section showed the importance of using context-aware
   policies to control the processing of Autonomic control loops.
   There are two types of classifications of policies:

      1) policies that pertain to specific actors, and
      2) policies of a technological nature

5.3.1.  Policies Organized by Actors

   The Policy Continuum [Davy07] defines a set of stratified policy
   languages, where each language is used by one or more actors in
   the end-to-end management of the system. This helps ensure
   consistency among the different constituencies that use policies,
   enabling each constituency to use a grammar and terminology that
   is familiar to them while being able to relate each language
   to at least each other language at the next lowest level of
   abstraction.








Strassner, et al.         Expires April 16, 2016               [Page 14]


Internet-Draft            Autonomic Control Loop Usage          Oct 2015


5.3.2.  Policies Organized by Technology

   The document draft-strassner-supa-generic-policy-info-model-02
   describes the difference between two types of policy rules.
   Imperative policies, typified by "condition-action" or "event-
   condition-action", define the set of commands to perform to
   manipulate the state of the system. In contrast, declarative
   policies, typified by logic-based languages, define relationships
   between variables in terms of functions or inference rules. A
   third type of policy rule, called a procedural policy, is one
   that explicitly defines a sequence of actions to execute given a
   set of conditions.

   To date, the vast majority of policy implementations are either
   imperative or procedural. Lately, a lot of excitement has been
   generated over the concept of "intent-based" policies, which have
   been described as declarative policies.


5.4.  Policy Conflicts

   There are two classes of policy conflicts that must be taken into
   account if policy is to be used to control the processing of the
   control loop. They are:

      1) Conflicts arising from technology, and
      2) Conflicts arising from different actors

   This is elaborated on in the following two subsections.

5.4.1.  Policy Conflicts Caused by Technology

   In imperative and procedural policies, policy conflict detection
   and remediation MUST be provided. Since state is directly
   manipulated by both types of these policies, different instances
   of each can give rise to conflicting actions in response to the
   same conditions. For example, if two policies have the same
   conditions but different actions, this is a conflict.

   There are many different algorithms to resolve policy conflicts.
   The simplest is adding a priority integer to each policy rule.
   This, however, is not advised, because:

      1) it is complex to ensure that all integers are properly
         ordered for all cases, and
      2) this is a static, reactive mechanism, and may not be able
         to be adjusted dynamically to resolve all conflicts




Strassner, et al.         Expires April 16, 2016               [Page 15]


Internet-Draft            Autonomic Control Loop Usage          Oct 2015


   This type of policy conflict detection and resolution will be
   examined later in the lifecycle of the ANIMA WG.

   Note that policy conflicts are typically not possible in
   declarative policies. This is because such policies are a set of
   statements that determine whether a proposition is true or not.

5.4.2.  Policy Conflicts Caused by Different Actors

   Conflict can occur between the following broad classes of actors:

     o between actions of different autonomic networks

     o between actions of an autonomic network and actions of a non-
       autonomic network

   [RFC7575] recommends the use of prioritization, which yields the
   following (incomplete) first pass of remediation:

     o manual, or operator-driven (e.g., using scripts) operations
       have the highest priority

     o operator-driven autonomic operations

     o default behavior of autonomic operations

   < more on the next revision >


5.5.  Control Loops

   Control loops provide a generic mechanism for self-adaptation.  That
   is, as user needs, business goals, and the ANI itself change, self-
   adaptation enables the ANI to change the services and resources it
   makes available to adapt to these changes.  Self-adaptive systems
   move decision-making from static, pre-defined commands to dynamic
   processes computed at runtime.

   Control loops operate to continuously capture data that enables the
   understanding of the system, and then provide actions to move the
   state of the system toward a common goal.

5.5.1.  Types of Control

   There are two generic types of closed loop control. Feedback
   control adjusts the control loop based on measuring the output of
   the system being managed to generate an error signal (the
   deviation of the current state vs. its desired state).  Action is
  then taken to reduce the deviation.


Strassner, et al.         Expires April 16, 2016               [Page 16]


Internet-Draft            Autonomic Control Loop Usage          Oct 2015

   In contrast, feedforward control anticipates future effects on a
   controlled variable by measuring other variables whose values may
   be more timely, and adjusts the process based on those variables.
   In this approach, control is not error-based, but rather, based
   on knowledge.

   Autonomic control loops MAY require both feedforward and feedback
   control, depending on the specific type of algorithm used.

5.5.2.  Types of Control Loops

   There are many different types of control loops.  In autonomics,
   the most commonly cited loop is called Monitor-Analyze-Plan-Execute
   (with Knowledge), called MAPE-K [Kephart03]. However, MAPE-K has a
   number of systemic problems, as described in [Strassner09]. Thus,
   other autonomic architectures, such as AutoI [AutoI] and FOCALE
   [Strassner07] use different types of control loops. In these two
   cases, both AutoI and FOCALE evolved from the OODA control loop
   [Boyd95].  One of the most important reasons for using this loop,
   and not the MAPE-K loop, is because the OODA loop contains a
   critical step not contained in other loops: orientation.
   Orientation determines how observations, decisions, and actions
   are performed.

   Figure 2 shows a simplified model of a control loop containing both
   feedforward and feedback elements.


                       Input Variables
                ----------+-------------------------+
                          |                         |
                          |                         |
                         \ /                       \ /
                    +-----+------+             +----+----+
      Set Point --->| Controller |------------>| Process |--+---> Output
                    +-----+------+  Deltas of  +---------+  |
                          ^         Control                 |
                          |        Variable(s)              |
                          |                                 |
                          +---------------------------------+

       Figure 2: Control Loop with Feedforward and Feedback Elements

   Note that Figure 2 is a STATIC model.  Figure 3 is a dynamic version,
   called a Model-Reference Adaptive Control Loop (MRACL).







Strassner, et al.         Expires April 16, 2016               [Page 17]


Internet-Draft            Autonomic Control Loop Usage          Oct 2015


                             Model   +--------------+
                  +-------+  Output  |   Adaptive   |<----+
             +--->| Model |--------->| Algorithm(s) |     |
             |    +-------+          +---+-----+----+     |
             |              Adjusted     |     ^          |
      Input  |             Parameters    |     |          |
     --------+          +----------------+     |          |
             |          |                      |          |
             |          |            +---------+          |
             |         \ /           |                    |
             |    +-----+------+     |       +---------+  |
             +--->| Controller |-----+------>| Process |--+---> Output
                  +-----+------+  Deltas of  +---------+  |
                        ^         Control                 |
                        |        Variable(s)              |
                        |                                 |
                        +---------------------------------+

             Figure 3: A Model-Reference Adaptive Control Loop

   More complex adaptive control loops have been defined; these will
   be described in a future I-D, so that an appropriate gap analysis
   can be defined to recommend an architectural approach for ANIMA.

5.5.3.  Management of an Autonomic Control Loop

   Both standard and adaptive control loops (e.g., as represented in
   Figures 2 and 3, respectively) enable intervention by a human
   administrator or central control systems, if required.  Interaction
   mechanisms include changing the behaviour of one or more elements in
   the control loop, as well as providing mechanisms to bypass parts of
   the control loop (e.g., skip the "decide" phase and go directly to
   the "action" phase of an OODA loop, as is done in FOCALE).  This also
   enables the default behaviour to be changed if necessary.


6.  Security Considerations

   To be done in the next revision


7.  IANA Considerations

   This document requests no action by IANA.


8.  Acknowledgements

   Thank you to Michael Behringer for reviewing this document.


Strassner, et al.         Expires April 16, 2016               [Page 18]


Internet-Draft            Autonomic Control Loop Usage          Oct 2015


9.  References

   [I-D.behringer-anima-reference-model-03]
      Behringer, M., Carpenter, B., Eckert, T., Ciavagia, L., Liu, B.,
      Nobre, J., Strassner, J., "A Reference Model for Autonomic
      Networking", June 2015

   [RFC2119]
      Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997.

   [RFC7575]
      Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
      Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Networking:
      Definitions and Design Goals", RFC 7575, June 2015.

   [AutoI]
      Galis, A., Denazis, S., Bassi, A., Giacomin, P., Berl, A.,
      Fischer, A., de Meer, H., Strassner, J., Davy, S., Macedo, D.,
      Pujolle, G., Loyola, J.R., Serrat, J., Lefevre, L., Cheniour, A.,
      "Management Architecture and Systems for Future Internet
      Networks," in FIA Book: "Towards the Future Internet - A European
      Research Perspective". IOS Press, May 2009, pp. 112-122,
      ISBN 978-1-60750-007-0

   [Boyd95]
      Boyd, J.R., "The Essence of Winning and Losing", 28 June, 1995

   [Davy07]
      Davy, S., Jennings, B., Strassner, J., "The Policy Continuum - A
      Formal Model", Proc. of the 2nd Intl. IEEE Workshop on Modeling
      Autonomic Communication Environments (MACE), Multicon Lecture
      Notes, No. 6, Multicon, Berlin, 2007, pages 65-78

   [Kephart03]
      Kephart, J. and D. Chess, "The Vision of Autonomic Computing",
      IEEE Computer, vol. 36, no. 1, pp. 41-50, DOI
      10.1109/MC.2003.1160055, January 2003.

   [Meyer97]
      Meyer, B., "Object-Oriented Software Construction", 2nd edition,
      Prentice Hall, 1997, ISBN 0-13-629155-4

   [Strassner07]
      Strassner, J., Agoulmine, N., Lehtihet, E., "FOCALE - A Novel
      Autonomic Networking Architecture",  International Transactions
      on Systems, Science, and Applications (ITSSA) Journal, Vol. 3,
      No 1, pp 64-79, May, 2007


Strassner, et al.         Expires April 16, 2016               [Page 19]


Internet-Draft            Autonomic Control Loop Usage          Oct 2015


   [Strassner09]
      Strassner, J., Kim, S., Hong, J., "The Design of an Autonomic
      Communication Element to Manage Future Internet Services", Proc.
      of the 12th Asia-Pacific Network Operations and Management
      Conference, pg 122-132



Authors' Addresses

   John Strassner
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Email: john.sc.strassner@huawei.com


































Strassner, et al.         Expires April 16, 2016               [Page 20]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/