Patrice Nivaggioli

SP Architectures - EMEAR

June 2015

Cisco Strategy for SDN/NFV

Evolved Service Platform

• Evolved Service Platform (ESP) Overview

• Model driven architectures

• Virtual topologies

• Use Cases

Agenda

Evolved Programmable Network

Applications

Evolved Services Platform

Cisco ESP Framework Transform Business through Automation, Service Innovation, and Optimization

Cisco Services

Business Mobility Video Consumer

Service Broker

Catalog of Network Functions

(Phy, VNFs)

Service Profile

Orchestration Engine

VNFs

Storage Network Compute

Evolved Programmable Network

Applications

Evolved Services Platform

Cisco ESP Solutions Transform Business through Automation, Service Innovation, and Optimization

Cisco Services

Business Mobility Video Consumer

Service Broker

VNFs

Storage Network Compute

Catalog of Network Functions

Service Profile

Orchestration Engine

Meraki

ESC-lite

Customer Premise

Open SDN Ctlr.

Access / WAN

APIC, VTC

ESC, CTCM

Data Center

Network Services Orchestrator enabled by tail-f

Orchestration Engine

MX60

ISR G2

VNF/UCS(E

)

ASR

CRS

CSR/XRv

ACI/Nexus

VTF

VNFs

• Evolved Service Platform (ESP) Overview

• Model driven architectures

• Virtual topologies

• Use Cases

Agenda

VNF

YANG in the Orchestration domain

MPLS Core

P0

P1 P2

P3

PE0

PE1 PE2

PE3

CE0

CE1

CE2

CE3 CE4 CE5

CE6

YANG

Service

Model

VIM (OpenStack)

Virtu

aliz

ed

Infr

astr

uctu

r e

VNF Service chain

VNF VNF

vSwitch

VNF Manager

Physical Domain Virtualized Domain

SDN CTL

Render Orchestrator

YANG Model Example : L3VPN - topology

