Model-driven configuration management for multi-domain service orchestration

On the journey towards intent-based, zero-touch network management, there are many obstacles to overcome to realize the promised flexibility and cost efficiency of network function virtualization and automation. The network management solutions need to deal with the increasingly complex and multi-vendor infrastructure. These advancements bring challenges in service design and instantiation. Communications service providers (CSPs) struggle with extended time-to-market, rising operational costs, and errors due to manual tasks in complex scenarios. Automation in this environment is not a choice but a necessity. The multiple layers of infrastructure and service abstractions should provide the capability to focus on delivering business value. Building automation on top of abstract service and infrastructure capabilities tackles the interoperability challenges and reduces operational costs. To realize services across multiple administrative and technological domains, CSPs must automate service component deployments across a range of domain orchestrators. 

Automation across abstraction layers tackles multi-domain complexity 

Imagine a team leader heading a diverse group with its members all talking different languages. Despite their complementary skills, they are often unable to communicate with each other. It's challenging. How can the team leader efficiently manage and deliver every possible assignment that requires indispensable contribution from all team members? What is the most valuable tool that can help optimally distribute and rigorously specify the tasks?  

First, team leaders need to understand the capabilities of all members. Then they need to be able to communicate the tasks. This is crucial – to realize the intent behind the team assignment. The role of the team leader here is taken by the multi-domain service orchestration and assurance layer (MDSO), which is to coordinate the inter-operation between various single-domain orchestrators (SDO) – the team members – to deliver the requested service (team assignment) towards the commercial layer, and ultimately to the customer.  

The multi-domain automation architecture is depicted in Figure 1, which positions MDSO below the commercial layer while managing interactions with an array of single-domain orchestrators. The automation architecture is described in more detail in Unified multi domain service orchestration: a must for 5G enterprise services. MDSO takes the selected generic service description and the specified service level agreements (SLAs) to create an end-to-end service instance for the customer, implemented across various domains. Similarly, when a team leader receives an assignment, they assess their team's capabilities and delegate tasks accordingly. Service inventory and common topology keeps track of the capabilities and statuses of all domains, which is used by the service orchestration function to dynamically calculate an execution plan for any service instance.  

Figure 1:  Multi-domain service orchestration is positioned between the commercial layer and the domain orchestration layer. 

Orchestration engineers make sure that the MDSO can build on the interfaces of each SDO and coordinate the end-to-end capabilities. On a higher abstraction layer, the service designers work with domain-independent service building blocks to create reusable blueprints for end-to-end services. Similarly, the team leader studies the capabilities of each member to build an abstract functional view of the team and uses it to break down the assignment into tasks for the members. 

This gives us some initial questions:  

• How can the MDSO represent the end-to-end capabilities in a domain-independent manner, so that service designers can ensure the reusability of services?  
• How can the domain-specific capabilities of the SDOs be exposed to enable abstract operations? 

The first component of the answer lies in service and data models.  

Leverage technology-independent open standard to model services 

Our team leader cleverly knows the team’s capabilities and keeps track of how each member contributes to goals. Whenever a new assignment arrives, it's important to quickly identify the members responsible for each task.  

Ericsson has chosen OASIS Open’s Topology and Orchestration Specification for Cloud Applications (TOSCA) standard as the language for writing service templates. This enables the technology-independent description of multi-domain end-to-end services, such as network slices. TOSCA is widely accepted across the telecom and IT industry to describe services and automate their life-cycle management. The power of TOSCA lies in its capability to provide technology-independent, composable, end-to-end service descriptions. The team leader’s resource management skills are analogous to TOSCA, it enables him/her to describe the team’s capabilities to the stakeholders, without the need to talk about each member’s individual skills.  

The TOSCA service orchestrator is packaged into the multi-domain service orchestration and assurance  (MDSO), as shown in Figure 1, where it compiles these service templates into actual service instances based on the underlying network topology. These service instances are execution plans that contain a combination of user-provided parameters in the SLAs, infrastructure information, and contextual information necessary for the SDOs to realize their corresponding service components. In short, a service template hierarchy written in TOSCA enables a reusable representation of the multi-domain capabilities, abstracting the details of the technological domains. 

Domains expose their capabilities via abstract models 

Team members have CVs that contain an abstract view of what they have learned, experienced and their potential contribution to a team independent of how they have acquired their skills. 

Looking at Figure 1 , vendors of the SDOs abstract their domain-specific orchestration logic. These capabilities are exposed through a domain-specific configuration data model, which conceals their implementation details. For example, in the 5G Core domain, Ericsson develops cloud-native software to implement 5G network functions. These functions expose their configuration data models via the 3GPP-endorsed YANG modeling language. YANG is widely accepted in the telecom industry, and it is considered a de-facto standard modeling language to describe the configuration data model of various domains. The MDSO also relies on the transport domain to guarantee the SLAs end-to-end, so its SDO exposes an abstract configuration model of the transport network to enable the usage of its services from the upper layer. Lastly, proprietary data models such as Amazon Web Services (AWS) CloudFormation, also exist for the same purpose: to enable the programmatic creation of AWS services.  

Similarly, data modeling languages such as YANG correspond to a standardized CV format, that is well-understood by team leaders, allowing them to seamlessly align the described skills with the team's capabilities.  All SDOs expose their capabilities via configuration data models, which enable the MDSO to order the instantiation of service components. 

