The document compares the ETSI MANO framework to the ONAP framework for orchestrating virtual network functions (VNFs). Both frameworks include functions for orchestrating, controlling software-defined networking, and managing generic VNFs and virtualized infrastructure managers. However, ONAP separates the service-level and resource-level flows for lifecycle management and leaves timing of resource allocation to the orchestrator, while MANO specifies interfaces and information flows.
The document compares the ETSI MANO framework to the ONAP framework for orchestrating virtual network functions (VNFs). Both frameworks include functions for orchestrating, controlling software-defined networking, and managing generic VNFs and virtualized infrastructure managers. However, ONAP separates the service-level and resource-level flows for lifecycle management and leaves timing of resource allocation to the orchestrator, while MANO specifies interfaces and information flows.
The document compares the ETSI MANO framework to the ONAP framework for orchestrating virtual network functions (VNFs). Both frameworks include functions for orchestrating, controlling software-defined networking, and managing generic VNFs and virtualized infrastructure managers. However, ONAP separates the service-level and resource-level flows for lifecycle management and leaves timing of resource allocation to the orchestrator, while MANO specifies interfaces and information flows.
The document compares the ETSI MANO framework to the ONAP framework for orchestrating virtual network functions (VNFs). Both frameworks include functions for orchestrating, controlling software-defined networking, and managing generic VNFs and virtualized infrastructure managers. However, ONAP separates the service-level and resource-level flows for lifecycle management and leaves timing of resource allocation to the orchestrator, while MANO specifies interfaces and information flows.
2. Create VNF Object The ONAP “Assign” perhaps corresponds to both the MANO “Create VNF” (which for some 3. Assign VNF reason is not shown on this MANO diagram; See section 5.3.1 of ETSI GS NFV-SOL 003 V2.3.1) and the initial processing of the “Instantiate VNF”? Perhaps in ONAP we should 4. Create VNF in Local Inventory; Make VNF Network Assignments also create the VNF in the Gen VNF’s Controller’s local inventory (if different than SDN-C)? For Each VDU in the VNF Initial Configuration 5. Create VDU Object 6. Assign VDU
7. Create VDU in Local Inventory; Make VDU Network Assignments
MANO provides for NFVO to perform the VIM interactions, but has the VNFM control the timing of the call to VIM. In ONAP the timing of the resource allocation is left to the Orchestrator. This would allow ONAP to support the common scenario whereby we want to perform all of the “Assign” operations first for the VNFs in a given Service instance prior to actually realizing that design with any real network resources.
8. Instantiate VDU Cloud Resources
9. Result of Request
In MANO, the realization of the VNF in the cloud is VNF
always immediately followed by configuration of the 10. Configure VNF (VNF) VNF with its “deployment specific parameters”. This is usually the proper sequence, but no guarantee that 11. Configure VNF (VNF Level; deployment specific parameters) cross-VNF interleaving of these operations may be 12. Notify VNF Instantiated needed in some cases. Thus in ONAP these operations are individually under Orchestrator control. 13. Notification of VNF as managed device 14. Configure VNF (Service Level, App-Specific Parameters)
I am not aware that AT&T or the ONAP community has yet implemented two separate levels of configuration of the VNF, once at the Resource and once at the Service level. However such an interaction may well be needed in cases of more complex Services so I have added it here to match what I understand to be the ETSI equivalent. ETSI MANO (White Background) ONAP (Green Background)
Control Loop Orchestration SDN Generic VNF
Controller Controller A&AI VIM (Resource Level Flow)
1. Scaling Request (VNF, +1 Units)
The request for a “Lock” of the VNF Controller can be
2. Validate Request (conflict check) thought of as part of a feasibility check for scaling.
The “Assign” request can be thought of as “preparatory 3. Determine VNF Controller (Assume Gen VNF) work” that must take place in the VNF Controller. 4. Request Lock (VNF) MANO provides for NFVO to perform the VIM interactions, but has the VNFM control the timing of the call to VIM. In ONAP the timing of the resource For Each VDU in a “Scale Up” Request allocation is left to the Orchestrator. This would allow ONAP to support the common scenario whereby we 5. Create VDU Object want to perform all of the “Assign” operations first for the VNFs in a given Service instance prior to actually 6. Assign VDU realizing that design with any real network resources. 7. Create VDU in Local Inventory; Make VDU Ntw Assignments
8. Instantiate VDU Cloud Resources
9. Result of Request
ONAP vendor guidelines specify that scaling a VNF should be
a “plug and play” exercise, and not require any configuration of the VNF to recognize any newly added VDUs.
(Cultural Encounters in Late Antiquity and the Middle Ages, 41) Ildikó Csepregi - Incubation in Early Byzantium_ The Formation of Christian Incubation Cults and Miracle Collections-Brepols (2024)
