The history of creating standards for the telecommunications industry dates back to the 19th century as do the vigorous debates on which draft proposal or specific technology should win out. A very recent example of this comes from the network functions virtualization (NFV) world where there is an open question about which data modeling language should be used for deploying applications and services in virtual, physical, or hybrid networks.
There are several technology options that are being discussed and considered, but the two most prominent contenders have been Topology and Orchestration for Cloud Applications (TOSCA) and Yet Another Next Generation (YANG). TOSCA is a data modeling standardization effort led by Oasis for cloud orchestration environments and applications. It is a hybrid information/data-model based on Yet Another Multicolumn Layout (YAML) with a number of variants that commercial NFV management and orchestration (MANO) vendors have introduced based on their own YAML Domain Specific Language (DSL).
YANG is the data modeling language standard used by the Internet Engineering Task Force (IETF). YANG provides a semantically precise data modeling of both configuration and state change information. This precision allows it to be compiled into data parsers/validators and can even automatically be compiled into transactional Netconf operations. It is also possible to compile YANG specifications into a YAML DSL with associated data model parsers/validation checkers.
Why a Schema?
There have certainly been no shortage industry debates in favor and against both proposals with solid arguments raised by both sides. However, while mired in the heat of these arguments, the NFV industry is perhaps missing the bigger picture: Why not simply enable them all? That is, instead of arguing which language is better, the industry should spend its energy and knowhow behind a more productive effort to create the proper schema as the framework to support any number of data models and languages.
If this industry-wide and agreed-upon schema exists, then it would not matter which language a data model is presented in – be it TOSCA, YANG, YAML, etc. Operators and vendors would be able to translate freely between these languages with no loss of information, leading to improved interoperability and quicker integrations.
There should be three goals guiding this effort to create an industry-wide schema:
- First, when an information model is specified, implementations should not be left to vendor interpretation.
- Second, the model should encode all lifecycle events so that the need to use scripts or an external entity to change the lifecycle state of a virtual network function or a network service under orchestration is minimized.
- Third, the model needs to be sufficiently abstracted to accommodate all virtual infrastructure managers (VIMs), all virtual network functions (VNFs), and all use cases by enabling operators to “write once and deploy many”.
These goals should align to the ETSI specifications for the packaging of VNFs that are delivered to service providers, delivering a schema capable of “holistic end-to-end view of the VNF package lifecycle, from design to runtime, capturing development as well as operational views.” For example, the ETSI Open Source MANO (OSM) project, using YANG, is relatively far along in alignment with this workgroup’s (IFA 011) schema. TOSCA, being standardized by Oasis, on the other hand, is not as far along though there are efforts in progress to tightly link a TOSCA-based schema to the ETSI MANO specifications.
TM Forum report IG1141, “Procurement and Onboarding of Virtualization Packages R16.5.1 Standard”, summarized that OASIS’s TOSCA template is a “best-in-class” solution for modeling cloud-native applications but noted some gaps:
“In summary, TOSCA is a generic modeling template, which supports custom types, but without a standard model of the package, its dependencies and behaviors the packages require extensive manual intervention (e.g. portable like a ZIP file, but no meaningful automation is possible). On its own, TOSCA does not solve the multi-vendor interoperability and integration problem for the service providers.”
There are some schema elements within the ETSI specific that require further development. Specifically, while concepts such as lifecycle states and events are very well described, it is limited to objects, attributes, relationships, and unidirectional cardinality. Further improvements target implementation-related details such as attribute type as well as default/minimum/maximum values.
The Mandate for Operators
Operators can play a significant role in pushing the industry toward this information/data model schema for the benefit of simplifying their path to a full-scale NFV deployment. One way they can get involved now is to ask their NFV MANO vendors about what open information model (OIM) their products support and if their products have limitations that restrict them from working with either TOSCA-based or YANG-modeled descriptors.
It’s also important for operators to remember that not all “open” is created equal, particularly when information models are concerned. Just because a product is available on Github does not mean it is not proprietary. Only when “open” is backed by a strong community will there be broad agreement. Then you can truly avoid vendor lock-in.