Multi-Vendor Service Orchestration
& Network automation for today’s networks
(. . . and for NFV)
Joachim Jerberg Jensen
Systems Engineer, Global Service Providers
CCIE SP #42403
joajense@cisco.com
Confidential
1
From device-centric to network-as-platform …
Phase 1
Orchestration
NSO
Phase 2
Orchestration
NSO
SDNWAE
Controller
ODL
Centralized service provisioning
Work with existing network devices
Confidential
On Device
Minimal but sufficient
AN: Autonomic Networking
SR: Segment Routing
VPN services: eVPN + static PW
2
What is NETCONF?
qNETCONF is an IETF network management protocol
designed to support management of configuration,
including:
§
Distinction between configuration and state data
§
Multiple configuration data stores (candidate, running, startup)
§
Configuration change validations
§
Configuration change transactions
§
Selective data retrieval with filtering
§
Streaming and playback of event notifications
§
Extensible remote procedure call mechanism
qNETCONF server runs on networking device and client
runs as part the management application.
Confidential
Configuration data
<get-config>, <edit-config>, <notification>
<rpc>, <rpc-reply>
BEEP, SSH, SSL, console
XML payload, modeled in YANG.
<get>, <get-config>, <edit-config>, <copy-config>,
<delete-config>, <lock>, <unlock>, <closesession>, <kill-session>, <notification>,
<commit>…
3
YANG
YANG (RFC6020 etc.) is a data modelling language
•
•
•
“Yet Another Next Generation“ – developed after the NG-SNMP fiasco
Data modelling for NETCONF protocol, and more: XML conversion, visualization, code generation...
NETCONF/YANG‘s ambition is to provide the ultimate multi-vendor R/W element and service management, thus an open
standard programmability architecture
Example:
change
an interface
IP address
ietf-interfaces.yang
Example:
configure
interface
IP address
YANG vs. SNMP
YANG
SNMP
Framework
(definition language)
YANG
SMI
Content
(information model)
YANG module
MIB
Payload
(encoded data)
XML
(ASCII)
ASN.1 BER
(binary)
Protocol
(remote access)
NETCONF,
RESTCONF
SNMP
IOS Yang Support: XR-XML, XR-YANG (5.1.1 LA/SMU), xOS-YANG (5.3-5.4)
Confidential
container
interfacesencoding="UTF-8"?>
{
<?xml
version="1.0"
description
"Interface
configuration parameters.“;
<rpc
message-id="9”
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
list interface { key "name“;
<edit-config>
leaf
name { type</target>
string; }
<target>
<candidate/>
description { type string; }
<configleaf
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0”>
leaf xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
type {
<interfaces
type identityref {
<interface>
base interface-type;
<name>GigabitEthernet0/0/0/0</name>
}
<ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip”><address>
mandatory true;
<ip>10.1.1.1</ip>
}
<prefix-length>24</prefix-length>
leaf enabled {
</address></ipv4>
type boolean;
</interface>
default "true";
</interfaces>
}
</config>
leaf link-up-down-trap-enable {
</edit-config>
<commit/>type enumeration {
enum enabled { value 1; }
</rpc>
...
]]>]]>
4
YANG abstraction example
Cisco NSO/Tail-F – Abstraction Capabilities using Modeling language (Netconf/Yang)
Abstraction enabled with the decoupling of Service Layer
to the Underlying Device/Infrastructure Layer
NED 1
Confidential
NED 2
5
NED ‘N’
5
Cisco Orchestration and SDN Strategy for SPs
NFV View
• Generic Orchestration architecture that spans
physical and virtual domains and migration
• Generic architecture for different use cases
BSS
including mobility, vCPE and virtual Managed
Services
OSS (Prime Service Catalogue, etc.)
Network Services Orchestrator
NFVO
CTCM / ESC
VNF
Manager(s)
VNF3
VNF2
VNF1
Openstack
EMS
Hypervisor
PHYSICAL INFRASTRUCTURE
Confidential
Virtualized
Infrastructure
Manager(s)
SDN
Controller
DC Overlay
SDN
NFV INFRASTRUCTURE
6
Tail-f NSO
Confidential
(Network Services Orchestrator)
7
Reality: An Ambitious Layer 3 VPN
Peering VLAN,
subinterface, and eBPG
SVI connectivity
and highavailability
configuration
Transit VLAN
Tenant A
156.5.5.5
VLAN 801
VM
OS
EXT 1
ASR 1
ASR 2
AS
64554
EXT 2
VLAN 801
Routes to enterprise
networks need to be
established
Provider Edges
Layer 3 IEEE 802.1Q subinterface
OpenStack
Computing
Node
Data Center
Layer 2 VLAN
Tenant Private VRF
OpenStack Layer 3 Neutron
Confidential
8
Network Orchestration Layer
BSS/OSS
Network Service Request
Service Attributes
Network Orchestration Layer
Agility : Model-Driven
Operations: Network Transactions
Minimal
Device Configuration
New Service Type: 2 days
New Device Type: 2 weeks
Confidential
9
NSO Overview
OSS/BSS
Portals
Python, REST, Java
Network
Engineer
Network-wide CLI, WebUI
Tail-f Network Control System
Service Manager
Service
Models
Device Manager
Network
Element Drivers
OpenFlow
Device
Models
Multi-vendor
Transactions
Model-driven
NETCONF, XML, CLI, SNMP…
Large Multi-Vendor Networks:
Hardware, Virtual, OpenFlow
Confidential
10
10
Tail-f NSO Main Features
Tail-f NSO Main Features
Tail-f NSO
•
Model-based architecture
•
Transactional guarantees
•
In-memory storage of
configuration states for all
services and all devices
•
FastMap* algorithm for
service-layer CRUD
operations
•
Reactive FastMap*
* Patent No.: US 8,533,303 B2
Confidential
11
Tail-f NSO Main Feature 1: Model-Based Architecture
BSS
Service
Models
Tail-f NSO
Device
Models
No hard-coded assumptions about:
•
Network services
•
Network architecture
•
Network devices
Instead:
•
Data models written in YANG
(RFC 6020)
Multivendor Layer 2, Layer 3, and Layer
4-7 Network
Confidential
12
Tail-f NSO Main Feature 1: Model-Based Architecture
BSS
YANG data models for:
Service
Models
Tail-f NSO
Device
Models
•
Network services
•
Network topology
•
Network devices
YANG data models drive:
•
Northbound APIs
•
User interfaces
•
Southbound command sequences
Benefits:
•
Can be used for all types of
services and all types of networks
Multivendor Layer 2, Layer 3, and Layer
4-7 Network
Confidential
13
Tail-f NSO Main Feature 2: Transactional Guarantees
BSS
Transactional guarantees:
Tail-f NSO
Transactional
Integrity
•
Help ensure fail-safe operations
(automated handling of
exceptions)
•
Keep accurate copy of network
configuration state in Tail-f NSO at
all times
Benefits:
•
Automation can be based on
accurate real-time view of service
and network state
•
Much higher degree of automation
possible
Multivendor Layer 2, Layer 3, and Layer
4-7 Network
Confidential
14
Tail-f NSO Main Feature 3: In-memory Data Store
Tail-f NSO
Multivendor Layer 2, Layer 3, and Layer
4-7 Network
Confidential
•
Stores both service and device config
states
•
RAM datastore with persistent
journaling
•
Runs as integral part of NSO
application (in the same address
space)
•
Native YANG database with compact
binary data encoding
•
1:N data replication (asynchronous or
synchronous)
•
Subscription notifications with priority
level ordering
•
In-service schema (data model)
upgrade
•
Distributed 2PC transaction manager
15
Tail-f NSO Main Feature 4: FastMap* Algorithm
CREATE SERVICE
UPDATE SERVICE
DELETE SERVICE
REDEPLOY SERVICE
Tail-f NSO
FastMap:
•
Only the CREATE operation needs
to be specified
•
UPDATE, DELETE and REDEPLOY
operations are automatically
generated and compute minimal
change set needed
FastMap*
Benefits:
•
Reduces service implementation
code by two orders of magnitude
•
Supports modifications of services
at runtime
* Patent No.: US 8,533,303 B2
Confidential
Multivendor Layer 2, Layer 3, and Layer
4-7 Network
16
Tail-f NSO Main Feature 5: Reactive FastMap*
CREATE SERVICE
UPDATE SERVICE
DELETE SERVICE
Tail-f NSO
REDEPLOY SERVICE
FastMap*
Changed network
state triggers
service redeploy
Benefits:
One algorithm supporting:
•
Provisioning
•
Orchestration
•
Elasticity
•
Virtual machine and VNF
mobility
•
Self-healing network
* Patent No.: US 8,533,303 B2
Multivendor Layer 2, Layer 3, and Layer
4-7 Network
Confidential
17
NSO Overview, Zoom 3
Network
Engineer
OSS/BSS
NETCONF
NSO
REST
CLI
EMS/NMS
Web UI
SNMP
JAVA/Javascri
pt
Service
Models
Service Manager
Script API
AAA
Package
Manager
Mapping
Logic
Core Engine
Templates
Fast Map
Developer
API
Alarm Manager
Notification Receiver
REST
Device
Models
OpenFlow Controllers
Network Element Drivers
NETCONF SNMP
Device Manager
CLI
WS
Openflow Switches
Multi-Vendor Network
Confidential
18
18
NED Overview
• NED’s are created and maintained by Cisco Engineering.
• NED’s are classified as either Production or POC grade by Cisco Engineering.
• Production Grade
• Can be sold as a license
• Used in production today and continuously tested towards all active NCS/NSO versions on
real equipment (reference hardware and software versions).
• Fully supported by the Cisco Support team.
• It covers at least the use cases of its current customers and the coverage is continuously
expanded.
• Messaging to customers: The NEDs you purchase will support all the configuration you
require for when you need it
• Provided that the customer has support contract, makes available the required configurations in
advance.
• POC Grade
• Can be used for demos or POC’s.
• Can be sold if upgraded to Production Grade.
• Not tested continuously on real equipment.
• Messaging to customers: The NED can show case NCS towards the devices in a POC but for a
real deployment, the NED needs to be upgraded to production grade.
Confidential
19
Supported Vendors
Production Grade
Confidential
PoC Grade
20
Tail-f NSO Differentiation: Agility and Flexibility
Implementation of new service = 2 days
How?
Data model for MPLS L3 VPN service:
100 lines of YANG
Mapping MPLS L3 VPN service model to
network of Cisco 7600, Cisco ASR 9K
and 3.party devices:
300 lines of XML template
Confidential
Support for new device type = 2 weeks
How?
Develop YANG device model
Network Element Driver automatically
generates sequences of device-specific
commands (CLI, REST, SOAP, SNMP,
NETCONF, etc).
How?
How?
FASTMAP algorithm
NED algorithm
21
21
NSO for Network Engineers – User Interfaces
Auto-rendered Web UI with
powerful extensibility features
Confidential
IOS-XR or J-style CLI for networkwide configuration changes
22
Tail-f NSO & NFV
Confidential
23
NSO is providing a migration path to NFV
BSS
Tail-f NSO
VNF
Virtual
Compute
VNF
VNF
Virtual
Storage
VNF
Virtual
Network
Virtualization Layer
Compute
Hardware
Traditional networking
Storage
Hardware
Network
Hardware
NFV/SDN
Technology migration path
Confidential
24
24
End-to-End Service Orchestration with ESP
(3) Customer orders new
Services from the Catalog:
a) service chain for new branch
b) IaaS container at DC
Portal /
Service Catalog
(PSC)
(0) Customer Orders
CPE for a New Site
SP OSS/BSS
REST API
(11) Customer Order
(1) CPE Order
ESP
(13) Push policies to
the CPE as necessary
CPE
Controller
(2) Call Home,
Zero touch CPE
Provisioning done
(4) Spin up the
Managed Service Chain
for the tenant
NFV Orch.
(DSC)
(14) CPE policies
modified as per
Service request
(6) Perform workload
(11) Optimize & Perform
necessary BW reservation in placement decision
as per SLA requirement
the WAN
(12) Analyze WAN, reoptimize and program new
path as necessary
Web VM
NAT
© 2012 Cisco and/or its affiliates. All rights reserved.
DB VM
FW
DC
“A”
PE
vESA
DCI
Customer Premise
(9) Service spin-up
as per the tenant’s
order
DCI
NFV POD
vCPE
CPE Arrives @ Site
(10) Program DCI and
Propagate new service
routes to the DCI
MP-BGP
Route Propagation
vFW
(8) Spin-up IaaS + NFV
service at the identified
DC/POD
DC & NFV Orchestration
(ACI+DSC)
WAN SDN Controller (WAE)
(5) Managed Service Chain
Spinned up in the NFV
POD
PE-CE
Route
Propagation
(7) Most optimal DC &
POD Identification as per
SLA requirement
Service
Assurance
Cross Domain Orchestrator (NSO)
(1) CPE Order,
Provisioning
parameters
EPN
(15) Perform Service Activation à
Notify BSS about Service
Activation to Commence Billing.
Start Service Assurance /
Monitoring
DC
“B”
Service Provider WAN
Cisco Confidential
25
Tak
Confidential
26