No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Will SDN Be the Future of Network Change Management?

A number of writers have suggested that the primary function of Software Defined Networking (SDN) is the functional equivalent of an IT discipline called Network Change and Configuration Management (NCCM). I think this thought pattern stems from SDN's ability to perform network configuration changes. If you don't look carefully, it would seem that SDN and NCCM perform nearly identical functions. However, there is a significant difference between the two systems. Let's take a look at each and then examine some examples that demonstrate the differences.

NCCM Functionality
NCCM provides functions that give the network and/or systems administrator the tools to automate tracking network changes and to perform configuration updates across the network infrastructure. A good NCCM system enhances the productivity of the network administrators, allowing them to track network changes, detect unauthorized changes, automate similar changes across many devices, and to automate device OS updates. The list of functions includes the following:

1. Change management. Incorrect configuration changes are the source of at least 40% of network outages, which makes tracking configuration changes a big factor in keeping networks stable and efficient. Monitoring physical infrastructure changes is another form of change management, identifying cases where a redundancy failure has occurred--before a second failure causes an outage. An audit trail of all changes provides useful fault analysis capabilities. A good change management system will interface with a trouble-ticketing system and a Change Control Board (CCB) process for validating proposed changes prior to implementation.

2. Validation of configurations against pre-defined and validated templates. A consistently configured network is more stable and easier to manage, making this function critical for a smoothly operating network.

3. Automation of configuration and OS updates.

An NCCM system typically does not perform the following:

1. Bi-directional communications mechanism between the applications and the NCCM system.

2. Dynamic, near real-time network changes to support application requirements.

3. Feedback from the network to inform the application of changes that would impact the application. The feedback could be verification that a requested change has or has not been performed. Or it could be information about an unexpected change in the network such as the loss of a critical link or network device and the subsequent change in available bandwidth or latency.

Top-performing organizations employ some form of NCCM to make their networks more consistent and stable. However, the network is separate from the applications. The aforementioned Change Control Board (CCB) process for verifying and approving changes is typically slow. Some CCB approval processes take a week or more. In some industries, there are restrictions on when changes can be implemented, such as in retail networks around the peak holiday online shopping times or in brokerage networks during stock market trading hours. The result is networks that are slow to react to changes in business applications.

The slow network configuration change process means that the network must be configured to support a variety of applications without changing the network. In addition, the network must support applications that migrate between VM servers. As the application and server environment becomes more dynamic, the network must become more dynamic, causing an increase in the number of emergency change requests.

What an SDN does
In some sense, an SDN is like a very dynamic NCCM. However, the dynamics require a fundamentally different system. There is a much tighter coupling between the applications and the network with SDN. The communications will ideally be in both directions:

1. The applications make requests of the network for bandwidth, latency, and connectivity. The network must return an acknowledgement regarding the result of the request. In some cases, the network may not be able to provide the service being requested, and the application needs to know that the request was denied.

2. The network needs to tell the applications that some part of the network changed, perhaps due to a link or device failure.

When an SDN controller receives a request from an application, it needs to know the current state of the network and whether the requested functionality can be provided. This means that the SDN needs to know the current state of the network, including external changes. In this way, it is similar to an NCCM.

The difference is in the real-time nature of the information that an SDN needs to have. When a VM is moved to another server, all the data paths to clients and other servers need to be maintained. When an application needs a particular class of service from the network, can that service be supported? What happens when a service that has been provided to an application is impacted by a failure within the network? Unlike in the NCCM environment, with SDN there is no need to provision the network to support the maximum requirements of all applications.

An SDN facilitates communication between applications and the network. The result is a much more dynamic network that supports a dynamic application environment. The network may change on a minute-by-minute basis. It will need to know that it should not try to make a configuration change to an interface that has gone down due to a physical failure. That is why an SDN will need to have a good knowledge of the current state of the network as well as a good record of any changes that it has made to the network.

The added efficiency of an SDN implies additional complexity. When something fails, troubleshooting the system will be challenging. The record of changes will be needed to facilitate the troubleshooting process.

Examples
One example of the dynamic nature of an SDN is with a Unified Communications (UC) application that is providing voice or video connectivity to several customers. When a call is initiated, the SDN can make sure that there is sufficient bandwidth on the path to support the call. Bandwidth can be dynamically added to the voice/video class of service in the network devices to support the new call. If there is insufficient available bandwidth, the SDN can inform the application. The treatment of the new call may be under administrator control:

1. It could be denied, a form of Call Admission Control (CAC).

2. It could be allowed to proceed, with the traffic marked down to a lower class of service, or the UC server could be told that the call can proceed if it uses a lower-bandwidth codec.

3. Other calls on the path could be modified to use lower-bandwidth codecs so that all calls can proceed with a lower, but acceptable service.

In another example, a multi-server database system could have a new set of VMs brought online to handle an increased load. These VMs could be anywhere in the data center, with connectivity to the load balancers dynamically created as the VMs are brought up. When the load drops, the VMs can be decommissioned and the network resources released for other applications.

Summary
An SDN and an NCCM are somewhat similar, but the SDN provides more dynamic control of the network. The dynamics of an SDN drive a fundamental difference in its internals that make it quite different from an NCCM. It certainly seems like the functionality of an SDN supersedes that of an NCCM.