Functionality

Unified lifecycle model

The standard lifecycle model is a key enabling factor for intent-based automation. To drive automation, the orchestration component of IBM Cloud Pak for Network Automation uses a standardized lifecycle model which requires all the underlying artifacts, network services and virtualized network functions (VNFs), to look the same to the orchestration component. Each artifact of a network service will be expected to go through the same lifecycle with defined lifecycle transitions.

Each artifact in a network service is optimally stepped through this lifecycle concurrently with others accounting for the declaratively identified dependencies. For example, on installation each artifact will be moved to the Installed state together before they are moved to the Inactive state. Only the lowest level artifacts (VNF components) have transition steps defined that will be performed as the network service progresses through the lifecycle.

Intent-based automation

Intent-based automation is comparable to a satellite navigation system. In order to go from A to B, you only need to enter the destination and the satnav works out the best way to get there. You do not need to manually program each turn. If there is a roadblock or a traffic jam, the engine works out the best alternative route without you having to manually reprogram the route.

The orchestration component of IBM Cloud Pak for Network Automation works in a similar way. Rather than programming all individual lifecycles for all possible lifecycle scenarios (such as upgrade and migration) the engine automatically generates and executes all lifecycles for VNFs and network services.

The intent engine (one of the core microservices) in the heart of the orchestration component has the responsibility for driving network service instances through their lifecycles according to the intent requests it receives. With support from other orchestration services, like catalog and topology, the intent engine resolves the necessary network service level actions, breaks them down to VNF and eventually to VNF component level lifecycle transitions, and works out the correct order to execute the steps. The exact sequence of execution steps depends on the model of the network service, the current state of the service, and the requested target state and pattern of the service. Finally, the intent engine pushes the corresponding requests to the responsible resource managers to complete through the southbound APIs of the orchestration component.

The detailed execution plans are stored by the orchestration component to enable real-time monitoring of the progress of currently active intents as well as browsing the intent history for a specific network service instance.

Intents can be requested through a set of API endpoints on the northbound API of the orchestration component. Requests can be triggered by an external northbound system or they can be manually requested through the network automation UI which then calls the corresponding API end point.

Behavior-driven testing

The orchestration component of IBM Cloud Pak for Network Automation has in-built behavior-driven testing capability functioning as an automated test framework for VNF and network service testing. While intent-driven automation automates the production lifecycle of your network services and associated resources, behavior-driven testing, together with CI/CD Hub, helps you to automate your service development processes. Automated behavior-driven testing reduces manual effort and errors in production.

In development and preproduction phase, the orchestration component’s behavior-driven testing can automatically spin up test environments, network service under test, and additional test VNFs such as probes and traffic generators, and run through full test scenario of all lifecycle states.

While services are deployed in production environment, ready-for-service testing can be invoked automatically so that the network service is first tested in full before being released to the customer.

Once designed, the test scenarios will be part of the VNF or network services package. Test scenarios can be either run directly from the network automation UI or triggered through its APIs enabling full automation and integration to CI/CD Hub pipelines.

Mapping to industry standards

In recent years the industry has been actively generating standards for NFV. NFV specifications are published on a regular basis by various industry forums. Those include ATIS, Broadband Forum, ETSI NFV ISG, IETF, ONF and others. In parallel, open source projects have been established to accelerate NFV adoption. The most recent and notable initiative within the orchestration area is the Open Network Automation Platform (ONAP) that is joining two projects: The Enhanced Control, Orchestration, Management and Policy (ECOMP) and the Open Orchestrator (Open-O). IBM closely monitors relevant forums and partners with key industry contributing members.

ETSI has introduced a number of key concepts that provide a language for describing an NFV environment. The following figure shows a mapping of IBM Cloud Pak for Network Automation concepts to ETSI definitions. The ETSI terminology/concepts are shown in the figure mapped to IBM's core concepts, that is, Assembly Descriptor (AD) and Resource Descriptor (RD).

How a VNF vendor has engineered their software will determine how many resource descriptors it presents to IBM Cloud Pak for Network Automation. For example, a native Cloud style VNF implementation could provide many Resource Descriptors representing micro-services that are assembled into VNF components, which are in turn assembled into VNFs.

Conversely, a VNF vendor may provide a single resource representing a complete VNF function. These resource descriptors in any case are re-assembled into an architecture specific to the service providers' environment and service design, once again by layering assembly descriptors and relationships.