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]