|
The NETCONF protocol is a modern building block for device management automation, offering a unified approach to network configuration, rather than a device-specific methodology. To equipment vendors, NETCONF is a way to standardize the management interface of network elements. To service providers, NETCONF is a way to optimize the administrative workflow, by moving management intelligence out of the device under management, and consolidating this management into higher-level applications. This paper provides a brief overview of NETCONF, presents its commands and operations, describes how the protocol works in a series of practical scenarios, and describes its sophisticated configuration capabilities.
Overview of NETCONF
NETCONF is a protocol which was officially published as an RFC by the IETF NETCONF Working Group on December 13, 2006. [1, 2]. It provides the mechanisms for installing, querying, manipulating and deleting the configurations of network devices. As shown in Figure 1, NETCONF consists of four layers.
NETCONF exposes a standardized RPC-style API based on XML. The XML requests and responses are sent over a persistent, secure, authenticated transport protocol, such as SSH. The use of encryption means the requests and responses are confidential and tamper-proof. This enables devices to be managed over an untrusted wide area network (WAN) using well-known security technologies. Configuration over a WAN means network management can be centralized, by consolidating all management to a single site, or decentralized, by permitting multiple sites to share device management work.
In addition to secure communications, NETCONF requires devices to track client identities and enforce permissions associated with identities. Identities are managed at the underlying secure transport layer, such as SSH, and reported to the NETCONF agent. The NETCONF agent then enforces any restrictions based on whatever security model is implemented by the node. NETCONF is extensible and future proof. NETCONF sessions begin with a capability discovery phase, where the network element exposes its capabilities to the management device and the parties subsequently discard unknown capabilities. New features can be defined locally, but formally, with a rigorous syntax and semantics.
NETCONF Commands and Operations
NETCONF consists of a base set of commands, extended by capabilities. A capability is identified by a URI, and augments the base operations with new commands, parameters, values and named entities. NETCONF commands operate mainly on data stores, which are versions of the device state. A data store consists of configuration data, which represents settable device parameters and state data, which represents device statistics. Configuration data can be read and written while state data is read-only. By default, a NETCONF device provides a single data store, named <running>. Capabilities add extra data stores, such as <startup>, which represents the device’s startup state, or <candidate>, which represents a temporary state before it is made permanent. NETCONF uses a remote procedure call model. Requests are XML documents with a top-level tag <rpc>. An XML namespace [3] and a unique message identifier are associated with each request. An example that defines a trivial query <get> of the configuration follows. (Note that, when appropriate, the core portion of XML requests will be highlighted to help understanding.)
|
