The (R)evolution of Software-Defined Networking
A few years ago a bunch of smart people at Stanford and Cal got together and came up with a pretty interesting notion–why not break the bond between networking hardware and the software that does all that mystical switching and routing? Separate the “control plane” from the “data plane” and a couple of interesting things would occur. First, switches and routers would become commodity items since they no longer need any specialized intelligence. Second, a whole new era of network applications would evolve as the tight grip of the networking vendors was slowly released. An interesting theory, but in practice Software- Defined Networking (SDN) is working to find its equilibrium point.
Manually-Defined Networking is No Longer an Option
One thing SDN has done is make the industry realize that manually configuring switches and routers is no longer an option. Manual configuration couple d with the static nature of traditional network topologies such as VLANs are simply not capable of meeting the needs of dynamic cloud computing environments. While SDN may not yet have reached its original goal, it has proven that virtualizing networks on top of existing physical infrastructure can be done, and it can be done through automation and at scale. New tunneling protocols such as VXLAN (Virtual Extensible LAN) provide secure multi-tenant networking within data centers. And through software automation enterprises are now able to provision their own wide area network services, eliminating the long deployment cycles normally associated with carriers.
From Software-Defined to Service- Defined Networking
Software automation of network services is rapidly transforming how networks are deployed and managed. Tasks that once were the purview of network architects can now be handled by network administrators through execution of trusted software, resulting in higher reliability and lower costs. But, as cloud computing has shown, users ultimately want to consume services, not technology. This requires that the details of the technology, whether physical or virtual, need to be hidden from the user. There are several initiatives underway that focus on high-level service orchestration–OpenStack® being one of the most notable open source efforts. But underneath the covers a lot of intelligence is required to translate the definition of a service into a series of policies and actions that must be applied across a wide variety of technologies from any number of vendors. This requires a combination of powerful discovery, topology, state, abstraction and transactional capabilities, like those found in CPLANE’s Dynamic Virtual Networks orchestration platform. Without these capabilities the promise of SDN will fall short. To effectively utilize the underlying network infrastructure as an elastic resource there must be visibility into its current operational context. Only then can things like quality of service, bandwidth management, service level adherence and application-aware policies be realized.
Network Function Virtualization and SDN – Either, Or, Both?
Automation of core services such as switching and routing is essential to making the network viable for dynamic cloud services. But what about all that “other” stuff? Firewalls, load balancers, intrusion detection, packet inspection, etc. A couple of years ago several carriers and telecommunication companies formed the Network Function Virtualization (NFV) initiative which is now housed under ETSI (European Telecommunications Standards Institute). NFV is focused on defining standards for describing virtualized network functions (VNF) so they can be reliably and predictably deployed, typically at the network edge, via service chains or network graphs. A question quickly arises as to where SDN stops and where NFV starts (or vice versa). Isn’t a VNF just another “network service” that can be deployed via SDN? There’s really not a clear answer to that question. While SDN isn’t focused on how services are defined, it does address the issue of how they are deployed. This is where the importance of the “service-defined” networking concept comes into play. Reliable orchestration, from definition to deployment to service assurance, of VNFs is absolutely essential. Knowing where VNFs can be deployed, how to deploy them and their impact on the current network state is critical.
The Edges are Getting Fuzzier
Typically the edge between the data center and the wide area network (carrier provided or otherwise) was pretty clear. We had great acronyms like CE and CPE that helped us define where that edge was. But the edge is now not so distinctly defined. Customers are now thinking about extending the value of traditionally “core” network protocols such as MPLS all the way to the top-of-rack inside the data center to take advantage of quality of service features. This makes the insight into the entire network topology even more critical–for both SDN and NFV.
End-to-End Orchestration for Workload Agility and Mobility
Clouds are great. They enable fast, flexible and agile IT services. Application programmers can now think about application features, not network dependencies. Network architects can focus on networks as a service. IT managers can deliver reliable, cost effective services. As we move beyond device virtualization and start thinking about service virtualization and mobility via containers and other emerging capabilities, one thing is clear. The boundaries for workload agility and mobility are quickly disappearing. Network services must be “end-to-end” to match the highly distributed nature of the next generation of applications. While still in its early days, SDN is poised to reshape the network into a responsive, dynamic resource.