Lean NFV: Accelerating the adoption of NFV and the deployment of 5G

What is Lean NFV and Business Drivers for Lean NFV?

Hema Kadia  – What is Lean NFV, and what are the key business drivers of Lean NFV?

Dan Pitt  – So let’s talk about NFV – Network Functions Virtualization – was a movement started and launched actually, next month will be eight years, as of 2012, what was called the Layer123 SDN and OpenFlow World Congress, and it kept that name for quite a few years. Then it became the SDN and NFV World Congress, and this year, next month, it will be just a Layer123 World Congress. It was launched in October of 2012, in Darmstadt, Germany, as an Industry Specification Group, an ISG of ETSI, the European Telecommunications Standards Institute. And it really set the industry on notice that for the telecom industry to move faster and serve customers better, not have industry sort of service-specific infrastructures, they had to virtualize what they did, and so that started the whole movement to virtualized network functions.

So instead of buying a set of appliances and individual appliances for every function, they would virtualize the functions that they needed. And they’d run them in commodity servers, in data centers. And it was a brilliant and great idea. And ETSI has served the industry extremely well by doing it. And yet, eight years later, it’s not as widely deployed as we would have liked, so the driver for lean NFV is that the communication service providers really have to cloudify and virtualize their internal operations and the way they offer services to their customers. And we think of mainly enterprise customers and industrial customers, but we also offer services to consumers. So they have to do this.

If we look at the future of those operators, 5G is a huge component of their future. And they’re really betting on it. And it’s bringing the promise that we have all hoped for the kind of services that we would be able to access. But 5G is going to need SDN and NFV to be successful, and we see that coming. But if we can’t deploy NFV easily, we’re going to have a hard time deploying and introducing 5G with novel services and not just a few basic connectivity services. And finally, the key essence, the fun part about NFV, is VNFs, the virtualized network functions. And it says virtualized – it can be containerized. We’re not distinguishing between VMs and containers here. And I remember doing a study a few years ago about the need to standardize something about VNFs. The answer was no; there’s no way we can standardize it because they all run in different environments. And so I was hoping for an explosion in third-party authored VNFs to meet certain niche opportunities in the market, what people would want to do certain functions; that hasn’t really happened.

We don’t have a write-once, run-anywhere VNF marketplace yet. We’re going to need this because of the novelty of services that customers are requiring that have to run on a common infrastructure from the telecom service providers. So that’s, that’s sort of what’s driven. This effort is called lean NFV. And it really is just a simple way to implement and deploy NFV: network functions virtualization. It’s important for the future of the industry. But we have to be able to deploy it more simply. And so we’re bringing a sort of an architectural openness to it in a simpler fashion, minimally invasive than the points that you see on here. So it can be added, and it is being added, and it’s now an industry movement that’s going on.

And I’m grateful for the opportunity to share it with your viewers today, Hema, because I think the industry will find it beneficial.

How Lean NFV Relates to ETSI NFV Architecture

Hema Kadia – The two key drivers that I take away from this particular slide are how lean NFV can really help or ease the NFV deployment and create an open VNF marketplace. So, let’s compare the two architectures in the context of those two business drivers. I guess you have ETSI NFV architecture, almost seven or eight years back, that we have defined. Of course, there is a new addition to that with a service-based architecture from a 5G perspective, but still, overall, this is the architecture that it started with. And if now we bring in Lean NFV, let’s compare how they look side by side and how, exactly, with the Lean NFV, we can accelerate the deployment of existing NFV deployments.

Dan Pitt  – Sure, the ETSI architecture has been instrumental in promoting the understanding of NFV as a concept. And so, by defining these components here, they really taught the telecom industry to think more like the computing industry.  And so that’s useful. What we have on the left side is the ETSI NFV and MANO – Management and Orchestration – picture, and we have the different kinds of components that you see there. And we have the VNFs, the virtualized network functions, and the element management systems, the EMSs, and so on. And then, of course, we have on the right the NFVO and the VNFM and the VIM, now, on the right side of the left-hand picture.

Now on the right side, we have the picture of Lean NFV. And it’s an implementation of this that really simplifies how these things are integrated. So we have the three main components of the, you know, the Infrastructure Manager, the VIM, the VNFs, and the NFV Manager, which is, you know, a combination of the VNF Manager and the NFV Orchestrator (the NFVO). What people tried to do initially was build these all very tightly and create standards and bilateral interfaces among every pair of devices. And consequently, NFV Management got embedded in the computing infrastructure. So it’s very hard to change. And new features require changes in the pairwise APIs because there are all these pairwise APIs. And that’s, I think, what has held back the independence of the VNF. So we have done a couple of things on the right side. First of all, instead of having really integration different for every infrastructure example, and every VNF, we’ve simplified it by making something called the Key-Value Store a universal integration mechanism: everything interfaces to that. And it’s steady, and it’s constant.

