Pixelbliss - Fotolia


Can the NETCONF protocol give OpenFlow a run for its money?

OpenFlow is no longer the undisputed king of the SDN castle, with alternative standards like the NETCONF protocol challenging its hegemony.

OpenFlow, long the accepted management and control protocol for software-defined networks, is facing a challenge...

from other protocols. Alternatives to OpenFlow include protocols like NETCONF, BGP, OVSDB, XMPP and MPLS-TP. While each of these protocols can be used to manage aspects of network operation, none offer identical functions and capabilities when compared to OpenFlow.

NETCONF protocol

The NETCONF protocol, defined by RFC 6241, is a device-configuration protocol designed to replace command line interface (CLI), Simple Network Management Protocol (SNMP), and other proprietary configuration mechanisms. Using the NETCONF protocol, management software can write configuration data to a device and retrieve data from a device. All data is encoded in Extensible Markup Language (XML) and transmitted via remote procedure calls (RPCs) over a secure, connection-oriented protocol, such as Secure Socket Shell or Transport Layer Security.

The NETCONF protocol defines multiple data stores, or sets of configuration data. The running configuration data store contains the configuration currently in use by the device. Some devices also maintain a startup configuration data store -- separate from the running configuration data store -- which contains the configuration data in place when the device first boots.

In addition to the configuration data stores, devices maintain state data, information like packet counts, and other data collected by the running device. This data can be read, but not written, by controller software.

The candidate configuration data store is an optional device feature. When available, it contains a set of configuration data that the controller may use to update the running data store and modify the device's operation. Separating the running configuration from the candidate eliminates the problem of inconsistent configuration (e.g., a series of CLI commands are updating the configuration and leave the configuration in an inconsistent state as one command after another is executed).

Controllers and devices exchange a set of capabilities when a NETCONF session starts. Capabilities include information such as the list of NETCONF protocol versions supported, whether a candidate data store is present, and the ways in which the running data store can be modified. In addition to capabilities defined in the NETCONF RFC, developers can add additional capabilities by following the specification format described in the RFC.

The NETCONF protocol's command set consists of commands that read and modify device-configuration data and a command to read state data. Commands are communicated via RPCs, and responses are returned as RPC replies. An RPC reply must be returned in response to each RPC. A configuration operation may consist of a series of RPCs, each with its corresponding reply.

The transport protocol chosen must guarantee that RPCs are delivered to the device in the order sent, and replies must be received in the order of the initiating RPCs. In addition to commands from the controller to the device, a device can issue a notification to inform the controller of some event on the device.

NETCONF protocol commands:

  • get-config: Requests return all or part of a configuration data store. The parameters passed specify which configuration data store, and whether the entire data store is to be returned or which specific items are requested. The device replies with the requested data or an rpc-error, if the device cannot fulfill the request.
  • get: Requests the running configuration data store and the state data. The command may request all of the data or specify a set of elements.
  • edit-config: Modifies a configuration data store. Operation directives contained within the command operate on specific configuration data elements within the target data store.
  • merge: The data carried in the edit command is merged with the existing data.
  • replace: The existing data is replaced by the data carried in the edit command.
  • create:  The specified data store element is created and the data in the command inserted. If the element already exists, the device returns an rpc-error.
  • delete: The specified data store element is deleted. If it doesn't exist, the device returns an rpc-error.
  • remove: Similar to delete, but if the element doesn't exist, the operation is ignored and no error is returned.
  • copy-config: Copies the contents of one data store to another. If the target data store does not exist, it is created.
  • commit: Copies the contents of the candidate data store into the running data store. Used when device capabilities do not permit copy-config to modify the running data store.
  • delete-config: Deletes the specified data store.
  • lock and unlock: A device may support multiple NETCONF sessions with different controllers or it may continue to support other configuration mechanisms such as CLI or SNMP. The lock command prevents other configuration sources from interfering with an ongoing set of NETCONF operations. The unlock command releases the lock and enables other sources to operate on the device. Locks should only be held during the short time period while an actual operation is going on.
  • close-session: Controller software typically opens a NETCONF connection with a device and maintains it as long as the controller is managing the device. Close-session gracefully shuts down the connection when the controller will no longer manage the device.

NETCONF and OpenFlow

Both NETCONF and OpenFlow can provide a communication path between controller software and devices, but the protocols differ in a number of ways. NETCONF is a configuration protocol, while OpenFlow operates only on the flow tables that specify how incoming packets are to be routed. OpenFlow switches are configured using the OF-Config, which uses NETCONF to communicate with devices.

The NETCONF protocol adapts to any device architecture via a set of optional capabilities, and developers can create additional capabilities so NETCONF devices can contain proprietary features. OpenFlow, on the other hand, dictates a specific device architecture. OpenFlow devices must be built to a standard architecture with no proprietary features, enabling vendors to develop white box switches that adhere to the OpenFlow standard. Availability of these commodity devices is expected to greatly reduce network cost.

OpenFlow switches do not support the routing protocols that switches and routers have traditionally used to determine paths through the network; all information about packet paths comes from the controller. NETCONF devices may support such routing protocols. In software-defined networks where these protocols continue to be used, controller software manages some aspects of network operation while packet paths are still determined at the device level.

OpenFlow or NETCONF?

So, OpenFlow or NETCONF? The bottom line: Networks vary. Some network managers will choose to continue to use existing devices that have been updated with NETCONF interfaces. Others will like the price advantage of white box switches. Managers must continue to follow developments as software-defined networking (SDN) matures and choose designs and products that most closely meet their networks' requirements.

Next Steps

Plethora of SDN protocols threaten OpenFlow

Is OpenFlow dead?

A look inside the OpenFlow protocol


This was last published in September 2015

Dig Deeper on Network protocols and standards