June 13, 2019

The Importance of Standard Management Interfaces

By Hassan Dakroub, Customer Solutions Architect

The wave of virtualization is catching up in every vertical of technology, and new protocols are being defined to improve functionality and management of emerging technologies. Software-defined Networking, or SDN, is one of those technologies.  SDN was first used in data centers to configure network devices connecting virtual machines amongst themselves and the internet on a massive scale and is now being adapted into other applications and technologies.

At a high level, SDN allows better control of devices in a network and enables automation of functionality within the network.  Prior to SDN, network devices consisted of separate control and data planes within the same device which required individual configuration or programming of each device. The data plane forwards traffic from one port to another within the same network box, while the control plane determines the ingress and egress ports for each data stream and pushes that information to the data plane. The control plane makes the forwarding determination by either using user-defined static configuration or using protocols to communicate with other network devices. These protocols discover what every surrounding device knows about the network, and then makes the calculation for the shortest path for each traffic stream.  This process works but requires individual instructions to each network element, which can slow down as the number of executable instructions increases.  Like everything in the networking space, this method was long overdue for some course correction to improve efficiency and speed and led to the birth of SDN.

SDN centralizes the control brain and localizes the “brain” in the network.  This separation of the control and data planes is done by centralizing the control plane of networking devices into an SDN controller. This allows a network operator to configure the network from a central location and add new services or update existing services without having to log in to every network device affected by the change.  This reduces the time to configure the network and makes the operation of the devices much simpler.  Additionally, the centralized control plane simplifies automation in the network.  This is because a centralized control plane has constant visibility of the network and devices which can determine network conditions, changes, and parameters and allow custom-built applications to be implemented in the network.  These applications will enable dynamic intelligence that will lead to improved performance and of the devices and the network by being able to predict network performance and dynamic correction/adjustment based on the performance.

We will discuss the various elements of SDN over subsequent posts and we’ll start by discussing three protocols and model languages that are essential for the operation of SDN.  These protocols are the YANG data model, Netconf, and Restconf.

• YANG (Yet Another Next Generation) is a data modeling language used to model configuration and state data of network devices. This makes them available for the Network Configuration (NETCONF) protocol to explore, manipulate and change the behavior/configuration of network devices.  A YANG module allows a complete description of all data sent between a NETCONF client and server. The client is the SDN controller and the server is the Network devices.
• NETCONF protocol provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data and the protocol messages. A NETCONF session is the logical connection between a network administrator, or network application, and a network device. The YANG data modeling language is used to represent data retrieved from network devices to the NETCONF protocol. Retrieved data from a running system is separated into two classes, configuration data, and state data. Configuration data is a set of writable data that a user can configure, while state data are read-only status information and collected statistics. NETCONF recognizes the difference between the two types of data and has a mechanism to retrieve one type of data, or both, by executing different commands. Executing the command retrieves configuration data only for the NETCONF protocol to manipulate and push back to the network device, while the operation retrieves configuration and state data. NETCONF defines the existence of a configuration datastore, which is the set of configuration commands for network devices. At a minimum, a network device has one datastore, “running” data store, that holds the complete running configuration on the unit. However, other devices can support candidate datastore, which can be manipulated without impacting the running datastore, until a commit command is executed.
• RESTCONF protocol, on the other hand, is an HTTP-based protocol, compared to NETCONF XML interface, that provides a programmatic interface for accessing data represented in YANG model, using the datastore concepts defined in the NETCONF protocol. RESTCONF allows web applications to access the configuration data, state data, RPC operations, and event notifications within a networking device in a modular and extensible manner. RESTCONF combines the simplicity of HTTP with the predictability and automation potential of a schema-driven API.  Knowing the YANG modules used by the server, a client can derive all management resource URLs and the proper structure of all RESTCONF requests and responses.

New protocols such as SDN, NETCONF, RESTCONF, YANG data Model, as well as devices that support these protocols, empower this new technology wave to simplify network management, and automating it, in a multi-vendor, multi-functionality network. This also makes supporting new technologies and services possible as they emerge, without having to forklift the whole network.

References:

• YANG RFC https://tools.ietf.org/html/rfc6020
• NETCONF RFC https://tools.ietf.org/html/rfc6241
• RESTCONF RFC https://tools.ietf.org/html/rfc8040