Brkopt 2102

Software Innovations and Control
Plane Evolution in the new SDN

Transport Architectures
Emerson Moura,
Distinguished Systems Engineer
emoura@cisco.com
BRKOPT-2102
SDN Investment – a disclaimer!
http://www.networkcomputing.com/data-centers/sdn-can-we-skip-the-hard-part/d/d-id/1269189
BRKOPT-2102 © 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public 4
Agenda
• Introduction
• SDN evolution of WAN
• WAN SDN Automation
• WAN SDN Optimization
• Programmable WAN Architecture Evolution
• Conclusions
Introduction
Routing Control Plane Evolution
Hybrid Control Plane Architecture
Traditional Control Plane SDN Control Plane Architecture
Architecture (Centralized)
(Distributed)
OpenFlow
• SDN Optimistic View

Application
• Simpler, more flexible, more scalable, cheaper
Distributed Control Plane
Centralized Control Plane
• SDN Pessimistic View
Data Plane
• Re-inventing the wheel, moving complexity
APIs
around
Network and Device Programmability:
Software APIs Automating the Network Infrastructure
Application Frameworks, Management Systems, Controllers, ...
C/Java Python NETCONF REST OpenFlow DC Fabric OpenStack Puppet Protocols …
RESTful
Management Puppet …
Orchestration Neutron
“Protocols”
Network Services BGP, PCEP,...
Control OpFlex
Forwarding OpenFlow
YANG JSON Vendor spcific Plug-Ins

Device API and Data Models
Operating Systems
“SDN” main value proposition:
Improve Network and Services
Traditional Managed Services New era of NFV & SDN
CPU, GB, bps

CPU, GB, bps
Next-Gen Internet & Cloud-based Service Delivery
Cross Domain Orchestration & Controller Domains
Service Service Service Service Service API
Cross-domain
Cross Domain Orchestrator Orchestrator
Domain abstracted
WAN DC Network
API
Compute Domain Storage
Controller Domain Controller Controller Domain Controller
Domain specific
controllers provide
device abstraction
Network and data

centre aware
Benefit: Cloud based service delivery with a dynamic, deterministic, optimized network
service placement
The new “SDN” WAN Era - Executive Summary
DC Network Compute Storage
WAN
Domain Domain Domain
Controller
“not sure why folks keep talking about SDN as mostly a Controller Controller Controller
datacenter technology… value in the WAN” - Vijay Gill,

MSFT
“we’re doing SDN to program services instead of re-

architecting the network and the OSS for every new service…
reduce our time-to-market from years to weeks…” - Axel
Clauberg, DT
“Global network optimization versus decentralized protocols

approximating global state… Manage the network as a fabric
rather than a collection of individual boxes… Traffic
differentiation” - Amin Vahdat, GOOG
SDN evolution of WAN Transport
SDN enables IP/MPLS evolution to a hybrid control-plane
Applications Applications Applications Applications
Controller
Evolution
• Distributed Control remains best for many use-cases; e.g. IGP convergence
• Centralized Control introduces new value; e.g. TE placement optimization
(see for example M. Horneffer(DT), “IGP Tuning in an MPLS Network”, NANOG 33, February 2005, Las Vegas )
Head-End TE Path Placement (an example)
Centralized control-plane improves distributed control-plane insufficiencies
Martin Horneffer (DT), “IGP Tuning in an MPLS Network”, NANOG 33, February 2005, Las Vegas
Cox Case Study: SDN – PCE vs Distributed Path Computation
M. Khaddam et al. invited SCTE 2014
Path Compuation Model

100.00% Online PCE
Link Utilization
80.00%
60.00%
40.00%
20.00%
0.00%
41
11
16
21
26
31
36
46
51
56
61
66
71
76
81
86
91
96
1
6
106
171
101
111
116
121
126
131
136
141
146
151
156
161
166
176
181
186
191
196
201
206
211
216
221
226
231
236
Links
Cisco’s SDN Proposed Architecture
Controller and API enabling technologies
Applications
• End User Applications
Applications Applications • External ISPs / Content Providers
• Service Provider Applications – OSS/BSS, Orchestration,
Data Analytics, etc
Controller - “Apps” APIs: REST based

Network SDN Controller
Control Control Control
Network Controller
Applications Applications Applications
• Augments distributed control plane
Infrastructure n/w controller • Control application – function specific
• Infrastructure common controller; e.g. ODL platform
Controller - NE APIs: PCEP, BGP-LS, OF, Netconf/YANG, etc
Network
• Simplified distributed control plane
• Augmented by central controllers
• Data plane forwarding
ODL – a great example of Infrastructure Controller
• OpenDaylight is an open source project under the Linux Foundation with the
mutual goal of furthering the adoption and innovation of Software Defined
Networking (SDN) through the creation of a common market-supported
framework.
• www.opendaylight.org
• wiki.opendaylight.org
WAN SDN “southbound” APIs to NE Protocols …
Key Function Protocol/API Comments
IGP Topology BGP Link-State (BGP-LS) Wraps up LSDB in BGP transport and pushes to BGP
speaker on SDN WAN Orch Platform
Create, Modify and Delete TE Stateful Extensions to PCEP Introduced as part of Stateful PCE effort
or SR Tunnels
Classification and Action Openflow Extensions Leveraging per-flow MATCH/Action semantics
Security BGP FlowSpec (BGP-FS) Employs BGP RR to distribute flowspecs to O(# of edge
or peering routers)
Read/Write of Persistent Netconf/Yang Gaining traction with vendor implementations and now
Configuration Data on on OpenDaylight Platform
Network Devices
WAN Orchestration API REST Standard web service APIs exposes WAN Orch
platform functions and services to applications
WAN Orchestration API RESTCONF Employs REST API principles enabling application
programmability of YANG Data Models
WAN SDN “southbound” APIs to NE Protocols …
Key Function Protocol/API Comments
IGP Topology BGP Link-State (BGP-LS) Wraps up LSDB in BGP transport and pushes to BGP
speaker on SDN WAN Orch Platform
We should not anymore care much about which
Create, Modify and Delete TE
Stateful Extensions to PCEP Introduced as part of Stateful PCE effort
protocol does what…
or SR Tunnels
Classification and Action Openflow Extensions Leveraging per-flow MATCH/Action semantics
• Focus
Security BGP FlowSpec
on the business (BGP-FS)
needs and Employs
outcome; the BGP RRapplication
workflow, to distribute flowspecs
and APIto O(# of edge
layer
or peering routers)
Read/Write of Persistent Netconf/Yang Gaining traction with vendor implementations and now
• SDN orchestration/controller
Configuration Data on
platforms “abstract away” all of the protocol details
on OpenDaylight Platform
Network Devices
• Protocols are generally open and open source; i.e. OpenDaylight
WAN Orchestration API REST Standard web service APIs exposes WAN Orch
platform functions and services to applications
• Need open standards because networks are heterogeneous
WAN Orchestration API RESTCONF Employs REST API principles enabling application
programmability of YANG Data Models
WAN SDN potential Use Cases – “Northbound Apps”
CPE Metro and Access Edge Core Data Center
Metro DWDM Long Haul DWDM
CPE Agg and access Edge Core Infrastructure Data Centre

Infrastructure
Virtualized n/w
NFV services Automated configuration NFV services Bandwidth calendaring Virtual 2 virtual n/w
interconnect
Automated Service definition Automated Demand engineering / PCE
provisioning provisioning Service chaining
Service assurance Single/multi layer optimization
Analytics Subscriber ctl Analytics collection
Analytics
SDN value example - Cox Virtualized Service Architecture
Reference: J. Finkelstein - Lightreading public seminar Aug. 2014
CONTROLLER WITH INTELLIGENCE TO

TOPOLOGY AND CALCULATE ROUTES,
TOMOGRAPHY DATA SDN
OPTIMAL PATHS,
Controller SERVICES AWARE
SDN enables zero-touch management using openflow and netconf/yang

