©  ETSI  2017

AN  UPDATE  ON  OSMTO  THE  NFVRG

Diego  R.  Lopez  –Telefónica I+D

©  ETSI  2017

DICEBAMUS HESTERNA DIE…

• Delivering  an  open  source  MANO  stack  aligned  to  ETSI  NFV  (information  and  data)  models• Capable  of  consuming  published  models  for  NFV  service  and  deployment  (VNFD,  NSD,  etc.)• Extending  these  models,  and  recommending  back  to  ETSI  NFV

• Assuring  predictable  behavior  of  VNF  and  NS• Under  these  models

• 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

2

©  ETSI  2017

OSM  AS  OF  TODAY

• Open  community-­‐based  NFVO,  founded  on  these  principles:• Compliance  and  feedback  to  ETSI  NFV  ISG  architecture  and  specs

• Base  implementation  on  information  model

• Independent  IOP  labs  to  test  &  integrate  in  the  community

• Open  governance  model  based  on  technical  meritocracy

• Types  of  engagement• Developers  (as  you  could  expect…)• Early  adopters• Testers  (modules  &  IOP)• Advisors

3

MeadowCom

• End-­‐User  Advisory  Board• Service  providers  and  other  end  users  of  the  technology  (not  integrators  or  resellers)  will  become  members

• Produce  feature  requests  to  the  technical  groups

©  ETSI  2017

A  PRODUCTION-­‐QUALITY  NFV  MANO  STACK

• Capturing  and  automating  real  production  complexity

• Covering  e2e  lifecycle  of  network  services  

4

Layering Abstraction

Modularity Simplicity

Architectural7Principles

• Avoiding  complex  integration  efforts

• Providing  a  consistent  model-­‐based  approach

©  ETSI  2017

• Automated  end-­‐to-­‐end  Service  Orchestration

• Superset  of  ETSI  NFV  MANO• Plugin  model  for  multiple  VIMs/SDN  Controllers

• Generic  VNFM  style  functionality  with  support  for  integrating  Specific  VNFMs

• PNF  integration• Greenfield  and  brownfield  deployments• GUI

Run-­‐Time  Scope

• Network  Service  Definition  (CRUD  operations)

• Model-­‐Driven  Environment  with  Data  Models  aligned  with  ETSI  NFV

• VNF  Package  Generation• GUI

Design-­‐Time  Scope

5

VirtualisedInfrastructureManager(s)

VNFManager(s)

NFV Orchestrator

Main NFV reference points

NFV Management and Orchestration

Or-­‐Vi

Or-­‐Vnfm

Os-­‐Ma

Ve-­‐Vnfm

Nf-­‐Vi

Service, VNF and Infrastructure Description

OSM  Components Other  Components

Vi-­‐Vnfm

Resource  Orchestrator(Includes  VIM/SDN  

Connectors)

VNF  Configuration  &  Abstraction

Network  Service  Orchestrator

GUI  &  Design-­‐Time  Tools

OpenVIM VMwareOpenStack

NFVI

ODL

Floodlight

VNFs

EMs

OSS/BSS

PNFs

Specific  VNFMs

Extract  from  Figure  4:  NFV  Reference  Architecture  Framework,  ETSI  GS  NFV  002  V1.2.1  (2014-­‐12)

OSM  COMPONENTS

©  ETSI  2017

OSM  DATA  MODELS

6

• Data  Modelled  Language:  YANG• Format  Encoding:  YAML,  JSON,  XML• Note:  Data  Model  Translator  included  in  the  architecture  to  optionally  decouple  OSM  internals  from  the  user  input  formats.  

• OSM  open  to  supporting  multiple  input  formats  to  align  with  industry  directions

Aligned  with  ETSI  NFV  ISG  Phase  1  Information  Models

• Will  work  with  the  ETSI  NFV  ISG  community  for  clarifications,  bug  fixes  (sightings)  and  feature  advances.

• Possible  intersect  with  OSM  Release  THREE

Analysis  underway  on  ETSI  NFV  ISG  Phase  2  Information  Models

©  ETSI  2017

