Software-Defined Networking (SDN) is a revolutionary approach to designing, building and operating networks that aims to deliver business agility in addition to lowering capital and operational costs through network abstraction, virtualization and orchestration. Conceptually, SDN decouples the control and data planes, and logically centralizes network intelligence and control in software-based controllers that maintain a global view of the network. This enables more streamlined policy-driven external control and automation from applications, which ultimately enhances network programmability and simplifies network orchestration. As such, SDN-based design allows for highly elastic networks that can readily adapt to changing business needs.
The first wave of SDN deployment focuses on functionality, but with many innovations and enhancements in data center interconnect technologies, it is time to take a fresh look at more efficient, higher performance SDN deployment options.
This blog series focuses on SDN solutions for data centers, which is often an essential part of building cloud, whether it is private cloud or public cloud. The three blogs in this series will cover:
Three different deployment models dominate today’s SDN landscape:
In this model, the SDN Controller uses a south-bound device control protocol to directly communicate policy or forwarding table information to the physical and virtual switching and routing devices. OpenFlow is the most commonly used protocol, and some of the early SDN architectures are based on OpenFlow to decouple control plane from network devices.
Examples of SDN implementations based on this model are BigSwitch’s Big Cloud Fabric, Open Networking Lab(ON.LAB)’s ONOS, and Open Daylight (ODL). Beyond OpenFlow, ONOS and ODL also support other southbound protocols such as Netconf and SNMP for device configuration and management.
Essentially for every new flow, all the devices that this flow traverses potentially needs to be programmed to handle the proper flow operations. This model requires the network devices to be OpenFlow-aware, which can sometimes be a challenge when you have legacy networks or a mixture of various generation of network devices.
Many customers have an installed base of networking equipment that is not yet OpenFlow-enabled, and doing a network-wide upgrade may not be an option. Overlay approach of SDN deployment model came into being to bring SDN/network virtualization to these customers without requiring forklift network upgrade that can be both expensive and disruptive to business services. Overlay SDN has been the most commonly seen architecture, and mainstream SDN solutions such as VMware NSX, Nuage Networks (Now part of Nokia) VSP, PLUMGrid ONS, OpenContrail and Midokura MidoNet all primarily follow this model.
As the name indicates, in overlay model, logical networks are established through tunnels between endpoints, and these tunnels are overlaid onto an existing physical network. The intelligence about multi-tenancy, network and security policies are pushed to the network edge. Some of the most commonly used tunneling protocols include Virtual eXtensible LAN (VXLAN), Network Virtualization using GRE (NVGRE), and Generic Network Virtualization Encapsulation (GENEVE). In case of VXLAN, the tunnel endpoints are known as VXLAN Tunnel End Points (VTEP). The physical network, or the underlay, becomes the “core” network and its functionalities can potentially be simplified to providing high-performance IP connectivity between these VTEPs. An overlay SDN controller will primarily communicate with the VTEPs, which oftentimes are the virtual switching and routing device residing on servers.
Overlay SDN can be deployed to achieve network virtualization and automation without requiring upgrades of physical networking equipment, more specifically, the network devices that are NOT the VTEPs. Despite its pluses, overlay SDN introduce added complexity when it comes to managing both the overlay and underlay, and correlating information from both layers during troubleshooting.
There are two common ways to deploy VTEP: software VTEP in virtual switches, normally running in server hypervisors; or hardware VTEP in Top of Rack (ToR) switches, and there are tradeoffs between these two approaches. Software VTEP is flexible and conceptually simple, but can impact performance as well as raise CPU overhead on edge devices due to the packet processing associated with the relatively new tunneling protocols that not all server Network Interface Cards (NICs) can offload from CPU. This can be even more pronounced when the applications themselves are virtualized network functions (VNFs) in Network Function Virtualization (NFV) deployment. Hardware VTEPs can often achieve higher performance but pose added complexity on the ToR switch since the ToR switch needs to be VM-aware, maintain a large forwarding table, and performance VM Mac address or VLAN to VXLAN translations.
Beyond the virtualized environment with VXLAN/NVGRE/GENEVE, there are often Bare Metal Servers (BMS) or legacy networks that can only use VLAN, or North-South traffic that goes out to a VPN network or the Internet. In those cases, using a software VTEP gateway adds extra hop or potentially performance bottleneck and the best practice is to use the ToR that the BMS is connected to as hardware VTEP.
There are other proprietary SDN solutions in the market, such as Cisco Application Centric Infrastructure (ACI), Plexxi and Pluribus. With these solutions, the SDN controller and the SDN switching and routing elements are often tightly coupled. This category of SDN solutions are not as open as the above two, and pose limitations for ecosystem vendors to integrate with them.
In the next blog in this series, I will provide an overview of some new innovations that overcome some of the issues associated with the overlay and Openflow deployment models, and can make these SDN deployment more efficient, flexible and streamlined.