Data centre networking: what is SDN?

The recent contexts have shown that enterprises needed to take a different approach regarding their digital transformation and its prioritisation. They’ve experienced the need to run new configurations and operations remotely on their infrastructure. This quickly showed the benefits of automation solutions to run those changes from few central locations, which highly facilitated the task of systems and network admins. During the last decade enterprises have also been migrating to the cloud looking for quickly scalable infrastructures that the cloud service providers did take care to build and manage. Those network infrastructure capabilities in addition to a strong virtualisation approach, were key drivers to consider Software-Defined Networking (SDN) as a principal building-block of a wholly software-defined data centre infrastructure.

This blog is one of a series covering SDN and the journey to model-driven cloud infrastructures. Here, we are going to talk about software-defined networking, its evolution and the key benefits it brings to the data centre and cloud industry leveraging the concept of intent-based networking. Let’s begin with what SDN is.

What is SDN?

SDN is a network architecture model that adds a level of  abstraction to the functions of network nodes (switches, routers, bare metal servers, etc.), to manage them globally and coherently.

The decision-making part of the network device (control plane) is separated from its operational part (data plane) and deported to a single control point called the SDN controller, which manages the whole in a coherent way. This controller allows “network programmability” hence the name “Software Defined”. The concept was standardised by the Open Networking Foundation (ONF) which was founded in March 2011 to promote it as well as the development of OpenFlow.

OpenFlow is one of the protocols used by SDN controllers, which was of interest and worked on by research centers; notably the University of Stanford (US) and its research center (ONRC) who published the first OpenFlow specifications in 2009.

Why did we need SDN

While IT teams’ mission is to build and manage IT infrastructure and applications, it should ultimately serve key business drivers for their organisation, such as the following :

• Efficiency
• Growth
• Agility
• Scalability
• Security.

The non-SDN networks as we knew them in the data centre space, showed major drawbacks and led to a lot of IT operational challenges vis-à-vis the needs of modern IT infrastructures. These challenges and other new demands raised by organisations from different industries oriented the thinking towards SDN.

Here are some of those challenges and aspirations and how SDN comes to address them :

Innovation gap

A significant gap was observed between the innovations available in the application servers and storage space and those available in the world of network infrastructures. It varied from virtualization, to automation and hot migrations to mention few. The gap has been addressed by providing new networking functions (NF) and solutions to legacy and persistent problems. The control and forwarding planes separation with centralized network-wide visibility and policies, makes network configuration and changes more consistent.

Customisable network infrastructure

Customers have little choice in selecting networking components, hardware, or software for their specific use case. Historically, the network OS has been tied to the hardware and lacked well known interfaces. This was the case while new feature sets (applications) had been directly coupled with the full network OS stack. With its openness, SDN enables choice and experimentation at different layers of the networking stack. This is possible by providing a space to user applications and the possibility to pick and choose hardware on the underlay.

Complexity

Networking can be very prescriptive with many network details to be exposed to and understood by IT consumers. With few (if any) abstractions to hide those prescriptive details, it becomes complex to accurately and easily translate the application requirements on the underlying network infrastructure. Usually when an IT admin asks the network team to connect two new hosts, this develops into details like which vlan for each host, QoS, L2 or L3 to the Top-Of-Rack Switch…etc.

By introducing network applications at the top of the SDN architecture, it became easier to describe the network needs which then can be programmed and distributed by the control plane.

Control and automation

Automatic and rapid network configuration (agility) is a major request from business applications’ teams to shorten their time to market. The operations teams also need it to improve their control of the infrastructure. Today’s (often) manual network setup procedures take a long time to be executed. This was addressed by introducing programmable multi-tenant networks and simplified intent based interfaces to express the forwarding behavior. With a new orchestration layer, configuration and deployment became possible in minutes instead of days and troubleshooting required less manual involvement.

Network virtualisation

As with system infrastructures, customers wanted the possibility to manage their own virtual network itself instantiated on a shared physical infrastructure. SDN brought the virtualization to the network with virtualised networking services without the need for VRFs and MP-BGP. It also did to the operating system with its desagregation from the physical hardware.

Multitenancy, Multi-Clients

Sharing the same infrastructure between several clients is a key requirement for managed service providers and large organisations. This was already the case with VLANs and VPNs. Multitenancy is also widely covered by SDN thanks to overlay technologies like VXLAN and GENEVE.

Scalability

As server port density kept growing, It became inadequate to keep up with the significant increase in the size of data centre. This included limitation of the number of MAC addresses, many links being inactive, transport of multicast streams, etc.). Growing the infrastructure easily as needs changed and significantly was no more a “nice to have”. By leveraging “standardized” common off-the-shelf switches and pushing network configurations from central SDN controllers, it became easy to quickly add new switches and provision their configuration in minutes.

Network multi paths or Multipathing

Using efficiently all the available links on switches became a necessity to support the increase of downlink throughputs. Spanning-tree (which has been widely used in local networks) was already known to disable part of the links. With the phenomenal growth of  server density, things like Multi-chassis EtherChannel (MEC) and later ECMP (Equal Cost Multi Path) with CLOS architectures became foundational paths to address the variety of multipathing scenarios.

Virtualisation was one of the key abstraction capabilities that SDN brought . This was by supporting multiple, isolated virtual networks to keep pace with servers compute and storage. We saw a virtualisation movement in the network industry similar to that which had taken place in the application server industry. SDN continued to evolve at different layers and saw a number of distinct variants.

What is next?

In the next blog, we will give an overview of SDN architecture, its layers and its main components.

The next posts in this series will cover:

• Data centre networking : SDN fundamentals
• Data centre networking : SDDC
• Data centre networking : OVS and OVN
• Data centre networking : SmartNICs