GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7575

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7575.txt · Last modified: 2015/06/19 01:21 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki