Communications service providers (CSPs) have no standard way of provisioning and managing the lifecycles of virtual network functions (VNFs) or network services – interconnected virtual and/or physical network functions (PNFs) or service function chains. Every supplier has a different way of doing it, which translates to complex, expensive integration.
A new TM Forum application program interface (API) called the Resource Function Activation and Configuration API aims to standardize VNF and network service lifecycle management, which will help CSPs deliver services to customers more quickly and reduce operating costs. The API will help CSPs tackle one of the biggest challenges they face: end-to-end management across hybrid networks, made up of physical and virtualized components, based on network functions virtualization (NFV) and software-defined networking (SDN).
Today, in order to provision and manage, say, a cloud-based service across partners’ boundaries, CSPs must predefine the service, making sure everyone ‘speaks’ the same language and uses the same service definitions. In proofs of concept, they have used a master service orchestrator that has visibility into all the networks and operational and business support systems (OSS/BSS) involved, but this won’t scale in the real world.
A better approach is for operators to agree to use the same information and data models, and APIs like the Resource Function Activation and Configuration API, to allow orchestrators in different domains to communicate with each other. This, combined with intent-based, catalog-driven, policy-enabled management, is how CSPs will automate service provisioning and management end to end. The intent-based management abstracts the complexity of the network at a high level, then uses a customer’s intent and policy to manage it.
We caught up with Milind Bhagwat, Enterprise Architect, BT, who has been active in development of the API to learn more about how it works and what’s next.
DB: Why is this API necessary?
MB: There is a move toward virtualizing the network by using NFV and SDN technologies. The idea is that instead of running a physical network function on proprietary hardware, we run a virtual version of these network functions on standard hardware. This has the potential to significantly change the way we deploy and manage networks.
The problem is that there has been no standard way of managing the network functions. As Chris Rice from AT&T has said, they’re like snowflakes but they need to be more like Lego blocks. We need standard ways of managing network functions – standard ways of starting them, stopping them, healing them, scaling them, etc. Unless that standardization happens, we won’t get any of the benefits of network virtualization.
So with that in mind, we started working on this API in ZOOM [TM Forum’s Zero-touch Orchestration, Operations and Management project]. The purpose is fulfillment and lifecycle management of resource functions. We know that we will have to manage a hybrid network for a very long period of time, which means that the API has to deal with both the physical and virtual parts of the network.
DB: Where exactly does the API get implemented?
MB: This is one of the several APIs that will sit on top of what the TM Forum calls the Hybrid Infrastructure Platform. It will be used to fulfill or create infrastructure functions that are virtualized as well as physical but then also to manage the lifecycle of those resources and services. For example, there is an operation that allows you to scale the resource function and another to heal the resource function.
DB: How long have you been working on the API and how is it different from previous versions?
MB: We have been working on it for about a year. There are two main changes: Instead of having separate objects or entities to describe VNFs, PNFs and network services, we now have generalized all of that into a single entity called a resource function, which is more general than NFV (and also covers SDN). So, we’re saying that by using the atomic and composite pattern, you can describe a single VNF or a network service that includes the VNF.
The second big difference is that we can now create a topology. A user can design a network from components and request that it be created through our API. So, we allow intent-based creation of a network as well as detail-based creation of a network.
DB: What was your role in helping to develop the API?
First, I provided a real-life example, based on which the requirements for the API were developed. Then I developed the API – the specifications (TR664) and the conformance profile, which lists all the things that are mandatory and optional in the API. I also worked with others within BT and volunteers from other companies to develop the conformance toolkit and reference implementation.
DB: How much collaboration was involved?
MB: There was a lot of collaboration because effectively the requirements have come from a number of operators and vendors. I worked closely with other ZOOM leaders such as Steve Fratini [from Ericsson]to consolidate the requirements and then convert them into an API specification. Without collaboration and a lot of hard work from many others, this would not have happened.
DB: Did you face any specific challenges along the way?
MB: This API provides a vendor- and technology-neutral abstraction on top of an ecosystem that may be composed of open source components (for example, ONAP, Open Network Automation Platform, and OSM, Open Source MANO) and components based on standards like ETSI NFV, ONF Transport API and IETF Service Function Chaining. We had to ensure that we were aligned with these standards and opensource initiatives.
Other challenges are that the concepts of NFV and SDN are quite new, which means that there aren’t a lot of people who have hands-on experience with the technologies. The danger is that it could become a very theoretical API. Unless the API is implemented in a few scenarios, we will not know how it behaves. We’ve done the best we could, but that hands-on experience was a challenge.
DB: How have you tested this API and how will it be used?
MB: It was used in the Real Virtuality Catalyst and seems to have done the job for that scenario. This is such a critical API. It should feature in a number of Catalysts going forward. Anything to do with network virtualization needs fulfillment and lifecycle management, and for that this API is ideal.
The next step will be implementing it in vendors’ products, but it’s very early days – we have just published the API and it needs to be reviewed by the industry.
DB: What are the potential benefits for operators using the API?
MB: The first benefit is shorter time to market. If all vendors agree on this API as a standard, that will significantly accelerate the adoption of NFV. Today we don’t really get the benefit of virtualization because onboarding a new VNF is a huge integration effort. If there is a standard way of managing these VNFs, the integration effort will be reduced significantly. Then the operators will be tempted to virtualize a lot more, and that’s how they will get the associated benefits like significant reduction in CapEx and OpEX.
DB: How can this API be used in conjunction with other TM Forum Open APIs?
MB: It is an important part of the end-to-end fulfillment and assurance lifecycle for infrastructure services and will sit alongside other APIs including the Catalog and Inventory Management APIs to deliver end-to-end use cases.
DB: What’s next for this API? Is this something you have to evangelize within the industry?
MB: One important thing we want to implement is allowing the creation of flows (VNF forwarding graphs from NFV, and service function chains from SDN are examples), which means there is a topology and a consumer is able to request creation of a specialized flow through that topology. We also want to implement features and feature groups, which will enhance intent-based provisioning of resource functions.
Those are technical changes, but the second big thing that needs to happen is that we need to align this API with other similar APIs from standards bodies as well as open source organizations like ONAP and OSM. For example, ONAP has published its own set of APIs, and we need to do a gap analysis to see where we both need to enhance. We also must work with ETSI to do the same.
DB: Is BT using this API outside of Catalyst projects?
MB: It may not be ready for that yet, but it will be soon. We have signed the API manifesto and as a part of that, we insist that vendors’ products need to implement the TM Forum Open APIs. For this specific API, it needs to be tested and proved, but I’m sure that in a short amount of time we should be able to get to a point where we can implement it.