Editor's note: This is the second half of a two-part series on understanding SDN basics. In the first part, we...
explained the concepts of centralized control and network programmability. Here we explore network orchestration and network virtualization.
One of the key goals of SDN is to implement flexible networks that can be dynamically provisioned. While the main cornerstones of SDN are centralized control and network programmability, network virtualization and network orchestration are just as important.
Why network orchestration?
With SDN, the network can be provisioned in an orchestrated way along with other IT components like servers, storage and applications. The big concept is that a software-defined network can be automated. Automation allows services to be provisioned quickly and at scale with reduced chance for human error.
SDN orchestration tools have emerged from startup Anuta Networks and Alcatel-Lucent's Nuage Networks. These tools target cloud providers that need to automate the creation of network services for their customers, although each company attacks the problem in a different way. Anuta's solution focuses on working with the network infrastructure many providers already have in place, while Nuage introduces a distributed software router and overlay network to create multi-tenant friendly network containers.
While the needs of a cloud provider might seem distinct from that of an enterprise network, the fact is that enterprise networks face the same complex application deployment challenges that cloud providers do. While full SDN orchestration solutions for the enterprise haven't appeared yet, it's worth noting that as network vendors produce controllers, they highlight their partnerships with other vendors. The trend is for controllers to interoperate with a wide variety of network vendor equipment, including application delivery controllers. The long view is that fully automated network provisioning that integrates with broader IT orchestration will be a normal function for all networks, no matter what type of organization they serve.
Why network virtualization?
Much of the technology discussed so far leads to the implied goal of network virtualization. When a network is virtualized, the physical components of the network have been abstracted so users no longer have to think of the network in terms of specific routers, switches or even ports. Instead, a common physical network is shared by a variety of virtual networks. While hardly a new idea, a rudimentary example of this is 802.1Q virtual LANs paired with Q-in-Q tunneling. MPLS is another tried-and-true technology that has been used to achieve this sort of network virtualization. Despite being a well-known and mature technology, Q-in-Q and MPLS tend to be service provider technologies, and they are not often deployed in data center environments.
In SDN paradigms, network virtualization tends to be accomplished using overlays like Virtual Extensible LAN (VXLAN), Network Virtualization using GRE (NVGRE) and Stateless Transport Tunneling (STT), possibly in conjunction with OpenFlow. In an overlay network, traffic that is part of a particular virtual network has an identifying wrapper placed around it that isolates it from other virtual networks sharing the same underlying physical network. While not strictly required, an SDN controller can be used to identify all of a virtual network's endpoints, instructing switches where and how to encapsulate traffic inside of the overlay, maximizing the efficiency of endpoint-to-endpoint communication.
While an overlay is more of a cloud provider tool at this time, it could find its way into enterprises that are weary of building out separate physical environments for their lines of business or environments but don't want to support the complexity of virtual route and forwarding (VRF) or MPLS. Overlays are a potential way to securely provide logically separated virtual networks on the same physical infrastructure. Coupled with an SDN controller, deploying and maintaining such virtual networks could be an easily manageable task.
Often lumped into the network virtualization discussion are those vendors that have virtualized their appliances to run on a hypervisor. Strictly speaking, a virtual firewall or application delivery controller is not the same as SDN, although these virtualized network components could well play into an SDN infrastructure. Be careful not to let a vendor with a virtual appliance (and nothing more) claim it is selling SDN. While dovetailing nicely with SDN, what virtual appliance vendors are providing is more accurately described as network functions virtualization (NFV); NFV standards work is being done inside of ETSI for those wishing to follow this phenomenon more closely.
Any business seriously evaluating SDN should keep in mind that the technology is an evolving one. SDN is not mature, and it lacks standards or even a definitive reference model and means different things to different vendors. This has caused market confusion that has grown in lockstep with the buzz around it. At least partially in reaction to this, the OpenDaylight project (ODL) hosted by the Linux Foundation was formed by a consortium of SDN vendors to homogenize the SDN marketplace a bit. I believe ODL is a project to watch because it covers the entirety of the SDN stack, including network applications, orchestration, a controller, northbound APIs and a southbound abstraction layer. As ODL matures and the codebase begins to settle, it could well represent a common baseline for all SDN solutions.
About the author:
Ethan Banks, CCIE #20655, is a hands-on networking practitioner who has designed, built and maintained networks for higher education, state government, financial institutions and technology corporations. Banks has also been a host of the Packet Pushers Podcast, a technical program that covers practical network design, as well as cutting edge topics like virtualization, OpenFlow, software-defined networking and overlay protocols. He is the editor for the independent community of bloggers at PacketPushers.net and can be followed @ecbanks.