SDN-Enabled Carrier Ethernet Architectures

Istvan Kakonyi – Vertical Solutions Architect

Alexander Preusche – Consulting Systems Engineer

• Industry Trends and Business Drivers

• Cisco EPN Evolution

• Application Engineered Routing

• SDN-Enabled Carrier Ethernet

• High-Level Architecture

• Service Orchestration

• Service Models

• Demo

• Conclusion

Agenda

3

Industry Trends and Business Drivers

4

Evolving SDN:

tackling strategic,

technology, and

operational

challenges

NETWORKWORLDSDN revolution or evolution: Impact on the IT manager

Google revamps networks with OpenFlow

We share a more pragmatic view, noting Cisco (for example)

is likely to view SDN as a TAM expansion opportunity…

Deutsche Bank Research Note

“Jeda Networks

proposes yet another

software-defined

option for the data

center”

SDN

What is Software-Defined Networking We already have left this behind us…..

5

Realities

Static or Reduced

Budget

OTT competition

Network Growth

b/w, footprint, users

Technical and

Business disruptors

Operational

Simplicity

Goals

¥£€$ Cost Reduction

Incremental revenue

generation

Service Agility

Service Provider Challenges

6

SDN Deployment Drivers – Infonetics Research 2015

7

Cisco EPN Evolution

8

Cisco Evolved Programmable Network

Evolved Programmable Network

Video

Business

Cloud

Mobility

NCS NCS

APIs

APIs

EDGECORE

Access

VM VM

Edge

Core

VM

Agility

Optimize

Revenue ¥£€$

Always “ON”

On-DemandServices

AnywhereDynamic Scale

ApplicationInteraction

SeamlessExperience

Policy

Real-Time Analytics

Fully Virtualized

IntelligentConvergence

Automated

Open and Programmable

Access

Evolved Services Platform

Service Broker “Business Intents”Applications and Services

CDN

VM

VM / Storage Control

Service CatalogService Orchestration Apps

9

Application

Distributed Control Plane

Data Plane

Centralized Control Plane

APIs

Traditional Control Plane

Architecture

(Distributed)

SDN Control Plane Architecture

(Centralized)

Hybrid Control Plane Architecture

SDN strategy around the Hybrid Control Plane

• Both traditional and SDN CPs have benefits AND drawback

• CP solutions most be considered on a use case basis

• Many use cases are moving to an Hybrid CP approach

10

The Importance of Orchestration

Data Plane

Control Plane

Config Plane

Device centric

view

Orchestration

SDN Controller

Network-wide view

Network-wide orchestration replaces the individual device config. This allows network wide service definition and deployment

The SDN controller behaves like a centralized control plane for network wide policy & control. Examples of network wide policies include bandwidth calendaring, bandwidth scheduling & multi-layer traffic optimization.

However, the SDN controller does not replace the individual router control plane. For efficient route distribution and rapid convergence, we still need a distributed routing protocol that is best implemented in the individual router. Cisco refers to this as the Hybrid Control Plane model

11

SDN Orchestration and ControllerTail-f/NSO & Opendaylight & XRv

NSO

Network Orchestration System

XRv

XRv / PCEP

Visualization &

Analytics

Wave Automation Engine (WAE)

Collector &

Modelling

Bandwidth

Orchestration

Programming

onePK PCEP IRS OF

MATE

Design/Li

ve

Band-

width

Services

Tunnel

Manage

r

DC-WAN

Orchestra

tion

Java/REST/Thrift APIs

Apps

3rd Party

WAE

12

Aggregation AggregationCore

GW1

GW1

GW2

GW2

Large Scale Network – Unified MPLS (RFC 3107)

IGP/LDP island IGP/LDP island

VPN label

LDP label

End-to-End VPN Service

P1 P2

• Divide network into small isolated IGP/LDP domains. LDP label is used to reach BGP-LU next-hop

• End-to-End BGP-LU to advertise node’s prefix across IGP domains. BGP can scale to millions

• Low end node have limited RIB/FIB size. It can use BGP policy to filter BGP prefixes as needed

• Service is between end nodes, no service stitching required simple and optimized

• Network fast convergence by IP-FRR or TE-FRR, and BGP-PIC

IGP/LDP island

BGP Label UnicastBGP-LU label

Service

label

Transport

label

CE1 CE1

13

Aggregation AggregationCoreCE1

