Software Innovations and Control Plane
Evolution in the new SDN Transport
Architectures
Loukas Paraschis,
Technology Solution Architect, Cisco
Loukas@cisco.com

Abstract
2
In this session, we identify the important software innovations, and SDN control-
plane evolution, that jointly enable better network automation, more efficient capacity
utilization, and enhanced SLA for IP/MPLS and WDM transport.
We analyze the significant benefits of future programmable WAN architectures that
leverage these “SDN” innovation to advance operations, and traffic engineering,
extending to multi-layer transport optimization with novel restoration techniques.
The session also reviews the main SDN transport technologies becoming available
in the market place, including SDN controllers, Open Day Light, and protocols like
NETCONF/YANG, PCE-P/C, BGP-LS, Open Flow, Segment Routing, and GMPLS/
WSON.

SDN Investment – a disclaimer!
http://www.networkcomputing.com/data-centers/sdn-can-we-skip-the-hard-part/d/d-id/1269189

Agenda
• Introduction
• SDN evolution of WAN
• WAN SDN Automation
• WAN SDN Optimization
• Programmable WAN Architecture Evolution
• Conclusions

Acknowledgement of Insightful Interactions
• …with Service-providers, and especially with (alphabetic order) : Axel Clauberg (DT), Jeff
Finkelstein (Cox), Andreas Gladisch (DT), Mazen Khadam (Cox), Bikash Kooley (Google),
John Leddy (Comcast), Vishnu Shukla (Verizon), Valerio Torres (AMX), Kathy Tse (AT&T),
Gary Ratterree (Microsoft), Amin Vahdat (GOOG).
• … with Cisco, and especially S. Alvarez, J. Evans, A. Gous, C. Filsfils, G. Galimberti, A.
Maghbouleh, J. Medved, C. Metz, S. Spraggs, M. Thompson, W. Wakim, D. Ward.
• … with industry, and especially at IETF, IEEE, OSA OFC, OIF
• Disclaimer: This acknowledgement is NOT suggesting that these individuals have necessarily
reviewed or endorsed this presentation. Any errors are sole responsibility of the author.

Introduction
Some basic definitions and observations (to minimize the hype)

Traditional Control Plane
Architecture
(Distributed)
SDN Control Plane Architecture
(Centralized)
OpenFlow
Routing Control Plane Evolution
• SDN Optimistic View
• Simpler, more flexible, more
scalable, cheaper
• SDN Pessimistic View
– Re-inventing the wheel, moving complexity around
Application
Distributed Control Plane
Data Plane
Centralized Control Plane
APIs
Hybrid Control Plane Architecture
7

Network and Device Programmability
Software APIs Automating the Network Infrastructure
Application Frameworks, Management Systems, Controllers, ...
Device
Forwarding
Control
Network
Services
Orchestra8on
Management
…
…
OpenFlow
OpenFlow
Opera8ng
Systems
API
and
Data
Models
OpenStack
Puppet
C/Java
Puppet
Neutron
Protocols
“Protocols”
BGP,
PCEP,...
Python
NETCONF
REST
DC
Fabric
OpFlex
Vendor
spcific
Plug-­‐Ins
RESTful
YANG
JSON

Compute Domain
Controller
Storage
Domain Controller
DC Network
Domain Controller
Cross Domain Orchestrator
Service Service Service Service Service API
Domain abstracted
API
Cross-domain
Orchestrator
Domain specific
controllers provide
device abstraction
Network and data
centre aware
service placement
WAN
Controller
Next-Gen Internet & Cloud-based Service Delivery
Cross Domain Orchestration & Controller Domains
Benefit: Cloud based service delivery with a dynamic,
deterministic, optimized network

“not sure why folks keep talking about SDN as mostly a
datacenter technology… value in the WAN” - Vijay Gill,
MSFT
Compute
Domain
Controller
Storage
Domain
Controller
DC Network
Domain
Controller
WAN
Controller
“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
The new “SDN” WAN Era

SDN evolution of WAN Transport

SDN enables IP/MPLS evolution to a hybrid control-plane
centralized control improves network operations and optimization
Applications Applications
Controller
Evolution
Applications Applications
• Distributed Control remains best for many use-cases; e.g. IGPconvergence
• Centralized Control introduces new value; e.g. TE placement optimization
(see forexample M.Horneffer(DT),“IGPTuninginanMPLSNetwork”,NANOG33,February2005,LasVegas)
12