Coordinate maintenance by communicating New packet routing path
Optimize resources real-time by managing routes by application
Service Steering to
Service Aggregator Cloud Services
Cloud
Service Provider Network
WAN SDN Automation
SDN Automation – YANG/NETCONF Programmability
Business Drivers:
 Radical simplification of Network/OSS (OPEX)
 Faster deployment of services
DT @ ONS 2013
“We believe carriers can no longer afford to hard-code services into the OSS if they want to get to market quickly with
new services. The Tail-f NCS solution, with both services and the network modeled in a standardized high-level
language, shortens time to market, increases vendor independence and dramatically improves the cost
structure. This SDN solution is a key component in our next generation network architecture.” - Axel Clauberg, Vice
President at Deutsche Telekom
NETCONF/YANG Agility Example
Implementation of new service = 2 days Support for new device type = 2 weeks
How? How?
Data model for MPLS L3 VPN service:
Develop YANG device model
100 lines of YANG
Network Element Driver automatically

Mapping MPLS L3 VPN service model to
generates sequences of device-specific
network of Cisco 7500, Cisco ASR 9K
commands (CLI, REST, SOAP, SNMP,
and Juniper MX480:
NETCONF, etc).
300 lines of XML template
How? How?
FASTMAP algorithm NED algorithm
Cisco/Tail-f Industry Standards and Collaboration
Tail-f’s Focus Tail-f Contributors
• Martin Björklund
NETCONF and
• Contributes to NETCONF and NETMOD WG
YANG Data Modeling • Editor of YANG RFC
Software Defined • Carl Moberg

Networking • OF-CONFIG YANG Modules
Network Functions • Carl Moberg

Virtualization • Management and Orchestration (MANO)
• Håkan Millroth
Cloud Operating System
• OpenStack plugin for the Havana release
Service • Håkan Millroth

Provisioning • Harmony Catalysts
Modeling Carrier • Carl Moberg

Ethernet Services • Contributing to MEF FM and PM SOAM
VNF Management challenge
ETSI NVF Architecture
• EMS for each vendor’s VNF leads to
EMS sprawl and complexity for
Orchestrator and OSS
• Similar problem results in multiple
vendor-specific VNF managers
• Today’s static OSS cannot deliver the
service agility required to meet NFV
objectives, because:
• service definitions are hard-coded in
OSS
• translations to network (= VNFs)
requires substantial integration projects
YANG Multi-Vendor NFV Application Controller
Fully automated service provisioning, orchestration and VNF control
• Replace multiple vendor-specific EMSs

with a single system (NCS) that manages
all VNFs and fulfills VNF manager role
• Eliminate EMS sprawl, simplifies the Cisco NSO

Orchestrator and OSS
• Dynamically definable network

applications, with automated translation to
VNF operations
• Common API defined by data models for:

 network applications
 virtual network functions
WAN SDN Optimization
SDN Transport Optimization &Traffic Differentiation
Network Services Traffic Differentiation WAN Transport Optimization
SDN (vs Offline) WAN Optimization
• “SDN” increasingly useful as change frequent, and the load close to the max-
link-load objective.
Traffic change frequency
hourly SDN WAN

(online)
daily
monthly
Planning
annual (offline)
25% 50% 75% 100%

Max Link Utililization
Google B4, SDN Global WAN = The first mover (2011-2013)
Reference: ACM SIGCOMM’13
WAN Optimization building on the Cariden Portfolio
A Common Platform For Architecture, Engineering and Operations
Cisco WAE Design Cisco WAE Live Operational
Desktop Application Web Application
Design, engineer and Infrastructure Analytics
EXPLORE/ – interactively
plan IP/MPLS Predictive Model MAP
ANALYTICS
networks visualize, navigate and
Time report on near real
Archive Web Application Plan Series time and historical
Archives Data-store
data
Plan file Archives Time-Series Datastore
Automatically discover and

