Software Innovations and Control Plane Evolution in the new SDN Transport Architectures

Software Innovations and Control Plane Evolution in the new SDN Transport Architectures BRKOPT-2102

Loukas Paraschis, Technology Solution Architect, Cisco [email protected]

© 2015 Cisco and/or its affiliates. All rights reserved. BRKOPT-2102 Cisco Public

Abstract – ciscolive BRKOPT-2102

3

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.


Agenda

•  Introduction

•  SDN evolution of WAN

•  WAN SDN Automation

•  WAN SDN Optimization

•  Programmable WAN Architecture Evolution

•  Conclusions

4


Acknowledgement of Many 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 – Executive Summary

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


•  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


Infrastructure n/w controller

Control Applications

Network SDN Controller



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” APIs to NE Protocols …

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

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)

30


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

31


Offline Collection

WAN Optimization building on the Cariden Portfolio A Common Platform For Architecture, Engineering and Operations

32

Archive Web Application

Web Application

Plan Archives

Time Series Data-store

Time-Series Datastore Plan file Archives

Desktop Application MATE Design MATE Live

MATE Collector Online Collection

Predictive Model MAP EXPLORE/ ANALYTICS

Mul8vendor Network Devices

ALU Juniper Cisco Huawei External Systems

Flow Collec8on

Automatically discover and continuously maintain network data

Design, engineer and plan IP/MPLS networks

Operational Infrastructure Analytics – interactively visualize, navigate and report on near real time and historical data

SNMP and CLI

SOAP XML SAM

Flow Data

API

Sta8s8cs Router Configs

33 © 2014 Cisco and/or its affiliates. All rights reserved. Cisco Confidential

Weather Map Trending Network Inventory

WAN Automation Engine

Network Plan

WAN Automation Engine

Planning & Design Failure Analysis

WAE Applications

REST APIs

......... Multivendor Network Devices

Optimization and Prediction

Deployer Collector

New Model Current Model

Calendaring Analytics

NMS/EMS NetFlow CLI SNMP BGP-LS

Collec8on Drivers

EMS/NMS NCS PCEP (ODL) ...


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 PlaVorm 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

35




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

36

O2




WAN SDN Use-Case: Demand Admission

Problem: Provider’s customer has an “on demand” need for a DC backup or to move a cache

Result: After determining a best path, PCE programs an LSP via PCEP.

①  Network conditions reported to collector

②  Customer requests DC #1 – DC #2 bandwidth ASAP

③  Demand admission request: <R1-R3, B/W, NOW>

④  PCE returns option and customer confirms

⑤  If needed (insufficient bandwidth), R1-R3 LSP tunnel programmed via PCEP

WAN

R1

R2

R3 Data Center #1 Data Center #2 5

1

2 3

4

PCEP

Congested!!

37

Programmable WAN Evolution Innovations in Technology and Network Architecture


IP/MPLS Control-plane Innovations

39

Connectionless best-effort

MPLS TE QoS

FRR, FC

Capacity Planning

Services OAM & PerfMon

The new Internet (2009 --)

The textbook Internet (1995-2007)

Early Internet Today - EPN IPNGN (2000 – 2010)

IP T

raffi

c


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

40

•  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.

42

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


•  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

45


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

46


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

48

Reference: IEEE Comm. Mag., Jan. 2014 O. Gerstel et. al.

L0

L3

© 2015 Cisco and/or its affiliates. All rights reserved. BRKOPT-2102 Cisco Public 49

+

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)

© 2015 Cisco and/or its affiliates. All rights reserved. BRKOPT-2102 Cisco Public Cisco Confidential © 2010 Cisco and/or its affiliates. All rights reserved. 52

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


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

55


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%

56


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

58

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

61


Agenda

•  Introduction

•  SDN evolution of WAN

•  WAN SDN Automation

•  WAN SDN Optimization

•  Programmable WAN Architecture Evolution

•  Conclusions

62


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.

64


SDN automation & optimization adoption… can start today!

“Don’t bother me with new ideas; I’ve got a battle to fight!”


Complete Your Online Session Evaluation

•  Please complete your online session evaluations after each session. Complete 4 session evaluations & the Overall Conference Evaluation (available from Thursday) to receive your Cisco Live T-shirt.

•  All surveys can be completed via the Cisco Live Mobile App or the Communication Stations

66


Top SDN Use Cases – Heavy Reading analysis 2014

68

Software Innovations and Control Plane Evolution in the new SDN Transport Architectures

Documents

Transcript of Software Innovations and Control Plane Evolution in the new SDN Transport Architectures