You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

This section aims to present an end-to-end use case where the 8 LFN projects work in harmony to deliver a "service" that includes VNFs, connectivity and analytics-powered assurance as shown in the following picture:



In this example, 2 VNFs (for the sake of simplicity, provided by the same vendor) must be deployed on top of an NFVI (e.g., OpenStack), be interconnected and provided with external connectivity to the Internet. Moreover, the VNFs require network acceleration and the whole service must be assured using Analytics driven closed loop operations.

Using the 8 LFN project, an end user (e.g., a carrier) can realize the above as follows:

Phase 0 - Building the network infrastructure and preparing the network functions

Following the CNTT Reference model, the operator decides which CNTT Reference Architecture may best suit its needs. This is followed by picking a set of infrastructure components that fits a CNTT Reference Implementation of choice. The infrastructure is built using the deployment tolls and CI/CD provided by OPNFV. Next, the infrastructure is certified using the CNTT RC and OPNFV CVC.

Several LFN projects may be used as infrastrucutre building blocks for addressing the needs of network functions, such as high throughput/low latency networking:

  • Open Switch (OPX) can be used to configure the physical (underlay) network that connects the physical hosts used to deploy OpenStack (Mike Lazar is this correct? can OPX being instructed by ONAP? Should it?)
  • FD.io provides data plane network acceleration through its Vector Packet Processor (VPP). (it would be great to have ONAP instructing FD.io.Or perhaps ODL can do it? Abhijit Kumbhare)

VNFs are prepared for deployment and inclusion in network services:

  • An NFV vendor pre-validates and certifies a couple of VNFs (i.e., VNF1 and VNF2) through the OPNFV Verification Program (OVP). (Bin Hudo you think we should/could expand?)
  • The NFV vendor ensures that the VNF complies with the ONAP VNF requirements. This will enable ONAP to properly control the lifecycle of the VNF as part of a network service.

Phase 1 - Network service design and deployment

At design time, ONAP is used to onboard the VNFs that are compliant with the ONAP requirements and pre-certified using the OPNFV CVC . Those compliant resources can later be used to design any E2E service using ONAP Service Design and Creation (ONAP SDC).

At runtime, ONAP orchestrates the deployment of the whole service either through ONAP internal projects or leveraging the capability to interwork with 3rd party projects.

In particular, ONAP Service Orchestrator (ONAP SO) instructs the underlying ONAP projects in order to deploy all of the elements that compose the end-to-end service.

ONAP deploys the VNFs in the available NFVi and the overlay network connecting them using ONAP SDN-C. SDN-C uses its OpenDaylight based architecture to model and deploy the L1-L3 network. Next the ONAP APP-C is used to configure the network functions and their L4-L7 functionality. This is also done leveraging the OpenDaylight architecture.

By leveraging its SDN-C southbound interface, ONAP instructs Tungsten Fabric to create the external connectivity that will enable customers to "consume" the services offered by the VNFs. (Prabhjot Singh Sethido you think we should/could expand?)

The predefined policies that will control the lifecycle of the network service are designed using the ONAP design-time components such as CLAMP.

Phase 2 - Network service operation

Naturally, being a Network Automation Platform, ONAP plays a central role in the delivery and assurance of the service. The VNFs report their performance and fault data to the ONAP DCAE using the VNF Event Streaming (VES) interface. This information is constantly analyzed and may trigger predefined policies that were created at design-time. The policies are used to invoke closed loop automation actions such as scaling and healing of service components in order to assure the required SLA and respond to changing demands and network conditions.

Finally, closed loop operations may be further enriched by combining LFN Real Time Analytics capabilities of by SNAS.io (we need a SNAS expert!)and the synergies offered by ONAP and PNDA.io (Donald HunterI am sure we can add A LOT more)

  • No labels