continuously maintain network data
Cisco WAE Collector
Offline Collection Online Collection
SOAP
API XML
Flow Data SNMP and CLI
SAM
External Flow Collection Cisco Huawei Juniper ALU
Systems
Router Configs Statistics
Multivendor Network Devices
WAN Automation Platform
Service, Network,
Network Coordinated Failure and Analytics Weather Map
Business Network
Planning Maintenance Analysis Intelligence
REST APIs Inventory
Design and Network Planning Visualization, Analytics, BI, Inventory
WAN Automation Engine
Analytics
Optimization and Calendaring
Prediction
Current Model Network Modeler New Model
Collector Network Deployer

Interface
SNMP CLI NetFlow BGP-LS NMS/EMS NETCONF/YANG EMS/NMS PCEP
.........
Multivendor Network Devices
Unified Application Framework & ODL Integration
Unified Application Framework
Coordinated Segment Bandwidth Application

Offline Planning IGP Convergence Weather Map Inventory Bandwidth on
Failure Analysis Maintenance Routing Calendaring Latency Routing
Analyzer Demand
Optimizer
WAN Automation Engine
SDN Controller
WAN SDN Use Case: Coordinated Maintenance
• Optimal and Automated Network maintenance of routers, jointly with optical (SRLG info).
• Reduce operational overhead, and human error.
API Query: What is the best time for R1 to be taken out of service for 2 hours?
Cariden & SDN Platform: Analyze historical data, find the best time to remove R1 for 2
hours, and automate operation (according to customized workflow).
R1
Time(1) Time(n)
WAN SDN Use-Case: TE Optimization
Problem: Solution: ① Real-time data collection
reveals latency at L3 accessible to
A service provider needs to ensure low PCE assigns new TE metrics based on App (caused by fiber cut / optical
latency for high priority traffic, even in the measured latency, thereby routing LSPs failover)
event of a fiber cut according to lowest latent paths ② App requests TE Metric change on L3
2 circuits routed over L1 link
Latency ③ PCE computes new TE metric that
Reducer RESTful APIs will decrease latency of traffic
3 ④ PCE programs TE metric change
App Controller Platform using PCEP, causing LSPs to reroute
Collection Programming
PCEP 4
1
Rc
WAN
LSP
High latency!
R1 Ra Rb R2
O1 O2
WAN SDN Use-Case: Multilayer Transport Optimization
Problem: Provider wants to take Solution: Controller determines when a ① Realtime data collection
bypass route is the best choice, and reveals trending congestion
advantage of lowest cost path, which may (Rc-Rb link) imminent
involve direct optical path bypassing provisions new topology.
routers. ② App requests Multi-layer
optimization
2 ③ PCE programs Ra and Rb to initiate
Setup
RESTful APIs ④ New Ra-Rb link is injected into
IP/MPLS Topology
Controller Platform 3
Collection Programming
PCEP
1
WAN Rc
Ra Congested!!
Rb
4
R1 GMPLS UNI
R2
O1 O2
WAN SDN Use-Case: Demand Admission
① Network conditions reported to
Problem: Provider’s customer has an “on Result: After determining a best path, collector
demand” need for a DC backup or to PCE programs an LSP via PCEP.
② Customer requests DC #1 – DC #2
move a cache bandwidth ASAP
③ Demand admission request:
2 3 <R1-R3, B/W, NOW>
4 ④ PCE returns option and customer
RESTful APIs confirms
Controller Platform ⑤ If needed (insufficient bandwidth), R1-

