One document matched: draft-irtf-nmrg-autonomic-network-definitions-07.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited by Michael Behringer -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.irtf-nmrg-an-gap-analysis PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.irtf-nmrg-an-gap-analysis.xml">
<!ENTITY I-D.behringer-autonomic-control-plane PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.behringer-autonomic-control-plane.xml">
<!ENTITY I-D.pritikin-bootstrapping-keyinfrastructures PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.pritikin-bootstrapping-keyinfrastructures.xml">
]>
<rfc category="info"
docName="draft-irtf-nmrg-autonomic-network-definitions-07.txt"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="Autonomic Networking">Autonomic
Networking - Definitions and Design Goals</title>
<author fullname="Michael Behringer" initials="M." surname="Behringer">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Building D, 45 Allee des Ormes</street>
<city>Mougins</city>
<region/>
<code>06250</code>
<country>France</country>
</postal>
<email>mbehring@cisco.com</email>
</address>
</author>
<author fullname="Max Pritikin" initials="M" surname="Pritikin">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>5330 Airport Blvd</street>
<city>Boulder</city>
<region>CO</region>
<code>80301</code>
<country>USA</country>
</postal>
<email>pritikin@cisco.com</email>
</address>
</author>
<author fullname="Steinthor Bjarnason" initials="S." surname="Bjarnason">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Mail Stop LYS01/5</street>
<street>Philip Pedersens vei 1</street>
<city>LYSAKER</city>
<region>AKERSHUS</region>
<code>1366</code>
<country>Norway</country>
</postal>
<email>sbjarnas@cisco.com</email>
</address>
</author>
<author fullname="Alexander Clemm" initials="A." surname="Clemm">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose </city>
<region>California</region>
<code>95134-1706</code>
<country>USA</country>
</postal>
<email>alex@cisco.com</email>
</address>
</author>
<author initials="B. E." surname="Carpenter" fullname="Brian Carpenter">
<organization abbrev="Univ. of Auckland"></organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>University of Auckland</street>
<street>PB 92019</street>
<city>Auckland</city>
<region></region>
<code>1142</code>
<country>New Zealand</country>
</postal>
<email>brian.e.carpenter@gmail.com</email>
</address>
</author>
<author fullname="Sheng Jiang" initials="S." surname="Jiang">
<organization>Huawei Technologies Co., Ltd</organization>
<address>
<postal>
<street>Q14, Huawei Campus</street>
<street>No.156 Beiqing Road</street>
<city>Hai-Dian District, Beijing</city>
<code>100095</code>
<country>P.R. China</country>
</postal>
<email>jiangsheng@huawei.com</email>
</address>
</author>
<author fullname="Laurent Ciavaglia" initials="L." surname="Ciavaglia">
<organization>Alcatel Lucent</organization>
<address>
<postal>
<street>Route de Villejust</street>
<city>Nozay</city>
<region/>
<code>91620</code>
<country>France</country>
</postal>
<email>laurent.ciavaglia@alcatel-lucent.com</email>
</address>
</author>
<date day="23" month="March" year="2015"/>
<workgroup>Internet Research Task Force</workgroup>
<abstract>
<t>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.</t>
<t>This document defines common language, and outlines design goals
and non-design goals for autonomic functions. A high level reference
model illustrates how functional elements in an autonomic network
interact.
</t>
</abstract>
</front>
<middle>
<section title="Introduction to Autonomic Networking">
<t>Autonomic systems were first described in a manifesto by IBM in 2001
<xref target="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.</t>
<t>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 or ISIS
exhibit properties of self-management, and can thus be considered
autonomic in the definition of this document.</t>
<t>However, as IP networking evolved, the ever increasing intelligence
of network elements was often not put into protocols to follow this
paradigm, but external configuration systems. This configuration made network
elements dependent on some process that manages them, either a
human, or a network management system.</t>
<t>Autonomic functions can be defined in two ways:
<list style="symbols">
<t>On a node level: Nodes interact with each other to form feedback
loops.</t>
<t>On a system level: Feedback loops include central elements as well. </t>
</list>
System level autonomy is implicitly or explicitly the subject in many IETF
working groups, where interactions with controllers or network management
systems are discussed.
</t>
<t>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. </t>
<t>Some network deployments benefit from a fully autonomic approach, for
example networks with a large number of relatively simple devices.
Most of 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 centralised or follow an autonomic
approach. Instead, it should help make the decision which is the best
approach for a given situation.</t>
<t>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.</t>
<t>Autonomic Computing in general and Autonomic Networking in particular
have been the subject of academic study for many years. There is a large
literature, including several useful overview papers (e.g.,
<xref target="Samaan"/>, <xref target="Movahedi"/>, and
<xref target="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 co-exist with traditional methods of network
configuration and management, rather than realising an exclusively
autonomic system with all the properties that it would require. </t>
<t>There is an important difference between "automatic" and "autonomic".
"Automatic" refers to a pre-defined 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. </t>
<t>This document provides the definitions and design goals for
Autonomic Networking in the IETF and IRTF.</t>
</section>
<section title="Definitions">
<t>We make the following definitions:</t>
<t>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. </t>
<t>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. </t>
<t>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 <xref target="coexistence"/> on how Intent co-exists with
alternative management paradigms). It may contain information pertaining
to nodes 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.</t>
<t>Autonomic Domain: A collection of autonomic nodes that instantiate
the same Intent.</t>
<t>Autonomic Function: A feature or function which requires no configuration, and
can derive all required information either through self-knowledge, discovery or through Intent. </t>
<t>Autonomic Service Agent: An agent implemented on an autonomic node
which implements an autonomic function, either in part (in the case of
a distributed function) or whole.</t>
<t>Autonomic Node: A node which employs exclusively autonomic functions.
It requires (!) no configuration. (Note that configuration can be used to
override an autonomic function. See <xref target="coexistence"/> for
more details.) An Autonomic Node may operate on any layer of the networking
stack. Examples are routers, switches, personal computers, call managers,
etc.</t>
<t>Autonomic Network: A network containing exclusively autonomic nodes. It
may contain one or several autonomic domains.</t>
</section>
<section title="Design Goals">
<t>This section explains the high level goals of Autonomic Networking,
independent of any specific solutions.
</t>
<section title="Self-Management" anchor="self-management">
<t>The original design goals of autonomic systems as described in
<xref target="Kephart"/> also apply to Autonomic Networks. The
over-arching goal is self-management, which is comprised of several
self-* properties. The most commonly cited are:
<list style="symbols">
<t>Self-configuration: Functions do not require to be configured, neither
by an administrator nor 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.</t>
<t>Self-healing: Autonomic functions adapt on their own to changes
in the environment, and heal problems automatically. </t>
<t>Self-optimising: Autonomic functions automatically determine ways to
optimise their behaviour against a set of well-defined goals. </t>
<t>Self-protection: Autonomic functions automatically secure themselves against
potential attacks.</t>
</list></t>
<t>Almost any network can be described as "self-managing", as long as
the definition of "self" is large enough. For example, a well-defined SDN
system, including the controller elements, can be described over all as
"autonomic", if the controller provides an interface to the administrator which
has the same properties as mentioned above (high level, network-wide, etc).
</t>
<t>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. </t>
<t>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. Multi-party protocols are also possible but
can be significantly more complex. </t>
</section>
<section title="Co-Existence with Traditional Management" anchor="coexistence">
<t>For the foreseeable future, autonomic nodes and networks will be the
exception; autonomic behaviour will initially be defined function by function.
Therefore, co-existence with other network management paradigms has to be
considered. Examples are management by command line, SNMP, SDN (with related
APIs), NETCONF, etc.</t>
<t>Conflict resolution between autonomic default behaviour and Intent on one
side, and other methods on the other is therefore required. This is achieved through prioritisation. Generally,
autonomic mechanisms define a network wide behaviour, 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
examples of autonomic functions, for example routing: A (statically configured)
route has priority over the routing algorithm. In short:
<list style="symbols">
<t>lowest priority: autonomic default behaviour</t>
<t>medium priority: autonomic Intent</t>
<t>highest priority: node specific network management concepts, such as
command line, SNMP, SDN, NETCONF, etc. How these concepts are prioritised
between themselves is outside the scope of this document. </t>
</list></t>
<t>The above priorisation essentially results in the actions of the human administrator always being able to over-rule autonomic behaviour. This is generally the expectation of network operators today, and remains therefore 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. Warnings however should be issued if node specific overrides may conflict with autonomic behaviour.</t>
<t>In other fields, autonomic mechanisms disengage automatically if certain conditions occur: The auto-pilot in a plane switches off if the plane is outside a pre-defined envelope of flight parameters. The assumption is that the algorithms only work correctly if the input values are in expected ranges. Some opinions however suggest that exactly in exceptional conditions is the worst moment to switch off autonomic behaviour, 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. </t>
</section>
<section title="By Default Secure">
<t>All autonomic interactions should be by default secure.
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
neighbouring 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.</t>
<t>A strong, cryptographically verifiable domain identity is a
fundamental cornerstone in Autonomic Networking. It can be leveraged
to secure all communications, and allows thus automatic security
without traditional configuration, for example pre-shared keys.</t>
<t>Autonomic functions must be able to adapt their behaviour depending on
the domain of the node they are interacting with.</t>
</section>
<section title="Decentralisation and Distribution">
<t>The goal of Autonomic Networking is to minimise dependencies on
central elements; therefore, de-centralisation and distribution are
fundamental to the concept. If a problem can be solved in a
distributed manner, it should not be centralised.</t>
<t>In certain cases it is today operationally preferable to keep a
central repository of information, for example a user database on a
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 involve more complex interactions and organisation.</t>
</section>
<section title="Simplification of Autonomic Node Northbound Interfaces" anchor="simple-north">
<t>Even in a decentralised 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. </t>
<t>Therefore, also 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. </t>
</section>
<section title="Abstraction">
<t>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. </t>
<t>For example, the
administrator should not be exposed to the version of the IP
protocol running in the network.</t>
<t>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).</t>
</section>
<section title="Autonomic Reporting">
<t>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, presented in
consolidated fashion to the administrator.</t>
<t>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.</t>
<t>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 are actually
notified. This requires capabilities that allow systems within the
network to compare information and apply specific algorithms to
determine what should be reported.</t>
</section>
<section title="Common Autonomic Networking Infrastructure">
<t><xref target="I-D.irtf-nmrg-an-gap-analysis"/> points out that there are already a number of autonomic functions available today. However, these are largely independent, and each has its own methods and protocols to communicate, discover, define and distribute policy, etc. </t>
<t>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 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. </t>
<t>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. </t>
</section>
<section title="Independence of Function and Layer">
<t>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.</t>
<t>"Autonomic" in the context of this framework is a property
of a function which is implemented on a node. Autonomic functions
can be implemented on any node type, for example a switch,
router, server, or call manager.
</t>
<t>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 neighbour discovery protocols and other Autonomic
Control Plane functions.</t>
</section>
<section title="Full Life Cycle Support">
<t>An autonomic function does not depend on external input to operate; it
needs to understand its current situation and surrounding, and operate
according to its current state. Therefore, an autonomic function must
understand the full life cycle of the device it runs on, from first manufacturing testing
through deployment, testing, troubleshooting, up to
decommissioning.</t>
<t>The state of the life-cycle of an autonomic node is reflected in a
state model. The behaviour of an autonomic function may be different for
different deployment states.</t>
</section>
</section>
<section title="Non Design Goals">
<t>This section identifies various items that are explicitly not design goals in the IETF/IRTF for autonomic networks, which are mentioned to avoid misunderstandings of the general intention. They address some commonly expressed concerns from network administrators and architects. </t>
<section title="Eliminate human operators">
<t><xref target="self-management"/> states that "It is the design goal to [...] minimally dependent on
[...] human operators". It is however 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.)</t>
</section>
<section title="Eliminate emergency fixes">
<t>However good the autonomous mechanisms, sometimes there will be fault conditions etc. that they cannot deal with correctly. At this 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 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 minimise the operational impact. </t>
</section>
<section title="Eliminate central control">
<t>While it is a goal to simplify northbound interfaces (<xref target="simple-north"/>), 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.</t>
</section>
</section>
<section title="An Autonomic Reference Model">
<t>An Autonomic Network consists of Autonomic Nodes. Those nodes
communicate with each other through an Autonomic Control Plane which
provides a robust and secure communications overlay. The Autonomic
Control Plane is self-organizing and autonomic itself.</t>
<t>An Autonomic Node contains various elements, such as autonomic
service agents which implement autonomic functions. Figure 1 shows
a reference model of an autonomic node.
The elements and their interaction are:
<list style="symbols">
<t>Autonomic Service Agents, which implement the autonomic behaviour
of a specific service or function.</t>
<t>Self-knowledge: An autonomic node knows its own properties
and capabilities</t>
<t>Network Knowledge (Discovery): An autonomic service agent
may require various discovery functions in the network, such as
service discovery. </t>
<t>Intent: Network wide high level policy. Autonomic Service Agents
use an Intent interpretation engine to locally
instantiate the global Intent. This may involve coordination with
other Autonomic Nodes.</t>
<t>Feedback Loops: Control elements outside the node may interact
with autonomic nodes through feedback loops. </t>
<t>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.</t>
<t>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 inband, over a configured VPN, over a
self-managing overlay network, as described in
<xref target="I-D.behringer-autonomic-control-plane"/>, 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 <xref target="I-D.pritikin-bootstrapping-keyinfrastructures"/>.
</t>
</list></t>
<t>
<vspace blankLines='100' />
<figure anchor='ref_model' title="Reference Model for an Autonomic Node">
<artwork>
+------------------------------------------------------------+
| +------------+ |
| | Feedback | |
| | Loops | |
| +------------+ |
| ^ |
| Autonomic User Agent |
| V |
| +-----------+ +------------+ +------------+ |
| | Self- | | Autonomic | | Network | |
| | knowledge |<------>| Service |<------>| Knowledge | |
| | | | Agents | | (Discovery)| |
| +-----------+ +------------+ +------------+ |
| ^ ^ |
| | | |
| V V |
|------------------------------------------------------------|
| Autonomic Control Plane |
|------------------------------------------------------------|
| Standard Operating System Functions |
+------------------------------------------------------------+
</artwork>
</figure>
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This draft does not request any IANA action.</t>
</section>
<section title="Security Considerations">
<t>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.</t>
</section>
<section title="Acknowledgements">
<t>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.</t>
<t>We thank the following people for their input to this document:
Dimitri Papadimitriou, Rene Struik, Kostas Pentikousis, Dave Oran, and Diego Lopez Garcia. </t>
<t>The ETSI working group AFI (http://portal.etsi.org/afi) defines a
similar framework for Autonomic Networking in the
"General Autonomic Network Architecture" <xref
target="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. </t>
</section>
</middle>
<back>
<references title="Informative References">
&I-D.irtf-nmrg-an-gap-analysis;
&I-D.behringer-autonomic-control-plane;
&I-D.pritikin-bootstrapping-keyinfrastructures;
<reference anchor="Kephart" target="http://users.soe.ucsc.edu/~griss/agent-papers/ieee-autonomic.pdf">
<front>
<title>The Vision of Autonomic Computing</title>
<author initials="J." surname="Kephart"/>
<author initials="D." surname="Chess"/>
<date month="January" year="2003"/>
</front>
<seriesInfo name="IEEE Computer" value="vol. 36, no. 1, pp. 41–50"/>
</reference>
<reference anchor="Movahedi">
<front>
<title>A Survey of Autonomic Network Architectures and Evaluation Criteria</title>
<author initials="Z." surname="Movahedi"/>
<author initials="M." surname="Ayari"/>
<author initials="R." surname="Langar"/>
<author initials="G." surname="Pujolle"/>
<date year="2012"/>
</front>
<seriesInfo name="IEEE Communications Surveys & Tutorials" value="Volume: 14 , Issue: 2 DOI: 10.1109/SURV.2011.042711.00078, Page(s): 464 – 490"/>
</reference>
<reference anchor="Samaan">
<front>
<title>Towards Autonomic Network Management: an Analysis of Current and Future Research Directions</title>
<author initials="N." surname="Samaan"/>
<author initials="A." surname="Karmouch"/>
<date year="2009"/>
</front>
<seriesInfo name="IEEE Communications Surveys and Tutorials" value="Volume: 11 , Issue: 3; DOI: 10.1109/SURV.2009.090303; Page(s): 22 - 36"/>
</reference>
<reference anchor="GANA"
target="http://www.etsi.org/deliver/etsi_gs/AFI/001_099/002/01.01.01_60/gs_afi002v010101p.pdf">
<front>
<title>Autonomic network engineering for the self-managing Future Internet (AFI): GANA Architectural Reference Model for Autonomic Networking, Cognitive Networking and Self-Management. </title>
<author surname="ETSI GS AFI 002"/>
<date month="April" year="2013"/>
</front>
</reference>
<reference anchor="Dobson">
<front>
<title>A survey of autonomic communications</title>
<author initials="S." surname="Dobson et al."/>
<date month="December" year="2006"/>
</front>
<seriesInfo name="ACM Transactions on Autonomous and Adaptive Systems (TAAS)" value="Volume 1 Issue 2, Pages 223-259 "/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:55:14 |