NETCONF

src: i.ytimg.com

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

NETCONF provides a mechanism for installing, manipulating, and removing network device configurations. The operation is realized on a simple Remote Procedure Call (RPC) layer. The NETCONF protocol uses Extensible Markup Language (XML) -based data coding for configuration data as well as protocol messages. The protocol messages are exchanged over secure transport protocols.

The NETCONF protocol can be conceptually partitioned into four layers:

Content Layer consists of configuration data and notification data.
The Operations layer defines a set of basic protocol operations for retrieving and editing configuration data.
Message Layer provides mechanism for remote procedure call coding (RPC) and notifications.
The Safe Transport Layer provides secure and reliable messaging between clients and servers.

The NETCONF protocol has been implemented in network devices such as routers and switches by some major equipment vendors. One of NETCONF's special strengths is its support for powerful configuration changes using transactions involving multiple devices.

Video NETCONF

History

The IETF developed the Simple Network Management Protocol (SNMP) in the late 1980s and proved to be a very popular network management protocol. At the beginning of the 21st century it became clear that regardless of what was originally intended, SNMP is not used to configure network equipment, but is primarily used for network monitoring. In June 2002, the Internet Architecture Board and key members of the IETF network management community joined the network operator to discuss the situation. The results of this meeting are documented in RFC 3535. It turns out that operators primarily use Command Line Interfaces (CLI) to configure their devices. It has a number of features the operator likes, including the fact that it's text-based, as opposed to SNMP BER-encoded. In addition, many equipment vendors do not provide the option to fully configure their devices via SNMP. Because operators generally like to write scripts to help manage their boxes, they find the SNMP CLI lacking in some way. The most notable is the unpredictable nature of output. The content and output format tend to change in an unpredictable way.

Around this same time, Juniper Networks has used an XML-based network management approach. These are brought to the IETF and shared with the wider community. Collectively, these two events led the IETF in May 2003 for the formation of the NETCONF working group. This working group is hired to work on network configuration protocols, which will better suit the needs of network operators and equipment vendors. The first version of the basic NETCONF protocol was published as RFC 4741 in December 2006. Several extensions were published in subsequent years (notice on RFC 5277 in July 2008, a partial key at RFC 5717 in December 2009, with a default in RFC 6243 on June 2011, system notice on RFC 6470 in February 2012, access control at RFC 6536 in March 2012). The revised version of the basic NETCONF protocol was published as RFC 6241 in June 2011.

Maps NETCONF

Protocol layer

Content

The contents of the NETCONF operation are well-formed XML. Most of the content is related to network management. Further support for encoding in JavaScript Object Notation (JSON) is also added.

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

During the summer of 2010, the NETMOD work group has been hired back to work on core configuration models (systems, interfaces, and routing) and work on compatibility with SNMP modeling languages.

Operation

The basic protocol defines the operation of the following protocols:

Basic NETCONF functionality can be expanded with the NETCONF capability definition. An additional set of protocol features supported by the implementation is communicated between the server and the client during the session exchange capabilities of the session settings. The mandatory protocol feature is not included in the exchange of capabilities as it is assumed. RFC 4741 defines a number of optional capabilities including: xpath and: validation. Note that RFC 6241 obscures RFC 4741.

Ability to subscribe and receive asynchronous event notifications published in RFC 5277. This document defines & lt; make-subscriptions & gt; operation, which enables the creation of real-time subscriptions and replays. Notifications are then sent asynchronously using & lt; notification & gt; build. It also defines interleave capabilities, which, when supported with basic notification capabilities: facilitates the processing of other NETCONF operations while the subscription is active.

The ability to support partial locking of the running configuration is defined in RFC 5717. It allows multiple sessions to edit non-overlapping sub-trees in the current configuration. Without this capability, the only key available is for the entire configuration.

The ability to monitor NETCONF protocols is defined in RFC 6022. This document contains data models including information about NETCONF datastores, sessions, keys, and statistics that facilitate the management of NETCONF servers. It also defines a method for the NETCONF client to find the data model supported by the NETCONF server and define & lt; get-schema & gt; operation to retrieve it.

Message

The NETCONF message layer provides a simple, transport-independent framing mechanism for encoding

RPC invocations (& lt; rpc & gt; messages),
RPC results (& lt; rpc-reply & gt; messages), and
event notifications (& lt; notifications & gt; messages).

Each NETCONF message is a well-formed XML document. The RPC result is connected to RPC call by id attribute. NETCONF messages can be pipelined, that is, clients may request multiple RPCs without having to wait for RPC results first. RPC messages are defined in RFC 6241 and notification messages are defined in RFC 5277.