Post on 20-May-2020
© ETSI 2016
THE NEED FOR A REFERENCE MANO STACK
• One essential component for NFV transformation• Addressing the key NFV deltas• MANO is a reference framework
• Many interpretations of the MANO stack• What does it take to onboard a particular VNF within this MANO environment?• Would that VNF work as expected?• How could I operate a Network Service in practice?• How can I integrate it with the rest of my network and OSS/BSS?
• What translates into industry fragmentation and high entry barriers
• Nee to accelerate convergence on a telco-ready MANO solution• Drive NFV Ecosystem and Adoption
2
© ETSI 2016
THE GOALS
• Delivering a production-quality MANO stack• Aligned to openly available information and data models: ETSI NFV ISG
modeling• Available for everyone: Use open source to minimize uncertainties• Suitable for all VNFs: Capturing real production complexity• Operationally significant: Including service orchestration as well• Decoupled from the supporting infrastructure: VIM-independent
• Enabling an eco-system of model-based VNF solutions• Ready to be offered to cloud and service providers• No need of integration on a per- customer and/or MANO vendor basis
3
© ETSI 2016
THE NATURE
• An Open SourceCommunity hosted byETSI• Easing alignment with
NFV ISG
• Driven by serviceprovider requirements
• Supported by keyplayers in thevirtualization space
• Open recruiting office
4
© ETSI 2016
THE REQUIREMENTS
Addressing the aspects required by deployments in the field5
x100
EPA support Multi-VIM
Decoupled RO and SOMulti-site
© ETSI 2016
THE SEEDS
• And this helps to• Avoid over-engineering due to excess
of abstraction
• Start getting traction at SP level
• Ecosystem steering
• Seed code represents an initialstarting point• All OSM components are pluggable
and/or replaceable
6
• OSM does not start from scratch
• The project starts with runningcode from the beginning• OpenMANO (RO)
• https://github.com/nfvlabs/openmano
• Juju charms (VNF models &configuration)• https://jujucharms.com
• RIFTware Launchpad (SO/NSmanagement)• https://github.com/RIFTIO/RIFT.ware
© ETSI 2016
THE BOOTSTRAP
7
Kick-off 1st Release
Proof that the Communitycan do anything together
Demo
Seed code
ReleaseZero
Sound starting point forjoint evolutionary work
Community release withmore desired features
Kick-off 1st Release
No code • Very limited features• Proof that the
Community can doanything together
OTHERPROJECTS
© ETSI 2016
THE BASIC CONCEPTS
• Resource Orchestration (RO)• Set of operations for the allocation of compute, network and storage resources for the deployment of
VNFs and their interconnection
• Service Orchestration (SO)• Set of operations for the automatic configuration of P/VNFs, networks and traffic forwarding between
P/VNFs in a coordinated way• Configuration is driven by stimulus coming from
• Operator / OSS (high level service primitives)• VNF / EM• Infrastructure / VIM
• Nothing prevents service orchestration from requesting changes in resources
• Life Cycle Management (LCM)• Set of operations related to the life cycle of a VNF or NS, involving changes in resources and changes in
P/VNF and network configuration in a coordinated fashion• It can be considered a limited subset of SO operations
8
© ETSI 2016
THE MAPPING(S)
• Map NFVO and VNFM features in a way thatavoids functional fragmentation
• And make them pluggable
• Automated deployment & interconnection of allcomponents from an NFV Network Scenario
• Management of lifecycle at Network Servicelevel
9
OSM
SO
NFVO
G-VNFM
LCMRO
LCMRO
ETSI
OSM
SO
LCM
RO
OSM
SO
RO
<>Groupingtogetherall LCMand all RO
<>LCM aspart of SO
ETSI NFVscope
OSMscopeSO
NFVO
G-VNFM S-VNFM
© ETSI 2016
THE INITIAL ARCHITECTURE
• For demo(s)and Release O
• Based on theavailable seed
• Validation ofthe mappingfeasibility
• Initialassessment ofthe modelapplicability
10
Riftware(NSO)
OpenMANO(RO)
Juju Server(CM)
NSO: Network Service OrchestratorCM: Configuration ManagerRO: Resource Orchestrator
OpenStackController
Compute NodeCompute Node
Compute Node
ProxyCharm
ProxyCharm
VNFVNF
VNF
Compute NodeCompute Node
Compute Node
VNFVNF
VNF
OpenVIMController
OSM
scop
e
ProxyCharm
© ETSI 2016
THE INITIAL ARCHITECTURE
• For demo(s)and Release O
• Based on theavailable seed
• Validation ofthe mappingfeasibility
• Initialassessment ofthe modelapplicability
11
Riftware(NSO)
OpenMANO(RO)
Juju Server(CM)
NSO: Network Service OrchestratorCM: Configuration ManagerRO: Resource Orchestrator
OpenStackController
Compute NodeCompute Node
Compute Node
ProxyCharm
ProxyCharm
VNFVNF
VNF
Compute NodeCompute Node
Compute Node
VNFVNF
VNF
OpenVIMController
OSM
scop
e
ProxyCharm
DEPLOYMENT &INTERCONNECTION WITHREQUIRED RESOURCES
© ETSI 2016
THE INITIAL ARCHITECTURE
• For demo(s)and Release O
• Based on theavailable seed
• Validation ofthe mappingfeasibility
• Initialassessment ofthe modelapplicability
12
Riftware(NSO)
OpenMANO(RO)
Juju Server(CM)
NSO: Network Service OrchestratorCM: Configuration ManagerRO: Resource Orchestrator
OpenStackController
Compute NodeCompute Node
Compute Node
ProxyCharm
ProxyCharm
VNFVNF
VNF
Compute NodeCompute Node
Compute Node
VNFVNF
VNF
OpenVIMController
OSM
scop
e
ProxyCharm
VNF MODELLING &CONFIGURATION
VNF Model(primitives &attributes)
VNFConfiguration
© ETSI 2016
THE INITIAL ARCHITECTURE
• For demo(s)and Release O
• Based on theavailable seed
• Validation ofthe mappingfeasibility
• Initialassessment ofthe modelapplicability
13
Riftware(NSO)
OpenMANO(RO)
Juju Server(CM)
NSO: Network Service OrchestratorCM: Configuration ManagerRO: Resource Orchestrator
OpenStackController
Compute NodeCompute Node
Compute Node
ProxyCharm
ProxyCharm
VNFVNF
VNF
Compute NodeCompute Node
Compute Node
VNFVNF
VNF
OpenVIMController
OSM
scop
e
ProxyCharm
E2E SERVICE ORCHESTRATION(service primitives & attributes)
© ETSI 2016
THE MODEL-DRIVEN APPROACH
14
• OSM is committed to apply the models defined by ETSI NFV
• And contribute back according to development and experimentation results
LOCAL DEVELOPMENT &TESTING TEST POOL FOR DEVELOPERS SERVICE PROVIDER
Descriptors
Images Images
Descriptors
Open developmentenvironment
Functional tests Low cost Integration from the
beginning
Real servers and switches Performance tests (EPA can
be enforced) Cost-effective shared
infrastructure Move the value to VNF
services
Production/pre-productionenvironment
Real network scenarios Final service configuration Fast deployment Low final integration cost
© ETSI 2016
THE OSM MODEL
15
OSM INTERNALS
OpenMANO VNFDVNF resource orchestration info
(EPA resources and internalconnectivity)
- Descriptive information- metadata.yaml- config.yaml- actions.yaml
- Executables- Hooks- Actions
- Additional info (icon,README)
Juju charm
© ETSI 2016
THE OSM MODEL IN PLACE
16
OSM INTERNALS
OpenMANO VNFDVNF resource orchestration info
(EPA resources and internalconnectivity)
- Descriptive information- metadata.yaml- config.yaml- actions.yaml
- Executables- Hooks- Actions
- Additional info (icon,README)
Juju charm
VNF packageVNF package
VNFD
VNFartifacts
Additionalmetadata?
© ETSI 2016
THE AGNOSTIC MODEL
17
OSM INTERNALS
OpenMANO VNFDVNF resource orchestration info
(EPA resources and internalconnectivity)
- Descriptive information- metadata.yaml- config.yaml- actions.yaml
- Executables- Hooks- Actions
- Additional info (icon,README)
Juju charm
VNF packageVNF package
VNFD
VNFartifacts
Additionalmetadata?
DataModel
Translator
© ETSI 2016
THE MILESTONES AHEAD
• Seed Code• Code contributed to OSM repo, used in current demos
• Release 0• Initial release based on the code seeds• Ready for creating a proper development environment• Expected to be launched ~1-2 months after the kick-off meeting.
• Release 1• Release discussed in community since Kick-off and delivered 6 months after• Takes Release 0 as starting point.
• Release 2• Release discussed in community since OSM#2 (+6 months)
… and so forth
18
© ETSI 2016
THE FUTURE OUTLOOK
• Beyond the release plan…
• A model-driven approach supports mechanisms forintegration of advanced management procedures• Machine learning mechanisms
• Intent-based interfaces
• Currently addressing them within the CogNet project• Relying on the SDN and NFV converged framework proposed by ETSI NFV
• Essentially defining a Machine Learning Cluster (MLC) and two data flows• Measurement and monitoring• Policies
• OSM MANO stack as provider and consumer of these flows• And supporting their management
• Include intent in the loop• As an additional policy source
• Driving the policy translation
• Knowledge-based approaches required to address intent
19
MLC
© ETSI 2016
THE DEMONSTRATORS SO FAR
• Demo at MWC 2016• Demonstrate the feasibility of the concepts, starting with the
existing code seeds
• As realistic as possible, with commercial VNFs
• Proof of main concepts in OSM
• Useful for next stages of the project
20
https://www.youtube.com/watch?v=JJlxwJStkTk
https://www.youtube.com/watch?v=yyo26w8HSn8
• Catalyst project• Demonstrated right here
• NFV Service orchestration and lifecycle management based on OSM• Theater presentation on Tuesday, 14:30 – 14:50
• Full service lifecycle on top of OSM seed code
• OSM Modular & Abstracted Network Services
• Use of OSM exposed interfaces: onboarding, lifecycle,configuration primitives…
• Service design & Hybrid E2E Orchestration in Comptel’sFlowOne, encompassing Physical infrastructure
• Day 2 operations (fulfillment) triggered by Etiya’s Telaura