Presentation by Andrew Dolganow at APRICOT 2017 on Monday, 1 March 2017.

1. 1 © Nokia 2017
Stateful PCE and Segment
Routing
Increasing IP/MPLS network efficiency
Andrew Dolganow
February 2017
Public

2. 2 © Nokia 2017
– Discovers TE resources and topology by
tapping into IGP Segment Routing updates
(IGP, BGP-LS) and collecting link statistics
(Telemetry/IPFIX)
– Accepts requests from nodes or management
systems for computing paths (using the Path
Computation Element Protocol [PCEP]).
– Communicates with PCEs in other
domains/areas for multi-domain/area path
computation (Hierarchical PCE).
– Regularly re-optimises and downloads path
(re-)placement to nodes given measured real-
time traffic demand, LSP statistics, and
network-state.
– Supports TE tunnelinhg like RSVP and
Segment Routing
Traffic engineering with stateful PCE server
Public
Stateful PCE
State & Stat
Collection
Network
Topology
Disovery
Control
session
manager
Northbound I/F
Network
Telemetry/Ipfix IGP/BGP-LS PCEP/OF/BGP-
FS
PCEP Databases Path computation and
re-optimization engine

3. 3 © Nokia 2017
PCC-Initiated and PCE-Controlled SR-TE LSP:
Setup
• Once the SR-TE LSP is placed into a no shutdown state
the PCC sends a Path Computation Request (PCReq) to
the PCE.
• The PCE responds with a Path Computation Reply
(PCRep), which if successful carries an SR-ERO object
with the hops of the LSP
– If the PCE is unable to compute a path it will return a
PCRep with a NO-PATH object together with a NI
(Nature of Issue) field and a NO-PATH-VECTOR TLV
listing the reason for the negative reply.
• The PCC instantiates the SR-TE LSP and responds with a
Path Computation LSP State Report (PCRpt) indicating the
operational state of the LSP and delegating the LSP to the
PCE.
P1
192.0.2.43
Node-SID 20043
P2
P3 P4
PE4
PE3
192.0.2.13
Node-SID 20013
192.0.2.223
Node-SID 20223
192.0.2.222
Node-SID 20222 192.0.2.19
Node-SID 20019
192.0.2.28
Node-SID 20028
PCC PCE
PCReq
PCRep
PCRpt
Adj-SIDs
Public

4. 4 © Nokia 2017
PCE-Controlled SR-TE LSP: Failure Recovery
• As Segment Routing has no inherent control plane, it
must rely on other mechanisms to detect a
downstream failure of the LSP
• The PCE is aware of the domain-wide topology, so it
will be made aware of topology changes (through
IGP listening or BGP-LS).
• If the PCE is active it is therefore able to re-route
delegated LSPs around network failures.
• Upon detection of the topology change, the PCE
computes a new path for the affected LSP(s) and
sends a Path Computation Update (PCUpd)
message containing an SR-ERO with a newly
computed post-convergence path.
P1
192.0.2.43
Node-SID 20043
P2
P3 P4
PE4
PE3
192.0.2.13
Node-SID 20013 192.0.2.223
Node-SID 20223
192.0.2.222
Node-SID 20222
192.0.2.19
Node-SID 20019
192.0.2.28
Node-SID 20028
PCC PCE
PCUpd
PCRpt
• The PCC instantiates the new path and responds with a Path Computation LSP State Report (PCRpt)
containing the SR-ERO, a Reported-Route object (RRO) listing the actual hops, an LSP object listing the
admin/operational state of the LSP, together with Metric and Bandwidth objects.
Public

5. 5 © Nokia 2017
Increasing network utilization with PCE control
Public
• PCE can be designed to balance link utilisation and network utilisation goals with orthogonal objectives:
‒ Efficiency: Consume as little total network bandwidth as possible to optimise cost.
‒ Balance: Avoid overloading any links to avoid congestion and deadlock situations.
.• The optimal balance can be determined by introducing a factor a determining the degree for considering
alternate paths. An α of 0 corresponds to shortest path (min-hop) and an α of ∞ to the least congested
path (min-max).
0α =
¥=α
¥££ α0
LinkUtilization
NetworkUtilization
• One example: a 59-node network, 30,000 requests 1-10G Gb/s, Bell Labs STAR algorithm yields:
‒ 99.92% of path requests are accepted
‒ The same requests yield 87% of path request acceptance by CSPF

6. 6 © Nokia 2017
• Example: Service 1 needs to be routed
disjoined from Service 2 using SPF algorithm
(latency optimization through cost) instead of
STAR
• Programming behavior
- PCEP includes a ‘path-profile’ object
- A path-profile represents a policy (i.e. a list of path
parameters) that a PCC may present to PCE to
influence path computation
• Plane to use
• Algorithm to use
• Etc.
- A Profile/template is configured in TE controller
corresponding to a supported path-profile indicating
how the PCE TE controller should perform the path
calculation
- Paths are computed and returned to PCC via PCEP
Improving path placement grnaularity with PCE Path Profile
PCE TE controller
PCReq (path-
profile=1)
...
Path Profile configuration
PCEP Msg
Public
PE1
P1
PE3
Node-SID 30
Node-SID 10
P2
P5 P6
P3 P4
P7 P8
Red Plane
Anycast SID 100
Blue Plane
Anycast SID 200
PE2
Node-SID 20
PE3
Node-SID 40
Service 1
Service 2

