PCEP Technology White Paper

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Contents

Overview·· 1

Technical background· 1

Benefits· 1

PECP implementation· 1

PCEP network model 1

PCEP message· 2

Message types· 2

PCEP message header format 3

Object message format 3

Open message· 6

Keepalive message· 6

PCReq message· 6

PCRep message· 6

PCNtf message· 7

PCErr message· 7

Close message· 7

PCRpt message· 7

PCUpd message· 8

PCInitiate message· 8

Operating mechanism·· 8

PCEP session establishment 8

Path calculation· 9

LSP delegation· 11

Application scenarios· 12

Inter-domain network· 12

References· 13

 

Overview

Technical background

Path calculation in a large multiple domain network is highly complex. In some scenarios, it is necessary to deploy special computing components on the controller and enable collaboration between nodes in different domains to complete path calculation. This reduces the efficiency of the network element in path calculation and also decreases its forwarding performance.

The Path Computation Element Communication Protocol (PCEP) centrally controls the path calculation function within the network. The calculation units individually handle the calculation of MPLS and SRv6 paths to address the mentioned issues. The core concept of centralized computing in PCEP is well matched with SDN technology. Therefore, PCEP is also considered as one of the solutions for migrating MPLS networks to SDN networks.

 

NOTE: This document only covers the relevant content of calculating LSP paths using PCEP technology.

 

Benefits

PCEP has the following characteristics:

·     Centralized control: Centralize the network's path calculation function, improving path calculation efficiency, and facilitating the management and maintenance of the network.

·     Inter-domain path computation: In a large multiple domain network, inter-domain path computation can be achieved through the collaboration of multiple PCEs.

PECP implementation

PCEP network model

As shown in Figure 1, a typical PCEP network consists of the following components:

·     A Path Computation Element (PCE) is an entity in a network that provides path computation services for devices on the network. It can perform path computations within areas or calculate complete LSP paths in complex network environments.

·     The Path Computation Client (PCC) requests the PCE to execute path computation and establishes an LSP based on the path information returned by the PCE.

·     PCEP session: The session established between PCC and PCE, or between PCEs. There are two types of PCEP sessions:

¡     Stateless PCEP sessions: In this type of PCEP session, the PCC only requests the PCE to execute path computation, while the PCE only provides path computation services.

¡     Stateful PCEP session: In this type of PCEP session, the PCC reports all LSP information within the network to the PCE; besides providing path computation services, the PCE can create, delete, and optimize in-domain LSPs to maximize the allocation and utilization of network resources. Stateful PCE sessions include the following two types:

-     Active-stateful PCEP session: In an active-stateful PCEP session, the PCC can delegate LSPs to the PCE, and the PCE can optimize the LSPs.

-     Passive-stateful PCEP session: In a passive-stateful PCEP session, the PCE only maintains the LSP information reported by the PCC and does not support LSP delegation and optimization.

 

NOTE: LSP delegation refers to the PCC authorizing the PCE to modify LSPs on the PCC.

 

·     PCEP is a communications protocol that runs between PCC and PCE, or between PCEs. It is used to establish PCEP sessions and exchange PCEP messages. The protocol is based on TCP.

·     The two ends that establish a PCEP session are called PCEP peers.

Figure 1 PCEP network model

 

PCEP message

The session establishment, maintenance, path computation, and update between PCC and PCE are accomplished through the interaction of PCEP messages. A PCEP message consists of a PCEP message header and a variable-length message body. The message body is composed of one or more objects. The main content of PCEP messages is carried by different objects.

Message types

PCEP messages include the following types:

·     Open message: Used to initiate a PCEP session.

·     Keepalive message: A keep-alive message for the PCEP session.

·     Path Computation Request (PCReq) message: A message sent by the PCC to the PCE requesting path computation.

·     Path Computation Reply (PCRep) message: A path computation reply message sent by the PCE to the PCC.

·     Path Computation Notification (PCNtf) message: An event notification message sent by the PCC to the PCE or by the PCE to the PCC.

·     Path Computation Error (PCErr) message: An error notification message sent by the PCC to the PCE or by the PCE to the PCC.

·     Close message: A message used to close a PCEP session.

·     Path Computation LSP State Report (PCRpt) message: A message sent by the PCC to the PCE to report the current state of an LSP.

·     Path Computation LSP Update Request (PCUpd) message: A PCEP message sent by the PCE to the PCC to update LSP information.

·     LSP Initiate Request (PCInitiate) message: A PCEP message sent by the PCE to the PCC to initiate the creation of an LSP.

PCEP message header format

As shown in Figure 2, the PCEP message header contains the following content:

