The speed and agility of business information systems have forever been increasing, while the surrounding constructs around networking have been unable to keep up with the speed of change.

The resulting change has been a complete rethink of the way the network is built and operated with SDN.  This can be summed up in three key areas:

1. Separation of the Network Control and Data Planes

Software-defined networking (SDN) has driven a separation of the control plane from the data plane.

With traditional networking, these functions reside in the network switches and routers. The control plane is the information base where reachability of the hosts and sub-networks is contained and is exchanged via routing protocols such as Border Gateway Protocol (BGP).

With SDN this information is now retained in virtual functions called SDN Controllers that can be scaled out as the network grows.

The data plane intelligence has moved from the interfaces of the routers and switches (end of row or top of rack) to the compute host where the application resides.

Whereas with traditional networks the equipment stored the network intelligence and rules for all the network hosts within their domain, with SDN this information can be simplified and pushed to the very edge of the network.

The simplification comes from the requirement to only program the individual applications' necessary network rules they need to operate.

This also simplifies the security of the application. Whereas with traditional networking a centralised firewall would be deployed with complex rules ensuring exactly who could talk to whom for all applications at the site, SDN breaks the security rules into simple per application pieces (micro-security) and pushes this to the host where the application resides.

With traditional networking the upgrade cycle for equipment has been based on one of three events; lack of capacity, lack of a software feature or end of lifecycle.

In most cases it's the need for a new software feature that's forced a hardware refresh cycle on equipment that has adequate capacity.

If the control and data plane intelligence is removed with SDN, that existing network hardware can be unburdened via the removal of the configuration and requirement for complex network functions.

The result is in a longer lifecycle for the hardware and better investment profile, with any replacement being aligned with traffic growth and support lifecycle rather than prematurely enforced.

2. Centralised Network Configuration

Traditionally the network has been configured on a per node basis, for each router or switch in the network an engineer has connected to that device and set a local configuration.

This configuration includes the network wide configuration information (routing protocols) so that the device can partake in the overall network plus the localised configuration for the ports, which can include local addressing, quality of service and security rules.

This device-by-device configuration process becomes a laborious task whenever changes are implemented, it also becomes one of the key areas for network misconfiguration whereby the change is implemented incorrectly or a device is missed from the update.

SDN alleviates these issues by centralising the application specific network configuration into a policy system. The network operations team create the network wide and application specific policies that match their business rules and store these centrally.

When a new application is deployed the SDN solution will check the policy conditions for the application and send the correct network configuration via templates to the network end-points.

As the application traffic is contained within a virtual network (overlay tunnel) there is no networking configuration changes needed in the underlying network devices (switches) in the path.

They are set with basic forwarding information to let the traffic flow as the network intelligence has been lifted into the SDN domain where it is automatically controlled by the centralised policy system and the SDN controllers.

3. Overlays and Underlays

SDN lifts the application traffic into virtualised network tunnels, commonly called overlays, which are created whenever a new application is deployed on the network. These overlays are managed by the SDN (policy and SDN controllers) and persist as long as the application is instantiated.

The benefit of this is that if the application moves; say due to a host (server) failure or the need to serve the application from another data center arises, then the overlay tunnels move in sync with the application without the requirement for network reconfiguration or operator intervention.

The overlays contain all the network programing needed for the application, be that specific security rules or traffic priorities and are managed centrally as templates in the centralised policy system. This makes auditing and changing the network conditions simple.

For instance if a new version of the application requires a change in the firewall rules for the application traffic, this can be added to the template on the policy engine and then pushed out to the application hosts and network routers by the SDN solution.

With the application-specific intelligence residing in the network overlays, the network feature set (the running configuration) for the underlying network hardware can be simplified; in many cases to basic forwarding functions.

This de-loads the existing switches and routers and prolongs their usable life in the network; this simplification will also increase the stability of the network devices, as the less actions they need to take on the traffic the less chance there is of a software bug occurring.

This transition to network overlays and the use of the underlying network hardware purely as a transport path has resolved the process bottlenecks that had appeared between the IT application and the IP networking worlds. With SDN these two parts of the IT stack now work in concert to deliver the applications when and where the business requires.