wsdn01 - module 5 - pce - v1

Issue Date:

Revision:

SDN Workshop

Contact: [email protected]

[Date]

[xx]

WSDN01_v0.1

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

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

Element

. . .

Router 1 Router 2 Router n

One PCE for many PCCs



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

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


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


Engine

Mgmt-based PCEsThe NMS acts as a PCC, receives path from the PCE and configures head-end node accordingly.

TED

PCE

Input

PCEP


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


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




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.


51

Use case: Throughout maximisationObjective: Compute LSP placement in order to maximise utilisation of the networkPCE type: Stateless




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


52

Use case: Throughout maximisationObjective: Compute LSP placement in order to maximise utilisation of the networkPCE type: Stateful




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



53

Use case: DeadlockObjective: Avoid effects of deadlock when an LSP bandwidth increase request cannot be satisfiedPCE type: Stateless


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


A requests bandwidth upgrade of LSP1 from 2G to

20G. Request cannot be fulfilled and LSP1 stays on its

current path.


54

Use case: DeadlockObjective: Avoid effects of deadlock when an LSP bandwidth increase request cannot be satisfiedPCE type: Stateful


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


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


55

Use case: Minimum perturbationObjective: Limit the impact on the network (in terms of affected LSPs) when new LSP paths are computedPCE type: Stateless


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


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


56


Use case: Minimum perturbationObjective: Limit the impact on the network (in terms of affected LSPs) when new LSP paths are computedPCE type: Stateful


Outcome:Unnecessary network perturbation was avoided assuming the path computation requests were relatively close in time.

A

B

C E

D

Metric: 10


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


57

Use case: PredictabilityObjective: To provide a better degree of predictability over how paths are routedPCE type: Stateless




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


58

Use case: PredictabilityObjective: To provide a better degree of predictability over how paths are routedPCE type: Stateless




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




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




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


NO-PATH object (Optional, qtty: 1)





ERO object (Mandatory, 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


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


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)







• 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


common header

SRP object (Mandatory, qtty: 1)





• Stateful PCE Request Parameters (SRP):• Carries SRP-ID: uniquely


• 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)


END-POINTS object (Mandatory, qtty: 1)

LSP object (Optional., qtty: 1) **NEW**






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


NO-PATH 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


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


common header

SRP object (Mandatory, qtty: 1)


END-POINTS object (Optional, qtty: 1)




• 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


common header









• Stateful PCE Request Parameters (SRP):• Required for PCRpts sent in

response to PCUpd/PCInitiate• Carries SRP-ID: uniquely


• 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


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


RP object (Mandatory, qtty: 1) • [Stateful PCE] Request Parameters ([S]RP):• Includes PATH-SETUP-TYPE TLV that

indicates PST=1 (Segment Routing)


• 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

wsdn01 - module 5 - pce - v1

Documents