NETCONF: Difference between revisions

Content deleted Content added

Inline

Revision as of 22:13, 30 November 2013

The Network Configuration Protocol (NETCONF), is an IETF network management protocol. It was developed in the NETCONF working group and published in December 2006 as RFC 4741 and later revised in June 2011 and published as RFC 6241. The NETCONF protocol specification is an Internet Standards Track document.

NETCONF provides mechanisms to install, manipulate, and delete the configuration of network devices. Its operations are realized on top of a simple Remote Procedure Call (RPC) layer. The NETCONF protocol uses an Extensible Markup Language (XML) based data encoding for the configuration data as well as the protocol messages. The protocol messages are exchanged on top of a secure transport protocol.

The NETCONF protocol can be conceptually partitioned into four layers:

The Content layer consists of configuration data and notification data.
The Operations layer defines a set of base protocol operations to retrieve and edit the configuration data.
The Messages layer provides a mechanism for encoding remote procedure calls (RPCs) and notifications.
The Secure Transport layer provides a secure and reliable transport of messages between a client and a server.

The NETCONF protocol has been implemented in network devices such as routers and switches by some major equipment vendors. One particular strengths of NETCONF is its supports for robust configuration change transactions involving a number of devices.

Operations

Basic operations

The base protocol includes the following protocol operations: <get>, <get-config>, <edit-config>, <copy-config>, <delete-config>, <lock>, <unlock>, <close-session>, <kill-session>.

Capabilities

Basic NETCONF functionality can be extended by the definition of NETCONF capabilities. The set of additional protocol features that an implementation supports is communicated between the server and the client during the capability exchange portion of session setup. Mandatory protocol features are not included in the capability exchange since they are assumed. RFC 4741 defines a number of optional capabilities including :xpath and :validate. Note that RFC 6241 obsoletes RFC 4741.

A capability to support subscribing and receiving asynchronous event notifications is published in RFC 5277. This document defines the <create-subscription> operation, which enables creating real-time and replay subscriptions. Notifications are then sent asynchronously using the <notification> construct. It also defines the :interleave capability, which when supported with the basic :notification capability facilitates the processing of other NETCONF operations while the subscription is active.

A capability to support partial locking of the running configuration is defined in RFC 5717. This allows multiple sessions to edit non-overlapping sub-trees within the running configuration. Without this capability, the only lock available is for the entire configuration.

A capability to monitor the NETCONF protocol is defined in RFC 6022. This document contains a data model including information about NETCONF datastores, sessions, locks, and statistics that facilitates the management of a NETCONF server. It also defines methods for NETCONF clients to discover data models supported by a NETCONF server and defines the <get-schema> operation to retrieve them.

Transport protocols

NETCONF defines four transport mappings

SSH (RFC 6242), which is mandatory to implement
TLS (RFC 5539)
SOAP (RFC 4743) (Historic)
BEEP (RFC 4744) (Historic)

Content

The content of NETCONF operations is well-formed XML. Most content is related to network management.

The NETMOD working group has completed work to define a "human-friendly" modeling language for defining the semantics of operational data, configuration data, notifications, and operations, called YANG. YANG is defined in RFC 6020, and is accompanied by the "Common YANG Data Types" found in RFC 6021.

During the summer of 2010, the NETMOD working group was re-chartered to work on core configuration models (system, interface, and routing) as well as work on compatibility with the SNMP modeling language.

History

The IETF developed SNMP in the late 1980s and it proved to be a very popular network management protocol. In the early part of the 21st century it became apparent that in spite of what was originally intended, SNMP was not being used to configure network equipment, but was mainly being used for network monitoring. In 2002, the Internet Architecture Board and key members of the IETF's network management community got together with network operators to discuss the situation. The results of this meeting are documented in RFC 3535. It turned out that operators were primarily using proprietary Command Line Interfaces (CLI) to configure their boxes. This had a number of features that the operators liked, including the fact that it was text-based, as opposed to the BER-encoded SNMP. In addition, many equipment vendors did not provide the option to completely configure their devices via SNMP. As operators generally liked to write scripts to help manage their boxes, they did find the CLI lacking in a number of ways. Most notably was the unpredictable nature of the output. The content and formatting of output was prone to change in unpredictable ways.

Around this same time, Juniper Networks had been using an XML-based network management approach. This was brought to the IETF and shared with the broader community.

Collectively, these two events led the IETF to the creation of a protocol which it hopes will better align with the needs of network operators and equipment vendors.

External links

@@ Line 12: / Line 12: @@
 # The Secure Transport layer provides a secure and reliable transport of messages between a client and a server.
-The NETCONF protocol has been implemented in network devices such as routers and switches by some major equipment vendors. The protocol provides a mechanism to manipulate the configuration of such devices. It supports robust configuration change transactions involving a number of devices.
+The NETCONF protocol has been implemented in network devices such as routers and switches by some major equipment vendors. One particular strengths of NETCONF is its supports for robust configuration change transactions involving a number of devices.
 == Operations ==