Overview
This white paper explores the major challenges associated with deploying large-scale multi-domain service orchestration architectures for service provider networks and how the Itential Automation Platform addresses those challenges through:
01 Rapid Integration Capabilities & Flexibility
02 Accessibility & Ease-of-Use of Orchestration & Automation
03 Highly Scalable Orchestration to Meet Growing Demands
Key Components of an Orchestration Platform
In order to explain the impact of the challenges faced when deploying large-scale multi-domain service orchestration architectures, it will be necessary to explain two components of orchestration platforms that have a significant impact on flexibility, cost to implement, and total cost of ownership – data models and interfaces.
Data Models & Interfaces
While there are multiple components and capabilities associated with multi-domain service orchestration solutions, there are two areas that have had a significant impact on flexibility, cost to implement, and total cost of ownership – data representation (models) and communication interfaces. The data models define how information is structured within the box, while interfaces are represented by the arrows between the boxes.
The multi-domain architecture shown above is similar to others defined by standards bodies like 3GPP, IETF, and organizations like TM Forum. Separation of multi-domain orchestration activities from domain-specific orchestration, and the division of multiple technology domains allows for each domain to be defined based on the characteristics, management tools, and processes unique to each domain. For example, the tools and processes for managing assets in a cloud domain are very different than the tools and processes used in an optical network.
The architecture also reflects the need for a cross-domain orchestration, sometimes called a multi-domain service orchestrator (MDSO) function to coordinate activities between and across the domains, and the need for interactions with multiple layers of service assurance and inventory (usually at service and resource layers, with the domains containing the resources).
As stated earlier, the difficulties for orchestration architects arise in establishing agreement on how data should be structured and represented within the boxes (the data models) and how communications between boxes should be defined (the interfaces)
Data Representation & Data Models
The data model defines how objects and the relationships between objects are represented. Usually, a data model for a given domain or technology will accurately reflect the characteristics of that technology – so a data model for a cloud domain will be structured to best represent cloud objects, while the model for a 5G mobile core domain will be designed to represent the types of objects, policies, and relationships between 5G core network functions. Within any given domain, the data model should be sufficient to represent the network functions, data, and relationships for every component of that domain. Normally there is no challenge inside of the domain – domain controllers and orchestrators are designed with the appropriate data model in mind.
However, in an environment where there are multiple domains, each domain will have a model that is optimized for the technologies within that domain – so multiple data models will exist simultaneously. The architects responsible for designing (or choosing) the domain data model will need to consider how best to expose their model for users outside the domain who wish to access domain resources. After the domain architects have selected their data models and designed how they wish to expose those models to others, the focus can shift to the architect of the MDSO to begin the process of designing and orchestrating services across the domains.
Interfaces & APIs
Once the data model has been developed, the domain architect must decide how best to expose that model. This type of interface is normally referred to as an Application Programming Interface (API). Any API should be a reasonably complete representation of the types of capabilities and services that a domain will provide. The API may also provide visibility to the operational state of objects (network functions, controllers, etc.) within the domain.
SCENARIO 01
Integration
In scenario one, one end of the communication path takes responsibility for adapting to the other domain’s protocols. Often this is the responsibility of the MDSO, since its primary role is to provide orchestration across and between all the domains. Most MDSOs have a mechanism to facilitate the integration, typically called something like a connector or adapter. So for each new domain/controller, the MDSO team needs to develop a new integration. For some systems, this is performed through software development and testing, which can take multiple months. Each time the domain API changes, this integration must be updated. For systems designed around custom integrations, this effort can add significant time and cost to orchestration projects, as well as ongoing lifecycle costs to maintain.
SCENARIO 02
Standardization
In the second scenario, orchestration architects select an architecture based on standardized data models and interfaces, such as the APIs defined by the Telemanagement (TM) Forum. These models were developed as a reaction to the costs, time, and effort associated with the integration approach. Each of the APIs defines a minimum, standardized set of functions and capabilities to be provided by the appropriate system. For example, a system that performs service ordering functionality can utilize the TMF641 Service Ordering REST specification to request and provide a common set of service order functionality.
By utilizing these standards, architects could require each of their vendors to conform to the API appropriate to their systems, which in theory would avoid the costly integration cycles and enable a shorter project timeline.
With data models and interfaces now explained, the challenges can be addressed.
Key Challenges of an Orchestration Platform
CHALLENGE 01
Standards Take Time & Limit Flexibility
The standards-based approach to integration promises reduced effort and faster implementation than a development-driven integration. While this may be true in some cases, it creates some limitations that should be considered by architects and implementers.
First, standards typically lag new technologies and capabilities, and changes to standards can take months, if not years. Second, the goal of standards is to provide a common, generic set of APIs that can apply to products from multiple vendors. To accommodate this, standards typically follow a “lowest common denominator” model, where the focus of the APIs is on features and functions that are common to all platforms. The downside of this is that it prohibits implementers from incorporating differentiating features into their services, as there will be no support for unique vendor capabilities in the generic models. Every service that is offered on a standards-based implementation will be the same as a service offered by competitors that also follow the standard.
CHALLENGE 02
Technology (Especially the Disruptive Kind) is Unpredictable
The second challenge faced by many service orchestration implementations is that orchestration platforms designed around specific data models are hard coded to those models, and are unable to evolve to support new, disruptive technologies. For example, the transition from physical network functions to virtual functions required a new set of tools, but any tools that were designed with data models based on virtual machines (VMs) were challenged to adapt when many in the industry made the move from VMs to containers. Any disruptive technology, by its nature, will give competitive advantages to those who are able to quickly bring products based on the new capabilities. To do this requires orchestration systems and tools that are flexible and easily adaptable to change – and most are not, being based on fixed schemas and hard coded around existing, mass market technologies and services.
CHALLENGE 03
The Costs of Development-Heavy Platforms
To provide some levels of flexibility, many orchestration platforms are designed with the capability to support a wide range of services and technologies – but only through a high level of software development, both for the initial deployment and for the ongoing lifespan of the orchestration platform.
These costs manifest in multiple ways – the software licensing costs may be comparatively low, only to be eclipsed by high software development costs in the form of integrations, workflow development, customizations, and new feature development. Once the solution has been deployed, these solutions require ongoing professional services and software development investments to maintain existing code and to develop enhancements and new flows.
Total cost of ownership has become an important factor in the selection of orchestration platforms and in the decisions to move/migrate to new systems. Orchestration platform vendors, like Itential, have differentiated by offering platforms that have lower cost of ownership due to code-free integrations, dynamic object creation, and other features that enable domain experts to develop and manage their own orchestration and automation flows.
The Design Principles Needed in an Orchestration Platform
To address these challenges, Itential created a new type of orchestration platform based on the following principles:
PRINCIPLE 01
Rapid integration capabilities and flexibility are mandatory.
New technologies and capabilities are becoming available at a rate that far surpasses the rate that IT integration teams and standards bodies can accommodate. For example, in the past five years the focus of service providers has shifted from virtualization to containerization as the preferred method for network function deployment and management. Orchestration systems that are hard coded to specific technologies are limited to those technologies.
Another area that has historically been an impediment to rapid progress has been integration with OSS and ITSM systems. Virtually all other orchestration systems require development-heavy, time/cost consuming integration efforts to perform integration with external systems – even when both sets of endpoints conform to standards like TMF APIs. Itential enables rapid integration, that can be performed by end users in minutes, eliminating costly integration efforts and enabling new, more robust, orchestration flows. This capability has enabled Itential to become the platform of choice for service providers who wish to bring new services and capabilities to market quickly.
PRINCIPLE 02
Orchestration and automation must be accessible and easy to use regardless of domain or development skill level.
Orchestration and automation platforms have been predominantly based on older, development heavy software technologies, and subsequently have required significant investments in professional services and software development expertise to deploy and maintain, diminishing business value by increasing total-cost-of-ownership and extending program durations unnecessarily. The Itential Automation Platform is built on a true low-code paradigm, not only for creation of integrations as mentioned above, but also for design of automation/orchestration flows and activities such as payload data transformation and policy design/execution.
Additionally, Itential maintains an open source repository of pre-built workflows and orchestrations that end users can deploy immediately. The net result of this focus on accessibility and ease-of-use is that a larger proportion of the technical community can participate directly in the development, testing, and operation of service orchestrations. Technical subject matter experts can work with tools and concepts that make it easy to translate their expertise into orchestrations. Itential does not expect or require its customers to commit to lengthy professional services engagements. The majority of Itential customers are 100% self-sufficient with the platform, having been trained through the Itential enablement team.
PRINCIPLE 03
Orchestration must be highly scalable to meet the growing demands of global operators.
In the service provider environment, the size and scope of the infrastructure, and the explosive growth in the rate of change in that infrastructure, places heavy demand on the orchestration infrastructure for availability, performance, and scalability. Itential is built on a modern technology stack designed to scale up to the largest networks in the world. The solution supports multiple deployment options to meet the needs of a diverse user community and has demonstrated the ability to perform more than 200 million automated transactions in one month in a production environment for a Tier 1 service provider. This vision has been realized by many Itential customers, including 4 of the top global wireless service providers and Tier 1 wireline/business service providers like Lumen.
Today the Itential Automation Platform is providing service orchestration in production networks for such use cases as:
- Enterprise wireless customer service activation and service lifecycle for 4G and 5G, including cross-domain orchestration of transport (TN) and Core domains.
- Service orchestration for fixed access B2B and B2C across a range of fixed access technologies.
- Orchestration of 5G core and IMS pods.
- Orchestration of wireless edge, including edge site creation/lifecycle management, tenant placement and networking, and cloud network orchestration,
- Wireless transport network creation and day 2+ lifecycle for 4G and 5G.
- Mobile core (4G/5G) service orchestration.
- Orchestration of network migration and network evolution.
- TMF-compliant service orchestration for mobility services.
- Cross-domain service orchestration (mobile core, access, IP domains).
The further clarify this point – There are three capabilities of the platform that are unique to Itential, giving Itential a competitive advantage:
Itential’s Unique Automation & Orchestration Capabilities
The Itential Automation Platform is designed for flexibility and extensibility. It performs a wide range of orchestration functions (cross-domain, single domain, network slicing, NAAS, closed-loop) and is highly customizable.
Itential believes that it will be critical for operators to select orchestration solutions that provide the lowest cost to implement, operate, and to modify. These capabilities are the foundation of Itential. Activities that are typically costly and time consuming with comparable orchestration products from other vendors, such as integration, customization, and orchestration flow development, require significantly less time and effort with the Itential Automation Platform. Itential users have been able to launch new services in a fraction of the time that it takes with competing solutions.
Itential believes that it is impossible for any service provider or vendor to be able to predict new innovative capabilities, services, and network functions. One example of such a change was the shift from VIM-centric implementations to CISM-centric implementations. Vendors who hard-coded support for VIM were forced to undertake massive development efforts to pivot to CISM. Itential was able to make the pivot in days, through customization of templates and dynamic generation of integrations with the Itential Adapter Builder web app.
Data Representation & Flexible Model Support
The platform utilizes JSON and JSON schema for internal data representation. Inbound payloads are normalized to JSON and internal orchestration activities are performed using JSON and JSON schema. This approach provides a higher level of flexibility than orchestration platforms that are limited to specific schemas or object types. Particularly in situations where orchestration platforms are designed around traditional networks, components are unable to easily accommodate cloud and container object types. This capability is what enables Itential to comply with the diverse sets of functionalities requested by service providers. The Itential Automation Platform can not only support TMF SID models, but any other resource/data model. When changes inevitably occur, such as the introduction of a new resource type, it takes only minutes for an Itential user to create the new schema object and schema mappings using the graphical JSON Schema Transformation tool provided by Itential. Other orchestration platforms are dependent on roadmap or professional services for this type of support.
Dynamic Object Creation
Itential utilizes its ability to understand models like YANG, as well as its integration capability, to dynamically generate objects such as workflow tasks and input forms. When an Itential user creates or onboards an integration on the platform, all relevant workflow tasks and objects are created dynamically. This is significantly different than platforms that are based on BPMN or similar technologies. With BPMN-based systems, every service task in a workflow requires a script, microservice, or API call. This creates an extra step, where each workflow task has its own code development, testing, lifecycle management needs. Itential requires none of this effort, saving significant time and effort over BPMN-based systems .
Object Federation
When Itential connects to a southbound system, the platform dynamically learns about all the objects (xNFs, services) controlled by that southbound system and organizes that information through federation. With federation, users and systems can utilize the system to easily do things such as:
- View and interact with a global list of network functions or service instances, regardless of the underlying controller, orchestrator, or EMS/xNMF.
- Provide a single network API to applications and OSS to simplify interactions with those systems. The OSS does not need to understand which controller, or which type of controller, a device is connected to – it can utilize device federation to and simply name the device it wants to make the change on, and the federation system will determine the best way to route and execute the request.
Conclusion
Now that many organizations have deployed service orchestration capabilities and are looking to expand their orchestration platforms to incorporate end-to-end multi-domain service orchestration capabilities, their decision criteria should evolve based on their experiences and the experiences of others. The multi-domain orchestration layer presents different challenges than the domain-specific layer, and the vendors that had advantages within domains (typically the same vendors that provide the network functions within their domain), are at a disadvantage in the multi-domain layer.
Itential agrees with industry analysts, such as ACG Research, that there is a significant advantage to service providers that select multiple vendors for their multi-domain orchestration solution. In their 2020 report “Service Provider Directions in Network Automation,” ACG predicts that while the xNF/domain vendors will have significant advantages for domain orchestration of their respective domains, multi-domain orchestration will be better performed by independent software vendors, like Itential, that focus their competencies on rapid integration and ecosystem engagement.
There is also strong interest in simplifying the deployment of end-to-end services that span multiple layers and domains. This is an inherently multivendor, multidomain undertaking, one that often also has important end customer-facing functions. CSPs tend to work with independent software solution providers that have the requisite depth of vendor ecosystem engagement and application expertise, in this portion of their operations.