R3 LSP tunnel programmed via
Collection PCEP
Programming
PCEP
1
WAN Congested!!
R2
R1 5
Data Center #1 Data Center #2
R3
Programmable WAN Evolution
Network-aware
Applications
WAN Control-plane Innovations
The new Internet (2009 --)
The textbook Internet (1995-2007)
WAN Traffic
Services-aware 50-200G
Networks WDM
Capacity
Super-
CCD Planning
channel
OAM & ROADM
FRR PerfMon
Connectionless MPLS TE
best-effort QoS
Early Internet
IPNGN (2000 – 2010) Today
From Device Centric to Network-as-Platform
Network-wide orchestration instead
Network-wide
Device-centric of individual device config. for service
(future) definition, and deployment.
(past)
Orchestration
Config SDN centralized controller offers
Plane network wide policy & control; e.g.
application-aware routing, bandwidth
Control SDN cntrl. calendaring & scheduling, multi-layer
traffic optimization.
Plane
Device functionality important for:
Data • Packet forwarding & Route
Plane distribution
• Convergence, local failure detection
& repair
• Local features: OAM/PM, QoS,
Timing, mcast replication …
Segment Routing (SR) – Basic principles overview
Nodal segment: Operator allocates a label from the SR registry
to each node. For example Z is given label 65 A packet injected anywhere
Adjacency segment: Node automatically allocates a local label with top label 65 will reach Z
for each adjacency. For example Label 9001 allocated for O.
Forwarding state (segment) is established by IGP

 LDP and RSVP-TE are not required BB C D
A
A C D
MPLS Dataplane is leveraged without any modification
push, swap and pop: all what we need segment = label 9001 ZZ
M N
N O
O P
P 65
The flow state is in the header, not in the
network
• A node holds state only for global segments & local segments; A packet injected at node C
with label 9001 is forced
• For a flow F, only its ingress node a per-flow state. Any other node does
not hold state for F. Hence, while they can be millions of flows crossing a
through datalink CO
midpoint, its SR FIB scale is kept small.
SR with WAN Orchestration
• WAN O allows for the best possible simplification of SR
• Optimum state computation; Ask for path to G
with certain SLA
• A single touch-point at the Source Node; (delay, bandwidth,
• Instant set-up time; duration, etc)
• Also a stateful PCE, as with MPLS-TE, can be help to: 1 0

F
• Compute globally optimum paths for traffic-engineered SR tunnels; B D
G
• Instantiate SR tunnels based on requests from applications;
• Instantiate traffic steering onto the instantiated tunnel; C E
A
• Minimal changes
SDN WAN O
• PCEP capability to negotiate SR between PCE and PCC;
• IGP capability used by PCE’s to advertise their SR/PCE capability; Indentify best
path and
• Extension to BGP-LS to convey the segments; segments (B, D,
• Extension to I2RS policy retrieval to include segment information; C, E, G)
• Minimal changes in (Cisco) CLI and look and feel stays same;
SR + PCE value - A real Customer Example
Reference: MPLS World Congress paper D2-13 C. Filsfils et al.
SR with Centralized Controller allows for better network utilization (50% in specific example), predictability,
and operation simplification (2000x less tunnels in this specific example).
SR (green) is compared to RSVP-TE (red) for the 72 most important Failures in a

real network
Legacy IP-DWDM Inefficiencies – OpEx Challenge
LFA/TE FRR Fate-Sharing with WAN Disjointness for PoP. Inhomogeneous Latency
primary and/or Fate sharing
of Logical Link-Bundles
Agile IP layer
• Too little information sharing
• Too limited interaction between layers
Static DWDM layer
The Shifting Economics of Converged Network Transport
Reference: IEEE OFC 2013 NSu1 workshop Doverspike, AT&T et.al.
• 100G scales transport, and lowers TCO; “Moore’s Law” benefit and “Shannon limit”
• 100G photonics cost dominates, and motivates maximum DWDM utilization; Statistical & sub-
wave multiplexing, Multi-layer network optimization
100G TCO lower

than 40G, and 10G.
100G Routing
CapEx < 25%
Photonics > 60% of CapEx
Graph source: cisco, 2011

IEEE OFC Market Watch 3
The Multi-Layer Optimization
• The new DWDM layer enables a truly Converged IP+Optical Transport
• Scalable more than 8Tb/s per fiber, based on 100+Gb/s DWDM channels
• Flexible, fully non-blocking wavelength switching
BUT…
• Past: Optical BW was relatively cheap  throw optical BW at the problem
• Future: Optical BW most expensive part of CapEx  need to use it efficiently
• SDN transport enables Converged network optimization

