Explore the future of TOSCA and NFV, and explore the future of TOSCANFV

Explore the future of TOSCA and NFV, and explore the future of TOSCANFV

Standardization and unification have great advantages, but they also face great risks. The worst of these is the lazy idea. In a world filled with changes, we are too cautious. We trust standardization organizations too much and lack bold and imaginative plans.

This article will discuss the risks of open standards, open-source specifications, and excessive standardization and possible NFV standards.

Standard

In the telecom field, traditional service standards have been very important in terms of reliability, availability, continuity and scale. One of the key reasons for standardization is interoperability, carriers can provide services in a hybrid manner and match hardware and software products from different vendors to achieve their goals.

Standards can come from an independent company and become practical standards through extensive adoption. For example, TCP/IP becomes a standard in this way. Regulatory authorities promote legal standards, such as ISO. The actual standards are sometimes translated into legal standards. Generally, they are developed through some form of consensus process between the members of the Standard Development Organization (SDO, it usually represents the public and private sectors. Many people refer to this type of open standards, but the open standards are too inaccurate. Not all open standards are open.

Open Standards

Most people agree with the definition of open standards for ITU-T: Open Standards are public-oriented standards that are developed and maintained through writing and consensus driven processes. Open Standards promote interoperability and data exchange between different products or services, and are designed to be widely used.

Some of the details of the definition of ITU-T involving intellectual property rights (IPR) may have some differences of opinion, as far as this article is concerned, the "Open Standards" will be limited to what comply with Intellectual Property Rights, on the basis of no discrimination, everyone can apply for free.

Open Source

Open source covers two related concepts, namely software development and license. The definition of "free and open source software" and "Open Source" involves free access to and free distribution of code. While adhering to "code is King", open-source organizations are also making efforts in terms of specifications, which can be regarded as "Open Standards ". If these open standards are widely adopted, they will become actual standards and may become official standards.

This is actually the best way to develop valuable standards: SDO cooperates with open-source projects to generate a true "Open Standard", which is verified, accepted, and finalized.

Dangers caused by excessive standards

Because NFV focuses on management and orchestration, standardization usually reduces Opex. Due to more replicable operations, operators are independent of vendors to a certain extent, the interoperability between products from different vendors is improved, which can significantly reduce costs. At the same time, standardization reduces the potential of innovation and creates obstacles for operators who are willing to introduce cutting-edge technical services.

The most comprehensive standard for MFV management and orchestration comes from etsi nfv, which has completed a lot of work in a relatively short period of time. In fact, ETSI has made great efforts in NFV standardization. In the early stage, it promoted standard standards (Release 2 and Release 3), rather than allowing more time to absorb standard information (Release 1) test and evolve with Industry feedback before authorization. Too many or too early releases of standardization mean that there are many Unsatisfactory standards for NFV, which are still in the development stage.

The establishment of etsi nfv standards is based on the concept of NFV-centric, avoiding FACPS management and unwilling to break down network functions. Early Research on NFV standards requires entering the NFV field, but operators need to break these rules to fully benefit from NFV.

If the operator uses the following solutions in the production environment, the impact of implementation/ceshi and dui etsi nfv standards is as follows:

• NFVO is absorbed into the higher-level service orchestrator.
• A vnfm or a VNF component
• The general VNFM is absorbed by NFVO.
• The concept of a network service disappears or is absorbed into a wider range of service concepts.
• The VNF we are familiar with is further divided into fine-grained network functions in the management system architecture.

Operators need to figure out when and where standards are needed, and manufacturers are thriving in differentiation. Operators need to take advantage of the advantages of standardization while ensuring service agility. Their Investment in products is for the future. Therefore, carriers need "proper standards ".

Proper standards

What we need now for telecom NFV is adequate standards. The standards at this stage are not only optimal, but also about what standards are needed to achieve interoperability, while at the same time, service agility cannot be eliminated.

It is hoped that the etsi nfv Working Group will recognize the dangers of transition standardization and the reasons for its failure to fully generate "Open Standards" due to its intellectual property policy. There is still a long way to go to achieve the right standards. It is more selective to undertake new work in normative standards, and a bold move is to transform most existing IFA and SOL specifications into informatization.

We want the NFV community to follow the standards because the Community is a very valuable source of information, not because it is mandatory. A good example is the etsi nfv Information Model recorded in IFA011, IFA014, and IFA015. Why do we need to force these information models, especially the data models that require their implementation, to replicate the layers imposed by these standards and specifications? The etsi nfv information model should simply represent what needs to be implemented, rather than how to implement it.

TOSCA -- just right

This article is incomplete if the appropriate standards are not met, so let's talk about TOSCA. It is a set of standards developed to deploy and orchestrate cloud applications, which makes it more extensive than NFV, and more extensive than telecommunications companies, but also applies to both. It is an open standard first.

It enables open-source projects (such as ONAP) or SDO (such as etsi nfv) to use its syntax and philosophy to expand it to meet the needs of open-source projects and standard organizations, and create the actual standards required by the communities they serve.

The etsi nfv ifa and SOL standards clearly target specific nfv mano functional blocks. This is very strict. vendors create products that comply with these standards to facilitate interoperability between other products (such as VNFM or NFVO. How will these products develop when one of the carrier deployment solutions mentioned above is implemented? The standardization is too early.

In contrast, TOSCA can be used to create VNFM, but also applies to NFVO or other orchestrations (such as ARIA/TOSCA in ONAP), which makes the nfv mano standard just right.

When a user implements a complete set of nfv mano of etsi nfv standards, the user is locked to the current etsi nfv information model, and is forcibly orchestrated through the interface that locates the reference point. In contrast, TOSCA is flexible because the model itself drives orchestration.

The information-based etsi nfv information model and TOSCA summarize the appropriate NFV orchestration standards, which were adopted and verified by ONAP.