7. 7 © Nokia 2017
Adjacency segment load balancing with PCE
Public
• Multiple adjacencies exist between P1-P2.
• Adj-SID TLV provides the capability to load-
balance across multiple adjacencies.
– P1 advertises individual Adj-SIDs for
the link A (1001) weight X, and link
B(1002) with weight Y.
– P1 also advertises an Adj-SID for the
adjacency set (1003).
• By default PCE returns. To PE1 segment list
{200, 1003, 800}. Node-SID 200 gets the
traffic to P1 whilst Adj-SID 1003 load-
balances the traffic to P2 on a weighted X:Y
basis.
• Based on link monitoring, PCE can use
either Adj SID of link A or Adj SID of link B in
PCRep to a PCReq or PCUpd foran existing
path to rebalance adjacencies
Weighted load-
balancing on
P1-P2 links
Node-SID 300
PE1 P1 P2 PE2
Node-SID 200Node-SID 100
Packet
800
Link A
Link B
Node-SID 800
Packet
800
Packet
Link Adj-SID Adj-Set Weight
10G 1001 1003 1
40G 1002 1003 4
Both 1003 - -
1003
200
800
Swap
800 to 800
Pop {200,
1003}
PCC PCE
PCRep/PCUp
dPCRpt1001
200
800
1002
200
800

8. 8 © Nokia 2017
AS 100
– PeerNode segment for each of its defined peers (R7,
R8, and R9)
– PeerAdj segment for each recursive interface to a
multi-hop peer (R9)
– PeerSet segment to a set of peers (R7 & R8 [AS200]).
• BGP-LS session established between EPE-enabled
border router (R1) and the EPE controller:
– R1 advertises PeerNode, PeerAdj, and PeerSet SIDs
using SR extensions to BGP-LS and programmes FIB.
• EPE controller programmes source-routes from ingress
routers to EBGP peers using i.e.
FlowSpec/OpenFlow/BGP SR TE policy; ie:
– 80% traffic to AS 300 with segment list {100, 1005}.
– 20% traffic to AS 200 with segment list {100, 1006}.
– Prefix <NLRI/Length> segment list {100, 1003}
– Prefix <NLRI/Length> segment list {100, 1004}
Egress Peer Engineering (EPE)
R2
1001
300
• Egress Peer Engineering (EPE) defines three BGP Peering SIDs, that allow for programming of source-
routed inter-domain paths; PeerNodeSID, PeerAdjSID, and PeerSetSID.
• R1 is an EPE-enabled egress router and allocates the following:
Incoming Label Operation Outgoing Interface
1001 POP Link to R7
1002 POP Link to R8
1003 POP Upper link to R9
1004 POP Lower link to R9
1005 POP Load-balance on any link to R9
1006 POP Load-balance on any link to R7 or R8
R1
AS 200
AS 300
R7
R8
R9
EPE controller
BGP-LS
Node-SID
100
CoarseGranular
Public

10. 10 © Nokia 2017 Public
Copyright and confidentiality
The contents of this document are proprietary and
confidential property of Nokia. This document is
provided subject to confidentiality obligations of
the applicable agreement(s).
This document is intended for use of Nokia’s
customers and collaborators only for the purpose
for which this document is submitted by Nokia. No
part of this document may be reproduced or made
available to the public or to any third party in any
form or means without the prior written permission
of Nokia. This document is to be used by properly
trained professional personnel. Any use of the
contents in this document is limited strictly to the
use(s) specifically created in the applicable
agreement(s) under which the document is
submitted. The user of this document may
voluntarily provide suggestions, comments or
other feedback to Nokia in respect of the contents
of this document ("Feedback"). Such Feedback
may be used in Nokia products and related
specifications or other documentation.
Accordingly, if the user of this document gives
Nokia Feedback on the contents of this document,
Nokia may freely use, disclose, reproduce,
license, distribute and otherwise commercialize
the feedback in any Nokia product, technology,
service, specification or other documentation.
Nokia operates a policy of ongoing development.
Nokia reserves the right to make changes and
improvements to any of the products and/or
services described in this document or withdraw
this document at any time without prior notice.
The contents of this document are provided "as
is". Except as required by applicable law, no
warranties of any kind, either express or implied,
including, but not limited to, the implied warranties
of merchantability and fitness for a particular
purpose, are made in relation to the accuracy,
reliability or contents of this document. NOKIA
SHALL NOT BE RESPONSIBLE IN ANY EVENT
FOR ERRORS IN THIS DOCUMENT or for
any loss of data or income or any special,
incidental, consequential, indirect or direct
damages howsoever caused, that might arise
from the use of this document or any contents of
this document.
This document and the product(s) it describes
are protected by copyright according to the
applicable laws.
Nokia is a registered trademark of Nokia
Corporation. Other product and company names
mentioned herein may be trademarks or trade
names of their respective owners.