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)– 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

4

High level flow with ETSI NFV architecture incl. allocation

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

Virtual Infrastructure

Manager

VNF ManagerVNF

ManagerVNF Manager

Orchestrator (NFVO)

1. ResourceReser-vationRequest(start, end, expiry, resources, amount, attributes)

3. LCM operation granting(reservationId, …)

2. ResourceReser-vationResponse(reservationId, message)

4. ComputeAllocation Request (reservationId, flavour, attributes, …)

Nf-Vi

Or-Vi

5. NotifyAllocated

5

Challenges

• Back to the Future effect

– 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

Consumer A Consumer B

Shim-layer(w/ allocation+reserv. logic+policies)

OpenStack(Nova, Neutron, Cinder)

Reservation + alloc./termin. requests

Allocation/terminationSync capacity

• Pros

– 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

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 + BlazarXw/ 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 + BlazarXw/ 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

– 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

• 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

YangForge

Models

Web Browsers Node.js

REST/JSON

External Integration

Web Socke

ts

Data Synchronization

CLI AutomationUser Interaction

Browser

VisualizationUser Interaction

12

Promise Live Demonstration

OPNFV Project Theater Thursday 2:25 - 2:45pm Promise - Planning the Future

Peter Lee, ClearPath Networks

Gerald Kunzmann, DOCOMO

• Create Reservation

• Query Capacity

• Create Instance

• Visualizations

• … and More!

13

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!

14

Promise Info

15

BACKUP

16

Software Design Architecture

17

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