[yang]pnivaggi $ more l3vpn.yang module l3vpn { namespace "http://com/example/l3vpn"; prefix l3vpn; import ietf-inet-types { prefix inet; } import tailf-common { prefix tailf; } import tailf-ncs { prefix ncs; }

container topology { list role { key "role"; tailf:cli-compact-syntax; leaf role { type enumeration { enum ce; enum pe; enum p; } } leaf-list device { type leafref { path "/ncs:devices/ncs:device/ncs:name"; } } }

list connection {

key "name";

leaf name {

type string;

}

container endpoint-1 {

tailf:cli-compact-syntax;

uses connection-grouping;

}

container endpoint-2 {

tailf:cli-compact-syntax;

uses connection-grouping;

}

leaf link-vlan {

type uint32;

}

}

}

YANG Model Example : L3VPN - VPN

container vpn { list l3vpn { description "Layer3 VPN"; key name; leaf name { tailf:info "Unique service id"; tailf:cli-allow-range; type string; } uses ncs:service-data; ncs:servicepoint l3vpn-servicepoint; leaf as-number { description "AS used within all VRF of the VPN"; tailf:info "MPLS VPN AS number."; mandatory true; type uint32; }

list endpoint { key "id"; leaf id{ tailf:info "Endpoint identifier"; type string; } leaf ce-device { mandatory true; type leafref { path "/ncs:devices/ncs:device/ncs:name"; } } leaf ce-interface { mandatory true; type string; } leaf ip-network { // the private IP network mandatory true; type inet:ip-prefix; } leaf bandwidth { tailf:info "Bandwidth in bps"; mandatory true; type uint32; } }

YANG Model configuration examples : L3VPN • L3 VPN service configuration • L3 VPN topology configuration

admin@ncs% show topology

role ce {

device [ ce0 ce1 ce2 ce3 ce4 ce5 ce6 ce7

ce8 ];

}

role pe {

device [ pe0 pe1 pe2 pe3 ];

}

role p {

device [ p0 p1 p2 p3 ];

}

connection c0 {

endpoint-1 {

device ce0;

interface GigabitEthernet0/8;

ip-address 192.168.1.1/30;

}

endpoint-2 {

device pe0;

interface GigabitEthernet0/0/0/3;

ip-address 192.168.1.2/30;

}

link-vlan 88;

}

admin@ncs% show vpn l3vpn ford

as-number 22000;

endpoint 10 {

ce-device ce0;

ce-interface gigabitethernet0/1;

ip-network 10.0.1.0/24;

bandwidth 1000000;

}

endpoint 20 {

ce-device ce1;

ce-interface gigabitethernet0/1;

ip-network 10.0.2.0/24;

bandwidth 1000000;

}

qos {

qos-policy BRONZE;

}

Service Modeling with Cisco NSO Architecture overview

Service Manager

Network Engineer

NETCONF REST CLI Web UI JSON RPC JAVA

OSS/BSS

NCS

AAA Core Engine

Network Element Drivers

Mapping Logic

Mapping Templates

Fast Map

Device Manager Notification Receiver Alarm Manager

Service Models

Package Manager

Script API

Device Models

Developer

API

Topology Models

Service Assurance

Models

Resource Manager Models

Policy Models (QoS)

Auxiliary Service Data

Service and Device Data

NSO (Powered by

Tail-f NCS)

ESC

OpenStack

VTC/APIC

SP’s OSS/BSS or Prime Order Fulfillment

KVM (or ESXi)

Ceph VTF/ACI

SP’s Portal / Prime Service Catalog

VNF 1 (Cisco or 3rd Party)

NSO

VNF 2 (Cisco or 3rd Party)

NSO

VNF 3 (Cisco or 3rd Party)

NSO

Cisco UCS UCS (iSCSI) Cisco Network

Cisco Solution Mapped on ETSI NFV Framework

Service

Assurance

Virtual Topology System (VTS)

End-to-End Solution from Cisco including NFVI, MANO, Wide array of VNFs and Professional Services 1

1

ETSI NFV PoC#36 Orchestration of Active Monitoring

https://www.youtube.com/watch?v=zfTkZTceHLQ

Service Modeling with Cisco NSO Service Application and Mapping

Mapping Logic

Mapping Templates

Fast Map

Developer

API

Service Application

VPN Service Model

Java Mapping Logic

PE Feature Template

VNFM Feature Template

Auxiliary Data

Simple variable interface

IOS XR YANG Model

IOS YANG Model

3rd Party YANG Model

ESC YANG Model

3rd Party YANG Model

CE Feature Template

3rd Party YANG Model

IOS YANG Model

L3 VPN example

Physical and NFV resources

Service Modeling with Cisco NSO Service Application and Fast Map algorithm

Mapping Logic

Mapping Templates

Fast Map

Developer

API

Service Application

Service creation

Service change Note : Service delete not shown

Service Modeling with Cisco NSO Service Intent, Topology Overlay and Underlay

Transaction Database

(CDB)

GraphDB

localadmin@cvpn-ncs-svc-01> show configuration virto

localadmin@cvpn-ncs-svc-01> show configuration topology NSO seeks for

appropriate

resources to

instantiate the

service

Network Devices Modeling

Feature Template

IOS

IOS YANG Model

NED

CLI

IOS XR

IOS XR YANG Model

NED

NETCONF

/YANG

ESC

ESC YANG Model

NED

NETCONF

/YANG

How NSO touches ODL

Same with OS Neutron

ODL

ODL YANG Model

NED

RESTFul

• Lot of RFCs / drafts on YANG models for network feature or overall service delivery

• YANG model and Netconf adoption on devices will simplify the 3rd party device integration i.e. NED simplification

• Policy abstracts like GBP or SFC have already their YANG model

IETF network and service models

draft-zhang-mpls-lspdb-yang-00

A generic YANG Data Model for Label Switch Path (LSP).

draft-ietf-netmod-routing-cfg-19

A YANG Data Model for Routing Management

draft-penno-sfc-yang-13

Yang Data Model for Service Function Chaining

draft-ietf-isis-yang-isis-cfg-02

YANG Data Model for ISIS protocol

draft-asechoud-netmod-diffserv-model-02

YANG Model for Diffserv

draft-litkowski-spring-sr-yang-00

YANG Data Model for Segment Routing

draft-zhdankin-idr-bgp-cfg-00

Yang Data Model for BGP Protocol

draft-ltsd-l3sm-l3vpn-service-model-00

YANG Data Model for L3VPN service delivery

https://datatracker.ietf.org/doc/search/?sort=status&rfcs=on&name=yang&activedrafts=on

• Provides the API to applications to control the network

• Has a database that stores requested network state

• Doesn’t control the network directly

• Controls software forwarders that move packets from hardware NICs to VMs

• Or, controls SR-IOV hardware

• Controls hardware between the hosts to move packets efficiently, e.g. on-switch VXLAN, DC edge routers

• May be software or hardware

A typical NFV/SDN network design

Orchestrator or

VIM

SDN controller (GBP, SFC, VTN…)

forwarding

elements

Introducing Group Based Policy Model Group: Set of endpoints with the same

properties. Often a tier of an application.

Policy Rules Set: Set of Classifier / Actions

describing how Policy Groups communicate.

Policy Classifier: Traffic filter including

protocol, port and direction.

Policy Action: Behavior to take as a result of a

match. Supported actions include “allow” and

“redirect”.

Service Chains: Set of ordered network

services between Groups.

L2 Policy: Specifies the boundaries of a

switching domain. Broadcast is an optional

parameter

L3 Policy: An isolated address space

containing L2 Policies/Subnets.

L3 Policy

Policy

Rules Set

Policy Rule

Policy Rule

Service Chain

Classifier Action

Classifier Action

L2 Policy

Group

Policy Target

Policy Target

Policy Target

Group

Policy Target

Policy Target

Policy Target

L2 Policy

provide consume

Node Node

Group Based Policy deployment

• Neutron Driver maps GBP to existing Neutron API and offers compatibility with any existing Neutron Plugin

• Native Plugins exist for OpenDaylight as well as multiple vendors (Cisco, Nuage Networks, and One Convergence)

Group Based Policy

CLI Horizon Heat

Neutron Driver

Neutron

Any Existing Plugins and ML2 Drivers

Open model that is compatible with ANY physical or virtual networking backends

GBP Native Driver

3rd Party

GBP configuration in Horizon

New Policy Tab

Policy Authoring Interface

• Trend is to separate network functions into individual VMs and link them via a service chain

• Service chain types

• Bridged: use separate virtual bridges to enforce a service chain

• VLANs: stitch VLANs together to guide a flow through the sequence of service functions

• Routing: manipulate routing tables

• NSH / Service Function Chaining

Service Chaining Function Introduction

• Try rendering a business policy like …

• All traffic between the Internet & Web front end servers apply:

• De/Encryption with highest throughput / low latency and least $$ cost

• Copy all “mobile” only transactions to a Big Data analytics system

• Perform the copy at most optimal point ($$ cost & least latency impact)

• Send all traffic through a SLB+WAF & and IDS

• Additionally, deploy this policy with other caveats like:

• Service functions are both virtual and physical and vendor neutral

• Compute & service elasticity; compute mobility

• Practically impossible today!

Why we must Evolve Service Function Chaining

Internet Elastic

SSL

Elastic

LB +

WAF

Elastic

IDS

Elastic

Web FE

Elastic

Copy

Elastic

Analytics

Mobile

• Service Classifier (SC)

• Determines which traffic requires service

• forms the logical start of a service path

• Service Path

• the actual forwarding path used to realize a service chain

• the “intent” ->the actual instantiation of the chain in the network

• Service Overlay

• The network overlay created to form the service path

• Service Network Forwarder (SNF)

• Tunnels service paths to downstream SFF

• Service Function Forwarder (SFF)

• Forwards packets to SF instance

• Loadbalancing awareness across multiple SF instances

• Service Header

• Shared context, carried in a service header,

• enables network-service interaction and richer policy creation and enforcement.

Components of an Evolved Service Chaining Architecture

SC

SNF

SFF

SF11 SF2

1

SNF

SFF

SF2

IP

IP

NSH

IP

NSH

GRE

IP

NSH

IP

NSH

GRE

IP

NSH

VXLan

IP

NSH

GRE

IP

NSH

IP

NSH

GRE

IP

NSH

SFxy Instance X of Service Function of Type Y

2

4

Resource Footprint Example: NAT, FW, QoS, IPSec and DPI Services • Assume we need to carry 10 Gbps of traffic with IPSec, (QOS + NAT + Firewall) and DPI

• Assume 1vCPU image on VMWare ESXi, IOS XE 3.14 for IPSec, Qos, NAT and Firewall

• Assume 4vCPU image for DPI

Multi-Service VM Multiple Single-Service VMs

Throughput per VM

S1: IPSEC (1vCPU) n.a 0.388 Gbps

S2: NAT + Firewall + QoS (1vCPU) n.a 0.69 Gbps

S3: DPI (4vCPU) n.a. 0.7 Gbps

S1+S2+S3: IPSEC + (FW + QoS +

NAT) + DPI

0.21 Gbps n.a.

Number of VMs required for 10 Gbps of

forwarding

Total: 48

IPSec: 26, NAT+Firewall+QoS: 15, DPI: 15

Total: 56

Total Number of vCPUs required 48 101

Plus 50% HV traversal tax per VM (e.g. ofr KVM+OVS) 96 202

Total Memory required (GB) 192 224

LB S1+

S2 +

S3

S1 S2 LB S3

SFC YANG Model in Opendaylight

Yang Data Model for Service Function Chaining

draft-penno-sfc-yang-13

• Evolved Service Platform (ESP) Overview

• Model driven architectures

• Virtual topologies

• Use Cases

Agenda

Updates on Nexus Portfolio Offerings Extended NX-API Support Across Nexus 2K-9K

Programmable Network Application Centric

Infrastructure

NEW! Unified Open NX-OS Release for

Nexus 3000 and Nexus 9000 (Q3 2015)

• Enhancements to NX-API – object store

and model driven

• Native 3rd party RPM applications

integration (tcollector, Nagios, Ganglia,

Puppet / Chef etc.)

• Linux utilities support for seamless tool

integration across compute and network

• SDK for custom application integration

NEW! ACI Release for Nexus 9000

(Shipping June 2015 )

• Microsoft Azure and System Center

Integration

• Programmability examples: vCenter plug-

in, ACI toolkit etc.

• Simplified operations

• Stretched fabric, multiple destinations

from 30KMs to 150KMs

• Group-based policy on Openstack

• New ACI ecosystem partners (CliQr)

DB DB

Web Web App Web App

NEW! Common NX-API across N2K-

N9K (2H 2015)

Programmable Fabric

NEW! Virtual Topology System

(VTS) for software overlay

provisioning and management

across for Nexus 2K-9K (2H

2015)

• Standards-based fabric

support on Nexus 5600/7x00

with VXLAN BGP EVPN

(shipping with Nexus 9000

today)

Cisco ACI integration with Openstack

Web Web Web Web App App DB DB

HYPERVISOR HYPERVISOR HYPERVISOR

NEUTRON

ROUTER

SECURITY

GROUP

NEUTRON

NETWORK

Contract Contract Contract

DB APP WEB ADC

F/W

ADC

APIC

Driver OVS Driver

Neutron

Networking Group Policy

OVS Driver

Neutron

Networking

APIC Group Driver

Web Web Web Web App App DB DB

HYPERVISOR HYPERVISOR HYPERVISOR

APIC Driver (ML2) Group Policy Plugin

Programmable Fabric NX-API, VXLAN BGP EVPN Fabric, and Virtual Topology System (VTS)

Operations /

Programmability

& Automation

Automated

DCI / WAN

VM

OS

VM

OS

NX-API

Physical Virtual

DCI/WAN

Bare Metal Virtualized

BGP-EVPN VXLAN Fabric

VTS

VTS for overlay provisioning and management across Nexus

2000 – Nexus 9000 (2H 2015)

3

0

VXLAN as Data Center Overlay technology

VTEP

Local LAN Local LAN Local LAN Local LAN

IP Transport Network

VTEP

VTEP VTEP

VXLAN VNI

LAN Segment

Underlay Network:

• IP routing – proven, stable, scalable

• ECMP – utilize all available network paths

Overlay Network:

• Standards-based overlay

• Layer-2 extensibility and mobility

• Expanded Layer-2 name space

• Scalable network domain

• Multi-Tenancy Modes of Operation:

• BGP EVPN (BGP control plane with MP-BGP Extensions)

• Multicast based flood and learn (No control plane)

3

1

VTS Architecture

VCenter OpenStack 3rd Party VM

Manager

REST API

Virtual Topology System

(VTS) MP-BGP

BGP-EVPN

VTF VTF OVS dVS

RESTCONF/Yang

MP-BGP

BGP-EVPN RR RR

Cisco NSO

IP / MPLS

WAN

WAN / Internet

3rd Party Cloud

Bare Metal

Workload

Virtualized

Workloads with OVS

Virtualized Workloads with Feature Rich &

High Performance Cisco VTF Solution

Virtualized

Workloads with SR-IOV Virtualized

Workloads with dVS

DCI DCI

Data Plane

Control Plane

Management &

Orchestration Plane

VTS GUI

ToR ToR

VM or

VNF

VM or

VNF VM or

VNF

VM or

VNF VM or

VNF

VM or

VNF VM or

VNF

VM or

VNF

VM or

VNF

VM or

VNF

VM or

VNF

VM or

VNF

Cisco Virtual Topology Forwarder

(VTF)

• Lightweight, multi-tenant

software dataplane

• High performance L2, L3, VXLan

packet processing on x86

• SW VTEP for VXLAN overlays

• Hybrid overlays by stitching

Hardware and Software VTEPS

VTS – Overlay Configuration through GUI

• Create a Tenant

• Add Network to the Tenant

• Add Subnet

• Select the ToR and host facing ports

• VLAN and VNID is automatically allocated

• Layer-2 VXLAN segment is configured on the ToR switches

3

3

Current VTS Network Models Based on OpenStack Neutron Constructs

3

4

• Evolved Service Platform (ESP) Overview

• Model driven architectures

• Virtual topologies

• Use Cases

Agenda

How it all started ..

GOAL: Improve Experience for

Consumer of Network Services

Service immediacy and speed

Freedom of choice, service customization

Personalized experience, user in charge

Consumption based economics

Bring your own device, craft your own design

Cloud Network

Services

How it all started ..

CPE

Device

CPE

Device

Orchestration Layer

Network Service Lifecycle Mgmt

Network Layer

Control and Data Planes

Automated service delivery simplicity and efficiency ( “IT-

less” )

Automated service creation, high cadence of new services

Self-service creation and reporting

Elasticity of network and compute resources

Open architecture, extensibility

GOAL: Improve Experience for

Consumer of Network Services

Service topology

Model based

Soft-real time

Event driven

Discovery of devices

Network topology

Physical devices

Virtual devices

Advanced Network

technologies/features

Customer Experience

Unbox & Plug-in

Service up and running

CPE ships

Orchestration happens! Order Services

vCPE CPE

vFW

CPE

CPE

CPE

SP CLOUD

Cloud-Hosted Management

Scalable, elastic, on-demand

Internet

Router vFW VR

vNG-

IPS

Internet

Cloud IPVPN with FW and Remote

Access to Internet

vFW with NAT and Policy

vFW with IPSec/SSL Remote Access

including Remote End-Host posture

verification

vNG-IPS (SourceFire) for advanced

threat protection and real-time

contextual awareness

Overlay Packet Tunnels

IPSec tunnels – mesh, hub&spoke;

CloudVPN Business Services CloudVPN with Internet, FW, RA and Next-Gen-IPS

Elastic Services

Controller (ESC)

Tenant Portal

NETCONF/YANG

SP’s OSS/BSS

CPE

PnP Functionality

Zero Touch Provisioning

X86 S

erv

er

Internet

Gateway

VNF Service chain

Provision

CSR1Kv

CPE Shipped at Customer

Site, connected & Powered ON

Customer Orders Service

Provide Day 1

Configuration

Establish VPN: IPSec tunnel, IP Overlay

(L2TP, VXLAN, GRE, LISP)

CloudVPN Architecture

CSR1Kv ASAv vWSA

vSwitch

Provision

ASAv

Provision

vWSA

VTF

NCS PnP server

REST API

NC/YANG, RC/YANG

ODL OpenStack

CBCS : Cloud based Consumer Services A Service Enabling Approach

pCPE

Virtual Broadband Network

Access Network

vCPE

• Home network is virtually extended to the vBN platform and

moving most L3 features from the home to the SP datacenter

• Services instantiated on “compute module” Network Attached Storage Wi-Fi Management Remote Access to Data

Multimedia Access Home Automation / IoE Anti-virus / Parental Control

4

1

Orchestration Infrastructure and Interfaces

IP or IP/MPLS Transport

Controller

Media

Server/ vSwitch vCPE

Orchestration

Containers / Host

IP

Po

rta

l S

elf O

nbo

ard

ing

A

CS

RC

S REST APIs

TR69:

pCPE forwarding mode and overlay

Resource Manager

RPC APIs

SoftGRE, L2TPv3 or VLANs

Connected

Storage

Thank you