GW1

GW1

GW2

GW2

Segment Routing for Transport

SR island SR island

VPN label

SR Label

End-to-End VPN Service

P1 P2

• Use of Segment Routing with IGP Extensions ( Aggregation and Core )

• Simplified Protocol Stack, no LDP needed

• Low end node have limited RIB/FIB size.

• Network fast convergence by TI-LFA and BGP-PIC

• Traffic Engineering via Segment Routing

SR island

BGP Label UnicastBGP-LU label

Service

label

Transport

label

CE1

14

Aggregation AggregationCoreCE1

GW1

GW1

GW2

GW2

Fully Automated, SDN-aware Service Provisioning

SR island SR island

VPN label

SR Label 1

P1 P2

• Use of Segment Routing with IGP Extensions ( Aggregation and Core ) , Services

provisioned via SR mechanics

• Simplified Protocol Stack, no LDP needed

• Low end node have limited RIB/FIB size.

• Network fast convergence by TI-LFA and BGP-PIC

• Traffic Engineering via Segment Routing

SR island

SR Label 2

Service

label

Transport

label

CE1

SDN Controller

Orchestration

SR Label n

15

Application Engineered Routing

16

Application Engineered Routing

Applications express

requirements –

bandwidth, latency, SLAs

SDN controllers are capable of

collecting data from the network –

topology, link states, link

utilization, …

Applications are mapped to a path

defined by a list of segments

The network only maintains segments

No application state

Segment

Routing

(SW upgrade)

SDN

Controller

Applications

1

2

3

17

• Simplicity

• Less numbers of protocols to operate & troubleshoot

• Less numbers of protocol interactions to deal with

• Deliver automated FRR for any topology

• Scale

• Avoid thousands of labels in LDP database

• Avoid thousands of MPLS Traffic Engineering LSP’s in the network

• Avoid thousands of tunnels to configure

• Leverage all services supported over MPLS today (L3/L2 VPN, TE, IPv6)

• Requires evolution and not revolution

• Incremental deployment

• Bring the network closer to the applications

Operators Desire from the Network

18

• Source Routing: the source chooses a path and encodes it in the packet header as an ordered list of segments

• Segment: an identifier for any type of instruction

• Service

• Context

• Locator

• IGP-based forwarding construct

• BGP-based forwarding construct

• Local value or Global Index

Segment Routing

Segment = Instructions such as

"go to node N using the shortest path"

19

• MPLS: an ordered list of segments is represented as a stack of labels

• SR re-uses MPLS data plane without any change

• IPv6: an ordered list of segments is represented as a routing extension header, see 4.4 of RFC2460

• IGP-based segments require minor extension to the existing link-state routing protocols (OSPF and IS-IS).

Segment Routing

The remainder of this presentation focuses on SR on MPLS data plane

20

Segment Routing - Overview

Path expressed in the packet Data

Dynamic path

Explicit path

Paths options

Dynamic

(SPT computation)

Explicit

(expressed in the packet)

Control Plane

Routing protocols with

extensions

(IS-IS,OSPF, BGP)

SDN controller

( BGP , PCEP,

NETCONF/YANG)

Data Plane

MPLS

(segment labels)

IPv6

(+ SR extension header)

21

65

A packet injected anywhere

with top label 65 will reach Z

Node/Prefix Segment: label allocated

from the SR registry to each node.

Globally significant. For example Z is given

label 65. 9001

Adjacency Segment: Node automatically

allocates a local label for each adjacency.

Locally significant. For example Label

9001 allocated for adjacency O. A packet injected at node C

with label 9001 is forced

through datalink CO

A B C

M N O

Z

D

P

A B C D

Z

M N O P

Segment Routing Basic Operation and Segment Types

Source Routing: The source chooses a

path and encodes it in the packet header

as an ordered list of segments.

Segment: An identifier for any type of

instruction i.e. "go to node C using the

shortest path"

Segment Routing Introduction

22

Explicit Path Routing

• Any explicit path can be expressed i.e. ABCOPZ

A B C

M N O

Z

D

P

9001

Packet to Z

65

9001

Packet to Z

65

Packet to Z

65

Packet to Z

65

9001

72

Packet to Z

65

9001

72

7272

65

65

nt Routing Segment Routing Label usage

A B C D

Z

M N O P

Available today (XR 5.2.2)

Packet to Z

