INTRODUCTION
SDN (Software Defined Networking) as been from the start tightly associated to functions virtualization (NFV) nevertheless OpenDaylight (ODL) has been developing away from the shadows of NFV. Even the first version of ETSI MANO has not considered ODL SDN Controller important enough to be part of its NFV MANO Service Model. Recent critics have emerged recently to criticize ODL of being too complex and not be adapted for a new model where Digital Transformation should be faster track to costs optimization and monetization of functions virtualization.
In that perspective, can we just say that ODL-based SDN separated from the NFVO irrelevant in nowadays market?
---------------------------------------------------------------------------------------------------------------------------
In today’s market, we have been largely associating both SDN (Software Defined Networking) & NFV (Network Functions Virtualization) together. For the simplest reason that they are both taking advantage of the hardware and software separation. Nonetheless, SDN and NFV differs fundamentally in their roles, while remain complimentary, that they would be orchestrating/automating and allow the scaling of a Virtual Service Infrastructure. SDN (Software Defined Networking) evangelize the possibility of automating the networking pipes that either establish Datacenter to Datacenter connectivity using networking virtual circuits (VXLAN and VTEP and more recently EVPN) leveraging either legacy technologies (PWE3, MPLS, IPv4 or IPv6 routing protocols..) at the benefits of Service Providers, MNOs or Carriers and even enterprises as mini-telcos.
Although, the first phase for NFV and related NFVO (Network Functions consists in instantiating VNFs (Virtual Networking Functions) or/and CNFs (Containerized Networking Functions) manually and provide the first step of virtual services monetization. In a second phase, automation and customer portal is moving things in a step further for differentiation and increase customer loyalty and further monetization of virtual services. Then, SDN is naturally used to establish a virtual link between VNFs, CNFs and PNFs (Physical Networking Functions) using Service Function Chaining. Due to complexity reasons, SDN requirements have also been associated to Service Orchestration functions aka NFVO, which can either be provided through a proprietary approach (Juniper Contrail, ADVA Ensemble Orchestrator, Cisco NSO, etc..) or a combined proprietary/Open-Source with Cloudify or RIFT IO. Some market players such as Lumina Networks or Inocybe Technologies (now bought by Kontron) were keeping things separate : leveraging SDN capabilities with ODL while leaving NFVO to others. Putting an additional pressure on Service Providers, which then endorse the full responsibility of making them a seamlessly working solution.
The association of NFVO supporting SDN-like features is mainly due to the necessity to connect Virtual Services together, once they are instantiated, in order to formalize a coherent Service chain. While making sure to virtually and logically customer service chains segregated one from the others.
THE GREAT PROMISES OF ODL
For Service Providers and Network Operators, there was a large consensus of interests leading to OpenDaylight to be the Holy Grail for the automated creation, change but also the tear-down of service circuits leveraging both dynamic routing capabilities and legacy transport mechanisms such as PWE3, MPLS-TE and now MPLS-TP services or as plainly as IGP or EGP routing paths. The mission critical aspect was to use ODL (OpenDaylight) as an overlay (Control Plane) mechanism meant to better organizing the underlay (DataPlane) functions while maintaining a certain level of required segregation with the Management Plane information.
Besides the creation and deletion of service circuits, OpenDaylight is expected to support a series of important functions that will be necessary to support both legacy and next-generation capabilities side by side without neglecting one aspect against the other. Alongside the Service Function Chaining, Traffic Engineering with BGP-LS and PCEP, PNF Management and Change of configuration, Zero Touch Provisioning, Virtual Bridging leveraging both OVS and OpenStack or Kubernetes, Automatic Bandwidth scheduling and shaping. Thus, with the most recent versions of OpenDaylight such as Fluorine then Containers Orchestration Engine or CoE, OTN and ODTN support with Transport PCE were very important for future networks leading towards 5G, DOCSIS 3.1 or 4.x, G-Fast, etc... It is equally important to never forget that OpenDaylight was and still is an important piece of element linking our bad habits in Networking notably with IPv4 and our necessary changes towards IPv6 in the automation requirements between the old world and the new.
Despite the great expectations that the market had for OpenDaylight, there were also some great unknowns notably about simplicity, scalability, manageability and Edge Networking and disaggregated Service Intelligence.
Simplicity:
With today’s larger and larger networks, we often talk about thousand of endpoints that might be associated with the rapid turn-up and creation of service circuits. With the perspective of Mobile and IOT Networks, the magnitude of endpoints to connect can easily become a spiral out of control. Therefore, the requirement for simplicity and convergence for APIs structure and southbound protocols use across vendors to prevent against lock-in strategies and a better and simpler collaboration between vendors.
2. Scalability:
Indeed, despite its great potential, OpenDaylight is still a technology that generates a lot of questions as per how many devices can be supported upon a single OpenDaylight SDN Controller ?
The number of 400/500 devices, often considered as a valid denominator but will obviously depend on the number of derived and expected features (SFC/TE/ZTP/OCE, etc...). Once again, next-generation networks with Mobile and IoT networks combined with autonomous driving and any connected objects. This directly questions the need for a scalable response adapted to legacy service offering and a next generation capability that will boost in the number of elements linked to an ODL SDN Controller from thousands to millions and trillions if we imagine that wholesale situations involving two or more large Service Providers.
The best example of this would be the remarkable work put together by the MEF (Metro Ethernet Forum) with E-Access and E-Transit Carrier-Ethernet and upper layer services.
3. Manageability:
With compelling functions associated with SDN and OpenDaylight, this will require some newly defined management requirements that once again will take in consideration the legacy needs with typical management protocols such as SNMP and NETCONF. But, to address new generation type of networks, this will require some new mechanisms such as Prometheus, RedFish API but also mechanisms such as
Service OAM (Y.1731) that could be associated with the ME (Managed Entity) supporting either OpenFlow, Netconf or other typical southbound protocols.
As they are and will remain key functions for network infrastructure, SDN Controllers would themselves require some redundancy capabilities due to their compelling roles to the dynamic nature of Service Orchestration and OSS/BSS layer functions. Disaster Recovery capabilities combined with real-time OS to support the applications heartbeat pings from the applications to decide which instances of SDN is in better shape to respond to queries and demands should provide a workable approach.
4. Interoperability:
Considerations for interoperability for SDN and ODL shall be considered at on multiple fronts but let us limit the approach on just a couple. The first element is Yang. Indeed, it is now the de-facto standard language for Network modeling and favored by all major SDOs: IETF, IEEE, OCP, ODL, etc... Once again, the interpretation of RFCs or recommendation from SDO have been proving counter-productive to make sure that across the board hardware and software vendors could use both the same model and the same standard APIs. Another aspects are the constant evolution of all the layers comprised in the full SDN/NFV model. To say a quick word about this, the MEF has been doing a tremendous background work with several operators with MEF 3.0 and LSO, in order, to deliver a workable set of APIs structure to allow operators and enterprises to envisage taking advantage of virtual services while involving different ISO layered services from Layer-1 to Layer-7.
Another example is that Operators and even enterprises, have been working towards service models that function only if consistency can be satisfied across the board. By definition, operators and enterprises work on the principle of mitigating the risks by selecting at least two vendors to satisfy their product & service requirements. Therefore, market actors are dependent on providing a consistent service model (Service functions/Management, etc...) across PNF, VNF and CNF solutions to support Netconf and a workable and evolvable Yang model. Just this simple fact is already a wide challenge with a simple vendor to put together and maintain over time. Now, a very daunting task when it involves several HW & SW vendors are involved. It also brings a natural dependency towards the IOS aka NOS (Network Operating Software) where vendors are naturally favouring their own SDN and NFVO solutions compared to work with Open Source alternative.
Evolution is obviously a key element to consider, notably at the NFVi layer. We know how often OpenStack releases (Canonical, Wind River and plenty of others); Kubernetes & Docker, VMWARE, Microsoft Azure and related stacks evolve. Even internal components of these solution stacks evolve independently such as OVS, NSX, Docker and Flannel, Kubernetes and even APIs. Additionally, examples of acquisitions such as IBM buying Red Hat makes the whole decision process and further perspectives even more difficult for business stakeholders and executives, due to natural reinforcement of lock-in strategies.
When we consider the entire context of interoperability, we now have a picture of moving plates that are evolving independently while maintaining the necessity for them to work together. The NOS aspect is possibly the most complex to apprehend. Indeed, while all parts are moving : OpenStack/Kubernetes, ODL itself, OVS, Flannel but also the NOS solutions have to evolve while considering the other plates but also
in consideration of the vendor market strategy and necessity to maintain itself some relevance and independence against Open-Source.
5. Edge Networking and disaggregated Service Intelligence
With a new era leading towards large and distributed networks and Mobile Networks that will naturally see a time where Hybrid Service Chains will be common. The concept of Hybrid Service chain calls upon the fact that not all applications can be virtualized and that some functions/services will require some highly specialized PNFs. Indeed, OTN (Optical Transport Networks) and even ODTN (Optical Disaggregated Transport Networks) will pave a new wave of possibilities that will facilitate the transition towards 5G networks, Datacenter connectivity and Operators trans-continental connectivity. However, it will also bring the necessity to make PNFs, VNFs and CNFs to work tightly altogether under a given umbrella of key and core business and infrastructure functions such as MSDO (Multi-Service Domain Orchestrator) aka E2E Orchestrator / SDN Controller for Orchestration and Automation capabilities / OSS & BSS functions and Service Management.
Therefore, it will require that some of these functions to be centralized and others to be disaggregated in an attempt to have them working hierarchically but also built and linked on per regional or PoP perspectives. This hierarchical requirement will naturally fall on Orchestration and SDN Controller. Some actors in the market have already started to work on these aspects such as Lumina Networks / Inocybe Technologies (now Kontron) (ODL), Cloudify (NFVO), Sedona Systems, RIFT (NFVO), RedHat (NFVi & ODL), Frinx (ODL) and others are obviously very active.
HOW IS SDN ON THE SERVICE ORCHESTRATION FUNCTION SIDE ?
Let us venture on the side of Virtual Services orchestration aspects for a moment.
A lack of rapid monetization, technology understanding and too fast-evolving technologies have been the key reasons of the market slow adoption of virtual services. However, reduced complexity, improved stability, evolution and faster tracks towards revenues have been tremendous reasons to consider NFV and NFVO compared to SDN-centric ODL deployments.
While deployments of ODL have been stalling and rendered extremely complex, before the recent market roller coaster called SD-WAN. Most of the recent successful deployments have been mostly based on the capacity to leverage and monetize virtualize resources via the means of Service Orchestration aka NFVO (Network Function Virtualization). While at the NFVO layer, there is a consensus towards TOSCA (Topology and Orchestration
Specifications for Cloud Application) which is often map to take full advantage of the Yang modelled structure provided by Cloud applications. Although, TOSCA as an Open-Source innovation has been chosen as the ONAP model driven orchestration. On its opposite side, Tail-F (acquired by Cisco) is offering a similar approach but with a proprietary twist.
Besides orchestration, Open-Source oriented solutions such as Cloudify and RIFT.IO have been bringing SDN capabilities alongside TOSCA in order to combine both orchestration and Service Chaining Functions in one approach. Making ODL as a separate SDN Controller less relevant and bringing an additional level of useless complexity without an n: 1 offering. Let us not forget that generally NFVO functions are often associated with VNFM (VNF Manager) meant to manage the VNFs lifecycle and eventually the licenses on a per application basis.
CAN SD-WAN AS AN OVERLAY-BASED TECHNOLOGY DEFINE ITSELF AS SDN ALIKE ?
It is a very large debate but I would prefer the notion of NaaS (Network as a Service). The very notion NaaS has been considered mostly to describe the tunnelling mechanisms used to connect either different Service Provider domains or to identify tunnels used to carry/groom customers traffics across a given network domain between enterprise branches. Various technologies have been associated to this NaaS definition, notably: Transport mechanisms across Service Provider domains with Carrier-Ethernet and MEF services, EVPN and even MPLS-TP / Grooming tunnelling mechanisms such as BGP, IGP, MPLS-TE and VXLAN and VTEP but also EVPN, which to me is an hybrid technology between being a Datacenter centric and a transport service function.
Therefore, when we consider the notion of SDN and the recent ubiquity of SD-WAN, without stretching ourselves too far we can easily say that SD-WAN could be easily be associated with both the two notions of NaaS and SDN technologies. Which can combined since it can be orchestrated automatically either centrally or disaggregated and define itself as a overlay technology with possible underlay capabilities also. There are even examples in the market today where both SD-WAN Conductor/Controller would connect either to NFVO using RestFul API and leveraging a Netconf/Yang model. Or, eventually to support themselves some Orchestration capabilities, alongside, the possibility of offering SFC capabilities as well.
Thinking about it more carefully, SD-WAN and MPLS connecting seamlessly together using BGP, peering would naturally be an accelerator to guarantee what MPLS and GMPLS/MPLS-TP has failed years ago to deliver: Tunnels or LSP stitching.
CONCLUSION
Our market has been rather slow on adopting a certain pace to implement and leverage SDN/NFV altogether as a merged force to optimize Capex/OPex costs but also to accelerate the monetization of virtualized services either VM (VNFs) or Container-based (CNFs). The need for simplicity and manageability without compromising legacy technologies at the network (underlay and overlay) and management layers. This prove, in my view, that the separation of NFV and SDN will not be sustainable options in a near future especially considering the transition that our market is currently undergoing towards greater complexity and wider service perspectives where 5G being one of them but certainly not the only one. I almost called this article **Is ODL-SDN dead ?** but on the contrary I believe that the need for ODL/ONOS aka SDN functions is a necessity in the market but not separated from NFVO for Orchestration and Automation I see limited possibility to monetize SDN on its own since it is considered as a dependency to serve and connect PNFs, VNFs and CNFs.
However, I see almost limitless possibility for SDN capabilities alongside Service Orchestration function as a key element to compliment orchestration and automation possibilities and accelerate access to Intent-Based Networking and Orchestration but as a single combined function and not separated or compartmentalized.
Written by Luc-Yves Pagal Vinette