·     Version: version number of PCEP, with a length of 3 bits.

·     Flags: A flag field, 5 bits in length. Currently undefined, filled with zeros in the message.

·     Message-Type(8 bits): 8-bit field. The following message types are currently supported:

¡     1: Open

¡     2: Keepalive

¡     3: PCReq

¡     4: PCRep

¡     5: PCNtf

¡     6: PCErr

¡     7: Close

¡     10: PCRpt

¡     11: PCUpd

¡     12: PCInitiate

·     Message-Length(16 bits): The total length of the PCEP message, including the PCEP message header, is 16 bits.

Figure 2 PCEP message header format

 

Object message format

Composition of an object

An object is composed of two parts, namely the object header and the object body.

As shown in Figure 3, the content included in the header of the object is as follows:

·     Object-Class: PCEP object class, with a length of 8 bits.

·     Object-Type (OT): PCEP object type, with a length of 4 bits. The Object-Class and Object-Type fields uniquely identify a PCEP object.

·     Res: A reserved field, 2 bits in length. This field must be set to zero during transmission and ignored upon receipt.

·     Processing-Rule (P): The P flag in a PCEP message from PCC to PCE indicates whether the specified object must be considered by the PCE during path computation. When the P flag is set to 1, it means the PCE must consider the object. Conversely, when the P flag is set to 0, the object is optional, and the PCE may ignore it.

·     Ignore (I): The I flag in a PCEP message indicates to the PCC whether the PCE considered an optional object. If the I flag is set to 1, the optional object was ignored during path computation. Conversely, if the I flag is set to 0, the PCE considered the optional object. The I flag is meaningless in a PCRep message if the corresponding PCReq message's I flag is set to 1.

·     Object Length: Indicates the total object length, including the object header, in bytes. The object length field must always be a multiple of 4 and at least 4. The maximum object length is 65 528 bytes.

Figure 3 Object header message format

 

Different object bodies have different message formats. Below are some common types of object bodies.

Open object

The Object-Class and Object-Type fields of the Open object are both set to 1. As shown in Figure 4, the Open object body contains the following content:

·     Ver: PCEP version number, 3 bits in length.

·     Flags: A flag field, 5 bits in length. Currently undefined, filled with zeros in the message.

·     Keepalive: The interval for sending Keepalive messages.

·     DeadTimer: The aging time for the PCEP session.

·     SID: PCEP session ID.

·     Optional TLVs: Optional TLVs, such as the STATEFUL-PCE-CAPABILITY TLV.

Figure 4 Open object body message format

 

Bandwidth object

The value of the Object-Class field for the Bandwidth object is 5, and the Object-Type field includes two values. When the value is 1, it represents the requested link bandwidth. When the value is 2, it represents the current bandwidth of the link that needs to be adjusted in the automatic bandwidth adjustment scenario. As shown in Figure 5, the Bandwidth object body has a fixed length of 4 bytes, with the bandwidth value measured in bytes per second.

Figure 5 Bandwidth object format

 

Metric object.

The Object-Class and Object-Type fields of the Metric object are set to 6 and 1, respectively. As shown in Figure 6, the Metric object body includes the following content:

·     Reserved(16 bits): A field with a length of 16 bits. Currently undefined, all filled with 0 in the message.

·     Flags: A flag field, 8 bits in length. The currently defined flags are B (Bound) and C (Computed Metric).

·     T: Metric type. The currently defined metric types are as follows:

¡     1: IGP metric.

¡     2: TE metric.

¡     3: Hop count.

·     Metric value: The value of a metric.

Figure 6 Metric object body message format

 

Explicit Route object

The Object-Class and Object-Type fields of the Explicit Route object have values of 7 and 1, respectively. As shown in Figure 7, the Explicit Route object contains the following information:

·     L: The L flag must be set to 0 in the message.

·     Type: The currently defined types are:

¡     1: Indicates IPv4 type.

¡     2: Indicates IPv6 type.

¡     3: Indicates Label type.

·     Length: The length of the object.

·     U: A flag indicating the direction of the label. A value of 0 indicates a downstream label; a value of 1 indicates an upstream label.

·     C-type: The service type.

·     Label: The label value of the path.

Figure 7 Explicit Route Object Body Message Format

 

SRP object

The Object-Class and Object-Type fields of the SRP (Stateful PCE Request Parameters) object are set to 33 and 1, respectively. As shown in Figure 8, the SRP object body includes the following content:

·     Flags: A flag field, 16 bits in length. Currently undefined, filled with zeros in the message.

·     SRP ID: The Stateful PCE request ID.

·     Optional TLVs: Optional TLVs, such as the PATH-SETUP-TYPE TLV.