And they don’t have to negotiate interfaces among pairs of components. And with that, by keeping the NFV-specific features out of the VIM, we can now really translate and implement the NFVO, the VNFM, and the VIM as a series of independent what we call microcontrollers. These are code modules that do certain functions, and you can create them, create them once, and apply them. And they really exchange state with the VNFs and the EMSs and the compute and switching infrastructure, simply through the control plane interfaces of the Key-Value Store or the KVS. So it’s an implementation that says we’re going to do these as independent modules that have a universal integration mechanism. And it’s very simple. And I think it will proliferate not only VNFs as an open marketplace but also the microcontrollers, as you see on the right side, whether they’re service chaining, you know, placement, launching, these functions that are important for deployment. This is not theoretical stuff, Hema; this is how you get services out there. 

Hema Kadia  – From a VNF vendor perspective, basically, what we are alluding to is that they can bring in their VNF. And it may only need integration with Lean NFV. Lean NFV would really be the key integration point, whether it’s northbound, southbound, or east-west, based on the different components in the operator ecosystem. This is one way of addressing the interoperability issue that we didn’t see in the market when we were looking for NFV adoption. 

Dan Pitt  – Right, it would be the interface to the Key-Value Store, it would be the API, it’d be a universal API to a Key-Value Store. And it certainly allows a telecom operator to go shopping and to build an infrastructure confident that any of the functions they want, either as microcontrollers, as VNFs, or CNFs, will plug into it. So it’s going to simplify their investment, it’ll speed their deployment, and I think it’s going to foster growth in very cool VNFs and microcontrollers. 

Lean NFV Differentiator – Key-Value Store (KVS)

Hema Kadia  – We know the industry perspective, what is Key-Value Store. But let’s understand from a Lean NFV perspective how we are leveraging Key-Value Store in the context of NFV deployment. 

Dan Pitt  –  The Key-Value Store has been around for a while; it just stores keys and values. You can get the information you need by looking up the key and extracting the value, but you can write the value; you can read the value. And it’s a very simple mechanism that’s there, open-source versions, you know, etc is a very popular one; it’s deployed in many industries. It’s not new. It’s a very useful computing construct that we’re applying to the world of telecom.

Hema Kadia  –  VNF vendor will need to configure, predominately, their product in the Key-Value Store, whether it’s for integration northbound with NFVO or OSS/BSS applications or southbound with the existing NMS, EMS, VIM, or whatever ecosystem components. As long as they are able to configure it, whether it is for service chaining, or for discovering, or any specific place where they need to integrate in the ecosystem. As long as they configure, that’s the key differentiator I see from ETSI NFV to what Lean NFV is bringing to the table. 

Dan Pitt  –  That’s absolutely the goal. I mean, the devil will be in the details. And yes, we’re hammering stuff out. And we’ll talk at the end about where that work is going on. But what we’re trying to hammer out is a standard method of communicating these control-plane flows. And that should make it easy to write once and run anywhere.

VNFs in ETSI MANO vs. Lean NFV

Hema Kadia  – let’s discuss how VNF is onboarded based on the ETSI MANO concept vs. how it is going to be in Lean NFV.

Dan Pitt  –  ETSI MANO is this concept. And it’s been implemented in a way too often with these integrated components. So the VNF manager is monolithic. And you know, every VNF is customized to its vendor’s EMS. Yes. And to the NFV infrastructure. And to the VNF manager. And so if you want to introduce something new or you want to change something, you have to change all of these components. They’re tightly integrated, but it’s not like it’s a really beautifully architected, tight integration where you need tight integration, it’s kind of spaghetti, to me, more like a spaghetti integration of too many things are tied into too many other things.

What we’re trying to show on the right is that you write your VNF. And you have this API to a Key-Value Store, defining those. And you don’t have to do something monolithic, like the VNF Manager. These microcontrollers to constitute the sub-components of, the NFVO and the VIM, and the VNFM, which are also written once. And they can perform the functions that they need when needed. In fact, they can be invoked in a dynamic fashion, as the VNFs need to call them. 

Hema Kadia  – Dan, I see in both the pictures and both the diagrams we have VNF Manager. I understand that, yes, today, as you rightly mentioned, most of the VNF vendors bring in their VNF manager, but I see the VNF Manager also, in the LEAN NFV diagram. I’m assuming that is just to accelerate the deployment of the existing VNFs in the NFV ecosystem rather than re-architecting the existing VNFs. You can take existing VNF, and as long as you configure it into the Lean NFV architecture, you should be able to on-board/integrate into the ecosystem.

