Protocol contention: Is NETCONF sufficient to compete with OpenFlow?

Protocol contention: Is NETCONF sufficient to compete with OpenFlow?

OpenFlow, which has been a management and control protocol for Software Defined networks for a long time, is currently facing challenges from other protocols.

Protocols that can replace OpenFlow include NETCONF, BGP, OVSDB, XMPP, and MPLS-TP. However, although these protocols can be used to manage all aspects of network operations, they do not provide the same functions and features as OpenFlow.

NETCONF Protocol

The NETCONF Protocol, defined by RFC 6241, is used to replace command line interface (CLI), Simple Network Management Protocol (SNMP), and other proprietary configuration mechanisms. Management software can use the NETCONF protocol to write configuration data to the device or retrieve data from the device. All data is encoded using Extensible Markup Language (XML). Using Secure and connection-oriented protocols such as SSL or Transport Layer Security, remote procedure CILS, RPCs.

The NETCONF Protocol defines multiple data storage or multiple configuration data sets. The running configuration data storage contains the configuration information that the current device is using. Some devices also store STARTUP configuration data, which includes the configuration data when the device is started for the first time, but is separated from the running configuration data.

In addition to configuration data, devices also store status data and information, such as package statistics and other data collected by running devices. The control software can read the data but cannot write the data.

Candidate configuration data storage is an optional device performance. If enabled, it contains a set of configuration data, and the controller can be used to update running data storage and modify device operations. Separating the running configuration data from the alternative configuration data can eliminate different configuration problems (for example, a series of CLI commands are updating the configuration, as one command is executed successively, the configuration will be in an inconsistent state ).

Once the NETCONF session starts, the controller and the device exchange a set of features ". This set of "Features" includes some information, such as the NETCONF Protocol version Support List, whether the alternative data exists, and how the running data storage can be modified. In addition, "features" are defined in the netconf rfc. developers can add additional "features" by following the standard format described in RFC ".

The command set of the NETCONF protocol consists of a series of commands that read and modify device configuration data and read status data. The command communicates through RPCs and responds with RPC replies. An RPC reply must respond to an RPC before returning. A configuration operation must consist of a series of RPC, each of which has a corresponding response RPC.

The selected transmission protocol must ensure that RPC is delivered to the device in the sending order, and the response must be received in the order of initiating RPC. In addition to sending commands from the Controller to the device, the device can also send notifications to inform the Controller of some events on the device.

NETCONF protocol command:

Get-config: The request returns all or part of the configuration data. The passed Parameters specify the configuration data to be returned and the specific elements to be retrieved. The device replies to the requested data. If the device cannot meet the request, an RPC error is returned.

Get: The request returns the running configuration data and status data. This command can request all data or specify a group of elements.

Edit-config: modify configuration data. The operation commands contained in the Command operate on specific configuration data elements in the target data.

Merge: The data carried in the edit command is merged into existing data.

Replace: replace existing data with the data carried in the edit command.

Create: create a specified data storage Element and insert data in the command. If this element already exists, the device returns an RPC error.

Delete: delete a specified data storage element. If the element does not exist, the device returns an RPC error.

Remove: similar to the delete command, but if the element does not exist, the operation is ignored and no error is returned.

Copy-config: copy one data storage to another. If the target data storage does not exist, create it.

Commit: copy the content in the alternative data storage to the running data storage. This command is used when the copy-config command is not allowed to modify the running data storage.

Delete-config: delete the specified data storage.

Lock and unlock: A device may support multiple NETCONF sessions with multiple controllers, and may continue to support other configuration mechanisms, such as CLI or SNMP. the lock command prevents other configuration sources from interfering with a series of running NETCONF operations. The unlock Command releases the lock and allows other sources to operate on the device. In practice, the locks command can only be executed in a short time.

Close-session: the controller software usually opens a NETCONF connection when the device is started, and the connection is maintained as long as the controller is still managing the device. When the Controller no longer manages the device, close-session is used to close the connection normally.

NETCONF vs. OpenFlow

Although both NETCONF and OpenFlow can provide communication between controller software and devices, the two Protocols are completely different in many aspects. NETCONF is a configuration protocol, while OpenFlow only specifies how data packets are transmitted through routes in the process table. OpenFlow switches use OF-Config for configuration, while OF-Config uses NETCONF to communicate with devices.

The NETCONF Protocol applies to any device architecture through a set of optional performance. developers can create additional "Features", so the NETCONF device can include proprietary features. In contrast, OpenFlow has a specific device architecture. OpenFlow devices must be built on a standard architecture without proprietary features to ensure that vendors can develop white-box switches that are attached to OpenFlow standards. Once these products are put into use, the network cost will be greatly reduced.

The OpenFlow switch does not support the routing protocol used by traditional switches and routers to determine the network path. All information about the packet Path comes from the router. The NETCONF device supports this routing protocol. In a Software Defined network, these protocols will continue to be used, controller software manages some aspects of network operations, and the data packet path is still determined at the device level.

OpenFlow or NETCONF?

Therefore, do you choose OpenFlow or NETCONF? The essence is that the network is different. Some network administrators choose to continue using existing devices that have updated the NETCONF interface. Other administrators may choose white-box switches because of their price advantages. With the maturity of software-defined network technology, administrators must continue to focus on market development and choose the designs and products that best meet their network needs.