Network service providers are currently up against a serious issue: how to improve agility when setting up new competitive services to meet the demands of the IT world. It’s not just about reducing network equipment expenses (needed to maintain competitiveness) but being able to deploy services at a much quicker pace.

IT is calling for increased bandwidth from service providers and this, in turn, brings on the relentless need for both new equipment and access technologies.  In addition to all this, network service providers have to compete against IT and content providers, giving rise to the definition of new services and how to get production moving as swiftly as posible.

Basically, all services are made up of appropriately configured groups of devices, be they physical or virtual, where installation and configuration is intensively costly. Device configuration processes today are based on encoded scripts written by experts. Process automatization is hindered by the wide variety of devices needed to adapt to new services and the cost involved. New devices inevitably mean new scripts and training.

In view of the fact that current procedures neither contribute to cost reductions (CAPEX/OPEX), or reduce the time involved in exploitation, it’s obvious a new approach is needed: focus on how to be a service rather than how to deploy said service.

Definition of a service must take place through formal language. The language will allow the service to be formally specified, giving rise to a model. The model must be recognized and interpreted by service provider management tools. And it’s patently obvious that current tools, OSS/BSS, are no longer valid: adaptation to a new model is crucial.

What is a Service Model?

As already referenced, the way to define a service is by using a formal language, permitting the service to be shaped, specifying the related and associative elements essential for the service. A service model does not specify an ultimate manufacturer for a specific device, nor the configuration schema.

The advantages to this approach are evident: a service can quickly and formally be specified using a library of elements to help create it.  The key, of course, lies in how to achieve the series of configurations needed to make the equipment work from a generic model.

The mechanism is by no means easy. However, once achieved, the process can be automated.  Essentially, this means the mapping of a service model to other models that formally specify the configurations required to deploy the service.  For each type of device, a corresponding configuration model is generated (always bearing in mind this does not guarantee validity for all manufacturers). Models, resulting from the mapping, can then be used to configure all devices involved in delivering the service.

Formal models defining the services and configuration models are currently sparking great interest in our sector. Initiatives, with this end goal in mind, are now appearing where direct involvement by equipment manufacturers is a must to meet the needs of providers.

Languages such as TOSCA, which fulfills the definition of formal and is used to define services, and YANG, fulfilling the formal definition of configurations, are particularly important.  The former is a language directly applied to the SDX/NFV world, while the latter, although not new, is beginning to appear in the portfolios of some manufacturers. NETCONF often accompanies YANG to transport and manage the configurations.

TOSCA (Topology and Orchestration Specification for Cloud Applications) is a language based on templates used to specify a service and its deployment in a Cloud infrastructure. The two basic elements in TOSCA for services are nodes and relationships.

A node may be a subnet, a network, a server, a service, an NFV, etc., while the relationship describes how the nodes connect to one another.  The definition also includes node lifecycles, policies and operational behavior.

The templates are specified through YAML, although XML was initially used.

TOSCA is currently the subject of much interest in projects such as Juju, Cloudify, IBM Cloud Orchestrator and OpenStack Heat.

YANG (Yet Another Next Generation) is a formal data model language widely used to define configurations and interfaces.

A configuration can be considered as a set of data that must be orchestrated and may depend on other values. YANG interprets configuration data as a hierarchical tree where each tree node either has a value, or is the point of connection to other nodes.  Each node is perfectly defined, together with its interaction with other nodes. An important aspect of YANG is the limiting constraints placed on node values, restricting the appearance of a node, or its value, over the appearance of other nodes, or values, in the hierarchy.

A generic YANG mode includes data for configuration, status, RPC (Remote Procedure Call) and notifications.

YANG is often accompanied by NETCONF (Network Configuration Protocol). This is a configuration transfer and management protocol. YANG models are directly mapped in XML and transmitted by NETCONF. This guarantees atomic transaction, where a result is correct or erroneous, and configuration management.  There are three types of configurations: Candidate, over which changes are made; Running, executing in the device and Startup being the configuration stored in the device and used in startup. A candidate configuration can transform into running and the latter, in turn, into startup, providing the changes to the configuration are considered correct.

Conclusion

Modeling, for both services and configurations, is a concept that network equipment manufacturers (for physical and virtual devices) must take into consideration, not in the long term, but now.  It is one of the main elements network service providers need up and running to survive IT competition.