• SLA aware routing (e.g. min Latency) or Cost aware routing (e.g. min regens)
• Link failure Restoration can lead to 20+% savings, by reusing available router ports
• SDN innovation most important for Converged Transport SDN

• The IP/MPLS evolution to SDN is an important innovation! Controller
• Optical control, always mainly centrally controlled (NMS)! (WAN O)
Example of the value of Multilayer Optimization
Reference: IEEE Comm. Mag., Jan. 2014 O. Gerstel et. al.
L3
L0
Multi-Layer Restoration - basic use-cases
• Todays networks provide spare capacity on
core links to cater for other core link failures.
• If the optical network can, fast enough, restore

link failures (and signal new lambda to router), MLR-P
this spare capacity could (partially) be saved. MLR-O
No MLR
260G 70G
+ +
180G 180G 180G IP-only MLR-A
+
130G
Multi-Layer Restoration efficiencies
Premium: 30G 3 x 100G Worst-case stable:

R1 R2 120G on 200G
BE: 90G Avg IP util: 120/300= 40%
2 x 100G
Premium: 30G Worst-case transient:
R1 R2 120G on 100G. BE loss
BE: 90G Worst-case stable:
120G on 200G
Avg IP util: 120/200= 60%
Typically, 10-40 % less interfaces

(less router ports, less transponders, less wavelengths, less power, more scale)
Multilayer Optimization vs Single-layer Optimization
Reference: IEEE OFC 2015 M. Khaddam (Thursday 8 am, invited) Applications
(Multi-layer, SPRING, etc)
SDN
EMS
Controller
Client
WDM
Next Gen WDM - Flex-Rate & “Super-Channel”
Optimize trade-off of Spectral-efficiency vs Distance to minimize OEO Regens
baud rate line bit rate payload bit rate
BPSK – 28 Gbaud/s | 56 Gb/s | 50Gb/s
QPSK – 28 Gbaud/s | 112 Gb/s | 100Gb/s
16QAM – 28 Gbaud/s | 224 Gb/s | 200Gb/s
16QAM – 35 Gbaud/s | 280 Gb/s | 250Gb/s
Multi-Layer Planning Tool Extensions
L3
 Design “add-on” innovation (IEEE OFC, and JOCN)
 incorporate IP jointly with optical (e.g. SRLGs)
 Maximize overall network utilization, optimize
capacity upgrades, and asses super-
channels.
 New IP+O restoration features being developed. L1
 Automated “L1- Collector-license” with 6.1, YANG-
model based (supported by CTC 10.x).
SDN Advanced Traffic Management
• Centrally optimized actions before,
during and after service provision to Traffic Management
ensure network supports services within
the bounds of SLAs
Demand Calendaring Real-time
• Functions:
• Demand calendaring – ensuring future Demand Admission
Now
capacity is available for scheduled services and Placement
• Demand Admission and placement –
verifying there are sufficient resources to Network Optimization Next week
place a demand
• Network Optimisation – moving demands to Capacity Planning Next month
make more efficient use of resources
• Capacity planning – how much capacity you Offline
need in future to continue to meet the
committed SLAs?
Network Aware Service Placement Benefits from
centralised optimization
Reference: MPLS World Congress 2014 paper D2-5 J. Evans et al
• Centrally optimized TE can typically support 30-35% more traffic for the same
provisioned bandwidth (when compared to other placement algorithms).
Avg. Network Worst-Case Utilisation

180%
160%
135% 130% 130%
140%
120%
100%
100%
80%
60%
40%
20%
0%
Random WRR Lowest latency Demand eng
Example of Network Aware Service Placement
Based on Cisco WAE Design Planning Tool
DC: SJC DC: CHI

WC delay: 33.0ms WC delay: 22.0ms
WC path util: 90.8% WC path util: 91.4%
WC net util: 90.8% WC net util: 91.4%
DC: NYC DC: KCY

