The Open Networking Foundation defines SDN as an emerging architecture that “… decouples the network control and forwarding functions enabling the network control to become directly programmable…”
A subset of the SDN architecture states that it should be programmatically configured. This is something that really interested me when first reading about SDN and thinking about the possibilities of being able to configure, manage, secure, and optimise network elements at the touch of a button.
Please bear with me throughout this blog post, as there is no getting away from the various technologies and acronyms in use that leverage SDN.
It’s not just the Open Networking Foundation that references the programmable network/infrastructure. The Cisco Evolved Programmable Network (EPN) is an evolution of the well known IP Next-Generation Network (IP NGN), and improves the network architecture by uniting physical and virtual devices to form an end-to-end, unified multilayer fabric for an open programmable and elastic network. Using APIs across and between all layers, network operators can automate services across both multivendor and traditional environments.
Cisco Open Network Architecture
With the ever increasing demand on networks from today’s mobile, cloud and video-based traffic, operators need solutions that can handle this and also manage the huge number of events occurring in real time. This is where infrastructure programmability really comes into the fore.
So what exactly is infrastructure programmability? Fundamentally, it is leveraging the programmatic interfaces and capabilities of products and solutions to either exert control, think configuring a device, and/or extract information, which is only limited by how open that particular device is.
That’s all good and well, but what does this mean exactly, and how can it be used? It can mean something as simple as leveraging an API on a device to more efficiently configure a device, or writing a python script to automate a repetitive task, or it can be as complex as enabling a 3rd party system to access the information from a network device to enable new applications or services. Although the possibilities are not limitless, the scope for exerting control and extracting information through infrastructure programmability is huge, and arguably only limited by creativity.
SDN plays a significant role within network programmability as it opens up the APIs that in turn enables external applications to control the functions of a network element. This is the main function that opens up the possibilities to create new services and capabilities.
Cisco has some fantastic offerings in the Network/Services abstraction space, namely APIC, UCS-D, and NSO. These SDN controllers are placed in strategic control points in the network and are thought of as the brain of the network. They are able to relay information to network elements via southbound APIs and can communicate with applications or higher layer control programs via northbound APIs.
Cisco Network Services Orchestrator (NSO) enabled by Tail-f provides end-to-end automation to design and deliver services faster. It lets a network manager easily create and change services without lengthy customer coding or service disruptions. Using strict, standardised YANG models for both services and devices, NSO lets you automate all of the multivendor devices that may be in a given environment. The most impressive thing about this product in my mind however is that users are able to change and reconfigure these models whenever they want, and without any time consuming and error prone manual effort, leading to a reported 90 percent less coding.
The main architectural component of the Cisco ACI solution, the Cisco Application Policy Infrastructure Controller (Cisco APIC) is a centralised application-level engine for physical, virtual, and cloud infrastructures that is designed for automation, programmability, and centralised management. It exposes northbound APIs through XML and JSON, and provides both a command-line interface and GUI which utilise the APIs to manage the fabric, based on Nexus 9000 Series Switches and the Cisco Application Virtual Switch, holistically. Cisco Unified Computing System (UCS) is also a programmable infrastructure component for the data centre which provides an API to the installed software stack for identification, monitoring, configuration and control, all through the UCS Manager.
Then there is the APIC EM (Enterprise Module), sitting between applications and the network infrastructure, acting as a conduit through which you can automate tasks, orchestrate workflows, policies, and simplify operations. The controller translates the business policy directly into network device-level policy and automates the deployment, compliance checking, and enforcement of network policies across the network. Simply put, it hugely simplifies enterprise networks for the next generation of IT. This is exactly what I imagined when I first read about SDN!
If, like me, you are somewhat sceptical of the things claimed in data sheets, then don’t take mine or their word for it. If you are a lover of technology and appreciate the advancement and simplification that these products bring, you will love playing with them in Cisco dCloud.
Authors
