PCEP configuration¶
There is a list of necessary elements to know when setting up a PCEP framework.
PCEP overview¶
PCEP (Path Computation Element Protocol) is a TCP based protocol used between path computation elements. The documentation focuses on the communication between the path computation client (PCC) and the path computation element (PCE). The PCE is responsible for computing and determining paths in a network, while the PCC stands for the router in charge of forwarding or switching the traffic. Generally, the PCC requests path computations to the PCE for head-end LSPs sourced from the PCC. The PCC can also act passively, while the PCE will take control of the PCC, updating the LSPs with the PCEP protocol too.
PCEP allows the PCC to communicate its requirements and constraints to the PCE, which will compute requested paths.
The Virtual Service Router uses the PCEP protocol and implements the PCC side to create SR policies in MPLS segment routing networks.
There are multiple advantages to using the PCEP protocol with a PCE server:
PCE allows for a centralized approach, and is responsible for computing and optimizing paths in the network. This centralization enables better coordination and control over path decisions, leading to more efficient resource utilization, like using under-used links in the topology, or separating high priority from best effort flows.
PCE can be used for inter-domain path computation, enabling coordination between different network domains. This is particularly valuable in large-scale networks where traffic may traverse multiple domains.
PCE overview¶
A PCE requires certain information to perform path computations effectively. The traffic engineering database (TED) is part of this information and contains the topology and resource information of the domain. The TED may be fed by IGP extensions from the IS-IS protocol. In order to aggregate topology information from multiple domains, the BGP link state protocol may be used to convey this information to the server.
More information about BGP-LS protocol: :ref: BGP Link State <routing-bgp-ls>
Note
Virtual Service Router does not support the BGP-LS speaker mode, which may be necessary for sending link-state information to a PCE server.
A PCE controller has multiple working modes, and the PCC functionality of the Virtual Service Router is able to cooperate in the below mentioned working modes.
When a dynamic candidate path is configured and selected on the PCC,
path computation request messages are sent for each computation request. The PCE
tries to compute the path and either sends a positive path computation reply with
the explicit route object (ERO) containing the LSP information; or the PCE
sends a negative path computation reply message, indicating that no LSP path
could be provided. More information about dynamic candidate path configuration.
This way of working is called the stateless mode: the LSP policy state of each
PCC is not known by the PCE, there is no ongoing state information stored on the
PCE, all the PCC requests are processed independently. Stateless PCE is simpler
but may not be as adaptive to real-time changes in the network.
When working in stateful mode, in addition to replying to requests of the PCCs,
the PCE maintains synchronised information about the network’s current state of
each PCC, at each LSP policy operational status change. If the PCE has the
stateful capability, then the PCC sends lsp state report messages, to inform
about the LSP status changes. Stateful PCE allows for better control and
optimization of paths based on real-time network conditions. For instance, the
lsp state report messages optionally include a recorded route object (RRO),
which gives information to the PCE about the LSP information that the PCC
knows, about how to steer colored traffic up to the endpoint. This information is
used by the PCE to better syncronise with the PCC.
The active stateful mode mode is a sub-mode of the stateful mode. When the delegation
bit of a report message LSP is set to 1, The PCE is allowed to send multiple
path communication update messages to the PCC. Those messages update the
dynamic LSP policy, whenever a change in the synchronised information is detected
by the PCE.
There is an additional working mode called pce-initiated lsp setup where the
PCC exchanges an additional capability that authorises PCE to create LSPs
instead of only relying on the PCC configured LSP policies. An example consists in
letting the PCE to create the whole policies, by means of the PCEP protocol. More
information about delegated mode configuring delegated mode in pcc.
PCC configuration¶
PCC Server configuration¶
The below configuration establishes a PCEP communication with the 192.0.2.10
and the 192.0.2.20 PCE controllers. By default, the PCEP protocol operates
over the TCP destination port 4189.
vsr running config# vrf main
vsr running vrf main# interface physical eth0
vsr running physical eth0# ipv4 address 192.0.2.1/24
vsr running physical eth0#
vsr running vrf main# routing segment-routing
vsr running segment-routing# enabled true
vsr running segment-routing# traffic-engineering
vsr running traffic-engineering# pcep
vsr running pcep# pcc
vsr running pcc# pce server1
vsr running pce server1# server 192.0.2.10 port 4189
vsr running pce server1# source 192.0.2.1 port 10001
vsr running pce server1# priority 10
vsr running pce server1# ..
vsr running pcc# pce server2
vsr running pce server2# server 192.0.2.20 port 4189
vsr running pce server2# source 192.0.2.1 port 10002
vsr running pce server2# priority 5
vsr running pce server2# commit
The below command dumps the status of the PCEP session with the PCE controller:
vsr> show segment-routing pcep session
2 session(s) configured.
2 session(s) connected.
Name Status Address Port Connected since PCE keepalive PCE dead-timer Primary PCE confidence
==== ====== ======= ==== =============== ============= ============== ======= ==============
server1 up 192.0.2.10 4189 04m53s 30s 02m00s True normal
server2 up 192.0.2.20 4189 05m53s 30s 02m00s False normal
The Primary information tells which PCE effectively replies to PCE requests from the
PCC. Only the established connection with the lowest priority will be the primary server.
When the primary PCE fails, the PCC will synchronise its state with the secondary PCE.
The secondary PCE will be considered as the primary one.
The below command dumps the capabilities exchanged between the PCC and the PCE devices.
vsr> show segment-routing pcep session capability
Name Type Capabilities
==== ==== ============
server1 PCE sr-te-pst stateful-pce
server1 PCC pcc-initiated-lsps sr-te-pst stateful-pce
server2 PCE sr-te-pst stateful-pce
server2 PCC pcc-initiated-lsps sr-te-pst stateful-pce
To maintain the connectivity, keepalive PCEP messages are sent when no other PCEP
message is sent. A keepalive frequency interval value is exchanged in PCEP open
messages. The keepalive-interval configurable parameter determines the PCC
transmitted frequency interval. Reversely, the keepalive-peer-min-interval and
keepalive-peer-max-interval values control the acceptable keepalive value sent by
the PCE: when out of range, the PCC will not establish the PCEP connection. By
default, the PCC keepalive value is set to 30 seconds.
A similar control mechanism is present for the dead-interval value which stands for
the time a PCC waits before considering a PCEP session down when no PCEP messages
are received. By default, the PCE dead interval timer value is set to 120 seconds.
The below configuration changes the default timer values.
vsr running config# vrf main
vsr running vrf main# routing segment-routing
vsr running segment-routing# traffic-engineering
vsr running traffic-engineering# pcep
vsr running pcep# pcc
vsr running pcc# pce server1
vsr running pce server2# timer keepalive-interval 45
vsr running pce server2# timer keepalive-peer-min-interval 60
vsr running pce server2# timer keepalive-peer-max-interval 90
vsr running pce server2# timer dead-interval 45
vsr running pce server2#
PCC segment-routing capability announcement¶
In a PCEP communication, each device sends its own capability in the PCEP open message.
By default, the Virtual Service Router sends the segment routing capability as a sub-tlv in the path setup
type capability TLV, as per RFC 8664. This option is not well understood by some PCE
vendors that implement an alternative tlv as depicted in draft-ietf-pce-segment-routing-07.
The pce-segment-routing draft-ietf-07 command facilitates the interoperability with those
PCE vendors.
vsr running vrf main# routing segment-routing
vsr running segment-routing# enabled true
vsr running segment-routing# traffic-engineering
vsr running traffic-engineering# pcep
vsr running pcep# pcc
vsr running pcc# pce server1
vsr running pce server1# server 192.0.2.10 port 4189
vsr running pce server1# source 192.0.2.1 port 10001
vsr running pce server1# priority 10
vsr running pce server1# pce-segment-routing draft-ietf-07
vsr running pce server1#
PCC configuration in delegated mode¶
When operating in stateful mode, the PCE can be configured to create
LSP policies on each PCC. The below pce-initiated command adds a
new PCC capability named pcc-and-pce-initiated-lsps that will be
used by PCE to send initiated LSPs.
vsr running vrf main# routing segment-routing
vsr running segment-routing# enabled true
vsr running segment-routing# traffic-engineering
vsr running traffic-engineering# pcep
vsr running pcep# pcc
vsr running pcc# pce server1
vsr running pce server1# server 192.0.2.10 port 4189
vsr running pce server1# source 192.0.2.1 port 10001
vsr running pce server1# priority 10
vsr running pce server1# pce-initiated
vsr running pce server1#
vsr> show segment-routing pcep session capabilities
Name Type Capabilities
==== ==== ============
server1 PCE sr-te-pst stateful-pce
server1 PCC pcc-and-pce-initiated-lsps sr-te-pst stateful-pce
No additional SR-TE configuration is required by the PCE to completely take the control of the LSP policies of the PCC.
PCC maximum sid depth control¶
When computing a path, the PCE needs to take into account the maximum number
of labels that a PCC can support. The msd value is a PCEP parameter
sent to the PCE, that stands for the maximum number of label stack that a
computed LSP should have on the PCC device. This value is set to 4 by default
and can be modified:
vsr running vrf main# routing segment-routing
vsr running traffic-engineering# pcep
vsr running pcep# pcc
vsr running pcc# msd 8
vsr running pce server1# server 192.0.2.10 port 4189
vsr running pce server1#