WC delay: 29.5ms WC delay: 22.2ms
WC path util: 101.8% WC path util: 90.8%
WC net util: 101.8% WC net util: 90.8%
DC WAN connectivity in the Cloud-era - More than DCI
• “DCI” with varying requirements:
Ent DC1 Ent DC2
• Multiple 100G needs;
• Higher Density Interconnect in metro;
• Inter-DC architecture extend beyond metro;
• Enterprise Data Center inter-connect;
• Enterprise Data Center to Provider Data PE PE
Center;
• Provider Data Center to Provider Data SP NGN
CE DCPE CE
Center ;
DCPE
DCE
DCE
SP DC1 SP DC2
WAN Orchestration: Network Aware Service Placement
1 4 1 Additional capacity needed –
Workload
Workload Deployed request cloud resources
increase
Cloud
Request Data Center
Internal resources 2 Check resource availability,
Data Center
performance – determine
2 optimal location
SP VPN
3 3 Provision network tenant,
virtual compute, storage, VPN,
Cloud services
Data Center
4 Virtual infrastructure and

Cloud
Data Center
network container active
SDN-enabled Optimized Network Consumption Model
1. Services Catalog 2. Control Plane 3. Data Plane
Choose CP Align DP
per use-case: to use-case
Core / Transport High High
Multi-chassis
Peering
Virtual, or
Hybrid
Expansion Single-chassis
DCI
High-end System
PE
Single-chassis
Subscriber Services Today’s mode Low-end System
on the router
Virtual PE (vPE)
Virtual Routing
Low
Virtual RR (vRR)
Low
SDN SP end-to-end Architecture – High Level View
BSS • End-to-end service and customer
experience focus
OSS (Fulfillment & Assurance)
• Loosely-coupled modular
Service-Intent API
architecture
Platform APIs
Orchestration, Service & Policy Implementation

• Data model driven design –
Branch/CPE Multi-layer WAN DC & NFV
declarative and not imperative
EMS/NMS
Controller SDN Controller
• Orchestration across Multi-
SDN / APIs domain Muti-vendor & multi-layer
CLI/
SNMP
Netconf/
YANG
BGP
Segment
Routing
PCEP Openflow
Openstack /
vCenter
provides centralized policy and
services across entire network
CPE Metro and Access Core Data Centre
• Seamless integration with
existing and future OSS/BSS
Multi Vendor End to End (Physical & Virtual)

Conclusions
SDN WAN automation & optimization adoption…
can start today!
“Don’t bother me with new ideas; I’ve got a battle to fight!”

Key Take Aways
• Introduced SDN evolution of WAN Transport
• Summarized SDN WAN Transport Use-Cases
• Automation
• Optimization
• Evaluated SDN WAN Technology and Programmable Network Innovations
From Device Centric to Network-as-Platform
Network-wide orchestration instead
Network-wide
Device-centric of individual device config. for service
(future) definition, and deployment.
(past)
Orchestration
Config SDN centralized controller offers
Plane network wide policy & control; e.g.
application-aware routing, bandwidth
Control SDN cntrl. calendaring & scheduling, multi-layer
traffic optimization.
Plane
Device functionality important for:
Data • Packet forwarding & Route
Plane distribution
• Convergence, local failure detection
& repair
• Local features: OAM/PM, QoS,
Timing, mcast replication …
SDN WAN Innovations
• SDN is the most important new networking evolution for agility, automation,
optimization, and service orchestration;
• Much industry-wide development and innovation: open, multi-vendor, even
open-source;
• Incremental, phased adoption possible;
• Routing evolution allowing to centralized control automation & optimization;
• Optical control mainly central. SDN maintains PMO, need extensions, notably
YANG, and other layer-3 innovations e.g. BGP-LS.
• SDN particularly great enabler for Multilayer IP+Optical transport, removing the
GMPLS gaps.
Complete Your Online Session Evaluation
• Give us your feedback to be
entered into a Daily Survey
Drawing. A daily winner will
receive a $750 Amazon gift card.
• Complete your session surveys
through the Cisco Live mobile
app or from the Session Catalog
on CiscoLive.com/us.
Don’t forget: Cisco Live sessions will be available