Figure 8 Explicit Route object body message format

 

Open message

The Open message is used to establish and maintain PCEP sessions between PCEP peers. It must be the first PCEP message sent from a PCC to a PCE or from a PCE to a PCC.

During the establishment of a PCEP session, the PCEP peers negotiate the PCEP session parameters carried in the Open message. If both parties agree on these parameters, the PCEP session will be successfully established; otherwise, the TCP connection between PCEP peers will be closed. The session parameters contained in the Open message are as follows.

·     PCEP version

·     Keepalive send interval.

·     Session aging time.

·     PCEP session ID.

·     PCEP capabilities set, such as session type (stateful, stateless) and local Segment Routing capability.

Keepalive message

Keepalive messages are PCEP messages transmitted by PCC or PCE to maintain the persistence and activity of a session. Keepalive messages are also used to respond to Open messages, validating that the Open message has been received and that the PCEP session parameters carried in the Open message are acceptable.

The Keepalive messages carry no objects. The interval for sending Keepalive messages is negotiated through the Keepalive send interval included in the Open message. The interval between Keepalive messages can vary between PCEP peers.

Any PCEP message has the function of session keep-alive.

PCReq message

The PCReq message is a PCEP message sent by a PCC to a PCE requesting path computation.

The PCReq message primarily carries the following information:

·     Path computation request ID.

·     Source IP address for the requested path computation.

·     Destination IP address for the requested path computation.

·     Constraints for path computation:

¡     Priority.

¡     Path Constraint: Include or exclude a specific node, shared risk link group (SRLG), or interface address.

¡     Affinity attributes.

¡     Bandwidth information.

¡     Metric information.

PCRep message

The PCE responds to the received PCReq message by transmitting a path calculation response message to the PCC.

If the PCE successfully computes the path, the reply in the PCRep message primarily carries the following information:

·     Path computation request ID. This ID matches the one carried in the corresponding PCReq message.

·     Calculated path information.

If the PCE path calculation fails, the PCRep message will primarily include the reason for the path calculation failure.

PCNtf message

The PCNtf message can be sent from a PCE to a PCC or from a PCC to a PCE to notify about specific events. The main events are as follows:

·     The path calculation request has been canceled by the PCC.

·     The current state of PCE is overload.

·     The current state of PCE is no longer in overload.

PCErr message

The PCErr message can be sent by a PCE to a PCC or by a PCC to a PCE to notify about errors occurring between PCEP peers. PCErr messages are mainly sent in the following situations:

·     A protocol error occurs. For example, an LSP created by a PCInitiate message already exists on the PCC.

·     The PCEP message does not comply with the PCEP protocol specification. For example, if a message with the wrong format is received or if the received message is missing an object.

Close message

The Close message can be sent by a PCE to a PCC or by a PCC to a PCE to close an established PCEP session.

Upon receiving a Close message, the PCEP peers must cancel all pending requests, refrain from sending any other types of PCEP messages, and close the TCP connection between the PCEP peers.

PCRpt message

The PCRpt message is a PCEP message sent by a PCC to a PCE to report the current status of an LSP. The following scenarios trigger the PCC to send a PCRpt message:

·     PCC receives an LSP update request from PCE.

·     The state of the LSP on the PCC has changed.

The main contents of the nPCRpt message package are as follows:

·     PLSP ID: Identifies an LSP.

·     LSP operational flags and status flags. Operational flags include managed, reported, and synchronized, while status flags include Up, Down, and Active.

·     Stateful PCE Request ID. The ID matches the Stateful PCE request ID carried by the corresponding PCUpd message.

·     Path information.

·     Bandwidth information.

·     Metric information.

·     Affinity attributes.

·     Priority.

PCUpd message

The PCUpd message is a PCEP message sent by a PCE to a PCC to update LSP information. The PCUpd message mainly includes the following content:

·     PLSP ID: Identifies an LSP.

·     LSP operational and status flags. Operational flags include managed, reported, and synchronized, while status flags include Up, Down, and Active.

·     Path information.

·     Stateful PCE request ID: Identifies an update request.

·     Bandwidth information.

·     Link metrics.

·     Affinity attributes.

·     Priority.

PCInitiate message

In LSP delegation scenarios, the PCInitiate message is a PCEP message sent by a PCE to a PCC to create an LSP. The PCInitiate message mainly contains the following content:

·     PLSP ID: Identifies an LSP.

·     LSP operational and status flags. Operational flags include managed, synchronized, etc., while status flags include Up, Down, and Active.

·     Path information.

·     Stateful PCE request ID.

·     Bandwidth information.

·     Metric information.

·     Affinity attributes.