Head-End TE Path Placement (an example)
Centralized-control improves Distributed-control insufficiencies
13
Martin Horneffer (DT), “IGP Tuning in an MPLS Network”, NANOG 33, February 2005, Las Vegas

Cisco’s SDN Proposed Architecture
Controller and API enabling technologies Applications
• End User Applications
• External ISPs / Content Providers
• Service Provider Applications – OSS/BSS, Orchestration
etc
Network Controller
• Augments distributed control plane
• Control application – function specific
• Infrastructure common controller; e.g. ODL platform
Network
• Simplified distributed control plane
• Augmented by central controllers
• Data plane forwarding
Controller - “Apps” APIs: REST based
Controller - NE APIs: PCEP, BGP-LS, OF, Netconf/YANG, etc
Applications Applications
Infrastructure n/w controller
Control
Applications
Network SDN Controller
Control
Applications
Control
Applications
14

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

Platinum Gold Silver
Who is OpenDaylight Project?
16

OpenDayLight Highlights
• Built OpenDaylight Framework
– Opendaylight.org
– Cisco is a founding member
– Open Platform for Network
Programmability
– Open sourced community
– 40 community members
• Leverage KARAF containers
– Lightweight OSGI runtime
– Provides container where
different apps can run
– Ability to plug and play different
apps
Cisco Contributions

WAN SDN “southbound” APIs to NE Protocols …
18
Key Function Protocol/API Comments
IGP Topology BGP Link-State Wraps up LSDB in BGP transport and pushes to BGP speaker
on SDN WAN Orch Platform
Create, Modify and Delete TE
or SR Tunnels
Stateful Extensions to PCEP Introduced as part of Stateful PCE effort
Classification and Action Openflow Extensions Leveraging per-flow MATCH/Action semantics
Security BGP FlowSpec Employs BGP RR to distribute flowspecs to O(# of edge or
peering routers)
Read/Write of Persistent
Configuration Data on
Network Devices
Netconf/Yang Gaining traction with vendor implementations and now on
OpenDaylight Platform
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”…
19
Key Function Protocol/API Comments
IGP Topology BGP Link-State Wraps up LSDB in BGP transport and pushes to BGP
speaker on SDN WAN Orch Platform
Create, Modify and Delete TE
or SR Tunnels
Stateful Extensions to PCEP Introduced as part of Stateful PCE effort
Classification and Action Openflow Extensions Leveraging per-flow MATCH/Action semantics
BGP FlowSpec Employs BGP RR to distribute flowspecs to O(# of edge
or peering routers)
Read/Write of Persistent
Configuration Data on
Network Devices
Netconf/Yang Finally gaining traction with vendor implementations and
now on OpenDaylight Platform
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
We should not care anymore much about which protocol
does what…
• Focus on the needs and the business outcome; the workflow, application and API layer
• SDN orchestration/controller platforms “abstract away” all of the protocol details
• Protocols are generally open and now even the controller is open source; i.e.
OpenDaylight
• Need open standards because networks are heterogeneous

Core
Long
Haul
DWDM
Data
Center
Metro
and
Access
CPE
Metro
DWDM
Data Centre
Virtualized n/w
Virtual 2 virtual n/w
interconnect
Service chaining
appliances
Analytics collection
Core Infrastructure
Bandwidth calendaring
Demand engineering / PCE
Single/multi layer optimization
Agg and access
Infrastructure
Automated configuration
Service definition
Service assurance
CPE
NFV
Services
provisioning
Analytics
Edge
Edge
NFV
Services
Provisioning
Subscriber ctl
Analytics
WAN SDN potential Use Cases – “Northbound Apps”

Service
Aggregator
Service
Steering
to
Cloud
Cloud
Services
Service
Provider
Network
SDN
Controller
CONTROLLER WITH
TOPOLOGY AND
TOMOGRAPHY DATA
INTELLIGENCE TO
CALCULATE ROUTES,
OPTIMAL PATHS,
SERVICES AWARE
Immediate SDN value example - Cox Virtualized Service
Architecture Reference: J. Finkelstein - Lightreading public seminar Aug. 2014