23

Nodal segment to C

Nodal segment to Z

A B C

M N O

Z

D

P

Adj Segment

Nodal segment to C

Less

protocols

more

scalabilityEvolution not Revolution!

• Leverages MPLS data plane and simplifies MPLS control plane

• Extends IGP protocols to carry labels – no need for LDP/RSVP-TE

Source Routing: the source chooses a path and encodes it in the packet

The states are in the packet not in the network

Excellent Scale: a node installs N+A FIB entries

Segment Routing – Technical Details

24

• 100%-coverage 50-msec link and node protection

• Simple to operate and understand

automatically computed by the IGP

• Prevents transient congestion and suboptimal routing

• Incremental deployment applicable to IP

and LDP traffic

Topology Independent LFA (TI-LFA)

25

TI-LFA - Optimality Benefit Example

• Protecting destination Node5 on Node2 against failure of link 2-3

• Classic LFA: Node2 switches all traffic destined to Node5 towards the edge node PE4

Low BW (high metric) links and an edge node are used to protect the failure of a core link

A common planning rule is to avoid Edge nodes for transit traffic

Classic LFA does not respect this rule

• TI-LFA: Node2 switches all traffic destined to Node5 via high BW core links: OK!

✗

✓

100100

PE4 5

2 31

6 7 8

Initial

Classic LFA FRR

TI-LFA FRR

Source

Dest1

Dest2Default metric: 10

Post-convergence

26

Simple Node Redundancy

Multiple nodes advertise the same Segment Identifier (anycast segment) in addition to their SID

Traffic is forwarded to the closest node based on IGP best path A C

B O

Z

SN1

SN2

Packet sent

to SN1 or SN2

100

SN2 : SID 102

SN1 or SN2:

Anycast SID 100

SN1: SID 101

If primary node fails traffic is auto re-routed to another node with the same anycast segment

Very simple node redundancy mechanism at transport layer

Same concept applicable to Pseudowire at the service layer

No need for complex features

Failure

27

Optimize Infrastructure with SDN/WAE ControllerPath AZ expressed as

{66, 68, 65} A B C

M N O

Z

D

P

FULL66

68

65

WAN Automation Engine (WAE) monitors and re-optimizes the infrastructure according to Service Provider business rules (bandwidth, link cost, delay)

WAE modifies network paths by pushing label stack/SR-TE tunnels to source node only

PCEP is used to program SR Traffic Engineering Tunnels at the source nodes

BGP-LS is used collect network topology information from the network

PCEP

BGP-LS

28

Segment Routing: IGP only, no need for LDP; IGP shortest path as baseline

Any node to any node transport connectivity: SR Node label

Service Node redundancy: anycast SR label

Link or node protection with Topology Independent Loop Free Alternate (TI-LFA):

50 ms Fast Reroute in any topology

Segment Routing for Carrier Ethernet

IGP/SR Domain: single area or process

No IGP and LDP

interaction, NO hierarchy

BGP and LDP LSP

Leverages ECMP

50 msec auto TI-LFA

14

5

6

7

DC

Core

Service NodesAnycast label

1001

2

3

101

102SR Node label: 1

Node 1 Service Node 101 or 102: {1001}Service Node Node 1: {1}

Node 1 Node 5: {5}Node 5 Node 1: {1}

SR Node label: 5

29

Deploying Services with Segment Routing

• Traditional model: services and protocol stacks: L3VPN, VPWS/VPLS, PBB-EVPN using MP-BGP, T-LDP protocols

• Simplified service provisioning: use controller to push service labels to source nodes while SR infrastructure provides transport, service node and transport node resiliency

Traditional model

A B C

M N O

Z

D

P

MP-BGP

IPv4

VPN

T-LDP

IPv6

VPNVPLS VPWS X-EVPN

Controller Service Provisioning

CE

Minimal but “Sufficient” distributed control plane intelligence

with Centralized intelligence on the SDN controller

IPv4

VPN

SDN

IPv6

VPNVPLS VPWS X-EVPN

30

SDN-Enabled Carrier Ethernet

Architecture Evolution

31

Key Requirements of the Carrier Ethernet Network

• Large Scale

• Operational Simplicity

• Optimized and Application-aware Service Delivery

• Diverse Topologies

• High Availability

Aggregation

TDMTDMTDMTDMTDMTDMTDMTDM

