Skip to main content

Network Configuration Negotiation Problem Statement and Requirements
draft-jiang-config-negotiation-ps-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Sheng Jiang , Yuanbin Yin
Last updated 2013-06-29
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-jiang-config-negotiation-ps-00
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]