WAN SDN Automation

SDN Automation – YANG/NETCONF Programmability
DT @ ONS 2013
Business Drivers:
§ Radical simplification of Network and OSS
(OPEX)
§ Faster deployment of services
“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

Brief History of Netconf/YANG
Reference: C. Metz TECMPL-3200
• SNMP and CLI have been around forever
• Overview of the 2002 IAB Network Management Workshop
defined Operator Requirements
– Source: RFC3535
• Netconf developed (2006) to read/write configuration data
between client (e.g. NMS) and server (e.g. router)
– Initially content-agnostic, needed a data model
• YANG developed (2010) as data model language for
Netconf
– XML-based, human-readable, flexible and extensible
24

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:
100 lines of YANG
Mapping MPLS L3 VPN service model to
network of Cisco 7500, Cisco ASR 9K
and Juniper MX480:
300 lines of XML template
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

NETCONF and
YANG Data Modeling
Cloud Operating System
Modeling Carrier
Ethernet Services
Service
Provisioning
• Håkan Millroth
• OpenStack plugin for the Havana release
• Martin Björklund
• Contributes to NETCONF and NETMOD WG
• Editor of YANG RFC
• Carl Moberg
• Contributing to MEF FM and PM SOAM
• Håkan Millroth
• Harmony Catalysts
• Carl Moberg
• OF-CONFIG YANG Modules
Software Defined
Networking
Tail-f’s Focus Tail-f Contributors
• Carl Moberg
• Management and Orchestration (MANO)
Network Functions
Virtualization
Tail-f Industry Standards and Collaboration

Tail-f Supported Vendors
• Rapidly growing list of
supported vendors
• Clean distinction between
protocol specific support code
and models
• Development turnaround for
new or extended drivers in
order of days or weeks

VNF Management challenge (ETSI NVF Architecture)
• An EMS for each vendor’s VNF leads to
EMS sprawl and more complexity for
Orchestrator and OSS to handle each
EMS
• 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 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
Tail-f NCS

WAN SDN Optimization

Network Services Traffic Differentiation WAN Transport Optimization
SDN WAN Transport Optimization through Traffic Differentiation

Cox Case Study: SDN – PCE vs Distributed path Computation
M. Khaddam et al. invited SCTE 2014
0.00%
50.00%
100.00%
1
6
11
16
21
26
31
36
41
46
51
56
61
66
71
76
81
86
91
96
101
106
111
116
121
126
131
136
141
146
151
156
161
166
171
176
181
186
191
196
201
206
211
216
221
226
231
236
LinkUtilization
Links
Path Compuation Model
Online PCE

SDN (vs Offline) WAN Optimization
“SDN” increasingly useful as change frequent and the load close to the max-link-load
objective
Trafficchangefrequency
annual
monthly
daily
hourly
Max Link Utililization
25% 50% 75% 100%
Planning
(offline)
SDN WAN
(online)

Google B4, SDN Global WAN = The first mover (2011-2013)
Reference: ACM SIGCOMM’13
34

WAN Automation Engine
Network
Interface
Network Modeler
WAN Automation Platform
Design and Network Planning
Network
Planning
Coordinated
Maintenance
Failure
Analysis
Visualization, Analytics, BI, Inventory
Weather Map
Business
Intelligence
Network
Inventory
Service, Network,
and Analytics
REST APIs
.........
Multivendor Network Devices
Optimization and Prediction
DeployerCollector
New ModelCurrent Model
CalendaringAnalytics
NMS/EMSNetFlowCLI
SNMP BGP-LS EMS/NMSNETCONF/YANG PCEP

Unified Application Framework & ODL
Integration
WAN Automation Engine
Cisco Open SDN Controller
Unified Application Framework
Bandwidth
Calendaring
Bandwidth on
Demand
Inventory
Coordinated
MaintenanceOffline Planning IGP Convergence
Analyzer
Failure Analysis Weather Map
Application
Latency Routing
Segment
Routing
Optimizer

