One document matched: draft-behringer-autonomic-network-framework-00.txt
Network Working Group M. Behringer
Internet-Draft M. Pritikin
Intended status: Informational S. Bjarnason
Expires: December 24, 2012 A. Clemm
Cisco Systems
June 22, 2012
A Framework for Autonomic Networking
draft-behringer-autonomic-network-framework-00.txt
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 document applies the concepts of autonomic systems to a network,
and describes a framework for Autonomic Networking. The goal is a
network where nodes have minimal dependencies on human administrators
or centralized management systems.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 24, 2012.
Copyright Notice
Copyright (c) 2012 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
Behringer, et al. Expires December 24, 2012 [Page 1]
Internet-Draft autonomic-network-framework June 2012
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction to Autonomic Networking . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Fundamental Concepts . . . . . . . . . . . . . . . . . . . . . 4
3.1. Domain Identity . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Intent . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Abstraction . . . . . . . . . . . . . . . . . . . . . . . . 5
3.5. Autonomic Reporting . . . . . . . . . . . . . . . . . . . . 5
3.6. Decentralisation and Distribution . . . . . . . . . . . . . 6
3.7. Modularity . . . . . . . . . . . . . . . . . . . . . . . . 6
3.8. Independence of Function and Layer . . . . . . . . . . . . 6
3.9. Full Life Cycle Support . . . . . . . . . . . . . . . . . . 7
4. An Autonomic Framework . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Behringer, et al. Expires December 24, 2012 [Page 2]
Internet-Draft autonomic-network-framework June 2012
1. Introduction to Autonomic Networking
Autonomic systems were first described in a manifesto by IBM in 2001
[1]. 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 autonomic
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. A routing protocol such as OSPF
or ISIS exhibits properties of self-management, and can thus be
considered autonomic in the definition of this framework.
However, as IP networking evolved, the ever increasing intelligence
of network element was often not put into protocols to follow this
paradigm, but into configuration. This configuration made network
elements highly dependent on some process that manages them, either a
human, or a network management system.
Autonomic Networking aims at putting the intelligence of today's
operations back into algorithms at the node level, to minimize
dependency on human administrators and central management systems.
Some information an autonomic node requires however cannot be
discovered; where input from some central intelligence is required,
it is provided in a highly abstract, network wide form.
This document provides a framework for achieving this goal.
2. Definitions
Autonomic: Self-managing (self-configuring, self-protecting, self-
healing and self-optimizing); however, allowing high-level guidance
by a central entity, through intent.
Intent: An abstract, high level policy used to operate the network
autonomically. Its scope is an autonomic domain, such as an
enterprise network. It does not contain configuration or information
for a specific node. It may contain information pertaining to nodes
with a specific role.
Autonomic Domain: A collection of autonomic nodes that instantiate
the same intent.
Autonomic Function: A function which requires no configuration, and
can derive all required information either through discovery or
Behringer, et al. Expires December 24, 2012 [Page 3]
Internet-Draft autonomic-network-framework June 2012
through intent.
Autonomic Node: A node which employs autonomic functions. It may
operate on any layer of the networking stack. Examples are routers,
switches, personal computers, call managers, etc.
Fully Autonomic Node: A node which employs exclusively autonomic
functions. It requires no configuration.
Autonomic Network: A network containing autonomic nodes.
Fully Autonomic Network: A network consisting of exclusively
autonomic nodes.
3. Fundamental Concepts
3.1. Domain Identity
Any member of the 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 common trust anchor.
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.
Autonomic nodes must be able to adapt their behaviour depending on
the domain of the node they are interacting with.
3.2. Discovery
In traditional networks, significant amounts of the information that
a node needs to operate are provided through northbound interfaces,
for example configuration. An autonomic node has a minimal
northbound interface, limited to receiving intent and providing
feedback loops.
Discovery is the default way for a node to receive the information it
needs to operate.
There are certain pieces of information that a node cannot discover,
because they derive from non-technical business objectives. For
Behringer, et al. Expires December 24, 2012 [Page 4]
Internet-Draft autonomic-network-framework June 2012
example a routing policy cannot be discovered through intelligence in
the network. This type of information is an exception to the rule of
"default discover", and is propagated in intent.
3.3. Intent
An autonomic network has to allow for input from the outside to guide
the network's behaviour. The administrator's desired behaviour of
the network is expressed as "intent". It contains certain
information which is derived from business level objectives. Intent
should only include information which the network cannot infer or
discover.
Intent has a network wide scope and must be communicated to all nodes
of the network, independent of their function. A node may
instantiate only the portions of intent that are relevant to its
function. Intent must not be used to address specific nodes or
locations in the network.
3.4. 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. The administrator should not even 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".
3.5. 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, presented
in 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
Behringer, et al. Expires December 24, 2012 [Page 5]
Internet-Draft autonomic-network-framework June 2012
should provide aggregate information about the number of ports that
were able to be shut down 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
are actually notified. This requires capabilities that allow systems
within the network to compare information and apply special
algorithms to determine what should be reported.
3.6. Decentralisation and Distribution
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.
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 must also be able to use such
central systems, in order to be deployable. However, it is possible
to distribute such databases as well, and such efforts should be at
least considered.
3.7. Modularity
It is unrealistic to expect a fully autonomic network in complex
environments for many years to come. While simple networks may
become autonomic in one single step, a phased approach is required
for most of today's networks.
Autonomic functions can be implemented in a modular way. For
example, the internal routing algorithm in many networks today is
already mostly autonomic. Other modules can be made autonomic step
by step.
3.8. Independence of Function and Layer
Today's autonomic functions may reside on any layer in the networking
stack. For example, layer 2 switching today is already relatively
autonomic in many environments; routing functions can be autonomic.
"Autonomic" in the context of this framework is a property of a node.
This node can be a switch, router, server, or call manager.
Autonomic functionality is independent of the function of a node.
Behringer, et al. Expires December 24, 2012 [Page 6]
Internet-Draft autonomic-network-framework June 2012
Even application layer functionality such as unified communications
can be autonomic.
An Autonomic Network requires an overall control plane for autonomic
nodes to communicate. As in general IP networking, IP is the 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.
3.9. Full Life Cycle Support
An autonomic node 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 node
must understand its full life cycle, from first manufacturing testing
through deployment, testing, troubleshooting, up to decommissioning.
The state of the life-cycle of an autonomic node is reflected in a
state model. The behaviour of an autonomic node may be different for
different deployment states.
4. An Autonomic Framework
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.
An Autonomic Node runs Autonomic Processes. These Autonomic
Processes include:
o An Autonomic Control Plane client, allowing the node to
participate in the Autonomic Control Plane.
o An Intent Interpretation Engine, allowing the node to locally
instantiate the global intent. This may involve coordination with
other Autonomic Nodes.
o An Intent Dissemination Function, to share the global intent with
other autonomic nodes.
o An Aggregation and Decentralized Monitoring Engine, allowing the
node to participate in the collection and aggregation of
statistics and reports across the Autonomic Network.
o An Autonomic User Agent, providing a front-end to external users
(administrators and management applications) through which they
can communicate intent, receive reports, and monitor the Autonomic
Network.
Behringer, et al. Expires December 24, 2012 [Page 7]
Internet-Draft autonomic-network-framework June 2012
5. Security Considerations
This document specifies a framework. Security is an integral part of
this framework.
6. Acknowledgements
The work on Autonomic Networking is 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.
Authors' Addresses
Michael H. Behringer
Cisco Systems
Email: mbehring@cisco.com
Max Pritikin
Cisco Systems
Email: pritikin@cisco.com
Steinthor Bjarnason
Cisco Systems
Email: sbjarnas@cisco.com
Alex Clemm
Cisco Systems
Email: alex@cisco.com
Behringer, et al. Expires December 24, 2012 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-21 17:53:48 |