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

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

3. 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 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 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 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 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 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.

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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)

10. 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

11. 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

12. 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

13. 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 2:25pm
Join the Promise project!

14. Promise Info

15. BACKUP

16. Software Design Architecture

17. Promise Status Requirement study, architecture design, Gap analysis
Initial Work Done – “Stable Draft” in
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:
ETSI TST is comparing OpenStack APIs and ETSI NFV IFA specs