PLNOG 13: Julian Lucek: Centralized Traffic Enginnering

CENTRALISED TRAFFIC
ENGINEERING
JULIAN LUCEK
JLUCEK@JUNIPER.NET
PLNOG13, SEPTEMBER 2014
Copyright © 2014 1 Juniper Networks, Inc. Copyright © 2013 Juniper Networks, Inc.

AGENDA
1
2
3
Motivations for Centralised Traffic Engineering
Key protocol mechanisms: PCEP, BGP-LS
TE Controller Example: NorthStar
Copyright © 2014 2 Juniper Networks, Inc.

WHAT INFORMATION GOES INTO DETERMINING A PATH FOR
PACKET TRAFFIC?
Shortest
Path
(IGP,LDP)
Distributed
TE
(constrained SPF)
+
Reservable
Topology bandwidth
+
Centralised
TE
+
Reservable
Topology bandwidth
Fragmented view of
packet demands
+
Complete 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
90/100
P1 P2
20/100
0/50 0/50
PE1
bw=20
PE2
bw=90 20/50 20/50
P3
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.

DISTRIBUTED TRAFFIC ENGINEERING
I J K
L M
N O P
A
C
B
X
Z
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.

CENTRALISED TRAFFIC ENGINEERING
I J K
L M
N O P
A
C
B
X
Z
TE Controller has knowledge
of all the LSPs needed, so
can perform a global
optimisation.

AUTONOMOUS OPTIMISATION: FAILURE SCENARIOS
I J K
L M
N O P
A
C
B
X
Z

DYNAMIC LSP SPLITTING
LSP A-E (7G Auto-Bw Adjusted) LSP A-E (7G)
Traffic surges to 10G
Traffic drops to 4G LSP A-E-1 (5G)
LSP A-E (4G)
LSP A-E-2 (5G)
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:
1
1 Node tagged as going into maintenance mode, affected LSPs are identified by NorthStar.
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.
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

Path Computation Element

PCE: A STANDARDS-BASED APPROACH
What is it? Components
§ 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
PCEP PCE
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.

A CTIVE 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

SPRING (SEGMENT ROUTING)
Path
setup
To make traffic take path
A-L-M-N-Y, send it to L
with label stack =
{406,607,708}
Centralized
path
computation
L N
A
M
Y
C
D
Z
407 708
704 807

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)

GIVING CONTROLLER VISIBILITY OF TED VIA IGP
PEERING
B D F H
E
G J
K
C
A
Central
Controller
IGP over G RE
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

TED NLRI TYPES: NODES AND LINKS
Link NLRI describes “unidirectional link”
“Link Attribute” TLVs: carry
same info between domains as
carried by IGP TE extensions
within a domain
“Node
Anchor” TLVs
“Link Descriptor”
TLVs

GIVING CONTROLLER VISIBILITY OF TED VIA BGP-LS
B D F H
E
G J
K
C
A
Central
Controller
Central Controller just needs one
BGP-LS session with network
BGP-LS

Putting it all together

INTERACTION BETWEEN CONTROLLER AND
NETWORK (1)
LSP X
LSP Y
BGP-LS
TE Controller
Network
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.

NETWORK (2)
LSP X
LSP Y
LSP X
LSP Y
PCEP
TE Controller
Network
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

NETWORK (3)
LSP X
LSP Z
LSP Y
LSP X
LSP Y
LSP Z
TE Controller
Network
PCEP
Controller can compute LSP path and install it on ingress router using PCEP.
Ingress router confirms successful setup of LSP using PCEP.

TE Controller Example: Northstar

NETWORK PROGRAMMABILITY MODEL
Path
Computation
OPTIMISE
Routing
BGP-LS
PCEP
Netconf/YANG
Topology
Discovery
Path
Installation
ANALYZE
PROVISION
CSPF
Algorithms
ANALYTICS
ENGINE
Dynamic feedback loop
harvests network
state

NORTHSTAR CONTROLLER
SOFTWARE-DRIVEN POLICY
ANALYZE OPTIMISE PROVISION
Topology Discovery Path Computation Path Installation
Routing Algorithms 3 PCEP Netconf/YANG rd party
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
Algorithms
RSVP
signaling
OPEN
APIs

STANDARD APIS FOR 3RD PARTY TOOLS &
CUSTOM APPLICATIONS
Standard, custom, & 3rd party Applications
Built-in Applications, e.g.
Bandwidth Calendaring
LSP Path Diversity
Node Maintenance
REST or
Thrift
REST or
Thrift
Topology API Path Comput. API Path Provision API
Topology Discovery Path Computation Path Installation
Routing Junos CSPF Algorithms PCEP Netconf/YANG
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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to PLNOG 13: Julian Lucek: Centralized Traffic Enginnering

Similar to PLNOG 13: Julian Lucek: Centralized Traffic Enginnering (20)

Recently uploaded

Recently uploaded (20)

PLNOG 13: Julian Lucek: Centralized Traffic Enginnering