“May you live in interesting times!” goes a Chinese curse! And interesting times, while challenging and marked with uncertainty, have immense potential waiting to be realized. The SDN canvas, dotted with hopeful startups, open source communities and networking behemoths edging their way in (seemingly a little too early, without giving startups a chance to have had a good run in the new market), is brimming with opportunities and promises to accelerate service velocity through automation and orchestration, while being cost-effective.
The famed SDN definition
To fast-forward through Software Defined Network (SDN) evolution to this date, SDN started off with a compelling vision to centralize network control plane in a network controller, and strip off intelligence from the distributed data plane, to provide administrators an environment that is generic, open, extendable and centrally manageable. With few takers to rebuild control plane solutions from scratch, the vision has evolved to accelerate deployment of end user applications in a secure and scalable manner.
Control Plane Approaches
OpenFlow’s imperative and OpFlex’s declarative model are the two main control plane approaches in the SDN market.
In the imperative model as in OpenFlow, the controller fully instructs routers and switches on how to move packets based on application requests, with no control intelligence embedded in the distributed data path network elements. The imperative model suffers from the drawbacks of centralized controller becoming a bottleneck and single point of failure in the network.
In contrast, the declarative model implemented in OpFlex, allows for more distributed intelligence. The controller sets a central policy based on the application needs but gives power for network nodes to determine how best to execute the said policies and meet the application needs. In this approach, the network can sustain itself even if the controller fails, allowing for better availability and resiliency. The network can also scale better as the controller is no longer the sole brain of the network. Cisco’s Application Centric Infrastructure (ACI) framework is based on the declarative model.
Open Standards and Development Communities
Open communities such as Open Networking Foundation (ONF), OpenStack and OpenDaylight have played a pivotal role in bringing together IT, cloud and telecom service providers, compute, storage and network equipment vendors & silicon providers, technologists, developers and researchers, to streamline efforts in formulating open standards and following through with open source development, promotion and adoption of SDN.
Open Networking Foundation (ONF) is accredited with introducing OpenFlow, the first SDN standard and vital element of the open SDN architecture.
OpenStack – Unlike ONF which is limited to networking and is a standards community, OpenStack encompasses compute, storage and networking (refer figure below), and is a developer community focused on cloud environment solutions. OpenStack software is an open-source cloud operating system that helps control large pools of compute, storage and networking resources throughout a datacenter, allows administrators to manage resources through the OpenStack dashboard, and empowers application users to provision resources, through a web interface, transparently orchestrating across compute, storage and networking blocks.
OpenStack is architected to provide flexibility as businesses design their public/private clouds, with no proprietary hardware or software requirements and the ability to integrate with legacy systems and third-party technologies.
OpenStack has multiple official programs targeted for specific architectural blocks such as Nova (Compute), Swift (Storage), Quantum replacing earlier termed Neutron (Networking), Heat (Orchestration) etc. to provide plugins to deliver each of these blocks as a service, for e.g. Network as a Service in the cloud environment, and thus the value proposition of programmability in the SDN/SDCC paradigm, though in a cloud environment.
Figure – OpenStack Architecture – Sourced from openstack.org
OpenDaylight is an open platform that any enterprise or provider can use today, to enable SDN and NFV through programmability of networks of any scale. The software is combination of components and includes a fully pluggable controller, interfaces, protocol plug-ins and applications.
SDN Architecture
Towards realizing the SDN vision, Open communities and foundations comprised of business users, vendors, technologists and researchers, have arrived at a basic SDN architecture [captured in below figure], which consists of 3 main layers – Application, SDN controller and Network Infrastructure.
The SDN controller which houses the intelligent control plane, interfaces between user services & applications and the network on which they run (latter denoting the distributed packet-forwarding data plane in an SDN environment), with the goal of abstracting the network, so that application developers can tune the network to meet application needs, without having to understand the inner workings of the network.
Figure – Basic SDN architecture – Sourced from Datacenterjournal.com
Northbound APIs are used for communication between the controller and application layer, to enable efficient orchestration and automation of the network to align with needs of different applications, while Southbound APIs are used between the controller and infrastructure layer.
To demystify the term ‘orchestration’, as in a musical orchestra, this function in the SDN architecture ensures that various resources (for e.g. compute, storage and network blocks in a data center) are controlled by a common entity to align with or complement each other and work synergistically to meet the business application needs.
Let us now see how OpenStack, OpenFlow and OpenDaylight fit into the SDN architecture.
OpenStack allows for orchestration in a cloud environment to deliver networking-as-a-service, through OpenStack Quantum APIs that I discussed earlier in this article.
OpenFlow is a open-standard Southbound communication protocol that enables OpenFlow SDN controller to add and delete flow tables entries in OpenFlow switches and routers, and thus control flows for optimal performance and eventually make the network more responsive to real-time traffic demands. More to this, when I explore OpenDaylight in the next section.
OpenDaylight is a complete implementation of SDN and I think the below framework summarizes it best. Let me also repeat how I introduced OpenDaylight earlier in this article. OpenDaylight is an open source software platform that implements a pluggable controller, northbound programmatic & southbound implementation interfaces, protocol plug-ins and applications, that anyone can use today (that’s right, today!) to evaluate, commercialize, and deploy SDN (and NFV – the topic I’ve saved for a future blog post). The controller is contained within its own Java Virtual Machine, and can be deployed on platform that runs Java.
OpenDaylight Framework – Sourced from OpenDaylight.org
A Deep Dive into OpenDaylight components
In this section, I’ll go over various protocols and stacks that you would hear of in the SDN context and see how they fit into the SDN architecture, based on the OpenDaylight framework [refer figure above].
Northbound Interfaces
Northbound APIs are the most critical in the SDN environment, as the value of SDN is closely tied to the innovative applications it can potentially support and enable. Given that they must support a wide variety of applications, a variety of possible interfaces currently exist to control different types of applications via an SDN controller. Consolidation of these interfaces is yet to happen, given that SDN usecases are still evolving.
OpenDaylight supports OSGi framework and bidirectional REST for northbound APIs. The OSGi framework is used for applications that will run in the same address space as the controller. In comparison, REST (HTTP based) APIs are used for applications that do not run in the same address space or even necessarily on the same machine, as the controller.
Northbound APIs are also used to integrate the SDN controller with automation stacks such as Puppet, Chef, Salt, Ansible and CFEngine. As we saw earlier, they also help interface with orchestration platforms such as OpenStack.
SDN Applications that can be optimized via Northbound interfaces include load balancers, firewalls and other software-defined security (SDSec) services.
Southbound Interfaces
The southbound interface is capable of supporting multiple protocols for (1) managing physical and virtual network elements, (2) operating on the control plane to allow for controller driven programmability, or communicating network state/events and (3) configuring data forwarding plane on distributed physical and virtual network elements. Networking equipment vendors implement one or more protocols in the above categories, to add SDN capability to their legacy equipment, thus ensuring investment protection for their existing installed base, during the move to SDN.
NETCONF, OF-CONFIG using YANG data models, SNMP and XMPP operate in the management plane and allow for network device configuration and monitoring.
I2RS, PCEP, BGP-FlowSpec and BGP-LS are protocols that operate on the control plane and either update routing tables in a programmatic way, allow for creation of MPLS-TE tunnels from a central controller and communication of computed LSP paths to network nodes, automate distribution of traffic filter lists for DDoS mitigation or help export link/topology/tunnel states through BGP to the controller.
OpenFlow (v1.0, v1.3), LISP and OVSDB are protocols that allow the controller to configure flows tables and influence the forwarding behavior of physical and virtual devices.
SDN Controller
As discussed earlier, the controller is the key arbitrator between network applications and network infrastructure, and forms the crux of the SDN network. To be able to effectively centralize the intelligent control plane, the controller typically implements base network functions to provide host/node service, flow service, topology service, path service to setup and manage a path based on specified constraints, multi-tenant network virtualization, network statistics, security, centralized monitoring etc. In addition, it provides a collection of pluggable modules in the Service Abstraction Layer to support a variety of southbound interfaces.
No comments:
Post a Comment