for viewing on-demand after the event at
CiscoLive.com/Online
Continue Your Education
• Demos in the Cisco campus
• Walk-in Self-Paced Labs
• Table Topics
• Meet the Engineer 1:1 meetings
• Related sessions
Please join us for the Service Provider Innovation Talk featuring:
Yvette Kanouff | Senior Vice President and General Manager, SP Business
Joe Cozzolino | Senior Vice President, Cisco Services
Thursday, July 14th, 2016

11:30 am - 12:30 pm, In the Oceanside A room
What to expect from this innovation talk

• Insights on market trends and forecasts
• Preview of key technologies and capabilities
• Innovative demonstrations of the latest and greatest products
• Better understanding of how Cisco can help you succeed
Register to attend the session live now or

watch the broadcast on cisco.com
Thank you

Brkopt 2102

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Brkopt 2102

Uploaded by

Copyright:

Available Formats

Software Innovations and Control

Plane Evolution in the new SDN

• SDN Optimistic View

C/Java Python NETCONF REST OpenFlow DC Fabric OpenStack Puppet Protocols …

YANG JSON Vendor spcific Plug-Ins

CPU, GB, bps

Network and data

datacenter technology… value in the WAN” - Vijay Gill,

“we’re doing SDN to program services instead of re-

“Global network optimization versus decentralized protocols

Applications Applications Applications Applications

Path Compuation Model

Controller - “Apps” APIs: REST based

Controller - NE APIs: PCEP, BGP-LS, OF, Netconf/YANG, etc

Metro DWDM Long Haul DWDM

CPE Agg and access Edge Core Infrastructure Data Centre

CONTROLLER WITH INTELLIGENCE TO

SDN enables zero-touch management using openflow and netconf/yang

Service Provider Network

Network Element Driver automatically

FASTMAP algorithm NED algorithm

Software Defined • Carl Moberg

Network Functions • Carl Moberg

Service • Håkan Millroth

Modeling Carrier • Carl Moberg

• Replace multiple vendor-specific EMSs

• Eliminate EMS sprawl, simplifies the Cisco NSO

• Dynamically definable network

• Common API defined by data models for:

Traffic change frequency

hourly SDN WAN

25% 50% 75% 100%

Plan file Archives Time-Series Datastore

Automatically discover and

Design and Network Planning Visualization, Analytics, BI, Inventory

WAN Automation Engine

Current Model Network Modeler New Model

Collector Network Deployer

SNMP CLI NetFlow BGP-LS NMS/EMS NETCONF/YANG EMS/NMS PCEP

Coordinated Segment Bandwidth Application

WAN Automation Engine

Controller Platform ⑤ If needed (insufficient bandwidth), R1-

Forwarding state (segment) is established by IGP

• Also a stateful PCE, as with MPLS-TE, can be help to: 1 0

SR (green) is compared to RSVP-TE (red) for the 72 most important Failures in a

100G TCO lower

Photonics > 60% of CapEx

Graph source: cisco, 2011

• SDN transport enables Converged network optimization

• SDN innovation most important for Converged Transport SDN

• If the optical network can, fast enough, restore

Premium: 30G 3 x 100G Worst-case stable:

Typically, 10-40 % less interfaces

BPSK – 28 Gbaud/s | 56 Gb/s | 50Gb/s

QPSK – 28 Gbaud/s | 112 Gb/s | 100Gb/s

16QAM – 28 Gbaud/s | 224 Gb/s | 200Gb/s

16QAM – 35 Gbaud/s | 280 Gb/s | 250Gb/s

Avg. Network Worst-Case Utilisation

DC: SJC DC: CHI

DC: NYC DC: KCY

4 Virtual infrastructure and

Orchestration, Service & Policy Implementation

Multi Vendor End to End (Physical & Virtual)