TDMTDMTDMTDM TDMTDMTDMTDM

PE

TDMTDMTDMTDMTDMTDMTDMTDM

TDMTDMTDMTDM

Pre-

Aggregation

32

A

GW

GWA

A A

A

Payload C-tag S-tag

S-VLANs on all core interfaces

C-VLANs on edge

C-VLANs on edge

• Encapsulation: qinq (or MacinMac)

• Control protocol: STP/G.8032 for S-VLANs. [topology restrictions]

• No additional control protocol required for C-VLANs

• Packet forwarding: per-VLAN based load balancing, not efficient. BUM

• IPless: doesn’t require IP address (except management)

• Encapsulation: Flexible label stacking

• Control protocol: ospf/isis + LDP (BGP optionally) for transport label

• Control protocol: BGP/T-LDP for VPN service label

• Packet forwarding: ECMP, optimized

• IP address management

The Network Complexity Discussion: L2 vs. L3

VPN on edge

A

GW

GWA

A A

A

PayloadVPN

labelTransport

label

IP/MPLS on all core interfaces

VPN on edge

Classic IP/MPLS forwarding

L2 forwarding

33

Leading Carrier Ethernet Technologies

BGPT-LDP

RFC3107

BGP

RSVP-TE

LDPIGP

AccessAggregation

Unified MPLS Model

Flexible and scalable

Multi-Service Architecture

Unified operation across domains

Optimized forwarding

Complex to operate and manage

AccessAggregation

L2 Brdidging Model

REP, G.8032, STP

802.1q/.1ad/.1ah

Simple, plug & play

It only supports Ethernet services

Not scalable

No A/A load balancing

BUM

Complex across L2/L3 domains

…

AccessAggregation

SDN

SDN + OpenFlow Model

Simple network layer

Complex controller layer

Not mature for large scale SP

Service SLA?

34

Our Vision: Agile Carrier Ethernet

BGP

T-LDP

RFC3107

BGP

RSVP-TE

LDP

IGP

AccessAggregation

SDN

OF

Access Aggregation

Fully Distributed Control PlaneUnified MPLS

Fully Centralized CP and DP OpenFlow

Balance

?

35

A

GW

GWA

A A

A

PayloadVPN

labelTransport

label

IP unnumbered on all core interfaces

Auto VPN label

Auto VPN label

Our Proposal: a Simple L3 IP/MPLS Solution

SDN-enabled MPLS forwarding

• Encapsulation: Flexible label stacking

• Control protocol: ospf/isis + LDP (BGP optionally) for transport label

• Control protocol: BGP/T-LDP for VPN service label

• Packet forwarding: ECMP, optimized

• IP address managementIP unnumbered interface. Only need IP address for management and loopback

NO control protocol for VPN service label. Controller provision the label automatically

Single IGP SR for the transport. Controller provision the inter-domain label

36

Application Engineered

Routing

SimplificationAPP Interaction

SDN Orchestration

Consolidated

VPN Services

AutomationProgrammability

FlexibilitySecurity

Agile Carrier Ethernet (ACE) Architecture

37

Our Vision: Agile Carrier Ethernet

Access Aggregation

Orchestrator

Controller

Service Orchestration

Segment Routing

Transport

Autodiscovery

• Minimal, but sufficientControl Plane on NetworkElements, with CentralizedSDN-aware ServiceOrchestration

38

Core

Metro area 1Single IGP SR domain

A

GW

GWA

A

IP unnumbered

interfaces

A

A

Metro area 2Single IGP SR domain

GW

GW

A

A

A

Controller

CE

ACE Architecture: High-Level View

CE

Centra

lized

Serv

ice

IP unnumbered

interfaces

Dis

tribute

d

Tra

nspo

rt

39

SDN-Enabled Carrier Ethernet

Transport Architecture

40

Metro area

ACE Architecture: Plug-n-Play Node InsertionBaseline requirement: Plug-n-Play node insertion

• New node can be pre-configured: loopback address, isis, SR, etc

• Require IP unnumbered interface feature, so doesn’t require re-configure the link ip address

on the existing nodes

Advanced requirement: zero-touch provisioning

• Require auto-discovery

Auto-discovery and initial auto-

configuration options

• Autonomic Networking (some work to

be done to cover all products )

• Standardize the satellite auto

discovery

Core

A

GW

GW

NCS

(Orchestrator)