Evolved
Programmable
Network
Evolved
Services
Platform
WAN Automation Engine
Network
Interface
Network Modeler
Design and Network Planning
Network
Planning
Coordinated
Maintenance
Failure
Analysis
Visualization, Analytics, BI, Inventory
Weather Map
Business
Intelligence
Network
Inventory
Service, Network,
and Analytics
REST APIs
.........
Multivendor Network Devices
Optimization and Prediction
DeployerCollector
New ModelCurrent Model
CalendaringAnalytics
NMS/EMSNetFlowCLI$SNMP BGP-LS EMS/NMSNETCONF/YANG PCEP
Multi-Layer Network
Optimization
Cisco EMS / FCAPS
& Assurance
PCM / EPN Manager
Multi-Vendor Device
Configuration
Network Element Drivers
Device Manager
Service Manager
tail-f
Network-wide CLI, Web UIREST, Java, NETCONF
NETCONF, CLI, SNMP, REST, etc!
SDN WAN Solution Vision
CRSASR 9000NCS2000 NCS4000 NCS6000
Multi-Vendor Support for:
• Juniper
• ALU IP
• Huawei IP
• Ciena Optical
• Infinera Optical
MV IP & Optical Network Collection MV Network Device Configuration Nwk Mgmt for Cisco EPN
and

WAN SDN Use Case: Coordinated Maintenance
Optimal and Automated Network maintenance of routers, jointly with optical (SRLG info).
ü Reduce operational overhead, and human error.
Cariden & SDN Platform: Analyze historical data, find the best time to remove R1 for 2
hours, and automate operation (according to customized workflow).
API
Query: What is the best time for R1 to be taken out of service for 2 hours?
Time(1) Time(n)
R1

Controller
PlaTorm
RESTful
APIs
Programming
Collec5on
WAN SDN Use-Case: TE Optimization
Problem:
A service provider needs to ensure low
latency for high priority traffic, even in
the event of a fiber cut
Solution:
PCE assigns new TE metrics based
on measured latency, thereby routing
LSPs according to lowest latent paths
① Real-time data collection
reveals latency at L3 accessible to
App (caused by fiber cut / optical
failover)
② App requests TE Metric change on L3
circuits routed over L1 link
③ PCE computes new TE metric that will
decrease latency of traffic
④ PCE programs TE metric change
using PCEP, causing LSPs to reroute
1
2
R1 R2
3
Ra Rb
Rc
O1 O2
High latency!
PCEP
WAN
LSP
4
Latency
Reducer
App
39

Controller
PlaTorm
RESTful
APIs
Programming
Collec5on
WAN SDN Use-Case: Multilayer Transport Optimization
Problem: Provider wants to take
advantage of lowest cost path, which
may involve direct optical path
bypassing routers.
Solution: Controller determines when
a bypass route is the best choice, and
provisions new topology.
① Realtime data collection
reveals trending congestion
(Rc-Rb link) imminent
② App requests Multi-layer
optimization
③ PCE programs Ra and Rb to initiate
Setup
④ New Ra-Rb link is injected into IP/
MPLS Topology
1
2
R1 R2
3
Ra
Rb
Rc
O1
Congested!!
PCEP
GMPLS UNI
4
WAN
40 O2

Programmable WAN Evolution
Innovations in Technology and Network Architecture

WAN Control-plane Innovations
42
Connectionless
best-effort
MPLS TE
QoS
FRR
Capacity
Planning
Services-aware
Networks
OAM &
PerfMon
The new Internet (2009 --)
The textbook Internet (1995-2007)
Early Internet TodayIPNGN (2000 – 2010)
WANTraffic
CCD
ROADM
50-200G
WDM
Super-
channel
Network-aware
Applications

65
A packet injected anywhere
with top label 65 will reach Z
Nodal segment: Operator allocates a label from the SR registry to
each node. For example Z is given label 65
9001
Adjacency segment: Node automatically allocates a local label for
each adjacency. For example Label 9001 allocated for adjacency O
A packet injected at node C
with label 9001 is forced
through datalink CO
Forwarding state (segment) is established by IGP
Ø LDP and RSVP-TE are not required
MPLS Dataplane is leveraged without any modification
push, swap and pop: all what we need segment = label
A B C
M N O
Z
D
P
A B C D
Z
M N O P
Segment Routing – Basic principles overview
For more details ciscolive sessions specific on SR
43
• A node holds a state per global segment O(3), & a state per local segment it
originates O(2)
• For a flow F, only its ingress node N holds a per-flow state for F. Any other node does
not hold any state for F. While they can be millions of flows crossing a midpoint, its SR
FIB scale is only O(3).

