PLNOG 13: Julian Lucek: Centralized Traffic Enginnering

Copyright © 2014 Juniper Networks, Inc. 1 Copyright © 2013 Juniper Networks, Inc.

CENTRALISED TRAFFIC ENGINEERING

JULIAN LUCEK [email protected] PLNOG13, SEPTEMBER 2014

Copyright © 2014 Juniper Networks, Inc. 2

Title Only

1

2

AGENDA

3

Motivations for Centralised Traffic Engineering

Key protocol mechanisms: PCEP, BGP-LS

TE Controller Example: NorthStar


WHAT INFORMATION GOES INTO DETERMINING A PATH FOR PACKET TRAFFIC?

Shortest Path

(IGP,LDP)

Distributed TE

(constrained SPF)

+Reservable bandwidth Topology

+

Centralised TE

+Reservable bandwidth Topology

+Complete view of packet demands

Fragmented view of packet demands

Topology


ADVANTAGES OF CENTRALISED CONTROL

Purely distributed computation does not work for all cases. A central entity (TE Controller) with global knowledge can: • Avoid TE “blocking” problems that occur in distributed computation case

• Compute a global optimum for a set of TE paths •  Can use more sophisticated algorithms than CSPF •  Can make more efficient use of network resources

• Deal with path diversity requirements • Give predictability in path placement • Take account of future requirements, when computing paths


LSP BLOCKING PROBLEM WITH DISTRIBUTED TE

20/100

0/50 0/50

PE1

PE2

PE3

X/Y: X=reserved bw Y=total link bw

•  PE1 has already set up the green LSP to PE3, with BW reservation of 20 units.

•  PE2 wants to set up an LSP to PE3 with BW=90. It is blocked by presence of green LSP.

•  Centralised path computation would solve the problem.

bw=20

P1 P2

P3

bw=90 20/50 20/50

90/100


N O P

L M

DISTRIBUTED TRAFFIC ENGINEERING

I J K

B

X

Z

A

C

Suppose all links are 10G. Assume all links have same metric. A has set up an LSP to X, bw=4 B has set up an LSP to Z, bw=4. If C now needs to set up an LSP to Z, with bw=4, it has to use a non-optimum path.


N O P

L M

CENTRALISED TRAFFIC ENGINEERING

I J K

B

X

Z

A

C

TE Controller has knowledge of all the LSPs needed, so can perform a global optimisation.


AUTONOMOUS OPTIMISATION: FAILURE SCENARIOS

N O P

L M

I J K

B

X

Z

A

C


DYNAMIC LSP SPLITTING

LSP A-E (7G Auto-Bw Adjusted) LSP A-E (7G)

LSP A-E-2 (5G)

Traffic surges to 10G

LSP A-E-1 (5G) Traffic drops to 4G

LSP A-E (4G)

E

A B

C D


PATH DIVERSITY

PE1

PE2

PE3

PE4

• The two paths must be engineered such that they have no nodes or links in common – including the PEs!

• Difficult to achieve path separacy when each ingress node calculates its own path.

• However, a central controller can calculate both paths to ensure separacy.


P2MP PATH DIVERSITY

Source, S1 Source, S2

Ingress PE1 Ingress PE2

Egress PEs Egress PEs

Receiver Receiver

The two P2MP LSPs have different ingress PEs and must not have any nodes or links in common • Difficult to ensure path separacy when ingress nodes calculate the paths. • However, a central controller can calculate both paths to ensure separacy.


BANDWIDTH CALENDARING

Bandwidth Calendaring allows network operators to reserve resources in advance

§  Via NorthStar GUI or via API §  Can be a one-off reservation, or a recurring reservation


PROGRAMMABLE PATH COST FUNCTION

Lowest latency path Lowest IGP metric path

Path computation according to application/service requirements: •  Lowest metric path •  Lowest latency path •  Path that avoids particular links or nodes


MAINTENANCE-MODE

