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

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

   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
   ( 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


   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

   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,

   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

   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

    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

    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

             Mohamed Boucadair, and Christian Jacquenet, "Requirements
             for Automated (Configuration) Management", working in

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

   Yuanbin Yin
   Huawei Technologies Co., Ltd
   Huawei Q15 Building, No.156 Beiqing Rd.,
   Hai-Dian District  100095

   Brian Carpenter
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland, 1142
   New Zealand

Jiang, et al.         Expires December 31, 2013              [Page 10]