NFV's Major Movements
Following the initial rush of excitement a few years back, the NFV community has stumbled into the quicksand of operational reality and, despite the best efforts of industry bodies, willing operators and sometimes desperate vendors, it hasn't yet been pulled free. (See Time for a Telecom Reboot.)
But every communications network operator knows that network functions virtualization (NFV) is part of its future, so an NFV implementation strategy is needed. The major problem facing operators, though, is that each one has a unique network and different challenges: Yes, there are many commonalities between them, but each operator has a network with different legacy systems and each one has a different end goal.
But there are a couple of challenges that are universal:
- Business models: Many of the major challenges for operators come in the form of operational processes, business models and business relationships (how to engage with the suppliers of software and hardware for their virtualization plans). This is a challenge that outgoing Vodafone group head of Network Virtualization, SDN and NFV, David Amzallag, has articulated on a number of occasions but which isn't the main focus of this article. (See Vodafone: The Pricing Isn't Right.)
- Interoperability: Network operators need to be able to deploy virtual network functions (VNFs) from any developer, be sure they will run seamlessly over the installed NFV infrastructure (NFVi) and interact seamlessly with the installed MANO (management and orchestration) software. (See Together, We Can Build the Telecom 'App Store'.)
If that latter challenge sounds relatively simple, it isn't… currently it's not possible -- the NFV sector is still a set of development islands and the interoperability that operators need seems a long way off.
So where do operators turn for help to solve this problem?
Well, there's no shortage of industry bodies and groups offering up a broad range of help, from advice to specifications to platforms and blueprints. And then there's the vendor community, which has a large number of silver bullets ready to whip out at any given moment. It's just that there's no gun to fire them (yet).
But on the technology planning and implementation side, there are a few key areas where operators can engage with collaborative bodies and independent organizations to further their strategies, particularly when it comes to multi-vendor testing and deciding on an all-important MANO (management and orchestration) strategy. There are also some key starting points for operators as they consider their NFVi (NFV infrastructure) options.
So let's look at some of the key considerations for network operators, including testing and the options available for those seeking an existing MANO that they could deploy.
Third-party testing has long been a key element in any network operator's technology decision-making processes and there's no reason for that to change. NFV testing, though, is relatively new and the labs that undertake such tasks are, in many ways, developing the blueprints for NFV tests as they engage with the industry.
That's certainly the experience of the team at EANTC, which been undertaking multiple NFV interoperability tests on behalf of the The New IP Agency (NIA). (See 2016 NIA-EANTC NFV Interoperability Test Report and Light Reading Publishes Unique NFV Interoperability Test Report.)
(FYI, the next NIA test undertaken by EANTC will be showcased at the upcoming Big Communications Event (BCE) in Austin, Texas. (See New IP Agency Plans Test for NFV Interoperability.)
Other bodies have also undertaken multi-vendor tests, including CableLabs, ETSI (which holds "plugtests") and OPNFV, which has undertaken assessments in partnership with the University of New Hampshire Interoperability Lab. (See Outstanding Results for the First ETSI NFV Interoperability Test Event, OrbTV: ETSI NFV ISG Plugtest Results, CableLabs Sets Up NFV Interop Lab and OPNFV Nearing Commercial Deployment.)
The MANO, or management and network orchestration, segment of the ETSI NFV ISG's original architecture was once a sorely neglected space -- for sure, some sort of MANO package could be sourced from commercial technology vendors, but such a move leads to the frantic waving of the "interoperability" and "open" flags.
So what are the non-commercial vendor options? Prior to 2016 there was little for operators to choose from (Open Baton being the exception -- see below) but that lack of options was wildly corrected in 2016, with the arrival of three new efforts, two of which have since joined forces to reduce the dilution of effort.
Here's a brief look at the key offerings:
OSM includes an impressive list of technical features, including native support for multiple virtual infrastructure managers (VIMs) including OpenStack, OpenVIM and VMware Inc. There is support for OpenDaylight and Floodlight OpenFlow-based SDN controllers, but also a plugin model to facilitate addition of future VIMs and SDN controllers, for added flexibility. The software is currently deployed in test labs and was used in the ETSI Plugtest. (See OSM Quick on First Release Trigger.)
The Open-O group, which had the weight of China Mobile, China Telecom, Ericsson, Huawei and Intel behind it, was always active in forging collaborative efforts, having been part of the OPNFV's Plugfest last December and working with the MEF to determine how Open-O fits into its Lifecycle Services Orchestration (LSO) effort. At the Plugfest, Open-O was able to successful integrate with OPNFV's Colorado release. (See OPNFV Nearing Commercial Deployment.)
Then in February this year, a major "MANO Marriage" was announced as Open-O joined forces with the ECOMP development spearheaded by AT&T. (See below.)
AT&T always said it was keen to share its code and other major operators were attracted to AT&T's efforts, with Orange and Canada's BCE collaborating on the effort. (See Orange to Focus Polish ECOMP Trials on Residential vCPE , Orange Preps ECOMP Trial in Poland, Broadens AT&T Collaboration and Bell Canada to Test AT&T's ECOMP.)
That sharing strategy took a big leap forward early this year as AT&T announced that ECOMP would be offered up to the open source community via the Linux Foundation. (See Will ECOMP Be the Alpha MANO? and Amdocs: Expect ECOMP Adoption Boomlet.)
That announcement was shortly followed by the combination of ECOMP and Open-O to form a new group called ONAP (Open Network Automation Platform), which is now focused on how to integrate the code developed by the ECOMP and Open-O teams. The first software release is expected in the fourth quarter of this year. (See MANO Marriage: ECOMP, OPEN-O Converge as ONAP and ONAP Makes Splashy ONS Debut.)
Chris Rice, senior vice president of Domain 2.0 Architecture and Design at AT&T, noted in February that he expected more operators to join ONAP, and India's Reliance Jio duly obliged, while Ciena added to the growing list of vendor participants. (See Reliance Jio Joins ONAP and Ciena Jumps on ONAP Bandwagon.)
The growing expectation in the market is that the formation of ONAP will lead to further harmonization of MANO efforts to create a single resource that all operators could turn to -- that would need to involve a merger of ONAP and OSM.
The situation with NFVi is not as clear cut: Whereas in MANO there are collaborative efforts with an open source ethos, the NFVi territory is more product-oriented.
The ETSI NFV group developed a blueprint for an NFVi and, from that, some 'hardened' open source-based options are available from the likes of Red Hat and Canonical (Ubuntu), while VMware is also a popular selection for network operators. (See VMware Makes Major MWC Splash, Swisscom Picks Red Hat for OpenStack, Virtualization , Kontron, Canonical Team on Integrated OpenStack Platform and Etisalat Activates NFV Telco Cloud in UAE.)
The OPNFV initiative, though, is a collaborative industry effort with some major backers: The expectation is that it would offer up an NFVi framework upon which operators could develop their most suitable infrastructure. Its most recent release, dubbed Danube, delivers integration between the NFVi/Virtual Infrastructure Manager (NFVi/VIM) and the OPEN-O system that is now part of ONAP. (See OPNFV's Danube Dubbed 'Milestone' Release.)
Obviously, what operators really need is the ability to be able to select the NFVi and MANO that best suits their current situation, future plans and resources and then be confident that they can either deploy third-party (or in-house) VNFs with the confidence that all the piece parts will interoperate and enable them to focus on delivering profitable applications and services to their customers.
As noted, the industry is still a long way off that point but, five years after the promise of NFV was first dangled like a digital carrot in front of their eyes, there needs to be concrete action in 2017 that makes that virtual promise a hard and fast reality. MANO harmonization and the development of a single API that can bridge the NFVi and MANO platforms look like they would be very welcome developments.
— Ray Le Maistre, , International Group Editor, and Carol Wilson, Editor-at-Large, Light Reading