HOW  OSM  BEHAVES

7

Service'Orchestrator'(SO)

(seeded'from'Riftware)

VNF'Configuration'Agent'(VCA)(seeded'from'Juju)

Resource'Orchestrator'(RO)

(seeded'from'OpenMANO)

VNF VNF VNF VIM VIM VIM

VNFDVNFDVNFD

VNF'CharmVNF'CharmVNF'Charm

NSDNSDNSD

©  ETSI  2017

NETWORK  AND  FUNCTIONAL  COMPOSITION

• Need  to  map  functional  interfaces  to  network  connection  points• More  on  this  when  talking  about  draft-­‐aranda-­‐nfvrg-­‐recursive-­‐vnf

8

Network Service

VNF.B#1

VNF.A#1

VNF.C#1

VNF.B#2

VL#1 VL#2 VL#3 VL#4

VL#5

cba lk

j

fed

ihg

… …

VNF$A#1

Interfaces

offered

Interfaces

consumed

Type$A

Type$B

Type$X

Type$Y

OffersType)A

VNF)A#1

VNF)B#1

ConsumesType)A

1.)Verify)matching)types

2.)Interface)configuration)

script

2.)Interface)configuration)

script

VCA

©  ETSI  2017

FROM  RELEASE  ZERO…

• Simplified  on-­‐boarding  process• Human-­‐readable  VNF  and  NS  descriptors• Multi-­‐VIM  support:  OpenStack,  OpenVIM• EPA  Support,  assuring  predictable  performance• Underlay  configuration  with  SDN•Web  interface• Documentation• Installation  guides• How-­‐to  guides  for  users  and  developers• Data  model  in  detail• Minimal  infrastructure  requirements• Videos• …

9

©  ETSI  2017

…  TO  RELEASE  ONE…

•Multi-­‐VIM

•Multi-­‐SDN  

• Plugin  model  for  adding  new  VIMs  and  SDN  frameworks

•Multi-­‐site  network  services

• Simplified  installation• Including  support  for  OpenVIM

• Enhancements  to  VNF  and  NS  models• Contributed  to  ETSI  NFV

10

openvim

Release ONEAvailable(at:(osm.etsi.org

©  ETSI  2017

…  TO  WHAT  IS  BEING  DISCUSSED  FOR  RELEASE  TWO…

• Interoperability  with  public  clouds

• Service  chaining  use  case•OSM  sandbox

• Auto-­‐scaling  VNF  with  horizontal  scale  out  of  VDUs

• Deployment  of  OSM  in  reduced  environments

• Distribution  of  OSM  SW  as  container  images

• Unified  CLI  • Interchangeable  PNFs  and  VNFs

Beware:  This  is  a  list  of  features  discussed  by  the  EUAGNot  a  commitment  from  the  OSM  team

11

©  ETSI  2017

…AND  OTHER  PROPOSED  FEATURES  RELATED  TO  DEVOPS

• Emulated  multi-­‐PoP environment• Facilitate  the  whole  model-­‐driven  development  cycle• Environment  based  on  Mininet/  Containernet• Executed  on  single  physical  or  virtual  machine

• Mediated  interactions• Embrace  the  openness  of  a  NFV  Service  Platform  without  compromising  security• Use  AuthN/AuthZ at  scale:  external  systems,  package  signing…• A  Gatekeeper  as  a  mediator  of  all  MANO  operations• Rely  on  a  microservice architecture  to  guarantee  modularity  and  extensibility

12

Emulated)multi+PoP)Environment

PoP#CPoP#BPoP#A

OSM(Developer)

{Running'Service'Chain}

S

t

Gatekeeper

GUIBSSsNet*SDK

OSMOrchestration/Stack

©  ETSI  2017

GETTING  REAL

•A  network  of  remote  labs  enables  continuous  and  automated  testing  with  different  VIMs  and  NFVIs

•Fully  integrated  with  OSM  CI/CD  pipeline

•Bring  realistic  conditionsto  OSM  testing

•Minimize  barriers  for  community  engagement

•Securely  connected  over  ETSI’s  HIVE  (Hub  for  Inter-­‐operability  and  Validation)

