four pillars of orchestration: architecture for service lifecycle … · service manager device...

Carl Moberg Technology Director, NFV November 2, 2016

CKN Webinar Series #4: Data Models and Data Model Mapping

Four Pillars of Orchestration: Architecture for Service Lifecycle Automation

2 © 2016 Cisco and/or its affiliates. All rights reserved.

•  Architecture for Lifecycle Service Automation •  Four Pillars of Orchestration

•  Pillar 4: Data Models and Data Model Mapping

•  Demo

•  Resources

•  Q&A

Agenda


Architecture for Lifecycle Service Automation

Event Management Alarm and Fault Customer Portals Order Management

Orchestration Reference Architecture

Orchestrated Assurance

Orchestrated Fulfillment

NFV Orchestration

OSS

Orchestration

Network


Why Automate?

Execution at the speed of software

!  Agility, DevOps, NFV, SDN, new services platforms

Rapidly changing business models

!  Cloud services, virtualization, programmable networks

!  New ecosystems and value chains

!  OTT co-opetition

Changing customer behavior and new

expectations

!  Everything on demand !  New services with a press

of a button

All of this requires successful, flexible automation. But complexity has destroyed many automation initiatives.


The Four Pillars of Orchestration

Orchestration Across Multiple Domains

1

State Convergence

2

Orchestrated Assurance

3

Data Models and Data Model Mapping

4

Foundation for Full Lifecycle Service Automation


Some Notes on Models


•  YANG is a Data Modeling Language •  Explicitly and precisely determines the

structure, syntax and semantics of the data…

•  …that is externally visible •  Consistent and complete

Data, Data Model and Protocols

7

Data Model

Configuration Database


•  YANG is a Data Modeling Language •  Explicitly and precisely determines the

structure, syntax and semantics of the data…

•  …that is externally visible •  Consistent and complete

•  NETCONF and RESTCONF are Protocols •  Provides primitives to view and

manipulate data •  Content of the data as defined by the

data model

Data, Data Model and Protocols

Instance Data

Protocols

8

Data Model

Configuration Database

interface GigabitEthernet3 no switchport service instance 503 ethernet


Beware Confusions on IM vs DM The main purpose of an IM is to model managed objects at a conceptual level, independent of any specific implementations or protocols used to transport the data.

[...]

DMs, conversely, are defined at a lower level of abstraction and include many details. They are intended for implementors and include protocol-specific constructs.

-- RFC 3444 On the Difference between Information Models and Data Models

9


Languages, Encodings, Protocols Data Modeling Language Instance Encoding(s) Protocol(s)

SMI ASN.1 SNMP

SQL Schema SQL N/A

XML Schema XML N/A

Swagger JSON HTTP

YANG XML, JSON NETCONF, RESTCONF


Example Languages, Encodings, Protocols Data Modeling Language Instance Encoding(s) Protocol(s)

SMI ASN.1 SNMP

SQL Schema SQL N/A

XML Schema XML N/A

Swagger JSON HTTP

YANG XML, JSON NETCONF, RESTCONF


Data Models and Data Model Mapping


What an Orchestrator Does

Devices (Routers, VNFs, VNFMs, Applications)

Services (Policies, Service Chains, Readiness),

Orders

A System

Operations Operations


Without Models



Orders


•  Semantics in customer-specific code •  No versioning, automation or rendering •  Long and tedious software projects, months

Script Script Script Operations described in procedural scripts

• Services described in documents, diagrams outside system

• Translated into source code by integrator


Introducing Models



• Services described in data models inside system

Orders


• Configuration and operational data described in data models


Now, With Models



Orders


•  Semantic models by domain-experts •  Declarative data-model mapping •  Programming effort drastically reduced •  Iterations in days

• Services described in data models inside system

• Configuration and operational data described in data models


Streamlining the Development Process

EMS

Developers

Product Owners

Bag of developed integrated software components

Informal Models (UML, SID, ...) Informal Models (UML, SID, ...)

Product Owners

Auto-generated code from models; APIs rendered at run-time

Developers

Network Services

Formal Data Models

Data Models YANG

YANG

What we used to do Where we are going


Principles by Example


Moving Parts

Service Manager

Device Manager

Fastmap

• A service model representing what the network does

• Can be consumed through any northbound

• A device model (IOS-XR) representing the configuration and operations data set

• Produces southbund protocol operations

• A programming environment that allows for: • Listening on operations in the service

tree • Manipulating device model data

.py, .tpl .java


The Service Model in YANG


The Service Model in YANG

services eline eline0 a-side GigabitEthernet 4 device ios0 remote-ip 192.168.0.1services eline eline0 z-side GigabitEthernet 4 device ios1 remote-ip 192.168.1.1

Example service instance:


The Resulting Device Configuration

! A-side (device ios0)interface GigabitEthernet3 description a-side eline0 no switchport service instance 503 ethernet encapsulation default xconnect 192.168.0.1 503 encapsulation mpls

! Z-side (device ios1)interface GigabitEthernet4 description z-side eline0 no switchport service instance 503 ethernet encapsulation default xconnect 192.168.1.1 503 encapsulation mpls


The Resulting Device Configuration (Mapping) eline0 serviceinstance 503 a-side GigabitEthernet 3 device ios0 remote-ip 192.168.0.1eline0 serviceinstance 503 z-side GigabitEthernet 4 device ios1 remote-ip 192.168.1.1

! A-side (device ios0)interface GigabitEthernet3 description a-side eline0 no switchport service instance 503 ethernet encapsulation default xconnect 192.168.0.1 503 encapsulation mpls

! Z-side (device ios1)interface GigabitEthernet4 description z-side eline0 no switchport service instance 503 ethernet encapsulation default xconnect 192.168.1.1 503 encapsulation mpls


Let’s Run It


Result: NetDevOps Cycle

Product Owner Software Engineering Infrastructure Engineering

.py, .tpl .java


•  Informal and external definition of service, adds expensive interpretation steps

•  Precisely defined models drives the implementation itself by contract

Summary and Conclusions

•  Lack of lifecycle management of service definitions

•  Versioning and automation of models and mapping brings full lifecycle management


•  Cisco NSO and ESC www.cisco.com/go/nso

•  Editorial Resources on LR

Resources


Q&A

four pillars of orchestration: architecture for service lifecycle … · service manager device...

Documents