doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc7575.txt b/doc/rfc/rfc7575.txt
new file mode 100644
index 0000000..d7a43ab
--- /dev/null
+++ b/doc/rfc/rfc7575.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Research Task Force (IRTF)                         M. Behringer
+Request for Comments: 7575                                   M. Pritikin
+Category: Informational                                     S. Bjarnason
+ISSN: 2070-1721                                                 A. Clemm
+                                                           Cisco Systems
+                                                            B. Carpenter
+                                                       Univ. of Auckland
+                                                                S. Jiang
+                                            Huawei Technologies Co., Ltd
+                                                            L. Ciavaglia
+                                                          Alcatel Lucent
+                                                               June 2015
+
+
+           Autonomic Networking: Definitions and Design Goals
+
+Abstract
+
+   Autonomic systems were first described in 2001.  The fundamental goal
+   is self-management, including self-configuration, self-optimization,
+   self-healing, and self-protection.  This is achieved by an autonomic
+   function having minimal dependencies on human administrators or
+   centralized management systems.  It usually implies distribution
+   across network elements.
+
+   This document defines common language and outlines design goals (and
+   what are not design goals) for autonomic functions.  A high-level
+   reference model illustrates how functional elements in an Autonomic
+   Network interact.  This document is a product of the IRTF's Network
+   Management Research Group.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Research Task Force
+   (IRTF).  The IRTF publishes the results of Internet-related research
+   and development activities.  These results might not be suitable for
+   deployment.  This RFC represents the consensus of the Network
+   Management Research Group of the Internet Research Task Force (IRTF).
+   Documents approved for publication by the IRSG are not a candidate
+   for any level of Internet Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7575.
+
+
+
+
+Behringer, et al.             Informational                     [Page 1]
+
+RFC 7575                  Autonomic Networking                 June 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.
+
+Table of Contents
+
+   1.  Introduction to Autonomic Networking  . . . . . . . . . . . .   3
+   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3.  Design Goals  . . . . . . . . . . . . . . . . . . . . . . . .   5
+     3.1.  Self-Management . . . . . . . . . . . . . . . . . . . . .   5
+     3.2.  Coexistence with Traditional Management . . . . . . . . .   6
+     3.3.  Secure by Default . . . . . . . . . . . . . . . . . . . .   7
+     3.4.  Decentralization and Distribution . . . . . . . . . . . .   8
+     3.5.  Simplification of Autonomic Node Northbound Interfaces  .   8
+     3.6.  Abstraction . . . . . . . . . . . . . . . . . . . . . . .   8
+     3.7.  Autonomic Reporting . . . . . . . . . . . . . . . . . . .   9
+     3.8.  Common Autonomic Networking Infrastructure  . . . . . . .   9
+     3.9.  Independence of Function and Layer  . . . . . . . . . . .  10
+     3.10. Full Life-Cycle Support . . . . . . . . . . . . . . . . .  10
+   4.  Not among the Design Goals  . . . . . . . . . . . . . . . . .  11
+     4.1.  Eliminate Human Operators . . . . . . . . . . . . . . . .  11
+     4.2.  Eliminate Emergency Fixes . . . . . . . . . . . . . . . .  11
+     4.3.  Eliminate Central Control . . . . . . . . . . . . . . . .  11
+   5.  An Autonomic Reference Model  . . . . . . . . . . . . . . . .  12
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
+   7.  Informative References  . . . . . . . . . . . . . . . . . . .  13
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  15
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Behringer, et al.             Informational                     [Page 2]
+
+RFC 7575                  Autonomic Networking                 June 2015
+
+
+1.  Introduction to Autonomic Networking
+
+   Autonomic systems were first described in a manifesto by IBM in 2001
+   [Kephart].  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, including self-
+   configuration, self-optimization, self-healing, and self-protection.
+
+   IP networking was initially designed with similar properties in mind.
+   An IP network should be distributed and redundant to withstand
+   outages in any part of the network.  Routing protocols such as OSPF
+   and IS-IS exhibit properties of self-management and can thus be
+   considered autonomic in the definition of this document.
+
+   However, as IP networking evolved, the ever-increasing intelligence
+   of network elements was often not put into protocols to follow this
+   paradigm, but was put into external configuration systems.  This
+   configuration made network elements dependent on some process that
+   manages them, either a human or a network management system.
+
+   Autonomic functions can be defined in two ways:
+
+   o  On a node level: Nodes interact with each other to form feedback
+      loops.
+
+   o  On a system level: Feedback loops include central elements as
+      well.
+
+   System-level autonomy is implicitly or explicitly the subject in many
+   IETF working groups, where interactions with controllers or network
+   management systems are discussed.
+
+   This work specifically focuses on node-level autonomic functions.  It
+   focuses on intelligence of algorithms at the node level, to minimize
+   dependency on human administrators and central management systems.
+
+   Some network deployments benefit from a fully autonomic approach, for
+   example, networks with a large number of relatively simple devices.
+   Most currently deployed networks, however, will require a mixed
+   approach, where some functions are autonomic and others are centrally
+   managed.  Central management of networking functions clearly has
+   advantages and will be chosen for many networking functions.  This
+   document does not discuss which functions should be centralized or
+   follow an autonomic approach.  Instead, it should help make the
+   decision which is the best approach for a given situation.
+
+
+
+
+
+Behringer, et al.             Informational                     [Page 3]
+
+RFC 7575                  Autonomic Networking                 June 2015
+
+
+   Autonomic function cannot always discover all required information;
+   for example, policy-related information requires human input, because
+   policy is by its nature derived and specified by humans.  Where input
+   from some central intelligence is required, it is provided in a
+   highly abstract, network-wide form.
+
+   Autonomic Computing in general and Autonomic Networking in particular
+   have been the subject of academic study for many years.  There is
+   much literature, including several useful overview papers (e.g.,
+   [Samaan], [Movahedi], and [Dobson]).  In the present document, we
+   focus on concepts and definitions that seem sufficiently mature to
+   become the basis for interoperable specifications in the near future.
+   In particular, such specifications will need to coexist with
+   traditional methods of network configuration and management, rather
+   than realizing an exclusively autonomic system with all the
+   properties that it would require.
+
+   There is an important difference between "automatic" and "autonomic".
+   "Automatic" refers to a predefined process, such as a script.
+   "Autonomic" is used in the context of self-management.  It includes
+   feedback loops between elements as well as northbound to central
+   elements.  See also the definitions in the next section.  Generally,
+   an automatic process works in a given environment but has to be
+   adapted if the environment changes.  An autonomic process can adapt
+   to changing environments.
+
+   This document provides the definitions and design goals for Autonomic
+   Networking in the IETF and IRTF.  It represents the consensus of the
+   IRTF's Network Management Research Group (NMRG).
+
+2.  Definitions
+
+   We make the following definitions.
+
+   Autonomic: Self-managing (self-configuring, self-protecting, self-
+   healing, self-optimizing); however, allowing high-level guidance by a
+   central entity, through Intent (see below).  An autonomic function
+   adapts on its own to a changing environment.
+
+   Automatic: A process that occurs without human intervention, with
+   step-by-step execution of rules.  However, it relies on humans
+   defining the sequence of rules, so is not Autonomic in the full
+   sense.  For example, a start-up script is automatic but not
+   autonomic.  An automatic function may need manual adjustments if the
+   environment changes.
+
+
+
+
+
+
+Behringer, et al.             Informational                     [Page 4]
+
+RFC 7575                  Autonomic Networking                 June 2015
+
+
+   Intent: An abstract, high-level policy used to operate the network.
+   Its scope is an autonomic domain, such as an enterprise network.  It
+   does not contain configuration or information for a specific node
+   (see Section 3.2 on how Intent coexists with alternative management
+   paradigms).  It may contain information pertaining to a node with a
+   specific role (for example, an edge switch) or a node running a
+   specific function.  Intent is typically defined and provided by a
+   central entity.
+
+   Autonomic Domain: A collection of autonomic nodes that instantiate
+   the same Intent.
+
+   Autonomic Function: A feature or function that requires no
+   configuration and can derive all required information through self-
+   knowledge, discovery, or Intent.
+
+   Autonomic Service Agent: An agent implemented on an autonomic node
+   that implements an autonomic function, either in part (in the case of
+   a distributed function) or whole.
+
+   Autonomic Node: A node that employs exclusively autonomic functions.
+   It requires (!) no configuration.  (Note that configuration can be
+   used to override an autonomic function.  See Section 3.2 for more
+   details.)  An Autonomic Node may operate on any layer of the
+   networking stack.  Examples are routers, switches, personal
+   computers, call managers, etc.
+
+   Autonomic Network: A network containing exclusively autonomic nodes.
+   It may contain one or several autonomic domains.
+
+3.  Design Goals
+
+   This section explains the high-level goals of Autonomic Networking,
+   independent of any specific solutions.
+
+3.1.  Self-Management
+
+   The original design goals of autonomic systems as described in
+   [Kephart] also apply to Autonomic Networks.  The overarching goal is
+   self-management, which is comprised of several "self" properties.
+   The most commonly cited are:
+
+   o  Self-configuration: Functions do not require configuration, by
+      either an administrator or a management system.  They configure
+      themselves, based on self-knowledge, discovery, and Intent.
+      Discovery is the default way for an autonomic function to receive
+      the information it needs to operate.
+
+
+
+
+Behringer, et al.             Informational                     [Page 5]
+
+RFC 7575                  Autonomic Networking                 June 2015
+
+
+   o  Self-healing: Autonomic functions adapt on their own to changes in
+      the environment and heal problems automatically.
+
+   o  Self-optimizing: Autonomic functions automatically determine ways
+      to optimize their behavior against a set of well-defined goals.
+
+   o  Self-protection: Autonomic functions automatically secure
+      themselves against potential attacks.
+
+   Almost any network can be described as "self-managing", as long as
+   the definition of "self" is large enough.  For example, a well-
+   defined Software-Defined Networking (SDN) system, including the
+   controller elements, can be described overall as "autonomic", if the
+   controller provides an interface to the administrator that has the
+   same properties as mentioned above (high level, network-wide, etc.).
+
+   For the work in the IETF and IRTF, we define the "self" properties on
+   the node level.  It is the design goal to make functions on network
+   nodes self-managing, in other words, minimally dependent on
+   management systems or controllers, as well as human operators.  Self-
+   managing functions on a node might need to exchange information with
+   other nodes in order to achieve this design goal.
+
+   As mentioned in the introduction, closed-loop control is an important
+   aspect of self-managing systems.  This implies peer-to-peer dialogues
+   between the parties that make up the closed loop.  Such dialogues
+   require two-way "discussion" or "negotiation" between each pair or
+   groups of peers involved in the loop, so they cannot readily use
+   typical top-down command-response protocols.  Also, a discovery phase
+   is unavoidable before such closed-loop control can take place.
+   Multiparty protocols are also possible but can be significantly more
+   complex.
+
+3.2.  Coexistence with Traditional Management
+
+   For the foreseeable future, autonomic nodes and networks will be the
+   exception; autonomic behavior will initially be defined function by
+   function.  Therefore, coexistence with other network management
+   paradigms has to be considered.  Examples are management by command
+   line, SNMP, SDN (with related APIs), the Network Configuration
+   Protocol (NETCONF), etc.
+
+   Conflict resolution between a) autonomic default behavior and Intent
+   and b) other methods is therefore required.  This is achieved through
+   prioritization.  Generally, autonomic mechanisms define a network-
+   wide behavior, whereas the alternative methods are typically on a
+   node-by-node basis.  Node-based management concepts take a higher
+   priority over autonomic methods.  This is in line with current
+
+
+
+Behringer, et al.             Informational                     [Page 6]
+
+RFC 7575                  Autonomic Networking                 June 2015
+
+
+   examples of autonomic functions; for example, with routing, a
+   (statically configured) route has priority over the routing
+   algorithm.  In short:
+
+   o  lowest priority: autonomic default behavior
+
+   o  medium priority: autonomic Intent
+
+   o  highest priority: node-specific network management concepts, such
+      as command line, SNMP, SDN, NETCONF, etc.  How these concepts are
+      prioritized is outside the scope of this document.
+
+   The above prioritization essentially results in the actions of the
+   human administrator always being able to overrule autonomic behavior.
+   This is generally the expectation of network operators today and
+   therefore remains a design principle here.  In critical systems, such
+   as atomic power plants, sometimes the opposite philosophy is used:
+   The expectation is that a well-defined algorithm is more reliable
+   than a human operator, especially in rare exception cases.
+   Networking generally does not follow this philosophy yet.  However,
+   warnings should be issued if node-specific overrides may conflict
+   with autonomic behavior.
+
+   In other fields, autonomic mechanisms disengage automatically if
+   certain conditions occur: The autopilot in a plane switches off if
+   the plane is outside a predefined envelope of flight parameters.  The
+   assumption is that the algorithms only work correctly if the input
+   values are in expected ranges.  However, some opinions suggest that
+   exactly in exceptional conditions is the worst moment to switch off
+   autonomic behavior, since the pilots have no full understanding of
+   the situation at this point and may be under high levels of stress.
+   For this reason, we suggest here to NOT generally disable autonomic
+   functions if they encounter unexpected conditions, because it is
+   expected that this adds another level of unpredictability in
+   networks, when the situation may already be hard to understand.
+
+3.3.  Secure by Default
+
+   All autonomic interactions should be secure by default.  This
+   requires that any member of an autonomic domain can assert its
+   membership using a domain identity, for example, a certificate issued
+   by a domain certification authority.  This domain identity is used
+   for nodes to learn about their neighboring nodes, to determine the
+   boundaries of the domain, and to cryptographically secure
+   interactions within the domain.  Nodes from different domains can
+   also mutually verify their identity and secure interactions as long
+   as they have a mutually respected trust anchor.
+
+
+
+
+Behringer, et al.             Informational                     [Page 7]
+
+RFC 7575                  Autonomic Networking                 June 2015
+
+
+   A strong, cryptographically verifiable domain identity is a
+   fundamental cornerstone in Autonomic Networking.  It can be leveraged
+   to secure all communications and thus allows automatic security
+   without traditional configuration, for example, preshared keys.  See
+   also the document "Making The Internet Secure By Default" [Behringer]
+   for more information.
+
+   Autonomic functions must be able to adapt their behavior depending on
+   the domain of the node they are interacting with.
+
+3.4.  Decentralization and Distribution
+
+   The goal of Autonomic Networking is to minimize dependencies on
+   central elements; therefore, decentralization and distribution are
+   fundamental to the concept.  If a problem can be solved in a
+   distributed manner, it should not be centralized.
+
+   In certain cases, it is today operationally preferable to keep a
+   central repository of information, for example, a user database on an
+   Authentication, Authorization, and Accounting (AAA) server.  An
+   Autonomic Network should be able to use such central systems, in
+   order to be deployable.  It is possible to distribute such databases
+   as well, and such efforts should be at least considered.  Depending
+   on the case, distribution may not be simple replication but may
+   involve more complex interactions and organization.
+
+3.5.  Simplification of Autonomic Node Northbound Interfaces
+
+   Even in a decentralized solution, certain information flows with
+   central entities are required.  Examples are high-level service
+   definitions, as well as network status requests, audit information,
+   logging, and aggregated reporting.
+
+   Therefore, nodes in an Autonomic Network require a northbound
+   interface.  However, the design goal is to maintain this interface as
+   simple and high level as possible.
+
+3.6.  Abstraction
+
+   An administrator or autonomic management system interacts with an
+   Autonomic Network on a high level of abstraction.  Intent is defined
+   at a level of abstraction that is much higher than that of typical
+   configuration parameters, for example, "optimize my network for
+   energy efficiency".  Intent must not be used to convey low-level
+   commands or concepts, since those are on a different abstraction
+   level.
+
+
+
+
+
+Behringer, et al.             Informational                     [Page 8]
+
+RFC 7575                  Autonomic Networking                 June 2015
+
+
+   For example, the administrator should not be exposed to the version
+   of the IP protocol running in the network.
+
+   Also on the reporting and feedback side, an Autonomic Network
+   abstracts information and provides high-level messages such as "the
+   link between node x and y is down" (possibly with an identifier for
+   the specific link, in case of multiple links).
+
+3.7.  Autonomic Reporting
+
+   An Autonomic Network, while minimizing the need for user
+   intervention, still needs to provide users with visibility like in
+   traditional networks.  However, in an Autonomic Network, reporting
+   should happen on a network-wide basis.  Information about the network
+   should be collected and aggregated by the network itself and
+   presented in a consolidated fashion to the administrator.
+
+   The layers of abstraction that are provided via Intent need to be
+   supported for reporting functions as well, in order to give users an
+   indication about the effectiveness of their Intent.  For example, in
+   order to assess how effective the network performs with regards to
+   the Intent "optimize my network for energy efficiency", the network
+   should provide aggregate information about the number of ports that
+   were able to be shut down, and the corresponding energy savings,
+   while validating current service levels are, on aggregate, still met.
+
+   Autonomic network events should concern the Autonomic Network as a
+   whole, not individual systems in isolation.  For example, the same
+   failure symptom should not be reported from every system that
+   observes it, but only once for the Autonomic Network as a whole.
+   Ultimately, the Autonomic Network should support exception-based
+   management, in which only events that truly require user attention
+   actually cause the user to be notified.  This requires capabilities
+   that allow systems within the network to compare information and
+   apply specific algorithms to determine what should be reported.
+
+3.8.  Common Autonomic Networking Infrastructure
+
+   [RFC7576] points out that there are already a number of autonomic
+   functions available today.  However, they are largely independent,
+   and each has its own methods and protocols to communicate, discover,
+   define, and distribute policy, etc.
+
+   The goal of the work on Autonomic Networking in the IETF is therefore
+   not just to create autonomic functions but to define a common
+   infrastructure that autonomic functions can use.  This Autonomic
+   Networking Infrastructure may contain common control and management
+
+
+
+
+Behringer, et al.             Informational                     [Page 9]
+
+RFC 7575                  Autonomic Networking                 June 2015
+
+
+   functions such as messaging, service discovery, negotiation, Intent
+   distribution, self-monitoring, and diagnostics, etc.  A common
+   approach to define and manage Intent is also required.
+
+   Refer to the reference model below: All the components around the
+   "Autonomic Service Agents" should be common components, such that the
+   Autonomic Service Agents do not have to replicate common tasks
+   individually.
+
+3.9.  Independence of Function and Layer
+
+   Autonomic functions may reside on any layer in the networking stack.
+   For example, Layer 2 switching today is already relatively autonomic
+   in many environments, since most switches can be plugged together in
+   many ways and will automatically build a simple Layer 2 topology.
+   Routing functions run on a higher layer and can be autonomic on Layer
+   3.  Even application-layer functionality such as unified
+   communications can be autonomic.
+
+   "Autonomic" in the context of this framework is a property of a
+   function that is implemented on a node.  Autonomic functions can be
+   implemented on any node type, for example, a switch, router, server,
+   or call manager.
+
+   An Autonomic Network requires an overall control plane for autonomic
+   nodes to communicate.  As in general IP networking, IP is the
+   spanning layer that binds all those elements together; autonomic
+   functions in the context of this framework should therefore operate
+   at the IP layer.  This concerns neighbor discovery protocols and
+   other functions in the Autonomic Control Plane.
+
+3.10.  Full Life-Cycle Support
+
+   An autonomic function does not depend on external input to operate;
+   it needs to understand its current situation and surroundings and
+   operate according to its current state.  Therefore, an autonomic
+   function must understand the full life cycle of the device it runs
+   on, from manufacturing and initial testing through deployment,
+   testing, troubleshooting, and decommissioning.
+
+   The state of the life cycle of an autonomic node is reflected in a
+   state model.  The behavior of an autonomic function may be different
+   for different deployment states.
+
+
+
+
+
+
+
+
+Behringer, et al.             Informational                    [Page 10]
+
+RFC 7575                  Autonomic Networking                 June 2015
+
+
+4.  Not among the Design Goals
+
+   This section identifies various items that are explicitly not design
+   goals in the IETF and IRTF for Autonomic Networks; they are mentioned
+   to avoid misunderstandings of the general intention.  They address
+   some commonly expressed concerns from network administrators and
+   architects.
+
+4.1.  Eliminate Human Operators
+
+   Section 3.1 states that "It is the design goal to make functions
+   [...] minimally dependent on [...] human operators".  However, it is
+   not a design goal to completely eliminate them.  The problem targeted
+   by Autonomic Networking is the error-prone and hard-to-scale model of
+   individual configuration of network elements, traditionally by manual
+   commands but today mainly by scripting and/or configuration
+   management databases.  This does not, however, imply the elimination
+   of skilled human operators, who will still be needed for oversight,
+   policy management, diagnosis, reaction to help-desk tickets, etc.
+   The main impact on administrators should be less tedious detailed
+   work and more high-level work.  (They should become more like doctors
+   than hospital orderlies.)
+
+4.2.  Eliminate Emergency Fixes
+
+   However good the autonomous mechanisms, sometimes there will be fault
+   conditions, etc., that they cannot deal with correctly.  At that
+   point, skilled operator interventions will be needed to correct or
+   work around the problem.  Hopefully, this can be done by high-level
+   mechanisms (adapting the policy database in some way), but, in some
+   cases, direct intervention at the device level may be unavoidable.
+   This is obviously the case for hardware failures, even if the
+   Autonomic Network has bypassed the fault for the time being.  "Truck
+   rolls" will not be eliminated when faulty equipment needs to be
+   replaced.  However, this may be less urgent if the autonomic system
+   automatically reconfigures to minimize the operational impact.
+
+4.3.  Eliminate Central Control
+
+   While it is a goal to simplify northbound interfaces (Section 3.5),
+   it is not a goal to eliminate central control, but to allow it on a
+   higher abstraction level.  Senior management might fear loss of
+   control of an Autonomic Network.  In fact, this is no more likely
+   than with a traditional network; the emphasis on automatically
+   applying general policy and security rules might even provide more
+   central control.
+
+
+
+
+
+Behringer, et al.             Informational                    [Page 11]
+
+RFC 7575                  Autonomic Networking                 June 2015
+
+
+5.  An Autonomic Reference Model
+
+   An Autonomic Network consists of Autonomic Nodes.  Those nodes
+   communicate with each other through an Autonomic Control Plane that
+   provides a robust and secure communications overlay.  The Autonomic
+   Control Plane is self-organizing and autonomic itself.
+
+   An Autonomic Node contains various elements, such as autonomic
+   service agents that implement autonomic functions.  Figure 1 shows a
+   reference model of an autonomic node.  The elements and their
+   interaction are:
+
+   o  Autonomic Service Agents: They implement the autonomic behavior of
+      a specific service or function.
+
+   o  Self-knowledge: An autonomic node knows its own properties and
+      capabilities
+
+   o  Network Knowledge (Discovery): An Autonomic Service Agent may
+      require various discovery functions in the network, such as
+      service discovery.
+
+   o  Feedback Loops: Control elements outside the node may interact
+      with autonomic nodes through feedback loops.
+
+   o  An Autonomic User Agent, providing a front-end to external users
+      (administrators and management applications) through which they
+      can receive reports and monitor the Autonomic Network.
+
+   o  Autonomic Control Plane: Allows the node to communicate with other
+      autonomic nodes.  Autonomic functions such as Intent distribution,
+      feedback loops, discovery mechanisms, etc., use the Autonomic
+      Control Plane.  The Autonomic Control Plane can run in-band, over
+      a configured VPN, over a self-managing overlay network as
+      described in [ACP], or over a traditional out-of-band network.
+      Security is a requirement for the Autonomic Control Plane, which
+      can be bootstrapped by a mechanism as described in [BOOTSTRAP].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Behringer, et al.             Informational                    [Page 12]
+
+RFC 7575                  Autonomic Networking                 June 2015
+
+
+   +------------------------------------------------------------+
+   |                      +------------+                        |
+   |                      | Feedback   |                        |
+   |                      |    Loops   |                        |
+   |                      +------------+                        |
+   |                            ^                               |
+   |                    Autonomic User Agent                    |
+   |                            V                               |
+   | +-----------+        +------------+        +------------+  |
+   | | Self-     |        | Autonomic  |        | Network    |  |
+   | | knowledge |<------>| Service    |<------>| Knowledge  |  |
+   | |           |        | Agents     |        | (Discovery)|  |
+   | +-----------+        +------------+        +------------+  |
+   |                            ^                     ^         |
+   |                            |                     |         |
+   |                            V                     V         |
+   |------------------------------------------------------------|
+   |                 Autonomic Control Plane                    |
+   |------------------------------------------------------------|
+   |           Standard Operating System Functions              |
+   +------------------------------------------------------------+
+
+              Figure 1: Reference Model for an Autonomic Node
+
+   At the time of finalizing this document, this reference model is
+   being worked out in more detail.  See [Reference-Model] for more
+   details.
+
+6.  Security Considerations
+
+   This document provides definitions and design goals for Autonomic
+   Networking.  A full threat analysis will be required as part of the
+   development of solutions, taking account of potential attacks from
+   within the network as well as from outside.
+
+7.  Informative References
+
+   [ACP]      Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An
+              Autonomic Control Plane", Work in Progress,
+              draft-behringer-anima-autonomic-control-plane-02, March
+              2015.
+
+   [Behringer]
+              Behringer, M., Pritikin, M., and S. Bjarnason, "Making The
+              Internet Secure By Default", Work in Progress,
+              draft-behringer-default-secure-00, January 2014.
+
+
+
+
+
+Behringer, et al.             Informational                    [Page 13]
+
+RFC 7575                  Autonomic Networking                 June 2015
+
+
+   [BOOTSTRAP]
+              Pritikin, M., Behringer, M., and S. Bjarnason,
+              "Bootstrapping Key Infrastructures", Work in Progress,
+              draft-pritikin-anima-bootstrapping-keyinfra-01, February
+              2015.
+
+   [Dobson]   Dobson, S., Denazis, S., Fernandez, A., Gaiti, D.,
+              Gelenbe, E., Massacci, F., Nixon, P., Saffre, F., Schmidt,
+              N., and F. Zambonelli, "A survey of autonomic
+              communications", ACM Transactions on Autonomous and
+              Adaptive Systems (TAAS), Volume 1, Issue 2, Pages 223-259,
+              DOI 10.1145/1186778.1186782, December 2006.
+
+   [GANA]     ETSI, "Autonomic network engineering for the self-managing
+              Future Internet (AFI); Generic Autonomic Network
+              Architecture (An Architectural Reference Model for
+              Autonomic Networking, Cognitive Networking and Self-
+              Management)", ETSI GS AFI 002, April 2013,
+              <http://www.etsi.org/deliver/etsi_gs/
+              AFI/001_099/002/01.01.01_60/gs_afi002v010101p.pdf>.
+
+   [Kephart]  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.
+
+   [Movahedi] Movahedi, Z., Ayari, M., Langar, R., and G. Pujolle, "A
+              Survey of Autonomic Network Architectures and Evaluation
+              Criteria", IEEE Communications Surveys & Tutorials, Volume
+              14, Issue 2, Pages 464-490,
+              DOI 10.1109/SURV.2011.042711.00078, 2012.
+
+   [Reference-Model]
+              Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia,
+              L., and B. Liu, "A Reference Model for Autonomic
+              Networking", Work in Progress, draft-behringer-anima-
+              reference-model-02, June 2015.
+
+   [RFC7576]  Jiang, S., Carpenter, B., and M. Behringer, "General Gap
+              Analysis for Autonomic Networking", RFC 7576,
+              DOI 10.17487/RFC7576, June 2015,
+              <http://www.rfc-editor.org/info/rfc7576>.
+
+   [Samaan]   Samaan, N. and A. Karmouch, "Towards Autonomic Network
+              Management: an Analysis of Current and Future Research
+              Directions", IEEE Communications Surveys and Tutorials,
+              Volume 11, Issue 3, Page(s) 22-36,
+              DOI 10.1109/SURV.2009.090303, 2009.
+
+
+
+
+Behringer, et al.             Informational                    [Page 14]
+
+RFC 7575                  Autonomic Networking                 June 2015
+
+
+Acknowledgements
+
+   Many parts of this work on Autonomic Networking are the result of a
+   large team project at Cisco Systems.  In alphabetical order: Ignas
+   Bagdonas, Parag Bhide, Balaji BL, Toerless Eckert, Yves Hertoghs,
+   Bruno Klauser.
+
+   We thank the following people for their input to this document:
+   Dimitri Papadimitriou, Rene Struik, Kostas Pentikousis, Dave Oran,
+   and Diego Lopez Garcia.
+
+   The ETSI working group AFI <http://portal.etsi.org/afi> defines a
+   similar framework for Autonomic Networking in the "General Autonomic
+   Network Architecture" [GANA].  Many concepts explained in this
+   document can be mapped to the GANA framework.  The mapping is outside
+   the scope of this document.  Special thanks to Ranganai Chaparadza
+   for his comments and help on this document.
+
+Authors' Addresses
+
+   Michael H. Behringer
+   Cisco Systems
+   Building D, 45 Allee des Ormes
+   Mougins  06250
+   France
+
+   EMail: mbehring@cisco.com
+
+
+   Max Pritikin
+   Cisco Systems
+   5330 Airport Blvd
+   Boulder, CO  80301
+   United States
+
+   EMail: pritikin@cisco.com
+
+
+   Steinthor Bjarnason
+   Cisco Systems
+   Mail Stop LYS01/5
+   Philip Pedersens vei 1
+   LYSAKER, AKERSHUS  1366
+   Norway
+
+   EMail: sbjarnas@cisco.com
+
+
+
+
+
+Behringer, et al.             Informational                    [Page 15]
+
+RFC 7575                  Autonomic Networking                 June 2015
+
+
+   Alexander Clemm
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose, CA  95134-1706
+   United States
+
+   EMail: alex@cisco.com
+
+
+   Brian Carpenter
+   Department of Computer Science
+   University of Auckland
+   PB 92019
+   Auckland  1142
+   New Zealand
+
+   EMail: brian.e.carpenter@gmail.com
+
+
+   Sheng Jiang
+   Huawei Technologies Co., Ltd
+   Q14, Huawei Campus
+   No.156 Beiqing Road
+   Hai-Dian District, Beijing  100095
+   China
+
+   EMail: jiangsheng@huawei.com
+
+
+   Laurent Ciavaglia
+   Alcatel Lucent
+   Route de Villejust
+   Nozay  91620
+   France
+
+   EMail: laurent.ciavaglia@alcatel-lucent.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Behringer, et al.             Informational                    [Page 16]
+