One document matched: draft-jiang-config-negotiation-ps-03.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-jiang-config-negotiation-ps-03"
ipr="trust200902">
<front>
<title abbrev="Config Negotiation PS">Network Configuration Negotiation
Problem Statement and Requirements</title>
<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>
<author fullname="Yuanbin Yin" initials="Y." surname="Yin">
<organization>Huawei Technologies Co., Ltd</organization>
<address>
<postal>
<street>Q15, Huawei Campus, No.156 Beiqing Road</street>
<city>Hai-Dian District, Beijing, 100095</city>
<country>P.R. China</country>
</postal>
<email>yinyuanbin@huawei.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>
<date month="May" year="2014" />
<area>Internet Area</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>Configuration Negotiation</keyword>
<keyword>Autonomic Networking</keyword>
<abstract>
<t>This document describes a problem statement and general requirements
for distributed autonomic 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
negotiation behavior model. The document also reviews whether existing
management and configuration protocols may be suitable for autonomic
networks.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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. <xref
target="I-D.boucadair-network-automation-requirements"></xref> 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 by requiring a
configuration negotiation protocol rather than only unidirectional provisioning.</t>
<t>Autonomic operation means network devices could decide configurations
by themselves. More background on autonomic networking is given in
<xref target="I-D.irtf-nmrg-autonomic-network-definitions"/> and
<xref target="I-D.irtf-nmrg-an-gap-analysis"/>.
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, distributed autonomic
configuration is a well established mechanism. The question is how to
extend autonomy to cover all kinds of configuration, not just routing
tables.</t>
<t>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 currently require
centralised manual coordination. The basic model for this document is that
in an autonomic network, devices will need to negotiate directly with one
another to provide this coordination. </t>
<t>Today, there is no generic negotiation protocol that can be used to
control decision processes 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 and a central database.
An autonomic system needs to be less hierarchical and with less dependence
on an operator. This requires network elements to negotiate directly
with each other, with an absolute minimum or zero configuration data at
the installation stage.</t>
<t>This document analyzes the requirements for a generic negotiation
protocol in view of various application use cases, then gives considerations for
detailed technical requirements for designing such a protocol. Some
existing protocols are also reviewed as part of the analysis. A protocol
behavior model, which may be used to define such a negotiation protocol,
is also described.</t>
<t>Note in draft: the requirements analysis will need to be reviewed and
completed after a number of use cases for autonomic networking have been
documented. </t>
</section>
<section title="Requirements and Application Scenarios for Network Devices Negotiation">
<t>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 utilization rate.</t>
<t>A negotiation model with no human intervention is needed when the
coordination of multiple devices can provide better overall network
performance.</t>
<t>A negotiation model provides a possibility for forecasting. A "dry
run" becomes possible before the concrete configuration takes place.</t>
<t>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).</t>
<t>Negotiation of security mechanisms, for example to determine the
strongest possible protection for a given link, is another example. </t>
<t>When a new user or device comes online, it might be necessary 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.</t>
<t>Status information and traffic metrics need to be shared between
nodes for dynamic adjustment of resources.</t>
<t>Troubleshooting should be as automatic as possible. Although it is
far from trivial, there is a need to detect the "real" breakdown amongst
many alerts, and then take action to reconfigure the relevant devices.
Again, routing protocols have done this for many years, but in an
autonomic network it is not just routing that needs to reconfigure
itself after a failure.</t>
<section title="Negotiation between downstream and upstream network devices">
<t>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.</t>
<t>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 dynamic
management and maintenance, there are many other network events that
downstream network devices may need to report to upstream network
devices and then initiate some configuration change on these upstream
devices. Currently, these kinds of synchronizing operations require
the involvement of human operators.</t>
<t>Similar requirements can also appear between other types of downstream
and upstream network devices.</t>
</section>
<section title="Negotiation between peer network devices">
<t>Within a large network, in many segments, there are network devices
that are in equivalent positions. They have a peer rather
than hierarchical relationship. There may be many horizontal traffic
flows or tunnels between them. In order to make these connections efficient,
their configurations (for example, quality of service parameters) have to
match each other. Any change of a device's configuration may require
synchronizing with its peer network devices.</t>
<t>However, in many cases the peer network devices may not
be able to make the exact changes as requested. Instead, another slightly
different change may be the best choice for optimal
performance. In order to decide on this best choice, multiple rounds of
information exchange between peers may be necessary. This should be done
without requiring the involvement of human operators. To provide this
ability, a mechanism for network devices to be able to negotiate with each
other is needed.</t>
</section>
<section title="Negotiation between networks">
<t>A network may announce some information about its internal capabilities to
connected peer networks, so that the peer networks can react
accordingly. BGP routing information is a simple example.</t>
<t>Beyond reachability, more information may enable better
coordination among networks. Examples include traffic engineering among
multiple connections between two networks, particularly when these
connections are geographically distributed; dynamic capacity adjustment
to match changing traffic from a peer network; dynamic establishment and
adjustment of differentiated service classes to support Service Level
Agreements; and so on.</t>
</section>
<section title="Information and status queries among devices">
<t>In distributed routers, many data such as status indicators or
traffic measurements are dynamically changing.
These may be the triggers for subsequent negotiation. For example,
assume there are two routers A and B sharing traffic load.
Router A may request the traffic situation of router B,
then start negotiation, such as requesting router B to
handle all the traffic so that router A can enter power-saving mode.
Another example is that a device may request its neighbor to send
a forecast or dry-run result based on a given
potential configuration change.
Then, the initiating router can evaluate whether the potential
configuration change would meet its original target.</t>
</section>
<section title="Unavoidable configuration">
<t>Even with autonomic negotiation, some initial configuration data
cannot be avoided in some devices. A design goal is to reduce this to
an absolute minimum. This information may have to be pre-configured
on the device before it has been deployed physically, and
is typically static. A preliminary list of unavoidable
configuration data is:</t>
<t><list style="symbols">
<t>Authentic identity for each device. This may be a public key or
a signed certification. This is necessary to protect the
infrastructure against unauthorized replacement of equipment.</t>
<t>The role and function and capability of the device. The
role and function may depend on the network planning. The capability
is typically decided by the hardware.</t>
<t>On the network edge, the routers may need to be configured with
the identity of each peer provider, and their entitlements to
service.</t>
</list></t>
<t>Ideally, everything else (topology, link capacity, address
prefixes, shared resources, customer authentication and authority,
etc.) will be discovered or negotiated autonomously according to
general policy for various negotiated objective.</t>
</section>
</section>
<section title="Existing protocols">
<t>Routing protocols are mainly one-way information announcements. The
receiver makes independent decisions based on the received information
and there is no direct feedback information to the announcing peer. This
remains true even though the protocol is used
in both directions between peer routers; there is no negotiation, and
each peer runs its route calculations independently. </t>
<t>Simple Network Management Protocol (SNMP) <xref target="RFC3416"/>
uses a command/response model not well suited for peer negotiation.
Network Configuration Protocol (NETCONF) <xref target="RFC6241"/>
uses an RPC model that does allow positive or negative
responses from the target system, but this is still not adequate
for negotiation. </t>
<t>There are various existing protocols that have elementary negotiation
abilities, such as
Dynamic Host Configure Protocol for IPv6 (DHCPv6) <xref target="RFC3315"></xref>,
Neighbor Discovery (ND) <xref target="RFC4861"></xref>,
Port Control Protocol (PCP) <xref target="RFC6887"></xref>,
Remote Authentication Dial In User Service (RADIUS) <xref target="RFC2865"/>,
Diameter <xref target="RFC6733"/>, etc.
Most of them are configuration or management protocols. However, they
either provide only a simple request/response model in a master/slave context
or very limited negotiation abilities.</t>
<t>There are also signalling protocols with an element of negotiation.
For example Resource ReSerVation Protocol (RSVP) <xref target="RFC2205"/>
was designed for negotiating quality of service parameters along the path
of a unicast or multicast flow. RSVP is a very specialised
protocol aimed at end-to-end flows. However, it has some flexibility,
having been extended for MPLS label distribution <xref target="RFC3209"/>.
A more generic design is
General Internet Signalling Transport (GIST) <xref target="RFC5971"/>,
but it is complex, tries to solve many problems, and is also aimed
at per-flow signalling across many hops rather than at device-to-device
signalling. However, we cannot yet exclude extended RSVP or GIST as a negotiation
protocol. </t>
<t>It is worth noting that some of the above protocols have
either an explicit information model describing their messages,
or at least a flexible and extensible message format. A negotiation
protocol will require such capabilities. One design consideration
is whether to adopt an existing information model or to design
a new one. Another consideration is whether to be able to carry
some or all of the message formats used by the above protocols. </t>
<t>We now consider two protocols that are works in progress at the
time of this writing. Firstly, RESTCONF <xref target="I-D.ietf-netconf-restconf"/>
is a protocol intended to convey NETCONF information expressed in the YANG language
via HTTP, including the ability to transit HTML intermediaries. While this is
a powerful approach in the context of centralised configuration of a complex
network, it is not well adapted to efficient interactive negotiation between
peer devices, especially simple ones that are unlikely to include YANG processing
already. </t>
<t>Secondly, we consider HomeNet Control Protocol (HNCP)
<xref target="I-D.ietf-homenet-hncp"/>. This is defined as "a
minimalist state synchronization protocol for Homenet routers."
Specific features are:
<list style="symbols">
<t>Every participating node has a unique node identifier.</t>
<t>"HNCP is designed to operate between directly connected neighbors on a
shared link using link-local IPv6 addresses."</t>
<t>Currency of state is maintained by spontaneous link-local multicast messages.</t>
<t>HNCP discovers and tracks link-local neighbours.</t>
<t>HNCP messages are encoded as a sequence of TLV objects, sent over UDP.</t>
<t>Authentication depends on a signature TLV (assuming public keys are associated with node identifiers). </t>
<t>The functionality covered initially includes: site border discovery,
prefix assignment, DNS namespace discovery, and routing protocol selection.</t>
</list>
Clearly HNCP does not completely meet the needs of a general negotiation protocol,
especially due to its limitation to link-local messages and its strict dependency on
IPv6, but at the minimum it is a very interesting test case for this style of
interaction between devices without needing a central authority. </t>
</section>
<section title="A Behavior Model of a Generic Negotiation Protocol">
<t>This section describes a behavior model and some considerations for
designing a generic negotiation protocol, which would act as a platform
for different negotiation objectives.</t>
<t><list style="symbols">
<t>A generic platform<vspace blankLines="1" />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
counterparts. The negotiation contents will vary according to
the various negotiation objectives and the different pairs of
negotiating counterparts.<vspace blankLines="1"/></t>
<t>Security infrastructure and trust relationship<vspace
blankLines="1" />Because this negotiation protocol may directly
cause changes to device configurations and bring significant
impacts to a running network, this protocol must be based on a
restrictive security infrastructure. It should be carefully managed
and monitored so that every device in this negotiation system behaves
well and remains well protected.<vspace blankLines="1" />On
the other hand, a limited negotiation model might be deployed based on a
limited trust relationship. For example, between two administrative
domains, devices might also exchange limited information and negotiate some
particular configurations based on a limited conventional or contractual trust
relationship.<vspace blankLines="1"/></t>
<t>A uniform pattern for negotiation contents<vspace
blankLines="1" />The negotiation contents should be defined
according to a uniform pattern. They could be carried either in TLV
(Type, Length and Value) format or in payloads described by a
flexible language, like XML. A protocol design should choose one of
these two. The format must be extensible for unknown future
requirements. As noted above, an existing information model and
existing message format(s) should be considered. <vspace blankLines="1"/></t>
<t>A simple initiator/responder model<vspace blankLines="1" />
Multi-party negotiations are too complicated to be modeled and
there may be too many dependencies among the parties to converge
efficiently. A simple initiator/responder model is more feasible and
could actually complete multiple-party negotiations by indirect
steps. Naturally this process must be guaranteed to terminate and
must contain tie-breaking rules.<vspace blankLines="1"/></t>
<t>Organizing of negotiation content<vspace
blankLines="1" />Naturally, the negotiation content should be
organized according to the relevant function or service. The content
from different functions or services should be kept independent from each
other. They should not be combined into a single option or single
session because these contents may be negotiated with different
counterparts or may be different in response time.<vspace blankLines="1"/></t>
<t>Topology neighbor device discovery<vspace blankLines="1" />Every
network device that supports the negotiation protocol is a responder
and always listens to a well-known (UDP?) port. A well-known link-local
multicast address should be defined for discovery purposes. Upon
receiving a discovery or request message, the recipient device
should return a message in which it either indicates itself as a
proper negotiation counterpart or diverts the initiator towards
another more suitable device.<vspace blankLines="1"/></t>
<t>Self aware network device<vspace blankLines="1" />Every
network device should be pre-configured with its role and functions and be
aware of its own capabilities. The roles may be only distinguished
because of network behaviors, which may include forwarding
behaviors, aggregation properties, topology location, bandwidth,
tunnel or translation properties, etc. The role and functions may depend
on the network planning. The capability is typically decided by the
hardware or firmware. These parameters are the foundation of the negotiation behavior of a
specific device.<vspace blankLines="1"/></t>
<t>Requests and responses in negotiation procedures<vspace
blankLines="1" />The initiator should be able to negotiate with its
relevant negotiation counterpart devices, which may be different
according to the negotiation objective. It may request relevant
information from the negotiation counterpart so that it can decide
its local configuration to give the most coordinated performance. It
may request the negotiation counterpart to make a matching
configuration in order to set up a successful communication with it.
It may request certain simulation or forecast results by sending some
dry run conditions. <vspace blankLines="1" />Beyond the traditional
yes/no answer, the responder should be able to reply with a suggested
alternative if its answer is 'no'. This would start
a bi-directional negotiation ending in a compromise between the
two devices.<vspace blankLines="1"/></t>
<t>Convergence of negotiation procedures<vspace blankLines="1" />The
negotiation procedure should move towards convergent results. It
means that when a responder makes a suggestion of a changed
condition in a negative reply, it should be as close as possible to
the original request or previous suggestion. The suggested value of
the third or later negotiation steps should be chosen between the
suggested values from the last two negotiation steps. In any case
there must be a mechanism to guarantee rapid convergence in a small
number of steps.<vspace blankLines="1"/></t>
<t>Dependencies of negotiation<vspace blankLines="1" />In order to
decide a configuration on a device, the device may need information
from neighbors. This can be reached through the above
negotiation procedure. However, a given item in a neighbor
may depend on other information from its own neighbors, which may
need another negotiation procedure to obtain or decide. Therefore,
there are dependencies among negotiation procedures. There need to
be clear boundaries and convergence mechanisms for these negotiation
dependencies. Also some mechanisms are needed to avoid loop dependencies.<vspace blankLines="1"/></t>
<t>End of negotiation<vspace blankLines="1" />A single negotiation
procedure also needs ending conditions if it does not converge. A
limited number of rounds, for example three, should be set on the devices.
It may be an implementation choice or a pre-configurable parameter. However,
the protocol design needs to clearly specify this, so that the
negotiation can be terminated properly. In some cases, a timeout
might be needed to end a negotiation. <vspace blankLines="1"/></t>
<t>Failed negotiation<vspace blankLines="1" />There must be a
well-defined procedure for concluding that a negotiation cannot
succeed, and if so deciding what happens next (deadlock resolution,
tie-breaking, or revert to best-effort service).<vspace blankLines="1"/></t>
<t>Policy constraints<vspace blankLines="1" />There must be
provision for general policy rules to be applied by all devices in
the network (e.g., security rules, prefix length, resource sharing
rules). However, policy distribution might not use the negotiation
protocol itself.<vspace blankLines="1"/></t>
<t>Management monitoring, alerts and intervention<vspace
blankLines="1" />Devices should be able to report to a monitoring
system. Some events must be able to generate operator alerts and
some provision for emergency intervention must be possible (e.g. to
freeze negotiation in a mis-behaving device). These features may not
use the negotiation protocol itself.</t>
</list></t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not include a detailed threat analysis for
autonomic 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 form of
strong authentication and, if possible, built-in protection against
denial of service attacks.</t>
<t>Separation of network devices and user devices may become very
helpful in this kind of scenario.</t>
<t>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.</t>
<t>As noted earlier, a cryptographically authenticated identity for each
device is needed in an autonomic network. It is not safe to assume that
a large network is physically secured against interference or that all
personnel are trustworthy. Each autonomic device should be
capable of proving its identity and authenticating its messages. One
approach would be to use a private/public key pair and sufficiently
strong cryptography. Each device would generate its own private key,
which is never exported from the device. The device identity and
public key would be recorded in a network-wide database. The
alternative of using symmetric keys (shared secrets) is less
attractive, since it creates a risk of key leakage as well as a key
management problem when devices are installed or removed.</t>
<t>Generally speaking, no personal information is expected to be
involved in the negotiation protocol, so there should be no direct
impact on personal privacy. Nevertheless, traffic flow paths, VPNs,
etc. may be negotiated, which could be of interest for traffic
analysis. Also, carriers generally want to conceal details of their
network topology and traffic density from outsiders. Therefore,
since insider attacks cannot be prevented in a large carrier network,
the security mechanism for the negotiation protocol needs to provide
message confidentiality.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This draft does not request any IANA action.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors want to thank Zhenbin Li, Bing Liu for valuable
comments.</t>
<t>This document was produced using the xml2rfc tool <xref
target="RFC2629"></xref>.</t>
</section>
<section title="Change Log [RFC Editor please remove]">
<t>draft-jiang-negotiation-config-ps-03, text improvements, added
RESTCONF and HNCP to existing protocols, 2014-05-19.</t>
<t>draft-jiang-negotiation-config-ps-02, text improvements, added extra
existing protocols, 2014-01-19.</t>
<t>draft-jiang-negotiation-config-ps-01, add more requirements, and add
more considerations for behavior model, 2013-10-11.</t>
<t>draft-jiang-negotiation-config-ps-00, original version,
2013-06-29.</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include='reference.RFC.2205'?>
<?rfc include='reference.RFC.3209'?>
<?rfc include='reference.RFC.5971'?>
<?rfc include='reference.RFC.3416'?>
<?rfc include='reference.RFC.6241'?>
<?rfc include='reference.RFC.2865'?>
<?rfc include='reference.RFC.6733'?>
<?rfc include='reference.RFC.2629'?>
<?rfc include='reference.RFC.3315'?>
<?rfc include='reference.RFC.4861'?>
<?rfc include='reference.RFC.6887'?>
<?rfc include='reference.I-D.boucadair-network-automation-requirements'?>
<?rfc include='reference.I-D.ietf-homenet-hncp'?>
<?rfc include='reference.I-D.ietf-netconf-restconf'?>
<?rfc include='reference.I-D.irtf-nmrg-autonomic-network-definitions'?>
<?rfc include='reference.I-D.irtf-nmrg-an-gap-analysis'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 21:56:16 |