A

AIP unnumbered

interface

41

• Simple to configure

• Simple to operate

ACE Architecture: SR Base Configuration

RP/0/0/CPU0:xrvr-1#sh run router isis

router isis 1

is-type level-2-only

net 49.0000.1720.1625.5001.00

address-family ipv4 unicast

metric-style wide

segment-routing mpls

!

interface Loopback0

passive

address-family ipv4 unicast

prefix-sid absolute 16001

!

!

RP/0/0/CPU0:xrvr-13#sh cef 1.1.1.1/32

1.1.1.1/32, version 5093, internal 0x1000001 0x1

(ptr 0xa1375ff4) [1], 0x0 (0xa135acf8), 0xa28

(0xa14f0320)

Updated Mar 12 12:42:43.541

local adjacency 99.11.13.11

Prefix Len 32, traffic index 0, precedence n/a,

priority 1

via 99.11.13.11, GigabitEthernet0/0/0/1, 13

dependencies, weight 0, class 0 [flags 0x0]

path-idx 0 NHID 0x0 [0xa1068314 0x0]

next hop 99.11.13.11

local adjacency

local label 16001 labels imposed

{16001}

Label 16001

imposed for

loopback 0 of R1

Configure IPv4

Prefix-SID value

for loopback0

Enable SR on all

IPv4 interfaces in

this IS-IS

instance

42

CoreMetro1 Metro2

A B

GW21 1002

GW221002

GW11 1001

GW12 1001

IGP/SR metro island IGP/SR metro islandCore IGP

End-to-End LSP provisioned

by tail-f NSO

Node prefix-to-SID mapping is pre-configured or auto

discovered by BGP-LS

SR label: [1001, 1002,B] SR label: [1002, 1001, A]

SDN controlled end-to-end LSP (SR segment list)

ACE Transport Architecture: Shortest path Routing

router static

address-family ipv4 unicast

20.0.0.4/32 sid-list 1001 1002 16002

SID: 16002SID: 16001

NSO

(Orchestrator)

43

CoreMetro 1 Metro 2

A B

GW21 1002

GW221002

GW11 1001

GW12 1001

IGP/SR metro

island

IGP/SR metro

island

Core IGP

SR label: [999, 1001, 1002, 888, 16002] SR label: [888, 1002, 1001, 999, 16001]

ACE Transport Architecture: Shortest path Routingwith limited redistribution of the GW node SIDs

SID: 16002SID: 16001

GW01 999

GW02 999

GW31 888

GW32888

Metro 0.1 Metro 0.2

Or: SR label: [999, 888, 16002] Or: SR label: [888, 999, 16001]

Controller

NSO

(Orchestrator)

44

CoreMetro1 Metro2

A B

GW21 1002

GW22 1002

GW11 1001

GW12 1001

IGP/SR metro island IGP/SR metro islandCore IGP

Low latency

path required SR-TE biding SID:

16888 [SID list for

the SR-TE RED]

SR label: [1001, 16888,B]WAE

WAE calculate the path and provide the

information to tail-f or EPN manager

ACE Transport Architecture: Application-engineered Routing

SDN controlled end-to-end LSP (SR segment list)

SR-TE

SR binding SID provide an enhanced inter-

domain TE without require deep label stack

support on the access nodes

BGP-LS

NSO

(Orchestrator)

45

CoreMetro1 Metro2

A B

GW21 1002

GW221002

GW11 1001

GW121001

IGP/SR metro island IGP/LDP metro

island

Core IGP/LDP

End-to-End LSP provisioned

by tail-f NSO or EPN manager

SR label: [GW1:1001,B:24019]

SDN controlled

ACE Transport Architecture: Inter-operability

BGP-LU

3107: [LDP to GW2: impNull, BGP-LU to B: 24010]

RP/0/RSP0/CPU0:GW11#sh cef 20.0.0.4/32

<snip>

recursion-via-/32

next hop 100.0.0.3 via 24024/0/21

local label 24019 must be static SR label

next hop 100.0.13.3/32 Te0/0/1/0 labels imposed {ImplNull 24010}

20.0.0.4

router static

address-family ipv4 unicast

20.0.0.4/32 sid-list 1001 24019

NSO

(Orchestrator)

46

SDN-Enabled Carrier Ethernet

Service Architecture

47

CoreMetro1 Metro2

A B

