Discussing the future of TOSCA and NFV

Standardization and unification have great advantages, but they also face great risks. The worst of these are lax thinking, being too cautious in a world full of changes, putting too much trust in standardization organizations, and lacking bold and imaginative plans.

This article will explore open standards, open source specifications, the dangers of over-standardization, and what might constitute an NFV standard.

standard

In the telecommunications sector, traditional service standards have long been very important in terms of reliability, availability, continuity and scalability. One of the key reasons for the need for standardization is interoperability, which enables operators to mix services and match hardware and software products from different manufacturers to achieve their goals.

[[217958]]

Standards can come from an independent company and become de facto standards through widespread adoption, such as TCP/IP. Regulatory bodies promote statutory standards, such as ISO. De facto standards sometimes evolve into statutory standards, usually through some form of consensus process among the members of a standards development organization (SDO), usually representing both the public and private sectors. Many people refer to this category as open standards, but open is too imprecise, and not all open standards are open.

Open Standards

Most people agree with the ITU-T's definition of open standards: Open standards are standards that are available to the public, developed and maintained through a written and consensus-driven process. Open standards promote interoperability and data exchange between different products or services and are intended for broad adoption.

There may be some differences of opinion on some details of the ITU-T definition involving intellectual property rights (IPR). For the purpose of this article, "open standards" will be limited to those areas that comply with intellectual property rights and can be applied free of charge by everyone on a non-discriminatory basis.

Open Source

Open source covers two related concepts, namely software development and licensing. The definitions of "free and open source software" and "open source" both involve the free acquisition and free distribution of code. While adhering to the principle of "code is king", open source organizations also make efforts in standardization, which can be regarded as "open standards". If these open standards are widely adopted, they become de facto standards and may become official standards.

This is actually the healthiest way to develop a valuable standard: collaboration between SDOs and open source projects to produce a true "open standard" that is validated, adopted, and ultimately formalized.

The harm caused by excessive standards

Since NFV focuses on management and orchestration, standardization usually leads to a reduction in Opex. Since there are more replicable operations, operators have a certain degree of independence from vendors, and interoperability between products from different vendors is improved, which can significantly reduce costs. At the same time, standardization reduces the potential for innovation and creates obstacles for operators who are willing to introduce cutting-edge technology services.

The most comprehensive standards for MFV management and orchestration come from ETSI NFV, which has accomplished a great deal of work in a relatively short period of time. In fact, ETSI has been very prominent in the standardization of NFV, pushing the specification standards early (Release 2 and Release 3), rather than allowing more time to absorb the information standards (Release 1), test, and evolve with industry feedback before authorization. Pushing too much standardization too early means that for NFV, which is still in its development stage, a lot of less than ideal standards have been produced.

The formulation of ETSI NFV standards adheres to the pure NFV-centric concept, avoiding the limitations of FACPS management and unwillingness to perform network function decomposition. Early research on NFV standards requires entering the NFV field, but operators need to break these rules if they want to fully benefit from NFV.

If operators adopt some of the following scenarios in production environments, the impact based on implementation/ceshi, dui ETSI NFV standards is as follows:

• NFVO is absorbed into higher-level service orchestrators
• Specific VNFM components or reorganization into VNF components
• General VNFM is absorbed by NFVO
• The concept of network services disappears or is absorbed into the broader concept of services
• The VNFs we are familiar with are further decomposed into fine-grained network functions in the management architecture

Operators need to understand when and where standards are needed, and vendors thrive on differentiation. Operators need to take advantage of benefits beyond standardization while ensuring service agility and that their product investments are future-proof. Therefore, operators need "just the right standard".

Just the right standard

What we need now for telecom NFV is sufficient standards, standards at this stage that are not only the best, but also about what standards are needed to achieve interoperability without stifling service agility.

Hopefully, the ETSI NFV working group realizes the dangers of over-standardization and why it cannot produce "open standards" completely due to its intellectual property policy, and has a long way to go to get standards just right. It is more selective to take on new work in the specification standards, and a bolder move would be to convert most of the existing IFA and SOL specifications into information.

We expect the NFV community to follow standards because the community is an invaluable source of information, not because of community mandates. A good example is the ETSI NFV Information Model documented in IFA011, IFA014, IFA015. Why should these information models be mandated, and in particular why should the data model required to implement them need to replicate the layers normatively imposed by these standards? The ETSI NFV Information Model should simply represent what needs to be implemented, not how it should be implemented.

TOSCA - Just Right

This article wouldn't be complete without implementing just the right standards, so let's talk about TOSCA next. It's a set of standards developed for deploying and orchestrating cloud applications, which makes it broader than NFV, broader than telcos, but applicable to both. It's first and foremost an open standard.

It enables open source projects (such as ONAP) or SDOs (such as ETSI NFV) to adopt its syntax and philosophy to extend it to meet the needs of open source projects and standards organizations and create de facto standards required by the communities they serve.

The ETSI NFV IFA and SOL standards explicitly target specific NFV MANO functional blocks. This is very rigorous, and vendors create products that conform to the interfaces specified in these standards in order to interoperate with other products (such as VNFM or NFVO). When one of the operator deployment scenarios mentioned above is realized, how will these products develop? It is too early to standardize now.

In contrast, TOSCA can be used to create VNFM, but is equally applicable to NFVO or other orchestrators (such as ARIA/TOSCA in ONAP), which makes the standard just right for NFV MANO.

When a user implements the NFV MANO of the entire set of ETSI NFV standards, he is locked into the current ETSI NFV information model and is forced to orchestrate through the interface of the positioning reference point. This situation stifles innovation. In contrast, TOSCA is flexible because the model itself drives the orchestration.

The informative ETSI NFV Information Model and TOSCA summarize the right standards for NFV orchestration today, which are adopted and validated by ONAP.