...
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:
Picture needs an update: VES - VNF Event Stream - from VNF directly to ONAP for VNF feedback loop
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.
...
Following the CNTT Reference model, the operator decides which CNTT Openstack OpenStack based Reference Architecture Reference Architecture (Proposed by Hiroshi Dempo) may best suit its needs. This is followed by picking a set of infrastructure components that fits fit 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:
- OpenDaylight and Tungsten Fabric can be used as3rd party SDN solutions.
As described in the OPNFV Documentation, OpenDaylight uses the standard ML-2 plugin whereas Tungsten Fabric is integrated by means of Tungsten Fabric plugin for OpenStack which implements Neutron API.(Proposed by Hiroshi Dempo)to provide network connectivity. - Open Switch (OPX) can be used to configure the physical (underlay) network that connects the physical hosts used to deploy OpenStack (
Mike Lazaris this correct? can OPX being instructed by ONAP? Should it?) Leaf The network topology may follow the leaf and spine topology as a physical infrastructure is recommended in thethe requirements of physical infrastructure . (Hiroshi Dempo )infrastructure of the CNTT Reference Architecture. - FD.io provides data plane network acceleration through its Vector Packet Processor 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?) Rabi Abdel - Please add more details. The OVP program cover the following certification aspects of VNFs:- Compliancy of VNF Packaging to industry standards such as ETSI and ONAP.
- The ability to onboard and life cycle manage VNFs on a given cloud platform.
- Limited performance characterisation of VNFs.
- 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.
...
At runtime, ONAP orchestrates the deployment of the whole service either through ONAP internal projects functions/components or leveraging the capability to interwork with 3rd party projectscomponents.
In particular, ONAP Service Orchestrator (ONAP SO) instructs the underlying ONAP projects functions in order to deploy all of the elements that compose the end-to-end service.
ONAP deploys the VNFs in the available NFVi 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.
In a case where OpenDaylight manages leaf and spine switch fabric (SDN-based network infrastructure), OpenStack Neutron is a client application of the OpenDaylight SDN controller. OpenStack Neutron interacts with the OpenDaylight SDN controller to manage virtualised networks via OpenDaylight plugin. The OpenDaylight SDN controller interacts with agents running on the host servers OpenDaylight may be used to stitch together the physical switch fabric of the infrastructure with the virtual networking in the NFVI (e.g. OpenStack compute, controller). OpenStack Neutron does not have any features to manage underlay network infrastructure resources. Therefore, ONAP-SDNC works as another client application of the OpenDaylight SDN controller to complement the OpenStack weakness. Through the OpenDaylight-NBINeutron). Through the OpenDaylight Northbound Interface, ONAP-SDNC is able to instruct the OpenDaylight SDN controller for underlay network management. The southbound interfaces (e.g. NETCONF, etc) support interactions with OpenSwitch running on the leaf and spine fabric switches in the NFVI. (Hiroshi Dempo )
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 of the network service are designed using the ONAP design-time components such as SDC and CLAMP.
Phase 2 - Network service operation
...
Finally, closed loop operations may be further enriched by combining LFN Real Time Analytics capabilities of by of SNAS.io (we need a SNAS expert!)and and the synergies offered by ONAP and PNDA.io (Donald HunterI am sure we can add A LOT more). Information about changes in the network topology gathered by SNAS can be used to trigger ONAP policies that will spawn more instances of packet routing network functions. The data analytics capabilities of PNDA may be used to trigger ONAP policies based on data streams produced by all layers of the infrastructure as well as the network functions. ONAP may respond to an infrastructure issue detected by PNDA by migrating VNFs from an affected location to one that is healthy and has the available resources.
...