GW21 1002

GW221002

GW11 1001

GW121001

IGP/SR metro island IGP/SR metro

island

Core IGP

Static PW provisioning by Tail-f NCS

or EPN manager

PW label: 24001

ACE Service Architecture (1): L2VPN P2P

A

CE1 CE2

In-band PW OAM Remote-port shutdownRemote-port shutdown

NSO

(Orchestrator)

48

CoreMetro1 Metro2

A B

GW21 1002

GW221002

GW11 1001

GW121001

Provision static PW label on both

access nodes and the GW nodes

PW label: 24001

ACE Service Architecture (2): L2VPN MP

A

CE1 CE2

EVPN Static PWStatic PW

BD

BD

BD

BD

Simple GW node redundancy solution

• Transport: anycast GW label

• EVPN: Static PW as redundant virtual Ethernet Segment

PW label: 24002

EVPNStatic PWStatic PW

NSO

(Orchestrator)

49

CoreMetro1 Metro2

A

GW21 1002

GW221002

GW11 1001

GW121001

EPN

Manager

Provision static PW label on both

access nodes and the GW nodes

PW label: 24001

ACE Service Architecture (3): L3VPN centralized

CE1 CE2

PW

HE

GW node redundancy options

• CE-PE routing, ECMP: access node use specific GW node for PWHE

• Default route: access node use anycast GW for PWHE. ARP/ND sync between

PWHE

PW label: 24002, 24003

IP-

VPN

Static

PW

Static

PWPW

HE

PW

HE

PW

HE

PW

HEPW

HEDefault route: anycast GW CE-PE routing: ECMP

B

B

NSO

(Orchestrator)

50

CoreMetro1 Metro2

A0 B0

GW21 1002

GW221002

GW11 1001

GW121001

NSOLocal prefix and

default route or

alternatively

MP-BGP

ACE Service Architecture(4): L3VPN distributed

IP-

VPN

MP-BGP VPN route

exchange

A1

Remote prefix: default

Local prefix: specific

Static VPN Route:

A0 1.1.1.2/32 VPN Label 16001, SR Label 102

A1 1.1.1.1/32 VPN Label 16001, SR Label 101

Default 0.0.0.0/0 VPN Label 16001, SR Label 1001

1.1.1.1/32

1.1.1.2/32

102

101

Remote prefix: default

L3VPN L3VPN

51

SDN-Enabled Carrier Ethernet

Controller Evolution

52

From device-centric to network-as-platform

Orchestration

Centralized service provisioning Work with existing network devices

NSO Orchestration

SDN Controller

Network as PlatformFully programmable

Device is PnP component

NSO

PCE / XRvWAE

Now

NSO: Network Service Orchestrator

WAE: Wan Automation Engine

ODL: Open Daylight

PCE: Path Computation Element

Target Architecture

53

Inter-Domain Reachability

CoreMetro1 Metro2

B

GW21 1002

GW221002

GW11 1001

GW12 1001

A

NSO PCE / XRv NSO is responsible for configuration of:

Services ( L2 and L3 VPN )

TE tunnel

PCE is responsible of:

Path computation

Separation between the

Components / functions

54

One-time configurationinterface tunnel-te and traffic steering

• SRTE Policy configuration, on NodeA:

• Traffic steering, on NodeA:

interface tunnel-te1

ipv4 unnumbered Loopback0

destination 1.1.1.22

path-option 1 dynamic pce address ipv4 1.1.1.10 segment-routing

path-selection

metric igp !! Or metric te for low latency path

PCE calculates path (PCReq/PCRepl)

use default PCE if not specified SRTE

router static

address-family ipv4 unicast

1.1.1.22/32 tunnel-te 1

CoreMetro1 Metro2

B

GW21 1002

GW221002

GW11 1001

GW12 1001

A

PCE / XRv

55

+-+-+ +-+-+

|PCC| |PCE|

+-+-+ +-+-+

| |

1) Path computation |----- PCReq message --->|

request sent to | |2) Path computation

PCE | | request received,

| | path computed

| |

|<---- PCRep message ----|3) Computed paths

4) PCC updates SRTE | | sent to the PCC

Policy | |

| |

5) Status Report |-- PCRpt, Delegate=1 -->|

sent to all | . |

stateful PCEs | . |

| . |

6) Repeat for each |-- PCRpt, Delegate=1 -->|