SR with WAN Orchestration
• WAN O allows for the best possible simplification of SR
– Optimum state computation
– A single touch-point at the Source Node
– Instant set-up time
• Also a stateful PCE, as with MPLS-TE, can be help to:
– Compute globally optimum paths for traffic-engineered SR tunnels
– Instantiate SR tunnels based on requests from applications
– Instantiate traffic steering onto the instantiated tunnel
• Minimal changes
– PCEP capability to negotiate SR between PCE and PCC
– IGP capability used by PCE’s to advertise their SR/PCE capability
– Extension to BGP-LS to convey the segments
– Extension to IR2S policy retrieval to include segment information
– Minimal changes in (Cisco) CLI and look and feel stays same
B
Ask for path to G
with certain SLA
(delay, bandwidth,
duration, etc)
SDN WAN O
Indentify best
path and
segments (B, D,
C, E, G)
A
D
C
F
E
G

SR + PCE value - A real Customer Example!
Reference: MPLS World Congress paper D2-13 C. Filsfils et al.
45
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

SDN Transport: An important, industry-wide innovation.
Ø Febr. 2014 OIF Workshop - "Transport SDN - Cutting
Through the Hype“ http://www.oiforum.com/public/OIF_NW_Workshop2014_reg.html
“As SDN moves along the curve from curiosity to hype to reality, Carriers and their
vendors need to be able to cut through the hype and identify what is needed to make
Transport SDN a desirable and deployable technology. The workshop will present
views across the industry of what the enabling technologies and standards will be,
including practical use cases and applications for Transport SDN”.
Ø Jan. 2015 OIF plenary – Paraschis oif2015.083
ü SDN important advancement.
ü open, agile, network automation, optimization, and orchestration.
ü SDN WAN main novelty is the evolution of IP/MPLS to include centralized control.
ü Optical central control (NMS) has always existed. So, SDN not radically new.
ü SDN transport valuable in the optimization of converged packet-optical architectures,
especially with the new generation of fully flexible DWDM; e.g. multi-layer restoration.
Hybrid Control Plane Architecture
Application
Distributed Control Plane
Data Plane
Centralized Control Plane
APIs

Legacy IP-DWDM Inefficiencies – OpEx Challenge
§ Too little information sharing
§ Too limited interaction between
layersStatic DWDM layer
Agile IP layer

100G Routing
CapEx < 25%
100G TCO lower
than 40G, and 10G.
Photonics > 60% of CapEx
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
Graph source: cisco, 2011
IEEE OFC Market Watch 3
48

Colorless – ROADM ports are not frequency
specific (re-tuned laser does not require fiber
move)
Omni-Directional – ROADM ports are not
direction specific (re-route does not require fiber
move)
Contention-less - Same frequency can be added/
dropped from multiple ports on same device.
Flex Spectrum – Ability to provision the
amount of spectrum allocated to wavelength(s)
allowing for 400G and 1T channels.
Complete Control in Software, No Physical Intervention Required
Foundation for Multi-Layer Network Programmability
Tunable Transponder – Color and
modulation. Ability to derive max b/w based on
distance and fibre quality
The new fully flexible Optical Transport layer
49

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
Ø The IP/MPLS evolution to SDN is an important innovation!
Ø Optical control, always mainly centrally controlled (NMS)!
SDN
Controller
(WAN O)

Example of the value of Multilayer Optimization
51
Reference: IEEE Comm. Mag., Jan. 2014 O. Gerstel et. al.
L0
L3

Multi-Layer Restoration - basic use-cases
+
180G
260G
+
180G180G
+
70G
130G
180G
§ 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), this spare capacity could (partially)
be saved.
MLR-O
MLR-P
MLR-AIP-only
No MLR

Multilayer Optimization vs Single-layer Optimization
Reference: IEEE OFC 2015 M. Khaddam (Thursday 8 am, invited)
SDN
Controller
EMS
Applications
(Multi-layer, SPRING, etc)
WDM
Client

