What Is NETCONF?

Disadvantages of CLI and SNMP

CLI-based configuration is complex and differs greatly according to vendors.

CLIs vary significantly by vendor, so users have to learn and develop adaptation scripts for each vendor's CLI. Additionally, frequent changes to the CLI structure and syntax make it difficult to maintain CLI scripts.

The output of commands is structure-agnostic, unpredictable, and prone to changes, causing great difficulties in automatically parsing CLI scripts.

SNMP does not support the transaction mechanism, resulting in a low configuration efficiency. Therefore, it is typically used for monitoring purposes.

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

SNMP does not have a mechanism for submitting configuration transactions. Therefore, configuration is performed separately for each object, not for each service. When multiple objects need to be configured, unknown impacts may be caused on the network if some objects are successfully configured and some fail to be configured.

SNMP manages device configuration on a per-device basis and does not support network-level configuration or multi-device configuration collaboration.

Emergence of NETCONF

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

• NETCONF uses a hierarchical protocol framework, making it more suitable for on-demand, automated, and big data requirements of cloud-based networks.
• NETCONF uses XML encoding to define messages and uses the RPC mechanism to modify configuration data. This facilitates configuration data management and interoperability between devices from different vendors.
• NETCONF performs operations on devices based on the YANG model, reducing network faults caused by manual configuration errors.
• NETCONF provides security mechanisms such as authentication and authorization to ensure message transmission security.
• NETCONF provides a transaction mechanism to support data classification, storage, and migration, phase-based submission, configuration isolation, as well as overall configuration delivery, verification, and rollback, minimizing the impact on network services.
• NETCONF defines a variety of operation interfaces and supports extension on basis of capabilities. This allows vendors to define their own protocol operations, so as to implement unique management functions.

Basic Network Architecture of NETCONF

A NETCONF system contains at least one NMS that manages network-wide devices. The following figure shows the basic network architecture of NETCONF.

Basic network architecture of NETCONF

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

• A client provides the following functions:
  • Manages network devices using NETCONF.
  • Sends RPC requests to a NETCONF server to query or modify one or more parameter values.
  • Learns the status of a managed device based on the alarms and events sent by the NETCONF server of the managed device.

• A server maintains information about managed devices and responds to the client-initiated requests.
  • When receiving a request from a NETCONF client, the NETCONF server parses the request and sends a reply to the client.
  • If a fault or another type of event occurs on a managed device, the NETCONF server reports an alarm or event to the client through the notification mechanism. This allows the client to learn the status of the managed device.

Establishing a NETCONF Session

The NETCONF client and server use the RPC mechanism to communicate with each other. The communication is allowed only after a secure and connection-oriented session is established between them. The client sends an RPC request to the server, and the server returns a reply 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:

1. A client establishes an SSH connection with a server, and then establishes a NETCONF session with the server after authentication and authorization are complete.
2. The client and server send Hello messages to negotiate capabilities.
3. The client sends one or more RPC requests to the server. The following lists some request examples:
   • Modify and commit the configuration.
   • Query the configuration data or status.
   • Perform maintenance operations on the device.
4. The client terminates the NETCONF session.
5. The SSH connection is terminated.

NETCONF Protocol Framework

NETCONF uses a hierarchical structure. Each layer encapsulates certain functions and provides services for its upper layer.

This hierarchical structure enables each layer to focus only on a single aspect of NETCONF and reduces the dependencies between different layers. In this way, the internal implementation changes of one layer have minimized impact on other layers.

NETCONF protocol framework

NETCONF Message Format

The following figure shows the structure of a complete NETCONF YANG request message.

Structure of a NETCONF YANG request message

XML encoding is used in NETCONF, allowing complex hierarchical data to be expressed in a text format that can be read, saved, and manipulated with both traditional text tools and XML-specific tools.

For details about fields in a NETCONF message, see NETCONF Message Formats.

NETCONF Communication Mode

The client-initiated RPC requests and the server-originated replies are both encoded in <rpc> and <rpc-reply> elements using XML. This request-reply framework is independent of transport layer protocols. The following lists some basic RPC elements:

• <rpc>

  An <rpc> element is used to enclose a request sent from a NETCONF client to a NETCONF server.

• <rpc-reply>

  An <rpc-reply> element is sent by a NETCONF server in response to each <rpc> request.

• <rpc-error>

  If any error or alarm occurs during the processing of an <rpc> request, the NETCONF server returns an <rpc-reply> message containing only the <rpc-error> element to the NETCONF client.

• <ok>

  If no error or alarm occurs during the processing of an <rpc> request, the NETCONF server returns an <rpc-reply> message containing only the <ok> element to the NETCONF client.

Configuration Datastores

A configuration datastore is a complete set of configuration parameters for a device. NETCONF defines the existence of one or more configuration datastores and allows configuration operations on them.

Only the <running/> configuration datastore is available in the base model of NETCONF. Additional configuration datastores can be defined by capabilities, and are available only on devices that support the capabilities.

• <running/>: a running configuration datastore. It stores all 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 datastore. It stores configuration data that is about to be committed to <running/> on a device.

  The <candidate/> configuration datastore can be manipulated without impacting the device's current configuration. The <commit> operation can be performed to commit the candidate configuration.

  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

Capabilities

NETCONF capabilities include IETF-defined standard capabilities for implementing basic functions and vendor-defined extended capabilities for implementing extended functions. A device can support more protocol operations by adding capabilities, extending the operation scope of existing configuration objects.

NETCONF defines the syntax and semantics of capabilities. The NETCONF client and server can advertise the supported capabilities to each other. As a result, the client sends the operation requests only within the capability range supported by the server.

For more information, see What Operations and Capabilities Does NETCONF Support?.

NETCONF Capabilities Exchange

Capabilities are advertised in messages sent by each peer during session establishment. When a NETCONF session is established, the client and server immediately exchange Hello messages (containing the <hello> element that lists the supported capabilities) with each other. In this way, they can use the negotiated capabilities to implement specific management functions.

The result of negotiating standard capabilities (except the notification capability) depends on the capabilities supported by the server; the result of negotiating extended capabilities depends on which capabilities both peers support.

NETCONF capabilities exchange process

Generally, the client and server perform the following steps to obtain and modify configurations:

1. The client and server establish a connection-oriented transport protocol session.
2. The client and server exchange Hello messages for capabilities negotiation (for example, both support the latest NETCONF version), preventing ambiguity during data parsing.
3. The client sends an <rpc> request to the server.
4. The server receives and parses the <rpc> request, and verifies validity of this request based on the definition of the YANG data model.
5. The server executes the <rpc> request, and returns an <rpc-reply> message containing the execution result to the client.
6. The client receives and parses the <rpc-reply> message.

Basic Operations of NETCONF

NETCONF defines the base capability that provides a set of operations to modify configurations in datastores and obtain information from datastores. The base capability provides only a small set of low-level operations, not all functions of NETCONF.

NETCONF supports the following basic operations:

• <get-config>: queries all or specified configuration data. The <source> parameter can be used to specify the configuration datastore to be queried from.
• <get>: queries configuration data and status data from only the <running/> configuration datastore.
• <edit-config>: loads configuration data to a specified target configuration datastore (<running/> or <candidate/>). The device performs authorization for the operation in <edit-config>, and performs the requested modifications if authorization is successful.
• <copy-config>: copies data from one configuration datastore to another.
• <delete-config>: deletes a configuration datastore. The <running/> configuration datastore cannot be deleted.
• <lock>: locks a specified configuration datastore. Such locks allow a client to exclusively have the permission to make modifications and thereby prevent conflicts.
• <unlock>: releases a configuration lock, which is previously obtained with the <lock> operation. A client is not permitted to unlock a configuration datastore that is not locked by this client.
• <close-session>: requests graceful termination of a NETCONF session.
• <kill-session>: forces the termination of a NETCONF session. Only an administrator can perform this operation.

NETCONF Standard Capabilities