·     Priority.

Operating mechanism

This section uses the establishment of a PCEP session between a PCC and a PCE as an example to introduce the working mechanisms of PCEP session establishment, path computation, and LSP delegation.

PCEP session establishment

A PCC can discover a PCE in the network to establish a PCEP session in the following ways:

·     Statically specify the PCE on the PCC device.

·     Advertise the PCE's IP address into the network using OSPF TE.

As shown in Figure 9, the process of establishing PCEP sessions between PCEP peers is as follows:

1.     TCP connections are established between PCEP peers.

2.     The PCC transmits an Open message to the PCE.

3.     The PCE transmits an Open message to the PCC.

4.     Upon receiving the Open message, the PCE negotiates session parameters based on the information carried in the message. If successful, it sends a Keepalive message to confirm.

5.     After the PCC receives the Open message, it negotiates session parameters based on the information in the message. If successful, it sends a Keepalive message to confirm.

6.     When both PCEP peers have received a Keepalive message from the other, the PCEP session is considered established..

Figure 9 PCEP session establishment

 

Path calculation

PCC initiates the path calculation request to PCE for path computation. PCE calculates the path for PCC, and PCC establishes the LSP based on the path computation result from PCE.

Intra-domain path calculation

As shown in Figure 10, AS 1 needs to calculate an LSP from the Ingress node to the Egress node. The specific process for calculating the path within the domain is as follows:

1.     The PCC transmits a PCReq message to the PCE.

2.     After receiving the PCRep message, the PCE uses a constraint-based path optimization algorithm to calculate a path that meets the constraints in the TEDB (Traffic Engineering Database) to reach the destination node.

3.     Upon successful path computation, the PCE sends a PCRep message.

4.     After receiving the PCRep message, the PCC establishes an LSP based on the path computed by the PCE.

Figure 10 Intra-domain path computation

 

Inter-domain path computation

As shown in Figure 11, in a multi-domain scenario, since PCE 1 within AS 1 cannot learn the IGP routing information within AS 2 where the Egress node is located, it cannot compute the LSP path to the Egress node. Therefore, PCE 2 within AS 2 needs to collaborate to compute the inter-domain LSP path. The specific process for inter-domain path computation is as follows:

1.     The PCC transmits a PCReq message to PCE 1, requesting computation of the LSP to reach the Egress node. The PCReq message carries the addresses of PCE 1 and PCE 2.

2.     After receiving the PCReq message, PCE 1 realizes that it cannot calculate the path information to reach the Egress node. Therefore, it transmits the PCReq message to PCE 2, requesting PCE 2 to calculate the path information from PCE 1 to the Egress node.

3.     After receiving the PCRep message, PCE 2 calculates a path to the destination node that satisfies the constraint conditions using a constraint-based path first algorithm in the TEDB. Then it transmits the path information to PCE 1 through the PCReq message.

4.     After receiving the PCReq message from PCE 2, PCE 1 calculates the path information from the Ingress node to PCE 1, combines it with the path information from PCE 1 to the Egress node, and responds to the PCC via the PCRep message.

5.     After receiving the PCRep message, the PCC establishes an LSP based on the path computed by the PCE.

Figure 11 Inter-domain path computation

 

LSP delegation

LSP delegation refers to the PCE having the authority to modify LSPs on the PCC, with the PCE initiating the creation and updating of LSP paths.

As shown in Figure 12, an Active-Stateful PCEP session is established between the PCC and the PCE. LSPs can be established or updated on the PCC in the following ways:

·     The PCC delegates LSP 1 to the PCE by sending a PCRpt message. After computing the path for LSP 1, the PCE informs the PCC to update LSP 1 via a PCUpd message.

·     PCE actively transmits the PCInitiate message to request the creation of LSP 2. After receiving the PCInitiate message, the PCC creates LSP 2 on the basis of path information, and then reports and delegates LSP 2 to PCE through the PCRpt message.

Figure 12  LSP delegation, update, and creation

 

Application scenarios

Inter-domain network

As shown in Figure 13, deploying PCE nodes in large-scale multi-domain networks can enhance the efficiency of intra-domain and inter-domain path computation. With the network's path computation functions centrally controlled by the PCE, it is easier for administrators to manage and maintain the network. The PCC delegates and reports LSPs to the PCE, which maintains the network's TEDB, also reducing the load on other network elements. Therefore, the application of PCEP is widespread in large multi-domain MPLS networks.

Figure 13 Inter-domain network

 

References

·     RFC 5440: Path Computation Element (PCE) Communication Protocol (PCEP)

·     RFC 8231: Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE

·     RFC 8281: Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model

·     RFC 8408: Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages