NETCONF

What Is NETCONF?

The Network Configuration Protocol (NETCONF) is a network management protocol developed and standardized by the IETF, allowing a network management system (NMS) to deploy, modify, and delete configurations 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.

Why Do We Need NETCONF?

In the era of cloud computing, network automation has become a critical need, encompassing rapid and on-demand service provisioning as well as autonomous operations and maintenance (O&M). Traditional network management techniques, such as command line interface (CLI) and Simple Network Management Protocol (SNMP), are not sufficient to meet these requirements. This gap is filled by NETCONF, which is increasingly becoming a driving force in network automation.

Disadvantages of CLI and SNMP

Variability in CLI-Based Configuration and Vendor-Specific Complexity

CLIs vary widely from vendor to vendor, requiring users to learn and develop custom scripts for each vendor's CLI. In addition, frequent changes in CLI structure and syntax make CLI scripts difficult to maintain.

Command output is structure agnostic, unpredictable, and subject to change, which makes automatic parsing of CLI scripts very difficult.

Limitations of SNMP Transaction Support: Impeding Efficient Configuration, Primarily Suited for Monitoring

SNMP uses the User Datagram Protocol (UDP), which cannot provide reliable and orderly data transmission and lacks an effective security mechanism.

Since SNMP lacks a system to process configuration changes as transactions, configurations must be applied individually to each object rather than collectively for a service. This piecemeal approach can lead to unpredictable consequences on the network when configuration succeeds for certain objects but fails for others.

Moreover, SNMP's approach to device management is centered on singular devices, with no provision for orchestrating configurations across the network or collaboration among multiple devices.

Advantagesof NETCONF

To overcome the disadvantages of CLI and SNMP, XML-based NETCONF is introduced, which has the following advantage:

• NETCONF is better suited to the on-demand, automated, and high-volume requirements of cloud-based networks because it uses a hierarchical protocol framework.

• NETCONF employs XML-based encoding for message composition and leverages the RPC protocol to alter configuration data, thereby streamlining the management of such data and ensuring interoperability across devices produced by various manufacturers.

• NETCONF reduces network failures caused by manual configuration errors by performing operations on devices based on the YANG model.

• NETCONF provides security mechanisms such as Authentication and Authorization to help ensure the security of messages transmitted.

• NETCONF offers a transactional approach that facilitates the categorization, preservation, and transfer of data. It also allows for phased deployment, segregates configurations, and ensures comprehensive distribution, validation, and reversion of configurations—thereby reducing the potential disruptions to network operations.

• NETCONF establishes an array of operational interfaces and provides support for augmentations based on existing capabilities, enabling manufacturers to craft proprietary protocol actions to execute distinct management features.

How Does NETCONF Work?

Basic Network Architecture of NETCONF

There is at least one NMS that manages network-wide devices in a NETCONF system. The basic network architecture of NETCONF is shown in the following figure.

Basic network architecture of NETCONF

The NETCONF architecture consists of two roles: client and server.

• A client provides the following functions:

• 1. Uses NETCONF to manage network devices.

• 2. Queries or changes one or more parameter values by sending RPC requests to a NETCONF server.

• 3. Determines the status of a managed appliance based on alarms and events sent by the NETCONF server of the managed appliance.

• A server maintains information about devices under management and responds to requests from clients.

• 1. Upon receipt of a query from a NETCONF client, the NETCONF server deciphers the query and transmits a response back to the client.

• 2. In the event of an error or some other incident on a device under management, the NETCONF server utilizes the notification system to inform the client by sending an alert or event notification, enabling the client to ascertain the current condition of the device being managed.

Establishing a NETCONF Session

To communicate with each other, the NETCONF client and server use the RPC mechanism. Only after a secure and connection-oriented session is established between them, communication is allowed. The client sends an RPC request to the server. The server returns a response to the client after processing the request.

Process of establishing a NETCONF session

