Device information is stored in databases. Therefore, the NETCONF protocol defines the basic capability base, which includes a set of operations that modify database configurations and obtain information from the databases. The operations included in base must be a minimal set of functions supported by NETCONF, but not all functions of NETCONF. Table 1 lists the operations included in base.
Operation |
Description |
|---|---|
| <get-config> | Obtains some or all configuration data from the <running/>, <candidate/>, and <startup/> databases. |
| <get> | Obtains some or all running configuration data and status data from the <running/> database. |
| <edit-config> | Adds, modifies, and deletes configuration data in the <running/> or <candidate/> database. |
| <copy-config> | Replaces the target database with the source database. If no target database has been created, this operation creates a database and then replaces the database. |
| <delete-config> | Deletes a database. The <running/> database cannot be deleted. |
| <lock> | Locks a database. A locked database cannot be modified by other users, preventing multi-user configuration conflicts. |
| <unlock> | Unlocks a database. Users can unlock only the databases they have locked. |
| <close-session> | Closes a NETCONF session. |
| <kill-session> | Forcibly closes a NETCONF session. Only an administrator can perform this operation. |
In addition to basic capabilities, NETCONF also provides a series of standard capabilities. These standard capabilities enhance the NETCONF functionality and strengthen the fault tolerance and scalability. They facilitate the implementation of the NETCONF-based open network management architecture, and provide an efficient method for equipment manufacturers to develop new functions. Table 2 lists the standard capabilities and operations of NETCONF.
| Capability | Description |
Operation |
|---|---|---|
Writable-Running |
This capability allows a device to perform the <edit-config> and <copy-config> operations on the <running/> database. |
- |
Candidate Configuration |
This capability indicates that a device supports the <candidate/> database. This capability allows a device to operate the <candidate/> database without affecting the <running/> database. |
<commit>: commits all configuration data in the <candidate/> database. The committed data becomes the running configuration data. |
<discard-changes>: discards uncommitted configuration data in the <candidate/> database. After this operation is performed, the configuration data in the <candidate/> database remains the same as that in the <running/> database. |
||
Rollback on Error |
This capability allows a device to perform a rollback. If an error occurs during the <edit-config> operation and the <rpc-error> element is generated, the NMS stops performing the <edit-config> operation and restores the specified configuration to the status before the <edit-config> operation is performed. |
- |
Distinct Startup |
This capability indicates that a device is capable of starting independently and supports the <startup/> database. |
- |
Notification |
This capability indicates that a device can send alarms and events to the NMS. The NMS manages the device based on the received alarms and events. |
<notification>: actively sends alarms and events to the NMS. |
Interleave |
This capability indicates that a device supports NETCONF session reuse for multiple purposes. You can use the same NETCONF session to maintain the device and manage the alarms and events, improving management efficiency. |
- |