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:
<suggested edit by Ranny Haiby - I would recommend adding a section describing building the cloud platform, prior to the "design time" phase described below. This will cover building the infrastructure, and will mention the use of OPX, FD.IO, and the artifacts of the OPNFV projects such as deployment and configuration tools.>
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?)
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?)
Naturally, being a Network Automation Platform, ONAP plays a central role in the delivery and assurance of the service. (Chaker Al-Hakim Ranny Haiby Jason Hunt Fernando Oliveiraplease review and feel free to amend the following micro-section)
At design time, ONAP works in conjunction with OPNFV to onboard such VNFs according to community-led compliance processes. 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 OpenStack hosts and the overlay network connecting them using ONAP SDN-C (based on OpenDaylight) (or perhaps ONAP "asks" ODL via SBI to create the overlay network?)
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?)
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)
Finally, closed loop operations are realized 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)