Dan Pitt  – Yeah, that’s right, you know, by sort of deconstructing the VNF Manager into the functions we saw on the previous slide as the different microcontrollers, you can create those as purpose-specific code modules.  And you can write to them for the functions that you need to implement. And you don’t write them tied into a particular VNF that is involved in that.

For example, you want to chain some VNFs together for a particular service chain. You don’t have to write that function – that microcontroller – specific to the functions you want to chain. 

Why Lean NFV?

Hema Kadia  – Let’s summarize, Why do we need Lean NFV? 

Dan Pitt  – The real goal is to really accelerate this virtualization and cloudification of telco operations and services. So they can roll out new services wherever in the network they are and take advantage of standard computing platforms. And an army of independent programmers who can bring these to market. The key to this is having this Lean NFV architecture that simplifies the integration by making the Key-Value Store really the primary mechanism and universal mechanism for this integration. And resource efficiency that’s a general term, but it certainly applies to what it takes to deploy and manage this on the part of the communication service provider. But it also applies to the VNF authors and the companies that want to deploy these services and the microcontrollers.

You can focus on the inherent function of your VNF or your microcontroller without spending, you know, 30 to 70% of your effort integrating it into the rest of the infrastructure.  And, because we realized that, unlike a lot of the hyper-scale web providers that have brand new build-outs, the telcos all have brownfield infrastructure. So these can be added, really, incrementally to existing infrastructure. They’ll certainly work with existing infrastructures and deployments. But I think once someone starts deploying these, as we know some operators are, they don’t want to deploy any of the others in the old, older way of doing so. So there are some basic things that are happening now that will pave the way, and then there is much more that we can do to really create a vibrant infrastructure that will help to move the telecom industry into the realm of computing, and that’s going to be a big part of 5G. 

How Lean NFV can accelerate deployment of 5G

Hema Kadia  – What are add-on features that Lean NFV brings that would accelerate 5G deployments? 

Dan Pitt  – You can debate the business cases of 5G and the consumer market or the industrial market and the commercial market. And hopefully, some of those things will get out there. But I think it’s a big driver for the deployment of SDN and NFV. And for the transition to computing instead of networking as really the heart and soul of the telecom industry. So that’s why you need service-based architectures; you need microservices, especially if you look at the diversity of 5G applications. I mean, there are so many of the three big corners. But beyond that, there are so many variations. You can’t have complex integrated infrastructures for each service.

That’s why a microservices architecture for implementing the endpoints of 5G is going to be essential. Cloud-Native, vendor-independent, highly distributed, as you know, I think we have a slide coming up on this, where might you deploy, you know, not just Lean NFV. But NFV in general, is in lots of places. And you want to have the freedom and the agility. Agility is really important here to put the computing tasks where they need to be, and that could be very close to the customer if you have a very low-latency requirement. It could be in a big central core database if it requires just a whole lot of, say, accelerator technology. And you may want to move these workloads around. And that’s really what virtualization has brought to the computing industry. And we’re bringing it to the telecom industry. We can go back one slide through a couple of points there that are probably worth mentioning. 

The fact that we can create sort of the middle way through, you know, aggregation at the mobile edge. And that includes both the service provider edge and the user edge. And these edge clouds and these cloudlets. By having a really agile way of moving workloads around to do particular functions that you need, you can enable the satisfaction of different service requirements. And finally, control plane-user plane separation. Well, this is, you know, this was given as we have to do this, they didn’t say how, you know, 3GPP said, it’s just an essential part of 5G. Well, this makes that possible and not only makes it possible, it makes it easy.

And finally, I think it’s going to be very useful in slicing and splicing. Splicing is where you attach different slices in different parts of the network, where you can actually implement a Key-Value Store per slice if you need it, or per service provider if you have multiples, or even per tenant if you have multiple tenants in some kind of a shared infrastructure. So we can go actually to the next slide and take a look at some of these places. So I think the provider edge and the user edge are getting a little bit blurred. I’m working with a company that does this on the customer premises. And in some cases, it’s considered the user edge because the user owns it and manages it. In other cases, it’s the provider’s edge because the provider manages it. I’d also like to mention private 5G.  I think we’re going to see a lot of this before we see, a huge record of deployment in public networks because the private 5G brings particular benefits to industrial customers that don’t have a good network otherwise. 

