Basic NETCONF Concepts
NETCONF Network Architecture
Figure 1 shows a typical NETCONF network topology which contains at least one NMS used for device management. The NETCONF network architecture consists of the following components:
NETCONF Manager
A NETCONF manager resides on an NMS server and functions as a client that uses NETCONF to manage devices. It sends <rpc> elements to a NETCONF agent to query or modify configuration data, and learns the status of a managed device based on the alarms and events actively reported by the NETCONF agent.
NETCONF Agent
A NETCONF agent resides on a managed device and functions as a server that maintains the configuration data on the managed device, responds to the <rpc> elements sent by a NETCONF manager, and sends the requested information to the NETCONF manager.
A NETCONF session is a logical connection between a NETCONF manager and agent. A network device must support at least one NETCONF session.
The NETCONF manager obtains configuration data and status data from the running NETCONF agent and operates the configuration data to migrate the NETCONF agent status to the expected status. NETCONF deals with configuration data operations performed by the NETCONF manager and is not involved with how configuration data is stored.
- Configuration data: a set of writable data that is required to transform a device from its initial default state into its current state
- State data: the additional non-configuration data on a device, such as read-only status information and collected statistics
NETCONF Modeling Language
YANG is a data modeling language developed to design NETCONF-oriented configuration data, status data models, RPC models, and notification mechanisms.
Related Concepts
The NETCONF client and server communicate through the RPC mechanism. To implement the communication, a secure and connection-oriented session must be established. The client sends an RPC request to the server. After processing the request, the server sends a response to the client. The RPC request of the client and the response message of the server are encoded in XML format.
NETCONF defines the syntax and semantics of capabilities. The protocol allows the client and server to notify each other of supported capabilities. The client can send the operation requests only within the capability range supported by the server.
XML encoding
XML, the encoding format used by NETCONF, uses a text file to represent complex hierarchical data. NETCONF allows a user to use a traditional text compilation tool or XML-specific compilation tool to read, save, and operate configuration data.
XML-based network management uses XML to describe managed data and management operations so that management information becomes a database comprehensible to computers. XML-based network management helps computers efficiently process network management data, improving network management capabilities.
The header of an XML encoding file is <?xml version="1.0" encoding="UTF-8"?>, where:- <?: indicates the start of an instruction.
- xml: identifies an XML file.
- Version: indicates the NETCONF version. "1.0" indicates that the XML1.0 standard version is used.
- encoding: indicates the character set encoding format. Only UTF-8 encoding is supported.
- ?>: indicates the end of an instruction.
RPC mode
NETCONF uses the RPC mechanism and XML-encoded <rpc> and <rpc-reply> elements to provide a framework of request and response messages independent of transport layer protocols. Table 1 lists some basic RPC elements.
Table 1 Elements Element
Description
<rpc>
Encapsulates a request that the client sends to the server.
<rpc-reply>
Encapsulates a response message for an <rpc> request message. The server returns a response message, which is encapsulated in the <rpc-reply>element, for each <rpc> request message.
<rpc-error>
Notifies a client of an error that occurs during <rpc> request processing. The server encapsulates the <rpc-error> element in the <rpc-reply> element and sends the <rpc-reply> element to the client.
<ok>
Notifies a client that no errors occur during <rpc> request processing. The server encapsulates the <ok> element in the <rpc-reply> element and sends the <rpc-reply> element to the client.
Capability set
A capability set includes basic and extended functions implemented based on NETCONF. A device can add protocol operations through the capability set to extend the operation scope of existing configuration objects.
Each capability is identified by a unique uniform resource identifier (URI). The URI format of the capability set defined by NETCONF is as follows:
urn:ietf:params:xml:ns:netconf:capability:{name}:{version}In addition to the capability set defined by NETCONF, a vendor can define additional capability sets to extend management functions. A module that supports the YANG model needs to add YANG notifications to Hello messages before sending the messages. The message format is as follows:<capability>http://www.huawei.com/netconf/vrp/huawei-ifm?module=huawei-ifm&revision=2013-01-01</capability>
Configuration Database
A configuration database is a collection of complete configuration parameters for a device. Table 2 describes NETCONF-defined configuration databases.
Table 2 NETCONF-defined configuration databases Configuration Database
Description
<running/>
It stores the effective configuration running on a device, and the device's status information and statistics.
Unless the NETCONF server supports the candidate capability, this configuration database is the only standard database that is mandatory.
To support modification of the <running/> configuration database, the device must have the writable-running capability.
<candidate/>
It stores the configuration data to be run on a device.
An administrator can perform operations on the <candidate/> configuration database. Any change to the <candidate/> database does not directly affect the current device.
To support the <candidate/> configuration database, the current device must have the candidate capability.
NOTE:The <candidate/> configuration databases supported by Huawei devices do not allow inter-session data sharing. Therefore, the configuration of the <candidate/> configuration database does not require additional locking operations.
<startup/>
It stores the configuration data loaded during device startup, which is similar to the saved configuration file.
To support the <startup/> configuration database, the current device must have the Distinct Startup capability.