software innovations and control plane evolution in the new sdn transport architectures
TRANSCRIPT
Software Innovations and Control Plane Evolution in the new SDN Transport Architectures Loukas Paraschis, Technology Solution Architect, Cisco [email protected]
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
9
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. 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 )
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 Link
Util
izat
ion
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
Traf
fic c
hang
e fre
quen
cy
annual
monthly
daily
hourly
Max Link Utililization
25% 50% 75% 100%
Planning (offline)
SDN WAN (online)
33
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
Deployer Collector
New Model Current Model
Calendaring Analytics
NMS/EMS NetFlow CLI SNMP BGP-LS EMS/NMS NETCONF/YANG PCEP
Unified Application Framework & ODL Integration
WAN Automation Engine
Cisco Open SDN Controller
Unified Application Framework
Bandwidth Calendaring
Bandwidth on Demand
Inventory Coordinated Maintenance Offline 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
Deployer Collector
New Model Current Model
Calendaring Analytics
NMS/EMS NetFlow CLI$SNMP BGP-LS EMS/NMS NETCONF/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 UI REST, Java, NETCONF
NETCONF, CLI, SNMP, REST, etc!
SDN WAN Solution Vision
CRS ASR 9000 NCS2000 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 Today IPNGN (2000 – 2010)
WA
N T
raffi
c
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
1 0
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
layers
Static 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
52
+
180G
260G
+
180G 180G
+
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-A IP-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%
60
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
metro SP 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 Plane 2. 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 NFVs Netconf/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
