Network operator took service logic from ONAP and repackaged it, now preparing to upstream what it developed.

March 29, 2018

6 Min Read
CenturyLink to Open Source NFVi Orchestrator

LOS ANGELES -- Open Networking Summit -- CenturyLink is preparing to contribute part of its NFVi orchestration process to the open source community, even though the operator isn't yet ready to join ONAP, which is the largest orchestration open source project.

Adam Dunstan, vice president of SDN/NFV Engineering for CenturyLink Inc. (NYSE: CTL), explained in a presentation here and in an interview that his team has taken a bit of service logic out of an Open Network Automation Platform (ONAP) module and repackaged it as part of its NFV orchestration process, calling it Victor, and now intends to release that into open source. Once the legal details are sorted, the contribution will likely go into ONAP -- which CenturyLink has contributed to before. (See ONAP Adds Verizon, Claims De Facto Title.)

Because CenturyLink is charting its own path and develop its own tooling, however, the company likely won't be plunking down the dollars required to formally join ONAP anytime soon, Dunstan says. (See CenturyLink Touting New MVP.)

"We continue to consider it but we haven't used a lot of the tooling and so if you are not really using the tooling then it limits the benefit of joining, so that's why we haven't," he says in an interview here. "ONAP is a big complex system and putting aside opinions on the whole thing, CenturyLink already has a big complex system, getting it all to fit together is a challenge. Also we now have the Level 3 systems. Going off and adding another whole thing doesn't make sense. We have to get much more granular about what we do."

Figure 1: CenturyLink's Adam Dunstan presents Victor to ONS audience. CenturyLink's Adam Dunstan presents Victor to ONS audience.

As ONAP's proponents note, it is a modular system and can be consumed that way, but CenturyLink is getting even more granular than that. It extracted what it calls the Service Logic Interpreter from within one of the modules, Dunstan says, and took it out of OpenDaylight and back into Java to create Victor.

Victor is a microservice that runs inside containers and its job is "to do one thing and one thing well - spin up something automatically and let the system know that happened, and then his job is done," he explains. A separate system handles domain management and the two are compared for consistency through an automatic process.

"What an operator does is, they go and create a service template or a service graph or service definition. It's all done graphically and it looks very similar to what ONAP did," Dunstan says. "It uses the same tooling, and that lets you go and create the service model. What we did in addition to that, that service model generates a basic UI and the Web services associated with it."

That latter part is important because it solves another problem that CenturyLink and other operators face when their network teams have to work with their IT teams on back-office processes. Too often, Dunstan says, the network guys speak in their own language to IT folks, whose expertise doesn't include understanding things like MPLS and labels. Making things work between the two organizations can slow things down, but Victor provides an abstraction for all of that.

"The network guys create the service model and this graphical programmatic tool. It then creates the web service, documents the web services automatically, creates a simple UI for it, and I can hand it to the IT guys," he explains.

Next page: Reducing complexity to move forward faster

Reducing complexity to move forward faster
CenturyLink has chosen to break up the orchestration process and not attempt to use one master orchestrator for everything, Dunstan says. Instead it has created separate domain orchestrators, one for VNFs and another for physical network functions, as well as a third for third-parties, such as transport and more. Then there is a master orchestration system above the three domain orchestrators. (See CenturyLink: Kill Complexity to Speed NFV.)

"The logic behind this was not that you couldn't build one system, you just can't have enough meetings to get it to work right," he says. When one part of the organization had completed its work, another part might have gotten distracted by something else and getting everyone on the same page proved too difficult. "When the system has so many cross-dependencies, you can't get there. So we decided that we would break it up this way. We don't do PNF and VNF together. That was a deliberate decision that took quite a long time to get through."

PNF and VNF orchestrators are fundamentally different, since the one controls an existing piece of hardware and the other addresses something that doesn’t yet exist, Dunstan explains.

"But adding all of those things to bring a VNF into existence in the existing PNF infrastructure, which is already one of the world's largest Tail-F implementations, was going to be a massive effort, disrupting lots and lots of customer telemetry," he says. "So we determined to separate it."

Light Reading is bringing together all of the key players in the automation revolution for the first time at Automation Everywhere on April 4 in Dallas. Join us as we tackle the business and technology challenges behind driving network automation. The event is free for communications service providers -- register today!

CenturyLink also spent considerable time deciding how to handle VNF onboarding, and ultimately chose not to create a single uniform interface that replaces vendor interfaces, when those have their own appeal.

"It didn't make sense, because the people that bought Palo Alto, for instance, like the Palo Alto UI, so why should we replace that," he said. "You are further chasing breaches and bugs. So we decided to not follow that path. When we do VNF integration, we bring the VNF into existence, we do all the connectivity associated with it, we do some basic set-up and then we hand it over to the specialist who deals with it."

In the case of a virtual firewall, CenturyLink gets it operational and then hands off to the customer with an IP address, or offers configuration services associated with that for customers who prefer that level of assistance.

Dunstan came to CenturyLink with its acquisition of Active Broadband, and arrived as the company was struggling with the second version of its Programmable Services Backbone architecture, which was its early venture into virtualization dating back to 2012. The first version was VMware-based but wasn't a complete stack, which lead to the second version, an OpenStack-based system. (See CenturyLink's ABN Buy Is Software Harbinger, CenturyLink: Building the Case for NFV and Inside CenturyLink's NFV/SDN Strategy.)

"I looked at this thing and we came to the conclusion within three-to-four months that we had built something too complicated," he says. "And so because the scope was so broad, these guys had built virtualization to run anything but the mission that the business needed was NFVi. So we went back and rebuilt again, and we went specifically for that purpose. In doing so, we were able to simplify the proper system we built significantly [over] the previous version and make it much easier to get into production and manage."

— Carol Wilson, Editor-at-Large, Light Reading

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like