This leaves us with some further questions to resolve:   

• How does the MDSO translate any service instance (compiled onto any network topology) into configuration instance data for each involved SDO data model?  
• How does it determine which domains to configure and where to extract their necessary parameters from?  

• How does the network automation solution enable zero-touch deployment of newly created services?  

The second component of the answer lies in model-driven configuration management. 

Use common functions to generate configuration for each domain 

Continuing with the teamwork analogy, we assumed that the team members are unable to communicate with each other because they speak different languages. The leader must provide detailed instructions in the mother language of each team member to ensure that the assignment meets the expectations of stakeholders. Imagine a tool that could automatically and optimally assign tasks to each team member, in their mother languages, simply by looking at their CVs. Maybe this is too much to wish for in the case of teamwork support software, but not in the case of multi-domain service orchestration. 

And that is why the model-driven configuration management approach is needed. It enables the automated translation of intents described in high-level TOSCA service templates into low-level configuration data for each involved SDO. By adopting a model-driven mindset for service realization, we empower service designers to focus on intent, and orchestration engineers to create generic domain model mappings. Meanwhile, the complex task of managing all the intricate configuration details is handled by automated software in SDOs, enabling the effortless creation, launch, and management of new, innovative services across various domains. 

Each domain exposes their specific configuration data model, which abstracts their internal behavior and summarizes the meaning of their parameters. This enables orchestration engineers to create a general model mapping between the MDSO’s service model and each domain’s configuration data model. The model mapping, shown in the left of Figure 2, defines the relevant parts of the MDSO’s service model, selecting only the service instance elements and attributes, which are required by a specific SDO. This translation, filtering, and mapping between the MDSO’s service model and a domain-specific configuration model only needs to be designed once by the orchestration engineers, when the domain is integrated with the MDSO. 

Figure 2: The common configuration function (CCF) generates domain configuration instances based on model mappings. 

Thanks to the common configuration function (CCF), the relevant part of the service instance is mapped and translated to the appropriate parameters of the domain’s configuration data model. The model driven CCF takes the data model of any domain, a service instance, and the defined model mapping to generate the configuration instance. CCF is shared across all domains, and its logic can be used for mapping to the data model of any domain.  

Figure 3: Model-driven common configuration function (CCF) is domain-agnostic and shared across all domains. 

As shown in Figure 3, once the MDSO has generated the service instance, the model-driven CCF can be called for each integrated domain with its specific configuration data model resulting in the generation of the configuration instances.  This can be sent directly to the SDOs, which understand what they need to do as the received configuration instance complies with their exposed data model. CCF is a crucial function enabling the MDSO layer to operate on its abstract model, without needing to deal with how a service instance is realized in the SDOs. The model mapping prepared during SDO integration enables CCF to decide for each domain (RAN, Core, HCP/edge) if any capability of an SDO is needed to realize the service instance. 

The end-to-end capabilities are described in the domain-independent TOSCA service templates complying with the MDSO’s service model. The domain-specific capabilities of each SDO are described via abstract configuration data models, such as YANG models. The new common configuration function enables a generic mapping between the service and domain data models. This facilitates the selection of the domains, translation between abstract layers, and the automation of domain configuration. 

Future-proof, cost-efficient service design, and instantiation relies on stability and reusability 

The most valuable tool for a team leader would be the ability to interpret the objective-focused assignment description – as specified by the stakeholders – and break it down into detailed tasks for each team member. This would enable the team leader to focus on maintaining the team’s competence and hire new members if needed – activities that cannot be automated.  

The CCF realizes an abstraction layer in the multi-domain automation architecture by connecting the MDSO’s service model with each domain’s configuration data models. This abstraction helps to manage complexity and address inter-operability challenges. CCF contributes to faster lead-times while introducing new services and lowers operational expenses. 

When an SDO releases a new software version, and even if its model is not backward compatible with earlier releases, the changes do not necessarily require modifications to the service templates. The orchestration engineers only need to adapt the model mapping of the domain. The service designer does not need to be aware of the changes, making the end-to-end service description more stable and reusable. 

During the introduction of a brand-new service, the service designer can reuse component service templates to build the new composite service without additional integration. At the deployment of the newly created service, the MDSO can instantiate it with zero-touch automation, because all elementary SDO configurations are generated. 

During the life cycle of a network service, when updates are required, configuration changes in some domains become necessary. As the update operations are done on the MDSO’s service model, any change in the domains can be automated by identifying the configuration objects that correspond to the affected service elements, based on the data model mappings. 

In the pursuit of intent-based, zero-touch network management, automation is the key to managing complexity. The abstract layers enable service design to focus on business value and automate the instantiation to reduce time-to-market and operational costs. The domain-independent, model-driven, common configuration function automatically translates between abstract layers, making it an essential stepping stone on the road ahead. 

Read more:

OSS/BSS evolution for successful 5G monetization - Ericsson 

Service orchestration for better service quality - Ericsson 

Network slicing – operational enablement - Ericsson 

Closing the loop: CSPs aim to automate service orchestration and assurance 

Fuel innovation with service orchestration and assurance | LinkedIn

Ericsson Technology Review: Evolving service management toward intent-driven autonomous networks 

Services Brief Ericsson network orchestration and assurance services 

Solution Brief Ericsson Service Orchestration and Assurance 

Solution Brief Accelerating 5G business growth with Ericsson Dynamic Network Slicing