Multi-Layer Restoration efficiencies
R1 R2
Premium: 30G
BE: 90G
3 x 100G Worst-case stable:
120G on 200G
Avg IP util: 120/300= 40%
R1 R2
Premium: 30G
BE: 90G
2 x 100G
Worst-case transient:
120G on 100G. BE loss
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)

Cisco Confidential© 2010 Cisco and/or its affiliates. All rights reserved. 55
Next Gen WDM - “Super-Channel” Flex-Rate
Optimize trade-off of Spectral-efficiency vs Distance to minimize OEO Regens
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
baud rate line bit rate payload bit rate

Example: G. Bosco et al, “On the Performance of Nyquist-WDM Terabit Super-channels…”, J. of Lightwave Technology, Vol 29, No. 1, 2011.
Next Gen WDM – Moore’s Law at Shannon Limit
DSP, Coherent, super-channel 50Gb/s-1Tb/s, silicon-photonics
Different channel
spacing, 𝐵𝐸𝑅
≤4×​10↑−3 ,
for SSMF (solid line) and
NZDSF (dashed line)

L1
L3
Multi-Layer Planning Tool Extensions
Ø 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.
Ø Automated “L1- Collector-license” with 6.1, YANG-model
based, and supported by CTC 10.x.

SDN Advanced Traffic Management
• Centrally optimized actions before, during
and after service provision to ensure
network supports services within the
bounds of SLAs
• Functions:
– Demand calendaring – ensuring future
capacity is available for scheduled services
– Demand Admission and placement – verifying
there are sufficient resources to place a
demand
– Network Optimisation – moving demands to
make more efficient use of resources
– Capacity planning – how much capacity you
need in future to continue to meet the
committed SLAs?
Traffic Management
Capacity Planning
Demand Admission
and Placement
Network Optimization
Demand Calendaring
Next month
Next week
Offline
Real-time
Now

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).
135% 130% 130%
100%
0%
20%
40%
60%
80%
100%
120%
140%
160%
180%
Random WRR Lowest
latency Demand
eng
Avg.
Network
Worst-­‐Case
Utilisation
59

Example of Network Aware Service Placement
Based on MATE Design Planning Tool
• Process:
1. Receive demand request(s).
In this case a request per
candidate DC.
2. Add corresponding new
demand(s) to network
3. Simulate for worst-case
4. Respond with WC util
• NYC exceeds acceptable WC
util and WC delay thresholds
• SJC exceeds acceptable WC
delay threshold
• CHI and KCY are able to
support the requested
demands
• KCY is preferred because the
worst-case utilisation is lower
than for CHI
DC: CHI
WC delay: 22.0ms
WC path util: 91.4%
WC net util: 91.4%
DC: NYC
WC delay: 29.5ms
WC path util: 101.8%
WC net util: 101.8%
DC: SJC
WC delay: 33.0ms
WC path util: 90.8%
WC net util: 90.8%
DC: KCY
WC delay: 22.2ms
WC path util: 90.8%
WC net util: 90.8%

DC WAN connectivity in the Cloud-era - More than DCI
“DCI” with varying requirements:
• Multiple 100G needs
• Higher Density Interconnect in metro
• Inter-DC architecture extend beyond
metroSP DC1 SP DC2
Ent DC1 Ent DC2
SP NGN
DCPE
DCPE
DCE
DCE
PE PE
CE CE
§ Enterprise Data Center inter-connect
§ Enterprise Data Center to Provider Data
Center
§ Provider Data Center to Provider Data
Center

Cloud
Data Center
Cloud
Data Center
Workload
increase
SP VPN
Cloud
Data Center
Request
resources
Workload
Deployed
Additional capacity needed –
request cloud resources
1
Check resource availability,
performance – determine
optimal location
2
Provision network tenant,
virtual compute, storage, VPN,
services
3
Virtual infrastructure and
network container active
4
1
2
3
4
WAN Orchestration: Network Aware Service Placement
62
Internal
Data Center

SDN-enabled Optimized Network Consumption Model
Low
High
Today’s mode
on the router
Virtual, or
Hybrid
Expansion
Core / Transport
Peering
DCI
PE
Subscriber Services
Virtual PE (vPE)
Virtual RR (vRR)
Align DP
to use-case
Choose CP
per use-case:
Low
High
Single-chassis
High-end System
Single-chassis
Low-end System
Virtual Routing
Multi-chassis
1. Services Catalog 3. Data Plane2. Control Plane

