Network Working Group S. Jiang
Internet Draft Y. Yin
Intended status: Informational Huawei Technologies Co., Ltd
Expires: December 31, 2013 Brian Carpenter
Univ. of Auckland
June 29, 2013
Network Configuration Negotiation
Problem Statement and Requirements
draft-jiang-config-negotiation-ps-00.txt
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 31, 2013.
Copyright Notice
Copyright (c) 2013 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. 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.
Jiang, et al. Expires December 31, 2013 [Page 1]
Internet-Draft draft-jiang-config-negotiation-ps-00 June 2013
Abstract
This document describes a problem statement and general requirements
for distributed autonomous configuration of multiple aspects of
networks, in particular carrier networks. The basic model is that
network elements need to negotiate configuration settings with each
other to meet overall goals. The document describes a generic
discovery and negotiation behavior model. The document also reviews
whether existing management and configuration protocols may be
suitable for autonomic networks.
Table of Contents
1. Introduction ................................................. 3
2. Requirements and Application Scenarios for Network Devices
Negotiation ..................................................... 4
2.1. Negotiation between downstream and upstream network devices5
2.2. Negotiation between peer network devices ................ 5
2.3. Negotiation between networks ............................ 6
3. Existing protocols ........................................... 6
4. A Generic Behavior Model of a Negotiation Protocol ........... 6
5. Security Considerations ...................................... 8
6. IANA Considerations .......................................... 9
7. Acknowledgements ............................................. 9
8. Change Log [RFC Editor please remove] ........................ 9
9. References ................................................... 9
9.1. Informative References .................................. 9
Author's Addresses ............................................. 10
Jiang, et al. Expires December 31, 2013 [Page 2]
Internet-Draft draft-jiang-config-negotiation-ps-00 June 2013
1. Introduction
The success of IP and the Internet has made the network model very
complicated, and networks have become larger and larger. The network
of a large ISP typically contains more than a hundred thousand
network devices which play many roles. The initial setup
configuration, dynamic management and maintenance, troubleshooting
and recovery of these devices have become a huge outlay for network
operators. Particularly, these devices are managed by many different
staff requiring very detailed training and skills. The coordination
of these staff is also difficult and often inefficient. There are
therefore increased requirements for autonomy in the networks.
[I-D.boucadair-network-automation-requirements] is one of the
attempts to describe such requirements. It listed a "requirement for
a protocol to convey configuration information towards the managed
entities". However, this document is going further to require a
configuration negotiation protocol rather than only provision.
Autonomic operation means network devices could decide configurations
by themselves. There are already many existing internal
implementations or algorithms for a network device to decide or
compute its configuration according to its own status, often referred
to as device intelligence. In one particular area, routing protocols,
autonomous configuration is a well established mechanism. The
question is how to extend autonomy to cover all kinds of
configuration, not just routing tables.
However, in order to make right or good decisions, the network
devices need to know more information than just routes from the
relevant or neighbor devices. There are dependencies between such
information and configurations. Currently, most of these
configurations require manual coordination/operation.
Currently, there is no generic negotiation protocol that can be used
to control decision process among distributed devices or between
networks. Proprietary network management systems are widely used but
tend to be hierarchical systems ultimately relying on a console
operator. An autonomous system needs to be less hierarchical and with
less dependence on an operator. This requires network elements to
negotiate directly with each other.
This document analyzes the requirements for a generic negotiation
protocol and the application scenarios, then gives considerations for
detailed technical requirements for designing such a protocol. Some
existing protocols are also reviewed as part of the analysis. A
Jiang, et al. Expires December 31, 2013 [Page 3]
Internet-Draft draft-jiang-config-negotiation-ps-00 June 2013
protocol behavior model, which may be used to define such a
negotiation protocol, is also described.
2. Requirements and Application Scenarios for Network Devices
Negotiation
Routing protocols are a typical autonomic model based on distributed
devices. But routing is mainly one-way information announcement (in
both directions), rather than bi-directional negotiation. Its only
focus is reachability. The future networks need to be able to manage
many more dimensions of the network, such as power saving, load
balancing, etc. The current routing protocols only show simple link
status, as up or down. More information, such as latency, congestion,
capacity, and particularly available throughput, is very helpful to
get better path selection and utility rate.
A negotiation model is needed when the coordination of multiple
devices can provide better overall network performance.
A negotiation model provides a possibility for forecasting. A "dry
run" becomes possible before the concrete configuration takes place.
Scenarios require negotiation
Another area is tunnel management, with automatic setup, maintenance,
and removal. A related area is ad hoc routes, without encapsulation,
to handle specific traffic flows (which might be regarded as a form
of software defined networking).
When a new user or device comes online, it might be needed to set up
resources on multiple relevant devices, coordinated and matched to
each other so that there is no wasted resource. Security settings
might also be needed to allow for the new user/device.
Status information and traffic metrics need to be shared between
nodes for dynamic adjustment of resources.
Troubleshooting should be as autonomous as possible. Although it is
far from trivial, there is a need to detect the "real" breakdown from
many alerts, and then take action to reconfigure the relevant
devices. Again, routing protocols have done this for many years, but
in an autonomous network it is not just routing that needs to
reconfigure itself.
Jiang, et al. Expires December 31, 2013 [Page 4]
Internet-Draft draft-jiang-config-negotiation-ps-00 June 2013
2.1. Negotiation between downstream and upstream network devices
The typical scenario is that there is a new access gateway, which
could be a wireless base station, WiFi hot spot, Data Center switch,
VPN site switch, enterprise CE, home gateway, etc. When it is plugged
into the network, bi-direction configuration/control is needed. The
upstream network needs to configure the device, its delegated
prefix(es), DNS server, etc. For this direction, DHCP might be
suitable and sufficient. However, there is another direction: the
connection of downstream devices also needs to trigger the upstream
devices, for example the provider edge, to create a corresponding
configuration, by setting up a new tunnel, service, authentication,
etc.
Furthermore, after the communication between gateway and provider has
been established, the devices would like to optimize their
configurations interactively according to dynamic link status or
performance measurements, power consumption, etc. For dynamical
management and maintenance, there are many other network events that
downstream network devices may need to report to upstream network
devices and initiate some configuration change on these upstream
networks. Currently, these kinds of synchronizing operations requires
the involvement of human operators.
The similar requirements can also appear between other downstream and
upstream network devices.
2.2. Negotiation between peer network devices
Within a large network, in many segments, there are network devices
that are in equal position for each other. They have a peer rather
than hierarchical relationship. There are many horizontal traffics or
tunnels between them. In order to make their connection efficient,
their configurations have to match each other. Any change of their
configuration may request synchronizing on their peer network
devices.
However, there are many cases that the peer network devices may not
be able to make homologous changes as required. Instead, another
close but different changes may be the best choice for the best
possible performance. In order to decide this best choice, multiple
rounds of information exchanges between peers may be taken. This
should be done without requiring the involvement of human operators.
To fulfill this ability, a mechanism for network devices to be able
to negotiate each other is needed.
Jiang, et al. Expires December 31, 2013 [Page 5]
Internet-Draft draft-jiang-config-negotiation-ps-00 June 2013
2.3. Negotiation between networks
A network may announce some information of its internal network to
connected peer networks, so that the peer networks can reaction
accordingly. Routing information is a good example.
Beyond the reachability, more information may enable better
coordination among networks. Examples include traffic engineer among
multiple connections between two networks, particularly when these
connections are geographic distributed; dynamic bandwidth adjustment
to match the traffic change from peer network; dynamically establish
and adjust the Service Level Agreements; and etc.
3. Existing protocols
Routing protocols are mainly one-way information announce. The
receiver makes decision independent based on the received information
and there is no much feedback information for the announcing peer.
There are many existing protocols that have some negotiation
abilities, such as Dynamic Host Configure Protocol (DHCP) [RFC3315],
Neighbor Discovery (ND) [RFC4861], Port Control Protocol (PCP)
[RFC6887], etc. Most of them are configuration or management
protocols. However, they are either only simple request/response
model or only be able to negotiate on very limit objects.
4. A Generic Behavior Model of a Negotiation Protocol
This section describes a generic behavior model and some
consideration for designing a negotiation protocol.
o A generic platform
The design of the network device protocol is desired to be a generic
platform, which is independent from the negotiation contents. It
should only take care of the general intercommunication between
negotiation parts. The negotiation contents are various giving the
various negotiation purposes and the different pairs of negotiating
routers.
o Security infrastructure and trust relationship
Because this negotiation protocol may directly cause the change of
device configurations and bring significant impacts to a running
network, this protocol must be based on a restrict security
infrastructure. It should be carefully managed / monitored so that
Jiang, et al. Expires December 31, 2013 [Page 6]
Internet-Draft draft-jiang-config-negotiation-ps-00 June 2013
every device in this negotiation system behaves well while they are
well protected.
On another hand, a limited negotiation model may be deployed based on
a limited trust relationship. For example, between two administration
domains, devices may also exchange information and negotiation some
configurations based on the conventional/contracted trust
relationship.
o The uniformed pattern for negotiation contents
The negotiation contents should be defined according to an uniformed
pattern. They could be carried either in TLV (Type, Length and Value)
format or in payload described by a flexible language, like XML.
o A simple initiator/responser model
While multiple-party negotiations are too complicated to be modeled
and there may be too many dependencies among the parties to be
convergent efficiently. A simple initiator/responser model is more
feasible and could actually complete multiple-party negotiations.
o Discovery and self description
Every network device that supports the negotiation protocol is a
responser and always listens to a well-known UDP port. A well-known
ALL-Responser multicast address should be defined for discover
purpose. Upon receiving a discovery message, the device should
response a message in which it describes itself and its capability.
o Roles of routers
The routers should be abstracted into a number of well-defined roles.
The roles should be only distinguished because of their network
behaviors, which may include forwarding behaviors, aggregation
properties, topology location, bandwidth, tunnel or translation
properties, etc. The number of well-defined roles should be as small
as possible, but be suffient to make the others understand the
capability of a certain router. The roles will be used to describe
the router itself in the above discovery process.
o Requests and responses in negotiation procedures
The initiator, which is a router in IP network, should be able to
negotiate with its relevant neighbor devices, which are routers too.
It may request relevant information from neighbors so that it can
decide its local configuration to give the most coordinated
Jiang, et al. Expires December 31, 2013 [Page 7]
Internet-Draft draft-jiang-config-negotiation-ps-00 June 2013
performance. It may request the neighbor device to make a matching
configuration in order to set up a successful communication with it.
It may request certain simulation/forecast result by sending some dry
run conditions.
Beyond the traditional yes/no answer, the responder should be able to
reply with suggestion of change condition in the negative scenario.
This is going to start a bi-direction negotiation towards reaching a
compromise between the two routers.
o convergence of negotiation procedures
The negotiation procedure should be towards convergence results. It
means when a responder make a suggestion of change condition in a
negative reply, it should be as close as possible to the original
request or previous suggestion. In any case there must be mechanism
to guarantee rapid convergence in a small number of steps.
o Dependencies of negotiation
In order to decide a configuration on a router, the router may need
information from neighbor routers. This can be reached through the
above negotiation procedure. However, a certain information on a
neighbor router may depend on other information from its neighbors,
which may need another negotiation procedure to obtain or decide.
Therefore, there are dependencies among negotiation procedures. There
need to be clear edge/convergence for these negotiation dependencies.
Also some mechanisms are needed to avoid loop dependencies.
o End of negotiation
A single negotiation procedure also need ending conditions, for
example three rounds.
o Failed negotiation
There must be a well-defined procedure for concluding that a
negotiation cannot succeed, and if so deciding what happens next.
5. Security Considerations
This document does not include a detailed threat analysis for
autonomous configuration, but it is obvious that a successful attack
on autonomic nodes would be extremely harmful, as such nodes might
end up with a completely undesirable configuration. A concrete
protocol proposal will therefore require a threat analysis, and some
Jiang, et al. Expires December 31, 2013 [Page 8]
Internet-Draft draft-jiang-config-negotiation-ps-00 June 2013
form of strong authentication and, if possible, built-in protection
against denial of service attacks.
Separation of network devices and user devices may become very
helpful in this kind of scenarios.
Also, security configuration itself should become autonomic whenever
possible. However, in the security area at least, operator override
of autonomic configuration must be possible for emergency use.
6. IANA Considerations
This draft does not request any IANA action.
7. Acknowledgements
The authors want to thank Zhenbin Li, Bing Liu for valuable comments.
8. Change Log [RFC Editor please remove]
draft-jiang-negotiation-config-ps-00, original version, 2013-06-29.
9. References
9.1. Informative References
[RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for
IPv6", RFC 3315, July 2003.
[RFC4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC6887] D. Wing, S. Cheshire, M. Boucadair, R. Penno, and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
2013.
[I-D.boucadair-network-automation-requirements]
Mohamed Boucadair, and Christian Jacquenet, "Requirements
for Automated (Configuration) Management", working in
progress.
Jiang, et al. Expires December 31, 2013 [Page 9]
Internet-Draft draft-jiang-config-negotiation-ps-00 June 2013
Author's Addresses
Sheng Jiang
Huawei Technologies Co., Ltd
Huawei Q14 Building, No.156 Beiqing Rd.,
Hai-Dian District 100095
Email: jiangsheng@huawei.com
Yuanbin Yin
Huawei Technologies Co., Ltd
Huawei Q15 Building, No.156 Beiqing Rd.,
Hai-Dian District 100095
Email: yinyuanbin@huawei.com
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand
Email: brian.e.carpenter@gmail.com
Jiang, et al. Expires December 31, 2013 [Page 10]