One document matched: draft-irtf-nmrg-an-gap-analysis-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-irtf-nmrg-an-gap-analysis-00"
ipr="trust200902">
<front>
<title abbrev="Autonomic Networking Gap Analysis">Gap Analysis for
Autonomic Networking</title>
<author fullname="Michael H. Behringer" initials="M.H."
surname="Behringer">
<organization>Cisco Systems</organization>
<address>
<email>mbehring@cisco.com</email>
</address>
</author>
<author fullname="Brian Carpenter" initials="B. E." surname="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>
<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, No.156 Beiqing Road</street>
<city>Hai-Dian District, Beijing, 100095</city>
<country>P.R. China</country>
</postal>
<email>jiangsheng@huawei.com</email>
</address>
</author>
<date day="" month="April" year="2014" />
<area></area>
<workgroup>Internet Research Task Force</workgroup>
<abstract>
<t>This document summarises a problem statement for an IP-based
autonomic network that is mainly based on distributed network devices.
The document reviews the history and current status of autonomic aspects
of IP networks. It then reviews the current network management style,
which is still heavily depending on human administrators. Finally the
document describes the general gaps between the ideal autonomic network
concept and the current network abilities.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The general goals and relevant definitions for autonomic networking
are discussed in <xref target="I-D.irtf-nmrg-autonomic-network-definitions"></xref>. In
summary, the fundamental goal of an autonomic network is
self-management, including self-configuration, self-optimization,
self-healing and self-protection. Whereas interior gateway routing protocols
such as OSPF and IS-IS largely
exhibit these properties, most other aspects of networking require
top-down configuration often involving human administrators and a
considerable degree of centralisation. In essence Autonomous Networking is
putting all network configuration onto the same footing as routing,
limiting manual or database-driven configuration to an essential
minimum. It should be noted that this is highly unlikely to eliminate
the need for human administrators, because many of their essential tasks
will remain. The idea is to eliminate tedious and error-prone tasks, for
example manual calculations, cross-checking between two different
configuration files, or tedious data entry. Higher level operational
tasks, and trouble-shooting, will remain to be done in any case.</t>
<t>Note in draft: This is a preliminary version. It certainly lacks
information about current status, and it lacks many external references.
Especially the final section (<xref target="Gaps"/>) is very preliminary.
Comments and suggestions are very welcome.</t>
</section>
<!-- intro -->
<section anchor="terms" title="Terminology">
<t>The terminology defined in <xref
target="I-D.irtf-nmrg-autonomic-network-definitions"></xref> is used in
this document. Additional terms include:</t>
<t><list style="symbols">
<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. </t>
</list></t>
</section>
<!-- terms -->
<section anchor="Status"
title="Current Status of Autonomic Aspects of IP Networks">
<t>This section discusses the history and current status of autonomy in
various aspects of network configuration, in order to establish a
baseline for the gap analysis. In one particular area, routing protocols,
autonomic information exchange and decision is a well established
mechanism. The question is how to extend autonomy to cover all kinds of
network management objectives.</t>
<section title="IP Address Management and DNS">
<t>Originally there was no alternative to completely manual and static
management of IP addresses. Once a site had received an IPv4 address
assignment (usually a Class C /24 or Class B /16, and rarely a Class A
/8) it was a matter of paper-and-pencil design of the subnet plan (if
relevant) and the addressing plan itself. Subnet prefixes were
manually configured into routers, and /32 addresses were assigned
administratively to individual host computers, and configured manually
by system administrators. Records were typically kept in a plain text
file or a simple spreadsheet.</t>
<t>Clearly this method was clumsy and error-prone as soon as a site
had more than a few tens of hosts, but it had to be used until DHCP
<xref target="RFC2131"></xref> became a viable solution during the
second half of the 1990s. DHCP made it possible to avoid manual
configuration of individual hosts (except, in many deployments, for a
small number of servers configured with static addresses).</t>
<t>In terms of management, it is difficult to separate IP address
management from DNS management. At roughly the same time as DHCP came
into widespread use, it became very laborious to manually maintain DNS
source files in step with IP address assignments. Because of reverse
DNS lookup, it also became necessary to synthesise DNS names even for
hosts that only played the role of clients. Therefore, it became
necessary to synchronise DHCP server tables with forward and reverse
DNS. For this reason, Internet Protocol address management
tools emerged. These are, however, a centralised and far from
autonomic type of solution.</t>
<!-- <t>IPv6 has complicated the situation. Using DHCPv6 <xref
target="RFC3315"></xref>, the situation is similar to IPv4. However,
IPv6 also allows stateless address auto-configuration, which is
largely autonomic, as long as the local router is correctly configured
to provide Router Advertisements. There is significant disagreement in
the community which of these methods is better, and there are
coexistence issues.</t> -->
<t>A related issue is prefix delegation, especially in IPv6 when more
than one prefix may be delegated to the same physical subnet. DHCPv6 Prefix Delegation
<xref target="RFC3633"/> is a useful solution, but how this topic
is to be handled in home networks is still an open question. Still further
away is automated assignment and delegation of IPv4 subnet prefixes.
</t>
<t>Another complication is the possibility of Dynamic DNS Update <xref
target="RFC2136"></xref>. With appropriate security, this is an
autonomic approach, where no human intervention is required to create
the DNS records for a host. Also, there are coexistence issues with
a traditional DNS setup.</t>
</section>
<section title="Routing">
<t>Since a very early stage, it has been a goal that Internet routing
should be self-healing when there is a failure of some kind in the
routing system (i.e. a link or a router goes wrong). Also, the problem
of finding optimal routes through a network was identified many years
ago as a problem in mathematical graph theory, for which well known
algorithms were discovered (the Dijkstra and Bellman-Ford algorithms).
Thus routing protocols became largely autonomic in the 1980s, as soon
as the network was big enough for manual configuration of routing
tables to become difficult.</t>
<t>IGP routers do need some initial configuration data to start up the
autonomic routing protocol. Also, BGP-4
routers need static configuration of routing policy data. So far, this
policy configuration has not been made autonomic at all.</t>
</section>
<section title="Configuration of Default Router">
<t>Originally this was a manual operation. Since the deployment of
DHCP, this has been automatic as far as most IPv4 end systems are
concerned, but the DHCP server must be appropriately configured. In
simple environments such as a home network, the DHCP server resides in
the same box as the default router, so this configuration is also
automatic. In more complex environments, where an independent DHCP
server or a local DHCP relay is used, configuration is more complex
and not automatic.</t>
<t>In IPv6 networks, the default router is provided by Router
Advertisement messages <xref target="RFC4861"></xref> from the router
itself, and all IPv6 hosts make use of it. The router may also provide
more complex Route Information Options. The process is automatic as
far as all IPv6 end systems are concerned, and DHCPv6 is not involved.
Howwever there are still open issues when more than one prefix is in
use on a subnet and more than one first-hop router may be available as
a result.</t>
</section>
<section title="Hostname Lookup">
<t>Originally host names were looked up in a static table, often
referred to as /etc/hosts from its traditional file path in Unix
systems. When the DNS was deployed during the 1980s, all hosts needed
DNS resolver code, and needed to be configured with the IP addresses
(not the names) of suitable DNS servers. Like the default router,
these were originally manually configured. Today, they are provided
automatically via DHCP or DHCPv6 <xref target="RFC3315"/>. For IPv6 end systems, there is also
a way for them to be provided automatically via a Router Advertisement
option. However, the DHCP or DHCPv6 server, or the IPv6 router, need
to be configured with the appropriate DNS server addresses.</t>
</section>
<section title="User Authentication and Accounting">
<t>Originally, user authentication and accounting are mainly based on
the physical connectivities. Network operators charged based on the
set up of dedicated physical links with users. Autonomic user
authentication are introduced by Point-to-Point Protocol <xref
target="RFC1661"></xref>, <xref target="RFC1994"></xref> and RADIUS
protocol <xref target="RFC2865"></xref>, <xref
target="RFC2866"></xref> in early 1990s. As long as a user complete
online authentication through RADIUS protocol, the accounting for that
user starts on AAA server autonomically. This mechanism enables
charging business model based on the usage of users, either traffic
based or time based. However, the management for user authentication
information remains manual by network administrators.</t>
</section>
<section title="Security">
<t>Security has many aspects that need configuration and are therefore
candidates to become autonomic. On the other hand, it is essential
that a network's central policy should be applied strictly for all
security configuration. As a result security has largely been based on
centrally imposed configurations.</t>
<t>Many aspects of security depend on policy, for example firewall policies.
Policies are by definition human made and will therefore also persist in
an autonomic environment. However, policies are becoming more high-level,
abstracting for example addressing, and focusing on the user or application.
The methods to manage, distribute and apply policy, and to monitor compliance
and violations could be autonomic. </t>
<t>Today, many security mechanisms show some autonomic properties. For example
user authentication via 802.1x allows automatic mapping of users after authentication
into logical contexts (typically VLANs). While today configuration is still very important,
the overall mechanism displays signs of self-adaption to changing situations. </t>
<t>BGP Flowspec <xref target="RFC5575"/> allows a partially autonomic threat defense mechanism, where threats
are identified, the flow information is automatically distributed, and counter-actions
can be applied. Today typically a human operator is still in the loop to check correctness, but
over time such mechanisms can become more autonomic. </t>
<t>Negotiation capabilities, present in many security protocols, also display simple
autonomic behaviours. In this
case a security policy about algorithm strength can be configured into
servers but will propagate automatically to clients. A proposal has
been made recently for automatic bootstrapping of trust in a network
<xref target="I-D.behringer-default-secure"/>. Solutions for opportunistic encryption
have been defined <xref target="RFC4322"></xref>,
<xref target="I-D.farrelll-mpls-opportunistic-encrypt"></xref>, but these do
not adhere to a central policy.</t>
</section>
<section title="Miscellaneous">
<t>There are innumerable other properties of network devices and end
systems that today need to be configured either manually or using a
management protocol such as SNMP <xref target="RFC1157"></xref> or
NETCONF <xref target="RFC6241"></xref>. In a truly autonomic network,
all of these would need to either have satisfactory default values or
be configured automatically. Some examples are parameters for tunnels
of various kinds, flows (in an SDN context), quality of service,
service function chaining, energy management, system identification,
NTP configuration etc. Even one undefined parameter would be
sufficient to prevent fully autonomic operation.</t>
</section>
</section>
<!-- history -->
<!--
<section anchor="summary" title="Summary of Autonomic Status and Trends">
<t>The most advanced area is of course routing protocols, where we
observe that a minimal amount of information must be pre-configured
(neighbour routers, prefixes supported, and BGP-4 policies) and the rest
is calculated dynamically as a result of peer-to-peer communication with
other routers. In all other areas, there has been a slow progress over
many years from fully manual configuration towards top-down
configuration from central administrators or network management systems
driven by databases. There are only a few instances, such as negotiation
of cryptographic algorithms, where automation is not in the top-down
style that relies ultimately on humans - either to correctly create and
maintain configuration files, or to correctly use a network management
system to do this work. At the moment the trend seems to be towards more
widespread deployment of tools to help centralised configuration, such
as IPAM tools, rather than to move away from this towards a more
distributed and autonomic approach.</t>
</section> -->
<!-- summary-->
<section anchor="HumanDependencies"
title="Current Non-Autonomic Behaviors">
<t>In the current networks, many operations are still heavily depending on
human intelligence and decision, or on centralised top-down network management
systems. These operations are the targets of Autonomic
Network technologies. The ultimate goal of Autonomic Network is to
replace tedious human operations by autonomic functions, so that the networks
can independently run without having to ask human support for routine details, while it
remains possible to restore human intervention when unavoidable. Of course, there would
still be the absolute minimum of human input required, particularly
during the network establishment stage, and during difficult trouble-shooting.</t>
<t>This section analyzes the existing human and central dependencies in the current
networks.</t>
<section title="Network Establishment">
<t>Network establishment requires network operators to analyze the
requirements of the new network, design a network archetecture and
topology, decide device locations and capacities, set up hardware,
design network services, choose and enable required protocols,
configure each device and each protocol, set up
user authentication and accounting policies and databases, design and
deploy security mechanisms, etc.</t>
<t>Overall, these jobs are quite complex work that cannot become
fully autonomic in the forseeable future. However, part of these jobs
may be able to become autonomic, such as device and protocol
configurations and database population. The initial network management policies/behaviors may
also be transplanted from other networks and automatically localized.</t>
</section>
<section title="Network Maintenance & Management">
<t>The network maintenance and management are very different for ISP
networks and enterprise networks. ISP networks have to change much
more frequently than enterprise networks, given the fact that ISP
networks have to serve a large number of customers who have very
diversified requirements. The current rigid model is that network
administrators design a limited number of services for customers to
order. New requirements of network services may not be able to be met quickly by
human management. Given a real-time request, the response must be autonomic,
in order to be flexible and quickly deployed. However, behind the
interface, describing abstracted network information and user
authorization management may have to depend on human intelligence from
network administrators in the forseeable future. User identification
integration/consolidation among networks or network services are
another challenge for autonomic network access. Currently, the end
users have to manually manage their user accounts and authentication
information when they switch among networks or network services.</t>
<t>Classical network maintenance and management mainly manages the
configuration of network devices. Tools have developed to enable
remote management and make the management easier. However, the
decision of each configuration depends either on human
intelligence or rigid templates. This is the source of most network
configuration errors. It is also the barrier to increase the utility
of network resources because the human management cannot respond
quickly enough to network events, such as traffic bursts, etc. For
example, currently, a light load is normally assumed in network design
because there is no mechanism to properly handle a sudden traffic flood. It is
actually normal to avoid network crashes caused by traffic overload by wasting
a huge amount of resources. </t>
<t>Autonomic decision processes of configuration would enable dynamic
management of network resources (by managing resource relevant
configuration). Self-adapting network configuration would
adjust the network into the best possible situation, which also
prevents configuration errors from having lasting impact.</t>
</section>
<section title="Troubleshooting and Recovery">
<t>Current networks suffer difficulties in locating the cause of
network failures. Although network devices may issue many warnings
while running, most of them are not sufficiently precise to be identified as
errors. Some of them are early warnings that would not develop into
real errors. Others are in effect random noise. During a major failure,
many different devices will issue multiple warnings within a short time,
causing overload for the NMS and the operators. However, for many scenarios, human
experience is still vital to identify real issues and locate them. This situation
may be improved by automatically associating warnings from multiple network
devices together. Also, introducing automated learning techniques (comparing
current warnings with historical relationships between warnings and actual faults)
could increase the possibility and success rate of autonomic network diagnoses and
troubleshooting.</t>
<t>Depending on the network errors, some of them may always require human
interventions, particularly for hardware failures. However, autonomic network
management behavior may help to reduce the impact of errors, for example by
switching traffic flows around. Today this is usually manual (except for
classical routing updates). Fixing software
failures and configuration errors currently depends on humans, and may even
involve rolling back software versions and rebooting hardware.
Such problems could be autonomically corrected if there were
diagnostics and recovery functions defined in advance for them. This would fulfill the
concept of self-healing.</t>
<t>Another possible autonomic function is predicting device failures or overloads
before they occur. A device could predict its own failure and warn its neighbors;
or a device could predict its neighbor's failure. In either case, an autonomic network
could respond as if the failure had already occurred by routing round the problem
and reporting the failure, with no disturbance to users. The criteria for predicting
failure could be temperature, battery status, bit error rates, etc. The criteria for
predicting overload could be increasing load factor, latency, jitter, congestion loss, etc. </t>
</section>
</section>
<section anchor="Gaps" title="Approach toward Autonomy">
<t>The task of autonomic networking is to build up individual autonomic decision
processes that could properly combine to respond to every type of network event.
This section (when complete) will outline what needs to be developed. </t>
<section title="More Coordination among Devices or Network Partitions">
<t>Events in networks are normally not independent. They are
associated with each other. But most of current response functions are
based on independent processes. The network events that may naturally
happen distributed should be associated in the autonomic
processes.</t>
<t>In order to make right or good decisions autonomically, the network
devices need to know more information than just reachability (routing)
information from the relevant or neighbor devices. There are
dependencies between such information and configurations. Currently,
most of these configurations currently require manual coordination by
network administrators.</t>
<t>There are therefore increased requirements for horizontal
information exchanging in the networks. Particularly, negotiation
among network devices are needed for autonomic decision. <xref
target="I-D.jiang-config-negotiation-ps"></xref> analyzes such
requirements. Although there are many existing protocols with
negotiation ability, each of them are only serve a specifc and narrow
purpose. <xref target="I-D.jiang-config-negotiation-protocol"></xref>
is one of the attempts to create a generic negotiation platform, which
would support different negotiation objectives.</t>
</section>
<section title="Forecasting and Dry Runs">
<t>In a conventional network, there is no mechanism for trying
something out. That means that configuration changes have to
be designed in the abstract and their probable effects have to
be estimated theoretically. The only alternative to this would be
to test them on a complete and realistic network simulator, which
is unlikely to be possible for a network of any size. In any case,
there is a risk that applying the changes to the running network
will cause a failure of some kind. An autonomic
network could fill this gap by supporting a "dry run" mode in which
a configuration change could be tested out in the control plane
without actually affecting the data plane. If the results are
satisfactory, the change could be made live; if there is a problem,
the change could be rolled back with no effect on users. </t>
</section>
<section title="Benefit from Knowledge">
<t>The more knowledge we have, the more intelligent we are. It is the
same for networks and network management. It is when one component in
the network lacks knowledge that affects what it should do, and another
component has that knowledge, that we usually rely on a human operator
or a centralised management tool to convey the knowledge. </t>
<!-- The deep reason why human
decision have to be needed relies on either lacking of information or
experience. Note from Sheng: this statement is useful, I think. But it
seems not fit the context here. I also cannot find a better place for
it. -->
<t>Up to now, most available network knowledge is only the current network
status, either inside a device or relevant data from other devices. </t>
<t>However, historic knowledge is very helpful to make correct
decisions, in particular to reducing network oscillation or to
manage network resources over time. Transplantable knowledge from other
networks can be helpful to initially set up a new network or new
network devices. Knowledge of relationship between network events and
network configuration may help network to decide the best parameters
according to real performance feedback. </t>
</section>
</section>
<!-- gaps -->
<section anchor="security" title="Security Considerations">
<t>This document is focussed on what is missing to allow autonomic
network configuration, including of course security settings. Therefore,
it does not itself create any new security issues. It is worth
underlining that autonomic technology must be designed with strong
security properties from the start, since a network with vulnerable
autonomic functions would be at great risk.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>The authors would like to acknowledge the valuable comments made by
participants in the IRTF Network Management Research Group and others.</t>
<t>This document was produced using the xml2rfc tool <xref
target="RFC2629"></xref>.</t>
</section>
<section anchor ="changes" title="Change log [RFC Editor: Please remove]">
<t>draft-irtf-nmrg-an-gap-analysis-00: RG comments added, 2014-04-02.</t>
<t>draft-jiang-nmrg-an-gap-analysis-00: original version, 2014-02-14.</t>
</section> <!-- changes -->
</middle>
<back>
<references title="Informative References">
<?rfc include='reference.RFC.2629'?>
<?rfc include='reference.RFC.1157'?>
<?rfc include='reference.RFC.1661'?>
<?rfc include='reference.RFC.1994'?>
<?rfc include='reference.RFC.2131'?>
<?rfc include='reference.RFC.2136'?>
<?rfc include='reference.RFC.2865'?>
<?rfc include='reference.RFC.2866'?>
<?rfc include='reference.RFC.3315'?>
<?rfc include='reference.RFC.3633'?>
<?rfc include='reference.RFC.4322'?>
<?rfc include='reference.RFC.4861'?>
<?rfc include='reference.RFC.5575'?>
<?rfc include='reference.RFC.6241'?>
<?rfc include="reference.I-D.jiang-config-negotiation-ps"?>
<?rfc include="reference.I-D.jiang-config-negotiation-protocol"?>
<?rfc include="reference.I-D.irtf-nmrg-autonomic-network-definitions.xml"?>
<?rfc include="reference.I-D.behringer-default-secure.xml"?>
<?rfc include="reference.I-D.farrelll-mpls-opportunistic-encrypt.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 05:46:16 |