And this gives some very focused solutions that can be deployed quickly. And so the operators and the vendors are fostering this really as we speak. I think we’ll see much more function at the cell site, and the cell site is sometimes the tower, and sometimes it’s in street furniture nearby. And this stuff can be pretty powerful. And you can put some computing infrastructure there. And I think you’ll see more computing infrastructure there where you need it to be very close to a workload.

Now, we haven’t yet seen exactly what those workloads are that require something that close to the source of the data. But I think those will come over time. I mentioned these 5G Island gateways. Well, what is that? A lot of 5G is being built out in certain places where you have it as a last-mile technology, and you can reach other endpoints in that island of 5G connectivity, but you’ll need to communicate with the whole world. So how do you get out of that to other things with preservation, if possible, of your quality of service and your service level agreement? And this is where you might have slicing or splicing to really make the transition from one subnetwork segment to another. Now, if you take that further, I just mentioned the inter-provider gateways. We have seen in the deployment of the Sonata East-West API in MEF that carriers are concatenating services in an automated fashion that does not take months to set up. It takes seconds or minutes to set up. And where they have these inter-provider gateways, they have to manage their services and their business. And these functions are going to be dynamic, containerized, virtualized network functions. This is a good place, I think, where we will see this deployed. And if you want NFV and you’re going to use NFV, I’m not sure I know of a better way of building and deploying NFV. So wherever NFV is sold, I think we’ll see opportunities for Lean NFV to make a tangible difference. 

Lean NFV current implementations & future directions

Hema Kadia  – Are the architecture aspects of Lean NFV and the deployment mode you explained already supported by Lean NFV? What features are currently supported?

Dan Pitt  – There are companies that are starting to serve customers. I’m not really at liberty to say what they’re actually doing. But the number one thing people want to do is to onboard VNFs. Yes. In an automated fashion, very quickly. There have been competitions over the last few years on how quickly you can onboard a VNF. It’s been like three months, three weeks, 17 hours, that was tremendous. This is ridiculous. You need to deploy like any other piece of code. So that’s where the current implementations are focusing and the service chaining of the VNFs. And then scaling and change management and the things that you have to do and the lower bullets about making sure that you can maintain an SLA for your customer by knowing what’s going on and being able to react to what’s going on. 

Hema Kadia  – What is the timeline for the mentioned future features?

Dan Pitt  – These are increasingly vendor-specific plans. And so there’s no general industry area. We will see in the standards activity that the essential framework is being put in place now. When that gets there, we’ll get a little bit of experience with it. Then we’ll expand to other use cases and additional deeper capabilities. 

MEF project plan for Lean NFV

Hema Kadia  – What’s MEF’s role in the Lean NFV project?

Dan Pitt  – Lean NFV was launched at the Open Networking Summit in April of 2019 in San Jose, and they created this thing called leannfv.org. And you can go to it. And you can read the white paper. And you can see the video, although there might be a new link to the video. It’s on YouTube. It’s no longer on Vimeo. And they created leannfv.org. And they got signatories to the original white paper. But they didn’t want to build an organization. They didn’t want to hire people who have a budget and membership and all of that complexity. So they went around the industry to see where could we move that to some kind of an industry forum/consortium/standards organization to get industry agreement on how we might do it initially, and they shopped around, and they talked to lots of people and then this spring they decided they’re going to come into MEF and so that was launched in April as what was called an Incubation Group and that has to meet certain milestones.

And so they launched it and then had to go through these milestones to become an approved project. In this case, it’s the LSO Committee (Lifecycle Service Orchestration Committee) in MEF; that was assigned a draft specification number of W120. That was approved the final week of July. So it’s now an official project, and there are weekly calls on it. A number of the companies involved are developing a PoC related to a SASE application, Secure Access Service Edge. January, I think we’re gonna have these first PoCs, probably be part of the could be part of the Infinite Edge project of MEF. The specification is developing these control plane APIs and the schema. So they’re working on the schema now. I estimate that they’ll have a letter ballot on that no later than the second quarter of next year, and hopefully, sooner, and that letter ballot will be version one. And once that’s done, and it’s, you know, we get the experience and some feedback, then we’ll take it to a version 2 and do some additional things on it.

So, it is an official plan/project in MEF; we have weekly calls, and any member company can send any number of people to the calls and can participate in a PoC, and this is just the first one; we expect there will be others over time as people demonstrate how it can be used. So I want to direct people not only to the leannfv.org website but also to the MEF website. And there’s a website here for all the white papers. And the last I looked it was like the second one down, and it’s open to the public. And anyone can read that white paper. So it’s now moving forward with really strong industry participation led by a number of operators and vendors.