NETCONF defines a series of standard capabilities, which enhance the NETCONF functionality and strengthen the fault tolerance and scalability. This facilitates the implementation of the NETCONF-based open network management architecture, and provides an efficient method for vendors to develop new functions.

• Writable-running capability

  This capability indicates that a device supports direct writes to the <running/> configuration datastore. Specifically, the device supports <edit-config> and <copy-config> operations on the <running/> configuration database.

• Candidate configuration capability

  This capability indicates that a device supports the <candidate/> configuration datastore, which stores a complete set of the device's configuration data. Such configuration data can be manipulated without impacting the device's current configuration.

• Confirmed commit capability

  This capability indicates that a device supports the <confirmed> and <confirm-timeout> parameters for the <commit> operation. This capability is mainly used in service trial run and verification scenarios.

  • <confirmed>: commits and converts the configuration data in the <candidate/> datastore into configuration data in the <running/> datastore.
  • <confirm-timeout>: specifies a timeout period for confirming the <commit> operation, in seconds. The default value is 600.

  This capability is valid only when a device supports the candidate configuration capability.

• Rollback-on-error capability

  This capability allows a device to perform a rollback if an error occurs. Specifically, "rollback-on-error" can be carried in the <error-option> parameter of the <edit-config> operation. If an error occurs and the <rpc-error> element is generated, the server stops performing the <edit-config> operation and restores the specified configuration to the state before the <edit-config> operation is performed.

  This capability is valid only when a device supports the candidate configuration capability.

• Distinct startup capability

  This capability indicates that a device can perform an independent startup. Specifically, the device can distinguish the <running/> configuration datastore from the <startup/> configuration datastore.

  Operations on the <running/> configuration datastore will not be automatically copied to <startup/> configuration datastore. An operation (such as <copy-config>) needs to be performed to update the startup configuration in the <startup/> datastore to the current running configuration in the <running/> datastore.

• Notification capability

  This capability enables a device to send alarms and events to a client, so that the client can promptly learn device configuration or other changes.

• XML Path Language (XPath) capability

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

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

• Validate capability

  This capability indicates that a device can check configurations for syntactical and semantic errors. Specifically, when delivering configurations, the device checks for syntactical errors, but not the configuration sequence; when committing configurations, the device checks for semantic errors, corrects the configuration delivery sequence, and then commits the configurations to the <running/> configuration datastore.

• URL capability

  This capability indicates that a device can modify or copy files in a specified path. Currently, the <edit-config> and <copy-config> operations are supported. Password information in URLs is protected. When configuration data is exported, password information is exported in cipher text.

• Interleave capability

  This capability indicates that a device supports NETCONF session reuse for multiple purposes. An administrator can use the same NETCONF session to maintain the device and manage alarms and events, improving management efficiency.

• With-defaults capability

  This capability indicates that a device can process default values of the model. The <get>, <get-config>, and <copy-config> operations can carry the <with-defaults> parameter.

NETCONF Extended Capabilities

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

In addition to support for standard capabilities, Huawei defines extended capabilities in the YANG model file huawei-ietf-netconf-ext.yang.

• Sync capability

  This capability indicates that a device can perform full or incremental data synchronization. Through data synchronization, the NMS or controller that manages network devices can have the same configuration data with NEs in real time.

• Active notification capability

  This capability indicates that a device can periodically send keepalive messages to a client when performing a time-consuming operation. This prevents the client from considering a request timeout if the client does no receive a response from the device.

• Commit-description capability

  This capability indicates that a device supports a user-defined description for the <commit> operation, helping users to identify configurations during configuration rollback.

• YANG push capability

  This capability indicates that a server can report the data that a user is interested in to a client through notifications periodically or when trigger conditions are met.

• YANG-library capability

  This capability indicates that a device can provide the YANG capabilities that it supports. A NETCONF client can display basic information about YANG modules supported by a server, including the module name, YANG model version, namespace, and list of submodules. Additionally, the client can save the information to the local buffer.

For more information about Huawei-defined extended capabilities, log in to Huawei Support Website and search for "NETCONF extended capabilities".