Download - WSDN01 - Module 5 - PCE - v1
Issue Date:
Revision:
Path Computation ElementSDN Workshop
[Date]
[xx]
WSDN01_v0.1
Overview
• In a nutshell• Introduction• Motivations• PCE architecture• Stateful PCE• PCE-initiated LSPs• PCEP• PCEP extensions for stateful PCEs• PCEP extensions for PCE-initiated LSPs• SR extensions• Operational considerations• References
3
4
In a nutshell
SDN architectural framework
5
Application Plane
Application Service
Topology Discovery & Management
Network Devices – IP/MPLS/Transport
Southbound Interfaces
REST/RESTCONF/NETCONF/XMPP
Control Plane
(controller)
Traffic Engineering
Route selection & failover
Resource Management
BGP-LS PCE-Pi2RS
SNMP MIBs OpenFlow YANG
Configuration
OpenFlowSNMP Netconf
Data Plane
BGP PCCRIBs
RSVP-TE
East/West-bound
interfaces –BGP
IPFIXForCES
Northbound Interfaces
Note: designations of north-bound and south-bound are relative to the control plane (“controller”)
Device & Resource Abstraction Layer (DAL)
Network Services Abstraction Layer
Segment Routing
PCE: in a nutshell…
6
Mechanism by which the responsibility of path computation can be devolved to a central server
By decoupling the path computing function from routers and enabling them to communicate with the path computation element via a standard protocol.
To exploit the benefits of a centralised control element as espoused by the SDN architectural paradigm.
What?
How?
Why?
The PCE split
7
FROM TO
Path Computation Element
Path Computation Client
Path Computation Client
Path Computation
Element
PCE Protocol (PCEP)
PCE
PCC
PCE
PCC
Computes paths based on desired characteristics e.g. bandwidth
Consults PCE for path, then signals it using a protocol such as RSVP-TE
Tightly coupled
Centralised path computation
8
Path Computation Client
Path Computation
Element
. . .
Router 1 Router 2 Router n
One PCE for many PCCs
Path Computation Client
Path Computation Client
PCE Protocol (PCEP)
PCE Protocol (PCEP)
9
Introduction
MPLS traffic-engineering objectives
10
Optimisationof resource usage in the
network
To provide QoS
guarantees
To provide fast failure recovery
(fast-reroute)
Key objectives of MPLS TE
Elements of MPLS-TE solution
11
Routing IGP traffic-engineering extensions
SignalingEstablishes the
LSP by signaling it along the
computed path
Path ComputationPlacement of LSP by the head-end LSR based on
CSPF algorithm
MPLS TE is concerned with explicitly routing MPLS LSPs whose paths satisfy a set of traffic-engineering constraints
Path computation
• In a traffic-engineering context:
12
The determination of an ordered
sequence of nodes and/or links that
a traffic path should traverse while
satisfying specified constraints
Path computation algorithms (1)
• Dijkstra’s algorithm (SPF):
– Given a network graph comprised of vertices (nodes) and edges (links), the algorithm is able to determine the shortest path between any pair of nodes.
– The concept of shortest is based on the ‘length’ of each graph edge
13
Shortest path from 1 to 2: 1 -> 3 -> 4 -> 2
12
3
4
5
6
3
539
25
7
12
4
11
Path computation algorithms (2)
• Constrained SPF
– Given a network graph comprised of vertices (nodes) and edges (links), the algorithm is able to determine the shortest path between any pair of nodes, after pruning nodes and links that do not satisfy the required constraints.
– Used by RSVP-TE in MPLS networks
14
12
3
4
5
6
3
539
25
7
12
4
Constraint: only ‘blue nodes’
11
Shortest path from 1 to 2: 1 -> 4 -> 6 -> 2
Current mode of operation
15
12
3
4
5
6
3
539
25
7
12
4
11
All routers are ’Composite PCE’ nodes, having both path computation and path
signaling functions
Signaling Engine
TED
PCE
Input
Request/Response
PCC
16
Motivations
Key motivations (1)
• CPU-intensive path computations:– e.g. complex algorithms that attempt to minimise the maximum link
utilisation
• Partial visibility due to TE information not being advertised across domain boundaries:– e.g. in case of LSPs that start in one domain and end in another.
• Absence of a traffic-engineering database (TED):– e.g. when using devices that may not have the required memory or
processing capability to handle large TEDs
17
Key motivations (2)
• Lack of control plane capability on network elements:– e.g. in the case of optical networks
• Backup path computation for bandwidth protection:– e.g. co-ordinated computation of backup path resources across
multiple LSPs
• Multi-layer networks:– e.g. an IP/optical network where the IP network needs to understand
resource dependencies in the optical network
18
Scenario: inter-domain LSP (1)
• Challenges:– Routing and traffic-engineering info is not distributed outside of
domain boundaries– If we cannot see all links and nodes along the path from a source to
destination, how can we construct an optimal end-to-end path ?– How can a node select an exit point from its domain ?
• Solutions:– Per-domain path computation– Simple, co-operating PCEs– Backward Recursive Path Computation
19
Domain 2
Domain 1
Scenario: inter-domain LSP (2)
20
Requirement: An optimal (based on hop count) TE path needs to be calculated between router 1 and 15.
All IGP metrics are equal to 10 unless otherwise indicated
2 5
143
6
7
9
10 11
12 14
13Router 1 selects router 5 as exit
point: 1-2-5 (shortest path)
815
Routes are summarisedbetween the
domains
Router 7’s shortest path to 15 is 7-10-11-15
Computed path from 1 to 15 is 1-2-5-7-10-11-15
(hop count = 6)
Actual shortest path from 1 to 15 is 1-3-4-6-12-15
(hop count = 5)
21
PCE Architecture
Terminology: information sources
CSPFConstrained Shortest Path First. Shortest path algorithm that first prunes the network graph of elements that do not satisfy computational constraints.
LSDBLink-state database with information on nodes within the domain and links inter-connecting them.
Traffic Engineering Database (TED)Database of topology (nodes and links connecting them) and resource information of the domain.
22
Terminology: TE-LSPs
Domain(RFC4655) “Any collection of network elements within a common sphere of address management or path computation responsibility”
Inter-domain TE LSPA traffic-engineered LSP whose head-end LSR and tail-end LSR do not reside in the same domain, where a domain is either an IGP area, autonomous system or a BGP confederation
23
Terminology: PCE
Path Computation Client (PCC)A client application (typically a router) that requests a path computation to be performed by the Path Computation Element (PCE)
Path Computation Element (PCE)A network entity that is capable of computing a network path given a network graph while taking into account computational constraints.
Path Computation Element Protocol (PCEP)Protocol used for communication between non-collocated PCCs and PCEs.
24
MPLS-TE with PCE
• A Path Computation Element (PCE) can be used to compute MPLS-TE paths:
– within a “domain” (e.g. an IGP area)• May be used to provide greater computational capability, ability to impose additional
policy and more complex algorithms
– across multiple domains (such as a multi-area AS or multiple ASs)• Since the TED only includes information for a single area, routers cannot make
optimal decisions for constructing end-to-end traffic-engineered paths.• One solution to this problem is per-domain path computation (RFC5152). However,
it suffers from several limitations.
– across layers• One use case is creating diverse MPLS-TE LSPs at the IP layer while ensuring that
no SRLGs exist at the optical layer
25
The PCE split
26
FROM TO
Path Computation Element
Path Computation Client
Path Computation Client
Path Computation
Element
PCE Protocol (PCEP)
PCE
PCC
PCE
PCC
Computes paths based on desired characteristics e.g. bandwidth
Consults PCE for path, then signals it using a protocol such as RSVP-TE
Tightly coupled
Path Computation Element (PCE)
• A network entity that is capable of computing a network path given a network graph while taking into account computational constraints such as:– required minimum bandwidth– minimum latency– maximum hop count
• PCE refers to a specific function and does not imply a separate hardware element; it can be located on:– a routing node– a separate server or,– be part of the network management system
27
PCC and PCE: responsibility split
28
Path Computation Element (PCE)
• Responsible for calculating paths given:
• Source node• Destination node• Required constraints:
• bandwidth• latency• SRLGs• protection etc
• Is not involved in signaling the actual path
Path Computation Client (PCC)
• Network element that requests path computation from a PCE
• Supplies all necessary constraint information to the PCC
• Once it receives a path from the PCE, the PCC signals it using RSVP-TE or uses supplied segment list in the header of segment-routed packets
Computation Signaling
Types of paths
29
Fully-specified explicit paths
Complete explicit path from the source to the destination
comprising a list of strict hops
Partially-specified paths
Path specified as an ordered sequence of loose and/or strict
hops where the loose hops may be expanded by
intermediate nodes in the path.
Network path
Ordered sequence of nodes and/or links that a traffic path should traverse in order to
meet specified constraints
Scope of path computation
30
Intra-domain
Case where operator has ownership of entire network
across which path computations are desired
Inter-domain
Requires some level of visibility across all domains
Inter-layerMulti-layer scenario where path
computation at a layer is required to take into account
topology and resource information at other layers.
Path computation scope
Extent of path computation
Domain• “Any collection of network
elements within a common sphere of address management or path computation responsibility” [RFC4655]
• Example:• IGP areas• Autonomous systems• Multiple autonomous
systems within a service provide network
Computation Models (1)
31
Single PCE
A single PCE is used to calculate any given path in a domain. Multiple PCEs may exist in the domain but only a
single one is selected for each computation.
Multiple PCE
Multiple PCEs work together in order to compute any path in the domain. For example,
a different PCE could be used in each sub-domain of an
intra-domain path.
Single/Multiple PCEs
Number of PCEs involved in path calculation
Computation Models (2)
32
Single PCE
A single PCE is used to calculate any given path in a domain. Multiple PCEs may exist in the domain but only a
single one is selected for each computation.
Multiple PCEs
Multiple PCEs work together in order to compute any path in the domain. For example,
a different PCE could be used in each sub-domain of an
intra-domain path.
Centralised Computation Model
All paths are computed by a single, centralised PCE
Distributed Computation Model
Computation of paths is shared among multiple PCEs
Dependent path computation
• Independent path computation requests are not related to each other.
• Path computations for dependent path requests need to consider all such requests in path calculations e.g. computation of diverse paths for two LSPs
33
2
3
1
4
5
6
7
8
9
Requirement:• 2 LSPs:
• From 1 to 9• From 2 to 10
• LSPs need to be path-diverse
All IGP metrics are equal to 10 unless otherwise indicated
20
20
10
Single points of failure
Synchronised path computation
• Path computations for non-synchronised path computation requests may be performed in a serialized manner
• Synchronisation of path computation requests requires the PCE to compute them simultaneously i.e. to consider the best way of performing the computations to allow the greatest number of requests to succeed
• Dependent path calculations generally tend to be synchronised
34
Deployment models:Composite PCE node
35
Signaling Engine
TED
Service request
Signaling protocol
PCE
Head-end node Adjacent nodeRouting protocol
TED
Signaling Engine
Input Composite NodeA router that also implements PCE functionality (status quo in most current deployments)
Request/Response
PCC
Deployment models: External PCE
36
Signaling Engine
TED
Service request
Signaling protocol
PCE
TED synchronisationmechanism
Signaling Engine
Input External PCE NodePCE is physically decoupled from the routing element
External PCE
Head-end node Adjacent node
PCEP
PCC
Deployment models: Multiple PCEs
37
Signaling Engine
TED
Service request
Signaling protocol
PCE
Signaling Engine
Input
Multiple PCEsPCE for head-end receives partially-specified path for which intermediate nodes require further computation
Signaling protocol Signaling
Engine
TED
PCE
Input
External PCE External PCE
Head-end node Intermediate node Intermediate node
PCEP
PCC
PCEP
PCC
Deployment models:Multiple PCEs with inter-PCE comms
38
Signaling Engine
TED
Service request
Signaling protocol
PCE
Signaling Engine
Input
Multiple PCEsPCE for head-end requests other PCEs to help perform computation, using an inter-PCE protocol
Signaling protocol Signaling
Engine
TED
PCE
Input
Inter-PCE Request/Response
External PCE External PCE
Head-end node Intermediate node Intermediate node
PCEP
PCC
External PCE
Deployment models:Management-based PCE
39
Signaling Engine
Service request
Signaling protocol Signaling
Engine
Mgmt-based PCEsThe NMS acts as a PCC, receives path from the PCE and configures head-end node accordingly.
TED
PCE
Input
PCEP
Head-end node Adjacent node
Network Management
System (NMS)
Service request
TED synchronisationmechanism
PCC
Topology visibility for PCE
• There is no standards-defined mechanism mandated for a PCE to acquire network topology
• One option that is used by many implementations for the PCE is to use the services of a passive IGP listener
• BGP-LS provides an alternative option
40
Topology and TE information
41
Link-state database (LSDB) Traffic-engineering database (TED)
• Router IP addresses• Router link attributes:
• Neighbor router identifier• Local Interface IP address• Remote interface IP address• IP subnet address of link• IGP link metric
• Router IP addresses• Router link attributes:
• Local Interface IP address• Remote interface IP address• Traffic-engineering metric• Maximum bandwidth• Maximum reservable bandwidth• Unreserved bandwidth• Administrative group• Per-CoS reservation state• Pre-emption• SRLGs
42
Stateful PCE
Stateless PCEs
• All of the material covered thus far assumed Stateless PCEs.
• Stateless PCEs have knowledge of the Link-State Database and the Traffic Engineering Database and are able to make path computation decisions based on that– they generally do not have knowledge of existing paths and
computation requests can be processed independently of LSPs already present in the network
43
Stateful PCEs
• In addition to the LSDB and the TED, Stateful PCEs have complete knowledge of all paths (LSPs) in the network and the resources they have reserved in the network. – paths computed by Stateful PCEs also consider existing LSPs and
resource reservations– mechanisms are required to ensure Stateful PCEs are strictly
synchronised with the network
44
Terminology (1)
Passive Stateful PCEA PCE that takes into account LSP state information it has acquired from PCCs when calculating new paths. It does not actively update LSP state after initial path computation.
Active Stateful PCEA stateful PCE, in addition to considering existing LSPs in new path calculations, also issues recommendations on updating LSPs subsequent to the initial path calculation.
45
Terminology (2)
DelegationMechanism by which a PCC grants a PCE the right to update LSP parameters for an LSP belonging to that PCC.
LSP DBDatabase where a PCE stores information on all active LSPs in the network: complete network path, resource usage, constraints etc.
46
PCE taxonomy
47
Path Computation ElementElement that performs path computation
functions based on a network graph, taking into account specific constraints
Stateful PCEHave complete knowledge of topology, TE information and all paths (LSPs) in
the network and the resources they have reserved in the network
Passive StatefulMaintain knowledge of state of all
LSPs in the network but do NOTactively update LSP state after
initial computation
Stateless PCE
Have knowledge of topology and TE information in the network but not of
the existing LSPs
Active StatefulMaintain knowledge of state of all LSPs in the network and actively
update LSP state after initial computation
Deployment model: Stateful PCE
48
Signaling Engine
LSPDB
Service request
Signaling protocol
PCE
TED synchronisation
mechanism
Signaling Engine
Input
External PCE NodePCE is physically decoupled from the routing element
External Stateful PCE
Head-end node Adjacent node
PCEP
PCC
TED
Input
LSPDB synchronisation
mechanism
Motivations: LSP placement (1a)
49
Use case: Throughout maximisationObjective: Compute LSP placement in order to maximise utilisation of the networkPCE type: Stateless
A
E
B C
GF
All IGP metrics are equal to 10 with bandwidth of 10Gbps unless otherwise indicated
LSP computation requests:
Time LSP Src Dest Demand Routable ? Path
t1 1 E G 10 Yes E-F-G
t2 2 A B 10 No -
t3 3 F C 10 No -
Outcome:Only 50% of the network throughput is utilised as LSPs 2 and 3 could not be accommodated.
Motivations: LSP placement (1b)
50
Use case: Throughout maximisationObjective: Compute LSP placement in order to maximise utilisation of the networkPCE type: Stateful
A
E
B C
GF
All IGP metrics are equal to 10 with bandwidth of 10Gbps unless otherwise indicated
LSP computation requests:
Time LSP Src Dest Demand Routable ? Path
t1 1 E G 10 No -
t2 2 A B 10 Yes A-E-F-B
t3 3 F C 10 Yes F-G-C
Outcome:100% of the network throughput is utilised if LSP1 is rejected and LSPs 2 and 3 are accepted.
Motivations: LSP placement (2a)
51
Use case: Throughout maximisationObjective: Compute LSP placement in order to maximise utilisation of the networkPCE type: Stateless
All IGP metrics are equal to 10 with bandwidth of 10Gbps unless otherwise indicated
LSP computation requests:
Time LSP Src Dest Demand Routable ? Path
t1 1 A E 5 Yes A-C-D-E
t2 2 B E 10 No -
Outcome:Only part of the network throughput is utilised as LSP 2 could not be accommodated.
A
B
C E
D
Metric: 10BW: 5 Gbps
Motivations: LSP placement (2b)
52
Use case: Throughout maximisationObjective: Compute LSP placement in order to maximise utilisation of the networkPCE type: Stateful
All IGP metrics are equal to 10 with bandwidth of 10Gbps unless otherwise indicated
LSP computation requests:
Time LSP Src Dest Demand Routable ? Path
t1 1 A E 5 Yes A-C--E
t2 2 B E 10 Yes B-C-D-E
Outcome:By intelligent placement of LSP1, LSP 2 could also be accommodated
A
B
C E
D
Metric: 10BW: 5 Gbps
Motivations: LSP placement (3a)
53
Use case: DeadlockObjective: Avoid effects of deadlock when an LSP bandwidth increase request cannot be satisfiedPCE type: Stateless
All IGP metrics are equal to 10 with bandwidth of 10Gbps unless otherwise indicated
LSPs
LSP Src Dest Demand Path
1 A E 2 A-C-D-E
2 B E 2 B-C-D-E
Outcome:Failure to satisfy bandwidth upgrade request for LSP1 degrades its performance as well as that of LSP2
A
B
C E
D
Metric: 10BW: 5 Gbps
A requests bandwidth upgrade of LSP1 from 2G to
20G. Request cannot be fulfilled and LSP1 stays on its
current path.
Motivations: LSP placement (3b)
54
Use case: DeadlockObjective: Avoid effects of deadlock when an LSP bandwidth increase request cannot be satisfiedPCE type: Stateful
All IGP metrics are equal to 10 with bandwidth of 10Gbps unless otherwise indicated
LSPs
LSP Src Dest Demand Path
1 A E 2 A-C-D-E
2 B E 2 B-C-D-E
Outcome:Failure to satisfy bandwidth upgrade request for LSP1 degrades its performance but does not affect LSP2 as it is moved to another, diverse path.
A
B
C E
D
Metric: 10BW: 5 Gbps
A requests bandwidth upgrade of LSP1 from 2G to
20G. Request cannot be fulfilled and LSP1 stays on its current path. However, LSP2
is moved.B-C-E
Motivations: LSP placement (4a)
55
Use case: Minimum perturbationObjective: Limit the impact on the network (in terms of affected LSPs) when new LSP paths are computedPCE type: Stateless
All IGP metrics are equal to 10 with bandwidth of 10Gbps unless otherwise indicated
Outcome:Unnecessary network perturbation resulted from LSP1 being pre-empted
A
B
C E
D
Metric: 10
LSP2 is a higher priority LSP and preempts LSP1
LSP computation requests:
Time LSP Src Dest Demand Priority Routable ? Path
t1 1 A E 7 7 Yes A-C-D-E
t2 2 B E 7 0 Yes B-C-D-E
t3 1 A E 7 7 Yes A-C-ELSP1 is re-signaled
Motivations: LSP placement (4b)
56
All IGP metrics are equal to 10 with bandwidth of 10Gbps unless otherwise indicated
Use case: Minimum perturbationObjective: Limit the impact on the network (in terms of affected LSPs) when new LSP paths are computedPCE type: Stateful
All IGP metrics are equal to 10 with bandwidth of 10Gbps unless otherwise indicated
Outcome:Unnecessary network perturbation was avoided assuming the path computation requests were relatively close in time.
A
B
C E
D
Metric: 10
LSP computation requests:
Time LSP Src Dest Demand Priority Routable ? Path
t1 1 A E 7 7 Yes A-C-E
t2 2 B E 7 0 Yes B-C-D-E
Motivations: LSP placement (5a)
57
Use case: PredictabilityObjective: To provide a better degree of predictability over how paths are routedPCE type: Stateless
All IGP metrics are equal to 10 with bandwidth of 10Gbps unless otherwise indicated
LSP computation requests:
Time LSP Src Dest Demand Routable ? Path
t1 1 A E 7 Yes A-C-E
t2 2 B E 7 Yes B-C-D-E
Outcome:LSP from A to E gets the shorter path since it was requested first
A
B
C E
D
Motivations: LSP placement (5b)
58
Use case: PredictabilityObjective: To provide a better degree of predictability over how paths are routedPCE type: Stateless
All IGP metrics are equal to 10 with bandwidth of 10Gbps unless otherwise indicated
LSP computation requests:
Time LSP Src Dest Demand Routable ? Path
t1 1 B E 7 Yes B-C-E
t2 2 A E 7 Yes A-C-D-E
Outcome:LSP from B to E gets the shorter path since it was requested first
A
B
C E
D
Motivations: Recovery (5a)
59
Use case: Co-ordinated protectionObjective: To ensure protection resources are not over-subscribedPCE type: Stateful
All IGP metrics are equal to 10 with bandwidth of 10Gbps unless otherwise indicated
LSP computation requests:
Time LSP Src Dest Demand Routable ? Path
t1 1-W A E 2 Yes A-E
1-P A E Yes A-B-E
t2 2-W B E 2 Yes B-A-E
2-P B E Yes B-E
Outcome:If link A-E fails, both LSPs fail and end up using the same protection resources (B-E link)
A
E
B C
D
Motivations: Recovery (5b)
60
Use case: Co-ordinated protectionObjective: To ensure protection resources are not over-subscribedPCE type: Stateful
All IGP metrics are equal to 10 with bandwidth of 10Gbps unless otherwise indicated
LSP computation requests:
Time LSP Src Dest Demand Routable ? Path
t1 1-W A E 2 Yes A-E
1-P A E Yes A-B-E
t2 2-W B E 2 Yes B-C-D-E
2-P B E Yes B-E
Outcome:LSPs 1 and 2 share no SRLGs so can share protection resources (B-E link)
A
E
B C
D
61
PCE-initiated LSPs
PCE-initiated LSPs
• Till now, we have considered PCE models where a PCE computes LSP paths at the request of PCCs i.e. all LSP-creation requests were PCC-initiated.
• In a stateful PCE scenario:– PCEs are synchronised with all LSPs on all PCCs and are kept
informed of changes impacting any of these LSPs– The PCC may delegate a PCE the authority to make changes to
LSPs subsequent to their creation.
• A PCE-initiated LSP is one that is created on a PCC at the request of a PCE
62
LSP taxonomy
63
Local PCE-computedPath is computed by PCE function
hosted on same node as PCC (Composite PCE)
External PCE-computed
Computed by an external PCE at the request of a PCC
Delegated LSPPCE is given the authority to
update LSP parameters by the PCC
Label Switched PathA path from an ingress to an
egress LER in an MPLS network
Traffic-engineered LSPLSP follows a path that is
calculated to fufil certain network constraints as calculated by a
constrained SPF algorithm
PCC-initiatedAn LSP that is configured on a
PCC.
Shortest-Path LSP
LSP follows the shortest path as determined by an IGP
PCE-initiatedAn LSP that is created on a
PCC at the request of a PCE
Motivations
• PCC-instantiated LSPs are suited to networks where traffic flows are reasonably static.
• The PCE-initiated LSP is better suited to SDN environments requiring on-demand connectivity– Dynamic network optimisation algorithms that place new LSPs and
update existing LSPs in order to better balance traffic in the network– NFV applications where VNFs are dynamically instantiated, scaled
and torn down
64
65
Path Computation Element Protocol (PCEP)
Objectives
• Path Computation Element Protocol (PCEP): protocol used for communication between:– a PCC and a PCE, OR– between two PCEs
• A PCC uses the PCEP to send a path computation request for one or more TE LSPs to a PCE
• The PCE replies to the PCC with zero or more computed paths
66
Sessions
• Runs over TCP on port 4189
• For a stateless PCE, PCEP sessions can be either:– Permanent: kept permanently up, OR– Temporary: in which case a session is established whenever a path
computation is required and torn down when completed.
• For a stateful PCE, PCEP sessions are required to be set up on a permanent basis
67
PCEP Messages (1)
68
Value Type Abbreviatedname
1 Open
2 Keepalive
3 Path ComputationRequest
PCReq
4 Path Computation Reply PCRep
5 Notification PCNtf
6 Error
7 Close
8 Path Computation Monitoring Request
PCMonReq
9 Path ComputationMonitoring Reply
PCMonRep
10 Report PCRpt
11 Update PCUpd
12 Initiate PCInit
Original set of messages specified for Stateless PCE (RFC5440)
Extensions for PCE monitoring
(RFC5886)
Stateful PCE extensions (draft-ietf-pce-stateful-pce)Extensions for PCE-
initiated LSPs (draft-ietf-pce-pce-initiated-lsp)
PCEP Messages (2)
69
Value Type Short name Purpose
1 Open Initiate PCEP session
2 Keepalive Maintain PCEP session
3 Path ComputationRequest
PCReq Sent by PCC to PCE to request a path computation
4 Path Computation Reply PCRep Send by PCE to PCC in response to a PCReq
5 Notification PCNtf Sent by either side to notify of a specific event
6 Error Sent on occurrence of an error
7 Close Used to close a session
8 Path Computation Monitoring Request
PCMonReq Sent by a PCC to a PCE to get PCE state metrics
9 Path ComputationMonitoring Reply
PCMonRep Sent by a PCE to a PCE in response to a PCMonReq
10 LSP State Report PCRpt Sent by a PCC to a PCE to report the current state of an LSP
11 LSP Update Request PCUpd Sent by a PCE to a PCC to update the attributes of an LSP
12 Initiate PCInitiate Sent by a PCE to a PCC to trigger LSP creation or deletion
Operation: Initialisation
70
PCC PCE
TCP 3-way handshake
Negotiation of Keepalive timer and DeadTimer
Operation: Keepalives
71
PCC PCE
Keepalivetimer
seconds
Keepalivetimer secondsKeepalives
Keepalives act as beacons and are not responded to. Each side advertises its Keepaliver timer and the Deadtimer its peer should use.Default: 30s
Operation: Path computation
72
PCC PCE
PCReq
PCRep
Path computation event
1.PCReq received2.Successful path
computation3.Computed paths
sent to PCC
PCReq ExampleCompute a TE LSP between source A and destination B with bandwidth=B Gbps, max latency=80 ms
• Source/Dest IP• Setup/hold priority• Bandwidth• Metric to be optimised
• ERO• Bandwidth• Actual metric
Header format
• All PCEP messages use the following common header followed by a set of message-specific objects
73
flags length
32 bits16 bits16 bits
typever
version:- current version is version 1
message type:- as per previous table
Object format
• All PCEP objects messages use the following common object header followed by object-specific fields
74
Object class:- Identifies the PCEP object class
OT:- Object type- Combination of object class and OT uniquely identifies each PCEP object
P-flag:- Set for objects that must be considered in path computation
I-flag:- Set for optional objects that were ignored during path computation
length
32 bits16 bits16 bits
OTObject class
P IRES
Object body
Message formats (1)
75
32 bits
Open MessageUsed to establish a PCEP session
Keepalive MessageUsed to keep the PCEP session active
common header
OPEN object (Mandatory, qtty: 1)
32 bits
common header
32 bits
Close MessageUsed to terminate a PCEP session
common header
CLOSE object (Mandatory, qtty: 1)
• Keepalive• Deadtimer• PCEP session
identifier
• Reason for closing the PCEP session
Message formats (2)
76
32 bits
PCReq Message• Used to request a path computation• May carry more than one request
One or more
requests
common header
SVEC object (Optional, qtty: 1 or more)
RP object (Mandatory, qtty: 1)
END-POINTS object (Mandatory, qtty: 1)
LSPA object (Optional., qtty: 1)
BANDWIDTH object (Optional., qtty: 1)
METRIC object (Opt., qtty: 1 or more)
RRO object (Optional., qtty: 1)
IRO object (Optional., qtty: 1)
LOAD-BALANCING object (Opt., qtty: 1 or more)
• Request Parameters (RP):• Priority• Re-optimisation flag• Request ID
• Source and destination IP address of path
• Requested bandwidth
• Indicates metric to be optimised:• IGP metric• TE metric• Hop count
• Maximum bound on path cost
• Reported Route Object for re-optimisation
• LSP attributes to be considered• Setup/hold priority
• Include Route Object for element
that must be included in path
• Sychronisation Vector (SVEC) object• Lists a set of request IDs
that must be synchronised• Can indicate dependency
such as:• Link diverse• Node diverse• SRLG diverse
• Allows use of set of TE LSPs to satisfy a large bandwidth demand
Message formats (3)
77
32 bits
PCRep Message• Sent by PCE to PCC in response to a PCReq
• May carry more than one reply
One or more
responses
common header
RP object (Mandatory, qtty: 1)
NO-PATH object (Optional, qtty: 1)
LSPA object (Optional., qtty: 1)
BANDWIDTH object (Optional., qtty: 1)
METRIC object (Opt., qtty: 1 or more)
IRO object (Optional., qtty: 1)
ERO object (Mandatory, qtty: 1)
LSPA object (Optional., qtty: 1)
BANDWIDTH object (Optional., qtty: 1)
METRIC object (Opt., qtty: 1 or more)
IRO object (Optional., qtty: 1)
For unsuccessful computations
One or more for successful computations
• Used for unsuccessful computations
• Specifies nature of issue
• Specify constraints that could not be satisfied
• Computed path of TE LSP
78
PCEP extensions for stateful PCE
Objectives
• Allow a single PCC to interact with a mix of stateless and stateless PCEs using the same PCEP protocol
• Provide a mechanism for state synchronisation between the PCC and a stateful PCE
• Allow a PCC to delegate control of LSPs to an active stateful PCE
79
New messages
• Path Computation State Report (PCRpt)– sent by a PCC to a PCE to report on the status of one or more LSPs– includes the LSP’s path, bandwidth, operational status, admistrative
status– also used for delegating control of an LSP to a PCE– sent:
• whenever the state of an LSP changes• in response to an LSP Update Request from a PCE
• Path Computation Update Request (PCUpd)– sent by a PCE to a PCC to update parameters for one or more LSPs
80
Operation: capability advertisement
81
PCC PCE
Presence of ‘Stateful PCE Capability’ TLV indicates that the PCC is willing to send LSP State Reports when LSP state changes. If LSP-UPDATE-CAPABILITY flag is set, PCC supports LSP delegation
Presence of ‘Stateful PCE Capability’ TLV indicates that the PCE is interested to receive LSP State Reports when LSP state changes.If LSP-UPDATE-CAPABILITY flag is set, PCE supports LSP delegation
Operation: state synchronisation
82
PCC PCE
PCRpt, SYNC=1
PCRpt, SYNC=1
PCRpt, SYNC=1
PCRpt, SYNC=1
PCRpt, SYNC=0
State SynchronisationAfter initialisation, PCC sends a complete snapshot of its LSP state to the PCE
…
Start of synchronisation
End of synchronisation. PCE has up-to-date database of all LSPs owned by the PCE
Operation: passive stateful req/rep
83
PCC PCE
Passive StatefulRequest/ResponseModified process for stateful PCE
Request received, path computed
LSP state change eventLSP State Report sent to
all PCEs
Request sent to PCE
Computed path sent to PCC
Report for future state change events
Operation: LSP delegation
84
PCC PCE
LSP DelegationPCC delegates an LSP to the PCE by setting the ‘Delegate’ flag in the PCRpt to 1.
…
LSP delegated
Delegate bit must be set to 1 in all LSP State Reports while delegation is in force
Delegation confirmed
Operation: LSP delegation revocation
85
PCC PCE
LSP Delegation RevocationPCC revokes delegation of an LSP to the PCE by setting the ‘Delegate’ flag in the PCRpt to 0.
…
LSP delegated
Delegate bit must be set to 1 in all LSP State Reports while delegation is in force
Delegation confirmed
LSP delegation is revoked. PCE may revert to operator-defined paramaters
Operation: returning LSP delegation
86
PCC PCEReturning LSP DelegationPCE return delegation of an LSP to the PCC by setting the ‘Delegate’ flag in the PCUpd to 0.
…
LSP delegated
Delegation confirmed
PCC indicates that there is no delegation for this LSP
Delegation returned
Operation: active stateful LSP update
87
PCC PCE
Active Stateful LSP UpdatePCE requests update and PCC reports on outcome
LSP delegated
LSP State Report sent: state changed to ‘Going-up’
LSP delegated to PCE
PCE decides to update the LSP
LSP State Report sent: state changed to ‘Up’
State synchronisation
PCUpd message sent to PCC
Message formats (1)
32 bits
PCRpt Message• Used by PCC to report state of LSPs to PCEs
• May carry more than one request
common header
SRP object (Optional, qtty: 1)
LSP object (Mandatory, qtty: 1)
ERO object (Mandatory, qtty: 1)
BANDWIDTH object (Optional., qtty: 1)
METRIC object (Opt., qtty: 1 or more)
RRO object (Optional., qtty: 1)
BANDWIDTH object (Optional., qtty: 1)
METRIC object (Opt., qtty: 1 or more)
• Stateful PCE Request Parameters (SRP):• Required for PCRpts sent
in response to PCUpd• Carries SRP-ID: uniquely
identifies PCE update request for an LSP
• Used to correlate between PCUpd request and corresponding State Reports
One or more
reports
Intended path
Actual attribute list
Actual path
Intended attribute list
• LSP object:• PLSP-ID: Unique PCEP-
specific LSP identifier allocated by PCC
• Flags:• Delegate flag• Sync flag• Remove flag: used by
PCC to notify PCE that LSP has been removed
• Operational state: down, up, active, going-down, going-up
• LSP Identifiers TLV (for RSVP-TE):• Tunnel Sender Address• LSP ID• [Extended] Tunnel ID• Tunnel Endpoint Address
• Symbolic Path Name TLV
Message formats (2)
32 bits
PCUpd Message• Used by PCE to request update of LSP parameters
• May carry more than one request
common header
SRP object (Mandatory, qtty: 1)
LSP object (Mandatory, qtty: 1)
ERO object (Mandatory, qtty: 1)
BANDWIDTH object (Optional., qtty: 1)
METRIC object (Opt., qtty: 1 or more)
• Stateful PCE Request Parameters (SRP):• Carries SRP-ID: uniquely
identifies PCE update request for an LSP
• Used to correlate between PCUpd request and corresponding State Reports
One or more
requests• Explicit Route
Object (ERO)• Intended path of
TE LSP
Message formats (3)
90
32 bits
PCReq Message• Used to request a path computation• May carry more than one request
One or more
requests
common header
SVEC object (Optional, qtty: 1 or more)
RP object (Mandatory, qtty: 1)
END-POINTS object (Mandatory, qtty: 1)
LSP object (Optional., qtty: 1) **NEW**
LSPA object (Optional., qtty: 1)
BANDWIDTH object (Optional., qtty: 1)
METRIC object (Opt., qtty: 1 or more)
RRO object (Optional., qtty: 1)
IRO object (Optional., qtty: 1)
LOAD-BALANCING object (Opt., qtty: 1 or more)
• Request Parameters (RP):• Priority• Re-optimisation flag• Request ID
• Source and destination IP address of path
• Requested bandwidth
• Indicates metric to be optimised:• IGP metric• TE metric• Hop count
• Maximum bound on path cost
• Reported Route Object for re-optimisation
• LSP attributes to be considered• Setup/hold priority
• Include Route Object for element
that must be included in path
• Sychronisation Vector (SVEC) object• Lists a set of request IDs
that must be synchronised• Can indicate dependency
such as:• Link diverse• Node diverse• SRLG diverse
• Allows use of set of TE LSPs to satisfy a large bandwidth demand
Message formats (4)
91
32 bits
PCRep Message• Sent by PCE to PCC in response to a PCReq
• May carry more than one reply
One or more
responses
common header
RP object (Mandatory, qtty: 1)
NO-PATH object (Optional, qtty: 1)
LSP object (Optional., qtty: 1) **NEW**
LSPA object (Optional., qtty: 1)
BANDWIDTH object (Optional., qtty: 1)
METRIC object (Opt., qtty: 1 or more)
IRO object (Optional., qtty: 1)
ERO object (Mandatory, qtty: 1)
LSP object (Optional., qtty: 1) **NEW**
LSPA object (Optional., qtty: 1)
BANDWIDTH object (Optional., qtty: 1)
METRIC object (Opt., qtty: 1 or more)
IRO object (Optional., qtty: 1)
For unsuccessful computations
One or more for successful computations
• Used for unsuccessful computations
• Specifies nature of issue
• Specify constraints that could not be satisfied
• Computed path of TE LSP
92
PCEP extensions for PCE-initiated LSPs
New messages
• LSP Initiate Request (PCInitiate)– sent by a PCE to a PCC to request the instantiation (or deletion) of
an LSP– the PCC:
• creates the LSP using supplied attributes• generates an LSP State Report (PCRpt) for the LSP with a newly assigned PLSP-
ID• sets the delegate bit in the LSP State Report
• The PCE is able to update parameters for the LSP by sending PCUPd messages
93
Operation: capability advertisement
94
PCC PCE
Presence of ‘Stateful PCE Capability’ TLV indicates that the PCC is willing to send LSP State Reports when LSP state changes. The LSP-INSTANTIATION-CAPABILITY flag (I- flag) is set to indicate support of PCE-initiated LSPs.The LSP-UPDATE-CAPABILITY flag has to be set as well.
Presence of ‘Stateful PCE Capability’ TLV indicates that the PCE is interested to receive LSP State Reports when LSP state changes.The LSP-INSTANTIATION-CAPABILITY flag (I- flag) is set to indicate support of PCE-initiated LSPs.The LSP-UPDATE-CAPABILITY flag has to be set as well.
Operation: PCE-initiated LSP creation
95
PCC PCE
PCE-initiated LSP creationPCE requests creation of LSP
LSP State Report sent: state changed to ‘Going-up’
LSP created by PCC
PCE decides to update the LSP
LSP State Report sent: state changed to ‘Up’
PCUpd message sent to PCC
Message formats (1)
32 bits
PCInitiate Message• Used by PCE to request creation of an LSP by a PCC
• May carry more than one request
common header
SRP object (Mandatory, qtty: 1)
LSP object (Mandatory, qtty: 1)
END-POINTS object (Optional, qtty: 1)
ERO object (Mandatory, qtty: 1)
BANDWIDTH object (Optional., qtty: 1)
METRIC object (Opt., qtty: 1 or more)
• Stateful PCE Request Parameters (SRP):• Carries SRP-ID: uniquely identifies
PCE initiate request for an LSP• Used to correlate between
PCInitiate request and corresponding State Reports
One or more
requests• Explicit Route
Object (ERO)• Intended path of
TE LSP
• LSP object:• PLSP-ID: set to 0• Flags:
• Delegate flag
96
32 bits
PCRpt Message• Used by PCC to report state of LSPs to PCEs
• May carry more than one request
common header
SRP object (Optional, qtty: 1)
LSP object (Mandatory, qtty: 1)
ERO object (Mandatory, qtty: 1)
BANDWIDTH object (Optional., qtty: 1)
METRIC object (Opt., qtty: 1 or more)
RRO object (Optional., qtty: 1)
BANDWIDTH object (Optional., qtty: 1)
METRIC object (Opt., qtty: 1 or more)
• Stateful PCE Request Parameters (SRP):• Required for PCRpts sent in
response to PCUpd/PCInitiate• Carries SRP-ID: uniquely
identifies PCE update request for an LSP
• Used to correlate between PCUpd/PCInitiate request and corresponding State Reports
One or more
reports
Intended path
Actual attribute list
Actual path
Intended attribute list
• LSP object:• PLSP-ID: Unique PCEP-specific
LSP identifier allocated by PCC• Flags:
• Delegate flag• Sync flag• Create flag: to indicate that
the LSP was PCE-initiated.• Remove flag: used by PCC to
notify PCE that LSP has been removed
• Operational state: down, up, active, going-down, going-up
• LSP Identifiers TLV (for RSVP-TE):• Tunnel Sender Address• LSP ID• [Extended] Tunnel ID• Tunnel Endpoint Address
• Symbolic Path Name TLV• Speaker Entity ID TLV: identifies
PCE which initiated LSP
Message formats (2)
98
Extensions for Segment Routing
Building the Segment List
• In a Segment Routing network, the ingress LER has to impose a label stack on packets corresponding to the required TE path.
• How can the ingress LER derive this information ?
• One solution is to use an external PCE.
99
SR-TE LSP Paths
• SR-TE LSPs computed by a PCE can take one of the following forms:
– Ordered set of IP addresses representing segments (links or nodes); in this case, the PCC would have to translate these to the appropriate MPLS labels
– Ordered set of SIDs
– An ordered set including both MPLS labels and IP addresses in which case the IP addresses needs to be translated to MPLS labels.
100
Operation: capability advertisement
101
PCC PCE
Presence of ‘SR PCE Capability’ TLV indicates that the PCC is capable of supporting the head-end functions for SR-TE LSP
Presence of ‘SR PCE Capability’ TLV indicates that the PCE is capable of computing SR-TE paths
Message extensions
102
SRP object (Optional, qtty: 1)
RP object (Mandatory, qtty: 1) • [Stateful PCE] Request Parameters ([S]RP):• Includes PATH-SETUP-TYPE TLV that
indicates PST=1 (Segment Routing)
ERO object (Mandatory, qtty: 1)
• Explicit Route Object• Carries new SR-ERO sub-object:
• SID <-> NAI (Node of Adjacency Identifier)
• Indication of loose or strict hop• Flags to indicate whether a complete
MPLS label stack is provided or just the MPLS label
• NAI can be an IPv4/v6 Node ID or IPv4/v4 Adjacency ID
RRO object (Optional, qtty: 1)
• Reported Route Object• Carries new SR-RRO sub-object:
• SID <-> NAI (Node of Adjacency Identifier)
• Flags to indicate whether a complete MPLS label stack is provided or just the MPLS label
• NAI can be an IPv4/v6 Node ID or IPv4/v4 Adjacency ID
103
Operational Considerations
PCE discovery
• PCEs may be discovered by a PCC either via:– Local configuration– IGP extensions
104
105
References
References (1)• RFC4105: Requirements for Inter-Area MPLS Traffic Engineering
• RFC4655: A Path Computation Element (PCE)-Based Architecture
• RFC5440: Path Computation Element (PCE) Communication Protocol (PCEP)
• RFC5152: A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)
• RFC8051: Applicability of a Stateful Path Computation Element (PCE)
• draft-ietf-pce-stateful-pce: PCEP Extensions for Stateful PCE
• draft-ietf-pce-segment-routing: PCEP Extensions for Segment Routing
• draft-ietf-pce-pce-initiated-lsp: PCEP Extensions for PCE-initiated LSP Setup in a StatefulPCE Model
106
References (2)• A Quick Start to Path Computation Element (PCE) | Packet Design:
www.packetdesign.com/blog/quick-start-path-computation-element-pce/
• http://www.olddog.co.uk/AdrianFarrel-TheRoleOfPCEInAnSDNWorld.pdf
• http://www.olddog.co.uk/Farrel_PCE_Tutorial.ppt
• http://www.olddog.co.uk/AdvancedPCE.pdf
• http://content.ipspace.net/get/PCEP
107
Issue Date:
Revision:
Thank You !End of session
[Date]
[xx]
WSDN01_v0.1