SDN data plane

It consists of a distributed set of forwarding network elements (mainly switches) responsible for forwarding packets. SDN uses software-based control through an open, vendor-neutral southbound interface, and the control plane and data plane are separated.

Several well-known candidate protocols for the southbound interface exist, including OpenFlow (McKeown et al. 2008; Costa et al. 2021) and ForCES (Forwarding and Control Element Separation). In both cases, the control and forwarding planes are divided into network elements, and the communication between them is standardized. In terms of network architecture design, these solutions differ in many ways.

SDN control plane

In SDN architectures, the control plane is the backbone that communicates between network applications and devices through a centralized software controller. The SDN controllers deliver relevant information to SDN applications by translating applications’ requirements into underlying elements of the data plane.

In SDN, the control layer called the network operating system (NOS), abstracts network data from the application layer. Policies can be specified while implementation details are hidden.

Typically, the control plane is logically centralized yet implemented as a physically distributed system for scalability and reliability. East-west APIs are needed to enable communication and network information exchange across SDN controllers.

SDN application plane

An SDN application plane consists of control programs that implement logic and strategies for network control. An open northbound API connects this higher-level plane to the control plane. The SDN controller translates the network requirements of SDN applications into southbound-specific commands and forwarding rules that dictate how the SDN devices should behave. SDN applications that run on top of existing controller platforms include routing, traffic engineering (TE), firewalls, and load balancing.

Example: Big Switch

Throughout the last 5-years, data center innovation has come from companies such as Google, Facebook, Amazon, and Microsoft. These companies are referred to as hyper-scale players. The vision of Big Switch is to take hyperscale concepts developed by these companies and bring them to smaller data centers around the world in the version of hyperscale networking, enabling a hyperscale architecture.

Before you proceed, you may find the following helpful post for pre-information:

1. Virtual Data Center Design
2. ACI Networks
3. Application Delivery Architecture
4. ACI Cisco
5. Data Center Design Guide

Back to basic with OpenFlow

With OpenFlow, the switching device has no control plane, as the controller interacts directly with the FIB. Instead, OpenFlow provides a packet format and protocol to carry these packets that now describes forwarding table entries in the FIB. In OpenFlow documentation, the FIB is referred to as the flow table, which contains information about each flow the switch needs to know about.

Critical Benefits of Hyperscale Networking:

1. Scalability: Hyperscale networking allows organizations to scale their networks effortlessly as demand grows. With traditional networking, scaling often involves costly hardware upgrades and complex configurations. In contrast, hyperscale networks can scale horizontally by adding more commodity hardware, resulting in significantly lower costs and simplified network management.

2. Agility: In the fast-paced digital landscape, businesses must adapt quickly to changing requirements. Hyperscale networking enables organizations to deploy and provision network resources on demand, reducing time-to-market for new services and applications. This agility empowers businesses to respond rapidly to customer demands and gain a competitive edge.

3. Enhanced Performance: Hyperscale networks are designed to handle massive data and traffic efficiently. By distributing workloads across multiple nodes, these networks can deliver superior performance, low latency, and high throughput. This translates into a seamless user experience and improved productivity for businesses.

4. Cost Efficiency: Traditional networking often involves significant upfront investments in proprietary hardware and complex infrastructure—hyperscale networking leverages off-the-shelf hardware and cloud-based technologies, resulting in cost savings and reduced operational expenses. Moreover, the ability to scale horizontally eliminates the need for expensive equipment upgrades.

Hyperscale Networking in Various Industries:

1. Cloud Computing: Hyperscale networking is the backbone of cloud computing platforms. It enables cloud service providers to deliver scalable and reliable services to millions of users worldwide. By leveraging hyperscale architectures, these providers can efficiently manage massive workloads and deliver high-performance cloud services.

2. Internet of Things (IoT): The proliferation of IoT devices generates enormous amounts of data that must be processed and analyzed in real-time. Hyperscale networking provides the infrastructure to handle the massive data influx from IoT devices, ensuring seamless connectivity, efficient data processing, and rapid insights.

3. E-commerce: The e-commerce industry heavily relies on hyperscale networking to handle the ever-increasing number of online transactions, user interactions, and inventory management. With hyperscale networks, e-commerce platforms can ensure fast and secure transactions, reliable inventory management, and personalized user experiences.

Hyperscale Architecture

Hyperscale networking consists of three elements. The first is bare metal and open switch hardware. Bare metal switches are sold without software and makeup 10% of all ports shipped. The second hyperscale aspect is Software-Defined Networking (SDN). In SDN vision, one device acts as a controller, managing the physical and virtual infrastructure.

The third element is the actual data architecture—Big Switch leverages what’s known as the Core-and-Pod design. Core-and-Pod differs from the traditional core, aggregation, and edge model, allowing incredible scale and automation when deploying applications.

Standard Chassis Design vs. SDN Design

Standard chassis-based switches have supervisors, line cards, and fabric backplanes. In addition, a proprietary protocol runs between the blades for controls. Big Switch has all of these components but is named differently. Under the covers, the supervisor module acts like an SDN controller, programming the line cards and fabric backplane.