Conclusions

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
65

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

SDN WAN Innovations - Summary
(OIF2015.083 Plenary January 2015)
Ø 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:
ü unified controller (ODL) and applications framework, advanced automation and optimization
ü software and APIs innovation in network programmability
ü full spectrum of hardware sophistication useful; “white” boxes not the main value in SDN WAN.
ü Standards mainly IETF, notably NETCONF/YANG, SPRING, BGP-LS, and PCEP. Carrier driven industry definition e.g.
Open-Config, ONF, OIF. YANG data models vision!
Ø Incremental, phased adoption possible
ü Routing important evolution allowing to centralized (global, state-full) control automation & optimization.
ü Optical control always central mainly; 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.

References for Further Reading
Segment Routing:
• IETF SR group; key document https://tools.ietf.org/id/draft-filsfils-spring-segment-routing-use-cases-00.txt
• MPLS World Congress 2014 presentations:
– Day-2_12 on Segment Routing by George Swallow
– Day-2_13 on Segment Routing by Clarence Filsfils
– Day-3_08 on Demand Engineering by John Evans
Multilayer Optimization:
• OIF effort starting on SDN Transport http://www.oiforum.com/public/OIF_NW_Workshop2014_reg.html e.g. January 2015 Plenary
presentation oif2015.083.
• IEEE OFC 2014 tutorials
– AT&T Post-Deadline-1 http://www.ofcconference.org/home/conference-program/online-technical-digest-papers/
– O. Gerstel: http://www.ofcconference.org/home/conference-program/short-courses/next-generation-transport-networks-the-evolution-f/
– L. Paraschis: http://www.ofcconference.org/home/conference-program/short-courses/new!-the-evolution-of-network-architecture-towards/
• “Advancements in Metro Regional and Core Transport Network Architectures for the Next-Generation Internet”, L. Paraschis,
Chapter 18 (pp. 793–817) in Optical Fiber Telecommunications VI B, Systems and Networks, ELSEVIER, May 2013. ISBN
978-0123969606.
68

§ Give us your feedback and you could win
a Plantronics headset. Complete the
session survey on your Cisco Connect
Toronto Mobile app at the end of your
session for a chance to win
§ Winners will be announced and posted at
the Information desk and on Twitter at the
end of the day (You must be present to win!)
Complete your session evaluation – May 14th

#CiscoSpark
Let’s continue this
conversation on…
Spark
Cisco’s mobile collaboration
team application
Visit the Collaboration booth in the
World of Solutions to join the
Connect Spark room

Top SDN Use Cases – Heavy Reading analysis 2014
72

Tier
1
SP
MPLS
Fabric
Cisco
Proposal
Cisco Confidential 19© 2013-2014 Cisco and/or its affiliates. All rights reserved.
CO CO
CO
CO CO
Metro Wide Ethernet Fabric
Metro 2 Metro 3
ASE
Domain 1.0
CBB
CO
CO CO
Spine
Leaf
Leaf Leaf
Spine
Border-Leaf Border-Leaf
Leaf
Leaf
Leaf
Leaf Leaf
Uverse
CO
AT&T Metro Architecture – Cisco Proposed (Logical) Topology
Metro 1 Domain 1.0
Domain 1.0
Centralized Control
NFVs
NFVs NFVs
NFVs
NFVs NFVsNetconf/YANG
BGP
Netconf/YANG
BGP ROADMf ROADMf
Skywarp
Skywarp
Fre9a
• Working
with
ESC/Tail-­‐F
VPE
• Provides
network
(VLAN)
connec8vity:
–
Between
customer
sites
and
D2.0
virtualized
PEs
–
Between
D2.0
virtualized
PEs
and
Metro
core
• Fabric
operates
as:
–
Phase
1:
Single
Ethernet
switch
(L2)
–
Future:
Single
MPLS
LSR
(L3)
Sunstone
• Leafs
connect
to
compute
servers
and,
op8onally,
customer
sites
Operate
as
MPLS
LERs
(L2VPN)
• Border
Leafs
connect
to
core
routers
and,
op8onally,
customer
sites
Operate
as
MPLS
LERs
(L2VPN)
• Spines
provide
connec8vity
between
Local