Automate re-routing of traffic before a scheduled maintenance window:

Node tagged as going into maintenance mode, affected LSPs are identified by NorthStar. 1

1 3

X X

X

2

2 LSPs are re-computed and re-signaled around the affected node through a PCEP update (all make-before-break). Node is subsequently moved into maintenance mode.

Node is tagged as available again after maintenance window finishes. Optimum LSP paths are restored again through PCEP update and LSP re-signaling

3 Node is tagged as available after maintenance window finishes. Optimum LSP paths are restored through PCEP update and re-signaling.


KEY ATTRIBUTES OF A CENTRALISED CONTROLLER • Has real-time knowledge of topology of network, link attributes and bandwidth availability on each link

• Has real-time knowledge of status and attributes of all TE LSPs in the network

• Has real-time knowledge of the traffic matrix • Has the ability to modify existing LSPs, and to instantiate new LSPs

• Has the ability to exchange information and receive requests for action from northbound applications via APIs


Title Only

Path Computation Element


PCE: A STANDARDS-BASED APPROACH

§  PCE: Path Computation Element (RFC 4655)

An entity that can calculate paths in the network

§  PCE: Path Computation Element Computes the path

§  PCC: Path Computation Client Receives the path. Signals LSP using RSVP (or sets up SPRING LSP)

§  PCEP: PCE protocol (RFC 5440) For PCE/PCC communication

Components What is it?

PCE PCEP

PCC PCC

PCC


ACTIVE STATEFUL PCE

• The original PCE draft (mid-2000s) were mainly focused on stateless PCE.

• In the last two years, the hot topic has been Active Stateful PCE, as it is in line with the SDN paradigm.

•  The PCE has visibility into the network state AND the demands

•  The PCE (rather than the routers) is the entity that drives changes •  Dictates the order of operations network-wide •  Creates new state


LSP TYPES, WHEN USING ACTIVE STATEFUL PCE 1/ “Vanilla” LSP

•  Configured on ingress router (i.e. exists in router config file) •  Path computed by ingress router using CSPF •  Existence of LSP, and associated parameters, reported to PCE for PCE’s info

only – PCE cannot modify the LSP.

2/ Delegated LSP •  Configured on ingress router (i.e. exists in router config file) •  When first set up, path is computed by ingress router using CSPF •  Delegated to PCE – means that PCE can modify parameters from time to time

e.g. bandwidth, ERO

3/ PCE-initiated LSP •  PCE decides to create LSP. •  Sends set-up request to ingress router via PCEP, with ERO, bandwidth etc •  Automatically delegated to PCE –means that PCE can modify parameters over

time •  Is ephemeral –does not exist in router’s config file.


ACTIVE STATEFUL PCE FUNCTIONS • Delegation – ability for a PCC to grant control over an LSP • Report (PCRpt)– ability for a PCC to report state of LSPs

•  Each LSP Status Report in a PCRpt message can contain the actual LSP's path, bandwidth, operational and administrative status

•  Can report all LSPs, delegated and non-delegated, so PCE has full visibility of all LSPs

• Update (PCUpd) – ability of the PCE to update attributes for an LSP delegated to it

• Instantiate/tear down (PCInitiate)– ability for a PCE to create or tear down an LSP


N L

A

M

Y

C

D

Z

To make traffic take path A-L-M-N-Y, send it to L with label stack = {406,607,708}

Path setup

Centralized path

computation

N L

A

M

Y

C

D

Z

407 708

704 807

SPRING (SEGMENT ROUTING)


Title Only

BGP-LS


BGP-LS BACKGROUND • Mechanism to carry traffic engineering link state info in BGP

•  bandwidth availability, link colours (admin-groups), SRLGs etc

• Two major categories of application • 1/ For inter-domain (i.e. inter-area, inter-AS) traffic engineering.

•  Traditional approach of loose-hop expansion at border nodes has limitations

• 2/ As a “TE-topology reporting protocol” towards a central controller (e.g. a PCE)

