Promise Resource Reservation 09 November 2015 Peter Lee, ClearPath Networks, PTL Ildikó Váncsa, Ericsson Gerald Kunzmann, DOCOMO Euro-Labs OPNFV Summit 2015

Content Overview Uses Cases and Requirements Architectural Considerations Implementation Design and Demo Summary and Next Steps Q&A

Promise overview Key requirement (short-term goal) Long-term goal Guarantee that at start time of a reservation, all reserved resources of that reservation are ready to be used/allocated As-Is: Without reservation, when trying to allocate resources required for a (complex/composed) network service (NS), it may happen that during the individual allocation requests (for compute/storage/network) an error occurs, as not sufficient resources with the requested characteristics are available, and the overall instanstiation of the service may fail. Assumption: NFVI has limited resources Long-term goal Efficient resource usage, e.g. Before start time, allow for other usage of the resources before start time, instead of immediate allocation. After start time, resources may be used for „best effort“ services, but shall immediately be made available for the reserved service at time of the allocation of the reserved resources. Use cases / scenarios (see also ETSI NFV IFA010) Scheduled event: e.g. rock concert or football match with expected peak traffic Detailed capabilities: VIM holds detailed information about managed NFVI resources and their availability, whereas the NFVO only holds abstracted information. 5G services: many virtualized service that have to share limited resources Disaster: valuable limited time after e.g. tsunami warning Multi-tenant deployment: avoid resource management race conditions IFA010: A.2.2.1 Use case for securing resources for several tenants NFV and the management and orchestration framework enable tenants to request and make use of virtualised resources provided by the platform. VIM manages the NFVI and offers to consumers (tenants) operations for managing virtualised resources. In NFV deployments, several tenants can coexist, and in this scenario resource management race conditions can happen, ending in resource service denegation. In carrier telco environments, with stringent SLAs, reliability and performance requirements, resource service denegation can become an issue. The NFVO plays a key role in the NFV-MANO, as central point for orchestrating the resource consumption by VNFs and Network Services and granting the lifecycle operations. The NFVO cannot guarantee resource availability during the granting of a VNF lifecycle request if the resources needed to accommodate such lifecycle operation have not been secured (i.e., reserved) by the VIM, entity responsible for the NFVI resources management. A.2.2.2 Use case for securing resources with detailed capabilities The VIM, as end point for managing and controlling the NFVI resource holds more detailed information about the managed resources and their availability. At the NFVO, visibility of specific resources is not the same as the VIM. The NFVO holds information about the availability, reserved and allocated NFVI resources as abstracted by the VIM. Examples of more detailed information are specific acceleration capabilities, CPU-pinning, etc. This information is visible at the VIM level in order to execute the right allocation of virtualised resources according to the resource capability requirements. If such capabilities are needed, and the NFVO has no visibility on the particular resources accommodating such capabilities, granting the VNF lifecycle operations can lead to undesired resource service denegation, in particular those that follow with subsequent virtualised resource management requests for detailed capabilities. A.2.2.3 Use case for securing resources during Network Service instantiation A Network Service (NS) can be composed of a number of VNFs, virtual links to interconnect them, etc. In order to realize a NS, it is possible that a great quantity of NFVI resources will be needed. Thus, the instantiation of an NS will be possible as long as all the resources can be secured to be available at the time of the instantiation of the NS. The instantiation of an NS can involve several transactions, with possibly a number of different VIMs managing the required NFVI resources, and VNFMs managing the lifecycle of the VNFs to instantiate. During the instantiation process, if resources cannot be secured to be available by the VIM(s) for the Network Service, the overall instantiation can fail. This can lead to inefficient processing and arrangement of Network Services instantiation. A.2.2.4 Use case for securing resources during Network Service scaling A Network Service can be composed of a number of VNFs, virtual links to interconnect them, etc. In order to realize an NS, as well as for scaling purposes, it is possible that a great quantity of NFVI resources will be needed. Moreover, under certain scenarios, such as sport events or natural disasters, operators require that Network Services can scale to accommodate the extra traffic to handle. Such NS scaling requires adding extra resources to be used by the VNFs part of the NS, or news ones to be instantiated. By reserving resources in advance against the VIM managing the resources, it is ensured that NS can scale properly. A.2.2.5 Use case for securing resources related to a scheduled event Network Services or certain capacity may only be needed for a specified duration. For instance, the duration of a scheduled sport event is usually known in advance, i.e., with an expectation to be ended at some point in time. To support the event, the operator may need to add extra Network Service capacity or instantiate a new Network Service. In this scenario, the service provider wishes to secure the instantiation of new VNF instances, or the expansion of existing instances for the Network Service by reserving underlying NFVI resources. The present use case exemplifies the need for the NFVO and VIM to handle reservation time information. As part of the NS instantiation/expansion, the NFVO requests to the appropriate VIM(s) the reservation of virtualised resources needed by the VNF instances. In addition, the NFVO provides information about the expected timespan where the virtualised resources will be used, i.e., it provides start and end time information. The time information may either be the same or have certain deviation from the scheduled event timing to allow for certain backup time. This information about start and end time helps the VIM to determine the best scheduling of resources and their availability in the NFVI-PoP(s). This is particularly applicable when scheduling resources for multiple future events, i.e. the VIM will know about reservations that have been scheduled but whose reserved resources are not being used yet or reservations that have been scheduled, but whose reserved resources will be freed prior to another reservation.

