Even as programmable networks serve current needs for service providers, significant progress in writing standards for virtualization and vendor offerings is already underway.
In the third part of this Telco Transformation Q&A, Level 3 Communications' Claudio Scola provides an overview of the shift towards the virtualization of network functions. Scola, director of global product marketing for Core Network Services at Level 3 Communications Inc. (NYSE: LVLT), also spoke about the importance of Southbound APIs, which converse with routers, switches and the SDN controllers in the infrastructure layer of a network.
Scola discussed Lifecycle Service Orchestration and SD-WAN for network-as-a-Service in the first two Q&As. (See Scola: Lifecycle Service Orchestration Key for Level 3 and Level 3's Scola Discusses SD-WAN for NaaS.)
Telco Transformation: What breakthroughs have been achieved in the virtualization of the network elements of WAN transportation, and their integration with SDN, that makes it a viable alternative to MPLS?
Claudio Scola: I am not against dedicated hardware -- especially if they support open APIs such as NETCONF and YANG. As an industry, we are still reliant on CLI software adaptors, but at least they exist and allow us to move forward with network programmability. I think some network functions might be better on a dedicated piece of hardware for now.
[In regards to virtualized open source infrastructure] we have started to build out early deployments and proof of concepts for commodity hardware based virtualized infrastructure for SDN-based networking. We are starting to see a range of good network functions become available as virtualized network functions (VNFs). Many of the big brands that make dedicated routers, firewalls, switches and WAN optimization controllers have released virtual versions of their products.
SD-WAN is a technology that leverages SDN and NFV and wraps it into a WAN solution. Vendors like Versa, Nuage Networks and VeloCloud are making good progress with NFV-based solutions that can build into the service provider’s network. Up until recently, these solutions were mainly CPE OTT based solutions aimed at the self-managed market, but now there are carrier-grade solutions that have true flexibility built into the solution from the ground up. SD-WAN has been a key trigger for service providers to start building their NFV infrastructure.
The big challenge right now seems to be orchestrating it and service chaining the functions together.
For large-scale deployments in multi-vendor environments, we want to see solid progress on API standards for end-to-end controls.
There're many standards within the open source community -- ETSI, TM Forum and MEF and good progress is being made. The Metro Ethernet Forum's UNITE, OpenLSO and OpenCS initiatives are useful initiatives that we are supporting. Carrier grade outputs from these allow the industry to start building NFVi MANO environments instead of using dedicated hardware.
For next-generation virtualized infrastructure, the MEF's OpenCS Initiative is a great hub for tracking and pushing use cases based on E-CORD for virtualized DC (data centers), MANO (for NFV), OpenDaylight (for packet WAN) and SD-WAN. So we are getting closer to modernizing the infrastructure and standardizing the southbound API that is trying to talk to it.
TT: What is the experience so far with OpenFlow standards in flexible resource allocation for WANs? How does it cope with the sunk costs of legacy infrastructure?
CS: There is very little experience of OpenFlow in the WAN sector. OpenFlow traditionally lives in the DC dealing with the switching fabric. There is so much more to SDN than OpenFlow, but people often marry the two concepts together. We leverage open standards where possible at Level 3, and currently, we use several southbound control protocols.
The key thing for us is that we have standard APIs and protocols. The OpenDaylight controller is progressing well, and so maybe we will see OpenFlow featuring more on the WAN.
As for sunk cost of legacy infrastructure, we are not throwing away equipment until it is end-of-life. As long as we can create an abstracted YANG view of that infrastructure and control it within Level 3's Adaptive Network Control, we can extend the life of this equipment and bring it into the context of dynamic and orchestrated services while we build trust in the next generation of virtualized open-source infrastructure.
East-West APIs enable service orchestration, at the control and management layer, among a network of service providers partners. Programmability of the networks enables the East-West service orchestration.
MEF's Lifecycle Service Orchestration Architecture
The MEF's Presto
is the interface to the Southbound APIs that extend control to the infrastructure layer. The LSO OpenCS initiative
will leverage standard APIs and orchestrate virtualized network functions
The following use cases become possible with Southbound APIs:
- The DC (Data Center) or a PoP (Point-of-Presence), based on the E-CORD design, enables hyper-scale switch fabric with commodity hardware and open source software
- NFV controls the functions customers want to run in the DC/PoP
- The packet WAN utilizes OpenDaylight platform for network control
- Concurrently, the optical network layer also needs to be orchestrated
- SD-WAN would likely run with NFV within the DC
- Cloud interconnects and 5G access for IoT are other useful use-cases
The first five use cases provide the rudiments for a virtualized hyper-scale PoP. So we appreciate the work that the MEF's LSO initiatives, such as OpenCS, are doing to help get the standards ready for next-generation infrastructure. However, that does not stop us from using dedicated hardware in the meantime to build LSO-based dynamic, agile and assured services.
— Kishore Jethanandani, Contributing Writer, Telco Transformation