status change | |

| |

PCReq/PCRepl/PCRept in a nutshell

• PCC sends PC Request (PCReq), specifying all elements needed to compute path (end-points, metric, constraints)

• PCE computes path and returns ERO/SID list in PC Reply (PCRep)

• PCC installs path, sends PC Report (PCRpt) (with Delegate-flag set)

56

Agile Carrier Ethernet Demo

57

Application Engineered

Routing

SimplificationAPP Interaction

SDN Orchestration

Consolidated

VPN Services

AutomationProgrammability

FlexibilitySecurity

Agile Carrier Ethernet (ACE) Architecture

58

Unified MPLS vs. Agile Carrier Ethernet

Unified MPLS Agile Carrier Ethernet

Separation into IGP Domains Yes Yes

Transport Path E2E Yes Yes

Intra-Area Path Provisioning IGP/LDP IGP with Segment Routing

Inter-Area Path Provisioning BGP-3107 Dynamic via PCE

Service Provisioning MP-BGPProgrammed - Netconf/YANG &

MP-BGP

Redundancy LFA/R-LFA TI-LFA

Traffic Engineering RSVP TE SR TE

Application Engineered Routing N/A Yes (with WAE integration) 59

https://tools.ietf.org/html/draft-filsfils-spring-large-scale-interconnect-00

ACE

60

Core

Metro1

Metro2

A B

GW21 1002

GW221002

GW11 1001

GW121001

NSO

A1

CE1 CE2

GUI/CLI/RESTService (L2/L3VPN) + SLA

NSO:

1. Creates L2/L3 VPN

2. Creates SR Tunnel Interface

Destination = B

SLA „tag“ (e.g. 1)

Sid-list 1001, 1002, 16040

3. Creates static route to Tunnel

ACE – Concept Phase 1

ACE

192.168.0.1

Sid 16010

192.168.0.4

Sid 16040

• NSO (Service Orchestration and

transport configuration)

• NSO verifies if service provisioning

is intra- or inter-area path

• NSO queries internal static table

for sid-list (if inter-area) and

programs transport path, along with

service statically via Netconf/YANG

(NED) to the edge devices.

61

Core

Metro1

Metro2

A B

GW21 1002

GW221002

GW11 1001

GW121001

NSO

A1

CE1 CE2

GUI/CLI/RESTService (L2/L3VPN) + SLA

NSO:

1. Creates L2/L3 VPN

2. Creates SR Tunnel Interface

Destination = B

SLA „tag“ (e.g. 1)

PCE IP

3. Creates static route to Tunnel

ACE – Concept Phase 2

ACE

192.168.0.1

Sid 16010

192.168.0.4

Sid 16040

PCE

BGP-LS

62

Core

Metro1

Metro2

A B

GW21 1002

GW221002

GW11 1001

GW121001

NSO

A1

CE1 CE2

GUI/CLI/RESTService (L2/L3VPN) + SLA

NSO:

1. Creates L3 VPN

2. Creates ODR Policy and tags BGP

routes with ext. community

Points to PCE

3. Node creates auto_Tunnel for next hop

ACE – Concept Phase 3

ACE

192.168.0.1

Sid 16010

192.168.0.4

Sid 16040

PCE

BGP-LSC

63

IP CoreMobile Aggregation Mobile Core

PGW

low

latency

best effort

NSO

Service PortalService (L2/L3VPN) + SLA

ALI

VAL

EPC

BCN

BCN

MAD

MAD

PCEBGP RR

192.168.0.1 192.168.0.2 192.168.0.3

192.168.0.4

192.168.0.11 192.168.2.2 192.168.2.3

64

• Using an SDN-centric approach can result in tremendous simplification in Carrier Ethernet Networks

• Using Application Engineered Routing helps to reduce complexity and makes Traffic Engineering “cheap”

• Cisco Architecture “Agile Carrier Ethernet” combines the SDN-centric approach with AER

Conclusion

65

Call to Action

• Visit the World of Solutions for

• Cisco Campus – EPN, Segment Routing Demo (SP Booth)

• Similar Breakout Sessions

• BRKSPG-2456 True Realisation of SDN and NfV in an SP Environment

66

Complete Your Online Session Evaluation

• Please complete your online sessionevaluations 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 viathe Cisco Live Mobile App or theCommunication Stations

67

Demo

68

Thank you

69