High level flow with ETSI NFV architecture incl. allocation Orchestrator (NFVO) NFVI Virtual Compute Virtual Storage Virtual Network Virtualization layer Hardware resources VNF 1 VNF 2 VNF 3 EMS 1 EMS 2 EMS 3 OSS/BSS 3. LCM operation granting (reservationId, …) Or-Vi VNF Manager 1. ResourceReser-vationRequest (start, end, expiry, resources, amount, attributes) 2. ResourceReser-vationResponse (reservationId, message) 4. ComputeAllocation Request (reservationId, flavour, attributes, …) Virtual Infrastructure Manager 5. NotifyAllocated Nf-Vi

Challenges Back to the Future effect Complexity of OpenStack Simultaneous handling of reservation and immediate allocation requests Reserve/allocate resources without end time Complexity of OpenStack Complex, multi-dimensional resource model No feature loss by introducing reservation as a feature Integration Multiple OpenStack components to integrate with (Nova, Cinder, …) OpenStack is not ready

Shim-layer approach Pros Cons Consumer A Consumer B Flexible API update No direct need for integration with OpenStack modules Multi-site support for reservation Cons Synchronization API changes System state No handling of complex, structured resources No affinity/anti-affinity rule support Hides VIM I/Fs Consumer A Consumer B Shim-layer (w/ allocation+reserv. logic+policies) OpenStack (Nova, Neutron, Cinder) Reservation + alloc./termin. requests Allocation/termination Sync capacity

OpenStack integrated approach Pros Pure extended VIM I/Fs No synchronization need VIM APIs are used Code changes in VIM are synchronized automatically The solution is maintained by the upstream community No need to remodel resource structure in VIM Cons Integration with multiple OpenStack resources Nova scheduler is not ready Blazar project is on hold Consumer A Consumer B Reservation + alloc./termin. requests OpenStack + BlazarX w/ policies for dealing with reserved resources

Evolution of the solutions Shim-layer approach as a prototype API definition Basic functional testing Gap analysis in OpenStack in parallel OpenStack integrated approach As a next step Optimize the solution in steps Block reserved resources Reuse reserved resources Introduce priorities Collaborate with OpenStack projects like Nova, Neutron and Cinder Shim-layer (w/ allocation+reserv. logic+policies) OpenStack + BlazarX w/ policies for dealing with reserved resources

Implementation Overview Intent-driven N/B Interfaces create/update/cancel/query reservation increase/decrease/query capacity create/destroy instance Supported Interfaces CLI, REST/JSON, WEBSOCKET, BROWSER Model-driven Implementation YANG (data model schemas) YAML (control logic definitions) JSON (configuration data) JSX* (visualization schemas)

Data Model Hierarchy Everything is a ResourceElement ResourceInstance ResourceContainer ResourceCollection ResourcePool ResourceReservation ResourceAllocation ComputeElement Models… NetworkElement StorageElement Everything is a ResourceElement Attributes and Behavior Inheritance Polymorphic Relationships ResourceCollection contains temporal attributes – start and end ResourcePool represents what’s available between a given time window ResourceReservation represents what’s planned for use between a given time window ResourceAllocation represents what’s currently being consumed

Modular and Portable Design REST/JSON External Integration Web Sockets Data Synchronization CLI Automation User Interaction Browser Visualization Promise YangForge Models Web Browsers Node.js Promise runs on YangForge YANG schemas opnfv-promise.yang, nfv-infrastructure.yang, nfv-mano.yang, etc… YAML control definitions opnfv-promise.yaml JSON configuration data opnfv-promise.json YangForge runs on Node.js and Web Browsers

Promise Live Demonstration Create Reservation Query Capacity Create Instance Visualizations … and More! OPNFV Project Theater Thursday 2:25 - 2:45pm Promise - Planning the Future Peter Lee, ClearPath Networks Gerald Kunzmann, DOCOMO

Promise is all about the Future Summary and Next Steps Promise is all about the Future Seamless integration with VIMs Moving beyond capacity to capture Elements Proactive and Reactive Notifications Interactive and Dynamic Visualizations Scenario planning with Simulations Come and see the live demo @ 2:25pm Join the Promise project!

Promise Info

BACKUP

Software Design Architecture

Promise Status Requirement study, architecture design, Gap analysis Initial Work Done – “Stable Draft” in https://wiki.opnfv.org/promise Refinement activities ongoing Architectural options and information flows Additional scenarios, e.g. reservation update due to resources still allocated at end time Proof-of-concept demo Based on Shim-layer approach OPNFV Project Theater on Thursday 2:25 - 2:45 Standardization Sync On-going ETSI NFV IFA: https://docbox.etsi.org/ISG/NFV/Open/Drafts/ ETSI TST is comparing OpenStack APIs and ETSI NFV IFA specs http://nfvprivatewiki.etsi.org/index.php?title=VIM_to_OpenStack_APIs