Instead of supervisors, they have a controller, and the internal chassis proprietary protocol is OpenFlow. The leaf switches are treated like line cards, and the spine switches are like the fabric backplane. In addition, they offer an OpenFlow-integrated architecture.

Traditional data center topologies operate on hierarchical tree architecture. The big switch follows a new networking architecture called spine leaf architecture, which overcomes the shortcomings of conventional tree architectures. To map the leaf and spine to traditional data center terminology, the leaf is accessed, and the spine is a core switch.

In addition, the leaf and spine operate on the concept that every leaf has equidistant endpoints. Designs with equidistant endpoints make POD placement and service insertion easier than hierarchical tree architecture.

Big Switch hyperscale architecture has multiple connection points. Similar to Equal Cost Multipath (ECMP) fabric and Multi-Chassis Link Aggregation (MLAG), enabling layer 2 and layer 3 multipathing. This type of connectivity allows you to have network partition problems without having a global effect. You still lose your spin switch’s capacity but have not lost connectivity. The controller controls all this and has a central view.

• Losing a leaf switch in a leaf and spine architecture is not a big deal as long as you have configured multiple paths.

Bare metal switches

The first hyperscale design principle utilizes bare metal switches. Bare metal switches are Ethernet switches sold without software. Disaggregating the hardware from the switch software allows you to build your switch software stack. It is cheaper in terms of CAPEX and will enable you to tune the operating system to your needs better. It gives you the ability to tailor the operations to specific requirements.

Core and pod design

Traditional core-agg-edge is a monolithic design that cannot evolve. Hyperscale companies are now designing to a core-and-pod design, allowing operations to improve faster. Data centers are usually made up of two core components. One is the core with the Layer 3 routes for ingress and egress routing. Then, you have a POD, a self-contained unit connected to the core.

Intra-communication between PODs is done via the core. A POD is a certified design of servers, storage, and network grouped into standard services. Each POD contains an atomic networking, computing, and storage unit attached directly to the core via Layer 2 or 3. Due to a PODs-fixed configuration, automation is simple and stable.

Hyperscale Networking and Big Switch Products

Big Tap and Big Cloud Fabric are two product streams from Big Switch. Both use a fabric architecture built on white box switches with a centralized controller and POD design. Big Clouds’ hyperscale architecture is designed as a network for a POD.

Each Big Cloud architecture instance is a pair of redundant SDN controllers, and a leaf/spine topology is the network for your POD. Switches have zero-touch, so they are stateless. Turn them on, and they boot and download the switch image and configuration. It auto-discovers all of the links and troubleshoots any physical problems.

SDN controller architecture

There are generic architectural challenges of SDN controller-based networks. The first crucial question is, where are the controller and network devices split? In OpenFlow, it’s clear that the split is between the control plane and the data plane. The split affects the outcomes from various events, such as a controller bug, controller failure, network partitions, and the size of the failure domain.

You might have an SDN controller cluster, but every single controller is still a single point of failure. The controller cluster protects you from hardware failures but not from software failures. If someone misconfigures or corrupts the controller database, you lose the controller regardless of how many controllers are in a cluster.

Every controller is a single fat fingers domain. Due to the complexity of clusters and clustering protocols, you could implement failures by the lousy design. Every distributed system is complex, and it is even more challenging if it has to work with real-time data.

SDN controller – Availability Zones

The optimum design is to build controllers per availability zone. If one controller fails, you lose that side of the fabric but still have another fabric. To use this concept, you must have applications that can run in multiple availability zones. Availability zones are great, but applications must be adequately designed to use them. Availability zones usually relate to a single failure domain.

How do you deal with failures, and what failure rate is acceptable? The failure rate acceptance level drives the redundancy in your network. Full redundancy is a great design goal as it reduces the probability of total network failure. But full redundancy will never give you 100% availability. Network partitions still happen with fully redundant networks.

Be careful of split-brain scenarios, where one controller looks after one partition and another looks after the other partitions. Big Switch overcomes time with a distributed control plane. The forwarding elements are aligned so a network partition can happen.

Hyperscale Architecture: Big Switch distributed routing.

For routing, they have the concept known as a tenant router. With the tenant router, you can say that these two broadcast domains can talk to each other via policy points. A tenant router is a logical router physically distributed throughout the entire network. Every switch has a copy of the tenant router’s routing table that is local to it. The routing state is spread everywhere. Traffic needs to cross no specific layer 3 points to get from one layer 2 segment to the other.

As all the leaf switches have a distributed copy of the database, all routing takes the most optimal path. When two broadcast domains are on the same leaf switch, traffic does not have to hairpin to a physical layer 3 points.

You can map the application directly to the tenant router, which acts like a VRF with VRF packet forwarding hardware. This is known as micro-segmentation. With this, you can put a set of applications or VMs in a tenant, demarcate the network by the tenant, and have a per-tenant policy.

Hyperscale networking revolutionizes how we build and manage networks in the digital era. Its ability to scale effortlessly, provide agility, enhance performance, and reduce costs makes it a game-changer in various industries. As data volumes grow, organizations must embrace hyperscale networking to stay competitive, deliver exceptional user experiences, and drive innovation in a rapidly evolving digital landscape.