The process of establishing and terminating a NETCONF session is as follows:

• After successfully completing authentication and authorization, a client initiates an SSH connection to the server and subsequently sets up a NETCONF session with it.

• To negotiate capabilities, the client and server send hello messages.

• The client sends one or more RPC requests to the server. Here are some examples of requests:

• 1. Modify and commit the configuration.

• 2. Query configuration data or status.

• 3. Perform maintenance on the device.

• The client terminates the NETCONF session.

• The SSH connection is terminated.

NETCONF Protocol Framework

NETCONF Protocol Framework

NETCONF has a hierarchical structure. Each layer is an encapsulation of certain functions and a service provider for its parent layer.

This hierarchical structure reduces dependencies between layers by allowing each layer to focus on a single aspect of NETCONF. This ensures that internal changes made to one layer will not affect other layers.

NETCONF protocol framework

NETCONF can be theoretically divided into four strata, consisting of the Secure Transport, Messages, Operations, and Content layers, arranged from the lowest to the highest.

• Secure Transport Layer

This layer provides a way to communicate between Client and Server. NETCONF can overlay any transport protocol meeting basic requirements.

In NETCONF, the preferred transport protocol for transmitting XML information is Secure Shell (SSH).

• Messages Layer

This layer delivers an uncomplicated, transport-agnostic structure for the coding of RPCs and alerts.

Clients wrap an RPC query within an `rpc` tag and forward it to a server. The server then enwraps the outcome of the executed request in an `rpc-reply` tag and transmits it back to the client.

• Operations Layer

This layer defines a set of basic protocol operations that are invoked as RPC methods with parameters that are encoded in XML.

• Content Layer

The top layer is concerned with configuration and notification data. At present, the most common data models are Schema and YANG.

A Schema constitutes a collection of prescribed norms aimed at delineating XML documents. Comparable to an SNMP MIB file, a device employs a Schema document to offer interfaces for configuration and managing devices to a Network Management System (NMS).

YANG is a data modeling language crafted specifically for use with NETCONF. A client is capable of translating RPC operations into XML communications to facilitate interaction between the client and server, all within the parameters defined by the YANG model.

NETCONF Message Format

The following figure shows a complete NETCONF YANG request message.

Structure of a NETCONF YANG request message

NETCONF uses XML encoding to express complex hierarchical data in a text format that can be read, saved, and manipulated by both traditional text and XML-specific tools.

NETCONF Communication Mode

RPC requests initiated by the client and the responses sent by the server are encapsulated within XML-encoded `rpc` and `rpc-reply` elements, respectively. This request-response structure operates irrespective of the underlying transport protocols. Below are a few fundamental RPC elements listed for reference:

• `rpc`

• A request sent from a NETCONF client to a NETCONF server is enclosed in a `rpc` element.

   

• `rpc-reply`

• In response to each `rpc` request, a NETCONF server sends a `rpc-reply` element.

• `rpc-error`

• The NETCONF server returns a `rpc-reply` message containing only the `rpc-error` element to the NETCONF client when an error or alarm occurs during the processing of a `rpc` request.

• `ok`

• The NETCONF server returns a `rpc-reply` message containing only the `ok` element to the NETCONF client if no error or alarm occurs during the processing of a `rpc` request.

Configuration Datastores

A Configuration Datastore is a complete set of parameters used to configure a device. NETCONF defines the existence of one or more Configuration Datastores and allows configuring operations performed on them.

In the base model of NETCONF, only the configuration datastore is available. Additional configuration datastores can be defined by capabilities, available only on devices supporting those capabilities.

• `running/`: A running configuration datastore. It is used to store all of the configurations that are currently active on a network device.

• Only one `running/` configuration datastore exists on a device, and it always exists.

• `candidate/`: a candidate configuration data store. It is used to store configuration data that is in the process of being committed to a on a device.

