Patrice Nivaggioli SP Architectures - EMEAR June 2015 Cisco Strategy for SDN/NFV Evolved Service Platform
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