Netcracker’s View: Improving ONAP Commercial Readiness With Domain Orchestration

An important step in commercial readiness is to make sure ONAP can effectively address the real-life operational needs of service providers. Let’s look into some specific operational challenges that service providers face on their SDN/NFV transformation journey.

1. Interworking in a “Best-of-Breed” Orchestration Environment

Service providers often select a “best-of-breed” multivendor orchestration solution when it decides to move from the proof-of-concept (PoC) or trial phase into commercial deployment. In this model, particular ONAP modules will need to interwork with third-party commercial or open-source solutions, such as application-specific VNF Managers (VNFMs) or a design-time environment. To achieve this, ONAP needs to support the right level of modularity (click here for our previous blog on ONAP modularity).

2. Ability to Support Hybrid Services

Given that almost all commercial services are hybrid, either the full ONAP stack or particular ONAP modules will need to be integrated with legacy BSS/OSS and third-party SDN controllers to enable end-to-end hybrid service lifecycle automation. To achieve this, ONAP needs to be aligned with industry-standard APIs (click here for more information).

3. Flexibility in Adapting to Operational Settings and Business Goals

ONAP should be flexible enough to adapt quickly to current and future operational settings and business goals of each service provider. Service providers typically start with a simple service like virtualized security or SD-WAN. As they mature and expand their SDN/NFV transformation scope, they require automation of more complex services involving simultaneous management of different geo-distributed virtualized and physical domains, such as customer premises, points of presence, access and transport networks, data centers, etc.

Netcracker has proposed the adoption of domain orchestration in ONAP to support the different operational and deployment scenarios required by the service providers.

What is Domain Orchestration?

Domain orchestration (DO) divides the network or services into specific self-sufficient operational domains that can be automated by the orchestration environment. A domain can be part of the network, a technology or a service. DO includes a specific set of microservices-based modules spanning fault, configuration, accounting, performance, security (FCAPS), SDN control, service fulfillment and assurance to achieve closed-loop automation in each domain.

How Can DO help ONAP With Commercial Readiness?

Domain orchestration increases ONAP’s flexibility in supporting different operational and deployment scenarios by providing the following unique capabilities.

• Ability to compose a specific DO by grouping individual reusable building blocks in a flexible manner, catering to specific service provider needs at a particular stage of its SDN/NFV transformation journey.
• Support of interoperability between the basic building blocks using standard reference points and interfaces.
• Deployment hierarchies that can scale from small, single-vendor virtualized domain to multisite, multivendor hybrid cases.

How ONAP Can Evolve Toward Domain Orchestration?

Netcracker introduced the DO concept in the ONAP “Tiger Team” and played an active role in coordinating different service providers’ views on this topic. Below is the summary of the current work in progress, defining how ONAP’s architecture can evolve towards domain orchestration.

• Deployability of ONAP instances as configurable self-sufficient Dos, fully automating operations within a specific domain as per business needs.
  • ONAP instance as service DO. For example, VPN DO or VoIP DO.
  • ONAP instance as network DO. For example, radio access network (RAN) DO or mobile core DO.
  • ONAP instance as technological DO. For example, IP/MPLS DO or optical DO.
     
• Modularity.
  • ONAP modules, which become the building blocks of each DO, are loosely coupled functional blocks implemented as a set of microservices for independent upgradability, scalability and manageability.
  • ONAP and non-ONAP modules should coexist as part of one DO.
     
• Grouping both domain-specific and reusable ONAP modules across different DOs in order to increase efficiency and flexibility of ONAP deployment.
  • Domain-specific ONAP modules, such as service orchestration, application controller or virtual function controller, provide run-time support for each DO.
  • Reusable ONAP modules, such as service design and creation (SDC), policy framework or common services, can be shared across several DOs. For example, SDC can be used for the design of VoIP and VPN domains.
     
• Standardized Open APIs.
  • ONAP modules should support internal open APIs with each module, exposing its capabilities through standardized APIs and communicating with other modules (ONAP or non-ONAP) only through these APIs.
  • ONAP should support external open APIs to achieve seamless interoperability with other DOs and non-ONAP systems, like legacy OSS or WAN controllers.
     
• Custom DO distributions.
  • Ability to support a DO distribution (the collection of reusable modules and DevOps development pipeline) tailored to specific service provider requirements, e.g. mobile operator distribution, fixed-line operator distribution, transport operator distribution, etc.

These architectural contributions will help increase the production readiness of ONAP to address current operational and business needs of service providers. They will also ensure that ONAP is capable of meeting future needs, such as support for 5G.