• The `candidate/` configuration data store can be manipulated without any effect on the current configuration of the device. To commit the candidate configuration, the `commit` operation can be performed.

• To support the `candidate/` configuration datastore, a device must support the candidate configuration capability, which is a standard NETCONF capability.

• `startup/`: a startup configuration datastore (similar to a saved configuration file). It stores the configuration data to be loaded during device startup.

• To support the `candidate/` configuration datastore, a device must support the distinct startup capability, which is a standard NETCONF capability.

Configuration data migration between datastores

What Are NETCONF Capabilities?

Capabilities

NETCONF capabilities include standard capabilities defined by the IETF for implementation of basic functions, and advanced capabilities defined by the vendor for implementation of advanced functions. By adding capabilities, a device can extend the scope of operation of existing configuration objects to support more protocol operations.

NETCONF is the definition of the syntax and semantics of capabilities. The supported capabilities can be advertised to each other by the NETCONF client and server. Consequently, the client sends operation requests only within the server's supported capabilities.

NETCONF Capabilities Exchange

During session establishment, capabilities are advertised in messages sent by each peer. The client and server immediately exchange hello messages (containing the element that lists the supported capabilities) when a NETCONF session is established. In this way, they can use the negotiated capabilities for the implementation of specific management functions.

The outcome of the negotiation of standard features (except the notification feature) depends on the features supported by the server; the outcome of the negotiation of extended features depends on the features supported by both peers.

In general, to obtain and change configurations, the client and server perform the following steps:

• A connection-oriented transport protocol session is established between the client and the server.

• To avoid ambiguity during data parsing, the client and server exchange Hello messages for capabilities negotiation (eg: both support the latest NETCONF version).

• The client sends a `rpc` request to the server.

• The server receives and parses the `rpc` request, and verifies the validity of this request on the basis of the definition of the YANG data model.

• The server executes the `rpc` request and sends a `rpc-reply` message back to the client with the result of the execution.

• The `rpc-reply` message is received and parsed by the client.

What Operations and Capabilities Does NETCONF Support?

NETCONF delivers a core suite of functions for handling device configurations as well as for requesting information about device settings and status. Moreover, it accommodates supplementary operations contingent on the capabilities a device declares.

Basic Operations of NETCONF

NETCONF defines the base capability, which provides a set of operations for changing configurations in data stores and for retrieving information from data stores. Only a small set of low-level operations, not all of NETCONF's functionality, is provided by the base capability.

NETCONF supports the following basic operations:

• `get-config` : Retrieves all or specified configuration data. The configuration datastore to query can be specified with the parameter.

• `get` : Retrieves configuration and status data from the configuration datastore only.

• `edit-config` : Loads configuration data into a specified target configuration datastore (`running/` or `candidate/` ). The device will perform authorization for the operation in `edit-config` , and will perform the requested changes if the authorization is successful.

• `copy-config` : Copies data from one configuration datastore to another.

• `delete-config` : Deletes a configuration datastore. The `running/` configuration store cannot be cleared.

• `lock` : locks a specified configuration datastore. Such locking allows only one client to be allowed to make changes, thereby preventing conflicts.

• `unlock`: Releases a configuration lock previously obtained with the operation. A configuration datastore that is not locked by that client cannot be unlocked by a client.

• `close-session`: Requests that a NETCONF session be gracefully terminated.

• `kill-session`: Forces the termination of a NETCONF session. This operation can be performed only by an administrator.

NETCONF Standard Capabilities

NETCONF defines a set of standard features that extend the functionality of NETCONF. These features provide fault tolerance and scalability. This provides an efficient way for vendors to develop new features and facilitates the implementation of the NETCONF-based open network management architecture.

• Writable-running Capability

This capability indicates that a device supports direct writes to the `running/` configuration data store. In particular, the device supports `edit-config` and `copy-config` operations on the `running/` configuration data store.

• Candidate Configuration Capability