13

openvim

©  ETSI  2017

ETSI  NFV  PLUGTESTS

• Interoperability  tests,  in  a  combination  of  1  MANO  +  1  VIM  +  1  VNF• Objective  is  to  check  that  they  can  work  together• ETSI  does  not  certify  NFV  solutions• 10  VIMs  x  15  VNFs  =  150  combinations• Only  a  random  sample  per  MANO

• Test  sessions  randomly  scheduled  the  day  before• Based  on  pre-­‐testing  activities  &  daily  feedback• VIM,  VNF  and  MANO  sitting  in  the  same  table

• An  8  days  event• At  the  5TONIC  lab  in  Leganés (Spain)• 23  January  to  3  February• See  http://www.etsi.org/news-­‐events/events/1104-­‐1st-­‐nfv-­‐plugtests

14

©  ETSI  2017

OSM  AT  THE  PLUGTESTS

• OSM  interoperated  with  all  VIMs  and  VNFs  participating  in  the  PlugTests

• Objective:  A  unique  OSM  descriptor  for  all  VIMs• All  OSM  VIM  plugins  were  used  in  the  tests:  OpenStack,  VMware,  OpenVIM• A  wide  range  of  OpenStack  platforms  were  tested  successfully• From  Kilo-­‐ to  Newton-­‐based• Deployment  on  specific  segments:  regions,  availability  zones• Access  to  VMs  through  both  provider  external  network  and  tenant  network  connected  to  the  public/external  network

• A  total  of  32  test  sessions  in  8  days,  all  successful• Addition/removal  of  VNF  and  NS  packages  into  the  Catalog• Instantiation  and  termination  of  NS  instances.• Update  operations  on  running  NS  instances  (start/stop  VNF  instance)

• 22  bugs  collected,  many  already  fixed

15

©  ETSI  2017

IOP  MATRIX

16

OpenStack  Newton OpenStack  Newton OpenStack  Kilo OpenVIM OpenStack+ODL OpenStack+ODL OpenStack  MitakaOpenStack  Mitaka  w/  regions

OpenStack  Mitaka  w/  regions

VIM  1 VIM  2 VIM  3 VIM  4 VIM  5 VIM  6 VIM  7 VIM  8 VIM  9 VIM  10FW VNF  1 Ok Ok 2LB VNF  2 Ok 1Probe VNF  3 Ok Ok Ok 3IMS VNF  4 Ok 1FW VNF  5 Ok Ok 2Enterprise  Messaging VNF  6 Ok Ok 2

Probe

VNF  7Ok Ok

Ok(minor  issue  with  LCM  update)

Ok Ok5

PCRF VNF  8 Ok 1FW VNF  9 Ok 1Probe/LB VNF  10 Ok Ok 2DPI VNF  11 Ok 1SBC VNF  12 Ok Ok Ok 3Tester VNF  13 Ok Ok Ok 3Tester VNF  14 Ok Ok 2Probe VNF  15 Ok Ok Ok 3

1 5 2 1 2 2 3 8 7 1 32

• OSM  passed  successfully  all  scheduled  tests• All  VNFs,  all  VIMs• Most  time  spent  on  creation  and  debugging  of  descriptors

• Blank  =  combinations  not  tested  during  the  Plugtests (likely  to  work)• Note  that  all  VNFs  and  VIMs  were  assigned  at  least  once

©  ETSI  2017

FACILITATING  HORIZONTAL  VIRTUALIZATION

This  is  the  footer 17

Technology*availability*and*maturity

Baremetal Vertically,Virtualized Horizontally,Virtualized

Telefonica5led*UNICA*development

Standard*availability(OpenStack)

Include*OSM*service*orchestration*as*part*of*the*UNICA*architecture*

vIMSvAAA SD'WANNaaSvCPE vCPE

KVM KVM KVM

HW HW HW HW

KVM

vAAA vCPENaaS SD'WAN

UNICA

vIMS

HW

KVM

HW

KVM

©  ETSI  2017

18

Find  out  more  and  come  join  the  party  at

osm.etsi.org