The original objectives surrounding Open Networking were that of options, innovation, programmability, cost-avoidance, and time-to-delivery advancements. Early on, we got stuck definitionally around SDN, NFV, Cloudification, and broader — as you could ask 10 different networking experts what each was, and how and when to apply — and would get 10 different answers.
Probably the best thing that happened some two to three years back was when we began to tell a BYO (bring-your-own) story around the decoupling of legacy, proprietary networking, to that of BYO-HW, BYO-OS, and BYO-Functions/Applications as ‘BYO-Open.’ This uniformly became referenced as “network disaggregation,” and this reference has stuck with most folks. All this said, what then becomes the key to ‘Open’ and allowing the BYO-components to plug-and-play nicely?
Key Ingredients to Openness
The most common answer you will receive around key ingredients to make the network plug-and-play like Legos™ would be that of Open-Standards, Open-APIs, Open-Ecosystem (vendor-neutral), programmatically configured, Open-Source (SW and HW), and on and on. The reality the service providers have woken up to with all of this ‘Openness’ is that the more open and extensible these key ingredients are, the more variability there becomes for aligning on a uniform approach. Folks are then apt to throw standardization efforts (specifications, recommendations, other, etc.) and user consortiums at this to get to alignment, but at the risk of becoming ETSI, ITU, IETF, fBellcore, and other in nature.
The Implications of Open
There’s lots to consider on this journey towards ‘open.’ With all this in play, little is discussed around the implication of how this openness will integrate with existing people, process, systems, and the current legacy network itself. Remember, the original intent of SDN, that of network abstraction and making it all look the same? This especially holds true as we contemplate the complexity of supporting the old, current, and BYO-Open at the same time.
When done well, the role of abstraction functions as a bridge between all of these disparate environments to allow service providers, data center and exchange providers, webscale companies and broader to make the transition to an Open-next, while supporting what’s in place.
Let’s dive a little deeper into what functional roles the SDN Controller shall perform. The best way to view this is that of the circle-of-life. No, not “The Lion King” melody that is now stuck in your head, but that of Life Cycle Service Automation.
Networks and related services are living entities in nature in that they have an initial birth, or instantiation. Once born, they provide biotelemetry such as data and analytics, they grow and change, they require upgrades and routine maintenance, and ultimately, overall health is dependent on how well we manage all of this and do so in a proactive and predictive manner.
For Open Networking, or legacy/current for that matter, Life Cycle Service Automation requires three core functional-capability groupings.
Realtime inventory of the network, physical and logical, as learned from the network, provides the most up-to-date representation as required for service instantiation and change, as well as for service assurance and understanding of real-time service path, topology, and correlation.
All data available from an individual network element, service, end-to-end performance, and broader must not only be collected, but analyzed with basic (threshold, if/then/action) and advanced learning algorithms. This data must be actionable to provide visibility and control (feedback-loop-actionability), as programmed by the operator or end customer, with real-time understanding of active-and-available inventory.
Automation can now tackle not just basic provisioning automation for human-hands-off, but also that which is programmable (Intent/Policy-Based, Customer-if/then/else-Defined) and beyond.
Now back to SDN, abstraction, and making it all look the same to the factory (operations, humans), consuming applications (OSS, Orchestrators, UI/UX), and the network itself (Disagg Open, Current, Legacy). The circle-of-life functional capabilities of Discover, Analyze, and Control must be normalized from the network ‘below’ via southbound application programming interfaces (API’s), and the applications and business logic ‘above,’ via northbound API’s. The Open Network Element (NE) may speak OpenFlow, RestConf, or broader. The current NE may speak NetConf, SNMP, and vast other options. And yes, the older stuff may speak Command Line, TL1, etc. It does not matter what protocol choice (language) to the NE’s, or the nouns-and-verbs of what is modeled or spoken over these; the consuming applications and business-practice-process should not care. The human operator, UI/UX built on top, OSS or Orchestration Layer needs to expect an abstraction layer that can manage the network of yesterday, today, and openness and awesomeness of tomorrow!
Programmable Networking and Open
In conclusion, this piece didn’t explicitly provide directions on how to build your disaggregated Open Network of tomorrow. However, if you are on a strategic journey to scale your operation without adding bodies, provide on-demand and custom-defined customer self-serve options, proactively manage networks and services leveraging actionable-analytics, and reduce complexities facing your own applications and business-practice-process, then the right SDN (abstraction) Control Automation solution can help. netFLEX® was built, from the beginning, to abstract-and-normalize Nextgen Optical and Legacy Transport networks, across the core Discover, Analyze, and Control functional-automation areas. The objective of making it all look the same across disparate technologies, suppliers, generations, to even include Open-Disaggregated networks, was and is the objective of LightRiver.