This capability indicates that a device has support for the configuration data store, which stores a complete set of the device's configuration data. Without affecting the current configuration of the device, such configuration data can be manipulated.

• Confirmed Commit Capability

This capability indicates that a device supports `confirmed` and `confirm-timeout` parameters for `commit`. Service test-run and verification scenarios primarily use this capability.

• 1. `confirmed`: commits and converts the configuration data in the `candidate/` datastore to the configuration data in the `running/` datastore.

• 2. `confirm time out`: Specifies a timeout period for the confirmation of the `commit` operation, in seconds. The default is 600.

This capability is valid only if a device has support for the candidate configuration capability.

• Rollback-on-error Capability

When an error occurs, this capability allows a device to perform a rollback. In particular, "rollback-on-error" can be passed in the `error-option` parameter of the `edit-config` operation. If an error occurs and the `rpc-error` element is generated, the server will stop the execution of the `edit-config` operation and will restore the specified configuration to the state it was in before the `edit-config` operation was performed.

This capability is valid only if a device has support for the candidate configuration capability.

• Distinct Startup Capability

This capability is an indication that a device is capable of independent startup. In particular, the device can distinguish the `running/` configuration data store from the `startup/` configuration data store.

Operations performed on the `running/` configuration datastore are not automatically copied to the `startup/` configuration datastore. To update the startup configuration in the `startup/` datastore to the current running configuration in the `running/` datastore, an operation (such as `copy-config`) must be performed.

• Notification Capability

This capability allows a Device to send alarms and events to a Client, allowing the Client to quickly learn when the Device is configured or other changes occur.

• XML Path Language (XPath) Capability

This capability indicates that a device can use XPath expressions as query conditions in the `filter` element of the `get` operation. The `get` and `get-config` operations can use XPath to query the specified data.

To address parts of an XML file, XPath uses path expressions. The syntax of XPath is similar to the syntax of a file path in a file management system.

• Validate Capability

This capability means that a device can check configurations for syntactic errors as well as semantic errors. Specifically, during configuration delivery, the device checks for syntax errors but not configuration order; during configuration commit, the device checks for semantic errors, fixes the configuration delivery order, and then commits the configurations to the `running` configuration store.

• URL Capability

This capability indicates that a device has the ability to modify or copy files located in a specified path. At present, `edit-config` and `copy-config` operations are supported. Password information in URLs is protected. Password information is exported in ciphertext when exporting configuration data.

• Interleave Capability

This capability is an indication that a device supports NETCONF session reuse for multiple purposes. An administrator can use the same NETCONF session to maintain the device and to manage alarms and events, which improves the efficiency of the management process.

• With-defaults Capability

This capability indicates that a device can handle model defaults. The `get`, `get-config`, and `copy-config` operations can take the `with-defaults` parameter.

NETCONF Extended Capabilities

In addition to the NETCONF-defined features, vendors can customize features to extend management capabilities.

• Sync Capability

This capability signifies the device's ability to execute comprehensive or partial data alignment. By means of data synchronization, the management systems or controllers overseeing network elements can maintain concurrent and matching configuration data with the network entities.

• Active Notification Capability

This capability allows a device to emit regular keepalive signals to a client during lengthy procedures. It ensures that the client does not interpret the absence of an immediate response from the device as a request timeout.

• Commit-description Capability

This capability demonstrates that a device accommodates the addition of custom descriptions to the `commit` action, aiding users in recognizing specific configurations when reverting changes.

• YANG Push Capability

This feature allows a server to send periodic notifications, or notifications when trigger conditions are met, to a client about data that a user is interested in.

• YANG-library Capability

This capability signifies that a device is equipped to reveal the YANG capabilities it possesses. A NETCONF client is able to present essential details of the YANG modules a server supports, encompassing the module's name, its version of the YANG model, the associated namespace, and any included submodules. Furthermore, this information can be stored by the client in a local buffer.