)
We need to evolve our telecom infrastructure to be virtualized and containerized while reducing costs of integration and verification for deploying several applications. NTT, KDDI, and NEC have adopted Tacker, an ETSI NFV standard-compliant G-VNFM (Generic VNF Manager), with expectation that it will continue to support the standard as one of the most active projects in OpenStack.
As presented at the Open Infrastructure Summit in 2020, Tacker is now at the stage to be making a strong relationship with ETSI NFV. It is creating a development process to automate IF and spec compliance test with ETSI-NFV using ETSI-NFV TST010 and Zuul and will promote the solution of CNF control with ETSI-NFV. The cooperation will promote interoperability with other products.
Challenges of Network Operators
Background
There are several telecom companies competing in the market but have the same challenges. KDDI and NTT are top share companies in Japan. Although our service systems have been developed for each company individually, we have realized that we should share some common issues and tackle them by cooperating with each other to develop large-scale telco services with the latest virtualization technologies rapidly.
We have two big challenges especially for aiming to realize the latest network services.
Challenge #1 Operate both VNF and CNF together
CNF based technologies, Cloud Native applications or 5GC in other words, have emerged. Is it possible to switch from VNF to CNF for all applications?
Our answer is NO. For some applications, such as the U-plain function or legacy application, VNF is more suitable. We need to deploy both VNF and CNF together.
Challenge #2 Multi-vendor integration with high SLA
We are able to integrate multi-vendor products for the fruits of activities of standardization and OSS communities, but the increasing cost of NFV is still a problem. One of the most critical parts is VNFM.
The reasons why VNFM is costly are
- VNFM has many interfaces
- It requires some optional implementations
- All the vendors do not comply with standards
- Standards themselves are not almighty for all use cases. It requires extra costs to fulfill our demands.
In addition to VNFM, we need to satisfy requirements for high-level service system-wide. As the result, integration and verification costs are largely increased.
OpenStack Tacker
Tacker is trying to solve these challenges as an open source G-VNFM. The development of tacker has been led by NTT, NEC and Fujitsu with wide experience of telcom operator or vendor.
Why Tacker?
Tacker provides ETSI NFV standard-based VNFM and NFVO as main components of NFV. It was started to develop Tacker as an NFV Orchestration framework on OpenStack in 2014. Several network vendors and operators, such as NEC, Brocade, 99cloud and Intel, have joined to implement their requirements on Tacker.
Now, Tacker is one of the major candidates for deploying NFV system as a multi-vender-oriented open source G-VNFM. It is targeting the use case of 5GC and introducing CISM (Container Infrastructure Service Management) with Kubernetes in addition to OpenStack for realizing the co-existence of CNF and VNF.
For challenge #1, Tacker covers a wide range of use cases including integration of VNF and CNF by referencing ETSI NFV standard. Kubernetes support is one of the latest hot topics of the Tacker project and it is under active development.
For challenge #2, Tacker provides not only ETSI NFV compliant features but also many test cases as unit and functional tests. The test scenarios are also designed based on use cases in ETSI NFV.
Community Growth
As a background of demands for NFV, the development of Tacker has been getting more active than previous releases. For example, the total number of proposed patches increased by 37%, or the number of active contributors is 26 counted by the authors and more including reviewers in the Victoria cycle.
Tacker is focusing more on ETSI NFV compliant features in recent releases to meet the requirements for the co-existence environment of VNF and CNF. In the Victoria cycle, the Tacker team released 11 essential features of ETSI NFV.
- Enhance VNF lifecycle management in Tacker
- Support ETSI NFV-SOL based error-handling
- Support LCM notifications for VNF based on ETSI NFV-SOL specification
- Support scaling operations for VNF based on ETSI NFV-SOL specification
- Support ETSI NFV SOL003 to interoperate with 3rd-party NFVO
- Support VNF update operations based on ETSI NFV-SOL specification
- VNF Workflows Customization by Action Driver
- Add artifacts support for vnf package
- Support event trigger alarm and vdu_autoheal by alarming type policy
- Adopt Robot Framework to use ETSI NFV-TST API test code
- CNF with VNFM and CISM
Tacker in Commercial Service Network
KDDI is one of the biggest companies providing fixed and mobile network services. The number of subscribers is over 60 million. KDDI adopts Tacker as VNFM for fixed network.
From some experiences of using dedicated or specific VNFM, we have realized that it provides quite a lot of functions with beautiful GUI, but many of them are no need. It is not flexible, stable, and difficult to use.
There are several reasons why KDDI using Tacker:
- Lightweight for simplicity
- Compatibility for ETSI NFV Standards
- Open Source Software for multi-vendor integration
- Matured as OpenStack based product
Especially for VNFM:
- Support HOT (Heat Orchestration Template) and VRD. VNF vendor is able to verify Vi-Vnfm Interface without VNFM.
- OpenStack Heat is more popular than TOSCA VNFD and more flexible.
- Implement the latest ETSI NFV standard features and Kubernetes supports.
KDDI has proposed some features to Tacker with NEC to fill gaps of current implementation and actual use cases.
- Multi deployment flavor with HOT for using deployment flavor required in commercial VNF.
- Support rollback of LCM resource to deal with unexpected errors.
Collaboration with ETSI NFV
For realizing highly qualified standard-compliant G-VNFM, it is not enough to develop Tacker without any feedback from or to ETSI NFV. So collaboration is one of the keys to success.
ETSI NFV TST
NEC has lead an introduction of a test framework defined in ETSI NFV TST (Testing). From the developer perspective, we expect that using OpenAPI and Robot much improve Tacker for connectivity with 3rd party products.
We think making mutual cooperation must make benefits for both of us. For ETSI NFV TST, feedback for enhancing test code from Tacker must be helpful for improving interoperability and confirming feasibility. On the other hand, for Tacker, we can get automated API test codes and assure that our MANO complies with the standards. The scope of using TST is not only giving feedback to the ETSI NFV but also creating a feedback cycle for continuing such an improvement again and again.
Introduce ETSI NFV TST to Tacker
We have started to discuss with ETSI NFV TST. There are several topics needed to be detailed and concrete to proceed with our development. Here are some examples:
- Enhancement test coverage for response codes, HTTP response header check, and request input parameters.
- Test code management such as a branch or naming on repository, versioning or providing descriptions of test coverage in specifications.
As the first step for introducing ETSI NFV TST to Tacker, we are targeting API Conformance Testing Specificatio, called TST010, to be enabled in our Zuul test. Through some evaluations, we have found that we need to clarify how we implement “pre-conditions” for. We do not have any implementations of “pre-conditions” currently, although it can be referred to as specifications. We understand that there is further work required to include the testing to Tacker not only implementation but also maintain the test codes. How do we develop test codes, or make some scenarios for the tests?
The next step is to complete automated API testing. Our plan is just to execute compliance tests by only downloading test codes from the ETSI NFV repository and Tacker’s support API list. The test is developed by ETSI NFV, and Tacker provides supported APIs which are auto-tested with minimal effort. We will continue to discuss this with the ETSI NFV community.
Get Involved
This article is a summary of the Open Infrastructure Summit session, NTT and KDDI Challenges for Sustainable Infrastructure Transformation.
Watch more Summit session videos like this on the Open Infrastructure Foundation YouTube channel. Don’t forget to join the global Open Infrastructure community, and share your own personal open source stories using the hashtag, #WeAreOpenInfra, on Twitter and Facebook.
Madhu Kashyap