•  Much cleaner than using IGP, or CLI-scraping

• Was called BGP Traffic Engineering (BGP-TE) in the earlier drafts • Later changed name to BGP Link State (BGP-LS)


B H D F

E

G J

K

C

A

GIVING CONTROLLER VISIBILITY OF TED VIA IGP PEERING

Central Controller

IGP over GRE

tunnel

IGP over GRE tunnel

Each router only knows TED of its own IGP area(s), so Central Controller needs IGP peering with each area


“Link Attribute” TLVs: carry same info between domains as carried by IGP TE extensions

within a domain

TED NLRI TYPES: NODES AND LINKS “Node

Anchor” TLVs

“Link Descriptor” TLVs

Link NLRI describes “unidirectional link”


B H D F

E

G J

K

C

A

GIVING CONTROLLER VISIBILITY OF TED VIA BGP-LS

Central Controller

Central Controller just needs one BGP-LS session with network

BGP-LS


Title Only

Putting it all together


INTERACTION BETWEEN CONTROLLER AND NETWORK (1)

LSP X

LSP Y

Network

TE Controller

BGP-LS peering between TE Controller and at least one node in the network gives TE Controller real-time knowledge of topology and TE parameters of each link.

BGP-LS



LSP X

LSP Y

Network

TE Controller

LSP X and LSP Y were set up via router CLI, not PCEP. However, each LSP ingress router reports existence of its LSPs to the controller via PCEP. In this way, controller is made aware of the existence of such LSPs

PCEP

LSP X

LSP Y



LSP X

LSP Y

Network

TE Controller

Controller can compute LSP path and install it on ingress router using PCEP. Ingress router confirms successful setup of LSP using PCEP.

PCEP

LSP X

LSP Y

LSP Z

LSP Z


Title Only

TE Controller Example: Northstar


Title Only

Routing

BGP-LS

PCEP

Netconf/YANG

Topology Discovery

Path Installation

Path Computation

ANALYZE

PROVISION

OPTIMISE CSPF

Algorithms

NETWORK PROGRAMMABILITY MODEL

ANALYTICS ENGINE

Dynamic feedback loop harvests network

state


Title Only

SOFTWARE-DRIVEN POLICY

Topology Discovery Path Computation Path Installation

NORTHSTAR CONTROLLER

PCEP §  LSP discovery IGP-TE, BGP-LS §  TED discovery Traffic Statistics

PCEP §  Install traffic engineered LSP §  One session per LER/PCC

Netconf/XML/YANG BGP-flowspec §  Other state injection methods

ANALYZE OPTIMISE PROVISION

Routing Netconf/YANG PCEP Algorithms 3rd party Algorithms

RSVP signaling

OPEN APIs


Title and Bullets

STANDARD APIS FOR 3RD PARTY TOOLS & CUSTOM APPLICATIONS

Topology Discovery Path Computation Path Installation

Topology API Path Comput. API Path Provision API

Routing Netconf/YANG PCEP Junos CSPF Algorithms

Standard, custom, & 3rd party Applications

Built-in Applications, e.g. Bandwidth Calendaring LSP Path Diversity Node Maintenance

REST or Thrift

REST or Thrift

REST or Thrift

Custom and 3rd Party Applications


SUMMARY • TE Controller: Real-time visibility and control of the network. • Solves problems that Distributed TE cannot

•  Fully diverse paths •  Avoidance of LSP blocking •  Globally optimum bin-packing

• APIs for interaction with Northbound applications • Uses standards-based protocols wherever possible

•  PCEP •  BGP-LS

• For more details: •  http://www.juniper.net/us/en/products-services/sdn/northstar-

network-controller/ . •  Please get in touch if you would like to see a demo.

PLNOG 13: Julian Lucek: Centralized Traffic Enginnering

Internet

Transcript of PLNOG 13: Julian Lucek: Centralized Traffic Enginnering